Backup e Recuperação contra Ransomware: entendendo o risco e definindo objetivos de recuperação

O que caracteriza ransomware (visão operacional)

Ransomware é um tipo de ataque que busca interromper a operação e forçar pagamento (ou outra vantagem) por meio de indisponibilidade e pressão. Do ponto de vista operacional, ele costuma combinar quatro ações principais:

• Criptografia de dados: arquivos, volumes ou bancos são cifrados para impedir leitura e uso. Em ambientes corporativos, a criptografia pode atingir shares de rede, servidores de arquivos, VMs, endpoints e repositórios de dados.
• Extorsão: além de bloquear o acesso, o atacante ameaça publicar dados (dupla extorsão) ou ampliar o impacto (tripla extorsão, incluindo pressão sobre clientes/fornecedores). Operacionalmente, isso implica que a recuperação não é só “voltar a operar”, mas também reduzir exposição de dados.
• Tentativa de destruir ou inutilizar backups: o atacante procura apagar snapshots, corromper repositórios, remover retenções, roubar credenciais de backup e desativar agentes. O objetivo é impedir restauração rápida e aumentar a chance de pagamento.
• Movimentação lateral e escalonamento: após entrar, o atacante busca credenciais e privilégios para alcançar sistemas mais críticos (controladores de domínio, servidores de virtualização, storage, backup). Isso aumenta o raio de impacto e permite criptografar “em massa”.

Ativos mais atingidos (o que normalmente vira alvo)

Ao mapear risco, assuma que o atacante tentará atingir ativos que maximizam interrupção e dificultam recuperação:

• Identidades: Active Directory/IdP, contas privilegiadas, MFA/SSO (quando possível), servidores de autenticação.
• Serviços de infraestrutura: DNS, DHCP, NTP, PKI/certificados, servidores de arquivos, serviços de impressão (em alguns ambientes), ferramentas de gerenciamento remoto.
• Camada de virtualização: hipervisores, vCenter/gerenciadores, datastores, repositórios de imagens, orquestração.
• Bancos de dados: ERPs, CRMs, bancos transacionais, data warehouses, filas e caches persistentes.
• Aplicações e integrações: APIs, middleware, mensageria, ETL, integrações com parceiros.
• Repositórios de backup: servidores de backup, storage de backup, catálogos, credenciais e chaves.
• Endpoints: estações e notebooks (muitas vezes o ponto inicial), além de servidores com acesso administrativo.

Mapeando dados críticos, serviços essenciais e dependências

O objetivo deste mapeamento é responder: “O que precisa voltar primeiro para a empresa operar minimamente?” e “Do que isso depende?”. Faça o exercício com foco em operação e recuperação, não em inventário perfeito.

Passo a passo prático: inventário mínimo para recuperação

1. Liste os processos de negócio essenciais (3 a 10 itens). Ex.: faturamento, emissão de NF, atendimento, logística, produção, e-commerce, folha de pagamento.
2. Para cada processo, liste os serviços/sistemas que o suportam. Ex.: “Faturamento” depende de ERP + banco de dados + serviço de emissão + integrações.
3. Para cada sistema, identifique o “ativo de dados” principal: banco, diretório de arquivos, storage, repositório de documentos, etc. Ex.: “ERP” → banco PostgreSQL + diretório de anexos.
4. Mapeie dependências técnicas (o que precisa existir antes de restaurar/operar):
   • Identidades: AD/IdP, DNS, certificados, MFA.
   • Infra: virtualização, storage, rede, VPN, jump servers.
   • Plataforma: SO, middleware, runtime, containers, orquestração.
   • Integrações: filas, APIs, gateways, chaves e segredos.
5. Defina o “modo degradado aceitável” para cada processo (continuidade mínima). Ex.: “emitir NF manualmente por 24h”, “atendimento só leitura”, “expedição com planilha”.
6. Identifique onde os dados vivem e como mudam: frequência de atualização, volume diário, janelas de pico. Isso alimenta RPO/RTO.
7. Marque os pontos únicos de falha (single points): um único AD, um único DNS, um único storage, um único servidor de licenças, um único repositório de backup.

Modelo simples de tabela para preencher

Definindo objetivos práticos de recuperação

Objetivos de recuperação precisam ser operacionais (o que volta, em qual ordem, em quanto tempo, com qual perda aceitável) e verificáveis (critérios de sucesso). Três definições ajudam a tornar isso executável:

1) Continuidade mínima (o “mínimo para funcionar”)

Defina um conjunto de serviços que, restaurados, permitem operar de forma limitada. Exemplo de continuidade mínima em muitas empresas:

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

• Identidades básicas (AD/IdP) e acesso administrativo controlado
• DNS interno funcionando
• Rede/VPN/jump server para equipe de TI
• Um canal de comunicação operacional (ex.: e-mail corporativo ou alternativa definida)
• O sistema que gera receita (e-commerce/ERP/faturamento) em modo reduzido

O ponto é: não é “restaurar tudo”, é restaurar o suficiente para reduzir prejuízo e organizar o restante.

2) Prioridade de restauração (ordem realista)

Uma ordem prática costuma seguir dependências. Exemplo de sequência típica (ajuste ao seu ambiente):

