Segurança em Nuvem (Cloud Security) para AWS, Azure e GCP

O que é segurança em nuvem e por que ela falha por configuração, não por tecnologia

Segurança em nuvem, ou cloud security, é a disciplina que protege dados, identidades, aplicações e workloads executados em provedores de infraestrutura como Amazon Web Services (AWS), Microsoft Azure e Google Cloud Platform (GCP). Diferente da segurança tradicional de datacenter — onde existe um perímetro físico e de rede claramente delimitado — a nuvem dissolve o perímetro: cada recurso (um bucket de armazenamento, uma máquina virtual, uma função serverless, uma fila de mensagens) é endereçável por API e governado por uma permissão de identidade. A consequência prática é que a postura de segurança de um ambiente cloud não é definida por firewalls de borda, mas por milhares de pequenas decisões de configuração distribuídas, qualquer uma das quais pode abrir uma porta.

Há um equívoco corrente de que 'a nuvem é insegura' ou, no extremo oposto, de que 'a nuvem cuida da segurança por mim'. Ambas estão erradas. A infraestrutura dos grandes provedores é, em termos de segurança física e de plataforma, mais robusta do que a da imensa maioria das empresas conseguiria construir sozinha. O problema não está no provedor — está na ponta do cliente. O Verizon Data Breach Investigations Report (DBIR) de 2025 aponta que 60% das brechas envolvem o elemento humano — um clique malicioso, uma ligação de engenharia social ou a exposição acidental de dados —, categoria que inclui justamente sistemas mal configurados. Os 'erros diversos' (Miscellaneous Errors), padrão que captura a configuração incorreta e o envio equivocado de dados, seguem entre os mais frequentes do relatório (12% das brechas em 2025, terceiro padrão mais comum). Em outras palavras: a tecnologia raramente é o ponto de falha; a operação dela é.

Dentro de cada empresa, essa estatística tem rosto. Um analista de infraestrutura sob pressão de prazo que afrouxa uma permissão 'só para destravar o deploy'; um desenvolvedor que comita uma chave de acesso no repositório para testar rápido; um time que sobe um ambiente de homologação espelhando produção e esquece de fechá-lo. Nenhuma dessas pessoas agiu de má-fé — mas cada uma criou, sem perceber, uma porta que um atacante automatizado encontra em minutos. Bots varrem continuamente a internet em busca de buckets públicos, painéis administrativos abertos e credenciais vazadas; o intervalo entre 'expor por engano' e 'ser encontrado' é medido em horas, às vezes minutos.

É por isso que segurança em nuvem madura não é um produto que se instala, e sim um ciclo contínuo: descobrir todos os recursos existentes (incluindo os que ninguém lembra que criou — o chamado shadow cloud), avaliar a configuração de cada um contra um padrão de referência, priorizar o que representa risco real de exposição, corrigir e validar, e então monitorar para que a postura não se degrade com o tempo. Esse ciclo é o que separa empresas que tratam a nuvem como uma extensão segura do negócio daquelas que descobrem suas falhas apenas no dia do incidente.

Modelo de responsabilidade compartilhada: onde termina o provedor e começa você

O conceito central que organiza toda a segurança em nuvem é o modelo de responsabilidade compartilhada (shared responsibility model), formalizado pela AWS e adotado, com variações, por Azure e GCP. A AWS o resume em uma distinção precisa: ela é responsável pela 'segurança da nuvem' (security of the cloud) e o cliente é responsável pela 'segurança na nuvem' (security in the cloud). O provedor garante o hardware, o software de virtualização, a rede física e a segurança dos datacenters — do hypervisor para baixo. O cliente assume tudo do sistema operacional convidado para cima: configuração de identidades e acessos (IAM), criptografia de dados, regras de firewall (security groups), gestão de patches e a configuração segura de cada serviço que utiliza.

O ponto crítico — e mais mal compreendido — é que a fronteira da responsabilidade se desloca conforme o tipo de serviço. Em um serviço de Infraestrutura como Serviço (IaaS), como uma instância Amazon EC2, o cliente é responsável por praticamente tudo: o sistema operacional convidado, os patches, as aplicações instaladas e a configuração do security group. Já em serviços abstraídos, como o Amazon S3 ou o DynamoDB, a AWS opera a infraestrutura, o sistema operacional e a plataforma, e o cliente é responsável essencialmente pela configuração de acesso e pelos dados que ali deposita. Quanto mais gerenciado o serviço, menor a superfície do cliente — mas nunca zero. Mesmo no mais abstraído dos serviços, quem decide se um bucket é público ou privado é o cliente.

