Registro de auditoría MQTT: qué registrar y por qué

Q: ¿Puedo obtener eventos de conexión de un broker MQTT gestionado?

En ConnectMQ puedes suscribirte a $SYS/broker/connection/{clientId}/state para conocer el estado de conexión y combinarlo con logs del cliente sobre reason codes para construir tu propio historial de conexiones.

El registro de auditoría MQTT consiste en anotar quién se conectó, quién no logró conectarse, qué cambió en la configuración y qué acciones fueron relevantes, para poder investigar incidentes y demostrar a los auditores que los controles funcionan. Esta guía explica qué eventos registrar, qué campos necesita cada entrada, cuánto tiempo conservarlos y cómo montar un pipeline de logs alrededor de un broker MQTT gestionado. Se centra en eventos de seguridad y operativos, no en almacenar cada payload.

Logs de auditoría frente a datos de mensajes

Conviene separar tres tipos de registros:

Logs de auditoría: eventos relevantes para la seguridad, como logins, logins fallidos, cambios de credenciales y acciones administrativas. Pequeños, estructurados y conservados durante un periodo definido.
Logs operativos: caídas de conexión, errores, cuotas alcanzadas y señales de rendimiento que se usan para mantener el sistema en marcha.
Historial de mensajes: la propia telemetría, normalmente almacenada en una base de datos de series temporales o un historian para analítica.

Mezclarlos genera problemas. Los archivos de payloads son grandes, pueden contener datos personales o confidenciales y entierran los eventos de seguridad que realmente necesitas durante una investigación. Mantén los logs de auditoría ligeros y centrados.

Qué registrar

Evento	Por qué importa	Campos clave
Conexión correcta	Muestra qué identidad estaba activa, cuándo y desde dónde	Marca de tiempo (UTC), client ID, usuario, IP de origen, versión del protocolo, TLS sí/no
Autenticación fallida	Detecta intentos de adivinar contraseñas, credenciales filtradas y dispositivos mal configurados	Marca de tiempo, usuario intentado, client ID, IP de origen, reason code
Desconexión	Explica cortes y secuestros de sesión	Marca de tiempo, client ID, reason code, duración de la sesión
Denegación de autorización	Muestra clientes que intentan acceder a topics que no les corresponden	Client ID, filtro de topic, acción, reason code
Evento de cuota o límite de tasa	Identifica dispositivos descontrolados y abusos	Client ID, tipo de límite, reason code (por ejemplo 0x97)
Bloqueos de IP	Confirma que las defensas automáticas funcionan	IP de origen, desencadenante, duración
Ciclo de vida de credenciales	Demuestra que el aprovisionamiento, la rotación y la revocación se realizan	Identidad, acción, actor, marca de tiempo
Cambios administrativos	Quién cambió brokers, planes, reglas de alerta o usuarios	Actor, acción, objeto, valor anterior y nuevo
Mensajes de comando	En topics de control, quién envió qué comando	Topic, identidad del emisor, comando, resultado

La última fila merece atención. La telemetría rara vez necesita una pista de auditoría, pero los comandos que cambian el estado de un equipo a menudo sí. Registra el comando, la identidad que lo envió y el acuse de recibo, no solo el hecho de que pasó un mensaje.

Campos que necesita cada entrada

Sea cual sea la fuente, normaliza las entradas a una estructura coherente:

{
  "ts": "2026-10-16T09:41:07.312Z",
  "event": "client.disconnected",
  "source": "connectmq-monitor",
  "client_id": "gw-plant1-01",
  "username": "gw-plant1-01",
  "ip": "203.0.113.24",
  "reason_code": "0x8E",
  "details": { "previous_state": "connected" }
}

Usa marcas de tiempo UTC con milisegundos, mantén estables los nombres de los eventos y nunca registres contraseñas, tokens ni payloads completos que contengan datos personales.

De dónde salen los eventos

En un entorno autoalojado, los propios archivos de log del broker son la fuente principal. Mosquitto, por ejemplo, registra conexiones, desconexiones y fallos de autenticación cuando se activan las opciones log_type correspondientes, y tú envías esos archivos a un sistema central.

Con un broker MQTT gestionado, combinas lo que expone la plataforma con lo que registran tus propios clientes y aplicaciones. Es importante ser preciso sobre qué es cada cosa. En ConnectMQ las fuentes visibles son:

Topics de estado de conexión: $SYS/broker/connection/{clientId}/state indica si un cliente está conectado; puedes suscribirte y registrarlo.
Dashboard del portal y vista de dispositivos: visibilidad operativa de los clientes conectados y los topics.
Reglas de alerta por umbral y registro de alertas: constancia de cuándo los datos cruzaron los umbrales que definiste.
Reason codes de MQTT 5: devueltos a los clientes al rechazarlos, incluido el 0x97 de cuota superada, que tus clientes pueden registrar.
Protecciones de la plataforma: la protección contra floods y el bloqueo de IP tras varios logins fallidos se ejecutan en el lado del broker.

Son señales operativas, no una pista de auditoría para cumplimiento normativo. Para una pista de auditoría completa, registra los eventos desde el lado del cliente y de la aplicación en un almacenamiento que controles, y documenta los procedimientos administrativos en tus propios registros de cambios. Es el reparto de responsabilidad compartida habitual en un broker MQTT gestionado: la plataforma opera el broker y tú conservas la pista de auditoría de tus clientes y procesos.

Monta un pipeline de auditoría sencillo

Un pequeño servicio que se suscribe a los topics de estado de conexión y escribe líneas estructuradas en un archivo o en un agente de envío de logs te da un historial de conexiones fiable. Este ejemplo usa paho-mqtt 2.x y vigila una lista conocida de client ID:

