Las tres acciones correctivas con las que cerró la lección anterior —copias inmutables en cuenta separada, prueba de restauración trimestral y alerta de borrado— no son respuesta a incidentes: son otra disciplina. El plan de respuesta te dice cómo actuar cuando la agenda de 40 clínicas está parada, pero no cuánto tiempo puede estar parada antes de que el negocio no lo resista, ni cuántos datos se puede permitir perder, ni cómo siguen atendiendo Rubén y las clínicas mientras el sistema no vuelve, ni cuánto tarda de verdad una restauración que nadie ha cronometrado. Esta lección responde a esas cuatro preguntas y cierra el módulo con el artefacto que en 02-06 habría cambiado el desenlace más que ningún otro: una copia verificada.

1. Continuidad de negocio y recuperación ante desastres: dos planes distintos
2. El análisis de impacto en el negocio (BIA)
3. RTO y RPO: qué son, cómo se fijan y cuánto cuestan
4. Estrategias de copia de seguridad
5. La prueba de restauración: el corazón de la lección
6. El escenario ransomware, que rompe los planes clásicos
7. Alta disponibilidad no es copia de seguridad
8. El plan escrito: DRP y procedimientos de emergencia
9. Pruebas del plan y cadencia
10. Métricas y mejora continua

Son complementarios y no sustituibles. Un DRP excelente sin BCP significa que durante las 12 horas de recuperación las clínicas no pueden hacer absolutamente nada y pierden a sus pacientes; un BCP excelente sin DRP significa que se puede aguantar unos días a mano, pero nadie sabe cuándo volverá el sistema ni si los datos existen.

Y una precisión de vocabulario: en este contexto «desastre» no significa terremoto. Para una PYME como Nimbus los desastres realistas son, por orden de probabilidad: un ransomware, un borrado accidental masivo, una caída prolongada del proveedor cloud, un error de migración que corrompe datos y, muy lejos, un incendio en la oficina. El plan se escribe contra los primeros, no contra el último.

El BIA (Business Impact Analysis) es el punto de partida obligatorio, y responde a una sola pregunta por proceso: si esto se para, ¿cuánto duele y a partir de cuándo? Sin BIA, los objetivos de recuperación se fijan por intuición o por lo que la tecnología ya hace, que es exactamente al revés.

Se identifican los procesos de negocio, no los sistemas. El sistema es el medio; el proceso es lo que el cliente paga.

El MTPD (Maximum Tolerable Period of Disruption) es el tiempo máximo que el negocio soporta la interrupción de ese proceso antes de sufrir un daño que ya no se repara. Tres reglas para fijarlo bien:

• Lo fija negocio, no tecnología. Marta y Rubén saben a partir de qué hora una clínica empieza a llamar a sus pacientes para reprogramar; Lucía no.
• No todo es crítico. Si en tu BIA todos los procesos tienen MTPD de 1 hora, no has hecho un BIA: has hecho una lista de deseos, y el resultado será que no se prioriza nada.
• El impacto no es lineal. Fíjate en la tabla: dos horas de caída son una molestia y veinticuatro son una crisis. Por eso el BIA se mide por tramos, no con un único número.

Una observación sobre el caso de Nimbus que conviene interiorizar: el proceso más crítico (reservas, MTPD de 4 h) no es el que más datos maneja, y el que más datos sensibles maneja (historial y adjuntos) tolera bastante más interrupción. Confidencialidad y disponibilidad tienen prioridades distintas, y por eso el registro de riesgos de 04-01 daba mayor ALE a la caída que a la fuga pese a ser mucho menos grave por evento.

• RPO (Recovery Point Objective): cuántos datos se puede permitir perder, medido en tiempo. Un RPO de 1 hora significa que, en el peor caso, se pierde el último trabajo de una hora. Lo determina la frecuencia de copia.
• RTO (Recovery Time Objective): cuánto se puede tardar en volver. Lo determina la arquitectura y el procedimiento, y debe ser siempre menor que el MTPD.

