Guias de Segurança
Exposição pública de armazenamento em nuvem: quando os dados podem vazar mesmo com o Block Public Access ativado
Vazamentos de bucket são eventos de configuração, não invasões. A AWS afirma que o Block Public Access não altera as políticas nem as ACLs existentes — então as configurações públicas continuam lá por baixo. Como auditar e corrigir de verdade.
Vazamentos de armazenamento de objetos normalmente não envolvem invasão. Ninguém invadiu um sistema, nenhuma credencial foi roubada e nada parece incomum nos logs. A configuração simplesmente tornou os dados públicos.
Por que os dados vazam sem ninguém invadir
Invasão
vulnerabilidade ou credenciais → invadir → levar os dados
correções, autenticação e monitoramento têm, cada um, uma chance de barrar
Configuração incorreta (bucket público)
saber (ou adivinhar) a URL → baixar
não é "a autenticação foi contornada" — a autenticação nunca foi exigida
O que torna esse tipo difícil de detectar é que o acesso não parece ilegítimo. O atacante envia um GET comum para um endpoint que é de fato público, então há pouco para a detecção de intrusão ou para anomalias nos logs captarem. É o mesmo problema de o que nunca deve ficar num diretório público, só que no armazenamento em vez de no servidor.
Cada uma das quatro configurações barra uma coisa diferente
O S3 Block Public Access são quatro configurações independentes que podem ser aplicadas em qualquer combinação. Os nomes são parecidos o bastante para serem tratados como um único botão, mas cada uma barra uma coisa diferente.
- BlockPublicAcls
- Faz falhar as tentativas de aplicar uma nova ACL pública (
PutBucketAcl,PutObjectAcl, ou umPutObjectcom ACL pública). As políticas e ACLs existentes não são modificadas, então uma ACL pública que já existe continua lá - IgnorePublicAcls
- Faz o S3 ignorar todas as ACLs públicas do bucket e dos objetos. Um
PutObjectcom ACL pública continua dando certo (essa é a diferença em relação ao BlockPublicAcls). Não remove as ACLs existentes e não impede que novas ACLs públicas sejam definidas - BlockPublicPolicy
- Rejeita uma política de bucket que permite acesso público (
PutBucketPolicye as chamadas relacionadas de access point). Não afeta as políticas existentes - RestrictPublicBuckets
- Restringe o acesso a um bucket com política pública a principais de serviço da AWS e a usuários autorizados da própria conta. Bloqueia o acesso entre contas (exceto por principais de serviço da AWS), inclusive a delegação não pública a uma conta específica
A propriedade que as quatro têm em comum, e que quase todos deixam passar
Repare que cada item acima diz que as políticas e ACLs existentes não são modificadas. A documentação afirma a consequência diretamente: "As configurações de bloqueio de acesso público não alteram as políticas nem as ACLs existentes. Portanto, remover uma configuração de bloqueio de acesso público faz com que um bucket ou objeto com política ou ACL pública volte a ficar acessível publicamente."
Ou seja, ligar o bloqueio não removeu o perigo. Ele só barra o acesso por enquanto, e as políticas e ACLs públicas continuam lá. Alguém removendo o bloqueio temporariamente para investigar, uma cópia para outra conta, um diff do Terraform que o reverte: qualquer um desses torna os dados públicos de novo. Defina o seu estado-alvo como "não público com o bloqueio desligado", não como "o bloqueio está ligado".
"Público" tem uma definição mais ampla do que você imagina
Você pode considerar um bucket privado e ainda assim o S3 avaliá-lo como público.
Avaliado como público
・Uma ACL que concede permissões a AllUsers ou AuthenticatedUsers — o segundo significa todo mundo que tem conta AWS, não todo mundo da sua empresa
・Uma política de bucket que nomeia principais com valores que contêm curinga ou variável de política
・Uma faixa de aws:SourceIp ampla demais (maior que /8 em IPv4, maior que /32 em IPv6, excluindo faixas privadas)
O S3 começa assumindo que uma política de bucket é pública e depois avalia se ela se qualifica como não pública. Se houver ambiguidade, ela é avaliada como pública.
Avaliado como não público
Uma política que limita o acesso a valores fixos sem curingas — um principal, um conjunto de blocos CIDR, aws:SourceArn, aws:SourceVpc, aws:SourceVpce, aws:SourceOwner, aws:SourceAccount e assim por diante.
O exemplo da própria documentação: aws:SourceVpc definido como vpc-* é público; definido com um valor fixo como vpc-91237329, não é. "Eu restringi" e "eu restringi a um valor fixo" são os dois lados desse julgamento.
Ative o bloqueio no nível da conta, não por bucket
A documentação recomenda aplicar o BlockPublicPolicy no nível da conta, porque uma política de bucket pode permitir que usuários alterem as configurações de bloqueio de acesso público daquele bucket.
Só no nível do bucket
alguém que pode mudar a política do bucket → insere uma política que desativa o bloqueio → o bucket pode ficar público
Nível da conta
mesmo depois de reescrita a política do bucket, o S3 bloqueia a política pública
Quando as configurações do access point, do bucket e da conta diferem, o S3 aplica a combinação mais restritiva. A configuração mais estrita vence, então restringir no nível de cima (a conta) significa que não dá para afrouxar embaixo — o privilégio mínimo aplicado ao armazenamento.
A ordem para corrigir
Veja o que está público — antes de esconder
Ligar o bloqueio primeiro interrompe a exposição e, ao mesmo tempo, destrói a sua capacidade de ver o que estava exposto. É exatamente isso que a documentação diz que o BlockPublicAcls permite: proteger contra acesso público "enquanto você audita, refina ou altera de outra forma as políticas e ACLs existentes". A AWS oferece o IAM Access Analyzer for S3, que lista os buckets cujas ACLs ou políticas concedem acesso público e, para cada achado, informa a origem e o nível desse acesso. Faça o inventário ali primeiro.
Ative as quatro configurações no nível da conta
A AWS recomenda ligar as quatro configurações de bloqueio de acesso público na sua conta (e em cada bucket, que é o que o controle S3.8 do Security Hub verifica). Confirme antes que as suas aplicações funcionam sem acesso público — se algo realmente precisar dele, como hospedagem de site estático, ajuste esse caso individualmente em vez de pular o controle em tudo.
Remova de fato as ACLs e políticas públicas (o passo mais importante)
O bloqueio não apaga as políticas públicas nem as ACLs públicas existentes. Volte ao inventário do passo 1 e remova ou reescreva cada uma. Só então você está no estado "não público com o bloqueio desligado". A maioria das equipes para no passo 2, e esse é o ponto principal deste artigo.
Nos buckets que precisam ser públicos, controle o que entra neles
Onde o acesso público é um requisito real, separe o armazenamento para que um bucket público só contenha coisas que podem ser públicas. Backups, dumps de banco de dados e listas de clientes não dividem bucket com arquivos publicados. O que você coloca num bucket decide quanto pode vazar dele. A versão do mesmo raciocínio no lado do servidor está em como manter o .env fora de alcance em hospedagem compartilhada.
Não confie no nome do arquivo
"Ninguém sabe a URL" não é controle de acesso (é o mesmo problema dos identificadores adivinháveis). Um nome impossível de adivinhar é uma proteção extra, não um substituto para a verificação de permissão. Quando precisar compartilhar algo temporariamente, use algo que expire sozinho — uma URL assinada com prazo — e mantenha fechada a configuração pública.
A visão deste site: incidentes de configuração só diminuem quando o estado é auditável
A exposição de buckets continua se repetindo não porque as pessoas são descuidadas, mas porque o estado não é visível. Ao contrário de uma permissão de arquivo ou de uma configuração de servidor, saber se o armazenamento é público depende da combinação de quatro camadas — política, ACL, configuração da conta, access point — e nenhuma delas sozinha dá a resposta. A nossa posição para áreas assim é deixar uma máquina avaliar a combinação em vez de depender da atenção humana: restrinja no nível de cima para que não dê para afrouxar embaixo, e refaça o inventário periodicamente com algo que dê o veredito público/não público por você. "Tomar cuidado" não é um controle — a mesma conclusão a que chegamos para dependências (primeiros passos com o osv-scanner).
Fontes (primárias)
- Amazon Web Services, "Blocking public access to your Amazon S3 storage" (Amazon S3 User Guide) — docs.aws.amazon.com (o comportamento das quatro configurações, a afirmação de que o bloqueio não altera as políticas nem as ACLs existentes, a definição de "público" e o motivo para recomendar a aplicação no nível da conta vêm todos deste documento)
Leia a seguir
- Onde colocar: o que nunca deve ficar num diretório público / como manter o .env fora de alcance em hospedagem compartilhada
- Credenciais: o que é perigoso no .env e nas chaves de API / chaves SSH e privilégio mínimo
- Inventário: o checklist de inventário de ativos
- O mesmo tipo de "vazamento por configuração": tomada de subdomínio e DNS pendente
FAQ
QSe o Block Public Access estiver ativado, estou seguro?
Você está num estado em que nada é acessível de fora neste momento, mas o perigo não desapareceu. A documentação da AWS afirma que as configurações de bloqueio de acesso público não alteram as políticas nem as ACLs existentes e que, por isso, remover uma configuração de bloqueio faz com que um bucket ou objeto com política ou ACL pública volte a ficar acessível publicamente. As políticas e ACLs públicas continuam lá, por baixo do bloqueio. O que você quer não é "o bloqueio está ligado", mas "nada seria público mesmo com o bloqueio desligado" — o que significa apagar as próprias políticas e ACLs públicas.
QDevo aplicar as configurações por bucket ou por conta?
Por conta. Sobre o BlockPublicPolicy, a documentação explica o motivo: uma política de bucket pode permitir que usuários alterem as configurações de bloqueio de acesso público daquele bucket, então qualquer pessoa que consiga mudar uma política de bucket poderia inserir uma política que desativa o bloqueio. Com a configuração ativada para a conta inteira, o S3 bloqueia políticas públicas mesmo que um usuário altere a política do bucket. Uma configuração no nível do bucket pode ser removida por quem consegue editar políticas de bucket.
QO que exatamente conta como "público"?
Uma definição mais ampla do que a maioria imagina. Uma ACL é pública se concede permissões aos grupos predefinidos AllUsers ou AuthenticatedUsers — e AuthenticatedUsers significa todo mundo que tem uma conta AWS, não todo mundo da sua empresa. Para políticas de bucket, o S3 começa assumindo que a política é pública e depois avalia se ela se qualifica como não pública; ela só se qualifica quando o acesso é limitado a valores fixos, sem curingas nem variáveis de política. Uma política que usa aws:SourceIp com uma faixa muito ampla (maior que /8 em IPv4) também é avaliada como pública.
QBuckets recém-criados são seguros por padrão?
A documentação diz que, por padrão, novos buckets, access points e objetos não permitem acesso público — mas que os usuários podem modificar políticas de bucket, políticas de access point ou permissões de objetos para permiti-lo. Então o padrão é o lado seguro, e quase todo incidente acontece onde alguém saiu desse padrão de propósito, ou temporariamente para algum trabalho. Não confie no padrão: você precisa de um controle que não possa ser desligado localmente (bloqueio no nível da conta) e de um jeito de ver quando algo saiu do lugar.