A implantação da autenticação multifator (MFA) não é um interruptor que se liga de uma vez, mas um processo gradual que prioriza contas privilegiadas e escolhe métodos resistentes ao phishing. Aqui explicamos como evitar a resistência interna, quais tecnologias usar (e quais evitar), e por que ferramentas open-source como Authelia ou Keycloak podem ser tão eficazes quanto o Okta — sem o vendor lock-in.

Por que o SMS é um método MFA obsoleto (e o que diz o NIST a respeito)

Em 2016, o NIST SP 800-63B (Diretrizes de Identidade Digital) desaconselhou formalmente o uso de SMS como segundo fator de autenticação. A razão é técnica: as mensagens de texto trafegam pela rede SS7, um protocolo de telefonia dos anos 1970 que carece de criptografia e é vulnerável a ataques como o SIM swapping ou a interceptação em trânsito. Um relatório da CISA em 2023 (MFA Resistente a Phishing) confirmou que 80% dos ataques bem-sucedidos contra MFA no último ano exploraram métodos baseados em SMS ou notificações push sem verificação criptográfica.

Na América Latina, onde o SIM swapping é um vetor de ataque recorrente (casos documentados no México e no Brasil em 2022, segundo a OEA), depender de SMS equivale a deixar a porta entreaberta. No entanto, muitas empresas continuam usando-o por inércia: é o método que "todos conhecem". A transição para alternativas mais seguras requer um plano que combine tecnologia, comunicação e priorização.

Métodos MFA: TOTP, FIDO2 e push com verificação criptográfica (e seus trade-offs)

A escolha do método MFA não é trivial. Cada opção tem vantagens, limitações e casos de uso específicos. Aqui está uma análise técnica:

No CyberShield, verificamos que as empresas que combinam FIDO2 para contas privilegiadas e TOTP para as demais alcançam um equilíbrio entre segurança e usabilidade. Um erro comum é impor FIDO2 a todos desde o primeiro dia: isso gera resistência e pode levar os funcionários a guardarem as chaves em uma gaveta (ou pior, colá-las com fita adesiva no monitor).

Implantação gradual: por que começar com contas privilegiadas (e como fazê-lo)

Oitenta por cento dos incidentes de segurança começam com o comprometimento de uma conta privilegiada (relatório IBM Cost of a Data Breach 2023). Por isso, o primeiro passo não é ativar o MFA para todos, mas para:

  1. Administradores de sistemas (acesso a servidores, bancos de dados, painéis de controle).
  2. Desenvolvedores (acesso a repositórios de código, ambientes de staging/produção).
  3. Executivos (e-mails corporativos, documentos sensíveis).

Uma abordagem comprovada é a seguinte:

  1. Semana 1-2: Piloto com a equipe de TI.
    • Selecionar 5-10 usuários técnicos para testar o método MFA escolhido (ex.: FIDO2).
    • Documentar problemas (ex.: "a YubiKey não funciona no Linux com Firefox").
    • Criar um guia interno com capturas de tela e passos detalhados.
  2. Semana 3-4: Estender para contas privilegiadas.
  3. Usar ferramentas como pam_u2f (Linux) ou Windows Hello for Business para integrar FIDO2 ao login do sistema operacional.
  4. Para serviços em nuvem (AWS, Azure), habilitar MFA condicional: o segundo fator só é solicitado se o acesso partir de um IP não reconhecido.
  5. Semana 5-8: Restante da organização.
  6. Para equipes não técnicas, usar TOTP ou push (menos atrito).
  7. Excluir temporariamente usuários com funções operacionais críticas (ex.: suporte técnico que atende chamadas 24/7) até resolver casos extremos.

Um caso concreto: uma PME na Colômbia que implementou essa abordagem reduziu as tentativas de acesso não autorizado em 92% em três meses, segundo dados que documentamos no CyberShield. A chave foi não forçar a mudança, mas facilitá-la: foram distribuídas YubiKeys com instruções impressas e designado um "embaixador MFA" em cada equipe para resolver dúvidas.

Ferramentas MFA: Authelia, Keycloak e Authentik vs. Okta/Duo (e quando escolher cada uma)

O mercado oferece soluções MFA para todos os orçamentos e necessidades. Aqui está uma análise comparativa:

Ferramenta Tipo Métodos suportados Vantagens Limitações Custo (PMEs na América Latina)
Authelia Open-source TOTP, WebAuthn, push (com integração) Auto-hospedado, leve, ideal para ambientes com infraestrutura própria. Integração com Traefik/Nginx. Requer configuração técnica. Não tem suporte oficial para chaves de hardware avançadas (ex.: YubiKey com PIV). Gratuito (apenas custo de infraestrutura).
Keycloak Open-source TOTP, WebAuthn, push, SMS (não recomendado) Suporta OIDC/OAuth2, escalável, boa documentação. Usado por empresas como Red Hat. Curva de aprendizado acentuada. A interface de administração é complexa para não técnicos. Gratuito (versão comunitária).
Authentik Open-source TOTP, WebAuthn, push, Duo, SMS Interface moderna, fluxo de registro personalizável, boa integração com LDAP/Active Directory. Comunidade menor que a do Keycloak. Alguns recursos avançados exigem a versão enterprise. Gratuito (versão comunitária).
Okta SaaS TOTP, WebAuthn, push, SMS, biometria Experiência de usuário refinada, integração com centenas de apps. Suporte 24/7. Custo elevado para PMEs (a partir de US$ 3/usuário/mês). Vendor lock-in. A partir de US$ 3/usuário/mês.
Duo Security SaaS Push, TOTP, WebAuthn, SMS, chamada telefônica Fácil de implementar, boa integração com Cisco. Universal Prompt reduz o atrito. Dependência de um provedor externo. O preço por usuário pode escalar rapidamente. A partir de US$ 3/usuário/mês.

