Autenticador VPN perdido: substituílo sen desactivar o MFA

Alguén perde o teléfono e o tícket chega como VPN roto. Ese planteamento é erróneo dúas veces: a conta segue existindo e a pasarela segue confiando no provedor de identidade, así que a única parte rota é un factor que a persoa xa non ten. Tráteo como unha recuperación e non como unha caída: verifique o solicitante, rexistre un substituto, retire o método perdido e logo demostre que a conta funciona. Todo iso presupón que o plan se escribiu antes da perda, porque inventalo durante a chamada é como o MFA acaba desactivado para todos.

Paso 1: lea os factores rexistrados dun rexistro, non da memoria

A primeira pregunta non é que dispositivo se perdeu, senón que máis pode seguir usando a conta. Unha conta pode levar un contrasinal con push, un código baseado no tempo, unha chave física e códigos de recuperación impresos, e perder un deles é un acontecemento moi distinto de perder o único. Lea a lista de métodos do sistema de identidade en lugar de pedirlle ao usuario que a recorde, e nun inquilino de Microsoft Entra a consulta é unha liña:

Get-MgUserAuthenticationMethod -UserId [email protected]

A continuación, escriba o rexistro de recuperación mentres a conta segue funcionando: identificador da conta, factores rexistrados, onde viven os códigos de recuperación, quen pode verificar o solicitante de forma independente e a que sistemas chega a conta. Gárdeo no inventario protexido que o equipo xa usa, nunca nunha nota que tamén conteña códigos activos. Eses cinco campos converten unha chamada de pánico nunha lista de comprobación, e a guía do NIST sobre o ciclo de vida dos autenticadores trata a recuperación como parte da credencial e non como unha excepción.

Rexiste o canal de verificación como un campo propio, porque esa é a parte que a xente salta. Un número de teléfono asociado á conta non é un canal independente cando a persoa que o pide tamén controla o teléfono.

Paso 2: verifique o solicitante fóra do camiño que falla

Realice a comprobación de identidade por un canal que non dependa da VPN, da caixa de correo nin do dispositivo perdido. Unha chamada de volta a un número do rexistro de persoal, ou unha comprobación en persoa cun xefe que xa está no directorio, funcionan ambas; unha mensaxe de chat enviada desde a conta en recuperación non funciona. A comprobación trata da persoa, non da súa capacidade de responder preguntas sobre a conta, porque os detalles da conta se filtran. Rexiste quen verificou a solicitude e cando, xa que o seguinte revisor quererá ambas as cousas.

Cando a solicitude chega con urxencia e presión para saltar a comprobación, ese é o momento de ir máis devagar. A fraude de recuperación parece exactamente un colega servicial que ten présa.

Paso 3: rexistre o substituto e despois retire o factor antigo

Rexiste o novo autenticador polo fluxo de rexistro normal, nunca por unha omisión administrativa. Despois elimine explicitamente o método perdido, porque rexistrar un substituto deixa o autenticador anterior autorizado ata que alguén o retire. Se o dispositivo antigo pode estar en mans doutra persoa, trate a eliminación como urxente e siga o proceso de incidente en lugar do de recuperación. Revogue as sesións existentes na mesma pasada, xa que unha sesión creada antes do cambio pode sobrevivirlle:

Revoke-MgUserSignInSession -UserId [email protected]

Eliminar o factor para todos os demais, ou relaxar as comprobacións de certificado da pasarela, cambia a recuperación dunha persoa por unha caída que afecta todo o despregamento. Manteña o cambio limitado á conta única e escale se as probas apuntan a un compromiso máis amplo. Anote no tícket que factor se retirou e cal o substituíu.

Paso 4: demostre que a conta funciona nas dúas direccións

Inicie sesión unha vez co factor novo mediante un cliente compatible e logo confirme que a conta segue chegando aos recursos aos que chegaba antes da perda. Proba un recurso que necesite o túnel e outro que non, para que un fallo apunte á capa correcta. Intente un inicio de sesión co factor retirado e espere un rexeitamento en lugar dun aviso, o que demostra que a eliminación surtiu efecto. Un desafío que falla desde un dispositivo rexistrado existente é un problema de aviso, non un motivo para volver rexistrar todo.

Despois pida ao usuario que complete o mesmo inicio de sesión sen indicacións. A súa proba correcta demostra a configuración; o seu intento demostra a entrega.

Pecha o tícket coa marca temporal do inicio de sesión correcto e o nome do factor que se usa agora. Actualice o rexistro de recuperación na mesma pasada, para que a próxima perda parta dun inventario preciso e non dun obsoleto.

Paso 5: elimine a condición que fixo isto doloroso

Cada chamada de recuperación é unha proba sobre o deseño do rexistro. Se a conta tiña exactamente un factor, esixa un segundo para todos nese grupo. Se os códigos de recuperación estaban no portátil perdido, cambie onde viven. Se a verificación necesitaba un xefe que estaba de vacacións, nomee un suplente. Cada corrección custa unha tarde e elimina a peor hora do seguinte incidente.

Despois relea o rexistro do paso un contra a realidade. Enumera os factores que existen realmente e o canal de verificación segue chegando a unha persoa? Un manual que ninguén actualiza convértese nun documento que a xente ignora durante a chamada para a que se escribiu.