El aislamiento de tenants en MQTT es lo que garantiza que un cliente nunca pueda leer, escribir ni ralentizar los mensajes de otro. En este artículo aprenderás la diferencia entre el aislamiento lógico y el físico, cómo funciona la protección contra vecinos ruidosos, qué modos de fallo conviene probar y cómo elegir el nivel de separación adecuado para cada cliente.
Por qué importa el aislamiento de tenants
Si tu producto conecta dispositivos que pertenecen a distintos clientes, el broker guarda sus datos uno junto a otro. Un solo error, como una suscripción con comodín que abarca demasiado, una credencial compartida o una colisión de client ID, puede exponer la telemetría de un cliente a otro o permitir que una flota que se comporta mal degrade el servicio de todos. Esos incidentes son difíciles de explicar a los clientes y caros de solucionar.
El aislamiento tiene tres dimensiones, y un buen diseño las aborda todas:
- Confidencialidad. Un tenant no puede leer los mensajes, valores retenidos ni datos de sesión de otro tenant.
- Integridad. Un tenant no puede publicar en los topics de otro tenant ni apoderarse de sus sesiones.
- Disponibilidad. Un tenant no puede consumir tanta capacidad que los demás salgan perjudicados.
Aislamiento lógico frente a físico
Aislamiento lógico
Con el aislamiento lógico, los tenants comparten los mismos procesos y máquinas del broker, y es el software el que los mantiene separados. Cada tenant tiene sus propias identidades y su propio espacio de topics, y las cuotas por tenant limitan el uso de recursos. Así funcionan la mayoría de los servicios en la nube compartidos y, bien implementado, es una frontera sólida para la confidencialidad y la integridad.
Su límite es que los recursos físicos siguen agrupados. Las cuotas acotan el impacto de un vecino ruidoso, pero un tenant en un clúster compartido no puede obtener garantías de capacidad independientes de los demás.
Aislamiento físico
Con el aislamiento físico, un tenant obtiene su propio clúster: procesos separados, máquinas separadas y, a menudo, endpoints de red separados. Nada de lo que haga otro cliente puede afectar a su CPU, memoria o conexiones. Cuesta más porque la capacidad se reserva en lugar de agruparse, y tarda más en aprovisionarse.
Un paso más es situar ese clúster dedicado dentro de la propia cuenta de nube del cliente, lo que añade la propiedad de la infraestructura misma. Es el modelo bring-your-own-cloud descrito en broker MQTT BYOC.
| Nivel de aislamiento | Compartido con otros | Protege contra | Elección típica para |
|---|---|---|---|
| Solo prefijo de topic (sin aplicación forzosa) | Todo | Solo confusiones accidentales | Aplicaciones internas de un único propietario |
| Lógico, identidad de broker por tenant | Hardware, procesos | Fugas de datos, suplantación, vecinos ruidosos acotados | La mayoría de los clientes SaaS, prototipos |
| Físico, clúster dedicado | Nada a nivel de broker | Vecinos ruidosos por completo | Flotas grandes, SLA estrictos, clientes regulados |
| Físico, en la cuenta del cliente | Nada; el cliente posee la infraestructura | Requisitos de propiedad de la infraestructura | Políticas de control de datos y cumplimiento |
La protección contra vecinos ruidosos en la práctica
Los vecinos ruidosos rara vez son maliciosos. Las causas habituales son mundanas:
- Firmware que se reconecta inmediatamente tras un fallo y crea una tormenta de conexiones.
- Un script de prueba que publica en un bucle cerrado sin pausa.
- Payloads sobredimensionados, como imágenes, enviados donde se esperaba un JSON pequeño.
- Miles de suscripciones creadas por un cliente que nunca cancela la suscripción.
Una protección eficaz actúa a nivel de cliente y de tenant: límites de conexiones, tasa de mensajes, tamaño de payload y suscripciones; bloqueo de direcciones tras inicios de sesión fallidos repetidos; y una respuesta clara al cliente. En MQTT 5, el reason code 0x97 (Quota exceeded) indica al cliente exactamente por qué se rechazó una publicación o una conexión. Lee más sobre cómo afectan las cuotas de conexión de un broker MQTT al diseño de los clientes.
La identidad es la base
El aislamiento falla antes que en ningún otro sitio en la capa de identidad. Sigue estas reglas:
- Nunca compartas credenciales entre tenants. Cada cliente recibe sus propias credenciales y, idealmente, también cada dispositivo.
- Vincula los client IDs a las credenciales. En MQTT, una segunda conexión con el mismo client ID expulsa a la primera. Si los client IDs no están ligados a identidades, un tenant podría perjudicar a otro reutilizando sus IDs.
- Usa TLS en todas partes. Las credenciales enviadas por TCP sin cifrar en una red pública pueden capturarse. Los puertos 8883 u 8084 deberían ser el estándar en producción.
- Rota los secretos. Planifica la rotación desde el primer día, incluido cómo reciben los dispositivos las nuevas credenciales.
La guía de buenas prácticas de seguridad MQTT trata estos controles con más profundidad.
Probar tu aislamiento
No des por hecho que el aislamiento funciona; verifícalo. Un plan de pruebas mínimo:
- Conecta un cliente con las credenciales del tenant A y suscríbete a
#. Publica desde el tenant B. El tenant A no debe recibir nada. - Intenta conectarte con el client ID del tenant B usando las credenciales del tenant A. El broker debe rechazarlo.
- Publica retained messages como tenant B y después suscríbete como tenant A al mismo nombre de topic. No debe llegar ningún retained message.
- Desde el tenant A, supera el límite de conexiones o de tasa. Confirma que la latencia y las conexiones del tenant B no se ven afectadas.
- Falla repetidamente el inicio de sesión del tenant A desde una dirección. Confirma que el bloqueo se aplica a esa dirección, no al tenant B.
Aquí tienes un pequeño script de Python, con paho-mqtt 2.x, para la prueba 1. Ejecútalo con los datos del tenant A mientras otro cliente publica con los del tenant B.
import ssl
import time
import paho.mqtt.client as mqtt
received = []
def on_connect(client, userdata, flags, reason_code, properties):
print("Tenant A connected:", reason_code)
client.subscribe("#", qos=0)
def on_message(client, userdata, msg):
received.append(msg.topic)
print("Unexpected message:", msg.topic)
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(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883, keepalive=30)
client.loop_start()
time.sleep(60) # publica desde el tenant B durante esta ventana
client.loop_stop()
print("Isolation OK" if not received else f"Leak: {len(received)} messages")
En tu propio broker verás, lógicamente, el tráfico de tu propio tenant, así que ejecuta esta prueba con un tenant que no tenga publicadores propios.
Cómo aísla ConnectMQ a los tenants
ConnectMQ aplica el aislamiento con distinta intensidad según el plan:
- Serverless (Free y Paid). Los brokers comparten un clúster con aislamiento multi-tenant. Cada broker tiene credenciales generadas, client IDs vinculados a esas credenciales y cuotas por plan, por ejemplo hasta 25 conexiones en el plan gratuito y hasta 1.000 en el de pago. La protección contra inundaciones y el bloqueo de IP tras inicios de sesión fallidos repetidos protegen el clúster compartido.
- Dedicated. Tu broker se ejecuta en un clúster aislado, así que ningún otro cliente comparte su capacidad.
- BYOC. El broker se ejecuta en tu propia cuenta de nube y ConnectMQ lo gestiona.
- Self Managed Enterprise. Para organizaciones que operan la plataforma por su cuenta.
El servidor MQTT público gratuito de broker.connectmq.com es deliberadamente lo contrario de aislado: su área de demostración la puede leer cualquiera y está pensada solo para pruebas y prototipos. Úsalo para aprender, nunca para datos de clientes ni de producción. La página del servidor MQTT público gratuito enumera sus límites.
Elegir el nivel adecuado
Parte de lo que exigen tus clientes y contratos, no de lo que es técnicamente posible:
- Sin datos de clientes, solo para aprender: el servidor público.
- Tu propio producto, un único propietario de todos los datos: un broker Serverless privado.
- Muchos clientes con requisitos corrientes: un broker aislado por cliente, o un broker compartido con una separación estrictamente aplicada en tu propio backend.
- Clientes con garantías de capacidad o necesidades regulatorias: Dedicated o BYOC.
Para ver cómo combinan estas opciones los productos SaaS, consulta MQTT para SaaS IoT.
Empieza con ConnectMQ
Crea un broker aislado en minutos con el plan Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Cuando un cliente necesite garantías más fuertes, pásalo a un clúster Dedicated o a BYOC con el mismo código de cliente. La visión general del broker MQTT gestionado y la guía de broker MQTT en la nube explican los planes con más detalle.
Preguntas frecuentes
¿Cuál es la diferencia entre el aislamiento lógico y el físico en MQTT?
El aislamiento lógico separa a los tenants mediante software en máquinas compartidas; el físico da a un tenant su propio clúster. El aislamiento físico además elimina por completo los efectos de los vecinos ruidosos.
¿Puede otro cliente de un broker compartido leer mis mensajes?
No, si el proveedor aísla correctamente a los tenants. Cada tenant debe tener sus propias credenciales y su propio espacio de topics, algo que puedes verificar con una prueba de suscripción con comodín.
¿Qué ocurre cuando un tenant supera su cuota?
El broker rechaza la conexión o el mensaje adicional. Los clientes MQTT 5 reciben un reason code como 0x97 para que puedan reducir el ritmo y registrar la causa.
¿Está aislado el servidor MQTT público gratuito?
No. El área pública de broker.connectmq.com la puede leer cualquiera y está pensada solo para pruebas.
