Modelo de responsabilidade compartilhada

Na AWS, segurança e conformidade são uma responsabilidade compartilhada, resumida em duas frases:

• Segurança DA nuvem (AWS): proteger a infraestrutura que roda todos os serviços — hardware, software, rede e instalações físicas dos data centers.
• Segurança NA nuvem (cliente): tudo o que você coloca e configura em cima dessa infraestrutura. O tamanho dessa fatia depende dos serviços que você escolhe.

Essa segunda frase é a mais importante: a linha divisória não é fixa. Ela muda de serviço para serviço, e também depende de como o serviço se integra ao seu ambiente e das leis e regulações que se aplicam a você.

Uma forma prática de pensar é em três categorias de serviço, que a própria AWS usa em guias como a Financial Services Lens: infraestrutura, containers (plataforma gerenciada) e serviços abstratos.

Categoria	Exemplo	A AWS opera	Você cuida de
Infraestrutura (IaaS)	Amazon EC2	Instalações, hardware, rede física, camada de virtualização e SO do host.	SO convidado (atualizações e patches), software instalado, security groups, dados, IAM.
Containers / plataforma	Amazon RDS	Também o SO da instância e o software do motor de banco.	Configuração do banco, usuários do banco, rede (VPC, security groups), backups/retenção, criptografia, IAM, agendamento de manutenção.
Abstratos	Amazon S3, Amazon DynamoDB, AWS Lambda	Infraestrutura, SO e plataforma; você só acessa endpoints.	Dados (classificação e opções de criptografia), permissões IAM e políticas de recurso, código e dependências (no Lambda).

Quanto mais abstrato o serviço, menos camadas ficam com você. Mas repare na última coluna: ela nunca fica vazia. Dados, identidades e permissões são sempre seus.

Patch

• EC2: aplicar patches no SO convidado e nas aplicações é tarefa sua (por exemplo, com AWS Systems Manager Patch Manager).
• RDS: a AWS identifica vulnerabilidades, desenvolve e publica as atualizações de SO e de versão do motor e avisa você. A sua parte é revisar essas atualizações e aplicá-las: escolher a janela de manutenção, aplicar o update ou agendar o restart dentro do prazo comunicado.
• Lambda: com runtime gerenciado no modo Auto (padrão), a própria AWS aplica as atualizações do runtime. Se você usa imagem de container, reconstruir a imagem a partir da base atualizada e reimplantar é sua tarefa. As bibliotecas que você empacota também são suas.
• S3 e DynamoDB: a AWS aplica os patches sem nenhuma ação sua.

Configuração e acesso

• Num banco RDS, quem cria usuários, define senhas, ajusta parâmetros e decide se a instância fica acessível publicamente é você.
• Num bucket S3, novos objetos já são criptografados com SSE-S3 por padrão, e o DynamoDB criptografa todos os dados em repouso. Mesmo assim, escolher o tipo de chave (por exemplo, uma chave gerenciada pelo cliente no AWS KMS), quem pode usá-la e quem pode ler os dados continua sendo decisão sua.

O modelo também vale para os controles de TI que um auditor vai avaliar. A AWS os divide em três tipos:

Tipo	O que é	Exemplos
Herdado	Você herda integralmente da AWS.	Controles físicos e ambientais dos data centers.
Compartilhado	Existe nas duas camadas, em contextos diferentes: a AWS implementa na infraestrutura, você implementa no que usa.	Gestão de patches, gestão de configuração, conscientização e treinamento (a AWS treina os funcionários dela; você treina os seus).
Específico do cliente	Só seu, por depender da aplicação que você implanta.	Proteção de serviços e comunicações, ou zoneamento de dados em ambientes de segurança específicos.

Para os controles herdados, você não precisa provar nada sozinho: usa os relatórios da AWS como evidência. É o tema da lição 4.

A boa prática SEC01-BP05 pede que você avalie se dá para reduzir o seu escopo de gestão de segurança escolhendo serviços gerenciados, que transferem parte dos controles para a AWS. Rodar tudo em EC2 costuma deixar com você a maior fatia de responsabilidade.

Exemplos citados pelo Well-Architected: Amazon RDS em vez de um banco instalado à mão numa VM, Amazon EKS ou Amazon ECS para orquestrar containers e opções serverless para novas aplicações.

O ganho vai além do operacional: menos controles para operar também pode significar menos requisitos de conformidade para você comprovar. O tema volta com mais detalhes na lição 11.

• "É gerenciado, então a AWS cuida da segurança": ela cuida de mais camadas, mas dados, acesso e configuração continuam com você.
• Esquecer o agendamento de updates: no RDS ou no Lambda com modos manuais, a atualização existe, mas pode não chegar ao seu recurso se você não agir. O AWS Health ajuda a acompanhar esses eventos.
• Hospedar banco em VM sem comparar: o Well-Architected aponta como anti-padrão não avaliar o serviço gerenciado equivalente, nem incluir o esforço de segurança no custo total.
• Assumir que a matriz é igual para todos: consulte o capítulo de segurança da documentação de cada serviço. Para uma visão consolidada, veja a matriz de responsabilidade.

A AWS cuida da segurança DA nuvem; você, da segurança NA nuvem. A linha sobe conforme o serviço fica mais abstrato (EC2 → RDS → S3/DynamoDB/Lambda), mas dados, criptografia, IAM e configuração são sempre seus. Controles podem ser herdados, compartilhados ou específicos do cliente. Escolher serviços gerenciados é a forma mais direta de reduzir o seu escopo (SEC01-BP05).

• SEC01-BP05 Reduce security management scope

• Shared Responsibility Model — AWS
• Shared responsibility — Security Pillar
• Maintaining a DB instance — Amazon RDS
• Shared responsibility model for Lambda runtime management