Resiliência cibernética: backup não é recuperação
Manter cópias dos dados é indispensável, mas não garante que a empresa consiga retomar as operações depois de um ataque ou de uma falha grave. A diferença aparece quando os sistemas precisam voltar: o backup pode estar disponível e, ainda assim, a restauração demorar mais do que o negócio suporta ou deixar serviços essenciais sem funcionar.
Uma cópia armazenada responde apenas a uma parte do problema: os dados foram salvos? Para falar em resiliência, também é preciso saber se eles estão íntegros, protegidos contra exclusão ou adulteração e acessíveis em uma situação de crise. E, principalmente, se aplicações e serviços podem ser reconstruídos dentro do prazo necessário.
Ransomware também ataca a capacidade de recuperação
Em incidentes de ransomware, criminosos podem tentar localizar e comprometer consoles de backup, repositórios, contas administrativas e ferramentas de recuperação antes de iniciar a criptografia dos sistemas. Se a organização perde a possibilidade de restaurar os dados, aumenta a pressão para que pague pela extorsão.
A cópia de segurança, portanto, precisa ser protegida como um ativo crítico. Controles de acesso, separação de privilégios e monitoramento são tão importantes quanto a rotina que cria os backups. Quando uma única conta administra tanto o ambiente de produção quanto o de cópias, o comprometimento dessa identidade pode colocar os dois sob risco.
A imutabilidade ajuda a impedir alterações ou exclusões durante um período definido. Porém, não resolve todos os problemas. É necessário avaliar quem pode mudar as políticas de retenção, como o console é protegido e se as cópias imutáveis podem ser restauradas em um ambiente confiável. Uma barreira contra exclusão não garante, por si só, que os dados estejam limpos ou que o serviço volte a operar.
Também é importante considerar a extorsão baseada em roubo de informações. Mesmo que a empresa consiga restaurar os sistemas, dados previamente exfiltrados ainda podem ser usados para ameaçar clientes, funcionários ou parceiros. Recuperar a operação reduz parte do impacto, mas não elimina todas as consequências de um ataque.
Um backup bem-sucedido não prova que o serviço voltou
Relatórios indicando que as tarefas de backup foram concluídas mostram que determinado processo ocorreu. Eles não demonstram que uma aplicação completa pode ser recuperada e usada normalmente.
Um sistema corporativo pode depender de banco de dados, servidores, DNS, certificados, credenciais, serviços de identidade, armazenamento, rede, filas e integrações externas. Restaurar apenas os arquivos ou o banco pode produzir um ambiente aparentemente recuperado, mas que não autentica usuários, não se conecta a outros sistemas ou não atende às necessidades da equipe.
Por isso, o teste relevante é a restauração acompanhada de validação funcional. É preciso medir quanto tempo a recuperação leva e confirmar se os usuários conseguem executar as tarefas essenciais. O resultado deve registrar não só se os dados foram recuperados, mas também quais etapas falharam, quais dependências estavam ausentes e quanto trabalho manual foi necessário.
RTO e RPO precisam ser comprovados
O RTO, ou objetivo de tempo de recuperação, define quanto tempo um serviço pode ficar indisponível. Já o RPO, objetivo de ponto de recuperação, indica a quantidade máxima de dados que a empresa aceita perder, medida em tempo.
Esses parâmetros devem refletir as necessidades reais de cada operação. Se a empresa estabelece um RTO de quatro horas para o sistema financeiro, mas um exercício leva 14 horas, existe uma diferença entre o plano e a capacidade prática. Da mesma forma, prometer um RPO de 15 minutos exige cópias, arquitetura e procedimentos compatíveis com essa frequência.
Não basta registrar metas em um documento. Os testes precisam confirmar que elas são atingíveis e apontar o que deve mudar quando não são. A frequência de backup, a largura de banda, o volume de dados, a disponibilidade de especialistas e o tempo necessário para recriar a infraestrutura podem afetar o resultado.
Recuperar com segurança exige um ambiente confiável
Restaurar sistemas rapidamente sobre uma infraestrutura ainda comprometida pode reintroduzir o invasor. Uma conta roubada, um servidor com persistência maliciosa ou uma ferramenta administrativa contaminada podem comprometer novamente os serviços que acabaram de voltar.
Por isso, a recuperação deve estar coordenada com a resposta a incidentes. Antes de reativar sistemas importantes, a equipe precisa avaliar identidades, endpoints, servidores e caminhos de administração. Em determinadas situações, é mais seguro reconstruir o ambiente em uma infraestrutura nova do que restaurar tudo sobre a base existente.
O ambiente de backup também precisa ser acompanhado continuamente. Exclusões inesperadas de tarefas, redução de retenção, mudanças de configuração, falhas repetidas e logins administrativos fora do padrão podem indicar uma tentativa de preparar o terreno para um ataque. Tratar esses eventos como alertas de segurança ajuda a identificar problemas antes de uma emergência.
Como transformar cópias em capacidade de recuperação
Um programa eficaz começa pela identificação dos serviços essenciais e de suas dependências. Para cada sistema, a organização deve definir a ordem de retorno, as equipes responsáveis e as condições mínimas para liberar o acesso. Assim, a recuperação não depende de improviso no momento de maior pressão.
Os exercícios devem incluir cenários diferentes: perda de um servidor, indisponibilidade de um datacenter, comprometimento de credenciais e ataque que alcance ferramentas de administração. Testar apenas a restauração de arquivos individuais não revela se a empresa consegue reconstruir um serviço completo em uma situação complexa.
Também convém testar cópias em um ambiente isolado, separado da produção e preparado para a recuperação. Esse procedimento permite verificar a integridade dos dados sem expor sistemas restaurados a uma infraestrutura possivelmente infectada. O teste deve incluir credenciais de emergência e caminhos alternativos de acesso, pois as contas habituais podem estar indisponíveis ou não ser mais confiáveis.
Os resultados precisam ser documentados e convertidos em melhorias. Se uma restauração excedeu o RTO, a equipe deve identificar a causa: falta de capacidade, etapas manuais demais, documentação desatualizada ou dependências esquecidas. Repetir o mesmo exercício sem corrigir as falhas não aumenta a resiliência.
A decisão sobre o que volta primeiro também não é exclusivamente técnica. Durante uma crise, a empresa pode precisar escolher quais serviços são prioritários, que perda de dados é aceitável, quais integrações podem permanecer desligadas e em que momento é seguro retomar a operação. Essas escolhas devem ser discutidas antecipadamente com as áreas de negócio, tecnologia, segurança, jurídico e comunicação.
A abordagem de resiliência cibernética reúne governança, proteção, detecção, resposta e recuperação. O backup é uma peça essencial desse conjunto, mas não substitui planos, responsabilidades definidas, testes e capacidade de reconstruir serviços em condições seguras.
Resiliência, portanto, não está guardada em um repositório. Ela existe quando pessoas, processos e tecnologia conseguem trabalhar em conjunto para restaurar as funções prioritárias, respeitar os limites de tempo e perda de dados e reduzir o risco de que o incidente se repita.