Segurança em buckets S3: como evitar exposição pública de dados
Vazamentos por buckets mal configurados são clássicos. Veja como blindar acesso, criptografia e rastreabilidade no S3.
O S3 é um dos serviços mais usados da AWS e também um dos que mais aparecem em vazamentos de dados. O motivo quase nunca é uma falha do serviço, e sim configuração: um bucket marcado como público, uma policy permissiva demais ou ACLs herdadas que ninguém revisou. Como o S3 guarda dados, o impacto de um erro aqui costuma ser alto.
Este guia mostra como configurar buckets de forma defensiva: bloquear acesso público por padrão, escrever policies restritas, exigir criptografia e transporte seguro, e manter rastreabilidade. A meta é que um dado só fique acessível quando isso for uma decisão explícita e consciente.
Block Public Access e políticas
Mantenha o Block Public Access ativado no nível da conta e do bucket, salvo exceção justificada. Esse controle funciona como uma trava geral: mesmo que uma policy ou ACL tente tornar algo público, o bloqueio prevalece. Para conteúdo realmente público, como assets de um site, o padrão moderno é servir via CloudFront com origem restrita, em vez de abrir o bucket.
Prefira bucket policies a ACLs. As ACLs são um modelo antigo e confuso; o ideal é desabilitá-las definindo o controle de objetos como Bucket owner enforced e gerenciar acesso por policy e IAM. Escreva policies específicas, restringindo principal, ação e recurso, e evite curingas amplos.
"Condition": {
"Bool": { "aws:SecureTransport": "false" }
}Criptografia, versioning e SecureTransport
Habilite criptografia em repouso. A criptografia padrão já cobre todos os objetos novos, e para dados sensíveis vale usar uma chave KMS dedicada, que adiciona controle de quem pode descriptografar. Em paralelo, uma policy com a condição de SecureTransport nega qualquer acesso que não use HTTPS.
O versioning protege contra exclusão e sobrescrita acidental ou maliciosa, mantendo versões anteriores recuperáveis. Combinado com regras de ciclo de vida, ele equilibra proteção e custo, movendo versões antigas para armazenamento mais barato ou expirando o que não é mais necessário.
Logging e detecção
Habilite o registro de acesso para saber quem leu ou escreveu objetos, e considere data events do CloudTrail nos buckets sensíveis. Sem esse registro, um acesso indevido a dados pode passar completamente despercebido. Use também o Access Analyzer para S3, que aponta buckets com acesso externo não intencional.
Checklist prático
- Manter Block Public Access ativo na conta e nos buckets
- Desabilitar ACLs com Bucket owner enforced
- Escrever bucket policies específicas, sem curingas amplos
- Servir conteúdo público via CloudFront com origem restrita
- Exigir HTTPS com condição de SecureTransport
- Habilitar criptografia em repouso e KMS para dados sensíveis
- Ativar versioning e regras de ciclo de vida
- Habilitar registro de acesso e data events nos buckets críticos
- Rodar o Access Analyzer para S3 e revisar achados
- Revisar periodicamente buckets com acesso externo
Boas práticas
- Trate público como exceção explícita, nunca como padrão
- Prefira policy e IAM a ACLs para controle de acesso
- Use KMS dedicado para dados sensíveis e controle a chave
- Combine versioning com ciclo de vida para proteção e custo
- Mantenha rastreabilidade de leitura e escrita em buckets sensíveis
- Centralize a revisão de exposição com o Access Analyzer
Erros comuns
Bucket público para servir um site
Expõe potencialmente todo o conteúdo e dificulta controle; o padrão correto é CloudFront com origem restrita.
ACLs herdadas e esquecidas
Acesso concedido sem que ninguém perceba, fora do controle de policy.
Policy com curinga amplo no principal
Acesso muito além do necessário e risco de exposição não intencional.
Sem condição de SecureTransport
Dados podem trafegar sem HTTPS, sujeitos a interceptação.
Sem logging de acesso
Um acesso indevido a dados passa despercebido e a investigação fica sem evidência.
Quando procurar apoio especializado
Revisar a exposição de dados em muitos buckets e definir um padrão seguro reutilizável é parte do serviço de Segurança AWS da GUARDIASEC, que avalia exposição pública, criptografia e rastreabilidade e prioriza a correção dos buckets mais sensíveis.
Perguntas frequentes
O Block Public Access garante que nada fica público?
Ele é uma trava forte: quando ativo na conta e no bucket, prevalece sobre policies e ACLs que tentem tornar objetos públicos. É o controle mais eficaz contra exposição acidental. Ainda assim, vale combiná-lo com policies restritas e revisão periódica, porque exceções pontuais podem ser criadas de forma consciente.
Como sirvo arquivos públicos sem abrir o bucket?
O padrão recomendado é usar o CloudFront na frente do bucket, com a origem restrita para que o S3 só responda ao CloudFront. Assim o conteúdo fica acessível ao público pela distribuição, enquanto o bucket permanece fechado e protegido pelo Block Public Access.
Preciso de KMS ou a criptografia padrão basta?
A criptografia padrão já protege os dados em repouso e cobre objetos novos automaticamente. O KMS dedicado agrega controle granular sobre quem pode descriptografar e gera trilha de uso da chave, o que faz diferença para dados sensíveis. Para dados de baixa sensibilidade, a criptografia padrão costuma ser suficiente.
Versioning protege contra ransomware no S3?
Ajuda, porque mantém versões anteriores recuperáveis após sobrescrita ou exclusão. Para fortalecer, combine versioning com restrição de quem pode excluir versões e com mecanismos de retenção, de forma que um acesso comprometido não consiga apagar o histórico. Sozinho, o versioning é proteção parcial.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.