OPC UA es el protocolo que los equipos industriales usan para comunicarse con el software y, tal como lo opera el campo, casi siempre es alcanzable, en texto plano y sin autenticación. Access Gate coloca identidad, política y cifrado delante de un servidor OPC UA sin cambiar el servidor ni el cliente. Esta página explica el protocolo brevemente y luego recorre una guía de extremo a extremo que toma un servidor expuesto y lo asegura.
Descripción general de OPC UA
OPC UA (Open Platform Communications Unified Architecture) es el protocolo estándar que los equipos industriales usan para comunicarse con el software. Un PLC que controla una bomba, un sensor que lee el nivel de un tanque, un variador de motor, un sistema SCADA, un historiador: todo ello habla OPC UA para intercambiar datos. Es la lingua franca de la planta, las plantas de agua, los sitios de energía y los entornos OT en general.
Un servidor, normalmente situado en el equipo o cerca de él (como una instancia de KEPServerEX), expone un espacio de direcciones: un árbol de nodos que representan valores del mundo real. Cada tag, como Motor1.RPM o Tank1.Level_pct, es un nodo que puedes leer y, a menudo, escribir. Los clientes (portátiles de ingeniería, SCADA, paneles) se conectan por TCP, normalmente en el puerto 4840, para leer esos valores, suscribirse a cambios en vivo o escribir nuevas consignas.
Para entender cómo cifra OPC UA el tráfico y la diferencia entre sus dos mecanismos de seguridad, consulta El papel de TLS en la protección de OPC UA.
Guía de extremo a extremo: asegurar un servidor OPC UA no seguro
Esta es una demostración por etapas que toma un servidor OPC UA no seguro (KEPServerEX, SecurityPolicy=None, anónimo) y muestra cómo Access Gate lo protege sin tocar el servidor ni el cliente heredados. Se desarrolla en dos actos fijos y luego se ramifica en uno de los tres caminos del Acto 3, según lo que admitan el cliente y el Gate.
Puntos de conexión y tags usados en todo el ejemplo:
EP_DIRECT = opc.tcp://172.31.144.41:4840/kepware/ (servidor crudo, underlay)
EP_GATE = opc.tcp://kepware.bluelab.ts-sec.net:4840/kepware/ (vía el enclave, por nombre)
RPM = ns=2;i=2 Motor1.RPM
TEMP = ns=2;i=3 Motor1.Temp_C
TANK = ns=2;i=4 Tank1.Level_pct
ROOT_CA = ~/Downloads/troutzt_root.cert (raíz de Trout Access Gate)
Acto 1: la exposición (underlay, sin protección)
El servidor tal como lo opera el campo: alcanzable, en texto plano, anónimo, escribible.
export EP="opc.tcp://172.31.144.41:4840/kepware/"
echo ">>> Explorar el servidor sin credenciales"
uabrowse -u "$EP" -v ERROR
echo ">>> Leer una consigna en vivo"
uaread -u "$EP" -n "ns=2;i=4" -v ERROR
echo ">>> Escribir un nuevo valor sin autenticación"
uawrite -u "$EP" -n "ns=2;i=4" 50.0 -v ERROR
uaread -u "$EP" -n "ns=2;i=4" -v ERROR
Cualquiera que pueda alcanzar el puerto 4840 lee todos los valores y mueve las consignas. Sin usuario, sin certificado. El protocolo admite seguridad; simplemente no está activada.
Acto 2: crear el enclave (overlay)
Coloca el servidor dentro de un enclave de Access Gate para que solo sea alcanzable a través del overlay, por nombre, para una identidad autorizada. El servidor heredado no cambia.
export EPG="opc.tcp://kepware.bluelab.ts-sec.net:4840/kepware/"
echo ">>> El mismo servidor, ahora alcanzado vía el enclave por nombre"
uaread -u "$EPG" -n "ns=2;i=2" -v ERROR
uabrowse -u "$EPG" -v ERROR
Nada en el PLC ni en el servidor cambió. El servidor ahora se sitúa detrás del Gate, alcanzable a través del overlay en lugar de en la red plana. El acceso se controla por identidad y se registra.
Acto 3: asegurar el canal (elige UN camino)
Los tres caminos siguientes son mutuamente excluyentes. Un cliente dado usa exactamente uno, según lo que admitan el cliente y el Gate. Decide de antemano y ejecuta solo ese camino.
Camino A: túnel TLS (el cliente habla TLS, mostrar PQC)
Úsalo cuando el cliente pueda terminar TLS hacia el Gate, o cuando coloques un terminador TLS local en la máquina cliente para que el segmento en texto plano nunca salga del host.
Comprueba el punto de conexión TLS del Gate:
openssl s_client -connect kepware.bluelab.ts-sec.net:4840 \
-servername kepware.bluelab.ts-sec.net \
-CAfile ~/Downloads/troutzt_root.cert </dev/null 2>&1 | \
grep -E "Verify return code|Negotiated TLS|Protocol|issuer="
El canal hacia el Gate es TLS 1.3 con intercambio de claves post-cuántico (ML-KEM-768), verificado contra nuestra propia PKI, delante de un PLC que no habla nada de eso. Para ver cómo el Gate aprovisiona certificados, negocia suites de cifrado e impone una política de "solo TLS", consulta Configurar el cifrado TLS. OPC UA también define sus propios mappings basados en TLS (opc.https y opc.wss) en el estándar, consulta El papel de TLS en la protección de OPC UA para la comparación.
Cuándo elegir A: el argumento del TLS post-cuántico es lo destacado y aceptas un terminador local (o tienes un cliente genuinamente compatible con TLS).
Camino B: seguridad de mensaje OPC UA
Úsalo cuando quieras que cualquier cliente OPC UA estándar se conecte de forma segura, sin cambios ni terminador. Aquí el cifrado ocurre en la capa de mensaje OPC UA en lugar de en un túnel TLS, y Access Gate aporta la conectividad DNS, los controles ACL y el registro a su alrededor.
La seguridad de mensaje OPC UA se ejecuta dentro del SecureChannel del protocolo. Para activarla, ajusta ambos extremos a una política de seguridad actual y a un modo de seguridad de mensaje:
- Política de seguridad:
Basic256Sha256(o una políticaAes*más nueva si ambos extremos la admiten). Evita las políticas obsoletasBasic128Rsa15yBasic256. - Modo de seguridad de mensaje:
SignAndEncrypt.Signpor sí solo prueba la integridad pero deja la carga útil legible; soloSignAndEncryptaporta confidencialidad. - Certificados: cliente y servidor intercambian certificados de instancia de aplicación X.509 y cada uno verifica el del otro contra su lista de confianza, de modo que el canal queda mutuamente autenticado. Confía en el certificado del Gate en el cliente y en el certificado del cliente en el Gate.
El cifrado aquí es RSA y AES según la suite SecurityPolicy elegida, nativo del estándar y mutuamente autenticado, no la suite TLS post-cuántica del Camino A.
Cuándo elegir B: tu servidor y tu cliente admiten seguridad de mensaje OPC UA y no TLS, y quieres un canal nativo del estándar y mutuamente autenticado, sin terminador.
Camino C: túnel en texto plano a través del Gate (alternativa)
Úsalo cuando el cliente no pueda hacer TLS y ni el cliente ni el servidor puedan terminar un SecureChannel de OPC UA. El Gate transporta la sesión. El cliente habla opc.tcp en texto plano al punto de conexión del enclave, sin cambios.
Incluso sin criptografía del lado del cliente ni en la capa de mensaje, el servidor ya no está en la red abierta. Alcanzarlo exige ser una identidad autorizada en el overlay, y cada sesión se controla y se registra. Esta es la postura mínima: control de acceso y auditoría vía el enclave, sin cambiar el cliente ni el servidor heredados.
Resumen
Tomaste un servidor OPC UA expuesto, lo colocaste dentro de un enclave para que solo sea alcanzable por una identidad autorizada a través del overlay y luego aseguraste el canal con una de tres opciones: un túnel TLS post-cuántico (Camino A), seguridad de mensaje OPC UA nativa del estándar (Camino B) o un túnel en texto plano controlado que aun así aporta control de acceso y auditoría (Camino C). El servidor y el cliente heredados nunca se modificaron.
Recurre a esto cuando un servidor OPC UA sea alcanzable, en texto plano y anónimo en la red, y necesites colocar identidad, cifrado y registro delante de él sin tocar el equipo.