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
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 ()
- • Classificar seus dados e definir quem pode acessar
- • Configurar e 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 |
Padrão do exame: "Quem aplica patches no SO do RDS?" → AWS. "Quem aplica patches no SO de uma EC2?" → cliente. Não memorize por cor — raciocine pelo tipo de serviço.
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 —
📋 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.
Erro comum fatal: confundir "AWS é segura" com "minha aplicação na AWS é segura". A AWS pode ser perfeitamente segura e ainda assim você sofrer um vazamento porque configurou S3 como público. O cliente é responsável por 100% das decisões de configuração que afetam seus dados.
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?
Take-aways: AWS protege a nuvem (hardware, hipervisor, DCs físicos, serviços gerenciados). Você protege o que está dentro (IAM, dados, configurações, código). A linha muda conforme o serviço — mais gerenciado = mais responsabilidade da AWS. Dados e identidades são SEMPRE do cliente. Compliance é herdada em parte, mas nunca 100% garantida só pela AWS.
Próximos passos sugeridos
Discussão
Carregando…