La recuperación ante desastres de TI (también, simplemente recuperación ante desastres (DR) ) es el proceso de mantenimiento o restablecimiento de la infraestructura y los sistemas vitales después de un desastre natural o inducido por el hombre , como una tormenta o una batalla. DR emplea políticas, herramientas y procedimientos con un enfoque en los sistemas de TI que respaldan las funciones comerciales críticas. [1] Esto implica mantener todos los aspectos esenciales de un negocio en funcionamiento a pesar de eventos disruptivos significativos; por lo tanto, puede considerarse un subconjunto de la continuidad comercial (BC). [2] [3] DR asume que el sitio principal no es inmediatamente recuperable y restaura datos y servicios a un sitio secundario.
La continuidad del servicio de TI (ITSC) es un subconjunto del BCP [4] que se basa en las métricas (que se utilizan con frecuencia como indicadores clave de riesgo ) de los objetivos de tiempo/punto de recuperación. Abarca la planificación de recuperación ante desastres de TI y la planificación más amplia de resiliencia de TI . También incorpora la infraestructura y los servicios de TI relacionados con las comunicaciones , como la telefonía y las comunicaciones de datos . [5] [6]
La planificación incluye la organización de sitios de respaldo, ya sean "calientes" (que operaban antes de un desastre), "tibios" (listos para comenzar a operar) o "fríos" (requieren un trabajo sustancial para comenzar a operar), y sitios de reserva con hardware según sea necesario para la continuidad.
En 2008, la British Standards Institution lanzó una norma específica que respaldaba la Norma de Continuidad de Negocios BS 25999 , titulada BS25777, específicamente para alinear la continuidad informática con la continuidad de negocios. Esta norma fue retirada tras la publicación en marzo de 2011 de la ISO/IEC 27031, "Técnicas de seguridad: directrices para la preparación de tecnologías de la información y la comunicación para la continuidad de negocios". [7]
ITIL ha definido algunos de estos términos. [8]
El Objetivo de Tiempo de Recuperación (RTO) [9] [10] es la duración de tiempo prevista y un nivel de servicio dentro del cual se debe restaurar un proceso de negocio después de una interrupción para evitar una interrupción en la continuidad del negocio. [11]
De acuerdo con la metodología de planificación de la continuidad del negocio, el RTO se establece durante el análisis de impacto en el negocio (BIA) por parte del propietario o los propietarios del proceso, incluida la identificación de plazos para soluciones alternativas o manuales.
El RTO es un complemento del RPO. Los límites del rendimiento aceptable o "tolerable" de ITSC se miden mediante el RTO y el RPO en términos de tiempo perdido en el funcionamiento normal del proceso empresarial y datos perdidos o no respaldados durante ese período. [11] [12]
El tiempo de recuperación real (RTA) es la métrica crítica para la continuidad del negocio y la recuperación ante desastres. [9]
El grupo de continuidad del negocio lleva a cabo ensayos cronometrados (o reales), durante los cuales se determina y perfecciona el RTA según sea necesario. [9]
Un objetivo de punto de recuperación (RPO) es el intervalo máximo aceptable durante el cual se pierden datos transaccionales de un servicio de TI. [11]
Por ejemplo, si el RPO se mide en minutos, entonces en la práctica, las copias de seguridad reflejadas fuera del sitio deben mantenerse continuamente , ya que una copia de seguridad diaria fuera del sitio no será suficiente. [13]
Una recuperación que no es instantánea restaura los datos transaccionales durante un cierto intervalo sin incurrir en riesgos o pérdidas significativas. [11]
El RPO mide el tiempo máximo en el que los datos recientes pueden haberse perdido de forma permanente y no es una medida directa de la cantidad de pérdida. Por ejemplo, si el plan de BC es restaurar hasta la última copia de seguridad disponible, entonces el RPO es el intervalo entre dichas copias de seguridad.
El RPO no está determinado por el régimen de copias de seguridad existente, sino que BIA determina el RPO para cada servicio. Cuando se requieren datos fuera de las instalaciones, el período durante el cual los datos pueden perderse puede comenzar cuando se preparan las copias de seguridad, no cuando se aseguran las copias de seguridad fuera de las instalaciones. [12]
Las métricas de recuperación se pueden convertir en métricas de fallas o se pueden usar junto con ellas . Las mediciones comunes incluyen el tiempo medio entre fallas (MTBF), el tiempo medio hasta la primera falla (MTFF), el tiempo medio hasta la reparación (MTTR) y el tiempo medio de inactividad (MDT).
Un punto de sincronización de datos [14] es cuando se completa una copia de seguridad. Detiene el procesamiento de actualización mientras se completa una copia de disco a disco. La copia de seguridad [15] refleja la versión anterior de la operación de copia, no cuando los datos se copian a cinta o se transmiten a otro lugar.
El RTO y el RPO deben equilibrarse, teniendo en cuenta el riesgo comercial, junto con otros criterios de diseño del sistema. [16]
El RPO está vinculado a los momentos en que se realizan copias de seguridad en un lugar remoto. El envío de copias sincrónicas a un espejo externo permite la mayoría de los eventos imprevistos. El uso de transporte físico para cintas (u otros medios transportables) es común. La recuperación se puede activar en un sitio predeterminado. El espacio y el hardware compartidos fuera del sitio completan el paquete. [17]
Para grandes volúmenes de datos de transacciones de alto valor, el hardware se puede dividir en varios sitios.
La planificación de la recuperación ante desastres y la tecnología de la información (TI) se desarrolló a mediados y fines de la década de 1970 cuando los gerentes de centros de cómputo comenzaron a reconocer la dependencia de sus organizaciones de sus sistemas informáticos.
En ese momento, la mayoría de los sistemas eran mainframes orientados al procesamiento por lotes . Se podía cargar un mainframe externo desde cintas de respaldo en espera de la recuperación del sitio principal; el tiempo de inactividad era relativamente menos crítico.
La industria de recuperación de desastres [18] [19] se desarrolló para proporcionar centros informáticos de respaldo. Sungard Availability Services fue uno de los primeros centros de este tipo, ubicado en Sri Lanka (1978). [20] [21]
Durante los años 1980 y 1990, la informática creció exponencialmente, incluyendo el tiempo compartido interno en las empresas, la entrada de datos en línea y el procesamiento en tiempo real . La disponibilidad de sistemas de TI se volvió más importante.
Las agencias reguladoras se involucraron; a menudo se exigían objetivos de disponibilidad de 2, 3, 4 o 5 nueves (99,999 %) y se buscaron soluciones de alta disponibilidad para instalaciones de sitios calientes . [ cita requerida ]
La continuidad del servicio de TI se volvió esencial como parte de la Gestión de la Continuidad del Negocio (BCM) y la Gestión de la Seguridad de la Información (ICM), como se especifica en ISO/IEC 27001 e ISO 22301 respectivamente.
El auge de la computación en la nube desde 2010 creó nuevas oportunidades para la resiliencia del sistema. Los proveedores de servicios asumieron la responsabilidad de mantener altos niveles de servicio, incluida la disponibilidad y la confiabilidad. Ofrecieron diseños de red altamente resilientes. La recuperación como servicio (RaaS) está ampliamente disponible y es promovida por la Cloud Security Alliance . [22]
Los desastres pueden ser el resultado de tres amplias categorías de amenazas y peligros.
Las medidas de preparación para todas las categorías y tipos de desastres se enmarcan en las cinco áreas de misión de prevención, protección, mitigación, respuesta y recuperación. [23]
Las investigaciones respaldan la idea de que es más rentable implementar un enfoque de planificación previa al desastre más integral. Por cada dólar gastado en mitigación de riesgos (como un plan de recuperación ante desastres ) la sociedad ahorra cuatro dólares en costos de respuesta y recuperación. [24]
Las estadísticas de recuperación ante desastres de 2015 sugieren que el tiempo de inactividad que dura una hora puede costar [25]
A medida que los sistemas de TI se han vuelto cada vez más críticos para el buen funcionamiento de una empresa y, posiblemente, de la economía en su conjunto, ha aumentado la importancia de garantizar el funcionamiento continuo de esos sistemas y su rápida recuperación. [26]
Las medidas de control son pasos o mecanismos que pueden reducir o eliminar las amenazas. La elección de los mecanismos se refleja en un plan de recuperación ante desastres (PRD).
Las medidas de control pueden clasificarse como controles destinados a prevenir que ocurra un evento, controles destinados a detectar o descubrir eventos no deseados y controles destinados a corregir o restaurar el sistema después de un desastre o evento.
Estos controles se documentan y se ejercen periódicamente mediante las denominadas "pruebas DR".
La estrategia de recuperación ante desastres se deriva del plan de continuidad del negocio. [27] Las métricas de los procesos de negocio se asignan luego a los sistemas y la infraestructura. [28] Un análisis de costo-beneficio destaca qué medidas de recuperación ante desastres son las adecuadas. Diferentes estrategias tienen sentido en función del costo del tiempo de inactividad en comparación con el costo de implementar una estrategia en particular.
Las estrategias comunes incluyen:
Las estrategias de precaución pueden incluir:
La recuperación ante desastres como servicio (DRaaS) es un acuerdo con un proveedor externo para realizar algunas o todas las funciones de recuperación ante desastres en situaciones como cortes de energía, fallas de equipos, ataques cibernéticos y desastres naturales. [30]
en tiempo real... proporcionar redundancia y respaldo a...
.. registros de pacientes
...la industria de recuperación de desastres ha crecido
Sungard... fundada en 1978
SunGard... el futuro de Sri Lanka.