Backup e Recuperação contra Ransomware: testes de restauração e validação de integridade

Por que testar restauração é diferente de “ter backup”

Em cenários de ransomware, o risco não é apenas perder dados: é descobrir tarde demais que o backup não restaura, restaura incompleto ou restaura “de pé” (serviço inicia) mas a aplicação não funciona. Testes de restauração e validação de integridade servem para provar recuperabilidade de forma repetível, com critérios objetivos de aprovação e evidências para auditoria interna.

Uma rotina madura combina: (1) testes automatizados para detectar falhas cedo, (2) testes manuais para cobrir fluxos críticos e validações funcionais, (3) amostragem por criticidade (o que é mais importante é testado mais), e (4) validações de integridade em múltiplas camadas (arquivo, sistema, banco, aplicação).

Desenhando a rotina de testes: o que testar, quando e com qual profundidade

Tipos de teste (e o que cada um prova)

• Teste de restauração de arquivo: prova que objetos individuais podem ser recuperados com permissões e conteúdo corretos.
• Teste de restauração de VM/servidor: prova que o sistema operacional e serviços sobem com configuração coerente (rede, DNS, certificados, agentes).
• Teste de restauração de banco de dados: prova consistência lógica e capacidade de atender consultas/transactions.
• Teste de restauração de aplicação (end-to-end): prova que o usuário consegue executar jornadas essenciais (login, consulta, gravação, emissão de relatório etc.).
• Teste de “ponto no tempo” (quando aplicável): prova que é possível restaurar para um instante específico e que a aplicação se comporta corretamente com aquele estado.

Frequência recomendada (modelo prático)

Se houver restrição de tempo/infra, priorize: (1) banco e aplicação crítica, (2) identidade/autenticação, (3) arquivos compartilhados críticos. O objetivo é reduzir a chance de descobrir falhas somente durante um incidente.

Amostragem por criticidade (como escolher o que entra no teste)

Use uma lista de “itens testáveis” (datasets, VMs, bancos, volumes, shares) e aplique amostragem ponderada:

• Alta criticidade: 100% dos itens entram em algum teste recorrente (nem que seja alternando profundidade).
• Média: amostra de 30% a 50% por ciclo, rotacionando para cobrir 100% ao longo do trimestre.
• Baixa: amostra de 10% a 20% por ciclo.

Inclua variação: arquivos pequenos e grandes, muitos arquivos pequenos (pior caso), bancos com alto volume de logs, VMs com múltiplos discos, e itens com permissões complexas.

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

Critérios de aprovação (definição objetiva)

Defina critérios mensuráveis para cada tipo de teste. Exemplo:

• Arquivo: hash confere; tamanho esperado; permissões/ACL corretas; abertura bem-sucedida no aplicativo.
• VM/servidor: boot sem erros; serviços essenciais “healthy”; tempo de boot dentro do limite; logs sem falhas críticas; conectividade básica validada.
• Banco: restore concluído; checks de consistência sem erros; consultas de sanidade retornam resultados esperados; latência aceitável.
• Aplicação: smoke tests passam (login, leitura, escrita); integrações críticas respondem; páginas/rotas principais carregam; filas/processos assíncronos operam.

Registre também critérios de reprovação (por exemplo: “restaurou mas não monta volume”, “aplicação sobe mas não autentica”, “banco restaura mas falha em consistência”). Isso acelera triagem e correção.

Validação de integridade: do arquivo à aplicação

1) Integridade por hash (arquivo/objeto)

Hash é uma forma simples de verificar se o conteúdo restaurado é idêntico ao original (ou ao que foi capturado como referência). Use quando você tem um “golden hash” armazenado de forma confiável (por exemplo, para artefatos, exports, pacotes, dumps).

Exemplo prático (Linux):

# Gerar hash do arquivo original (antes) e salvar em local controlado
sha256sum contrato.pdf > contrato.pdf.sha256

# Após restaurar, validar
sha256sum -c contrato.pdf.sha256

Exemplo prático (Windows PowerShell):

# Gerar hash
Get-FileHash .\contrato.pdf -Algorithm SHA256 | Format-List

# Comparar com hash esperado (exemplo simples)
$expected = "ABCDEF..."  # substitua pelo valor armazenado
((Get-FileHash .\contrato.pdf -Algorithm SHA256).Hash -eq $expected)

Boas práticas: (1) use SHA-256 ou superior, (2) guarde hashes em repositório controlado e versionado, (3) aplique em amostras representativas (arquivos críticos, exports de banco, binários de aplicação).

2) Verificação pelo aplicativo (abrir, processar, validar formato)

Mesmo com hash correto, o “funciona” pode falhar por dependências externas, permissões, encoding, chaves/certificados, ou dados inconsistentes. Por isso, inclua validações no nível do aplicativo:

• Arquivos Office/PDF: abrir e renderizar sem erro; imprimir/exportar; validar assinatura digital (se houver).
• Arquivos compactados: zip -T (teste de integridade) ou ferramenta equivalente.
• Imagens: validar leitura por biblioteca padrão; checar metadados essenciais.
• Artefatos de deploy: validar checksum + executar teste de inicialização em ambiente isolado.

