9.5 Recuperação de desastres e continuidade de negócio

Visão geral e motivação

Mais cedo ou mais tarde, algo que vocês não planejaram vai derrubar um sistema: uma interrupção de nuvem que atinge uma região inteira, um DROP TABLE digitado com dedos desastrados, uma inundação num data center, a detonação de um ransomware ou um fornecedor que some da noite para o dia. A pergunta nunca é se a interrupção chega, e sim quão depressa vocês se recuperam e quanto perdem no processo. Este capítulo trata de estar pronto para o dia ruim antes de ele chegar.

Duas disciplinas respondem a essa prontidão, e não são a mesma coisa. O planejamento de continuidade de negócio (BCP) mantém a organização inteira funcionando durante uma interrupção: pessoas, escritórios, comunicações, folha de pagamento e os processos de negócio críticos de que os clientes dependem. A recuperação de desastres (DR) é o trabalho técnico, mais estreito, de restaurar os sistemas de TI e os dados depois que falham. A continuidade é o objetivo; a recuperação é um dos meios. Vocês podem restaurar todos os servidores e ainda assim falhar com os clientes se ninguém sabia quem podia declarar um desastre ou como alcançá-los. Este capítulo trata a DR como prática de engenharia e o BCP como o enquadramento de negócio a que ela serve.

Para grandes equipes, as apostas escalam com vocês. Uma empresa carrega obrigações regulatórias de recuperação, pegadas multirregião e risco de concentração em um punhado de fornecedores. O governo carrega o dever legal de sustentar funções essenciais para os cidadãos, codificado como continuidade de operações. Ambos operam sob um escrutínio em que um plano não testado é um passivo que vocês descobrirão no pior momento possível. A recuperação é onde a confiabilidade (capítulo 9.1) e a resposta a incidentes (capítulo 9.3) encontram a pergunta mais difícil de sobreviver às falhas que não se consegue eliminar por projeto.

Princípios fundamentais

A continuidade é mais ampla que a recuperação. Restaurar servidores não é o mesmo que manter o negócio funcionando.
Dois números conduzem tudo. O objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO), definidos a partir do impacto no negócio, dimensionam cada decisão.
Um backup não testado não é um backup. Uma restauração que vocês nunca fizeram é uma esperança, não uma capacidade.
Presumam que o backup é um alvo. O ransomware caça primeiro os seus backups, então mantenham as cópias imutáveis e offline.
Reconstruam a partir de código, não da memória. Se vocês não conseguem recriar a infraestrutura a partir do código-fonte, não conseguem recuperá-la de modo confiável.
Mapeiem do que vocês dependem. Vocês só se recuperam tão depressa quanto a sua dependência a montante mais lenta.
Meçam a recuperação como qualquer outro sistema. RTO e RPO reais de exercícios de verdade, não os números que vocês escreveram num slide.

Recomendações

Defina o RTO e o RPO a partir de uma análise de impacto no negócio

Toda decisão de recuperação desce de dois números, então acertem-nos primeiro. O objetivo de tempo de recuperação (RTO) é por quanto tempo um sistema pode ficar fora do ar antes que o dano se torne inaceitável. O objetivo de ponto de recuperação (RPO) é quantos dados vocês podem se dar ao luxo de perder, medido como a idade da última cópia boa para a qual vocês conseguem restaurar. Um livro-razão de pagamentos pode exigir um RTO de minutos e um RPO próximo de zero; um painel interno de análises pode tolerar um dia de cada. Vocês não conseguem defini-los na engenharia. Derivem-nos de uma análise de impacto no negócio (BIA) que classifica os processos de negócio pelo custo de sua interrupção e rastreia cada um até os sistemas e dados de que precisa. Objetivos mais apertados custam mais, então a BIA é o que impede vocês de dourar um serviço trivial e proteger de menos um crítico.

Faça os backups direito: a regra 3-2-1, a imutabilidade e os testes