import json
import logging
from datetime import datetime, timezone
import paho.mqtt.client as mqtt

WATCHED_CLIENTS = ["gw-plant1-01", "gw-plant1-02", "dashboard-01"]

logging.basicConfig(filename="mqtt-audit.jsonl", level=logging.INFO, format="%(message)s")

def audit(event, **fields):
    entry = {"ts": datetime.now(timezone.utc).isoformat(timespec="milliseconds"),
             "event": event, "source": "connectmq-monitor", **fields}
    logging.info(json.dumps(entry))

def on_connect(client, userdata, flags, reason_code, properties):
    audit("monitor.connected", reason_code=str(reason_code))
    for cid in WATCHED_CLIENTS:
        client.subscribe(f"$SYS/broker/connection/{cid}/state", qos=1)

def on_message(client, userdata, msg):
    cid = msg.topic.split("/")[3]
    audit("client.state", client_id=cid, state=msg.payload.decode("utf-8", "replace"))

def on_disconnect(client, userdata, flags, reason_code, properties):
    audit("monitor.disconnected", reason_code=str(reason_code))

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()
client.on_connect = on_connect
client.on_message = on_message
client.on_disconnect = on_disconnect
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_forever()

Cualquier agente de envío de logs puede recoger el archivo JSON lines y reenviarlo al SIEM o a la plataforma de logs que ya use tu organización. Observa que el monitor también registra sus propias desconexiones: los huecos en tu pista de auditoría son en sí mismos eventos importantes.

Registra también en el lado del cliente

Los dispositivos y las aplicaciones ven eventos que el broker nunca te comunica, como sus propios intentos de conexión fallidos y las publicaciones rechazadas. Haz que cada cliente registre:

Los intentos de conexión con el reason code resultante.
Las suscripciones rechazadas (códigos SUBACK de 0x80 en adelante).
Las publicaciones rechazadas, especialmente 0x97 de cuota superada y 0x87 de no autorizado.
Los comandos recibidos, los resultados de validación y las acciones realizadas.
Los eventos de rotación de credenciales.

En los gateways de planta, envía estos logs a un recolector central en lugar de guardarlos solo en el dispositivo. La guía de seguridad OT con MQTT explica cómo hacerlo sin abrir puertos de entrada.

Retención, integridad y privacidad

Los logs de auditoría solo son útiles si son completos, fiables y legales de conservar.

Retención: fija un periodo según tus necesidades regulatorias, contractuales y de investigación, y documéntalo. Elimina los logs cuando termine ese periodo.
Integridad: escribe en almacenamiento de solo anexado o en un sistema que restrinja el borrado, y limita quién puede modificar los logs.
Sincronización horaria: usa NTP en cada host que registre; los relojes desfasados hacen inútiles las líneas de tiempo.
Privacidad: las direcciones IP y los nombres de usuario pueden ser datos personales. Recoge lo que necesites, protege el acceso y aplica tu política de privacidad.
Acceso: registra también el acceso a los propios logs.

Convierte los logs en alertas

Los logs que nadie lee no mejoran la seguridad. Empieza con unas pocas alertas de alto valor:

Muchas autenticaciones fallidas para un usuario o desde una IP en poco tiempo.
Un dispositivo conocido que se conecta desde una red inesperada.
Un gateway desconectado más tiempo que su corte máximo esperado.
Rechazos repetidos por cuota o límite de tasa de un mismo cliente.
Cualquier comando en un topic de control fuera del horario laboral o desde una identidad inesperada.

Estas alertas encajan con las ideas de verificación continua de zero trust para la mensajería IoT y con las expectativas de monitorización de eventos de marcos como IEC 62443.

Checklist de registro de auditoría

Lista definida de eventos de seguridad y responsables de cada fuente.
Estructura JSON coherente con marcas de tiempo UTC.
Estado de conexión monitorizado para cada cliente crítico.
Registro en el cliente de reason codes, rechazos y comandos.
Cambios administrativos registrados en tu proceso de gestión de cambios.
Almacenamiento central con control de acceso y un periodo de retención documentado.
Alertas sobre logins fallidos, desconexiones inesperadas y anomalías de tasa.
Revisión periódica de que el propio pipeline funciona.

Empieza a monitorizar tu broker con ConnectMQ

Crea un broker privado en el plan gratuito Serverless en app.connectmq.com (sin tarjeta de crédito), conecta el monitor anterior con tus credenciales generadas y observa cómo aparecen los eventos de conexión. Si antes quieres experimentar sin credenciales, prueba el servidor MQTT público gratuito, solo con datos de prueba y nunca con datos de producción. El artículo de buenas prácticas de seguridad MQTT cubre los controles que tus logs deberían verificar.

Preguntas frecuentes

¿Debo registrar cada mensaje MQTT para auditoría?

Normalmente no. Registra los eventos de seguridad y administrativos, además de los comandos en topics de control. Guarda la telemetría por separado en un historian o una base de datos si la necesitas para analítica.

¿Cuál es el evento MQTT más importante de auditar?

Los intentos de autenticación fallidos, porque revelan pronto los intentos de adivinar contraseñas, las credenciales filtradas o caducadas y los dispositivos mal configurados.

¿Cuánto tiempo deben conservarse los logs de auditoría MQTT?

No hay una única respuesta. La retención depende de tus requisitos regulatorios, contractuales y de investigación, así que define un periodo, documéntalo y aplica el borrado cuando termine.

¿Puedo obtener eventos de conexión de un broker MQTT gestionado?

En ConnectMQ puedes suscribirte a $SYS/broker/connection/{clientId}/state para conocer el estado de conexión y combinarlo con logs del cliente sobre reason codes para construir tu propio historial de conexiones.