Ist MQTT sicher? Das Protokoll selbst liefert nur die Ansatzpunkte für Sicherheit, ein Feld für Benutzername und Passwort und die Möglichkeit, über TLS zu laufen, und es ist genau so sicher wie das Deployment drumherum. Dieser Artikel erklärt, was MQTT schützt und was nicht, welche Bedrohungen reale Systeme tatsächlich treffen, welche Mythen Probleme verursachen und welche Schichten ein MQTT-Setup sicher machen.
Was MQTT selbst mitbringt
MQTT wurde als leichtgewichtiges Messaging-Protokoll entworfen, und die Spezifikation überlässt den Großteil der Sicherheit bewusst anderen Schichten. Von Haus aus erhalten Sie:
- Ein Feld für Benutzername und Passwort im CONNECT-Paket, übertragen als einfache Bytes.
- Ansatzpunkte für MQTT 5 Enhanced Authentication (eine Authentifizierungsmethode und AUTH-Pakete) für Challenge-Response-Verfahren, die der Broker implementiert.
- Reason Codes, mit denen der Broker „falsche Zugangsdaten" oder „nicht autorisiert" melden kann.
- Transportunabhängigkeit, sodass MQTT über TLS oder sichere WebSockets laufen kann.
Was das Protokoll allein nicht bietet:
- Keine Verschlüsselung. Ohne TLS sind alle Topics, Payloads und Passwörter auf der Leitung lesbar.
- Kein Autorisierungsmodell. Welcher Client welches Topic nutzen darf, entscheidet der Broker.
- Keine Integrität oder Signatur der Payload. Eine Nachricht trägt keinen Nachweis darüber, wer sie erstellt hat, außer der Verbindung, über die sie ankam.
- Kein Rate Limiting und kein Missbrauchsschutz. Das ist eine Funktion des Brokers.
Die OASIS-MQTT-Spezifikation enthält sogar ein Sicherheitskapitel, das diese Punkte als Verantwortung der Implementierung beschreibt. Die ehrliche Antwort auf „Ist MQTT sicher?" lautet also: MQTT lässt sich absichern, und Sicherheit ist eine Eigenschaft des Brokers, der Clients und des Netzwerkdesigns.
Die Bedrohungen, die wirklich zählen
| Bedrohung | Wie sie entsteht | Wichtigster Schutz |
|---|---|---|
| Abhören | Traffic auf Port 1883 wird im WLAN, beim Provider oder im Cloud-Netz mitgeschnitten | TLS auf 8883 / 8084 |
| Diebstahl von Zugangsdaten bei der Übertragung | Passwort wird aus einem unverschlüsselten CONNECT gelesen | TLS mit Zertifikatsprüfung |
| Offene Broker | Broker mit anonymem Zugang aus dem Internet erreichbar | Authentifizierung, kein anonymer Zugriff in Produktion |
| Auslesen von Zugangsdaten aus Geräten | Passwort fest in der Firmware oder unverschlüsselt im Flash | Zugangsdaten pro Gerät, verschlüsselter Speicher |
| Identitätsdiebstahl | Angreifer verbindet sich mit einer gestohlenen oder geteilten Client ID | An Zugangsdaten gebundene Client IDs |
| Mandantenübergreifender Zugriff | Schwache Isolation auf einem gemeinsam genutzten Broker | Mandantenisolation |
| Bösartige Befehle | Jeder kann auf ein Befehls-Topic publizieren | Autorisierung, Befehlsvalidierung auf dem Gerät |
| Denial of Service | Verbindungsfluten, Nachrichtenfluten, Brute-Force-Logins | Quotas, Flood Protection, IP-Sperre |
Scans nach offen erreichbaren Brokern finden regelmäßig Systeme auf Port 1883 mit anonymem Zugang, die Sensordaten preisgeben und teilweise Befehle annehmen. Das sind Konfigurationsfehler, keine Schwachstellen im Protokoll, weshalb der größte Teil der eigentlichen Arbeit im Betrieb liegt. Unter offen erreichbare MQTT-Broker lesen Sie, wie solche Broker gefunden und geschlossen werden.
Verbreitete Mythen zur MQTT-Sicherheit
„MQTT ist unsicher, weil es Passwörter im Klartext sendet."
Es sendet sie innerhalb der MQTT-Schicht im Klartext, genau wie HTTP Basic Authentication. Über TLS ist die gesamte Verbindung verschlüsselt, einschließlich des CONNECT-Pakets. Das Problem ist MQTT ohne TLS, nicht MQTT selbst.
„Port 1883 ist in unserem Netzwerk in Ordnung."
Interne Netze werden kompromittiert, WLAN wird mitgeschnitten, und „vorübergehende" Portweiterleitungen werden dauerhaft. Behandeln Sie jedes Netz als nicht vertrauenswürdig und nutzen Sie TLS, wo immer möglich. Reservieren Sie unverschlüsseltes 1883 für öffentliche Testdaten, die Sie überall sehen könnten, wie den Demo-Traffic auf dem kostenlosen öffentlichen MQTT-Broker.
„Eine lange, zufällige Client ID ist ein Geheimnis."
Client IDs tauchen in Logs, Dashboards und Topic-Pfaden auf. Sie identifizieren einen Client, sie authentifizieren ihn nicht. Sicherheit entsteht durch die Zugangsdaten, an die die Client ID gebunden ist.
„TLS macht Payloads Ende-zu-Ende sicher."
TLS schützt jede Teilstrecke zwischen einem Client und dem Broker. Der Broker sieht die Payload im Klartext. Wenn Sie Ende-zu-Ende-Vertraulichkeit vom Gerät bis zur Anwendung brauchen, ergänzen Sie MQTT-Payload-Verschlüsselung.
„Niemand würde sich die Mühe machen, meine Sensoren anzugreifen."
Automatisierten Scannern ist egal, was Ihre Sensoren messen. Sie suchen nach offenen Ports und Standard-Zugangsdaten, und ein offen erreichbarer Broker kann als Brückenkopf oder als kostenloses Relay missbraucht werden.
Die Schichten, die MQTT sicher machen
- Transportverschlüsselung. TLS 1.2 oder neuer auf Port 8883 oder sichere WebSockets auf 8084 für Browser, mit aktivierter Zertifikatsprüfung in jedem Client.
- Authentifizierung. Kein anonymer Zugriff auf Produktionsdaten. Eindeutige Zugangsdaten pro Gerät und Dienst.
- Identitätsbindung. Client IDs sind an Zugangsdaten gebunden, sodass sich ein Client nicht als ein anderer ausgeben kann.
- Isolation und Autorisierung. Getrennte Mandanten und Umgebungen; Topics einschränken, wo Ihr Broker das unterstützt, und Topic-Bäume so entwerfen, dass Identität und Richtung sichtbar sind. Der Leitfaden zur MQTT ACL behandelt beide Ansätze.
- Missbrauchsschutz. Verbindungs- und Nachrichten-Quotas, Flood Protection und das Sperren von Brute-Force-Loginversuchen.
- Gerätehärtung. Verschlüsselte Speicherung von Zugangsdaten, Secure Boot, deaktivierte Debug-Schnittstellen, signierte Firmware-Updates.
- Betrieb. Rotation von Zugangsdaten, Überwachung von Verbindungsstatus und Anomalien sowie ein Plan zum Widerruf eines kompromittierten Geräts.
In der Industrie ordnen sich diese Schichten in bekannte Rahmenwerke ein: IEC 62443 beschreibt Zonen, Conduits und Sicherheitsstufen für OT-Netze, und europäische Vorgaben wie NIS2 und der EU Cyber Resilience Act erhöhen die Anforderungen an Betreiber und Hersteller vernetzter Produkte. Wie MQTT in diese Struktur passt, zeigen IEC 62443 und MQTT und unser Beitrag zum EU Cyber Resilience Act.
Wie ein verwalteter MQTT-Broker die Lücken schließt
Mehrere dieser Schichten liegen auf Broker-Seite, und genau dort machen selbst betriebene Deployments am häufigsten Fehler: Zertifikate laufen ab, anonymer Zugriff bleibt nach einem Test aktiv, eine Passwortdatei wird von allen Geräten geteilt. Ein verwalteter MQTT-Broker übernimmt diese Aufgaben.
So bildet ConnectMQ die oben genannten Schichten ab:
| Schicht | ConnectMQ |
|---|---|
| Transportverschlüsselung | TLS auf 8883 und sicherer WebSocket auf 8084 (Pfad /mqtt) mit Let's-Encrypt-Zertifikat |
| Authentifizierung | Generierter Benutzername und Passwort pro Satz von Broker-Zugangsdaten |
| Identitätsbindung | Client IDs an ausgestellte Zugangsdaten gebunden |
| Isolation | Mandantenisolation zwischen Kunden; Dedicated-Plan für einen isolierten Cluster; BYOC in Ihrem eigenen Cloud-Konto |
| Missbrauchsschutz | Quotas pro Plan, Flood Protection, IP-Sperre nach wiederholten fehlgeschlagenen Logins |
| Transparenz | Dashboard, Live-Topic-Explorer und $SYS/broker/connection/{clientId}/state für den Verbindungsstatus pro Client |
ConnectMQ erzwingt keine ACLs pro Topic, die Sicherheitsgrenze sind daher Mandant und Broker: Wenn zwei Gruppen von Clients die Daten der jeweils anderen nicht sehen dürfen, geben Sie ihnen getrennte Broker, und halten Sie nicht vertrauenswürdige Nutzer hinter Ihrem eigenen Backend, statt ihnen Broker-Zugangsdaten auszuhändigen. Gerätehärtung und Rotation von Zugangsdaten bleiben Ihre Verantwortung, wie bei jedem Broker; die Leitfäden MQTT-Zugangsdaten auf Geräten schützen und Best Practices für MQTT-Sicherheit behandeln diese Themen.
Schneller Selbsttest
Beantworten Sie diese Fragen zu Ihrem aktuellen Deployment:
- Verbindet sich irgendein Produktions-Client über Port 1883?
- Deaktiviert irgendein Client die Zertifikatsprüfung?
- Teilen sich zwei oder mehr Geräte dieselben Zugangsdaten?
- Sind Zugangsdaten fest in einem Firmware-Image oder einem öffentlichen Repository hinterlegt?
- Können Sie ein einzelnes Gerät innerhalb von Minuten widerrufen, ohne andere zu beeinträchtigen?
- Würden Sie bemerken, wenn ein Gerät sich plötzlich von einem unerwarteten Ort verbindet oder mit der zehnfachen normalen Rate publiziert?
Ein „Ja" bei einer der ersten vier Fragen oder ein „Nein" bei einer der letzten beiden zeigt, wo Sie anfangen sollten.
Starten Sie mit ConnectMQ
Erhalten Sie TLS, Authentifizierung, Identitätsbindung, Mandantenisolation und Missbrauchsschutz vom ersten Tag an mit einem Cloud-MQTT-Broker, der für Sie verwaltet wird. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und verbinden Sie Ihr erstes Gerät in wenigen Minuten über Port 8883.
Häufig gestellte Fragen
Ist MQTT ohne TLS sicher?
Nein. Ohne TLS kann jeder, der den Traffic mitschneiden kann, Benutzernamen, Passwörter, Topics und Payloads lesen. Verwenden Sie Port 8883 oder sichere WebSockets für alles, was über öffentliche Testdaten hinausgeht.
Ist MQTT sicherer oder unsicherer als HTTP?
Beide sind vergleichbar. Beide setzen für die Verschlüsselung auf TLS und für Authentifizierung und Autorisierung auf den Server; keines von beiden ist im Klartext sicher.
Verbessert MQTT 5 die Sicherheit?
MQTT 5 ergänzt Enhanced Authentication, Re-Authentifizierung und aussagekräftigere Reason Codes, wodurch sich sichere Designs leichter bauen und debuggen lassen. Verschlüsselung bringt es selbst nicht mit.
Ist ein öffentlicher MQTT-Broker sicher?
Zum Lernen, für Tests und Prototypen mit nicht sensiblen Daten ja. Ein öffentlicher MQTT-Broker ist für alle lesbar, Produktionsdaten gehören daher auf einen privaten Broker mit Zugangsdaten und TLS.
