🔮 Alta disponibilidad (High Availability - HA)

1. ALEGORÍA 🧠

Imagina que tu sistema es un castillo mágico que protege un reino. No importa si llueve, hay terremotos o dragones atacan: el castillo nunca puede caerse. Para lograrlo, el reino construye puentes dobles, torres de vigilancia gemelas, y hasta cámaras secretas subterráneas por si una parte falla.

Ese castillo es tu infraestructura IT, y los mecanismos que permiten que siempre funcione –pase lo que pase– es lo que llamamos Alta disponibilidad (HA).

2. DEFINICIÓN

Alta disponibilidad (HA) - High Availability es una estrategia de diseño e implementación de sistemas que busca minimizar el tiempo de inactividad, asegurando que los servicios, datos y recursos críticos estén siempre disponibles.

Implica tolerancia a fallos, redundancia de componentes, conmutación por error automática y ubicación geográfica distribuida.

3. TERMINOLOGÍA CLAVE

• Alta disponibilidad- High Availability (HA)

• Conmutación por error - Failover

• Tolerancia a fallos  - Fault Tolerance

• Equilibrio de carga - Load Balancing

• Tiempo de inactividad máximo tolerable  - Maximum Tolerable Downtime (MTD)

• Recuperación ante desastres - Disaster Recovery (DR)

• Dispersión geográfica - Geographical Distribution

• Sitio caliente / tibio / frío - Hot / Warm / Cold Site

4. EJEMPLOS Y ESCENARIOS

• Un banco que necesita que su plataforma de banca online esté disponible 24/7 implementa clústeres de servidores y sitios de respaldo en otra ciudad.

• Un hospital que depende de sistemas para monitorizar signos vitales usa fuentes de energía redundantes y redes duplicadas.

5. HERRAMIENTAS Y TECNOLOGÍAS

• Balanceadores de carga: NGINX, HAProxy, AWS Elastic Load Balancer

• Clústeres de alta disponibilidad: Proxmox HA, VMware vSphere HA, Pacemaker

• Replicación y respaldo: Rsync, Veeam, Azure Site Recovery

• Cloud DR y escalado automático: AWS, Azure, GCP

• Monitorización y pruebas: Nagios, Zabbix, SolarWinds

6. BUENAS PRÁCTICAS

🔎 Resumen: Las buenas prácticas en HA consisten en diseñar para el fallo, anticiparse a los desastres y asegurar continuidad operacional.

• 1. Evitar puntos únicos de fallo (Single Point of Failure - SPOF)

  Un SPOF es cualquier componente cuya falla haría que todo el sistema deje de funcionar.
  🔍 Ejemplo realista: Si un solo servidor DNS se cae y no hay uno secundario, nadie puede acceder a los servicios.
  Buena práctica: Diseñar la arquitectura con duplicación en cada capa (servidores, redes, energía) para garantizar continuidad incluso si un elemento falla.

  2. Implementar pruebas periódicas de conmutación por error (Failover Testing)

  Estas pruebas simulan fallos para validar que los sistemas cambien automáticamente a sus copias redundantes.
  🔍 Ejemplo: Desconectar un nodo del clúster de servidores para comprobar si otro toma el control sin afectar al usuario final.
  Buena práctica: Programar estas pruebas en entornos controlados o de staging para verificar que los scripts y mecanismos de failover funcionen correctamente.

  3. Usar redundancia geográfica

  Esto significa distribuir recursos y datos en diferentes ubicaciones físicas, alejadas entre sí.
  🔍 Ejemplo: Tener un sitio principal en Madrid y uno secundario en A Coruña, para protegerse ante desastres regionales como apagones o incendios.
  Buena práctica: Replicar servicios y bases de datos entre estos sitios, con sincronización continua o en intervalos definidos según el nivel de criticidad.

  4. Establecer un plan de pruebas de carga (Load Testing Plan)

  Estas pruebas simulan tráfico elevado o uso intensivo de recursos para ver cómo responde el sistema.
  🔍 Ejemplo: Simular 100.000 usuarios accediendo al mismo tiempo a una web bancaria.
  Buena práctica: Utilizar herramientas como Apache JMeter, Locust o Gatling para encontrar cuellos de botella y asegurar que el sistema puede escalar bajo demanda.

  5. Monitorear continuamente los sistemas (Monitoring & Alerting)

  El monitoreo proactivo permite detectar fallos antes de que afecten al usuario.
  🔍 Ejemplo: Un sistema de alertas que notifica cuando un disco está al 95% de capacidad o un CPU sobrecargado.
  Buena práctica: Integrar soluciones como Zabbix, Prometheus, Datadog, o Nagios, con alertas configuradas por niveles de criticidad (INFO, WARNING, CRITICAL).

