Backup e Recuperação contra Ransomware: inventário de dados, classificação e fontes de verdade

Por que inventário de dados é a base do backup contra ransomware

Uma estratégia de backup e recuperação só funciona quando você sabe exatamente o que precisa ser protegido, onde está, quem responde por aquilo e qual cópia é a referência correta (fonte de verdade). Sem um inventário, é comum proteger “o servidor” e esquecer dados críticos espalhados em endpoints, SaaS, repositórios de código, pastas locais, NAS, bancos e configurações.

Neste capítulo, você vai aprender a montar um inventário prático de dados e sistemas, classificar os conjuntos de dados e definir fontes de verdade, reduzindo lacunas que costumam quebrar a recuperação após um incidente.

Conceitos essenciais

O que é inventário de dados e sistemas

É um registro estruturado dos ativos de informação (dados) e dos componentes que os armazenam ou processam (sistemas), incluindo:

• Localização: onde os dados vivem (endpoint, servidor, SaaS, banco, NAS, storage em nuvem etc.).
• Proprietário (dono do dado): área/pessoa responsável por definir uso, retenção, acesso e prioridade de recuperação.
• Fonte de verdade: o repositório/cópia que deve ser considerado “o registro oficial” quando houver divergência.
• Dependências: quais sistemas/datasets precisam estar consistentes entre si para o serviço funcionar.
• Classificação: criticidade, sensibilidade e volatilidade.

Fonte de verdade (Source of Truth)

Fonte de verdade é o local onde a informação é mantida como referência primária. Em recuperação, isso evita decisões erradas como “restaurar a pasta errada” ou “confiar no export desatualizado”. Exemplos:

• CRM SaaS como fonte de verdade de clientes; planilhas locais são apenas cópias de trabalho.
• Banco de dados de produção como fonte de verdade de pedidos; cache e réplicas são derivados.
• Repositório Git como fonte de verdade de código; diretórios locais são cópias.
• Vault/gerenciador de segredos como fonte de verdade de chaves; arquivos .env em máquinas são derivados (e risco).

Classificação: criticidade, sensibilidade e volatilidade

• Criticidade: impacto no negócio se o dado/sistema ficar indisponível ou inconsistente. Ex.: faturamento, pedidos, folha de pagamento.
• Sensibilidade: impacto se houver vazamento/alteração não autorizada. Ex.: dados pessoais, financeiros, segredos comerciais, chaves.
• Volatilidade: frequência de mudança. Ex.: logs e eventos mudam continuamente; um manual de políticas muda pouco.

Essas três dimensões ajudam a priorizar proteção e a desenhar backups coerentes (por exemplo, dados muito voláteis e críticos exigem mais disciplina de consistência e testes de restauração).

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 para construir o inventário

Passo 1 — Defina o escopo e o formato do inventário

Escolha um formato simples (planilha ou tabela em ferramenta interna) e defina o escopo inicial:

• Comece pelo que “para a empresa”: sistemas que suportam receita, operação, atendimento, finanças e identidade.
• Inclua dados e configurações, não apenas servidores.
• Defina um identificador único por item (ex.: DATA-001, SYS-014) para rastrear mudanças.

Dica prática: se o ambiente é grande, faça em ondas: (1) sistemas críticos, (2) sistemas importantes, (3) restante.

Passo 2 — Mapeie onde os dados vivem (fontes e superfícies comuns)

Use esta lista como guia para não esquecer “lugares invisíveis”:

• Endpoints: notebooks/desktops (Documentos, Área de Trabalho, pastas de projeto), dispositivos de campo, máquinas de desenvolvedores.
• Servidores: file servers, servidores de aplicação, VMs, hosts de virtualização, servidores legados.
• SaaS: e-mail, drive corporativo, CRM, ERP, helpdesk, ferramentas de marketing, RH.
• Bancos de dados: relacionais, NoSQL, data warehouse, bancos embarcados em aplicações.
• NAS e storage: compartilhamentos SMB/NFS, appliances, storages em nuvem.
• Repositórios de código: Git (cloud/on-prem), registries de artefatos, imagens de container.
• Configurações e infraestrutura: IaC (Terraform/Ansible), templates, pipelines CI/CD, configurações de rede, DNS, certificados.
• Segredos e chaves: vault, HSM, gerenciadores de senha, chaves SSH, tokens de API, chaves de criptografia.
• Logs e telemetria: SIEM, logs de aplicação, auditoria, trilhas de acesso.

Como coletar rapidamente: combine entrevistas curtas com donos de sistemas, varredura de ativos (CMDB/MDM/AD), e revisão de contas SaaS ativas (lista de aplicativos autorizados).

Passo 3 — Identifique o dono do dado (data owner) e o responsável técnico

Para cada conjunto de dados, registre:

• Dono do dado: quem decide prioridade, retenção, acesso e validação pós-restauração (ex.: gerente de finanças para dados contábeis).
• Responsável técnico: quem executa/automatiza backup e restauração (ex.: time de infraestrutura, DBA, SRE).

Regra prática: se ninguém “assina” a validação do dado restaurado, o inventário está incompleto.

Passo 4 — Defina a fonte de verdade e as cópias derivadas

Para cada item, responda:

• Qual é o registro oficial? (ex.: banco de produção, sistema SaaS, repositório Git).
• Quais são cópias derivadas? (exports, planilhas, caches, réplicas, relatórios).
• Como a verdade é atualizada? (fluxo de escrita: app → DB, integrações, ETL).

Exemplo prático (registro no inventário):

• Dataset: “Pedidos”
• Fonte de verdade: DB transacional
• Derivados: data warehouse (ETL noturno), relatórios PDF, cache Redis
• Risco comum: restaurar o warehouse e esquecer que ele é derivado; o correto é restaurar o DB e reprocessar o ETL.

