// INICIALIZANDO SISTEMA...
Falar no WhatsApp

Utilizamos cookies essenciais para o funcionamento do site. Ao continuar, você concorda com nossa Política de Privacidade e com a LGPD.

CyberZ
Fale Conosco
CyberWiki / Defesa & Hardening / Zero Trust — Nunca Confie, Sempre Verifique
● Intermediário 22 min de leitura Zero Trust IAM MFA Microsegmentação ZTNA BeyondCorp Identity SDP

Zero Trust — Nunca Confie, Sempre Verifique

Zero Trust é o modelo de segurança que substituiu o perímetro de rede. Parte do princípio que qualquer rede é potencialmente hostil — incluindo a interna. Cada acesso é verificado explicitamente, independente de onde veio. Implementado por Google (BeyondCorp), Microsoft (Azure AD) e grandes enterprises.

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 autorizado

Os 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íticos

Identidade 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ário

Microsegmentaçã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: 5432

ZTNA — 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 == true

Implementaçã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 abrangente

Mé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