Dette er prinsippene og fallgruvene ved å rotere Master Key på Panorama, PAN-OS-brannmurer og Log Collectors. Kommandoer, menyvalg og sjekklister ligger i den fulle gjennomføringsveiledningen.
Harde fakta som styrer prosedyren: nøkkelen skal være nøyaktig 16 tegn, verken 15 eller 17. Den kan ikke leses ut eller eksporteres fra enheten, så gjenoppretting er ikke mulig, og det finnes ingen rollback etter byttet uten factory reset. Utløper nøkkelen, rebooter enheten i maintenance mode, interne SSH-nøkler og sertifikatnøkler nulles, og factory reset kreves. Master Key synkroniseres aldri automatisk mellom HA-peers, den må settes på begge noder manuelt. Byttet utløser automatisk commit, så ventende endringer må committes først. Maksimal levetid er 18 250 dager (50 år), selv om Palo Alto anbefaler maks to år. Time for Reminder kan uansett aldri settes lenger enn 365 dager. Én ting til: en konfigurasjonseksport er ubrukelig uten nøkkelen den ble kryptert med, så arkivér nøkkelen sammen med, og samtidig som, konfigurasjonsbackupene.
Rekkefølgen: brannmurer først, deretter Panorama
Prinsippet i sju steg: commit alt ventende i Panorama og push til enhetene, slå av HA config sync på brannmur-HA-par, bytt nøkkel på de managed brannmurene med HA-par først, slå på HA config sync igjen og verifiser, bytt nøkkel på Panorama én node av gangen med HA midlertidig av og identisk nøkkel satt manuelt på begge peers, bytt nøkkel på Log Collectors som må ha samme nøkkel som Panorama, og til slutt slå på Panorama-HA igjen, resynkroniser alle enheter og verifiser. Brannmurene tas før Panorama, fordi Panorama trenger en fungerende styringskanal for å sende nøkkelen ut.
Vær obs på at den mest googlebare prosedyren for dette (KB kA10g000000PPboCAG) er utdatert. Den beskriver en prosedyre for PAN-OS 8.1/9.x der Panorama-konfigurasjonen deaktiveres på brannmuren, med dokumentert nedetid som konsekvens. Fra PAN-OS 10.1 pushes nøkkelen direkte fra Panorama med Deploy Master Key, uten dataplane-restart og uten trafikkbrudd. Legg arbeidet i vedlikeholdsvindu likevel, siden commit-tiden ikke er null og feilscenarioene er alvorlige.
Nøkkelstrategi: splitt for å begrense skadeomfanget
Unike nøkler per brannmur eller HA-par er støttet fra PAN-OS 10.1. To bindinger gjelder uansett: HA-par må dele nøkkel, og Log Collectors må dele Panoramas. En tredeling som følger de naturlige skillelinjene i miljøet, styringsplattform, datasenter og distribuerte lokasjoner, balanserer skadebegrensning mot forvaltbarhet bedre enn både én nøkkel for alt og én nøkkel per enhet. Restrisikoen ved delt nøkkel skal aksepteres eksplisitt: mistes én enhet i en gruppe som deler nøkkel, er hemmelighetene for alle som deler den eksponert. Beredskapsscenarioet må være definert på forhånd, slik at nøkkelen byttes på alle som deler den hvis noe skjer. Generér selve nøkkelverdien tilfeldig i hvelvet, og dropp krav om «ett tegn fra hver kategori», det reduserer bare entropien uten gevinst når verdien uansett genereres av et verktøy.
Levetid: lang på enheten, kort i rutinen
Anbefalingen er ti års levetid på selve enheten, kombinert med en toårs rotasjonsrutine drevet av en sak i sakssystemet, ikke av enheten selv. Dette er et bevisst avvik fra Palo Altos anbefalte to år, og bør behandles som et avvik i risikoregisteret. Begrunnelsen: en utløpt nøkkel er verre enn en gammel nøkkel, siden konsekvensen av glemt rotasjon er katastrofal og irreversibel, mens konsekvensen av forlenget levetid er teoretisk.
Palo Alto oppgir at hver Master Key kan generere opptil 2³² unike krypteringer før initialiseringsvektoren gjentar seg, og begrunner toårsrådet med forventet volum av krypteringer, men definerer aldri hva som utgjør én kryptering. Vår slutning — og det er en slutning, ikke en dokumentert beregning — er at det dokumenterte peker mot lagrede konfigurasjonsobjekter og ikke mot trafikkvolum: Master Key krypterer privatnøkkelen SSL Forward Proxy bruker, ikke hver dekrypteringssesjon. Merk også at problemet med gjenbruk av initialiseringsvektor gjelder AES-256-GCM (nivå 2) særskilt, og ikke treffer AES-256-CBC (nivå 1) på samme måte.
Palo Alto anbefaler likevel nivå 2. Vi anbefaler å la nivået stå gjennom selve rotasjonen og planlegge en eventuell heving som en egen sak — begrunnelsen står i gjennomføringsveiledningen.
Fordi Time for Reminder maksimalt kan settes til 365 dager, utløser enhetens egen påminnelse først i år 9 av et tiårsløp, og kan derfor ikke drive toårsrutinen. Rutinen må i stedet hvile på et hvelvflagg og en sak med frist, opprettet samme dag som nøkkelen settes. Master Key bør også inn i sjekklisten for enhver migrering av hvelv, Panorama eller brannmurer, siden en tapt nøkkel først oppdages når noen trenger den.
Tre pilotfunn
En testkjøring på én brannmur før resten av porteføljen avdekket tre udokumenterte forhold: pågående innholdsoppdateringer blokkerer nøkkelbyttet midlertidig, men feilen er ufarlig og per enhet. Panorama kan melde «vellykket» før enheten faktisk er ferdig, så sjekk task manager før du leser systemlogg. Og enhetsvelgeren i deploy-dialogen husker forrige valg, så kontrollér utvalget hver gang, ellers kan en enhet falle ut av utvalget og bli stående på standardnøkkelen uten at noen ser det.
Automatisk utrulling fra 12.2.2, med én felle
Fra PAN-OS 12.2.2 kan en device master key på Panorama pushes automatisk til hver ny brannmur ved første tilkobling. Dette krever to ting samtidig: nøkkelen satt under Master Key Configuration for Auto Deployed Devices, og avkryssingen for automatisk push aktivert i riktig Template Stack. Mangler avkryssingen, skjer ingenting og ingen feilmelding vises. Brannmuren står da på standardnøkkelen med en løpende frist som ingen får vite om. Verifiser per enhet i Panorama > Managed Devices > Summary. Kolonnen «Default Master Key Enabled» skal vise No, og «Days Remaining to Configure Custom Master Key» skal vise Not Applicable.
Last ned hele gjennomføringsveiledningen, SA-2026-08-08, med CLI-kommandoer, sjekklister og feilhåndtering ved å trykke på lenken under og fylle ut litt informasjon.
Kilder
Alle lenker verifisert 21. august 2026.
- Manage the Master Key from Panorama — Panorama Administrator’s Guide. Hovedreferanse for rekkefølgen i sju steg, for at HA-peers ikke synkroniserer nøkkelen, for at Log Collectors og WildFire-enheter må dele Panoramas nøkkel, og for automatisk utrulling fra 12.2.2. Oppdatert 30.07.2026
- Configure a Master Key — NGFW Administration. 16-tegnskravet, levetid fra 1 time til 18 250 dager, påminnelse opptil 365 dager, og grunnlaget for 2³²-betraktningen. Oppdatert 18.08.2026
- Master Key Encryption — NGFW Administration. Oversikt over hva nøkkelen krypterer
- Is there a way to recover a lost Master Key? — KB kA10g000000PLwECAW. Ingen gjenoppretting, factory reset er eneste utvei
- How to update the Master Key on Panorama and synchronize with firewalls — KB kA10g000000PPboCAG. Dette er den utdaterte prosedyren artikkelen advarer mot. Skrevet for PAN-OS 8.1, 9.0 og 9.1, og har «Now Firewall experiences downtime» som dokumentert steg 4. Lenken står her for at leseren skal kjenne den igjen, ikke for å følges
For mer informasjon, ta kontakt:
