Serviços que confiam uns nos outros apenas porque compartilham a mesma rede seguem sendo o caminho mais curto para movimentação lateral em ambientes de nuvem. O NIST publicou no SP 800-207A um modelo de arquitetura zero trust voltado a aplicações cloud-native distribuídas entre data centers próprios e múltiplos provedores, e a decisão prática que o documento impõe é objetiva: toda comunicação entre serviços precisa ser autenticada e autorizada com base em identidade, e não em localização de rede. Equipes que operam Kubernetes, service mesh, APIs internas ou cargas híbridas são as mais afetadas. A ação prioritária é mapear os fluxos leste-oeste do ambiente e transformar cada conexão implícita em uma política explícita com dono, identidade e justificativa.
O problema: confiança implícita na rede
O controle tradicional de acesso parte de uma premissa que não sobrevive a ambientes dinâmicos: se o pacote veio de dentro do perímetro, ele é confiável. Em plataformas de contêineres, endereços IP mudam a cada replanejamento, cargas migram entre zonas de disponibilidade e o mesmo cluster pode tocar três nuvens diferentes ao mesmo tempo. Regras baseadas em sub-rede passam a valer pouco quando a identidade real de quem origina a chamada é desconhecida. O resultado é uma superfície interna permissiva: um único workload comprometido alcança bancos de dados, filas e serviços adjacentes porque a rede inteira aceita o tráfego por padrão.
A mudança de foco defendida pelo NIST no SP 800-207A é tratar serviços como entidades com identidade própria, verificável a cada conexão. É a mesma lógica que já orienta o lado humano das organizações, em que passkeys resistentes a phishing substituem a confiança em senha por criptografia ligada a um domínio. No plano das máquinas, o equivalente é emitir credenciais curtas para cada workload e exigir autenticação mútua em toda chamada.
Duas camadas de política
O documento do NIST deixa claro que zero trust em aplicações distribuídas não é escolher entre rede e identidade, e sim operar as duas juntas. Uma arquitetura eficaz exige a combinação de políticas de camada de rede e políticas de camada de identidade, conforme detalha o texto integral da publicação. A camada de rede continua responsável por segmentação, firewalls e gateways de trânsito entre ambientes: ela define por onde o tráfego pode passar. A camada de identidade define quem pode passar e sob qual token, com decisões tomadas no momento da chamada.
Na prática, a camada de rede se materializa em ingressos e saídas de cluster, grupos de segurança e roteamento entre nuvens. A camada de identidade se materializa em gateways de API, proxies sidecar e infraestrutura de identidade de aplicação. O ponto de decisão avalia três coisas antes de liberar uma conexão: a identidade do chamador, a identidade do destino e a política que rege aquele par. Sem as duas camadas operando juntas, resta um perímetro mais fino, mas ainda um perímetro.
Identidade criptográfica com SPIFFE
Para que a camada de identidade funcione, cada workload precisa receber uma credencial que prove quem ele é sem depender de segredo compartilhado ou endereço. É o papel da SPIFFE, conjunto de padrões abertos para identificar sistemas de software em ambientes heterogêneos. A especificação emite para cada workload identidades criptográficas de curta duração chamadas SVIDs, entregues por uma API local sem necessidade de alterar o código da aplicação. O documento pode ser um certificado X.509 usado em TLS mútuo ou um JWT assinado apresentado em chamadas entre serviços.
A vantagem operacional está no ciclo de vida: como a credencial expira rápido, a rotação deixa de ser projeto e passa a ser propriedade do sistema. A emissão usa atestação do nó e da carga, ou seja, o emissor verifica o que realmente está rodando antes de entregar a identidade — um pod que se diz ser o serviço de pagamentos precisa provar que é ele. O ecossistema é maduro: SPIRE implementa o padrão completo, e projetos como Istio, Envoy e cert-manager consomem ou emitem SVIDs de forma nativa. A decisão de ferramenta é menor que a decisão de modelo: o que importa é que nenhuma chamada interna siga sem autenticação mútua verificável.
Um mesh por cluster
Com identidades emitidas, resta a questão de escala: como aplicar um conjunto uniforme de políticas quando os serviços estão espalhados por vários clusters e nuvens. A tentação é concentrar tudo em um único control plane. O NIST avalia exatamente esse cenário e recomenda o caminho oposto: rodar uma instância de control plane de service mesh por cluster ajuda a isolar domínios de falha e melhora disponibilidade e escalabilidade. Um plano de controle único transformaria múltiplos clusters em um só domínio de falha e derrotaria o propósito de uma arquitetura multi-cluster.
O modelo proposto combina um plano de controle global, que define as políticas válidas para toda a empresa, com planos locais por cluster, que as aplicam no runtime. O dado planejado pelo mesh tem valor adicional para detecção: os proxies geram telemetria de cada conexão permitida e negada, insumo que alimenta a mesma disciplina de visibilidade recomendada no padrão mínimo de logging do ENISA. Negativas de autenticação entre serviços que antes conversavam são sinal de investigação imediata: indicam credencial expirada, política mal escrita ou movimentação lateral em curso.
Checklist de implantação
| Etapa | Entregável | Verificação |
|---|---|---|
| Inventário de fluxos | Mapa de conexões leste-oeste por serviço | Nenhuma conexão sem dono declarado |
| Emissão de identidade | SVIDs para todos os workloads | Autenticação mútua ativa nas chamadas |
| Políticas por par | Regras explícitas chamador-destino | Padrão negar, exceções documentadas |
| Segmentação de rede | Gateways de entrada e saída por cluster | Tráfego só nos caminhos aprovados |
| Telemetria | Logs de conexões permitidas e negadas | Alerta para quedas de autenticação |
| Teste de ruptura | Simulação de workload comprometido | Movimentação lateral bloqueada |
Prioridades P1 e P2
Como P1, trate o que já está exposto: mapear os fluxos internos de maior risco, ativar emissão de SVIDs nos clusters de produção e transformar em política explícita as conexões que hoje dependem de rede aberta. Serviços com acesso a dados sensíveis, como bancos e filas de pagamento, entram primeiro na fila.
Como P2, entre a rotina: estender a identidade a ambientes legados, revisar exceções de política em ciclo mensal, integrar a telemetria do mesh à detecção existente e repetir o teste de ruptura após cada mudança estrutural. Zero trust de serviço é programa contínuo de engenharia, não um projeto com data de encerramento.