CompTIA SY0-701: Continuidad del Negocio y Recuperación ante Desastres — Guía de estudio

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Forma parte de la CompTIA Security+ SY0-701 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de CompTIA, o realiza tests cronometrados en ExamRoll.io.

La continuidad del negocio (BC) y la recuperación ante desastres (DR) forman la columna vertebral operativa de la resiliencia organizacional. Mientras que los controles de seguridad intentan prevenir incidentes, la planificación de BC/DR reconoce que algunas interrupciones —detonaciones de ransomware, huracanes, cortes de fibra, fallos en la red eléctrica o interrupciones en cascada de la nube— ocurrirán independientemente de las medidas preventivas. La disciplina se centra en cuantificar la interrupción tolerable, diseñar vías de recuperación y validar esas vías antes de que se necesiten.

Objetivos de recuperación: RTO, RPO, MTTR y MTBF

Dos métricas anclan toda conversación sobre recuperación, y confundirlas es uno de los errores más persistentes en los documentos de planificación. El Objetivo de Tiempo de Recuperación (RTO) expresa la duración máxima aceptable que un sistema puede permanecer no disponible después de una interrupción. Se mide en tiempo real, desde el momento del fallo hasta el momento en que los servicios se restauran a un estado utilizable.

El Objetivo de Punto de Recuperación (RPO), por el contrario, mide la tolerancia a la pérdida de datos: hasta qué punto en el tiempo la organización está dispuesta a perder transacciones. El RPO se mide hacia atrás desde el momento del fallo hasta el último punto de recuperación conocido y válido. Un RPO de quince minutos significa que el negocio puede tolerar la pérdida de hasta quince minutos de escrituras; en consecuencia, las copias de seguridad, la replicación o el envío de registros de transacciones deben ocurrir al menos con esa frecuencia.

La forma más clara de internalizar la distinción es una línea de tiempo: el RPO se sitúa a la izquierda de la interrupción (datos), y el RTO se sitúa a la derecha (tiempo de inactividad). Una réplica síncrona de base de datos entre dos zonas de disponibilidad podría ofrecer un RPO cercano a cero y un RTO de segundos mediante una conmutación por error automatizada. Una copia de seguridad nocturna en cinta enviada fuera del sitio ofrece, en el mejor de los casos, un RPO de 24 horas y un RTO medido en días.

Dos métricas de apoyo completan el vocabulario. El Tiempo Medio de Reparación (MTTR) es el tiempo promedio observado para restaurar un componente fallido, mientras que el Tiempo Medio Entre Fallos (MTBF) describe la fiabilidad. Un MTBF alto y un MTTR bajo son los objetivos de ingeniería que hacen alcanzables los RTOs agresivos.

Análisis de impacto en el negocio

Los valores de RTO y RPO no los elige el departamento de TI, sino que surgen de un Análisis de Impacto en el Negocio (BIA). El BIA identifica sistemáticamente los procesos de negocio, los asigna a los activos tecnológicos de soporte y cuantifica el daño operativo, financiero, regulatorio y de reputación que se acumula a medida que se prolonga una interrupción. Un sistema de nóminas puede tener un RTO modesto de 48 horas porque los cheques de pago se emiten quincenalmente, mientras que el registro electrónico de administración de medicamentos de un hospital puede requerir un RTO de minutos porque la seguridad del paciente se degrada de inmediato.

El BIA produce varios artefactos posteriores: un nivel de criticidad para cada sistema, el Tiempo de Inactividad Máximo Tolerable (MTD), que es el límite absoluto más allá del cual la recuperación carece de sentido, y los pares RTO/RPO que impulsan las decisiones de arquitectura. También saca a la luz las dependencias: recuperar un sistema de gestión de pedidos sin recuperar también su proveedor de autenticación, base de datos y pasarela de pago no produce nada utilizable.

Estrategias de sitios de recuperación

Cuando se pierde una instalación principal, las cargas de trabajo deben trasladarse a algún lugar. Los tres tipos canónicos de sitios alternativos intercambian costo por velocidad de recuperación.

Un sitio caliente (hot site) es un duplicado totalmente operativo de la producción. El hardware está instalado en racks, el software está licenciado y parcheado, y los datos se replican continuamente. La conmutación por error puede medirse en minutos o incluso segundos cuando se combina con un balanceo de carga global. Los sitios calientes ofrecen el RTO y RPO más bajos, pero conllevan el costo más alto, duplicando efectivamente el gasto en infraestructura.

Un sitio tibio (warm site) ocupa una posición intermedia. El hardware y la conectividad están instalados, y se instala algún software base, pero los datos no se replican continuamente; deben restaurarse desde una copia de seguridad, y la configuración final se completa durante la activación. Los sitios tibios suelen recuperarse en horas o hasta un día.

Un sitio frío (cold site) proporciona espacio físico, energía, refrigeración y conectividad a Internet, pero poco más. Los servidores deben ser enviados o adquiridos, los sistemas operativos instalados, las aplicaciones desplegadas y los datos restaurados desde copias de seguridad. Un sitio frío es económico de mantener, pero puede requerir días o semanas para ponerlo en funcionamiento. Tratar un sitio frío como un destino de conmutación por error rápida es un fallo de planificación recurrente; solo es apropiado para sistemas cuyo RTO se mide en días.

Las arquitecturas modernas dependen cada vez más de la recuperación basada en la nube —luz piloto (pilot light), espera tibia (warm standby) o activo/activo multirregión— lo que difumina estas categorías. Un diseño de luz piloto (pilot light) mantiene en funcionamiento servicios centrales mínimos (una base de datos replicada, por ejemplo) mientras que el resto de la pila se levanta desde plantillas de infraestructura como código bajo demanda.

