AWS Shared Responsibility Model Quem Cuida do Quê na Nuvem

Boa parte dos incidentes de segurança na nuvem não acontece porque a AWS falhou — acontece porque alguém assumiu, incorretamente, que a AWS cuidaria de algo que na verdade era responsabilidade do cliente. O Shared Responsibility Model (Modelo de Responsabilidade Compartilhada) é o framework que a AWS usa para deixar essa linha explícita, e é provavelmente o conceito de segurança mais citado — e mais mal compreendido — entre quem opera workloads na nuvem.

Este artigo detalha o modelo, como a linha de responsabilidade se desloca conforme o tipo de serviço usado, e onde estão os erros mais comuns na prática.

1. A frase que resume tudo

A AWS resume o modelo inteiro em uma única distinção:

AWS é responsável pela segurança DA nuvem (security of the cloud). O cliente é responsável pela segurança NA nuvem (security in the cloud).

Essa frase parece simples, mas o detalhe importante é que ela muda de posição dependendo de qual serviço você está usando. Não existe uma linha fixa e universal — existe uma linha que se desloca conforme o modelo de serviço (IaaS, PaaS, SaaS) e quanto da pilha técnica a AWS gerencia por baixo dele.

2. Segurança DA nuvem (responsabilidade da AWS)

Isso cobre a infraestrutura física e a camada de plataforma que sustenta todos os serviços AWS, independentemente do que o cliente escolhe rodar em cima dela:

• Data centers físicos: segurança de acesso físico, vigilância, controles ambientais (energia, refrigeração).
• Hardware: ciclo de vida de servidores, discos, equipamentos de rede — aquisição, manutenção e descarte seguro.
• Virtualização: segurança do hypervisor que isola as cargas de trabalho de diferentes clientes rodando na mesma infraestrutura física subjacente.
• Rede global: o backbone de fibra que conecta regiões, Availability Zones e edge locations, incluindo a isolação de tráfego entre regiões.
• Patching da infraestrutura de serviços gerenciados: para serviços como RDS, DynamoDB ou S3, a AWS também cuida do patching do sistema operacional e do software subjacente da plataforma — não apenas do hardware.
• Compliance da infraestrutura: auditorias regulares de terceiros (SOC 1/2/3, ISO 27001, PCI-DSS, entre outros) que certificam que a infraestrutura da AWS atende a padrões de segurança reconhecidos.

O cliente não tem acesso e não pode alterar nada dessa camada — e também não precisa se preocupar com ela: é inteiramente coberta pela AWS, com evidência de auditoria disponível via AWS Artifact.

3. Segurança NA nuvem (responsabilidade do cliente)

Isso cobre tudo que o cliente configura, insere ou constrói em cima da infraestrutura da AWS — e é onde a esmagadora maioria dos incidentes reais de segurança na nuvem acontece:

• Dados: classificação, criptografia (em repouso e em trânsito), e decisão de quem pode acessá-los.
• Identidade e acesso (IAM): usuários, roles, políticas de permissão, MFA — garantir que apenas identidades autorizadas acessem recursos, com o mínimo privilégio necessário.
• Configuração de aplicação e sistema operacional: em serviços IaaS, isso inclui aplicar patches de SO, configurar firewall a nível de instância (security groups, NACLs) e proteger o código da aplicação.
• Configuração de rede: VPCs, sub-redes, tabelas de rota, security groups — desenhar a segmentação de rede corretamente.
• Gestão de credenciais: chaves de API, segredos de aplicação, rotação de credenciais.
• Compliance da aplicação: garantir que a forma como os dados são tratados dentro da aplicação atende às regulações aplicáveis ao negócio (LGPD, HIPAA, PCI-DSS, conforme o caso).

A AWS fornece as ferramentas (IAM, KMS, Security Groups, GuardDuty, Config, entre outras) — mas usar essas ferramentas corretamente é responsabilidade do cliente. A AWS não pode, por exemplo, impedir que alguém configure um bucket S3 como público por engano — só pode fornecer os mecanismos (como o S3 Block Public Access, que passou a vir habilitado por padrão em buckets novos) para tornar esse erro menos provável.

4. Como a linha se desloca conforme o tipo de serviço

Esse é o ponto mais importante e mais frequentemente mal entendido do modelo: a divisão de responsabilidade não é a mesma para todo serviço da AWS. Ela varia de acordo com quanto da pilha técnica é gerenciado pela AWS por trás daquele serviço específico — na prática, o mesmo raciocínio de IaaS/PaaS/SaaS aplicado à segurança.

Infraestrutura (ex.: Amazon EC2)

Camada Responsável Data centers, hardware, virtualização, rede global AWS Sistema operacional convidado (patches, configuração) Cliente Firewall a nível de instância (Security Groups) Cliente Software instalado, configuração da aplicação Cliente Dados armazenados, criptografia de dados Cliente Gestão de identidade e acesso à instância Cliente

Rodar uma instância EC2 é o cenário onde o cliente assume a maior fatia de responsabilidade — equivalente a um modelo IaaS: a AWS garante o hardware e o hypervisor, tudo a partir do SO para cima é por conta do cliente.

Containers gerenciados (ex.: Amazon ECS/EKS com Fargate)

