Modelo de responsabilidade compartilhada na nuvem

O que é o modelo de responsabilidade compartilhada na nuvem?

O modelo de responsabilidade compartilhada é uma divisão de deveres de segurança entre um provedor de serviços em nuvem e a organização que o usa. O provedor responde pelas instalações, pelo hardware, pelo sistema operacional hospedeiro e pela camada de virtualização. O cliente responde pelos dados, pelas identidades, pelas políticas de acesso e pela configuração de cada serviço que ativa.

A AWS enuncia sua metade do modelo de responsabilidade compartilhada em uma frase: "Segurança e conformidade são uma responsabilidade compartilhada entre a AWS e o cliente". A empresa separa as duas metades como segurança "da" nuvem e segurança "na" nuvem. A AWS opera a primeira. Você opera a segunda.

A Microsoft traça o piso do cliente no mesmo ponto: "Para todos os tipos de implantação de nuvem, você possui seus dados e identidades". Esses dois nunca se movem no modelo de responsabilidade compartilhada, seja qual for a sua compra.

O modelo de responsabilidade compartilhada atribui trabalho, não responsabilidade legal. Nada nele faz um provedor responder por como você configura o produto dele. A CISA diz isso às agências federais sem suavizar: as agências devem identificar e entender com clareza a delimitação de responsabilidades entre elas e seu provedor.

Três coisas que o modelo de responsabilidade compartilhada não é:

• Não é uma cláusula contratual que você possa negociar para baixo. O provedor não pode ver dentro dos seus dados, e você não pode chegar ao hypervisor dele.

• Não é idêntico entre provedores. A CISA alerta que os provedores podem definir essa relação de segurança compartilhada de forma diferente de um fornecedor para outro.

• Não é estático. Cada serviço novo que você habilita move a linha de novo.

Segurança da nuvem e segurança na nuvem

A segurança da nuvem é tudo o que o provedor opera e você não pode tocar. A segurança na nuvem é tudo o que você implanta, configura e a que dá acesso. O modelo de responsabilidade compartilhada é a linha entre as duas, e essa linha fica em um lugar diferente conforme o modelo de serviço.

Em IaaS você aluga máquinas e redes, então quase tudo acima do hypervisor é seu. Em PaaS o provedor também opera o sistema operacional e o runtime, de modo que a sua parte se reduz à aplicação e aos dados dela. Em SaaS você configura e alimenta software pronto, então o modelo de responsabilidade compartilhada deixa com você os dados, as contas e as configurações de compartilhamento.

O NIST descreveu o modelo de responsabilidade compartilhada em SP 800-210 antes de a linguagem de marketing se firmar. Para IaaS: os dados nas camadas de middleware, dados, aplicações e sistema operacional pertencem ao consumidor e estão sob o controle dele. Para SaaS: os dados gerenciados pela camada de aplicação pertencem ao consumidor e estão sob o controle dele. Superfície diferente, mesmo dono.

Responsabilidade por modelo de serviço, seguindo a divisão da Microsoft e o reparto IaaS, PaaS e SaaS do NIST SP 800-210.

Leia a tabela pelas três primeiras linhas. Os dados do cliente, as configurações e ajustes, e as identidades e usuários não trocam de mãos em nenhuma versão do modelo de responsabilidade compartilhada. Toda violação na nuvem originada em um bucket público, em um papel com privilégios a mais ou em uma chave vazada vive em uma dessas três linhas.

SaaS é onde o modelo de responsabilidade compartilhada é mais mal interpretado, porque a parte do provedor parece total. Não é. As configurações de compartilhamento, os colaboradores externos, os tokens de API e o ciclo de vida das contas continuam sendo seus, e um tenant SaaS sem autenticação multifator é uma falha do lado do cliente.

O modelo de responsabilidade compartilhada na Fluid Attacks

