Zero trust na prática

O modelo antigo era um castelo com fosso: quem entrasse na VPN estava “dentro” e falava com tudo. Ele deixou de funcionar por motivos práticos — trabalho remoto, SaaS, várias nuvens, parceiros — e por um motivo estrutural: uma máquina comprometida dentro do fosso tem acesso irrestrito.

Zero trust troca a pergunta “de onde você vem?” por “quem é você, em qual dispositivo, e pode acessar exatamente este recurso, agora?” — verificada em toda requisição, e não uma vez no login.

Os princípios, sem marketing

1. Verificação explícita a cada requisição: identidade, dispositivo, contexto.
2. Menor privilégio, com acesso a um recurso específico e por tempo limitado.
3. Presumir violação: segmentar, registrar tudo, limitar o que um comprometimento alcança.

Nada disso é produto. É uma arquitetura que se adota por partes — e algumas dessas partes você provavelmente já tem.

Identidade de pessoa e de serviço

• Pessoas: um provedor de identidade único (SSO), MFA resistente a phishing (chave de segurança ou passkey), e postura do dispositivo como condição de acesso — disco criptografado, sistema atualizado, gerenciado pela empresa.
• Serviços: identidade emitida pela plataforma, de vida curta, sem chave estática. Workload Identity, IRSA, managed identity, SPIFFE, OIDC no CI — os mecanismos das páginas de identidade e segredos.

Este é o item que mais reduz risco, e o mais frequentemente adiado: eliminar credencial de longa duração, para pessoas e para máquinas.

Acesso a recurso interno sem VPN

O padrão é um proxy com reconhecimento de identidade na frente da aplicação: o usuário autentica no provedor de identidade, o proxy avalia a política e só então encaminha. A aplicação não fica exposta à internet e não precisa implementar autenticação.

# Exemplo com Cloudflare Access / IAP / Teleport — a ideia é a mesma
aplicacao: painel-interno.exemplo.com.br
politica:
  permitir:
    - grupo: [email protected]
      exigir: [mfa, dispositivo_gerenciado]
    - grupo: [email protected]
      exigir: [mfa]
      caminhos: ["/consulta/*"]     # somente leitura, caminho específico
  registrar: todas as requisições

Para acesso administrativo (SSH, kubectl, banco), o equivalente é um bastion moderno que emite certificado de curta duração por identidade e grava a sessão — em vez de distribuir chave SSH permanente. Ganha-se revogação imediata (basta remover do grupo) e auditoria por pessoa.

VPN não desaparece de um dia para o outro: ela continua útil para acesso a rede legada. A diferença é que ela deixa de ser a única barreira, e o que está atrás dela também exige identidade.

Microsegmentação

Dentro da rede, o objetivo é que cada serviço fale apenas com quem precisa. Comece pelo default de negação, que muda o jogo com pouco esforço:

# nada entra neste namespace, exceto o que for explicitamente liberado
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: negar-tudo, namespace: pagamentos }
spec: { podSelector: {}, policyTypes: [Ingress] }
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: permitir-checkout, namespace: pagamentos }
spec:
  podSelector: { matchLabels: { app: pagamento } }
  ingress:
    - from:
        - namespaceSelector: { matchLabels: { time: loja } }
          podSelector: { matchLabels: { app: checkout } }
      ports: [{ port: 8080 }]

Na nuvem, o equivalente são security groups referenciando outros security groups (em vez de faixas de IP) e políticas baseadas em identidade. Para autorização por identidade criptográfica entre serviços, o passo seguinte é mTLS — via service mesh ou SPIFFE.

Adote por etapas

A ordem que entrega valor cedo e não trava o time:

1. SSO com MFA para tudo, incluindo consoles de nuvem e ferramentas SaaS.
2. Elimine credencial estática de CI e de workloads (OIDC e identidade de workload).
3. Coloque um proxy de identidade na frente das aplicações internas mais sensíveis.
4. Acesso administrativo just-in-time, com elevação temporária e sessão registrada.
5. Segmente a rede, começando pelo namespace mais crítico com default de negação.
6. Postura de dispositivo como condição de acesso.
7. Registre e revise: log de acesso por identidade, com alerta para o anômalo.

Cada etapa tem valor sozinha — e é por isso que zero trust é um caminho, não um projeto de dois anos que termina com um botão sendo ligado. Comece pela primeira que você ainda não fez.

Próximo passo: você fechou a trilha de Redes. Aprofunde os controles em Hardening e revise o acesso à nuvem em Identidade e acesso.