O gerenciamento da postura de segurança em nuvem, ou CSPM (Cloud Security Posture Management), avalia a configuração do plano de controle da nuvem em relação aos requisitos de segurança estabelecidos. No AWS, Azure e Google Cloud, o CSPM nos ajuda a identificar se recursos, identidades e configurações em nível de conta estão em conformidade com uma postura definida. Ele não inspeciona o conteúdo (payload) de pacotes de aplicativos nem substitui a detecção em tempo de execução de um ataque ativo.
[fontes][/fontes]
As ferramentas de CSPM geralmente operam sem agentes. Elas utilizam credenciais de apenas leitura para chamar as APIs de cada provedor, criar um inventário de recursos e avaliar regras com base nesse inventário. Exemplos incluem AWS Config e Security Hub, Microsoft Defender for Cloud, Google Security Command Center e ferramentas de varredura de código aberto, como Prowler e Steampipe. Quando um recurso não atende a uma dessas regras, a ferramenta relata o resultado como uma constatação (ou finding).
Uma constatação é uma declaração sobre um estado de configuração observável, como a configuração de acesso de um recurso de armazenamento ou a permissão atribuída a uma identidade. Seu valor depende das evidências que o processo de CSPM consegue ler e da regra utilizada para interpretar essas evidências.
[fontes][/fontes]
Agora podemos mapear os limites do provedor e as fontes de evidência utilizadas em uma avaliação de CSPM.
[fontes][/fontes]
Evidências de configuração descrevem o que o plano de controle do provedor relata no momento da coleta. Logs de atividade fornecem um registro histórico de ações de gerenciamento, como uma entidade (principal) alterando uma política ou criando um recurso. Na AWS, são o AWS Config e o CloudTrail; no Azure, o Azure Resource Graph e o Activity Log; e no Google Cloud, o Cloud Asset Inventory e o Cloud Audit Logs. Juntas, essas fontes podem demonstrar a existência de uma configuração e indicar quem a alterou, mas nenhuma delas prova que uma solicitação de aplicativo foi bem-sucedida, que dados foram acessados ou que um pacote de rede era seguro.
[fontes][/fontes]
Desvio de configuração (configuration drift) é a diferença entre a configuração aprovada ou esperada e a configuração atual observada. O desvio pode resultar de uma alteração manual, um erro de automação, uma reversão de implantação (rollback) que restaurou um valor antigo ou um recurso criado fora do processo de entrega pretendido. O CSPM detecta a diferença apenas quando o recurso está em seu inventário e as evidências estão disponíveis.
[fontes][/fontes]
Limite da evidência Uma descoberta do CSPM estabelece uma condição de configuração dentro do escopo do provedor. Ela não determina, por si só, a explorabilidade, o impacto nos negócios ou a ocorrência de um acesso bem-sucedido.
[fontes][/fontes]
Uma descoberta pode ser um falso positivo quando a regra avaliada aponta um problema, embora o requisito aplicável permita o estado observado. Por exemplo, uma regra formulada de forma genérica pode sinalizar um endpoint voltado para a internet que é deliberadamente público e protegido por controles não avaliados pela regra. A abordagem segura consiste em validar o requisito, a finalidade do recurso, o caminho de exposição e os controles compensatórios antes de alterar a configuração de produção.
[fontes][/fontes]
A ausência de permissões de leitura gera o problema oposto. Se a identidade do CSPM não conseguir listar um recurso, recuperar uma política ou inspecionar uma configuração relevante, a avaliação poderá apresentar uma cobertura incompleta em vez de um resultado limpo. Um recurso não gerenciado produz o mesmo efeito prático quando está fora do escopo de contas, assinaturas, projetos ou inventário que está sendo avaliado.
[fontes][/fontes]
A responsabilidade compartilhada também estabelece um limite. O provedor de nuvem opera o serviço subjacente, enquanto o cliente permanece responsável por decisões como atribuição de identidade, exposição de rede, política de recursos e configuração de acesso a dados. Uma verificação de postura bem-sucedida não transfere essa responsabilidade nem demonstra a eficácia de todos os controles gerenciados pelo cliente.
[fontes][/fontes]
Regra de decisão Considere a ausência de descobertas como uma informação útil apenas após confirmar o escopo, as permissões de coleta, a aplicabilidade da regra e a janela de tempo da evidência.
Utilizaremos uma carga de trabalho deliberadamente pequena chamada orders-api. Ela representa um serviço de aplicação que escuta na porta 8080 e armazena dados de pedidos em um recurso de armazenamento de objetos nativo do provedor. Cada versão permanece dentro dos limites do seu próprio provedor; portanto, não se pressupõe que identidades, permissões de armazenamento ou descobertas (findings) transitem de uma nuvem para outra.
Na AWS, a orders-api utiliza a role orders-api-role e o bucket orders-data-s3. No Azure, utiliza a identidade gerenciada orders-api-mi e a conta de armazenamento ordersdatast. No Google Cloud, utiliza a conta de serviço orders-api-sa e o bucket orders-data-gcs. Esses identificadores são fictícios, mas o limite que eles demonstram é reutilizável.
Podemos examinar como a identidade de cada carga de trabalho permanece restrita aos recursos do seu próprio provedor.