Isolation des tenants MQTT : séparer les données clients

L'isolation des tenants MQTT est ce qui garantit qu'un client ne pourra jamais lire, écrire ni ralentir les messages d'un autre client. Dans cet article, vous découvrirez la différence entre isolation logique et physique, le fonctionnement de la protection contre les voisins bruyants, les modes de défaillance à tester et la manière de choisir le bon niveau de séparation pour chaque client.

Pourquoi l'isolation des tenants est importante

Si votre produit connecte des appareils appartenant à différents clients, le broker conserve leurs données côte à côte. Une seule erreur, comme un abonnement à wildcard trop large, un identifiant partagé ou une collision de client ID, peut exposer la télémétrie d'un client à un autre ou laisser une flotte défaillante dégrader le service de tous. Ces incidents sont difficiles à expliquer aux clients et coûteux à réparer.

L'isolation comporte trois dimensions, et une bonne conception les traite toutes :

Confidentialité. Un tenant ne peut pas lire les messages, les valeurs retained ou les données de session d'un autre tenant.
Intégrité. Un tenant ne peut pas publier dans les topics d'un autre tenant ni s'approprier ses sessions.
Disponibilité. Un tenant ne peut pas consommer tant de capacité que les autres en pâtissent.

Isolation logique ou isolation physique

L'isolation logique

Avec l'isolation logique, les tenants partagent les mêmes processus et les mêmes machines du broker, et c'est le logiciel qui les sépare. Chaque tenant a ses propres identités et son propre espace de topics, et des quotas par tenant plafonnent l'utilisation des ressources. C'est ainsi que fonctionnent la plupart des services cloud mutualisés et, lorsqu'elle est implémentée avec soin, c'est une frontière solide pour la confidentialité et l'intégrité.

Sa limite : les ressources physiques restent mutualisées. Les quotas bornent l'impact d'un voisin bruyant, mais un tenant sur un cluster mutualisé ne peut pas obtenir de garanties de capacité indépendantes de tous les autres.

L'isolation physique

Avec l'isolation physique, un tenant dispose de son propre cluster : processus séparés, machines séparées et souvent endpoints réseau séparés. Rien de ce que fait un autre client ne peut affecter son CPU, sa mémoire ou ses connexions. Elle coûte plus cher, car la capacité est réservée plutôt que mutualisée, et son provisionnement prend plus de temps.

Une étape supplémentaire consiste à placer ce cluster dédié dans le propre compte cloud du client, ce qui ajoute la propriété de l'infrastructure elle-même. C'est le modèle bring-your-own-cloud décrit dans broker MQTT BYOC.

Niveau d'isolation	Partagé avec d'autres	Protège contre	Choix typique pour
Préfixe de topic seul (non imposé)	Tout	Les confusions accidentelles uniquement	Applications internes à propriétaire unique
Logique, identité de broker par tenant	Matériel, processus	Fuites de données, usurpation, voisins bruyants bornés	La plupart des clients SaaS, prototypes
Physique, cluster dédié	Rien au niveau du broker	Les voisins bruyants, entièrement	Grandes flottes, SLA stricts, clients réglementés
Physique, dans le compte du client	Rien ; le client possède l'infrastructure	Exigences de propriété de l'infrastructure	Politiques de contrôle des données et de conformité

La protection contre les voisins bruyants en pratique

Les voisins bruyants sont rarement malveillants. Les causes habituelles sont banales :

Un firmware qui se reconnecte immédiatement en cas d'échec, provoquant une tempête de connexions.
Un script de test qui publie en boucle serrée sans délai.
Des payloads surdimensionnés, comme des images, envoyés là où l'on attendait du JSON léger.
Des milliers d'abonnements créés par un client qui ne se désabonne jamais.

Une protection efficace agit au niveau du client et du tenant : plafonds sur les connexions, le débit de messages, la taille des payloads et les abonnements ; blocage des adresses après des échecs de connexion répétés ; et retour clair au client. En MQTT 5, le reason code 0x97 (Quota exceeded) indique précisément au client pourquoi une publication ou une connexion a été refusée. Pour en savoir plus, voyez comment les quotas de connexion d'un broker MQTT influencent la conception des clients.

L'identité est le fondement

C'est au niveau de l'identité que l'isolation cède le plus vite. Suivez ces règles :

Ne partagez jamais d'identifiants entre tenants. Chaque client reçoit ses propres identifiants, et idéalement chaque appareil aussi.
Liez les client IDs aux identifiants. En MQTT, une seconde connexion avec le même client ID expulse la première. Si les client IDs ne sont pas liés à des identités, un tenant pourrait perturber un autre en réutilisant ses IDs.
Utilisez TLS partout. Des identifiants envoyés en TCP clair sur un réseau public peuvent être interceptés. Les ports 8883 ou 8084 doivent être la norme en production.
Renouvelez les secrets. Prévoyez la rotation dès le premier jour, y compris la manière dont les appareils reçoivent leurs nouveaux identifiants.

