Un plan de recuperación ante desastres es el procedimiento documentado para restaurar los servicios tecnológicos tras un fallo, especificando qué sistemas se restablecerán y en qué orden, cuánto tiempo debería tardar cada uno, cuánta pérdida de datos es aceptable y quién realizará el trabajo. Constituye la capa técnica de la planificación de la continuidad del negocio. Mientras que un plan de continuidad mantiene el negocio en funcionamiento por cualquier medio, un plan de recuperación se centra específicamente en restablecer los sistemas en sí.
- Una lista de sistemas priorizados, heredada del análisis de negocios en lugar de haber sido inventado por el departamento de TI.
- Un objetivo de recuperación y una cifra aceptable de pérdida de datos para cada sistema.
- Manuales de procedimientos lo suficientemente detallados como para que los pueda seguir alguien que no sea la persona habitual.
- El orden de dependencia, porque los sistemas restaurados en la secuencia incorrecta no se inician.
- Un registro de prueba, ya que un procedimiento de recuperación no probado es una hipótesis.
¿Qué es un plan de recuperación ante desastres?
Un plan de recuperación ante desastres establece cómo se restablecen los servicios tecnológicos tras un evento que los interrumpe: fallo de hardware, pérdida de un centro de datos, un cambio fallido, una interrupción en una región de la nube o un ataque de ransomware. Responde a tres preguntas para cada sistema afectado: ¿Con qué rapidez debe restablecerse?, ¿Cuántos datos recientes podemos permitirnos perder? y ¿Qué pasos debe seguir exactamente alguien para recuperarlo?
El término "desastre" puede resultar engañoso. La mayoría de las situaciones no son dramáticas. Una base de datos dañada, una migración fallida o un certificado caducado en un servicio crítico conllevan el mismo escenario que una inundación. Elaborar un plan solo para situaciones catastróficas obliga a improvisar ante las situaciones mucho más comunes.
La planificación de la recuperación forma parte de la capacidad más amplia descrita en el ámbito de la continuidad del negocio , de donde se derivan las prioridades y los plazos de recuperación. Si la visión tecnológica se ha desarrollado sin tener en cuenta estos aspectos, el plan protege los sistemas en un orden que nadie ha validado en función de las necesidades del negocio.
¿Cómo elegir un enfoque de recuperación?
El objetivo de recuperación determina la arquitectura, y la arquitectura determina el costo. Esta es la disyuntiva que define todo lo demás en el plan, y conviene definirla explícitamente en lugar de adoptar la infraestructura existente. Existen tres opciones generales, y el vocabulario técnico que las rodea resulta poco útil para ideas bastante sencillas.
| Restauración de copia de seguridad | Modo de espera cálido | Activo-activo | |
|---|---|---|---|
| Lo que es | Reconstruir el servicio a partir de la última copia de seguridad después de un fallo. | Una segunda copia seguía funcionando pero inactiva, y se activaba cuando era necesario. | Dos copias en vivo compartiendo el trabajo, por lo que no hay nada que encender. |
| Ventana de pérdida de datos | Desde la última copia de seguridad | Minutos de datos | Cerca de cero |
| hora de restaurar | Horas a días | Minutos a horas | Cerca de cero |
| Protege contra | Datos incorrectos o cifrados | Pérdida de infraestructura | Pérdida de sitio o región |
| Costo fijo | Solo almacenamiento | Parte de una segunda propiedad | Dos fincas vivas |
| Adecuado para | Servicios que pueden tolerar una interrupción | Servicios más críticos | Servicios que no pueden detenerse |
Pocas organizaciones necesitan el mismo enfoque en todas partes. Lo más útil es la estratificación: un pequeño número de servicios que realmente no pueden detenerse reciben una protección costosa, la mayoría recibe una protección proporcional, y el resto se restaura a partir de copias de seguridad. Aplicar un enfoque uniforme conlleva un gasto excesivo en actividades que podrían tolerar un día de inactividad, o bien deja a los pocos servicios críticos con un tiempo de recuperación que la empresa ya ha descartado.
Se repiten dos modos de fallo. El primero consiste en elegir un objetivo de recuperación sin presupuestar la arquitectura que lo proporciona, lo que implica comprometerse con algo que la infraestructura no puede hacer. El segundo consiste en adquirir replicación y asumir que garantiza la recuperación, cuando un conjunto de datos corrupto o cifrado se replica con la misma fidelidad que uno en buen estado. La replicación protege contra la pérdida de infraestructura. Las copias de seguridad protegen contra los datos erróneos, y no son sustitutas.
¿Qué debe contener un plan de recuperación ante desastres?
Por sistema, no por organización. Un único documento descriptivo que explique el enfoque en general no es útil a las tres de la mañana para quien esté de guardia.
- Objetivos de recuperación: el tiempo objetivo y la pérdida de datos aceptable para ese sistema, atribuible al análisis de negocio que los estableció.
- Orden de dependencia¿Qué debe ejecutarse primero? La autenticación, la red, el DNS y las bases de datos generalmente preceden a las aplicaciones que los necesitan.
- El manual de operaciones: los pasos concretos, escritos de forma que un ingeniero competente que no sea el propietario del sistema pueda ejecutarlos.
- Acceso y credenciales: cómo se obtiene el acceso privilegiado durante un incidente, y cómo se almacena en algún lugar que sobreviva al fallo.
- Restauración de datos: dónde se encuentran las copias de seguridad, cómo verificar su integridad y cuánto tiempo tarda realmente una restauración en volúmenes de datos reales.
- Verificación: cómo confirmar que el servicio realmente está funcionando en lugar de simplemente estar en ejecución.
- Roles y escalamiento: quién decide invocar, quién ejecuta, quién comunica y quién autoriza una alternativa.
De todos estos aspectos, el orden de dependencias es el que requiere mayor atención, ya que un error en este produce fallos que se asemejan a un sistema averiado en lugar de un simple error de secuenciación. Una aplicación restaurada antes de la base de datos que lee, o antes del servicio de identidad con el que se autentica, no se iniciará, y el equipo pierde tiempo diagnosticando el problema equivocado. Esta estructura general se mantiene en la mayoría de los entornos.
El detalle que suele pasarse por alto es cuánto tiempo tarda realmente una restauración. Una copia de seguridad que se completa durante la noche puede tardar mucho más en restaurarse a volumen de producción, y si nadie lo ha medido, el tiempo de recuperación es solo una suposición.
Es importante establecer un límite. Un plan de recuperación restablece los sistemas. La solución provisional que la empresa utiliza mientras tanto, para un riesgo específico, debería formar parte de un plan de contingencia . Las organizaciones que solo conservan el plan tecnológico suelen descubrir que nadie acordó cómo continuar el trabajo durante ese período.
Detrás de todo esto hay algo más importante.
Esta página abarca una parte de la resiliencia empresarial. Real Resilience, el marco de IO para conectar la seguridad, la privacidad y la gobernanza de la IA, es donde se obtiene la visión completa.
¿Cómo se prueba un plan de recuperación ante desastres?
Las pruebas son donde los planes de recuperación ganan credibilidad, y existe una progresión. Cada nivel cuesta más y demuestra más, y un programa que nunca pasa del primer nivel no ha demostrado gran cosa.
| Tipo de prueba | Lo que demuestra | Que cuesta |
|---|---|---|
| Tutorial | Que la documentación sea completa y comprensible para alguien que no la haya escrito. | Unas horas. Ningún sistema tocado. |
| Ejercicio de mesa | Que las personas conozcan sus funciones y que la toma de decisiones y la resolución de problemas funcionen bajo presión. | Medio día del tiempo de las personas adecuadas. |
| Restauración de componentes | Que las copias de seguridad sean restaurables y que se conozca la duración real de la restauración. | Moderado. Necesita un entorno aislado. |
| Conmutación por error parcial | Que un único servicio pueda ejecutarse desde su posición de recuperación, incluidas las dependencias. | Planificación importante. Cierto riesgo en el servicio. |
| Conmutación por error completa | Que todo el entorno pueda funcionar desde la recuperación, bajo carga, con la empresa trabajando en ello. | Alto. Normalmente requiere una ventana planificada. |
Registra los fallos. Un registro de pruebas que muestre los problemas detectados y solucionados constituye una prueba más sólida de la capacidad de funcionamiento que una serie de pruebas sin fallos, que principalmente sugieren que las pruebas no fueron lo suficientemente exigentes. Compartir los resultados con los propietarios y las fechas es lo que convierte las pruebas en mejoras, en lugar de simplemente brindar tranquilidad.
¿Qué normas abarcan la recuperación ante desastres?
No existe ninguna norma dedicada exclusivamente a la recuperación ante desastres, por lo que los requisitos se distribuyen entre varias, lo que explica en parte por qué la planificación de la recuperación a menudo termina desconectada de todo lo demás.
- ISO 22301,: el sistema de gestión certificable para la continuidad del negocio. Establece las prioridades de análisis y recuperación que debe incorporar un plan tecnológico.
- ISO / IEC 27031: orientación específica sobre la preparación de las TIC para la continuidad del negocio, que es lo que más se ajusta a la recuperación ante desastres como disciplina.
- ISO 27001,El Anexo A incluye controles sobre la seguridad de la información durante las interrupciones, la preparación de las TIC para la continuidad y la copia de seguridad de la información, por lo que la capacidad de recuperación se examina durante una auditoría.
- Reglas del sector: las organizaciones reguladas se enfrentan a expectativas adicionales, por ejemplo los requisitos de continuidad y recuperación en virtud de Guía de implementación de NIS 2.
Trabajar conjuntamente conforme a las normas ISO 22301 e ISO 27001 proporciona la mayor parte de la evidencia que exigen estos regímenes, en un formato que ya ha sido auditado de forma independiente.
Comienza tu prueba gratuita
¿Quieres explorar?
Regístrese hoy para su prueba gratuita y pruebe todas las funciones de cumplimiento que ISMS.online tiene para ofrecer
¿Cómo se relaciona la recuperación ante desastres con la resiliencia?
La recuperación ante desastres restaura los sistemas. La resiliencia es la capacidad más amplia de absorber interrupciones de cualquier tipo, incluidos los eventos que ningún manual de procedimientos prevé. La relación entre ambas radica en que la recuperación depende por completo de controles que se encuentran fuera del plan de recuperación: si las copias de seguridad son inmutables, si el acceso privilegiado sigue funcionando cuando el proveedor de identidades no está disponible, si el proveedor que aloja el entorno de recuperación ha sido evaluado y si el proceso de respuesta a incidentes funciona correctamente.
El ciclo de resiliencia gestiona la seguridad de la información según la norma ISO 27001, la privacidad de los datos según la norma ISO 27701 y la gobernanza de la IA según la norma ISO 42001 como un sistema conectado, con la recuperación como una perspectiva adicional sobre los mismos controles. El ransomware lo demuestra claramente. Es simultáneamente un incidente de seguridad, una posible filtración de datos personales y un evento de recuperación, y una organización que gestiona estos tres aspectos como programas separados responde a él tres veces. La estructura que evita esto se establece en el marco de resiliencia empresarial.
¿Cómo se demuestra que la recuperación ante desastres funciona?
Nadie con credibilidad acepta la existencia de un plan como prueba. Lo que sí es válido es el plan en sí, con sus objetivos de recuperación actuales, los registros de las pruebas que muestran las fechas y los participantes, las fallas que revelaron dichas pruebas, las medidas correctivas posteriores y la confirmación de que el plan aún se ajusta al patrimonio que describe.
Generada durante el desarrollo del trabajo, esta evidencia siempre está disponible. Recopilada antes de una auditoría o la debida diligencia del cliente, suele revelar hasta qué punto el patrimonio documentado se ha desviado del real. El enfoque se describe en el documento sobre cómo demostrar la resiliencia , y la Puntuación de Resiliencia proporciona una base de referencia.
¿Por qué elegir ISMS.online para la planificación de la recuperación ante desastres?
Los planes de recuperación fallan con mucha más frecuencia en lo que respecta a la moneda que al contenido. ISMS.online está diseñado para mantenerlos alineados con el patrimonio.
- Planes vinculados a los sistemas que cubrenCada entrada se conecta con el activo, su propietario y los controles de los que depende, por lo que la desviación es visible.
- Los objetivos de recuperación son heredados, no inventados.Los objetivos establecidos por el análisis de negocio se trasladan al plan tecnológico.
- Los cronogramas de las pruebas y los resultados se presentan juntos.Planificar los ejercicios, registrar los fallos y hacer un seguimiento de las medidas correctivas en el mismo lugar que el plan.
- Un conjunto de controles, cada marco: Los controles de respaldo, acceso y proveedores se mapean una sola vez y se reutilizan en ISO 22301, ISO 27031, ISO 27001, ISO 27701 e ISO 42001.
- Se evaluaron las dependencias de los proveedores.: los terceros de los que depende discretamente su recuperación se gestionan en el mismo sistema.
- Basado en una profunda experiencia.: Implementación guiada por especialistas que han dirigido programas de recuperación en entornos regulados.
- Diseñado para el Reino Unido y los mercados regulados.: diseñado para organizaciones que deben demostrar su capacidad de recuperación ante auditores y clientes.
Vea cómo se integra en la plataforma de resiliencia empresarial o solicite una demostración.
Preguntas Frecuentes
¿Cuál es la diferencia entre un plan de recuperación ante desastres y un plan de continuidad del negocio?
Un plan de recuperación ante desastres restablece los servicios tecnológicos. Un plan de continuidad del negocio mantiene la actividad empresarial durante las interrupciones mediante cualquier medio disponible, lo que puede incluir el trabajo manual mientras los sistemas están inactivos. La recuperación es un componente de la continuidad, no una alternativa a ella, y los objetivos de recuperación en el plan tecnológico deben derivarse del análisis de negocio en el que se basa el plan de continuidad.
¿Cuáles deberían ser el RTO y el RPO?
Ambos objetivos se derivan del análisis del impacto en el negocio, más que de la capacidad actual de la infraestructura. El objetivo de tiempo de recuperación se establece a partir del punto en que la interrupción de la actividad se vuelve inaceptable, con un margen de seguridad dentro de ese límite. El objetivo de punto de recuperación se basa en la cantidad de datos recientes que la empresa podría reconstruir o permitirse perder. Establecer cualquiera de ellos a partir de la capacidad técnica actual genera objetivos que siempre se cumplen y no demuestran nada.
¿Cuál es la diferencia entre el modo de espera en caliente y el modo activo-activo?
La reserva en caliente mantiene una segunda copia del servicio en funcionamiento, pero inactiva. No presta servicio a nadie hasta que se activa la conmutación por error, por lo que la recuperación implica un cambio deliberado, que lleva tiempo y puede fallar. El modo activo-activo significa que dos copias activas gestionan el trabajo real al mismo tiempo, por lo que si se pierde una, la otra sigue en funcionamiento y no hay nada que activar. El modo activo-activo elimina el paso de conmutación por error y, por consiguiente, es más costoso, ya que se gestionan y licencian dos entornos de producción en lugar de uno y uno de reserva.
¿Con qué frecuencia se debe poner a prueba un plan de recuperación ante desastres?
Al menos una vez al año para una prueba significativa, con recorridos más sencillos con mayor frecuencia y una revisión cada vez que el sistema cambie sustancialmente. La frecuencia importa menos que la progresión: una organización que usa el mismo simulador cada año sabe que su personal comprende sus funciones, pero aún no tiene evidencia de que la restauración funcione a volumen de producción. Alterne el tipo de prueba para que se examinen diferentes supuestos.
¿El alojamiento en la nube elimina la necesidad de un plan de recuperación ante desastres?
No. Las plataformas en la nube proporcionan los componentes básicos para una arquitectura resiliente, pero las zonas de disponibilidad y los servicios gestionados son opciones de configuración, no valores predeterminados, y sí se producen interrupciones regionales. La nube tampoco se ocupa de los datos borrados o cifrados, las configuraciones incorrectas o las cuentas comprometidas. El enfoque cambia en la nube, centrándose más en la configuración, las copias de seguridad inmutables y la recuperación de cuentas que en el hardware, pero no desaparece.
¿El ransomware constituye un escenario de recuperación ante desastres?
Es eso y mucho más. El ransomware es un incidente de seguridad, frecuentemente una filtración de datos personales y un proceso de recuperación simultáneo, e invalida las suposiciones de la planificación de recuperación habitual. Las copias de seguridad pueden estar cifradas o eliminadas, por lo que la inmutabilidad y las copias sin conexión son cruciales, y puede ser necesario reconstruir el entorno en lugar de restaurarlo directamente, ya que restaurarlo en un sistema comprometido simplemente lo reinfecta.
