Pentest em Cloud: Guia Completo para AWS, Azure e GCP

Resumo:

• Os vetores são diferentes entre pentest em cloud e pentest em aplicação: IAM com permissões excessivas, buckets expostos, serviços de metadados vulneráveis e movimentação lateral entre serviços são riscos exclusivos do ambiente de nuvem.
• Cada provedor tem características próprias: AWS centraliza os riscos em IAM e S3, Azure em Entra ID, RBAC e identidades gerenciadas, e GCP no modelo de contas de serviço e hierarquia de recursos.
• A responsabilidade de segurança na nuvem é compartilhada, mas assimétrica. Enquanto o provedor protege a infraestrutura, a empresa é responsável por configuração, identidade, dados e controle de acesso. A maioria das violações acontece na parte da empresa.
• Para compliance, pentest de cloud é exigido por BCB 538/2025 (ativos de terceiros no escopo), PCI DSS 4.0 (CDE em cloud), ISO 27001 e SOC 2 Type 2. Em todos os casos, o pentest precisa cobrir os ativos de cloud que fazem parte do ambiente crítico.
• O custo de um pentest de cloud varia conforme o escopo: de projetos menores focados em um único provedor até avaliações complexas de múltiplas contas, regiões e workloads.

Muitas empresas já testaram a segurança das aplicações web, mas nunca chegaram ao ambiente de nuvem. Isso é um problema, porque o pentest de aplicação e pentest de nuvem cobrem superfícies de ataque diferentes 

Configurações incorretas em AWS, Azure e GCP são hoje a principal causa de violações de dados em ambientes corporativos. Permissões IAM excessivas, buckets S3 públicos por erro de configuração, serviços de metadados vulneráveis e movimentação lateral entre serviços são vetores ausentes do escopo de um pentest de aplicação web.

Este artigo explica o que é pentest em cloud, o que é testado em cada provedor, como ele se encaixa em exigências regulatórias e como contratar o serviço certo para o seu ambiente.

O que é pentest em cloud?

Pentest em cloud é uma avaliação de segurança manual do ambiente de nuvem, da configuração de IAM, dos serviços de armazenamento, das instâncias de computação, das funções serverless, dos clusters de containers, dos controles de rede e das permissões entre serviços. 

Esse teste é conduzido por um profissional certificado com o objetivo de identificar vulnerabilidades exploráveis antes que um atacante real as encontre.

Ferramentas como AWS Security Hub, Microsoft Defender for Cloud e Security Command Center do GCP fazem uma revisão de configuração automatizada, mas o pentest vai além disso: um profissional tenta encadear as configurações incorretas em caminhos de ataque reais, seguindo a mesma lógica que um atacante usaria para escalar privilégios de uma chave de API comprometida até o acesso root.

Por que pentest de cloud é diferente de pentest de aplicação web?

Responsabilidade compartilhada: onde a maioria erra 

AWS, Azure e GCP operam sob o modelo de responsabilidade compartilhada: o provedor é responsável pela segurança da infraestrutura (hardware, rede física e hipervisor). A empresa é responsável por tudo o que roda sobre ela, como configuração, identidade, dados, controle de acesso e criptografia.

O provedor não vai impedir que você crie um bucket S3 público por acidente, que configure permissões IAM excessivas ou que exponha um metadata service sem proteção. Essas são responsabilidades da empresa. O pentest de cloud avalia o que a empresa configurou, como configurou e se um atacante consegue explorar o resultado.

O que é testado em cada provedor

AWS: Amazon Web Services

Em ambientes AWS, as áreas de maior risco concentram-se em identidade e acesso. IAM com permissões excessivas é o vetor mais comum: funções com permissões excessivamente amplas, políticas que permitem ações além do necessário e caminhos de escalação de privilégios que um atacante com acesso inicial consegue explorar.

• IAM: funções, políticas, limites de permissões e caminhos de escalação de privilégios.
• S3: buckets expostos publicamente, ACLs incorretas e políticas de bucket permissivas.
• EC2: serviços de metadados (IMDSv1 vulnerável), grupos de segurança e exposição de instâncias.
• Lambda: permissões excessivas, variáveis de ambiente com credenciais e injeção de eventos.
• RDS e bancos de dados: exposição pública, credenciais fracas e snapshots acessíveis.
• CloudTrail e logging: verificação se eventos críticos estão sendo registrados.
• Movimentação lateral: encadeamento de permissões entre serviços para ampliar o acesso.

