No Amazon S3, você faz upload de objetos (arquivos), escolhe uma classe de armazenamento, define quem pode acessar o arquivo, configura exclusão automática e muito mais. A cobrança é por hora, e você pode excluir qualquer objeto a qualquer momento para parar de pagar pelo armazenamento.
Um dos recursos lançados pela AWS é o Object Lock — um mecanismo que impede a exclusão ou sobrescrita de objetos. Ele foi pensado para proteger dados de retenção de longo prazo, seja por questões de compliance ou para fins de arquivamento, contra remoções acidentais ou maliciosas.
Ao criar um bucket, você pode escolher um Retention Mode do Object Lock, que determina como a AWS vai restringir as exclusões:
- Governance mode — Os objetos ficam protegidos contra escrita, mas usuários com permissões especiais conseguem sobrepor ou remover o bloqueio.
- Compliance mode — Os objetos ficam totalmente imutáveis durante o período de retenção definido. Ninguém — nem mesmo o usuário root da conta ou o suporte da AWS — consegue excluí-los nesse intervalo.
Nas duas opções, você pode definir um período de retenção entre 1 dia e 100 anos, contado individualmente para cada objeto a partir do momento em que ele é enviado ao S3.
Depois que o Object Lock está ativo em um bucket, você pode definir o modo de bloqueio e o período de retenção de cada objeto no momento do upload. Se essas configurações não forem informadas durante o upload, valem as configurações padrão.
Se você alterar as configurações padrão depois, a mudança vale apenas para os novos objetos — os objetos existentes mantêm a configuração de bloqueio com a qual foram enviados.
Vamos focar no Compliance mode:
Se você ativá-lo, depois que um objeto for enviado, nenhuma IAM Role ou usuário — nem mesmo o usuário root — vai conseguir excluir os objetos até o fim do período de retenção. Nem mesmo o suporte da AWS pode te ajudar a excluir antes do prazo.
Você verá o seguinte erro:
"Access Denied because object protected by object lock."
Então, por que você iria querer bloquear esse recurso?
Para reduzir o estrago caso uma conta AWS seja comprometida.
Vou explicar — existem três padrões comuns que os atacantes seguem ao conseguir acesso a uma conta AWS:
- Resgate e destruição: criptografar backups, exigir resgate e excluir recursos para causar caos.
- Mineração de criptomoedas: subir instâncias caras de GPU em todas as regiões disponíveis para minerar cripto.
- Sangria financeira: provisionar recursos caros, como metal instances e volumes EBS gigantescos, ou comprar Redshift Reserved nodes para inflar a fatura.
Um truque especialmente cruel que um atacante pode usar é criar um bucket S3 com Object Lock de longo prazo em Compliance mode e fazer upload de arquivos enormes usando instâncias EC2 zumbis, ou até mesmo conteúdo cuja posse seja ilegal.
Mais tarde, em uma revisão de custos ou na detecção de anomalias, você pode se deparar com um bucket cheio de volumes massivos de dados que não dá para apagar, custando milhares a dezenas de milhares de dólares por mês, sem nenhuma forma de removê-los.
E como excluir um bucket com objetos protegidos pelo Compliance mode?
Não dá.
A única saída é encerrar a conta AWS inteira com todos os seus recursos, o que é uma enorme dor de cabeça, principalmente em ambientes de produção.
Você vai precisar migrar todos os seus workloads para uma nova conta AWS — um processo que pode levar semanas ou até meses, parecido com uma migração completa de ambiente.
Como bloquear?
Com as Resource Control Policies (RCP) — um recurso do AWS Organizations que permite aplicar políticas em todas as contas da sua organização (exceto a conta de gerenciamento) para recursos como S3 Buckets.
Você pode criar uma resource policy que nega qualquer tentativa de habilitar o Object Lock (infelizmente, não é possível restringir apenas ao Compliance Mode). Se alguém tentar aplicar, vai receber um erro de Access Denied.
Dica de especialista: você também pode liberar apenas usuários específicos (por exemplo, o time de segurança) para contornar a restrição, bloqueando todos os outros. Assim, você mantém o controle sem expor a conta a riscos desnecessários.
Veja um exemplo de RCP que bloqueia totalmente o uso do Compliance mode, tanto para buckets existentes quanto para os novos:
Apliquei a policy, criei um novo bucket e, ao tentar habilitar o Compliance mode, recebi o seguinte erro:
Considerações finais:
Se você leva a sério minimizar danos financeiros de longo prazo causados por configurações incorretas ou acessos não autorizados, recomendo muito aplicar essa política.
A propósito, o Compliance mode não é exclusividade do S3 — ele também existe em:
- EBS Snapshots — backups de volumes (discos) do EC2
- AWS Backup Vault — serviço AWS Backup
Vale considerar bloqueá-los também, dependendo da sua postura de risco.
Conheça mais recursos úteis em doit.com/services — seu próximo passo rumo ao sucesso já está te esperando!