La diferencia entre réplica asíncrona y síncrona merece una frase: en la asíncrona la escritura se confirma al cliente antes de llegar a la copia, así que es rápida y puede perder los últimos segundos; en la síncrona no se confirma hasta que ambas copias la tienen, lo que garantiza RPO cero a costa de latencia en cada escritura y de que un problema en la zona secundaria degrade la principal.

Objetivos de Nimbus, derivados del BIA y no del deseo:

Y la regla que evita la conversación circular: RTO y RPO se derivan del MTPD del BIA, y después se comprueba si el presupuesto los permite. Si no los permite, no se cambia el número en la hoja: se documenta la brecha como riesgo aceptado en el registro de 04-01, con firma. Un RTO comprometido con un cliente y no alcanzable es, además de una mentira, un incumplimiento contractual.

Esquema típico y sensato para Nimbus: completa semanal, incremental diaria y copia continua del registro de transacciones de PostgreSQL —esta última es la que permite un RPO de 15 minutos, porque habilita la recuperación a un punto en el tiempo—.

Ya apareció en 02-04; aquí se desarrolla, porque cada dígito responde a un fallo distinto:

Los dos últimos dígitos son los que separan esta regla de la clásica 3-2-1, y son exactamente los que le faltaban a Nimbus en 02-06. El cuarto dígito —inmutabilidad— es el que impide el borrado del día 20 a las 02:10; el quinto —verificación— es el que habría revelado, semanas antes, que la única copia alternativa era un disco externo de cinco semanas que nadie había probado.

Sobre la inmutabilidad hay un matiz que decide su eficacia: debe estar en una cuenta cuyas credenciales no conozca producción, y con retención bloqueada de forma que ni siquiera el administrador pueda acortarla durante el periodo fijado. Si el mismo conjunto de credenciales que gestiona producción puede desactivar la retención, la inmutabilidad es una etiqueta, no un control.

Retención y versionado. Nimbus conserva: 7 copias diarias, 4 semanales, 12 mensuales y 1 anual. La retención larga no es capricho: una corrupción silenciosa o un borrado lógico pueden descubrirse semanas después, y con solo siete días de retención ya se ha replicado el problema a todas las copias.

Cifrado de la copia, con la clave fuera del entorno (03-07). Las copias contienen los mismos datos que producción y viajan a sitios menos vigilados, así que van cifradas. Y la clave no puede estar donde está lo que se cifra: si la clave de las copias vive en el mismo gestor de secretos que el atacante ya controla, el cifrado no aporta nada frente a la doble extorsión. Custodia separada, con procedimiento de recuperación de la clave probado —perder la clave de la copia es perder la copia—.

Qué se copia además de los datos, y que casi nadie incluye: la configuración de la infraestructura (idealmente como código, versionada en el repositorio), la definición de los recursos cloud, los secretos —cifrados y con custodia separada—, los certificados, la configuración del proveedor de identidad y la propia documentación de recuperación. Restaurar una base de datos sin poder reconstruir la infraestructura que la sirve alarga el RTO en días.

Y qué NO cubre una copia. Es la parte que produce sorpresas: el borrado lógico replicado —si borras una fila y la copia se sincroniza, la copia también la borra—; la corrupción propagada, cuando un error de aplicación lleva semanas escribiendo datos incorrectos que todas las copias contienen fielmente; los datos que solo viven en un SaaS que nadie exporta; y los cambios de esquema, porque una copia de hace seis meses puede no ser restaurable en la aplicación actual sin un proceso de migración.

Una copia no verificada no es una copia: es una esperanza. Esta frase resume el módulo entero, y en el caso de 02-06 fue literal: existía una copia y no servía. Las tres cosas que solo se descubren restaurando de verdad son que el fichero está íntegro y es legible, que el procedimiento funciona con la documentación que hay escrita, y cuánto se tarda en realidad —que es siempre más que la estimación—.

