Seguridad de OPC UA: lo que todo ingeniero de OT debería saber

Por qué la seguridad de OPC UA merece una mirada más atenta

Como ingeniero de tecnología operativa (OT), usted ya sabe cuánto depende de los sistemas industriales. OPC UA (Open Platform Communications Unified Architecture) se ha convertido en un protocolo estándar que une esos sistemas entre sí: PLC, sensores, variadores, SCADA e historiadores que nunca se diseñaron para interactuar entre sí. La buena noticia es que OPC UA se concibió pensando en la seguridad desde el principio. La mala es que ese modelo es por capas y opcional, lo que significa que la mayoría de las implementaciones de campo activan solo una parte, o ninguna. Saber exactamente qué ofrece el protocolo, y qué cambia cada ajuste, marca la diferencia entre un extremo reforzado y una puerta abierta.

Esta guía recorre el modelo de seguridad de OPC UA tal como lo estructura realmente la especificación y, después, señala los errores que aparecen con más frecuencia en el campo.

El modelo de seguridad por capas

La seguridad de OPC UA no es una única función que se activa. El documento OPC Foundation Part 2 Security Model la describe como tres capas que cooperan, cada una de las cuales resuelve un problema distinto:

1. Capa de transporte. Es la conexión subyacente que mueve los bytes entre el cliente y el servidor. Para el binding habitual opc.tcp, el transporte es un socket TCP simple. Para los bindings HTTPS y WebSocket (opc.https, opc.wss), el transporte es TLS.
2. Capa de comunicación (el SecureChannel). Aquí OPC UA establece la confidencialidad y la integridad de la conversación, con independencia del transporte. Sobre opc.tcp, esta capa la proporciona UA-SecureConversation, definida en OPC Foundation Part 6 Mappings. Negocia las claves, firma los mensajes y, opcionalmente, los cifra.
3. Capa de aplicación (la Session). Una Session se ejecuta sobre un SecureChannel y es donde residen la autenticación y la autorización del usuario. Un mismo SecureChannel puede transportar una Session, y las Session pueden reasociarse a un canal nuevo si la conexión subyacente se cae.

Lo esencial que debe interiorizar: sobre opc.tcp, la seguridad que protege sus datos es el SecureChannel, no TLS. Es habitual suponer que, como una conexión «parece cifrada», debe usar TLS, pero opc.tcp realiza su propia firma y su propio cifrado mediante UA-SecureConversation. TLS solo entra en juego cuando se usan los bindings opc.https o opc.wss. Esta distinción importa en cuanto razona sobre lo que un cortafuegos, una captura de paquetes o un proxy que termina TLS puede ver, o no.

MessageSecurityMode: None, Sign, SignAndEncrypt

Cuando un cliente abre un SecureChannel, elige un MessageSecurityMode. Hay tres valores, que se corresponden directamente con la protección que recibe realmente su tráfico:

• None. Sin firma ni cifrado. Los mensajes viajan en texto claro y nada verifica que no se hayan alterado en tránsito. Equivale a usar el protocolo con las puertas quitadas.
• Sign. Cada mensaje se firma, de modo que el receptor puede detectar manipulaciones y confirmar que el mensaje procede del titular de la clave negociada. El contenido sigue siendo legible en la red, pero no se puede modificar de forma silenciosa.
• SignAndEncrypt. Los mensajes se firman y se cifran. Así obtiene integridad y confidencialidad a la vez, y es el modo que conviene para todo lo que transporte consignas, valores de proceso o credenciales.

Para el tráfico de OT en producción, SignAndEncrypt debe ser el valor por defecto. El modo Sign por sí solo tiene un lugar limitado, cuando la confidencialidad realmente no importa pero la integridad sí. El modo None no tiene prácticamente ningún lugar en producción, lo que nos lleva al error más frecuente en el campo.

La trampa del modo None

