Pasarelas web seguras en la nube frente a las locales
- Las pasarelas web seguras en la nube y las locales se diferencian principalmente en el lugar donde se descifra e inspecciona el tráfico.
- Los SWG en la nube son adecuados para usuarios remotos y servicios SaaS; los SWG locales son adecuados para el tráfico regulado, interno y de tecnología operativa (OT).
- La latencia, la soberanía, la resiliencia y el coste a gran escala son más importantes que unas listas de características cada vez más similares.
- Un sistema híbrido de control de acceso a sitios web ( secure web gateway ) examina a cada usuario y cada sitio web en el punto más adecuado, de acuerdo con una única política.
- El hecho de ejecutar ambos modelos sin un motor de políticas compartido provoca desviaciones entre los usuarios de la oficina y los usuarios remotos.
Un « secure web gateway » local es un dispositivo proxy, físico o virtual, que se ejecuta en su propio centro de datos o sucursal e inspecciona el tráfico web de forma local. Un « secure web gateway » en la nube realiza la misma función desde los puntos de presencia del proveedor. En la actualidad, muchas organizaciones necesitan ambos, por lo que el SWG híbrido se ha convertido en una arquitectura habitual para las empresas sujetas a regulación.
Este artículo forma parte de la guía sobre seguridad en la nube híbrida.
En qué consiste el trabajo de un « secure web gateway »
Un dispositivo « secure web gateway » se interpone entre los usuarios e Internet para bloquear amenazas, garantizar un uso adecuado y evitar la pérdida de datos, independientemente del lugar en el que se ejecute.
Por lo general, ofrece:
- Filtrado por URL y categoría
- Descifrado e inspección de TLS
- Análisis de malware, entorno aislado y « remote browser isolation » para sitios web de riesgo
- Data loss prevention para la carga de archivos y el envío de formularios
- Visibilidad y control de las aplicaciones en la nube
- Registro de datos con fines de investigación y cumplimiento normativo
La norma NIST SP 800-215 incluye los SWG entre las soluciones de seguridad puntuales que las redes empresariales modernas combinan con ZTNA, CASB y otros controles a medida que desaparece el perímetro tradicional.
SWG en la nube frente a SWG local: comparación detallada
La principal diferencia entre los SWG en la nube y los locales radica en dónde se lleva a cabo la inspección y quién es el responsable de ejecutarla.
| Factor | Nube SWG | SWG local |
|---|---|---|
| Lugar de la inspección | Puntos de presencia de los proveedores | Sus centros de datos y sucursales |
| Ideal para | Usuarios remotos y móviles, tráfico directo a SaaS | Usuarios de oficinas, plantas y centros de datos; tráfico interno |
| Latencia | Depende de la distancia al punto de presencia más cercano | Añadido un salto mínimo para los usuarios locales |
| Cuando existen datos descifrados | Infraestructura de los proveedores | Su infraestructura |
| Ubicación del registro | Regiones seleccionadas por el proveedor o configurables | Independientemente de dónde lo guarde |
| Dependencia de la conectividad externa | Obligatorio | No es necesario para la inspección local compatible; los servicios prestados en la nube requieren conexión a Internet |
| Planificación de la capacidad | Responsabilidad del proveedor | Su responsabilidad |
| Esfuerzo operativo | Menor esfuerzo en materia de hardware; las políticas y las excepciones siguen estando en sus manos | El ciclo de vida del hardware, la aplicación de parches y el escalado están en sus manos |
| Modelo de costes | Por usuario o por consumo; se adapta al número de usuarios | Hardware y licencias: se adaptan al volumen de trabajo |
| Redes aisladas físicamente | No es adecuado | Únicamente en los casos en que esté explícitamente admitido y se hayan resuelto todas las dependencias |
Lugar de la inspección
El lugar de la inspección determina quién gestiona el contenido descifrado.
En el caso de muchas clases de tráfico, un SWG en la nube que cuente con los controles y las certificaciones adecuados puede cumplir los requisitos. En el caso de las cargas útiles reguladas, la inspección local puede reducir el procesamiento externo; no obstante, evalúe los servicios reenviados, el registro, las pruebas, el acceso y los requisitos aplicables antes de elegir el lugar de inspección.
Las directrices de la NSA sobre la gestión de riesgos derivados de la inspección de TLS recomiendan realizar dicha inspección una sola vez, dentro de la red de la empresa, y evitar cadenas de servidores proxy en las que cada uno descifre el mismo tráfico. En los diseños híbridos, debe garantizarse que un flujo determinado sea descifrado bien por la pasarela local, bien por la pasarela en la nube, pero no por ambas. Véase «Inspección de TLS local frente a en la nube: consideraciones de implementación».
Latencia y experiencia del usuario
La latencia depende del enrutamiento real, la distancia al punto de presencia, la capacidad de la pasarela y la carga de inspección.
En el caso de los usuarios remotos, un SWG en la nube puede mejorar la experiencia al eliminar el enlace de retorno de la VPN a la sede central. En el caso de los usuarios presenciales, la inspección local puede evitar una ruta de tránsito en la nube, aunque la inspección en la nube puede seguir siendo adecuada en función del destino y del diseño de la red. Evalúe la diferencia en los siguientes casos:
- Aplicaciones en tiempo real, como las de voz, vídeo y plataformas de negociación
- Transferencias de archivos de gran tamaño y actualizaciones de software
- Ubicaciones alejadas del punto de presencia más cercano del proveedor
- Sistemas OT y sistemas industriales con requisitos de sincronización estrictos
Control de políticas
Ambos modelos aplican una política granular; la verdadera cuestión es si las pasarelas en la nube y las locales comparten una misma política.
Las organizaciones que gestionan un parque de dispositivos heredados junto con un servicio en la nube independiente suelen mantener dos conjuntos de reglas, dos conjuntos de excepciones y dos configuraciones de DLP. Con el paso del tiempo, se trata de forma diferente a un usuario que se encuentra en la oficina y al mismo usuario cuando está en casa, y nadie se da cuenta hasta que se produce una auditoría o un incidente.
Un SWG híbrido con gestión unificada de políticas permite a los equipos definir una regla una sola vez y aplicarla en todas las puertas de enlace. Skyhigh SWG for Hybrid, por ejemplo, admite la gestión unificada de políticas en los puntos de aplicación tanto locales como en la nube, y las políticas se crean una sola vez en la consola en la nube.
Esfuerzo operativo
Los SWG en la nube reducen la carga de trabajo relacionada con el hardware, pero la gestión de políticas, excepciones y certificados sigue siendo responsabilidad de su equipo en cualquiera de los dos modelos.
Los SWG en la nube eliminan la necesidad de adquirir hardware, planificar la capacidad y aplicar parches a los dispositivos. Sin embargo, no eliminan el diseño de políticas, la gestión de excepciones, la gestión de certificados ni la clasificación de incidencias. Estas tareas siguen siendo responsabilidad de su equipo en cualquiera de los dos modelos.
Los SWG locales requieren una gestión del ciclo de vida: renovaciones de hardware, actualizaciones del sistema operativo y ampliación para adaptarse al aumento del tráfico. Los dispositivos virtuales y en contenedores reducen parte de ese esfuerzo. Un cambio de plataforma de proveedor puede generar costes operativos imprevistos. Los clientes de Symantec Edge SWG (anteriormente, Blue Coat ProxySG), por ejemplo, se enfrentan al fin de la vida útil de SGOS 7.3 y a la eliminación de la consola de gestión basada en Java en SGOS 7.4. Consulte «Blue Coat » y «Fin de la vida útil de ProxySG: planificación de la migración».
Resiliencia
Los SWG locales siguen realizando inspecciones cuando falla la conectividad externa, mientras que los SWG en la nube dependen del proveedor y de la ruta de red hasta el mismo.
Un SWG en la nube depende de la conectividad con el proveedor y de la disponibilidad de este. La mayoría de las organizaciones aceptan esta situación en el caso de los usuarios remotos. Sin embargo, en el caso de una fábrica, un hospital, una sala de operaciones bursátiles o una instalación gubernamental, la pérdida de la inspección web o el «falling open» durante un corte de servicio pueden resultar inaceptables. Las pasarelas locales siguen inspeccionando el tráfico web de forma local cuando fallan las conexiones externas. Los servicios que dependen de la nube del proveedor, como la protección de datos y remote browser isolation, no estarán disponibles hasta que se restablezca la conexión. Consulte «Resiliencia del SSE híbrido: conmutación por error y recuperación».
Requisitos de migración
Toda migración de SWG, ya sea entre modelos o entre proveedores, consta de los mismos seis pasos:
- Política actual de inventario, excepciones, ámbitos de autenticación e integraciones como ICAP y DLP.
- Decida qué usuarios y sitios se trasladan a cada punto de control.
- Restablezca el control del tráfico: proxy explícito o archivos PAC, agentes, túneles o controles del navegador.
- Vuelva a emitir y distribuya la autoridad de certificación de inspección TLS.
- Llévelo a cabo en paralelo con un grupo piloto antes de la transición.
- Realice la transición por fases con un plan de reversión probado.
Consulte la «Lista de comprobación para la migración aSecure Web Gateway : transición y reversión».
¿Qué modelo es el más adecuado para usted?
Elija en función de dónde se encuentren sus usuarios, sus aplicaciones y sus datos sujetos a normativa, y no basándose en listas de características.
Opte principalmente por la nube si la mayoría de los usuarios trabajan a distancia, la mayoría de las aplicaciones son de tipo SaaS y no existe ninguna normativa ni contrato que exija el procesamiento local del tráfico descifrado.
Opte principalmente por la instalación local cuando se requiera un procesamiento local o la continuidad del servicio para un tráfico específico. En entornos aislados físicamente, clasificados o de tecnología operativa (OT), compruebe que el producto ofrezca compatibilidad explícita y que se cumplan todos los requisitos relacionados con la gestión, la identidad, las actualizaciones, las licencias y las inspecciones.
Elija la opción híbrida si cuenta con una combinación de usuarios en la oficina y a distancia, datos sujetos a normativa junto con tráfico general, o si dispone de una infraestructura de puertas de enlace locales que desea modernizar sin verse obligado a migrar a la nube. Esto describe a la mayoría de las grandes empresas de sectores regulados.
El híbrido secure web gateway
Un SWG híbrido combina dispositivos locales y puntos de presencia en la nube bajo un único motor de políticas, una única consola y un único conjunto de registros.
El tráfico de la oficina se supervisa de forma local, el tráfico remoto se supervisa en la nube y el tráfico regulado se supervisa allí donde lo exija la política.
Skyhigh Hybrid SSE Mesh amplía este modelo más allá de las pasarelas web, incorporando ZTNA local, controles de navegador seguro y CASB, DSPM, DLP y RBI en la nube, todo ello bajo una misma política.
Fuentes
- 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
- 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
- Skyhigh Security. Secure Web Gateway para Hybrid. https://www.skyhighsecurity.com/products/secure-web-gateway-for-hybrid.html
- Skyhigh Security. «Skyhigh Security , clasificada en el primer puesto en la categoría de casos de uso avanzados de SSE en el informe de Gartner de 2026 « Critical Capabilities » para Security Service Edge» (5 de agosto de 2026). https://www.globenewswire.com/news-release/2026/08/05/3339504/0/en/skyhigh-security-ranked-1-in-advanced-sse-use-case-in-2026-gartner-critical-capabilities-for-security-service-edge.html
- Broadcom. Fin de la vida útil y ciclo de vida del producto para Edge SWG (ProxySG) y Advanced Secure Gateway (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html