Cinco práticas de segurança no Amazon S3 que todo desenvolvedor deveria aplicar

Um guia publicado no AWS Builder Center lista cinco práticas básicas de segurança para quem usa Amazon S3 no dia a dia. O texto é raso sozinho, mas aponta pra armadilhas reais que todo dev que sobe bucket acaba encontrando.

Nota da redação: este artigo contém quatro afirmações que não encontramos respaldo na fonte citada (o post do AWS Builder Center) nem em documentação oficial da AWS consultada: a alegação de que o S3 é "disparado" o serviço mais usado por devs no Brasil, a afirmação de que um create-bucket via CLI/CI pode sair sem bloqueio público se a flag não for explícita, a de que SSE-S3 é gratuita, e a de que parte do monitoramento (CloudTrail/CloudWatch/access logs) vem desabilitada por padrão. São afirmações plausíveis sobre comportamento técnico da AWS, mas o leitor deve verificar essas informações na documentação oficial antes de tomar decisões de configuração com base só neste texto.

Um guia publicado no AWS Builder Center lista cinco práticas básicas de segurança para quem usa Amazon S3 no dia a dia. O texto é raso sozinho, mas aponta pra armadilhas reais que todo dev que sobe bucket acaba encontrando.

Um guia publicado no AWS Builder Center lista cinco práticas básicas de segurança para quem usa Amazon S3 no dia a dia. O texto é raso sozinho, mas aponta pra armadilhas reais que todo dev que sobe bucket acaba encontrando.

O Amazon S3 é, disparado, o serviço mais usado por quem desenvolve na AWS no Brasil: toda aplicação guarda alguma coisa lá, de imagem de upload a backup de banco. Por isso um bucket mal configurado não é um detalhe de infraestrutura, é uma porta aberta direto para dados de cliente.

No dia 10 de novembro, o AWS Builder Center publicou um post do membro da comunidade Chiranth G reunindo cinco práticas de segurança para quem trabalha com S3. O conteúdo é introdutório, do tipo que todo dev já ouviu em algum onboarding, mas serve de gancho pra entender onde cada uma dessas práticas realmente aperta no código e no bolso.

Bloquear acesso público parece básico, mas ainda engana

A primeira prática do post é habilitar o Block Public Access (BPA), o conjunto de configurações que impede que um bucket (ou toda a conta) fique acessível publicamente. Isso pode ser feito no nível da conta ou do bucket, e é a recomendação padrão da AWS para evitar que um bucket fique exposto sem necessidade clara de negócio.

O problema é que esse padrão seguro não cobre automaticamente quem provisiona via CLI, SDK ou IaC sem passar os parâmetros certos. Um aws s3api create-bucket chamado de dentro de um script de CI, por exemplo, pode sair sem bloqueio nenhum se a flag não for explícita:

aws s3api put-public-access-block \
 --bucket meu-bucket-producao \
 --public-access-block-configuration \
 BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Least privilege na prática é escrever a policy certa, não copiar um exemplo

O post cita o clássico: nunca dar s3:* quando a aplicação só precisa ler ou só precisa escrever. Isso é fácil de concordar e difícil de aplicar quando o deadline aperta e alguém cola uma policy genérica achada no Stack Overflow.

Uma policy de least privilege real restringe não só a ação, mas o recurso e, idealmente, a condição:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": ["s3:GetObject"],
 "Resource": "arn:aws:s3:::meu-bucket-producao/uploads/*",
 "Condition": {
 "StringEquals": { "aws:PrincipalTag/app": "checkout-service" }
 }
 }
 ]
}

Repare que a Resource já restringe ao prefixo uploads/, e não ao bucket inteiro. Um serviço de leitura de recibo não precisa enxergar a pasta de backup de outro time, mesmo que esteja no mesmo bucket. É esse tipo de granularidade que separa least privilege de teoria de curso introdutório.

Criptografia resolve dado parado, não dado mal exposto

