Auditoria de Kubernetes Pós-Wiz e Prisma: Como Sobreviver Sem CNAPP em 2026
Com a saída de plataformas CNAPP ocidentais do mercado russo, empresas enfrentam desafios na auditoria de Kubernetes. Este artigo explora as dificuldades atuais e apresenta uma nova ferramenta de código aberto para atender às exigências regulatórias.
MundiX News·25 de maio de 2026·7 min de leitura·👁 4 views
Nos últimos anos, o cenário de segurança em nuvem para empresas russas sofreu uma reviravolta significativa com a saída de plataformas CNAPP (Cloud-Native Application Protection Platform) ocidentais como Wiz, Prisma Cloud, Lacework e Orca. Para grandes corporações como Sber e Yandex, a perda dessas ferramentas foi um inconveniente gerenciável, pois possuem equipes robustas capazes de construir suas próprias soluções de auditoria utilizando componentes open source como OPA, Falco e Trivy. No entanto, para empresas menores, como bancos de segundo escalão, fintechs e companhias estatais, a situação se tornou crítica, especialmente com a proximidade de auditorias regulatórias.
Atualmente, muitas equipes de segurança com poucos membros dependem de métodos manuais e scripts legados para auditar seus clusters Kubernetes. Comandos como kubectl get pods --all-namespaces -o yaml e a análise visual de configurações se tornaram a norma. Scripts de ex-funcionários, cuja funcionalidade é desconhecida, e a esperança de que auditores não questionem ServiceAccounts privilegiados são práticas comuns. Embora ferramentas como OPA/Kyverno atuem como admission controllers, bloqueando configurações inseguras na entrada, elas não respondem à pergunta crucial: "O que está rodando no meu cluster agora e por quê?". O Trivy, embora útil para escanear imagens em CI/CD, tem seus relatórios frequentemente arquivados sem análise posterior, deixando lacunas significativas na visibilidade e conformidade.
A entrada em vigor do Decreto FSTEC nº 117 em 1º de março de 2026 marca uma mudança importante, substituindo o antigo Decreto nº 17. Este novo regulamento destaca a conteinerização e a arquitetura de microsserviços como um grupo de medidas de proteção separadas. Na prática, isso significa que ativos, incluindo contêineres, devem ser escaneados mensalmente, com vulnerabilidades críticas corrigidas em 24 horas. O acesso privilegiado requer controle e registro de todas as ações, e indicadores de eficácia de proteção devem ser enviados ao regulador com base probatória. Sem uma ferramenta que gere documentação padronizada, o processo de auditoria se torna um pesadelo administrativo, com planilhas que podem ser rejeitadas pelos auditores. Paralelamente, regulamentos como o Decreto nº 21 para processadores de dados pessoais e o GOST R 57580 para o setor financeiro impõem requisitos semelhantes em termos de privilégios, segmentação e análise de vulnerabilidades, mesmo que formulados de maneira diferente.
Diante desse cenário, a busca por alternativas open source se intensificou. Ferramentas como Kubescape oferecem verificações baseadas em frameworks ocidentais (NSA/CISA, MITRE ATT&CK), mas carecem de mapeamento direto para os requisitos da FSTEC. O kube-bench foca no hardening do control plane, uma tarefa específica e limitada. O Trivy, embora excelente para CVEs, é um scanner de imagem, não uma ferramenta de auditoria de cluster. O Polaris ajuda com best practices de configuração em CI/CD, mas não com conformidade. Soluções russas como Kaspersky Container Security e NOTA KUPOL.Контейнеры oferecem proteção em tempo de execução e escaneamento de imagens, mas geralmente não incluem CSPM (Cloud Security Posture Management) com detecção baseada em grafos. O principal desafio de todas essas ferramentas é a incapacidade de gerar um documento aceitável para auditores da FSTЭК, além da falta de um grafo de dependências para identificar combinações de risco.
Em resposta a essa lacuna, foi desenvolvido o ShieldOps, um scanner CLI para Kubernetes que opera sem agentes, SaaS ou dependência de nuvem, podendo ser executado localmente ou em pipelines de CI/CD. O ShieldOps coleta um inventário completo do cluster (pods, deployments, ServiceAccounts, secrets, etc.) utilizando apenas a API de leitura. Essas informações são estruturadas em um banco de dados PostgreSQL como um grafo com arestas tipadas, representando relações como USES_SA, BOUND_TO_ROLE, MOUNTS_SECRET e CAN_REACH. Essa representação compacta do cluster facilita a identificação de cadeias de ataque. O scanner foca em detectar não apenas violações isoladas, mas sim combinações de fatores que, juntos, criam caminhos de exploração. Exemplos incluem um pod com privileged: true que também monta um ServiceAccount com cluster-admin, possui hostNetwork e é exposto via LoadBalancer, criando um cenário de comprometimento total do cluster. O MVP do ShieldOps implementa detecções para combinações como pods expostos à internet com CVEs críticos, ServiceAccounts cluster-admin em pods e segredos montados em pods acessíveis externamente. Cada descoberta é acompanhada de uma descrição textual detalhada do caminho de ataque. O Trivy é integrado como uma biblioteca Go para escanear imagens de contêineres, utilizando seu próprio banco de dados de CVEs. O relatório gerado é em HTML, com agrupamento por pod e um rascunho de mapeamento para os controles regulatórios, que será refinado com a ajuda de auditores certificados.
O mapeamento de conformidade é a parte mais desafiadora. O ShieldOps visa fornecer um artefato único para apresentar aos auditores, simplificando o processo. O roadmap inclui a finalização do mapeamento para o Decreto nº 117, compatibilidade com o Decreto nº 17, mapeamento para o Decreto nº 21, exportação em PDF (essencial para auditorias formais) e relatórios delta para rastrear mudanças e riscos. O suporte para o GOST R 57580 do Banco Central também está em consideração. O autor busca feedback da comunidade de segurança sobre como os audits de Kubernetes são atualmente realizados, quais documentos são apresentados aos reguladores e como a saída de ferramentas como Wiz e Prisma impactou as práticas existentes. O projeto está aberto no GitHub e busca colaboradores para validação e desenvolvimento futuro.
Nos últimos anos, o cenário de segurança em nuvem para empresas russas sofreu uma reviravolta significativa com a saída de plataformas CNAPP (Cloud-Native Application Protection Platform) ocidentais como Wiz, Prisma Cloud, Lacework e Orca. Para grandes corporações como Sber e Yandex, a perda dessas ferramentas foi um inconveniente gerenciável, pois possuem equipes robustas capazes de construir suas próprias soluções de auditoria utilizando componentes open source como OPA, Falco e Trivy. No entanto, para empresas menores, como bancos de segundo escalão, fintechs e companhias estatais, a situação se tornou crítica, especialmente com a proximidade de auditorias regulatórias.
Atualmente, muitas equipes de segurança com poucos membros dependem de métodos manuais e scripts legados para auditar seus clusters Kubernetes. Comandos como kubectl get pods --all-namespaces -o yaml e a análise visual de configurações se tornaram a norma. Scripts de ex-funcionários, cuja funcionalidade é desconhecida, e a esperança de que auditores não questionem ServiceAccounts privilegiados são práticas comuns. Embora ferramentas como OPA/Kyverno atuem como admission controllers, bloqueando configurações inseguras na entrada, elas não respondem à pergunta crucial: "O que está rodando no meu cluster agora e por quê?". O Trivy, embora útil para escanear imagens em CI/CD, tem seus relatórios frequentemente arquivados sem análise posterior, deixando lacunas significativas na visibilidade e conformidade.
A entrada em vigor do Decreto FSTEC nº 117 em 1º de março de 2026 marca uma mudança importante, substituindo o antigo Decreto nº 17. Este novo regulamento destaca a conteinerização e a arquitetura de microsserviços como um grupo de medidas de proteção separadas. Na prática, isso significa que ativos, incluindo contêineres, devem ser escaneados mensalmente, com vulnerabilidades críticas corrigidas em 24 horas. O acesso privilegiado requer controle e registro de todas as ações, e indicadores de eficácia de proteção devem ser enviados ao regulador com base probatória. Sem uma ferramenta que gere documentação padronizada, o processo de auditoria se torna um pesadelo administrativo, com planilhas que podem ser rejeitadas pelos auditores. Paralelamente, regulamentos como o Decreto nº 21 para processadores de dados pessoais e o GOST R 57580 para o setor financeiro impõem requisitos semelhantes em termos de privilégios, segmentação e análise de vulnerabilidades, mesmo que formulados de maneira diferente.
Diante desse cenário, a busca por alternativas open source se intensificou. Ferramentas como Kubescape oferecem verificações baseadas em frameworks ocidentais (NSA/CISA, MITRE ATT&CK), mas carecem de mapeamento direto para os requisitos da FSTEC. O kube-bench foca no hardening do control plane, uma tarefa específica e limitada. O Trivy, embora excelente para CVEs, é um scanner de imagem, não uma ferramenta de auditoria de cluster. O Polaris ajuda com best practices de configuração em CI/CD, mas não com conformidade. Soluções russas como Kaspersky Container Security e NOTA KUPOL.Контейнеры oferecem proteção em tempo de execução e escaneamento de imagens, mas geralmente não incluem CSPM (Cloud Security Posture Management) com detecção baseada em grafos. O principal desafio de todas essas ferramentas é a incapacidade de gerar um documento aceitável para auditores da FSTЭК, além da falta de um grafo de dependências para identificar combinações de risco.
Em resposta a essa lacuna, foi desenvolvido o ShieldOps, um scanner CLI para Kubernetes que opera sem agentes, SaaS ou dependência de nuvem, podendo ser executado localmente ou em pipelines de CI/CD. O ShieldOps coleta um inventário completo do cluster (pods, deployments, ServiceAccounts, secrets, etc.) utilizando apenas a API de leitura. Essas informações são estruturadas em um banco de dados PostgreSQL como um grafo com arestas tipadas, representando relações como USES_SA, BOUND_TO_ROLE, MOUNTS_SECRET e CAN_REACH. Essa representação compacta do cluster facilita a identificação de cadeias de ataque. O scanner foca em detectar não apenas violações isoladas, mas sim combinações de fatores que, juntos, criam caminhos de exploração. Exemplos incluem um pod com privileged: true que também monta um ServiceAccount com cluster-admin, possui hostNetwork e é exposto via LoadBalancer, criando um cenário de comprometimento total do cluster. O MVP do ShieldOps implementa detecções para combinações como pods expostos à internet com CVEs críticos, ServiceAccounts cluster-admin em pods e segredos montados em pods acessíveis externamente. Cada descoberta é acompanhada de uma descrição textual detalhada do caminho de ataque. O Trivy é integrado como uma biblioteca Go para escanear imagens de contêineres, utilizando seu próprio banco de dados de CVEs. O relatório gerado é em HTML, com agrupamento por pod e um rascunho de mapeamento para os controles regulatórios, que será refinado com a ajuda de auditores certificados.
O mapeamento de conformidade é a parte mais desafiadora. O ShieldOps visa fornecer um artefato único para apresentar aos auditores, simplificando o processo. O roadmap inclui a finalização do mapeamento para o Decreto nº 117, compatibilidade com o Decreto nº 17, mapeamento para o Decreto nº 21, exportação em PDF (essencial para auditorias formais) e relatórios delta para rastrear mudanças e riscos. O suporte para o GOST R 57580 do Banco Central também está em consideração. O autor busca feedback da comunidade de segurança sobre como os audits de Kubernetes são atualmente realizados, quais documentos são apresentados aos reguladores e como a saída de ferramentas como Wiz e Prisma impactou as práticas existentes. O projeto está aberto no GitHub e busca colaboradores para validação e desenvolvimento futuro.
