Anforderungen an einen Enterprise MQTT Broker: ein praxisnaher Bewertungsleitfaden

Ein Enterprise MQTT Broker muss mehr als nur Entwickler zufriedenstellen: Sicherheitsarchitekten, Compliance-Verantwortliche, Betriebsteams und der Einkauf reden alle mit. Dieser Leitfaden macht aus ihren typischen Erwartungen eine konkrete Anforderungs-Checkliste, erklärt, welche Bereitstellungsmodelle welche Bedenken ausräumen, und zeigt, wie die ConnectMQ-Optionen Dedicated, BYOC und Self Managed Enterprise darauf abgebildet werden, damit Sie eine fokussierte statt einer ausufernden Evaluierung durchführen.

Warum Unternehmensanforderungen anders sind

Ein Startup fragt: „Funktioniert es, und ist es günstig?“ Ein Unternehmen fragt: „Wohin gehen unsere Daten, wer kann darauf zugreifen, was passiert bei einem Ausfall, und wie beweisen wir das alles gegenüber einem Auditor?“ Das Protokoll ist dasselbe MQTT 3.1.1 oder 5.0, das jeder Broker spricht, doch die Fragen rundherum bestimmen die Entscheidung.

Industrielles und betriebliches IoT in Unternehmen ist zudem meist heterogen: SPS-Gateways und OPC-UA-Server in Werken, MES- und ERP-Anbindungen, Gebäudesysteme, Feldgeräte, mobile Apps und Cloud-Analytics, oft im Besitz verschiedener Teams. Der Broker wird zur gemeinsam genutzten Infrastruktur, was die Messlatte für Isolation, Governance und betriebliche Reife anhebt. Die Protokollgrundlagen dahinter finden Sie unter was ein MQTT Broker macht.

Die Anforderungsbereiche

1. Isolation und Mandantenfähigkeit

Kann die Last eines anderen Kunden Ihre beeinflussen? Gemeinsam genutzte, mandantenfähige Stufen isolieren logisch über Zugangsdaten, Namensräume und Kontingente, was für viele Einsatzzwecke ausreicht. Unternehmen mit strengen Richtlinien wünschen meist physische Isolation oder Isolation auf Kontoebene: einen dedizierten Cluster oder einen Broker im eigenen Cloud-Konto.

2. Kontrolle über die Bereitstellung und Datenstandort

Wo läuft der Broker, und wem gehört die Infrastruktur? Die Optionen reichen vom Hosting beim Anbieter über Bring Your Own Cloud bis zum vollständigen Eigenbetrieb. Meist entscheiden Vorgaben zur Datenresidenz (im DACH-Raum oft mit Blick auf die DSGVO), die Netzwerkarchitektur (private Anbindung an Werke oder VPCs) und interne Cloud-Richtlinien.

3. Identität, Authentifizierung und Zugriff

Typische Fragen: Sind Zugangsdaten pro Client eindeutig, lassen sich gestohlene Zugangsdaten einzeln sperren, sind Client IDs an Identitäten gebunden, und werden Brute-Force-Angriffe blockiert? Unternehmen fragen auch nach der Anbindung an die Unternehmensidentität für menschliche Nutzer der Verwaltungskonsole. Unterscheiden Sie in Ihrer Evaluierung genau zwischen dem, was heute verfügbar ist, und dem, was auf einer Roadmap steht, und behandeln Sie Single Sign-on und feingranulare Topic-Autorisierung als ausdrückliche Prüfpunkte, statt sie vorauszusetzen.

4. Transportsicherheit

TLS auf jeder externen Verbindung, moderne Cipher Suites, öffentlich vertrauenswürdige Zertifikate oder eine verwaltete private CA sowie Secure WebSocket für Browser-Clients. Unser Leitfaden zu Best Practices für MQTT-Sicherheit beschreibt auch, was Sie auf Geräteseite verlangen sollten. In Industrie-4.0-Projekten werden diese Punkte zunehmend an Normen und Regulierung gemessen: an IEC 62443 für die OT-Sicherheit, an NIS2 für wichtige und besonders wichtige Einrichtungen und künftig am EU Cyber Resilience Act für Produkte mit digitalen Elementen. Wie sich MQTT in Zonen und Conduits nach IEC 62443 einfügt, zeigt der Beitrag zu IEC 62443 und MQTT.

5. Betrieb und Observability

Wer hat Rufbereitschaft, wie wird der Broker überwacht, wie werden Upgrades ausgerollt, und welchen Einblick erhalten Sie in Verbindungen, Datenverkehr und Fehler? Hier zählen ein Verwaltungsportal, Topics zum Verbindungsstatus und Alarmierung.

6. Skalierbarkeit und Ausfallsicherheit

