Cloud Security: Atacando e Defendendo AWS, Azure e GCP

Em 2024, a Verizon DBIR revelou que 68% dos incidentes de segurança em ambientes cloud foram causados por configurações incorretas — não por exploits sofisticados ou zero-days. Um bucket S3 exposto. Um security group com porta 22 aberta para o mundo. Uma IAM role com permissões administrativas atribuída a uma função de leitura. Falhas humanas banais que custam milhões.

A migração para a nuvem transformou a superfície de ataque das organizações. Antes, o perímetro era um firewall físico. Hoje, a infraestrutura é código, as credenciais são API keys, e o atacante precisa apenas de uma conta com privilégios errados para comprometer um ambiente inteiro. O CEH v13 dedica atenção especial a esse cenário porque é onde a maioria dos pentests corporativos acontece agora.

Este artigo cobre como atacar e defender ambientes em AWS, Azure e GCP, passando por containers, serverless e ferramentas de avaliação de segurança cloud. Ao final, você vai entender por que identity is the new perimeter — e como explorar isso.

📊 Dica do Hacker: Antes de qualquer engajamento cloud, entenda o modelo de responsabilidade compartilhada do provider. Você não pode avaliar o que não sabe quem é responsável por proteger.

Cloud Security Fundamentals

O Shared Responsibility Model

Todo provedor cloud opera sob um modelo de responsabilidade compartilhada. Ele garante a segurança da nuvem; você garante a segurança na nuvem. Parece simples, mas é aí que a maioria das organizações falha.

No caso da AWS, por exemplo, a Amazon é responsável pela segurança física dos data centers, pela camada de virtualização (hypervisor), pela rede subjacente e pelos serviços gerenciados (DynamoDB, RDS gerenciado, Lambda). O cliente é responsável por tudo que roda em cima: AMIs, configurações de rede (VPC, security groups, NACLs), IAM, dados em repouso e em trânsito, e a aplicação em si.

Azure e GCP seguem lógica idêntica com terminologia própria. O ponto crítico: em IaaS (EC2, VMs), o cliente tem mais controle e mais responsabilidade. Em PaaS (App Service, Cloud Run), o provider absorve parte do gerenciamento do SO. Em SaaS (Office 365, G Suite), quase tudo é do provider — mas o cliente ainda gerencia identidade e dados.

Identity Is the New Perimeter

Não há mais firewall de perímetro no sentido tradicional. O acesso à infraestrutura cloud é via API, autenticado por credenciais (API keys, tokens, SSO). Se um atacante obtém credenciais válidas, ele bypassa completamente o conceito de “rede interna” — porque não existe mais rede interna. Um usuário autenticado com a role certa pode acessar qualquer recurso na conta, de qualquer lugar do mundo.

Isso faz do IAM (Identity and Access Management) o componente mais crítico de qualquer ambiente cloud. Uma policy mal escrita no IAM é mais perigosa que um servidor desatualizado.

📊 Dica do Hacker: Em pentests cloud, o primeiro objetivo é sempre enumeração de identidades. Listar usuários, roles, policies e permissões dá o mapa completo do que é explorável. Muitas vezes, a própria enumeração revela a escalada antes de qualquer exploit.

Misconfigurations como Principal Vetor de Ataque

Se existe um consenso na indústria de segurança cloud, é este: misconfigurations são a causa número 1 de breaches em nuvem. O Gartner estima que até 2025, 99% dos problemas de segurança cloud serão culpa do cliente, não do provider.

As misconfigurations mais comuns e impactantes:

