Pruebas de conmutación por error: ejercicios teóricos y simulacros de recuperación ante desastres

Un plan de recuperación ante desastres que nunca se ha probado es solo un documento: proporciona una falsa sensación de confianza sin garantías reales. Entre los fallos habituales que se descubren durante desastres reales, pero no en planes sin probar, se incluyen: listas de contactos desactualizadas (el personal clave ha cambiado de puesto o se ha marchado), restauraciones de copias de seguridad que fallan debido a incompatibilidades entre versiones de software, sistemas que tardan 4 horas en restaurarse cuando el plan suponía 30 minutos y lagunas en la autoridad para tomar decisiones, en las que nadie sabe quién está autorizado para declarar un desastre. Las pruebas revelan estos fallos en un entorno controlado en lugar de hacerlo durante una crisis.

Las pruebas de DR y BCP abarcan un espectro de complejidad y realismo crecientes. La revisión documental —verificar que los planes estén actualizados y completos— es el nivel mínimo de referencia. Los ejercicios de simulación consisten en debatir sin activar ningún sistema. Los simulacros guiados hacen que los participantes repasen verbalmente los procedimientos. Los ejercicios funcionales activan componentes específicos (árboles de llamadas, conmutaciones por error parciales del sistema). Las pruebas a escala completa implican cambiar realmente a la infraestructura de DR y ejecutar el negocio desde el sitio alternativo. Cada nivel proporciona mayor confianza, pero con un coste y una interrupción mayores.

Un ejercicio de simulación reúne a las partes interesadas clave para repasar verbalmente un escenario hipotético de desastre, sin activar ningún sistema real. Un facilitador presenta el escenario: «Es lunes por la mañana y recibe una alerta que indica que el ransomware ha cifrado el servidor de base de datos principal y se está propagando por la red. ¿Qué hace?». Los participantes responden en tiempo real, lo que permite revelar deficiencias en la autoridad para tomar decisiones, los protocolos de comunicación y el conocimiento de los procedimientos de recuperación, todo ello sin ninguna interrupción operativa.

Los ejercicios funcionales prueban componentes específicos del plan de DR sin una activación completa. Algunos ejemplos son: prueba del árbol de llamadas (llamar realmente a todos los contactos de emergencia a las 2 de la madrugada para verificar que los números son correctos y que el personal responde dentro del tiempo objetivo), prueba de restauración de copias de seguridad (restaurar una base de datos desde una copia en un entorno de pruebas y verificar la integridad de los datos), prueba de conmutación por error (conmutar una única aplicación no crítica al sitio de DR) y prueba del sistema de comunicación (utilizar el canal de comunicación fuera de banda para coordinar un incidente simulado). Cada ejercicio funcional valida un componente específico del plan.

Un simulacro de DR a escala completa cambia realmente las operaciones de producción al sitio de DR y valida que toda la cadena de recuperación funcione. La organización activa el sitio alternativo, carga los sistemas desde las copias de seguridad, redirige el DNS al entorno de DR e intenta ejecutar las operaciones empresariales reales. Las pruebas a escala completa responden a preguntas críticas: ¿cuánto tarda realmente la recuperación completa? ¿Pueden funcionar todas las aplicaciones en el sitio de DR? ¿Son correctas todas las configuraciones de red? ¿Funcionan las herramientas de supervisión y alertas en el entorno de DR? Estas pruebas son costosas y generan interrupciones, pero proporcionan el mayor nivel de confianza.

Los ejercicios de DR deben medir el rendimiento real frente a los objetivos de RTO y RPO. Durante el simulacro, registre lo siguiente: la hora a la que se activó cada sistema en el sitio de DR, cuándo pudo autenticarse correctamente el primer usuario y utilizar cada aplicación, qué antigüedad tenían los datos cuando los sistemas entraron en funcionamiento y el tiempo total transcurrido desde la «declaración del desastre» hasta el «restablecimiento de las operaciones». Compare estos datos con los objetivos de RTO y RPO. Cada diferencia entre el rendimiento objetivo y el real identifica una mejora concreta que debe realizarse antes del siguiente ejercicio.