Azure: Microsoft Azure

Ambientes Azure têm relação próxima entre os recursos e o Microsoft Entra ID (antigo Azure AD). A maioria dos caminhos de ataque passa por identidade: identidades gerenciadas, principais de serviço, acesso condicional e atribuições RBAC são as áreas de maior exposição.

• Microsoft Entra ID: registros de aplicativos, acesso condicional e funções administrativas.
• RBAC: atribuições excessivas e diretores de serviço com permissões amplas.
• Managed identities: validação de permissões e potencial para escalação de privilégios.
• Azure Storage: blob containers públicos e tokens SAS com permissões excessivas.
• Key Vault: acesso a segredos e certificados, e políticas de acesso.
• App Services e Azure Functions: variáveis de ambiente e abuso de identidades gerenciadas.
• AKS (Kubernetes): configuração do cluster, políticas de rede e RBAC do Kubernetes.

GCP: Google Cloud Platform

O GCP tem estrutura de hierarquia de recursos e contas de serviços com características próprias. O modelo de contas de serviço é o principal vetor de ataque, já que permissões excessivas ou chaves expostas permitem o escalação de privilégios e acesso a recursos críticos.

• Contas de serviço: permissões, chaves, personificação e escalação de token.
• Hierarquia de recursos: projetos, pastas e políticas de nível orgânico.
• Cloud Storage: buckets públicos, ACLs e signed URLs.
• Compute Engine: servidor de metadados, associações de contas de serviço e regras de firewall.
• Funções de Cloud: permissões, gatilhos e variáveis de ambiente.
• BigQuery e Cloud SQL: acesso a dados e permissões de dataset.
• Workload Identity Federation: configurações de confiança e abuso federal.

Vetores comuns a todos os provedores

• Exploração de serviços de metadados: acesso às credenciais temporárias via SSRF ou acesso interno.
• Exposição de credenciais: chaves hardcoded em repositórios e variáveis de ambiente ou logs.
• Abuso de confiança inter-serviço: exploração de relações de confiança entre serviços.
• Movimentação lateral: uso de permissões iniciais para ampliar o acesso progressivamente.
• Gaps de logging: identificação de ações que não geram log e podem passar despercebidas.

Pentest de cloud e compliance: o que cada regulação exige

O pentest de cloud é relevante para compliance porque os provedores de nuvem fazem parte do ambiente crítico de muitas organizações e os reguladores exigem que esse ambiente seja testado.

AWS, Azure e GCP têm políticas de pentest que definem o que pode ser testado sem autorização prévia. Em geral, testes nos seus próprios recursos são permitidos, enquanto os testes que podem afetar a infraestrutura compartilhada exigem comunicação prévia com o provedor. Um fornecedor de pentest com experiência em cloud vai conhecer essas políticas e operar dentro delas.

Pentest de cloud vs. Cloud Security Review: qual a diferença?

Os dois serviços são complementares e frequentemente confundidos:

Cloud Security Review (também chamado de Cloud Configuration Assessment) é uma análise sistemática das configurações do ambiente de nuvem contra benchmarks de segurança, como CIS Benchmarks para AWS, Azure ou GCP, NIST ou frameworks do próprio provedor. 

Ele identifica desvios de boas práticas, falhas de configuração e exposições, sendo amplo em cobertura, mas menos profundo em exploração. 

O pentest de cloud vai além: parte das configurações incorretas identificadas e busca comprovar os caminhos de ataque reais, provando que a vulnerabilidade é explorada. Entrega evidência técnica que auditores e reguladores aceitam como demonstração de teste.

Para compliance, o pentest de cloud é o que fornece a evidência formal. O Cloud Security Review é o que mantém o ambiente com o menor número possível de configurações incorretas entre os ciclos de pentest. Os dois juntos formam um programa de cloud security mais robusto.

Como funciona um pentest de cloud 

• Escopo e autorização

Antes de qualquer teste, são definidos: quais provedores, quais contas/assinaturas/projetos, quais regiões, quais serviços e workloads serão testados. O escopo determina o custo, o prazo e o que será coberto. Testes em produção são feitos com janelas definidas para minimizar o impacto.