Trabalhamos nos dois lados do modelo de responsabilidade compartilhada. Testamos as configurações de nuvem dos nossos clientes com Cloud Security Posture Management (CSPM) e técnicas manuais, e operamos nossa própria infraestrutura de produção sobre a AWS sob o mesmo modelo de responsabilidade compartilhada pelo qual perguntamos a eles. É isto o que se vê, e o que não.

O que avaliamos e sob quais regras

Nosso CSPM revisa um ambiente da AWS em busca de configurações que descumprem requisitos de segurança, que é a metade do cliente no modelo de responsabilidade compartilhada, e faz isso de forma contínua em vez de uma vez por trimestre. Você registra o ambiente na nossa plataforma como um ativo Cloud (CSPM), que nossa documentação define assim: você está adicionando seu ambiente da AWS para ser testado com gestão da postura de segurança na nuvem.

O acesso é delimitado, não aberto, porque o modelo de responsabilidade compartilhada corre nas duas direções. Nossa documentação de conexão afirma que a Fluid Attacks alcança apenas os recursos que você autoriza e o resto da sua rede permanece privado. A regra de menor privilégio com a qual avaliamos você se aplica ao acesso que você nos dá.

Como isso se vê na prática

Cada achado na nuvem é mapeado para uma entrada do nosso catálogo aberto de fraquezas e para os requisitos que o fecham. Esse mapeamento transforma um alerta de scanner em algo sobre o que um desenvolvedor pode agir, e cada linha abaixo está do lado do cliente no modelo de responsabilidade compartilhada.

Cada fraqueza na nuvem que reportamos traz o requisito que a resolve.

Nossa entrada de database para armazenamento em nuvem acessível publicamente, com seus requisitos vinculados.

Como cumprimos a nossa própria parte

Também somos clientes do modelo de responsabilidade compartilhada, e nossa infraestrutura é reconstruída em vez de corrigida. Nossa documentação de stack diz que o Terraform é usado para escrever todo o nosso stack de infraestrutura como código e que a infraestrutura é regenerada do zero sempre que é necessária. Uma configuração que se desvia não sobrevive ao próximo deploy.

Os segredos nunca ficam legíveis em um repositório. Nós os gerenciamos com o Sops, que resolve os segredos no momento da implantação dentro do GitLab CI/CD, sem dependência em tempo de execução. Essa é a contramedida direta à fraqueza que mais encontramos no código dos clientes, e ela está do nosso lado do modelo de responsabilidade compartilhada exatamente como estaria do seu.

Nossos pentesters trabalham ambientes da AWS com AWS CLI, Pacu e enumerate-iam, todos listados no nosso conjunto público de ferramentas. As ferramentas trazem a má configuração à superfície. Uma pessoa encontra a cadeia que transforma três ajustes inofensivos isoladamente em uma escalada de privilégios, que é a parte do modelo de responsabilidade compartilhada que a automação sozinha não fecha.

O padrão se manteve por anos. Jonathan Armas, analista de segurança na Fluid Attacks, escreveu em Secure Cloud as Code que "as falhas mais comuns que encontramos quando testamos implantações de IaC são os segredos em texto claro e as credenciais embutidas no código". E acrescentou uma observação dos próprios trabalhos: "na maioria das vezes em que comprometi chaves da AWS, elas estavam configuradas com permissões excessivas".

Onde o nosso benchmark para

No benchmark da Fluid Attacks de 36 ferramentas AppSec de terceiros contra um dataset de 1.201 vulnerabilidades, um pentester encontrou 1.076 delas, o que é 89,6 % de recall com 100 % de precisão, enquanto nosso próprio scanner encontrou 273, ou 22,7 % de recall com 99 % de precisão. Ele tem dois limites que preferimos declarar a deixar que você deduza.

Esse benchmark rodou contra uma aplicação web, não contra um ambiente de nuvem. Ele não mede quão bem qualquer ferramenta detecta um bucket mal configurado ou um papel com privilégios a mais.

