Ransomware moderno não se contenta em cifrar os dados de produção. O operador procura o backup primeiro — porque backup íntegro é o que torna o resgate desnecessário. Se ele apagar suas cópias antes de cifrar, a negociação começa com você sem alternativa.

É contra isso que serve a imutabilidade. E é por isso que como ela é configurada importa mais que o fato de estar ligada.

O que Object Lock realmente faz

O Object Lock do S3 impede que uma versão de objeto seja apagada ou sobrescrita até uma data determinada. Ele exige versionamento habilitado e é definido na criação do bucket — não dá para ligar depois num bucket que já existe.

Há dois modos, e a diferença entre eles é a coisa mais importante deste texto:

Modo governance. O objeto é protegido, mas quem tiver a permissão específica de ignorar a retenção pode remover a proteção. Serve contra engano, automação defeituosa e credencial de baixo privilégio comprometida.

Modo compliance. Ninguém remove a proteção antes do prazo. Nem o administrador. Nem a conta raiz. Nem a AWS a pedido do titular. Serve contra um atacante que já obteve controle administrativo da conta.

A escolha é real e tem duas faces. O modo compliance protege de verdade contra o cenário mais grave — e também significa que um erro seu é definitivo. Gravou 500 TB com dez anos de retenção por engano? Você vai pagar por dez anos. Não há botão de desfazer, e é exatamente isso que o torna eficaz.

Onde a proteção costuma vazar

Ligar o Object Lock e considerar o assunto encerrado é o erro mais comum. A proteção depende de coisas ao redor:

A retenção precisa cobrir o tempo de detecção. Comprometimentos ficam semanas sem serem notados. Retenção de sete dias não protege contra um invasor que está na sua rede há um mês — quando você percebe, o prazo já passou e as versões protegidas já podem ser apagadas.

Ciclo de vida pode apagar o que a retenção protegeria. Uma política de expiração configurada de forma independente convive mal com a retenção. O resultado costuma ser descoberto tarde: dados que deveriam existir, mas não existem.

Quem grava não deveria poder apagar. Se a mesma credencial que envia o backup tem permissão de exclusão, o comprometimento dessa credencial derruba as duas pontas. Escrita e exclusão devem ser identidades diferentes.

Governance sem restringir a permissão de bypass é teatro. O modo governance só significa alguma coisa se a permissão de ignorar a retenção for genuinamente restrita. Se todo mundo do time de infraestrutura a tem, você tem um aviso, não uma proteção.

Imutável não quer dizer recuperável

Este é o ponto que mais custa caro. Imutabilidade garante que o dado não foi alterado. Não garante que ele seja útil.

Um backup pode estar perfeitamente protegido contra exclusão e, ainda assim, ser inútil porque:

a chave de criptografia se perdeu — e sem ela, o dado imutável é ruído protegido;
o índice que diz onde cada arquivo está nunca foi testado;
ninguém sabe executar a recuperação sem a pessoa que está de férias;
a recuperação leva mais tempo do que o negócio aguenta parado.

A pergunta certa não é "os dados estão imutáveis?". É "quanto tempo levo para ter este arquivo de volta, e eu já cronometrei isso?".

A chave de criptografia é o ponto único de falha

Se o backup é cifrado — e deveria ser — a chave passa a ser tão crítica quanto o dado. Perdê-la produz o mesmo resultado prático que perder o backup, com o agravante de você continuar pagando o armazenamento.

Duas regras que resolvem a maior parte dos casos:

A chave não vive só na máquina que faz o backup. Se ela morre com o servidor, o backup morre junto.
A cópia da chave é testada. Guardar num cofre e nunca conferir se a cópia funciona é a mesma categoria de erro que nunca testar a recuperação.

Checklist honesto

Object Lock habilitado, com versionamento — e o modo escolhido conscientemente, sabendo que compliance não tem volta.
Retenção maior que o seu tempo realista de detecção, não que o seu tempo desejado.
Identidade de escrita sem permissão de exclusão.
Permissão de bypass de retenção restrita a poucas pessoas, com registro de uso.
Política de ciclo de vida revisada junto com a retenção, não em separado.
Chave de criptografia guardada fora do servidor de backup e com cópia testada.
Recuperação exercitada de ponta a ponta, cronometrada, com a identidade real.
Registro de auditoria de quem pediu o quê — inclusive das recuperações.

Nenhum desses itens é caro. O que é caro é descobrir a ausência de um deles no dia em que o backup é a única coisa entre você e o pagamento de um resgate.

O NubliVault grava com Object Lock ativado, separa as identidades de escrita e exclusão, registra toda ação em trilha de auditoria e roda na infraestrutura do próprio cliente, com as chaves dele. Veja a página de segurança.