Segurança em Multicloud: os Pontos Cegos Que Ninguém Vê

Segurança multicloud não é sobre ter mais de uma nuvem. É sobre governar as nuvens que a empresa já tem com o mesmo padrão. Diversificar fornecedor entrega alavancagem comercial e resiliência regional. Diversificar risco depende de operar AWS, Azure e Google Cloud sob o mesmo modelo de governança, e quase nenhuma empresa faz isso.

Em 2025, cerca de 89% das empresas médias e grandes já rodavam em duas ou mais nuvens públicas, segundo o Flexera State of the Cloud. A adoção virou padrão. A governança, não — e é essa assimetria que atravessa todo o panorama de cibersegurança corporativa da Mabex.

Três edições consecutivas do relatório Top Threats to Cloud Computing, da Cloud Security Alliance, publicadas em 2019, 2022 e 2024, mantêm configuração incorreta e gestão de identidade no topo do ranking de ameaças.

Muda o provedor, o padrão do erro continua.

Este artigo mapeia os 5 pontos cegos que aparecem em auditoria e em investigação pós-incidente de ambiente multicloud, explica onde os modelos de responsabilidade compartilhada da AWS, da Azure e do Google Cloud não conversam entre si, e mostra a diferença real entre CSPM, CIEM e CNAPP. Termina com um checklist de 10 itens de governança mínima.

O que Capital One 2019 e BlueBleed 2022 têm em comum?

Em julho de 2019, uma pessoa com conhecimento técnico em engenharia de software encontrou uma falha de SSRF no firewall de aplicação web da Capital One. Usou a brecha para obter credenciais de IAM temporárias e leu um bucket S3 com 106 milhões de registros de clientes.

A conta final: multa de US$ 80 milhões do OCC, o regulador bancário americano, mais US$ 190 milhões em acordo de ação coletiva — além do dano direto aos 106 milhões de titulares de dados expostos, que passaram a conviver com risco de fraude, phishing direcionado e uso indevido de informações pessoais e financeiras. Um caso canônico de encadeamento entre serviços dentro de uma única nuvem, a AWS.

Em outubro de 2022, a empresa de inteligência de ameaças SOCRadar identificou um Azure Blob Storage público desde 2017, mantido pela própria Microsoft. Mais de 2,4 terabytes, mais de 65 mil organizações em 111 países.

A Microsoft contestou a magnitude divulgada pela SOCRadar, mas confirmou a exposição. As duas versões do caso, conhecido como BlueBleed, seguem registradas: a discordância sobre o tamanho é parte da história, não muda o padrão do erro.

Depois de acompanhar duas décadas de migração corporativa para a nuvem, o que me chama atenção nesses dois casos não é a tecnologia. É a repetição: configuração default que ninguém revisou, e identidade temporária com privilégio maior do que deveria ter.

Não existe nuvem mais segura em abstrato. Existe modelo de responsabilidade compartilhada, e o cliente está sempre do lado exposto quando configura errado. Multicloud multiplica esse lado: três nuvens, três chances de errar a mesma coisa.

Se a mesma classe de erro atingiu a AWS em 2019 e a Azure em 2022, o que a sua empresa está assumindo sobre a terceira nuvem que também usa?

O padrão é histórico, não novidade. A mesma classe de erro reaparece a cada poucos anos, sempre um passo à frente da correção de default do provedor:

Ano	Marco	Tipo
2009	Primeiros vazamentos públicos de buckets S3	Incidente
2017	Onda de buckets S3 públicos (Verizon, Accenture, entre outros)	Incidente
2018	AWS lança o S3 Block Public Access (novembro)	Correção de default
2019	Capital One: SSRF + IAM temporário + bucket S3, 106 milhões de registros	Incidente
2020	Google Cloud lança o Uniform Bucket-Level Access; NIST publica a SP 800-210	Correção + referência
2021	Azure remove o acesso público anônimo por default em contas de armazenamento	Correção de default
2022	BlueBleed: Azure Blob público desde 2017; CSA publica o Pandemic 11	Incidente + referência
2024	Snowflake: credenciais roubadas sem MFA; CSA publica o Top Threats 2024	Incidente + referência