7. ERRORES COMUNES

• Solo confiar en backups sin validarlos

• No tener failover automático

• No documentar rutas de recuperación

• No testear la escalabilidad bajo carga real

• Subestimar el tiempo de recuperación

8. NORMATIVAS Y FRAMEWORKS RELACIONADOS

• Continuidad de operaciones (en negrita) - Continuity of Operations Plan (COOP)

• Planes de recuperación ante desastres (en negrita) - Disaster Recovery Plans (DRP)

• ISO/IEC 27031 - Directrices para continuidad de servicios

• NIST SP 800-34 - Contingency Planning Guide for Federal Information Systems

9. CHECKLIST OPERATIVA 🛠️

✅ Definí sistemas críticos que no pueden fallar
✅ Identificá puntos únicos de fallo (SPOF)
✅ Diseñá redundancia para cada capa: red, servidor, energía, ubicación
✅ Configurá monitoreo y alertas automáticas
✅ Probá regularmente con escenarios de desastre
✅ Tené un sitio caliente o una solución en la nube para recuperación
✅ Asegurá compliance con estándares (ISO, NIST)

10. ENFOQUES 3x3 🔍

🔴 RED TEAM

• Simulación de fallo físico: Cortar red eléctrica en una zona para evaluar la conmutación.

• Ataques a balanceadores: DDoS o manipulación de DNS round robin.

• Ataques en sitios fríos: Aprovechar infraestructuras sin protección activa.

🔵 BLUE TEAM

• Monitoreo en tiempo real del estado de conmutadores, servidores y balanceadores.

• Pruebas de recuperación: Realizar failover planeado y documentado.

• Defensas segmentadas: Redundancia + segmentación lógica + IDS distribuidos.

🟣 PURPLE TEAM

• Pruebas coordinadas: Simular fallos mientras se testean alertas y recuperación.

• Análisis post-fallo: ¿Se activó el failover? ¿Hubo pérdida de datos o alertas fallidas?

• Automatización de recuperación: Ensayar scripts automáticos de conmutación y validar la resiliencia.

Ejemplos prácticos Purple Team

💥 Ejemplo 1: Fallo inducido en el sistema primario (DoS sobre nodo activo)

• Red Team ataca provocando un DoS (Denegación de Servicio) sobre el nodo principal para forzar el failover al sistema secundario. Aprovecha este momento para observar vulnerabilidades en la conmutación por error.

• Blue Team lo defiende detectando anomalías de tráfico con un IDS/IPS, activando alertas de disponibilidad, y verificando la correcta transición al nodo secundario sin pérdida de datos ni sesiones.

• Purple Team lo gestiona diseñando un playbook de failover probado con simulacros, asegurando que ambos sistemas (primario y secundario) estén continuamente sincronizados y protegidos, con monitoreo activo en ambos entornos.

💥 Ejemplo 2: Compromiso del balanceador de carga

• Red Team ataca explotando una mala configuración del balanceador de carga para redirigir tráfico a un servidor vulnerable que no está parcheado.

• Blue Team lo defiende validando reglas de enrutamiento, revisando registros del balanceador y asegurando autenticación mutua y certificados válidos entre componentes.