S3 buckets públicos: Apenas um clique errado no AWS Console torna um bucket acessível para qualquer pessoa na internet. Casos notáveis incluem dados de 200 milhões de eleitores americanos expostos por um bucket mal configurado da Deep Root Analytics.
Security groups abertos: Regras que permitem inbound 0.0.0.0/0 em portas como 22 (SSH), 3306 (MySQL) ou 3389 (RDP). Um scanner como Shodan encontra esses serviços em segundos.
IAM overprivileged: Permissões administrativas concedidas a usuários ou aplicações que não precisam. O princípio do menor privilégio existe por um motivo, mas na prática quase ninguém aplica.
Snapshots públicos: Snapshots de EBS compartilhados publicamente podem conter dados sensíveis — cópias inteiras de volumes de produção.
Storage sem criptografia: S3 buckets, Azure Blob Storage e GCP Cloud Storage criados sem Server-Side Encryption (SSE). Se um bucket é exposto, os dados ficam em plaintext.
Logs desabilitados: CloudTrail desligado, Azure Activity Logs sem retenção, GCP Audit Logs desativados. Sem logs, é impossível investigar um incidente.

A raiz do problema é quase sempre a mesma: equipes DevOps e desenvolvedores priorizam velocidade sobre segurança. Um bucket S3 é criado, o app funciona, ninguém volta para revisar as permissões. Em ambientes com dezenas de contas cloud, centenas de buckets e milhares de IAM policies, o problema escala exponencialmente.

AWS Security

A AWS é a líder de mercado cloud (31% de share em 2024) e, consequentemente, o alvo mais comum em pentests e ataques reais. Entender os vetores de ataque AWS é fundamental para qualquer ethical hacker.

S3 — Simple Storage Service

O S3 é o serviço mais explorado na AWS, e por bons motivos. Bucket policies e ACLs são complexos, o console facilita configurações públicas acidentais, e o volume de dados armazenado é colossal.

Vetores de ataque:

Enumeração de buckets: Se o nome do bucket segue um padrão previsível (empresa-projeto-dados), um atacante pode enumerar buckets via DNS — cada bucket S3 resolve para um endpoint próprio. Ferramentas como s3scanner automatizam isso.
Listagem de objetos: Se a policy do bucket permite s3:ListBucket para Principal *, qualquer um lista os arquivos. Não precisa de autenticação AWS.
Download de dados: Se permite s3:GetObject para *, qualquer arquivo é acessível via URL direta ou via AWS CLI.
Bucket takeover: Se um bucket é deletado mas referenciado por outro serviço (CloudFront, por exemplo), um atacante pode criar um bucket com o mesmo nome na sua própria conta e assumir o tráfego.

Defesa: Ativar S3 Block Public Access em nível de conta (não apenas por bucket). Usar bucket policies explícitas (nunca ACLs). Aplicar SSE-S3 ou SSE-KMS para todos os buckets. Habilitar S3 Server Access Logging e CloudTrail data events para auditoria.

IAM — Identity and Access Management

O IAM é o controle de acesso central da AWS. Se você compromete uma credencial IAM válida, você compromete tudo que essa credencial tem permissão para acessar.

Vetores de ataque:

Credenciais hardcoded: Access keys expostas em código-fonte (GitHub, repositórios públicos) são encontradas por bots em minutos. A AWS publica publicamente se uma chave foi encontrada, mas o dano pode ser imediato.
Escalada de privilégios: Um atacante com permissões limitadas pode escalar para administrador explorando policies permissivas. Exemplo: a capacidade de criar uma nova versão de uma Lambda function que usa uma role admin. Ou a permissão iam:PassRole combinada com lambda:CreateFunction.
AssumeRole abuse: Se uma role permite que qualquer usuário autenticado assuma ela (Principal: "*"), um atacante com uma conta AWS qualquer pode assumir os privilégios dessa role.

Defesa: Aplicar minimum privilege rigorosamente — cada policy deve permitir apenas as actions e resources necessários. Usar MFA obrigatório para todos os usuários humanos (via IAM condition key aws:MultiFactorAuthPresent). Rotacionar access keys a cada 90 dias. Usar roles em vez de access keys para workloads. Implementar AWS Organizations SCPs (Service Control Policies) como guardrails de conta.

Security Groups

Security groups são stateful firewalls em nível de instância. O problema: são allow-only — se uma regra permite inbound de qualquer IP, nada é negado explicitamente.