Fonte: Cloud Security Alliance, comunicados oficiais de AWS, Azure e Google Cloud, e documentação dos casos públicos.

Por que multicloud virou padrão, e o que essa escolha esconde?

Multicloud virou padrão de operação porque três forças se combinaram: negociação com fornecedor, serviço especializado por nuvem e herança organizacional. O que essa pilha esconde é que ela raramente foi desenhada. Na maioria das empresas, foi acumulada.

Os três motivos que chegam ao conselho são reais. Ter uma segunda nuvem em produção é o único argumento que funciona numa negociação de contrato com um hyperscaler: o CFO pede, o CTO entrega.

Cada nuvem também tem um serviço que a concorrência não replica bem: BigQuery no Google Cloud, Bedrock na AWS, Active Directory federado no Azure. O time de dados escolhe uma, o time de IA generativa escolhe outra.

E existe resiliência regional de verdade: conformidade em jurisdição específica, dado residente em país determinado, tolerância a falha de região inteira.

Os três motivos que não aparecem em nenhum relatório são mais comuns na prática. A empresa que a sua acabou de comprar já rodava em outra nuvem, e migrar consome seis meses que ninguém tem. A subsidiária escolheu Azure porque o parceiro local só sabia trabalhar com Azure.

Um time experimentou um serviço em outra nuvem, subiu carga real, o cliente entrou em produção, e o experimento virou dependência que ninguém autorizou formalmente.

O resultado é que cada nuvem chegou com equipe própria, catálogo de serviços aprovados próprio, logs próprios e um jeito próprio de fazer gestão de identidade. A empresa acredita que está em uma arquitetura.

Na prática, está em três arquiteturas paralelas que só se falam por chamado de suporte. É nesse intervalo entre elas que o incidente encontra espaço para crescer — o mesmo hiato de governança que o panorama de cibersegurança para gestores mapeia em outras frentes.

Onde os modelos de responsabilidade compartilhada não conversam?

AWS, Azure e Google Cloud publicam modelos de responsabilidade compartilhada com vocabulário parecido, mas granularidade diferente. Não dá para copiar o mapa de controles de uma nuvem para outra sem tradução manual. É nesse hiato que os direitos dos titulares de dados protegidos pela LGPD — e os compromissos regulatórios da Circular Bacen 4.658 — deixam de ser efetivamente garantidos, expondo pessoas reais a risco de uso indevido de suas informações.

Provedor	Formulação central	Ponto singular
AWS	Segurança “da” nuvem (AWS) x segurança “na” nuvem (cliente). A divisão muda por serviço: EC2 é IaaS clássico, DynamoDB é abstraído, Lambda fica no meio	Publica matriz de responsabilidade por categoria de serviço; o cliente precisa saber em qual categoria cada serviço se enquadra, nem sempre óbvio
Microsoft Azure	Modelo em camadas: on-premises, IaaS, PaaS, SaaS. A responsabilidade do cliente decresce conforme sobe na pilha	O diagrama oficial deixa identidade e diretório sempre do lado do cliente, inclusive em SaaS puro, escolha coerente com o legado do Active Directory
Google Cloud	Responsabilidade compartilhada mais destino compartilhado. O GCP formaliza responsabilidade proativa do provedor: blueprints seguros, telemetria por padrão	É o único dos três a nomear formalmente “shared fate”, reconhecendo que o cliente falha quando os controles do provedor não são acionáveis

Os três modelos não conversam em pelo menos quatro pontos. A granularidade de controle muda por serviço: criptografia em repouso pode ser responsabilidade do cliente na AWS via KMS gerenciado, ficar por conta do provedor por padrão no Google Cloud, e seguir um terceiro modelo no Azure via Key Vault.

