Estandarización y seguridad en el protocolo OPC UA

Introducción del protocolo OPC

El protocolo OPC (Object Linking and Embedding for Process Control) nació de la necesidad de una interfaz común para la comunicación de procesos industriales. Basado inicialmente en la tecnología COM/DCOM de Microsoft, esta tecnología permite de una manera abstracta la comunicación de diferentes elementos de la red de procesos.

-Estado inicial sin OPC-

OPC utiliza un planteamiento cliente-servidor para la comunicación. El servidor OPC es el encargado de la encapsulación de la información y de la disponibilidad de esta a través de su interfaz, mientras que el cliente OPC se conecta al servidor OPC y accede a la información disponible. En el OPC clásico las interfaces están basadas en la tecnología COM y DCOM de Microsoft, mientras que en OPC UA en la última versión del estándar, se utilizan dos protocolos, un protocolo TCP binario de alto rendimiento (OPC-TCP) y un segundo basado en web services (HTTP).

-Estado inicial con OPC-

Evolución del protocolo OPC

La primera versión del protocolo OPC, conocida como OPC clásico, se adaptó a las necesidades del momento y planteaba tres especificaciones distintas:

• OPC DA (Data Access): utilizado para el acceso a datos actuales de los procesos.
• OPC A&E (Alarm and Events): utilizado para información de eventos y alarmas.
• OPC HDA (Historical Data Access): acceso a datos históricos ya almacenados.

La interfaz OPC DA es actualmente la más importante de OPC y la utilizada en la mayoría de los dispositivos que implementan el protocolo. Las interfaces OPC A&E y OPC HDA son menos relevantes y se utilizan a modo de complemento de OPC DA.

Después del lanzamiento de la primera versión de OPC, nace OPC XML DA, que es el primer intento de OPC de crear una especificación OPC independiente de la plataforma, reemplazando la tecnología propietaria de Microsoft COM/DCOM por HTTP/SOA y tecnologías web, manteniendo la funcionalidad de OPC-DA. El problema de OPC XML DA fue su bajo rendimiento y consumo elevado de recursos.

Es por estos problemas por lo que nace OPC UA, es decir, por la necesidad real de una herramienta independiente de la plataforma (del sistema operativo subyacente), pero manteniendo el rendimiento y las características del OPC clásico.

La aparición de OPC UA supone un cambio total de paradigma en las infraestructuras OPC. Windows deja de ser un requisito obligatorio al pasar el protocolo a ser independiente de la plataforma. Es tanto el cambio que supone OPC UA, que hasta cambia el significado de las siglas OPC, de OLE for Procces Control a Open Platform Communication.

El objetivo principal de OPC UA es unificar toda la arquitectura OPC clásica en una infraestructura independiente de la plataforma, manteniendo toda la funcionalidad, evitando así la dependencia de los sistemas de Microsoft y de su tecnología COM/DCOM. Para ello, define los mecanismos de transporte y modelo de datos.

En cuanto al transporte define dos mecanismos, como ya se han mencionado anteriormente. Por un lado, un protocolo TCP binario de alto rendimiento para comunicaciones intranet y acceso a los estándares de Internet aceptados como HTTP.

En cuanto al modelo de datos define las reglas y bloques necesarios para el acceso al espacio de direcciones.

Los servicios en OPC UA se definen de manera 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 datos subyacente.

-Flujo de comunicación de una aplicación OPC UA-

Medidas de seguridad OPC clásico vs OPC UA

En el estándar OPC se implementan varias medidas de seguridad a la hora de garantizar los principios de confidencialidad, integridad y disponibilidad. Para ello, plantea los siguientes objetivos:

Autenticación de la aplicación

Mediante el mecanismo de autenticación, se permite a las aplicaciones que corren bajo OPC UA identificarse las unas a las otras. Para ello, poseerán 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 restricciones, por lo que normalmente no se encuentra configurado. Además, configurar la autenticación de las aplicaciones requiere mucho trabajo, ya que requiere configurar todos los elementos DCOM.

