Skift en VPN-adgangskode uden at låse alle enheder ude
En kodeændring opdaterer ikke gemte kopier. Lav en oversigt over hver klient, erstat den gemte værdi hos dens ejer, og stop gentagelsesløkken.
Tre telefoner, en router og et overvågningstjek holder stadig den gamle adgangskode, og en af dem genopretter forbindelse hvert minut og et halvt. Kontoadgangskoden blev ændret for ti minutter siden, så hver af disse klienter sender nu en værdi, som serveren afviser. Det er det øjeblik, myten brister: en kodeændring rører kontoen, ikke kopierne af den gamle værdi på hver enhed. Det, der følger, er det arbejde, ændringen ikke gjorde.
Myten: én ændring, overalt på én gang
Troen er, at en kodeændring logger alt ud og tvinger et rent nyt login. Det gør den ikke, fordi serveren kun holder styr på, hvilken legitimationsoplysning den sidst accepterede, mens klienterne beholder det, de har gemt. En enhed med en gemt adgangskode prøver den igen efter sin egen tidsplan og fejler i det stille, indtil nogen opdager, at kontoen er låst. Når man accepterer, at kopierne lever uden for kontoen, holder rotation op med at ligne en enkelt handling.
Intet af dette taler imod rotation. Det taler for at behandle de gemte kopier som en del af ændringen i stedet for en eftertanke. En udelåsning kommer normalt fra parallelle gentagelser: hver enhed bliver ved med at sende den gamle værdi efter sin egen tidsplan, indtil tælleren slår til. Kontoen ser så angrebet ud, mens den blot får tilbudt legitimationsoplysninger, som ingen har erstattet. Den forskel betyder noget, fordi løsningen er en liste over enheder og ikke en strengere udelåsningspolitik.
Kortlæg kopierne, før du roterer
Skriv oversigten, før du åbner adgangskodeformularen. List hver klient, script, automatisering og administreret profil, der autentificerer som denne konto: telefonen, der forbinder af sig selv, routeren, der blev konfigureret for to år siden, laptop’en, der kun vågner om mandagen, og overvågningstjekket, der prøver hvert minut. For hver af dem skal du notere, hvor legitimationsoplysningen er gemt, om enheden kan nås under ændringen, og hvilken gendannelsesvej der findes, hvis den ikke kan genoprette forbindelsen. Den liste er det, der gør en risikabel ændring til en planlagt ændring, og den skal findes, før den gamle adgangskode holder op med at virke.
Offline enheder er den klassiske forglemmelse. En laptop i en skuffe vender tilbage tre uger senere og præsenterer den forældede værdi på det værst tænkelige tidspunkt. Noter også dens placering og tidsplan, fordi du bliver nødt til at jage den i stedet for at vente på den.
På en Linux-flåde er søgningen mekanisk snarere end smart. Leder du efter profiler, der henviser til en legitimationsfil, derefter efter legitimationsfilerne selv, fordi den anden liste er den, der skal skrives om. Gentag øvelsen for desktopklienter og telefoner, hvor lageret er en profil eller en nøgleringspost i stedet for en sti. Målet er en liste, du kan arbejde dig igennem, ikke en scanning, der påstår at finde hver kopi.
grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null
Mål kopierne op mod de mennesker, der ejer dem. En enhed, som ingen gør krav på, er en enhed, som ingen opdaterer, og den er også den, der mest sandsynligt bliver ved med at prøve igen.
Hvilken hemmelighed du egentlig roterer
En kontoadgangskode er kun én legitimationsoplysning i en VPN-udrulning. En nøgleadgangsfrase, en certifikatidentitet og en valgfri peer-hemmelighed har hver deres erstatningsvej og deres egen ejer. At ændre kontoadgangskoden gør intet for en enhed, der autentificerer med et certifikat, og at genudstede et certifikat gør intet for en klient med en gemt adgangskode. Navngiv hemmeligheden, før du navngiver løsningen.
Hvis rotationen er drevet af mistanke snarere end af politik, har hændelsesprocessen forrang for bekvemmelighedsplanen. Tilbagekald det, som beviserne kræver, og accepter det ekstra arbejde på enhedslisten. Den beslutning tilhører hændelsesejeren, ikke hvem der tilfældigvis holder formularen til nulstilling af adgangskode.
Erstat den gemte værdi, der hvor den bor
Skift legitimationsoplysningen gennem den mekanisme, som tjenesten dokumenterer, og opdater derefter den gemte kopi eller kør loginforløbet på hver enhed, du vil beholde. Rediger ikke en genereret konfiguration bag en manager, der skriver den om, fordi manageren gendanner den ældre værdi ved næste kørsel, og redigeringen bliver en forsinket fejl. Opdater den kilde, manageren læser, eller brug klientens eget legitimationslager. Under alle omstændigheder skal enheden ende med den nye værdi på det sted, hvor klienten faktisk læser.
En klient, der gemmer en adgangskodefil, har brug for, at filen skrives om, mens en klient, der spørger, har brug for et fuldført login. NetworkManager gemmer hemmeligheden inde i forbindelsesprofilen, så ændringen går gennem nmcli i stedet for en teksteditor:
nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work
En profil, der læser en legitimationsfil, er et tredje tilfælde. Erstat indholdet af den fil, hold dens tilladelser lukkede, og genindlæs klienten i stedet for at redigere den profil, der peger på den. Profilen ændrede sig ikke; kun hemmeligheden, den læser, ændrede sig.
Genopret forbindelsen for hver tilsigtet enhed én gang, bevidst, og se, hvilke der fejler. Hvis en enhed bliver ved med at fejle, så se på den konto, den peger på, og det lager, den læser, før du ændrer adgangskoden igen, fordi en anden ændring mangedobler de kopier, der skal opdateres. En enhed, der fejler to gange, peger normalt på den forkerte konto eller læser et lager, du ikke har fundet endnu. Ret det, og genopret derefter forbindelsen.
Sessioner og tokens overlever adgangskoden
At ændre adgangskoden beviser ikke, at eksisterende sessioner eller separate certifikater blev tilbagekaldt. Nogle tjenester holder en session i live, indtil den udløber eller afsluttes eksplicit, og udstedte tokens har deres egen levetid. Kontroller, hvad tjenesten faktisk gør, i stedet for at antage, at ændringen var global. Hvis ændringen var drevet af mistanke, skal du afslutte sessionerne eksplicit og bekræfte resultatet.
Vejledningen om legitimationsoplysningers livscyklus i NIST SP 800-63B holder autentifikatorer og sessioner i adskilte kategorier, og derfor er en kodeændring og en global logout to forskellige handlinger. Behandl dem som to opgaver med to færdiggørelseskriterier. Den første er færdig, når den nye værdi virker, og den anden er færdig, når de gamle sessioner er væk.
Registrer færdiggørelsen uden at skrive den nye adgangskode ind i posten. En rotationslog, der indeholder legitimationsoplysningen, er en ny hændelse, der venter på et delt drev. Noter datoen, de opdaterede enheder og de enheder, der stadig mangler.