Cinco decisiones del script que son de método. Se cronometra, porque el dato más valioso de la prueba no es «funcionó», sino «tardó 55 minutos» comparado con el RTO comprometido. Se verifica el hash antes de restaurar, para no descubrir la corrupción a mitad. Se compara el número de filas con producción, porque pg_restore puede terminar con éxito habiendo restaurado una copia truncada. Se comprueba la coherencia referencial con la consulta de filas huérfanas, que detecta una restauración parcial que las cifras globales esconderían. Y se destruye el entorno al terminar, porque contiene datos reales de pacientes y un entorno de prueba olvidado es exactamente el A-22 con clasificación «a revisar» del inventario de 01-04.

El campo hallazgos del informe es el que justifica todo el ejercicio: la prueba debe producir hallazgos. Una prueba de restauración que sale perfecta a la primera casi siempre significa que se probó lo fácil.

Los planes de recuperación tradicionales se diseñaron contra el fallo técnico: un disco que se rompe, un centro de datos que se inunda. El ransomware con doble extorsión rompe cuatro supuestos de ese modelo:

De ahí las cuatro exigencias específicas frente a ransomware. Inmutabilidad real, con retención bloqueada que nadie pueda acortar. Aislamiento de las credenciales de copia: la cuenta que escribe las copias no debe poder borrarlas, y la que las lee para restaurar debe ser distinta y estar fuera del alcance de producción. Copia offline o lógicamente aislada como último recurso. Y un RTO calculado para el escenario de reconstrucción completa, no para el de restaurar un fichero: si Nimbus promete 4 horas y su escenario de ransomware exige 3 días, tiene un compromiso que no puede cumplir y debe saberlo antes de firmarlo.

Nota de validación. La decisión sobre el pago de un rescate, las obligaciones de notificación derivadas de la exfiltración y las condiciones de cobertura del seguro son cuestiones jurídicas y contractuales, no técnicas. Se consultan con asesoría jurídica, con el responsable de cumplimiento y con la aseguradora, cuya póliza suele imponer procedimientos concretos (04-01, 04-05).

La fila decisiva es la tercera. Una réplica no es una copia porque replica los errores con la misma diligencia con la que replica los aciertos. Confundirlas es uno de los errores más caros y más frecuentes: «tenemos alta disponibilidad» no responde a «¿y si alguien borra la tabla de citas?».

Además de la redundancia, el BCP cuenta con la degradación elegante: diseñar el sistema para que, ante un fallo parcial, siga ofreciendo lo esencial. En Nimbus significa que si el bucket de adjuntos no responde, la agenda debe seguir funcionando en modo solo lectura de citas en lugar de devolver un error general. Cada grado de degradación que el sistema soporta reduce el impacto por hora del BIA, y suele ser más barato que subir un escalón de la tabla de RTO.

Restaurar en el orden equivocado alarga el RTO y produce errores confusos. El orden se deriva del mapa de dependencias del inventario de 01-04:

Dos avisos sobre el diagrama. El paso 7 se deja para el final a propósito: reactivar las integraciones antes de validar puede disparar cientos de correos o de cobros duplicados con datos restaurados. Y el paso 8 no es opcional: la conciliación —comprobar qué citas se crearon entre el RPO y el desastre y no están— es el trabajo que convierte una restauración técnica en una recuperación de negocio.

Mientras dura el RTO, el negocio tiene que seguir. Esta es la parte del plan que no es técnica y la que más agradecen los clientes:

La primera fila contiene la idea más rentable de esta lección: una exportación diaria automática que cada clínica ya tiene en su correo convierte una catástrofe operativa en una molestia, cuesta cerca de nada y funciona incluso si Nimbus entero ha desaparecido.

El simulacro parcial trimestral es el que mejor relación coste-valor tiene y el que Nimbus no puede saltarse. El completo anual conviene hacerlo en ventana planificada y avisando a los clientes: un simulacro que sale mal en horario acordado es aprendizaje; el mismo fallo en un desastre real es una crisis.

