Introducción del protocolo OPC
El protocolo OPC surgió de la idea de crear una interfaz estándar y común para comunicar sistemas de control industrial. El mercado de los sistemas de control originalmente había estado dominado por protocolos de comunicación propietarios, cada uno vinculado a una plataforma de hardware concreto (a un PLC) de un fabricante determinado. Estos protocolos propietarios eran complejos y eran diferentes entre ellos, lo que requería un desarrollo exprofeso para conectar cada PLC con los sistemas de gestión de: fabricación MES, procesos PIMS, compañía ERP/SAP.
Evidentemente todos estos protocolos no eran compatibles entre ellos y no existía un lenguaje común que “hablasen” todos los sistemas de control para poderse comunicar con facilidad.
Para cubrir esta necesidad de una comunicación genérica, nació el protocolo OPC.
El protocolo OPC está basado en un pilar tecnológico, que es la tecnología COM y DCOM de Microsoft. Esta tecnología permite comunicar los diferentes equipos que forman una red industrial de procesos, pero añadiendo una capa de abstracción a la información.
El protocolo OPC usa la arquitectura clásica cliente-servidor para gestionar las comunicaciones. El servidor OPC tiene la misión de encapsular la información y publicarla (hacerla disponible y accesible para los demás equipos) usando su interfaz de datos. El cliente OPC tiene la capacidad de conectarse al servidor OPC y acceder a la información publicada.
En el OPC clásico, estas interfaces de datos y comunicaciones están basadas en la tecnología COM y DCOM de Microsoft
En el OPC UA (es la última actualización del estándar), se usan dos protocolos para las comunicaciones:
- Un protocolo OPC-TCP, que es un protocolo de bajo nivel (binario) de alto rendimiento.
- Un protocolo HTTP basado en web services.
Evolución del protocolo OPC
La primera versión del OPC es del año 1995, debemos tomar conciencia de que este protocolo tiene casi 30 años. En estos 30 años los entornos industriales han cambiado y las necesidades que los mueven también.
La versión primigenia del protocolo OPC, se diseñó adaptándose a las necesidades de comunicación que tenía la industria de aquel instante. Esto implicó que fuesen necesario cubrir tres nichos de datos: datos vivos, alarmas y eventos, y datos históricos. Para cada uno de esos nichos se creó una especificación diferente:
- OPC DA (Data Access): permite acceder a datos vivos del proceso.
- OPC A&E (Alarm and Events): utilizado para capturar la información de las alarmas y eventos, que se generan en cualquier proceso productivo. Alarmas de alta temperatura, bajo caudales, alta presiones y eventos de producción (lote iniciado, fase X iniciada, lote Y fabricado).
- OPC HDA (Historical Data Access): esta especificación permitía que el servidor fuese capturando periódicamente los datos vivos a intervalos determinados, creando un “histórico de datos vivos” que sería almacenado y posteriormente consultado por el cliente OPC.
De las tres especificaciones, la interfaz OPC DA es la más usada y la más implementadas en dispositivos industriales que usan este protocolo. Realmente es el protocolo más simple de los tres. Las interfaces OPC A&E y OPC HDA son menos relevantes y se utilizan a modo de complemento de OPC DA, sobre todo la de A&E que se usa para integrar alarmas de múltiples sistemas, cuando el sistema de control empieza a tener un cierto tamaño y es importante tener una visión de conjunto.
Después surgió el OPC XML DA, que fue un intento fallido de crear una especificación OPC independiente de la plataforma. Esta especificación intentó sustituir la tecnología propietaria de Microsoft COM y DCOM por las tecnologías HTTP/SOA y otras tecnologías web, pero intentando mantener la funcionalidad de OPC-DA. Su principal problema era su bajo rendimiento y el alto consumo de recursos en el servidor.
Los problemas del OPC Clásico
La tecnología COM y DCOM de Microsoft tiene un problema en la complejidad en su configuración. Para esto, se usa una herramienta de Windows que se llama DCOMCNFG, que permite configurar cada servicio DA (el OPC DA realmente es un objeto más dentro del DCOM) y configurar los niveles de inicio y activación, permisos de acceso y configuración. La mayoría de los manuales de integración del protocolo OPC dejan completamente desprotegido este protocolo dándole a todos los usuarios acceso total (acceso de administración). Da igual del fabricante que sea el manual de protocolo OPC.
La configuración correcta y securizada del OPC DA es un tema complejo y nada banal, añadiendo el problema de que no es realmente una comunicación encriptada.
Otro problema es el uso masivo de puertos TCP (ver Nota 1), que es necesario abrir en los firewalls cuando se usa este protocolo entre la red industrial OT y la red de gestión de compañía IT.
Cuando se piden las aperturas de estos puertos al personal de ciberseguridad, siempre es la misma pregunta: “¿realmente es necesario abrir todos estos puertos?”
Nota 1: Para hacer una comunicación ethernet, aparte de conocer las direcciones IP de ambos equipos, también hay que conocer el puerto. El puerto se identifica con un numero entre 1 a 65535. Este número es el que identificador del canal de comunicación. En base a esto entre dos máquinas, podremos tener 65535 “tubos” de comunicación que podremos ir abriendo por donde intercambiar información de forma simultánea.
La solución: OPC UA
Para solucionar estos problemas surge el OPC UA.
Se necesita una herramienta “independiente” de la plataforma hardware (y del sistema operativo subyacente), pero debe mantener: rendimiento y características del OPC clásico.
La aparición de OPC UA es un cambio radical para las comunicaciones OPC.
Desvinculación total de las tecnologías COM Y DCOM de Windows, dejando de ser un requisito obligatorio y dando independencia de la plataforma.
Esto implica un cambio del significado de las siglas OPC, de OLE for Procces Control a Open Platform Communication.
Para conseguir una infraestructura independiente, manteniendo toda la funcionalidad, se definen los mecanismos de transporte y modelo de datos.
Respecto al transporte se definen dos mecanismos, como ya se han mencionado anteriormente, un protocolo OPC-TCP binario de alto rendimiento para comunicaciones intranet y acceso a los estándares de Internet aceptados como HTTP mediante web services.
Respecto al modelo de datos se definen las reglas y bloques necesarios para el acceso al espacio de direcciones. Esta es la famosa estructura de árbol del OPC Clásico, donde cuelgan los tags o ítems que son los identificadores de los valores vivos que vamos a leer.Los servicios en OPC UA se definen de forma abstracta y se utilizan los mecanismos de transporte para intercambiar datos entre cliente y servidor. Gracias a esta abstracción, un cliente puede acceder a los datos sin entender el modelo de datosinferior.
Medidas de seguridad OPC UA vs OPC clásico
En el estándar OPC se implementan varias medidas de seguridad para garantizar la confidencialidad, integridad y disponibilidad.
Para conseguir esto se marcan los siguientes objetivos:
- Autenticación de la aplicación
Este mecanismo permite que las aplicaciones OPC UA pueden identificarse unas a las otras. Tienen un certificado digital que comparte en la fase de conexión.
En cambio, en OPC clásico, no todos los clientes y servidores OPC soportan este tipo de autentificaciones. Esta autentificación requiere una configuración de los objetos DCOM (herramienta Dcomcnfg). Es un trabajo arduo y requiere unos conocimientos avanzados para que sea implementada correctamente (que no es lo habitual), ya que requiere configurar todos los elementos DCOM.
El OPC UA aporta mayor facilidad para implementar autenticación de la aplicación en comparación con la versión clásica.
- Autenticación del usuario
En OPC UA la autenticación del usuario es de obligado cumplimiento.
Hay varios mecanismos de autenticación soportados, en comparación con la versión clásica, en la que la autenticación no está habilitada por defecto, siendo costosa y compleja su implementación.
Tres son los mecanismos soportados son: Usuario y contraseña, Certificado digital y ticket Kerberos.
Todas las aplicaciones que usen OPC UA deben soportar como mínimo usuario y contraseña. Es la más fácil de implementar, pero debe configurarse en cada aplicación.
La identificación del usuario es específica de la aplicación.
La identificación de usuario de OPC UA funciona de manera similar entre máquinas dentro de: un grupo de trabajo, un dominio, entre dominios distintos, o incluso cuando los sistemas operativos son distintos.
En el OPC clásico el acceso no es restringido por defecto.
En un entorno de dominio, el dominio identifica a todos los servidores OPC clásicos y les asigna derechos de acceso apropiados a los grupos de usuarios (roles) de los clientes que se conectarán. Como todas las cuentas de un dominio se administran desde un controlador de dominio, es simple habilitar la autenticación de los usuarios.
En un entorno sin dominio, se puede configurar, pero requiere trabajo adicional para identificar a los usuarios, que son cuentas comunes en todas las máquinas, grupo de usuarios comunes.
- Autorización del usuario
En OPC UA, cuando el usuario es identificado y autenticado, es la aplicación la encargada de restringir los derechos de acceso de navegación y de lectura / escritura, etc.
Lo mismo ocurre en OPC clásico, las aplicaciones proporcionan restricciones de acceso individual para un elemento determinado frente al acceso DCOM de lectura o escritura.
Pero en la práctica, esto está incluido realmente en muy pocas.
- Disponibilidad del servidor
La disponibilidad de servidores no es algo inherente al protocolo. Es recomendable que los servidores OPC implementen servidores de respaldo y redundancia.
- Auditabilidad del sistema
En OPC UA también se contempla la capacidad de ser auditado.
OPC UA define los mecanismos para que un servidor almacene ficheros log de todos los eventos relevantes.
- Confidencialidad e integridad
La confidencialidad e integridad de los datos se implementa en la capa de transporte de OPC UA mediante el cifrado de las comunicaciones.
Si se usan los servicios web, se usa el protocolo WS Secure Conversation.
Si se usa la versión TCP binaria se usa una adaptación de WS Secure Conversation. También existe una versión mixta en la cual se utiliza TLS.
En el OPC clásico, DCOM se puede configurar para firmar los datos y el cifrado, pero no es una opción por defecto.
Por tanto, la principal ventaja del OPC UA es que el cifrado está habilitado por defecto.
Conclusiones
Llegado a este punto es bastante evidente las numerosas debilidades del OPC clásico, tanto a nivel de ciberseguridad como a nivel de complejidad de configuración. Esta es la razón por la que la organización que gestiona el protocolo, OPC Foundation, ha redefinido el nuevo estándar OPC UA, corrigiendo e implementado nuevos mecanismos de seguridad obligatorios, que eran impensables hace casi 30 años cuando se definió el primer estándar de OPC clásico.
El consejo es sencillo, mientras más expuesta esté una comunicación OPC más aconsejable la migración al nuevo OPC UA.