MQTT-Mandantentrennung garantiert, dass ein Kunde niemals die Nachrichten eines anderen Kunden lesen, schreiben oder ausbremsen kann. In diesem Artikel lernen Sie den Unterschied zwischen logischer und physischer Isolation kennen, wie Schutz vor Noisy Neighbors funktioniert, auf welche Fehlerbilder Sie testen sollten und wie Sie für jeden Kunden die richtige Trennungsstufe wählen.
Warum Mandantentrennung wichtig ist
Wenn Ihr Produkt Geräte verschiedener Kunden verbindet, hält der Broker deren Daten Seite an Seite. Ein einziger Fehler, etwa eine zu weit greifende Wildcard-Subscription, geteilte Zugangsdaten oder eine Kollision von Client IDs, kann die Telemetrie eines Kunden einem anderen offenlegen oder einer fehlerhaften Flotte erlauben, den Service für alle zu verschlechtern. Solche Vorfälle sind Kunden schwer zu erklären und teuer zu bereinigen.
Im DACH-Raum betrifft das besonders Maschinen- und Anlagenbauer, die Maschinendaten ihrer installierten Basis bei vielen Endkunden für Service, Fernwartung und Predictive Maintenance sammeln. Jeder Betreiber erwartet, dass seine Produktionsdaten bei ihm bleiben. Bildet jeder Kunde seinen eigenen Unified Namespace (UNS) nach ISA-95 ab, ist die oberste Ebene (Enterprise) die natürliche Mandantengrenze: Alles unterhalb von kunde-a/werk-stuttgart/... gehört genau einem Mandanten.
Isolation hat drei Dimensionen, und ein gutes Design adressiert alle drei:
- Vertraulichkeit. Ein Mandant kann die Nachrichten, Retained-Werte oder Sitzungsdaten eines anderen Mandanten nicht lesen.
- Integrität. Ein Mandant kann nicht in die Topics eines anderen Mandanten publizieren oder dessen Sitzungen übernehmen.
- Verfügbarkeit. Ein Mandant kann nicht so viel Kapazität verbrauchen, dass andere darunter leiden.
Logische vs. physische Isolation
Logische Isolation
Bei logischer Isolation teilen sich Mandanten dieselben Broker-Prozesse und Maschinen, und die Software hält sie auseinander. Jeder Mandant hat eigene Identitäten und einen eigenen Topic-Raum, und Quoten pro Mandant begrenzen den Ressourcenverbrauch. So funktionieren die meisten geteilten Cloud-Services, und sorgfältig umgesetzt ist das eine starke Grenze für Vertraulichkeit und Integrität.
Die Grenze liegt darin, dass physische Ressourcen weiterhin gepoolt sind. Quoten begrenzen den Einfluss eines Noisy Neighbors, doch ein Mandant auf einem geteilten Cluster kann keine Kapazitätsgarantien erhalten, die von allen anderen unabhängig sind.
Physische Isolation
Bei physischer Isolation erhält ein Mandant einen eigenen Cluster: separate Prozesse, separate Maschinen und oft separate Netzwerk-Endpunkte. Nichts, was ein anderer Kunde tut, kann dessen CPU, Arbeitsspeicher oder Verbindungen beeinträchtigen. Das kostet mehr, weil Kapazität reserviert statt gepoolt wird, und die Bereitstellung dauert länger.
Ein weiterer Schritt ist, diesen dedizierten Cluster im eigenen Cloud-Account des Kunden zu platzieren, womit auch das Eigentum an der Infrastruktur selbst hinzukommt. Das ist das Bring-Your-Own-Cloud-Modell, beschrieben unter BYOC MQTT-Broker.
| Isolationsstufe | Mit anderen geteilt | Schützt vor | Typische Wahl für |
|---|---|---|---|
| Nur Topic-Präfix (nicht durchgesetzt) | Alles | Nur versehentlicher Verwechslung | Interne Apps mit einem einzigen Eigentümer |
| Logisch, Broker-Identität pro Mandant | Hardware, Prozesse | Datenlecks, Identitätsmissbrauch, begrenzten Noisy Neighbors | Die meisten SaaS-Kunden, Prototypen |
| Physisch, dedizierter Cluster | Nichts auf Broker-Ebene | Noisy Neighbors vollständig | Große Flotten, strenge SLAs, regulierte Kunden |
| Physisch, im Kunden-Account | Nichts; der Kunde besitzt die Infrastruktur | Anforderungen an Infrastruktureigentum | Richtlinien zu Datenkontrolle und Compliance |
Schutz vor Noisy Neighbors in der Praxis
Noisy Neighbors handeln selten böswillig. Die üblichen Ursachen sind banal:
- Firmware, die sich bei einem Fehler sofort neu verbindet und so einen Connect-Sturm auslöst.
- Ein Testskript, das ohne Verzögerung in einer engen Schleife publiziert.
- Übergroße Payloads wie Bilder, wo kleines JSON erwartet wurde.
- Tausende Subscriptions von einem Client, der sich nie abmeldet.
Wirksamer Schutz greift auf Ebene des Clients und des Mandanten: Obergrenzen für Verbindungen, Nachrichtenrate, Payload-Größe und Subscriptions; Sperren von Adressen nach wiederholt fehlgeschlagenen Logins; und klare Rückmeldung an den Client. In MQTT 5 teilt der Reason Code 0x97 (Quota exceeded) dem Client genau mit, warum ein Publish oder eine Verbindung abgelehnt wurde. Lesen Sie mehr darüber, wie Verbindungsquoten eines MQTT-Brokers das Client-Design beeinflussen.
Identität ist das Fundament
Isolation scheitert am schnellsten auf der Identitätsebene. Befolgen Sie diese Regeln:
- Teilen Sie niemals Zugangsdaten zwischen Mandanten. Jeder Kunde erhält eigene Zugangsdaten, idealerweise auch jedes Gerät.
- Binden Sie Client IDs an Zugangsdaten. In MQTT wirft eine zweite Verbindung mit derselben Client ID die erste hinaus. Sind Client IDs nicht an Identitäten gebunden, könnte ein Mandant einen anderen stören, indem er dessen IDs wiederverwendet.
- Nutzen Sie überall TLS. Über unverschlüsseltes TCP in einem öffentlichen Netz gesendete Zugangsdaten können abgefangen werden. Port 8883 oder 8084 sollte in der Produktion der Standard sein.
- Rotieren Sie Secrets. Planen Sie die Rotation vom ersten Tag an, einschließlich der Frage, wie Geräte neue Zugangsdaten erhalten.
Der Leitfaden zu MQTT-Sicherheit: Best Practices behandelt diese Kontrollen ausführlicher.
Ihre Isolation testen
Gehen Sie nicht davon aus, dass Isolation funktioniert; überprüfen Sie es. Ein minimaler Testplan:
- Verbinden Sie einen Client mit den Zugangsdaten von Mandant A und abonnieren Sie
#. Publizieren Sie als Mandant B. Mandant A darf nichts empfangen. - Versuchen Sie, sich mit der Client ID von Mandant B und den Zugangsdaten von Mandant A zu verbinden. Der Broker muss das ablehnen.
- Publizieren Sie als Mandant B Retained Messages und abonnieren Sie dann als Mandant A denselben Topic-Namen. Es darf keine Retained Message ankommen.
- Überschreiten Sie als Mandant A das Verbindungs- oder Ratenlimit. Prüfen Sie, dass Latenz und Verbindungen von Mandant B unbeeinflusst bleiben.
- Lassen Sie den Login für Mandant A von einer Adresse aus wiederholt fehlschlagen. Prüfen Sie, dass die Sperre für diese Adresse gilt, nicht für Mandant B.
Hier ein kleines Python-Skript mit paho-mqtt 2.x für Test 1. Führen Sie es mit den Daten von Mandant A aus, während ein anderer Client mit denen von Mandant B publiziert.
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) # in diesem Zeitfenster als Mandant B publizieren
client.loop_stop()
print("Isolation OK" if not received else f"Leak: {len(received)} messages")
Auf Ihrem eigenen Broker sehen Sie natürlich den Verkehr Ihres eigenen Mandanten; führen Sie diesen Test daher mit einem Mandanten ohne eigene Publisher aus.
Wie ConnectMQ Mandanten isoliert
ConnectMQ setzt Isolation je nach Plan in unterschiedlicher Stärke um:
- Serverless (Free und Paid). Broker teilen sich einen Cluster mit Multi-Tenant-Isolation. Jeder Broker hat generierte Zugangsdaten, an diese Zugangsdaten gebundene Client IDs und Quoten pro Plan, zum Beispiel bis zu 25 Verbindungen im kostenlosen Plan und bis zu 1.000 im kostenpflichtigen. Flood-Schutz und IP-Sperren nach wiederholt fehlgeschlagenen Logins schützen den geteilten Cluster.
- Dedicated. Ihr Broker läuft auf einem isolierten Cluster, sodass kein anderer Kunde dessen Kapazität teilt.
- BYOC. Der Broker läuft in Ihrem eigenen Cloud-Account und ConnectMQ verwaltet ihn.
- Self Managed Enterprise. Für Organisationen, die die Plattform selbst betreiben.
Der öffentliche MQTT-Broker unter broker.connectmq.com ist bewusst das Gegenteil von isoliert: Sein Demo-Bereich ist für alle lesbar und nur für Experimente gedacht. Nutzen Sie ihn zum Lernen, niemals für Kundendaten. Die Seite zum kostenlosen öffentlichen MQTT-Broker listet seine Limits auf.
Die richtige Stufe wählen
Gehen Sie von dem aus, was Ihre Kunden und Verträge verlangen, nicht von dem, was technisch möglich ist:
- Keine Kundendaten, nur Lernen: der öffentliche MQTT-Broker.
- Ihr eigenes Produkt, ein einziger Eigentümer aller Daten: ein privater Serverless-Broker.
- Viele Kunden mit gewöhnlichen Anforderungen: ein isolierter Broker pro Kunde oder ein gemeinsamer Broker mit strikt durchgesetzter Trennung in Ihrem eigenen Backend.
- Kunden mit Kapazitätsgarantien oder regulatorischen Anforderungen: Dedicated oder BYOC.
Wie SaaS-Produkte diese Optionen kombinieren, lesen Sie unter MQTT für IoT-SaaS.
Starten Sie mit ConnectMQ
Erstellen Sie in wenigen Minuten einen isolierten Broker im kostenlosen Serverless-Plan unter app.connectmq.com, ganz ohne Kreditkarte. Wenn ein Kunde stärkere Garantien braucht, verschieben Sie ihn mit demselben Client-Code auf einen Dedicated-Cluster oder zu BYOC. Der Überblick zum verwalteten MQTT-Broker und der Leitfaden zum Cloud-MQTT-Broker erklären die Pläne genauer.
Häufig gestellte Fragen
Was ist der Unterschied zwischen logischer und physischer MQTT-Isolation?
Logische Isolation trennt Mandanten per Software auf gemeinsam genutzten Maschinen; physische Isolation gibt einem Mandanten einen eigenen Cluster. Physische Isolation beseitigt zudem Noisy-Neighbor-Effekte vollständig.
Kann ein anderer Kunde auf einem geteilten Broker meine Nachrichten lesen?
Nicht, wenn der Anbieter Mandanten korrekt isoliert. Jeder Mandant sollte eigene Zugangsdaten und einen eigenen Topic-Raum haben, was Sie mit einem Wildcard-Subscription-Test überprüfen können.
Was passiert, wenn ein Mandant seine Quote überschreitet?
Der Broker lehnt die zusätzliche Verbindung oder Nachricht ab. MQTT-5-Clients erhalten einen Reason Code wie 0x97, damit sie zurückfahren und die Ursache protokollieren können.
Ist der öffentliche MQTT-Broker isoliert?
Nein. Der öffentliche Bereich von broker.connectmq.com ist für alle lesbar und nur zum Testen gedacht.