Os backups são o piso sob toda estratégia de recuperação, e a maioria das organizações os faz pior do que pensa. Sigam a disciplina de backup conhecida como a regra 3-2-1: mantenham pelo menos três cópias dos dados, em duas mídias ou sistemas diferentes, com uma cópia fora do local. As ameaças modernas acrescentam mais duas exigências. Mantenham pelo menos uma cópia imutável (de gravação única, impossível de apagar durante uma janela de retenção) e, idealmente, offline ou isolada por ar (air-gapped), porque o ransomware hoje criptografa ou apaga deliberadamente os backups alcançáveis antes de se anunciar. Acima de tudo, testem as restaurações numa agenda. Um backup não testado não é um backup, é uma suposição não testada, e as falhas que vocês acham num exercício (arquivos corrompidos, chaves de criptografia ausentes, backups do volume errado) são exatamente as que teriam acabado com vocês num evento real.

Escolha uma estratégia de DR ao longo do espectro de custo versus velocidade

As estratégias de DR trocam dinheiro por velocidade de recuperação, e vocês devem escolher por sistema com base no seu RTO e RPO em vez de comprar um nível único para tudo. Quatro padrões ancoram o espectro. O backup e restauração é o mais barato e o mais lento: vocês reconstroem a partir dos backups quando o desastre ocorre, com um RTO de horas a dias. A luz piloto (pilot light) mantém um núcleo mínimo (bancos de dados replicando, configuração central no lugar) aquecido mas reduzido, pronto para expandir. O standby morno (warm standby) roda uma cópia menor, sempre ligada, da pilha completa, que vocês escalam no failover, cortando o RTO para minutos. O multissite ativo-ativo roda capacidade plena em dois ou mais locais atendendo tráfego ao vivo, dando um RTO próximo de zero ao custo e à complexidade mais altos. Ajustem o nível ao número que o negócio aprovou e não paguem preço de ativo-ativo por um sistema que tolera uma luz piloto.

Replique os dados tendo em mente o compromisso de consistência

A velocidade da recuperação depende de quão atuais estão os seus dados em standby, e aqui vocês herdam os problemas difíceis dos sistemas distribuídos (capítulo 3.3). A replicação síncrona confirma cada escrita num segundo local antes de reconhecê-la, dando um RPO próximo de zero ao custo de latência de escrita adicional e de um limite rígido de distância. A replicação assíncrona reconhece localmente e envia as mudanças depois, de modo que é rápida e geograficamente flexível mas deixa uma janela de defasagem de replicação que vocês perderão no failover. Não há escolha grátis: consistência mais forte custa latência, consistência mais fraca custa dados. Decidam por repositório de dados a partir do seu RPO e conheçam a defasagem típica de replicação, porque essa defasagem é o seu RPO real num dia ruim, não o número no documento de projeto.

Reconstrua a partir de código com infraestrutura como código

Vocês não conseguem recuperar de modo confiável um ambiente que provisionaram à mão, porque ninguém lembra cada clique. Definam os ambientes como infraestrutura como código (capítulo 8.2) para que uma pilha inteira possa ser recriada a partir de código-fonte versionado num estado sabidamente bom. Isso transforma a recuperação de um projeto de arqueologia numa execução repetível de pipeline, mantém honesta a sua região em standby (ela deriva menos quando ambas são construídas do mesmo código) e dá um jeito limpo de montar infraestrutura de recuperação numa conta ou região nova depois de um comprometimento. Guardem o código, as referências a segredos e os runbooks num lugar que sobreviva à perda do ambiente primário.

Mapeie as dependências antes de precisar delas