A distância entre 22,7 % e 89,6 % é o segundo limite, e a razão pela qual não apresentamos a varredura automatizada como a resposta completa à sua metade do modelo de responsabilidade compartilhada. Um scanner diz que um serviço de armazenamento está público. Ele não pode dizer se isso foi uma decisão ou um acidente, e sob o modelo de responsabilidade compartilhada só você pode responder isso.

A prática que decide o resto

A verificação contínua ganha de uma boa configuração inicial. A sua metade do modelo de responsabilidade compartilhada muda toda vez que alguém implanta, e uma revisão de março não diz nada sobre julho.

Nossa análise de segurança on-premises frente à nuvem sustenta que o monitoramento contínuo continua sendo do cliente, onde quer que a carga de trabalho rode. Aprofunde-se nos nossos textos sobre DevSecOps na AWS e no Azure.

Onde o modelo de responsabilidade compartilhada falha

O modelo de responsabilidade compartilhada falha do lado do cliente, em três lugares recorrentes: armazenamento aberto, identidades com mais privilégios do que o trabalho precisa e credenciais enviadas ao código-fonte. A Cloud Security Alliance colocou a má configuração com controle de mudanças insuficiente, a gestão de identidade e acesso, e as interfaces e API inseguras como as três principais ameaças do relatório Top Threats to Cloud Computing 2024. As três estão na metade do cliente do modelo de responsabilidade compartilhada.

O mesmo relatório aponta que os problemas associados tradicionalmente aos provedores de nuvem seguem perdendo importância. Os provedores melhoraram na metade deles do modelo de responsabilidade compartilhada. A lacuna se moveu para a nossa.

Armazenamento que responde a qualquer um

Um serviço de armazenamento acessível sem credenciais é o erro de nuvem mais antigo e ainda o mais produtivo para os atacantes. Nosso catálogo o descreve assim: algum serviço de armazenamento em nuvem usado pela aplicação pode ser acessado publicamente, sem exigir autenticação. E a correção é igualmente simples: restringir o acesso aos serviços de armazenamento público do sistema.

Não é um achado raro, e o modelo de responsabilidade compartilhada o coloca diretamente no cliente. No nosso Relatório de ataques 2026, o acesso não autorizado a arquivos em serviços de armazenamento em nuvem somou 13.499 instâncias reportadas e 500.832,48 unidades CVSSF de exposição ao risco nas aplicações que testamos em 2025.

Identidades com mais privilégios do que o trabalho precisa

O privilégio excessivo transforma um comprometimento pequeno em um grande. Nosso catálogo define a fraqueza como uma aplicação, um usuário ou um papel que têm mais privilégios do que precisam, e observa que um atacante pode aproveitar isso para executar ações normalmente restritas em um sistema.

A remediação é um requisito, não uma ferramenta: os usuários e as aplicações devem sempre ter um papel com o nível mínimo de privilégio necessário para executar suas funções. Nada do que um provedor de nuvem entregue vai aplicar isso por você, que é o modelo de responsabilidade compartilhada funcionando como foi projetado.

A gestão de identidade e acesso está inteiramente dentro da parte do cliente no modelo de responsabilidade compartilhada, e a identidade superprivilegiada raramente é uma pessoa: é um papel de serviço que ninguém revisou depois do lançamento. Nosso catálogo também marca o equivalente em rede, onde a definição de infraestrutura para os segmentos de rede na AWS é permissiva demais.

Credenciais que viajam com o código

Uma chave de acesso em um repositório é uma chave sem validade e sem dono, e nenhuma leitura do modelo de responsabilidade compartilhada passa ao provedor as credenciais embutidas no código. Nossa análise de DevSecOps na nuvem relata que os pentesters da Fluid Attacks encontram de forma repetida credenciais de serviços em nuvem dentro do código-fonte dos clientes, e que avaliamos os arquivos de infraestrutura como código pelas más configurações que vêm depois.

O número do Relatório de ataques 2026 quantifica isso: a informação sensível no código-fonte com credenciais chegou a 37,4 % dos sistemas que testamos, com uma exposição média ao risco de 112,62 unidades CVSSF por sistema afetado.

