A falácia da imutabilidade: por que backups travados ainda são deletados por ransomware

A indústria de armazenamento vendeu a você um sonho confortável: a "Imutabilidade". A promessa de que, ao marcar uma caixa de seleção na interface do seu storage ou software de backup, seus dados se tornam intocáveis, gravados em pedra digital, imunes a qualquer criptografia maliciosa.

Isso é mentira. Ou, na melhor das hipóteses, uma meia-verdade perigosa.

A imutabilidade de software (Object Lock, WORM) é excelente contra um ransomware automatizado que varre a rede criptografando arquivos SMB. Mas contra um invasor humano, persistente e com credenciais privilegiadas, essa "pedra" vira pó. Se o atacante possui as chaves do reino (root, admin do storage ou acesso físico via IPMI), a imutabilidade do dado não importa. Ele não precisa deletar o arquivo; ele deleta o volume, o pool ou reseta a controladora RAID para os padrões de fábrica.

Vamos dissecar por que seus backups "travados" ainda estão sumindo e como a arquitetura de armazenamento — e não apenas o software — precisa mudar.

Resumo em 30 segundos

• Acesso Administrativo > Imutabilidade: Se o atacante comprometer a interface de gerenciamento do storage (Data Domain, Synology, TrueNAS), ele pode destruir o volume inteiro, ignorando travas de arquivos individuais.
• O Vetor do Tempo (NTP): Travas de retenção dependem do relógio do sistema. Alterar a data do servidor para o futuro faz com que os backups expirem e se tornem deletáveis instantaneamente.
• O Pecado do Active Directory: Integrar servidores de backup e storage ao domínio principal é entregar os dados de bandeja. Se o AD cai, o backup cai junto.

O ataque ao plano de gerenciamento supera o bloqueio de software

A maioria das implementações de imutabilidade (como o S3 Object Lock ou o Hardened Repository do Veeam) funciona na camada de aplicação ou sistema de arquivos. O software diz ao disco: "Não permita a exclusão deste bloco até a data X".

O problema é a hierarquia de controle. Abaixo do sistema de arquivos, existe o Plano de Gerenciamento do hardware.

Imagine que você tem um NAS Synology ou um storage enterprise Dell/HPE. Você configurou snapshots imutáveis. Ótimo. Mas o que acontece se eu conseguir acesso à interface web de gerenciamento ou ao SSH dessa caixa?

Eu não vou tentar deletar o arquivo backup_full.vbk. O sistema operacional vai me impedir. Em vez disso, eu vou ao gerenciador de volumes e ordeno a destruição do LUN ou do Storage Pool inteiro. Ou pior, inicio uma "inicialização rápida" nos discos físicos. A imutabilidade do arquivo é irrelevante se o contêiner onde ele vive deixa de existir.

⚠️ Perigo: Muitos administradores protegem o servidor de backup (Windows/Linux) mas deixam a interface de gerenciamento do storage (iDRAC, ILO, IPMI ou Web UI do NAS) com senhas padrão ou sem MFA. Esse é o caminho de menor resistência para o ransomware moderno.

Figura: A anatomia do desastre: atacando a infraestrutura subjacente para contornar travas de software.

Se o seu storage array permite que um administrador logado destrua dados imutáveis sem uma segunda autenticação física ou um atraso de tempo forçado (time-delay), você não tem imutabilidade. Você tem apenas uma lixeira glorificada.

A manipulação do NTP e o vetor de ataque "Time Travel"

A imutabilidade é, fundamentalmente, matemática baseada no tempo. A regra é simples: Se Data_Atual < Data_Retenção, então BLOQUEAR_DELEÇÃO.

O calcanhar de Aquiles aqui é a variável Data_Atual. De onde o seu storage ou servidor de backup tira essa informação? Do relógio do sistema, que geralmente é sincronizado via NTP (Network Time Protocol).

Grupos de ransomware sofisticados já utilizam a técnica de "Time Travel". O processo é assustadoramente simples:

1. O atacante ganha acesso root/admin ao servidor de backup ou storage.

2. Ele desabilita a sincronização automática de NTP.

3. Ele altera a data do sistema manualmente para o ano 2099.

4. O sistema de imutabilidade verifica a condição: 2099 > 2026 (Data_Retenção).

5. A trava expira. O sistema entende que o período de retenção acabou.

6. O atacante deleta os dados.

💡 Dica Pro: Configure seus hosts de virtualização e storage para usar fontes de NTP internas e seguras, e monitore desvios de tempo. Um salto de tempo de anos em um servidor de produção deve disparar todos os alarmes do seu SIEM imediatamente. Alguns sistemas modernos (como repositórios Linux endurecidos bem configurados) impedem alterações drásticas de tempo sem autenticação adicional, mas a maioria dos NAS de mercado "prosumer" não possui essa defesa.

O erro fatal de integrar o servidor de backup ao Active Directory

Se eu tivesse que escolher apenas uma falha para corrigir em 90% das empresas, seria esta: Tire o seu backup do Domínio.

A conveniência é a mãe da insegurança. É muito prático logar no servidor de backup com sua conta de Admin do Domínio. Mas isso cria uma dependência circular suicida.