Os sistemas falham em teias, não isoladamente, e a recuperação empaca na dependência que vocês esqueceram. Mapeiem do que cada sistema crítico precisa para funcionar: serviços a montante, DNS, identidade e autenticação, autoridades certificadoras, filas de mensagens e APIs e provedores SaaS de terceiros. Anotem a ordem de recuperação, porque subir uma aplicação antes do banco de dados ou do provedor de identidade só produz uma segunda interrupção. Prestem atenção especial aos fornecedores externos, já que a sua recuperação é limitada pela deles e vocês podem não ter visibilidade sobre ela. Esse mapeamento se liga diretamente à resiliência e à degradação graciosa (capítulo 3.5): quanto menos dependências rígidas um sistema tem, mais depressa ele volta.

Teste a recuperação como prática, não como evento

Um plano de DR que vocês não exercitaram é ficção. Construam uma escada de testes. Um exercício de mesa (tabletop) percorre com a equipe um cenário no papel para achar lacunas em papéis, decisões e comunicação. Um game day injeta uma falha controlada real num ambiente semelhante ao de produção. Um exercício completo de failover de fato corta para o site de recuperação e roda nele. Rodem esses testes numa cadência, façam rodízio dos cenários (incluindo a perda de uma pessoa-chave ou de um fornecedor) e meçam o resultado: capturem o RTO e o RPO reais que vocês alcançaram e comparem com a meta. A diferença entre a recuperação medida e a prometida é a métrica de confiabilidade mais honesta que vocês têm, e fechá-la é todo o ponto do exercício.

Planeje a recuperação cibernética como um cenário próprio

O ransomware e os ataques cibernéticos destrutivos quebram as suposições da DR comum, então tratem-nos separadamente. Num desastre natural, os seus dados estão intactos em outro lugar; num evento de ransomware, os seus dados e muitas vezes os seus backups são a arma, e o seu ambiente de recuperação pode ele mesmo estar comprometido. Planejem uma recuperação em sala limpa (clean-room): um ambiente isolado e confiável onde vocês restauram a partir de cópias imutáveis, varrem em busca da intrusão e reconstroem identidade e credenciais antes de reconectar qualquer coisa. Saibam qual backup é o seu último ponto sabidamente limpo e esperem que achá-lo leve tempo forense que o seu RTO comum nunca orçou. É aqui que as cópias imutáveis e offline pagam o seu custo, e isso se liga estreitamente à gestão de incidentes (capítulo 9.3) e às obrigações de conformidade e governança para o tratamento de violações (capítulo 4.6).

Compromissos: prós e contras

Estratégia de DR	Prós	Contras
Backup e restauração	Mais barata. Simples. Baixo custo contínuo	RTO lento (horas a dias). RPO maior
Luz piloto	Baixo custo. Dados centrais aquecidos e prontos	Escala manual. A recuperação ainda leva tempo real
Standby morno	RTO rápido (minutos). Pilha completa comprovada	Custo contínuo de um segundo ambiente em execução
Multissite ativo-ativo	RTO próximo de zero. Sem falha de site único	Custo e complexidade mais altos. A consistência é difícil
Replicação síncrona	RPO próximo de zero	Latência de escrita. Limitada por distância. Acoplamento mais forte
Replicação assíncrona	Rápida, flexível, livre geograficamente	Janela de perda de dados igual à defasagem de replicação

A tensão central é que a velocidade de recuperação e a atualidade dos dados custam, ambas, dinheiro e complexidade, e nenhuma é grátis em nível algum. Resolvam por sistema e não por organização: deixem a análise de impacto no negócio atribuir a cada sistema crítico um RTO e um RPO e comprem exatamente a estratégia que os atende. Gastar dinheiro de ativo-ativo numa ferramenta de relatórios deixa à míngua o livro-razão que precisava dele, e o inverso é negligência. A disciplina é ajustar o gasto ao número de que o negócio é dono e revisitar esse ajuste conforme os sistemas mudam de importância.

Perguntas para discutir com sua equipe

