MQTT-Sicherheit: Best Practices als praktische Checkliste

MQTT wurde für eingeschränkte Netzwerke entwickelt, nicht für feindliche. Viele Broker akzeptieren im Auslieferungszustand anonyme Clients auf Port 1883 und übertragen alles im Klartext. Das ist kein Fehler im Protokoll – MQTT bringt alle nötigen Mechanismen mit –, aber Sicherheit musst du selbst einschalten. Dieser Guide geht jede Schicht durch und endet mit einer Checkliste, die du für Reviews verwenden kannst.

Wovor du dich schützt

• Abhören – Mitlesen von Zugangsdaten und Payloads im Netzwerk.
• Identitätsdiebstahl – ein fremder Client verbindet sich als eines deiner Geräte oder Services.
• Unbefugtes Publishen – jemand sendet unlock an home/door/cmd.
• Datenabfluss – ein Client abonniert # und liest alles mit.
• Denial of Service – Fluten von Verbindungen oder Nachrichten legen den Broker lahm.

1. Alles mit TLS verschlüsseln

TLS schützt Zugangsdaten und Payloads auf dem Transportweg und lässt Clients prüfen, dass sie wirklich mit dem richtigen Broker sprechen. Nutze Port 8883 für MQTT über TLS und wss:// für Browser; deaktiviere den unverschlüsselten Listener auf 1883 oder schirme ihn per Firewall ab, sobald er außerhalb eines vertrauenswürdigen lokalen Netzes erreichbar wäre. Details findest du unter MQTT-Ports erklärt und MQTT über WebSockets.

• Verlange TLS 1.2 oder neuer.
• Prüfe auf Clients immer das Serverzertifikat. Optionen wie --insecure, setInsecure() oder rejectUnauthorized: false sind nur fürs lokale Debugging gedacht.
• Plane die Zertifikatserneuerung – ein abgelaufenes Zertifikat nimmt alle Geräte gleichzeitig offline.

mosquitto_sub -h broker.example.com -p 8883 --cafile ca.crt \
  -u sensor-01 -P 'secret' -t 'devices/sensor-01/#' -v

2. Jeden Client authentifizieren

Schalte den anonymen Zugriff ab. Wähle dann für jede Art von Client eine passende Authentifizierungsmethode:

Verwende nie einen gemeinsamen Login für eine ganze Flotte: Wird ein einzelnes Gerät kompromittiert, willst du genau eine Zugangskennung widerrufen und nicht jedes Gerät neu flashen. Speichere Passwörter auf dem Broker gehasht – wenn du Mosquitto nutzt, hilft dir der Guide zur Mosquitto-Authentifizierung, und der mosquitto.conf-Generator erstellt eine sichere Konfiguration mit TLS und Passwortdateien.

3. Topics mit ACLs autorisieren

Authentifizierung beantwortet wer bist du; Autorisierung beantwortet was darfst du. Ohne ACLs kann jeder authentifizierte Client jedes Topic lesen und beschreiben. Wende das Least-Privilege-Prinzip an: Jeder Client bekommt nur Lese- oder Schreibrechte auf die Topics, die er wirklich braucht.

# backend service: read all telemetry, send commands
user backend
topic read devices/+/telemetry
topic write devices/+/cmd

# every device: only its own topics (%u = username)
pattern write devices/%u/telemetry
pattern read devices/%u/cmd

Pattern-Regeln, die Benutzername oder Client-ID einsetzen, skalieren deutlich besser als eine Regel pro Gerät. Prüfe deine Filter mit dem Topic-Matcher; MQTT-Wildcards behandelt der Artikel Topics und Wildcards.

4. Client-IDs kontrollieren

Ein Client, der sich mit einer bereits verwendeten Client-ID verbindet, wirft die ursprüngliche Verbindung vom Broker. Ein Angreifer, der deine IDs kennt, kann so Geräte trennen, und ein versehentliches Duplikat erzeugt endlose Reconnect-Schleifen. Binde Client-IDs an Zugangsdaten, wo dein Broker das erlaubt (zum Beispiel muss die Client-ID dem Benutzernamen oder dem Common Name des Zertifikats entsprechen), und vermeide vorhersagbare IDs auf geteilten Brokern. Der Client-ID-Generator hilft dir, eindeutige IDs zu erzeugen.

5. Topics mit Blick auf Sicherheit entwerfen

• Platziere die Geräte- oder Mandanten-ID an einer festen Position, damit ACL-Patterns sie treffen können.
• Trenne Telemetrie (Gerät schreibt) und Befehle (Gerät liest) in unterschiedliche Teilbäume.
• Halte Geheimnisse und personenbezogene Daten aus Topic-Namen heraus – Topics tauchen in Logs und Monitoring-Tools auf.
• Vorsicht mit Retained Messages auf Befehls-Topics: Ein gespeichertes unlock wird beim Reconnect erneut ausgelöst.

6. Sensible Payloads verschlüsseln oder signieren

TLS schützt jede Teilstrecke, aber der Broker sieht die Payloads im Klartext. Wenn der Broker-Betreiber oder andere Services darauf die Daten nicht lesen sollen, verschlüssele Payloads Ende-zu-Ende (zum Beispiel AES-GCM mit Schlüsseln, die außerhalb von MQTT verwaltet werden), oder signiere zumindest Befehle, damit Geräte gefälschte ablehnen können. Validiere jede eingehende Payload auf dem Gerät: Größenlimits durchsetzen, Typen prüfen und unbekannte Befehle ignorieren.

7. Limits und Rate Limits setzen

Begrenze die maximale Paketgröße, Inflight- und Queued-Nachrichten pro Client, die Verbindungsrate und die Anzahl der Subscriptions. Mit MQTT 5 kann der Broker Clients Limits wie Maximum Packet Size und Receive Maximum mitteilen. Rate Limits verhindern, dass ein fehlerhaftes Gerät in einer Publish-Schleife alle anderen mitreißt – mit dem Paketgrößen-Rechner legst du realistische Größenobergrenzen fest.

8. Zugangsdaten auf Geräten und in Apps schützen

Gerätezugangsdaten landen im Flash-Speicher, Browser-Zugangsdaten in JavaScript-Bundles, die jeder lesen kann. Geh davon aus, dass sie extrahiert werden können: Gib jedem Client die engste mögliche ACL, provisioniere Zugangsdaten pro Gerät bei der Fertigung oder beim ersten Start, statt ein einziges Geheimnis in die Firmware einzubrennen, und nutze Flash-Verschlüsselung oder ein Secure Element, wo die Hardware das unterstützt. Für Web- und Mobile-Apps stellst du kurzlebige Zugangsdaten aus deinem Backend aus, statt ein langlebiges Passwort mitzuliefern.

9. Überwachen und protokollieren

• Logge Connects, Disconnects und fehlgeschlagene Authentifizierungen und alarmiere bei Spitzen.
• Achte auf Clients, die unerwartet # oder $SYS/# abonnieren.
• Verfolge Verbindungszahlen und Nachrichtenraten pro Client, um kompromittierte oder fehlerhafte Geräte zu erkennen.
• Halte Broker und Client-Bibliotheken auf dem aktuellen Patch-Stand.

MQTT-Sicherheits-Checkliste

Wenn sich ein abgesicherter Client nicht verbinden kann, verrät dir der CONNACK-Reason-Code, ob es an den Zugangsdaten oder an der Autorisierung lag – schlag ihn in der Referenz der MQTT-Reason-Codes nach.

Häufig gestellte Fragen