Implementación privada de SSE: arquitectura y dependencias en la nube
- SSE privado gestiona la pasarela web y la aplicación de políticas de aplicaciones privadas en la infraestructura controlada por el cliente, mientras que los servicios de datos, como la protección de datos, pueden seguir siendo gestionados por la nube del proveedor. Indique cuáles son unos y cuáles otros.
- Evalúe por separado el plano de datos, el plano de control y los servicios de apoyo, ya que cada uno de ellos puede ser privado o estar en la nube.
- La mayoría de las soluciones SSE autohospedadas siguen dependiendo de la nube del proveedor para algún aspecto, por lo que debe identificar todas las dependencias externas.
- La telemetría consiste en datos; decida qué registros, muestras y metadatos salen de su entorno y adónde se envían.
- El SSE privado y el SSE en la nube pueden funcionar conjuntamente, reservando la aplicación de normas en el entorno privado para aquellos sitios que lo necesiten.
El modelo «Private SSE» es un modelo de implementación en el que las funciones de « Security Service Edge », como el « secure web gateway » (SWG), el « zero trust network access » (ZTNA) y el « data loss prevention » (DLP), se ejecutan en una infraestructura alojada por el cliente. Lo utilizan aquellas organizaciones que deben mantener la inspección del tráfico, las claves o los registros dentro de sus propias instalaciones o jurisdicciones, o que necesitan que la seguridad siga funcionando sin depender de una nube externa.
La definición de SSE de Gartner la describe como una solución prestada principalmente en la nube, aunque señala que puede incluir componentes locales o basados en agentes. El SSE privado se centra precisamente en esos componentes.
Este artículo forma parte de la guía sobre seguridad en la nube híbrida.
Los tres planos de una arquitectura SSE
Cada implementación de SSE, ya sea en la nube o privada, cuenta con tres capas lógicas.
El modelo de «confianza cero» del NIST recogido en la norma SP 800-207 establece la misma distinción entre las decisiones relativas a las políticas y la aplicación de las mismas.
Plano de datos. Los componentes que se encuentran en la ruta del tráfico y que inspeccionan o gestionan las conexiones: proxies web, pasarelas ZTNA, inspección TLS, análisis DLP y análisis de malware. Es aquí donde se encuentra el texto sin cifrar.
Plano de control. Es el lugar donde los administradores definen las políticas, gestionan las identidades y los grupos, y envían la configuración a los puntos de aplicación. Puede tratarse de una consola local, en la nube del proveedor o en ambas.
Servicios de apoyo. Los elementos a los que recurren los puntos de control para tomar decisiones: categorización de URL, inteligencia sobre amenazas, reputación de archivos, entornos aislados, actualizaciones de software y firmas, gestión de licencias y análisis.
La confidencialidad de un despliegue depende del nivel de confidencialidad de su plano menos confidencial.
Modelos de implementación de SSE privados
El SSE privado abarca desde un plano de datos privado con gestión en la nube hasta implementaciones totalmente privadas sin dependencias externas. Se trata de modelos de evaluación; la disponibilidad y los límites operativos dependen del producto seleccionado.
| Modelo | Plano de datos | Plano de control | Servicios de apoyo | Ajuste típico |
|---|---|---|---|---|
| SSE en la nube | Nube de un proveedor | Nube de un proveedor | Nube de un proveedor | Organizaciones que dan prioridad al teletrabajo |
| SSE híbrido | Nube de clientes y proveedores | Nube del proveedor o consola unificada | Nube del proveedor, con cachés locales | Empresas sujetas a regulación con personal que trabaja a distancia |
| Plano de datos privado | Infraestructura del cliente | Nube de un proveedor | Nube de un proveedor | Se requiere una inspección in situ; se acepta la gestión en la nube |
| Totalmente privado | Infraestructura del cliente | Infraestructura del cliente | Actualizaciones alojadas por el cliente o sin conexión | Entornos aislados físicamente, clasificados o soberanos |
El modelo de plano de datos privado es el más habitual. Mantiene el descifrado y la inspección a nivel local, al tiempo que utiliza una consola en la nube para la gestión de políticas y el análisis. Las implementaciones totalmente privadas son menos frecuentes y exigen un mayor esfuerzo por parte del equipo de operaciones del cliente.
Componentes alojados por el cliente
En una implementación de SSE privada o híbrida, el cliente aloja y gestiona los componentes de aplicación y los componentes clave, que suelen incluir:
- Dispositivos de puerta de enlace web —físicos, virtuales o en contenedores— para la inspección TLS local y la aplicación de políticas web
- Pasarelas o conectores ZTNA que facilitan el acceso a aplicaciones privadas
- Análisis DLP, cuando un proveedor lo ofrece a nivel local; Skyhigh aplica la protección de datos a través de su nube al tráfico que reenvía la pasarela.
- Entorno aislado, en las propias instalaciones, para archivos confidenciales
- Inspecciónde la CA y del almacenamiento de claves, con custodia respaldada por hardware únicamente cuando sea compatible y se haya verificado
- Recopiladores de registros que almacenan eventos de forma local y reenvían datos seleccionados
El cliente es responsable de la capacidad, la disponibilidad, la aplicación de parches y la seguridad física de estos componentes.
Dependencias en la nube que deben asignarse
La mayoría de las implementaciones privadas de SSE siguen dependiendo de la nube del proveedor en algún aspecto, por lo que debe enumerar cada dependencia y su comportamiento en caso de fallo.
Antes de evaluar cualquier arquitectura SSE privada, pida al proveedor que le facilite una lista de todas las conexiones salientes de los componentes alojados por el cliente y que le explique qué ocurre cuando cada una de ellas no está disponible:
| Dependencia | Pregunta que debe plantearse | Qué debe tener en cuenta |
|---|---|---|
| Políticas y configuración | ¿Se sigue aplicando la última política conocida si no se puede acceder a la consola? | Política almacenada en caché con un comportamiento definido |
| Clasificación y reputación de las URL | ¿Las consultas se realizan de forma local, en la nube o de forma híbrida? | Base de datos local con actualización en la nube |
| Información sobre amenazas y firmas | ¿Cómo se distribuyen las actualizaciones? ¿Es posible implementarlas por fases o sin conexión? | Actualizaciones por etapas; opción sin conexión para sitios sin conexión |
| Entorno aislado | ¿Se envían los archivos a un entorno aislado en la nube? | Opción de entorno de pruebas local |
| Autenticación | ¿Depende el acceso de un servicio de identidad en la nube? | Identidad local de reserva o tokens almacenados en caché |
| Licencias | ¿Se suspende la aplicación de la ley si no se superan los controles de la licencia? | Plazo de gracia |
| Registro y análisis | ¿Qué se envía, dónde se almacena y se puede desactivar? | Campos y regiones configurables |
| Acceso al servicio de asistencia | ¿Puede el personal del proveedor acceder a los componentes alojados por el cliente? | Acceso controlado por el cliente y sometido a auditoría |
Para cada dependencia, decida si el comportamiento predeterminado es aceptable o si se requiere una alternativa local.
Flujos de telemetría
La telemetría procedente de puntos de control privados constituye información por derecho propio y puede incluir:
- Registros de acceso: usuario, dispositivo, URL, categoría, acción
- Incidentes relacionados con la protección de datos (DLP), en ocasiones con extractos del contenido o copias completas
- Hash de archivos o muestras para el análisis de amenazas
- Indicadores de rendimiento y salud
- Datos de uso para la concesión de licencias
Parte de esto es inofensivo. Otra parte son datos regulados. Elabore un mapa de telemetría que registre cada flujo, su contenido, su destino y su retención. A menudo, esto marca la diferencia entre una revisión de soberanía que se aprueba y otra que se estanca. Véase «Soberanía de los datos en la seguridad de la nube híbrida».
Una práctica recomendable consiste en generar «huellas digitales» de los datos sensibles dentro del entorno del cliente y enviar únicamente los hash al servicio, de modo que el contenido protegido en sí nunca salga de dicho entorno. Pregunte a cada proveedor dónde se generan las huellas digitales para la comparación exacta de datos y de documentos, y qué es lo que se transmite. Skyhigh genera y aplica la comparación para la protección de datos en su nube.
Cuándo tiene sentido la SSE privada
La SSE privada resulta adecuada cuando la normativa, la conectividad, la tecnología operativa, el volumen de tráfico o la sustitución de sistemas heredados exigen una aplicación a nivel local.
- La normativa o los contratos exigen que el tráfico descifrado, las claves o los registros permanezcan en el país o en las instalaciones
- Las redes están aisladas físicamente, son de acceso restringido o están conectadas de forma intermitente
- La tecnología operativa o las infraestructuras críticas deben seguir funcionando durante los cortes de suministro externos
- El volumen de tráfico interno hace que la inspección en la nube resulte costosa o lenta
- La organización está sustituyendo un proxy local y desea modernizarse sin tener que migrar obligatoriamente a la nube
Cuando no se da ninguna de estas situaciones, el SSE en la nube suele suponer un menor esfuerzo operativo.
Compensaciones operativas
El servicio SSE privado traslada la responsabilidad al cliente: dimensionamiento, redundancia, aplicación de parches, preparación de actualizaciones y resolución de incidencias.
Las ventajas son el control sobre el texto sin cifrar, las claves y los registros, así como la continuidad en caso de que no se pueda acceder a la nube del proveedor. Los diseños híbridos permiten a las organizaciones limitar la aplicación de las políticas privadas a los emplazamientos y al tráfico que lo requieran.
Cómo Skyhigh da soporte a la SSE privada e híbrida
Skyhigh es compatible con la SSE privada e híbrida, con un plano de datos local gestionado desde la misma consola que sus servicios en la nube.
Skyhigh Hybrid SSE Mesh aplica la política de « secure web gateway » y de acceso «Zero Trust» en la propia pasarela local del cliente, con inspección TLS local y una arquitectura de dispositivos en contenedores introducida en marzo de 2026, y aplica la protección de datos, CASB y los demás servicios de datos de la nube de Skyhigh al tráfico que reenvía la pasarela, todo ello bajo una única política creada en una sola consola. El plano de control se proporciona desde la nube, por lo que la creación de políticas, la generación de informes y el envío de registros dependen de la accesibilidad a la nube, mientras que la aplicación local de las políticas para aplicaciones web y privadas continúa en las instalaciones si se interrumpe esa conexión. Skyhigh cuenta con la autorización FedRAMP High.
Fuentes
- Gartner. «Security Service Edge » (SSE), Glosario de tecnologías de la información. https://www.gartner.com/en/information-technology/glossary/security-service-edge-sse
- NIST. SP 800-207: Arquitectura «Zero Trust» (agosto de 2020). https://csrc.nist.gov/pubs/sp/800/207/final
- Skyhigh Security. «Skyhigh Security anuncia nuevas soluciones para reforzar su innovadora plataforma universal SSE» (24 de marzo de 2026). https://www.skyhighsecurity.com/about/newsroom/newswire/skyhigh-security-announces-new-solutions-to-strengthen-disruptive-universal-sse-platform.html
- 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
- 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