Quais são o RTO e o RPO de cada um dos seus sistemas críticos, e quem no negócio os aprovou? Se a engenharia inventou esses números sozinha, são chutes, e chutes são financiados ou de forma generosa demais ou de forma nenhuma. Os objetivos de tempo e de ponto de recuperação devem sair de uma análise de impacto no negócio que classifica os processos pelo custo da interrupção, de modo que o livro-razão tenha minutos e a wiki interna tenha um dia. Levem a classificação em níveis atual e perguntem se a pessoa responsável por cada processo de negócio de fato aceitaria a perda de dados e a indisponibilidade que vocês projetaram. Numa grande organização, essa conversa é o que previne o erro caro de proteger tudo por igual, o que não protege nada bem. Se ninguém fora da engenharia sabe nomear os números, vocês ainda não têm objetivos, têm esperanças.
Quando vocês fizeram pela última vez uma restauração real, e mediram o RTO e o RPO reais que alcançaram? Um backup que vocês nunca restauraram é uma suposição não testada, e os modos de falha que matam vocês (arquivos corrompidos, chaves de criptografia perdidas, um instantâneo do volume errado, uma dependência que não sobe) só aparecem quando se tenta. Levem a data e o resultado do último exercício completo de failover, não do último exercício de mesa, e a diferença entre a recuperação alcançada e a prometida. Para uma grande equipe, uma restauração bem-sucedida de um sistema não prova os outros, então perguntem que fração dos sistemas críticos foi recuperada de ponta a ponta no último ano. A diferença medida é o seu número de confiabilidade mais honesto, e se vocês não conseguem declará-lo, o plano é ficção até prova em contrário.
Se um ransomware criptografasse a sua produção e alcançasse os seus backups esta noite, qual é a sua última cópia sabidamente limpa e onde vocês reconstruiriam? A recuperação de desastres comum presume que os seus dados estão seguros em algum outro lugar, e um ataque cibernético destrutivo quebra exatamente essa suposição ao fazer dos seus dados e backups a arma. Perguntem se pelo menos uma cópia de backup é imutável e offline, como vocês identificariam o último ponto limpo de restauração e de onde viria um ambiente confiável de sala limpa quando a própria produção está comprometida. Esse cenário exige tempo forense que o seu RTO normal nunca orçou, então levem uma estimativa honesta de quanto tempo achar um ponto limpo de fato leva. Para equipes corporativas e governamentais, isso é também um evento de conformidade (capítulo 4.6), com os relógios de notificação de violação correndo em paralelo. Se a resposta é “restauraríamos o backup mais recente”, vocês não planejaram isso de modo algum.
Qual dos seus sistemas está pagando por um nível de recuperação que a análise de impacto no negócio não justifica, e qual está perigosamente subprotegido? A velocidade de recuperação e a atualidade dos dados custam dinheiro em todo nível, então uma política uniforme ou desperdiça o orçamento de ativo-ativo numa ferramenta de relatórios ou deixa à míngua o livro-razão que genuinamente precisava. A atração contrária é real: um único nível padrão é muito mais simples de operar para muitas equipes, enquanto classificar por sistema ajusta o gasto ao valor mas exige curadoria contínua conforme a importância de um sistema muda. Levem a estratégia atual de DR de cada sistema crítico, o RTO e o RPO que ela mira, o custo mensal de seu standby e de sua replicação e a data em que a classificação em níveis foi revisitada pela última vez contra uma análise de impacto nova. Num contexto corporativo ou governamental, um nível desajustado se multiplica entre regiões e a auditoria pedirá que vocês justifiquem tanto o dinheiro que gastam quanto a exposição que aceitam, de modo que uma conta inexplicada de ativo-ativo e um serviço crítico desprotegido são igualmente difíceis de defender.
Vocês de fato conhecem a ordem de recuperação dos seus sistemas críticos e o quanto a recuperação depende de fornecedores que vocês não conseguem testar? Os sistemas falham em teias, não isoladamente, e uma recuperação empaca na dependência que ninguém mapeou: subam uma aplicação antes do banco de dados, do provedor de identidade ou do DNS e vocês simplesmente produzem uma segunda interrupção. Mapear dependências é tedioso e o mapa fica obsoleto, mas a alternativa é descobrir a ordem de recuperação ao vivo durante um failover, e o risco de concentração em um punhado de provedores SaaS permanece invisível até eles falharem juntos e limitarem a sua recuperação à deles. Levem um mapa atual de dependências, a sequência documentada de recuperação e uma lista de fornecedores externos com seus compromissos declarados de recuperação e se vocês alguma vez validaram algum deles. Para uma organização grande ou pública, a continuidade de fornecedores e o risco de concentração são cada vez mais uma preocupação de contratação e regulatória, então essas obrigações de recuperação pertencem ao contrato numa forma que vocês possam auditar e não ao marketing de um fornecedor.
Se vocês restaurassem todos os servidores esta noite, o negócio de fato continuaria funcionando, e quem tem autorização para declarar um desastre? A recuperação de desastres restaura a TI, mas a continuidade de negócio mantém a organização funcionando: pessoas, comunicações, folha de pagamento e as decisões que dependem de alguém ter a autoridade de tomá-las. Vocês podem recuperar todos os sistemas e ainda falhar com os clientes se ninguém sabia quem podia declarar um desastre ou como alcançar a equipe quando os canais normais também estão fora do ar. A engenharia é dona da recuperação, mas a continuidade abrange instalações, RH, comunicações e sucessão da liderança, e essas costuras entre departamentos são exatamente onde um plano apodrece em silêncio. Levem a autoridade de declaração e a cadeia de escalonamento, o plano alternativo de comunicação, os sucessores nomeados e as instalações alternativas e a data em que o lado do negócio (não só a TI) exercitou o plano pela última vez. O governo carrega um dever legal de continuidade de operações, com sucessores nomeados e funções essenciais, e as empresas enfrentam obrigações regulatórias de continuidade, então ambos são julgados por se o negócio sobrevive ao dia ruim, não meramente os servidores.