• Reconhecimento externo

O pentester mapeia o que está exposto publicamente: buckets acessíveis, endpoints de API, instâncias sem proteção, interfaces de gerenciamento acessíveis pela internet. Esta fase simula o ponto de vista de um atacante externo sem credenciais.

• Teste com acesso inicial (gray box)

Com uma credencial de baixo privilégio, simulando uma chave de API comprometida, um funcionário malicioso ou um token vazado, o pentester testa o potencial de escalada de privilégios e movimentação lateral no ambiente. 

• Análise de configuração

Revisão de políticas, IAM, Security Groups, ACLs, logs e configurações de compliance para identificar desvios que criam riscos sem exposição imediata. 

• Exploração e documentação de evidências

Cada achado é explorado e documentado com evidência: o comando executado, a resposta obtida, o recurso acessado indevidamente e a cadeia de permissões usada. Sem evidência, o achado não é válido para compliance.

• Relatório e remediação

O relatório inclui sumário executivo, cada achado com evidência e recomendação específica, e priorização por criticidade e impacto de negócio. Após as correções, o reteste confirma que os caminhos de ataque foram fechados.

Quanto custa um pentest de cloud?

O custo de um pentest de cloud varia conforme quatro variáveis principais:

• Número de provedores: um único provedor (só AWS, por exemplo) vs. ambiente multi-cloud (AWS + Azure + GCP).
• Número de contas/subscriptions/projetos: uma conta de produção vs. múltiplas contas em múltiplas regiões.
• Serviços no escopo: apenas IAM e S3 vs. cobertura completa incluindo Kubernetes, serverless e bancos de dados.
• Profundidade: revisão de configuração com exploração parcial vs. pentest completo com privilege escalation chains documentadas.

Um projeto focado em uma conta AWS com escopo definido tende a ser significativamente menor do que uma avaliação multi-cloud com múltiplos workloads.

A forma mais precisa de obter um valor é definir primeiro o escopo. Fornecedores que enviam proposta sem entender o ambiente quase sempre subestimam o trabalho ou entregam um serviço menor do que o necessário.

Como contratar pentest de cloud: o que avaliar

Experiência específica em cloud, não apenas em pentest

Pentest em aplicações web e pentest em cloud exigem conhecimentos diferentes. Verifique se o fornecedor tem profissionais com experiência documentada nos provedores do seu ambiente: certificações como AWS Security Specialty, CCSP ou certificações ofensivas específicas de cloud são indicadores relevantes.

Metodologia documentada para cloud

Peça que o fornecedor descreva como avalia IAM, como identifica caminhos de escalação de privilégios e como documenta a movimentação lateral. Fornecedores sérios conseguem explicar a metodologia com especificidade sobre cloud.

Relatório com evidência de exploração real

O relatório deve conter a cadeia de permissões explorada, os comandos executados e o acesso obtido indevidamente. Para compliance, auditores vão pedir evidência de exploração.

Alinhamento com as políticas dos provedores

AWS, Azure e GCP têm políticas definidas de pentest. Confirme que o fornecedor conhece e opera dentro dessas políticas, especialmente em relação a testes que podem afetar a infraestrutura compartilhada.

Reteste e documentação formal

O reteste após as correções confirma que os caminhos de ataque foram fechados. A carta de atestado é o documento que comprova que o teste foi realizado por profissional independente, necessário para BCB 538, PCI DSS e ISO 27001.

Perguntas que você deve fazer antes de contratar

• Quem vai executar o teste? Qual a experiência específica com AWS/Azure/GCP?
• Como vocês testam IAM privilege escalation? Podem descrever o processo?
• O escopo inclui o quê exatamente: contas, regiões, serviços?
• O relatório vai incluir os caminhos de ataque completos, com os comandos executados?
• O reteste está incluso? Por quanto tempo?
• Emitem carta de atestado formal?
• Como tratam as políticas de pentest dos provedores?

Seu ambiente de cloud foi migrado, mas ainda não foi testado? 

A Vantico realiza Cloud Security Review e Pentest de Cloud em AWS, Azure e GCP com relatório técnico, evidências de exploração e carta de atestado para compliance. 

Agende uma demo ao vivo conosco.

FAQ: Perguntas frequentes

O que é pentest em cloud?

