Por que o Perímetro Morreu
O modelo tradicional de firewall ('confiar em tudo dentro da rede') falhou. Com cloud, BYOD, trabalho remoto e ataques de movimentação lateral, não existe mais 'dentro' seguro. Um atacante que entra uma vez pela VPN tem acesso a tudo — como o ataque à SolarWinds demonstrou.
Modelo tradicional:
[Internet] → [Firewall] → [Rede Interna = confiança total]
Um compromisso = acesso a tudo
Zero Trust:
[Qualquer rede] → [Verificação explícita por request]
Um compromisso = acesso limitado ao que foi autorizadoOs 5 Pilares do Zero Trust (NIST SP 800-207)
1. IDENTIDADE
- Todo acesso baseado em identidade verificada
- MFA obrigatório para todos os usuários
- Contas de serviço com credenciais rotativas
- Privileged Access Management (PAM)
2. DISPOSITIVO
- Verificar postura do dispositivo antes de conceder acesso
- É gerenciado? Tem EDR? Está atualizado? Tem criptografia?
- Device Compliance via MDM (Intune, Jamf)
- Certificados de dispositivo como fator de autenticação
3. REDE
- Microsegmentação: cada workload isolado
- Software-Defined Perimeter (SDP)
- ZTNA em vez de VPN
- Tráfego L-L (lateral) inspecionado como externo
4. APLICAÇÃO
- Acesso por aplicativo, não por rede
- Single Sign-On + MFA por aplicativo
- Autorização granular (RBAC, ABAC)
- Sessões com tempo limitado e revalidação
5. DADOS
- Classificação e rotulagem de dados
- Criptografia em repouso e em trânsito
- DLP para prevenir exfiltração
- Acesso just-in-time para dados críticosIdentidade como Novo Perímetro
# MFA — Hierarquia de segurança:
SMS OTP — fraco (SIM swap, SS7)
TOTP (Google Authenticator)— bom, mas vulnerável a phishing AiTM
Push Notification — sujeito a MFA fatigue
FIDO2 / Passkeys — melhor: vinculado ao domínio, imune a AiTM
Chave de hardware (YubiKey)— máximo para contas críticas
# Conditional Access (Microsoft Entra ID / Azure AD)
# Política: bloquear acesso se dispositivo não compliance
if (user == "admin" AND device.compliant == false) {
block_access()
} else if (location.risk == "high") {
require_mfa()
} else if (sign_in_risk == "medium") {
require_mfa() AND block_legacy_auth()
}
# Privileged Identity Management (PIM)
# Admins não têm privilégio constante
# Solicitar elevação → aprovação → janela de tempo → revogação automática
just_in_time_access(role="Global Admin", duration="1h", justification="Urgente")
# Identity Governance
# Revisões periódicas de acesso (quem tem acesso a quê)
# Remoção automática de acesso ao desligar funcionárioMicrosegmentação de Rede
# Segmentação tradicional: VLANs grandes
[VLAN Servidores] = todos os servidores conversam entre si
# Um comprometimento → movimentação lateral livre
# Microsegmentação: isolamento por workload
# Cada aplicação em seu próprio segmento
# Firewall entre todos os workloads (East-West)
# Exemplo com AWS Security Groups:
# App tier SG: permite apenas do LB SG na porta 8080
# DB tier SG: permite apenas do App SG na porta 5432
# Nenhum tráfego direto Internet → DB
# VMware NSX / Illumio / Guardicore
# Visualização de todos os fluxos de rede
# Aplicar políticas de microsegmentação baseadas em identidade da VM
# Kubernetes Network Policies
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-policy
spec:
podSelector:
matchLabels: {app: database}
policyTypes: [Ingress]
ingress:
- from:
- podSelector:
matchLabels: {app: backend}
ports:
- protocol: TCP
port: 5432ZTNA — Zero Trust Network Access
# Substitui VPN tradicional
# VPN: acesso à rede inteira
# ZTNA: acesso apenas à aplicação específica autorizada
# Como funciona:
1. Usuário tenta acessar app interno
2. ZTNA Client verifica: identidade + dispositivo + contexto
3. Túnel criptografado criado APENAS para aquela aplicação
4. Aplicação nunca exposta diretamente na internet
5. Log de cada acesso, sessão e ação
# Soluções populares:
# Cloudflare Access / WARP (excelente custo-benefício)
# Zscaler Private Access (ZPA)
# Palo Alto Prisma Access
# Google BeyondCorp Enterprise
# Tailscale (simples, baseado em WireGuard)
# Cloudflare Access — configuração básica:
# 1. Instalar cloudflared no servidor interno
cloudflared tunnel create meu-app
cloudflared tunnel route dns meu-app app.empresa.com
# 2. Configurar política de acesso no dashboard:
# Grupo: [email protected]
# Requer: device_posture.compliant == true
# Requer: identity.mfa_verified == trueImplementação Progressiva
Fase 1 — Identidade (0-3 meses)
- MFA para todos (começar com aplicações críticas)
- SSO centralizado
- Inventário de contas privilegiadas
- Disable legacy authentication
Fase 2 — Dispositivo (3-6 meses)
- MDM para todos os dispositivos
- Conditional Access baseado em compliance
- EDR em todos os endpoints
Fase 3 — Rede (6-12 meses)
- ZTNA substituindo VPN
- Microsegmentação dos workloads críticos
- Inspeção de tráfego E-W
Fase 4 — Dados (12+ meses)
- Classificação e rotulagem
- DLP
- Acesso JIT para dados sensíveis
- Criptografia abrangenteMétricas de Zero Trust
- MFA Coverage — % de usuários com MFA ativo (meta: 100%)
- Device Compliance Rate — % de dispositivos gerenciados e conformes
- Lateral Movement Blocked — tentativas de tráfego E-W bloqueadas por microsegmentação
- Privileged Access JIT Rate — % de acesso privilegiado via JIT vs permanente
- Mean Time to Detect — tempo médio para detectar comprometimento de conta
Quer testar isso na prática?
A CyberZ realiza testes autorizados de segurança usando as técnicas descritas neste artigo — e muito mais. Identifique suas vulnerabilidades antes que os invasores o façam.
Falar com Especialista