Perspectiva por setor

Startup. Com uma equipe minúscula e pouco fôlego, vocês não podem bancar uma segunda região quente, então sejam deliberados com as partes baratas que ainda salvam vocês. Definam um nível honesto de recuperação, sigam a regra 3-2-1 com instantâneos automatizados e pelo menos uma cópia imutável que os seus próprios administradores não consigam apagar e mantenham todo o ambiente como infraestrutura como código para poder reconstruir a partir do código-fonte. Pulem o plano elaborado e rodem, em vez disso, uma restauração real num ambiente provisório a cada trimestre, porque um único exercício cronometrado ensina mais que um fichário que ninguém lê.

Pequena empresa. Sem especialista dedicado em continuidade e com orçamento apertado, tratem a recuperação como algo que se compra e não que se constrói. Apoiem-se no backup gerenciado, nos instantâneos e na replicação entre regiões do seu provedor de nuvem em vez de montar infraestrutura de DR sob medida e escolham fornecedores cujos backups sejam imutáveis e cujo processo de restauração vocês mesmos consigam rodar. Enquadrem todo o exercício em duas perguntas que vocês conseguem responder sem um especialista: quantos dados podemos perder e por quanto tempo podemos ficar fora do ar, e provem que uma restauração funciona antes de confiar nela.

Grande empresa. Em escala o problema é a governança de portfólio entre muitas equipes: uma análise de impacto no negócio que atribui a todo serviço um RTO e um RPO, estratégias de recuperação classificadas em níveis do backup e restauração ao ativo-ativo e uma visão central das dependências a montante e dos fornecedores, incluindo o risco de concentração. Orcem explicitamente o standby, a replicação e o custo das cópias imutáveis, rodem failovers completos acompanhados por reguladores numa cadência e meçam a recuperação real contra a meta como uma métrica de confiabilidade acompanhada. Mantenham a recuperação cibernética como um programa próprio, com cópias imutáveis em cofre e um runbook de sala limpa, testado de forma independente dos exercícios de desastre natural.

