Uma empresa que roda workloads em AWS, Azure ou GCP costuma acumular, sem perceber, três problemas de segurança diferentes ao mesmo tempo: um bucket S3 público que ninguém lembra de ter criado, uma imagem de container com uma CVE crítica rodando em produção há meses, e nenhuma visibilidade real de como esses dois problemas se conectam a um caminho de ataque. O mercado de segurança em nuvem batizou cada uma dessas frentes com uma sigla própria, CSPM, CWPP e CNAPP e é comum confundir uma com a outra, ou tratar como três ferramentas concorrentes quando, na prática, a mais recente das três nasceu para unificar as outras duas.
Este artigo explica o que cada sigla significa, para que serve, como usar na prática e como elas se encaixam quando combinadas.
Visão geral rápida
| Sigla | Nome completo | Foco | O que responde |
|---|---|---|---|
| CSPM | Cloud Security Posture Management | Configuração da infraestrutura em nuvem | "Minha nuvem está configurada de forma segura?" |
| CWPP | Cloud Workload Protection Platform | Proteção do que roda dentro da nuvem (VM, container, serverless) | "O que está rodando dentro da minha carga de trabalho é seguro?" |
| CNAPP | Cloud-Native Application Protection Platform | Unificação de CSPM + CWPP + outras camadas | "Qual é o meu risco real, do código à execução?" |
Repare que CSPM e CWPP olham para dois lados diferentes do mesmo ambiente — um olha a configuração ao redor do workload, o outro olha o que roda dentro dele — e o CNAPP surgiu justamente para juntar essas duas vistas (e outras) em uma plataforma só.
CSPM: postura de configuração da nuvem
Como e por que surgiu
O termo foi cunhado pelo Gartner por volta de 2019, mas o problema é mais antigo: com a migração em massa para IaaS, times passaram a provisionar infraestrutura via console ou API em minutos, sem o mesmo processo de revisão que existia em datacenter próprio. O resultado recorrente eram erros de configuração — bucket de storage público, security group liberado para 0.0.0.0/0, banco de dados sem criptografia, chave de IAM com privilégio excessivo. Pesquisas do setor apontam configuração incorreta, não exploração de vulnerabilidade de software, como a causa mais comum de incidente em nuvem. O CSPM nasceu para automatizar a detecção contínua desse tipo de erro, que antes dependia de checklist manual ou auditoria pontual.
Para que serve
Uma ferramenta de CSPM conecta via API de leitura (read-only) às contas de nuvem do cliente (AWS, Azure, GCP, e às vezes Kubernetes gerenciado) e varre continuamente a configuração de cada recurso contra um conjunto de regras — benchmarks como CIS Benchmarks, controles de PCI-DSS, ISO 27001 ou frameworks próprios do provedor. Entre o que ela cobre:
| Categoria | Exemplo de verificação |
|---|---|
| Exposição de rede | Security group ou NSG liberando porta administrativa (22, 3389, 3306) para a internet |
| Storage | Bucket S3, Azure Blob ou GCS com acesso público não intencional |
| Criptografia | Volume EBS, banco RDS ou disco sem criptografia em repouso |
| IAM | Usuário ou role com política *:*, MFA desabilitado, chave de acesso não rotacionada |
| Logging/auditoria | CloudTrail, Activity Log ou Cloud Audit Logs desabilitado em alguma região/projeto |
| Compliance | Mapeamento automático da configuração atual contra CIS, PCI-DSS, HIPAA, LGPD |
A saída típica é um painel com findings priorizados por severidade, muitas vezes com remediação automática (auto-fix) ou geração de ticket para o time responsável. Ferramentas conhecidas nessa categoria: Wiz, Prisma Cloud, Microsoft Defender for Cloud, AWS Security Hub, Orca Security.
Exemplo prático
Um time sobe um bucket S3 para armazenar exports temporários de relatório e, por engano, deixa a política de bucket com Principal: "*". Sem CSPM, esse bucket fica exposto até alguém notar manualmente ou até aparecer em um scan externo de terceiros. Com CSPM rodando, a ferramenta detecta a mudança de configuração em minutos (via CloudTrail ou varredura periódica), classifica como severidade crítica por conter dados sensíveis, e dispara alerta ou já reverte a política automaticamente, dependendo da regra configurada.
CWPP: proteção da carga de trabalho
Como e por que surgiu
O termo também é do Gartner, um pouco mais antigo que CSPM (por volta de 2018), evoluindo do conceito tradicional de proteção de servidor (antivírus, EDR) adaptado para o mundo de nuvem híbrida. A motivação: CSPM garante que a configuração ao redor do workload está correta, mas não olha para dentro da VM, do container ou da função serverless, não detecta um processo malicioso rodando, uma imagem de container com vulnerabilidade conhecida, ou um binário malicioso plantado por um atacante que já obteve acesso inicial.
Para que serve
CWPP protege a carga de trabalho em si, ao longo de todo o ciclo de vida, do build ao runtime e normalmente cobre múltiplos tipos de workload sob uma mesma plataforma:
| Tipo de workload | O que o CWPP cobre |
|---|---|
| Máquinas virtuais | Hardening de SO, detecção de malware, EDR, gestão de patch |
| Containers | Scan de vulnerabilidade de imagem, verificação de configuração do Dockerfile, proteção em runtime |
| Kubernetes | Políticas de admissão, detecção de comportamento anômalo em pod, segmentação de rede entre namespaces |
| Serverless (Lambda, Cloud Functions) | Análise de permissões da função, detecção de código malicioso injetado, proteção de dependências |
As capacidades típicas se dividem em duas fases:
- Antes do deploy (shift-left): scan de imagem de container em pipeline CI/CD, análise de IaC (Terraform, CloudFormation) antes do apply, verificação de dependências vulneráveis (SCA — Software Composition Analysis)
- Durante a execução (runtime): monitoramento de comportamento do processo, detecção de escalonamento de privilégio, bloqueio de conexão de rede anômala, integridade de arquivo
Ferramentas conhecidas: Aqua Security, Sysdig, Falco (open source, focado em runtime), Trivy (open source, focado em scan de imagem), CrowdStrike Falcon Cloud Security.
Exemplo prático
Uma imagem de container publicada há seis meses usa uma versão do OpenSSL com uma CVE crítica divulgada na semana passada. O CWPP, ao reavaliar continuamente o inventário de imagens em uso (não só no momento do build), identifica que essa imagem específica está rodando em produção, calcula o risco combinando severidade da CVE com exposição real (a aplicação recebe tráfego externo?) e prioriza a remediação, algo que um scan único feito só no pipeline de CI, sem revarredura contínua, jamais pegaria depois do deploy.
CNAPP: a unificação das duas camadas
Como e por que surgiu
Por volta de 2021, o Gartner formalizou o termo CNAPP reconhecendo um problema prático: empresas estavam comprando uma ferramenta de CSPM, outra de CWPP, mais uma de scan de IaC, outra de gestão de segredo, e mais uma de gestão de identidade em nuvem (CIEM), cada uma com console próprio, sem correlação entre os achados. Um finding de CSPM ("esse security group está aberto") e um finding de CWPP ("essa VM tem uma vulnerabilidade crítica") não conversavam entre si, mesmo quando, juntos, formavam um caminho de ataque real e explorável.
Para que serve
CNAPP é uma plataforma consolidada que integra, no mínimo, CSPM e CWPP sob um único data model, e tipicamente soma outras camadas:
| Componente incorporado | O que adiciona |
|---|---|
| CSPM | Postura de configuração de infraestrutura |
| CWPP | Proteção de workload (VM, container, serverless) |
| CIEM (Cloud Infrastructure Entitlement Management) | Análise de permissões excessivas de identidades humanas e de máquina |
| IaC scanning | Verificação de Terraform/CloudFormation/Bicep antes do deploy |
| KSPM (Kubernetes Security Posture Management) | Postura de configuração específica de cluster Kubernetes |
| Secrets scanning | Detecção de credencial exposta em código ou imagem |
| DSPM (Data Security Posture Management) | Descoberta e classificação de dado sensível espalhado pela nuvem |
O diferencial real de um CNAPP não é só "ter tudo isso na mesma assinatura" é a correlação entre camadas para priorizar risco por caminho de ataque real, em vez de uma lista plana de milhares de findings isolados. Um bucket com dado sensível exposto (DSPM), acessível por uma role com permissão excessiva (CIEM), rodando atrás de uma VM com uma CVE crítica e exposta à internet (CWPP + CSPM), é um caminho de ataque completo e é isso que um CNAPP maduro mostra graficamente, priorizando esse combo acima de mil alertas isolados de baixo risco.
Ferramentas conhecidas: Wiz, Prisma Cloud (Palo Alto), Microsoft Defender for Cloud, Orca Security, CrowdStrike Falcon Cloud Security, Aqua Security.
Exemplo prático
Retomando os dois exemplos anteriores: o bucket S3 mal configurado e a imagem de container vulnerável, isoladamente, geram dois alertas médios em ferramentas separadas o tipo de alerta que se acumula em uma fila e nunca é tratado com urgência. Em um CNAPP, o motor de correlação identifica que a role IAM usada pela aplicação vulnerável tem permissão de leitura sobre esse mesmo bucket. O resultado não são dois findings soltos: é um único alerta crítico descrevendo o caminho completo — "atacante explora CVE na imagem X, herda a role Y, acessa dado sensível no bucket Z" — com prioridade muito mais alta do que qualquer um dos dois problemas isolados sugeriria.
Como as três siglas se relacionam
| CSPM | CWPP | CNAPP | |
|---|---|---|---|
| O que protege | Configuração da infraestrutura em nuvem | O workload em execução (VM, container, função) | Ambos, mais camadas adicionais (CIEM, DSPM, IaC, secrets) |
| Momento de atuação | Contínuo, pós-deploy (e cada vez mais pré-deploy via IaC scan) | Build (shift-left) e runtime | Do código ao runtime, ciclo completo |
| Unidade de análise | Recurso de nuvem (bucket, security group, role) | Processo, imagem, container, função | Caminho de ataque correlacionado entre recursos |
| Nasce de | Necessidade de detectar erro de configuração em escala | Necessidade de estender EDR/antivírus para nuvem | Necessidade de unificar CSPM + CWPP + ferramentas correlatas |
| Substitui as outras? | Não | Não | Tipicamente incorpora ambas em uma única plataforma |
Uma forma simples de visualizar: CSPM olha a casa (portas e janelas trancadas, alarme ligado), CWPP olha quem está dentro da casa (processos e comportamento), e CNAPP é o painel único que junta as duas vistas e ainda soma outras câmeras (identidade, dado sensível, segredo) para mostrar o caminho de invasão completo, não só os pontos fracos isolados.
Como usar na prática
- Comece com CSPM se a maturidade em nuvem é baixa — é o retorno mais rápido: a maioria dos ambientes tem erro de configuração crítico esperando para ser encontrado, e a implantação costuma ser só leitura via API, sem agente
- Adicione CWPP onde há workload sensível — containers e VMs expostos à internet, ou que processam dado regulado, justificam agente de runtime além da varredura de configuração
-
Integre scan de IaC no pipeline antes do deploy — encontrar o security group mal configurado no
terraform plan, antes doapply, é ordens de magnitude mais barato do que corrigir depois de exposto em produção - Avalie CNAPP quando a organização já opera CSPM e CWPP separados e sofre com alert fatigue — a consolidação só compensa quando o time já tem findings suficientes para precisar de correlação; para um ambiente pequeno, CSPM isolado pode ser suficiente por um bom tempo
- Priorize por caminho de ataque, não por severidade isolada — uma CVE crítica em uma máquina isolada, sem exposição de rede e sem dado sensível, é bem menos urgente que uma CVE média em uma máquina exposta com acesso a dado regulado
- Não trate como substituto de WAF, SIEM ou pentest — CSPM/CWPP/CNAPP cobrem postura e workload de nuvem, não substituem proteção de borda de aplicação nem resposta a incidente formal
Boas práticas
- Não deixe alertas de CSPM acumular sem triagem — ambientes recém-conectados costumam gerar milhares de findings; comece filtrando por severidade crítica/alta e exposição pública antes de tentar zerar tudo
- Use as regras de CIS Benchmark como ponto de partida, não como lista definitiva — adapte exceções documentadas para casos legítimos (ex: bucket público de assets estáticos de um site)
- Integre o CWPP à pipeline de CI/CD, não só ao runtime — bloquear build com CVE crítica antes do deploy é mais barato do que caçar a imagem já rodando em produção
- Combine CIEM com CSPM/CWPP sempre que possível — permissão excessiva é o fator que transforma uma vulnerabilidade isolada em um caminho de ataque completo
- Revise a política de auto-remediação com cuidado — corrigir automaticamente uma configuração de produção sem revisão humana pode causar indisponibilidade; comece com alerta e evolua para remediação automática só em regras bem testadas
Perguntas frequentes
| Pergunta | Resposta |
|---|---|
| CSPM detecta vulnerabilidade dentro de um container? | Não — isso é função de CWPP. CSPM olha a configuração do ambiente ao redor, não o conteúdo do workload |
| Preciso de CWPP se uso só serviços gerenciados (managed services)? | Em menor grau — o provedor cuida da infraestrutura subjacente, mas funções serverless e containers que você mesmo publica ainda têm código e dependências que precisam de verificação |
| CNAPP substitui completamente CSPM e CWPP separados? | Na prática, sim — a maioria dos fornecedores de CNAPP oferece os módulos de CSPM e CWPP dentro da mesma plataforma, com a vantagem adicional da correlação |
| Ferramentas open source como Trivy e Falco competem com CNAPP comercial? | Cobrem pedaços específicos (scan de imagem, detecção de runtime) muito bem e sem custo de licença, mas não entregam a correlação entre camadas nem o painel de gestão unificado de um CNAPP comercial |
| Qual sigla é mais importante para começar? | Depende do maior risco do ambiente: se a preocupação é configuração exposta, CSPM primeiro; se é código/imagem vulnerável rodando, CWPP primeiro; times maduros tendem a convergir para CNAPP de qualquer forma |
Conclusão
CSPM, CWPP e CNAPP não competem entre si — são camadas que evoluíram para cobrir ângulos diferentes do mesmo problema. CSPM garante que a configuração da infraestrutura em nuvem está correta. CWPP garante que o que roda dentro dessa infraestrutura — VM, container, função — está livre de vulnerabilidade e comportamento malicioso. E CNAPP surgiu para unificar as duas vistas (e outras, como CIEM e DSPM) em uma plataforma só, com o benefício real de correlacionar findings isolados em caminhos de ataque priorizáveis.
Antes de sair comprando uma plataforma de CNAPP completa, vale mapear onde está o maior risco real do seu ambiente hoje — configuração exposta, workload vulnerável, ou falta de correlação entre os dois — e usar isso para decidir por onde começar.
Top comments (0)