Guia de Testes de Segurança em Nuvem da OWASP

O Guia de Testes de Segurança em Nuvem (CSTG) é um manual abrangente e neutro em relação a fornecedores para testar a segurança de ambientes de nuvem. Ele foi escrito para testadores de penetração, engenheiros de nuvem e de plataforma, arquitetos de segurança, engenheiros de detecção e auditores – qualquer pessoa que precise avaliar, ou defender, infraestrutura executada em um grande provedor de nuvem.

Os provedores de nuvem lançam e alteram serviços mais rápido do que qualquer equipe consegue acompanhar, e cada novo serviço gerenciado traz seu próprio modelo de identidade, exposição de rede e caminhos de abuso. As metodologias tradicionais de teste de rede e de aplicações não capturam esses riscos específicos do provedor: uma política de bucket S3, uma função IAM com permissões excessivas, uma identidade gerenciada anexada a uma máquina virtual ou um bucket de implantação com permissão de escrita não são achados que um port scan ou um proxy web consiga expor. O CSTG existe para preencher essa lacuna com uma metodologia de teste estruturada, repetível e específica do provedor.

O que torna o CSTG diferente

• Ofensivo e defensivo. Cada página de técnica documenta não apenas como enumerar e explorar uma fraqueza, mas também a pegada de detecção que ela deixa nos logs do provedor e a remediação concreta que a elimina. O guia é tão útil para um blue team endurecendo um ambiente quanto para um testador atacando-o.
• Ciente do acesso. As avaliações de nuvem são limitadas pelo acesso que o testador recebe – desde uma posição externa anônima, uma única credencial vazada, uma função de auditoria somente leitura ou um principal elevado. Cada página declara o acesso que assume, para que um engajamento possa ser escopado para o que é realmente testável com as credenciais disponíveis.
• Atômico e estruturado. O conteúdo é organizado como uma matriz de fase × serviço por provedor, com uma página autodescritiva por serviço e fase de teste. Isso torna o guia fácil de navegar, de contribuir e de consumir programaticamente.
• Abrangente. O objetivo é documentar o conjunto completo de técnicas do mundo real para cada serviço – os comandos de enumeração, as más configurações que importam e os caminhos de escalonamento de privilégios, movimento lateral, pós-exploração e persistência que se seguem.

Como o guia é organizado

Cada provedor é dividido em fases de teste e, dentro de cada fase, a unidade atômica é uma página de serviço:

A fronteira mais nítida no guia é entre testes não autenticados vs autenticados, refletindo a questão mais importante em qualquer engajamento de nuvem: que acesso temos para começar?

Cada página segue uma estrutura fixa – Resumo, Pré-requisitos, Enumeração, Más Configurações & Descobertas, Exploração, Detecção & Logging, Remediação & Hardening, Ferramentas, Referências – e carrega frontmatter legível por máquina (provedor, serviço, fase, acesso necessário, permissões necessárias). Consulte STRUCTURE.md para o formato de autoria e as definições dos níveis de acesso.

Guias de provedores

Amazon Web Services (AWS)

Identidade (IAM/STS), armazenamento (S3, EBS), computação (EC2, Lambda, ECS/EKS, ECR), dados (RDS, DynamoDB), aplicação e integração (API Gateway, SNS/SQS, Cognito), infraestrutura como código (CloudFormation), segredos e chaves (Secrets Manager, SSM, KMS) e registro/monitoramento (CloudTrail).

Microsoft Azure

Identidade (Entra ID, RBAC, Identidades Gerenciadas), armazenamento (Contas de Armazenamento), computação (Máquinas Virtuais, AKS), aplicação (App Service, Functions, Logic Apps), automação (Contas de Automação, modelos ARM), segredos e chaves (Key Vault) e rede.

Google Cloud Platform (GCP)

Identidade (IAM, Contas de Serviço), armazenamento (Cloud Storage), computação (Compute Engine, GKE, Cloud Run, Cloud Functions), dados (Cloud SQL), build e integração (Cloud Build, Pub/Sub), segredos e chaves (Secret Manager, KMS) e pivotagem no Workspace.

Plataformas de aplicação gerenciadas (PaaS / BaaS)

Serviços de plataforma cujo modelo de segurança é baseado em chaves de API, tokens e controles de camada de aplicação em vez de IAM de infraestrutura. Suas fases são adaptadas de acordo.

• Supabase – o modelo de chave anon vs service_role, a API PostgREST gerada automaticamente e o Row Level Security (RLS) do PostgreSQL, além de Auth, Storage e Edge Functions.
• Vercel – tokens de acesso e funções de equipe, segredos em variáveis de ambiente, proteção de implantação e implantações de preview, além de funções serverless / edge.

Usando o guia

1. Estabeleça o acesso disponível para o engajamento (provedor, forma de credencial, nível de privilégio, escopo) – isso determina quais fases e páginas estão em jogo.
2. Trabalhe as fases em ordem: entenda a plataforma, teste a superfície externa e, então (com credenciais), enumere, escale, mova-se lateralmente e avalie pós-exploração e persistência.
3. Para cada descoberta, use as seções Detecção & Logging e Remediação & Hardening para dar ao proprietário do ativo uma saída defensiva acionável – não apenas uma narrativa de ataque.

Autorização e regras de engajamento. Testar ambientes de nuvem está sujeito às políticas de uso aceitável e de teste de penetração de cada provedor. Ações de negação de serviço e destrutivas são proibidas por padrão na AWS, no Azure e no GCP sem aprovação prévia. Teste sempre apenas ambientes que você esteja explicitamente autorizado a avaliar, dentro do escopo acordado.

Contribuindo

O CSTG é conduzido pela comunidade. Novas páginas de serviço, técnicas adicionais, correções e cobertura de provedores são bem-vindas – consulte STRUCTURE.md para o formato da página e os modelos de issue em .github/ISSUE_TEMPLATE/. Todas as contribuições são licenciadas sob CC BY-SA 4.0.

Líderes do Projeto

• Stefano Di Paola
• Jamieson O'Reilly

Licença

Este trabalho é licenciado sob uma Licença Internacional Creative Commons Atribuição-CompartilhaIgual 4.0.