A Microsoft estrutura o mesmo princípio em camadas de IaaS, PaaS e SaaS, deixando explícito que a responsabilidade por informações e dados, dispositivos, contas e identidades é sempre do cliente, independentemente do modelo de serviço. O Google Cloud adota uma formulação semelhante, e mais recentemente evoluiu para o conceito de 'destino compartilhado' (shared fate), em que o provedor oferece blueprints seguros, configurações recomendadas e garantias para ajudar o cliente a acertar — reconhecendo que a divisão de responsabilidades, embora correta, deixava o cliente sozinho demais diante de decisões técnicas complexas.

A consequência operacional desse modelo é direta: contratar AWS, Azure ou GCP não terceiriza sua segurança — apenas redefine onde ela mora. Toda auditoria, todo relatório de conformidade (LGPD, PCI-DSS, ISO 27001) e toda resposta a incidente em nuvem começa pela mesma pergunta: 'isso estava do lado do provedor ou do nosso?'. E a resposta, na esmagadora maioria dos vazamentos noticiados, é a mesma: estava do nosso lado, em uma configuração que ninguém revisou. Entender essa fronteira com precisão é o pré-requisito para qualquer programa sério de cloud security — e é a primeira coisa que a Decripte mapeia ao avaliar um ambiente.

Os quatro vetores que mais causam vazamento na nuvem

O primeiro e mais notório vetor é o de buckets e storage públicos. Serviços como o Amazon S3, o Azure Blob Storage e o Google Cloud Storage permitem expor objetos à internet com um único ajuste de permissão — recurso legítimo para hospedar sites estáticos ou arquivos públicos, mas catastrófico quando aplicado por engano a dados sensíveis. Anos de incidentes envolvendo buckets S3 abertos (de backups de bancos de dados a documentos de identidade) consolidaram esse como o erro arquetípico da nuvem. A AWS respondeu com mecanismos como o Block Public Access, hoje ativado por padrão em novos buckets, mas configurações herdadas, políticas de bucket permissivas e ACLs legadas continuam a vazar. A defesa é detectar continuamente qualquer recurso de armazenamento exposto e validar se a exposição é intencional.

O segundo vetor é o IAM (Identity and Access Management) com privilégios excessivos. Na nuvem, identidade é o novo perímetro: quem controla uma credencial com permissões amplas controla o ambiente. O problema endêmico é a violação do princípio do menor privilégio — políticas que concedem '*' (todas as ações) sobre '*' (todos os recursos), papéis de serviço com permissões muito além do necessário, chaves de acesso de longa duração que nunca expiram e contas de administrador sem autenticação multifator (MFA). A sub-técnica T1078.004 (Valid Accounts: Cloud Accounts) do MITRE ATT&CK descreve exatamente como adversários usam contas cloud legítimas — obtidas por phishing, força bruta ou vazamento — para conseguir acesso inicial, persistência, escalonamento de privilégios e evasão de defesas sem disparar alarmes, porque do ponto de vista do sistema o acesso é autorizado. A disciplina de CIEM (Cloud Infrastructure Entitlement Management) existe justamente para mapear e reduzir esse excesso de permissões.

O terceiro vetor é o de segredos expostos: chaves de API, tokens de acesso, senhas de banco de dados e certificados deixados em código-fonte, repositórios Git, imagens de contêiner, variáveis de ambiente e logs. Uma única chave de acesso AWS vazada em um repositório público pode dar a um atacante a porta de entrada para minerar criptomoedas às custas da vítima, exfiltrar dados ou escalar para o controle total da conta. Ferramentas de varredura de segredos e a rotação rigorosa de credenciais — preferindo papéis temporários e cofres gerenciados (AWS Secrets Manager, Azure Key Vault, Google Secret Manager) a chaves estáticas — são a contramedida central.

O quarto vetor é a exposição de APIs, portas e painéis administrativos. Bancos de dados (como instâncias de Elasticsearch, MongoDB e Redis) acessíveis sem autenticação, painéis de orquestração (Kubernetes dashboard, consoles de CI/CD) abertos à internet, e endpoints de API sem controle de acesso adequado formam uma superfície de ataque que cresce silenciosamente a cada novo serviço lançado. O OWASP, em seu trabalho sobre riscos de API (API Security Top 10) e na própria lista do Top 10 de aplicações web, destaca a quebra de autorização (Broken Object/Function Level Authorization) e a configuração de segurança incorreta (Security Misconfiguration) entre as falhas mais críticas e mais frequentes. Reduzir essa superfície exige inventário contínuo do que está exposto e segmentação de rede que mantenha serviços internos efetivamente internos — não acessíveis por padrão a qualquer endereço da internet.