Camada Responsável Infraestrutura, orquestração dos nós, patching do SO do nó AWS Imagem de container, dependências da aplicação Cliente Configuração de rede do cluster/task Cliente IAM roles atribuídas a tasks/pods Cliente Dados da aplicação Cliente

A responsabilidade sobre o sistema operacional subjacente se desloca para a AWS quando se usa Fargate — o cliente continua responsável pelo que roda dentro do container.

Serviços gerenciados/PaaS (ex.: Amazon RDS)

Camada Responsável Infraestrutura, hypervisor, SO do banco, patching do motor do banco AWS Configuração de acesso ao banco (security groups, parâmetros) Cliente Gestão de usuários e permissões dentro do banco Cliente Backup (a AWS automatiza, mas a política de retenção é configurada pelo cliente) Compartilhado Dados armazenados no banco, criptografia Cliente

Aqui a AWS assume o patching do sistema operacional e do motor do banco — algo que, no EC2, seria integralmente do cliente. Ainda assim, a configuração de acesso e os dados continuam sendo do cliente.

Serverless/orientado a evento (ex.: AWS Lambda, Amazon S3)

Camada Responsável Infraestrutura, runtime, escalonamento, patching completo da plataforma AWS Código da função / política de bucket Cliente IAM role/policy anexada à função ou ao bucket Cliente Dados armazenados ou processados Cliente

Esse é o extremo oposto do EC2: a AWS absorve praticamente toda a pilha técnica. Mesmo assim, o cliente continua totalmente responsável pela configuração de acesso — e é exatamente aqui que estão os incidentes mais comuns e mais citados de segurança na nuvem: buckets S3 configurados como públicos por engano, ou funções Lambda com permissões IAM excessivamente amplas. A infraestrutura estar 100% protegida pela AWS não impede um vazamento de dados causado por uma política de acesso mal configurada pelo cliente.

5. O padrão que se repete: infraestrutura protegida não é dado protegido

O ponto central do modelo, resumido de forma direta: quanto mais gerenciado o serviço, menor a fatia de responsabilidade técnica do cliente — mas a responsabilidade sobre dados, identidade e configuração de acesso nunca desaparece, em nenhum modelo de serviço.

É por isso que a maioria dos incidentes de segurança envolvendo AWS (buckets S3 públicos expostos, credenciais vazadas em repositórios de código, políticas IAM excessivamente permissivas) não são falhas da AWS — são falhas do lado do cliente na fração de responsabilidade que sempre lhe pertence, independentemente de quão gerenciado seja o serviço escolhido.

6. Ferramentas da AWS que ajudam o cliente a cumprir sua parte

A AWS não pode atravessar a linha de responsabilidade — mas oferece serviços especificamente desenhados para reduzir a chance de erro do lado do cliente:

Ferramenta Ajuda a cobrir IAM + IAM Access Analyzer Identidade e acesso — identifica permissões não utilizadas ou excessivamente amplas AWS KMS Criptografia de dados em repouso, gestão de chaves Security Groups / NACLs Segmentação e controle de tráfego de rede S3 Block Public Access Reduz o risco de exposição acidental de buckets (habilitado por padrão desde 2023) Amazon GuardDuty Detecção de ameaças e comportamento anômalo na conta AWS Config Auditoria contínua de configuração de recursos contra regras definidas AWS Artifact Acesso a relatórios de compliance e certificações da infraestrutura AWS

Nenhuma dessas ferramentas “terceiriza” a responsabilidade de volta para a AWS — elas apenas tornam mais fácil para o cliente cumprir a parte que já é dele.

7. Erros comuns de interpretação do modelo

• “A AWS é responsável pela segurança, então meus dados estão seguros por padrão.” Incorreto — a AWS protege a infraestrutura; a configuração de acesso aos dados é sempre do cliente, em qualquer serviço.
• “Como uso um serviço gerenciado (RDS, Lambda, S3), não preciso pensar em segurança.” Incorreto — a fatia de responsabilidade técnica diminui, mas identidade, dados e configuração de acesso continuam sendo do cliente mesmo no serviço mais gerenciado que existe.
• “O modelo é o mesmo para todo serviço da AWS.” Incorreto — a linha se desloca conforme o serviço (EC2 vs. Fargate vs. RDS vs. Lambda), e entender onde ela está para cada serviço específico usado é parte do trabalho de arquitetura.
• “Backup automático da AWS significa que meus dados estão protegidos contra qualquer perda.” Parcialmente incorreto — a AWS automatiza o mecanismo de backup em muitos serviços gerenciados, mas a política de retenção, os testes de restore e a estratégia de disaster recovery continuam sendo decisões e responsabilidades do cliente.

Conclusão

O Shared Responsibility Model não é uma cláusula de contrato para ler uma vez e esquecer — é um mapa que precisa ser consultado para cada serviço específico que entra na arquitetura, porque a fronteira entre “isso é problema da AWS” e “isso é problema meu” muda de lugar a cada camada de abstração que se sobe. Entender exatamente onde essa linha está para o EC2, para o RDS, para o Lambda e para o S3 — em vez de tratar “a AWS cuida da segurança” como uma frase genérica — é o que separa uma arquitetura de nuvem bem protegida de uma que só parece estar.