El problema de seguridad de OPC UA más frecuente no es un exploit exótico. Son servidores que se dejan en SecurityPolicy=None, con MessageSecurityMode=None y acceso de usuario anónimo, exactamente la configuración con la que muchos productos se entregan por defecto para facilitar el primer arranque. En ese estado, cualquiera que pueda alcanzar el puerto TCP (a menudo el 4840) puede recorrer el espacio de direcciones, leer valores de proceso en directo y, con frecuencia, escribir consignas, sin autenticación ni cifrado.

No es un riesgo teórico. Así funciona realmente una gran parte de los servidores OPC UA expuestos a Internet o presentes en redes planas, porque los modos seguros nunca se activaron tras la puesta en marcha. La propia orientación de la OPC Foundation en el artículo "Exploring OPC UA Security Concepts" indica de forma explícita que el modo None está pensado para el descubrimiento y las pruebas, no para transportar datos reales. Si solo audita una cosa este trimestre, busque el modo None en los extremos de producción.

SecurityPolicies: qué conjunto criptográfico está en uso

Una SecurityPolicy es el conjunto con nombre de algoritmos criptográficos, el hash, los cifrados simétrico y asimétrico, los algoritmos de firma y de derivación de claves, que un SecureChannel usa una vez seleccionado Sign o SignAndEncrypt. Elegir una política es elegir su nivel de robustez criptográfica. Las que encontrará:

• Aes256_Sha256_RsaPss. La política recomendada en la actualidad. Usa AES-256, SHA-256 y firmas RSA-PSS. Prefiérala cuando ambos extremos la admitan.
• Basic256Sha256. Muy desplegada y todavía considerada aceptable. AES-256 con SHA-256 y firmas RSA-PKCS#1 v1.5. Una opción razonable cuando la política más reciente no está disponible en ambos lados.
• Basic128Rsa15 y la antigua Basic256. Estas políticas están obsoletas. Se basan en SHA-1 y en un relleno RSA débil, y la OPC Foundation las ha retirado del conjunto recomendado. Trate su presencia como un hallazgo que corregir, no como una configuración que conservar.

Un paso de auditoría práctico: enumere los endpoints que anuncia un servidor (cada servidor OPC UA expone sus endpoints admitidos mediante el servicio de descubrimiento) y confirme que ofrece una política robusta con SignAndEncrypt, y que las políticas obsoletas están desactivadas o no son las que los clientes seleccionan.

Autenticación de aplicación frente a autenticación de usuario

OPC UA autentica en dos niveles distintos, y confundirlos es una fuente frecuente de falsa confianza.

• La autenticación de aplicación se produce en el nivel del SecureChannel y responde a «¿son esta aplicación cliente y esta aplicación servidor quienes dicen ser?». Se basa en certificados de instancia de aplicación: cada aplicación posee un certificado X.509, y ambas partes intercambian y validan sus certificados al establecer el canal. La confianza se gestiona mediante una lista de certificados de confianza en cada lado; usted decide qué certificados (o qué autoridad de certificación emisora) acepta. Esto es lo que impide que una aplicación desconocida establezca un canal seguro.
• La autenticación de usuario se produce en el nivel de la Session y responde a «¿quién, persona o servicio, está al otro extremo?». OPC UA admite varios tipos de tokens de identidad de usuario: Anonymous (sin identidad de usuario, evítelo en producción), UserName/Password, y certificados de usuario X.509. Un SecureChannel puede ser criptográficamente sólido en el nivel de aplicación y, aun así, admitir un usuario anónimo en el nivel de sesión, por lo que ambas capas requieren atención.

La conclusión: un extremo OPC UA correctamente asegurado valida el certificado de la aplicación remota frente a una lista de confianza gestionada y exige una identidad de usuario con nombre en lugar de acceso anónimo. La gestión de certificados, su emisión, distribución, confianza y rotación para los certificados de aplicación y de usuario, es el trabajo operativo que hace esto real, y es también la parte en la que la mayoría de los equipos invierte de menos.

Dónde se concentran los riesgos reales

