Scanners de segurança não veem o risco que nasce da composição de configurações corretas

Um identity pool do Cognito, uma role do IAM e um bucket do S3 podem passar em todos os checks de segurança e, juntos, expor dados sensíveis a qualquer usuário anônimo da internet.

O caminho que três configurações corretas abrem

Um post recente na DEV Community, assinado por Bala Paranj, descreve um cenário que qualquer arquiteto de soluções AWS já montou sem perceber o risco. Um identity pool do Cognito permite acesso não autenticado, de propósito, para deixar usuários navegarem num catálogo antes de fazer login. Uma role do IAM concede s3:GetObject num bucket específico, com trust policy restrita ao próprio Cognito. Um bucket S3 guarda registros de saúde, está marcado com a tag data_classification: phi, é privado, criptografado com KMS e tem bloqueio de acesso público no nível da conta.

Cada recurso, isolado, passa em qualquer verificação. Nenhuma das três configurações é um erro. O problema é que o identity pool mapeia usuários anônimos para a role, e a role lê o bucket. Um visitante sem login pode pedir credenciais temporárias ao identity pool, assumir a role e chamar s3:GetObject direto no bucket de dados de saúde. Sem autenticação nenhuma.

Esse mesmo bucket guardando prontuário médico é um dado de saúde sensível por natureza, do tipo que a legislação de proteção de dados costuma tratar com rigor adicional. Para quem responde por compliance e proteção de dados dentro do time de nuvem, essa é exatamente a brecha que um relatório de auditoria não pode deixar passar: a exposição não está em nenhuma política isolada, está na aresta que liga as três.

Por que scanners de padrão não acusam nada

Uma ferramenta de checklist percorre recursos e avalia cada um contra uma linha de base: o bucket está público? A criptografia está ligada? O MFA está exigido? Esse modelo funciona bem para configurações universalmente erradas, independente do contexto, mas cada checagem continua avaliando um atributo de um recurso isolado.

Nenhuma dessas ferramentas percorre o grafo formado por identity pool, role e bucket ao mesmo tempo, porque o modelo de checklist avalia nós, não o caminho entre eles. A tag data_classification não entra como variável em nenhuma dessas checagens.

Isso não é uma lacuna que a AWS vai fechar com um patch. A AWS fornece os primitivos de grafo, como IAM, SCPs, políticas de recurso e VPC endpoints, mas a composição entre eles é definida pela arquitetura de cada organização. Avaliar essa composição está fora do que o modelo de responsabilidade compartilhada atribui ao provedor.

Uma ferramenta de checklist avalia nós. Um atacante navega pelas arestas.

A checklist tool evaluates nodes. An attacker navigates edges.Bala Paranj, autor do artigo na DEV Community

Fadiga de alerta: quando mais regra não ajuda

O post descreve um ciclo comum em times de segurança: um scanner sinaliza uma role com permissões amplas, abertas meses antes para uma migração ou integração com fornecedor. O time de engenharia responde "podemos precisar dessas permissões" e o ticket fica parado. No próximo scan, o mesmo achado volta, tecnicamente correto e operacionalmente inútil.

Adicionar mais checks a um modelo de checklist é como adicionar mais palavras ao dicionário de um corretor ortográfico: ele fica melhor em validar palavras isoladas, nunca aprende se a frase faz sentido. A pergunta "um usuário anônimo consegue chegar a dados de saúde por essa cadeia de três serviços?" exige avaliar a composição inteira de uma vez, algo que um modelo de lista não consegue expressar.

O autor propõe inverter a lógica: em vez de perguntar se uma configuração bate com um padrão conhecido como ruim, perguntar se ela contradiz o que o próprio operador declarou. Uma role marcada como role-type: readonly que acumulou secretsmanager:GetSecretValue e lambda:InvokeFunction não gera um achado genérico de "permissão ampla demais", gera uma contradição nomeada, com a ação específica que não deveria estar ali.

A variável que falta é a intenção

Um bucket público servindo arquivos CSS de um site estático está correto. O mesmo bucket público guardando prontuário médico é uma violação. A configuração é idêntica; o veredito depende de uma variável que nenhum scanner enxerga: o que o operador declarou sobre o dado ali dentro.

Essa variável não dá para treinar num modelo de antemão, porque ela só existe no momento em que alguém decide implantar aquele recurso daquele jeito, com aquele dado dentro. É por isso que a tag de classificação de dado deixa de ser burocracia e vira evidência: data_classification: phi é a declaração legível por máquina de que ali existe dado sensível, e é contra essa declaração que a composição precisa ser checada.

Em resumo: sem uma tag de classificação consistente, nem scanner, nem verificador formal, nem auditor humano consegue dizer se uma configuração está certa para aquele dado específico. Quem cuida de LGPD e compliance dentro do time de nuvem tem aqui um ponto de alavanca direto: exigir a tag como pré-requisito de deploy rende mais proteção do que qualquer regra adicional de scanner.

Dois tipos de problema, duas ferramentas diferentes

O artigo separa os problemas de segurança em nuvem em duas classes, e misturar as duas é a origem da falsa sensação de cobertura:

Scanners resolvem bem a primeira linha. A segunda exige avaliar o caminho entre recursos contra o que o operador declarou, não o atributo de um recurso isolado.

O que muda para quem desenha a arquitetura

Tratar os scanners de segurança como piso, não como teto, é o primeiro ajuste prático. Eles cobrem a classe de problemas de padrão universal e continuam necessários, mas não fecham o risco de composição.

• Torne a tag de classificação de dado obrigatória via SCP ou regra custom do AWS Config antes de liberar o deploy de um bucket ou tabela.
• Em ambientes com múltiplos identity pools, roles cross-account e pipelines de RAG com Bedrock, considere ferramentas de grafo (Cartography, BloodHound para AWS) para explorar caminhos, mas trate os milhares de caminhos possíveis como material de investigação, não como lista de achados a fechar.
• Para o cenário de maior risco, onde dado sensível e acesso público convivem na mesma arquitetura, verificação formal com solvers SMT (o artigo cita o Z3, usado em verificação de software de controle de voo) prova matematicamente se um estado proibido é alcançável, em vez de mapear todos os caminhos possíveis.

O autor do post também descreve uma ferramenta própria, o Stave, de código aberto, que exporta fatos de configuração para nove motores de raciocínio independentes e roda em snapshots air-gapped, sem credenciais de nuvem. Vale olhar como referência de implementação, mas o ponto estrutural do artigo independe dessa ferramenta específica: o problema é de modelo, não de produto.

Onde isso não compensa

Para uma conta pequena, sem dado classificado como sensível e sem múltiplos serviços de identidade compondo acesso, o investimento em grafo e verificação formal não se paga. Scanners de segurança bem configurados cobrem a maior parte do risco real desse cenário.

O custo de qualquer abordagem baseada em intenção é a disciplina de tagging: se a tag data_classification estiver errada ou ausente, o verificador herda esse erro e produz tanto falso negativo quanto um scanner tradicional. Formalizar a verificação sem resolver a governança de tags antes é trocar um tipo de ruído por outro, só que mais caro de manter.

Fonte 1: DEV Community — #aws (https://dev.to/bala_paranj_059d338e44e7e/defenders-think-in-lists-attackers-think-in-graphs-your-tools-should-too-424e)

Defenders Think in Lists. Attackers Think in Graphs. Your Tools Should Too. - DEV Community

✓ Human-authored analysis; AI used for formatting and proofreading.

Fonte: DEV Community — #aws