Autenticador VPN perdido: substituir sem desativar o MFA

Alguém perde o telefone e o ticket chega como VPN quebrado. Esse enquadramento está errado duas vezes: a conta ainda existe e o gateway ainda confia no provedor de identidade, então a única parte quebrada é um fator que a pessoa não tem mais. Trate como recuperação e não como parada: verifique o solicitante, registre um substituto, retire o método perdido e depois prove que a conta funciona. Tudo isso pressupõe que o plano foi escrito antes da perda, porque inventá-lo durante a ligação é como o MFA acaba desativado para todos.

Passo 1: leia os fatores registrados de um registro, não da memória

A primeira pergunta não é qual dispositivo se perdeu, mas o que mais a conta ainda pode usar. Uma conta pode ter uma senha com push, um código baseado em tempo, uma chave física e códigos de recuperação impressos, e perder um deles é um evento muito diferente de perder o único. Leia a lista de métodos do sistema de identidade em vez de pedir ao usuário que a memorize, e num tenant do Microsoft Entra a consulta é uma linha:

Get-MgUserAuthenticationMethod -UserId [email protected]

Depois escreva o registro de recuperação enquanto a conta ainda funciona: identificador da conta, fatores registrados, onde ficam os códigos de recuperação, quem pode verificar o solicitante de forma independente e a que sistemas a conta chega. Guarde-o no inventário protegido que a equipe já usa, nunca numa nota que também contenha códigos ativos. Esses cinco campos transformam uma ligação em pânico numa lista de verificação, e as orientações do NIST sobre o ciclo de vida dos autenticadores tratam a recuperação como parte da credencial e não como exceção.

Registre o canal de verificação como campo próprio, porque é essa a parte que as pessoas pulam. Um número de telefone ligado à conta não é um canal independente quando a pessoa que pede também controla o telefone.

Passo 2: verifique o solicitante fora do caminho que falha

Faça a verificação de identidade por um canal que não dependa da VPN, da caixa de correio ou do dispositivo perdido. Uma chamada de retorno para um número do registro de RH, ou uma verificação presencial com um gestor que já está no diretório, funcionam ambas; uma mensagem de chat enviada da conta em recuperação não funciona. A verificação é sobre a pessoa, não sobre a capacidade dela de responder a perguntas sobre a conta, porque os detalhes da conta vazam. Registre quem verificou o pedido e quando, já que o próximo revisor vai querer os dois.

Quando o pedido chega com urgência e pressão para pular a verificação, é esse o momento de desacelerar. A fraude de recuperação parece exatamente um colega prestativo com pressa.

Passo 3: registre o substituto e depois retire o fator antigo

Registre o novo autenticador pelo fluxo normal de registro, nunca por uma burla administrativa. Depois remova explicitamente o método perdido, porque registrar um substituto deixa o autenticador anterior autorizado até que alguém o retire. Se o dispositivo antigo puder estar nas mãos de outra pessoa, trate a remoção como urgente e siga o processo de incidente em vez do de recuperação. Revogue as sessões existentes na mesma passagem, já que uma sessão criada antes da mudança pode sobreviver a ela:

Revoke-MgUserSignInSession -UserId [email protected]

Remover o fator para todos os outros, ou afrouxar as verificações de certificado do gateway, troca a recuperação de uma pessoa por uma parada que atinge toda a implantação. Mantenha a mudança limitada à conta única e escale se as evidências apontarem para um comprometimento mais amplo. Anote no ticket qual fator foi retirado e qual o substituiu.

Passo 4: prove que a conta funciona nos dois sentidos

Entre uma vez com o novo fator por um cliente compatível e depois confirme que a conta ainda alcança os recursos que alcançava antes da perda. Teste um recurso que precisa do túnel e um que não precisa, para que uma falha aponte a camada certa. Tente um login com o fator retirado e espere uma rejeição em vez de um prompt, o que prova que a remoção surtiu efeito. Um desafio que falha a partir de um dispositivo registrado existente é um problema de prompt, não um motivo para registrar tudo de novo.

Depois peça ao usuário que conclua o mesmo login sem orientação. Seu teste bem-sucedido prova a configuração; a tentativa dele prova a entrega.

Feche o ticket com o carimbo de tempo do login bem-sucedido e o nome do fator em uso agora. Atualize o registro de recuperação na mesma passagem, para que a próxima perda comece de um inventário preciso e não de um obsoleto.

Passo 5: remova a condição que tornou isto doloroso

Cada ligação de recuperação é evidência sobre o desenho do registro. Se a conta tinha exatamente um fator, exija um segundo para todos naquele grupo. Se os códigos de recuperação estavam no portátil perdido, mude onde eles ficam. Se a verificação exigia um gestor de férias, nomeie um substituto. Cada correção custa uma tarde e remove a pior hora do próximo incidente.

Depois releia o registro do passo um contra a realidade. Ele lista os fatores que realmente existem, e o canal de verificação ainda alcança uma pessoa? Um manual que ninguém atualiza degrada-se num documento que as pessoas ignoram durante a ligação para a qual foi escrito.