Como implementar MFA empresarial com controlo

Uma credencial Microsoft 365, VPN ou ERP comprometida pode ser suficiente para parar uma operação inteira. Saber como implementar MFA empresarial não é, por isso, uma decisão sobre instalar uma aplicação de autenticação. É uma decisão de arquitetura, continuidade operacional e controlo de acesso.

O erro mais frequente é ativar MFA para todos no mesmo dia, sem conhecer aplicações legadas, contas de serviço, fluxos de acesso remoto ou utilizadores com funções críticas. O resultado é previsível: interrupções, exceções permanentes e equipas de IT pressionadas a reduzir a segurança para voltar a pôr o negócio a funcionar.

Uma implementação séria deve proteger o acesso sem introduzir fricção desnecessária. O método passa por quatro fases: diagnóstico, arquitetura, implementação controlada e operação contínua.

Porque o MFA empresarial deixou de ser opcional

As palavras-passe continuam a ser um ponto de entrada recorrente para ataques de phishing, reutilização de credenciais e força bruta. Mesmo uma palavra-passe longa pode ser exposta fora da organização, capturada numa página fraudulenta ou usada indevidamente por alguém com acesso legítimo.

O MFA reduz esse risco ao exigir uma segunda prova de identidade: uma notificação numa aplicação autenticadora, um código temporário, uma chave física de segurança ou um certificado no equipamento. Contudo, nem todos os fatores têm o mesmo nível de proteção. SMS e chamadas telefónicas podem servir como medida transitória, mas são mais vulneráveis a fraude de SIM swap e engenharia social. Para contas administrativas, acesso remoto e sistemas críticos, a prioridade deve ser autenticação resistente a phishing, como FIDO2 ou Windows Hello for Business.

Para muitas empresas portuguesas, a pressão também vem da conformidade. A NIS2 exige medidas proporcionais de gestão de risco cibernético. O MFA, quando aplicado a acessos relevantes e acompanhado por registo, revisão e resposta a incidentes, é uma medida concreta de governação ativa. Não resolve todos os requisitos, mas elimina uma lacuna que já não é aceitável em ambientes empresariais.

Como implementar MFA empresarial em quatro fases

1. Diagnóstico: mapear antes de bloquear

O primeiro passo não é escolher uma ferramenta. É identificar quem acede a quê, a partir de onde e com que privilégio. Uma organização pode ter Microsoft 365, VPN, firewalls, aplicações SaaS, ERP, servidores Windows, equipamentos de rede e plataformas cloud. Cada elemento tem métodos de autenticação, limitações e impacto operacional diferentes.

O levantamento deve separar utilizadores comuns, equipas financeiras, administradores de sistemas, direção, prestadores externos e contas privilegiadas. Deve ainda detetar contas partilhadas, contas de serviço, equipamentos antigos e protocolos de autenticação legados. Uma conta de serviço não deve receber uma notificação no telemóvel de um colaborador. Deve ser substituída, sempre que possível, por identidade gerida, certificado, segredo protegido ou outro mecanismo adequado ao sistema.

Nesta fase, vale a pena analisar os registos de autenticação. Eles mostram acessos de geografias invulgares, aplicações que ainda usam autenticação básica, falhas repetidas e utilizadores sem métodos de recuperação registados. Este diagnóstico evita que a política seja definida com base em suposições.

O resultado deve ser um plano claro: sistemas abrangidos, grupos de utilizadores, dependências técnicas, exceções justificadas, responsáveis e data de revisão de cada exceção. Uma exceção sem proprietário e prazo de validade torna-se, na prática, uma porta aberta.

2. Arquitetura: escolher fatores e políticas por risco

A arquitetura de MFA deve seguir o risco do acesso, não uma regra única para todos. Um utilizador que consulta correio eletrónico num computador gerido não apresenta o mesmo risco de um administrador que altera políticas de firewall a partir de uma ligação externa.

Uma política eficaz combina identidade, dispositivo, localização, aplicação e nível de privilégio. As políticas de acesso condicional permitem, por exemplo, exigir MFA fora da rede corporativa, bloquear autenticação legada, restringir acessos de países onde a empresa não opera e impor dispositivos conformes para aplicações que tratam informação sensível.

Para a maioria dos utilizadores, uma aplicação autenticadora com number matching oferece um bom equilíbrio entre segurança e experiência. Para administradores, direção e equipas com acesso a dados críticos, as chaves FIDO2 ou métodos sem palavra-passe devem ser a referência. Este investimento reduz a exposição ao phishing e simplifica a autenticação em equipamentos compatíveis.

Também é indispensável definir contas de emergência, frequentemente chamadas break-glass accounts. Devem ser poucas, protegidas por credenciais fortes, monitorizadas e usadas apenas quando o fornecedor de identidade ou as políticas normais impedem o acesso administrativo. Não devem servir para contornar processos nem ficar esquecidas numa folha de cálculo.