O vocabulário para o mesmo conceito também muda: uma IAM Role na AWS não é a mesma coisa que uma Managed Identity no Azure, que por sua vez não é o mesmo que uma Service Account no Google Cloud. Funcionalmente próximas, com armadilhas específicas em cada uma.

A linguagem contratual muda: o contrato de cliente da AWS, o Microsoft Products and Services Agreement e os termos do Google Cloud tratam responsabilidade por incidente de forma diferente. Para efeito do dever de segurança da informação previsto no art. 46 da LGPD — que recai tanto sobre a empresa controladora quanto sobre os provedores de nuvem quando atuam como operadores — e da Circular Bacen 4.658, analisar os três contratos separadamente não é opcional.

E o escopo geográfico muda: cada provedor tem regiões, políticas de residência e contratos de tratamento de dados diferentes. Para o art. 33 da LGPD, sobre transferência internacional, é preciso não apenas mapear nuvem por nuvem onde os dados residem e transitam, mas também identificar e formalizar a hipótese legal aplicável a cada transferência (cláusulas contratuais específicas, cláusulas-padrão contratuais, normas corporativas globais, selos e certificados, ou consentimento específico do titular, entre as hipóteses do art. 33), documentando as salvaguardas adotadas para cada provedor, o mesmo cuidado que entra na escolha da base legal de cada tratamento.

A boa prática em setor regulado, como financeiro, saúde ou órgão público, é manter um documento único de matriz de responsabilidade multicloud, que também esclareça os papéis de controlador e operador de dados pessoais (art. 5º, VI e VII, e art. 39 da LGPD): a empresa contratante normalmente permanece como controladora e responde solidariamente com os provedores de nuvem, atuando como operadores, nos termos do art. 42 da LGPD, independentemente da divisão técnica de responsabilidade definida contratualmente pelo provedor. Ele traduz cada controle relevante ao regulador para o vocabulário de cada nuvem em operação.

Esse documento precisa ser auditável, versionado e revisado a cada mudança contratual de qualquer um dos três provedores. Sem ele, a resposta a uma fiscalização vira improviso, e o RIPD de qualquer tratamento que passe por essas nuvens fica incompleto.

Quais são os 5 pontos cegos típicos do ambiente multicloud?

Cinco padrões recorrentes aparecem em auditoria e em investigação pós-incidente de ambiente multicloud: gestão de identidade fragmentada, logs fragmentados, segredos em silos, rede assimétrica e configuração default insegura herdada de época. A ordem segue a frequência com que aparecem como causa raiz nos casos analisados pela Cloud Security Alliance.

1. Gestão de identidade fragmentada

Três provedores, três modelos de política (políticas em JSON na AWS, RBAC no Azure, políticas de IAM no Google Cloud), e milhares de identidades entre humanas e não humanas: roles, service accounts, service principals, workload identities. Sem ferramenta dedicada, não existe visão única.

O caso Snowflake de 2024, analisado no relatório Top Threats to Cloud Computing 2024 da Cloud Security Alliance, é o exemplo mais recente. A política de autenticação multifator estava do lado do cliente, não do provedor.

Bastou uma credencial vazar num endpoint de terceiro para o atacante entrar em instâncias corporativas da AT&T, da Ticketmaster e do Santander, entre outras.

Em ambiente multicloud isso se amplia porque cada nuvem tem uma noção diferente do que é identidade privilegiada. O mesmo colaborador pode ter acesso amplo numa nuvem e restrito em outra, um risco que também aparece no due diligence técnico de fornecedores de IA generativa, que quase sempre operam em multicloud.

A referência técnica para esse ponto é a NIST SP 800-210, sobre controle de acesso em sistemas de nuvem. Um programa de Zero Trust aplicado à gestão de identidade é o caminho mais direto para reduzir esse ponto cego.

2. Logs fragmentados

CloudTrail na AWS, Activity Log e Diagnostic Log no Azure, Cloud Audit Logs no Google Cloud: formatos diferentes, taxonomias diferentes, retenção e latência de coleta diferentes. Correlacionar um incidente que atravessa as três nuvens é inviável sem um SIEM, um data lake dedicado ou uma ferramenta de detecção multicloud.