Y una regla que cierra el ciclo del módulo: toda prueba produce hallazgos, y todo hallazgo se convierte en una acción con propietario y fecha que entra en el registro de riesgos de 04-01 y, si procede, en el catálogo de controles de 04-03. Sin eso, probar es una ceremonia.

La métrica que más sorprende al medirla por primera vez es la de cobertura: casi siempre aparece algún sistema crítico —la configuración del proveedor de identidad, el gestor de incidencias, los datos de un SaaS— que nadie estaba copiando porque todos asumían que lo hacía el proveedor. Es la responsabilidad compartida de 04-04 manifestándose en la práctica.

• Tener copias y no haberlas restaurado nunca. Es el error del módulo entero, y fue literal en 02-06. Consejo: la prueba trimestral en el calendario, con informe y hallazgos; sin informe, la prueba no ocurrió.
• Fijar el RTO por lo que la tecnología ya hace. Sale un número cómodo y falso. Consejo: primero el BIA y el MTPD, después la tecnología, y si no llega, se documenta como riesgo aceptado con firma.
• Copias accesibles con las mismas credenciales que producción. Es lo que permitió el borrado del día 20. Consejo: cuenta separada, retención bloqueada y credenciales de copia que producción no conozca.
• Confundir alta disponibilidad con copia de seguridad. La réplica replica los errores. Consejo: pregúntate siempre «¿y si alguien borra la tabla?».
• Cifrar la copia y guardar la clave dentro del entorno cifrado. Consejo: custodia separada y procedimiento de recuperación de la clave probado.
• Copiar los datos y no la configuración. Restaurar una base de datos sin poder levantar la infraestructura alarga el RTO en días. Consejo: infraestructura como código versionada, y también en la copia.
• Retención demasiado corta. Una corrupción descubierta a las tres semanas ya está en todas las copias. Consejo: retención escalonada diaria/semanal/mensual/anual.
• Plan que solo existe en el sistema que puede caer. Consejo: copia impresa y fuera de banda, igual que el plan de respuesta.
• Olvidar el BCP. Un DRP perfecto deja al negocio parado mientras dura el RTO. Consejo: empieza por la exportación diaria de la agenda; es casi gratis.

Nimbus quiere lanzar un módulo de teleconsulta para las clínicas. Negocio estima que si el módulo se cae, las clínicas pueden reprogramar por teléfono, pero más de 2 horas de caída en horario de mañana implica perder las consultas del día, y que perder los registros de una consulta ya realizada es inaceptable porque son datos clínicos.

1. Fija el MTPD, el RTO y el RPO del módulo, justificándolos.
2. Elige la estrategia técnica usando la tabla del apartado 3 e indica el coste relativo.
3. Propón dos medidas de degradación elegante que reduzcan el impacto por hora sin subir de escalón de coste.

Este es el informe de la última prueba de restauración de otra empresa:

Identifica todo lo que hace que este informe no demuestre que la empresa puede recuperarse, y reescribe los campos que faltan.

Nimbus tiene comprometido un RTO de 4 horas para la API y la base de datos, medido en la prueba trimestral (55 minutos). Estima el RTO real ante un ransomware como el de 02-06 descomponiéndolo en fases, indica dónde está la mayor parte del tiempo y propón tres medidas que lo reduzcan. Termina indicando qué debería hacer Marta con el compromiso de 4 horas.

Ejercicio 1

(1) MTPD = 2 horas, porque es el límite que fija negocio antes de un daño no reparable (las consultas del día se pierden). El RTO debe ser menor que el MTPD, así que se fija en 1 hora, dejando margen para la detección y la decisión, que también consumen tiempo del MTPD —error muy común: fijar RTO = MTPD y descubrir que la hora de detectar y decidir ya lo agotó—. El RPO ≈ 0-5 minutos, porque perder el registro de una consulta ya realizada es inaceptable: son datos clínicos que además pueden tener valor probatorio.

