Proteção de Dados no S3 com Bucket Policy, SSE, Macie e Object Lock — Guia Completo para o SCS-C03
_Category: Data Protection_
O S3 é o serviço de armazenamento mais usado na AWS e, ao mesmo tempo, o mais perigoso quando mal configurado. No exame SCS-C03, a proteção de dados no S3 é testada em múltiplas camadas: ordem de avaliação de políticas de controle de acesso, mecanismos de imutabilidade, detecção de dados sensíveis e design de logs de auditoria. Vamos organizar tudo isso usando a estrutura de cinco camadas: controle de acesso → criptografia → imutabilidade → classificação → auditoria, com os erros mais frequentes em produção.
---
O Modelo de Defesa em Profundidade do S3 (Acesso, Criptografia, Imutabilidade, Classificação e Auditoria)
A proteção de dados no S3 não é uma função isolada — ela exige uma abordagem de Defesa em Profundidade, com camadas que se complementam. Pense como proteger um cofre em um banco: o controle de acesso ao prédio é a primeira barreira, a fechadura do cofre é a segunda, o lacre interno é a terceira, os rótulos classificando o conteúdo são a quarta, e o livro de registros de entradas e saídas é a quinta. Cada camada protege o que a anterior não consegue cobrir sozinha.
Camada 1 — Controle de Acesso: Bucket Policy, ACL, IAM Policy, Block Public Access, S3 Access Points, S3 Access Grants e VPC Endpoint Policy. Camada 2 — Criptografia: SSE-S3, SSE-KMS, SSE-C, DSSE-KMS e imposição de TLS via . Camada 3 — Imutabilidade: Versioning, MFA Delete e Object Lock com modos Governance, Compliance e Legal Hold. Camada 4 — Classificação: Amazon Macie detecta automaticamente PII, dados financeiros e credenciais. Camada 5 — Auditoria: Server Access Logging, CloudTrail Data Events e S3 Inventory.
Dominar essas cinco camadas — e saber quando cada uma entra em ação — é o diferencial entre passar e ser reprovado na SCS-C03.
---
Bucket Policy, ACL e IAM Policy: Quem Tem Prioridade e Por Quê (Ordem de Avaliação)
Quando uma requisição chega ao S3, a AWS avalia as políticas em uma ordem específica. Sem entender essa ordem, diagnosticar uma negação de acesso vira um trabalho de detetive.
Ordem de avaliação: Deny explícito → Block Public Access → Allow na Bucket Policy → Allow na IAM Policy → Allow na ACL. Um Deny explícito em qualquer lugar bloqueia imediatamente, e o Block Public Access sobrescreve qualquer Allow público definido na Bucket Policy.
| Tipo de Política | Escopo | Características Principais | Armadilha no Exame | |-----------------|--------|---------------------------|-------------------| | IAM Policy | Principal IAM (usuário/role) | Baseada em identidade, sem suporte a condição de VPC | A mesma role pode existir em outra VPC, tornando o isolamento por VPC ineficaz | | Bucket Policy | Recursos (bucket/objeto) | Suporta condições como e | Acesso entre contas exige Allow na Bucket Policy E na IAM Policy da conta que acessa | | ACL | Objeto e bucket | Legado, granularidade por conta | Ativando Bucket Owner Enforced, toda ACL é desativada |
O ponto central do acesso entre contas: é preciso ter Allow na Bucket Policy da conta dona do bucket E Allow na IAM Policy da conta que está acessando. Um lado sem o outro resulta em negação. Usando para ativar Bucket Owner Enforced, as ACLs são desativadas e o controle passa a ser exclusivamente por Bucket Policy e IAM Policy — é como o dono do prédio recolher todas as chaves extras que distribuiu.
Para restringir por VPC, use a condição na Bucket Policy. Mas atenção: um S3 VPC Endpoint (Gateway ou Interface) precisa estar configurado antes que essa condição funcione. O S3 Gateway Endpoint é gratuito; o Interface Endpoint tem cobrança por hora.
---
Block Public Access e os Erros Mais Comuns de Exposição
O Block Public Access é o mecanismo de segurança criado especificamente para evitar o erro mais frequente com S3: deixar dados públicos por engano. Pode ser configurado no nível de conta e no nível de bucket, sendo o nível de conta mais restritivo.
BlockPublicAcls impede a adição de ACLs públicas. IgnorePublicAcls ignora ACLs públicas já existentes. BlockPublicPolicy bloqueia a aplicação de Bucket Policies públicas. RestrictPublicBuckets neutraliza políticas públicas existentes e limita o acesso a principals do serviço S3 e usuários IAM da conta dona do bucket.
Três erros comuns em produção merecem atenção. O primeiro é desativar o Block Public Access no nível de conta para deixar um bucket específico público e, inadvertidamente, expor outros buckets. O segundo é não saber que o CloudFront com OAC (Origin Access Control) permite servir conteúdo do S3 sem desativar o Block Public Access — times que não conhecem esse recurso acabam abrindo o bucket desnecessariamente. O terceiro é a combinação com condição ser interpretada pelo RestrictPublicBuckets como política pública e bloqueada — nesse caso, restrinja o Principal a contas ou roles específicas.
Para forçar o Block Public Access em toda a organização, adicione um Deny no SCP para ou use a regra do AWS Config com correção automática.
---
As 4 Opções de Criptografia no Servidor (SSE-S3, SSE-KMS, SSE-C e DSSE-KMS) — Tabela Comparativa
Desde 2023, todo bucket S3 tem SSE-S3 aplicado por padrão. Mas dependendo dos requisitos de conformidade e gestão de chaves, outras opções precisam ser escolhidas conscientemente.
| Opção | Gestão de Chaves | Integração KMS | Custo | Caso de Uso Principal | |-------|-----------------|----------------|-------|----------------------| | SSE-S3 | AWS totalmente gerenciada (AES-256) | Nenhuma | Gratuito | Criptografia básica, custo mínimo | | SSE-KMS | CMK no KMS, controle do cliente | Sim (logs de auditoria) | Cobrado por chamada à API KMS | Auditoria, rotação e controle entre contas | | SSE-C | Cliente fornece a chave diretamente | Nenhuma | Sem custo adicional (responsabilidade pelo gerenciamento) | Sem depositar material de chave na AWS | | DSSE-KMS | CMK no KMS, criptografia dupla | Sim | Aproximadamente 2x o custo do SSE-KMS | Regulamentações FIPS 140-3 com dupla criptografia |
A maior armadilha do SSE-KMS é o custo inesperado. Cada operação PUT/GET faz uma chamada à API KMS, e em buckets com alto volume de objetos os custos podem explodir rapidamente. A solução é o S3 Bucket Keys: usando uma DEK no nível do bucket, as chamadas à API KMS caem em até 99%. Se você usa SSE-KMS, ativar Bucket Keys é obrigatório.
SSE-C exige que o cliente forneça a chave em cada requisição — a AWS usa a chave para criptografar/descriptografar mas nunca a armazena. Três restrições essenciais: HTTPS obrigatório, chave perdida significa dados irrecuperáveis, e CRR (Cross-Region Replication) não é suportada. DSSE-KMS usa duas chaves KMS independentes para criptografia dupla e é a escolha em ambientes sujeitos a requisitos FIPS 140-3.
Para impor a criptografia, use na Bucket Policy: Deny em PUT sem a condição para forçar SSE-KMS. Para TLS, use Deny com .
!4 opções de criptografia no lado do servidor no S3
Object Lock e Versioning: Proteção Contra Modificação e Exclusão
O S3 Object Lock impede que objetos sejam excluídos ou sobrescritos por um período determinado. Dois pontos fundamentais: o Object Lock só pode ser ativado no momento da criação do bucket — depois disso não é possível habilitá-lo — e o Versioning precisa estar ativo para que o Object Lock funcione.
Governance Mode permite que administradores com a permissão especial removam o bloqueio ou alterem o período de retenção. É o modo flexível, adequado para cenários onde correções eventuais são necessárias.
Compliance Mode é o cofre lacrado que nem o presidente da empresa consegue abrir antes do prazo. Durante o período de retenção, nenhum usuário — nem mesmo o root da AWS — pode excluir o objeto ou reduzir o período de retenção. É obrigatório para conformidade com FINRA, SEC Rule 17a-4, HIPAA e regulamentações similares.
| Critério | Governance Mode | Compliance Mode | |----------|----------------|----------------| | Remoção do bloqueio | Possível com permissão especial | Impossível antes do vencimento | | Redução do período | Possível com permissão especial | Impossível | | Conta root AWS | Pode remover | Não pode remover | | Casos adequados | Testes, conformidade flexível | FINRA, SEC, HIPAA, obrigações legais |
Legal Hold bloqueia o objeto sem prazo de vencimento. Apenas quem tem a permissão pode ativar ou remover um Legal Hold. É usado para preservar evidências durante processos judiciais.
No Versioning, excluir um objeto cria um Delete Marker e preserva as versões anteriores intactas. MFA Delete exige autenticação MFA para excluir versões, protegendo contra exclusões em massa após comprometimento de credenciais — só pode ser ativado pelo root via CLI. Quando há conflito entre Lifecycle e Object Lock, o Object Lock sempre prevalece: objetos com retenção ativa não podem ser excluídos por regras Lifecycle.
---
Macie: Classificação Automática e Monitoramento de Dados Sensíveis
Amazon Macie usa machine learning para detectar e classificar automaticamente dados sensíveis em buckets S3. Em vez de inspecionar manualmente centenas ou milhares de buckets, o Macie localiza PII (informações pessoalmente identificáveis), dados financeiros, credenciais e informações de saúde de forma automática.
O Macie oferece dois recursos principais. A avaliação de segurança de buckets verifica automaticamente acesso público, criptografia e compartilhamento entre contas. A detecção de dados sensíveis — por meio de scans agendados ou sob demanda — identifica números de cartão de crédito, CPF/SSN, credenciais AWS e outros dados críticos. Os resultados são entregues via EventBridge para Security Hub, SNS e Lambda. O padrão de resposta para o cenário "PII enviado ao S3 deve gerar alerta e quarentena automáticos" é sempre Macie + EventBridge + Lambda.
Um ponto frequente no exame é diferenciar Macie de GuardDuty. Macie classifica o conteúdo dos dados (informações sensíveis). GuardDuty