Confiança zero como a última linha de defesa

A velocidade com que novas funcionalidades são adicionadas e as aplicações evoluem aumenta diretamente a complexidade da arquitetura. Esse ritmo incessante não é motivado apenas pelo desejo de novas funcionalidades; ele é cada vez mais impulsionado pela constante descoberta de novas vulnerabilidades. Aplicar patches em uma única dependência crítica pode acionar uma cascata de atualizações necessárias e mudanças inesperadas na arquitetura, já que cada produto e solução oferece inúmeras opções de implementação e vários recursos para ativar ou desativar. Adaptar essa complexidade ao seu ambiente específico dificulta garantir que cada componente seja implantado de acordo com as práticas recomendadas do setor. Padrões validados preenchem essa lacuna ao oferecer padrões de implantação testados e prontos para uso em vários casos de uso, reduzindo a necessidade de criar do zero arquiteturas complexas e focadas em segurança.

A desconfortável verdade sobre gerenciar vulnerabilidades

Em 2025, foram publicados mais de 40.000 novos CVEs. Isso representa mais de 100 por dia. Atualmente, a geração de exploits por IA está acelerando drasticamente o tempo entre a divulgação de uma vulnerabilidade e a exploração ativa no ambiente real. "Em busca do Santo Graal" mostra como buscar a pontuação perfeita de zero CVEs pode ser contraproducente se desviar a atenção de estratégias de defesa em profundidade mais abrangentes. Um componente que está "limpo" às 09h00 pode apresentar uma vulnerabilidade recém-divulgada às 17h00. Mesmo quando você atinge zero CVEs conhecidos, vulnerabilidades desconhecidas sempre permanecem.

A matemática da aplicação de patches (a ideia equivocada de que a segurança é apenas um jogo de números em que menos CVEs significam menos riscos) simplesmente não fecha para ambientes empresariais que executam centenas de cargas de trabalho em containers. Diferente das arquiteturas monolíticas tradicionais executadas em um único sistema operacional, os ambientes de containers distribuídos apresentam uma complexidade de arquitetura significativamente maior. Inúmeros microsserviços e pontos de contato de rede oferecem muito mais opções de configuração, onde algo pode falhar e criar uma brecha de segurança inadvertidamente. Tentar corrigir absolutamente tudo de forma instantânea é uma tarefa de Sísifo que conflita com uma estratégia de segurança moderna e baseada em riscos. Isso também ignora uma verdade fundamental: não importa o quão agressivamente você tente aplicar as atualizações, sempre haverá um atraso.

Portanto, o que fazer no intervalo entre a divulgação da vulnerabilidade e a implantação do patch? A resposta está em um princípio de segurança que existe há anos, mas que é mais crítico hoje do que nunca: Arquitetura de confiança zero.

O que a confiança zero significa para seu cluster do Red Hat OpenShift

Confiança zero não é um produto que você instala. É uma filosofia de arquitetura que pressupõe que uma violação já ocorreu, exigindo que toda interação seja explicitamente verificada e autorizada. De acordo com o NIST SP 800-207, confiança zero significa remover a confiança implícita concedida a recursos (ativos, aplicações ou contas de usuário) com base apenas em sua localização física ou de rede. Autenticação e autorização são funções distintas executadas antes do estabelecimento de qualquer sessão em um recurso empresarial.

A implementação da confiança zero no Kubernetes e no Red Hat OpenShift exige uma abordagem em várias camadas que abrange a identidade da carga de trabalho, o gerenciamento de segredos e o controle de acesso ao runtime. Especificamente no domínio da rede, uma das implicações mais críticas dessa filosofia é ir além da postura de rede plana padrão, em que cada pod pode se comunicar livremente. Por padrão, o Kubernetes não aplica restrições de rede interna, o que equivale a deixar todas as portas internas de um edifício destrancadas apenas porque ele tem um portão principal (como um controlador de entrada de cluster, gateway de API ou firewall de perímetro). No entanto, confiar apenas nessa defesa de perímetro é fundamentalmente insuficiente para ambientes nativos em nuvem modernos.

De acordo com o modelo de confiança zero, supomos que uma violação já ocorreu e que agentes mal-intencionados já estão no ambiente, sejam eles invasores externos que contornaram o perímetro, um componente comprometido da cadeia de suprimentos ou ameaças internas maliciosas operando diretamente de dentro. Ao implementar restrições de recursos de rede do Kubernetes, criamos uma conexão de rede com negação padrão com autenticação e autorização explícitas para utilizar a rede e acessar outros recursos conectados a ela (Figura 1).

Da teoria à prática: o padrão validado de confiança zero em camadas (ZTVP)

Para transformar essas práticas recomendadas em realidade, usamos o Layered Zero Trust Validated Pattern (ZTVP). Um padrão validado incorpora as práticas recomendadas de infraestrutura como código (IaC) e automação de GitOps, reduzindo drasticamente o tempo de configuração de implantações complexas do OpenShift projetadas para segurança e escalabilidade. Nos últimos três meses, o projeto ZTVP avançou significativamente, conquistando a certificação Tested Tier.

