Uma startup de quinze engenheiros com quem trabalhei recentemente decidiu adotar Zero Trust depois que um pentest encontrou três caminhos de movimentação lateral a partir de uma máquina comprometida no staging. A leitura inicial da liderança foi que precisavam contratar ZTNA de um vendor conhecido, com cotação que cobria licenciamento pra oitenta usuários e seis meses de integração de microssegmentação. O orçamento anual de segurança era menor que a primeira parcela da proposta. Na minha avaliação, a conversa só virou produtiva quando ficou claro que Zero Trust não é o produto do vendor, mas um modelo de design, e que os três caminhos do pentest existiam porque a confiança implícita da rede interna nunca tinha sido questionada.
Zero Trust, como descrito no NIST SP 800-207 de 2020 (com o SP 800-207A de 2023 estendendo o tema pra ambientes cloud-native), é um conjunto de princípios arquiteturais que antecede qualquer tecnologia específica. O documento define sete princípios centrais, dos quais dois carregam o peso da decisão de design: toda requisição de acesso deve ser autenticada e autorizada antes da sessão ser estabelecida, com autorização dinâmica que avalia continuamente a confiança na identidade e no dispositivo. A rede é sempre hostil, inclusive a interna, e a decisão de permitir acesso é feita por requisição contra um policy engine com contexto atualizado.
Pra mim, o equívoco operacional mais comum em times enxutos é confundir Zero Trust com ZTNA. Zero Trust Network Access é uma categoria de produto que substitui VPNs tradicionais por brokers de acesso baseados em identidade, e representa uma fatia da arquitetura. Uma implementação mínima viável pra um time de quinze a cinquenta pessoas parte da identidade como perímetro e avança até a autorização contextual em cada recurso crítico, passando pela avaliação do dispositivo, sem precisar trocar o stack de rede. Essa sequência reaproveita infraestrutura que a maioria já possui: provedor de identidade (Google Workspace, Entra ID, Okta), MDM (Jamf, Intune, Kandji) e aplicações que suportem SSO via SAML ou OIDC. A parte arquitetural é decidir que nenhum recurso interno fica acessível sem identidade autenticada com MFA contra dispositivo conhecido, com avaliação de política no momento da requisição.
O primeiro movimento concreto é eliminar acessos que dependem apenas de estar dentro da rede. Painéis administrativos expostos por IP interno, bancos acessíveis a partir de qualquer workstation na VPN, CI/CD que confia em cookies de sessão longa, staging sem autenticação porque "só dev acessa": cada um desses pontos é uma aposta na confiança implícita. A substituição passa por colocar os recursos atrás de um proxy autenticado com SSO, de forma que a sessão exija reautenticação periódica e validação de contexto. Cloudflare Access e Pomerium, proxies de acesso autenticado baseados em identidade, oferecem essa camada com custo proporcional ao time. O ganho consiste em remover a suposição de que estar dentro da VPN concede acesso a qualquer coisa.
A segunda camada é device posture. A autorização contextual depende de saber se o dispositivo que faz a requisição é gerenciado pela política mínima de segurança. Em times enxutos, isso significa decidir quais sinais são observáveis e suficientes (versão do sistema operacional, criptografia de disco ativa, antivírus em execução, ausência de jailbreak ou root). O nível de sofisticação escala com a maturidade, mas a decisão arquitetural é binária. Ou a política consulta o estado do dispositivo, ou não consulta, e nesse segundo caso a arquitetura é Zero Trust apenas no nome. Provedores de identidade modernos já expõem esses sinais via MDM, e a política deixa de ser estática pra virar função do estado observado.
A terceira camada é a segmentação do que continua acessível dentro da rede. Produção e desenvolvimento não devem compartilhar o mesmo plano de rede, credenciais de banco não devem ser acessíveis a partir de workstations fora de um bastion controlado, e serviços internos que conversam entre si devem fazê-lo com mTLS ou tokens de serviço, nunca por origem de IP. Service mesh como Istio ou Linkerd resolve isso em Kubernetes, mas a decisão de design precede a escolha da ferramenta. Em arquiteturas mais simples, o mesmo efeito sai com WireGuard segmentado por role e security groups bem desenhados. O ponto recai sobre a eliminação da confiança por adjacência de rede.
Os trade-offs são previsíveis. A experiência do usuário piora no primeiro trimestre, porque prompts de reautenticação aparecem onde antes havia sessão permanente, e dispositivos pessoais que acessavam tudo passam a ser bloqueados por não atenderem device posture. O custo operacional sobe, porque a manutenção da política vira trabalho contínuo. O benefício aparece no próximo pentest, quando os caminhos de movimentação lateral que existiam por confiança implícita deixaram de estar disponíveis, independentemente de novas vulnerabilidades descobertas no ambiente.
A relação com ISO 27001 é direta. Os controles do Anexo A relacionados a gestão de identidade, controle de acesso e segurança de endpoints descrevem os componentes que Zero Trust organiza em uma arquitetura coerente. Uma implementação bem feita simplifica auditoria, porque a lógica de autorização deixa de estar espalhada em configurações pontuais e passa a concentrar-se em um policy engine auditável. A norma descreve controles, a arquitetura descreve como eles se conectam em um modelo de confiança. Sem o modelo, os controles funcionam isoladamente e deixam lacunas que só aparecem sob pressão real. Times enxutos que começam pela decisão arquitetural, antes da compra de produto, terminam com segurança proporcional ao risco. E entregam ao auditor uma narrativa que se sustenta sem precisar inflar.