CSPM, CWPP e CNAPP: o que cada sigla realmente resolve

A categoria de ferramentas de segurança em nuvem se organiza em torno de três siglas que frequentemente são confundidas, embora resolvam problemas distintos. CSPM (Cloud Security Posture Management) é a disciplina de avaliar continuamente a configuração do ambiente — o 'como está montado'. Um CSPM conecta-se às APIs do provedor, inventaria todos os recursos e compara cada configuração contra um padrão de referência (CIS Benchmarks, boas práticas do provedor, requisitos regulatórios), apontando desvios como buckets públicos, MFA ausente, criptografia desativada ou security groups abertos. O Gartner descreve o CSPM como especialmente valioso para organizações com grande pegada em nuvem distribuída entre múltiplos provedores, contas e ambientes, por oferecer uma visão unificada da postura. O CSPM responde à pergunta 'minha nuvem está configurada com segurança?'.

CWPP (Cloud Workload Protection Platform) atua em uma camada diferente: a da carga em execução. Enquanto o CSPM olha para a configuração da plataforma, o CWPP protege os workloads em si — máquinas virtuais, contêineres e funções serverless — com capacidades de gestão de vulnerabilidades, hardening de sistema, monitoramento, análise comportamental, detecção e resposta, e proteção contra malware. O CWPP responde à pergunta 'o que está rodando dentro dos meus servidores e contêineres está limpo e protegido em tempo de execução?'. CSPM e CWPP são complementares, não substitutos: um ambiente com configuração impecável pode rodar uma imagem de contêiner com uma vulnerabilidade crítica, e um workload blindado pode estar exposto por uma política de IAM frouxa.

CNAPP (Cloud-Native Application Protection Platform) é o termo que o Gartner cunhou em 2021 para descrever uma plataforma única que unifica essas e outras capacidades. Um CNAPP integra CSPM, CWPP, varredura de infraestrutura como código (IaC scanning), CIEM (gestão de direitos/entitlements), escaneamento de artefatos e análise comportamental — cobrindo o ciclo de vida da aplicação desde a criação do código até a execução em produção (do 'code to cloud'). A lógica por trás da consolidação é que ferramentas isoladas geram alertas isolados; o valor está em correlacionar, por exemplo, 'este contêiner com vulnerabilidade crítica está exposto à internet E roda com um papel IAM de administrador', transformando milhares de achados em um punhado de caminhos de ataque que realmente importam.

Na prática, a escolha entre adotar ferramentas pontuais ou uma plataforma consolidada depende da maturidade e da escala do ambiente. Para a maioria das empresas, o ponto de partida correto não é comprar a plataforma mais cara, e sim estabelecer o ciclo de CSPM bem-feito — porque é a configuração incorreta, e não o malware sofisticado, que causa a maioria dos vazamentos. A gestão de vulnerabilidades cloud da Decripte (/plano/gestao-vulnerabilidades) entrega exatamente isso: varredura de configuração contínua contra CIS Benchmarks, priorização por exposição real e orientação concreta de correção — sem que o cliente precise montar e operar uma stack de ferramentas internamente.

Cloud pentest e MITRE ATT&CK: validar a defesa do ponto de vista do atacante

Auditar configuração com CSPM responde se o ambiente segue as boas práticas; o cloud pentest responde a uma pergunta diferente e complementar: 'um atacante real conseguiria comprometer este ambiente, e até onde chegaria?'. O pentest de nuvem é um teste de intrusão autorizado e controlado que parte de premissas realistas — por exemplo, uma credencial de baixo privilégio vazada, ou acesso a um serviço exposto — e tenta encadear falhas de configuração, permissões excessivas e fraquezas de aplicação para escalar privilégios, mover-se lateralmente entre serviços e contas, e alcançar dados ou controle de alto valor. É a diferença entre saber que existem desvios na lista do CSPM e demonstrar que uma sequência específica deles leva, na prática, do acesso inicial ao comprometimento total da conta.

O cloud pentest tem particularidades técnicas e contratuais que o distinguem do pentest tradicional. Tecnicamente, o foco se desloca da exploração de vulnerabilidades de software para o abuso de relações de confiança entre serviços, herança e assunção de papéis IAM (role chaining), metadados de instância (a exploração do endpoint de metadata, que entrega credenciais temporárias, é um clássico — mitigada por IMDSv2 na AWS), e funções serverless mal isoladas. Contratualmente, é essencial respeitar as políticas de teste do provedor: AWS, Azure e GCP têm regras específicas sobre o que pode ser testado sem autorização prévia e o que exige notificação, sobretudo para testes que possam parecer ataques de negação de serviço (DoS). Um cloud pentest sério opera dentro dessas regras e com escopo formalmente acordado.