Vetores: Portas de gerenciamento abertas (22, 3389, 5432, 3306, 6379) para 0.0.0.0/0. Shodan e Censys indexam esses serviços automaticamente. Um banco de dados exposto na porta 3306 para o mundo é um convite para brute force e exfiltração.

Defesa: Permitir inbound apenas de CIDRs específicos. Usar AWS Systems Manager Session Manager para acesso SSH sem expor porta 22. Implementar regras restritivas como padrão e monitorar com VPC flow logs para detectar tráfego anômalo.

CloudTrail e GuardDuty

CloudTrail registra todas as chamadas de API na conta. Se não estiver habilitado em todas as regiões (incluindo us-east-1 como região global), um atacante pode operar em regiões sem logs. GuardDuty é o serviço de threat detection da AWS — analisa CloudTrail, VPC Flow Logs e DNS logs para identificar comportamento malicioso.

Ataque: Se CloudTrail não está habilitado, um atacante pode desabilitá-lo antes de agir (se tiver permissão). Se GuardDuty não está ativo, nenhum alerta é gerado. É comum encontrar contas prod com ambos desabilitados.

SSRF via Metadata (169.254.169.254)

Este é um dos ataques mais clássicos em cloud. A instância EC2 acessa um endpoint de metadata em 169.254.169.254 que expõe credenciais temporárias (via IMDSv1 ou IMDSv2). Se uma aplicação rodando na instância é vulnerável a SSRF (Server-Side Request Forgery), o atacante pode fazer a aplicação requisitar esse endpoint e obter as credenciais da instância.

Exemplo prático: Uma aplicação web tem um parâmetro url que faz fetch de conteúdo externo. O atacante envia url=http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name. A aplicação faz a requisição internamente, o IMDS retorna o access key, secret key e session token da role IAM associada à instância. Com essas credenciais, o atacante pode acessar qualquer recurso que a role permite.

⚠️ Atenção: Migre para IMDSv2 (requer token de sessão via PUT request) em todas as instâncias. O IMDSv1 é vulnerável a SSRF trivial e deveria estar desabilitado em qualquer ambiente sério. A AWS já recomenda isso como padrão, mas muitas contas ainda rodam IMDSv1.

Azure Security

Azure é a segunda maior plataforma cloud (25% de share) e domina em ambientes enterprise, especialmente organizações que já usam Microsoft 365 e Active Directory. Isso cria um ecossistema único onde a identidade é central — e explorável.

Azure AD / Microsoft Entra ID

O Azure Active Directory (agora rebatizado Microsoft Entra ID) é o provedor de identidade central do Azure. Ele autentica usuários, aplicações e serviços — e é o ponto de falha mais crítico.

Vetores de ataque:

Service principal abuse: App registrations no Entra ID criam service principals com permissões. Se um secret ou certificate é vazado, o atacante autentica como a aplicação e assume todas as permissões dela. Muitas aplicações têm permissões de Contributor ou Owner no subscription.
Phishing via OAuth: Consent phishing induz usuários a aprovarem um aplicativo malicioso que solicita permissões extensas (Mail.Read, Files.Read.All, User.Read.All). Uma vez aprovado, o app acessa dados sem interação adicional.
Brute force de senhas: Com o login padrão do Entra ID (login.microsoftonline.com), atacantes podem tentar brute force de credenciais. Sem proteção como Conditional Access e MFA, contas caem rápido.
Token theft: Se um atacante compromete uma estação de trabalho, pode extrair tokens de sessão do cache do navegador ou de ferramentas como Azure CLI (~/.azure/accessTokens.json).

Defesa: MFA obrigatório para todos os usuários. Implementar Conditional Access Policies (exigir MFA, bloquear logins de países suspeitos, exigir dispositivos compliant). Usar Privileged Identity Management (PIM) para just-in-time access a roles privilegiadas. Auditar regularmente app registrations e remover permissões desnecessárias.

Storage Accounts e Key Vault

