Recursos · 24
Implante autenticação resistente a phishing com recuperação segura.
Use fatores vinculados ao serviço genuíno e proteja o registro, a perda e a revogação.
Atualizado · 3 min
O que este guia ajuda a alcançar
- Mapear caminhos de acesso
- Selecionar um protocolo resistente
- Proteger o cadastro
- Simular recuperação.
Verificação rápida
- Quais contas acessam dados ou funções críticas?
- O fator está criptograficamente vinculado ao serviço genuíno?
- Quem autoriza um novo autenticador?
- Como um dispositivo perdido é revogado?
- As exceções têm um proprietário e uma data de término?
Método passo a passo
- 1
Inventariar caminhos de acesso
Listar aplicativos, federação, administradores, contas de emergência e métodos atuais. Identificar logins que ainda aceitam códigos inseridos manualmente.
Entregável: matriz de contas, aplicativos e fatores.
- 2
Selecionar a resistência necessária
Avaliar protocolos criptográficos vinculados a um canal ou nome de verificador, como WebAuthn/FIDO2, onde o aplicativo o suporta. O NIST não considera os OTPs inseridos manualmente como resistentes a phishing, pois um site falso pode retransmiti-los.
Entregável: escolha do método e limitações conhecidas.
- 3
Pilotar contas sensíveis.
Testar navegadores, dispositivos, delegação, possível uso offline e acessibilidade com um grupo representativo. Fornecer mais de um caminho autorizado sem acumular acesso inativo.
Entregável: cenários piloto e critérios de sucesso.
- 4
Proteger o cadastro
Verificar identidade e sessão antes de adicionar uma chave, notificar o usuário e registrar o evento. Testar a rejeição de uma solicitação de inscrição em um contexto suspeito.
Entregável: procedimento de inscrição e registro de eventos.
- 5
Planejar perda e revogação.
Documentar relatórios, desativação, recuperação e verificações de identidade para um autenticador perdido. Testar o processo sem burlar a proteção por meio de um canal mais fraco.
Entregável: exercício de recuperação e revogação.
- 6
Expandir e monitorar.
Implementar por grupo, medir a cobertura, acompanhar falhas e exceções e, em seguida, desativar os métodos legados assim que o processo de recuperação testado permitir.
Entregável: painel de migração e registro de exceções.
Indicadores de gestão
| Indicador | O que mede | Primeira ação |
|---|---|---|
| Abrangência | Contas sensíveis em métodos resistentes | Ampliar a implementação |
| Inscrição | Adições com verificações e notificações | Corrigir caminhos vulneráveis |
| Recuperação | Perdas simuladas resolvidas sem bypass | Repetir o exercício |
| Exceções | Acesso restante com proprietário e expiração | Desativar fatores legados |
Erros comuns
- Chamar todos os métodos de MFA de resistentes a phishing
- Proteger o login, mas deixar a inscrição vulnerável
- Administradores e contas de emergência ausentes
- Desativar um método legado antes que a recuperação funcione
Perguntas frequentes
Um código único é suficiente?
O NIST explica que um código inserido manualmente pode ser retransmitido por um serviço impostor e não é resistente a phishing.
Todos precisam de uma chave de hardware?
A escolha depende da garantia e do contexto; Alguns autenticadores WebAuthn sincronizáveis podem ser adequados para certos usos, com opções de recuperação apropriadas.
O que acontece após a perda do dispositivo?
Revogar o autenticador afetado, seguir o processo de recuperação verificado e notificar o usuário de acordo com a política de serviço.
Referências oficiais
As referências apoiam o método. Adapte as verificações ao seu contexto; elas não são uma certificação. Os títulos das referências originais e os documentos de origem podem estar em outro idioma.
