Inspección TLS local frente a la inspección TLS en la nube: consideraciones relativas a la implementación
- La inspección TLS descifra, examina y vuelve a cifrar el tráfico, por lo que el texto sin cifrar existe brevemente dondequiera que se produzca.
- La inspección local permite controlar el texto sin cifrar y las claves locales; evalúe por separado los servicios prestados en la nube y su procesamiento.
- Las directrices de la NSA recomiendan inspeccionar cada sesión una sola vez, dentro de la red de la empresa, sin utilizar proxies en cadena.
- Mantenga una lista de excepciones revisada para las aplicaciones ancladas, las categorías sensibles en materia de privacidad y el tráfico que no supera la inspección.
- El protocolo «Client Hello» cifrado, publicado como RFC 9849, limita la visibilidad pasiva y requiere un manejo deliberado.
La inspección TLS (que a menudo todavía se denomina inspección SSL) es el proceso que consiste en interceptar una sesión TLS, descifrarla con un certificado de confianza de la empresa, inspeccionar el contenido y volver a cifrarla antes de reenviarla a su destino. Sin ella, las pasarelas web seguras, los motores DLP y los entornos aislados solo ven los metadatos de destino. Con ella, pueden detectar malware, bloquear la filtración de datos y hacer cumplir las políticas de uso aceptable dentro de las sesiones cifradas.
La cuestión no es si se debe realizar la inspección, sino dónde. Esta guía compara la inspección TLS local y en la nube en lo que respecta a las vías de descifrado, las responsabilidades en materia de certificados, las excepciones, el registro de datos y las operaciones.
Este artículo forma parte de la guía sobre seguridad en la nube híbrida.
Cómo funciona la inspección TLS
La inspección TLS funciona de tal manera que un proxy de confianza interrumpe la sesión cifrada del cliente, inspecciona el contenido y abre una nueva sesión cifrada hacia el destino.
El proxy actúa como servidor para el cliente y como cliente para el destino:
- El cliente inicia una sesión TLS con un sitio web o una aplicación.
- El servidor proxy intercepta la conexión y presenta un certificado para el destino, firmado por una autoridad de certificación (CA) de inspección empresarial en la que confían los dispositivos cliente.
- El proxy establece su propia sesión TLS con el destino real y verifica el certificado de dicho servidor.
- El tráfico se descifra entre ambas sesiones, se inspecciona y se vuelve a cifrar.
Esto significa que el proxy dispone de una clave muy potente y maneja texto sin cifrar en cada sesión inspeccionada. El aviso de la NSA titulado «Gestión del riesgo derivado de la inspección de la seguridad de la capa de transporte» recomienda reducir al mínimo los casos en los que esto ocurra: realizar la inspección una sola vez, dentro de la red de la empresa, y evitar la inspección redundante por parte de múltiples proxies de reenvío. La alerta anterior de la CISA sobre la interceptación de HTTPS advertía de que los productos de inspección mal implementados pueden debilitar la seguridad de TLS, por ejemplo, al no validar correctamente los certificados de origen.
Comparación rápida entre la inspección TLS local y la inspección TLS en la nube
La inspección local mantiene el texto sin cifrar y las claves en su infraestructura, mientras que la inspección en la nube los traslada a los puntos de presencia del proveedor.
| Factor | Inspección TLS local (en las propias instalaciones) | Inspección TLS en la nube |
|---|---|---|
| Cuando existe texto sin cifrar | Sus dispositivos del centro de datos o de las sucursales | Puntos de presencia de los proveedores |
| ¿Quién es el titular de la clave privada de la CA de inspección? | Usted, si lo desea, en su propio HSM | El proveedor, o usted a través de las opciones de clave que ofrece el proveedor |
| Ideal para | Datos regulados, tráfico interno, usuarios en las instalaciones, OT | Usuarios remotos, tráfico directo a SaaS |
| Latencia para los usuarios locales | Depende de la capacidad local y de la ruta de tráfico | Depende de la distancia del punto de presencia y del enrutamiento |
| Planificación de la capacidad | Atentamente; el proceso de descifrado requiere un gran esfuerzo computacional | Del proveedor: |
| Dependencia de la conectividad externa | No es necesario para la aplicación de políticas web locales; sí es necesario para servicios prestados en la nube, como la protección de datos | Obligatorio |
| Ubicación de los registros y las pruebas | Los registros locales son configurables; los datos de los servicios en la nube se rigen por la política de almacenamiento de cada servicio. | Regiones de proveedores, según la configuración |
| Esfuerzo operativo | Dimensionamiento del hardware, aplicación de parches y ciclo de vida de los certificados | Distribución de certificados, excepciones y configuración de proveedores |
La mayoría de las organizaciones híbridas utilizan ambas opciones: la inspección local para el tráfico seleccionado in situ y el tráfico regulado, y la inspección en la nube para los usuarios remotos. Asigne la terminación TLS a cada ruta y evite el descifrado redundante, incluso cuando una pasarela local reenvíe tráfico para servicios que se aplican en la nube.
Vías de descifrado
Todo diseño híbrido debe identificar cada punto de terminación y recifrado de TLS y evitar inspecciones redundantes.
Entre las rutas más habituales se encuentran:
- Conexión de un usuario de oficina a Internet: a través de una pasarela local o mediante un túnel hacia un punto de presencia en la nube
- Usuario remoto conectado a Internet: punto de presencia en la nube o conexión de retorno a una pasarela local
- Del usuario a la aplicación privada: determine si la ruta ZTNA seleccionada admite la inspección TLS y, en caso afirmativo, en qué punto lo hace
- Sesión del navegador: controles a nivel del navegador que permiten visualizar el contenido sin necesidad de descifrado de red
- Punto final: inspección basada en agentes en el dispositivo
Uno de los riesgos en los entornos híbridos es el descifrado duplicado no planificado. Una sucursal puede enviar tráfico a través de un proxy local y, a continuación, a través de un servicio en la nube que vuelve a interrumpir la conexión TLS. Documente cada etapa de inspección necesaria, proteja cada límite de texto sin cifrar y elimine las etapas redundantes que aumenten la exposición o la complejidad a la hora de resolver incidencias.
Responsabilidades relacionadas con el certificado
La fiabilidad de la inspección TLS depende directamente de la fiabilidad de los certificados en los que se basa; por lo tanto, asigne claramente la responsabilidad de cada fase del ciclo de vida del certificado:
- Creación y protección de certificados de autenticación (CA). Indique dónde se almacena la clave privada, quién puede acceder a ella y si se requiere un HSM. Confirme las integraciones con HSM compatibles para cada pasarela local o servicio en la nube y su versión del producto; no dé por sentado que son compatibles.
- Distribución. Cómo se instala la CA en los almacenes de confianza del sistema operativo y del navegador en los dispositivos gestionados, y qué ocurre en los dispositivos no gestionados.
- Rotación. El calendario y el procedimiento para sustituir al responsable de inspección sin necesidad de una parada del servicio.
- Validación previa. Asegúrese de que el proxy rechace los certificados de destino no válidos, caducados o revocados, en lugar de ocultarlos a los usuarios.
- Compatibilidad con protocolos. El protocolo TLS 1.3 (RFC 8446) debe verificarse de forma nativa, sin recurrir a una versión anterior.
Excepciones de tráfico
Ninguna organización debería descifrar todo, por lo que debe mantener una lista de excepciones documentada y revisada periódicamente:
| Tipo de excepción | Motivo | Manejo habitual |
|---|---|---|
| Aplicaciones con certificado fijado | La inspección interrumpe la conexión | Excluir según el destino; aplicar controles de reputación y categoría |
| Categorías de salud, finanzas y asuntos personales | La privacidad de los empleados, los requisitos legales y los del comité de empresa | Omitir el descifrado; seguir aplicando la política de categorías |
| Autenticación TLS recíproca y mediante certificado de cliente | El servidor proxy no puede presentar el certificado de cliente | Omita esta opción o utilice una conexión de paso compatible |
| Servicios de actualización y algunos protocolos de OT | Estabilidad y asistencia técnica del proveedor | Desvío por destino con acceso restringido |
| QUIC y HTTP/3 (RFC 9000) | Muchos servidores proxy no pueden inspeccionar el protocolo QUIC | Bloquee QUIC para que los navegadores recurran a TLS sobre TCP, o confirme la compatibilidad nativa |
Revise las excepciones cada trimestre. Las exclusiones obsoletas constituyen un punto ciego habitual.
«Client Hello» cifrado y qué cambios conlleva
El protocolo «Client Hello» cifrado oculta el nombre de host de destino a los observadores pasivos, por lo que es necesario replantearse la visibilidad basada en SNI y algunas decisiones relativas al bypass.
El protocolo «Client Hello» cifrado se publicó como RFC 9849 en 2026. El ECH cifra la parte del protocolo de establecimiento de conexión TLS que anteriormente revelaba el nombre de host de destino (la indicación del nombre del servidor, o SNI) y otros campos. Las herramientas pasivas que clasifican el tráfico mediante la lectura de la SNI pierden esa visibilidad en los sitios web que tienen habilitado el ECH.
Los servidores proxy explícitos que interrumpen la conexión TLS se encuentran en una situación diferente, ya que establecen sus propias sesiones con los destinos. Aun así, el ECH tiene implicaciones operativas:
- Los navegadores pueden enviar extensiones similares a ECH incluso cuando no se está utilizando ECH, por lo que los productos de inspección deben gestionarlas correctamente.
- El RFC señala que, en entornos empresariales gestionados, una estrategia consiste en desactivar ECH mediante la política de grupo y confiar en que los clientes respeten dicha configuración.
- Las decisiones relativas a la categoría y la reputación que dependían del SNI para el tráfico desviado requieren una alternativa, como controles en la capa DNS o una configuración explícita del proxy.
Compruebe la hoja de ruta de ECH de su proveedor de servicios de inspección y el comportamiento de las pruebas con las versiones actuales de los navegadores.
Tala de árboles
Los registros de inspección pueden contener direcciones URL, identidades y pruebas de DLP, por lo que es necesario tomar decisiones explícitas sobre su contenido, ubicación y acceso:
- ¿Qué campos se registran en el caso del tráfico descifrado frente al tráfico no procesado?
- Dónde se almacenan los registros y si pueden salir de una jurisdicción
- Plazos de conservación y quién puede acceder al contenido completo de las pruebas
- ¿Qué eventos se reenvían al SIEM?
La inspección local facilita el mantenimiento de los registros y las pruebas en el propio país. La inspección en la nube requiere verificar las regiones de almacenamiento de registros del proveedor y los controles de acceso. Consulte «Soberanía de los datos en la seguridad de la nube híbrida».
Compensaciones operativas
La inspección local sacrifica la eficacia operativa en aras del control; la inspección en la nube sacrifica el control en aras de la simplicidad; y la inspección híbrida requiere un único motor de políticas para funcionar.
La inspección local requiere dimensionar los dispositivos para el descifrado en momentos de máxima carga, mantener actualizados los motores de inspección y planificar el crecimiento de la capacidad de hardware o virtual. A cambio, ofrece un control total sobre el texto sin cifrar, las claves y los registros del tráfico inspeccionado localmente, y la aplicación local de las políticas de aplicaciones web y privadas continúa durante una interrupción de la red WAN o de la nube, mientras que los servicios aplicados en la nube del proveedor se detienen hasta que se restablezca la conectividad.
La inspección en la nube traslada la planificación de la capacidad y las actualizaciones del motor al proveedor. Sigue requiriendo la distribución de certificados, la gestión de excepciones y el ajuste de políticas, y supone una dependencia de la disponibilidad y la conectividad del proveedor.
La inspección híbrida combina ambas opciones, pero solo funciona correctamente con un único motor de políticas. Si las pasarelas locales y en la nube tienen listas de excepciones y reglas de DLP distintas, los usuarios recibirán un trato diferente en función de su ubicación.
Cómo aborda Skyhigh la inspección local y en la nube
Skyhigh inspecciona el TLS de forma local cuando así lo exige la normativa y en la nube para los usuarios remotos, todo ello bajo una única política.
Skyhigh Hybrid SSE Mesh lleva a cabo el descifrado y la inspección de SSL/TLS de forma local en los propios dispositivos de la organización cuando así lo exige el cumplimiento normativo, y en los puntos de presencia de la nube de Skyhigh para los usuarios remotos, con un único motor de políticas para ambos entornos. La política de « Secure Web Gateway » y el acceso «Zero Trust» se aplican de forma nativa en la pasarela, mientras que la política de protección de datos se aplica en la nube de Skyhigh al tráfico que la pasarela reenvía. El tráfico web descifrado en la pasarela local se inspecciona y se vuelve a cifrar allí mismo para la aplicación de las políticas web locales. Cuando una política utiliza un servicio aplicado en la nube, como la protección de datos, la pasarela reenvía el tráfico correspondiente a la nube de Skyhigh, donde se aplica la misma política. Los controles de navegador seguro sin agente añaden una inspección compatible con WebSocket del tráfico de IA y mensajería en la sesión del navegador.
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
- CISA. «La interceptación de HTTPS debilita la seguridad de TLS» (Alerta TA17-075A, marzo de 2017). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF. RFC 8446: Protocolo de seguridad de la capa de transporte (TLS), versión 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF. RFC 9849: «Client Hello» cifrado mediante TLS. https://www.rfc-editor.org/rfc/rfc9849.html
- IETF. RFC 9000: QUIC: un protocolo de transporte seguro y multiplexado basado en UDP. https://www.rfc-editor.org/rfc/rfc9000.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
- 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