Een VPN-wachtwoord wijzigen zonder elk apparaat buitenshuis te sluiten

Drie telefoons, een router en een monitoringcontrole houden nog steeds het oude wachtwoord, en een ervan maakt elke negentig seconden opnieuw verbinding. Het accountwachtwoord is tien minuten geleden gewijzigd, dus elk van die clients stuurt nu een waarde die de server weigert. Dat is het moment waarop de mythe breekt: een wachtwoordwijziging raakt het account, niet de kopieën van de oude waarde op elk apparaat. Wat volgt is het werk dat de wijziging niet deed.

De mythe: één wijziging, overal tegelijk

De overtuiging is dat een wachtwoordwijziging alles afmeldt en een schone nieuwe aanmelding afdwingt. Dat doet ze niet, omdat de server alleen bijhoudt welke inloggegevens hij laatst heeft geaccepteerd, terwijl de clients vasthouden wat ze hebben opgeslagen. Een apparaat met een opgeslagen wachtwoord probeert het opnieuw volgens zijn eigen schema en faalt stil, tot iemand merkt dat het account vergrendeld is. Zodra je aanvaardt dat de kopieën buiten het account leven, ziet rotatie er niet langer uit als één handeling.

Niets daarvan pleit tegen rotatie. Het pleit voor het behandelen van de opgeslagen kopieën als deel van de wijziging en niet als een gedachte achteraf. Een vergrendeling komt meestal van parallelle herhalingen: elk apparaat blijft de oude waarde volgens zijn eigen schema sturen tot de teller aanslaat. Het account lijkt dan aangevallen terwijl het alleen inloggegevens krijgt aangeboden die niemand heeft vervangen. Dat onderscheid is belangrijk, want de oplossing is een lijst met apparaten en niet een strenger vergrendelingsbeleid.

Inventariseer de kopieën voordat je roteert

Schrijf de inventaris voordat je het wachtwoordformulier opent. Noem elke client, script, automatisering en beheerd profiel dat zich als dit account authenticeert: de telefoon die zelf verbinding maakt, de router die twee jaar geleden is geconfigureerd, de laptop die alleen op maandag wakker wordt, en de monitoringcontrole die het elke minuut probeert. Noteer voor elk waar de inloggegevens zijn opgeslagen, of het apparaat tijdens de wijziging bereikbaar is en welke herstelroute bestaat als het niet opnieuw kan verbinden. Die lijst is wat een riskante wijziging in een geplande wijziging verandert, en ze moet bestaan voordat het oude wachtwoord stopt met werken.

Offline apparaten zijn de klassieke misser. Een laptop in een la komt drie weken later terug en presenteert de verouderde waarde op het slechtst mogelijke moment. Noteer ook de locatie en het schema, want je zult erachteraan moeten in plaats van erop te wachten.

Op een Linux-vloot is het zoeken mechanisch en niet slim. Zoek profielen die naar een inloggegevensbestand verwijzen, en dan de inloggegevensbestanden zelf, want de tweede lijst is degene die herschreven moet worden. Herhaal de oefening voor desktopclients en telefoons, waar de opslag een profiel of een sleutelhanger-item is en geen pad. Het doel is een lijst waarmee je kunt werken, niet een scan die beweert elke kopie te vinden.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Weeg de kopieën af tegen de mensen die ze bezitten. Een apparaat dat niemand opeist, is een apparaat dat niemand bijwerkt, en het is ook degene die het meest waarschijnlijk blijft herhalen.

Welk geheim je werkelijk roteert

Een accountwachtwoord is maar één inloggegeven in een VPN-implementatie. Een sleutelwachtwoordzin, een certificaatidentiteit en een optioneel peer-geheim hebben elk hun eigen vervangingsroute en eigenaar. Het accountwachtwoord wijzigen doet niets voor een apparaat dat met een certificaat authenticeert, en een certificaat opnieuw uitgeven doet niets voor een client met een opgeslagen wachtwoord. Noem het geheim voordat je de oplossing noemt.

Als de rotatie door wantrouwen en niet door beleid wordt gedreven, gaat het incidentproces voor op het gemaksplan. Trek in wat het bewijs vereist en accepteer het extra werk op de apparatenlijst. Die beslissing hoort bij de eigenaar van het incident, niet bij wie toevallig het formulier voor het resetten van het wachtwoord vasthoudt.

Vervang de opgeslagen waarde waar ze leeft

Wijzig de inloggegevens via het mechanisme dat de dienst documenteert, werk daarna de opgeslagen kopie bij of voer de aanmeldingsstroom uit op elk apparaat dat je wilt behouden. Bewerk geen gegenereerde configuratie achter een beheerder die haar herschrijft, want de beheerder herstelt de oudere waarde bij de volgende run en de bewerking wordt een uitgestelde fout. Werk de bron bij die de beheerder leest, of gebruik de eigen opslag voor inloggegevens van de client. Hoe dan ook, het apparaat moet eindigen met de nieuwe waarde op de plek waar de client werkelijk leest.

Een client die een wachtwoordbestand opslaat, heeft het bestand herschreven nodig, terwijl een client die vraagt een voltooide aanmelding nodig heeft. NetworkManager houdt het geheim in het verbindingsprofiel, dus de wijziging loopt via nmcli en niet via een teksteditor:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

Een profiel dat een inloggegevensbestand leest, is een derde geval. Vervang de inhoud van dat bestand, houd de rechten gesloten en herlaad de client in plaats van het profiel te bewerken dat ernaar verwijst. Het profiel is niet veranderd; alleen het geheim dat het leest is veranderd.

Verbind elk bedoeld apparaat één keer opnieuw, bewust, en kijk welke falen. Als een apparaat blijft falen, kijk dan naar het account waarnaar het wijst en de opslag die het leest voordat je het wachtwoord opnieuw wijzigt, want een tweede wijziging vermenigvuldigt de kopieën die bijgewerkt moeten worden. Een apparaat dat twee keer faalt wijst meestal naar het verkeerde account of leest een opslag die je nog niet hebt gevonden. Repareer dat en maak dan opnieuw verbinding.

Sessies en tokens overleven het wachtwoord

Het wachtwoord wijzigen bewijst niet dat bestaande sessies of afzonderlijke certificaten zijn ingetrokken. Sommige diensten houden een sessie in leven tot ze verloopt of expliciet wordt beëindigd, en uitgegeven tokens dragen hun eigen levensduur. Controleer wat de dienst werkelijk doet in plaats van aan te nemen dat de wijziging globaal was. Als de wijziging door wantrouwen is ingegeven, beëindig de sessies dan expliciet en bevestig het resultaat.

De leidraad voor de levenscyclus van inloggegevens in NIST SP 800-63B houdt authenticators en sessies in aparte categorieën, waardoor een wachtwoordwijziging en een globale afmelding verschillende bewerkingen zijn. Behandel ze als twee taken met twee voltooiingscriteria. De eerste is klaar wanneer de nieuwe waarde werkt, en de tweede wanneer de oude sessies weg zijn.

Leg de voltooiing vast zonder het nieuwe wachtwoord in het record te schrijven. Een rotatielog dat de inloggegevens bevat, is een nieuw incident dat op een gedeelde schijf wacht. Noteer de datum, de bijgewerkte apparaten en de apparaten die nog openstaan.