Segurança em Nuvem (Cloud Security): Como Proteger Ambientes AWS, Azure e GCP

O que é cloud security e o modelo de responsabilidade compartilhada

Cloud security (segurança em nuvem) é a disciplina que protege dados, identidades, aplicações e infraestrutura hospedados em provedores como AWS, Microsoft Azure e Google Cloud (GCP). Diferente da segurança tradicional de datacenter, ela opera sobre recursos efêmeros, definidos por software (infrastructure as code) e acessíveis via API pública, o que muda radicalmente a superfície de ataque: o perímetro deixa de ser a rede e passa a ser a identidade e a configuração.

O modelo de responsabilidade compartilhada (shared responsibility model) define quem protege o quê. O provedor de nuvem é responsável pela segurança DA nuvem: hardware, virtualização, rede física e disponibilidade dos serviços gerenciados. O cliente é responsável pela segurança NA nuvem: configuração dos serviços, gestão de identidades e acessos (IAM), criptografia dos dados, regras de rede (security groups, NSGs, firewall rules) e o código das aplicações. A linha exata varia por tipo de serviço.

Em IaaS (ex.: EC2, máquinas virtuais), o cliente gerencia sistema operacional, patches e tudo acima dele. Em PaaS (ex.: RDS, App Service), o provedor cobre o SO e o runtime, mas o cliente ainda define acesso e dados. Em SaaS, o cliente responde essencialmente por identidade, configuração e dados. A maioria dos incidentes de nuvem ocorre exatamente na metade do cliente: o provedor entrega serviços seguros por padrão, mas a responsabilidade de configurá-los corretamente nunca é transferida. O padrão ISO/IEC 27017 formaliza esse modelo, definindo papéis dentro dos SLAs e adicionando sete controles específicos de nuvem além do ISO 27002.

Principais riscos em nuvem: misconfiguration, IAM excessivo, buckets expostos, secrets e supply chain

Erro de configuração (misconfiguration) é a causa raiz mais comum de exposição em nuvem. Buckets de armazenamento abertos, bancos de dados sem autenticação, security groups com 0.0.0.0/0 em portas sensíveis e logging desativado expõem dados sem que nenhuma vulnerabilidade de software seja explorada. O relatório IBM Cost of a Data Breach 2025 atribui 26% de todas as violações a erro humano, e a Tenable identificou que 9% dos serviços de armazenamento em nuvem publicamente acessíveis contêm dados sensíveis. O custo médio global de uma violação chegou a US$ 4,44 milhões em 2025.

IAM excessivo é o risco mais subestimado. Identidades (usuários, roles, service accounts) acumulam permissões que nunca usam, e essas permissões ociosas viram caminho de escalada de privilégio e movimento lateral. Em multi-cloud o problema se multiplica: cada provedor tem seu próprio modelo de permissões, e poucos times conseguem responder com precisão quem pode fazer o quê. Por isso o least privilege é o controle de maior alavancagem em nuvem.

Buckets e storage expostos (S3, Azure Blob, Cloud Storage) continuam vazando dados por ACLs públicas, políticas permissivas e ausência de Block Public Access. Secrets hardcoded — chaves de acesso, tokens e senhas em código, variáveis de ambiente, imagens de container e repositórios Git — são colhidos por atacantes que escaneiam o GitHub continuamente. Riscos de supply chain fecham a lista: imagens de container de base comprometidas, dependências maliciosas, módulos de Terraform de terceiros e pipelines de CI/CD com credenciais de longa duração permitem injetar código antes mesmo do deploy. A Decripte mapeia esses cinco vetores em todo pentest de cloud.

Os pilares modernos: CSPM, CWPP, CIEM e CNAPP

A segurança em nuvem moderna é organizada em capacidades complementares que, segundo o Gartner, vêm convergindo em uma plataforma única chamada CNAPP. Entender cada sigla é pré-requisito para escolher e operar as ferramentas certas.

CSPM (Cloud Security Posture Management) verifica continuamente se o ambiente está configurado de forma segura: buckets abertos, IAM fraco, criptografia ausente, logging desligado e desvios em relação a benchmarks como o CIS. É a camada que detecta misconfiguration em escala. CWPP (Cloud Workload Protection Platform) protege as cargas de trabalho em execução — máquinas virtuais, containers e funções serverless — escaneando vulnerabilidades, malware, secrets expostos e configurações inseguras dentro do próprio workload.

CIEM (Cloud Infrastructure Entitlement Management) governa as identidades e entitlements, medindo permissões concedidas contra permissões efetivamente usadas para forçar least privilege e remover acesso ocioso. É a resposta direta ao risco de IAM excessivo, especialmente em multi-cloud. CNAPP (Cloud-Native Application Protection Platform) é a plataforma unificada que integra CSPM, CWPP, CIEM e DSPM, correlacionando sinais ao longo de todo o ciclo de vida — do infrastructure as code aos workloads em produção. O Gartner aponta três motores de adoção: unificar a visibilidade de risco entre IaaS e PaaS, reduzir a complexidade de ferramentas sobrepostas e integrar segurança ao fluxo de DevOps com baixo atrito. A Decripte implementa essas camadas com base no risco real medido no ambiente, não como compra de ferramenta isolada.

Segurança de containers e Kubernetes

Containers e Kubernetes adicionam camadas próprias de risco que o CSPM tradicional não cobre por completo. A segurança começa na imagem: usar imagens base mínimas, escanear vulnerabilidades e secrets antes do deploy, assinar imagens e puxar somente de registries confiáveis. Containers devem rodar como usuário não-root, com filesystem somente leitura quando possível e capabilities reduzidas ao mínimo necessário.

