Backup e Recuperação contra Ransomware: imutabilidade, WORM e retenção protegida

Imutabilidade: o que é e por que muda o jogo contra ransomware

Imutabilidade é a propriedade de um backup (ou de seus metadados) ficar bloqueado contra alteração e exclusão por um período definido. Na prática, mesmo que um invasor obtenha credenciais administrativas, ele não consegue apagar, sobrescrever ou “encurtar” a vida útil daquele backup enquanto a janela de proteção estiver ativa.

O objetivo é neutralizar a sabotagem mais comum em ataques de ransomware: antes de criptografar os dados de produção, o atacante tenta destruir os backups (apagando repositórios, reduzindo retenção, eliminando snapshots, alterando políticas). Com imutabilidade, o backup passa a ter um “cadeado temporal”: ele existe e permanece íntegro até a data de expiração.

Imutabilidade não é só “não apagar”

• Bloqueio de exclusão: impede remover o backup antes do prazo.
• Bloqueio de alteração: impede modificar o conteúdo (evita “backup envenenado” por sobrescrita).
• Bloqueio de política: impede reduzir retenção ou desativar proteção sem um processo controlado.

Abordagens práticas: WORM, Object Lock, snapshots protegidos e retenção com bloqueio administrativo

1) Storage com WORM (Write Once, Read Many)

WORM é um modelo em que os dados são gravados e depois ficam somente para leitura até o fim da retenção. É comum em appliances/arrays e em soluções de arquivamento que implementam “modo compliance”.

Quando usar: para repositórios de backup que precisam de proteção forte contra exclusão/alteração, especialmente em ambientes com exigência regulatória.

Pontos de atenção: WORM costuma exigir planejamento de capacidade e políticas de retenção bem definidas, porque “erros” de retenção podem prender dados por tempo demais.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Passo a passo (genérico) para ativar WORM em um repositório

• 1. Defina o escopo: quais conjuntos de backup precisam ser WORM (ex.: backups diários e semanais do ERP, diretórios críticos, bases de dados).
• 2. Defina a retenção mínima por tipo de backup (ex.: diários 14 dias, semanais 8 semanas, mensais 12 meses).
• 3. Habilite WORM no nível correto: volume, share, bucket ou namespace (depende do storage).
• 4. Configure o software de backup para gravar nesse destino e não tentar “reutilizar” arquivos (evite modos que reescrevem blocos antigos).
• 5. Teste sabotagem controlada: com uma conta administrativa, tente apagar um backup dentro da retenção e valide que a operação falha e é registrada em log.
• 6. Documente exceções: como proceder quando houver necessidade legítima de retenção diferente (ex.: investigação, auditoria).

2) Object Lock (imutabilidade em armazenamento de objetos)

Em armazenamento de objetos, a imutabilidade costuma ser implementada por Object Lock, que aplica retenção e/ou “legal hold” a objetos. O mecanismo impede exclusão e sobrescrita até o prazo expirar.

Conceitos úteis:

• Retenção (Retention): define uma data até a qual o objeto não pode ser removido/alterado.
• Legal hold: bloqueio sem data de expiração (exige governança rigorosa para não virar “retenção eterna”).
• Versionamento: essencial para proteger contra sobrescrita; versões antigas permanecem recuperáveis.

Passo a passo para desenhar um bucket com Object Lock

• 1. Crie um bucket dedicado para backups imutáveis (evite misturar com dados de aplicação).
• 2. Habilite versionamento no bucket.
• 3. Habilite Object Lock (idealmente no momento da criação do bucket, conforme a tecnologia).
• 4. Defina retenção padrão por política (ex.: 30 dias) e ajuste por classe de backup via tags/metadados quando necessário.
• 5. Configure o software de backup para gravar objetos novos (append-only) e manter metadados de retenção.
• 6. Valide o comportamento: tente apagar um objeto dentro da retenção; confirme bloqueio e geração de eventos/logs.
• 7. Planeje o ciclo de expiração: após o prazo, a exclusão deve ser possível (automática ou por job controlado).

3) Snapshots protegidos (imutáveis ou com deleção restrita)

Snapshots são pontos no tempo do armazenamento. Para ransomware, o risco é o atacante apagar snapshots ou reduzir a política de retenção. A proteção vem de dois elementos: retenção mínima e restrição de deleção (por exemplo, exigir credenciais separadas, MFA, ou modo “locked snapshot”).

Quando usar: para recuperação rápida (RTO baixo) e para reduzir impacto de criptografia em volumes/VMs, desde que a deleção seja realmente controlada.

Passo a passo para snapshots “resistentes a sabotagem”

• 1. Separe políticas por criticidade: volumes críticos com snapshots mais frequentes e retenção maior.
• 2. Habilite snapshots com retenção mínima: defina que snapshots não podem ser removidos antes de X dias.
• 3. Restrinja deleção: use função/role específica para apagar snapshots, diferente da role de operação diária.
• 4. Proteja a conta de deleção: MFA obrigatório, acesso via bastion/jump host, e uso apenas sob mudança aprovada.
• 5. Monitore eventos: alertas para tentativas de deleção em massa, redução de retenção e falhas de autenticação.
• 6. Teste restauração: recupere um volume/VM a partir de snapshot e meça o tempo real.

4) Políticas de retenção com bloqueio administrativo (governança aplicada)