Passo 5 — Classifique por criticidade, sensibilidade e volatilidade

Use uma escala simples (Alta/Média/Baixa) para começar. O objetivo é priorizar, não criar burocracia.

Dica prática: volatilidade alta + criticidade alta costuma indicar necessidade de atenção especial a consistência e validação (por exemplo, app e banco restaurados em conjunto).

Passo 6 — Identifique conjuntos que precisam de consistência (app + banco + filas)

Ransomware e restauração podem introduzir inconsistências quando componentes relacionados são restaurados para pontos diferentes no tempo. Para mapear isso, procure por:

• Aplicação + banco: a aplicação grava no banco e depende do schema/versão.
• Banco + storage de arquivos: registros no DB apontam para arquivos (uploads, anexos).
• Aplicação + filas/streams: mensagens em fila podem ser reprocessadas após restauração.
• Identidade + permissões: diretórios/SSO e grupos precisam estar coerentes com acessos.
• Integrações: webhooks, sincronizações com SaaS, jobs agendados.

Como registrar no inventário: crie um campo “Grupo de consistência” (ex.: CONS-03) e liste todos os componentes que devem ser recuperados de forma coordenada.

Exemplo de grupo de consistência:

• CONS-03 (E-commerce): App Web, DB Pedidos, Storage de Imagens, Fila de Pagamentos
• Observação: após restauração, pausar consumidores da fila até validar DB e reconciliar transações.

Passo 7 — Evite lacunas comuns (o que quase sempre fica fora)

Pastas locais e dados “fora do servidor”

• Risco: documentos críticos em “Documentos/Área de Trabalho” de executivos, financeiro e comercial.
• Como detectar: amostragem por área (5–10 usuários chave), revisão de políticas de sincronização, inventário de endpoints.
• Como registrar: “Endpoint – pasta local crítica”, dono do dado, e se existe sincronização para repositório central.

Repositórios de código e artefatos

• Risco: recuperar servidores sem recuperar o código, pipelines e registries; ou depender de cópias locais.
• Itens a inventariar: repositórios Git, branches protegidas, registries de pacotes, imagens de container, pipelines CI/CD, runners.
• Fonte de verdade: repositório central e configuração de pipeline versionada.

Configurações, infraestrutura como código e “estado”

• Risco: restaurar VMs sem conseguir recriar rede, DNS, regras de firewall, balanceadores, ou perder o “estado” de ferramentas IaC.
• Itens a inventariar: repositórios IaC, arquivos de estado, inventários, templates, scripts de bootstrap, configurações de proxy/WAF.
• Boa prática: tratar configurações como dados críticos (com dono e fonte de verdade).

Chaves, certificados e segredos

• Risco: restauração “funciona”, mas serviços não sobem por falta de certificados, tokens e chaves; ou segredos vazam por estarem em arquivos soltos.
• Itens a inventariar: vault, rotação, backups do vault (quando aplicável), certificados TLS, chaves de criptografia de dados, chaves SSH, tokens de API.
• Campo obrigatório: “Dependência de segredos” e “Local oficial do segredo”.

Dados de SaaS e integrações

• Risco: assumir que SaaS “já tem backup” e não mapear exportação, retenção e restauração.
• Itens a inventariar: quais dados existem no SaaS, como exportar, quem valida, e quais integrações dependem dele.

Modelo de planilha (inventário) para copiar e usar

Use as colunas abaixo como base. Ajuste conforme seu ambiente, mas evite remover campos de dono, fonte de verdade e grupo de consistência.

ID,Tipo (Sistema/Dataset),Nome,Descrição curta,Localização (onde vive),Tecnologia/Plataforma,Dono do dado (área/pessoa),Responsável técnico,Fonte de verdade,Derivados/espelhos,Grupo de consistência,Dependências (sistemas/datasets),Criticidade (A/M/B),Sensibilidade (A/M/B),Volatilidade (A/M/B),Retenção necessária,Forma de acesso (URL/share),Método de export/backup conhecido,Validação pós-restauração (como checar),Observações/Lacunas

Exemplo preenchido (linha única):

DATA-012,Dataset,Pedidos,Pedidos e itens do e-commerce,DB Prod (cluster X),PostgreSQL,Operações (Fulano),DBA (Ciclano),DB Prod,Warehouse (ETL),CONS-03,App Web; Storage Imagens; Fila Pagamentos,Alta,Alta,Alta,5 anos,interno,Dump + snapshots,Conferir contagem de pedidos e últimos IDs,ETL deve ser reprocessado após restore

Checklist de validação do inventário (qualidade e cobertura)

• Cobertura de locais: há itens para endpoints, servidores, SaaS, bancos e NAS/storage?
• Sem “órfãos”: todo dataset tem dono do dado e responsável técnico definidos?
• Fonte de verdade explícita: cada item tem uma fonte de verdade única e clara (ou justificativa se houver mais de uma)?
• Derivados identificados: caches, relatórios, réplicas e warehouses estão marcados como derivados?
• Consistência mapeada: sistemas críticos têm grupos de consistência (app+DB+arquivos+fila) definidos?
• Lacunas comuns cobertas: pastas locais, repositórios de código, pipelines, configurações, segredos e certificados aparecem no inventário?
• Classificação completa: criticidade, sensibilidade e volatilidade preenchidas para todos os itens?
• Dependências registradas: integrações e pré-requisitos (identidade, DNS, certificados, filas) estão listados?
• Validação pós-restauração: existe um método de checagem por item (ex.: consulta, contagem, comparação, teste funcional)?
• Atualização contínua: há um responsável e uma cadência para revisar o inventário (ex.: mensal/trimestral) e gatilhos de atualização (novo sistema, mudança de SaaS, migração)?