O ferramental de segurança em nuvem se acumulou como um conjunto de siglas porque cada uma endereçava uma falha diferente. Um é o argumento de que elas deveriam ser um produto, e o argumento se sustenta por uma razão: as falhas se compõem, e visão alguma isolada consegue dizer qual combinação é perigosa.
Os quatro problemas
Configuração incorreta — um bucket de armazenamento legível por qualquer um, um banco alcançável da internet, registro desligado. Isso é gestão de postura, e é a maior fonte de incidentes em nuvem por larga margem, porque não exige exploração alguma.
Permissões excessivas — uma identidade que pode fazer muito mais do que seu trabalho exige. Modelos de permissão em nuvem são permissivos por padrão e crescem por acúmulo, e a distância entre concedido e usado é onde o movimento lateral vive.
Cargas vulneráveis — os contêineres e instâncias de fato em execução, com o software sem correção que contenham.
Código de infraestrutura inseguro — os modelos que produzirão a configuração incorreta de amanhã, hoje parados num repositório.
A composição é o ponto. Um contêiner vulnerável é um achado. Um contêiner vulnerável exposto à internet rodando como identidade com permissões administrativas é um incidente esperando para acontecer, e só uma visão que abrange os três consegue dizer isso.
Conectar contas de nuvem
A integração é acesso somente leitura às próprias APIs e logs do provedor: um papel na , um registro de aplicação no Azure, uma conta de serviço no GCP. A plataforma lê configuração, permissões, inventário de recursos e logs de atividade.
Dois pontos que decidem se a implantação é útil:
A cobertura precisa ser completa. Uma conta não conectada é invisível, e contas sombra são exatamente onde estão os problemas interessantes. Conectar as contas que você conhece enquanto uma desconhecida roda sem monitoramento dá falsa sensação de cobertura.
Somente leitura é o padrão correto. O trabalho da plataforma é ver e avisar. Autoridade de remediação é decisão separada que merece ser tomada deliberadamente, e não adquirida por padrão.
Modelos de implantação
Sem agente funciona inteiramente a partir de APIs e snapshots do provedor. Cobre tudo nas contas conectadas de imediato, não exige nada instalado, e vê configuração e inventário em vez de comportamento em execução.
Com agente coloca um coletor leve nas cargas e acrescenta o que o sem agente não vê: processos em execução, conexões de rede reais, atividade em memória. Mais profundo, e exige implantação.
A maioria das implantações reais usa os dois, e a sequência sensata é sem agente primeiro para visibilidade imediata de todo o parque, e então agentes nas cargas cujo comportamento importa.
Relatórios de conformidade
A plataforma avalia o parque contra frameworks — benchmarks CIS, , , , e outros — e informa quais controles passam e quais não.
O enquadramento honesto é que isso é um exercício de mapeamento, e não uma auditoria. Diz quais controles técnicos o framework espera e quais deles sua configuração satisfaz. Não sabe sobre seus controles compensatórios, suas exceções documentadas, ou as partes do framework que tratam de processo em vez de configuração.
Isso o torna genuinamente útil para duas coisas: achar as lacunas técnicas rápido, e produzir evidência para as partes que consegue avaliar. Tratar um relatório aprovado como conformidade é um erro que o próprio relatório não comete.
Ativos não conformes são onde o relatório vira trabalho. A lista só é acionável se puder ser priorizada, e é por isso que contexto de exposição e permissão importa: um ativo não conforme que nada alcança é prioridade diferente de um idêntico que é público.
Detectar risco
A detecção de risco é onde a composição é calculada. A plataforma correlaciona dados de configuração, exposição, vulnerabilidade e permissão para identificar combinações que constituem um caminho de ataque real, em vez de informar cada achado isoladamente.
O valor prático é triagem. Um parque de qualquer tamanho produz milhares de achados individuais, e o número deles que forma um caminho genuíno da internet até algo valioso é muito menor. Essa lista menor é a que vale trabalhar, e produzi-la é a principal coisa que distingue um CNAPP de quatro varredores separados.
O que quem vai prestar o exame precisa saber de cor
Um CNAPP unifica postura, proteção de cargas, gestão de permissões e varredura de infraestrutura como código porque essas falhas se compõem: uma carga vulnerável, exposta à internet e com permissões excessivas é um caminho de ataque que visão alguma isolada identifica. A integração é acesso somente leitura às APIs do provedor, e cobertura incompleta de contas produz falsa confiança. Sem agente dá visibilidade imediata de configuração em todo o parque; agentes acrescentam comportamento em execução. Relatórios de conformidade mapeiam controles técnicos a frameworks e não são auditoria. O valor da detecção de risco é reduzir milhares de achados aos poucos que formam um caminho de ataque real.