Arquitectura de referencia para la seguridad en la nube híbrida

Una arquitectura de referencia de seguridad en la nube híbrida es un modelo independiente de proveedores que muestra cómo se interconectan los controles de seguridad entre la infraestructura local, la nube privada, el SaaS y la nube pública. Se utiliza para planificar implementaciones, comparar proveedores, explicar el diseño de seguridad a los auditores y medir el progreso hacia el modelo «zero trust».

Este artículo ofrece un modelo de referencia completo: los principios de diseño en los que se basa, diagramas lógicos y de implementación, una referencia de componentes, seis flujos de tráfico, límites de control, consideraciones de diseño relativas a la identidad, el registro, la capacidad y la resiliencia, una correspondencia con los controles de la CISA y el NIST, cinco ejemplos de implementación y una trayectoria de madurez con pruebas de validación.

Este artículo forma parte de la guía sobre seguridad en la nube híbrida. Para obtener una visión general de la infraestructura de los entornos híbridos, consulte «Arquitectura de la nube híbrida: componentes y modelos de implementación».

Principios de diseño en los que se basa el modelo de referencia

El modelo de referencia se basa en cuatro principios extraídos de las directrices sobre el modelo «zero trust» del NIST y la CISA.

1. Separe las decisiones de la aplicación. La norma NIST SP 800-207 distingue entre el punto de decisión de la política (PDP), que determina si se permite el acceso, y el punto de aplicación de la política (PEP), que habilita, supervisa o interrumpe la conexión. Un PDP, varios PEP.
2. No conceda confianza basándose en la ubicación en la red. El hecho de encontrarse en la LAN corporativa no es motivo para omitir la autenticación o la inspección. La norma NIST SP 800-215 describe la desaparición de un perímetro significativo como una característica definitoria de las redes empresariales actuales.
3. Proteja los datos en función de su clasificación, no de su ubicación. Los controles siguen a la clase de datos allá donde se desplace.
4. Supongamos que cualquier dependencia concreta puede fallar. Los proveedores de identidad, los servicios en la nube y los enlaces WAN dejan de funcionar. La arquitectura define qué ocurre cuando esto sucede.

La guía práctica SP 1800-35 del NIST , titulada «Implementación de una arquitectura de confianza cero», publicada en junio de 2025 con la colaboración de 24 proveedores, presenta 19 ejemplos de implementación de estos principios tanto en entornos locales como en la nube, y constituye un complemento útil para este modelo.

Diagramas de arquitectura

La arquitectura de referencia se describe mediante dos perspectivas: una perspectiva lógica de sus planos y una perspectiva de implementación que muestra dónde se ejecutan los componentes.

Arquitectura lógica

La arquitectura lógica consta de tres planos: un plano de control centralizado, un plano de aplicación distribuido y un plano de visibilidad compartido.

El plano de control define la política una sola vez. El plano de aplicación la aplica allá donde fluya el tráfico. El plano de visibilidad recopila datos de telemetría de cada punto de aplicación y transmite las señales de riesgo de vuelta a la política.

Topología de implementación

La vista de implementación muestra dónde se ejecuta físicamente cada punto de aplicación en la sede central, las sucursales, las regiones en la nube y los usuarios remotos.

Referencia de componentes

Cada componente tiene una función, una ubicación y un conjunto de requisitos específicos para sistemas híbridos bien definidos.

Flujos de tráfico

Seis flujos de tráfico abarcan la mayor parte de las redes híbridas, y cada uno de ellos debe contar con un punto de aplicación documentado y un punto de descifrado.

Flujo 1: Usuario de Office a Internet o SaaS

El usuario se autentica a través del proveedor de identidad. El tráfico se dirige a la pasarela local, que lo descifra, comprueba si hay amenazas y aplica la política de web y de acceso; a continuación, reenvía las sesiones sujetas a la protección de datos a la nube del proveedor para su inspección con arreglo a la misma política. Documente la terminación y el recifrado de TLS a lo largo de esta ruta y evite la inspección redundante, de conformidad con las directrices de la NSA sobre la gestión del riesgo de inspección de TLS.

Flujo 2: Usuario remoto a SaaS