Exemplo (ZIP em Linux):

zip -T backup_documentos.zip

3) Consistência de banco de dados (integridade lógica)

Restauração de banco pode “subir” e ainda assim estar inconsistente (páginas corrompidas, índices quebrados, constraints violadas, logs incompletos). Sempre execute verificações nativas do SGBD e consultas de sanidade.

• SQL Server: DBCC CHECKDB após restore.
• PostgreSQL: validações por extensão (quando aplicável), checagens de índices e constraints, e consultas de sanidade; revisar logs de recovery.
• MySQL/MariaDB: checagem de tabelas/engine, validação de constraints e queries de sanidade.

Exemplo (SQL Server):

DBCC CHECKDB (N'SeuBanco') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Exemplo (PostgreSQL – sanidade simples):

-- Contagens esperadas (ajuste para sua realidade)
SELECT COUNT(*) FROM usuarios;
SELECT MAX(data_atualizacao) FROM pedidos;

-- Verificar constraints inválidas (exemplo genérico)
SELECT conname, convalidated FROM pg_constraint WHERE NOT convalidated;

Além disso, valide pontos de integração: credenciais de conexão, strings de conexão, certificados TLS, e permissões do usuário de aplicação no banco.

Como detectar restaurações que “sobem” mas não funcionam

O erro comum é considerar sucesso quando o serviço inicia. Para evitar isso, use uma abordagem em camadas:

Checklist de “subiu, mas não funciona” (sinais típicos)

• Aplicação inicia, mas falha no login (dependência de IdP/AD, chaves, relógio/NTP, certificados).
• API responde 200, mas operações de escrita falham (permissões no banco, filas, storage).
• Front-end carrega, mas telas críticas ficam vazias (jobs não rodando, cache quebrado, migrações pendentes).
• Banco restaurado, mas consultas críticas retornam erro/timeout (índices corrompidos, estatísticas, falta de recursos).
• Serviço sobe, mas integrações externas não funcionam (DNS, rotas, firewall, certificados, endpoints).

Smoke tests (testes rápidos e repetíveis)

Crie um conjunto pequeno de testes que rodam em minutos e cobrem o essencial. Exemplos:

• Autenticar com usuário de teste.
• Criar um registro e confirmar persistência no banco.
• Executar uma consulta crítica e validar resultado.
• Gerar um relatório/arquivo e validar download/abertura.
• Publicar e consumir uma mensagem em fila (se aplicável).

Automatize sempre que possível (scripts, coleções de API, testes de UI mínimos). O objetivo é detectar rapidamente que “está de pé” não significa “está operacional”.

Automação vs. testes manuais: como combinar

Testes automatizados (o que automatizar primeiro)

• Restauração de amostras de arquivos + validação por hash.
• Restauração de VM em rede isolada + checagem de serviços (health endpoints, portas, logs).
• Restore de banco em instância de teste + execução de check de consistência + queries de sanidade.
• Smoke tests de API (ex.: coleção de endpoints críticos).

Automação deve produzir evidência: logs, timestamps, checks executados, e resultado (pass/fail) com motivo.

Testes manuais (onde ainda são essenciais)

• Validação funcional de jornadas do usuário (principalmente em sistemas legados).
• Verificação de relatórios, documentos gerados, integrações complexas.
• Testes de permissões/ACL em compartilhamentos com regras específicas.
• Simulação de operação mínima do negócio por algumas horas (quando necessário).

Laboratório prático orientado (roteiro completo)

Objetivo do laboratório: executar três restaurações (arquivos, VM/servidor, banco) e validar integridade e funcionamento da aplicação. Faça em ambiente isolado (rede de laboratório) para evitar impacto e reduzir risco.

Preparação do laboratório (antes de restaurar)

• Defina um ambiente isolado (VLAN/rede separada) com DNS/NTP controlados.
• Crie um usuário de teste e dados de teste (registro “canário”) para validação.
• Separe uma lista de verificação com critérios de aprovação por item.
• Garanta espaço de armazenamento e recursos (CPU/RAM) para restaurar sem “falsos negativos” por falta de capacidade.

Parte A — Restaurar arquivos e validar integridade

Passo a passo:

1. Selecione uma amostra: 1 pasta crítica com muitos arquivos pequenos + 1 arquivo grande + 3 arquivos “sensíveis” (ex.: planilha, PDF assinado, imagem).
2. Restaure para um diretório de laboratório (não sobrescreva produção).
3. Valide integridade por hash (quando houver hash de referência) e por abertura no aplicativo.
4. Valide permissões/ACL: proprietário, grupos, herança, acesso de leitura/escrita conforme esperado.
5. Registre evidências: lista de arquivos restaurados, tamanho total, tempo de restauração, checks executados.

Critérios de aprovação (exemplo):

• 100% dos arquivos da amostra restaurados.
• 0 divergências de hash nos arquivos com referência.
• Arquivos abrem sem erro e sem conteúdo truncado.
• Permissões conferem com o esperado para pelo menos 2 perfis (usuário padrão e usuário privilegiado).