Mesmo sem WORM “hard”, muitas plataformas permitem bloquear administrativamente a redução de retenção e a exclusão de pontos de recuperação sem um fluxo de autorização. Isso não substitui imutabilidade forte, mas é uma camada útil para reduzir risco operacional e abuso de privilégio.

Exemplos de controles:

• Retenção mínima configurada por política central (não por job individual).
• Change management: alterações de retenção exigem ticket e aprovação.
• MFA e acesso condicional para ações destrutivas.
• Separação de funções: quem opera backup não é quem altera retenção.

Desenhando retenções em camadas (curta, média e longa) alinhadas ao risco de descoberta tardia

Ransomware nem sempre é detectado no dia do ataque. Em muitos incidentes, há permanência no ambiente (acesso indevido) por dias ou semanas antes da criptografia, ou há criptografia parcial que passa despercebida. Por isso, retenção deve considerar tempo de descoberta e tempo de permanência do atacante.

Modelo prático de camadas

Como escolher números sem “chute”

• Baseie a camada curta no tempo típico de correção e na frequência de mudanças (quanto mais mudança, mais pontos).
• Baseie a camada média no tempo máximo esperado de detecção do ataque (ex.: se seu SOC detecta em até 21 dias, retenção média deve exceder isso com folga).
• Baseie a camada longa em requisitos legais/contratuais e no pior cenário de permanência (ex.: 3–6 meses) somado ao tempo de investigação.

Exemplo de política em camadas (para um sistema crítico)

• Diários: 30 dias (imutável).
• Semanais: 12 semanas (imutável, em destino separado).
• Mensais: 24 meses (WORM/Compliance).

O ponto-chave é que as camadas devem ser independentes o suficiente para que uma sabotagem em uma delas não elimine todas as opções de recuperação.

Governança: quem pode reduzir retenção, como auditar mudanças e como evitar dependência de um único administrador

Princípio 1: reduzir retenção é uma ação destrutiva

Trate redução de retenção como equivalente a “apagar backups no futuro”. Portanto, aplique controles similares aos de mudanças críticas em produção.

Modelo de papéis (RBAC) recomendado

• Operador de Backup: executa e monitora jobs, restaura dados, mas não altera retenção global nem desativa imutabilidade.
• Administrador de Plataforma: mantém infraestrutura (storage/rede), mas não tem permissão para apagar pontos imutáveis.
• Gestor de Retenção (Data Owner/Compliance): aprova mudanças de retenção e exceções (ex.: legal hold).
• Auditor/Segurança: acesso somente leitura a logs e configurações; recebe alertas de mudanças.

Princípio 2: mudanças sensíveis exigem dupla aprovação (two-person rule)

Implemente um processo em que ações como reduzir retenção, desabilitar Object Lock/WORM, apagar repositórios ou alterar chaves/credenciais do destino exijam duas pessoas (ex.: operador + gestor de retenção) e, quando possível, aprovação fora da própria ferramenta (workflow corporativo).

Passo a passo para controlar redução de retenção

• 1. Defina retenções mínimas por classe de dado (crítico, importante, padrão) e publique como política interna.
• 2. Bloqueie tecnicamente a redução abaixo do mínimo (quando a plataforma permitir).
• 3. Exija ticket com justificativa, impacto e data de reversão (se aplicável).
• 4. Exija aprovação dupla (dono do dado + segurança/compliance).
• 5. Execute a mudança com conta privilegiada separada (não a conta do dia a dia).
• 6. Registre evidências: antes/depois da configuração, ID do ticket, aprovadores, horário.
• 7. Revise periodicamente alterações feitas no período (ex.: semanal/mensal).

Auditoria: o que registrar e como detectar sabotagem

Para que a imutabilidade seja confiável, você precisa provar que ela estava ativa e que não foi contornada.

• Logs de configuração: alterações de retenção, políticas, criação/remoção de repositórios, mudanças de permissões.
• Eventos de deleção: tentativas (bem-sucedidas e falhas), deleções em massa, expiração automática.
• Autenticação: logins privilegiados, falhas, uso de MFA, origem (IP/host) e horário.
• Alertas: gatilhos para “retenção reduzida”, “Object Lock desativado”, “snapshot policy alterada”, “picos de deleção”.

Boa prática: envie logs para um destino de auditoria com retenção própria e acesso somente leitura para administradores do backup (evita apagar rastros).

Evitar dependência de um único administrador (anti-single-admin)

• Contas nominativas: proíba conta compartilhada para administração; cada ação deve ter autor identificável.
• Credenciais separadas: uma conta para operação diária e outra para ações destrutivas, com uso raro e controlado.
• Cofre de credenciais: credenciais privilegiadas guardadas e liberadas sob aprovação e tempo limitado.
• Break-glass controlado: conta de emergência com MFA forte, monitoramento e revisão obrigatória após uso.
• Rotação e revisão de acessos: recertificação periódica de quem pode alterar retenção/imutabilidade.

Checklist de implementação (para aplicar sem ambiguidade)

• Backups críticos gravados em destino com imutabilidade real (WORM/Object Lock ou equivalente).
• Retenção desenhada em camadas (curta, média, longa) com prazos alinhados ao tempo de descoberta.
• Redução de retenção tratada como mudança destrutiva com dupla aprovação.
• Separação de funções: operar backup ≠ alterar retenção ≠ administrar storage.
• Logs e alertas para alterações de política, deleções e tentativas de contorno.
• Processo para exceções (ex.: legal hold) com dono e prazo, evitando retenção infinita acidental.