Azure Blob Storage é o equivalente ao S3. Misconfigurações similares: containers configurados como públicos, access keys hardcoded, SAS tokens com permissões excessivas.

Azure Key Vault armazena secrets, chaves e certificados. Se um atacante obtém acesso ao Key Vault (via permissões de Key Vault Contributor ou uma managed identity com acesso), ele tem acesso a todas as credenciais centralizadas — um single point of failure explosivo.

Defesa: Configurar network rules no Storage Account para permitir acesso apenas de subnets específicas. Usar Private Endpoints para Key Vault. Desabilitar acesso público. Rotacionar SAS tokens e storage keys regularmente.

Network Security Groups (NSGs)

NSGs são os firewalls da Azure, aplicados em nível de subnet ou NIC. Funcionam de forma similar aos security groups da AWS, mas com a vantagem de suportar Application Security Groups (ASGs) para agrupar VMs por função e simplificar regras.

O mesmo problema se aplica: regras permissivas (0.0.0.0/0) em portas de gerenciamento são encontradas em quase todo ambiente Azure de tamanho considerável.

Defender for Cloud

O Microsoft Defender for Cloud (antigo Azure Security Center) é a plataforma CSPM/MDR da Azure. Ele avalia configurações, identifica vulnerabilidades e pode aplicar automaticamente proteções. O tier gratuito cobre avaliação de posture; o tier pago (Defender for Servers, Defender for Storage, etc.) adiciona proteção ativa.

Na perspectiva do atacante, se o Defender for Cloud não está ativo, o ambiente provavelmente tem misconfigurations por toda parte. Se está ativo mas os alerts são ignorados, o efeito é o mesmo.

GCP Security

O GCP tem uma abordagem de IAM diferente da AWS e Azure — everything is a resource, e o controle de acesso é unificado pelo Cloud IAM. Isso cria flexibilidade, mas também complexidade.

IAM — Service Accounts e Roles

O GCP usa service accounts para workloads, diferente das IAM roles da AWS. Cada service account tem um email (nome@projeto.iam.gserviceaccount.com) e pode ter keys (JSON) ou ser acessada via default credentials.

Vetores de ataque:

Service account keys vazadas: Chaves JSON no GitHub são um dos vazamentos mais comuns. Uma vez com a key, o atacante autentica e tem todas as permissões da service account.
Default service accounts: O Compute Engine cria automaticamente a default service account ([PROJECT_NUMBER]-compute@developer.gserviceaccount.com) com permissões de Editor — que é mais permissiva do que a maioria precisa.
Impersonation via IAM: Se um atacante obtém a permissão iam.serviceAccounts.actAs, ele pode impersonar qualquer service account no projeto.

Defesa: Criar service accounts dedicadas para cada workload (nunca usar a default). Remover permissões Editor/Owner e atribuir roles granulares. Desabilitar criação de keys quando possível (usar workload identity). Habilitar Organization Policy que restringe creation de keys.

Cloud Storage e VPC Service Perimeters

GCP Cloud Storage segue o mesmo padrão de S3 e Blob Storage: buckets com IAM policies ou ACLs. Buckets podem ser acessados publicamente se a IAM permite storage.objects.get para allUsers ou allAuthenticatedUsers.

Uma ferramenta nativa poderosa é o VPC Service Perimeter — uma política que restringe quais recursos do GCP podem ser acessados de fora de uma VPC. Se configurado corretamente, até mesmo buckets públicos se tornam inacessíveis de fora do perímetro. Muitas organizações não implementam isso, perdendo uma camada de defesa significativa.

Security Command Center (SCC)

O Security Command Center é a ferramenta CSPM do GCP. Identifica vulnerabilidades, misconfigurations e ameaças em todos os recursos do projeto. O tier Standard é gratuito (descoberta de assets); o Premium adiciona findings avançados, threat detection e compliance.

Container Security

Containers (Docker, Kubernetes) são o runtime padrão para aplicações cloud-native. Eles introduzem uma superfície de ataque completamente nova que precisa ser avaliada separadamente.

Docker