Governo. As regras de contratação, a transparência e a prestação de contas públicas moldam toda escolha, e a continuidade costuma ser um dever legal e não uma preferência. Construam um programa de continuidade de operações que identifique as funções essenciais, ordene sua recuperação e nomeie sucessores e instalações alternativas para que as decisões nunca empaquem por falta de uma pessoa autorizada, e alinhem-no a orientações reconhecidas como a NIST SP 800-34 em apoio às obrigações do FISMA. Mantenham cópias de backup isoladas por ar, definam a infraestrutura como código para reconstruir numa região alternativa e rodem um exercício completo anual mais simulações de mesa de ransomware cujos resultados medidos vocês reportam aos órgãos de supervisão como evidência de que os serviços essenciais sobrevivem.

Exemplos

Startup. Uma empresa de SaaS de doze pessoas não pode bancar uma segunda região quente, então é deliberada com as partes baratas. Define um nível honesto: RTO de quatro horas, RPO de quinze minutos para o banco de dados dos clientes. Segue a regra 3-2-1 com instantâneos automatizados, uma cópia replicada para uma segunda região de nuvem e uma cópia imutável com uma janela de retenção travada que seus próprios administradores não conseguem apagar. Todo o ambiente é infraestrutura como código (capítulo 8.2), de modo que pode montar uma pilha nova a partir do código-fonte. Uma vez por trimestre roda uma restauração real num ambiente provisório numa tarde de sexta-feira, cronometra e arquiva uma nota curta. O primeiro exercício levou nove horas e achou um passo de migração ausente; a correção é o motivo de o seguinte ter levado três.

Grande empresa. Um banco multinacional opera sob exigências regulatórias de recuperação que impõem uma continuidade testada para os serviços críticos. Roda um standby morno em uma segunda região para a sua plataforma bancária central, com replicação síncrona dentro de um par metropolitano para um RPO próximo de zero e replicação assíncrona para uma região distante para sobreviver a um desastre regional. Uma análise de impacto no negócio atribui a cada serviço um RTO e um RPO, e uma equipe central mapeia as dependências a montante, incluindo dois provedores SaaS sinalizados como risco de concentração. Duas vezes por ano faz um failover completo acompanhado por reguladores, mede o real contra a meta e alimenta as lacunas no ciclo seguinte. Um programa separado de recuperação cibernética mantém cópias imutáveis em cofre e um runbook de sala limpa, testado de forma independente dos exercícios de desastre natural.

Governo. Uma agência nacional que entrega benefícios mantém um programa de continuidade de operações (COOP) construído para sustentar suas funções essenciais durante qualquer interrupção. Seguindo a prática de continuidade de operações e a orientação de planejamento de contingência NIST SP 800-34 que apoia suas obrigações do FISMA, identifica as funções essenciais, ordena sua recuperação e nomeia sucessores e instalações alternativas para que as decisões nunca empaquem por falta de uma pessoa autorizada. Os sistemas voltados ao cidadão carregam RTO e RPO documentados, os backups seguem a regra 3-2-1 com cópias isoladas por ar e a infraestrutura é definida como código para reconstrução numa região alternativa. Um exercício completo anual, mais simulações de mesa de um cenário de ransomware, testa o plano contra a recuperação medida, e os resultados são reportados aos órgãos de supervisão como evidência de que os serviços essenciais sobrevivem ao dia ruim.

Justificativa de negócio: motivações, ROI e TCO

O retorno da DR e da continuidade é a catástrofe evitada, que é genuinamente difícil de valorar até precisar dela e dolorosamente concreta quando se precisa. Enquadrem como gestão de risco: o custo esperado de uma interrupção é sua probabilidade vezes seu impacto, e o impacto para uma grande organização vai da receita perdida por hora de indisponibilidade até as penalidades regulatórias, os custos de notificação de violação e o dano à reputação que sobrevive à interrupção. Um único evento irrecuperável de ransomware acabou com empresas e, no setor público, tirou do ar por semanas serviços essenciais aos cidadãos. Diante disso, o custo de uma capacidade de recuperação testada é modesto e conhecível.

