DR Disaster Recovery.

Onde a recuperação de desastres se situa dentro da continuidade

A recuperação de desastres é a sala de máquinas técnica da continuidade de negócio. A gestão da continuidade de negócio pergunta como a organização continua a entregar as suas atividades críticas durante uma disrupção, abrangendo pessoas, instalações, fornecedores e processos. A recuperação de desastres responde a uma pergunta mais restrita: como recolocamos a TI em funcionamento. Servidores, redes, aplicações, bases de dados e os próprios dados. Quando um centro de dados é inundado, uma estirpe de ransomware cifra a produção ou uma região de nuvem se apaga, o plano de recuperação é o documento e a memória muscular que repõem os sistemas em funcionamento numa ordem conhecida, até um ponto no tempo conhecido.

Essa distinção é importante porque os dois são frequentemente confundidos. Um plano de continuidade pode descrever soluções manuais que mantêm um serviço vivo enquanto a TI está fora de serviço. Um plano de recuperação não tem esse luxo. É julgado puramente pelo facto de os sistemas voltarem, com que rapidez e quantos dados foram perdidos. Tratar a recuperação como um subconjunto da continuidade e não como um sinónimo mantém o âmbito honesto e impede que as equipas presumam que um servidor recuperado significa um serviço de negócio recuperado.

RTO, RPO e o runbook

Dois números governam cada decisão de recuperação. O objetivo de tempo de recuperação (RTO) é o tempo máximo tolerável que um sistema pode estar indisponível antes de o impacto se tornar inaceitável. O objetivo de ponto de recuperação (RPO) é a quantidade máxima tolerável de perda de dados, expressa como uma janela de tempo, o que na prática dita com que frequência replica ou faz cópias de segurança. Um RTO de quatro horas com um RPO de quinze minutos é uma arquitetura muito diferente, e um orçamento muito diferente, de um RTO para o dia útil seguinte com uma cópia de segurança diária. Estes objetivos devem provir de uma análise de impacto no negócio, e não do nível de conforto da equipa de infraestrutura.

• O RTO determina a arquitetura de recuperação: redundância a quente e replicação para alvos apertados, restauro a partir de cópia de segurança para os mais flexíveis.
• O RPO determina a estratégia de proteção de dados: replicação síncrona, instantâneos ou cópias de segurança periódicas.
• O runbook transforma esses objetivos num procedimento de recuperação testado, passo a passo, que alguém sob pressão consegue efetivamente seguir.

Normas, ameaças e prática atual

O panorama normativo mudou. A ISO/IEC 24762 deu outrora orientação dedicada sobre serviços de recuperação de desastres das TIC, mas foi retirada, e a prática atual remete de novo para a ISO 22301 quanto ao sistema de gestão da continuidade de negócio, com a ISO/IEC 27031 a cobrir a preparação das TIC para a continuidade de negócio. Nesse modelo, a recuperação não é uma disciplina autónoma; é a camada operacional que concretiza a estratégia de continuidade, governada pelo mesmo sistema de gestão e pelo mesmo apetite ao risco. Os setores regulados acrescentam a sua própria pressão: o regime de resiliência do setor financeiro da UE, por exemplo, espera que as empresas demonstrem que a recuperação e a continuidade das funções críticas são testadas, e não meramente documentadas.

A recuperação moderna é também moldada pelas ameaças que tem de absorver. O ransomware em particular reescreveu o guião, porque, se as suas cópias de segurança forem acessíveis e graváveis a partir do ambiente de produção, um atacante cifra-as também. Os profissionais privilegiam agora cópias de segurança imutáveis e isoladas, ambientes de recuperação segmentados e reconstruções em sala limpa para que o restauro não reinfete simplesmente.

A nuvem e a infraestrutura como código tornaram algumas recuperações mais rápidas de automatizar, mas introduzem os seus próprios pontos únicos de falha nas camadas de região, conta e identidade. A disciplina é a mesma de sempre: conheça os seus objetivos, proteja os seus dados para que sobrevivam ao desastre, escreva um runbook que alguém consiga seguir e prove que funciona antes de precisar dele.