Pentest em cloud é uma avaliação de segurança manual do ambiente de nuvem, configuração de IAM, storage, computação, funções serverless, containers e permissões entre serviços, conduzida por profissional certificado que tenta explorar vulnerabilidades reais. 

Diferente de uma revisão de configuração automatizada, o pentest prova que a vulnerabilidade é explorável no contexto do ambiente específico e documenta o caminho de ataque com evidência técnica.

Pentest de cloud é diferente de pentest de aplicação web?

Sim. O pentest de aplicação web testa a lógica da aplicação: injeção, autenticação quebrada, controle de acesso e lógica de negócio. Já o pentest de cloud testa a infraestrutura sobre a qual a aplicação roda, como as permissões IAM, configuração de armazenamento, exposição de instâncias e a movimentação lateral entre serviços. 

Os dois compartilham alguns vetores na borda (SSRF, APIs expostas e buckets públicos), mas a maior parte da cobertura é distinta. Muitas organizações que testam aplicações regularmente nunca testaram o ambiente de cloud.

O que é testado em um pentest de cloud AWS?

Em ambientes AWS, as principais áreas testadas são: IAM (funções, políticas e políticas de escalonamento de privilégios), S3 (buckets expostos e ACLs incorretas), EC2 (serviços de metadados e grupos de segurança), Lambda (permissões e injeção de eventos), RDS (exposição e credenciais), CloudTrail (gaps de logging) e movimentação lateral entre serviços. 

O vetor mais comum em ataques reais é IAM com permissões excessivas. Um atacante com acesso inicial a uma chave comprometida testa quais permissões consegue exercer e como ampliar o acesso progressivamente.

Pentest de cloud é obrigatório para compliance no Brasil?

Depende do framework. A BCB 538/2025 exige que ativos de terceiros integrados ao ambiente crítico (incluindo provedores de nuvem usados no ambiente do Pix e STR) estejam no escopo do pentest anual. 

O PCI DSS 4.0 exige pentest do CDE. Se o ambiente de processamento de cartões roda em cloud, o pentest deve cobrir esse ambiente. Já ISO 27001 e SOC 2 Type 2 exigem evidências de testes de segurança nos sistemas que processam dados sensíveis, incluindo cloud. 

Qual a diferença entre Cloud Security Review e pentest de cloud?

Cloud Security Review é uma análise sistemática das configurações do ambiente contra benchmarks de segurança (CIS Benchmarks e NIST). Ele identifica desvios de boas práticas e configurações incorretas, é mais amplo em cobertura. Já o Pentest de cloud vai além: parte das configurações incorretas e tenta explorar os caminhos de ataque reais, provando que a vulnerabilidade é explorável com evidência técnica. 

Para compliance, o pentest fornece a evidência formal que os auditores aceitam. O Cloud Security Review mantém o ambiente com o menor número de configurações incorretas entre os ciclos de pentest.

Quanto custa um pentest de cloud no Brasil?

O custo varia conforme o número de provedores, contas/assinaturas/projetos, regiões, serviços no escopo e profundidade do teste. Projetos focados em um único provedor com escopo definido são significativamente menores do que avaliações multi-cloud complexas. A forma mais precisa de obter um valor é definir o escopo antes. Fornecedores que enviam proposta sem entender o ambiente frequentemente subestimam o trabalho ou entregam um serviço menor do que o necessário. 

O provedor de nuvem (AWS, Azure e GCP) é responsável pela segurança do meu ambiente?

Não totalmente. AWS, Azure e GCP operam sob o modelo de responsabilidade compartilhada: o provedor é responsável pela segurança da infraestrutura subjacente. 

A empresa é responsável por configuração, identidade, dados e controle de acesso. O provedor não vai impedir que você crie um bucket público por erro, configure permissões excessivas ou exponha um serviço de metadados. Essas são responsabilidades da empresa e são os vetores mais explorados em ataques reais a ambientes de nuvem.

Quando contratar pentest de cloud?

Os principais gatilhos são: primeira migração para cloud (testar o ambiente antes de colocar dados críticos), após mudanças significativas de configuração ou arquitetura, para atender exigências de compliance (BCB 538, PCI DSS, ISO 27001 e SOC 2), antes de due diligence de M&A ou captação de investimento, e como parte de um programa anual de segurança.