Controle de permissões AWS e riscos de segurança

O conceito de “blast radius” ganhou uma definição prática e dolorosa esta semana com a confirmação de uma violação na infraestrutura AWS da LexisNexis. O caso serve como um estudo de caso perfeito sobre como uma postura de IAM permissiva pode transformar um comprometimento inicial em uma catástrofe de dados. Paralelamente, a newsletter destaca uma discrepância crítica de segurança entre o AWS Console e o Terraform, um lembrete urgente para equipes que adotam IaC.

Estudo de Caso LexisNexis: O Raio de Explosão em Ação

O ataque seguiu um caminho clássico de escalada de privilégios na nuvem. Os invasores exploraram uma aplicação React não corrigida para obter acesso inicial. O pivô decisivo ocorreu quando assumiram uma função de tarefa do ECS (ECS task role) configurada com permissões excessivas. Essa função possuía acesso de leitura a TODOS OS SEGREDOS na conta AWS, incluindo a credencial mestre do Redshift de produção.

O resultado foi a exfiltração de 536 tabelas do Redshift, 53 segredos do AWS Secrets Manager em texto plano e 3,9 milhões de registros de banco de dados. Este incidente sublinha a importância crítica do princípio do menor privilégio para funções do IAM, especialmente aquelas atribuídas a recursos computacionais como tarefas do ECS ou funções Lambda. A auditoria regular de políticas de IAM e o uso de ferramentas como o IAM Access Analyzer para identificar permissões excessivas são defesas não negociáveis.

A Lacuna de Segurança entre Console AWS e Terraform

A Lacuna de Segurança entre Console AWS e Terraform

Um artigo destacado por Laurence Tennant revela uma inconsistência perigosa. O AWS Console agora aplica padrões seguros para certos recursos, como a criptografia obrigatória para RDS (storage_encrypted=true) e a exigência de um ARN de origem (source_arn) em permissões do Lambda. No entanto, o Terraform herda os padrões legados da API, onde storage_encrypted é false e source_arn é opcional.

Isso significa que o mesmo recurso provisionado via Console versus Terraform pode ter posturas de segurança radicalmente diferentes. Equipes que confiam cegamente em IaC podem estar introduzindo inadvertidamente vulnerabilidades. A mitigação requer uma abordagem em camadas: uso de SCPs (Service Control Policies) para impor padrões em nível de conta, scanners de infraestrutura como código (ex: Trivy, Checkov) e o desenvolvimento de “módulos de ouro” internos que encapsulam configurações seguras por padrão.

Priorização Estratégica de Serviços de Segurança da AWS

Sena Yakut oferece um contraponto crucial ao “ativar tudo”. Habilitar todos os serviços de segurança da AWS (GuardDuty, Security Hub, Inspector, etc.) no primeiro dia gera milhares de alertas não investigados e dashboards ignorados, criando fadiga de alerta e desperdiçando recursos.

A recomendação é começar com uma modelagem de ameaças da arquitetura real para identificar os pontos de ruptura críticos. Em seguida, selecione controles que correspondam a esses riscos. A análise também cobre a conscientização de custos, a sobreposição de serviços com ferramentas de terceiros e defende o uso do IAM Identity Center com credenciais temporárias como uma base de identidade mais robusta do que simplesmente adicionar mais monitoramento.

Atualizações Técnicas e Vulnerabilidades Relevantes

A digest inclui uma lista extensa de mudanças na API, IAM e CloudFormation, além de vulnerabilidades em Amazon Linux. Destaques técnicos incluem:

• Vulnerabilidades em libsoup (CVE-2026-3632/3634/3633): Bypass de validação de hostname, injeção de cabeçalho Content-Type e injeção arbitrária de cabeçalhos HTTP, que podem habilitar HTTP smuggling, SSRF e splitting de resposta.
• CVE-2026-29062 (jackson-core): Bypass de JSON aninhado causa Denial of Service (StackOverflow). CVSS 7.5.
• CVE-2026-2297 (CPython): Importação de arquivos .pyc contorna hooks de auditoria sys.audit.
• Boletins de Segurança AWS: Problemas reportados na AWS-LC (CVE-2026-3336/3337/3338) e um bypass no plugin de auditoria do MariaDB Server via prefixos de comentário SQL.

Alterações na documentação de segurança trazem nuances importantes: o CDK agora desaconselha explicitamente a codificação fixa (hardcoding) de credenciais AWS para produção; o Security IR da AWS removeu linguagem “opcional” para resposta proativa, tornando-a um recurso central com dependência do GuardDuty; e o Amazon Neptune agora requer a cópia de snapshots criptografados antes da restauração.

“Turning on every AWS security service on day one gets you thousands of alerts nobody investigates and dashboards nobody checks.” – Sena Yakut

Conclusão: Controlando o Raio de Explosão

As lições desta semana são claras. A segurança na nuvem eficaz não é sobre a quantidade de ferramentas, mas sobre a precisão dos controles e a consistência das configurações. O caso da LexisNexis mostra que um único ponto fraco no IAM pode anular todas as outras defesas. A lacuna Console vs. Terraform revela que a automação sem validação de segurança pode ser tão perigosa quanto o provisionamento manual. A priorização, baseada em uma compreensão real dos riscos da arquitetura, é o que separa uma postura defensiva eficaz de um painel de alertas inúteis. O “blast radius” é controlado no design: pelo princípio do menor privilégio, pela infraestrutura imutável e segura por padrão, e por uma estratégia de monitoramento focada.

Análise baseada no AWS Security Digest #251 (09/03/2026). Pesquisa e adaptação: N00TROP1C — NULLTROPIC, 2026.