Modelo de responsabilidade compartilhada — o que é da cloud vs do cliente

O modelo de responsabilidade compartilhada define quem protege o quê em ambientes de cloud. É o ponto de partida de qualquer estratégia de segurança na nuvem. Provedores como AWS, GCP e Azure deixam isso claro na documentação, mas na prática a linha ainda confunde equipes inteiras.

A divisão básica

Responsabilidade do PROVEDOR (segurança DA cloud):
  - Hardware físico dos data centers
  - Rede global, roteadores, switches
  - Hypervisores e isolamento de VMs
  - Software base dos serviços gerenciados (RDS, S3, Lambda)
  - Patches do sistema operacional em serviços fully-managed

Responsabilidade do CLIENTE (segurança NA cloud):
  - Configuração dos serviços (IAM, security groups, buckets)
  - Dados armazenados e em trânsito
  - Sistema operacional de VMs/EC2 (patches, hardening)
  - Aplicações e código da workload
  - Gerenciamento de credenciais e chaves
  - Monitoramento, logging e resposta a incidentes

Varia conforme o modelo de serviço

O nível de responsabilidade do cliente muda conforme o modelo contratado:

On-Premises: cliente controla tudo (hardware → app)

IaaS (EC2, GCE, Azure VM):
  Provedor → hardware, hypervisor, rede física
  Cliente  → SO, runtime, middleware, app, dados, config de rede virtual

PaaS (Elastic Beanstalk, Cloud Run, App Service):
  Provedor → SO, runtime, plataforma
  Cliente  → app, dados, configurações da plataforma

SaaS (Google Workspace, Salesforce, Office 365):
  Provedor → quase tudo da infraestrutura
  Cliente  → dados, permissões de usuários, configuração de segurança do app

Erros comuns de interpretação

“O provedor garante disponibilidade, então eu não preciso de backup.” Disponibilidade do serviço não é o mesmo que proteção dos seus dados. Você deletou um bucket S3? O dado sumiu. O provedor não restaura o que o cliente apagou por acidente ou por ransomware.

“O serviço é gerenciado, então está seguro.” RDS gerenciado protege o SO do banco. Não protege seu schema, suas permissões de banco, ou suas queries sem prepared statements.

“A rede interna da cloud é confiável.” Movimento lateral entre recursos da mesma conta é possível se security groups e IAM estiverem mal configurados. Zero trust se aplica também dentro da cloud.

Mapeamento rápido — AWS como exemplo

S3:
  AWS  → durabilidade, criptografia de disco, disponibilidade
  Você → ACLs, bucket policy, bloqueio de acesso público, versionamento

EC2:
  AWS  → hardware, hypervisor, rede física
  Você → patches do SO, firewall (security groups), SSM agent, antivírus

Lambda:
  AWS  → SO, runtime, escalonamento
  Você → código, permissões da execution role, variáveis de ambiente

RDS:
  AWS  → SO, patches do engine, backups automáticos
  Você → senhas, permissões de banco, VPC/subnet group, acesso público on/off

IAM:
  AWS  → o serviço IAM em si
  Você → usuários, roles, policies, MFA — tudo é seu

Boas práticas

• Leia o Shared Responsibility Model do seu provedor. É documentação oficial e vincula o que eles garantem.
• Documente internamente quais controles são do time de plataforma vs do time de aplicação.
• Em auditorias, perguntas sobre “quem é responsável por X” devem ter resposta clara e escrita.
• Use frameworks como CIS Benchmarks e NIST CSF para mapear os controles que são sua responsabilidade.