El agente del terminal o los controles del navegador dirigen el tráfico hacia el punto de presencia en la nube autorizado más cercano. Se aplica el mismo conjunto de políticas que en el Flujo 1. El CASB añade controles específicos para SaaS, como restricciones por inquilino y DLP a nivel de actividad.

Flujo 3: Del usuario a la aplicación privada

El acceso se realiza a través de ZTNA, no mediante una VPN a nivel de red. El servicio de acceso comprueba la identidad, el estado del dispositivo y la política de seguridad, y a continuación conecta al usuario únicamente a una aplicación autorizada. Una implementación puede utilizar un intermediario en la nube para los usuarios remotos y una pasarela local para las sesiones presenciales compatibles. Confirme la ubicación del intermediario, los protocolos de las aplicaciones, la visibilidad de las sesiones y la ruta real de los datos. Consulte «ZTNA local para aplicaciones privadas».

Flujo 4: De una carga de trabajo a otra

El tráfico de servicio a servicio entre el centro de datos y las cargas de trabajo de IaaS utiliza la identidad de la carga de trabajo, el protocolo TLS mutuo y las reglas de segmentación. La misma fuente de política define qué servicios pueden comunicarse entre sí.

Flujo 5: Datos en reposo en servicios en la nube

La integración de la API de CASB y el análisis de DSPM examinan los servicios de almacenamiento en la nube y SaaS autorizados en busca de datos confidenciales, compartición de riesgo y permisos excesivos, y posteriormente aplican medidas correctivas utilizando la misma clasificación aplicada en tiempo real. Consulte cómo funcionan conjuntamente DSPM y SSE.

Flujo 6: Agentes de IA y cuentas de servicio

Los agentes de IA y la automatización suelen disponer de acceso a nivel de usuario y realizar llamadas a API internas a través de conexiones de larga duración, incluidos los WebSockets, que se originan dentro de la red. Asigne a cada agente su propia identidad y derechos específicos para cada aplicación, dirija su tráfico a través de un punto de control local y aplique la prevención de fugas de datos (DLP) a lo que envía a los servicios externos de IA.

Límites de control

Los límites de control deben trazarse en torno a lo que hay que proteger, no en torno a la ubicación de los equipos.

A menudo se pasa por alto el límite jurisdiccional. Si el tráfico descifrado, los registros de inspección o las copias de incidentes de DLP salen de una jurisdicción, la arquitectura podría incumplir los compromisos de residencia, incluso cuando los datos almacenados nunca se trasladen. Véase «Soberanía de los datos en la seguridad de la nube híbrida».

Seguridad de red para la nube híbrida

La seguridad de red en un entorno híbrido pasa de centrarse en la protección del perímetro a centrarse en la protección de las conexiones individuales.

• Sustituya la confianza plana entre sitios por la segmentación y el acceso por aplicación.
• Mantenga túneles cifrados (IPsec, GRE o interconexiones privadas) entre los centros y las regiones en la nube, pero no considere la pertenencia a un túnel como una autorización.
• Dirija el tráfico de forma deliberada: proxy explícito o archivos PAC para redes de oficina gestionadas, agentes o controles del navegador para usuarios itinerantes, túneles para sucursales.
• Decida qué componente descifra cada flujo, de modo que ningún flujo se descifre dos veces.
• Registre los datos en cada punto de control y realice una correlación de forma centralizada.

El documento NIST SP 800-215 analiza estas opciones, entre las que se incluyen el ZTNA, la microsegmentación, los perímetros definidos por software y los modelos de «Secure Access Service Edge» (SASE), que combinan servicios de red y de seguridad.

Consideraciones de diseño

Hay cuatro aspectos de diseño que determinan si la arquitectura funciona en la práctica: la identidad, el registro, la capacidad y el comportamiento ante fallos.

Arquitectura de identidad

La identidad es el primer factor que se tiene en cuenta en toda decisión de acceso, por lo que la arquitectura de referencia considera cuatro tipos de identidad como elementos fundamentales.