Vetores de ataque em containers:

Imagens vulneráveis: Imagens base com CVEs conhecidos. Um container rodando Alpine 3.15 com OpenSSL desatualizado é tão vulnerável quanto um servidor bare metal.
Contêineres privilegiados: Se um container roda com --privileged, ele tem acesso total ao host — incluindo dispositivos de bloco, network interfaces e capacidade de montar o filesystem do host. Um pod escape trivial.
Volume mounts perigosos: Montar / do host, /var/run/docker.sock (o socket do Docker daemon), ou /etc permite que um processo dentro do container comprometa o host.
Docker API exposta: O Docker daemon escuta em tcp://0.0.0.0:2375 (sem TLS). Qualquer um que conectar pode criar containers, montar volumes e executar comandos como root no host. Shodan encontra milhares desses endpoints.

Defesa: Nunca rodar --privileged. Usar read-only filesystem (--read-only). Montar apenas volumes necessários. Usar imagens oficiais e mantê-las atualizadas. Escutar o Docker daemon apenas em Unix socket (/var/run/docker.sock), nunca em TCP aberto. Implementar AppArmor ou Seccomp profiles.

Kubernetes

Kubernetes é um sistema distribuído complexo, e a complexidade gera misconfigurations em escala.

Vetores de ataque:

RBAC mal configurado: Um ClusterRoleBinding que concede cluster-admin a um service account de uma aplicação qualquer. Ou uma role com create pods em um namespace onde existem pods privilegiados.
Dashboard exposto: O Kubernetes Dashboard por padrão não tem autenticação forte. Se exposto na porta 8001 sem proxy de autenticação, qualquer um com acesso web pode executar comandos no cluster.
Pod escape: Um pod com hostPID: true, hostNetwork: true, ou mounts do host pode comprometer o node. Um container com privileged: true dentro de um pod é equivalente a root no host.
etcd desprotegido: O etcd armazena todos os secrets do cluster (em plaintext por padrão, sem encryption at rest). Se o endpoint do etcd (porta 2379) é acessível sem TLS/client certs, o atacante lê todos os secrets, tokens e configurações.

Defesa: Habilitar RBAC (nunca usar ABAC). Aplicar Pod Security Standards (restricted baseline no mínimo). Implementar Network Policies para segmentação entre pods. Usar secrets encryption at rest. Habilitar audit logging. Proteger o etcd com mTLS e network policies.

Ferramentas de Assessment para Containers

Trivy: Scanner de vulnerabilidades para imagens de container, filesystems e repositories Git. Open source, rápido, suporta SBOM e reporta CVEs de múltiplas fontes.
kube-bench: Implementa os checks do CIS Kubernetes Benchmark. Gera um relatório de compliance com scores por categoria.
kube-hunter: Ferramenta ativa que procura vulnerabilidades em clusters Kubernetes. Pode rodar como pod dentro do cluster ou externamente, simulando um atacante.

Serverless Attacks

Serverless (AWS Lambda, Azure Functions, Google Cloud Functions) muda o paradigma de segurança. Não há servidor para gerenciar, mas o código da função, o IAM role associado e os event sources criam novos vetores.

Vetores de ataque:

Function injection: Se a função serverless processa input do usuário (ex: um webhook HTTP), injeção de código pode ocorrer no contexto da função. Em Python, eval() de input do usuário. Em Node.js, child_process.exec() com parâmetros controláveis.
Event injection: Funções são triggeradas por eventos (S3 put, SQS message, SNS notification, API Gateway request). Se o atacante pode injetar um evento malicioso (ex: fazer upload de um arquivo para um bucket S3 que triggera uma Lambda), ele controla a execução.
IAM role abuse: A IAM role da função serverless é frequentemente a chave do reino. Se uma função Lambda tem permissão para acessar outros serviços (DynamoDB, S3, Secrets Manager), comprometer a função equivale a comprometer esses serviços. A função roda com as credenciais da role — e essas credenciais ficam disponíveis via environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN).
Cold start information leakage: No cold start, a função pode inicializar com dados de execuções anteriores se variáveis de ambiente ou volumes temporários não são limpos. Embora o isolamento entre execuções seja garantido pelo provider, bibliotecas mal escritas podem causar leakage.

