Revisado em por Roberto Lima
Neste artigo
O que e Zero Trust Architecture
Zero Trust e um modelo de segurança que elimina a confiança implícita em qualquer elemento dentro ou fora do perímetro da rede. Em vez de assumir que tudo dentro da rede corporativa e seguro, Zero Trust exige verificação continua de cada usuário, dispositivo e conexão antes de conceder acesso a recursos.
O conceito foi introduzido por John Kindervag, analista da Forrester Research, em 2010, mas ganhou adoção massiva após 2020 com o aumento do trabalho remoto e a dissolucao do perímetro tradicional. Segundo o Gartner, até 2025, 60% das organizações adotarao Zero Trust como ponto de partida para segurança, contra menos de 10% em 2021.
Princípios Fundamentais do Zero Trust
1. Verificação explícita
Sempre autenticar e autorizar com base em todos os dados disponíveis: identidade do usuário, localização, saúde do dispositivo, serviço ou carga de trabalho, classificação de dados e anomalias.
2. Acesso com mínimo privilégio
Limitar o acesso do usuário ao mínimo necessário com Just-In-Time (JIT) e Just-Enough-Access (JEA). Isso minimiza o raio de explosão em caso de comprometimento. Não ha mais "acesso total a rede" - apenas acesso específico ao recurso necessário.
3. Assumir violação (Assume Breach)
Operar como se um atacante já estivesse dentro do ambiente. Isso direciona investimentos para detecção, resposta a incidentes, microsegmentacao e criptografia end-to-end. O objetivo não e apenas prevenir, mas limitar o impacto quando (não se) um breach ocorrer.
Siglas como ZTA, MFA, SSO, PAM, EDR, XDR e outras são explicadas no nosso glossário de acrônimos de TI e SI.
Os 5 Pilares do Zero Trust
O modelo Zero Trust se estrutura em cinco pilares que devem ser protegidos e verificados continuamente:
1. Identidade
Usuários, service accounts e credenciais de máquinas. A identidade e o novo perímetro de segurança.
- Autenticação forte (MFA obrigatório)
- Single Sign-On (SSO) com provedores seguros
- Gestão de identidades privilegiadas (PAM)
- Autenticação baseada em risco (comportamento, localização)
- Identidades verificadas para workloads e APIs
2. Dispositivos
Endpoints, servidores, dispositivos IoT - gerenciados e não-gerenciados (BYOD).
- Inventário completo de dispositivos
- Verificação de compliance e postura de segurança
- EDR/XDR para detecção e resposta
- Isolamento de dispositivos não-conformes
- Políticas diferenciadas por nível de confiança do device
3. Rede
Segmentação, criptografia e controle de fluxo de tráfego.
- Microsegmentacao (cada workload isolado)
- Criptografia de todos os fluxos (TLS everywhere)
- Software-Defined Perimeter (SDP)
- Eliminação de movimentação lateral
- Network Detection and Response (NDR)
4. Aplicações e Workloads
Aplicações on-premises, cloud, SaaS e APIs.
- Acesso condicional baseado em contexto
- Proteção de APIs (autenticação, rate limiting)
- Segurança de containers e Kubernetes
- CASB para aplicações SaaS
- Monitoramento contínuo de comportamento
5. Dados
O ativo mais crítico - dados em repouso, em trânsito e em uso.
- Classificação e rotulagem de dados
- Criptografia em repouso e trânsito
- Data Loss Prevention (DLP)
- Rights Management (IRM)
- Auditoria de acesso a dados sensíveis
Zero Trust vs Segurança Tradicional
| Aspecto | Modelo Tradicional (Perímetro) | Zero Trust |
|---|---|---|
| Filosofia | "Confie, mas verifique" | "Nunca confie, sempre verifique" |
| Perímetro | Rede corporativa e o limite | Identidade e o novo perímetro |
| Acesso interno | Confiável por padrão | Verificado igual ao externo |
| VPN | Acesso total a rede | Acesso apenas ao recurso específico |
| Segmentação | Macro (VLANs) | Micro (por workload/aplicação) |
| Movimentação lateral | Fácil após comprometimento | Extremamente limitada |
| Trabalho remoto | Depende de VPN para rede | Acesso direto e seguro a recursos |
Por que o modelo tradicional falha
O modelo de perímetro assume que ameaças vem de fora. Mas 34% dos breaches envolvem atores internos (Verizon DBIR 2025), e atacantes que ultrapassam o perímetro (via phishing, por exemplo) tem movimentação livre. Com cloud, SaaS e trabalho remoto, o perímetro tradicional deixou de existir.
Framework NIST Zero Trust (SP 800-207)
O NIST publicou o Special Publication 800-207 como referência para implementação de Zero Trust Architecture. O documento define componentes logicos e modelos de deployment.
Componentes logicos do NIST ZTA
- Policy Engine (PE): Toma decisões de acesso baseadas em políticas
- Policy Administrator (PA): Executa as decisões do PE, estabelecendo/removendo sessões
- Policy Enforcement Point (PEP): Ponto de controle que aplica as decisões de acesso
Modelos de deployment
- Device Agent/Gateway: Agente no dispositivo comunica com gateway para acesso
- Enclave Gateway: Gateway protege recursos em enclave específico
- Resource Portal: Portal web media acesso a recursos (comum para SaaS)
- Sandboxing: Recursos executados em ambiente isolado
Implementação Passo a Passo
Zero Trust não e um produto - e uma jornada. Implementação gradual e essencial para sucesso.
Descoberta e Avaliação
- Mapear todos os ativos: usuários, dispositivos, aplicações, dados
- Identificar fluxos de dados e dependências
- Avaliar maturidade atual dos controles
- Definir "protect surfaces" (recursos mais críticos)
- Identificar gaps em relação aos pilares
Fortalecer Identidade
- Implementar MFA em todas as contas (priorizar admin)
- Consolidar identidades em IdP centralizado
- Implementar SSO para aplicações
- Configurar acesso condicional baseado em risco
- Revisar e reduzir privilégios excessivos
Essa fase sozinha bloqueia a maioria dos ataques baseados em credenciais.
Proteger Dispositivos
- Implantar EDR em todos os endpoints
- Implementar device compliance checks
- Definir políticas para BYOD e dispositivos móveis
- Integrar postura do dispositivo nas decisões de acesso
Segmentar Rede
- Implementar microsegmentacao em ambientes críticos
- Substituir VPN tradicional por ZTNA
- Criptografar tráfego interno (TLS everywhere)
- Implementar monitoramento de rede (NDR)
Proteger Aplicações e Dados
- Implementar CASB para SaaS
- Classificar dados e aplicar DLP
- Proteger APIs com autenticação e rate limiting
- Monitorar acesso a dados sensíveis
Orquestrar e Automatizar
- Integrar fontes de telemetria em SIEM/XDR
- Implementar SOAR para resposta automatizada
- Criar playbooks para cenários comuns
- Medir e reportar métricas de Zero Trust
- Iterar e expandir cobertura
Tecnologias Habilitadoras
Identity and Access Management (IAM)
- IdP: Azure AD, Okta, Ping Identity
- MFA: Microsoft Authenticator, Duo, YubiKey
- PAM: CyberArk, BeyondTrust, Delinea
Zero Trust Network Access (ZTNA)
- SASE: Zscaler, Palo Alto Prisma, Cloudflare Access
- SDP: Appgate, Perimeter 81
Endpoint e Workload
- EDR/XDR: CrowdStrike, SentinelOne, Microsoft Defender
- Microsegmentacao: Illumio, Guardicore, VMware NSX
Dados e Aplicações
- CASB: Netskope, Microsoft Defender for Cloud Apps
- DLP: Symantec, Digital Guardian, Microsoft Purview
Dica prática: Não tente implementar tudo de uma vez. Comece pela identidade (MFA e SSO) - isso oferece o maior retorno sobre investimento. Em seguida, enderece os ativos mais críticos e expanda gradualmente.
Precisa de Ajuda com Zero Trust?
Oferecemos assessment de maturidade, roadmap de implementação e suporte na jornada Zero Trust.
Falar com EspecialistaPerguntas Frequentes
Não. PMEs podem adotar Zero Trust de forma pragmatica, começando com controles essenciais: MFA em todas as contas, SSO com provedores cloud, EDR nos endpoints, e ZTNA no lugar de VPN tradicional. Muitas soluções cloud-native tem custo acessível e escalam conforme necessidade.
Zero Trust e uma jornada continua, não um projeto com fim. Implementacoes iniciais (identidade + endpoints) podem ser concluidas em 3-6 meses. Maturidade avançada (microsegmentacao, automação) geralmente leva 2-3 anos. O importante e começar e iterar.
Quando bem implementado, a experiência pode até melhorar. SSO reduz número de senhas. MFA com push notification e mais simples que tokens físicos. ZTNA elimina fricao de VPN. O segredo e usar autenticação baseada em risco: solicitar verificação adicional apenas quando o contexto exigir.