As credenciais no código-fonte afetaram 37,4 % dos sistemas que testamos em 2025.

Fraquezas do lado da nuvem no Relatório de ataques 2026 da Fluid Attacks, sobre sistemas testados entre 1º de janeiro e 31 de dezembro de 2025.

O que o modelo de responsabilidade compartilhada não resolve

Ele não diz como configurar nada, e não torna infalível a metade do provedor. Os próprios provedores reconhecem as duas lacunas.

O Google é o mais direto. Sua documentação de arquitetura afirma que, na opinião da empresa, o modelo de responsabilidade compartilhada fica aquém de ajudar os clientes de nuvem a obter melhores resultados de segurança, porque cada serviço tem um perfil de configuração diferente e pode ser difícil determinar qual é a melhor configuração de segurança. A resposta do Google é o que chama de destino compartilhado: o provedor assume um papel ativo no resultado do cliente em vez de traçar uma linha e se afastar.

A segunda lacuna é mais simples. O modelo de responsabilidade compartilhada pressupõe que a metade do provedor se sustenta, e às vezes ela não se sustenta. Em 2023, um agente de ameaças chegou às caixas de correio do Exchange Online de funcionários do governo dos Estados Unidos pela própria infraestrutura de autenticação do provedor. A Cyber Safety Review Board fez uma revisão independente, e o resumo da CISA sobre os achados aponta para as decisões do provedor e não para cliente algum: o relatório detalhou as decisões operacionais e estratégicas que levaram à intrusão.

Os clientes não teriam como prevenir essa. Ela ficou inteiramente do lado do provedor, e é a razão para checar o histórico de segurança de um provedor em vez de dar a metade dele como resolvida.

De quem foi a culpa

Três incidentes, três respostas diferentes do mesmo modelo de responsabilidade compartilhada. O que os separa não é o tamanho da empresa nem o provedor que ela escolheu. É de que lado do modelo de responsabilidade compartilhada a falha ficou.

Duas das três falhas ficaram do lado do cliente no modelo de responsabilidade compartilhada.

Sobre a Toyota, a revisão da Cloud Security Alliance concluiu que a causa raiz foi um erro ao configurar os ajustes de nuvem da companhia. Uma década de exposição não é um ataque sofisticado. É um ciclo de revisão ausente na metade do cliente do modelo de responsabilidade compartilhada.

A Twitch descreveu o próprio incidente nos mesmos termos: disse que foi resultado de uma mudança de configuração em um servidor que permitiu o acesso indevido de um terceiro não autorizado.

Se todo incidente na nuvem fosse culpa do cliente, o modelo de responsabilidade compartilhada seria um aviso legal e não uma divisão de trabalho.

Como cumprir a sua parte

Comece por escrever a linha. Peça ao seu provedor a versão documentada do modelo de responsabilidade compartilhada, serviço por serviço, e confronte-a com o que você realmente opera. A instrução da CISA às agências serve igual para um banco: identificar e entender a delimitação antes de precisar dela.

Aplique o menor privilégio aos papéis, não só às pessoas. Nosso requisito estabelece que os usuários e as aplicações devem ter o privilégio mínimo que a função exige. A gestão de identidade e acesso fica do seu lado do modelo de responsabilidade compartilhada em todos os modelos de serviço, e a identidade superprivilegiada costuma ser um papel de serviço que ninguém revisou depois do lançamento.

Tire as credenciais do código e coloque-as em um resolvedor. Os segredos cifrados que se resolvem na implantação eliminam toda a classe de achado que afeta mais de um terço dos sistemas que testamos. É a mudança com a melhor relação entre esforço e risco eliminado em todo o modelo de responsabilidade compartilhada.

Restrinja o armazenamento e a rede por padrão. Estes são os dois ajustes que o modelo de responsabilidade compartilhada deixa inteiramente com você. O acesso público em um serviço de armazenamento e uma regra de rede 0.0.0.0 são mudanças de uma linha que os atacantes encontram mais rápido que os auditores.