No cenário clássico de ransomware, o primeiro alvo é o Active Directory. Uma vez que o atacante compromete um Domain Admin, ele tem acesso a qualquer servidor membro do domínio. Se o seu servidor de backup (que controla o storage) está no domínio, o atacante usa as credenciais roubadas para logar via RDP, abrir o console de gerenciamento e apagar tudo.

A Regra de Ouro da Segmentação de Storage: A infraestrutura de backup (Servidor de Backup + Repositório de Storage) deve viver em um Workgroup isolado ou em uma floresta de gerenciamento separada, sem relação de confiança com o domínio de produção.

As credenciais para acessar esse ambiente devem ser locais, únicas e nunca digitadas em uma estação de trabalho que tenha acesso à internet ou e-mail.

Arquitetura de repositórios Linux endurecidos e isolamento físico

Se o Windows é um alvo fácil e os appliances de storage proprietários têm backdoors de gerenciamento, qual é a solução prática? A resposta da indústria tem convergido para o Linux Hardened Repository.

Não estamos falando apenas de instalar um Ubuntu e colocar arquivos lá. Estamos falando de uma arquitetura de armazenamento desenhada para ser hostil:

1. Sistema de Arquivos XFS com Reflink: Essencial para performance de clonagem de blocos (Fast Clone), economizando espaço e IOPS em discos rotacionais (HDD) e SSDs.

2. Credenciais de Uso Único: O software de backup conecta-se ao Linux uma única vez para implantar os serviços de transporte de dados. Depois disso, as credenciais SSH são removidas ou desabilitadas. Não há chave SSH persistente nem senha salva no software de orquestração.

3. Imutabilidade via Chattr: O uso do atributo +i (immutable) no nível do sistema de arquivos Linux impede que até mesmo o usuário root delete os arquivos sem antes remover o atributo.

4. SSH Desabilitado: Após a configuração, o serviço SSH é parado e desabilitado. O único jeito de acessar o console é fisicamente (ou via KVM/iDRAC, que deve estar em uma rede de gerenciamento isolada).

Figura: O conceito de Hardened Repository: reduzindo a superfície de ataque ao mínimo absoluto.

Isso resolve o problema do "Time Travel"? Parcialmente. Se o atacante tiver acesso físico ou ao console virtual (iDRAC), ele ainda pode tentar reiniciar a máquina em modo single-user e alterar o tempo. É aqui que entra a defesa em profundidade.

Protocolos de "Break-Glass" e a última linha de defesa em fita

Se tudo o que é digital pode ser hackeado, a segurança definitiva é analógica ou fisicamente desconectada.

Não revire os olhos para a fita LTO. A fita é a única tecnologia de armazenamento que possui um "Air Gap" verdadeiro por design. Uma fita LTO-9 em uma prateleira não pode ser deletada por um script russo. Ela não tem endereço IP. Ela não consome energia (o que é ótimo para o TCO a longo prazo).

Além disso, cartuchos LTO possuem uma trava física de proteção contra gravação (Write-Protect switch). Uma vez movida essa trava, o drive de fita fisicamente não consegue sobrescrever os dados. É uma barreira de hardware, não de software.

Se fita não é viável para o seu Home Lab ou PME, considere o protocolo "Break-Glass" para discos USB ou NAS desconectados:

1. Rotação de Mídia: Tenha discos externos que são conectados apenas durante a janela de backup e removidos fisicamente depois.

2. Contas Break-Glass: A senha de root/admin do seu repositório imutável deve ser complexa (25+ caracteres), gerada aleatoriamente e não salva em nenhum gerenciador de senhas digital. Escreva-a em papel, coloque em um envelope lacrado e tranque em um cofre físico.

3. MFA no Console: Se o seu storage suporta, exija MFA até para o login no console local ou console serial.

O ultimato da física

A imutabilidade não é um produto que você compra; é um estado que você mantém com vigilância paranoica. A falácia reside em acreditar que o software pode corrigir falhas de arquitetura. Não pode.

Enquanto o seu plano de gerenciamento de storage estiver na mesma rede que seus usuários, e enquanto suas credenciais de backup estiverem acessíveis via Active Directory, seus dados estão em risco. O ransomware evoluiu. Eles não atacam mais apenas os dados; eles atacam a infraestrutura que sustenta os dados.

Seu próximo passo não é renovar a licença do software de backup. É auditar quem tem acesso à porta 443 do seu storage, isolar suas VLANs de gerenciamento e, talvez, comprar um cofre físico para guardar a única senha que pode salvar sua empresa.

Referências & Leitura Complementar

• NIST SP 800-209: Security Guidelines for Storage Infrastructure. Um guia essencial para entender como proteger a camada de blocos e arquivos.

• SNIA (Storage Networking Industry Association): "Protecting Data from Ransomware and Other Malware". Documentos técnicos sobre isolamento de SAN/NAS.

• Veeam Hardened Repository Best Practices: Documentação técnica sobre implementação de repositórios Linux com imutabilidade (XFS + chattr).

• RFC 5905 (NTPv4): Para entender as vulnerabilidades do protocolo de tempo e como o "Time Travel" é tecnicamente viável.