La mayoría de los incidentes de OPC UA en el campo se deben a la configuración, no a defectos del protocolo:

• El modo None en producción, descrito antes, el problema dominante.
• La aceptación automática de certificados no confiables. Algunas implementaciones configuran el servidor para confiar en cualquier certificado que vea (un «trust on first use» dejado activado de forma permanente), lo que anula por completo la autenticación de aplicación.
• El acceso de usuario anónimo dejado activado junto a un canal por lo demás cifrado.
• Las SecurityPolicies obsoletas mantenidas disponibles por compatibilidad y luego seleccionadas por clientes antiguos.
• El repliegue a texto claro cuando un cliente baja en silencio al modo None si el saludo seguro falla, en lugar de rechazar la conexión.

Son exactamente las debilidades que orientaciones de OT más amplias, como el NIST SP 800-82, Guide to Operational Technology Security, le piden encontrar y cerrar: imponer la autenticación, proteger los datos en tránsito y segmentar la red para que un extremo no asegurado no sea directamente alcanzable desde cualquier lugar.

Qué hacer al respecto

Por lo general dispone de dos vías complementarias. La primera consiste en configurar correctamente la seguridad de OPC UA en los propios extremos: seleccionar una SecurityPolicy robusta, exigir SignAndEncrypt, validar los certificados de aplicación frente a una lista de confianza real y exigir autenticación de usuario con nombre. La segunda, para servidores y clientes heredados que no puede reconfigurar, consiste en situar la protección delante del dispositivo en el nivel de red, colocando el servidor dentro de un enclave segmentado y asegurando el canal mediante un túnel controlado, de modo que el extremo no asegurado nunca quede directamente expuesto.

Proteger los endpoints OPC UA que no pueden protegerse por sí mismos

Esa segunda vía es justo la brecha que Trout Access Gate está diseñado para cerrar. En lugar de aprovisionar y mantener certificados en cada endpoint, Access Gate termina la sesión en un proxy consciente del protocolo, aplica identidad y política, y restablece la conexión con el activo. Ese único punto de paso es lo que permite añadir cifrado, imponer el control de acceso y ver el tráfico sin tocar el firmware del dispositivo.

Para un servidor OPC UA, o cualquier protocolo en texto plano o heredado, esto significa que puede:

• Envolverlo en un túnel TLS transparente. Access Gate opera su propia PKI y emite certificados terminales sobre la marcha, de modo que un dispositivo que habla en texto plano en la planta puede alcanzarse de forma segura a través de una red más amplia, sin trabajo de certificados dispositivo por dispositivo. La guía Configurar el cifrado TLS lo cubre de principio a fin, y El papel de TLS en la seguridad de OPC UA explica dónde se aplica TLS a OPC UA y dónde no.
• Denegación por defecto según identidad y protocolo. Conceder a un usuario acceso OPC UA a un activo no concede nada más; cada protocolo en cada activo es una autorización explícita. Consulte Casos de uso de configuración de protocolos.
• Segmentar y observar. El mismo proxy que controla el canal registra quién se conectó, a qué y mediante qué protocolo, la evidencia que marcos como NIST 800-171, CMMC y NIS2 acaban exigiendo. Este es el núcleo de la seguridad de red OT.

Conclusión

La seguridad de OPC UA se reduce a una lista breve y comprobable. Confirme que los extremos de producción no funcionan en modo None. Exija SignAndEncrypt con una SecurityPolicy actual como Aes256_Sha256_RsaPss, y retire las políticas obsoletas como Basic128Rsa15. Valide los certificados de instancia de aplicación frente a una lista de confianza gestionada, y exija autenticación de usuario con nombre en lugar de acceso anónimo. Recuerde que sobre opc.tcp su protección es el SecureChannel, mientras que opc.https y opc.wss se apoyan en TLS. Casi todas las debilidades de OPC UA que encontrará en el campo son lagunas de configuración, no defectos del protocolo, lo que significa también que puede corregirlas.