Modelo de Responsabilidade Compartilhada
Em cloud computing, nada é mais mal interpretado do que "quem é responsável pela segurança". A resposta: é compartilhada — e a linha divisória depende do serviço. A AWS chama essa linha de Shared Responsibility Model, e você precisa entendê-la de forma cirúrgica: o exame CLF-C02 dedica 30% das questões ao domínio de segurança, e quase todas começam perguntando "quem é responsável por isso?".
Onde isso entra no exame
Este é o domínio de maior peso do CLF-C02 e o modelo de responsabilidade compartilhada é o primeiro tópico. Esperam-se questões de cenário: "X aconteceu, quem é responsável?". A regra mental é simples — mas aplicá-la em cada serviço exige saber o quão "gerenciado" ele é.
A grande divisão: of vs. in
┌──────────────────────────────────────────────────────────────┐ │ RESPONSABILIDADE DO CLIENTE │ │ "SECURITY IN THE CLOUD" │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Dados do cliente │ │ │ │ Plataforma, aplicações, IAM │ │ │ │ Configuração SO, rede e firewall │ │ │ │ Criptografia client-side & integridade dos dados │ │ │ │ Criptografia server-side (cliente habilita/config) │ │ │ │ Tráfego de rede (proteção, firewall) │ │ │ └──────────────────────────────────────────────────────┘ │ │ │ ├──────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Software: compute, storage, database, networking │ │ │ │ Hardware / AWS global infrastructure │ │ │ │ Regiões, AZs, Edge Locations │ │ │ └──────────────────────────────────────────────────────┘ │ │ │ │ RESPONSABILIDADE DA AWS │ │ "SECURITY OF THE CLOUD" │ └──────────────────────────────────────────────────────────────┘
A mnemônica do exame: AWS protege a cloud; você protege o que está DENTRO da cloud.
O que a AWS SEMPRE faz
- • Segurança física dos data centers (24/7, controle de acesso, câmeras, guardas)
- • Manutenção do hardware (troca de discos, servidores, racks)
- • Manutenção do hipervisor (virtualização)
- • Segurança da rede global da AWS (backbone, DDoS Shield Standard gratuito)
- • Patching e atualização de serviços gerenciados (RDS, Lambda, DynamoDB, S3)
- • Descomissionamento seguro de mídia (discos destruídos ao falhar)
- • Compliance das instalações (SOC 1/2/3, ISO 27001, PCI-DSS Level 1, HIPAA-eligible)
O que VOCÊ (cliente) SEMPRE faz
- • Gerenciar contas, usuários, grupos e permissões (
IAM) - • Classificar seus dados e definir quem pode acessar
- • Configurar
Security Groupse NACLs - • Habilitar criptografia em repouso e em trânsito (AWS fornece ferramentas, mas você ativa)
- • Configurar e rotacionar credenciais
- • Monitorar atividade (CloudTrail, GuardDuty) e responder a alertas
- • Garantir compliance das suas aplicações com leis (LGPD, GDPR, HIPAA)
A linha divisória muda conforme o serviço
Esse é o ponto mais importante — e o mais cobrado. Quanto mais gerenciado o serviço, mais responsabilidade fica com a AWS:
| Tipo | Exemplo | AWS cuida de | Você cuida de |
|---|---|---|---|
| IaaS | EC2 | Hardware, hipervisor | SO, patches, firewall, app, dados |
| Container gerenciado | ECS Fargate | Hardware, SO, runtime | Imagem de container, app, dados, IAM |
| PaaS (managed) | RDS, Elastic Beanstalk | Hardware, SO, runtime, patches | Schema, queries, dados, IAM |
| SaaS | Chime, WorkMail | Praticamente tudo | Apenas como usa + usuários |
Exemplos clarinhos — quem faz o quê
| Cenário | Responsável |
|---|---|
| Disco físico do servidor falha e precisa ser trocado | AWS |
| Vulnerabilidade Log4Shell no código da sua aplicação Java | Cliente |
| Senha de admin foi deixada em código-fonte público no GitHub | Cliente |
| Hipervisor da EC2 tem CVE crítica (ex: Meltdown) | AWS |
| Security Group permite SSH aberto para a internet | Cliente |
| Bucket S3 foi tornado público por engano | Cliente |
| DDoS de camada 4 na rede global da AWS | AWS (Shield Standard) |
| DDoS de camada 7 (HTTP flood) na sua aplicação | Cliente (usar Shield Advanced + WAF) |
| Funcionário demitido ainda tem acesso IAM ativo | Cliente |
| Dados do cliente precisam ser apagados definitivamente ao encerrar conta | AWS garante + cliente solicita |
Cenários de decisão
📋 Empresa migra app PHP legada para AWS. Quer menor responsabilidade operacional
Quanto mais gerenciado o serviço, menos responsabilidade do cliente sobre patching, runtime e SO. Lambda é o extremo: você só cuida do código.
Alt: EC2 + Apache — Viável, mas exige patching do SO, Apache, PHP e configuração de ALB + Auto Scaling manual
📋 Banco precisa provar que só ele acessa suas chaves de criptografia
No modelo de responsabilidade compartilhada, o banco é dono das chaves e do acesso. CloudHSM permite controle total (ninguém da AWS tem acesso). KMS com BYOK também é aceito em regimes de compliance exigentes.
📋 Startup precisa compliance PCI-DSS para processar cartões
A AWS é PCI-DSS Level 1 para a infra física. Mas o cliente ainda precisa implementar segmentação de rede, criptografia, IAM mínimo, auditoria (CloudTrail) e revisão de código. Compliance herdada reduz escopo, mas não elimina.
Perguntas típicas de exame (Q&A)
❓ Quem é responsável por criar, manter e rotacionar as credenciais IAM?
❓ Em Lambda (serverless), quem cuida do patching do sistema operacional?
❓ Em EC2, quem instala o antivírus se a empresa exige?
❓ Quem é responsável se um funcionário compartilhar uma access key no Slack e houver uso indevido?
Quiz rápido
3 perguntas · Acerte tudo e ganhe o badge 🎯 Gabarito