A migração para cloud virou realidade consolidada no Brasil. AWS, Azure e GCP hospedam sistemas críticos de empresas de todos os tamanhos, de startups a bancos. Mas existe um equívoco que persiste: a ideia de que "estar na nuvem" automaticamente significa "estar seguro".
Os provedores de cloud cuidam da segurança da nuvem (hardware, rede física, hipervisores). A sua empresa cuida da segurança na nuvem (configurações, identidades, dados, aplicações). E é justamente nesse modelo de responsabilidade compartilhada que a maioria das falhas acontece.
O modelo de responsabilidade compartilhada
Cada provedor define com clareza o que é responsabilidade dele e o que é do cliente.
O provedor garante segurança física dos data centers, hardware, backbone de rede, hipervisor e disponibilidade da infraestrutura base.
O cliente garante configuração de serviços, gerenciamento de identidades e acessos (IAM), criptografia, segmentação de rede, firewalls, logging, monitoramento e patching de sistemas e aplicações.
Na prática, violações de segurança em cloud quase nunca são falhas do provedor. São configurações incorretas feitas pelo cliente. E é exatamente isso que um pentest de cloud avalia.
Os vetores de ataque mais comuns
IAM permissivo demais
IAM é o sistema nervoso central de qualquer ambiente cloud. Políticas mal configuradas são o vetor mais explorado e mais perigoso.
O que encontramos com frequência: roles com permissões de administrador atribuídas a serviços que só precisam de leitura, políticas com wildcards (Action: "*", Resource: "*") aplicadas sem critério, credenciais de longa duração guardadas em código-fonte ou variáveis de ambiente, e roles que podem ser assumidas por qualquer conta externa.
Com uma credencial de IAM permissiva demais, um atacante pode escalar de um acesso limitado para controle total do ambiente. Isso inclui acesso a todos os dados, capacidade de criar novas credenciais e até possibilidade de apagar logs.
Storage público
Buckets S3 na AWS, Blob Storage no Azure e Cloud Storage no GCP são frequentemente configurados como públicos, seja por erro, conveniência ou desconhecimento.
Já encontramos buckets S3 com ACL pública contendo backups de banco de dados, logs de aplicação com dados pessoais, credenciais e chaves de API. Também containers Azure Blob com acesso anônimo e objetos com URLs previsíveis que permitem enumeração.
Secrets no código
Chaves de API, tokens de acesso, senhas de banco e outros segredos hardcoded em código-fonte ou arquivos de configuração são uma das formas mais comuns de conseguir acesso inicial a ambientes cloud.
Os cenários que mais encontramos: repositórios Git (inclusive no histórico de commits) contendo access keys da AWS, variáveis de ambiente em Lambda ou Cloud Functions com credenciais de produção, Dockerfiles com secrets no build e arquivos de state do Terraform com credenciais em texto plano.
Metadados de instância
O serviço de metadados (disponível em 169.254.169.254 na AWS e GCP) fornece credenciais temporárias associadas à instância. Se um atacante consegue SSRF ou execução de código remoto numa aplicação rodando em EC2, pode acessar o IMDS e obter credenciais válidas.
Na AWS, o IMDSv1 (sem autenticação) ainda é o padrão em muitas instâncias. O IMDSv2 exige um token e mitiga bastante esse vetor, mas precisa ser habilitado de forma explícita.
Segmentação fraca
Em ambientes on-premises, segmentação de rede é física e visível. Em cloud, é virtual e fácil de negligenciar. Encontramos regularmente security groups abertos para o mundo (0.0.0.0/0 em SSH e RDP), VPCs sem separação entre dev, staging e produção, e serviços internos expostos diretamente na internet.
O que o pentest de cloud avalia
Um pentest focado em cloud analisa três camadas.
A camada de identidade e acesso cobre revisão de políticas IAM, roles, grupos, service accounts, MFA, políticas de senha, credenciais de longa duração e relacionamentos de confiança entre contas.
A camada de configuração olha para storage, compute (instâncias, containers, serverless), networking (VPCs, security groups, NACLs), logging (CloudTrail, Azure Monitor, Cloud Audit Logs), criptografia (KMS, chaves) e aderência a CIS Benchmarks.
A camada de aplicação testa as mesmas vulnerabilidades web de sempre (SQLi, XSS, SSRF, broken access control), mas com o agravante de que em cloud um SSRF pode levar ao IMDS e escalar para controle total do ambiente.
Diferenças entre os provedores
Os conceitos são parecidos, mas cada provedor tem sua nomenclatura e particularidades.
Na AWS, o modelo gira em torno de IAM com policies JSON, S3 com ACLs e bucket policies, EC2 com security groups, VPC com NACLs e CloudTrail para auditoria. Ferramentas de referência para análise incluem ScoutSuite e Prowler.
No Azure, o centro é o Entra ID (antigo Azure AD) com RBAC, Blob Storage com access levels, NSGs para firewall e Azure Monitor para logging. Um ponto de atenção: a integração com Active Directory on-premises via Azure AD Connect cria vetores de ataque híbridos que são especialmente interessantes para um atacante.
No GCP, o modelo usa IAM com bindings, Cloud Storage com ACLs e IAM policies, VPC com firewall rules e Cloud Audit Logs. O ponto crítico aqui são as service accounts, que frequentemente têm permissões muito acima do necessário.
Regras dos provedores sobre pentest
Um ponto importante: os provedores têm políticas específicas sobre testes de segurança em seus ambientes.
A AWS não exige notificação prévia para a maioria dos testes em serviços como EC2, RDS, Lambda e API Gateway. Proíbe testes de DDoS, DNS zone walking e port flooding.
O Azure também não exige aviso prévio, desde que o teste siga as regras de engajamento publicadas. Proíbe ataques que afetem outros tenants e DDoS.
O GCP segue a mesma linha: sem notificação prévia, desde que o teste se limite aos recursos do cliente.
Em todos os casos, o pentest atua sobre os recursos e configurações do cliente, nunca sobre a infraestrutura do provedor em si.
Os erros que mais vemos
Depois de muitos pentests em cloud, alguns padrões de erro se repetem o tempo todo.
O primeiro é a mentalidade de "funciona, então não mexo". Equipes que montaram o ambiente para funcionar, não para ser seguro. Security groups com regras permissivas desde o dia 1 que nunca foram revisadas.
O segundo são credenciais que nunca expiram. Access keys criadas há 3 anos, nunca rotacionadas, usadas por scripts que ninguém lembra onde estão.
O terceiro é ambiente de dev como porta de entrada. Segurança concentrada em produção enquanto dev e staging dividem a mesma VPC e têm credenciais com acesso a recursos de produção.
O quarto é logging desabilitado. CloudTrail desativado em regiões "não usadas" (atacantes usam regiões inesperadas de propósito), ou logs retidos por apenas 7 dias.
E o quinto é infraestrutura como código sem revisão de segurança. Terraform e CloudFormation criam recursos em segundos, incluindo configurações inseguras. Sem checagem de segurança no pipeline, vulnerabilidades são deployadas automaticamente a cada push.
Recomendações práticas
Para organizações que operam em cloud e querem reduzir risco de forma concreta: adotar menor privilégio em IAM de forma rigorosa, implementar IMDSv2 em todas as instâncias EC2, habilitar logging completo em todas as regiões com retenção adequada, rotacionar credenciais e migrar para roles com credenciais temporárias, segmentar ambientes em VPCs separadas, usar ferramentas de CSPM para monitoramento contínuo e fazer pentest de cloud pelo menos uma vez por ano.
Cloud não é inerentemente insegura, mas também não é inerentemente segura. A segurança do seu ambiente depende das decisões de configuração que sua equipe toma todo dia. O pentest revela quais dessas decisões criaram riscos que precisam ser tratados.
