Autenticatore VPN smarrito: sostituirlo senza disattivare l’MFA

Qualcuno perde il telefono e il ticket arriva come VPN guasta. Questa impostazione è sbagliata due volte: l’account esiste ancora e il gateway si fida ancora del provider di identità, quindi l’unica parte guasta è un fattore che la persona non possiede più. Trattatelo come un ripristino e non come un’interruzione: verificate il richiedente, registrate un sostituto, ritirate il metodo smarrito, poi dimostrate che l’account funziona. Tutto ciò presuppone che il piano sia stato scritto prima della perdita, perché inventarlo durante la chiamata è il modo in cui l’MFA finisce disattivato per tutti.

Passo 1: leggete i fattori registrati da un registro, non dalla memoria

La prima domanda non è quale dispositivo sia andato perduto, ma cos’altro può ancora usare l’account. Un account può avere una password con push, un codice basato sul tempo, una chiave hardware e codici di recupero stampati, e perdere uno di questi è un evento molto diverso dal perdere l’unico. Leggete l’elenco dei metodi dal sistema di identità invece di chiedere all’utente di ricordarlo, e in un tenant Microsoft Entra la query è una riga:

Get-MgUserAuthenticationMethod -UserId [email protected]

Poi scrivete il registro di recupero mentre l’account funziona ancora: identificatore dell’account, fattori registrati, dove vivono i codici di recupero, chi può verificare il richiedente in modo indipendente e a quali sistemi arriva l’account. Tenetelo nell’inventario protetto che il team già usa, mai in una nota che contiene anche codici attivi. Quei cinque campi trasformano una chiamata nel panico in una lista di controllo, e le linee guida NIST sul ciclo di vita degli autenticatori trattano il recupero come parte della credenziale e non come un’eccezione.

Registrate il canale di verifica come campo a sé, perché è la parte che le persone saltano. Un numero di telefono collegato all’account non è un canale indipendente quando chi chiede controlla anche il telefono.

Passo 2: verificate il richiedente fuori dal percorso guasto

Eseguite il controllo di identità attraverso un canale che non dipende dalla VPN, dalla casella di posta o dal dispositivo smarrito. Una richiamata a un numero del registro del personale, o un controllo di persona con un manager già presente nella directory, funzionano entrambi; un messaggio in chat inviato dall’account in recupero non funziona. Il controllo riguarda la persona, non la sua capacità di rispondere a domande sull’account, perché i dettagli dell’account trapelano. Registrate chi ha verificato la richiesta e quando, dato che il prossimo revisore vorrà entrambe le cose.

Quando la richiesta arriva con urgenza e pressione per saltare il controllo, quello è il momento di rallentare. La frode al recupero assomiglia esattamente a un collega disponibile che ha fretta.

Passo 3: registrate il sostituto, poi ritirate il vecchio fattore

Registrate il nuovo autenticatore tramite il normale flusso di registrazione, mai tramite una deroga amministrativa. Poi rimuovete esplicitamente il metodo smarrito, perché registrare un sostituto lascia l’autenticatore precedente autorizzato finché qualcuno non lo ritira. Se il vecchio dispositivo può essere in mani altrui, trattate la rimozione come urgente e seguite il processo di incidente invece di quello di recupero. Revocate le sessioni esistenti nella stessa passata, poiché una sessione creata prima della modifica può sopravviverle:

Revoke-MgUserSignInSession -UserId [email protected]

Rimuovere il fattore per tutti gli altri, o allentare i controlli sui certificati del gateway, scambia il recupero di una persona con un’interruzione che tocca l’intera distribuzione. Mantenete la modifica limitata al singolo account e scalate se le prove indicano un compromesso più ampio. Annotate nel ticket quale fattore è stato ritirato e quale lo ha sostituito.

Passo 4: dimostrate che l’account funziona in entrambe le direzioni

Accedete una volta con il nuovo fattore tramite un client supportato, poi confermate che l’account raggiunge ancora le risorse che raggiungeva prima della perdita. Provate una risorsa che richiede il tunnel e una che non lo richiede, così un guasto indica il livello giusto. Tentate un accesso con il fattore ritirato e aspettatevi un rifiuto invece di un prompt, il che dimostra che la rimozione ha avuto effetto. Una sfida che fallisce da un dispositivo registrato esistente è un problema di prompt, non un motivo per registrare di nuovo tutto.

Poi chiedete all’utente di completare lo stesso accesso senza guida. Il vostro test riuscito dimostra la configurazione; il suo tentativo dimostra la consegna.

Chiudete il ticket con il timestamp dell’accesso riuscito e il nome del fattore ora in uso. Aggiornate il registro di recupero nella stessa passata, così la prossima perdita parte da un inventario accurato e non da uno obsoleto.

Passo 5: eliminate la condizione che ha reso tutto questo doloroso

Ogni chiamata di recupero è una prova sul progetto di registrazione. Se l’account aveva esattamente un fattore, richiedetene un secondo per tutti in quel gruppo. Se i codici di recupero erano sul portatile smarrito, cambiate dove vivono. Se la verifica richiedeva un manager in ferie, nominate un supplente. Ogni correzione costa un pomeriggio ed elimina l’ora peggiore dell’incidente successivo.

Poi rileggete il registro del primo passo contro la realtà. Elenca i fattori che esistono davvero, e il canale di verifica raggiunge ancora una persona? Un manuale che nessuno aggiorna si degrada in un documento che le persone ignorano durante la chiamata per cui è stato scritto.