• Purple Team lo gestiona implementando revisiones periódicas de configuración con escaneo de seguridad automatizado (por ejemplo, Nessus), y gestionando el ciclo de vida de los certificados y credenciales en el balanceador.

💥 Ejemplo 3: Acceso al sitio de recuperación mal asegurado

• Red Team ataca aprovechando que el sitio de recuperación (cold site o warm site) no está debidamente protegido ni actualizado, lo que permite pivotar y mantener persistencia.

• Blue Team lo defiende configurando los mismos controles de seguridad y monitoreo en los sitios secundarios: control de acceso físico, MFA, hardening del sistema y replicación segura.

• Purple Team lo gestiona incluyendo los sitios de recuperación en los análisis de riesgo y auditorías regulares, además de aplicar Zero Trust (ZTNA) a todo el entorno distribuido.

💥 Ejemplo 4: Manipulación del canal de replicación

• Red Team ataca interceptando o saboteando el canal de replicación entre nodos, inyectando latencia o manipulando los datos transmitidos.

• Blue Team lo defiende usando cifrado robusto punto a punto (TLS 1.3) y validaciones de integridad con hash para asegurar la consistencia de los datos replicados.

• Purple Team lo gestiona documentando el canal de replicación como activo crítico, auditando su seguridad y simulando ataques internos para validar su robustez.

💥 Ejemplo 5: Engaño en el sistema de monitoreo (falsos positivos o negativos)

• Red Team ataca manipulando el sistema de monitoreo para generar falsas alertas o suprimir las reales, con el objetivo de desactivar las respuestas automáticas.

• Blue Team lo defiende implementando validación cruzada de métricas, integración con SIEM y detección de anomalías basada en comportamiento (UEBA).

• Purple Team lo gestiona creando redundancia en las fuentes de monitoreo, y programando revisiones cruzadas periódicas del sistema de alertas con un equipo mixto de Red y Blue.

💥 Ejemplo 6: Ataque durante pruebas de conmutación por error

• Red Team ataca durante una simulación planificada, sabiendo que los equipos están centrados en la prueba y no esperando una intrusión real.

• Blue Team lo defiende manteniendo una monitorización activa incluso durante ejercicios, y aplicando límites de acceso estrictos al entorno de pruebas.

• Purple Team lo gestiona coordinando simulacros "Red vs Blue" reales, validando no solo la capacidad técnica, sino también la respuesta y coordinación humana.

🛠️ NIVEL AVANZADO – Dominio Técnico Funcional

🧨 Ejemplo 1: Ataque durante un failover programado

• Red Team: Lanza un ataque DDoS justo cuando se ejecuta una conmutación por error (failover), sabiendo que los recursos están ocupados en la transición y la visibilidad puede ser limitada.

• Blue Team: Usa un WAF + IPS en modo activo, segmenta el tráfico malicioso y utiliza mecanismos de autoescalado para absorber el impacto sin comprometer la conmutación.

• Purple Team: Evalúa las métricas de tiempo de conmutación real vs. esperado, documenta puntos débiles y entrena al equipo Blue sobre alertas durante ventanas de mantenimiento.

🧨 Ejemplo 2: Acceso lateral desde clúster mal segmentado

• Red Team: Consigue acceso a un nodo de clúster de servidores de aplicaciones y se mueve lateralmente para llegar al nodo del backend, aprovechando permisos demasiado amplios en la red interna.

• Blue Team: Detecta el movimiento lateral con alertas de comportamiento (UEBA), aplica microsegmentación entre los nodos y restringe accesos con Zero Trust NAC.

• Purple Team: Crea un playbook para evaluar configuraciones de segmentación cada trimestre y realiza un pentest en los clústeres tras cada parcheado mayor.

🧨 Ejemplo 3: Apagado físico de redundancia eléctrica

• Red Team: Explora la posibilidad de un sabotaje físico (ej: acceso al panel eléctrico o al generador de respaldo en un sitio secundario mal protegido).

