Atualizado em
O modelo de responsabilidade compartilhada define com clareza o que é papel do provedor de cloud e o que é papel da sua empresa. Confundir os dois é a origem de boa parte dos incidentes de segurança em ambientes cloud — e este artigo vai mostrar exatamente onde cada linha está.
O que é o modelo de responsabilidade compartilhada
Imagine que você aluga um escritório em um prédio comercial. O condomínio cuida da estrutura do edifício, da segurança do hall de entrada, dos elevadores e da energia elétrica. Você cuida do que acontece dentro do seu andar: quem tem a chave, o que fica guardado no cofre, se os computadores têm senha de acesso. Se alguém arrombar sua sala porque você deixou a porta aberta, não adianta culpar o condomínio — a porta era sua responsabilidade.
Em cloud é a mesma lógica. O provedor — seja ele de cloud privada como a Adentro ou de cloud pública — entrega uma infraestrutura segura. Você é responsável pelo que constrói e configura sobre essa infraestrutura.
O conceito parece simples, mas a maioria dos incidentes de segurança em cloud acontece exatamente nessa fronteira mal compreendida. Times de TI assumem que o provedor cuida de tudo. Auditores encontram brechas óbvias que estavam na zona de responsabilidade do cliente, não do fornecedor.
Como o limite muda conforme o modelo de serviço
O problema real aqui é que o limite de responsabilidade não é fixo — ele se move dependendo do tipo de serviço que você contrata.
IaaS (Infraestrutura como Serviço): O provedor gerencia o datacenter, os servidores físicos, o storage físico, a rede física e o hipervisor. Você gerencia absolutamente tudo acima disso: sistema operacional (incluindo patches e hardening), runtime de aplicação, middleware, configurações de rede virtual (grupos de segurança, VLANs, regras de firewall), dados e identidades. Em IaaS, a liberdade é máxima e a responsabilidade é proporcional. É o modelo mais comum em cloud privada.
PaaS (Plataforma como Serviço): O provedor passa a gerenciar também o sistema operacional e o runtime. Você gerencia o código da aplicação, os dados, as configurações de acesso à plataforma e as integrações. Serviços de banco de dados gerenciado, por exemplo, tiram de você a responsabilidade de patching do SO do banco — mas não tiram a responsabilidade de quem tem acesso ao banco, de como os dados são cifrados e de como as backups são configuradas.
SaaS (Software como Serviço): O provedor gerencia tudo, da infraestrutura ao código da aplicação. Você ainda é responsável por quem tem acesso ao serviço, com quais permissões, como os dados são classificados dentro do sistema e como o serviço se integra ao resto do seu ambiente. Muita empresa acha que ao contratar SaaS não tem mais responsabilidade de segurança — e aí aparecem as contas de funcionários demitidos ainda ativas, dados confidenciais em pastas compartilhadas publicamente e ausência de MFA. É o mesmo raciocínio que explica por que o Microsoft 365 não faz backup dos seus dados.
Os erros mais comuns que expõem sua empresa
Na prática, o que mais aparece em auditorias e investigações de incidentes são variações dos mesmos problemas recorrentes.
Storage mal configurado é o campeão. Buckets de armazenamento criados rapidamente para um projeto, com permissão pública por descuido ou por pressa, e lá ficam — com dados de clientes, contratos, planilhas internas — acessíveis para qualquer pessoa com a URL. A ferramenta que cria o bucket não vai gritar que ele está público: isso é decisão do operador.
Ausência de patch no sistema operacional das VMs é o segundo mais frequente. Em IaaS, o SO dentro da VM é sua responsabilidade. Ambientes cloud que ficam meses sem atualização de segurança são alvos fáceis para exploração de vulnerabilidades conhecidas — inclusive algumas com exploits públicos disponíveis há anos. Estruturar um processo de gestão de vulnerabilidades é o que fecha essa lacuna.
MFA desabilitado ou opcional fecha o pódio. Acesso ao console de administração do ambiente cloud com apenas usuário e senha é uma brecha que não deveria existir hoje. Força bruta, credential stuffing e phishing são eficientes demais contra autenticação simples. MFA não é opcional para contas privilegiadas — e é o primeiro passo de qualquer estratégia de gestão de identidade e acesso.
Outros erros frequentes incluem: regras de grupo de segurança excessivamente permissivas (“abre tudo para testar e esquece”), chaves de API com acesso irrestrito e sem rotação, e ausência de logging — o que significa que quando algo acontece, você não tem como investigar o que foi acessado, por quem e quando. É exatamente o problema que um SIEM resolve.
Tabela de responsabilidades por camada e modelo
| Camada | IaaS | PaaS | SaaS |
|---|---|---|---|
| Datacenter físico | Provedor | Provedor | Provedor |
| Rede física e hipervisor | Provedor | Provedor | Provedor |
| Sistema operacional | Cliente | Provedor | Provedor |
| Runtime e middleware | Cliente | Provedor | Provedor |
| Configuração de rede virtual | Cliente | Compartilhada | Provedor |
| Aplicação e código | Cliente | Cliente | Provedor |
| Identidades e acessos | Cliente | Cliente | Cliente |
| Dados e classificação | Cliente | Cliente | Cliente |
| Criptografia de dados | Compartilhada | Compartilhada | Compartilhada |
| Logs e monitoramento | Compartilhada | Compartilhada | Compartilhada |
A coluna “Compartilhada” significa que provedor e cliente têm papéis distintos na mesma camada: o provedor fornece a capacidade (por exemplo, o serviço de criptografia e as chaves gerenciadas por padrão), e o cliente decide como usar e se quer trazer suas próprias chaves.
Como documentar para auditorias de compliance
Imagine que você passa por uma auditoria ISO 27001 ou PCI DSS e o auditor pergunta: “Como vocês garantem a segurança dos dados armazenados no ambiente cloud?” Sem documentação do modelo de responsabilidade, a resposta vai ser vaga — e auditores não gostam de respostas vagas.
A forma correta de documentar é criar uma matriz de responsabilidade — um documento que lista cada camada e controle de segurança do ambiente, especifica se a responsabilidade é do provedor, do cliente ou compartilhada, e indica como cada controle é evidenciado.
Para o que é responsabilidade do provedor, você documenta com o contrato de serviço, o SLA, os relatórios de compliance que o provedor disponibiliza (ISO 27001, SOC 2, etc.), o DPA e eventuais relatórios de auditoria de terceiros. A Adentro disponibiliza documentação técnica e evidências de compliance para clientes que precisam passar por processos de auditoria.
Para o que é responsabilidade sua, você documenta com políticas internas, registros de configuração, logs de acesso, relatórios de scan de vulnerabilidade e evidências de treinamento. Se não está documentado, para o auditor não aconteceu.
Essa matriz também serve para um propósito interno valioso: ela força a conversa entre TI, segurança e negócio sobre onde estão as lacunas — antes que um incidente ou uma auditoria as exponha.
Quer um mapeamento de responsabilidades adaptado ao seu ambiente? O time técnico da Adentro pode ajudar na construção dessa documentação. Entre em contato com nosso suporte.