• Usuarios de Workforce. Un único proveedor de identidad de referencia, federado con todos los proveedores de servicios en la nube y todas las aplicaciones SaaS, que cuente con autenticación multifactorial (MFA) resistente al phishing y acceso condicional. Los datos relativos a grupos y roles deben proceder de una única fuente, de modo que los derechos de acceso no varíen entre los distintos entornos.
• Dispositivos. Se debe evaluar la identidad y el estado de los dispositivos (estado de gestión, nivel de parches, cifrado de disco, protección de terminales) tanto para los usuarios que se encuentran en las instalaciones como para los que trabajan a distancia.
• Cargas de trabajo y servicios. Las aplicaciones y los servicios se autentican entre sí mediante identidades de carga de trabajo y TLS mutuo, en lugar de secretos compartidos o la ubicación en la red.
• Agentes de IA y automatización. Cada agente cuenta con su propia identidad, derechos limitados a un ámbito concreto y un responsable humano, de modo que sus acciones pueden autorizarse, registrarse y revocarse de forma independiente.

Hay dos detalles de diseño que pueden pasar fácilmente desapercibidos. En primer lugar, las sesiones deben reevaluarse cuando cambie el contexto —por ejemplo, si un dispositivo deja de cumplir los requisitos de conformidad— en lugar de darse por válidas hasta su vencimiento. En segundo lugar, defina un acceso de emergencia para los administradores que funcione cuando el proveedor de identidad no esté disponible, con controles estrictos y alertas sobre su uso.

Registro y telemetría

El registro de datos en una arquitectura híbrida debe servir para la detección, la investigación y el cumplimiento normativo, respetando al mismo tiempo las restricciones sobre el destino de los datos.

• Qué datos se deben recopilar. Cada punto de aplicación debe registrar el usuario, el dispositivo, la aplicación o el destino, la decisión de política, la regla a la que se ha ajustado y la clasificación de datos correspondiente. Utilice claves de correlación comunes (ID de usuario, ID de dispositivo, ID de sesión) para que se puedan unir los eventos procedentes de la aplicación local y en la nube.
• Dónde recopilarlos. Los recopiladores locales de cada emplazamiento principal almacenan primero los eventos y, a continuación, los reenvían al SIEM central. De este modo, se conservan los registros durante las interrupciones de la red WAN y se permite el reenvío selectivo.
• Qué debe reenviarse. Reenvíe los metadatos necesarios para la detección. Conserve todas las pruebas de DLP y los extractos de contenido en la jurisdicción en la que se capturaron, restringiendo el acceso a los investigadores autorizados.
• Conservación. Adapte la política de conservación a los requisitos normativos según cada clase de datos y cada jurisdicción, y documéntela.
• Integridad. Proteja los registros contra la manipulación y avise en caso de lagunas, que pueden indicar tanto fallos como ataques.

Capacidad y dimensiones

Los puntos de aplicación locales deben dimensionarse en función del tráfico descifrado en horas punta, ya que esta es la causa más habitual de los problemas de rendimiento en las implementaciones híbridas.

• Mida el rendimiento máximo y las velocidades de conexión por emplazamiento, así como la proporción de tráfico que se descifrará. El descifrado TLS requiere un gran esfuerzo computacional.
• Dimensionar los clústeres dejando margen para la conmutación por error, de modo que la pérdida de un nodo no sobrecargue al resto.
• Tenga en cuenta el aumento del tráfico cifrado, las transferencias de archivos de mayor tamaño y las sesiones prolongadas de inteligencia artificial y colaboración.
• Planifique cómo se ampliará la capacidad. Los dispositivos virtuales y en contenedores pueden escalar más rápidamente que el hardware dedicado.
• En el caso de los puntos de presencia en la nube, confirme con el proveedor la capacidad regional y las opciones de conmutación por error, especialmente cuando la normativa de residencia limite las regiones que puede utilizar.

Resiliencia y comportamiento ante fallos

Una arquitectura de referencia no está completa hasta que se defina qué ocurre cuando falla cada dependencia.