(2) Con RTO de 1 h y RPO de minutos, la tabla del apartado 3 sitúa la solución en réplica asíncrona a otra zona con promoción manual (× 2), no en réplica síncrona (× 3-4). La asíncrona con un desfase de segundos cumple un RPO de 5 minutos con holgura, y la promoción manual cabe en 1 hora si el procedimiento está escrito y probado. Pagar la síncrona aquí sería sobredimensionar: el RPO exigido no es cero, es «minutos», y esa distinción vale el doble de coste.

(3) Dos medidas de degradación elegante: (a) que la aplicación de teleconsulta guarde localmente en el dispositivo del profesional las notas de la consulta en curso y las sincronice al recuperarse, de modo que una caída no destruya el trabajo hecho —esto reduce el impacto del RPO sin cambiar la arquitectura de datos—; y (b) un modo degradado en el que, si falla el servicio de vídeo, la plataforma siga permitiendo consultar la ficha y registrar la consulta, ofreciendo un enlace telefónico alternativo: se mantiene el proceso de negocio aunque falle su componente más caro. Ambas reducen el impacto por hora del BIA y ninguna sube el escalón de coste.

Ejercicio 2

Problemas del informe:

Campos que faltan: hash_verificado: true, copia_probada: {reciente: ..., antigua: ...}, filas: {citas, clientes, huerfanas} con desviacion_vs_produccion_pct, rpo_real, ejecutada_por y procedimiento_suficiente: true|false, entorno_destruido: true, hallazgos con al menos una observación y acciones con propietario y fecha.

Ejercicio 3

Descomposición del RTO real ante ransomware:

La mayor parte del tiempo no está en restaurar, sino en reconstruir y en confiar. Restaurar es el 3 % del total; el 97 % restante es descubrir el alcance, levantar un entorno limpio y verificar que se puede volver.

Tres medidas que lo reducen de verdad: (a) infraestructura como código completa y probada, que convierte las 8-24 horas de reconstrucción en 1-2 horas de aplicar una plantilla —es, con diferencia, la medida de mayor impacto—; (b) controles detectivos (C-08, C-09 de 04-03), que recortan la fase de detección de días a horas y además reducen el alcance a investigar; y (c) un entorno de recuperación preparado en una cuenta separada, con la red y los roles ya definidos, para no crearlo bajo presión.

Qué debe hacer Marta con el compromiso de 4 horas. No mantenerlo como está. Tiene tres opciones defendibles y una inaceptable. Puede cualificar el compromiso —4 horas para fallo técnico, un objetivo distinto y declarado para escenarios de compromiso de seguridad, que es lo que hacen los proveedores serios—; puede invertir en infraestructura como código y en el entorno de recuperación preparado para acercar el escenario ransomware a las 4 horas; o puede aceptar formalmente el riesgo con firma de dirección y caducidad (04-01) mientras ejecuta lo anterior. Lo inaceptable es dejar el número tal cual en el contrato: un RTO comprometido y no alcanzable es un incumplimiento contractual esperando su fecha, y además falsea el riesgo residual del registro.

Has cerrado el módulo con la disciplina que decide si la empresa sobrevive. Distingues BCP y DRP como planes complementarios y no sustituibles —que el negocio siga frente a que la tecnología vuelva—, y sabes que para una PYME «desastre» no significa terremoto: significa ransomware, borrado masivo, caída del proveedor o migración corrupta. Sabes construir un BIA identificando procesos de negocio y no sistemas, con su MTPD fijado por negocio y no por tecnología, medido por tramos porque el impacto no es lineal, y con la observación que reordena prioridades: en Nimbus el proceso más crítico por disponibilidad no es el que maneja los datos más sensibles.

