Prueba de restauración de respaldos y simulacro de recuperación ante ransomware

En Honduras, el Art. 35 de la Circular CNBS 025/2022 pide procedimientos de respaldo y recuperación basados en el RTO y el RPO definidos, y dice que esos procedimientos deben ser probados periódicamente. También obliga a respaldar al menos el cierre contable mensual y el anual. El Art. 29 pide fijar el RTO y el RPO de cada proceso en el análisis de impacto.

En El Salvador, el Art. 23 de la NRP-23 pide procedimientos de respaldo regular y periódicamente validados, que permitan recuperar la información esencial en forma oportuna después de una falla o un desastre. Las copias y los procedimientos de restauración deben guardarse lejos del centro de datos principal, y la ubicación se notifica a la Superintendencia.

En Guatemala, el Art. 20 de la JM-98-2025 pide definir la periodicidad y validación de las copias y los procedimientos de restauración. La información crítica se respalda como mínimo a diario, en infraestructura dentro del territorio nacional, a disposición de la Superintendencia de Bancos. En Costa Rica, el Art. 23 del Acuerdo CONASSIF 5-24 pide que los servicios en la nube respeten el RPO y el RTO de la entidad y que exista respaldo en un sitio alterno cuando el servicio contratado no lo incluye.

Ninguna de las cuatro normas acepta que la copia exista. Todas hablan de probar, validar o restaurar.

Elegimos con usted entre dos y cinco sistemas. Al menos uno debe ser crítico según su análisis de impacto: el core, la base de datos de clientes, el controlador de dominio, el correo. Para cada uno restauramos desde la copia real, no desde una copia preparada para la prueba.

• Que la copia más reciente existe, está completa y se puede leer.
• Que el sistema arranca y la aplicación responde después de restaurar, no solo que los archivos volvieron.
• Cuánto tardó la restauración completa, desde la decisión de restaurar hasta el servicio disponible.
• Cuántos datos se perdieron: la distancia entre la última copia buena y el momento del corte.
• Si el procedimiento escrito alcanza para que otra persona de su equipo lo ejecute.
• Si las credenciales, llaves de cifrado y licencias necesarias están disponibles cuando faltan los sistemas de siempre.

Su plan de continuidad dice, por ejemplo, que el core se recupera en cuatro horas con una pérdida máxima de quince minutos de datos. Esos son el RTO y el RPO declarados. La prueba produce los mismos dos números, pero medidos.

Registramos la hora de cada paso: inicio de la restauración, fin de la copia de datos, arranque del sistema, primera transacción de prueba. Si el RTO real es de once horas, el informe lo dice, con la causa. A menudo la causa no es la herramienta. Es un paso manual que nadie documentó, una contraseña guardada en el mismo servidor que se cayó, o un ancho de banda que nunca se midió para un volumen real.

Un ataque de ransomware cambia la pregunta. No basta con que la copia se restaure. Tiene que sobrevivir a alguien que ya entró a su red con una cuenta de administrador y que, antes de cifrar, busca la consola de respaldo para borrar las copias.

En el simulacro revisamos si existe al menos una copia que esa cuenta no puede borrar ni modificar: una copia inmutable, una copia fuera de línea o una copia en otro dominio de administración. Revisamos quién puede cambiar la retención, si la consola de respaldo usa las mismas credenciales del dominio y si alguien recibe una alerta cuando se borra una copia.

Después restauramos en un segmento aislado de la red de producción. Así se comprueba que la recuperación no depende de sistemas que en un ataque real estarían cifrados, como el directorio activo o el servidor de archivos. Este ejercicio también es la evidencia que la NRP-23 (Art. 16 d) pide cuando habla de pruebas que simulen ataques cibernéticos.

Puede usar esta lista tal como está, con o sin Toukan. Si no puede marcar la mitad, la prueba va a encontrar trabajo.

• Tiene un inventario de qué sistemas se respaldan, con qué frecuencia y dónde quedan las copias.
• Cada sistema crítico tiene un RTO y un RPO escritos y aprobados.
• Existe un procedimiento de restauración por sistema, no solo el manual del fabricante.
• Al menos una copia no se puede borrar con las credenciales del dominio.
• La consola de respaldo tiene autenticación de varios factores y cuentas propias.
• Las llaves de cifrado de las copias están guardadas fuera de los sistemas que protegen.
• Hay un entorno aislado donde restaurar sin tocar producción.
• Alguien recibe una alerta si una copia falla o se borra.
• Las copias de los cierres contables mensuales y anuales se conservan y se pueden ubicar.
• La última restauración completa de un sistema crítico tiene fecha y un registro escrito.

Primero una llamada de alcance para elegir los sistemas y la ventana. Luego revisamos su plan, sus procedimientos y la configuración de la herramienta de respaldo, con acceso de lectura. La restauración se hace en la ventana acordada, con su equipo o su integrador operando la consola y Toukan midiendo y registrando. Nada se restaura sobre producción.

De la firma al informe pasan entre 2 y 6 semanas, según cuántos sistemas entren y cuándo haya ventana. El precio se fija después de la llamada de alcance. El informe trae un resumen para el comité, la tabla de RTO y RPO medidos frente a los del plan, los hallazgos con evidencia y la referencia al artículo de su norma. Lo firma la persona que dirigió la prueba.

Su integrador no queda fuera. Es quien mejor conoce la herramienta y casi siempre es quien corrige lo que la prueba encuentra. Toukan no recomienda cambiar de marca ni vende licencias.