O MITRE ATT&CK fornece o vocabulário comum para descrever esse percurso de ataque. Para nuvem, a matriz cobre táticas como Acesso Inicial, Persistência, Escalonamento de Privilégios, Evasão de Defesa, Acesso a Credenciais, Descoberta, Movimento Lateral e Exfiltração, com técnicas mapeadas para os comportamentos reais de adversários em ambientes IaaS e SaaS. Técnicas como T1078.004 (Valid Accounts: Cloud Accounts), o abuso de tokens de acesso de aplicações e a coleta de dados a partir de repositórios de armazenamento em nuvem permitem que defensor e atacante falem a mesma língua: o relatório de um cloud pentest da Decripte mapeia cada passo da cadeia a uma técnica ATT&CK, tornando o achado rastreável, comparável ao longo do tempo e diretamente conectável às detecções que o time de monitoramento precisa ter.

Por isso o cloud pentest e o CSPM não competem — encaixam-se. O CSPM mantém a higiene contínua e barata da configuração; o cloud pentest, executado periodicamente (idealmente após mudanças arquiteturais relevantes e ao menos anualmente), valida que as defesas resistem a um adversário determinado e expõe as cadeias de ataque que nenhuma checagem de configuração isolada revelaria. A segurança ofensiva da Decripte (/plano/seguranca-ofensiva) conduz esse teste com escopo acordado, respeito às políticas do provedor e entrega orientada a correção — não a um PDF que vira gaveta.

Como funciona na prática e quando contratar segurança em nuvem

Na prática, um programa de cloud security maduro segue um ciclo que se repete. Primeiro, descoberta e inventário: conectar-se às contas de AWS, Azure e GCP via APIs e papéis de leitura para enxergar todos os recursos — inclusive os esquecidos. Segundo, avaliação de postura (CSPM): comparar cada configuração contra CIS Benchmarks e boas práticas, gerando uma lista priorizada de desvios. Terceiro, priorização por exposição real: nem todo desvio importa igualmente — um bucket privado com criptografia desligada é diferente de um bucket público com dados de clientes. Quarto, correção e validação. Quinto, validação adversarial periódica por cloud pentest. Sexto, monitoramento contínuo, para que a postura não regrida silenciosamente a cada novo deploy. Cada etapa alimenta a seguinte, e o monitoramento realimenta a primeira.

O momento de contratar segurança em nuvem dedicada costuma chegar quando um destes gatilhos aparece: a empresa migrou cargas relevantes para a nuvem e não tem ninguém com tempo dedicado para revisar configuração; o ambiente cresceu além do que uma planilha consegue acompanhar (múltiplas contas, múltiplos provedores); surgiu uma exigência de conformidade (LGPD, PCI-DSS, ISO 27001, exigência contratual de um cliente grande) que pede evidência de controles; houve um susto — um quase-incidente, um bucket achado aberto, um alerta do provedor; ou simplesmente porque a liderança técnica entendeu que o custo de prevenir é uma fração do custo de responder a um vazamento. Em qualquer desses casos, terceirizar a disciplina é quase sempre mais barato e mais rápido do que contratar, treinar e reter um time interno de cloud security.

É importante distinguir cloud security de áreas vizinhas que costumam ser confundidas. Não é a mesma coisa que segurança de aplicação (AppSec), que olha o código e a lógica da aplicação; nem que gestão de identidade corporativa (IAM de usuários e SSO da empresa), embora o IAM da nuvem seja parte central dela; nem que conformidade, que é o resultado documentável de uma boa postura, não a postura em si. Cloud security é especificamente a proteção da configuração, das identidades de máquina e dos workloads que vivem na infraestrutura dos provedores. As demais disciplinas se conectam a ela, mas não a substituem.

O caminho de menor atrito para começar é diagnosticar antes de contratar. Pelo Intelligence Center da Decripte (/intelligence-center) é possível iniciar gratuitamente uma avaliação de exposição e ameaças do ambiente, entendendo onde estão os riscos reais antes de qualquer compromisso. A partir daí, três frentes se combinam conforme a necessidade: gestão de vulnerabilidades e CSPM contínuos (/plano/gestao-vulnerabilidades) para manter a configuração sob controle; cloud pentest (/plano/seguranca-ofensiva) para validar as defesas como um atacante faria; e monitoramento 24/7 (/plano/soc-247) para detectar e responder a ameaças em nuvem em tempo real. O objetivo não é vender ferramentas, e sim entregar a postura segura como resultado operacional — do diagnóstico à resposta.