Todo ejercicio de DR, independientemente del resultado, debe generar un informe posterior a la acción (AAR). El AAR documenta lo siguiente: qué escenarios se probaron, qué funcionó bien, qué falló o tardó más de lo previsto, las deficiencias concretas identificadas y una lista priorizada de mejoras con responsables y fechas objetivo de finalización. El AAR se comparte con la dirección ejecutiva para demostrar la madurez del programa y justificar la inversión necesaria para resolver las deficiencias identificadas. Sin un seguimiento documentado de las acciones del AAR, los ejercicios revelan problemas que nunca se corrigen.

Las pruebas de DR a gran escala utilizan uno de dos enfoques. Las pruebas de conmutación desvían realmente el tráfico de producción al sitio de DR; son realistas, pero implican un riesgo elevado si el sitio de DR falla, ya que podrían provocar una interrupción prolongada. Las pruebas en paralelo ponen en funcionamiento el entorno de DR junto con el de producción y dirigen el tráfico de prueba a DR mientras producción sigue atendiendo a los usuarios reales; validan la funcionalidad de DR con un riesgo bajo, ya que producción continúa operativa. La mayoría de las organizaciones utiliza pruebas en paralelo para los sistemas críticos y pruebas de conmutación para los sistemas menos críticos o durante ventanas de mantenimiento planificadas.

Un proceso claro de declaración de desastre es esencial: la ambigüedad sobre cuándo activar DR provoca retrasos peligrosos. Los planes deben definir criterios específicos y medibles que activen automáticamente DR: «Si el centro de datos principal no está accesible durante más de 2 horas» o «Si más del 50 % de los servidores de producción no están disponibles». El plan también debe definir quién tiene autoridad para declarar un desastre (normalmente el CIO o el CTO, con un suplente designado en caso de ausencia), un número de contacto disponible las 24 horas del día, los 7 días de la semana para comunicarse con esa persona y una ruta clara de escalamiento si la autoridad principal no está disponible.

La frecuencia de las pruebas debe corresponderse con la criticidad de los sistemas y el ritmo de los cambios en el entorno. Estas son las prácticas recomendadas del sector: ejercicios de mesa trimestrales (bajo costo y alto valor; mantienen actualizadas las habilidades), ejercicios funcionales semestrales (prueban componentes específicos), simulacros de DR a gran escala anuales (validación completa de todo el plan) y pruebas sin previo aviso al menos una vez al año (comprueban si el equipo puede responder sin preparación anticipada). Cualquier cambio importante en la infraestructura —como una migración a la nube, la implementación de una aplicación nueva o el traslado de un centro de datos— debe activar una nueva prueba de DR.

Muchos marcos normativos exigen realizar pruebas de DR con frecuencias y requisitos de documentación específicos. HIPAA exige que las entidades cubiertas prueben y revisen periódicamente sus planes de contingencia. El requisito 12.10 de PCI-DSS exige probar el plan de respuesta a incidentes al menos una vez al año y después de cambios importantes. Las directrices de la FDIC y la OCC para los bancos exigen realizar anualmente pruebas del BCP y presentar informes a nivel del consejo de administración. Los auditores de SOC 2 Type II revisan las evidencias sobre la frecuencia de las pruebas del BCP/DRP, sus resultados y la corrección de las deficiencias identificadas. Conserve evidencias documentadas de todas las pruebas, los resultados y las acciones correctivas para que los auditores puedan revisarlas.

En esta lección aprendió que las pruebas de DR avanzan desde debates de mesa, pasando por ejercicios funcionales, hasta simulacros a gran escala, en orden creciente de realismo y costo; que cada prueba debe medir el rendimiento real frente a los objetivos de RTO y RPO para identificar deficiencias concretas; y que los informes posteriores a la acción con acciones asignadas garantizan que las debilidades identificadas se corrijan antes del siguiente incidente. ¡Felicidades por completar el módulo de Continuidad del negocio y recuperación ante desastres! Ya está preparado para avanzar a los temas avanzados sobre amenazas.