A consequência prática é mensurável: o time de segurança descobre a hora exata do movimento lateral com dias de atraso, quando descobre. Em incidente sob a LGPD, isso empurra a contagem do prazo de comunicação de incidente à ANPD, com prazo de 3 dias úteis conforme a Resolução CD/ANPD nº 15/2024 (a LGPD, no art. 48, exige comunicação em prazo razoável, detalhado por norma da ANPD), para o limite.

3. Segredos em silos

KMS e Secrets Manager na AWS, Key Vault no Azure, Secret Manager no Google Cloud, mais HashiCorp Vault e o estado do Terraform. Cada silo tem sua própria política de rotação, seu próprio escopo, sua própria auditoria de acesso.

Rotação coordenada entre todos eles é uma rotina que praticamente nenhuma empresa tem funcionando de ponta a ponta. Quando uma credencial vaza, por commit acidental, ex-funcionário ou terceiro comprometido, a janela de exposição é a soma das latências de cada silo, não a menor delas.

4. Rede assimétrica

VPC e Transit Gateway na AWS, VNet, ExpressRoute e Virtual WAN no Azure, VPC e Cloud Interconnect no Google Cloud. Cada modelo tem sua própria unidade lógica, sua sintaxe de peering, seu conceito de firewall.

Conectividade entre nuvens vira dependência oculta, com regras duplicadas, contraditórias ou esquecidas em ambientes de teste que viraram produção.

O movimento lateral, o padrão de ataque que marcou o ataque de ransomware à Renner em 2021, fica trivial quando existe um túnel esquecido entre duas nuvens.

A microssegmentação de uma arquitetura Zero Trust é a resposta estrutural para esse ponto cego.

5. Configuração default insegura herdada de época

Cada nuvem carrega um passado de defaults inseguros, corrigidos em datas diferentes. Bucket S3 público por padrão até novembro de 2018, quando a AWS lançou o Block Public Access. Conta de armazenamento do Azure com acesso público anônimo permitido até 2021. Listas de controle de acesso do Google Cloud Storage só corrigidas pela Uniform Bucket-Level Access em 2020.

Uma empresa que provisionou recursos em anos diferentes convive com defaults diferentes, e o inventário raramente marca o que foi criado antes da correção.

Foi essa a mecânica do BlueBleed: buckets criados em 2017 ficaram públicos até 2022, cinco anos de exposição sem que ninguém tenha feito nada de errado recentemente. O erro estava no default vigente na criação, nunca revisitado.

A referência de auditoria para esse ponto são os CIS Benchmarks de AWS, Azure e Google Cloud, baseline de configuração usada por toda ferramenta de CSPM séria.

#	Ponto cego	Sintoma típico em auditoria	Categoria de ferramenta
1	Identidade fragmentada	Nenhuma visão consolidada de quem tem o quê; roles não usadas há meses; contas de serviço com permissão excessiva	CIEM
2	Logs fragmentados	Tempo médio de resposta alto; sem resposta rápida a “onde essa identidade agiu nas últimas 24h?”	SIEM + data lake
3	Segredos em silos	Credenciais estáticas em variáveis de ambiente; rotação manual; sem detecção de vazamento em repositório	Gestor de segredos + scanner
4	Rede assimétrica	Diagramas de rede desatualizados; peerings esquecidos entre testes; firewall com regras contraditórias	CSPM + detecção de rede
5	Defaults inseguros herdados	Recursos legados com configuração pré-correção; buckets públicos “por acidente”; armazenamento sem criptografia	CSPM

O que CSPM, CIEM e CNAPP resolvem, cada um?

CSPM audita configuração. CIEM audita permissão efetiva. CNAPP é o guarda-chuva que integra os dois com segurança de workload e de Kubernetes. São categorias complementares, não intercambiáveis. Chamar CSPM de CIEM é o erro de vocabulário mais comum num RFP mal escrito.

