Introducción
El objetivo es pasar de una conexión OPC UA que funciona, pero deja información visible, a una comunicación con confianza mutua y canal cifrado.
En el artículo anterior dejamos el servidor OPC UA del PLC Siemens funcionando y validado desde UA Expert. Aquí continuamos desde ese punto: certificados, confianza y comparación entre None, Sign y Sign & Encrypt.
Herramientas: Wireshark, TIA Portal V20, PLCSIM Advanced V7.0 y UA Expert.
Problema de comunicación insegura
Wireshark con None
Partimos con la conexión de UA Expert configurada en None. En este modo la comunicación funciona, pero el tráfico de aplicación puede inspeccionarse desde la máquina donde está el cliente.
En Wireshark se ve la negociación, los mensajes OPC UA y la actividad entre el cliente y el PLC simulado.
Cuando introducimos las credenciales y se completa la autenticación, la sesión queda activa. El usuario aparece en la traza, y aunque la contraseña no se ve como texto plano en esta captura, los datos de proceso siguen viajando sin cifrado efectivo.
Valores visibles en Wireshark
Para comprobarlo de forma clara, fijamos valores en el PLC y los cambiamos manualmente. Cuando el servidor publica el cambio, cazamos un PublishResponse del PLC hacia el cliente.
La ruta de anidación dentro del paquete de Wireshark es esta:
- OpcUa Service: bloque raíz del payload OPC UA.
- PublishResponse: respuesta del servidor a la suscripción del cliente.
- NotificationMessage: contenedor principal de los datos publicados.
- DataChangeNotification: confirma que se trata de un cambio de valor.
- MonitoredItemNotification: elemento monitorizado que ha cambiado.
- DataValue / Variant: valor real de la variable y sus metadatos.
Con una variable Real ocurre lo mismo. Si el canal no cifra, Wireshark permite seguir el paquete hasta el dato publicado.
Con esto comprobamos que cualquiera que capture el tráfico entre servidor y cliente podría ver los paquetes y su contenido, con los riesgos que esto conlleva.
Securización
Conceptos básicos
Cuando hablamos de seguridad, hablamos de proteger la comunicación en varios aspectos:
Firma, cifrado y certificado
- Firma: valida integridad y autenticidad. Si alguien modifica el mensaje, se detecta.
- Cifrado: oculta el contenido. Aunque alguien capture la trama, no puede leer variables ni valores.
- Certificado: identifica a una aplicación o servidor y permite establecer confianza. En OPC UA hay políticas y algoritmos antiguos que ya están obsoletos o debilitados; son más atacables, así que conviene evitarlos y usar políticas actuales soportadas por PLC y cliente.
Tipo de seguridad OPC UA
En la seguridad del Servidor OPC UA de la primera prueba, activamos una política con Sign. Es útil para ver el flujo de confianza, pero por sí sola no cifra los datos de proceso.
Activar Certificate Manager
El siguiente paso es habilitar el Certificate Manager en el proyecto de TIA Portal. Antes de generar certificados, compilamos para ver qué errores aparecen y separar los problemas.
Al activarlo y compilar el proyecto, nos arroja errores de compilación derivados de esta activación.
Al activar la gestión de certificados, TIA Portal nos obliga a crear un usuario para la gestión del proyecto. Después ya aparecen las Security features necesarias.
Se ha creado un usuario con permisos de administración de ingeniería.
Al hacerlo se activan las características de seguridad del proyecto.
Crear Autoridad certificadora (CA) y certificado del servidor OPC UA
En este punto necesitamos tres cosas:
- Crear la Certificate Authority del proyecto.
- Crear el certificado del OPC UA Server.
- Asignar el certificado al PLC para que lo pueda usar el servidor OPC UA.
La Certificate Authority es quien va a emitir, firmar y validar los certificados del proyecto. En una prueba local puede ser una CA del propio proyecto; en planta habría que encajar esto con la política de certificados de la instalación.
Ahora creamos el certificado del OPC UA Server. Seleccionamos el uso correspondiente, definimos un nombre común y añadimos los Subject Alternative Names necesarios: aplicación, IP y/o URI.
El SAN es importante porque da al cliente más pruebas de que ese certificado pertenece a ese servidor concreto. No solo dice “soy el PLC”, también dice “soy válido para esta IP, este nombre o esta URI OPC UA”.
Después asignamos el certificado al PLC para que se almacene en el propio controlador y pueda seleccionarse dentro de la configuración del servidor OPC UA.
Lo asignamos como certificado del OPC UA server.
Al compilar de nuevo, el error específico de OPC UA sin certificado desaparece. El servidor OPC UA ya tiene certificado asociado.
Certificado PG/PC y HMI
Aunque no es el objetivo principal de este artículo, generamos también el certificado para comunicaciones PG/PC y HMI. Esto deja preparado el camino para otros escenarios, por ejemplo WinCC Unified.
De nuevo, lo asignamos a los certificados almacenados en el PLC.
Para asignarlo al servicio, entramos en Protection & Security y en los mecanismos de conexión lo asociamos donde corresponde.
De nuevo compilamos, y ya no hay errores asociados a la seguridad que habilitamos.
Confiar en el servidor desde UA Expert
Descargamos el PLC y volvemos a UA Expert.
Lo primero que aparece es esperable: el cliente ya no considera confiable el certificado del servidor.
Si intentamos usar la conexión anterior en None, no sirve. Rehacemos la conexión seleccionando la política segura que vamos a probar e introducimos las credenciales del usuario.
Como todavía no hemos importado correctamente la autoridad certificadora, UA Expert muestra el aviso de confianza.
Podemos aceptar temporalmente para ver variables, pero esa no es la solución buena, ya que la conexión no es confiable.
Importar CA y CRL en UA Expert
La solución es hacer que UA Expert confíe en la Certificate Authority que firmó el certificado del PLC. Exportamos la CA desde TIA Portal y la copiamos en la carpeta de issuers de UA Expert.
Introducimos clave para la exportación:
Y lo guardamos en la ruta del cliente UA Expert: y ahí movemos el certificado del CA
Y verificamos que está como Issuer.
Después aparece otro aviso: falta la lista de revocación o CRL. No basta con copiar la CA; el cliente también espera poder comprobar si un certificado emitido por esa CA ha sido revocado.
Vamos al Certificate Manager para exportar, pero ahora seleccionamos el tipo de archivo este:
y de nuevo, En UA Expert del cliente, lo introducimos en su ruta: en este caso es en "crl"
Una vez importada la CA y su CRL, el lado de UA Expert queda correcto y el servidor OPC UA del PLC ya puede validarse de forma limpia.
Queda corriendo y el log del UA Expert nos confirma que no hay errores.
Confiar en el cliente UA Expert
Queda una pregunta importante: ¿por qué en la primera prueba no tuvimos que importar el certificado de cliente de UA Expert en el PLC?
Es decir, no le hemos dicho al PLC que hay un cliente concreto, que va a conectarse a su servidor OPC UA.
La razón era esta opción del PLC: Automatically accept client certificates during runtime. Con esa opción activa, el PLC acepta certificados de cliente durante la ejecución. Es cómodo para pruebas, pero no es lo ideal si queremos una confianza controlada.
Al desactivar esa aceptación automática, descargamos de nuevo el PLC y la conexión ya no entra. Ahora sí necesitamos registrar explícitamente el certificado de cliente de UA Expert en el proyecto.
Para conseguirlo vamos a los certificados propios de UA Expert, dentro de own, y localizamos el certificado de la aplicación cliente.
Importamos ese certificado en el Certificate Manager del proyecto, junto al resto de certificados que hemos generado antes.
Una vez hecho, ahora sí se lo asignamos como certificado de Cliente de OPC UA:
Al hacerlo ya vemos que pone que esta usado para OPC UA.
Descargamos el PLC y repetimos la conexión. Ahora el camino está completo: UA Expert confía en la CA y la CRL del PLC, y el PLC confía en el certificado de cliente de UA Expert.
Pasar de Sign a Sign & Encrypt
Con los certificados ya ordenados, toca mirar Wireshark otra vez. En la prueba con Sign, los equipos confían entre sí y los mensajes van firmados, pero el contenido no queda cifrado.
Esto es el punto fino del artículo: firmar no es cifrar.
La firma protege contra modificación, pero no impide que se lean los datos si el modo elegido no cifra el canal.
Cambiamos entonces la seguridad del canal a Sign & Encrypt, descargamos el PLC y rehacemos la conexión desde UA Expert con la nueva política.
Ahora la conexión es inmediata y todo comunica bien a la primera porque los certificados son los mismos, lo que hemos cambiado es la política, es decir, la manera de protegerlos:
Verificación
Comprobar cifrado en Wireshark
Al volver a capturar, ya no podemos seguir la misma ruta hasta los valores monitorizados. Ni siquiera resulta igual de evidente localizar las respuestas de publicación. La conversación está cifrada.
Este es el resultado que buscábamos: certificados bien distribuidos, confianza mutua entre cliente y PLC, y canal OPC UA con cifrado activo.
Claves del artículo
- Política None en OPC UA: sirve para probar rápido, pero deja la conversación observable en Wireshark.
- Usuario y contraseña: controlan el acceso, pero no sustituyen al cifrado del canal.
- Certificate Manager: habilita la gestión formal de certificados dentro del proyecto TIA Portal.
- CA del proyecto: emite y firma los certificados que después deben confiar cliente y servidor.
- Certificado OPC UA Server: identifica al PLC como servidor y debe incluir nombres alternativos coherentes con IP, nombre o URI.
- UA Expert: debe confiar en la CA del PLC y tener disponible la lista de revocación.
- Certificado de cliente: si el PLC no acepta clientes automáticamente, hay que importar el certificado de UA Expert como cliente confiable.
- Sign: firma el mensaje y ayuda con la integridad, pero no oculta el dato.
- Sign & Encrypt: es el punto en el que la captura deja de mostrar los valores de proceso.
Esquema mental: primero hacemos que las partes se conozcan mediante certificados; después hacemos que confíen en la CA y en la CRL; por último elegimos un modo de seguridad que cifre realmente. Si falta una de esas piezas, la conexión puede fallar o puede funcionar sin estar tan protegida como creemos.
Notas:
- Dependiendo del cliente OPC utilizado, puede ser que se exijan unas medidas de seguridad distintas en el certificado.
- No todos los clientes soportan las políticas de seguridad más modernas.
- Las políticas de seguridad antiguas son susceptibles de ser atacadas, por eso se usan las modernas.
Artículos relacionados