Tapt VPN-autentifikator: bytt uten å slå av MFA

Noen mister en telefon, og billetten kommer inn som VPN ødelagt. Den rammen er feil to ganger: kontoen finnes fortsatt, og gatewayen stoler fortsatt på identitetsleverandøren, så den eneste ødelagte delen er én faktor som personen ikke lenger har. Behandle det som gjenoppretting og ikke som et avbrudd: verifiser forespørreren, registrer en erstatning, trekk tilbake den tapte metoden, og bevis deretter at kontoen virker. Alt dette forutsetter at planen ble skrevet før tapet, for å finne den opp under samtalen er måten MFA ender med å være slått av for alle.

Trinn 1: les de registrerte faktorene fra en registrering, ikke fra hukommelsen

Det første spørsmålet er ikke hvilken enhet som gikk tapt, men hva kontoen ellers fortsatt kan bruke. En konto kan bære et passord pluss push, en tidsbasert kode, en hardwarenøkkel og utskrevne gjenopprettingskoder, og å miste én av dem er en helt annen hendelse enn å miste den eneste. Les metodelisten fra identitetssystemet i stedet for å be brukeren huske den, og i en Microsoft Entra-leier er spørringen én linje:

Get-MgUserAuthenticationMethod -UserId [email protected]

Skriv deretter gjenopprettingsregistreringen mens kontoen fortsatt virker: kontoidentifikator, registrerte faktorer, hvor gjenopprettingskodene bor, hvem som uavhengig kan verifisere forespørreren, og hvilke systemer kontoen når. Oppbevar den i det beskyttede inventaret som teamet allerede bruker, aldri i et notat som også inneholder aktive koder. De fem feltene gjør en panisk samtale om til en sjekkliste, og NISTs veiledning for autentifikatorens livssyklus behandler gjenoppretting som en del av legitimasjonen og ikke som et unntak fra den.

Registrer verifiseringskanalen som sitt eget felt, fordi det er den delen folk hopper over. Et telefonnummer knyttet til kontoen er ikke en uavhengig kanal når personen som spør også kontrollerer telefonen.

Trinn 2: verifiser forespørreren utenfor den sviktende veien

Kjør identitetskontrollen gjennom en kanal som ikke avhenger av VPN-en, postboksen eller den tapte enheten. En tilbakeringing til et nummer fra HR-registreringen eller en personlig kontroll hos en leder som allerede er i katalogen, virker begge; en chatmelding sendt fra kontoen under gjenoppretting virker ikke. Kontrollen handler om personen, ikke om evnen til å svare på spørsmål om kontoen, fordi kontodetaljer lekker. Logg hvem som verifiserte forespørselen og når, siden den neste gjennomgangen vil ha begge.

Når forespørselen kommer med hastverk og press for å hoppe over kontrollen, er det øyeblikket å senke farten. Gjenopprettingssvindel ser nøyaktig ut som en hjelpsom kollega som har det travelt.

Trinn 3: registrer erstatningen, og trekk deretter tilbake den gamle faktoren

Registrer den nye autentifikatoren gjennom den normale registreringsflyten, aldri gjennom en administrativ omvei. Fjern deretter den tapte metoden eksplisitt, fordi registrering av en erstatning lar den forrige autentifikatoren være autorisert til noen trekker den tilbake. Hvis den gamle enheten kan være i andres hender, skal fjerningen behandles som akutt og hendelsesprosessen følges i stedet for gjenopprettingsprosessen. Tilbakekall eksisterende sesjoner i samme gjennomgang, siden en sesjon opprettet før endringen kan overleve den:

Revoke-MgUserSignInSession -UserId [email protected]

Å fjerne faktoren for alle andre, eller lempe på gatewayens sertifikatkontroller, bytter én persons gjenoppretting mot et avbrudd som rammer hele utrullingen. Hold endringen begrenset til den ene kontoen, og eskaler hvis bevisene peker mot et bredere kompromiss. Noter i billetten hvilken faktor som ble trukket tilbake, og hvilken som erstattet den.

Trinn 4: bevis at kontoen virker i begge retninger

Logg inn én gang med den nye faktoren gjennom en støttet klient, og bekreft deretter at kontoen fortsatt når ressursene den nådde før tapet. Test én ressurs som trenger tunnelen og én som ikke gjør det, slik at en feil peker på riktig lag. Forsøk en innlogging med den tilbaketrukne faktoren og forvent en avvisning i stedet for en forespørsel, noe som beviser at fjerningen virket. En utfordring som feiler fra en eksisterende registrert enhet er et forespørselsproblem, ikke en grunn til å registrere alt på nytt.

Be deretter brukeren fullføre den samme innloggingen uten veiledning. Din vellykkede test beviser konfigurasjonen; deres forsøk beviser overleveringen.

Lukk billetten med tidsstemplet for den vellykkede innloggingen og navnet på faktoren som nå brukes. Oppdater gjenopprettingsregistreringen i samme gjennomgang, slik at det neste tapet starter fra et nøyaktig inventar og ikke et utdatert.

Trinn 5: fjern betingelsen som gjorde dette smertefullt

Hver gjenopprettingssamtale er bevis om registreringsdesignet. Hvis kontoen hadde nøyaktig én faktor, krev en annen for alle i den gruppen. Hvis gjenopprettingskodene lå på den tapte laptopen, endre hvor de bor. Hvis verifiseringen krevde en leder på ferie, utpek en stedfortreder. Hver rettelse tar en ettermiddag og fjerner den verste timen i den neste hendelsen.

Les deretter registreringen fra trinn én på nytt mot virkeligheten. Lister den opp faktorene som faktisk finnes, og når verifiseringskanalen fortsatt et menneske? En driftshåndbok som ingen oppdaterer, forfaller til et dokument folk ignorerer under samtalen den ble skrevet for.