Ransomware maduro não começa pela criptografia. Antes de executar a carga final, os operadores entram no ambiente com credenciais de administrador, mapeiam os repositórios de backup e os destroem em primeiro lugar — em incidentes documentados, cópias foram apagadas tanto no data center primário quanto no de recuperação, antes e depois da criptografia da rede. Quando a última cópia válida morre junto com a produção, a organização perde a única alavanca real que tinha: restaurar sem pagar. A resposta de engenharia é a imutabilidade — backups gravados uma única vez, impossíveis de alterar ou apagar durante uma janela de retenção fixa, mesmo para quem tem privilégios máximos no ambiente. Para equipes defensivas, a decisão prática imediata é ativar retenção WORM no armazenamento de backup em nuvem e provar, em teste periódico, que a restauração funciona de ponta a ponta.
Essa não é uma preferência arquitetural discutível. O guia #StopRansomware, mantido pela CISA em conjunto com FBI, NSA e MS-ISAC, trata a resiliência do backup como controle central de preparação contra extorsão, e a documentação técnica do Object Lock oferece o mecanismo concreto para implementar essa resiliência em armazenamento de objetos. Unir as duas pontas — o que a autoridade recomenda e como traduzir isso em um desenho que resista a um invasor com credenciais de administrador — é o que separa um backup de papel de um backup que sobrevive ao pior dia da empresa.
O backup é o alvo
A lógica do ataque é econômica. O guia da CISA registra que a maioria dos atores de ransomware tenta localizar, apagar ou criptografar backups acessíveis para tornar a restauração impossível sem pagamento do resgate, e que esses grupos caçam credenciais guardadas no próprio ambiente comprometido para alcançar as consoles de backup, além de explorar falhas conhecidas em produtos de proteção que ficaram sem correção. Por isso a recomendação expressa da agência é manter backups offline e criptografados de dados críticos, testando com regularidade a disponibilidade e a integridade das cópias em um cenário de recuperação de desastres. A extorsão dupla — criptografia e ameaça de vazamento no mesmo golpe — só atinge o efeito máximo quando a vítima não consegue restaurar por conta própria, o que transforma a cópia íntegra no ativo mais valioso da resposta.
Na nuvem, o guia desce do princígio ao recurso específico: recomenda ativar proteção contra exclusão ou object lock nos recursos de armazenamento frequentemente visados por ransomware — armazenamento de objetos, banco de dados, arquivos e blocos —, considerar versionamento para manter múltiplas variantes recuperáveis de cada objeto, fazer cópias com frequência, inclusive cloud-to-cloud, e habilitar registro e alertas de uso anômalo em todos os recursos. É a combinação dessas camadas, e não o bloqueio isolado, que sustenta a recuperação.
Como o Object Lock funciona
O Object Lock implementa o modelo WORM (write once, read many) sobre versionamento de objetos: cada versão carrega metadados próprios de retenção, e o bucket precisa ter versionamento e bloqueio habilitados desde a criação — depois de ativado, o Object Lock não pode ser desativado nem o versionamento suspenso. Há dois modos de retenção. No modo governance, usuários comuns não conseguem apagar ou alterar a versão, mas quem detém a permissão específica de bypass contorna a proteção com um cabeçalho explícito na requisição — útil para ensaiar políticas sem risco. No modo compliance, a versão protegida não pode ser sobrescrita nem apagada por nenhum usuário, inclusive o usuário root da própria conta. O modo não pode ser alterado, o prazo não pode ser encurtado e a única saída antes do vencimento é apagar a conta AWS inteira. O teto de retenção chega a 100 anos. Além do prazo, existe o legal hold, uma trava sem data de expiração que permanece até remoção explícita por alguém autorizado — adequada para preservar evidências durante uma investigação.
Arquitetura imutável de ponta a ponta
Imutabilidade de gravação, sozinha, não basta: o invasor ataca em volta dela, pelas credenciais, pelas chaves de criptografia e pela topologia de contas. O desenho abaixo fecha essas bordas.
| Componente | Decisão de projeto | Motivo |
|---|---|---|
| Bucket de backup | Habilitar versionamento e Object Lock na criação | O bloqueio não pode ser ativado depois em bucket novo sem previsão, e nunca pode ser revertido |
| Modo de retenção | Compliance para cópias finais; governance só para ensaio | Compliance não admite encurtamento nem bypass, nem pelo root |
| Janela de retenção | Prazo mínimo igual ao pior tempo aceito de recuperação, com folga | Janela curta demais devolve ao invasor o poder de apagar depois da expiração |
| Conta de destino | Conta AWS segregada da produção, sem credenciais compartilhadas | Isola o conjunto de permissões que o invasor compromete primeiro |
| Criptografia | Chaves KMS dedicadas, com política restritiva e proteção contra exclusão | O bloqueio de objeto não protege contra a perda ou o apagamento das chaves |
| Replicação | Entre contas e regiões, com retenção aplicada também no destino | Cópia única na mesma conta é ponto único de falha |
| Auditoria | CloudTrail e logs de acesso ao bucket de backup | Tentativas de apagar versões travadas geram negativas registradas e acionáveis |
Erros que anulam a imutabilidade
O primeiro erro clássico é criptográfico. A documentação da AWS é explícita: o Object Lock impede o apagamento do objeto, mas não protege contra a perda das chaves de criptografia — se a chave KMS usada pelos backups for apagada, os objetos travados ficam ilegíveis. Proteção de chave, com política restritiva, pré-requisito administrativo para exclusão e alerta sobre qualquer agendamento de remoção, é parte do desenho, não um acessório.
O segundo erro é de permissão. Distribuir a permissão de bypass do modo governance por comodidade operacional recria, na prática, um backup apagável. Essa permissão deve existir apenas em função de emergência com registro. O terceiro é de configuração: bucket sem retenção padrão aceita uploads sem trava alguma, e cópias antigadas migradas sem versão protegida permanecem expostas — a retenção precisa ser verificada por objeto, não presumida. O quarto é de percepção: marcadores de exclusão escondem o objeto sem apagar a versão, o que confunde operação e monitoração se ninguém explica o comportamento à equipe. Por fim, a ausência de testes: a restauração só é comprovada quando ensaiada em cenário realista, com cronômetro e validação de integridade, como detalhamos no guia sobre o teste real após um incidente.
Prioridades de implantação
P1, para as próximas semanas: habilitar Object Lock em modo compliance em bucket dedicado de backup, dentro de conta segregada; definir retenção padrão no bucket para que todo upload novo já nasça travado; proteger as chaves KMS do backup contra exclusão; e criar alertas para rajadas de exclusão negadas contra o bucket. P2, para o trimestre: replicar as cópias travadas entre contas e regiões; inventariar objetos com relatórios de inventário do S3 para confirmar cobertura de retenção; executar teste trimestral de restauração com métrica de tempo; e restringir qualquer permissão de bypass a processo de vidro quebrado com aprovação registrada.
Sinais a monitorar
Cinco padrões merecem alerta imediato: rajadas de respostas de acesso negado em tentativas de apagar objetos ou versões contra o bucket de backup; qualquer uso do cabeçalho de bypass de governance; chamadas que alterem a configuração de bloqueio do bucket; enumeração em massa do estado de retenção dos objetos, sinal de reconhecimento preparatório; e agendamento de exclusão de chave KMS usada pelo backup. Cada um desses eventos, isolado, pode ser ruído; em sequência, costuma anteceder a destruição planejada das cópias.