Defesa: Validar e sanitizar todo input. Nunca usar eval() ou equivalentes com dados externos. Atribuir o mínimo de permissões IAM para cada função (uma função que lê do S3 não precisa de permissão de escrita). Implementar resource-based policies para restringir quais serviços podem invocar a função. Habilitar AWS Lambda Powertools para logging estruturado e tracing.

Ferramentas de Avaliação Cloud

Um pentest cloud exige ferramentas especializadas. Diferente de um pentest de rede tradicional onde você usa Nmap e Metasploit, em cloud você avalia configurações, permissions e APIs.

ScoutSuite

O ScoutSuite é uma ferramenta open source de auditoria multi-cloud. Conecta via API às contas AWS, Azure e GCP e gera um relatório HTML com todos os findings de segurança. Analisa IAM policies, S3 bucket configs, security groups, encryption settings, logging configurations e muito mais.

Uso típico:

# AWS
python scout.py aws --access-key-id AKIA... --secret-access-key ...

# Azure
python scout.py azure --user-id ... --password ...

# GCP
python scout.py gcp --project-id ... --service-account-key key.json

O relatório destaca findings por severidade (alta, média, baixa) e agrupa por serviço. É o ponto de partida para qualquer assessment cloud.

Prowler

Prowler é focado em AWS e implementa checks do CIS AWS Benchmark, além de checks customizados. Mantido pela community, suporta mais de 300 checks cobrindo IAM, CloudTrail, S3, VPC, Redshift, RDS, Lambda, entre outros.

prowler aws --profile default
prowler aws --regions us-east-1,eu-west-1
prowler aws --severity critical,high --compliance cis_aws_level_1

O Prowler é excelente para compliance — se o objetivo é verificar se o ambiente segue o CIS Benchmark, ele é a ferramenta certa.

Pacu

O Pacu é um framework de exploitation para AWS. Diferente do ScoutSuite e Prowler (que são passivos/análise), o Pacu executa ações ofensivas: enumeração, escalada de privilégios, exfiltração e pós-exploração.

Funciona como uma sessão interativa (similar ao Metasploit) com módulos para cada fase do ataque. Módulos notáveis:

iam__enum_users_roles_policies_groups — enumera todos os usuários, roles e policies
iam__privesc_scan — identifica caminhos de escalada de privilégios
s3__enum — enumera e testa buckets S3
ec2__download_userdata — baixa user data de todas as instâncias (pode conter credenciais)
lambda__enum — lista e analisa funções Lambda

⚠️ Atenção: O Pacu é uma ferramenta ofensiva. Use apenas em ambientes autorizados para pentest. Nunca rode contra contas AWS de terceiros sem consentimento explícito por escrito.

CloudSploit

O CloudSploit (agora parte do Aqua Security) é outra ferramenta de auditoria multi-cloud que verifica por misconfigurations comuns. Suporta AWS, Azure e GCP com dezenas de plugins organizados por categoria (IAM, networking, storage, logging). É particularmente útil em pipelines de CI/CD — pode ser integrado para rodar automaticamente a cada deploy e failar o build se misconfigurations são detectadas.

Trivy

O Trivy merece menção dupla porque vai além de containers. Além de escanear imagens Docker, o Trivy escaneia filesystems, repositories Git, Kubernetes clusters, IaC files (Terraform, CloudFormation, Helm charts) e configurações cloud (AWS, Azure, GCP). É o scanner mais versátil do ecossistema open source de segurança.

# Escanear imagem Docker
trivy image nginx:latest

# Escanear filesystem
trivy fs /path/to/project

# Escanear IaC
trivy config ./terraform/

# Escanear cluster K8s
trivy k8s --report summary my-cluster

Hands-on: Scanning e Enumeração Cloud