O custo total de propriedade (TCO) é real e contínuo: infraestrutura de standby, largura de banda de replicação, armazenamento de backup (multiplicado pelas cópias imutáveis e offline) e o tempo de engenharia para construir automação e rodar exercícios. É exatamente por isso que se classifica por RTO e RPO em vez de comprar ativo-ativo em toda parte, para que o gasto acompanhe o valor de cada sistema e não uma política uniforme. Para defender o caso junto à liderança, traduzam o plano para a linguagem dela: eis a indisponibilidade e a perda de dados que podemos sobreviver hoje, eis a diferença para as nossas metas, eis o que fechá-la custa e eis a exposição se não o fizermos. O artefato mais persuasivo é um exercício medido, porque uma recuperação que vocês demonstraram é um número em que a liderança pode confiar, e um plano não testado é um passivo disfarçado de ativo.

Antipadrões e armadilhas

Backups não testados. Uma restauração que vocês nunca fizeram é uma esperança. O exercício é onde vocês acham a corrupção, a chave ausente e o volume errado.
Backups alcançáveis a partir da produção. Se o ransomware consegue criptografar ou apagar os seus backups, vocês têm uma cópia, não três. Mantenham uma imutável e offline.
Um só RTO e RPO para tudo. Níveis uniformes protegem demais o trivial e de menos o crítico. Classifiquem a partir de uma análise de impacto no negócio.
Confundir DR com BCP. Restaurar todos os servidores enquanto ninguém sabe quem declara um desastre ou como alcançar a equipe é um sistema recuperado e um negócio fracassado.
Ambientes de recuperação montados à mão. A infraestrutura que vocês não conseguem reconstruir a partir de código deriva, e a deriva é descoberta no meio do failover.
Dependências ignoradas. Recuperar uma aplicação antes do banco de dados, do provedor de identidade ou do DNS só produz uma segunda interrupção.
Podridão do plano. Um fichário escrito uma vez e nunca exercitado descreve um sistema que não existe mais.
Pontos cegos de fornecedores. A sua recuperação é limitada pela recuperação dos seus fornecedores críticos, e o risco de concentração é invisível até eles falharem juntos.

Modelo de maturidade

Nível 1, Iniciar: A recuperação é ad hoc e reativa. Os backups podem rodar, mas as restaurações não são testadas. Não há RTO ou RPO combinado, nem análise de impacto no negócio, e a recuperação é improvisada durante o incidente. Uma perda séria de dados ou um evento de ransomware provavelmente seria irrecuperável.
Nível 2, Desenvolver: Existem práticas básicas, mas inconsistentes entre as equipes. Alguns sistemas críticos têm backups que seguem a regra 3-2-1 e RTO e RPO documentados para os serviços mais importantes, e existe um plano básico de DR com restaurações testadas ocasionalmente. A cobertura é parcial, as dependências não são mapeadas, os exercícios são ad hoc e a disciplina de uma equipe não implica a da seguinte.
Nível 3, Padronizar: A prática de recuperação é documentada e imposta em toda a organização. Uma análise de impacto no negócio conduz RTO e RPO classificados em níveis entre os sistemas, as estratégias de recuperação são ajustadas a esses níveis, os ambientes são infraestrutura como código, as dependências e a ordem de recuperação são mapeadas e exercícios agendados (de mesa, game day e failover) rodam numa cadência definida. Um plano de recuperação cibernética com cópias imutáveis e offline é documentado e aplicado de modo consistente e não deixado a cada equipe.
Nível 4, Gerenciar: A recuperação é medida e controlada em relação a linhas de base. Cada exercício captura o RTO e o RPO reais alcançados e acompanha a diferença para a meta, e métricas como a taxa de sucesso das restaurações, a fração dos sistemas críticos recuperados de ponta a ponta no último ano, a cobertura e a imutabilidade dos backups e a defasagem de replicação monitorada como o RPO real são reportadas em painéis. Os desvios disparam ação, a classificação em níveis é rederivada de dados sobre como os sistemas são de fato usados e as decisões de ir ou não ir repousam em evidências e não nos números escritos num slide.
Nível 5, Orquestrar: A recuperação é continuamente melhorada, integrada em toda a organização e adaptativa. O failover e as restaurações em sala limpa da recuperação cibernética são ensaiados como rotina, o risco de fornecedores e de concentração é ativamente gerenciado e a continuidade é integrada à confiabilidade (capítulo 9.1) e à resposta a incidentes (capítulo 9.3), de modo que a organização se recupera de modo previsível de falhas que nunca viu e redefine sua postura de recuperação conforme o panorama de sistemas e o quadro de ameaças mudam.

