Seguridad OT con MQTT: cómo proteger las plantas industriales al enviar datos a la nube

La seguridad OT con MQTT es la práctica de sacar datos de una planta industrial sin crear una nueva vía de entrada a ella. Esta guía cubre los patrones de red que funcionan, como las conexiones solo salientes, los gateways en DMZ y la segmentación, además de la higiene de credenciales y la supervisión de los datos de planta enviados a un broker en la nube. Al final tendrás un diseño de referencia y una lista de comprobación que podrás debatir con tus equipos de OT e IT.

Por qué las redes OT necesitan un enfoque distinto

Las redes de tecnología operativa (OT) controlan equipos que mueven, calientan, mezclan y cortan. Se diferencian de la IT de oficina en aspectos que condicionan cada decisión de seguridad:

• La disponibilidad es lo primero. Un control de seguridad que detiene la producción suele considerarse un riesgo mayor que la amenaza que aborda.
• Ciclos de vida largos. Los PLC y HMI permanecen en servicio durante muchos años, a menudo con firmware que no puede actualizarse rápidamente.
• Protocolos heredados. Modbus, las versiones antiguas de Profinet y muchos protocolos serie no tienen ninguna autenticación.
• Consecuencias físicas. Un comando falsificado puede dañar equipos o herir a personas, no solo filtrar datos.

MQTT se adapta bien a este entorno porque invierte la dirección habitual del tráfico. En lugar de que una aplicación en la nube entre en la planta para sondear las máquinas, un gateway dentro de la planta envía los datos hacia fuera. Bien hecho, eso significa que no hay ninguna regla de firewall entrante hacia la red OT.

El principio fundamental: conexiones solo salientes

Todo cliente MQTT abre una conexión TCP hacia el broker, nunca al revés. Por tanto, un gateway de planta que publica en un broker en la nube necesita exactamente una regla de firewall: TCP saliente hacia el nombre de host del broker en el puerto 8883.

Solo saliente no significa sin riesgo. El gateway sigue teniendo una sesión TCP con el mundo exterior, y si se suscribe a topics de comandos, los datos pueden fluir de vuelta hacia dentro. La pregunta de diseño pasa a ser: ¿qué acepta el gateway y cómo lo valida?

Arquitectura de referencia

Un diseño por capas que encaja en la mayoría de las plantas, desde una operación minera en Chile hasta una planta de manufactura en Querétaro, siguiendo a grandes rasgos los niveles del modelo Purdue:

1. Nivel 0–1: dispositivos de campo y PLC. Sin ruta a internet. Solo hablan protocolos industriales.
2. Nivel 2: red de supervisión. HMI y SCADA. Tampoco tienen ruta a internet.
3. Nivel 3/3.5: DMZ industrial. Aquí vive el gateway edge. Lee del nivel 2 (por ejemplo, mediante OPC UA o Modbus TCP) a través de un firewall que solo permite esos flujos concretos.
4. Nivel 4–5: empresa y nube. El gateway publica en el broker MQTT en la nube sobre TLS. Los dashboards, la analítica y los historiadores se suscriben desde aquí.

¿Un único gateway o un broker en la DMZ?

Hay dos variantes habituales que funcionan bien:

• El gateway publica directamente en el broker en la nube. La opción más sencilla: una conexión saliente, con almacenamiento y reenvío en el gateway durante las caídas.
• Un broker local en la DMZ hace de puente con la nube. Las máquinas o gateways publican en un broker de la DMZ, y un único cliente puente o de retransmisión reenvía hacia fuera los topics seleccionados. Esto añade un búfer local y un punto único para inspeccionar y filtrar el tráfico, a cambio de un sistema más que actualizar y supervisar.

En ambos casos, la planta nunca habla directamente con internet. Para entender cómo enruta los datos un broker, consulta qué hace un broker MQTT.

Reglas de segmentación que importan

Escribe las reglas de firewall de modo que cada una tenga un motivo que puedas explicar:

# Firewall OT (entre el nivel 2 y la DMZ)
ALLOW  gateway-01  -> plc-line1:4840/tcp   (lectura OPC UA)
ALLOW  gateway-01  -> plc-line2:502/tcp    (lectura Modbus TCP)
DENY   any         -> any                   (por defecto)

# Firewall perimetral (de la DMZ a internet)
ALLOW  gateway-01  -> YOUR_BROKER_HOST:8883/tcp   (MQTT sobre TLS)
ALLOW  gateway-01  -> ntp-server:123/udp          (sincronización horaria para TLS)
DENY   any         -> any                          (por defecto)
DENY   internet    -> DMZ                          (nada entrante)

Ten en cuenta estos puntos:

• Prefiere nombres de host con filtrado de salida en un proxy o firewall de nueva generación cuando las direcciones IP del broker puedan cambiar.
• Permite solo el puerto 8883. MQTT sin cifrar en el 1883 nunca debe salir de la planta.
• La hora exacta importa: la validación del certificado TLS falla en gateways con el reloj desajustado.
• Registra las conexiones denegadas desde el lado OT; los intentos de salida inesperados son una señal de alerta temprana.

Higiene de credenciales para gateways

Los gateways de planta suelen funcionar sin supervisión durante años, así que las credenciales deben gestionarse con cuidado desde el primer día.