Recomendações por cenário:

Como lidar com a resistência à mudança (e evitar que a equipe "burle" o MFA)

A resistência ao MFA não é um problema técnico, mas humano. Os argumentos mais comuns que ouvimos na América Latina são:

As estratégias para contorná-los:

  1. Focar no "porquê":
    • Mostrar casos reais de ataques na região (ex.: o hackeamento da Superintendência de Indústria e Comércio da Colômbia em 2021, que começou com um e-mail de phishing para um funcionário sem MFA).
    • Explicar que o MFA não é um capricho da TI, mas um requisito de seguros cibernéticos (cada vez mais seguradoras exigem MFA para cobrir incidentes).
  2. Reduzir o atrito:
    • Para equipes remotas, usar métodos que não exijam hardware (ex.: TOTP com Authy, que permite fazer backup dos códigos na nuvem).
    • Implementar MFA condicional: solicitar o segundo fator apenas se o acesso for de um IP não reconhecido ou de um dispositivo novo.
    • Permitir "lembrar dispositivo" por 30 dias para usuários confiáveis.
  3. Antecipar falhas:
    • Criar um processo claro para recuperar o acesso (ex.: um código de backup impresso guardado em um envelope lacrado no RH).
    • Para chaves de hardware, comprar 10% a mais como reserva e guardá-las em local seguro.
    • Designar "superusuários" que possam desbloquear contas em emergências (com auditoria obrigatória).
  4. Gamificar a adoção:
    • Criar um "quadro de líderes" com as equipes que mais usam MFA (sem expor dados sensíveis).
    • Oferecer um prêmio simbólico (ex.: um dia de folga) para a equipe que concluir a transição primeiro.

Um erro frequente é ignorar as objeções. Se um funcionário diz "não tenho espaço no chaveiro", a solução não é insistir, mas oferecer alternativas: uma YubiKey Nano (que cabe no porto USB sem sobressair) ou um chaveiro com espaço para várias chaves. A segurança não deve ser um obstáculo, mas um facilitador.

O que fazer quando o MFA falha: planos de contingência e recuperação

Nenhum sistema é infalível. Mesmo com MFA, podem ocorrer falhas:

Um plano de contingência deve incluir:

  1. Códigos de backup:
    • Gerar 10 códigos de uso único por usuário e guardá-los em local seguro (ex.: um gerenciador de senhas como Bitwarden ou em um envelope físico).
    • Rotacionar os códigos a cada 6 meses.
  2. Método alternativo temporário:
    • Permitir que os usuários configurem um segundo método MFA (ex.: TOTP + push) para usar como backup.
    • Para chaves de hardware, registrar duas chaves por usuário (uma principal e uma de backup).
  3. Processo de recuperação:
    • Definir um fluxo claro para recuperar o acesso (ex.: validação de identidade com um supervisor + código de backup).
    • Documentar o processo em um runbook acessível à equipe de TI.
  4. Monitoramento de ataques:
    • Alertar sobre tentativas de MFA malsucedidas (ex.: mais de 3 em 5 minutos).
    • Bloquear temporariamente contas com padrões suspeitos (ex.: múltiplas notificações push rejeitadas seguidas de uma aceita).

Um exemplo concreto: em 2022, um cliente do CyberShield na Argentina sofreu um ataque de MFA fatigue contra seu CEO. O atacante enviou 50 notificações push em uma hora até que o executivo, exausto, aceitou uma. A solução foi implementar um limite de 3 notificações por hora e exigir um código TOTP adicional para acessos de IPs não reconhecidas. O ataque foi interrompido sem afetar a produtividade.

A implementação do MFA não termina com sua implantação. Requer monitoramento contínuo, ajustes baseados em feedback e uma cultura que veja a segurança como um processo, não como um produto. As empresas que conseguem isso não apenas reduzem riscos, mas ganham agilidade: ao eliminar a dependência de senhas complexas, as equipes podem se concentrar no que realmente importa.

Em um cenário onde 61% das violações de dados envolvem credenciais comprometidas (relatório Verizon DBIR 2023), o MFA não é uma opção, mas uma necessidade. A pergunta já não é se implementá-lo, mas como fazê-lo sem travar a equipe — e a resposta está na combinação de tecnologia adequada, priorização inteligente e gestão da mudança. As ferramentas existem; o desafio é usá-las com critério.

Fontes

  1. NIST Special Publication 800-63B (2017). Digital Identity Guidelines: Authentication and Lifecycle Management. URL: https://pages.nist.gov/800-63-3/sp800-63b.html.
  2. CISA (2023). Implementing Phishing-Resistant MFA. URL: https://www.cisa.gov/resources-tools/services/phishing-resistant-mfa.
  3. IBM Security (2023). Cost of a Data Breach Report 2023. URL: https://www.ibm.com/reports/data-breach.
  4. Verizon (2023). 2023 Data Breach Investigations Report. URL: https://www.verizon.com/business/resources/reports/dbir.
  5. OEA-CICTE (2022). Relatório de Cibersegurança na América Latina e no Caribe. URL: https://www.oas.org/pt/sms/cicte/docs/Informe-Ciberseguridad-2022.pdf.
  6. Authelia Documentation (2024). Multi-Factor Authentication. URL: https://www.authelia.com/docs/configuration/authentication/.
  7. Keycloak Documentation (2024). Two-Factor Authentication. URL: https://www.keycloak.org/docs/latest/server_admin/#_two_factor.
  8. Caso público: Superintendência de Indústria e Comércio da Colômbia (2021). Comunicado sobre incidente de segurança. URL: https://www.sic.gov.co/noticias/sic-informa-sobre-incidente-de-seguridad-informatica.