Secure Web Gateway Migración: Lista de comprobación para la transición y la reversión
- Una migración de SWG requiere un inventario, una fase piloto, pruebas, una implantación por fases y una reversión probada, al igual que cualquier cambio a entorno de producción.
- La autenticación, los certificados TLS y las excepciones, el enrutamiento del tráfico y las integraciones con ICAP o DLP son los que entrañan mayor riesgo.
- Ponga en marcha la nueva pasarela en paralelo y traslade a los usuarios por grupos, en lugar de realizar la transición de una sola vez.
- Defina los desencadenantes de reversión y los criterios de aceptación antes de la primera fase de producción, no durante un incidente.
- La migración es la mejor oportunidad para eliminar normas que llevan años sin utilizarse y excepciones obsoletas.
Una migración de « secure web gateway » consiste en trasladar la inspección del tráfico web y las políticas de una plataforma de proxy a otra, ya sea desde un dispositivo local a un nuevo dispositivo, a un servicio en la nube o a un modelo híbrido. Esta lista de comprobación abarca todo el proceso: inventario, diseño del destino, conversión de políticas, preparación para la reversión, prueba piloto, pruebas, transición por fases y aceptación.
Este artículo forma parte de la guía sobre seguridad en la nube híbrida. Para obtener información específica sobre Blue Coat ProxySG y Symantec Edge SWG, consulte «Blue Coat » y «ProxySG End of Life: Migration Planning».
Fase 1: Inventario
La fase 1 documenta el estado actual de la infraestructura de la pasarela, la gestión del tráfico, la autenticación, la inspección TLS, las políticas y las integraciones antes de iniciar cualquier trabajo de diseño.
Infraestructura
- Cada puerta de enlace: modelo, versión de software, ubicación, función y fechas de fin de vida útil (en el caso de ProxySG y Edge SWG, consulte el artículo de Broadcom sobre el ciclo de vida)
- Volumen de tráfico y rendimiento máximo por sitio, con porcentaje de descifrado TLS
- Número de usuarios por centro y para el acceso remoto
- Encadenamiento de servidores proxy en las fases inicial y final, equilibradores de carga y diseño de conmutación por error
Gestión del tráfico
- Configuración explícita del servidor proxy, archivos PAC y WPAD
- Puntos de interceptación transparentes (WCCP, enrutamiento basado en políticas)
- Túneles desde sucursales (IPsec, GRE)
- Agentes en los dispositivos finales
- Excepciones relativas a la venta directa por Internet
Identidad
- Ámbitos de autenticación (SAML, Kerberos/IWA, LDAP, certificados de cliente)
- Asignaciones de grupos utilizadas en la política
- El tráfico no autenticado (servidores, IoT, OT) y cómo se gestiona
Inspección TLS
- Certificado de inspección, ubicación clave, fecha de caducidad y método de distribución
- Lista de excepciones de descifrado con motivos y responsables
Política
- Exportación completa de la política, incluyendo el orden de las reglas, las categorías, las listas personalizadas y las excepciones
- Reglas que no han tenido visitas en los últimos 90 días (candidatas a ser retiradas)
Integraciones
- Conexiones de ICAP con DLP, antivirus y entornos de aislamiento
- Reenvío de registros a herramientas SIEM y de generación de informes
- Supervisión y alertas
Fase 2: Diseño de la diana
En la fase 2 se determina dónde se inspeccionarán cada uno de los sitios y cada grupo de usuarios, así como la forma en que se gestionarán el tráfico, los certificados y los registros.
- Decida dónde se inspeccionará cada sitio y cada grupo de usuarios: en las propias instalaciones, en la nube o en un entorno híbrido
- Defina el método de enrutamiento del tráfico para cada caso: proxy explícito o PAC para redes gestionadas, agentes o controles del navegador para usuarios itinerantes, y túneles para sucursales
- Confirme la ubicación de la inspección TLS de modo que cada flujo se descifre una sola vez. Las directrices de la NSA recomiendan realizar la inspección una sola vez dentro de la red de la empresa y evitar la inspección redundante mediante proxies encadenados (NSA)
- Capacidad de tamaño para el rendimiento máximo descifrado más el crecimiento
- Diseño de la alta disponibilidad y el comportamiento ante fallos
- Decida dónde se almacenarán los registros y las pruebas de DLP
- Planifique la nueva CA de inspección o la transferencia de la ya existente, y confirme el almacenamiento de claves compatible y cualquier integración necesaria con un HSM
Fase 3: Adaptación de las políticas
La fase 3 traslada la política existente a la nueva plataforma mediante una correspondencia estructurada y validada, en lugar de una conversión directa de archivos.
- Asigne cada regla de origen a su equivalente de destino o márquela para su retirada
- Relacione las categorías de las URL entre los distintos proveedores y analice las diferencias en las categorías de mayor impacto
- Vuelva a crear listas personalizadas, listas de permitidos y listas de bloqueados
- Traduzca las reglas que dependen de la autenticación y confirme las asignaciones de grupos
- Vuelva a crear las soluciones para eludir el descifrado y revise cada una de ellas para determinar si siguen siendo necesarias
- Sustituya, siempre que sea posible, los traspasos de DLP basados en ICAP por el servicio de protección de datos propio de la plataforma, confirmando dónde se lleva a cabo la inspección, o restablezca las integraciones
- Registre cada cambio y cada norma retirada, indicando el motivo, siguiendo su proceso de control de cambios de configuración (la norma NIST SP 800-128 describe prácticas de gestión de la configuración centradas en la seguridad).
Algunas plataformas ofrecen la posibilidad de importar políticas existentes de forma asistida. Considere cualquier importación como un punto de partida que aún requiere revisión y pruebas.
Fase 4: Preparación de la reversión
En la fase 4 se definen los desencadenantes y los mecanismos de reversión antes de la fase piloto. Pruebe la reversión durante la fase piloto y compruebe que todo está listo antes de cada oleada de producción.
Desencadenantes de reversión (ejemplos)
- Errores de autenticación que superen un umbral acordado
- Una aplicación crítica para el negocio que no está disponible durante un tiempo superior al acordado
- Tickets del servicio de asistencia que superen un múltiplo establecido del valor de referencia
- Se ha confirmado que los controles de seguridad no se están aplicando
Mecánica de reversión
- Mantenga las puertas de enlace antiguas en funcionamiento y actualizadas hasta la aceptación definitiva
- Mantenga un control de versiones de los archivos PAC, el DNS y los cambios de enrutamiento para que puedan revertirse
- Tenga en cuenta los tiempos de almacenamiento en caché del DNS y del PAC en las estimaciones de reversión
- Asegúrese de que la antigua autoridad de certificación de inspección siga siendo de confianza en los dispositivos durante la transición
- Designe a las personas autorizadas para autorizar una reversión y documente los pasos a seguir
- Realice una reversión de prueba durante la fase piloto y compruebe que todo está listo antes de cada fase de transición.
Fase 5: Proyecto piloto
En la fase 5 se gestiona un grupo piloto representativo en el nuevo portal, en paralelo con el antiguo, durante al menos un ciclo económico.
- Seleccione usuarios piloto que representen a los departamentos clave, los tipos de dispositivos y las ubicaciones, incluyendo al personal de TI y a algunos usuarios avanzados de la empresa
- Ponga en funcionamiento la nueva pasarela en paralelo con la antigua
- Desvíe el tráfico de los pilotos hacia la nueva puerta de enlace mediante cambios en el PAC, en el agente o en el enrutamiento que puedan revertirse rápidamente
- Proporcione a los usuarios de la fase piloto un canal claro para comunicar los problemas
- Mantenga el proyecto piloto durante al menos un ciclo económico completo, incluyendo el cierre de mes, si procede.
Fase 6: Pruebas
La fase 6 evalúa todos los aspectos en los que los usuarios notarán una diferencia, desde la autenticación hasta el rendimiento y la conmutación por error.
| Área de pruebas | Qué hay que comprobar |
|---|---|
| Autenticación | Los usuarios y los grupos se identifican correctamente; el inicio de sesión único (SSO) funciona; el tráfico del sistema no autenticado se comporta según lo previsto |
| Política sobre categorías y URL | Las categorías «Permitidas», «Bloqueadas» y «Advertidas» se comportan igual que en el código fuente |
| Inspección TLS | Los certificados son reconocidos como fiables en todos los dispositivos gestionados; se omite el control de acceso; las aplicaciones ancladas funcionan correctamente |
| Protección frente a amenazas | Se bloquean las muestras de malware de prueba y las URL que se sabe que son maliciosas |
| DLP | Los documentos de prueba correspondientes a cada clase de datos se detectan al subirlos |
| Aplicaciones empresariales | Las 50 principales aplicaciones web y de SaaS críticas para el negocio, de principio a fin |
| Rendimiento | Los tiempos de carga de las páginas y el rendimiento en horas punta son aceptables |
| Tala de árboles | Los eventos llegan al SIEM con los campos previstos |
| Conmutación por error | El fallo de un nodo de pasarela se gestiona sin que ello afecte al usuario |
Fase 7: Transición por fases
En la fase 7, los usuarios y los sitios se trasladan a la nueva pasarela por oleadas, comenzando por los sitios de menor riesgo.
- Agrupe a los usuarios y los sitios en oleadas según su riesgo y complejidad, comenzando por los sitios de bajo riesgo
- Informe con antelación de cada oleada, indicando una persona de contacto para recibir apoyo
- Programe las oleadas fuera de los periodos críticos de actividad empresarial
- Organice un centro de mando para las primeras horas de cada oleada
- Supervise los tickets del servicio de asistencia, las tasas de bloqueo y las tasas de error en comparación con los valores de referencia
- Haga una pausa entre cada fase para resolver los problemas antes de continuar
Fase 8: Aceptación y desmantelamiento
En la fase 8 se comprueba que se cumplen los criterios de aceptación y, a continuación, se retiran las puertas de enlace, los certificados y los contratos antiguos.
Criterios de aceptación (ejemplos)
- Se han migrado todos los usuarios y sitios web
- El volumen de consultas al servicio de asistencia técnica ha vuelto a los niveles habituales desde hace dos semanas
- Todos los casos de prueba se han superado en el entorno de producción
- Registros e informes verificados por el departamento de operaciones de seguridad y cumplimiento normativo
- Se ha revisado y aprobado la lista de excepciones
Retirar del servicio
- Elimine las puertas de enlace antiguas de los archivos PAC, de la configuración de enrutamiento y del DNS
- Revoque y elimine la antigua CA de inspección de los dispositivos, en caso de que haya sido sustituida
- Archive los registros antiguos de acuerdo con la política de conservación
- Borrar y desechar el hardware de forma segura
- Cerrar licencias y contratos de asistencia técnica
Plazo habitual
Los plazos dependen del volumen del patrimonio y de la complejidad de la póliza.
Una organización con una única sede puede completar una migración en cuestión de semanas. Las grandes empresas con múltiples sedes suelen llevar a cabo una implementación en paralelo y una adopción por fases a lo largo de un periodo de entre seis y doce meses, según Skyhigh Security.
Cómo Skyhigh facilita la migración a SWG
Skyhigh facilita la migración a SWG mediante la implementación en paralelo, la importación validada de políticas CPL y modelos de implementación flexibles.
Skyhigh Hybrid SSE Mesh se implementa junto con las pasarelas existentes, de modo que las políticas puedan validarse con el tráfico paralelo antes de cualquier transición. Skyhigh reformula las políticas CPL existentes de Blue Coat en su consola de políticas unificada mediante un proceso de importación validado, y las políticas se crean en la consola en la nube de Skyhigh. Las políticas para aplicaciones web y privadas pueden aplicarse en la pasarela local, mientras que el tráfico que requiera protección de datos aplicada en la nube se reenvía a la nube de Skyhigh. Los usuarios remotos reciben el servicio a través de puntos de presencia en la nube. Skyhigh SWG se ejecuta de forma local, híbrida o en la nube, por lo que la migración no obliga a cambiar el modelo de implementación. El Programa de Modernización «Blue Coat » añade soporte de servicios y una compensación comercial para los clientes que cumplan los requisitos.
Fuentes
- 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
- NIST. SP 800-128: Guía para la gestión de la configuración de los sistemas de información centrada en la seguridad. https://csrc.nist.gov/pubs/sp/800/128/upd1/final
- 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
- 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