Le guide des bonnes pratiques de sécurité MQTT détaille ces contrôles.

Tester votre isolation

Ne présumez pas que l'isolation fonctionne : vérifiez-la. Un plan de test minimal :

Connectez un client avec les identifiants du tenant A et abonnez-vous à #. Publiez depuis le tenant B. Le tenant A ne doit rien recevoir.
Essayez de vous connecter avec le client ID du tenant B en utilisant les identifiants du tenant A. Le broker doit refuser.
Publiez des retained messages en tant que tenant B, puis abonnez-vous en tant que tenant A au même nom de topic. Aucun retained message ne doit arriver.
Depuis le tenant A, dépassez la limite de connexions ou de débit. Vérifiez que la latence et les connexions du tenant B ne sont pas affectées.
Échouez plusieurs fois à vous connecter au tenant A depuis une même adresse. Vérifiez que le blocage s'applique à cette adresse, et non au tenant B.

Voici un petit script Python, avec paho-mqtt 2.x, pour le test 1. Lancez-le avec les informations du tenant A pendant qu'un autre client publie avec celles du 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)   # publiez depuis le tenant B pendant cette fenêtre
client.loop_stop()
print("Isolation OK" if not received else f"Leak: {len(received)} messages")

Sur votre propre broker, vous verrez évidemment le trafic de votre propre tenant : lancez donc ce test avec un tenant qui n'a aucun éditeur.

Comment ConnectMQ isole les tenants

ConnectMQ applique l'isolation avec une force différente selon le plan :

Serverless (Free et Paid). Les brokers partagent un cluster avec une isolation multi-tenant. Chaque broker dispose d'identifiants générés, de client IDs liés à ces identifiants et de quotas par plan, par exemple jusqu'à 25 connexions sur le plan gratuit et jusqu'à 1 000 sur le plan payant. Une protection anti-flood et le blocage des IP après des échecs de connexion répétés protègent le cluster mutualisé.
Dedicated. Votre broker tourne sur un cluster isolé, si bien qu'aucun autre client ne partage sa capacité.
BYOC. Le broker tourne dans votre propre compte cloud et ConnectMQ le gère.
Self Managed Enterprise. Pour les organisations qui exploitent elles-mêmes la plateforme.

Le serveur MQTT public gratuit broker.connectmq.com est délibérément l'inverse d'un broker isolé : son espace de démonstration est lisible par tous et ne sert qu'aux expériences. Utilisez-le pour apprendre, jamais pour des données clients. La page qui lui est consacrée en précise les limites.

Choisir le bon niveau

Partez de ce qu'exigent vos clients et vos contrats, pas de ce qui est techniquement possible :

Aucune donnée client, simple apprentissage : le serveur MQTT public gratuit.
Votre propre produit, un seul propriétaire de toutes les données : un broker Serverless privé.
De nombreux clients aux exigences ordinaires : un broker isolé par client, ou un broker partagé avec une séparation strictement imposée par votre propre backend.
Des clients avec des garanties de capacité ou des contraintes réglementaires : Dedicated ou BYOC.

Pour voir comment les produits SaaS combinent ces options, consultez MQTT pour un SaaS IoT.

Démarrer avec ConnectMQ

Créez un broker isolé en quelques minutes sur le plan Serverless gratuit sur app.connectmq.com, sans carte bancaire. Lorsqu'un client a besoin de garanties plus fortes, faites-le passer sur un cluster Dedicated ou en BYOC avec le même code client. La présentation du broker MQTT managé et le guide du broker MQTT cloud détaillent les plans.

Questions fréquentes

Quelle est la différence entre isolation MQTT logique et physique ?

L'isolation logique sépare les tenants par le logiciel sur des machines partagées ; l'isolation physique donne à un tenant son propre cluster. L'isolation physique supprime aussi entièrement les effets de voisins bruyants.

Un autre client sur un broker partagé peut-il lire mes messages ?

Pas si le fournisseur isole correctement les tenants. Chaque tenant doit avoir ses propres identifiants et son propre espace de topics, ce que vous pouvez vérifier avec un test d'abonnement à wildcard.

Que se passe-t-il lorsqu'un tenant dépasse son quota ?

Le broker refuse la connexion ou le message supplémentaire. Les clients MQTT 5 reçoivent un reason code comme 0x97 pour pouvoir temporiser et journaliser la cause.

Le serveur MQTT public gratuit est-il isolé ?

Non. L'espace public de broker.connectmq.com est lisible par tous et n'est destiné qu'aux tests.

Isolation des tenants MQTT : garder les données de chaque client séparées