Um backup não é uma garantia apenas por existir. Se ninguém sabe o que ele contém, se pode ser apagado por meio de uma conta comprometida ou se nunca foi restaurado, ele pode falhar justamente quando for mais necessário.
O objetivo não é acumular arquivos duplicados. É restaurar informações e serviços importantes em um prazo aceitável depois de ransomware, erro humano, falha técnica ou exclusão acidental.
Um backup não é medido pelo espaço que ocupa, e sim pela capacidade comprovada de retomar a operação.
O guia #StopRansomware da CISA recomenda manter backups críticos criptografados, off-line e testados regularmente. O guia também alerta que muitas variantes de ransomware tentam localizar, apagar ou criptografar cópias às quais ainda conseguem acessar. Por isso, a recuperação deve ser planejada como parte da segurança, e não como uma tarefa técnica isolada.
1. Decida o que precisa ser recuperado primeiro
Nem todos os dados têm a mesma urgência. Antes de definir armazenamento ou frequência, faça um inventário curto dos recursos que sustentam a operação.
- Dados operacionais: clientes, pedidos, faturamento, agenda, estoque, documentos ou registros de produção.
- Sistemas e configurações: bancos de dados, aplicações, usuários, permissões, integrações e parâmetros relevantes.
- Ativos web: conteúdos, formulários, arquivos de mídia, configurações e dados recebidos pelo site.
- Materiais para reconstrução: código-fonte, instaladores, licenças, documentação técnica e procedimentos.
Para cada item, responda a duas perguntas específicas:
- Por quanto tempo ele pode ficar indisponível? Por exemplo: uma hora, um dia útil ou vários dias.
- Quanta informação recente pode ser perdida sem causar um dano inaceitável? Por exemplo: alterações da última hora, do último dia ou da última semana.
Essas escolhas transformam uma conversa vaga sobre “fazer backup” em prioridades operacionais. O NIST recomenda avaliar sistemas e operações para determinar requisitos e prioridades de contingência, evitando tratar dados críticos e arquivos dispensáveis da mesma forma.
2. Crie camadas de backup, não um único ponto de falha
Manter uma única cópia no mesmo dispositivo, servidor ou conta que se quer proteger não resolve um incidente grave. Uma estratégia consistente separa as cópias para que um único problema não atinja todas ao mesmo tempo.
Uma estrutura prática
- Cópia de trabalho: os dados e sistemas usados diariamente pela operação.
- Cópia para recuperação rápida: um backup recente para restaurar erros comuns ou perdas pontuais com agilidade.
- Cópia separada: um backup em outra localização, conta ou ambiente, com controles diferentes.
- Versões históricas: vários pontos no tempo para voltar a uma versão anterior quando um problema passa despercebido por dias.
Não é necessário aplicar a mesma combinação a tudo. Um banco de dados que muda constantemente pode exigir cópias mais frequentes do que um repositório de imagens institucionais. O importante é que a frequência corresponda à perda de dados que a organização aceita assumir.
3. Proteja o backup como um ativo crítico
Um backup exposto às mesmas credenciais e permissões do ambiente principal pode ser alterado por um invasor ou por um erro administrativo. A CISA recomenda criptografar backups, mantê-los off-line ou separados do ambiente habitual e testá-los regularmente.
Na prática, revise estes controles:
- Use contas dedicadas à administração de backups, e não contas pessoais compartilhadas.
- Use autenticação multifator quando estiver disponível.
- Limite quem pode apagar cópias, alterar retenções ou modificar configurações.
- Separe permissões de leitura, restauração e exclusão quando a ferramenta permitir.
- Ative proteção contra exclusão ou sobrescrita e mantenha versões quando o provedor oferecer esses recursos.
- Criptografe as informações tanto durante a transferência quanto no armazenamento.
- Guarde com segurança as chaves, credenciais e a documentação necessária para restaurar.
“Off-line” nem sempre significa desconectar manualmente um disco. Pode significar uma cópia que os sistemas de produção não conseguem acessar de forma permanente. A implementação técnica depende da infraestrutura, mas o princípio é duradouro: comprometer o ambiente principal não deve permitir destruir automaticamente todas as cópias.
4. Documente a restauração antes de um incidente
Um arquivo disponível não significa, necessariamente, um serviço disponível. Retomar a operação pode exigir restaurar um banco de dados em uma ordem específica, recriar usuários, reconectar uma integração, validar permissões ou alterar configurações de DNS e e-mail.
Crie uma ficha breve para cada sistema crítico com:
- responsável principal e substituto;
- localização exata dos backups e método de acesso;
- credenciais ou processo seguro para obtê-las;
- ordem de restauração de componentes e dependências;
- tempo previsto para uma primeira recuperação funcional;
- verificações posteriores: acesso, dados, formulários, pagamentos, relatórios ou integrações;
- canal para comunicar avanços às pessoas afetadas.
O NIST SP 800-34 Rev. 1 aborda o planejamento de contingência como uma combinação de procedimentos, estratégias de recuperação, testes, treinamento e manutenção. É um alerta importante: tecnologia sem responsáveis e sem etapas claras deixa decisões demais para um momento de pressão.
5. Teste uma restauração real e registre o resultado
A única maneira de saber se um backup funciona é restaurar uma cópia em um ambiente controlado. Não basta verificar se uma tarefa foi concluída sem erros ou se um painel mostra um indicador verde.
O que um teste útil deve incluir
- Escolha um sistema ou conjunto de arquivos com prioridade definida.
- Restaure a partir de uma cópia específica, sem usar o ambiente original para completar o que estiver faltando.
- Meça quanto tempo o processo leva e compare com o objetivo previsto.
- Verifique integridade e utilidade: abra arquivos, consulte registros, faça login, processe uma operação de teste ou confira integrações.
- Registre falhas, etapas manuais inesperadas, permissões ausentes e decisões pendentes.
- Atualize o procedimento e repita o teste sempre que a infraestrutura mudar.
O NIST destaca que os testes são essenciais para identificar deficiências e validar componentes do sistema e procedimentos de recuperação. Um exercício pequeno e recorrente costuma gerar mais aprendizado do que um plano extenso que nunca é executado.
6. Transforme backups em uma rotina de gestão
Os backups se deterioram quando ferramentas mudam, novos sistemas são incorporados, assinaturas vencem ou pessoas perdem acesso. Reserve uma revisão periódica para confirmar que a cobertura continua correta.
No mínimo, verifique:
- quais sistemas ou dados novos precisam ser incluídos;
- se as cópias terminam corretamente e na frequência acordada;
- se há alertas de falha sem atendimento;
- se contas e permissões continuam atribuídas a pessoas autorizadas;
- se a retenção cobre o período necessário para detectar um incidente;
- se a documentação de restauração corresponde à operação atual;
- quando ocorreu o último teste e quais melhorias permanecem em aberto.
O Cybersecurity Framework do NIST inclui a recuperação em uma gestão contínua de riscos: recuperar não é apenas voltar a um estado anterior, mas restaurar capacidades e aprender com o evento para melhorar a resiliência.
Conclusão: defina uma recuperação que você possa demonstrar
Um bom sistema de backups tem prioridades claras, cópias separadas do ambiente principal, controles de acesso, histórico de versões suficiente e um processo de restauração já testado. Comece nesta semana com um exercício concreto: escolha um ativo crítico, restaure-o com segurança e anote cada obstáculo. O resultado mostrará exatamente o que melhorar antes de uma emergência.