Ideias para discussão

Qual dos seus sistemas críticos nunca foi restaurado de ponta a ponta, e o que seria preciso para provar que pode ser?
Se vocês perdessem a região primária de nuvem por um dia inteiro, quais processos de negócio param, e em que ordem vocês trariam os sistemas de volta?
Quanto da sua recuperação depende de fornecedores cuja própria recuperação vocês não conseguem ver nem testar?
Onde vocês estão pagando por um nível de recuperação que a análise de impacto no negócio não justifica, e onde estão protegendo de menos?
Se os seus backups estivessem alcançáveis e criptografados esta noite, qual é o seu genuíno último ponto limpo de restauração?
Qual é a diferença honesta entre o RTO e o RPO prometidos e os que o seu último exercício de fato alcançou?

Principais conclusões

A continuidade é o objetivo. A recuperação é um meio. O planejamento de continuidade de negócio mantém a organização funcionando. A recuperação de desastres restaura os sistemas de TI de que ela depende.
RTO e RPO conduzem tudo, e ambos vêm de uma análise de impacto no negócio, não de chute da engenharia. Classifiquem os sistemas em níveis em vez de protegê-los todos por igual.
Um backup não testado não é um backup. Sigam a regra 3-2-1, mantenham pelo menos uma cópia imutável e offline contra o ransomware e testem as restaurações numa agenda.
Ajustem a estratégia de DR ao número: backup e restauração, luz piloto, standby morno ou ativo-ativo, escolhida pelo RTO e RPO de cada sistema.
A replicação troca consistência por atualidade (capítulo 3.3). O seu RPO real é a sua defasagem de replicação, não o seu documento de projeto.
Reconstruam a partir de código com infraestrutura como código (capítulo 8.2) e mapeiem as dependências antes de precisar delas.
Testem com exercícios de mesa, game days e exercícios completos de failover e meçam o RTO e o RPO reais contra a meta.
Planejem a recuperação cibernética separadamente, com restauração em sala limpa, e liguem toda a prática à confiabilidade (capítulo 9.1), à resposta a incidentes (capítulo 9.3) e à conformidade (capítulo 4.6).

Referências e leitura complementar

ISO 22301, Security and resilience: Business continuity management systems: Requirements (the international standard for BCP).
National Institute of Standards and Technology, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (RTO, RPO, and recovery strategies for government systems).
National Institute of Standards and Technology, SP 800-61 Rev. 2: Computer Security Incident Handling Guide (incident and cyber-recovery handling).
U.S. Federal Emergency Management Agency, Continuity Guidance Circular and federal COOP guidance (essential functions and continuity of operations).
Federal Financial Institutions Examination Council (FFIEC), Business Continuity Management booklet (regulatory recovery expectations for financial institutions).
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds., Site Reliability Engineering: How Google Runs Production Systems (reliability and disaster testing).
Kelly Shortridge and Aaron Rinehart, Security Chaos Engineering (deliberately exercising failure and recovery).
Cybersecurity and Infrastructure Security Agency (CISA), #StopRansomware Guide (ransomware prevention and recovery practice).