Tapt VPN-autentifikator: byt ut utan å slå av MFA

Nokon mistar ein telefon, og billetten kjem inn som VPN øydelagd. Den ramma er feil to gonger: kontoen finst framleis, og gatewayen stolar framleis på identitetsleverandøren, så den einaste øydelagde delen er éin faktor som personen ikkje lenger har. Handsaminga er gjenoppretting og ikkje avbrot: stadfest førespurnaden, registrer ein erstattar, trekk tilbake den tapte metoden, og prov deretter at kontoen verkar. Alt dette føreset at planen vart skriven før tapet, for å finne han opp under samtalen er måten MFA endar med å vere slått av for alle.

Steg 1: les dei registrerte faktorane frå ein registrering, ikkje frå minnet

Det første spørsmålet er ikkje kva eining som gjekk tapt, men kva kontoen elles framleis kan bruke. Ein konto kan bere eit passord pluss push, ein tidsbasert kode, ein hardwarenøkkel og utskrivne gjenopprettingskodar, og å miste éin av dei er ei heilt anna hending enn å miste den einaste. Les metodelista frå identitetssystemet i staden for å be brukaren hugse ho, og i ein Microsoft Entra-leigar er spørjinga éi linje:

Get-MgUserAuthenticationMethod -UserId [email protected]

Skriv deretter gjenopprettingsregistreringa medan kontoen framleis verkar: kontoidentifikator, registrerte faktorar, kvar gjenopprettingskodane bur, kven som uavhengig kan stadfeste førespurnaden, og kva system kontoen når. Oppbevar ho i det verna inventaret som teamet allereie brukar, aldri i eit notat som òg inneheld aktive kodar. Dei fem felta gjer ein panisk samtale om til ei sjekkliste, og NISTs rettleiing for livssyklusen til autentifikatoren handsamar gjenoppretting som ein del av legitimasjonen og ikkje som eit unntak frå han.

Registrer stadfestingskanalen som eige felt, fordi det er den delen folk hoppar over. Eit telefonnummer knytt til kontoen er ikkje ein uavhengig kanal når personen som spør òg kontrollerer telefonen.

Steg 2: stadfest førespurnaden utanfor den sviktande vegen

Køyr identitetskontrollen gjennom ein kanal som ikkje er avhengig av VPN-en, postkassen eller den tapte eininga. Ein tilbakeringing til eit nummer frå HR-registreringa eller ein personleg kontroll hos ein leiar som allereie er i katalogen, verkar begge; ei chatmelding send frå kontoen under gjenoppretting verkar ikkje. Kontrollen handlar om personen, ikkje om evna til å svare på spørsmål om kontoen, fordi kontodetaljar lek. Logg kven som stadfesta førespurnaden og når, sidan den neste gjennomgangen vil ha begge.

Når førespurnaden kjem med hast og press for å hoppe over kontrollen, er det augneblinken å senke farten. Gjenopprettingssvindel ser nøyaktig ut som ein hjelpsam kollega som har det travelt.

Steg 3: registrer erstattaren, og trekk deretter tilbake den gamle faktoren

Registrer den nye autentifikatoren gjennom den normale registreringsflyten, aldri gjennom ein administrativ omveg. Fjern deretter den tapte metoden eksplisitt, fordi registrering av ein erstattar lèt den førre autentifikatoren vere autorisert til nokon trekkjer han tilbake. Viss den gamle eininga kan vere i andre hender, skal fjerninga handsamast som akutt og hendingsprosessen følgjast i staden for gjenopprettingsprosessen. Trekk tilbake eksisterande sesjonar i same gjennomgang, sidan ein sesjon oppretta før endringa kan overleve henne:

Revoke-MgUserSignInSession -UserId [email protected]

Å fjerne faktoren for alle andre, eller lempe på sertifikatkontrollane til gatewayen, byter gjenopprettinga til éin person mot eit avbrot som rammar heile utrullinga. Hald endringa avgrensa til den eine kontoen, og eskaler viss prova peikar mot eit breiare kompromiss. Noter i billetten kva faktor som vart trekt tilbake, og kva som erstatta han.

Steg 4: prov at kontoen verkar i begge retningar

Logg inn éin gong med den nye faktoren gjennom ein støtta klient, og stadfest deretter at kontoen framleis når ressursane han nådde før tapet. Test éin ressurs som treng tunnelen og éin som ikkje gjer det, slik at ein feil peikar på rett lag. Freist ein innlogging med den tilbaketrekte faktoren og vent ei avvising i staden for ei førespurnad, noko som provar at fjerninga verka. Ei utfordring som feilar frå ei eksisterande registrert eining er eit førespurnadsproblem, ikkje ein grunn til å registrere alt på nytt.

Be deretter brukaren fullføre den same innlogginga utan rettleiing. Den vellukka testen din provar konfigurasjonen; forsøket deira provar overleveringa.

Lukk billetten med tidsstempelet for den vellukka innlogginga og namnet på faktoren som no er i bruk. Oppdater gjenopprettingsregistreringa i same gjennomgang, slik at det neste tapet startar frå eit nøyaktig inventar og ikkje eit utdatert.

Steg 5: fjern vilkåret som gjorde dette smertefullt

Kvar gjenopprettingssamtale er prov om registreringsdesignet. Hadde kontoen nøyaktig éin faktor, krev ein annan for alle i den gruppa. Låg gjenopprettingskodane på den tapte laptopen, endre kvar dei bur. Kravde stadfestinga ein leiar på ferie, peik ut ein stadfortredar. Kvar retting tek ein ettermiddag og fjernar den verste timen i den neste hendinga.

Les deretter registreringa frå steg éin på nytt mot røynda. Listar ho opp faktorane som faktisk finst, og når stadfestingskanalen framleis eit menneske? Ei driftshandbok som ingen oppdaterer, forfell til eit dokument folk ignorerer under samtalen ho vart skriven for.