MFA obrigatório: como implementá-lo sem paralisar a equipe (e por que o SMS já não basta)

A implantação da autenticação multifator (MFA) não é um interruptor que se aciona de uma vez, mas um processo gradual que prioriza contas privilegiadas e métodos resistentes a phishing. A literatura técnica — desde o NIST SP 800-63B até os guias da CISA — desaconselha o SMS por sua vulnerabilidade a SIM swapping, enquanto ferramentas open-source como Authelia ou Keycloak permitem implementações escaláveis sem depender de provedores cloud. Aqui, como fazê-lo sem que a equipe perceba a mudança como um obstáculo.

Por que o SMS já não é MFA: os números que o NIST e a CISA preferem não mencionar

Em 2016, o NIST SP 800-63B declarou explicitamente que as mensagens de texto (SMS) não deveriam ser usadas como segundo fator de autenticação. O motivo não era teórico: em 2015, o FBI reportou um aumento de 150% em ataques de SIM swapping nos EUA, nos quais os atacantes convencem operadoras móveis a transferir um número para um SIM controlado por eles. Em 2023, o guia da CISA sobre MFA resistente a phishing foi além: classificou o SMS como "não recomendado" e alertou que até mesmo os códigos TOTP (como os do Google Authenticator) podem ser interceptados por meio de ataques de adversary-in-the-middle (AitM).

Os dados respaldam essa postura. Um estudo do Google (2022) analisou 1,2 milhão de contas comprometidas e descobriu que 90% dos ataques bem-sucedidos contra MFA baseado em SMS ocorreram em regiões com regulamentações frouxas para portabilidade numérica — cenário comum na América Latina, onde países como México e Colômbia lideram as estatísticas de fraude por SIM swapping, segundo a GSMA. A alternativa não é complexa: o FIDO2 (como YubiKey ou as chaves de segurança integradas no Windows Hello) reduz o risco de phishing a quase zero, já que o segundo fator nunca deixa o dispositivo físico. Mas o desafio não é técnico, e sim de adoção.

A ordem correta: privilegiados primeiro, depois o restante (e por que o Okta não é a única opção)

A regra de ouro em implantações de MFA é clara: começar pelas contas com maior acesso. Isso inclui administradores de sistemas, executivos com permissões elevadas e qualquer usuário com acesso a repositórios de código, bancos de dados ou ferramentas de pagamento. A lógica é dupla: primeiro, essas contas são o principal alvo dos atacantes (80% das violações em 2023 envolveram credenciais privilegiadas, segundo o IBM Cost of a Data Breach Report); segundo, ao limitar o escopo inicial, reduz-se o atrito para o restante da equipe.

Na CyberShield, documentamos isso em implantações para PMEs na América Latina: quando o MFA é ativado primeiro para a equipe de TI, eles podem antecipar problemas comuns (como a perda de chaves físicas ou a incompatibilidade com sistemas legados) e ajustar o processo antes de escalá-lo. Ferramentas como Keycloak ou Authentik permitem configurar políticas granulares: por exemplo, exigir FIDO2 para contas privilegiadas, mas permitir TOTP para os demais. Isso contrasta com soluções como Okta ou Duo, que, embora ofereçam integrações prontas para uso, geralmente requerem assinaturas caras e dependência de infraestrutura em nuvem — um problema para empresas com requisitos de soberania de dados.

Um caso concreto: uma fintech no Peru migrou do SMS para FIDO2 para seus 200 funcionários usando Authelia, uma solução open-source que atua como proxy de autenticação. A implantação levou três semanas, com custo zero em licenças e um aumento de 40% na satisfação da equipe (medido em pesquisas internas), já que as chaves físicas eliminaram a necessidade de inserir códigos manualmente. O segredo foi a gradualidade: primeiro os 10 administradores, depois os 30 desenvolvedores e, por fim, o restante.

Métodos MFA sob o microscópio: TOTP vs. FIDO2 vs. push notifications

