Förlorad VPN-autentiserare: byt ut utan att stänga av MFA

Någon tappar en telefon och ärendet kommer in som VPN trasigt. Den ramen är fel två gånger: kontot finns fortfarande och gatewayen litar fortfarande på identitetsleverantören, så den enda trasiga delen är en faktor som personen inte längre har. Behandla det som återställning och inte som ett avbrott: verifiera begäraren, registrera en ersättare, dra tillbaka den förlorade metoden och bevisa sedan att kontot fungerar. Allt detta förutsätter att planen skrevs före förlusten, för att hitta på den under samtalet är hur MFA till slut stängs av för alla.

Steg 1: läs de registrerade faktorerna från en registrering, inte från minnet

Den första frågan är inte vilken enhet som gick förlorad, utan vad kontot annars fortfarande kan använda. Ett konto kan bära ett lösenord plus push, en tidsbaserad kod, en hårdvarunyckel och utskrivna återställningskoder, och att förlora en av dem är en helt annan händelse än att förlora den enda. Läs metodlistan från identitetssystemet i stället för att be användaren komma ihåg den, och i en Microsoft Entra-klient är frågan en rad:

Get-MgUserAuthenticationMethod -UserId [email protected]

Skriv sedan återställningsposten medan kontot fortfarande fungerar: kontoidentifikator, registrerade faktorer, var återställningskoderna bor, vem som oberoende kan verifiera begäraren och vilka system kontot når. Förvara den i det skyddade inventarium som teamet redan använder, aldrig i en anteckning som också innehåller aktiva koder. De fem fälten gör ett paniksamtal till en checklista, och NIST:s vägledning för autentiserarens livscykel behandlar återställning som en del av inloggningsuppgiften och inte som ett undantag från den.

Registrera verifieringskanalen som ett eget fält, eftersom det är den delen folk hoppar över. Ett telefonnummer kopplat till kontot är inte en oberoende kanal när personen som frågar också kontrollerar telefonen.

Steg 2: verifiera begäraren utanför den fallerande vägen

Utför identitetskontrollen via en kanal som inte beror på VPN:en, brevlådan eller den förlorade enheten. En återuppringning till ett nummer från HR-posten eller en personlig kontroll hos en chef som redan finns i katalogen fungerar båda; ett chattmeddelande som skickas från kontot under återställning fungerar inte. Kontrollen handlar om personen, inte om förmågan att svara på frågor om kontot, eftersom kontouppgifter läcker. Logga vem som verifierade begäran och när, eftersom nästa granskare vill ha båda.

När begäran kommer med brådska och press att hoppa över kontrollen är det ögonblicket att sakta ner. Återställningsbedrägeri ser precis ut som en hjälpsam kollega som har bråttom.

Steg 3: registrera ersättaren och dra sedan tillbaka den gamla faktorn

Registrera den nya autentiseraren genom det normala registreringsflödet, aldrig genom ett administrativt kringgående. Ta sedan bort den förlorade metoden uttryckligen, eftersom registrering av en ersättare lämnar den tidigare autentiseraren auktoriserad tills någon drar tillbaka den. Om den gamla enheten kan vara i någon annans händer, behandla borttagningen som akut och följ incidentprocessen i stället för återställningsprocessen. Återkalla befintliga sessioner i samma omgång, eftersom en session som skapats före ändringen kan överleva den:

Revoke-MgUserSignInSession -UserId [email protected]

Att ta bort faktorn för alla andra, eller att lätta på gatewayens certifikatkontroller, byter en persons återställning mot ett avbrott som träffar hela utrullningen. Håll ändringen begränsad till det enda kontot och eskalera om bevisen pekar på en bredare kompromiss. Notera i ärendet vilken faktor som drogs tillbaka och vilken som ersatte den.

Steg 4: bevisa att kontot fungerar i båda riktningarna

Logga in en gång med den nya faktorn via en klient som stöds och bekräfta sedan att kontot fortfarande når de resurser det nådde före förlusten. Testa en resurs som behöver tunneln och en som inte behöver det, så att ett fel pekar på rätt lager. Försök logga in med den tillbakadragna faktorn och förvänta dig ett avslag i stället för en uppmaning, vilket bevisar att borttagningen fick effekt. En utmaning som misslyckas från en befintlig registrerad enhet är ett uppmaningsproblem, inte en anledning att registrera om allt.

Be sedan användaren slutföra samma inloggning utan vägledning. Ditt lyckade test bevisar konfigurationen; deras försök bevisar överlämningen.

Stäng ärendet med tidsstämpeln för den lyckade inloggningen och namnet på faktorn som nu används. Uppdatera återställningsposten i samma omgång, så att nästa förlust börjar från ett korrekt inventarium och inte ett föråldrat.

Steg 5: ta bort villkoret som gjorde detta smärtsamt

Varje återställningssamtal är bevis om registreringsdesignen. Om kontot hade exakt en faktor, kräv en andra för alla i den gruppen. Om återställningskoderna låg på den förlorade laptopen, ändra var de bor. Om verifieringen krävde en chef på semester, utse en ställföreträdare. Varje rättelse tar en eftermiddag och tar bort den värsta timmen i nästa incident.

Läs sedan om posten från steg ett mot verkligheten. Listar den faktorerna som faktiskt finns, och når verifieringskanalen fortfarande en människa? En driftmanual som ingen uppdaterar urartar till ett dokument som folk ignorerar under samtalet den skrevs för.