Autenticador de VPN perdido: reemplazarlo sin desactivar el MFA

Alguien pierde el teléfono y el ticket llega como VPN roto. Ese planteamiento es erróneo dos veces: la cuenta sigue existiendo y la pasarela sigue confiando en el proveedor de identidad, así que la única parte rota es un factor que la persona ya no tiene. Trátelo como una recuperación y no como una caída: verifique al solicitante, registre un reemplazo, retire el método perdido y luego demuestre que la cuenta funciona. Todo ello presupone que el plan se escribió antes de la pérdida, porque inventarlo durante la llamada es como el MFA acaba desactivado para todos.

Paso 1: lea los factores registrados de un registro, no de la memoria

La primera pregunta no es qué dispositivo se perdió, sino qué más puede seguir usando la cuenta. Una cuenta puede llevar una contraseña con push, un código basado en el tiempo, una clave física y códigos de recuperación impresos, y perder uno de ellos es un acontecimiento muy distinto de perder el único. Lea la lista de métodos del sistema de identidad en lugar de pedir al usuario que la recuerde, y en un inquilino de Microsoft Entra la consulta es una línea:

Get-MgUserAuthenticationMethod -UserId [email protected]

A continuación, escriba el registro de recuperación mientras la cuenta sigue funcionando: identificador de la cuenta, factores registrados, dónde viven los códigos de recuperación, quién puede verificar al solicitante de forma independiente y a qué sistemas llega la cuenta. Guárdelo en el inventario protegido que el equipo ya utiliza, nunca en una nota que también contenga códigos activos. Esos cinco campos convierten una llamada de pánico en una lista de comprobación, y la guía del NIST sobre el ciclo de vida de los autenticadores trata la recuperación como parte de la credencial y no como una excepción.

Registre el canal de verificación como un campo propio, porque esa es la parte que la gente se salta. Un número de teléfono asociado a la cuenta no es un canal independiente cuando la persona que lo pide también controla el teléfono.

Paso 2: verifique al solicitante fuera de la ruta que falla

Realice la comprobación de identidad por un canal que no dependa de la VPN, el buzón ni el dispositivo perdido. Una llamada de vuelta a un número del registro de personal, o una comprobación en persona con un directivo que ya está en el directorio, funcionan ambas; un mensaje de chat enviado desde la cuenta en recuperación no funciona. La comprobación trata de la persona, no de su capacidad de responder preguntas sobre la cuenta, porque los detalles de la cuenta se filtran. Registre quién verificó la solicitud y cuándo, ya que el siguiente revisor querrá ambas cosas.

Cuando la solicitud llega con urgencia y presión para saltarse la comprobación, ese es el momento de ir más despacio. El fraude de recuperación se parece exactamente a un colega servicial que tiene prisa.

Paso 3: registre el reemplazo y después retire el factor antiguo

Registre el nuevo autenticador por el flujo de registro normal, nunca por una omisión administrativa. Después elimine explícitamente el método perdido, porque registrar un reemplazo deja el autenticador anterior autorizado hasta que alguien lo retire. Si el dispositivo antiguo puede estar en manos de otra persona, trate la eliminación como urgente y siga el proceso de incidente en lugar del de recuperación. Revogue las sesiones existentes en la misma pasada, ya que una sesión creada antes del cambio puede sobrevivirle:

Revoke-MgUserSignInSession -UserId [email protected]

Eliminar el factor para todos los demás, o relajar las comprobaciones de certificado de la pasarela, cambia la recuperación de una persona por una caída que afecta a todo el despliegue. Mantenga el cambio limitado a la cuenta única y escale si las pruebas apuntan a un compromiso más amplio. Anote en el ticket qué factor se retiró y cuál lo reemplazó.

Paso 4: demuestre que la cuenta funciona en ambas direcciones

Inicie sesión una vez con el factor nuevo mediante un cliente compatible y luego confirme que la cuenta sigue llegando a los recursos a los que llegaba antes de la pérdida. Pruebe un recurso que necesite el túnel y otro que no, para que un fallo apunte a la capa correcta. Intente un inicio de sesión con el factor retirado y espere un rechazo en lugar de un aviso, lo que demuestra que la eliminación surtió efecto. Un desafío que falla desde un dispositivo registrado existente es un problema de aviso, no un motivo para volver a registrarlo todo.

Después pida al usuario que complete el mismo inicio de sesión sin indicaciones. Su prueba correcta demuestra la configuración; su intento demuestra el traspaso.

Cierre el ticket con la marca temporal del inicio de sesión correcto y el nombre del factor que se usa ahora. Actualice el registro de recuperación en la misma pasada, para que la próxima pérdida parta de un inventario preciso y no de uno obsoleto.

Paso 5: elimine la condición que hizo esto doloroso

Cada llamada de recuperación es una prueba sobre el diseño del registro. Si la cuenta tenía exactamente un factor, exija un segundo para todos en ese grupo. Si los códigos de recuperación estaban en el portátil perdido, cambie dónde viven. Si la verificación necesitaba un directivo que estaba de vacaciones, nombre un suplente. Cada corrección cuesta una tarde y elimina la peor hora del siguiente incidente.

Después relea el registro del paso uno contra la realidad. ¿Enumera los factores que existen realmente y el canal de verificación sigue llegando a una persona? Un manual que nadie actualiza se convierte en un documento que la gente ignora durante la llamada para la que se escribió.