Do DRP à Resiliência Cibernética: como integrar a Recuperação de Desastres e a Proteção contra Ataques em um Único Plano
Introdução: O que é um Plano de Recuperação de Desastres (DRP)?
Com o crescimento da tecnologia como propulsora dos negócios, as empresas tornaram-se cada vez mais dependentes da disponibilidade de seus ambientes tecnológicos. O Plano de Recuperação de Desastres (em inglês, Disaster Recovery Plan ou DRP) surgiu como uma resposta à necessidade de garantir a continuidade dos negócios após desastres naturais, falhas de hardware ou outros eventos disruptivos.
No entanto, assim como a tecnologia evolui, os planos de recuperação também precisam se adaptar. Hoje, é imprescindível que o DRP inclua estratégias para lidar com novas ameaças, como os ataques cibernéticos e ações de hackers. Garantir uma recuperação ágil e eficiente nessas situações não é mais um diferencial, mas uma necessidade crítica para a sobrevivência dos negócios.
Como tudo surgiu: as primeiras necessidades
Na década de 1970, surgiram as primeiras iniciativas de armazenar dados críticos processados por mainframes em fitas magnéticas, uma prática que perdurou por décadas. As fitas de backup tornaram-se populares com a descentralização da computação, pois ajudavam a remediar falhas de hardware, erros técnicos e até desastres naturais, como incêndios, enchentes e terremotos.
A indústria financeira, em particular, a partir da década de 1980, começou a adotar DRPs de forma mais sistemática, dada a criticidade de seus sistemas e a necessidade de cumprir regulamentações. Um evento em particular, envolvendo o Bank of Americaem 1983, relacionado a uma falha grave de software em seu sistema de processamento de transações, teve importância fundamental para que os planos de recuperação fossem mais bem estruturados. Nesse período, começou a se expandir o conceito de data centers secundários e suas formas de atuação (Cold Site, Warm Site e Hot Site).
Outro evento relevante ocorreu em 1992, com o Hurricane Andrew nos EUA, que causou grandes prejuízos a empresas que não tinham planos de recuperação adequados. Esse evento foi um marco para a conscientização sobre a importância de DRPs para os demais setores da economia. Alguns padrões e frameworks, como o ITIL (InformationTechnology Infrastructure Library), começaram a incluir práticas para gerenciamento de continuidade de negócios e recuperação de desastres.
Mas o caso mais emblemático e discutido em todo o mundo ocorreu em 11 de setembro de 2001, quando os ataques às Torres Gêmeas nos EUA destacaram a importância de planos de recuperação que incluíssem não apenas falhas técnicas ou desastres naturais, mas também eventos de grande impacto, como atentados. Muitas empresas tinham seus DRPs nas próprias torres, o que facilitava o dia a dia, mas, infelizmente, não previa ataques dessa magnitude. Os planos começaram a ser revistos, e uma nova prática passou a ser adotada: os data centers secundários precisavam estar geograficamente distantes.
No entanto, durante todos esses anos, construir uma estrutura que replicasse o ambiente principal sempre foi muito debatido com os times financeiros e de negócio. A probabilidade de ocorrência de um evento de desastre foi sendo mitigada, seja por não construir operações em locais com risco de eventos naturais ou por adicionar camadas para aumentar a redundância nos equipamentos.
Manter um site secundário é oneroso financeiramente para as empresas, tanto inicialmente quanto ao longo do tempo. Custos de aquisição de servidores, equipamentos de rede, firewalls, conectividade, licenças de software, entre outros, fizeram com que muitas empresas não desenvolvessem um data center secundário igual ao primário, mas sim ambientes que cobrissem a parte essencial do negócio, ou seja, atendessem somente às áreas críticas.
A Probabilidade mudou radicalmente com os Ataques Cibernéticos
A popularização da computação em nuvem e o aumento dos ataques cibernéticos, como ransomware, transformaram a forma como as empresas abordam a recuperação de desastres. Esses ataques, cada vez mais frequentes e impactantes, exigem uma nova abordagem para garantir a resiliência dos negócios.
A partir de 2021, vários casos ganharam destaque na mídia, envolvendo empresas de diferentes setores, derrubando a ideia de que somente empresas do setor financeiro estavam na mira dos hackers. Os ataques cibernéticos por meio de ransomwarecriptografam os dados, e os hackers exigem pagamentos milionários para liberá-los ou ameaçam expor os dados roubados na Deep Web, colocando as empresas no radar das rígidas legislações de privacidade de dados e suas penalidades.
Só aqui no Brasil, tivemos inúmeros casos que repercutiram na mídia e trouxeram luz ao tema, como os ataques à JBS (2021), Fleury (2021), Localiza (2021), CVC (2021), Porto Seguro (2022), Light (2022), Serasa (2022) e Hospital Albert Einstein (2023).
O caso da JBS foi emblemático, pois a empresa relatou ter pago US$ 11 milhões em Bitcoin para evitar maiores prejuízos, já que suas operações nos EUA, Austrália e Canadá haviam sido afetadas. No Brasil, a empresa precisou interromper temporariamente algumas operações. O caso ganhou destaque internacional e levantou discussões sobre a necessidade de maior proteção cibernética em infraestruturas críticas e a ética no pagamento de resgates.
Para atuar de forma imediata, muitas empresas acabaram por desenvolver ações e planos exclusivos para endereçar os riscos cibernéticos, aumentando consideravelmente os custos da área de Tecnologia.
Entretanto, manter dois planos separados para desastres físicos e cibernéticos pode parecer uma solução simples, mas na prática, essa abordagem traz uma série de desafios, incluindo custos elevados, complexidade de gerenciamento, riscos de gaps na cobertura e dificuldades em testes e conformidade. A integração desses planos em uma estratégia única de resiliência não só reduz esses desafios, mas também aumenta a eficiência, a agilidade e a capacidade da empresa de responder a qualquer tipo de desastre, seja físico ou cibernético.
Desafios na Criação de um Plano Integrado
O primeiro passo é definir o RTO (Recovery Time Objective) e o RPO (Recovery Point Objective). O RTO é o tempo máximo que a empresa pode tolerar de downtime(inatividade) sem impactos críticos nos negócios. Já o RPO é o intervalo de tempo entre o último backup válido e o momento do desastre. Quanto menores forem esses tempos, maiores serão os investimentos necessários.
Nesse sentido, desenvolver uma Análise de Impacto nos Negócios (BIA – Business Impact Analysis) é o melhor caminho. Inicia-se sempre identificando os sistemas e processos críticos para a operação da empresa e o respectivo impacto financeiro, operacional e reputacional de um desastre em cada um deles. O dado primordial que norteia essa atividade é o inventário de sistemas e processos, bem como seus key users.
Em seguida, priorizam-se os sistemas com base em sua criticidade, ou seja, a sequência em que os sistemas voltam a operar. Nem todos os sistemas precisam dos mesmos RTOse RPOs; alguns serão mais curtos (sistemas críticos) e outros mais longos.
Com isso em mãos, é possível iniciar a análise técnica para identificar quais arcabouços técnicos serão necessários para criar o plano de recuperação. Em alguns casos, onde os RTOs e RPOs são mais longos, às vezes já é possível utilizar ferramentas já existentes na empresa. Em casos de tempos e perdas de dados mais arrojados, que exigem, por exemplo, replicação de dados em tempo real, ferramentas e infraestruturas adicionais serão inevitavelmente necessárias.
Vale ressaltar que, para ter resiliência em um ataque cibernético, é importante manter os dados de backup isolados e em condição de imutabilidade. O mesmo se aplica para dados replicados em tempo real, onde o segundo ambiente também deve estar protegido contra ataques.
Com o plano desenhado, o mais importante é realizar uma programação de testes regulares e simulações para treinar a equipe e garantir que os RTOs e RPOs possam ser atingidos na prática. Não basta ter um plano perfeito escrito se os times técnicos não estão familiarizados com ele. É com base nos testes que são percebidos ajustes necessários, fazendo com que o plano não se torne desatualizado. É ideal também que os testes sejam validados pelos times de negócio, para que, se houver a necessidade de ativar o plano, todos saibam como proceder.
Em uma das minhas experiências, pude constatar que as simulações mensais trouxeram não só uma melhor percepção das camadas técnicas e o atingimento do RTO combinado com os times de negócio, mas também o dimensionamento adequado da infraestrutura e os custos relacionados.
Um fator que tem ajudado muito as empresas no desenho técnico do DRP são as soluções oferecidas em nuvem, baseadas em serviços como Backup as a Service (BaaS) e Disaster Recovery as a Service (DRaaS).
A Importância de um Plano Integrado para a Continuidade dos Negócios
Os DRPs evoluíram de simples backups em fitas magnéticas para estratégias complexas que integram recuperação de desastres físicos e cibernéticos. Hoje, eles são parte essencial da governança corporativa, garantindo a resiliência dos negócios em um mundo cada vez mais digital e conectado.
Embora a especialização técnica para tratar ataques cibernéticos seja crucial, esses eventos podem ser vistos como um tipo de indisponibilidade e integrados ao DRP tradicional. Ao tratar o ataque cibernético como uma causa de indisponibilidade, é possível aproveitar o plano existente e adicionar etapas específicas para lidar com esses eventos de forma estruturada.