Termos-chave

Segurança em nuvem (cloud security)

Disciplina que protege dados, identidades, aplicações e workloads executados em provedores de infraestrutura como AWS, Azure e GCP, com foco na configuração segura de recursos, identidades de máquina e cargas em execução.

Modelo de responsabilidade compartilhada

Princípio que divide a segurança entre provedor e cliente: o provedor responde pela 'segurança da nuvem' (hardware, hypervisor, datacenter) e o cliente pela 'segurança na nuvem' (IAM, criptografia, configuração de serviços, dados).

CSPM (Cloud Security Posture Management)

Categoria de ferramenta que avalia continuamente a configuração de um ambiente cloud contra padrões de referência (CIS Benchmarks, boas práticas), apontando desvios como buckets públicos, MFA ausente ou security groups abertos.

CWPP (Cloud Workload Protection Platform)

Plataforma que protege as cargas em execução — máquinas virtuais, contêineres e funções serverless — com gestão de vulnerabilidades, hardening, monitoramento, detecção e resposta em tempo de execução.

CNAPP (Cloud-Native Application Protection Platform)

Termo cunhado pelo Gartner em 2021 para uma plataforma única que unifica CSPM, CWPP, CIEM e varredura de IaC, cobrindo o ciclo do código à execução e correlacionando achados em caminhos de ataque.

CIEM (Cloud Infrastructure Entitlement Management)

Disciplina e ferramenta focada em mapear, analisar e reduzir permissões excessivas de identidades na nuvem, aplicando o princípio do menor privilégio a usuários, papéis e contas de serviço.

Cloud pentest

Teste de intrusão autorizado e controlado em ambiente cloud que parte de premissas realistas e encadeia falhas de configuração, permissões excessivas e fraquezas de aplicação para demonstrar até onde um atacante real chegaria.

MITRE ATT&CK (T1078.004)

Sub-técnica 'Valid Accounts: Cloud Accounts' da base de conhecimento MITRE ATT&CK, que descreve o uso de contas cloud legítimas por adversários para acesso inicial, persistência, escalonamento de privilégios e evasão de defesas.

Por onde começar

1. Faça o inventário completo das contas e recursos em AWS, Azure e GCP — incluindo o shadow cloud que ninguém lembra que criou — conectando-se via APIs e papéis de leitura.
2. Mapeie com precisão a fronteira do modelo de responsabilidade compartilhada para cada serviço utilizado, separando o que é do provedor e o que é responsabilidade sua.
3. Rode uma avaliação de postura (CSPM) comparando cada configuração contra CIS Benchmarks e as boas práticas do provedor, gerando uma lista de desvios.
4. Priorize os achados por exposição e risco real (bucket público com dados sensíveis, IAM com '*' sobre '*', segredos em repositório, painel admin aberto) em vez de tratar todos os desvios igualmente.
5. Corrija e valide: feche exposições, aplique menor privilégio, rotacione e migre segredos para cofres gerenciados, e confirme que a correção surtiu efeito.
6. Valide as defesas com um cloud pentest periódico, respeitando as políticas de teste do provedor, mapeando cada passo a técnicas MITRE ATT&CK.
7. Implemente monitoramento contínuo (24/7) para detectar regressões de postura e ameaças em tempo real a cada novo deploy.
8. Comece gratuitamente um diagnóstico de exposição pelo Intelligence Center (/intelligence-center) antes de decidir o escopo de contratação.

Perguntas frequentes

Referências e normas técnicas

• ›AWS — Modelo de Responsabilidade Compartilhada (Shared Responsibility Model) — https://aws.amazon.com/compliance/shared-responsibility-model/
• ›Microsoft — Shared responsibility in the cloud (Azure) — https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
• ›Google Cloud — Shared responsibilities and shared fate — https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate
• ›MITRE ATT&CK — T1078.004 Valid Accounts: Cloud Accounts — https://attack.mitre.org/techniques/T1078/004/
• ›Verizon 2025 Data Breach Investigations Report (DBIR) — https://www.verizon.com/business/resources/reports/dbir/
• ›CIS Benchmarks (Center for Internet Security) — https://www.cisecurity.org/cis-benchmarks