Diseñar MQTT según IEC 62443 consiste en situar un flujo de datos MQTT dentro del modelo de zonas y conductos que ya usan los equipos de seguridad industrial. Esta guía traslada los principales conceptos de IEC 62443 a una arquitectura típica de PLC, gateways edge y un broker en la nube, para que puedas explicar tu diseño en el lenguaje que esperan tus revisores de seguridad OT. Es una guía de ingeniería, no un asesoramiento legal ni de certificación: el cumplimiento se evalúa para tu sistema y tu organización, no lo otorga un único producto.
Una breve introducción a IEC 62443
IEC 62443 es una serie de normas para la seguridad de los sistemas de automatización y control industrial (IACS). Está escrita para varios públicos: los propietarios de activos que operan las plantas, los integradores de sistemas que construyen soluciones y los proveedores de productos que fabrican componentes. Para el diseño de la mensajería, los conceptos más importantes son:
- Zonas: grupos de activos con requisitos de seguridad comunes, como una célula de PLC o una red IT corporativa.
- Conductos: las vías de comunicación entre zonas, con sus propios requisitos de seguridad.
- Requisitos fundamentales (FR): siete categorías que estructuran los requisitos técnicos: control de identificación y autenticación, control de uso, integridad del sistema, confidencialidad de los datos, flujo de datos restringido, respuesta oportuna a eventos y disponibilidad de recursos.
- Niveles de seguridad (SL): objetivos de SL 1 a SL 4 que describen a qué capacidad de atacante debe resistir la zona o el conducto, desde un uso indebido casual hasta ataques sofisticados y con muchos recursos.
- Evaluación de riesgos: el proceso (descrito en la parte 3-2) que decide las zonas, los conductos y los niveles de seguridad objetivo.
Varias partes son relevantes para los proyectos MQTT. La parte 3-3 enumera los requisitos de seguridad del sistema, la parte 4-2 cubre los requisitos de los componentes y la parte 2-1 trata el programa de seguridad del propietario de los activos.
Por qué MQTT encaja en el modelo de zonas y conductos
MQTT tiene una propiedad que gusta a los arquitectos de seguridad: los clientes siempre se conectan hacia fuera, hacia el broker. Un gateway de PLC publica en un broker; nada necesita conectarse hacia dentro de la planta. Eso hace que la vía de comunicación sea fácil de describir como un único conducto con una dirección, un protocolo y un puerto definidos.
Compáralo con los protocolos de sondeo, en los que un sistema central entra en la red de la planta para leer valores. Cada sondeo es un flujo entrante que hay que permitir a través de los firewalls. Con MQTT, la planta inicia la conexión y el firewall puede permanecer cerrado al tráfico entrante.
Cómo trasladar una arquitectura MQTT a zonas y conductos
Una arquitectura MQTT industrial típica tiene cuatro zonas:
| Zona | Activos | SL objetivo de ejemplo | Notas |
|---|---|---|---|
| Zona de control | PLC, variadores, HMI en la red de la célula | Lo fija la evaluación de riesgos, a menudo el más alto | Habla OPC UA, Modbus o Profinet; sin acceso directo a internet |
| Zona edge | Gateway edge, convertidores de protocolo | Lo fija la evaluación de riesgos | Lee de la zona de control y publica MQTT hacia fuera |
| DMZ de planta | Broker local opcional, hosts de salto, proxies | Lo fija la evaluación de riesgos | Almacena en búfer e inspecciona el tráfico entre la planta y el exterior |
| Zona cloud/corporativa | Broker MQTT en la nube, analítica, dashboards | Lo fija la evaluación de riesgos | Consume datos; envía comandos solo si se permite explícitamente |
Y tres conductos:
- Conducto control-edge: acceso de solo lectura mediante protocolo industrial desde el gateway a los PLC.
- Conducto edge-broker: MQTT sobre TLS en el puerto 8883, solo saliente, desde el gateway o la DMZ hasta el broker.
- Conducto broker-consumidor: MQTT sobre TLS desde las aplicaciones de analítica y los dashboards hasta el broker.
Los niveles de seguridad objetivo de la tabla no están fijados a propósito. Proceden de tu evaluación de riesgos, y la misma arquitectura podría ser SL 2 en una planta y SL 3 en otra.
Documenta cada conducto
Para cada conducto, anota: los extremos, la dirección en que se establece la conexión, el protocolo y el puerto, el método de autenticación, el cifrado, los topics o datos permitidos y qué ocurre cuando falla. Los revisores te pedirán exactamente estos detalles.
Aplicar los requisitos fundamentales a MQTT
| Requisito fundamental | Medida de diseño MQTT |
|---|---|
| FR1 Identificación y autenticación | Credenciales únicas o certificados de cliente por gateway y por aplicación; sin cuentas compartidas ni anónimas |
| FR2 Control de uso | Cada identidad publica y se suscribe solo donde lo necesita; identidades separadas para las vías de lectura y de comandos |
| FR3 Integridad del sistema | TLS protege los mensajes en tránsito; valida los payloads en los consumidores; firmware firmado en los gateways |
| FR4 Confidencialidad de los datos | TLS 1.2 o 1.3 en todos los conductos que cruzan una frontera de zona; cifrado opcional del payload para protección de extremo a extremo |
| FR5 Flujo de datos restringido | Conexiones solo salientes, reglas de firewall por conducto, brokers o tenants separados por zona de confianza |
| FR6 Respuesta oportuna a eventos | Supervisa el estado de conexión, los inicios de sesión fallidos y las tasas de mensajes anómalas; define quién responde |
| FR7 Disponibilidad de recursos | Almacenamiento y reenvío en el gateway, cuotas y límites de tasa del broker, comportamiento definido ante la pérdida del broker |
Los comandos merecen su propio análisis
Enviar telemetría fuera de una planta supone un nivel de riesgo. Enviar comandos hacia dentro de una planta supone otro. Muchas organizaciones mantienen el conducto con la nube estrictamente de solo lectura y gestionan las escrituras de forma local. Si necesitas consignas remotas, sepáralas: topics distintos, credenciales distintas, validación en el gateway y límites sobre qué valores reenviará el gateway al PLC. La zona de control nunca debe ejecutar payloads en bruto procedentes de un broker.
Dónde encaja un broker MQTT gestionado
En este modelo, el broker en la nube es una zona y el enlace edge-broker es un conducto. Un broker MQTT gestionado no hace que tu sistema cumpla IEC 62443, y deberías desconfiar de cualquier proveedor que dé a entender lo contrario. Lo que sí puede hacer es proporcionar controles que referencies en tu propia evaluación.
ConnectMQ ofrece los siguientes controles, que pueden respaldar una evaluación de este tipo:
- TLS en el puerto 8883 y WebSockets seguros en el 8084, con un certificado de Let's Encrypt (FR3, FR4).
- Autenticación con credenciales generadas, con los client IDs vinculados a esas credenciales (FR1).
- Aislamiento multi-tenant, un clúster aislado en los planes Dedicated o el despliegue en tu propia cuenta cloud con BYOC (FR5).
- Cuotas por plan con el código de motivo 0x97 de MQTT 5, protección contra inundaciones y bloqueo de IP tras inicios de sesión fallidos repetidos (FR6, FR7).
- Visibilidad del estado de conexión mediante
$SYS/broker/connection/{clientId}/state, además de dashboards en el portal y reglas de alerta por umbral (FR6).
ConnectMQ no ofrece ACL por topic, así que usa brokers o credenciales separados por zona de confianza cuando se requiera separación a nivel de topic, y aplica el filtrado de comandos en tu gateway edge. Registra estas responsabilidades en tu matriz de responsabilidad compartida. La guía del broker MQTT en la nube compara los modelos compartido, dedicado y BYOC, algo que a menudo influye en el diseño de las zonas.
Ejemplo: gateway edge que publica en la zona del broker
El gateway es donde se concentra la mayor parte del trabajo de seguridad. Un gateway mínimo en Python que lee valores localmente y publica sobre TLS podría tener este aspecto:
import json
import time
import paho.mqtt.client as mqtt
BROKER = "YOUR_BROKER_HOST" # desde el portal de ConnectMQ
TOPIC = "connectmq/plant1/production/line1/press1/telemetry"
def read_plc_values():
# Sustitúyelo por tu lectura OPC UA o Modbus; el gateway solo lee.
return {"pressure_bar": 182.4, "cycle_count": 50123, "state": "RUNNING"}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set() # verifica el certificado del broker con las CA del sistema
client.reconnect_delay_set(min_delay=2, max_delay=300)
client.connect(BROKER, 8883, keepalive=60)
client.loop_start()
while True:
payload = read_plc_values()
payload["ts"] = int(time.time())
client.publish(TOPIC, json.dumps(payload), qos=1)
time.sleep(10)
Fíjate en lo que falta: ningún puerto entrante en el gateway, ninguna suscripción a topics de comandos, ninguna credencial compartida con otros gateways. El topic sigue una jerarquía al estilo ISA-95, que además hace visibles las fronteras de tus zonas en el modelo de datos. La guía de IoT industrial con MQTT explica esta estructura con más detalle.
Lista de revisión para un diseño MQTT según IEC 62443
- Una evaluación de riesgos define las zonas, los conductos y los niveles de seguridad objetivo de los flujos MQTT.
- Toda conexión MQTT que cruza una frontera de zona usa TLS y verifica el certificado del servidor.
- Todas las conexiones se inician desde la planta hacia fuera; no hay puertos entrantes hacia la zona de control.
- Cada gateway y aplicación tiene credenciales únicas y revocables.
- Las vías de comandos están separadas de la telemetría y se validan en el gateway.
- Los gateways almacenan datos en búfer cuando el conducto cae y se recuperan sin provocar inundaciones.
- El estado de conexión, los inicios de sesión fallidos y las tasas anómalas se supervisan con una respuesta definida.
- Las responsabilidades compartidas con el proveedor del broker están documentadas.
Para la parte de red de esta lista, lee seguridad MQTT para redes OT, y para la parte de identidad, el artículo sobre zero trust para la mensajería IoT.
Construye tu conducto de datos industriales en ConnectMQ
Puedes crear hoy mismo un prototipo del conducto edge-broker. Crea un broker privado en el plan Serverless gratuito en app.connectmq.com (sin tarjeta de crédito), conecta un gateway sobre TLS y observa cómo aparecen los topics ISA-95 en la vista de dispositivos del portal. Cuando el diseño requiera aislamiento, un broker MQTT gestionado en un despliegue Dedicated o BYOC mantiene la misma configuración de cliente, tanto para una planta en Monterrey como para una en Bilbao. Las buenas prácticas de seguridad MQTT generales se aplican en todo momento.
Preguntas frecuentes
¿Está permitido MQTT según IEC 62443?
IEC 62443 no prohíbe ni prescribe protocolos concretos. Exige que la comunicación entre zonas cumpla los requisitos de seguridad de su conducto, algo que MQTT sobre TLS con autenticación sólida puede respaldar.
¿Puede un broker MQTT en la nube estar certificado IEC 62443 para mi planta?
La certificación se aplica a productos, procesos o sistemas concretos frente a partes concretas de la norma. La conformidad de tu sistema en su conjunto se evalúa para tu planta; un proveedor de broker solo puede aportar controles que referencies en esa evaluación.
¿Deben fluir comandos desde la nube hacia la planta?
Solo si la evaluación de riesgos lo permite. Muchas plantas mantienen el conducto con la nube de solo lectura, y las que permiten comandos los separan, los validan en el gateway y limitan lo que se puede modificar.
¿Necesito un broker local en la DMZ?
No siempre. Un broker en la DMZ añade almacenamiento en búfer y un punto de inspección, mientras que un gateway que publica directamente en un broker en la nube sobre TLS es más sencillo. Lo deciden la evaluación de riesgos y el nivel de seguridad objetivo.