No nível do cluster, as Pod Security Standards do Kubernetes (baseline e restricted) impedem pods privilegiados, montagem do filesystem do host e escalada de privilégio. Network Policies segmentam o tráfego leste-oeste entre namespaces e pods — sem elas, o cluster é uma rede plana onde um pod comprometido alcança todos os outros. RBAC do Kubernetes deve seguir least privilege, evitando bindings de cluster-admin e service accounts com tokens de longa duração montados automaticamente.

O Guia de Hardening de Kubernetes da NSA/CISA e os CIS Kubernetes Benchmarks são as referências autoritativas, e ferramentas como kube-bench automatizam a verificação contra o CIS. O OWASP Kubernetes Top 10 (2025) confirma que configurações inseguras de workload (K01), autorização excessivamente permissiva (K02) e ausência de segmentação de rede (K05) concentram a maior parte das falhas encontradas em clusters de produção. A Decripte testa e endurece clusters contra esses três vetores prioritários.

Identidade e least privilege em multi-cloud

Em nuvem, identidade é o novo perímetro. A maioria dos ataques bem-sucedidos não explora uma falha de software: usa uma credencial válida com permissões excessivas. Por isso o least privilege — conceder a cada identidade apenas o acesso estritamente necessário, pelo menor tempo possível — é o controle estruturalmente mais importante de um ambiente cloud.

A operacionalização passa por eliminar credenciais de longa duração. Em vez de access keys estáticas, usar roles e federação de identidade (AWS IAM Roles, Azure Managed Identities, GCP Workload Identity) para que workloads obtenham credenciais temporárias automaticamente. Para acesso humano, centralizar em um provedor de identidade com SSO e MFA obrigatório, e conceder acesso a recursos sensíveis just-in-time, não de forma permanente.

Em multi-cloud, a complexidade explode porque cada provedor tem modelo de permissões distinto, e permissões ociosas se acumulam invisíveis. Ferramentas de CIEM tornam possível medir o gap entre permissões concedidas e usadas, identificar identidades superprivilegiadas e roles órfãs, e detectar caminhos de escalada de privilégio entre contas e entre nuvens. A prática recomendada é revisão contínua: cada permissão não utilizada por um período definido é candidata a remoção. A Decripte audita modelos de IAM dos três provedores e implementa least privilege medido, reduzindo a superfície de identidade sem quebrar operações.

Conformidade e benchmarks: CIS, NIST, ISO 27017 e Well-Architected

Benchmarks e frameworks dão a régua objetiva para medir e provar a postura de segurança em nuvem. Os CIS Benchmarks são o padrão de fato para configuração segura, com guias específicos e prescritivos para AWS, Azure, GCP, Kubernetes e dezenas de serviços — cada controle é verificável e mapeável a uma ferramenta de CSPM. São o ponto de partida prático para hardening porque traduzem princípios em configurações concretas.

No nível de governança, o NIST SP 800-53 e o NIST Cybersecurity Framework oferecem catálogos abrangentes de controles aplicáveis à nuvem, amplamente adotados como base de programas de segurança. O ISO/IEC 27017 estende o ISO 27002 com controles específicos de nuvem (incluindo papéis no SLA, hardening de VMs e remoção de ativos do cliente), enquanto o ISO/IEC 27018 trata especificamente da proteção de dados pessoais (PII) em nuvem pública. Importante: 27017 e 27018 não são certificáveis isoladamente — apoiam-se na estrutura do ISO 27001.

O AWS Well-Architected Framework (e seus equivalentes Azure Well-Architected e Google Cloud Architecture Framework) traz o pilar de segurança como guia de implementação prático, complementando os padrões formais com recomendações arquiteturais. Na prática, esses frameworks se sobrepõem e se reforçam: um ambiente endurecido contra CIS Benchmarks já satisfaz boa parte dos controles de NIST e ISO 27017 simultaneamente. A Decripte usa esses benchmarks como base de auditoria de cloud, medindo o ambiente real do cliente contra cada controle e priorizando correções por risco.

Passo a passo

1. Mapeie o modelo de responsabilidade compartilhada: documente, por serviço (IaaS/PaaS/SaaS), exatamente o que o provedor cobre e o que é responsabilidade sua — configuração, IAM, criptografia e dados.
2. Estabeleça uma baseline com CSPM: avalie todo o ambiente contra os CIS Benchmarks de AWS, Azure e GCP, corrigindo buckets expostos, criptografia ausente e logging desativado por ordem de risco.
3. Implemente least privilege e elimine credenciais de longa duração: substitua access keys estáticas por roles temporárias, exija MFA, centralize identidade em SSO e use CIEM para remover permissões ociosas.
4. Proteja os workloads: escaneie imagens de container e funções por vulnerabilidades e secrets, rode containers como não-root e aplique Pod Security Standards e Network Policies no Kubernetes.
5. Gerencie secrets corretamente: tire chaves e tokens do código, imagens e variáveis de ambiente, movendo-os para um cofre (Secrets Manager, Key Vault, Secret Manager) com rotação automática.
6. Ative observabilidade e detecção: centralize logs (CloudTrail, Azure Monitor, Cloud Audit Logs), habilite detecção de ameaças nativa e integre alertas a um SOC para resposta rápida.
7. Valide com pentest de cloud e revisão contínua: teste IAM, configurações e caminhos de escalada de privilégio com um time ofensivo, e reavalie a postura em ciclo recorrente, não uma única vez.

Perguntas frequentes