RTO, RPO y MTTR: definición de objetivos de recuperación

Sin objetivos de recuperación específicos y medibles, es imposible diseñar estrategias de respaldo adecuadas, elegir el nivel correcto del sitio de DR o evaluar si se justifican las inversiones en tecnología de recuperación. RTO, RPO y MTTR convierten los requisitos empresariales de disponibilidad en objetivos de ingeniería precisos. Estas métricas permiten que los equipos de seguridad y TI mantengan conversaciones fundamentadas en datos con la dirección sobre el costo del tiempo de inactividad frente al costo de las inversiones en DR, haciendo que los casos de negocio sean concretos en lugar de abstractos.

El objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable desde el inicio de una interrupción hasta el restablecimiento del servicio normal. Si un sistema de pagos crítico falla a las 10:00 y el negocio puede tolerar como máximo 2 horas de inactividad antes de sufrir una pérdida de ingresos inaceptable o incumplir los SLA, el RTO es de 2 horas: el sistema debe restaurarse, como muy tarde, a las 12:00. El RTO determina las decisiones sobre el nivel del sitio de DR (sitio activo para un RTO de 15 minutos frente a sitio frío para un RTO de 48 horas), la frecuencia de replicación y la automatización de la conmutación por error.

El objetivo de punto de recuperación (RPO) es la pérdida máxima de datos aceptable, medida en tiempo: cuántos datos se pueden perder si ocurre un desastre. Un RPO de 1 hora significa que, al restaurar los sistemas, estos deben contener datos de no más de 1 hora antes de que ocurriera el desastre. El RPO determina la frecuencia de los respaldos: un RPO de 1 hora requiere respaldos al menos cada hora (o replicación continua). Un RPO de 4 horas puede tolerar intervalos de respaldo de 4 horas. El RPO se refiere a la recuperación de datos, mientras que el RTO se refiere al restablecimiento de la disponibilidad del servicio.

El RTO y el RPO abordan aspectos distintos de la recuperación y deben definirse de forma independiente. Un sistema puede tener un RPO exigente (1 hora, lo que significa que los datos se replican con frecuencia), pero un RTO holgado (4 horas, lo que significa que se necesita tiempo para poner en marcha el entorno de DR aunque los datos estén actualizados). Por el contrario, un sistema puede tener un RPO holgado (24 horas, ya que basta con un respaldo nocturno), pero un RTO exigente (se requiere una conmutación por error en 1 hora, por lo que debe existir un entorno de DR previamente aprovisionado y listo para activarse). Ambas métricas proceden del análisis de impacto empresarial.

El tiempo medio de recuperación (MTTR) es el tiempo real promedio que se tarda en restaurar el servicio después de un incidente: la medida operativa del rendimiento de la recuperación. Mientras que el RTO es el tiempo de inactividad máximo tolerable (objetivo o requisito), el MTTR es el promedio observado (rendimiento real). Las organizaciones miden el MTTR de los incidentes a lo largo del tiempo y lo comparan con el RTO para evaluar su capacidad de recuperación. Un MTTR que supera constantemente el RTO indica que las capacidades de DR son insuficientes y que se requieren inversiones en automatización, personal o infraestructura.

El tiempo medio entre fallos (MTBF) mide la fiabilidad del sistema: el tiempo promedio que un sistema funciona entre fallos. Un MTBF más alto indica una mayor fiabilidad. El MTBF y el MTTR determinan conjuntamente el porcentaje de disponibilidad de un sistema: Disponibilidad = MTBF / (MTBF + MTTR). Un sistema con un MTBF de 2000 horas y un MTTR de 2 horas tiene una disponibilidad de 2000/2002 = 99,9 %. Comprender el MTBF ayuda a predecir cuándo es probable que ocurran fallos y a planificar en consecuencia las ventanas de mantenimiento; un hardware cuyo MTBF disminuye se acerca al final de su vida útil y debe sustituirse de forma preventiva.

