Verloren VPN-authenticator: vervangen zonder MFA uit te schakelen

Iemand verliest een telefoon en het ticket komt binnen als VPN kapot. Die framing is twee keer fout: het account bestaat nog en de gateway vertrouwt nog steeds de identiteitsprovider, dus het enige kapotte deel is één factor die de persoon niet meer heeft. Behandel het als herstel en niet als storing: verifieer de aanvrager, registreer een vervanger, trek de verloren methode in en bewijs daarna dat het account werkt. Dat alles veronderstelt dat het plan vóór het verlies is geschreven, want het ter plekke bedenken tijdens het gesprek is hoe MFA uiteindelijk voor iedereen wordt uitgeschakeld.

Stap 1: lees de geregistreerde factoren uit een registratie, niet uit het geheugen

De eerste vraag is niet welk apparaat verloren ging, maar wat het account nog kan gebruiken. Een account kan een wachtwoord plus push, een tijdgebaseerde code, een hardwaresleutel en afgedrukte herstelcodes hebben, en één daarvan verliezen is een heel andere gebeurtenis dan de enige verliezen. Lees de methodelijst uit het identiteitssysteem in plaats van de gebruiker te vragen die te onthouden, en in een Microsoft Entra-tenant is de query één regel:

Get-MgUserAuthenticationMethod -UserId [email protected]

Schrijf vervolgens het herstelrecord terwijl het account nog werkt: accountidentificatie, geregistreerde factoren, waar de herstelcodes staan, wie de aanvrager onafhankelijk kan verifiëren en welke systemen het account bereikt. Bewaar het in de beschermde inventaris die het team al gebruikt, nooit in een notitie die ook actieve codes bevat. Die vijf velden maken van een paniekerig gesprek een checklist, en de NIST-richtlijn voor de levenscyclus van authenticators behandelt herstel als onderdeel van de inloggegevens en niet als uitzondering daarop.

Leg het verificatiekanaal vast als een eigen veld, want dat is het deel dat mensen overslaan. Een telefoonnummer dat aan het account hangt is geen onafhankelijk kanaal wanneer de persoon die erom vraagt ook de telefoon beheert.

Stap 2: verifieer de aanvrager buiten het falende pad

Voer de identiteitscontrole uit via een kanaal dat niet afhankelijk is van de VPN, de mailbox of het verloren apparaat. Een terugbelactie naar een nummer uit het HR-record, of een controle ter plaatse bij een manager die al in de directory staat, werken beide; een chatbericht vanaf het account in herstel werkt niet. De controle gaat over de persoon, niet over het vermogen om vragen over het account te beantwoorden, omdat accountgegevens uitlekken. Leg vast wie het verzoek heeft geverifieerd en wanneer, want de volgende beoordelaar wil beide.

Als het verzoek komt met haast en druk om de controle over te slaan, is dat het moment om langzamer te gaan. Herstelfraude ziet er precies uit als een behulpzame collega met haast.

Stap 3: registreer de vervanger en trek daarna de oude factor in

Registreer de nieuwe authenticator via de normale registratieflow, nooit via een administratieve omzeiling. Verwijder daarna de verloren methode expliciet, want het registreren van een vervanger laat de vorige authenticator geautoriseerd tot iemand die intrekt. Als het oude apparaat in andermans handen kan zijn, behandel de verwijdering dan als urgent en volg het incidentproces in plaats van het herstelproces. Trek bestaande sessies in dezelfde doorgang in, omdat een sessie die vóór de wijziging is gemaakt die kan overleven:

Revoke-MgUserSignInSession -UserId [email protected]

De factor voor alle anderen verwijderen, of de certificaatcontroles van de gateway versoepelen, ruilt het herstel van één persoon tegen een storing die de hele uitrol raakt. Houd de wijziging beperkt tot het enkele account en escaleer als het bewijs op een bredere compromittering wijst. Noteer in het ticket welke factor is ingetrokken en welke die heeft vervangen.

Stap 4: bewijs dat het account in beide richtingen werkt

Meld je één keer aan met de nieuwe factor via een ondersteunde client en bevestig daarna dat het account nog de resources bereikt die het vóór het verlies bereikte. Test één resource die de tunnel nodig heeft en één die dat niet heeft, zodat een fout naar de juiste laag wijst. Probeer een aanmelding met de ingetrokken factor en verwacht een weigering in plaats van een prompt, wat bewijst dat de verwijdering effect heeft gehad. Een uitdaging die faalt vanaf een bestaand geregistreerd apparaat is een promptprobleem, geen reden om alles opnieuw te registreren.

Vraag de gebruiker daarna dezelfde aanmelding zonder begeleiding te voltooien. Jouw geslaagde test bewijst de configuratie; zijn poging bewijst de overdracht.

Sluit het ticket met de tijdstempel van de geslaagde aanmelding en de naam van de factor die nu in gebruik is. Werk het herstelrecord in dezelfde doorgang bij, zodat het volgende verlies begint bij een nauwkeurige inventaris in plaats van een verouderde.

Stap 5: verwijder de voorwaarde die dit pijnlijk maakte

Elk herstelgesprek is bewijs over het registratieontwerp. Had het account precies één factor, eis dan een tweede voor iedereen in die groep. Stonden de herstelcodes op de verloren laptop, verander dan waar ze staan. Was voor de verificatie een manager met verlof nodig, benoem dan een plaatsvervanger. Elke correctie kost een middag en haalt het slechtste uur uit het volgende incident.

Lees daarna het record uit stap één opnieuw tegen de werkelijkheid. Noemt het de factoren die echt bestaan, en bereikt het verificatiekanaal nog steeds een mens? Een draaiboek dat niemand bijwerkt, verwordt tot een document dat mensen negeren tijdens het gesprek waarvoor het is geschreven.