# FortiCNAPP: postura de nuvem, integração de contas e conformidade > Um CNAPP existe porque risco em nuvem não é um problema só. Configuração incorreta, permissões excessivas, cargas vulneráveis e código de infraestrutura inseguro são quatro falhas diferentes exigindo quatro visões diferentes, e o valor da plataforma é mantê-las juntas o bastante para dizer qual de fato importa. Source: https://ronutz.com/pt-BR/learn/forticnapp-fundamentals-and-cloud-posture Updated: 2026-07-26 --- O ferramental de segurança em nuvem se acumulou como um conjunto de siglas porque cada uma endereçava uma falha diferente. Um CNAPP é 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 AWS, 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, PCI DSS, SOC 2, HIPAA, 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.