El tiempo máximo de inactividad tolerable (MTD) es el tiempo máximo absoluto durante el que un sistema puede no estar disponible antes de que el negocio sufra daños irreversibles, como pérdida de clientes, sanciones regulatorias o incapacidad para cumplir obligaciones contractuales. El MTD siempre es mayor o igual que el RTO. La relación es la siguiente: el MTD es el límite del negocio; el RTO es el objetivo de TI. Si un contrato permite un incumplimiento del SLA de 4 horas antes de que se apliquen sanciones, el MTD podría ser de 4 horas. El equipo de TI diseña un RTO de 1-2 horas para disponer de un margen de seguridad antes de alcanzar el MTD.

Los acuerdos de nivel de servicio (SLA) definen compromisos contractuales con los clientes que determinan directamente los requisitos de RTO y RPO. Un SLA de un proveedor de nube que promete un 99,95 % de disponibilidad permite aproximadamente 4,4 horas de inactividad al año. El incumplimiento del SLA da lugar a créditos de servicio o derechos de rescisión del contrato. Los SLA internos entre TI y las unidades de negocio funcionan de forma similar. El RTO y el RPO deben diseñarse para mantener el tiempo de inactividad real dentro de los compromisos del SLA, y el MTTR debe medirse y notificarse para demostrar el cumplimiento.

Las decisiones tecnológicas están determinadas directamente por los requisitos de RTO y RPO. Un RTO de 15 minutos con RPO cero requiere un clúster activo-activo con replicación síncrona: sin pérdida de datos y con conmutación por error automática. Un RTO de 4 horas con un RPO de 1 hora puede utilizar el envío de registros o la replicación asíncrona a un sistema en espera templado. Un RTO de 24 horas con un RPO de 24 horas puede utilizar respaldos diarios en almacenamiento en frío. Diseñar una resiliencia superior a la necesaria desperdicia presupuesto; diseñar una inferior crea un riesgo empresarial inaceptable durante los incidentes.

Los objetivos de recuperación solo son válidos si se validan periódicamente mediante pruebas. Las organizaciones deben realizar pruebas de recuperación que midan el MTTR real y verifiquen el punto de recuperación de datos real (¿qué antigüedad tienen los datos cuando se restauran?). Si una prueba revela que el MTTR es constantemente de 3 horas frente a un RTO de 1 hora, se debe corregir la brecha, ya sea mejorando la infraestructura de DR (automatización, aprovisionamiento previo) o reajustando las expectativas del negocio mediante una BIA actualizada. La frecuencia de las pruebas debe corresponder a la criticidad: trimestralmente para los sistemas críticos y anualmente para los demás.

Los informes de RTO, RPO y MTTR deben comunicarse a las partes interesadas del negocio en términos que comprendan. En lugar de decir «nuestro MTTR para los sistemas de nivel 1 es de 47 minutos», diga «cuando fallan nuestros sistemas más críticos, restauramos el servicio en menos de una hora en promedio, dentro del margen de 2 horas que permiten nuestros contratos». Los informes periódicos generan confianza entre las partes interesadas y crean una comprensión compartida del nivel de resiliencia de la organización. Los paneles que muestran las tendencias del MTTR a lo largo del tiempo demuestran la mejora del programa y respaldan la justificación presupuestaria de las inversiones en DR.

Ponga a prueba su comprensión de los conceptos de CompTIA Security+ (SY0-701) de esta lección.

En esta lección ha aprendido que: el RTO es el tiempo máximo durante el que el servicio puede permanecer inactivo y determina los requisitos de velocidad de la conmutación por error; el RPO es la pérdida máxima de datos aceptable y determina la frecuencia de las copias de seguridad y la replicación; y el MTTR es el tiempo medio real de recuperación medido, que se compara con el RTO para evaluar la eficacia del programa de DR. A continuación, exploraremos las estrategias de copia de seguridad: la regla 3-2-1 y las copias de seguridad inmutables que el ransomware no puede destruir.