Continuidad del negocio y recuperación ante desastres

La continuidad del negocio mantiene funciones esenciales durante una interrupción. La recuperación ante desastres restaura tecnología, datos y servicios después de un evento grave. Se coordinan, pero no son equivalentes. Restaurar un servidor no garantiza que el proceso de negocio pueda operar, y un procedimiento manual puede mantener una función aunque la tecnología siga indisponible.

Decisiones que deben tomarse antes del incidente

Un Business Impact Analysis (BIA) identifica procesos críticos, dependencias y consecuencias del tiempo de inactividad. De él se derivan objetivos como:

• RTO (Recovery Time Objective): tiempo objetivo para recuperar una capacidad.
• RPO (Recovery Point Objective): pérdida de datos máxima tolerable, expresada como un punto en el tiempo.
• MTPD/MAO: periodo máximo tolerable durante el que una actividad puede permanecer interrumpida.

Un RPO de cuatro horas exige poder recuperar datos con una antigüedad no superior a cuatro horas. No significa que la recuperación termine en cuatro horas, ya que ese segundo límite corresponde al RTO.

Elementos de un plan utilizable

1. criterios de activación y autoridad para declarar la contingencia
2. contactos, responsabilidades y canales alternativos
3. orden de recuperación basado en dependencias
4. copias, sistemas y ubicaciones alternativos
5. procedimientos técnicos y manuales
6. validación del servicio y retorno controlado a la normalidad
7. comunicación interna, externa, legal y regulatoria
8. mantenimiento del plan y registro de lecciones aprendidas.

Probar, no asumir

Las pruebas pueden progresar desde revisiones y ejercicios de mesa hasta restauraciones técnicas y conmutaciones completas. Deben verificar tiempos, integridad, capacidad, acceso a secretos, dependencias externas y decisiones humanas. El éxito de una copia de seguridad no demuestra que la restauración sea completa ni que cumpla el RTO.

Qué se puede validar sin interrumpir el servicio

Una revisión puede comprobar si producción y copias comparten el mismo punto de fallo, si las cuentas de recuperación dependen del entorno comprometido o si los procedimientos omiten servicios externos necesarios. También puede revisar evidencias de restauraciones y ejercicios anteriores.

Una conmutación real, la desconexión de sistemas o cualquier prueba que pueda afectar a producción exige autorización y salvaguardas específicas. El objetivo no es provocar el desastre, sino obtener evidencia suficiente de que la recuperación funcionará.

Preguntas de repaso

• ¿Qué diferencia práctica existe entre RTO y RPO?
• ¿Por qué una copia correcta no demuestra capacidad de recuperación?
• ¿Qué aporta un BIA antes de diseñar la solución técnica?

Referencias

• NIST SP 800-34 Rev. 1: Contingency Planning Guide
• NIST: Contingency Planning
• NIST SP 800-61 Rev. 3: Incident Response