Configurar flujos HTTP/HTTPS

Coloca identidad y cifrado delante de los HMIs web y las páginas de administración de dispositivos: elige un modo de terminación TLS, decide si se antepone una pantalla de inicio de sesión y resuelve las peculiaridades de los HMIs embebidos, sin tocar el dispositivo.

La mayoría de los equipos industriales incluyen una interfaz web: el HMI integrado de un PLC, la página de configuración de un variador, un panel de gestión de edificios. Muchos de ellos utilizan HTTP en texto plano por el puerto 80, 8080 u otros similares, sin autenticación real, y los que sí ofrecen HTTPS suelen servir un certificado caducado o autofirmado que el navegador rechaza. Access Gate coloca identidad y cifrado delante de estas interfaces sin tocar el dispositivo. Dos decisiones definen la configuración: cómo se termina el TLS y si se antepone un inicio de sesión a la aplicación.

Cómo la puerta protege una interfaz web

Access Gate es un proxy consciente del protocolo: el navegador se conecta a la puerta, la puerta aplica identidad y política, y la puerta se conecta a su vez al dispositivo. Como la sesión se termina en la puerta, esta puede presentar al usuario un certificado limpio y de confianza, sin importar lo que haga el dispositivo en su lado, y puede exigir autenticación antes de que la aplicación sea siquiera accesible. El dispositivo permanece exactamente como está, HTTP en texto plano incluido.

Decisión 1: cómo se termina el TLS

Hay tres modos útiles, en orden decreciente de frecuencia para los equipos industriales:

Terminar y reenviar en texto plano. El navegador obtiene HTTPS hacia la puerta; la puerta habla el HTTP nativo del dispositivo en el lado protegido. Este es el modo predeterminado para un dispositivo que solo habla HTTP en texto plano. Las credenciales y las cookies de sesión dejan de circular por la red en claro, y el dispositivo no necesita ninguna capacidad criptográfica propia.
Terminar y volver a cifrar. El dispositivo ya sirve HTTPS (a menudo con un certificado autofirmado). La puerta se conecta a él por HTTPS en el lado protegido, y los usuarios siguen viendo el certificado de confianza de la puerta, no el del dispositivo. Usa este modo cuando el segmento protegido también deba estar cifrado.
Passthrough. La puerta impone alcanzabilidad e identidad pero no termina el TLS; el navegador negocia el TLS directamente con el dispositivo. Usa este modo solo cuando el propio certificado del dispositivo ya sea de confianza.

Decisión 2: ¿se antepone un inicio de sesión?

Mediante access screen. Exige que el usuario se autentique en una access screen antes de que la aplicación web sea accesible. Este es el valor predeterminado adecuado para cualquier HMI con un inicio de sesión débil o compartido a nivel de dispositivo, pone identidad real delante de una página que no la tiene.
Passthrough. Omite la pantalla cuando la aplicación dispone de su propia autenticación adecuada y solo necesitas cifrado y control de red.

Configuración

Añade el activo a un enclave, consulta Proteger un activo con enclaves.
En Enclaves → [Your Enclave] → Access Control, añade una regla allow.
Selecciona el principal (usuario, grupo de IdP o rol) y los activos, luego guarda.
Elige el modo TLS (terminar, volver a cifrar o passthrough) y decide si se antepone una access screen.
Dirige a los usuarios a la URL del activo o a su IP de superposición.

Enclave protegiendo un servidor HTTP en Access Gate

Puedes usar Access Gate para añadir una capa de identidad y cifrado delante de una aplicación que solo habla texto plano, combinando una access screen con el cifrado TLS.

Protección de servidor HTTP con TLS mediante Access Gate

Peculiaridades de los HMIs embebidos

Las interfaces web industriales rara vez están diseñadas para situarse detrás de un proxy. Los obstáculos recurrentes:

Enlaces http://<ip> codificados de forma fija. Algunos HMIs incrustan URLs absolutas que apuntan directamente a la IP del dispositivo, eludiendo la puerta. Alcanzar la aplicación a través del nombre o la IP de superposición, en lugar de la dirección directa del dispositivo, mantiene esos enlaces dentro de la ruta intermediada.
Contenido mixto. Una página servida por HTTPS que carga scripts o imágenes por HTTP en texto plano es bloqueada por el navegador. Terminar TLS en la puerta mientras el dispositivo permanece en HTTP puede sacar esto a la luz; alcanzar los activos a través de la misma ruta de superposición evita el desajuste.
WebSockets. Los paneles en vivo y los clientes web SCADA suelen usar WebSockets (ws:// o wss://). Circulan por la misma concesión HTTP(S), pero confirma que el upgrade está permitido de extremo a extremo si un panel deja de actualizarse.
Certificados autofirmados en el dispositivo. Si el dispositivo sirve HTTPS con un certificado autofirmado, el modo terminar-y-volver-a-cifrar permite que la puerta se conecte en el lado protegido mientras los usuarios siguen viendo el certificado de confianza de la puerta.

Resumen

Publicaste un HMI web o una página de administración de dispositivo a través de un enclave, elegiste cómo se termina el TLS (reenvío en texto plano, recifrado o passthrough) y decidiste si una access screen autentica primero al usuario, de modo que un dispositivo heredado obtiene cifrado e identidad por delante sin ningún cambio en su lado.

Recurre a esto siempre que un equipo industrial exponga una interfaz HTTP en texto plano o autofirmada con autenticación débil, y necesites cifrado y control de acceso sin modificar el dispositivo.