O padrão reúne vários componentes em uma arquitetura de confiança zero coesa e implantada via GitOps:

• Gerenciador de identidades de cargas de trabalho de confiança zero: fornece identidades criptográficas de curta duração para cargas de trabalho, com base no projeto SPIFFE/SPIRE.
• HashiCorp Vault: armazena ativos confidenciais e segredos de cluster priorizando a segurança, integrados ao ZTWIM para autenticação JWT.
• Red Hat build of Keycloak: gerencia a autenticação de usuários e a identidade federada.
• Red Hat Advanced Cluster Security for Kubernetes: atua como o núcleo de segurança inteligente, fornecendo monitoramento multicluster unificado, controle de admissão proativo, detecção de anomalias comportamentais em tempo real e, crucialmente em nosso exemplo, um analisador de políticas de rede.

Políticas de rede: a última linha de defesa

Embora as políticas de rede sejam frequentemente discutidas como uma base da confiança zero, elas não são um princípio em si. Em vez disso, elas são um mecanismo de arquitetura proativo usado para aplicar os resultados desejados de um modelo de confiança zero. A Red Hat descreve quatro princípios básicos de confiança zero, e políticas de rede bem projetadas apoiam ativamente cada um deles:

• Microsegmentação: ao controlar o tráfego no nível do pod individual, as políticas de rede dividem inerentemente o cluster em segmentos granulares e com segurança aprimorada.
• Acesso com privilégios mínimos: uma postura de negação padrão garante que as cargas de trabalho recebam apenas as permissões de rede exatas de que realmente precisam para funcionar.
• Desperimetralização: os controles de segurança são deslocados da "porta da frente" do cluster e aplicados diretamente às próprias cargas de trabalho.
• Considere a violação: ao eliminar proativamente caminhos de ataque laterais, regras rígidas de entrada e saída já estão em vigor para conter o raio de explosão no momento em que ocorre um comprometimento.

Além disso, um aspecto extremamente importante das políticas de rede do Kubernetes é que elas existem em um plano de controle separado dos pods de aplicações que protegem. Isso significa que, mesmo que um invasor consiga violar um container e obter privilégios elevados nessa aplicação, ele não poderá simplesmente redefinir ou ignorar os limites de rede que o restringem. Para aprimorar a postura geral de segurança do ambiente interno e realmente colocar esses princípios em prática, precisamos definir políticas de rede granulares que controlem o tráfego de entrada e saída no nível do pod:

• Políticas de entrada: controlam o tráfego de entrada para um pod, impondo uma regra de que um serviço só aceita conexões de fontes explicitamente autorizadas. Se um pod vizinho no cluster for comprometido, uma política de entrada forte impedirá que o invasor acesse suas cargas de trabalho confidenciais lateralmente.
• Políticas de saída: controlam o tráfego de saída de um pod. O objetivo delas é limitar rigorosamente quais recursos externos ou internos um pod pode alcançar. Se um pod for comprometido, as políticas de saída neutralizam a capacidade de um invasor de exfiltrar dados, realizar amplo reconhecimento de rede ou baixar payloads maliciosos de servidores externos de comando e controle.

A base de negação padrão

Embora a definição de regras específicas de entrada e saída seja crucial, basear-se apenas nelas deixa uma lacuna perigosa, permitindo erros humanos e ataques enganosos. Por padrão, o Kubernetes opera em um modelo de permissão total, o que significa que qualquer tráfego não restrito é explicitamente permitido. Se um desenvolvedor simplesmente esquecer de aplicar uma política, o pod ficará totalmente exposto. Mas o risco vai além de erros honestos. Em um ataque à cadeia de suprimentos, um desenvolvedor pode ser induzido a implantar um componente de terceiros comprometido, sem saber da carga maliciosa oculta ou de suas consequências.

Uma política de negação padrão inverte esse paradigma de uma blocklist para uma allowlist. O princípio central da confiança zero exige que cada interação seja explicitamente autorizada. Portanto, logicamente, nenhum acesso pode ser implícito. Ao bloquear rigorosamente todo o tráfego desde o início, uma postura de negação padrão cria um ambiente em que uma omissão acidental (ou um container malicioso habilmente disfarçado tentando se comunicar externamente) resulta em uma conexão bloqueada com segurança. Isso obriga você a conceder acesso explicitamente por padrão, transformando o que poderia ser uma violação catastrófica silenciosa em um erro de implantação perceptível e fácil de corrigir.

A abordagem começa com uma regra simples, mas poderosa: negue todo o tráfego por padrão. Cada namespace recebe uma NetworkPolicy de negação padrão que bloqueia todas as entradas e saídas de cada pod, a menos que exista uma política de permissão explícita.

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata:   name: default-deny-in-namespace spec:   podSelector: {}   policyTypes:   - Ingress   - Egress

Assim que uma NetworkPolicy tem como destino um pod em um namespace, ele não retém mais o acesso irrestrito. Ao definir uma política que bloqueia o acesso por padrão, ela se alinha a uma postura de confiança zero de negação por padrão.

Por que isso é importante quando não é possível aplicar patches