Failover, Failback y Alta Disponibilidad

Failover (conmutación por error) es el acto de desviar el tráfico de un primario fallido a un sistema en espera (standby). Puede ser automático, impulsado por comprobaciones de estado y cambios de DNS o BGP, o manual, requiriendo autorización humana. Failback (retorno a la normalidad) —el retorno al primario original una vez reparado— a menudo se descuida en la planificación, pero conlleva su propio riesgo: los datos escritos en el sitio de conmutación por error durante la interrupción deben conciliarse y replicarse de vuelta antes del cambio, o se perderán las escrituras.

La redundancia a nivel de componente apoya estas estrategias. Los balanceadores de carga distribuyen el tráfico entre los nodos activos. Las bases de datos en clúster se replican de forma síncrona dentro de una región y de forma asíncrona entre regiones. RAID protege contra fallos de disco, pero no es una copia de seguridad. Las rutas de red redundantes, las fuentes de alimentación duales alimentadas desde PDU separadas y los circuitos de ISP diversos eliminan los puntos únicos de fallo dentro del centro de datos.

Continuidad Eléctrica: UPS, Generadores y Decisiones de Fallo en Abierto

La continuidad eléctrica es la base de todo. Un Sistema de Alimentación Ininterrumpida (UPS) cubre el lapso entre un fallo del suministro eléctrico y el arranque del generador, ofreciendo típicamente de 5 a 15 minutos de autonomía con baterías. Los generadores proporcionan energía de respaldo sostenida, generalmente de diésel o gas natural, y deben someterse a pruebas de carga con regularidad. Los contratos de combustible, el funcionamiento del conmutador de transferencia y las secuencias de arranque del generador fallan de forma silenciosa hasta que se ponen a prueba. Una prueba trimestral bajo carga real es mucho más reveladora que un simple arranque mensual en vacío.

Los dispositivos de seguridad plantean una cuestión aparte durante un fallo de alimentación o de software: ¿deberían fallar en modo abierto (fail-open) o fallar en modo cerrado (fail-closed)? Un firewall que falla en modo abierto permite el paso del tráfico cuando el dispositivo deja de funcionar, preservando la disponibilidad a costa de la seguridad. Un firewall que falla en modo cerrado bloquea todo el tráfico, preservando la seguridad a costa de la disponibilidad. Los controles de acceso físico se enfrentan al mismo dilema: una cerradura electrónica que falla en modo cerrado puede atrapar a los ocupantes durante un incendio, por lo que las normativas de seguridad humana suelen exigir un comportamiento de fallo en modo abierto (también llamado fail-safe o a prueba de fallos) para las vías de evacuación.

Pruebas: Ejercicio de Mesa, Recorrido, Simulación e Interrupción Total

Un plan que nunca ha sido probado es una hipótesis. Las pruebas progresan a lo largo de un espectro de realismo y riesgo.

Un ejercicio de mesa (tabletop exercise) reúne a las partes interesadas alrededor de una mesa de conferencias para discutir un escenario: «un ataque de ransomware ha cifrado el clúster principal de VMware a las 2 a.m. del domingo; guíenme a través de las próximas seis horas». Este ejercicio saca a la luz carencias en la documentación, listas de contactos, autoridad para la toma de decisiones y suposiciones. No conlleva ningún riesgo operativo y es el punto de partida adecuado.

Un recorrido (walkthrough) o revisión estructurada examina el propio documento del plan en busca de precisión. Una simulación introduce la interpretación de roles e inyecta eventos. Una prueba en paralelo pone en línea el sitio de recuperación junto con el de producción sin realizar la conmutación. La forma más rigurosa, una prueba de interrupción total, conmuta realmente la producción al sitio de recuperación; es costosa, disruptiva y la única prueba que demuestra que el plan realmente funciona.

Toda prueba debe incluir el plan de reversión (backout plan): cómo revertir la situación si el propio proceso de conmutación por error (failover) falla o corrompe los datos. Las pruebas de carga de los generadores, los simulacros de restauración de copias de seguridad y las activaciones del árbol de comunicaciones pertenecen al mismo calendario recurrente que la aplicación de parches de software.

Escenario Práctico: Un Plan de Recuperación No Probado Falla Durante un Incidente Real

El plan de recuperación ante desastres (DR) de un banco regional especificaba un sitio tibio (warm site) con un RTO de cuatro horas para su sistema bancario central. El plan se había redactado tres años antes y se había revisado anualmente en papel, pero nunca se había probado mediante una activación real. Cuando una descarga del sistema de extinción de incendios destruyó la infraestructura de refrigeración del centro de datos principal, el banco intentó activar el sitio tibio. El equipo descubrió que el sistema operativo del servidor de respaldo estaba dos versiones principales por detrás de la versión de producción actual y era incompatible con la versión actual de la aplicación. Las tareas de copia de seguridad de la base de datos habían estado fallando silenciosamente durante seis semanas debido a la expiración de un certificado en el agente de backup. La recuperación real tardó 31 horas —casi ocho veces el RTO documentado— y el banco fue objeto de un escrutinio regulatorio por la brecha entre sus capacidades de recuperación documentadas y las reales. La lección: el RTO y el RPO son compromisos de ingeniería, no objetivos aspiracionales, y deben ser validados mediante pruebas realistas al menos una vez al año.

← Seguridad de Datos · Todos los dominios · Seguridad de Endpoints →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →