Hay una conversación que se repite en casi todas las due diligence técnicas que he visto en los últimos tres años. El CTO enseña la arquitectura: un cluster de virtualización en su datacenter o en colocation, conectado por VPN o circuito dedicado a un entorno de nube pública donde corre la parte nueva del producto, una suite de productividad en SaaS y un par de aplicaciones verticales colgando del directorio corporativo. `»Híbrido», dice, y la palabra se pronuncia como si fuera una decisión arquitectónica meditada. No lo es. Es el resultado sedimentario de quince años de decisiones individualmente razonables que nunca se sentaron a hablar entre sí.
Y ese es exactamente el problema. La nube pública, sola, tiene un modelo de seguridad imperfecto pero coherente: identidad federada, todo es API, todo se audita, todo se puede expresar como código. La nube privada tradicional tiene otro modelo, también coherente a su manera: perímetro de red, segmentación por VLAN, directorio on-premise, firewalls físicos, ventanas de mantenimiento. El híbrido es donde ambos modelos se tocan sin integrarse, y la zona de contacto es el sitio más vulnerable de toda tu infraestructura. Es la costura, y las costuras es por donde se rompe la ropa.
Dónde se rompe: tres costuras mal cosidas
La identidad parte la organización en dos países
La mayoría de empresas medianas siguen teniendo un directorio on-premise como fuente de verdad histórica, sincronizado al directorio cloud del proveedor de productividad. En el papel suena bien: una identidad, dos planos. En la práctica el sync es unidireccional y parcial, las contraseñas se gestionan en sitios distintos según el caso, y los grupos que controlan permisos críticos en la nube pública están anidados en grupos del directorio on-prem que un administrador junior puede modificar sin que salte una alerta. El problema serio, sin embargo, no son las identidades humanas: son las identidades no humanas, las credenciales que usa un servidor del CPD para hablar con una base de datos gestionada en la nube pública. En la mayoría de entornos esas credenciales son claves estáticas guardadas en ficheros de configuración, rotadas por última vez cuando se montó el sistema. Si ese servidor on-prem cae a un ransomware, el atacante no necesita vulnerar la nube pública; ya tiene credenciales legítimas para entrar por la puerta principal.
La red híbrida es un perímetro que nadie ha dibujado
Cuando montas el túnel o el circuito dedicado entre tu CPD y la nube pública estás creando una extensión de red. Ese enlace, por defecto, es routing plano: cualquier carga en la nube pública puede hablar con cualquier servidor del CPD que esté en el rango anunciado, y al revés. He visto entornos donde el equipo de cloud había segmentado primorosamente su lado —subredes privadas, reglas de microsegmentación, control granular— y el lado on-prem era un descampado, porque «ese tráfico es interno». El concepto de «interno» sobrevive del mundo de los noventa y en híbrido es activamente peligroso. Tu red interna ya no es tuya; la mitad corre en un hipervisor que no es tuyo. A esto se suma el problema del DNS partido: quién resuelve qué, qué pasa con los nombres internos que coinciden, cómo se comporta la resolución cuando un servicio se mueve de on-prem a cloud. Cada uno de estos detalles es una oportunidad para que algo falle silenciosamente hasta que un cliente llame enfadado.
La responsabilidad compartida no aplica igual a los dos lados, y nadie lo escribe
En la nube pública el modelo está documentado hasta la náusea. En tu CPD eres responsable de todo, y el equipo de sistemas lo asume con naturalidad. El problema aparece en los servicios que cruzan la frontera. El ERP corre on-prem pero los backups se replican a almacenamiento de objetos en la nube pública por coste: ¿quién garantiza que ese almacenamiento tiene protección contra borrado e inmutabilidad activadas? ¿Quién prueba la restauración cross-site, no solo el backup? Una aplicación on-prem expone una API a internet a través de un balanceador en la nube pública porque montar el WAF allí es más fácil: ¿quién es dueño de actualizar las reglas cuando el OWASP Top 10 cambia? La responsabilidad compartida en híbrido no es entre tú y el proveedor; es entre tu equipo on-prem y tu equipo cloud, y en organizaciones de +100 empleados esos equipos son a veces dos personas que no están alineadas o sincronizadas.
Lo que cuesta cuando pasa
El incidente híbrido tiene un patrón económico distinto al puramente cloud. En cloud el daño se acota razonablemente: una cuenta comprometida, unos recursos, un blast radius medible. En híbrido, el ransomware que entra por on-prem cifra el CPD y, si las credenciales cloud estaban en los servidores comprometidos, también te quema los backups en la nube pública. Has pagado por redundancia y has comprado correlación: ambas copias caen porque la cadena de confianza era una sola. A esto se añade el coste regulatorio: explicarle a la AEPD que los datos personales viajaban entre tu CPD y una región cloud sin análisis de transferencia documentado, o a un auditor de ISO 27001 que los grupos del directorio on-prem podía tocarlos cualquier admin de dominio, son conversaciones que se ganan o se pierden antes de empezar.
Cómo se cose: una hoja de ruta que funciona
La buena noticia es que ninguno de estos problemas exige reinventar la arquitectura. Exigen tratar el híbrido como un sistema único en lugar de como dos sistemas conectados. Cuatro movimientos, en este orden, resuelven la mayor parte del riesgo en un horizonte de seis a nueve meses.
Unifica el plano de identidad y elimina las claves estáticas
Designa una única fuente de verdad —típicamente el directorio cloud, con el on-prem subordinado, o al revés si tu realidad lo exige— y federa todo lo demás vía estándares abiertos (SAML, OIDC). Pero el movimiento que de verdad cambia tu postura es acabar con las credenciales estáticas para cargas de trabajo. Los tres grandes proveedores cloud ofrecen federación de identidades de carga (workload identity federation, IAM Roles Anywhere y equivalentes) que permiten a un servidor on-prem autenticarse contra la nube pública usando certificados o tokens de corta vida, sin que exista una clave robable en disco. Es la inversión con mejor retorno de seguridad del año: la credencial que no existe no se filtra, no se rota y no aparece en un dump de ransomware.
Mete inspección en la costura
El enlace entre tu CPD y tu nube pública no debe ser un cable virtual transparente; debe pasar por un punto donde inspecciones, segmentes y registres. Esto se puede materializar de varias formas según tu realidad: un firewall de nueva generación virtualizado en el lado cloud, un servicio gestionado de firewall del proveedor, o —donde tenga sentido operativo— un servicio gestionado por un partner especializado que te quite el peso de mantener la pieza. La regla arquitectónica es la misma independientemente del producto: el tráfico que llega del CPD se trata como tan no-confiable como el que llega de internet. Zero Trust no es un eslogan, es decidir que el túnel no te da permisos. Aprovecha el mismo proyecto para sanear el DNS: una jerarquía de resolución clara, sin solapamientos entre zonas internas y cloud, con logging centralizado.
Escribe la matriz de responsabilidad antes del próximo incidente
Una hoja, un servicio por fila, columnas para «responsable de configuración», «responsable de parche», «responsable de monitorización», «responsable de respuesta». Si alguna celda queda vacía, ese servicio es tu primera prioridad. Si dos celdas dicen lo mismo cuando no deberían, ese es el segundo problema. Este ejercicio parece administrativo y es profundamente técnico: obliga a que alguien decida, con nombre y apellidos, quién aplica el siguiente parche al WAF que protege la API on-prem, quién valida la inmutabilidad del bucket de backup, quién mira las alertas del directorio sincronizado un sábado por la noche. En organizaciones medianas donde el equipo es limitado, esta matriz es también la herramienta que justifica externalizar piezas concretas —monitorización 24×7, gestión del firewall híbrido— en lugar de fingir que todo se cubre internamente.
Prueba la recuperación de verdad
Apaga deliberadamente un servicio crítico y restáuralo desde el backup de la nube pública —o desde el on-prem si el primario está en cloud—. Mide cuánto tarda. Verifica que las credenciales necesarias para la restauración no dependen del sistema que acabas de «perder». La primera vez será humillante, y por eso hay que hacerla antes de que lo haga un incidente. Esta prueba, repetida trimestralmente, es lo que separa un plan de continuidad documental de uno que funciona.
Cierre
La seguridad híbrida no falla en el CPD ni falla en la nube pública. Falla en el espacio mental donde nadie ha decidido aún si lo que tiene delante es una cosa o son dos. La diferencia entre las organizaciones que sufren incidentes graves y las que no, en mi experiencia, no es presupuesto ni herramientas: es que las segundas trataron el híbrido como un sistema único desde el día uno, con un plano de identidad coherente, una red con costuras inspeccionadas y una matriz de responsabilidad escrita.
Hacerlo no es barato, pero es perfectamente alcanzable para una organización de 100 a 500 empleados que decida priorizarlo. Lo que no es alcanzable es el plan alternativo: tener lo peor de los dos mundos, la rigidez del on-prem y la opacidad del cloud, unidas por un túnel que nadie vigila, y esperar que el incidente le toque a otro.