O post lista as três opções de server-side encryption do S3: SSE-S3 (chave gerida pela própria AWS), SSE-KMS (chave do AWS KMS) e DSSE-KMS (criptografia em duas camadas, também via KMS). A escolha entre elas também costuma envolver critérios de custo e de necessidade de controle mais granular sobre a chave, não só segurança.

• SSE-S3 é gratuita e suficiente pra maioria dos casos sem exigência regulatória específica.
• SSE-KMS permite usar chaves gerenciadas via AWS KMS, o que dá mais controle sobre quem pode usar a chave de criptografia, mas envolve uma camada adicional de gerenciamento que SSE-S3 não tem.
• DSSE-KMS dobra essa camada de criptografia, usada em cenários que exigem proteção adicional além da criptografia simples via KMS.

Em volume alto de requisições (milhões por dia num bucket de imagens, por exemplo), vale avaliar com calma o impacto de trocar SSE-S3 por SSE-KMS antes de aplicar a mudança em produção.

Versionamento recupera arquivo apagado, mas também acumula custo

O S3 Versioning guarda cada versão anterior de um objeto, então um aws s3 cp que sobrescreve por engano um config.json de produção vira um incidente reversível em vez de um resgate de backup manual:

aws s3api list-object-versions --bucket meu-bucket-producao --prefix config.json
aws s3api get-object --bucket meu-bucket-producao --key config.json \
 --version-id <version-id-anterior> config-recuperado.json

O que o post não menciona é que versionamento sem lifecycle policy tende a acumular custo: cada versão antiga continua ocupando espaço e sendo cobrada, mesmo que ninguém mais a acesse. A prática recomendada é combinar S3 Versioning com uma regra de lifecycle que move versões não-atuais pra uma classe de armazenamento mais barata depois de alguns dias e expira depois de um prazo definido pelo time, não deixar acumular indefinidamente.

Monitorar access logs exige ligar o que vem desligado

A quinta prática junta CloudTrail, CloudWatch e os access logs do próprio S3. O detalhe que costuma pegar desenvolvedor de surpresa: parte desse monitoramento não vem habilitada por padrão, e descobrir isso só depois de um incidente é tarde demais.

Pra auditar com mais detalhe o acesso a objetos específicos, geralmente é preciso configurar explicitamente o que o CloudTrail vai registrar, o que pode ter implicações de custo dependendo do volume:

aws cloudtrail put-event-selectors \
 --trail-name trilha-producao \
 --event-selectors '[{"ReadWriteType": "All", "IncludeManagementEvents": true, "DataResources": [{"Type": "AWS::S3::Object", "Values": ["arn:aws:s3:::meu-bucket-producao/"]}]}]'

Sem esse passo, um time que investiga um vazamento de dados depois do fato pode descobrir que não tinha log nenhum do acesso detalhado ao objeto. O S3 server access logging é uma alternativa mais simples de ligar, direto na configuração do bucket, mas é outra forma de registro que vale configurar com atenção às necessidades de auditoria do time.

O que fica de fora do checklist

O post do Builder Center termina com um checklist de seis itens (bloquear acesso público, IAM least privilege, criptografia, versionamento, monitoramento e lifecycle policies), que funciona bem como lembrete rápido antes de um deploy. Mas um checklist não substitui revisão de código de infraestrutura: as mesmas regras de bucket policy que protegem um S3 hoje podem ser derrubadas amanhã por um terraform apply que sobrescreve a configuração sem ninguém perceber.

Vale tratar a configuração de segurança do bucket como código versionado e revisado em pull request, com teste automatizado checando se BlockPublicAcls segue true depois de qualquer mudança de infraestrutura. É essa automação, mais do que o checklist manual, que evita que a próxima mudança de terça-feira reabra a porta que foi fechada há seis meses.

Fonte

• AWS Builder Center: Amazon S3 Security – 5 Best Practices Every Developer Should Know, por Chiranth G, publicado em 10 de novembro de 2026.

Fonte: AWS Builder Center