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" }
}Acesso entre contas, VPC endpoints e URLs pré-assinadas
Nem todo bucket precisa ser alcançável pela internet, mesmo com o acesso público bloqueado. Para dados que só devem ser lidos por cargas dentro da sua rede, restrinja a policy a um VPC endpoint específico, de forma que qualquer requisição vinda de fora daquele caminho seja negada. É um controle de rede somado ao controle de identidade, e reduz o valor de uma credencial que vaze para fora do ambiente.
"Condition": {
"StringEquals": { "aws:SourceVpce": "vpce-0abc123exemplo" }
}Quando o acesso precisa cruzar contas, conceda o mínimo: uma role específica com permissão apenas sobre os prefixos necessários, em vez de abrir o bucket para uma conta inteira. Em ambientes com AWS Organizations, a condição aws:PrincipalOrgID recusa qualquer principal de fora da organização, o que contém erros de policy que abririam acesso amplo demais por engano.
URLs pré-assinadas dão acesso temporário a um objeto sem tornar o bucket público, o que é útil para downloads pontuais. O cuidado é a validade: um link com expiração longa vira uma credencial de fato, que continua funcionando muito depois de necessário e pode ser repassado. Gere URLs com o menor tempo de vida viável para o caso de uso e evite embuti-las em páginas ou logs de longa retenção.
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.
Versioning e ciclo de vida
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. Sem regras de ciclo de vida, o versioning acumula custo indefinidamente; com elas, você define por quanto tempo o histórico é retido antes de ser descartado.
Resiliência: Object Lock, MFA delete e replicação
Versioning sozinho é proteção parcial, porque quem tem permissão de excluir versões consegue apagar o histórico. O Object Lock fecha essa lacuna: no modo de conformidade, nem a conta raiz remove um objeto antes do fim do prazo de retenção. É o controle que sustenta backups e registros que precisam resistir a exclusão maliciosa, incluindo o cenário de uma credencial comprometida que tenta apagar dados.
aws s3api put-object-lock-configuration \
--bucket meu-bucket \
--object-lock-configuration \
'{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'Para dados críticos, considere replicar para um bucket em outra conta, mantendo uma cópia fora do alcance de quem administra o ambiente de produção. O MFA delete adiciona uma barreira extra à exclusão de versões e à desativação do versioning. Nenhum desses controles substitui uma rotina de backup testada, mas juntos reduzem a chance de perder dados de forma irreversível em um incidente.
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
- Restringir acesso à organização com aws:PrincipalOrgID quando aplicável
- Limitar buckets internos ao tráfego do VPC endpoint com aws:SourceVpce
- Definir expiração curta para URLs pré-assinadas
- Avaliar Object Lock para dados que exigem imutabilidade
- Manter uma cópia replicada em conta separada para dados críticos
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
- Restrinja buckets internos a redes e contas específicas
- Combine Object Lock e replicação para resistir a exclusão maliciosa
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.
URLs pré-assinadas com validade longa demais
O link continua válido muito além do necessário e pode ser repassado ou vazar.
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.
O que é o Object Lock e quando usar no S3?
O Object Lock impede que objetos sejam apagados ou sobrescritos antes do fim de um prazo de retenção. No modo de conformidade, nem a conta raiz consegue remover o objeto durante esse período. Faz sentido para backups, registros de auditoria e dados que precisam resistir a exclusão maliciosa. O cuidado é planejar bem os prazos, porque, uma vez definido em conformidade, o bloqueio não pode ser afrouxado antes de expirar.
Como restrinjo um bucket para acesso apenas pela minha VPC?
Você adiciona à bucket policy uma condição que exige que a requisição venha de um VPC endpoint específico, usando a chave aws:SourceVpce. Assim, acessos que não passam por aquele caminho de rede são negados, mesmo que a identidade tenha permissão. É uma camada de rede sobre o controle de identidade, útil para dados que só devem ser lidos por cargas internas.
URLs pré-assinadas são seguras para compartilhar arquivos?
São úteis para dar acesso temporário a um objeto sem abrir o bucket, mas funcionam como uma credencial: quem tem o link tem o acesso enquanto ele for válido. Gere URLs com o menor tempo de expiração viável, evite colocá-las em páginas públicas ou logs de longa retenção e lembre que elas não podem ser revogadas individualmente antes de expirar. Para acesso recorrente, prefira conceder permissão à identidade em vez de gerar links longos.
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.