1. Una identidad por gateway. Si un gateway se ve comprometido, revócalo sin tocar los demás.
2. Identidades separadas para funciones separadas. Un publicador de telemetría y un receptor de comandos no deben compartir credenciales.
3. Guarda los secretos fuera del código fuente, en un archivo de configuración protegido o en el almacén de secretos del sistema operativo, legible solo por la cuenta de servicio del gateway.
4. Rota de forma programada y ante eventos, como cambios de personal o sospechas de compromiso. La guía para rotar credenciales MQTT muestra un enfoque con mínima interrupción.
5. Nunca reutilices las credenciales de la planta en brokers de prueba. Usa el servidor MQTT público gratuito solo para pruebas, con client IDs desechables y datos ficticios, nunca con datos de producción.

En ConnectMQ, cada broker recibe credenciales generadas y los client IDs están vinculados a esas credenciales, así que un client ID filtrado no puede usarse por sí solo para conectarse. Los inicios de sesión fallidos repetidos provocan el bloqueo de la IP, lo que limita los intentos de adivinar contraseñas contra las cuentas de tus gateways.

Gestionar los comandos con seguridad

Si el caso de negocio requiere consignas remotas o cambios de receta, trata la vía de comandos como un conducto separado y de mayor riesgo:

• Usa topics de comandos dedicados y una identidad de suscriptor separada.
• Valida cada comando en el gateway frente a una lista de permitidos: qué tag, qué rango, qué unidades.
• Exige un topic de respuesta o confirmación, para que los operadores vean lo que realmente ha ocurrido. Los response topics de MQTT 5 ayudan aquí.
• Mantén una anulación local y asegúrate de que los equipos pasen a un estado seguro si el broker no está disponible.
• Nunca reenvíes payloads en bruto a un PLC.

Muchas plantas deciden que la vía hacia la nube sea de solo lectura y que las escrituras se hagan únicamente desde los HMI locales. Es una elección legítima y habitual.

Supervisión y disponibilidad

En OT, la seguridad incluye la disponibilidad. Planifica estas situaciones:

• Caída del broker o de internet: el gateway almacena los datos localmente y los reenvía con backoff cuando vuelve la conexión. La caducidad de mensajes evita que se reproduzcan datos obsoletos horas después.
• Fallo del gateway: suscríbete a $SYS/broker/connection/{clientId}/state en ConnectMQ o usa un mensaje de last will para que los dashboards muestren el gateway como desconectado.
• Tráfico inusual: un gateway que de repente publica diez veces más de lo normal, o que se conecta desde una IP nueva, merece una investigación.
• Límites de cuota: el código de motivo 0x97 de MQTT 5 te indica que se ha superado una cuota del plan, para que puedas distinguirlo de los problemas de red.

El dashboard del portal de ConnectMQ, la vista de dispositivos por nivel ISA-95 y las reglas de alerta por umbral ayudan a los equipos de operaciones a ver todo esto sin construir herramientas propias.

Lista de comprobación de seguridad OT para MQTT

1. Ninguna regla de firewall entrante hacia la red OT para MQTT.
2. El gateway está en una DMZ y lee de los PLC mediante reglas de alcance muy limitado.
3. Solo sale de la planta TLS en el puerto 8883, con validación del certificado del servidor y hora exacta.
4. Una identidad única y revocable por gateway y por función.
5. Las vías de comandos están separadas, validadas y con estado seguro ante fallos, o directamente no existen.
6. Los gateways almacenan datos en búfer durante las caídas y se reconectan con backoff.
7. Se supervisan el estado de conexión y las tasas de mensajes de los gateways.
8. Las responsabilidades entre planta, IT y proveedor del broker están documentadas.

Para la parte normativa del mismo tema, lee IEC 62443 y MQTT. La guía de IoT industrial con MQTT cubre el modelado de datos, y las buenas prácticas de seguridad MQTT cubren el bastionado general de clientes.

Conecta tu planta a ConnectMQ de forma segura

Puedes probar este diseño con un único gateway en una tarde. Crea un broker privado en el plan Serverless gratuito en app.connectmq.com (sin tarjeta de crédito), abre una regla saliente para el puerto 8883 y publica tu primer topic ISA-95 sobre TLS. Cuando necesites aislamiento para producción, un broker MQTT gestionado en un despliegue Dedicated o BYOC mantiene la misma configuración de cliente.

Preguntas frecuentes

¿Requiere MQTT abrir puertos entrantes hacia la planta?

No. Los clientes MQTT se conectan hacia fuera, al broker, así que un gateway de planta solo necesita una regla saliente al puerto 8883. Los comandos, si los hay, vuelven por esa misma conexión.

¿Deben los PLC conectarse directamente a un broker en la nube?

Por lo general, no. Mantener los PLC en una red aislada y colocar un gateway edge en una DMZ limita la exposición y te permite controlar exactamente qué sale de la planta.

¿Hace falta una VPN para MQTT desde la planta a la nube?

Normalmente no. MQTT sobre TLS con validación del certificado del servidor y credenciales de cliente sólidas proporciona un canal cifrado y autenticado sin VPN.

¿Qué pasa con los datos cuando se cae la conexión a internet?

Un gateway bien diseñado almacena los datos localmente y los reenvía tras reconectarse con backoff. La caducidad de mensajes puede descartar los valores que ya no son útiles.