OPC UA es seguro por diseño. La mayoría de los despliegues no lo son.
El protocolo incorpora firma, cifrado, identidad de aplicación por certificado y autenticación de usuario con nombre. Todo ello es opcional, y los valores por defecto vienen abiertos. Esta guía explica qué hace realmente el modelo de seguridad, qué ajuste cambia qué, y cómo proteger servidores que no se pueden reconfigurar.
Última actualización:
¿Qué es la seguridad de OPC UA y por qué suele estar desactivada?
La seguridad de OPC UA es un modelo de tres capas integrado en el protocolo: un transporte, un SecureChannel que firma y cifra cada mensaje, y una Sesión que lleva la identidad de usuario. Las tres capas son opcionales, y la mayoría de productos se entregan con SecurityPolicy None, MessageSecurityMode None y acceso anónimo activo para facilitar el primer arranque. Casi toda debilidad de OPC UA que aparece en campo es un fallo de configuración y no del protocolo, y eso mismo la hace corregible.
OPC UA es el protocolo que une un parque industrial: PLC, variadores, sensores, SCADA e historians que nunca se diseñaron para hablar entre sí. A diferencia de Modbus, se concibió con la seguridad en mente desde el principio, y el modelo es realmente bueno. El problema es que está en capas y es opcional. Un servidor puede anunciar cifrado fuerte y aun así aceptar una sesión anónima en claro por el mismo puerto, porque así se entregan la mayoría de los productos.
¿Por qué la mayoría de servidores OPC UA quedan sin proteger?
Cuatro valores por defecto explican la mayor parte de lo que encuentra una auditoría en planta. Ninguno es una vulnerabilidad de la especificación. Todos son el estado en que queda un servidor cuando terminó la puesta en marcha y nadie volvió.
SecurityMode None en producción
Un servidor dejado en SecurityPolicy None con MessageSecurityMode None acepta sesiones en claro de cualquiera que alcance el puerto TCP 4840. Puede recorrer el espacio de direcciones, leer valores de proceso en vivo y muy a menudo escribir consignas. La Fundación OPC destina None a descubrimiento y pruebas, no a transportar datos reales. Si audita una sola cosa este trimestre, audite esto. Con SecurityPolicy None tampoco hay clave con la que cifrar el token de identidad, así que un inicio de sesión UserName envía la contraseña por la red como texto claro UTF-8 (OPC UA Part 4, 7.40).
Acceso de usuario anónimo activo
La autenticación de aplicación y la de usuario son distintas. Un canal puede ser criptográficamente sólido, con certificados válidos en ambos extremos, y admitir igualmente una sesión anónima encima. Cifrar la tubería no dice nada de quién está al otro lado.
Certificados no confiables aceptados automáticamente
Aceptar certificados automáticamente resulta cómodo durante la puesta en marcha y con frecuencia no se desactiva nunca. El parámetro se llama AutoAcceptUntrustedCertificates en la pila de la Fundación OPC, a menudo etiquetado como trust-on-first-use en las interfaces de fabricante, aunque es más débil de lo que ese nombre sugiere: confía en cada certificado, cada vez, no solo en el primero que ve. Un servidor en ese estado no tiene autenticación de aplicación alguna, diga lo que diga el modo de seguridad.
Políticas obsoletas mantenidas por compatibilidad
Basic128Rsa15 y Basic256 se apoyan en SHA-1 y en un relleno RSA débil, y la Fundación OPC las ha sacado del conjunto recomendado. Suelen dejarse anunciadas para que un cliente antiguo siga funcionando, y los clientes antiguos siguen eligiéndolas.
¿Qué puede hacer un atacante con un servidor OPC UA abierto?
OPC UA es rico por diseño: un cliente puede descubrir todo el espacio de direcciones, suscribirse a valores en vivo y llamar métodos. Esa riqueza es justo lo que hace valioso para un atacante un extremo sin autenticar.
Reconocimiento del espacio de direcciones
El servicio browse está diseñado para autodescribirse. Un cliente sin autenticar puede enumerar cada nodo, su tipo de dato y a menudo el nombre legible del proceso que controla, produciendo un mapa de la planta sin enviar un solo paquete malicioso.
Escrituras no autorizadas sobre consignas
Donde el servidor expone nodos escribibles y no exige identidad de usuario, la misma sesión que lee un valor puede cambiarlo. Nada en el protocolo distingue a un ingeniero de cualquier otro que alcanzó el puerto.
Caída silenciosa a texto en claro
Algunos clientes retroceden a SecurityMode None cuando falla el handshake seguro, en vez de rechazar la conexión. Un atacante capaz de romper el handshake obtiene texto en claro, y el operador ve una conexión que funciona.
Interceptación en una red plana
Sobre opc.tcp con solo Sign, las cargas viajan legibles. Valores de proceso, nombres de tags y la forma del proceso son visibles para cualquier cosa en el mismo segmento. Las contraseñas son la excepción: la especificación obliga al servidor a cifrar por separado el token de identidad de usuario siempre que el canal no sea SignAndEncrypt, así que el fallo de contraseña en claro corresponde a SecurityPolicy None y no a Sign.
¿Cómo funciona el modelo de seguridad de OPC UA?
La seguridad de OPC UA no es un interruptor. La especificación describe tres capas que cooperan, y saber a cuál pertenece un ajuste dado es la mayor parte del trabajo.
- 01
Transporte
La conexión que mueve los bytes. Para el binding opc.tcp habitual es un socket TCP puro. Para los bindings opc.https y opc.wss es TLS.
- 02
Comunicación: el SecureChannel
Donde se establecen confidencialidad e integridad, con independencia del transporte. Sobre opc.tcp esto es UA-SecureConversation: negocia claves, firma mensajes y opcionalmente los cifra.
- 03
Aplicación: la Sesión
Se ejecuta sobre un SecureChannel y contiene la autenticación y autorización de usuario. Una sesión puede reasociarse a un canal nuevo si cae la conexión.
¿Qué diferencia hay entre None, Sign y SignAndEncrypt?
Al abrir un SecureChannel el cliente elige uno de tres modos. Se corresponden directamente con la protección que recibe el tráfico.
| Modo | Integridad | Confidencialidad | Dónde corresponde |
|---|---|---|---|
| None | Ninguna. Nada detecta manipulación. | Ninguna. Texto en claro en la red. | Solo descubrimiento y pruebas. Sin lugar en un extremo de producción. |
| Sign | Cada mensaje firmado. La manipulación se detecta. | Ninguna. Carga legible en la red. | Caso estrecho: cuando importa la integridad y la confidencialidad realmente no. |
| SignAndEncrypt | Cada mensaje firmado. | Completa. Carga cifrada. | El valor por defecto en producción. Todo lo que lleve consignas, valores de proceso o credenciales. |
¿Qué SecurityPolicy de OPC UA debería usar?
Una SecurityPolicy es el conjunto nombrado de algoritmos que usa un SecureChannel una vez elegido Sign o SignAndEncrypt. Elegir política es elegir su fuerza criptográfica.
| Política | Algoritmos | Estado |
|---|---|---|
| Aes256_Sha256_RsaPss | AES-256, SHA-256, firmas RSA-PSS | Recomendación actual. Prefiérala allí donde ambos extremos la soporten. |
| Aes128_Sha256_RsaOaep | AES-128, SHA-256, RSA-OAEP | Actual, más ligera. Aceptable cuando AES-128 cumple el requisito. |
| Basic256Sha256 | AES-256, SHA-256, firmas RSA PKCS#1 v1.5 | Muy desplegada y aún aceptable. Elección razonable cuando las políticas más recientes no están disponibles en ambos lados. |
| Basic256 | AES-256, SHA-1, RSA-OAEP | Obsoleta según la Fundación OPC. El relleno es sólido, pero SHA-1 ya no es aceptable. Su presencia es un hallazgo a remediar. |
| Basic128Rsa15 | AES-128, SHA-1, cifrado RSA PKCS#1 v1.5 | Obsoleta según la Fundación OPC. Relleno débil y hash roto. Su presencia es un hallazgo a remediar. |
Un paso de auditoría concreto
Todo servidor OPC UA anuncia los extremos que soporta mediante el servicio de descubrimiento. Enumérelos, confirme que el servidor ofrece una política fuerte con SignAndEncrypt y que las políticas obsoletas están desactivadas o no son las que los clientes eligen. Una lista de extremos es la respuesta honesta más rápida a «¿esto está protegido?».
¿Cuáles son los métodos de autenticación de OPC UA?
OPC UA autentica en dos niveles distintos, y confundirlos es una fuente frecuente de falsa confianza. Uno pregunta si el software del otro extremo es conocido. El otro pregunta quién lo está usando.
Autenticación de aplicación
Ocurre en el SecureChannel y responde a «¿esta aplicación cliente y esta aplicación servidor son quienes dicen ser?». Cada aplicación posee un certificado de instancia X.509, y ambos lados intercambian y validan certificados al abrir el canal. La confianza se gestiona con una lista de certificados de confianza: usted decide qué certificados, o qué CA emisora, acepta. Es lo que impide que una aplicación desconocida establezca un canal.
Autenticación de usuario
Ocurre en la Sesión y responde a «¿qué persona o servicio está al otro lado?». OPC UA admite varios tipos de token de identidad: Anonymous, que no tiene lugar en producción, UserName con contraseña, y certificados de usuario X.509. Un canal puede ser criptográficamente sólido a nivel de aplicación y admitir igualmente un usuario anónimo encima.
Un extremo bien protegido hace ambas cosas: valida el certificado de la aplicación par contra una lista de confianza gestionada y exige una identidad de usuario con nombre. Emitir, distribuir, confiar y rotar esos certificados es el trabajo operativo que lo hace real, y es la parte en la que la mayoría de equipos invierte de menos.
¿Dónde falla la seguridad de OPC UA en campo?
La mayoría de los incidentes de OPC UA son de configuración y no fallos del protocolo. Estos cinco explican el grueso de lo que aparece en una evaluación.
SecurityMode None en producción
El problema dominante con diferencia, y el primero que hay que comprobar.
Aceptar automáticamente certificados no confiables
AutoAcceptUntrustedCertificates dejado activo de forma permanente, lo que anula por completo la autenticación de aplicación.
Acceso anónimo junto a un canal cifrado
El canal es sólido, la sesión está abierta de par en par, y los paneles muestran el extremo como protegido.
Políticas obsoletas todavía anunciadas
Mantenidas por retrocompatibilidad, y luego elegidas justo por los clientes antiguos que le preocupaban.
Caída silenciosa a texto en claro
Un cliente que retrocede a None cuando falla el handshake seguro, en lugar de rechazar la conexión sin más.
¿Cómo gestionar certificados OPC UA sin un Global Discovery Server?
La autenticación de aplicación de OPC UA depende de certificados, y la respuesta de la especificación a escala es un Global Discovery Server (GDS, OPC UA Part 12). Muchos parques de OT nunca llegan a montarlo: es un servidor más que operar, parchear y respaldar dentro de la red de proceso, y un parque pequeño rara vez lo justifica. Las capas siguen funcionando, solo cambia la distribución.
Emitir desde una autoridad local
Una CA on-premise, o certificados de instancia autofirmados cuando el parque es lo bastante pequeño para enumerarlo. Lo que importa es que una persona haya decidido qué certificados son de confianza, no que una CA pública responda por ellos.
Poblar las listas de confianza a propósito
Cada aplicación mantiene su propia lista de confianza. Llenarla durante la puesta en marcha, y desactivar después AutoAcceptUntrustedCertificates, es lo que convierte los certificados de adorno en autenticación.
Planificar la rotación antes de la caducidad
Los certificados caducan, y en un parque aislado nada los renueva solo. Una caducidad que nadie siguió se convierte en una parada en domingo. Registre fechas de emisión y caducidad en el mismo runbook que guarda el resto del estado de la red.
O sacar el problema de los equipos
Cuando el trabajo de certificados equipo por equipo no es realista, terminar la sesión en un proxy que entiende el protocolo permite que un único componente sostenga la PKI en lugar de que cada equipo sostenga un trozo.
Checklist de endurecimiento de OPC UA: qué verificar
La seguridad de OPC UA se reduce a una lista corta y comprobable. Casi todo es verificación más que construcción. Todo ello da por hecho una cosa: que tiene permiso para cambiar el extremo. Cuando no lo tiene, la siguiente sección cubre la otra forma de cerrar las mismas brechas.
- 01
Confirmar que ningún extremo de producción funciona en MessageSecurityMode None.
- 02
Exigir SignAndEncrypt para todo lo que lleve datos de proceso, consignas o credenciales.
- 03
Elegir una SecurityPolicy actual, preferiblemente Aes256_Sha256_RsaPss, y retirar Basic128Rsa15 y Basic256.
- 04
Validar los certificados de instancia contra una lista de confianza gestionada y desactivar AutoAcceptUntrustedCertificates al terminar la puesta en marcha.
- 05
Exigir identidad de usuario con nombre. Desactivar el acceso anónimo.
- 06
Confirmar que los clientes se niegan a degradar en vez de caer a texto en claro.
- 07
Recordar que sobre opc.tcp la protección es el SecureChannel, mientras que opc.https y opc.wss van sobre TLS. Compruebe el binding antes de razonar sobre qué puede ver un proxy o una captura.
Estos controles se corresponden con la identificación y autenticación de IEC 62443 (FR1) y el control de uso (FR2), con NIST SP 800-82r3 para sistemas de OT, y con las medidas de control de acceso que el artículo 21 de NIS2 exige a las entidades esenciales e importantes.
¿OPC UA usa TLS?
Sobre opc.tcp, lo que protege sus datos es el SecureChannel, no TLS. Una conexión que parece cifrada no usa necesariamente TLS, porque UA-SecureConversation hace su propia firma y su propio cifrado. TLS solo entra en juego con los bindings opc.https y opc.wss. Esto importa en cuanto razona sobre qué puede ver y qué no un cortafuegos, una captura de red o un proxy que termina TLS.
¿Cómo proteger un servidor OPC UA que no puede reconfigurar?
La checklist da por hecho que puede cambiar el extremo. A menudo no puede: el fabricante lo prohíbe, no existe ventana de mantenimiento, o el servidor es anterior a las partes de la especificación que quiere aplicar. La alternativa es poner la protección delante del equipo, en la red, para que el extremo inseguro nunca sea alcanzable directamente.
Envolverlo en un túnel transparente
Access Gate opera su propia PKI y emite certificados terminales al vuelo. El canal hacia el Gate es TLS 1.3 con intercambio de claves post-cuántico (ML-KEM-768), verificado contra esa PKI, delante de un servidor que no habla nada de eso, y sin trabajo de certificados equipo por equipo.
Denegación por defecto, por identidad y protocolo
Dar a un usuario acceso OPC UA a un activo no le da nada más. Cada protocolo en cada activo es un permiso explícito, que es justo la aplicación que la sesión anónima del servidor no puede ofrecer.
Mantener el servidor fuera de la red plana
El extremo queda dentro de un enclave segmentado y conserva su propia IP. Nada cambia en el equipo, y nada llega al puerto TCP 4840 sin pasar antes por la política.
Registrar quién se conectó a qué
El mismo proxy que filtra el canal registra la sesión: qué identidad, qué activo, qué protocolo. Esa es la evidencia de control de acceso que en último término piden IEC 62443, NIST SP 800-82r3, NIS2 y CMMC.
Controlar un servidor OPC UA sin tocarlo
Si su parque tiene servidores que no se pueden reconfigurar, o un trabajo de certificados poco realista por equipo, podemos repasar juntos qué aspecto tiene filtrar el canal en su red.
Configurar el acceso OPC UA
La guía paso a paso: llevar un servidor inseguro a un enclave y luego proteger el canal con TLS, seguridad de mensaje o un túnel filtrado.
Verlo en su propio parque
Un repaso sobre su topología: qué extremos están expuestos, cómo se ve la aplicación de políticas y qué exige el despliegue.
Preguntas sobre seguridad en OPC UA
El puerto TCP por defecto de OPC UA. Un extremo escuchando aquí en SecurityMode None es legible, y a menudo escribible, por cualquier cosa que pueda enrutar hasta él.
Solo en algunos bindings. Los bindings opc.https y opc.wss van sobre TLS. El binding opc.tcp habitual no: usa UA-SecureConversation, la firma y el cifrado propios del protocolo en la capa SecureChannel. Una conexión puede estar totalmente cifrada sin TLS de por medio, lo que importa al razonar sobre qué puede ver un proxy que termina TLS o una captura de red.
No. El modelo de seguridad es sólido, pero cada una de sus capas es opcional, y la mayoría de productos se entregan con SecurityPolicy None, MessageSecurityMode None y acceso anónimo activo para facilitar el primer arranque. Un servidor solo es seguro si alguien lo configuró así tras la puesta en marcha.
Sign aporta integridad: cada mensaje va firmado, así que la manipulación se detecta, pero la carga sigue siendo legible en la red. SignAndEncrypt añade confidencialidad, la carga también va cifrada. Para tráfico de OT en producción, SignAndEncrypt debería ser el valor por defecto; Sign solo tiene un hueco estrecho, cuando la confidencialidad realmente no importa.
Aes256_Sha256_RsaPss donde ambos extremos la soporten, y Basic256Sha256 como alternativa aceptable. Basic128Rsa15 y Basic256 están obsoletas: se apoyan en SHA-1 y en relleno RSA débil, y la Fundación OPC las ha sacado del conjunto recomendado. Si un servidor aún las anuncia, trátelo como un hallazgo y no como un ajuste a preservar.
Ponga la protección delante. Lleve el servidor a un enclave segmentado para que no sea alcanzable directamente, y termine la sesión en un proxy que entiende el protocolo y aplica identidad y política antes de restablecer la conexión con el activo. El equipo conserva su IP, su firmware y su configuración, y el cifrado, el control de acceso y el registro ocurren en el punto de paso en lugar de en el extremo.