Erwartete Anzahl an Verbindungen, Nachrichtenraten, Verhalten bei Lastspitzen während Reconnect-Stürmen und das Wiederherstellungskonzept beim Neustart eines Knotens. Stellen Sie konkrete Fragen zur Architektur, statt Schlagzeilen-Zahlen zu akzeptieren.

7. Support und Vertragsbedingungen

Reaktionszeiten, Eskalationswege, benannte Ansprechpartner und vertragliche Zusagen. Fordern Sie diese im Beschaffungsprozess schriftlich an und verlassen Sie sich nicht auf Marketingseiten.

8. Passung für Industrie und Datenmodell

In der Fertigung spart die Unterstützung für ISA-95-Topic-Hierarchien, einen Unified Namespace (UNS) und Sparkplug-B-Payloads erheblichen Integrationsaufwand. Der UNS ist dabei das Leitkonzept: Der Broker wird zur zentralen, ereignisgesteuerten Datendrehscheibe, an der SPS, SCADA, MES und ERP veröffentlichen und abonnieren, statt über Punkt-zu-Punkt-Schnittstellen zu kommunizieren. Die Anlagenhierarchie nach ISA-95 (IEC 62264) – Enterprise, Site, Area, Line, Cell – liefert die Topic-Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Prüfen Sie in der Evaluierung, ob der Broker solche Hierarchien erkennt, Sparkplug-B-Daten in den UNS überführen kann und Ihre Betriebsteams Geräte entlang dieser Ebenen sehen. Hintergründe liefert der Beitrag zu ISA-95-MQTT-Topics.

Bereitstellungsmodelle und Anforderungen im Abgleich

ConnectMQ bietet alle vier an. Dedicated stellt Ihnen einen isolierten Cluster bereit, der für Sie betrieben wird. BYOC stellt den Broker in Ihrem Cloud-Konto bereit, wobei er weiterhin für Sie verwaltet wird, und erfüllt damit die Anforderung „unsere Daten bleiben in unserem Konto“, ohne Ihr Team zu Broker-Betreibern zu machen. Self Managed Enterprise richtet sich an Organisationen, die alles selbst betreiben müssen. Der Leitfaden zum dedizierten MQTT Broker behandelt die Kapazitätsplanung für isolierte Cluster.

Funktionen, die Sie überprüfen können

Bei Unternehmensevaluierungen schlägt Klarheit Begeisterung. Diese Funktionen können Sie überprüfen:

• MQTT 3.1.1 und 5.0 über TCP 1883, TLS 8883, WebSocket 8083 und Secure WebSocket 8084 (Pfad /mqtt), mit Let's-Encrypt-Zertifikaten.
• Mandantenisolation mit Kontingenten pro Plan, Flood-Schutz, IP-Sperren nach wiederholten fehlgeschlagenen Anmeldungen und an die ausgegebenen Zugangsdaten gebundenen Client IDs.
• MQTT-5-Funktionen: Shared Subscriptions, Retained Messages, Session Expiry, Topic Alias, Message Expiry, Response Topic und Reason Codes wie 0x97 (Quota exceeded).
• Verbindungsstatus über $SYS/broker/connection/{clientId}/state.
• Portal-Werkzeuge: Client im Browser, Live-Topic-Explorer, Dashboard, Geräteansicht nach ISA-95-Ebenen, Schwellenwert-Alarmregeln und Alarmprotokoll, auf Türkisch und Englisch.
• Industrielle Funktionen: Erkennung von ISA-95- und Unified-Namespace-Topics, Dekodierung von Sparkplug B (Protobuf und JSON) und erneutes Publizieren von Sparkplug B in ISA-95-Topics, zum Beispiel spBv1.0/factory1/DDATA/line1/cnc1 nach connectmq/factory1/production/line1/cnc1/telemetry. Siehe Sparkplug B und der Unified Namespace.

Ebenso wichtig ist, womit Sie planen müssen. ConnectMQ ist ein Broker, keine Integrationsplattform: Es gibt keine integrierte Rule Engine, kein Webhook-System und keine Bridge zu Datenbanken oder Kafka. Unternehmen integrieren, indem sie eigene MQTT-Clients betreiben, etwa Node-RED, Telegraf oder einen kleinen Service, die abonnieren und in ihren Historian, Data Lake oder ihre Streaming-Plattform schreiben. Viele Architekten bevorzugen das, weil die Integrationsschicht unter ihrer Kontrolle bleibt. Fragen Sie ebenso direkt nach Clustering, Replikation, Autorisierung pro Topic und vertraglicher Verfügbarkeit für Ihre konkrete Bereitstellung, statt diese vorauszusetzen.