Considere um cenário empresarial que lembra a famosa crise do Log4j ou choques de framework mais recentes, como a vulnerabilidade React2Shell (CVE-2025-55182):

1. Uma vulnerabilidade crítica de execução remota de código (RCE) é descoberta abruptamente em uma biblioteca onipresente usada por sua aplicação.
2. A vulnerabilidade permite o controle total do servidor se um invasor enviar uma solicitação especialmente criada ao serviço afetado.
3. Como a biblioteca está profundamente incorporada às suas dependências, um patch validado não será testado e implantado com êxito na produção por vários dias.

O impacto em uma organização com políticas de rede de confiança zero é mínimo:

• Um invasor que compromete qualquer pod pode acessar facilmente o serviço vulnerável em qualquer namespace (sem isolamento lateral).
  • Com as políticas de rede do ZTVP: o invasor não pode acessar o serviço a partir de outro namespace (isolamento de namespace).
• Um invasor pode se conectar a qualquer porta exposta no serviço, incluindo portas críticas ou de gerenciamento (sem filtragem no nível da porta).
  • Com as políticas de rede do ZTVP: o invasor não pode se conectar a portas que não sejam explicitamente permitidas (filtragem no nível da porta).
• Um invasor pode fazer conexões de saída livremente para exfiltrar dados ou estabelecer canais de comando e controle (C2) (sem restrições de saída).
  • Com as políticas de rede do ZTVP: o invasor não pode exfiltrar dados para endpoints externos (restrições de saída).

Demonstração: elimine o caminho de ataque

Criamos um vídeo de demonstração no qual observamos exatamente como as políticas de rede implementadas corretamente eliminam os caminhos de ataque. Inicialmente, vemos um ambiente sem uma postura de negação padrão, em que um invasor que aproveita uma vulnerabilidade na cadeia de suprimentos pode facilmente realizar um amplo reconhecimento, sondando livremente a rede em busca de outros componentes sem patches para explorar. Depois, vemos que após a aplicação de políticas de rede rígidas, a história muda completamente.

Mesmo que um invasor consiga violar um pod, sua capacidade de pesquisar a rede, procurar vulnerabilidades ou se movimentar lateralmente fica totalmente neutralizada. As políticas restringem-nos ao container comprometido, contendo efetivamente a ameaça e ganhando o tempo necessário para implementar ações corretivas. Embora não sejam a única proteção contra falhas em uma estratégia de segurança abrangente, estabelecer limites de rede rígidos é, sem dúvida, o melhor ponto de partida para criar sua última linha de defesa.

Esta demonstração mostra como as políticas de rede restringem um ataque ao container comprometido, contendo a ameaça de maneira eficaz e ganhando o tempo necessário para implementar ações corretivas.

Panorama: defesa estruturada

As políticas de rede são apenas uma camada de uma estratégia abrangente. O Layered Zero Trust Validated Pattern combina essas políticas com identidades de carga de trabalho SPIFFE/SPIRE (usando o gerenciador de identidades de cargas de trabalho de confiança zero), segredos gerenciados pelo Vault, autenticação centralizada usando um provedor de identidade (IdP), como a Red Hat build of Keycloak padrão, e o monitoramento de runtime do Red Hat Advanced Cluster Security for Kubernetes. As políticas de rede completam o cenário, garantindo que, mesmo que a identidade, os segredos e a segurança da aplicação falhem, a camada de rede forneça contenção.

Mas como saber se suas políticas de rede estão realmente funcionando ou se um container comprometido está investigando repetidamente seus limites internos? O que acontece quando um exploit de dia zero desencadeia uma conexão negada?

Ajudamos a responder a essas perguntas importantes ao longo desta série de blogs que explora como o Layered Zero Trust Validated Pattern implementa práticas de segurança de confiança zero. Veja o que esperar à medida que avançamos:

• Defesa ativa com o Red Hat Advanced Cluster Security for Kubernetes: implementação de monitoramento profundo de runtime, verificação automatizada de políticas de rede e alertas em tempo real para atuar como seu cérebro central de segurança.
• Identidade e segredos: gerencie identidades de cargas de trabalho com mais segurança usando o gerenciador de identidades de cargas de trabalho de confiança zero e a integração do Vault.
• Cadeia de suprimentos: proteja sua cadeia de suprimentos de software de ponta a ponta, impondo assinaturas de conteúdo e verificando tarefas de pipeline para garantir que somente códigos confiáveis cheguem ao seu cluster.

Tudo pronto para vê-lo em ação? Você não precisa esperar pelo próximo artigo para começar. Confira o Layered Zero Trust Validated Pattern para explorar a arquitetura e teste você mesmo a demonstração de políticas de rede.

Referências

• NIST SP 800-207: Arquitetura de confiança zero
• NIST SP 800-207A: Confiança zero para aplicações nativas em nuvem
• CISA: Guia de microssegmentação Zero Trust
• Layered Zero Trust Validated Pattern
• Padrões validados
• Em busca do Santo Graal: Por que o Red Hat Hummingbird Project visa CVEs próximos de zero
• Métricas de CVE