Como configurar MFA e chaves FIDO2 no Microsoft 365, Google Workspace e AWS: passo a passo prático para reduzir invasões em 2026
Se você já viu uma conta administrativa ser tomada por phishing, sabe que um único clique pode custar semanas de retrabalho e reputação. A solução não é mágica, é disciplina: autenticação multifator (MFA) bem implementada e, quando possível, chaves de segurança FIDO2/WebAuthn para elevar a proteção a nível “resistente a phishing”. Neste guia técnico e direto ao ponto, mostro como ativar e padronizar MFA e FIDO2 em Microsoft 365 (Entra ID), Google Workspace e AWS, incluindo armadilhas reais, políticas eficazes, plano de contingência e validações de segurança que aprendi no campo.
Por que FIDO2 muda o jogo (e quando o MFA “comum” ainda serve)
Todo MFA ajuda, mas nem todo MFA é igual. SMS e chamadas quebram ataques massivos, porém falham frente a SIM swap e engenharia social. TOTP por app autenticador é melhor, mas ainda pode ser capturado por páginas falsas em ataques de proxy reverso. FIDO2/WebAuthn usa criptografia de chave pública vinculada ao domínio, o que torna inúteis os sites falsos. Em termos práticos: se você protege contas críticas com chaves FIDO2, você neutraliza a técnica mais comum dos invasores hoje.
Ainda assim, na vida real, você terá misto de cenários: usuários móveis, sistemas legados e integrações que exigem workarounds. O segredo é aplicar FIDO2 onde ele traz mais impacto (admin, finanças, TI, VIPs) e usar TOTP com políticas rígidas no restante, até elevar toda a base.
Preparação estratégica: políticas, inventário e redundância
Defina quem precisa de FIDO2 primeiro
- Contas privilegiadas (admin global, billing, developers com produção, IAM admins).
- Usuários-alvo frequentes de spear phishing (diretoria, financeiro, RH, fornecedores críticos).
- Contas de automação que ainda exigem senha: isole, migre para identidades gerenciadas ou tokens.
Tenha sempre 2 chaves por usuário
Uma chave principal no chaveiro do dia a dia e uma chave reserva guardada em local seguro. Rotule as chaves no momento do registro: “Chave-Julia-Principal” e “Chave-Julia-Backup”. Isso reduz chamados e evita bloqueios.
Contas de emergência (“break glass”)
Crie 2 contas de emergência com senhas longas e exclusão de políticas de MFA, monitoradas 24×7 por alertas de login. Use somente para recuperar o ambiente quando algo dá errado. Não deixe estas contas “esquecidas”.
Dica de ouro: antes de forçar MFA para todos, rode uma campanha de registro por 7 a 14 dias. Colete métricas: quem registrou chaves, quem ficou no TOTP, quem não iniciou. Só então habilite a exigência com prazo final claro. Evita pico de chamados e resistência cultural.
Microsoft 365 (Entra ID): habilitar MFA e FIDO2 com políticas de Acesso Condicional
Passo a passo para exigir MFA no Microsoft 365
- No centro de administração do Entra ID, acesse Segurança ou Protection e crie uma política de Acesso Condicional exigindo requisição de MFA para usuários-alvo. Aplique primeiro a um grupo piloto, exclua contas “break glass”.
- Evite depender apenas do “Security Defaults” se você precisa de granularidade. Acesso Condicional permite segmentar apps, locais, risco e grupos.
- Desative autenticação básica herdada (POP, IMAP, SMTP AUTH quando possível). Isso fecha portas que contornam o MFA.
Habilitar FIDO2/WebAuthn para usuários
- Em Métodos de Autenticação no Entra, habilite o método Chave de Segurança FIDO2 e defina escopo (todos ou grupos).
- Instrua os usuários a registrar as chaves em myaccount.microsoft.com ou em Segurança de Informações de Segurança (Security info). Registre pelo menos duas chaves.
- Confirme compatibilidade: navegadores modernos (Edge, Chrome, Firefox) e SO com suporte a WebAuthn.
Boas práticas específicas do Microsoft 365
- Política para admins: obrigue FIDO2 ou, no mínimo, “MFA forte” e bloqueie SMS para funções privilegiadas.
- Condição por risco: combine com Avaliação de Risco de Identidade para exigir reautenticação em sinais suspeitos.
- Apps legados: migre para OAuth moderno. Evite “senhas de app” a menos que seja temporário e monitorado.
Limitações reais: FIDO2 não substitui chaves de API, conectores antigos e fluxos que ainda dependem de Basic Auth. Para esses casos, isole com políticas de rede, acesso condicional por aplicação e prazos de migração.
Google Workspace: forçar 2SV e usar chaves de segurança como padrão
Ativar 2SV e permitir chaves de segurança
- No Admin Console, vá em Segurança e ative a verificação em duas etapas (2SV) com exigência por unidade organizacional ou grupo.
- Habilite o uso de Security Keys (FIDO2/U2F). Para administradores e contas sensíveis, exija chaves de segurança como fator primário.
- Para registro, peça aos usuários acessarem a conta Google, em Segurança, e adicionarem “Chave de segurança”. Registre duas chaves e nomeie-as.
Endurecimento para contas críticas
- Considere ativar proteções avançadas para administradores de alto risco, se compatível com seu fluxo.
- Bloqueie SMS para admins. Priorize FIDO2 e TOTP. Aplique context-aware access para analisar localização, dispositivo e risco.
Limitações reais: extensões de terceiros e aplicativos IMAP antigos ainda podem exigir exceções temporárias. Garanta auditoria e prazo curto. Defina um procedimento de exceção com aprovação formal e revisão semanal.
AWS: MFA obrigatório no root e chaves FIDO2 para IAM e Identity Center
Protegendo o usuário root e usuários IAM
- No console da AWS, acesse IAM e, em Credenciais de Segurança, configure MFA no usuário root imediatamente. Prefira “Security Key” (FIDO2) ou, no mínimo, TOTP por aplicativo autenticador.
- Para usuários IAM, em Users, abra Security credentials e escolha Assign MFA device como Security key (WebAuthn) ou TOTP. Exija duas chaves para perfis críticos.
- Remova o uso interativo de usuários IAM quando possível e migre para AWS IAM Identity Center com autenticação centralizada e suporte a FIDO2 via provedor de identidade.
Integração com SSO e provedores externos
- Se usar SSO com Entra ID ou Google como IdP, force FIDO2 no IdP e restrinja acesso à AWS apenas via SSO. Reduza superfícies de ataque desabilitando logins diretos desnecessários.
- Para acesso programático, use roles e credenciais temporárias. Nunca dependa de senhas ou chaves estáticas de longo prazo em estações de trabalho.
Limitações reais: pipelines legados e integrações com chaves estáticas exigem migração cuidadosa. Enquanto isso, isole com bloqueios por IP, rotação agressiva e Cofres de Segredo com auditoria.
Insight prático: sempre valide a experiência de recuperação. Simule “perdi minha chave e meu celular” com um usuário comum e um admin. Meça o tempo de desbloqueio. Ajuste procedimentos antes do go-live. É aí que a maioria das políticas falha.
Operação contínua: governança, suporte e auditoria
Fluxo de onboarding e offboarding
- No onboarding: emitir duas chaves, registrar, rotular e testar login. Documente como usar em notebook, desktop e mobile.
- No offboarding: revogue chaves do usuário e recupere dispositivos físicos. Registre a revogação no ticket de desligamento.
Recuperação e contingência
- Mantenha métodos alternativos seguros: TOTP e códigos de backup armazenados em cofre corporativo, com acesso sob dupla aprovação.
- Treine o Service Desk para validar identidade sem atalhos perigosos. Proíba “reset por e-mail pessoal”.
Monitoramento e melhoria contínua
- Acompanhe métricas: taxa de adoção de FIDO2, chamados de bloqueio, exceções abertas, logins negados por risco.
- Faça exercícios de phishing com cenários que tentam capturar OTP. Compare resultados entre quem usa TOTP vs FIDO2 e direcione treinamentos.
Checklist rápido para cada plataforma
Microsoft 365
- Desativar Basic Auth herdada.
- Habilitar MFA via Acesso Condicional e exigir FIDO2 para admins.
- Permitir registro de chaves FIDO2 e orientar dois registros por usuário.
Google Workspace
- Forçar 2SV por UO/grupo.
- Exigir chaves de segurança para perfis de alto risco.
- Bloquear SMS para admins e usar acesso contextual.
AWS
- MFA no root com Security Key.
- IAM com MFA obrigatório e preferência por Security Key.
- Adotar Identity Center/SSO e reduzir credenciais estáticas.
Erros comuns que derrubam boas implementações
- Confiar em SMS para tudo: melhor que nada, mas não é suficiente para contas sensíveis.
- Forçar MFA sem campanha de registro: resulta em sobrecarga no suporte e desativação emergencial.
- Ignorar apps leg