Dominas RTO y RPO —cuánto se tarda en volver y cuántos datos se pierden—, su relación con el MTPD, la tabla que traduce cada objetivo en una estrategia técnica y en un coste relativo, la diferencia entre réplica asíncrona y síncrona, y la regla que evita la conversación circular: se derivan del BIA y, si el presupuesto no llega, se documenta la brecha como riesgo aceptado con firma, nunca se cambia el número en la hoja. Conoces las estrategias de copia —completa, incremental y diferencial— y la regla 3-2-1-1-0 dígito a dígito, con los dos últimos dígitos como protagonistas porque son justo los que le faltaban a Nimbus en 02-06: el 1 de inmutable, que solo cuenta si la retención está bloqueada y las credenciales de copia son ajenas a producción, y el 0 de verificado. Sabes qué más hay que copiar además de los datos —configuración, infraestructura como código, secretos, certificados y la propia documentación— y qué no cubre una copia: el borrado lógico replicado, la corrupción propagada, los datos que solo viven en un SaaS y los cambios de esquema.

Te llevas el corazón de la lección: una copia no verificada no es una copia, es una esperanza, con los cuatro tipos de prueba, un script de restauración a entorno aislado que cronometra el RTO real, verifica el hash antes de restaurar, compara filas con producción, comprueba la coherencia referencial y destruye el entorno al terminar, y un informe en el que el campo de hallazgos es el que justifica el ejercicio. Sabes por qué el ransomware rompe los planes clásicos —copias accesibles que se cifran, reconstrucción en lugar de restauración, RTO multiplicado y confidencialidad que no se recupera—, por qué la alta disponibilidad no es copia de seguridad —replica el DELETE con la misma diligencia—, y qué aporta la degradación elegante. Y tienes el plan escrito: el orden de arranque por dependencias con sus dos avisos, los procedimientos manuales de emergencia encabezados por la idea más rentable de la lección —la exportación diaria de la agenda que cada clínica ya tiene en su correo—, la plantilla completa de DRP, la cadencia de pruebas con el simulacro parcial trimestral como pieza irrenunciable, y las métricas, entre las que la de cobertura siempre revela algún sistema crítico que nadie estaba copiando.

Con esto, el Módulo 4 está completo y forma un sistema. Sabes qué proteger y con qué prioridad, mediante una evaluación de riesgos defendible con su registro vivo, su apetito firmado y sus cuatro estrategias de tratamiento (04-01). Sabes bajo qué reglas, con una jerarquía documental que hace que las decisiones sobrevivan a quien las tomó y un registro de excepciones con caducidad obligatoria (04-02). Sabes con qué medidas, con un catálogo de controles clasificados por naturaleza y por función, medidos por cobertura y no por existencia, y trazados hasta su evidencia (04-03). Sabes hasta dónde llega tu perímetro, con un mapa de terceros, diligencia debida proporcionada, cláusulas contractuales y la cadena de suministro de software (04-04). Sabes cómo reaccionar, con un plan escrito antes, evidencias preservadas, comunicación honesta y post mortem sin culpables (04-05). Y sabes cómo volver, con objetivos derivados del negocio y copias verificadas (04-06).

Pero fíjate en una palabra que ha aparecido en las seis lecciones sin desarrollarse nunca: verificar. El catálogo de controles exige comprobar que el MFA cubre el 100 % de las cuentas; el escaneo externo mensual debe descubrir si el puerto 5432 ha vuelto a abrirse; las alertas de exfiltración tienen que existir y dispararse; las pruebas de autorización por tenant deben ejecutarse en cada fusión; y alguien tiene que buscar activamente las vulnerabilidades antes que el atacante. Todo eso es trabajo técnico con herramientas concretas que este módulo ha nombrado sin enseñar.

En el Módulo 5: Herramientas y Técnicas de Seguridad pasamos de la gestión a la ejecución: herramientas de análisis de vulnerabilidades (05-01) para encontrar lo que hay expuesto, técnicas de monitorización y detección (05-02) para construir por fin los controles detectivos que a Nimbus le faltan, pruebas de penetración (05-03), seguridad en redes (05-04), seguridad en aplicaciones (05-05), hardening del endpoint (05-06) y seguridad en la nube y en contenedores (05-07). Dejamos de preguntar qué merece la pena proteger y empezamos a comprobar, con herramientas en la mano, si de verdad está protegido.