ScoutSuite: Scanning Completo

Um assessment cloud típico começa com ScoutSuite. O workflow é simples:

Configure credenciais com least privilege necessário para leitura (ReadOnly access)
Rode python scout.py aws --profile target-account
Aguarde a coleta (5-15 min dependendo do tamanho da conta)
Abra o relatório HTML gerado em scoutsuite-results/aws-[timestamp]/report.html
Revise findings por severidade — priorize Critical e High

Findings típicos que você vai encontrar em uma primeira passagem: S3 buckets com public access, security groups com regras abertas, CloudTrail desabilitado em regiões, IAM users sem MFA, EBS snapshots públicos, instâncias EC2 com IMDSv1 habilitado.

Shodan: Exposição de Serviços Cloud

Shodan é uma ferramenta indispensável para descobrir serviços cloud expostos à internet. Queries úteis:

# Docker API exposta
product:"Docker" port:2375

# Kubernetes Dashboard exposto
http.title:"Kubernetes Dashboard"

# Azure Blob Storage público
http.title:"Azure Blob Storage"

# AWS S3 buckets
"aws-s3"

# MongoDB exposto
product:"MongoDB" port:27017

# ElasticSearch/Kibana expostos
product:"Elasticsearch"
product:"Kibana"

Para cada resultado, documente o serviço, a porta, o IP e a severidade. Em um pentest real, isso alimenta o relatório de findings.

S3 Bucket Enumeration

Para enumerar buckets S3 de um alvo, use s3scanner:

# Instalar
pip install s3scanner

# Enumerar buckets por nome de domínio
s3scanner scan --bucket-file buckets.txt --out results.csv

O arquivo de entrada contém nomes de buckets possíveis (baseados no domínio da empresa, subdomínios, padrões de nomenclatura). O s3scanner testa cada um e reporta se é acessível, se permite listagem, e se permite download de objetos.

📊 Dica do Hacker: Combine enumeração de buckets com subfinder e amass para gerar nomes de buckets baseados em subdomínios descobertos. Padrão comum: subdomain.s3.amazonaws.com, subdomain-data.s3.amazonaws.com, subdomain-backups.s3.amazonaws.com.

CSPM — Continuous Compliance Monitoring

Scans pontuais são úteis, mas a realidade é que infraestrutura cloud muda constantemente. Um bucket seguro hoje pode se tornar público amanhã por um commit errado no Terraform. É aqui que entra o CSPM (Cloud Security Posture Management).

AWS Config Rules

O AWS Config monitora mudanças em recursos da conta e avalia contra regras de configuração. Regras gerenciadas incluem checks como s3-bucket-public-read-prohibited, iam-password-policy, encrypted-volumes e no-unrestricted-ssh-ingress. Quando uma violação é detectada, o Config pode gerar notificações via SNS ou até mesmo remediar automaticamente (via Systems Manager Automation).

Azure Policy

O Azure Policy é o equivalente da Azure. Policies definem regras sobre recursos (ex: “nenhum Storage Account pode ser criado sem encryption” ou “nenhuma NSG pode permitir inbound RDP de qualquer IP”). As policies são avaliadas em tempo real e podem incluir efeitos como deny (bloqueia a criação do recurso) ou deployIfNotExists (cria automaticamente o recurso compatível, como um diagnostic setting).

GCP Organization Policies

O GCP Organization Policy Service aplica restrições em nível de organização ou projeto. Constraints como constraints/iam.disableServiceAccountKeyCreation (impede criação de keys de service account) ou constraints/compute.requireShieldedVm (obriga VMs shielded) protegem contra misconfigurations antes que elas ocorram. É o mais preventivo dos três — funciona como guardrail, não como detector.

A diferença fundamental: AWS Config e Azure Policy são mais reativos (detectam e remediaram), enquanto GCP Organization Policies são mais proativos (bloqueiam a criação de recursos não-compliant). Na prática, um programa maduro de segurança cloud usa ambos: guardrails preventivos + detecção e resposta contínua.