Exija autenticação multifator em cada conta administrativa de nuvem. O modelo de responsabilidade compartilhada a torna um controle do cliente em todos os modelos de serviço, inclusive SaaS, onde muitas vezes é o único controle que resta.

E depois verifique tudo de forma contínua. É aqui que uma abordagem DevSecOps ganha o seu lugar: uma revisão de configuração é exata enquanto ninguém implantar. Em uma pipeline que publica diariamente, isso são horas.

Conclusões

O modelo de responsabilidade compartilhada não é complicado, mas é lido de forma consistente como mais generoso do que é. No modelo de responsabilidade compartilhada, os provedores protegem o que operam. Você protege seus dados, suas identidades e cada configuração que toca, e essa última categoria é onde se origina quase todo incidente do lado do cliente.

A evidência de que o modelo de responsabilidade compartilhada falha do lado do cliente é consistente entre as fontes. As três principais ameaças de 2024 da Cloud Security Alliance são todas do lado do cliente. A Toyota passou uma década sem notar e a Twitch publicou o próprio código-fonte, as duas coisas por ajustes que ninguém releu.

A metade dos provedores também não é perfeita, como mostrou a intrusão no Exchange Online em 2023. Esse é um argumento para verificar as duas metades do modelo de responsabilidade compartilhada, não para dar nenhuma como coberta.

Perguntas frequentes

O que é o modelo de responsabilidade compartilhada na nuvem?

O modelo de responsabilidade compartilhada é a divisão de deveres de segurança entre um provedor de serviços em nuvem e seu cliente. O provedor protege as instalações físicas, o hardware, o sistema operacional hospedeiro e a camada de virtualização. O cliente protege os dados, as identidades, as políticas de acesso e a configuração dos serviços que habilita.

Quem responde quando uma má configuração na nuvem causa uma violação?

O cliente, em quase todos os casos. A configuração está do lado do cliente no modelo de responsabilidade compartilhada tanto em IaaS quanto em PaaS e SaaS, então um bucket de armazenamento público ou um papel superprivilegiado é um achado que o cliente corrige e um incidente que ele reporta. Os provedores entregam os controles; aplicá-los bem não faz parte do que eles vendem.

O modelo de responsabilidade compartilhada muda entre IaaS, PaaS e SaaS?

Sim, mas não para tudo. O sistema operacional, o runtime e os controles de rede se deslocam para o provedor conforme você vai de IaaS para SaaS. Os dados, as identidades e os ajustes de configuração ficam com o cliente nos três. O NIST SP 800-210 diz isso sem rodeios para SaaS: os dados gerenciados pela camada de aplicação pertencem ao consumidor e estão sob o controle dele.

Alguma vez a culpa é do provedor de nuvem?

Sim, e já aconteceu nos maiores. Em 2023 a Cyber Safety Review Board revisou de forma independente uma intrusão em caixas de correio do Exchange Online e documentou as decisões do provedor por trás dela. O Google também declarou que o modelo de responsabilidade compartilhada fica aquém de ajudar os clientes de nuvem a obter melhores resultados de segurança, e propõe no lugar o destino compartilhado. Dar a metade do provedor como resolvida é um risco em si.

A Fluid Attacks testa configurações na nuvem?

Sim, com CSPM em ambientes da AWS e testes manuais. Testamos a metade do cliente do modelo de responsabilidade compartilhada com CSPM, apoiados em técnicas manuais e na varredura de credenciais e de infraestrutura como código insegura. No nosso Relatório de ataques 2026, as credenciais no código-fonte apareceram em 37,4 % dos sistemas que testamos durante 2025, que é o problema do modelo de responsabilidade compartilhada que mais encontramos do lado do cliente.

Saiba o que cabe a você proteger

Nossos scanners e pentesters revisam de forma contínua sua configuração na nuvem, seu código e suas identidades, para que a metade do modelo de responsabilidade compartilhada que pertence a você fique verificada e não presumida. Teste gratuito · Fale conosco.