Categoria	O que faz	Exemplo de detecção
CSPM (Cloud Security Posture Management)	Auditoria contínua de configuração contra baseline, como CIS, NIST 800-53, PCI-DSS, HIPAA ou mapeamento LGPD	Bucket S3 público, máquina sem autenticação multifator no acesso administrativo, banco de dados sem criptografia em repouso
CIEM (Cloud Infrastructure Entitlement Management)	Análise de permissões efetivas, não apenas declaradas, e detecção de excesso de privilégio	Uma função que consegue assumir outra com acesso irrestrito; conta de serviço com permissão em toda a organização
CNAPP (Cloud-Native Application Protection Platform)	Guarda-chuva que integra CSPM, CIEM, segurança de workload e de Kubernetes, e varredura de infraestrutura como código, com correlação entre camadas	Vulnerabilidade no contêiner, cruzada com a identidade que o executa e a exposição de rede, numa única visão

As ferramentas nativas de CSPM, como o AWS Security Hub, o Microsoft Defender for Cloud e o Google Cloud Security Command Center, são o piso obrigatório mesmo num ambiente pequeno. Uma ferramenta unificada de terceiros se justifica a partir de duas nuvens em produção, ou em setor regulado.

CIEM se justifica com mais de duas nuvens em produção, mais de 200 contas ou projetos, ou setor regulado. A diferença prática é grande: o CSPM diz que uma permissão existe, o CIEM diz que ela está sendo usada. Em investigação pós-incidente, essa diferença é decisiva.

CNAPP faz sentido para quem já tem CSPM e sente a dor de operar quatro ou cinco ferramentas separadas. Para uma empresa sem workload cloud-native intensivo, ainda é investimento desproporcional em 2026. O custo se justifica a partir de operação com Kubernetes de produção e pipeline de integração contínua com infraestrutura como código.

Um SIEM não substitui CSPM nem CIEM. O SIEM é reativo: ingere e correlaciona eventos depois do fato. CSPM e CIEM são proativos: analisam a configuração e a permissão atuais, antes do fato. Uma operação madura tem os dois. Esse desenho de defesa em camadas é o mesmo princípio que sustenta o plano de resposta a incidentes cibernéticos de qualquer operação madura.

Quais são os 10 itens do checklist mínimo de governança multicloud?

Governança multicloud madura em 2026 tem 10 controles mínimos observáveis. Não é um framework aspiracional. É um baseline auditável que separa “a empresa tem multicloud” de “a empresa opera multicloud com governança”.

#	Controle mínimo
1	Inventário unificado de contas, subscriptions e projetos, com dono e centro de custo definidos para cada item
2	Baseline de configuração por nuvem alinhado aos CIS Benchmarks, mapeado para as medidas de segurança do art. 46 da LGPD, para a Circular Bacen 4.658 quando aplicável, e apoiado (mas não substituído) pelas certificações ISO 27017/27018 como evidência de boas práticas técnicas do provedor
3	Gestão de identidade: menor privilégio como política escrita, autenticação multifator universal, rotação de credenciais de longa duração, revisão trimestral de funções privilegiadas
4	Logs centralizados em SIEM ou data lake dedicado, com retenção mínima de 12 meses e alertas de adulteração
5	Segredos: zero credencial fixa em repositório, validado por varredura no pipeline; rotação automática documentada; uma credencial para um propósito só
6	Rede: inventário atualizado de todo peering e conexão entre nuvens; diagrama revisado a cada trimestre
7	CSPM ativo com alertas triados e prazo de correção definido por severidade
8	CIEM ativo se houver mais de duas nuvens em produção ou setor regulado, mesmo via ferramenta nativa
9	Plano de resposta por nuvem, mais um plano multicloud que orquestra as três, testados anualmente
10	Revisão trimestral de acesso privilegiado, mais simulação anual de incidente multicloud, com meta de identificar o escopo em menos de 4 horas

