Buenas prácticas de seguridad MQTT: una checklist práctica

MQTT se diseñó para redes con recursos limitados, no para redes hostiles. Por defecto, muchos brokers aceptan clientes anónimos en el puerto 1883 y lo envían todo en texto plano. Nada de esto es un fallo del protocolo —MQTT ofrece todos los mecanismos que necesitas—, pero la seguridad es algo que tienes que activar tú. Esta guía recorre cada capa y termina con una checklist que puedes usar en tus revisiones.

De qué te estás protegiendo

• Escuchas: leer credenciales y payloads en la red.
• Suplantación: un cliente malicioso que se conecta haciéndose pasar por uno de tus dispositivos o servicios.
• Publicación no autorizada: alguien que envía unlock a home/door/cmd.
• Fuga de datos: un cliente que se suscribe a # y lo lee todo.
• Denegación de servicio: avalanchas de conexiones o mensajes que agotan el broker.

1. Cifra todo con TLS

TLS protege las credenciales y los payloads en tránsito y permite a los clientes verificar que hablan con el broker real. Usa el puerto 8883 para MQTT sobre TLS y wss:// en el navegador; desactiva el listener sin cifrar en 1883 o bloquéalo con un firewall fuera de una red local de confianza. Más detalles en puertos MQTT explicados y MQTT sobre WebSockets.

• Exige TLS 1.2 o superior.
• Verifica siempre el certificado del servidor en los clientes. Opciones como --insecure, setInsecure() o rejectUnauthorized: false son solo para depurar en local.
• Planifica la renovación de certificados: un certificado caducado deja sin conexión a todos los dispositivos a la vez.

mosquitto_sub -h broker.example.com -p 8883 --cafile ca.crt \
  -u sensor-01 -P 'secret' -t 'devices/sensor-01/#' -v

2. Autentica a todos los clientes

Desactiva el acceso anónimo. Después elige un método de autenticación adecuado para cada tipo de cliente:

Nunca compartas un mismo login en toda una flota: si un solo dispositivo se ve comprometido, querrás revocar una credencial, no volver a flashear todos los dispositivos. Guarda las contraseñas con hash en el broker. Si usas Mosquitto, sigue la guía de autenticación de Mosquitto; el generador de mosquitto.conf crea una configuración segura con TLS y archivos de contraseñas.

3. Autoriza topics con ACL

La autenticación responde a quién eres; la autorización, a qué puedes hacer. Sin ACL, cualquier cliente autenticado puede leer y escribir en todos los topics. Aplica el principio de mínimo privilegio: cada cliente obtiene acceso de lectura o escritura solo a los topics que necesita.

# backend service: read all telemetry, send commands
user backend
topic read devices/+/telemetry
topic write devices/+/cmd

# every device: only its own topics (%u = username)
pattern write devices/%u/telemetry
pattern read devices/%u/cmd

Las reglas de patrón que sustituyen el nombre de usuario o el client ID escalan mucho mejor que una regla por dispositivo. Comprueba tus filtros con el probador de topics; los comodines de MQTT se explican en topics y comodines.

4. Controla los client IDs

Un cliente que se conecta con un client ID ya existente expulsa del broker a la conexión original. Un atacante que conozca tus IDs puede aprovecharlo para desconectar dispositivos, y un duplicado accidental provoca bucles de reconexión interminables. Vincula los client IDs a las credenciales cuando tu broker lo permita (por ejemplo, exigiendo que el client ID coincida con el nombre de usuario o con el common name del certificado) y evita IDs predecibles en brokers compartidos. El generador de client IDs te ayuda a crear IDs únicos.

5. Diseña los topics pensando en la seguridad

• Coloca el ID del dispositivo o del tenant en una posición fija para que los patrones de ACL puedan coincidir con él.
• Separa la telemetría (escribe el dispositivo) de los comandos (lee el dispositivo) en subárboles distintos.
• No pongas secretos ni datos personales en los nombres de topic: aparecen en logs y herramientas de monitorización.
• Cuidado con los mensajes retenidos (retained) en topics de comandos: un unlock retenido se vuelve a ejecutar al reconectar.

6. Cifra o firma los payloads sensibles

TLS protege cada salto, pero el broker ve los payloads en claro. Si el operador del broker u otros servicios conectados a él no deben leer los datos, cifra los payloads de extremo a extremo (por ejemplo, con AES-GCM y claves gestionadas fuera de MQTT) o, como mínimo, firma los comandos para que los dispositivos puedan rechazar los falsificados. Valida cada payload entrante en el dispositivo: aplica límites de tamaño, comprueba tipos e ignora comandos desconocidos.

7. Establece límites y rate limits

Limita el tamaño máximo de paquete, los mensajes en vuelo y en cola por cliente, la tasa de conexiones y el número de suscripciones. MQTT 5 permite al broker anunciar a los clientes límites como el tamaño máximo de paquete y el receive maximum. Los rate limits evitan que un dispositivo con un bug atrapado en un bucle de publicación tumbe a todos los demás. Usa la calculadora de tamaño de paquete para fijar límites de tamaño realistas.

8. Protege las credenciales en dispositivos y apps

Las credenciales de los dispositivos acaban en la memoria flash, y las del navegador, en bundles de JavaScript que cualquiera puede leer. Da por hecho que se pueden extraer: asigna a cada cliente la ACL más restrictiva posible, aprovisiona credenciales por dispositivo durante la fabricación o el primer arranque en lugar de incrustar un único secreto en el firmware, y usa cifrado de flash o un elemento seguro cuando el hardware lo permita. En apps web y móviles, emite credenciales de corta duración desde tu backend en lugar de distribuir una contraseña permanente.

9. Monitoriza y registra

• Registra conexiones, desconexiones y fallos de autenticación, y genera alertas ante picos.
• Vigila clientes que se suscriban inesperadamente a # o $SYS/#.
• Mide el número de conexiones y la tasa de mensajes por cliente para detectar dispositivos comprometidos o que se comportan mal.
• Mantén actualizados el broker y las librerías cliente.

Checklist de seguridad MQTT

Cuando un cliente con permisos restringidos no puede conectarse, el reason code del CONNACK te dice si el problema son las credenciales o la autorización. Búscalo en la referencia de reason codes de MQTT.

Preguntas frecuentes