Guia para arquitetura Zero Trust nas empresas

Um atacante não precisa de comprometer todo o datacenter para causar uma paragem operacional. Basta-lhe uma credencial válida, um posto de trabalho sem controlo adequado ou uma ligação entre sistemas demasiado permissiva. Este guia para arquitetura zero trust parte dessa realidade: na empresa moderna, confiar porque algo está dentro da rede deixou de ser uma política de segurança aceitável.

Zero Trust não é um produto, uma licença isolada nem uma alteração feita num fim de semana. É um modelo de decisão contínua: cada pedido de acesso deve ser validado com base na identidade, no estado do dispositivo, no contexto, no risco e no recurso solicitado. Para empresas com ambientes híbridos, utilizadores remotos, aplicações SaaS e obrigações de conformidade como a NIS2, esta mudança é sobretudo uma questão de controlo operacional.

O que uma arquitetura Zero Trust resolve na prática

A rede empresarial tradicional foi desenhada à volta de um perímetro. O utilizador entrava por VPN, autenticava-se uma vez e, em muitos casos, passava a ter visibilidade excessiva sobre servidores, partilhas e aplicações internas. Esse modelo aumenta o impacto de uma conta comprometida e facilita o movimento lateral associado a ataques de ransomware.

Numa arquitetura Zero Trust, o acesso não é concedido por localização. É concedido para uma ação específica, durante o tempo necessário e com condições verificáveis. Um colaborador que acede ao Microsoft 365 a partir de um portátil gerido não representa o mesmo risco que alguém a tentar consultar uma consola administrativa a partir de um equipamento pessoal, num país inesperado ou sem autenticação multifator.

O resultado pretendido não é criar fricção indiscriminada. É reduzir a superfície de ataque sem impedir as equipas de trabalhar. Esta distinção é decisiva: segurança que bloqueia processos críticos acaba por ser contornada; segurança bem arquitetada torna o acesso legítimo previsível e torna o acesso anómalo difícil de explorar.

Os princípios de uma arquitetura zero trust

A base é simples: verificar explicitamente, aplicar privilégio mínimo e assumir possibilidade de violação. Na execução, estes princípios exigem várias camadas técnicas que têm de funcionar em conjunto.

A identidade passa a ser o principal perímetro. Cada utilizador, administrador, serviço e aplicação deve ter uma identidade controlada, autenticação forte e permissões ajustadas à sua função. A autenticação multifator é obrigatória para acessos sensíveis, mas não resolve tudo. É necessário aplicar políticas de acesso condicional que avaliem sinais como localização, risco de sessão, tipo de dispositivo e sensibilidade da aplicação.

O dispositivo também conta. Um portátil com sistema operativo desatualizado, sem cifragem, sem proteção de endpoint ou fora da gestão central não deve receber o mesmo nível de acesso que um equipamento empresarial em conformidade. Ferramentas de gestão de endpoints e EDR permitem validar esse estado antes de conceder acesso e reagir quando surgem indicadores de compromisso.

A segmentação limita a propagação de um incidente. Em vez de uma rede plana onde muitos sistemas comunicam por defeito, os servidores, aplicações, postos de trabalho e ambientes de gestão devem comunicar apenas quando existe uma necessidade identificada. Esta microsegmentação pode ser feita na rede, no datacenter, na cloud ou ao nível da aplicação. O desenho certo depende da arquitetura existente e da criticidade dos serviços.

Por fim, é preciso proteger os dados, não apenas os sistemas onde residem. Classificar informação, cifrar dados sensíveis, controlar a sua partilha e registar acessos são medidas fundamentais. Em alguns contextos, políticas de prevenção de perda de dados fazem sentido. Noutros, a prioridade inicial é saber onde estão os dados críticos e quem lhes acede. Não vale a pena implementar controlos avançados sobre informação que a organização ainda não consegue identificar.

Como construir uma arquitetura Zero Trust sem parar a operação

O erro mais comum é comprar várias plataformas de segurança antes de definir prioridades, responsabilidades e fluxos de acesso. O resultado costuma ser custo elevado, alertas sem tratamento e utilizadores frustrados. Uma implementação sustentável começa pelo risco real e evolui por fases.

1. Diagnóstico de identidades, acessos e ativos

O primeiro passo é mapear quem acede a quê, a partir de onde e com que privilégios. Isto inclui colaboradores, fornecedores, contas de serviço, administradores, aplicações legadas e equipamentos de rede. As contas privilegiadas merecem atenção especial: uma conta de administração partilhada ou sem MFA pode anular grande parte do investimento feito noutros controlos.

Neste diagnóstico, também convém identificar ativos sem gestão, sistemas fora de suporte, aplicações expostas à internet e ligações entre redes que existem apenas por herança histórica. O objetivo não é produzir documentação para ficheiro. É estabelecer uma linha de base que permita decidir o que corrigir primeiro e medir evolução.

2. Arquitetura orientada à criticidade

