1.- SOLUCIÓN: REDES VPN

Para empezar, a nivel de comunicación de datos, usar una DMZ y cerrar todos los puertos de firewall entrantes es mucho más seguro que usar una VPN.

Una VPN en realidad no proporciona el nivel de seguridad que necesita un sistema industrial, simplemente extienden efectivamente el perímetro de seguridad más allá de la red de la planta para incluir la red de IT.

Una brecha de seguridad en la VPN expondría todos los sistemas de ambas redes a un ataque como un barco que se hunde si le entra una vía de agua

2.- SOLUCIÓN:  Datos OPC a través de MQTT

El push de datos OPC a la nube es otra posibilidad de comunicaciones.

Probablemente, el enfoque más común para realizar conexiones salientes mientras se mantienen cerrados los puertos del firewall de la planta es mediante el uso de MQTT.
Los dispositivos IoT/IIoT o software se conectan a un servidor llamado “broker” y publican sus datos en él y/o reciben datos de él.

El “BROKER MQTT” no examina lso datos que recibe, sino que simplemente la pasa como un mensaje de cada publicador a todos los suscriptores.

En el ámbito de la seguridad, esta arquitectura “push” evita el problema de la arquitectura cliente-servidor de OPC, lo que permite que los dispositivos realicen conexiones salientes sin abrir ningún puerto de firewall. Y además mediante el uso de un broker central, es posible establecer conexiones de muchos a muchos, lo que permite que varios publicadores se conecten a varios suscriptores.

MQTT resuelve así algunos problemas de comunicación y seguridad de IIoT. A pesar de estas ventajas arquitectónicas, MQTT tiene inconvenientes que deben abordarse si se quiere que sea realmente útil para escenarios de comunicación de OT/IT e IoT industrial.

5 razones a valorar el por qué MQTT puede NO ser la mejor solución:

— MQTT es un protocolo de transporte pero no especifica un formato de mensaje especifico, lo que plantea problemas de interoperabilidad entre diferentes aplicaciones de diferentes fabricantes ya que cada uno creará el mensaje MQTT con un formato diferente. Sparkplug B se creó para abordar este problema y está comenzando a ganar terreno entre los proveedores y usuarios.

.

 

— Broker MQTT no conserva el orden del tiempo entre los valores de datos sobre diferentes topics MQTT. Esto significa que puede no mantener el orden según el tiempo en el que se ejecute el envío (puede que un evento que ocurren en el orden A, luego B y luego C podrían recibirse en  la aplicación como C, luego B y luego A) y por lo tanto ocasionar problemas en sistemas físicos donde el orden y el tiempo de llegada de mensaje es crítico en muchos casos de uso de control industrial.

— Broker MQTT no tienen forma de indicar que una fuente de datos está desconectada.
La aplicación que recibe el dato  no puede diferenciar entre un valor antiguo de un sensor que ha fallado o un valor actual que simplemente no ha cambiado.

— QoS y MQTT: Los niveles de calidad de servicio (QoS) de MQTT no son adecuados para su uso en una DMZ, ya que solo se aplican a conexiones individuales.
Dado que la conexión a través de una DMZ requiere varios saltos, el emisor de datos nunca sabrá si un mensaje MQTT ha llegado a un usuario, independientemente del QoS que se seleccione.

— Broker MQTT no manejan bien las situaciones de sobrecarga. Si los datos llegan más rápido de lo que un subscriptor puede procesar, es probable que se pierda la consistencia de los datos y el orden o timing de tiempo entre el  “publicador y el subscriptor” de datos.

 

En resumen, MQTT mantiene cerrados los puertos de firewall entrantes, lo que lo hace útil para algunas aplicaciones de IoT industrial, en particular, la recopilación de datos de dispositivos de campo IoT o embebidos. Pero su incapacidad para garantizar la consistencia de los datos entre el “publicador y el subscriptor”, particularmente a través de una DMZ, no lo convierte en un candidato ideal para las conexiones OT/IT.

Un túnel de datos bien implementado, garantiza una comunicación óptima de datos históricos y en tiempo real y facilita la implementación y ayuda a cumplir los requisitos más exigente respecto a la comunicación de datos a través de una DMZ según las normativas de ciberseguridad actuales como por ejemplo la utilización de una DMZ (práctica recomendada por organismos como INCIBE por ejemplo).

Mediante el túnel de datos, Los servidores OPC y otras fuentes de datos en el lado de OT hacen conexiones locales a un componente de middleware (software Cogent DataHub), mientras que los “clientes receptores” en el lado de IT hacen lo mismo sin necesidad de redirigir puertos ni abrir puertos de entrada a la red, incluso pudiendo trabajar a través de proxies. Una vez configurado el túnel, los datos fluyen bidireccionalmente entre ambos extremos de una forma transparente, segura y optimizada.

En muchos casos de uso, esta característica proporciona lo mejor de ambos mundos: Acceso remoto a los datos de producción, además de seguridad, En definitiva, el Tuneller es la mejor solución sin necesidad de abrir puertos en la zonas vulnerables y trabajar mediante DMZ sin exponer los datos directamente a servicios CLOUD y en tiempo real.