• La nube del proveedor no está disponible: la aplicación local de la política de aplicaciones web y privadas continúa con la política almacenada en caché, mientras que los servicios prestados desde la nube —incluidos la protección de datos, remote browser isolation, los controles de seguridad basados en IA, CASB y la gestión del estado de seguridad de los datos— no se aplican hasta que se restablezca la conexión; los usuarios remotos se redirigen a otros puntos de presencia.
• Proveedor de identidad no disponible: defina si las sesiones existentes continúan y si existe alguna alternativa local.
• En caso de interrupción de la conexión WAN o a Internet: el ZTNA local garantiza que el acceso in situ a las aplicaciones locales siga funcionando.
• Fallo de la pasarela local: un nodo del clúster o un punto de presencia en la nube asume el control con arreglo a la misma política.
• «Fail-open» o «fail-closed»: decídalo según la clase de tráfico y haga que el estado sea visible para el equipo de operaciones.

Consulte «Resiliencia híbrida de SSE: conmutación por error y recuperación» para obtener un plan de pruebas.

Correspondencia de controles con la CISA y el NIST

La asignación de cada componente a marcos de trabajo reconocidos convierte la arquitectura de referencia en un elemento de prueba para los auditores y en una lista de comprobación para los responsables de la implementación.

La tabla establece una correspondencia entre los componentes y los pilares del Modelo de Madurez de «Zero Trust» de la CISA, así como con las familias de controles representativas de la norma NIST SP 800-53, Rev. 5.

Esta correspondencia constituye un punto de partida. Cada organización debe confirmar la aplicabilidad de los controles en función de su propia referencia y de su ámbito normativo.

Ejemplos de implementación

El mismo modelo de referencia se adapta a distintos sectores mediante el ajuste de los puntos de aplicación, y no mediante el rediseño de la política.

Ejemplo 1: Banco regional

La sede central y los centros de datos cuentan con pasarelas SWG y ZTNA locales, de modo que los datos de los clientes se descifran y se inspeccionan únicamente en la infraestructura controlada por el banco. El tráfico de las sucursales utiliza dispositivos locales o túneles hacia el centro de datos más cercano. El personal remoto utiliza puntos de presencia en la nube restringidos a ubicaciones dentro de la misma región. Los registros de inspección permanecen en el país. Este modelo cumple con los requisitos de DORA en materia de riesgos de TIC y de terceros para las instituciones de la UE, al tiempo que permite el uso de CASB en la nube para el SaaS.

Ejemplo 2: Fabricante con redes OT

Un cortafuegos de segmentación separa las redes OT de la planta de las redes IT corporativas. Los sistemas OT solo acceden a destinos autorizados de actualización y telemetría a través de un SWG local. Los ingenieros acceden a los sistemas de la planta a través de un ZTNA local con comprobaciones del estado de los dispositivos. Si se produce un fallo en la WAN o en un servicio en la nube, el acceso a la planta y las inspecciones continúan de forma local.

Ejemplo 3: Organismo del sector público

Las redes clasificadas o desconectadas requieren componentes que sean compatibles de forma explícita con el funcionamiento sin servicios externos. Las redes no clasificadas pueden utilizar servicios en la nube debidamente autorizados para los trabajadores a distancia. Documente la sincronización de políticas, la identidad, las actualizaciones y las dependencias de licencias, y mantenga las excepciones específicas del entorno bajo control de cambios.

Ejemplo 4: Sistema sanitario regional

El historial médico electrónico y los sistemas de imágenes se ejecutan en los centros de datos del sistema sanitario. Las estaciones de trabajo clínicas de los hospitales utilizan pasarelas locales, por lo que los datos de los pacientes en el tráfico web y SaaS se inspeccionan en las propias instalaciones. Los dispositivos médicos se encuentran en zonas segmentadas con un acceso saliente estrictamente restringido. Los profesionales sanitarios que trabajan de forma remota acceden a la historia clínica electrónica a través del intermediario ZTNA en la nube, con requisitos de dispositivos gestionados, y las normas de prevención de pérdida de datos (DLP) para la información sanitaria protegida se aplican de forma idéntica en ambas vías, lo que respalda las medidas de seguridad de la Norma de Seguridad de la HIPAA.

Ejemplo 5: Cadena minorista internacional

