Una DMZ MQTT es la zona de red por la que los datos de planta salen de la red de tecnología operativa (OT) camino de los sistemas cloud y corporativos, sin permitir que nada del exterior vuelva a entrar. En esta guía aprenderás por qué MQTT encaja tan bien en una DMZ, los tres patrones de ubicación que funcionan en la práctica, las reglas de firewall exactas que debes solicitar y una configuración de bridge funcional que reenvía datos OT a un broker en la nube sobre TLS.
Por qué MQTT encaja en una DMZ industrial
La mayoría de las arquitecturas de seguridad industrial siguen alguna variante del modelo Purdue o de las zonas y conductos de IEC 62443. Los niveles 0 a 2 contienen sensores, PLC y HMI, el nivel 3 contiene las operaciones de planta como SCADA e historiadores, y entre el nivel 3 y la red corporativa (nivel 4 y superiores) se sitúa una DMZ industrial, a menudo llamada nivel 3.5. La regla de la DMZ es sencilla: ningún tráfico la atraviesa directamente. Cada flujo termina en la DMZ y desde allí se inicia un flujo nuevo.
Los protocolos de integración clásicos tienen problemas con esa regla. Los protocolos de sondeo como OPC DA, Modbus TCP o una interfaz de consultas de un historiador esperan que el consumidor abra una conexión hacia el productor. Eso implica una conexión entrante hacia la red OT, justo lo que el equipo de seguridad quiere evitar.
MQTT invierte la dirección. Cada participante es un cliente que se conecta hacia fuera a un broker. Un gateway en el lado OT abre una conexión TCP saliente, se autentica y publica. Los consumidores de TI o de la nube también se conectan hacia fuera al broker y se suscriben. Nadie necesita abrir nunca un puerto de escucha en la planta. Una vez que entiendes qué hace un broker MQTT como punto de encuentro de estas conexiones salientes, es mucho más fácil razonar sobre el diseño de la DMZ.
Tres patrones de ubicación para una DMZ MQTT
No existe un único diseño correcto. El patrón adecuado depende de lo estricta que sea tu política de zonas y de cuántas plantas tengas.
| Patrón | Dónde está el broker | Flujo desde OT | Ideal para |
|---|---|---|---|
| A. Saliente directo | Solo en la nube | El gateway OT se conecta hacia fuera a través del firewall al broker en la nube | Plantas pequeñas, pilotos, plantas sin una DMZ formal |
| B. Broker puente en la DMZ | Broker local en la DMZ, con bridge a la nube | El gateway OT se conecta al broker de la DMZ; el broker de la DMZ se conecta hacia fuera a la nube | Plantas con una regla estricta de "ningún flujo atraviesa la DMZ" |
| C. Gateway en la DMZ | Software de gateway en la DMZ, broker en la nube | Un gateway en la DMZ lee el gateway OT o el servidor OPC UA y publica en la nube | Plantas en las que no se puede instalar nada en los niveles 2 o 3 |
Patrón A: solo saliente hacia un broker en la nube
El gateway se sitúa en el nivel 3 y abre una conexión TLS en el puerto 8883 directamente con un broker MQTT en la nube. El firewall permite un único destino saliente y un único puerto. El tráfico de retorno solo circula por esa sesión establecida. Este patrón se despliega rápido y es perfectamente aceptable para muchas plantas, pero técnicamente deja que una sesión atraviese la DMZ, algo que algunas políticas prohíben.
Patrón B: un broker puente en la DMZ
Un broker pequeño como Mosquitto se ejecuta en un host bastionado de la DMZ. Los gateways OT se conectan a él desde abajo, y el broker de la DMZ abre su propia conexión de bridge saliente hacia la nube. Dos sesiones separadas, dos juegos de credenciales separados, y el host de la DMZ es la única máquina que habla con internet. Si cae el enlace con la nube, el bridge encola localmente los mensajes QoS 1, lo que se combina de forma natural con store and forward MQTT en los gateways.
Patrón C: un gateway de protocolos en la DMZ
A veces no se puede instalar nada nuevo dentro de la zona OT. En ese caso, un gateway en la DMZ lee una interfaz existente, por ejemplo un servidor OPC UA expuesto a la DMZ mediante una regla muy acotada, y publica MQTT hacia arriba. Es el patrón menos elegante, porque ahora la DMZ inicia una conexión hacia OT, pero sigue manteniendo la nube completamente aislada de la planta. Nuestra guía del gateway edge IIoT explica cómo elegir ese gateway.
Reglas de firewall para una DMZ MQTT
Elijas el patrón que elijas, deja por escrito las reglas antes de la solicitud de cambio. Los equipos de firewall aprueban antes las reglas precisas que las vagas.
| Regla | Origen | Destino | Puerto | Dirección |
|---|---|---|---|---|
| 1 | Gateway OT (nivel 3) | Broker de la DMZ | TCP 8883 (o 1883 dentro de un segmento de confianza) | OT a DMZ |
| 2 | Broker de la DMZ | Hostname del broker en la nube | TCP 8883 | DMZ a internet |
| 3 | Consumidores de TI | Hostname del broker en la nube | TCP 8883 u 8084 (WSS) | Red corporativa a internet |
| 4 | Cualquiera | Zona OT | Cualquiera | Denegar |
| 5 | Internet | Broker de la DMZ | Cualquiera | Denegar |
Algunas notas prácticas:
- Usa el hostname del broker, no una dirección IP, en la regla saliente, o un objeto FQDN si tu firewall lo admite. Las IP en la nube pueden cambiar.
- Permite la resolución DNS al host de la DMZ, ya sea hacia un resolvedor interno o hacia un servidor externo concreto.
- Mantén el puerto 1883 en texto plano completamente fuera de internet. Usa el 8883 con TLS para todo lo que salga de la planta.
- Si en el camino hay un proxy con inspección TLS, excluye el hostname del broker. La inspección rompe la validación de certificados y las sesiones MQTT de larga duración.
- Los timeouts de inactividad largos importan. Algunos firewalls cortan las sesiones TCP inactivas al cabo de pocos minutos, así que fija el keepalive de MQTT por debajo del timeout de inactividad del firewall, por ejemplo en 60 segundos.
Ejemplo: un bridge de Mosquitto desde la DMZ a un broker en la nube
La siguiente configuración implementa el patrón B. El broker de la DMZ solo escucha en su interfaz orientada a OT y hace bridge de los topics seleccionados hacia un broker de ConnectMQ sobre TLS. Sustituye las credenciales por el nombre de usuario, la contraseña y el client ID generados en el portal.
# /etc/mosquitto/conf.d/dmz.conf
# Escucha solo en la interfaz orientada a la zona OT
listener 8883 10.20.0.5
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/dmz-broker.crt
keyfile /etc/mosquitto/certs/dmz-broker.key
allow_anonymous false
password_file /etc/mosquitto/passwd
# Bridge saliente hacia el broker en la nube
connection connectmq-cloud
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
bridge_capath /etc/ssl/certs
bridge_insecure false
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
try_private false
keepalive_interval 60
restart_timeout 10 120
# Reenvía solo la telemetría de planta, solo hacia arriba
topic factory1/# out 1 "" connectmq/
La línea topic es donde se aplica por software la política de la DMZ: out significa que los mensajes solo fluyen del broker de la DMZ a la nube, nunca de vuelta hacia abajo. Un topic local factory1/line1/cnc1/telemetry llega a la nube como connectmq/factory1/line1/cnc1/telemetry. Usa try_private false porque el lado remoto no es otra instancia de Mosquitto, y mantén bridge_insecure false para que el certificado de Let's Encrypt del endpoint en la nube se valide contra el almacén de CA del sistema.
Prueba la ruta desde el host de la DMZ antes de meter ningún dato de PLC:
# En el host de la DMZ: publica un mensaje de prueba local
mosquitto_pub -h 10.20.0.5 -p 8883 --cafile /etc/mosquitto/certs/ca.crt \
-u gateway01 -P 'local-secret' -i dmz-test-01 \
-t factory1/test/hello -m '{"status":"ok"}' -q 1
# Desde cualquier máquina con acceso al broker en la nube: confirma que ha llegado
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-reader \
-t 'connectmq/factory1/#' -v
Ten en cuenta que ConnectMQ vincula los client IDs a las credenciales emitidas, así que el segundo cliente necesita su propio juego de credenciales del portal en lugar de un ID inventado. Para hacer pruebas antes de tener credenciales, puedes apuntar el bridge al servidor MQTT público gratuito en el puerto 1883 con un prefijo único como connectmq/demo/<random-id>/, pero nunca envíes datos reales de planta a un área pública.
¿Deben fluir comandos hacia abajo?
Que la telemetría suba es la parte fácil. La pregunta más difícil es si algo debe volver hacia abajo: cambios de consigna, descargas de recetas, confirmaciones. Para un primer despliegue, un buen valor por defecto es que no. Mantén el bridge solo en out y deja que los operadores cambien las consignas a través del HMI o el SCADA existentes.
Si necesitas un enlace descendente, diséñalo de forma explícita:
- Haz bridge
inde un único topic de comandos muy acotado, por ejemploconnectmq/factory1/line1/cmd/+, nunca de un comodín sobre todo el árbol. - Deja que un gateway en el nivel 3 valide cada comando contra una lista de permitidos de tags y rangos de valores antes de escribir en el PLC.
- Exige un response topic y correlation data (una función de MQTT 5) para que cada comando genere una confirmación registrada.
- Deja que el PLC siga a cargo de los enclavamientos de seguridad. Un comando desde la nube debe solicitar un cambio, no saltarse la lógica.
Errores habituales en una DMZ MQTT
Ejecutar el broker de la DMZ con acceso anónimo. La DMZ sigue siendo una zona compartida. Exige nombres de usuario y contraseñas, e idealmente certificados de cliente, en el listener orientado a OT.
Hacer bridge de # en ambas direcciones. Es la forma más rápida de convertir una DMZ cuidadosamente diseñada en una red plana a nivel de aplicación. Haz bridge solo de los subárboles que necesites y solo en la dirección que necesites.
Olvidarse de la sesión. Con cleansession false, el lado de la nube conserva las suscripciones del bridge y los mensajes QoS 1 encolados durante cortes breves. Con una sesión limpia, todo lo publicado durante una ventana de reconexión puede perderse.
Ignorar los límites del broker. Una ráfaga de datos históricos tras una caída puede superar las cuotas por cliente. Limita el ritmo del reenvío en el gateway y lee los reason codes que devuelve el broker.
Dónde encaja un broker MQTT gestionado
Tanto en el patrón A como en el B, el endpoint en la nube es un componente que, de otro modo, tendrías que construir, exponer, parchear y monitorizar tú mismo. Usar un broker MQTT gestionado saca esa superficie expuesta a internet de tu centro de datos. ConnectMQ ofrece TLS en el 8883, aislamiento multiinquilino, protección contra inundaciones y bloqueo de IP tras repetidos intentos de inicio de sesión fallidos, así que lo único que necesita tu DMZ es una regla saliente. Para las organizaciones que quieren el broker dentro de su propia cuenta cloud, también ofrece una opción BYOC gestionada en su nombre.
Para ver en conjunto cómo encaja la DMZ con los gateways, Sparkplug B y un Unified Namespace, consulta nuestra guía completa de IoT industrial con MQTT. Si tus plantas se conectan por redes móviles en lugar de a través de un firewall de planta, lee también sobre MQTT sobre red celular.
Empieza con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. En minutos obtienes un nombre de usuario, una contraseña y un client ID generados, que es todo lo que necesitas para apuntar un bridge de DMZ a la nube y ver cómo llegan los topics de tu planta al explorador de topics en vivo. Cuando se te quede pequeño el nivel gratuito, los planes Serverless de pago, Dedicated y BYOC te permiten escalar sin rediseñar la DMZ.
Preguntas frecuentes
¿Requiere MQTT puertos entrantes en el firewall hacia la red OT?
No. Cada participante MQTT es un cliente que se conecta hacia fuera a un broker, así que la red OT solo necesita una regla saliente hacia el broker de la DMZ o el broker en la nube. Nada en internet inicia una conexión hacia la planta.
¿Debo usar el puerto 1883 o el 8883 en una DMZ MQTT?
Usa el 8883 con TLS en cada conexión que salga de la planta o atraviese un límite de zona. El 1883 en texto plano solo es aceptable dentro de un único segmento de confianza, e incluso ahí se recomienda TLS.
¿Necesito un broker dentro de la DMZ?
No siempre. Una conexión saliente directa desde un gateway de nivel 3 a un broker en la nube suele ser aceptable. Un broker puente en la DMZ es la mejor opción cuando tu política prohíbe que cualquier sesión atraviese la DMZ o cuando quieres un búfer local.
¿Pueden las aplicaciones en la nube enviar comandos a los PLC a través de la DMZ?
Pueden, pero solo a través de un topic de comandos acotado, con bridge explícito, y de un gateway que valide cada comando antes de escribir en el PLC. Muchas plantas empiezan con telemetría solo ascendente y añaden el enlace descendente más adelante.
