Plano de Recuperação de Desastres (DRP)

1. Definição e Propósito Estratégico

O Plano de Recuperação de Desastres (DRP) é descrito como um processo vital e estratégico dentro das políticas internas de segurança e governança de TI. Ele consiste em um documento que lista as medidas e instruções detalhadas para evitar que falhas operacionais e desastres impactem negativamente a infraestrutura tecnológica de uma organização.

O DRP visa estabelecer um plano de ação emergencial para responder a eventos adversos, sejam eles desastres naturais (incêndios, enchentes, sismos) ou incidentes provocados (vandalismo, sabotagem, ataques cibernéticos como ransomware). O objetivo é reconstruir os serviços com o menor custo e impacto mínimo na disponibilidade, garantindo que a empresa continue operacional.

Diferente do BCP (Business Continuity Plan), mais amplo e orientado a processos de negócio, o DRP é focado especificamente na recuperação dos sistemas de TI e na infraestrutura tecnológica. O DRP é um subconjunto do BCP, conforme ISO 22301 e NIST SP 800-34.

2. Categorias de Desastres

3. Indicadores de Tolerância (RTO e RPO)

Para que o DRP seja eficaz, as políticas internas devem definir dois indicadores críticos:

RTO (Recovery Time Objective)

Determina o tempo máximo aceitável para retomar os processos de negócios após uma interrupção. É a janela de tempo entre o desastre e o retorno operacional.

• RTO curto (minutos/horas): sistemas críticos (e-commerce, call center, ERP financeiro). Exige alta disponibilidade, failover automático e DR site quente.
• RTO médio (4-24h): sistemas importantes (RH, CRM, e-mail).
• RTO longo (dias/semanas): sistemas não críticos (arquivo morto, relatórios mensais).

RPO (Recovery Point Objective)

Determina a quantidade aceitável de perda de dados medida em tempo (por exemplo, a janela do último backup válido antes do desastre).

• RPO = 0: nenhuma perda tolerada. Exige replicação síncrona.
• RPO baixo (minutos): replicação assíncrona frequente (ex.: CDP, snapshots de storage).
• RPO médio (horas): backups incrementais a cada hora.
• RPO alto (dias): backups diários/noturnos.

Tabela de Acordo Comercial

4. Análise de Impacto no Negócio (BIA)

O BIA (Business Impact Analysis) é o ponto de partida do DRP. Ele identifica sistemas e funções críticas, definindo quanto tempo a empresa sobrevive sem eles. Etapas do BIA:

1. Inventário de ativos: listar todos os sistemas, aplicações, dependências e dados.
2. Identificação de processos críticos: mapear quais processos de negócio dependem de cada sistema.
3. Avaliação de impacto financeiro e regulatório: calcular custo de downtime por hora (perda de receita, multas SLA, sanções LGPD/PCI).
4. Definição de criticidade: classificar sistemas em tiers (Tier 1 crítico → Tier 4 baixo).
5. Atribuição de RTO/RPO por sistema.
6. Mapeamento de dependências: um sistema pode parecer Tier 3 mas depender de banco Tier 1 (herda criticidade).

5. Estratégias de Recuperação

A. Sites de Recuperação (DR Sites)

B. Estratégias de Backup

Recomenda-se a regra 3-2-1:
- 3 cópias dos dados (1 produção + 2 backups).
- 2 mídias distintas (disk + tape, on-prem + cloud).
- 1 cópia off-site (em local fisicamente distante).

Tipos de backup:
- Full: cópia completa. Base para restauração.
- Incremental: copia mudanças desde o último backup (full ou incremental). Rápido, mas restore longo.
- Diferencial: copia mudanças desde o último full. Compromisso.
- Snapshot: ponto no tempo do storage (CoW, instantâneo).
- CDP (Continuous Data Protection): captura mudanças em tempo real byte-a-byte. RPO ≈ 0.

C. Replicação

• Síncrona: escrita confirmada em ambos os sites antes de ACK ao aplicativo. RPO = 0, mas adiciona latência.
• Assíncrona: escrita local confirmada, replicação posterior. RPO > 0, sem impacto de latência.
• Storage-based: array-to-array (EM SRDF, NetApp SnapMirror).
• Hypervisor-based: storage-agnostic (Zerto, VMware Site Recovery Manager).

6. Fases de Execução do Plano

As fontes dividem a ativação do DRP em três etapas fundamentais:

1. Gestão de Crise: O passo inicial para identificar e começar a resolver o problema. Inclui declaração formal de desastre, ativação da equipe de resposta, comunicação com stakeholders e acionamento de seguro.
2. Manutenção da Continuidade Operacional: Execução de rotinas para garantir as funções essenciais de serviço. Pode envolver ativação de DR site, failover manual/automático e operação em modo degradado.
3. Recuperação de Serviços: Foco nos itens afetados, como equipamentos falhos ou dados corrompidos, para restabelecer a normalidade. Inclui failback para o site primário, sincronização reversa e desativação do DR site.

Runbook de Resposta (Checklist Operacional)

