Backup e Recuperação contra Ransomware: monitoramento, alertas e detecção de sabotagem de backup

O que significa “monitorar backup” em um cenário de ransomware

Monitorar backup não é apenas verificar se um job “terminou com sucesso”. Em um cenário de ransomware, o objetivo é detectar cedo qualquer sinal de que o ambiente de backup está sendo degradado, sabotado ou manipulado para impedir a recuperação. Isso inclui acompanhar: estabilidade (falhas recorrentes), integridade operacional (mudanças inesperadas de política), comportamento dos dados (picos de mudança e exclusões) e segurança (acessos administrativos anômalos).

Na prática, você precisa de três camadas de observabilidade:

• Saúde operacional: jobs, repositórios, agentes, janelas de execução, filas, erros e tempo de execução.
• Saúde do dado protegido: cobertura por sistema, idade do último backup, taxa de mudança, volume transferido, crescimento e exclusões.
• Saúde de segurança: alterações de configuração, mudanças de retenção, criação/remoção de repositórios, tentativas de login, elevação de privilégio e ações administrativas fora do padrão.

Sinais típicos de sabotagem ou ataque refletidos no backup

1) Falhas recorrentes e “sucessos” suspeitos

Falhas repetidas (principalmente em alvos críticos) podem indicar indisponibilidade causada por ataque, alteração de rede, credenciais quebradas ou tentativa de impedir a cópia. Já “sucessos” com volume muito menor que o normal podem indicar exclusões em massa, filtros alterados ou fontes de dados inacessíveis.

• Indicador prático: aumento de jobs com status “warning”, “partial success” ou “success” com bytes processados muito abaixo da média.
• Exemplo: um servidor que normalmente processa 800 GB por noite passa a processar 60 GB por três dias seguidos sem mudança planejada.

2) Aumento de exclusões e redução de escopo

Ransomware e atores humanos frequentemente tentam reduzir a capacidade de recuperação removendo itens do escopo: pastas, VMs, bancos, volumes, políticas ou tags. Isso aparece como queda de cobertura ou aumento de “itens excluídos”.

• Indicador prático: queda repentina no número de objetos protegidos (VMs, endpoints, shares) ou aumento de exclusões por política.
• Exemplo: 30 VMs deixam de estar associadas a uma política de backup após uma alteração administrativa fora da janela de mudança.

3) Mudanças de retenção e políticas “encurtadas”

Um padrão clássico de sabotagem é reduzir retenção para que pontos de restauração antigos expirem rapidamente, eliminando a chance de voltar a um estado limpo. Outra variação é alterar GFS/arquivamento, desativar cópias secundárias ou remover “hold”/bloqueios.

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

• Indicador prático: retenção reduzida (ex.: de 30 para 7 dias), desativação de cópias, alteração de regras de expiração.
• Exemplo: política de banco de dados muda de 35 para 5 pontos, e a expiração é forçada imediatamente.

4) Picos de taxa de mudança (change rate) e compressão anômala

Criptografia em massa aumenta a taxa de mudança: muitos blocos/arquivos se alteram em pouco tempo. Isso pode causar crescimento súbito do volume de backup, aumento de tempo de execução, saturação de rede e consumo acelerado de capacidade. Em alguns casos, a compressão/deduplicação piora (dados criptografados tendem a comprimir/deduplicar menos).

• Indicador prático: aumento abrupto de dados transferidos por job, queda de taxa de deduplicação, aumento de duração e consumo de repositório.
• Exemplo: job que transfere 50 GB/dia passa a transferir 400 GB/dia; dedupe cai de 8:1 para 2:1.

5) Acessos administrativos anômalos e ações de alto impacto

O ataque ao backup costuma envolver credenciais privilegiadas. Sinais: logins fora do horário, de IPs incomuns, tentativas repetidas, criação de novos usuários, alteração de MFA (quando aplicável), desativação de alertas, remoção de repositórios, alteração de chaves, mudança de destinos, limpeza de histórico.

• Indicador prático: eventos administrativos fora do padrão e sequência de ações de alto impacto em curto intervalo.
• Exemplo: em 15 minutos, um usuário admin altera retenção, remove um repositório e desativa notificações.

Como transformar sinais em alertas acionáveis

Princípio: alertar sobre “condições” e não só “eventos”

Um único job falhar pode ser ruído. Já “3 falhas consecutivas em um ativo crítico” é uma condição acionável. O mesmo vale para “queda de cobertura”, “retenção reduzida” e “pico de change rate”. Estruture alertas com: limiar, janela de tempo e impacto.

Passo a passo: desenhar a matriz de alertas (mínimo viável)

