CWPP — proteção de workload
Cloud Workload Protection Platform vigia o que acontece dentro da VM, container e serverless: syscalls, conexões e processos, em tempo de execução.
O que é
CWPP () é o sensor dentro da carga: VM, container, função serverless, host de Kubernetes. olha a configuração; CWPP olha o comportamento. Ele vê syscalls, conexões de rede, processos, leitura de arquivo, modificação de binário, e correlaciona isso contra regras e modelos.
Quando tudo dá certo, CWPP não aparece: log de detecção da regra, alerta discreto no SIEM, e a carga segue rodando. Quando dá errado, é a diferença entre um crypto miner rodar por seis meses e ser cortado em três minutos.
Como funciona: agents e eBPF
A escolha clássica é agent-based (um processo que sobe dentro da carga e intercepta eventos) versus eBPF-based (programas rodando dentro do kernel, sem processo extra). Cada um tem trade-off.
- agent user-space (Falco, Aqua): visibilidade ampla, fácil de atualizar, mas é mais um processo atacável
- eBPF (Tetragon, Cilium Tetragon, Datadog USM): instrumenta o kernel direto, sem processo extra, mas as regras ficam mais limitadas ao que o kernel expõe via hooks
- kernel module: máxima visibilidade, mas compromete compatibilidade com kernels gerenciados (GKE, EKS otimizado)
- sidecar por pod: isola o sensor da carga, útil quando a carga não pode ser modificada, mas custa mais recursos
Detecção comportamental: regras sobre o que acontece
A regra não pergunta 'qual processo está rodando?', pergunta 'esse processo está fazendo algo que ele nunca fez antes?'. A forma clássica é uma assinatura sobre syscalls: processo, container, syscall, condição. A forma moderna é modelo de comportamento (baseline por workload) que dispara anomalia, não assinatura.
Falco é o padrão aberto para assinatura. A regra abaixo pega o padrão clássico de shell sendo aberto dentro de um container, algo que nenhuma aplicação legítima faz em produção:
- rule: Terminal shell in container
desc: >
Detect shell spawned inside a workload container.
Legitimate workloads never open an interactive shell at runtime;
this is a strong indicator of intrusion or hands-on-keyboard activity.
condition: >
container and
spawned_process and
proc.name in (shell_binaries)
output: >
shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline
container=%container.name image=%container.image.repository
k8s=%k8s.ns.name/%k8s.pod.name
priority: WARNING
tags: [container, mitre_execution, mitre_T1059]Resposta: do aviso ao corte
Detecção sem resposta é só ruído. CWPP tem três alavancas, em ordem crescente de agressividade:
- alerta: manda evento para SIEM/, humano decide. Sem mudança no workload
- isolamento de rede: NetworkPolicy ou passa a bloquear o egress do pod/VM, cortando exfiltração mas mantendo o processo vivo para forense
- kill / quarantine: termina o processo, snapshot do filesystem para análise, container removido. É a resposta certa quando a regra é certeza (não anomalia)
Onde entra
CWPP vive depois do deploy. Ele assume que CSPM fez a parte dele (configuração OK), containers foram hardened (runtime OK), e agora a pergunta é: o que está acontecendo aqui dentro? Liga no SIEM junto com CloudTrail, flow logs e EDR de endpoint para correlação (shell no container + STS token AssumeRole na mesma janela de 30s = incidente crítico).
Pontos fortes
- detecta o que configuração nenhuma pega: em processo legítimo, exfiltração por canal permitido, persistência em filesystem limpo
- regras baseadas em comportamento pegam famílias de ataque, não específica: um reverse shell em qualquer linguagem dispara a mesma regra
- fechando o ciclo: snapshot do filesystem pós-detecção vira evidência para incidente, não vira prescrição para o próximo atacante
Limitações
- agent dentro da carga é superfície nova: bug no sensor vira RCE dentro do nó, e o histórico tem exemplos
- custo de telemetria em escala: instrumentar mil containers em eBPF parece grátis até o log ir para o SIEM, e a casa é o switch do provedor
- falsos positivos de comportamento quebram a confiança: regra boa demais é regra que todo mundo silencia; o tuning é trabalho permanente, não setup de uma vez
conexões no mapa
- CWPP — proteção de workloadmonitora o runtimeContainers — imagens e cadeia de suprimentos
- CWPP — proteção de workloaddetecta comportamentoKubernetes — runtime seguro
- Logging & detection - sinais e alertasfornece a trilhaCWPP — proteção de workload
- CWPP — proteção de workloadalerta de runtimeResposta a incidentes em cloud
atualizado em 14/10/2026 · fontes para aprofundar · reportar erro
Estude antes
teste o que entendeu
Carregando perguntas…