O uso prático do checklist tem três aplicações diretas. Em auditoria interna, funciona como assessment inicial: 10 de 10 é maduro, 6 de 10 é típico de empresa em transição, 3 de 10 é dívida de segurança acumulada.

Em RFP de fornecedor de CSPM, CIEM ou CNAPP, cada item vira uma pergunta de descoberta. Um fornecedor sério tem resposta clara para todos eles.

E no onboarding de um novo CISO, rodar o checklist e produzir o baseline atual é o primeiro trabalho, antes de propor qualquer estratégia nova. Esse mesmo exercício de baseline dialoga com o plano de resposta a incidentes cibernéticos que toda operação madura precisa ter documentado.

Diversificar fornecedor não é diversificar risco

Três provedores, três modelos de responsabilidade compartilhada, três taxonomias de log, três sintaxes de gestão de identidade, três conjuntos de defaults herdados. Os 5 pontos cegos se repetem porque a causa é sempre a mesma: governança que não acompanhou a arquitetura.

O caminho operacional para as próximas oito semanas: rodar o checklist de 10 itens como assessment; mapear os 5 pontos cegos na arquitetura atual; ativar os CSPM nativos, que são o piso obrigatório; avaliar a necessidade de uma ferramenta unificada de terceiros; e documentar a matriz de responsabilidade multicloud.

E vale o contraponto que fecha o argumento: multicloud também não protege contra a falha do próprio plano de controle de segurança. Em julho de 2024, uma atualização defeituosa do CrowdStrike Falcon derrubou cerca de 8,5 milhões de dispositivos Windows no mundo, atravessando qualquer fronteira entre nuvens. Diversificar provedor de nuvem não dilui a dependência de um agente de segurança único rodando em todas elas, o mesmo tipo de dependência única que a arquitetura Zero Trust tenta reduzir.

O erro que ninguém vê chegando não é técnico. É organizacional: três equipes rodando três nuvens sob três modelos mentais diferentes, achando que a diversidade em si cuida da segurança.

A Cloud Security Alliance vem dizendo a mesma coisa há três edições consecutivas do seu relatório: o problema é configuração e permissão. O trabalho de 2026 é parar de esperar que o multicloud resolva o multicloud, o mesmo raciocínio que sustenta todo o panorama de cibersegurança corporativa da Mabex.

Perguntas Frequentes

O que é segurança multicloud?

É o conjunto de práticas, controles e ferramentas que endereçam risco de configuração, identidade e rede em ambientes que operam mais de uma nuvem pública ao mesmo tempo, tipicamente AWS, Azure e Google Cloud. Exige tradução entre modelos diferentes de responsabilidade compartilhada e correlação entre logs de formatos distintos.

Multicloud é mais seguro que uma nuvem só?

Não automaticamente. Multicloud diversifica fornecedor, mas não diversifica risco por padrão: multiplica a superfície de ataque, com mais identidades para gerenciar, mais logs para correlacionar e mais defaults para revisar. Diversificação de risco depende de operar as três nuvens sob o mesmo modelo de governança.

Qual a diferença entre CSPM e CIEM?

CSPM audita configuração, como um bucket público ou uma máquina sem autenticação multifator. CIEM audita permissão efetiva, como uma função que consegue assumir outra com acesso irrestrito. CSPM responde se a configuração está correta; CIEM responde se a permissão é necessária.

O que é CNAPP?

É a categoria guarda-chuva que integra CSPM, CIEM, segurança de workload e de Kubernetes, e varredura de infraestrutura como código numa única plataforma, com correlação entre camadas. Consolidou-se como padrão de mercado a partir de 2023 e 2024.

Quais são os principais riscos de multicloud?

Cinco padrões recorrentes, segundo relatórios da Cloud Security Alliance e observação de auditoria: identidade fragmentada entre provedores, logs fragmentados em formatos distintos, segredos em silos com rotação descoordenada, rede entre nuvens com regras esquecidas ou contraditórias, e configuração default insegura herdada de épocas diferentes.