1. Liste os ativos críticos (por camada de prioridade já definida no seu plano) e associe cada um a uma política/job.
2. Defina categorias de alerta: Operacional, Capacidade, Cobertura, Segurança, Integridade.
3. Escolha limiares e janelas (exemplos abaixo) e valide com a linha de base das últimas semanas.
4. Defina destinatários por severidade (N1/N2/SecOps/Gestão) e horários (24x7 ou horário comercial).
5. Defina SLA de resposta e escalonamento (quem age, em quanto tempo, e quando subir o nível).
6. Padronize o conteúdo do alerta: o que aconteceu, onde, desde quando, impacto, evidências (IDs de job/evento), ação imediata sugerida.

Exemplos de alertas acionáveis (com limiar)

Quem recebe, SLA e escalonamento (modelo prático)

Alertas só funcionam se houver dono e tempo de resposta. Um modelo simples:

• Crítico (ex.: retenção reduzida, alertas desativados, remoção de repositório): notificar N2 + SecOps imediatamente; SLA de triagem 15 min; escalonar para gestor de plantão em 30 min se não houver confirmação.
• Alta (ex.: falhas recorrentes em crítico, pico de change rate): N1 em 5 min; SLA de triagem 30 min; escalonar para N2 em 60 min se não resolvido.
• Média (ex.: duração anômala, warning isolado): N1 em horário comercial; SLA 4h; consolidar em relatório diário.

Padronize o escalonamento com uma lista curta e objetiva (função, não nome): N1 Backup, N2 Backup, SecOps, Gestor de Infra, Gestor de Segurança.

Relatórios executivos: o que mostrar sem virar “ruído”

Relatório executivo não é log detalhado. Ele deve responder: “Estamos protegidos?”, “O risco está aumentando?” e “O que precisa de decisão?”. Use poucos indicadores, tendência e exceções.

Estrutura recomendada (1 página)

• Status geral: % de sucesso dos backups (últimos 7 dias) e variação vs semana anterior.
• Cobertura: % de ativos críticos com backup dentro do RPO definido (por camada), e lista curta de exceções.
• Idade do último backup válido: top 10 mais atrasados (com dono do sistema).
• Capacidade: consumo atual, crescimento semanal, previsão de esgotamento.
• Riscos e mudanças: alterações relevantes (retenção, políticas, repositórios) com referência de aprovação.
• Testes: número de testes realizados no período e taxa de sucesso (apenas o resultado e pendências).

Verificações de rotina (rotina anti-sabotagem)

1) Auditoria de logs (diária e semanal)

Objetivo: identificar ações administrativas e padrões anômalos antes que virem indisponibilidade.

Checklist diário (10–15 min)

• Eventos críticos: alteração de retenção, remoção/criação de repositório, desativação de jobs, mudança de credenciais, falhas de login admin.
• Jobs críticos: falhas/partial success, volume processado fora do padrão, duração fora do padrão.
• Capacidade: crescimento anormal e alertas de espaço.

Checklist semanal (30–60 min)

• Revisar “top mudanças” administrativas e validar se há ticket/aprovação.
• Revisar tendências: taxa de mudança, dedupe/compressão, crescimento do repositório.
• Revisar exceções persistentes (ativos com falha recorrente ou atrasos).

2) Revisão de permissões (mensal e após mudanças)

Objetivo: reduzir a chance de abuso de privilégio e detectar contas “sobrando”. Foque em contas com poder de: alterar retenção, apagar pontos, remover repositórios, desativar alertas e gerenciar credenciais.

Passo a passo (mensal)

1. Exportar a lista de usuários/grupos com privilégios administrativos no backup e no repositório.
2. Comparar com a lista de funções autorizadas (matriz de acesso).
3. Remover acessos não utilizados e contas órfãs (ex.: ex-funcionários, contas de projeto).
4. Validar contas de serviço: escopo mínimo, rotação conforme política, e registro do dono.
5. Registrar evidências (data, responsável, mudanças realizadas).

3) Controle de alterações (sempre)

Objetivo: qualquer mudança que afete capacidade de recuperação deve ser rastreável. Mudanças típicas: retenção, escopo, exclusões, janelas, destinos, chaves, credenciais, notificações, integrações e regras de expiração.

Modelo simples de controle:

• Pré-mudança: registrar o “antes” (prints/export), motivo, impacto e janela.
• Pós-mudança: validar 1 execução completa do job e checar indicadores (sucesso, volume, duração, idade).
• Regra de ouro: mudança sem registro vira alerta de segurança.

Painel mínimo de indicadores (o “dashboard” que você precisa ter)

Um painel mínimo deve caber em uma tela e ser atualizado automaticamente. Ele não substitui investigação, mas mostra rapidamente se a capacidade de recuperar está se deteriorando.