1. Controle e validação do ambiente de recuperação: rede isolada/segmentada, credenciais limpas, acesso administrativo.
2. Serviços de identidade: AD/IdP, políticas, contas de serviço essenciais.
3. DNS e serviços base: DNS, NTP, certificados/PKI (se necessário para autenticação e TLS interno).
4. Camada de virtualização/compute: hipervisores/gerência, datastores, clusters (se for o caminho de restauração).
5. Bancos de dados críticos: restaurar DBs antes das aplicações que dependem delas.
6. Aplicações essenciais: ERP/CRM/e-commerce, integrações mínimas.
7. Serviços secundários: BI, relatórios, ambientes de dev/test, arquivos históricos.

Se sua empresa depende fortemente de SaaS, a prioridade pode mudar: identidade e rede podem ser ainda mais críticas do que servidores internos.

3) Critérios de sucesso (como saber que “voltou”)

Evite critérios vagos como “o servidor está no ar”. Use critérios testáveis:

• Disponibilidade funcional: usuário consegue autenticar e executar uma transação real (ex.: emitir pedido, consultar cliente).
• Integridade: checksums/validações de banco, contagem de registros, consistência referencial, logs sem erros críticos.
• Segurança mínima: credenciais administrativas trocadas, contas suspeitas desativadas, acesso remoto controlado, backup protegido.
• Performance aceitável: tempos de resposta dentro de um limite definido para modo degradado.
• Rastreabilidade: registro do que foi restaurado, de qual ponto no tempo, e por quem.

RPO e RTO: conceitos e exemplos simples

RPO (Recovery Point Objective)

RPO é a perda máxima de dados aceitável, medida em tempo. Ele responde: “Até quanto no passado eu posso voltar sem quebrar o negócio?”

• RPO de 1 hora: posso perder até 1 hora de alterações (pedidos, lançamentos, arquivos).
• RPO de 24 horas: posso voltar para o backup de ontem e aceitar refazer o trabalho do dia.

RTO (Recovery Time Objective)

RTO é o tempo máximo aceitável para restaurar e voltar a operar. Ele responde: “Em quanto tempo esse serviço precisa estar funcional?”

• RTO de 2 horas: em até 2 horas o serviço deve estar utilizável (mesmo que em modo degradado).
• RTO de 2 dias: o serviço pode ficar indisponível por até 48 horas.

Exemplos práticos por tipo de sistema

Exercícios de estimativa (RPO/RTO) por sistema

Use os exercícios abaixo para transformar “achismos” em números iniciais. O objetivo é chegar em estimativas razoáveis para priorização e desenho de backup/recuperação.

Exercício 1: estimando RPO com base em volume de mudança

Passo a passo:

1. Escolha um sistema (ex.: ERP).
2. Responda: quanto retrabalho é aceitável se eu perder dados? (em horas)
3. Responda: qual o custo do retrabalho (pessoas x horas) e risco (financeiro/regulatório)?
4. Defina um RPO inicial que limite esse retrabalho.

Exemplo: se o ERP recebe pedidos continuamente e perder 8 horas gera reconciliação complexa, um RPO inicial pode ser 1 hora (ou menos). Se um file server de arquivos de projetos muda pouco, RPO de 24 horas pode ser aceitável.

Exercício 2: estimando RTO com base em dependências e tempo de restauração

Passo a passo:

1. Liste dependências do sistema (ex.: AD, DNS, banco, storage, licenças).
2. Estime tempo para cada etapa: provisionar VM/host, restaurar dados, aplicar configurações, validar.
3. Some os tempos e adicione margem (ex.: 20% a 50%) para imprevistos.
4. Compare com o tempo máximo que o negócio tolera parado e ajuste prioridade.

Exemplo numérico simples:

Sistema: CRM (aplicação + banco) Dependências: AD/DNS ok Tempo estimado: restaurar DB (60 min) + restaurar app (30 min) + configuração (30 min) + testes (30 min) = 150 min Margem 30%: 45 min RTO estimado: ~195 min (~3h15)

Exercício 3: classificando sistemas por “faixas” para facilitar decisão

Quando não dá para definir números exatos de início, use faixas e refine depois:

• Faixa A (crítico): RTO ≤ 8h e RPO ≤ 1h
• Faixa B (importante): RTO ≤ 72h e RPO ≤ 24h
• Faixa C (tolerante): RTO até 7 dias e RPO ≥ 24h

Passo a passo: pegue sua tabela de processos/sistemas e atribua A/B/C com base em impacto e retrabalho aceitável. Em seguida, valide se a ordem de restauração respeita dependências (por exemplo, um sistema Faixa A não pode depender de um serviço Faixa C que você planeja restaurar por último).

Checklist rápido: o que você deve ter ao final do mapeamento

• Lista de processos essenciais e seus sistemas
• Dependências técnicas por sistema (identidade, DNS, virtualização, bancos, integrações)
• Definição de continuidade mínima (modo degradado aceitável)
• Ordem de restauração baseada em dependências
• RPO e RTO iniciais por sistema (mesmo que em faixas)
• Critérios de sucesso testáveis para cada serviço crítico