Autenticador VPN perdut: substituir-lo sense desactivar l'MFA

Algú perd el telèfon i el tiquet arriba com a VPN trencat. Aquest plantejament és erroni dues vegades: el compte encara existeix i la passarel·la encara confia en el proveïdor d'identitat, així que l'única part trencada és un factor que la persona ja no té. Tracteu-ho com una recuperació i no com una caiguda: verifiqueu el sol·licitant, registreu un substitut, retireu el mètode perdut i després demostreu que el compte funciona. Tot això pressuposa que el pla es va escriure abans de la pèrdua, perquè inventar-lo durant la trucada és com l'MFA acaba desactivat per a tothom.

Pas 1: llegiu els factors registrats d'un registre, no de la memòria

La primera pregunta no és quin dispositiu s'ha perdut, sinó què més pot utilitzar encara el compte. Un compte pot portar una contrasenya amb push, un codi basat en el temps, una clau física i codis de recuperació impresos, i perdre'n un és un esdeveniment molt diferent de perdre l'únic. Llegiu la llista de mètodes del sistema d'identitat en lloc de demanar a l'usuari que la recordi, i en un inquilí de Microsoft Entra la consulta és una línia:

Get-MgUserAuthenticationMethod -UserId [email protected]

A continuació, escriviu el registre de recuperació mentre el compte encara funciona: identificador del compte, factors registrats, on viuen els codis de recuperació, qui pot verificar el sol·licitant de manera independent i a quins sistemes arriba el compte. Guardeu-lo a l'inventari protegit que l'equip ja utilitza, mai en una nota que també contingui codis actius. Aquests cinc camps converteixen una trucada de pànic en una llista de verificació, i l'orientació del NIST sobre el cicle de vida dels autenticadors tracta la recuperació com a part de la credencial i no com una excepció.

Registreu el canal de verificació com un camp propi, perquè aquesta és la part que la gent s'estalvia. Un número de telèfon associat al compte no és un canal independent quan la persona que ho demana també controla el telèfon.

Pas 2: verifiqueu el sol·licitant fora del camí que falla

Feu la comprovació d'identitat per un canal que no depengui de la VPN, la bústia de correu ni el dispositiu perdut. Una trucada de retorn a un número del registre de personal, o una comprovació en persona amb un gestor que ja és al directori, funcionen totes dues; un missatge de xat enviat des del compte en recuperació no funciona. La comprovació tracta de la persona, no de la seva capacitat de respondre preguntes sobre el compte, perquè els detalls del compte es filtren. Registreu qui ha verificat la sol·licitud i quan, ja que el següent revisor voldrà les dues coses.

Quan la sol·licitud arriba amb urgència i pressió per saltar-se la comprovació, aquest és el moment d'anar més lent. El frau de recuperació s'assembla exactament a un col·lega servicial que té pressa.

Pas 3: registreu el substitut i després retireu el factor antic

Registreu el nou autenticador pel flux de registre normal, mai per una derivació administrativa. Després elimineu explícitament el mètode perdut, perquè registrar un substitut deixa l'autenticador anterior autoritzat fins que algú el retira. Si el dispositiu antic pot ser a mans d'una altra persona, tracteu l'eliminació com a urgent i seguiu el procés d'incident en lloc del de recuperació. Revogueu les sessions existents en la mateixa passa, ja que una sessió creada abans del canvi pot sobreviure-hi:

Revoke-MgUserSignInSession -UserId [email protected]

Eliminar el factor per a tota la resta, o relaxar les comprovacions de certificat de la passarel·la, intercanvia la recuperació d'una persona per una caiguda que afecta tot el desplegament. Manteniu el canvi limitat al compte únic i escaleu si les proves apunten a un compromís més ampli. Anoteu al tiquet quin factor s'ha retirat i quin l'ha substituït.

Pas 4: demostreu que el compte funciona en totes dues direccions

Inicieu sessió una vegada amb el factor nou mitjançant un client compatible i després confirmeu que el compte encara arriba als recursos que arribava abans de la pèrdua. Proveu un recurs que necessiti el túnel i un que no, perquè un error assenyali la capa correcta. Intenteu un inici de sessió amb el factor retirat i espereu un rebuig i no una sol·licitud, cosa que demostra que l'eliminació ha tingut efecte. Un repte que falla des d'un dispositiu registrat existent és un problema de sol·licitud, no un motiu per tornar a registrar-ho tot.

Després demaneu a l'usuari que completi el mateix inici de sessió sense indicacions. La vostra prova correcta demostra la configuració; el seu intent demostra el traspàs.

Tanqueu el tiquet amb la marca temporal de l'inici de sessió correcte i el nom del factor que s'utilitza ara. Actualitzeu el registre de recuperació en la mateixa passa, perquè la propera pèrdua comenci des d'un inventari precís i no des d'un de caducat.

Pas 5: elimineu la condició que ha fet això tan dolorós

Cada trucada de recuperació és una prova sobre el disseny de registre. Si el compte tenia exactament un factor, exigiu-ne un segon per a tothom d'aquell grup. Si els codis de recuperació eren a l'ordinador portàtil perdut, canvieu on viuen. Si la verificació requeria un gestor que era de vacances, nomenau un suplent. Cada correcció costa una tarda i elimina la pitjor hora del proper incident.

Després rellegiu el registre del pas u contra la realitat. Enumera els factors que existeixen realment i el canal de verificació encara arriba a una persona? Un manual que ningú no actualitza es converteix en un document que la gent ignora durant la trucada per a la qual es va escriure.