Contra-medidas: O Checklist Essencial

Fechar o ciclo — depois de entender como atacar, como defender? Aqui está o checklist consolidado que todo ambiente cloud deveria implementar:

Identity & Access:

Aplicar minimum privilege em todas as IAM policies, roles e service accounts. Auditar periodicamente com Access Analyzer (AWS), Identity Governance (Azure) ou Policy Intelligence (GCP).
MFA obrigatório para todos os usuários humanos — sem exceção. Em workloads, usar short-lived credentials via roles/managed identities em vez de long-lived keys.
Rotacionar access keys e secrets regularmente. Automatizar com soluções como AWS Secrets Manager ou Azure Key Vault.
Usar Privileged Identity Management (Azure PIM) ou AWS IAM Access Analyzer para just-in-time access e review de permissões.

Network & Infrastructure:

Bloquear inbound 0.0.0.0/0 em todas as portas de gerenciamento. Usar bastion hosts, VPN ou Session Manager para acesso administrativo.
Implementar VPC flow logs (AWS), NSG flow logs (Azure) ou VPC Flow Logs (GCP) e enviar para SIEM para análise de tráfego anômalo.
Segmentar workloads em VPCs/subnets diferentes. Aplicar zero-trust: não confiar no tráfego interno por padrão.
Desabilitar IMDSv1 em todas as instâncias EC2. Configurar hop limit do IMDSv2 para 1.

Data Protection:

Encrypt at rest em todos os storage services (S3 SSE, Azure Storage Encryption, GCP default encryption). Usar customer-managed keys (KMS) para controle granular.
Encrypt in transit — TLS obrigatório para todas as conexões. Desabilitar HTTP em favor de HTTPS em todos os endpoints.
S3 Block Public Access habilitado em nível de conta. Azure Storage Account com acesso público desabilitado por padrão.

Monitoring & Response:

CloudTrail habilitado em todas as regiões com logs enviados para um bucket S3 centralizado e read-only. Azure Activity Logs com retention de 90+ dias. GCP Audit Logs com exportação para BigQuery.
GuardDuty / Defender for Cloud / Security Command Center ativos com todas as detecções habilitadas. Integração com SIEM e ticketing.
CSPM rodando continuamente com alerts em tempo real para misconfigurations de alta severidade.
Implementar automação de resposta: se um bucket S3 se torna público, automaticamente aplicar Block Public Access e notificar o time de segurança.

Compliance & Governance:

Usar IaC (Terraform, CloudFormation, ARM templates) para toda infraestrutura — código pode ser versionado, revisado e auditado. Nunca configurar recursos via console em ambiente prod.
Implementar CI/CD pipelines com security gates: checkov, tfsec ou trivy config para validar Terraform antes de apply.
Participar de programas de bug bounty cloud (HackerOne, Bugcrowd) para testar continuamente a postura de segurança contra pesquisadores externos.

Conclusão

A segurança cloud não é sobre firewalls ou perimetros de rede — é sobre controle de acesso, configuração correta e monitoramento contínuo. O atacante não precisa de um zero-day quando existe um bucket S3 público com dados sensíveis. Não precisa de exploit sophisticated quando uma IAM role com privilégios administrativos está atribuída a uma Lambda que processa input do usuário.

Para o ethical hacker, o cloud é um playground riquíssimo. A superfície de ataque é vasta (identidade, storage, compute, containers, serverless, APIs), os tools são maduros (ScoutSuite, Pacu, Prowler, Trivy), e as vulnerabilidades mais impactantes são frequentemente as mais simples de encontrar e explorar.

Para o defensor, a mensagem é clara: automatize a segurança. IAM least privilege via code review de policies. CSPM rodando 24/7. IaC com security gates no pipeline. Encryption habilitada por padrão. Logs centralizados com detecção automatizada. Não é glamouroso — mas é o que funciona.

No próximo artigo, vamos fechar a série com um guia de estudo para o exame CEH v13 — como se preparar, o que estudar, e como a prova é estruturada.