Uma cópia de segurança só ajuda durante um ataque de ransomware se continuar disponível quando a infraestrutura principal estiver comprometida. Isso exige mais do que automatizar backups: é preciso limitar quem pode apagá-los, separar os ambientes e ensaiar a recuperação.
O alerta conjunto da CISA e de outras agências sobre o ransomware Gunra, publicado em 10 de agosto de 2026, recomenda manter cópias em locais fisicamente separados, segmentados e seguros. O documento relata que operadores do grupo apagaram dados de backup e arquivo tanto no data center principal quanto no ambiente de recuperação de uma vítima. O caso reforça um risco operacional: réplicas acessíveis pelas mesmas credenciais ou pela mesma rede podem falhar junto com a produção.
O que significa isolar uma cópia de backup
Isolamento reduz a possibilidade de que uma conta ou sistema comprometido altere ou destrua simultaneamente a produção e suas cópias. Pode envolver armazenamento offline, segmentação de rede, credenciais administrativas separadas, controles de retenção e mecanismos de imutabilidade quando disponíveis. Nenhuma medida isolada é garantia absoluta; a arquitetura deve considerar ameaças, requisitos de acesso e capacidade de restauração.
Uma cópia remota não é automaticamente independente. Se a automação da produção puder excluir os arquivos remotos, ou se administradores usarem a mesma identidade privilegiada nos dois ambientes, o risco permanece. Avalie também os caminhos de gestão, as chaves de criptografia, os registros de auditoria e quem pode alterar políticas de retenção.
Desenhe a recuperação antes do incidente
Comece por listar serviços e dados essenciais: por exemplo, banco de dados de pedidos, arquivos enviados por clientes, aplicação do site, configurações, DNS e contas administrativas. Para cada item, indique dependências e responsáveis. Defina a ordem de recuperação: restaurar um banco sem recuperar primeiro a identidade, a rede ou a aplicação pode não devolver o serviço.
Transforme objetivos em critérios mensuráveis
- RPO (Recovery Point Objective) é a perda máxima de dados, expressa como intervalo de tempo, que o negócio aceita. Se o objetivo for quatro horas, a frequência e retenção dos pontos de recuperação precisam permitir escolher uma cópia dentro desse limite.
- RTO (Recovery Time Objective) é o tempo-alvo para retomar um serviço. Ele deve incluir detecção, decisão, provisionamento, restauração, validação e retorno seguro — não apenas o tempo de copiar arquivos.
Esses objetivos devem refletir impacto real no negócio. Um sistema de faturamento pode ter prioridade diferente de um ambiente de testes; metas ambiciosas também podem exigir recursos e processos adicionais.
Teste a restauração sem colocar produção em risco
Agende exercícios em ambiente isolado e registre o resultado. Restaure uma amostra de arquivos e, periodicamente, uma aplicação completa. Verifique integridade e funcionamento: abrir o site não basta se pedidos recentes, permissões ou integrações estiverem ausentes. Cronometre as etapas e compare o resultado com os RPOs e RTOs definidos.
- Selecione um serviço prioritário e um ponto de recuperação conhecido.
- Confirme que a equipe consegue acessar a cópia por uma via administrativa independente.
- Restaure em rede de teste, sem reconectar componentes potencialmente comprometidos.
- Valide dados, configurações, contas, logs e dependências com a área responsável.
- Documente duração, falhas e ajustes; repita após mudanças relevantes.
Checklist para reduzir o risco de perda das cópias
- Mantenha pelo menos uma cópia separada da rede de produção e revise os privilégios de exclusão.
- Use contas administrativas distintas e autenticação forte, especialmente para consoles de backup.
- Revise retenção, proteção contra exclusão e alertas de mudanças inesperadas.
- Guarde instruções, chaves e contatos de emergência de forma segura e acessível durante uma indisponibilidade.
- Defina critérios para declarar o ambiente limpo antes de restaurar e reconectar sistemas.
- Teste tanto a recuperação de arquivos quanto a reconstrução de servidores e configurações.
A CISA recomenda testes programados de recuperação para verificar a integridade das cópias e ajustar RPO e RTO. O NIST, em seu guia de recuperação de eventos cibernéticos, também enfatiza planejamento, dependências, exercícios e melhoria contínua. O processo deve ser adaptado ao porte, à criticidade e às obrigações da empresa.
Como a HAD Cloud pode ajudar
Se sua empresa está avaliando hospedagem, VPS ou infraestrutura em nuvem, converse com a equipe da HAD Cloud sobre os requisitos do ambiente e como eles se encaixam em uma estratégia de continuidade. Confirme escopo, responsabilidades, retenção e procedimentos de restauração antes de tomar decisões; este artigo não presume recursos ou níveis de serviço específicos de qualquer plano.
Perguntas frequentes
Backup em nuvem é suficiente contra ransomware?
Não necessariamente. Importam também a separação das credenciais e da rede, a proteção contra exclusão e a possibilidade comprovada de restaurar. A nuvem pode compor a estratégia, mas não substitui testes nem controles de acesso.
Com que frequência devo testar a restauração?
Defina uma cadência compatível com a criticidade e repita após mudanças relevantes. O essencial é testar de forma recorrente e registrar se o processo atende às metas estabelecidas.
Qual a diferença entre RPO e RTO?
RPO trata de quanto dado a empresa aceita perder; RTO trata de quanto tempo aceita levar para retomar o serviço. Os dois precisam ser definidos por processo de negócio e validados em exercícios.
