Autentificator VPN pierdut: înlocuire fără a dezactiva MFA

Cineva pierde telefonul și tichetul sosește ca VPN stricat. Această încadrare este greșită de două ori: contul încă există, iar gateway-ul încă are încredere în furnizorul de identitate, deci singura parte stricată este un factor pe care persoana nu îl mai deține. Tratați-o ca recuperare, nu ca pană: verificați solicitantul, înregistrați un înlocuitor, retrageți metoda pierdută, apoi demonstrați că contul funcționează. Toate acestea presupun că planul a fost scris înainte de pierdere, pentru că a-l inventa în timpul apelului este modul în care MFA ajunge dezactivat pentru toată lumea.

Pasul 1: citiți factorii înregistrați dintr-un registru, nu din memorie

Prima întrebare nu este ce dispozitiv s-a pierdut, ci ce altceva mai poate folosi contul. Un cont poate avea o parolă plus push, un cod bazat pe timp, o cheie hardware și coduri de recuperare tipărite, iar pierderea unuia dintre ele este un eveniment complet diferit de pierderea singurului. Citiți lista metodelor din sistemul de identitate în loc să cereți utilizatorului să o țină minte, iar într-un tenant Microsoft Entra interogarea este o singură linie:

Get-MgUserAuthenticationMethod -UserId [email protected]

Apoi scrieți registrul de recuperare cât timp contul încă funcționează: identificatorul contului, factorii înregistrați, unde se află codurile de recuperare, cine poate verifica independent solicitantul și la ce sisteme ajunge contul. Păstrați-l în inventarul protejat pe care echipa îl folosește deja, niciodată într-o notă care conține și coduri active. Acele cinci câmpuri transformă un apel panicat într-o listă de verificare, iar îndrumările NIST privind ciclul de viață al autentificatorului tratează recuperarea ca parte a acreditării, nu ca excepție de la ea.

Înregistrați canalul de verificare ca un câmp separat, pentru că exact acea parte este sărită de oameni. Un număr de telefon atașat contului nu este un canal independent când persoana care cere controlează și telefonul.

Pasul 2: verificați solicitantul în afara căii defecte

Efectuați verificarea identității printr-un canal care nu depinde de VPN, de căsuța poștală sau de dispozitivul pierdut. Un apel înapoi la un număr din registrul de resurse umane sau o verificare față în față cu un manager care este deja în director funcționează ambele; un mesaj de chat trimis din contul aflat în recuperare nu funcționează. Verificarea privește persoana, nu capacitatea ei de a răspunde la întrebări despre cont, pentru că detaliile contului se scurg. Înregistrați cine a verificat cererea și când, deoarece următorul revizor le va dori pe amândouă.

Când cererea vine cu urgență și presiune de a sări peste verificare, acela este momentul să încetiniți. Frauda de recuperare arată exact ca un coleg de ajutor care se grăbește.

Pasul 3: înregistrați înlocuitorul, apoi retrageți factorul vechi

Înregistrați noul autentificator prin fluxul normal de înregistrare, niciodată printr-o ocolire administrativă. Apoi eliminați explicit metoda pierdută, pentru că înregistrarea unui înlocuitor lasă autentificatorul anterior autorizat până când cineva îl retrage. Dacă dispozitivul vechi poate fi în mâinile altcuiva, tratați eliminarea ca urgentă și urmați procesul de incident, nu pe cel de recuperare. Revocați sesiunile existente în aceeași trecere, deoarece o sesiune creată înainte de schimbare o poate supraviețui:

Revoke-MgUserSignInSession -UserId [email protected]

Eliminarea factorului pentru toți ceilalți, sau relaxarea verificărilor de certificat ale gateway-ului, schimbă recuperarea unei persoane pe o pană care atinge întreaga implementare. Țineți schimbarea limitată la contul unic și escaladați dacă dovezile indică un compromis mai larg. Notați în tichet ce factor a fost retras și care l-a înlocuit.

Pasul 4: demonstrați că contul funcționează în ambele direcții

Autentificați-vă o dată cu noul factor printr-un client acceptat, apoi confirmați că contul ajunge în continuare la resursele la care ajungea înainte de pierdere. Testați o resursă care are nevoie de tunel și una care nu are, astfel încât o defecțiune să indice stratul corect. Încercați o autentificare cu factorul retras și așteptați-vă la o respingere, nu la o solicitare, ceea ce demonstrează că eliminarea a intrat în vigoare. O provocare care eșuează de pe un dispozitiv înregistrat existent este o problemă de solicitare, nu un motiv pentru a reînregistra totul.

Apoi rugați utilizatorul să finalizeze aceeași autentificare fără îndrumare. Testul dumneavoastră reușit demonstrează configurația; încercarea lui demonstrează predarea.

Închideți tichetul cu marca temporală a autentificării reușite și cu numele factorului folosit acum. Actualizați registrul de recuperare în aceeași trecere, astfel încât următoarea pierdere să pornească de la un inventar precis, nu de la unul învechit.

Pasul 5: eliminați condiția care a făcut asta dureros

Fiecare apel de recuperare este o dovadă despre proiectarea înregistrării. Dacă contul avea exact un factor, cereți un al doilea pentru toți din acel grup. Dacă codurile de recuperare erau pe laptopul pierdut, schimbați unde se află. Dacă verificarea necesita un manager în concediu, numiți un supleant. Fiecare corectură ia o după-amiază și elimină cea mai rea oră a următorului incident.

Apoi recitiți registrul de la pasul unu împotriva realității. Enumeră factorii care există cu adevărat și canalul de verificare mai ajunge la o persoană? Un manual pe care nimeni nu îl actualizează se degradează într-un document pe care oamenii îl ignoră în timpul apelului pentru care a fost scris.