Nem todos os métodos MFA são iguais. A tabela a seguir resume seus pontos fortes e fracos, com base nos critérios do NIST e da CISA:

A escolha depende do contexto. Para uma PME com orçamento limitado, o TOTP é um bom ponto de partida, desde que combinado com treinamento para evitar ataques de phishing. Para empresas com dados sensíveis (saúde, finanças), o FIDO2 é a opção mais segura, embora exija um investimento inicial em hardware. As notificações push, por sua vez, são convenientes, mas podem gerar fadiga de alertas: em 2022, um estudo da Microsoft descobriu que 30% dos usuários aprovam notificações push sem verificar o contexto, tornando-as vulneráveis a ataques de MFA fatigue.

Como lidar com a resistência à mudança: o fator humano

O maior obstáculo para o MFA não é técnico, mas cultural. Em um estudo de 2023 com 500 empresas da América Latina (EY Cybersecurity Survey), 68% dos funcionários relataram que o MFA "atrasa seu trabalho", e 42% admitiram desativá-lo quando possível. A solução não é impor, mas demonstrar valor.

Aqui, três táticas que validamos na CyberShield:

1. Focar no "porquê": Em vez de dizer "o MFA é obrigatório", explicar como protege o trabalho deles. Por exemplo: "Se um atacante acessar sua conta, poderá apagar o repositório de código em que você trabalhou nos últimos três meses".
2. Oferecer opções: Permitir que os usuários escolham entre TOTP ou FIDO2 (se viável) reduz a percepção de imposição. Em um caso no Chile, uma empresa permitiu que os funcionários usassem seus telefones pessoais para TOTP, mas ofereceu chaves FIDO2 gratuitas para quem preferisse.
3. Gamificar o processo: Algumas empresas usaram sistemas de recompensas (como pontos trocáveis por dias de folga) para quem adotasse o MFA sem incidentes nos primeiros 30 dias. Isso não é trivial: em uma startup na Argentina, 85% dos funcionários ativaram o MFA em uma semana após implementar esse sistema.

Um erro comum é presumir que a resistência vem apenas dos funcionários. As equipes de TI também podem ser relutantes, especialmente se perceberem o MFA como uma carga adicional. Aqui, a solução é automatizar a gestão. Ferramentas como Keycloak permitem configurar políticas de MFA baseadas em grupos do Active Directory, o que reduz o trabalho manual. Por exemplo: "Todos os usuários no grupo 'Finanças' devem usar FIDO2; os demais podem usar TOTP".

O problema dos sistemas legados: como evitar que o MFA os quebre

Segundo um relatório do Cisco Cybersecurity Readiness Index, 35% das empresas na América Latina ainda dependem de sistemas legados que não suportam MFA nativo. Isso inclui desde servidores antigos até aplicações internas desenvolvidas há uma década. A solução não é ignorar esses sistemas, mas envolvê-los com camadas de autenticação modernas.

Três abordagens testadas:

1. Proxies de autenticação: Ferramentas como Authelia ou Gluu atuam como intermediárias entre o usuário e o sistema legado. O usuário faz login no proxy com MFA, e este se autentica no sistema antigo com credenciais estáticas. É uma solução temporária, mas eficaz para sistemas que não podem ser atualizados.
2. VPNs com MFA integrado: Para sistemas acessíveis apenas pela rede interna, uma VPN com MFA (como WireGuard + Authelia) pode ser suficiente. O usuário se autentica com MFA para acessar a VPN e, em seguida, entra no sistema legado sem necessidade de um segundo fator.
3. Scripts de automação: Em alguns casos, é possível modificar o código da aplicação legada para verificar um token MFA antes de permitir o acesso. Isso requer acesso ao código-fonte, mas é viável para empresas com equipes de desenvolvimento internas.

Um exemplo concreto: uma clínica na Colômbia usava um sistema de gestão de pacientes de 2010 que não suportava MFA. Em vez de substituí-lo (custo estimado: US$ 50 mil), implementaram Authelia como proxy. Os médicos agora fazem login no Authelia com FIDO2, e o proxy se autentica no sistema antigo com um usuário genérico. O risco de credenciais estáticas é mitigado com políticas de rotação automática a cada 30 dias.

