Mistet VPN-autentifikator: udskift uden at slå MFA fra

Nogen mister en telefon, og billetten ankommer som VPN i stykker. Den ramme er forkert to gange: kontoen findes stadig, og gatewayen stoler stadig på identitetsudbyderen, så den eneste defekte del er én faktor, som personen ikke længere har. Behandl det som gendannelse og ikke som et nedbrud: verificér anmoderen, tilmeld en erstatning, afvikl den mistede metode, og bevis derefter at kontoen virker. Det hele forudsætter, at planen blev skrevet før tabet, for at opfinde den under opkaldet er måden, hvorpå MFA ender med at være slået fra for alle.

Trin 1: læs de tilmeldte faktorer fra en registrering, ikke fra hukommelsen

Det første spørgsmål er ikke, hvilken enhed der gik tabt, men hvad kontoen ellers stadig kan bruge. En konto kan bære en adgangskode plus push, en tidsbaseret kode, en hardwarenøgle og udskrevne gendannelseskoder, og at miste en af dem er en helt anden begivenhed end at miste den eneste. Læs metodelisten fra identitetssystemet i stedet for at bede brugeren huske den, og i en Microsoft Entra-lejer er forespørgslen én linje:

Get-MgUserAuthenticationMethod -UserId [email protected]

Skriv derefter gendannelsesregistreringen, mens kontoen stadig virker: kontoidentifikator, tilmeldte faktorer, hvor gendannelseskoderne bor, hvem der uafhængigt kan verificere anmoderen, og hvilke systemer kontoen når. Opbevar den i det beskyttede inventar, som teamet allerede bruger, aldrig i et notat, der også indeholder aktive koder. De fem felter gør et panisk opkald til en tjekliste, og NISTs vejledning til autentifikatorens livscyklus behandler gendannelse som en del af legitimationsoplysningen og ikke som en undtagelse fra den.

Registrér verifikationskanalen som sit eget felt, fordi det er den del, folk springer over. Et telefonnummer knyttet til kontoen er ikke en uafhængig kanal, når personen, der spørger, også kontrollerer telefonen.

Trin 2: verificér anmoderen uden om den svigtende vej

Kør identitetskontrollen gennem en kanal, der ikke afhænger af VPN'en, postkassen eller den mistede enhed. Et tilbagekald til et nummer fra HR-registreringen eller en personlig kontrol hos en leder, der allerede er i kataloget, virker begge; en chatbesked sendt fra kontoen under gendannelse virker ikke. Kontrollen handler om personen, ikke om deres evne til at svare på spørgsmål om kontoen, fordi kontodetaljer lækker. Log, hvem der verificerede anmodningen og hvornår, da den næste anmelder vil have begge.

Når anmodningen ankommer med hastværk og pres for at springe kontrollen over, er det øjeblikket at sætte farten ned. Gendannelsesbedrageri ligner præcis en hjælpsom kollega, der har travlt.

Trin 3: tilmeld erstatningen, og afvikl derefter den gamle faktor

Tilmeld den nye autentifikator gennem det normale tilmeldingsforløb, aldrig gennem en administrativ omvej. Fjern derefter den mistede metode eksplicit, fordi tilmelding af en erstatning efterlader den forrige autentifikator autoriseret, indtil nogen afvikler den. Hvis den gamle enhed kan være i andres hænder, skal fjernelsen behandles som akut, og hændelsesprocessen følges i stedet for gendannelsesprocessen. Tilbagekald eksisterende sessioner i samme gennemløb, da en session oprettet før ændringen kan overleve den:

Revoke-MgUserSignInSession -UserId [email protected]

At fjerne faktoren for alle andre eller lempe gatewayens certifikatkontroller bytter én persons gendannelse for et nedbrud, der rammer hele udrulningen. Hold ændringen afgrænset til den enkelte konto, og eskalér, hvis beviserne peger på et bredere kompromis. Notér i billetten, hvilken faktor der blev afviklet, og hvilken der erstattede den.

Trin 4: bevis, at kontoen virker i begge retninger

Log ind én gang med den nye faktor gennem en understøttet klient, og bekræft derefter, at kontoen stadig når de ressourcer, den nåede før tabet. Test en ressource, der kræver tunnelen, og en, der ikke gør, så en fejl peger på det rigtige lag. Forsøg et login med den afviklede faktor, og forvent en afvisning frem for en prompt, hvilket beviser, at fjernelsen har virket. En udfordring, der fejler fra en eksisterende tilmeldt enhed er et promptproblem, ikke en grund til at tilmelde alt igen.

Bed derefter brugeren gennemføre det samme login uden instruktion. Din vellykkede test beviser konfigurationen; deres forsøg beviser overdragelsen.

Luk billetten med tidsstemplet for det vellykkede login og navnet på den faktor, der nu bruges. Opdatér gendannelsesregistreringen i samme gennemløb, så det næste tab starter fra et præcist inventar i stedet for et forældet.

Trin 5: fjern den betingelse, der gjorde dette smertefuldt

Ethvert gendannelsesopkald er bevis om tilmeldingsdesignet. Hvis kontoen havde præcis én faktor, kræv en anden for alle i den gruppe. Hvis gendannelseskoderne lå på den computer, der gik tabt, så skift, hvor de bor. Hvis verifikationen krævede en leder på ferie, udpeg en stedfortræder. Hver rettelse tager en eftermiddag og fjerner den værste time i den næste hændelse.

Læs derefter registreringen fra trin et igen mod virkeligheden. Lister den de faktorer, der faktisk findes, og når verifikationskanalen stadig et menneske? En driftshåndbog, som ingen opdaterer, forfalder til et dokument, som folk ignorerer under det opkald, den blev skrevet til.