A arquitetura deve prever recuperação de acesso. Um telemóvel perdido, uma substituição de equipamento ou uma deslocação internacional não podem transformar-se numa paragem de trabalho de dois dias. Há que definir validação de identidade, passos de recuperação, tempos de resposta e quem pode autorizar o reset de métodos MFA. Este processo deve ser seguro, porque o helpdesk é um alvo habitual de engenharia social.

3. Implementação: piloto, comunicação e expansão faseada

Ativar MFA em massa sem piloto é uma forma dispendiosa de descobrir dependências. Recomendo começar por uma equipa de IT e por um grupo-piloto representativo: utilizadores de escritório, trabalhadores remotos, direção, equipas com dispositivos móveis e perfis com aplicações menos recentes.

O piloto deve testar cenários reais. Acesso a Microsoft 365, VPN, Wi-Fi empresarial, aplicações SaaS, dispositivos iOS e Android, computadores pessoais autorizados, equipamentos partilhados e recuperação de conta. Se houver integrações com RADIUS, SAML, VPN Fortinet ou Cisco, ou aplicações publicadas em cloud híbrida, estas devem ser validadas antes da expansão.

A comunicação aos utilizadores precisa de ser curta e objetiva. Deve explicar o que muda, quando muda, como registar o método de autenticação e a quem recorrer em caso de dificuldade. Mais importante: deve explicar como reconhecer pedidos fraudulentos. Um utilizador nunca deve aprovar uma notificação MFA que não iniciou. O fenómeno de fadiga do MFA baseia-se precisamente em pedidos repetidos até alguém carregar em “aprovar”.

Depois do piloto, a expansão deve ser feita por vagas, começando por utilizadores com menor dependência de sistemas legados e avançando para áreas mais críticas. As contas administrativas devem ter prioridade e ser tratadas com uma política mais exigente. Cada vaga deve ter uma janela de suporte reforçado, critérios de sucesso e capacidade de reversão limitada e documentada.

A reversão não deve significar desligar a segurança para todos. Deve permitir isolar a aplicação ou o grupo afetado, corrigir a dependência e retomar o plano. É esta disciplina que separa uma implementação controlada de uma alteração reativa.

4. Operação contínua: medir, rever e responder

O MFA não termina quando todos registam uma aplicação no telemóvel. As organizações mudam: entram colaboradores, saem administradores, surgem novas aplicações, equipamentos deixam de ser suportados e as ameaças evoluem.

A operação deve incluir revisão periódica das políticas de acesso condicional, análise de tentativas de autenticação falhadas, verificação de contas sem utilização, controlo de privilégios e validação das exceções. Deve ainda cruzar-se com gestão de dispositivos, proteção de endpoints, cópias de segurança e plano de resposta a incidentes. Um atacante que não consegue entrar pela identidade pode tentar explorar um equipamento sem atualizações ou uma conta local mal protegida.

Defina indicadores que permitam gerir o serviço: percentagem de utilizadores registados, cobertura de MFA em contas privilegiadas, número de aplicações com autenticação legada, tentativas bloqueadas por política, tempo médio de recuperação e número de exceções ativas. Estes dados transformam segurança numa disciplina mensurável, útil tanto para IT como para a direção.

Num modelo de serviços geridos, a responsabilidade deve estar explícita. Quem monitoriza alertas? Quem aprova alterações? Qual é o SLA para recuperação de acesso? Que relatórios são entregues e com que frequência? A tecnologia pode ser Microsoft, Cisco, Fortinet ou outra, mas a continuidade depende de responsabilidades operacionais claras.

Os erros que comprometem o projeto

Há quatro falhas que surgem repetidamente: deixar autenticação básica ativa, aceitar SMS como único método para acessos críticos, ignorar contas de serviço e manter exceções sem revisão. A quinta é tratar MFA como um projeto exclusivamente técnico. Sem comunicação, formação mínima e um processo de suporte bem definido, a resistência dos utilizadores aumenta e a equipa de IT acaba por criar atalhos inseguros.

Também convém evitar uma visão absolutista. MFA não substitui segmentação de rede, cópias de segurança testadas, EDR, gestão de vulnerabilidades ou princípio do menor privilégio. É uma camada essencial na defesa da identidade, mas deve integrar uma arquitetura de segurança coerente.

Na ITPOINT, a abordagem começa pelo ambiente real da empresa e pelas suas dependências operacionais, não por uma licença isolada. O objetivo é implementar controlos que a equipa consegue operar, auditar e manter dentro dos níveis de serviço acordados.

A melhor altura para testar a recuperação de uma conta privilegiada, validar uma exceção ou eliminar autenticação legada é antes de um incidente. MFA bem implementado não deve ser sentido como um obstáculo diário. Deve ser a prova discreta de que o acesso certo continua disponível para a pessoa certa, no momento certo.