Nem todas as aplicações justificam o mesmo nível de controlo no primeiro momento. Sistemas financeiros, plataformas de produção, dados pessoais, backup e consolas de administração devem estar no topo das prioridades. Para estes recursos, a arquitetura deve prever MFA resistente a phishing quando aplicável, acesso privilegiado just-in-time, dispositivos conformes, segmentação e registo detalhado.

A escolha entre tecnologias também depende do contexto. Uma empresa com Microsoft 365 e endpoints Windows pode tirar partido de uma integração forte entre gestão de identidade, acesso condicional e gestão de dispositivos. Uma organização com vários datacenters, workloads em cloud e tráfego complexo poderá precisar de reforçar a segmentação, o controlo de acesso à rede e a proteção de aplicações. Não existe uma lista universal de produtos que, por si só, crie Zero Trust.

A arquitetura deve ainda definir exceções. Há equipamentos industriais, aplicações antigas ou integrações de parceiros que não suportam autenticação moderna. Estas situações não devem ser ignoradas nem receber uma dispensa permanente. Devem ser isoladas, monitorizadas e incluídas num plano de substituição ou mitigação com responsável e prazo.

3. Implementação faseada e validada

Uma política demasiado restritiva aplicada a toda a organização pode interromper autenticações, integrações e processos de negócio. Por isso, a implementação deve começar com grupos-piloto, aplicações selecionadas e critérios de sucesso claros. Primeiro observa-se o comportamento, depois corrige-se o que for necessário e só então se aplica a política em produção mais ampla.

Uma sequência prática inclui quatro frentes de trabalho:

• reforçar a identidade com MFA, remoção de protocolos antigos e revisão de privilégios;
• colocar os dispositivos sob gestão, com cifragem, atualizações e proteção de endpoint verificáveis;
• restringir o acesso às aplicações e redes críticas com políticas contextuais e segmentação;
• centralizar logs, alertas e procedimentos de resposta para que as equipas consigam agir dentro do SLA definido.

Cada alteração deve ter dono, janela de implementação, plano de reversão e evidência de validação. É assim que a segurança deixa de ser um conjunto de boas intenções e passa a fazer parte da governança ativa da infraestrutura.

4. Operação contínua, não projeto encerrado

O risco muda quando entra um novo colaborador, surge uma aplicação SaaS, um fornecedor recebe acesso remoto ou um dispositivo deixa de cumprir políticas. Por isso, Zero Trust exige operação contínua: rever privilégios, tratar vulnerabilidades, analisar eventos, ajustar regras e testar a recuperação perante incidentes.

A monitorização 24/7 pode ser necessária para organizações expostas a serviços críticos ou requisitos elevados de continuidade. Noutras empresas, uma cobertura em horário alargado combinada com procedimentos de escalamento bem definidos será suficiente. O critério deve ser o impacto operacional e o RTO/RPO exigido pelo negócio, não uma configuração padrão.

Métricas que demonstram controlo e não apenas atividade

Uma arquitetura Zero Trust deve ser avaliada por resultados mensuráveis. O número de licenças adquiridas ou de políticas criadas não prova redução de risco. Faz mais sentido acompanhar a percentagem de contas com MFA, o número de utilizadores com privilégios administrativos permanentes, a conformidade dos endpoints, o tempo de revogação de acessos e a quantidade de sistemas críticos segmentados.

Também vale a pena medir tempos de deteção e resposta, falhas de autenticação anómalas, tentativas de acesso bloqueadas e sucesso dos testes de recuperação. Estes indicadores ajudam o CIO, o responsável de segurança e a direção financeira a perceber onde existe risco residual, qual o custo total de propriedade dos controlos e onde o investimento seguinte terá maior efeito.

A conformidade NIS2 reforça esta necessidade de evidência. A diretiva não se resume a instalar ferramentas: exige medidas de gestão de risco, resposta a incidentes, continuidade, controlo da cadeia de fornecimento e responsabilização. Uma arquitetura Zero Trust bem operada apoia estes objetivos porque transforma acesso, dispositivos e eventos em controlos verificáveis.

Onde as empresas falham mais vezes

A falha mais frequente é tratar Zero Trust como um projeto exclusivo de cibersegurança. Sem envolvimento das equipas de infraestrutura, workplace, aplicações, RH e responsáveis de negócio, as políticas não refletem os processos reais. A segunda é esquecer as contas de serviço, que muitas vezes mantêm permissões amplas durante anos. A terceira é implementar MFA e declarar o trabalho concluído, deixando redes planas, sistemas legados e privilégios excessivos intactos.

Há ainda uma decisão de gestão: quem responde quando um controlo bloqueia um acesso crítico? Sem responsabilidades operacionais, contactos de escalamento e SLA contratual, até uma boa arquitetura perde eficácia no momento em que é mais necessária.

Zero Trust não significa desconfiar das pessoas. Significa não depender de confiança implícita para proteger a operação. Comece pelos acessos que poderiam parar o negócio amanhã, trate as exceções como risco a gerir e mantenha o controlo vivo todos os dias.