Las tiendas utilizan pequeñas pasarelas o túneles de sucursal hacia los centros regionales, con sistemas de punto de venta en un entorno segmentado de datos de titulares de tarjetas al que solo tienen acceso los procesadores de pagos. La navegación del personal corporativo y de las tiendas se supervisa en los centros regionales o en los puntos de presencia en la nube, restringiéndose el tráfico europeo a las regiones de la UE y almacenándose los registros dentro de la propia región. Los sistemas de las tiendas siguen funcionando durante las interrupciones de la red WAN, ya que la segmentación local y las normas de acceso no dependen de la nube. Esto cumple con los requisitos de segmentación y registro de la norma PCI DSS.

Trayectoria de madurez y validación

Utilice las fases de madurez de la CISA para organizar la implantación por fases y realice pruebas repetibles para comprobar que cada fase funciona correctamente.

Trayectoria de vencimiento

Las organizaciones rara vez implementan la arquitectura de referencia completa de una sola vez; el modelo de la CISA describe cuatro etapas (tradicional, inicial, avanzada y óptima) que constituyen una hoja de ruta útil.

Utilice la diferencia entre la fase actual y la siguiente como base para elaborar un plan por fases.

Validación de la arquitectura

La calidad de una arquitectura depende de cómo se comporte en las pruebas, por lo que debe validar cada flujo y cada límite mediante pruebas repetibles.

• Envíe una URL que se sepa que es maliciosa, un archivo de malware de prueba y un documento de prueba de DLP a través de todos los puntos de aplicación y compruebe que los resultados sean idénticos utilizando la ruta en la nube disponible. Registre el comportamiento esperado de los controles aplicados en la nube cuando se interrumpa dicha ruta.
• Confirme que cada flujo se descifra exactamente una vez.
• Intente acceder a una aplicación privada desde las instalaciones, de forma remota y desde un dispositivo no gestionado, y compruebe que se obtienen los resultados esperados.
• Bloquee el acceso desde un sitio a la nube del proveedor y compruebe que se sigue aplicando la política a nivel local.
• Compruebe que los registros de todos los puntos de aplicación lleguen al SIEM y que se respeten las normas de residencia.

Cómo se ajusta Skyhigh a la arquitectura de referencia

Skyhigh Hybrid SSE Mesh abarca el plano de control (una consola y un motor de políticas con las políticas implementadas como código), la aplicación local (dispositivos SWG locales con inspección TLS local y ZTNA local), la aplicación en la nube (SWG, CASB, ZTNA y RBI en la nube), los controles a nivel de navegador y DSPM (Skyhigh Security).

Para la protección de claves de inspección y el entorno de pruebas local, confirme con Skyhigh las integraciones compatibles, las versiones de los productos y los requisitos de implementación. No dé por sentado que la pasarela o el servicio elegido sea compatible con HSM.

Fuentes

1. NIST. SP 800-207: Arquitectura «Zero Trust» (agosto de 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST. SP 800-215: Guía para un entorno de red empresarial seguro (noviembre de 2022). https://csrc.nist.gov/pubs/sp/800/215/final
3. NIST NCCoE. SP 1800-35: Implementación de una arquitectura de confianza cero (junio de 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
4. NIST. SP 800-53, rev. 5: Controles de seguridad y privacidad para sistemas de información y organizaciones. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
5. CISA. Modelo de madurez de «Zero Trust», versión 2.0. https://www.cisa.gov/zero-trust-maturity-model
6. NSA. Gestión de riesgos derivados de la inspección de la seguridad de la capa de transporte (noviembre de 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
7. Unión Europea. Reglamento (UE) 2022/2554 (Ley de Resiliencia Operativa Digital). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
8. Departamento de Salud y Servicios Humanos de EE. UU. (HHS) . Norma de Seguridad de la HIPAA. https://www.hhs.gov/hipaa/for-professionals/security/index.html
9. Consejo de Normas de Seguridad PCI. PCI DSS v4.0.1 (biblioteca de documentos). https://www.pcisecuritystandards.org/document_library/
10. Skyhigh Security. «Modernización de su solución Symantec Edge Secure Web Gateway con Skyhigh Hybrid SSE Mesh» (15 de julio de 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
11. Skyhigh Security. «La adopción de la tecnología híbrida es ahora más sencilla gracias a la plataforma Skyhigh SSE» (3 de octubre de 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html