Parte B — Restaurar VM/servidor e validar serviços

Passo a passo:

1. Escolha uma VM/servidor representativo (ex.: servidor de aplicação) e restaure em modo “isolado” (sem rotas para produção).
2. Ajuste parâmetros mínimos para o laboratório (ex.: IP, DNS apontando para laboratório). Evite mudanças que mascarem problemas: documente tudo.
3. Valide boot e serviços: verifique status do sistema, serviços essenciais e portas.
4. Valide logs: procure erros de inicialização, falhas de dependência, problemas de certificado e de resolução de nome.
5. Execute smoke tests locais (ex.: endpoint /health, login de teste se aplicável).

Exemplos de checagens:

# Linux (exemplos)
systemctl --failed
journalctl -p err -b --no-pager | tail -n 50
ss -lntp | head

# Endpoint de saúde (exemplo)
curl -fsS http://localhost:8080/health

Critérios de aprovação (exemplo):

• Boot completo sem erros críticos.
• Serviços essenciais ativos e respondendo.
• Endpoint de saúde retorna sucesso.
• Tempo de inicialização dentro do limite definido.

Parte C — Restaurar banco de dados e validar consistência

Passo a passo:

1. Restaure o banco em instância de laboratório (não reutilize a instância de produção).
2. Execute verificação de consistência nativa do SGBD (ex.: CHECKDB/checagens equivalentes).
3. Rode queries de sanidade: contagens, máximos de datas, integridade referencial, tabelas críticas.
4. Valide credenciais e permissões do usuário da aplicação no banco.
5. Conecte a aplicação restaurada ao banco restaurado e execute smoke tests de leitura e escrita.

Critérios de aprovação (exemplo):

• Restore finaliza sem erros.
• Check de consistência sem corrupção.
• Queries de sanidade retornam resultados esperados.
• Aplicação consegue ler e gravar (transação simples) com sucesso.

Parte D — Validar a aplicação (end-to-end) e detectar falhas ocultas

Passo a passo:

1. Execute um roteiro de 5 a 10 ações críticas (smoke tests) com usuário de teste.
2. Valide integrações essenciais (ex.: envio de e-mail em sandbox, fila interna, storage de anexos em laboratório).
3. Verifique jobs/rotinas assíncronas: agendadores, workers, filas.
4. Confirme que dados “canário” estão presentes e consistentes (ex.: pedido de teste, usuário de teste, registro de auditoria).
5. Registre evidências (prints, logs, resultados de testes automatizados).

Exemplo de teste de API (conceitual):

# 1) Login
POST /api/auth/login  {user, pass}  => 200 + token

# 2) Leitura
GET /api/pedidos?limit=1 (Authorization: Bearer token) => 200 + lista

# 3) Escrita
POST /api/pedidos {itens...} => 201 + id

# 4) Confirma persistência
GET /api/pedidos/{id} => 200 + dados esperados

Métricas e relatórios para auditoria interna

Métricas mínimas (o que medir sempre)

• Taxa de sucesso de restauração: % de testes aprovados por tipo (arquivo/VM/banco/aplicação).
• Tempo de restauração: por item e por tipo (mediana e p95).
• Tempo de validação: quanto tempo para executar checks e smoke tests.
• Falhas por categoria: credenciais/permissão, corrupção, dependência externa, configuração, capacidade, erro humano.
• Cobertura de testes: % de itens críticos testados no período (por criticidade).
• Recorrência: quantas falhas se repetiram sem correção.

Modelo de relatório (estrutura sugerida)

Checklist de evidências (para auditoria)

• Logs do job de restauração (com timestamps).
• Saída dos comandos de hash/checagens de integridade.
• Relatório do SGBD (resultado de consistência).
• Resultados dos smoke tests (automação ou roteiro manual assinado).
• Registro de mudanças feitas para o laboratório (ex.: IP/DNS) e justificativa.
• Tickets/ações corretivas vinculadas a cada reprovação.

Implementação rápida: primeiro ciclo em 7 dias (roteiro operacional)

Dia 1–2: definir escopo e critérios

• Selecionar 5 a 10 itens de alta criticidade (arquivos, 1 VM, 1 banco, 1 aplicação).
• Definir critérios de aprovação e evidências exigidas.
• Preparar ambiente de laboratório e usuário/dados canário.

Dia 3–4: automatizar o básico

• Script para restaurar amostra de arquivos e validar hash.
• Script para checar serviços e endpoint de saúde na VM restaurada.
• Script para rodar checks do banco + queries de sanidade.

Dia 5: executar teste completo end-to-end

• Rodar restauração de VM + banco + aplicação.
• Executar smoke tests e registrar evidências.

Dia 6–7: consolidar métricas e abrir correções

• Gerar relatório do ciclo (pass/fail, tempos, falhas por categoria).
• Abrir ações corretivas com prioridade baseada em criticidade.
• Atualizar checklist e scripts com aprendizados do ciclo.