Os ataques de ransomware e wiper estão a levar as organizações a reavaliar as suas capacidades de cópia de segurança e recuperação. Uma preocupação óbvia é saber se as cópias de segurança são seguras - por exemplo, se estão offline e não podem ser encriptadas ou apagadas.
Embora este seja um bom primeiro passo, não passa disso mesmo. Também precisamos de avaliar se as tecnologias de cópia de segurança e recuperação que utilizamos suportam a recuperação de ciberataques. Isto é particularmente importante se a recuperação bare-metal (BMR) fizer parte do seu plano de recuperação de AD.
Novo sentido de urgência
Como chefe de produto da Semperis, falo com muitos CIOs e CISOs sobre recuperação de desastres (DR) para o Microsoft Active Directory (AD). A atenção dada à recuperação do AD é bem merecida, tendo em conta o papel crítico do AD (se o AD não estiver disponível, nada estará) e o processo de recuperação especializado (quantos dos seus colegas já efectuaram uma recuperação florestal completa?)
Ao longo do último ano, tenho assistido a um novo sentido de urgência em torno da recuperação do AD. Já não se trata de anular uma actualização ao nível da floresta ou uma alteração de esquema. Agora, o foco está na recuperação do AD quando um ataque cibernético destrutivo e rápido (como o NotPetya ou o LockerGoga) elimina todos os seus controladores de domínio (DCs).
Isso foi na altura, isto é agora
Historicamente, o BMR tem proporcionado uma forma conveniente de recuperar um servidor inteiro. Por exemplo, a equipa de DR podia efectuar a recuperação por si própria, sem depender da equipa de aprovisionamento do servidor. Mas no novo cenário de ameaças, a maior força da BMR (recupera tudo no sistema operacional) se tornou sua maior fraqueza (potencialmente reintroduz malware).
O BMR também está a mostrar a sua idade. Foi criado para computadores físicos, numa altura em que muitos departamentos de TI precisavam de dias ou mesmo semanas para aprovisionar um servidor. Mas a virtualização mudou tudo isso.
E a BMR foi criada antes da nuvem e da infraestrutura como serviço (IaaS), que oferecem uma alternativa barata e prontamente disponível ao hardware de reserva.
Se o seu plano actual de recuperação do AD depende da BMR - ou se está a considerar novas capacidades de recuperação automatizada que dependem da BMR (para recuperar DCs quando o hardware ou o sistema operativo é afectado) - eis alguns aspectos a considerar.
Reinfecção
O BMR faz cópias de segurança e restaura tudo no DC, incluindo o sistema operativo (SO), o registo, os ficheiros do sistema, etc. Isto não é mau se um incêndio ou inundação destruir os seus DCs e for necessário restaurar o AD num novo hardware. Mas é uma coisa muito má se os seus DCs forem atingidos por um ciberataque.
Quando um intruso instala rootkits, ransomware ou outro malware nos seus DCs, todos esses executáveis e DLLs são incluídos nos backups do BMR. Quando faz um restauro BMR, o malware que não pretende é restaurado juntamente com o SO, o registo, a base de dados AD e todas as outras coisas que pretende. (Tenha em atenção que o malware também pode ser reintroduzido ao restaurar a partir de cópias de segurança do estado do sistema).
Aqui está uma demonstração que ilustra o risco de reinfecção com BMR:
Em alguns casos, poderá ser possível identificar e remover o malware após o restauro. Pessoalmente, não me sentiria confortável com essa abordagem e só a consideraria como último recurso (quando nenhuma outra opção de restauração estiver disponível). Não recomendo, de modo algum, que o seu plano de recuperação do AD seja concebido em torno desta opção.
Perda de dados
Se os DCs estiverem infectados quando os backups BMR forem efectuados - ou se suspeitar que possam ter sido - a abordagem tradicional é voltar a um backup anterior. Mas até que ponto se deve voltar atrás? O malware pode permanecer latente e não ser detectado durante semanas ou mesmo meses, pelo que poderá ter de recuar bastante.
Naturalmente, quanto mais recuarmos, mais dados perdemos. Pode fazer cópias de segurança diárias para um RPO (objectivo de ponto de recuperação) de 24 horas, mas se tiver de recuar 2 meses para obter uma boa cópia de segurança, está a perder esse SLA em grande escala. E dado o número de alterações de directório efectuadas todos os dias, a perda de dados é muito significativa.
Interrupções de serviço prolongadas
Cada minuto de tempo de inactividade custa dinheiro real à sua organização. No entanto, a BMR aumenta o tempo de recuperação de várias formas:
Configuração do hardware: O BMR foi concebido para a recuperação de hardware correspondente. A menos que tenha dinheiro para duplicar o hardware de reserva, precisará de pelo menos um ou dois dias para adquirir novo hardware. Só isto está fora do RTO (objectivo de tempo de recuperação) típico para infra-estruturas críticas (como o AD) e aplicações de nível 1. E se um ataque informático atingir muitas organizações e causar escassez de hardware, a aquisição pode demorar muito mais tempo. As soluções alternativas para restaurar para hardware alternativo (como a injecção de controladores) podem ser possíveis, mas demoram tempo e introduzem riscos adicionais.
Recuperação de cópias de segurança: Como eles contêm todo o sistema, os backups BMR são grandes. Eu sabia disso por experiência própria, mas queria quantificá-lo, então executei um teste simples em meu laboratório usando um DC "vanilla" do Windows Server 2016 com essencialmente um AD vazio (para determinar a sobrecarga associada a diferentes métodos de backup). Usei o Backup do Windows Server para fazer um backup BMR (bem como um backup do estado do sistema) e usei o Semperis AD Forest Recovery para fazer um backup Semperis (que extrai o AD do sistema operacional Windows subjacente). Aqui estão os resultados (não compactados):
Os backups maiores consomem mais armazenamento e largura de banda de rede e tendem a ocorrer com menos frequência (por exemplo, semanalmente ou após a terça-feira de patches). E durante a recuperação, demoram mais tempo a ser recuperadas (especialmente quando armazenadas na nuvem).
Selecção de cópias de segurança: Encontrar uma cópia de segurança BMR limpa é um processo iterativo (recuperar, montar, extrair, testar, repetir) que leva tempo quando cada minuto é caro.
Retrabalho: O restauro do AD a partir de uma cópia de segurança BMR mais antiga (e, espera-se, limpa) requer a recriação de alterações de directórios, a reconfiguração de aplicações, a junção de estações de trabalho, etc., e todo este trabalho exige um tempo considerável. - e todo esse retrabalho leva tempo e esforço consideráveis.
Recuperação falsa: A BMR acarreta um elevado grau de incerteza - os DCs foram infectados, quando foram infectados, até onde tenho de recuar? Poderá não descobrir que não recuou o suficiente até ter completado ou estar bem dentro do processo de recuperação do AD. A recuperação do AD não é uma tarefa simples, pelo que começar de novo é particularmente doloroso.
Conclusão
Os tempos mudam e os nossos planos de recuperação de desastres também. Os ataques cibernéticos são um perigo claro e presente que não pode ser ignorado. Embora a BMR possa abordar determinados cenários de recuperação, a recuperação de AD após um ciberataque não é um deles.