• Blue Team: Instala sensores de intrusión física y vigilancia activa en zonas de soporte vital, y activa notificaciones de energía UPS en el SIEM.

• Purple Team: Integra seguridad física + cibernética, revisa el plan BCP e incluye entrenamiento sobre fallos de energía y continuidad de TI.

🧠 NIVEL EXPERTO – Red, Blue y Purple con coordinación avanzada

⚔️ Ejemplo 4: Desincronización de bases de datos durante la replicación

• Red Team: Aprovecha un desfase en la replicación para lanzar un ataque de corrupción de datos: introduce modificaciones falsas en el nodo activo antes del próximo sync.

• Blue Team: Implementa hashes de verificación + snapshots programados, alerta cuando los hash de integridad no coinciden tras el sync.

• Purple Team: Diseña una estrategia de validación cruzada automatizada (CI/CD + controles de consistencia de datos), y entrena sobre detección temprana de corrupción lógica.

⚔️ Ejemplo 5: Engaño al sistema de detección redundante

• Red Team: Genera ruido controlado (ruido blanco digital) en los sensores duplicados para causar falsos positivos y que los analistas pierdan foco.

• Blue Team: Aplica filtros avanzados de correlación y alertas por patrones anómalos en tiempo y forma (detección basada en comportamiento, no firma).

• Purple Team: Organiza simulacros donde el Red Team lanza falsos positivos durante un ataque real y mide el tiempo de reacción, reajusta umbrales y respuestas automáticas.

⚔️ Ejemplo 6: Abuso del balanceador de carga

• Red Team: Manipula los headers HTTP para eludir reglas del balanceador y acceder directamente a servidores backend.

• Blue Team: Usa inspección profunda (Layer 7) con reglas que analizan encabezados anómalos, y fuerza autenticación mutua TLS backend-backend.

• Purple Team: Documenta bypass conocidos y valida configuraciones cada mes; genera un módulo de hardening del balanceador como parte del pipeline de infraestructura.

🧙‍♀️ NIVEL MAESTRO – Coordinación total, crisis y recuperación estratégica

🌀 Ejemplo 7: Ataque durante desastre natural real

• Red Team: Simula un ataque APT mientras la empresa enfrenta un evento real (terremoto, tormenta, incendio), esperando que se use el cold site o el warm site sin controles actualizados.

• Blue Team: Activa respuesta de emergencia según el plan BCP, conecta solo a través de VPN reforzada, aplica just-in-time access y mantiene visibilidad completa gracias a herramientas en la nube.

• Purple Team: Realiza un ejercicio de crisis total donde se combina desastre físico + ataque cibernético + cambio de entorno, y documenta los aprendizajes para mejorar la resiliencia organizacional global.

🌀 Ejemplo 8: Ataque a la cadena de suministro de HAaaS (High Availability as a Service)

• Red Team: Compromete el proveedor de HA de terceros (por ejemplo, backups automáticos mal gestionados o infraestructura compartida vulnerable).

• Blue Team: Monitorea integridad del proveedor con auditorías constantes, validación de SLA y herramientas de detección de cambios inesperados en configuraciones.

• Purple Team: Añade proveedores HA a la matriz de amenazas de la organización, desarrolla simulacros conjuntos con ellos y asegura cláusulas contractuales de visibilidad y cooperación durante incidentes.

🌀 Ejemplo 9: Simulacro realista de ataque a infraestructura multisitio sincronizada

• Red Team: Lanza un ataque sincronizado en varios sitios geográficos (cloud híbrida + on-prem) para saturar a los equipos de respuesta en diferentes husos horarios.

• Blue Team: Coordina a través de una sala de guerra virtual (SOAR centralizado + respuesta distribuida), escalando decisiones a través de flujos automáticos según región e impacto.

• Purple Team: Ejecuta un ejercicio de mesa + ataque técnico en paralelo, con todas las áreas (técnica, legal, directiva), y saca métricas de tiempo, calidad de respuesta y resiliencia estratégica.