Por lo tanto, OPC UA aporta mayor facilidad a la hora de implementar mecanismos de 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, y son soportados varios mecanismos de autenticación, en comparación con la versión clásica en la cual la autenticación no se encuentra habilitada por defecto pudiendo llegar a ser costosa su habilitación.

Para la autenticación del usuario en OPC UA se pueden utilizar varios mecanismos; uno de ellos es mediante la combinación de usuario y contraseña, otro sería mediante el uso de certificado digital, por último, también permite la autenticación mediante ticket Kerberos. Todas las aplicaciones que utilicen OPC UA deben soportar la combinación usuario y contraseña, que es la más sencilla de implementar, pero puede ser la más difícil de configurar, ya que ha de hacerse en cada aplicación. La selección de la manera de identificar al usuario es específica de la aplicación. La identificación de usuario de OPC UA funciona de manera similar entre máquinas (p. ej. cliente OPC, servidor OPC) dentro de un mismo grupo de trabajo, de un mismo dominio, entre dominios distintos, o incluso cuando la plataforma (sistema operativo) de estas es distinta.

En cuanto a OPC clásico el acceso no se encuentra restringido por defecto. En un entorno de dominio, el dominio debería identificar todos los servidores OPC clásico y asignar los derechos de acceso adecuados a los grupos de usuarios (roles) de los clientes que se conectarán. Dado que todas las cuentas de un dominio se administran desde un controlador central, es sencillo habilitar la autenticación de los usuarios, pero al no estar habilitada por defecto ha de ser configurada manualmente en el controlador central del dominio. En un entorno que no sea de dominio, se puede configurar, pero requiere trabajo adicional para identificar a los usuarios (cuentas comunes en todas las máquinas, grupo de usuarios común (roles), etc.).

Autorización del usuario

En OPC UA, una vez que el usuario es identificado y autenticado, es la aplicación la encargada de restringir los derechos de acceso para un usuario determinado con respecto a la navegación de lectura / escritura, etc.

Lo mismo ocurre en OPC clásico, donde las aplicaciones del mismo, pueden proporcionar restricciones de acceso individual para un elemento determinado frente al acceso DCOM general de lectura o escritura, pero pocas o ninguna aplicación incluyen este tipo de restricción.

Disponibilidad del servidor

Otro punto importante que contempla OPC UA es la disponibilidad de los servidores de la aplicación. No es algo que dependa del protocolo, sino que se recomienda que los servidores OPC implementen mecanismos para la disponibilidad de su sistema, como puede ser la disponibilidad de servidores de respaldo o el soporte para configuración de redundancia.

Auditabilidad del sistema

En OPC UA también se contempla la capacidad del sistema para ser auditado. Para ello, OPC UA define los mecanismos necesarios para que un servidor pueda almacenar en los ficheros de log todos los eventos relevantes.

Confidencialidad e integridad

La confidencialidad e integridad de los datos se contempla en la capa de transporte de OPC UA mediante el cifrado de las comunicaciones. Si se utilizan los servicios web para la comunicación, se usa el protocolo WS Secure Conversation. En caso de la versión TCP binaria se utiliza una adaptación de WS Secure Conversation. Por último, existe una versión mixta en la cual se utiliza TLS.

En cuanto al cifrado de los datos en OPC clásico, DCOM puede configurarse para proporcionar tanto el firmado de los datos como el cifrado. El problema de DCOM es que no tiene el cifrado habilitado por defecto y por lo tanto, debe ser configurado.

Tanto en el estándar OPC clásico como en OPC UA es posible el cifrado de las comunicaciones, la principal diferencia reside en que en OPC UA el cifrado se encuentra habilitado por defecto, mientras que en el estándar clásico ha de ser implementado manualmente.

Conclusiones

Algunos incidentes de seguridad como CrashOverride ponen de manifiesto las debilidades que posee el estándar OPC clásico y es por ello que la OPC Foundation define en su último estándar, OPC UA, nuevos mecanismos de seguridad que son obligatorios y que aportan un nivel superior respecto a la versión OPC clásico.