Integrationsmuster: ein Subscriber in Ihrer Hand

Ein typisches Muster in Unternehmen ist eine Konsumentengruppe über Shared Subscriptions, die in ein internes System schreibt. Betreiben Sie mehrere Instanzen dieses Services, wird die Last automatisch aufgeteilt (Shared Subscriptions erfordern einen Plan, der sie unterstützt).

import json
import ssl

import paho.mqtt.client as mqtt

GROUP_TOPIC = "$share/historian/connectmq/+/production/+/+/telemetry"


def write_to_historian(topic: str, payload: dict) -> None:
    # Durch Ihren Datenbank- oder Stream-Client ersetzen.
    print(topic, payload)


def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("Connect failed:", reason_code)
        return
    client.subscribe(GROUP_TOPIC, qos=1)


def on_message(client, userdata, msg):
    try:
        write_to_historian(msg.topic, json.loads(msg.payload))
    except (ValueError, UnicodeDecodeError):
        print("Skipping non-JSON payload on", 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.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Ersetzen Sie im Produktivbetrieb den Hostnamen durch Ihren Dedicated- oder BYOC-Endpunkt.

Eine Checkliste für die Unternehmensevaluierung

Nutzen Sie sie als Gerüst für Ihre Ausschreibung oder Ihren Proof-of-Concept-Plan:

1. Dokumentieren Sie das Bereitstellungsmodell, das Ihre Richtlinien verlangen: gemeinsam, dediziert, BYOC oder selbst verwaltet.
2. Listen Sie Vorgaben zu Datenstandort und Netzwerk auf, einschließlich Bedarf an privater Anbindung.
3. Bestätigen Sie Protokollversionen und Ports, einschließlich WebSocket für Browser-Apps.
4. Prüfen Sie Zugangsdaten pro Client, Sperrung und Brute-Force-Schutz.
5. Spezifizieren Sie den Bedarf an Autorisierung auf Topic-Ebene und klären Sie, wie er erfüllt wird.
6. Legen Sie erwartete Spitzenverbindungen, Nachrichtenraten und Payload-Größen fest.
7. Testen Sie im Proof of Concept einen Reconnect-Sturm.
8. Bestätigen Sie die Sichtbarkeit im Monitoring: Verbindungsstatus, Datenverkehr, Alarme.
9. Identifizieren Sie Integrationsziele und klären Sie, wer die Subscriber-Schicht baut und betreibt.
10. Vereinbaren Sie Supportbedingungen, Eskalationskontakte und Zusagen schriftlich.
11. Validieren Sie industrielle Anforderungen: ISA-95-Hierarchie, UNS, Sparkplug B.
12. Planen Sie die Migration vom Pilot in die Produktion, einschließlich Rotation der Zugangsdaten.

Den breiteren Kontext der Hosting-Entscheidungen hinter dieser Checkliste finden Sie im Leitfaden zum Cloud-MQTT-Broker und in unserem Leitfaden zum Modell des verwalteten MQTT-Brokers.

Evaluieren Sie ConnectMQ für Ihr Unternehmen

Am schnellsten beginnt eine Evaluierung praktisch. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless Broker (ohne Kreditkarte) und verbinden Sie ein Gateway, einen Subscriber und die Portal-Werkzeuge. Sprechen Sie dann mit ConnectMQ über Dedicated, BYOC oder Self Managed Enterprise für die Produktion, mit Ihrer Anforderungs-Checkliste in der Hand.

Häufig gestellte Fragen

Was macht einen MQTT Broker unternehmenstauglich?

Isolation, die Ihren Richtlinien entspricht, Kontrolle darüber, wo er läuft, starke Authentifizierung und TLS, betriebliche Transparenz und verlässliche Supportbedingungen. Das Protokoll selbst ist dasselbe wie bei jedem Standard-Broker.

Was ist der Unterschied zwischen Dedicated und BYOC?

Dedicated betreibt einen isolierten Cluster in der Infrastruktur des Anbieters. BYOC betreibt den Broker in Ihrem eigenen Cloud-Konto, während der Anbieter ihn weiterhin verwaltet.

Gibt es eine integrierte Rule Engine oder einen Datenbank-Connector?

Nein. Integrationen bauen Sie mit eigenen MQTT-Clients wie Node-RED, Telegraf oder individuellen Services, die abonnieren und in Ihre Systeme schreiben.

Kann ConnectMQ Sparkplug B von Industrie-Gateways verarbeiten?

Ja. Es dekodiert Sparkplug B in Protobuf oder JSON und kann es in ISA-95-strukturierte Topics für einen Unified Namespace (UNS) erneut publizieren, sodass Sparkplug-Gateways und andere Clients dieselbe Anlagenhierarchie nutzen.