Como aplicar princípios de zero trust em segurança

1. Fundamentos do modelo Zero Trust

O modelo Zero Trust parte de uma premissa radicalmente simples: nunca confie, sempre verifique. Diferente do modelo tradicional de segurança baseado em perímetro de rede — onde tudo dentro da rede corporativa era considerado confiável — o Zero Trust elimina qualquer confiança implícita, independentemente da localização do usuário ou dispositivo.

Enquanto o modelo clássico protege o "castelo com um fosso", o Zero Trust trata cada recurso como se estivesse exposto à internet. Os pilares fundamentais são:

  • Identidade: cada usuário e serviço precisa ser autenticado
  • Dispositivo: o estado de segurança do dispositivo é avaliado continuamente
  • Rede: a comunicação é restrita ao mínimo necessário
  • Dados: criptografia e classificação são obrigatórias
  • Workloads: cargas de trabalho são isoladas e verificadas

Na prática, isso significa que um administrador de rede não tem acesso automático a servidores de produção apenas por estar na VPN corporativa. Cada requisição deve ser autorizada individualmente.

2. Autenticação e verificação contínua

O primeiro passo prático é implementar autenticação multifator (MFA) como requisito mínimo. Mas o Zero Trust vai além: a verificação deve ocorrer em cada requisição, não apenas no login inicial.

Exemplo de política de token efêmero usando OAuth 2.0:

# Política de token de acesso
Tipo: Bearer Token
Duração: 15 minutos
Renovação: Permitida apenas com refresh token
Reautenticação: Obrigatória a cada 4 horas
MFA: Obrigatório para ações administrativas

Para implementar sessões de curta duração em APIs:

# Configuração de sessão para API Gateway
POST /api/auth/login
Headers:
  Authorization: Basic <credenciais>
Response:
  access_token: "eyJhbGciOiJIUzI1NiIs..."
  expires_in: 900  # 15 minutos
  refresh_token: "dGhpcyBpcyBhIHJlZnJlc2g..."

Sempre que um token expira, o sistema deve reavaliar o contexto: o dispositivo ainda está seguro? O usuário ainda tem privilégios? A localização mudou?

3. Microssegmentação de rede

A microssegmentação divide a rede em zonas isoladas por função e criticidade. Não basta ter uma VLAN para TI e outra para produção; é preciso segmentar por aplicação, camada e sensibilidade.

Exemplo de política de microssegmentação:

# Política de firewall lógico
Zona: "frontend-web"
  Permite: tráfego HTTP/HTTPS da internet
  Bloqueia: todas as conexões SSH
  Acesso à zona "api-gateway": apenas porta 443

Zona: "api-gateway"
  Permite: conexões da zona "frontend-web"
  Bloqueia: acesso direto à internet
  Acesso à zona "banco-dados": apenas porta 5432

Zona: "banco-dados"
  Permite: conexões da zona "api-gateway"
  Bloqueia: qualquer acesso administrativo direto
  Acesso: apenas via proxy com autenticação

Ferramentas como firewalls de próxima geração (NGFW) e SDN (redes definidas por software) facilitam essa implementação. O Kubernetes também oferece Network Policies nativas para microssegmentação em clusters.

4. Controle de acesso baseado em confiança dinâmica

No Zero Trust, a confiança é dinâmica e baseada em contexto. A cada requisição, o sistema avalia:

  • Localização geográfica
  • Estado do dispositivo (atualizações, antivírus)
  • Horário da requisição
  • Comportamento histórico do usuário
  • Nível de risco da ação solicitada

Exemplo de política adaptativa:

# Política de acesso condicional
IF localizacao != "escritorio_brasil" AND
   dispositivo.antivirus_atualizado == false THEN
   BLOQUEAR acesso a dados sensíveis
   EXIGIR MFA para acesso básico
   REGISTRAR evento como "risco alto"

IF usuario.tentativas_falhas > 3 IN 5 minutos THEN
   SUSPENDER conta por 30 minutos
   NOTIFICAR equipe de segurança

Essa abordagem permite que um funcionário acesse sistemas críticos do escritório sem MFA extra, mas precise de múltiplos fatores ao acessar de um café em outro país.

5. Proteção de dados e criptografia em todos os estados

Dados devem ser protegidos em três estados:

  • Em repouso: discos criptografados (AES-256)
  • Em trânsito: TLS 1.3 para todas as comunicações
  • Em uso: criptografia homomórfica ou enclaves seguros (SGX)

Exemplo de política de criptografia:

# Política de criptografia de dados
Dados em repouso:
  - Banco de dados: criptografia transparente (TDE)
  - Backups: criptografados com chave gerenciada pelo HashiCorp Vault

Dados em trânsito:
  - Comunicação interna: mTLS obrigatório
  - APIs externas: HTTPS com certificados válidos

Gerenciamento de chaves:
  - Rotação automática a cada 90 dias
  - Acesso restrito por política de mínimo privilégio
  - Auditoria de todas as operações com chaves

Ferramentas como HashiCorp Vault gerenciam segredos e chaves com políticas granulares:

# Política Vault para acesso a chaves de banco
path "database/creds/app-readonly" {
  capabilities = ["read"]
  allowed_parameters = {
    "ttl" = ["1h"]
  }
}

6. Monitoramento contínuo e resposta a incidentes

Monitoramento não é opcional no Zero Trust. É preciso coletar logs de todas as autenticações, autorizações e acessos. Ferramentas de UEBA (User and Entity Behavior Analytics) detectam anomalias com machine learning.

Exemplo de regra de detecção:

# Regra de anomalia comportamental
ALERTA: Usuário acessando sistema fora do horário padrão
  Usuário: {usuario}
  Sistema: {sistema}
  Horário: {horario} (padrão: 08:00-18:00)
  Ação: Registrar como "risco médio"
  Resposta: Exigir confirmação por e-mail

ALERTA: Múltiplas falhas de autenticação
  Contagem: >10 em 5 minutos
  Ação: Bloquear IP por 1 hora
  Notificar: SOC via SOAR

A orquestração SOAR (Security Orchestration, Automation and Response) automatiza respostas: isolar um dispositivo comprometido, revogar tokens ou bloquear um usuário suspeito.

7. Implementação prática em ambientes de desenvolvimento

Em ambientes de microsserviços, o Zero Trust se aplica a APIs e serviços internos. Um service mesh como Istio oferece autenticação mútua (mTLS) entre pods:

# Configuração Istio para mTLS entre serviços
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # Exige mTLS para toda comunicação

Para políticas de autorização, o Open Policy Agent (OPA) avalia regras em tempo real:

# Política OPA para acesso a API
package api.authz

default allow = false

allow {
  input.method == "GET"
  input.path == "/api/v1/users"
  input.user.role == "admin"
  input.user.department == "security"
}

allow {
  input.method == "POST"
  input.path == "/api/v1/reports"
  input.user.clearance_level >= 3
  input.request_time >= "08:00:00"
  input.request_time <= "18:00:00"
}

O BeyondCorp do Google é um exemplo prático de Zero Trust em escala: nenhum usuário acessa a rede interna diretamente; tudo passa por um proxy de autenticação que verifica identidade, dispositivo e contexto.

Referências