1. Detecção & Declaração: monitoramento detecta falha (Nagios, Zabbix, Datadog), on-call valida gravidade, comitê de crise declara desastre formal (RTO clock inicia).
2. Comunicação: notificar equipe DR (pager, Slack), usuários (status page), clientes críticos e reguladores (se aplicável — LGPD art. 48).
3. Failover: promover réplica de banco ou ativar DR site, atualizar DNS para site de recuperação, validar serviços críticos (smoke tests).
4. Operação degradada: monitorar performance, coordenar hotfixes.
5. Failback (após resolução do primário): sincronizar deltas reversos, planejar janela, validar e cortar de volta.
6. Pós-morte: Root Cause Analysis (RCA) e atualização do DRP com lições aprendidas.

7. Ciclo de Planejamento e Manutenção

O DRP não é um documento estático, mas um processo de melhoria contínua que envolve:

• Análise de Impacto no Negócio (BIA): Identifica sistemas e funções críticas, definindo quanto tempo a empresa sobrevive sem eles.
• Testes e Simulações: Devem ser realizados ao menos duas vezes por ano para verificar a eficácia do plano e fazer ajustes necessários. Tipos de teste:
• Checklist/Tabletop: leitura do plano em sala, simulação discursiva.
• Simulação funcional: equipe executa procedimentos sem mover tráfego.
• Failover completo (full interruption): desligar produção e ativar DR — risco alto, validação máxima.
• Paralelo: DR roda em paralelo com produção sem cortar tráfego.
• Revisão Frequente: O plano deve ser atualizado para refletir mudanças tecnológicas (como a migração para a nuvem, que oferece redundância geográfica) e novos riscos de TI.

8. Integração com Políticas e Governança

No contexto mais amplo das políticas internas, o DRP está interligado a outros pilares:

• Plano de Continuidade de Negócios (BCP): O BCP é um conjunto de procedimentos que engloba a análise de riscos, planos de contingência operacional e o DRP. Definido na ISO 22301.
• Gestão de Incidentes: O DRP fornece os procedimentos para que a equipe de resposta possa agir sobre eventos que comprometam a Tríade CIA (Confidencialidade, Integridade e Disponibilidade).
• Conformidade e Responsabilidade: A existência de um DRP bem estruturado protege os profissionais e a empresa de serem responsabilizados por negligência ou imperícia em caso de sinistros. Normas como PCI-DSS, HIPAA, SOX e LGPD exigem DRP formal.

Frameworks e Normas de Referência

9. Desafios Modernos: Ransomware e DR Imutável

A explosão de ataques ransomware (LockBit, BlackCat, Cl0p) alterou o desenho do DRP moderno:

• Backups imutáveis (WORM): backups que não podem ser sobrescritos nem pelo admin, impedindo criptografia pelo atacante. Implementados em storage (Object Lock AWS S3, Object Versioning GCP) ou fita LTO.
• Air gap: cópias fisicamente desconectadas (fita off-line, vaulting) — atacante não alcança.
• Zero Trust para backups: isolar VLAN de backup, MFA para acesso a restores.
• DRP específico para ransomware: runbook dedicado, incluindo negociação/forense/quarentena.
• DR em cloud multi-região: AWS RDS multi-AZ, Azure Geo-Replication, GCP BigQuery cross-region.

10. Boas Práticas e Armadilhas

As fontes advertem que as empresas devem evitar a implementação de planos sem pessoal dedicado e recursos especializados, pois a falta de comprometimento com a manutenção e testes pode levar ao fracasso do investimento.

Boas Práticas

• Documentar procedimentos em formato de runbook acessível offline (em caso de queda total, software de documentação pode estar indisponível).
• Manter lista de contatos impressa e atualizada (telefones de fornecedores, clientes, reguladores).
• Crossover de conhecimento: nunca só uma pessoa sabe restaurar o sistema X.
• Orquestração automatizada de failover (Veeam, Zerto, VMware SRM) — reduz erro humano.
• Verify backups before restore — nunca confiar cegamente em backup nunca testado.
• Manter runbooks testados para cenários de ransomware (criptografia total).

Armadilhas Comuns

• DRP nunca testado: revisão anual no papel, sem nunca executar failover real.
• RTO/RPO irrealistas: definir RTO de 5 minutos para sistema sem infraestrutura de HA adequada.
• Dependência não mapeada: aplicativo depende de DNS/AD/CA fora do escopo do DR.
• Backup sem restore testado: backup aparentemente OK mas corrompido na hora do desastre.
• Credenciais no cofre que também caiu: sem acesso a senhas, restore é bloqueado.
• Licenças de software expiradas: DR site não consegue iniciar por licença inativa.

11. Resumo Técnico

12. Conclusão

O DRP é o amortecedor entre a organização e o caos tecnológico. Em uma era marcada por ransomware, falhas de cloud e ataques APT, a pergunta não é "se" um desastre vai acontecer, mas "quando". Um DRP maduro — ancorado em BIA rigoroso, RTO/RPO realistas, backups imutáveis, testes frequentes e orquestração automatizada — transforma o desastre em uma interrupção controlada. A adesão a frameworks (ISO 22301, NIST SP 800-34) e a integração com BCP, gestão de incidentes e conformidade regulatória garantem que o plano não seja apenas um documento de compliance, mas uma capacidade operacional real, validada por simulações e pronta para ser executada no momento crítico.