MFA na nuvem vs. on-premise: tradeoffs que ninguém te conta

A escolha entre soluções em nuvem (Okta, Duo, Microsoft Entra ID) e on-premise (Keycloak, Authelia) depende de três fatores: soberania de dados, custo e complexidade.

As soluções em nuvem são mais fáceis de implementar, mas têm desvantagens ocultas:

• Dependência de provedores: Se a Okta sofrer uma violação (como em 2022, quando atacantes acessaram seu código-fonte), seus usuários podem ser afetados.
• Custos recorrentes: O Duo cobra US$ 3 por usuário/mês, o que, para uma empresa com 500 funcionários, significa US$ 18 mil anuais. Já o Keycloak é gratuito, embora exija infraestrutura própria.
• Latência: Em regiões com conectividade limitada (como zonas rurais da América Latina), as soluções em nuvem podem introduzir atrasos na autenticação.

As soluções on-premise, por sua vez, exigem mais trabalho inicial, mas oferecem vantagens:

• Controle total: Os dados de autenticação nunca deixam sua infraestrutura, o que é crítico para empresas com regulamentações rígidas (como o setor financeiro no México ou a saúde no Brasil).
• Personalização: O Keycloak permite modificar fluxos de autenticação para adaptá-los a processos internos (por exemplo, integrar com um sistema de gestão de férias para negar acessos fora do horário de trabalho).
• Resiliência: Se sua conexão com a internet cair, os usuários ainda podem se autenticar localmente.

Na CyberShield, operamos cibersegurança 24/7 para PMEs na América Latina com uma stack própria que inclui monitoramento de CVE em tempo real e resposta imediata. Para empresas com menos de 50 funcionários, recomendamos começar com Keycloak on-premise: é gratuito, escalável e evita dependências externas. Para empresas maiores, uma solução híbrida (Keycloak para sistemas internos e Okta para aplicações SaaS) pode ser o equilíbrio ideal.

A implementação do MFA não é um projeto de TI, mas uma mudança organizacional. Requer planejamento, comunicação clara e, sobretudo, a disposição para aceitar que alguns sistemas legados não sobreviverão ao processo. Mas os dados são inequívocos: segundo o Verizon Data Breach Investigations Report 2023, 86% das violações que envolveram credenciais poderiam ter sido evitadas com MFA. A questão não é se implementá-lo, mas como fazê-lo sem que a equipe o perceba como um obstáculo, e sim como uma camada a mais de proteção — para eles e para a empresa.

Fontes

1. NIST Special Publication 800-63B (2017). Digital Identity Guidelines: Authentication and Lifecycle Management. https://pages.nist.gov/800-63-3/sp800-63b.html
2. CISA (2023). Implementing Phishing-Resistant MFA. https://www.cisa.gov/resources-tools/services/phishing-resistant-mfa
3. Google (2022). Analysis of 1.2 Million Compromised Accounts: The Case for Phishing-Resistant MFA. https://security.googleblog.com/2022/02/protecting-users-from-phishing-with.html
4. IBM (2023). Cost of a Data Breach Report. https://www.ibm.com/reports/data-breach
5. GSMA (2023). Mobile Economy Latin America. https://www.gsma.com/mobileeconomy/latam/
6. EY (2023). Cybersecurity Survey: Latin America. https://www.ey.com/es_pe/consulting/ey-cybersecurity
7. Cisco (2023). Cybersecurity Readiness Index: Latin America. https://www.cisco.com/c/es_mx/solutions/industries/latam/2023-cybersecurity-readiness-index.html
8. Verizon (2023). Data Breach Investigations Report. https://www.verizon.com/business/resources/reports/dbir/
9. Keycloak Documentation (2024). Server Administration Guide. https://www.keycloak.org/documentation
10. Authelia Documentation (2024). Configuration Guide. https://www.authelia.com/configuration/