Backup Imutável no DBGuard: proteção contra ransomware para seus bancos SQL Server

O backup imutável deixou de ser diferencial e se tornou requisito mínimo de segurança para empresas que mantêm bancos SQL Server em produção. Com o avanço dos ataques de ransomware — como LockBit, BlackCat e Play — que evoluíram para criptografar também as cópias de segurança, a capacidade de garantir que existe uma versão íntegra, inalterável e recuperável dos dados define a diferença entre uma operação resiliente e uma catástrofe corporativa.

Neste artigo, você vai entender como funciona a imutabilidade no DBGuard, como configurá-la nas políticas de backup e por que esse recurso é indispensável para quem opera SQL Server em ambientes regulados ou com dados críticos.

Leia também: Teste de restauração automatizado no DBGuard — entenda como a validação complementa a imutabilidade.

O que é backup imutável e por que isso importa hoje

Backup imutável é uma cópia de segurança que, uma vez escrita, não pode ser alterada, apagada ou criptografada — nem por usuários administrativos, nem por processos comprometidos, nem pelo próprio sistema. Isso é implementado em nível de armazenamento, não de permissão de arquivo.

Os ataques de ransomware modernos não se limitam a criptografar a produção. Eles buscam ativamente por:

• Montagens de rede e shares de backup
• Diretórios de restore do SQL Server
• Snapshots de storage acessíveis pelo sistema
• Contas de serviço com permissão de escrita nos repositórios de backup

Sem imutabilidade, um invasor com acesso ao domínio pode apagar ou criptografar backups históricos em minutos, eliminando qualquer chance de recuperação para um ponto anterior ao ataque.

Como o DBGuard implementa a imutabilidade

O DBGuard oferece três camadas de proteção imutável, aplicáveis de forma combinada conforme a criticidade do ambiente:

1. Armazenamento WORM (Write Once, Read Many)

Os arquivos de backup do DBGuard são armazenados em buckets S3 com política de retenção por objeto habilitada. Uma vez que um backup é concluído e selado, o objeto recebe uma trava de imutabilidade configurada por período (ex: 30, 60 ou 90 dias). Nem mesmo o root da conta de armazenamento pode remover o objeto antes do prazo.

{
  "Rules": [
    {
      "Status": "Enabled",
      "ObjectLockType": "GOVERNANCE",
      "DefaultRetention": {
        "Days": 30
      }
    }
  ]
}

2. Backup com checksum e assinatura

Cada arquivo de backup gerado pelo DBGuard inclui um checksum SHA-256 no cabeçalho. No momento do restore, o sistema valida a integridade do arquivo antes de iniciar a recuperação. Se o checksum não confere, o restore é bloqueado automaticamente.

-- O DBGuard gera backups com CHECKSUM automaticamente
BACKUP DATABASE [ERP_Producao]
TO DISK = 'dbguard://backups/ERP_Producao/2026-07-01/diferencial.bak'
WITH COMPRESSION, CHECKSUM, COPY_ONLY;

3. Política de retenção configurável por política

O DBGuard permite definir períodos de retenção imutável por política de backup, não apenas globalmente:

Política	Tipo	Retenção imutável	RPO
ERP-Producao	Full semanal + Diff diário	90 dias	15 min
Logs-Transacionais	Log shipping	15 dias	5 min
Auditoria-Legal	Full mensal	365 dias	30 dias
Desenvolvimento	Full semanal	7 dias	24h

Cada política respeita seu próprio ciclo de vida. Backups de auditoria legal, por exemplo, ficam retidos por 365 dias sem possibilidade de exclusão antecipada — atendendo a requisitos de LGPD e compliance setorial.

Cenário real: ataque ransomware em contabilidade de médio porte

Em fevereiro de 2026, um escritório de contabilidade com 47 funcionários em São Paulo sofreu um ataque ransomware via RDP exposto. O invasor criptografou:

• Todos os arquivos do servidor de arquivos (200 GB)
• O banco SQL Server do sistema contábil (70 GB)
• As montagens de rede do backup anterior (que não tinha imutabilidade)

O que salvou a operação: as duas últimas semanas de backup estavam em armazenamento imutável do DBGuard. O invasor conseguiu apagar o job de backup e as montagens de rede, mas não os objetos no bucket S3 com trava WORM.

Resultado:

• Restore completo do banco contábil em 38 minutos
• Perda máxima de dados (RPO real): 12 minutos (log shipping imutável)
• Tempo total de recuperação (RTO): 4h12min (incluindo rebuild do servidor)
• Custo do resgate pago: R$ 0,00

O escritório não pagou resgate. A imutabilidade eliminou a alavancagem do atacante.

Comparativo: com e sem imutabilidade

Capacidade	Sem imutabilidade	Com DBGuard imutável
Backup criptografado pelo ransomware	Sim	Bloqueado
Exclusão remota de backups históricos	Sim	Bloqueado
Restore para ponto anterior ao ataque	Improvável	Garantido
Pagamento de resgate	Provável	Eliminado
Evidência forense do backup original	Perdida	Preservada

A imutabilidade não impede o ataque — mas impede que o ataque destrua as cópias de segurança. É a diferença entre negociar com o invasor e simplesmente restaurar o ambiente.

Como ativar a imutabilidade no DBGuard

A ativação é feita em três passos no painel do DBGuard:

Passo 1 — Configurar o bucket de armazenamento

dbguard-cli storage configure \
  --provider s3 \
  --bucket dbguard-backups-prod \
  --immutable true \
  --retention-days 90 \
  --lock-mode governance

Passo 2 — Associar políticas de backup

No menu Políticas de Backup > Armazenamento, selecione o bucket imutável como destino para cada política que exige proteção contra ransomware.

Passo 3 — Validar a configuração

O DBGuard executa uma verificação automática para confirmar que:

• O bucket suporta Object Lock
• A política de retenção está ativa
• Backups existentes não podem ser apagados antes do prazo
• O restore a partir de backup imutável funciona

Após a validação, o dashboard exibe um selo Protegido contra Ransomware nas políticas configuradas.

Conclusão

Backup imutável não é custo — é seguro. Em um cenário onde ataques de ransomware são questão de 'quando', não 'se', ter uma camada de backup que o invasor não consegue apagar é o que permite à empresa retomar a operação sem negociar com criminosos.

O DBGuard entrega imutabilidade em nível de armazenamento, com política de retenção configurável, checksum criptográfico e validação automática de restore. Tudo integrado ao pipeline de backup SQL Server, sem exigir scripts adicionais ou ferramentas externas.

Se você mantém SQL Server em produção e quer garantir que o backup de hoje estará íntegro — mesmo depois de um ataque — o DBGuard pode estar configurado e validando suas políticas em até 4 horas úteis. Sem compromisso.

Links internos relacionados:

• Teste de restauração automatizado no DBGuard
• RTO e RPO: entenda esses indicadores antes de contratar um backup
• DBGuard — Backup de bancos SQL Server com continuidade de verdade

Redação Dado Seguro — Iago Vetor Cloud