MQTT-Sicherheit: Best Practices als Checkliste mit 12 Punkten für IoT-Teams

MQTT-Sicherheit läuft auf eine Handvoll Gewohnheiten hinaus, die die meisten Teams kennen und unter Termindruck trotzdem auslassen. Dieser Leitfaden macht daraus eine Checkliste mit 12 Punkten, die Sie auf jede Installation anwenden können – mit Code zum Kopieren, um TLS in Python und auf der Kommandozeile zu prüfen. Zu jedem Punkt sagen wir außerdem, was ein verwalteter MQTT-Broker wie ConnectMQ bereits für Sie erledigt und was weiterhin Ihre Aufgabe bleibt.

Warum MQTT-Sicherheit eine eigene Checkliste braucht

MQTT wurde als schlankes Protokoll entworfen. Es definiert im CONNECT ein Feld für Benutzername und Passwort und überlässt alles andere – Verschlüsselung, Autorisierung, Missbrauchsschutz – dem Broker und der Netzwerkschicht. Diese Flexibilität ist ideal für ressourcenarme Geräte, bedeutet aber auch: Eine MQTT-Installation ist genau so sicher wie ihre schwächste Konfigurationsentscheidung.

Die typischen Fehlerbilder sind banal und vermeidbar:

• Geräte, die über das offene Internet unverschlüsseltes TCP auf Port 1883 sprechen.
• Ein einziges gemeinsames Passwort, das fest in die Firmware jedes Geräts eingebrannt ist.
• Topics wie customers/jane.doe@example.com/location, die allein über den Topic-Namen Daten preisgeben.
• Subscriber, die jeder Payload vertrauen und bei fehlerhaften Eingaben abstürzen (oder Schlimmeres).
• Clients, die einen TLS-Fehler „beheben“, indem sie die Zertifikatsprüfung abschalten.

In Industrie-4.0-Projekten kommt der regulatorische Rahmen hinzu: IEC 62443 beschreibt Zonen, Conduits und Sicherheitsstufen für OT-Netze, NIS2 verpflichtet viele Betreiber zu nachweisbarem Risikomanagement, und der EU Cyber Resilience Act stellt Anforderungen an vernetzte Produkte. Die folgende Checkliste ersetzt keine dieser Normen, deckt aber die MQTT-spezifischen Grundlagen ab, auf die sie aufbauen. Vertiefend: IEC 62443 und MQTT und MQTT-Sicherheit in OT-Netzen.

Wenn Sie noch nicht wissen, wie Broker Nachrichten weiterleiten, beginnen Sie mit Was ist ein MQTT-Broker? und kehren Sie dann hierher zurück.

Die Checkliste zur MQTT-Sicherheit im Überblick

Der Rest dieses Artikels geht jeden Punkt einzeln durch.

1. Immer TLS verwenden (Ports 8883 und 8084)

Unverschlüsseltes MQTT auf Port 1883 überträgt Benutzernamen, Passwörter und Payloads im Klartext. Jeder auf dem Übertragungsweg – das WLAN im Café, ein kompromittierter Router, ein gespiegelter Switch-Port – kann sie mitlesen und wiederverwenden. TLS löst das, indem es die Verbindung verschlüsselt und die Identität des Brokers nachweist.

Bei ConnectMQ akzeptiert jeder Broker:

• MQTT über TLS auf mqtts://broker.connectmq.com:8883
• MQTT über Secure WebSocket auf wss://broker.connectmq.com:8084/mqtt

Beide verwenden ein Let's-Encrypt-Zertifikat, dem die Standard-Trust-Stores der Betriebssysteme bereits vertrauen. Betrachten Sie die Ports 1883 und 8083 als reine Entwicklungsports. Browser-Apps müssen ohnehin WSS verwenden; ein vollständiges Beispiel finden Sie in MQTT über WebSocket.

2. Niemals echte Daten auf den öffentlichen MQTT-Broker

broker.connectmq.com dient zugleich als öffentlicher MQTT-Broker mit anonymem Zugang für Tests und Prototypen: Verbinden Sie sich ohne Benutzername und mit einer eindeutigen Client ID, und Sie können sofort veröffentlichen und abonnieren. Das ist großartig zum Lernen – und vollständig öffentlich. Wer das richtige Topic abonniert, kann Ihre Nachrichten lesen. Für Produktionsdaten ist er nicht gedacht.

Regeln für den öffentlichen MQTT-Broker:

• Verwenden Sie ein zufälliges Präfix wie connectmq/demo/<your-random-id>/..., um Kollisionen mit anderen zu vermeiden.
• Veröffentlichen Sie niemals personenbezogene Daten, Zugangsdaten, Standorte oder irgendetwas, das Sie nicht auch in einem Forum posten würden.
• Wechseln Sie zu Zugangsdaten aus dem Portal, bevor echte Nutzer oder echte Geräte beteiligt sind.

Authentifizierte Mandanten sind bei ConnectMQ isoliert: Ihre Topics sind für andere Mandanten und für anonyme Clients des öffentlichen MQTT-Brokers nicht sichtbar, und anonyme Clients sehen nur andere anonyme Clients. Mehr dazu in unserem Leitfaden zum kostenlosen öffentlichen MQTT-Broker.

3. Eindeutige Zugangsdaten pro Broker und Gerät

Ein einziges Passwort für die gesamte Flotte bedeutet: Ein ausgelesenes Firmware-Image kompromittiert jedes Gerät. Streben Sie Zugangsdaten an, die sich widerrufen lassen, ohne den Rest der Flotte anzufassen.

Im ConnectMQ-Portal (https://app.connectmq.com) erhält jeder Broker, den Sie anlegen, einen generierten Benutzernamen, ein Passwort und eine Client ID. Generierte Secrets vermeiden die klassischen schwachen Kandidaten (admin/admin, iot123) und halten Umgebungen getrennt: Legen Sie einen Broker für Staging und einen weiteren für die Produktion an, statt Zugangsdaten zwischen beiden zu teilen.

Unabhängig vom Broker gilt: Rotieren Sie Zugangsdaten, wenn ein Gerät außer Betrieb genommen wird, und fügen Sie Produktions-Secrets niemals in Tickets, Chats oder Screenshots ein.

4. Client IDs einschränken

Die MQTT-Client-ID identifiziert eine Session. Kann sich jeder mit beliebiger Client ID verbinden, kann ein Angreifer, der die ID eines Geräts kennt, dieses offline werfen (der Broker trennt die bestehende Session, sobald sich eine doppelte ID verbindet) oder seine persistente Session kapern.

ConnectMQ beschränkt authentifizierte Verbindungen auf die für den Broker ausgegebene Client ID sowie deren _suffix-Varianten. Lautet Ihre ausgegebene ID YOUR_CLIENT_ID, können Sie YOUR_CLIENT_ID_sensor1, YOUR_CLIENT_ID_dashboard usw. verbinden, aber keine beliebigen IDs. So erhalten Sie vorhersagbare, nachvollziehbare Session-Namen, und Fremde können sich nicht als Ihre Sessions ausgeben.

Praxistipp: Leiten Sie das Suffix von etwas Stabilem auf dem Gerät ab, etwa der Seriennummer oder MAC-Adresse, damit Reconnects dieselbe Session wiederverwenden.

5. Secrets auf Geräten sicher speichern

Zugangsdaten müssen irgendwo auf dem Gerät liegen. Machen Sie diesen Ort so schwer erreichbar, wie es praktikabel ist:

• Committen Sie keine Zugangsdaten in die Versionsverwaltung. Verwenden Sie einen separaten, von Git ignorierten Konfigurations-Header oder eine Umgebungsdatei.
• Nutzen Sie den geschützten Speicher der Plattform, sofern vorhanden (verschlüsselter Flash bzw. NVS-Verschlüsselung beim ESP32, ein TPM oder Secure Element bei Gateways, ein Secrets Manager auf Servern).
• Deaktivieren Sie Debug-Ports und serielle Konsolen in der Produktionsfirmware, damit Secrets nicht ohne Weiteres ausgelesen werden können.
• Planen Sie einen Provisionierungsschritt ein, der gerätespezifische Secrets bei der Fertigung schreibt, statt sie in ein gemeinsames Image zu kompilieren.

6. Topics entwerfen, die keine Informationen preisgeben

Topic-Namen sind Metadaten, und Metadaten verraten etwas. Selbst bei verschlüsselten Payloads verrät ein Topic wie hospital/ward3/patient-4471/heart-rate jedem, der es beobachten kann, eine Menge.

Richtlinien:

• Verwenden Sie undurchsichtige Kennungen (site-07/dev-3fa9/telemetry) statt Namen, E-Mail-Adressen oder Anschriften.
• Halten Sie eine konsistente Hierarchie ein, zum Beispiel site/area/line/device/kind, damit Berechtigungen und Wildcards beherrschbar bleiben. In der Fertigung ist das typischerweise die ISA-95-Hierarchie eines Unified Namespace (UNS), etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur; Werks- und Linienbezeichnungen sind dort unkritisch, Personen- oder Kundendaten gehören trotzdem nicht in den Topic-Namen.
• Vermeiden Sie breite Wildcard-Abonnements wie # in produktiven Consumern; abonnieren Sie nur, was Sie brauchen.
• Halten Sie die Anzahl der Ebenen überschaubar. Der öffentliche MQTT-Broker erlaubt zum Beispiel höchstens 8 Topic-Ebenen.

7. Jede Payload validieren

Der Broker transportiert Bytes; er weiß nicht, ob Ihr JSON wohlgeformt ist oder ob eine Temperatur von 9.000 °C plausibel ist. Jeder Subscriber sollte eingehende Payloads als nicht vertrauenswürdige Eingaben behandeln.

import json

ALLOWED_KEYS = {"temperature", "humidity", "ts"}

def parse_telemetry(raw: bytes):
    if len(raw) > 4096:
        raise ValueError("payload too large")
    data = json.loads(raw.decode("utf-8"))
    if not isinstance(data, dict) or not set(data) <= ALLOWED_KEYS:
        raise ValueError("unexpected fields")
    t = float(data["temperature"])
    if not -40.0 <= t <= 125.0:
        raise ValueError("temperature out of range")
    return data

Ablehnen, protokollieren, weitermachen. Geben Sie Payload-Inhalte niemals direkt an SQL, Shell-Befehle oder HTML weiter. ConnectMQ erzwingt maximale Nachrichtengrößen pro Plan (zum Beispiel 256 KB im kostenlosen Serverless-Plan und 64 KB auf dem öffentlichen MQTT-Broker), was den schlimmsten Fall begrenzt – die Schemavalidierung bleibt aber Ihre Aufgabe.

8. Rate Limits und Quotas anwenden

Eine fehlerhafte Firmware-Schleife, die so schnell wie möglich veröffentlicht, ist ein Denial-of-Service-Angriff, den Sie selbst geschrieben haben. Drosseln Sie auf dem Gerät (bei Änderung oder in festen Intervallen veröffentlichen) und rechnen Sie damit, dass auch der Broker Limits durchsetzt.

ConnectMQ wendet Quotas pro Plan und pro Bereich an. Der öffentliche MQTT-Broker erlaubt zum Beispiel 10 Nachrichten pro Sekunde und 10 Abonnements pro Client. Überschreitet ein Client unter MQTT 5 eine Quota, antwortet der Broker mit dem Reason Code 0x97 Quota exceeded; unter hoher Last kann er mit 0x89 Server busy antworten. Behandeln Sie diese Codes explizit: Backoff, Protokollierung und Alarm statt Wiederholung in einer engen Schleife. Der Leitfaden zu den Funktionen von MQTT 5 erklärt Reason Codes ausführlicher.

9. Schutz vor Brute Force und Verbindungsfluten

Exponierte Broker erleben ständiges Passwortraten und Reconnect-Stürme. Bei ConnectMQ gilt:

• IP-Adressen werden nach wiederholten Anmeldeversuchen mit falschen Zugangsdaten gesperrt.
• Verbindungsfluten lösen temporäre Sperren aus.
• Adaptiver Überlastschutz hält den Cluster auch bei Lastspitzen reaktionsfähig.

Implementieren Sie auf Client-Seite exponentiellen Backoff mit Jitter. Verbindet sich nach einem kurzen Netzwerkaussetzer eine ganze Flotte im selben Moment neu, sehen selbst legitime Geräte wie eine Flut aus.

10. Verbindungsstatus mit $SYS überwachen

Was Sie nicht sehen, können Sie nicht absichern. ConnectMQ veröffentlicht den Verbindungsstatus pro Client unter $SYS/broker/connection/{clientId}/state: 1, wenn sich der Client verbindet, und 0, wenn er sich trennt. Abonnieren Sie diese Topics aus einem Monitoring-Dienst und alarmieren Sie bei unerwarteten Abbrüchen oder wenn sich ein Gerät zu ungewöhnlichen Zeiten verbindet.

mosquitto_sub -h broker.connectmq.com -p 1883 -i monitor-7c2e \
  -t '$SYS/broker/connection/my-device-7c2e/state' -v
# $SYS/broker/connection/my-device-7c2e/state 1
# $SYS/broker/connection/my-device-7c2e/state 0

Kombinieren Sie das mit MQTT-Last-Will-Nachrichten, damit der Rest Ihres Systems von unsauberen Verbindungsabbrüchen erfährt.

11. Zertifikate in jedem Client prüfen

TLS ohne Zertifikatsprüfung ist Verschlüsselung zu einer unbekannten Gegenstelle. Ein Angreifer in der Mitte kann ein beliebiges Zertifikat vorlegen, und der Client schickt ihm bereitwillig seine Zugangsdaten. Leider ist „Verifizierung abschalten“ ein verbreiteter Copy-and-paste-Fix für TLS-Fehler.

Python (paho-mqtt 2.x mit dem ssl-Modul)

import ssl
import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)

ctx = ssl.create_default_context()          # System-CAs, Hostname-Prüfung aktiv
ctx.minimum_version = ssl.TLSVersion.TLSv1_2

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set_context(ctx)
client.on_connect = on_connect
client.connect("broker.connectmq.com", 8883)
client.loop_forever()

Liefern Sie niemals ctx.check_hostname = False, ssl.CERT_NONE oder client.tls_insecure_set(True) aus.

mosquitto_pub und mosquitto_sub

Unter Linux verweisen Sie die CLI auf das CA-Verzeichnis des Systems. Auf jeder Plattform können Sie stattdessen das Zertifikat ISRG Root X1 (isrgrootx1.pem) von Let's Encrypt herunterladen und mit --cafile übergeben:

# Linux: CA-Speicher des Systems
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_cli \
  -t "site-07/#" -v

# Jedes Betriebssystem: explizites Root-Zertifikat
mosquitto_pub -h broker.connectmq.com -p 8883 --cafile isrgrootx1.pem \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID_pub \
  -t "site-07/dev-3fa9/telemetry" -m '{"temperature":22.5}'

Passen Hostname oder Zertifikatskette nicht, schlägt die Verbindung fehl. Genau dieser Fehlschlag ist der Sinn der Sache.

12. Auf Topic-Ebene autorisieren, wo es nötig ist

Als allgemeine MQTT-Praxis gilt das Prinzip der minimalen Rechte auch für Topics: Ein Temperatursensor sollte nur auf sein eigenes Telemetrie-Topic veröffentlichen und nur sein eigenes Befehls-Topic abonnieren. Viele Architekturen setzen das mit Autorisierungsregeln auf Topic-Ebene durch oder indem sie Geräte mit unterschiedlichem Vertrauensniveau hinter getrennte Zugangsdaten und getrennte Broker stellen. Ein Unified Namespace nach ISA-95 erleichtert das: Weil Werk, Bereich und Linie feste Ebenen sind, lassen sich Regeln wie „Gateway der Linie 1 darf nur unter acme/werk-stuttgart/montage/linie-1/# publizieren“ sauber formulieren, passend zum Zonenmodell nach IEC 62443.

Bei ConnectMQ ist die Isolationsgrenze der Mandant: Die Topics eines Mandanten sind für andere Mandanten oder anonyme Clients des öffentlichen MQTT-Brokers niemals sichtbar. Wenn Sie Gerätegruppen strikt voneinander trennen müssen, legen Sie im Portal separate Broker für sie an und behalten Sie Prüfungen auf Anwendungsebene (wer welchen Befehl senden darf) in Ihrem Backend.

Eine sichere Verbindung, Ende-zu-Ende

Zusammengefasst: Ein produktionsreifer ConnectMQ-Client verbindet sich über Port 8883 (oder WSS 8084) mit aktiver Zertifikatsprüfung, authentifiziert sich mit Zugangsdaten aus dem Portal und einer Client ID der Form YOUR_CLIENT_ID_<device>, veröffentlicht mit vernünftiger Rate auf undurchsichtige Topics, setzt bei 0x97 und 0x89 auf Backoff und wird über $SYS überwacht.

Einen Durchgang auf Geräteseite bietet die ESP32-MQTT-Anleitung, die mit einer per TLS abgesicherten Version des Sketches endet.

Starten Sie mit ConnectMQ

ConnectMQ bietet Ihnen TLS- und WSS-Endpunkte, generierte Zugangsdaten, Client-ID-Beschränkungen, Mandantenisolation und Missbrauchsschutz ab Werk, sodass sich Ihr Team auf die Teile der MQTT-Sicherheit konzentrieren kann, für die nur Sie selbst verantwortlich sein können. Legen Sie im kostenlosen Serverless-Plan unter https://app.connectmq.com einen Broker an – ohne Kreditkarte – und verbinden Sie Ihren ersten sicheren Client in wenigen Minuten.

Häufig gestellte Fragen

Ist MQTT standardmäßig sicher?

Nein. Das MQTT-Protokoll definiert Felder für die Authentifizierung, überlässt Verschlüsselung und Autorisierung aber dem Broker und der Transportschicht. Für echte Sicherheit brauchen Sie TLS, starke Zugangsdaten pro Gerät und sinnvolle Broker-Limits.

Welchen Port sollte ich für sicheres MQTT verwenden?

Verwenden Sie 8883 für MQTT über TLS und 8084 für MQTT über Secure WebSocket (WSS). Bei ConnectMQ nutzen beide ein öffentlich vertrauenswürdiges Let's-Encrypt-Zertifikat.

Kann ich den öffentlichen MQTT-Broker broker.connectmq.com in der Produktion nutzen?

Nein. Der öffentliche MQTT-Broker ist für Tests gedacht, anonym und für jeden lesbar, der Ihre Topics abonniert. Verwenden Sie für echte Daten Zugangsdaten aus dem ConnectMQ-Portal; authentifizierte Mandanten sind vom anonymen öffentlichen Zugang und voneinander isoliert.

Was bedeutet der Reason Code 0x97?

0x97 ist der MQTT-5-Reason-Code für „Quota exceeded“. ConnectMQ gibt ihn zurück, wenn ein Client ein Plan- oder Bereichslimit überschreitet; Ihr Client sollte dann einen Backoff einlegen, statt es sofort erneut zu versuchen.

Darf ich die Zertifikatsprüfung zum Testen abschalten?

Nur auf einer Wegwerf-Entwicklungsmaschine und niemals in ausgelieferter Firmware oder produktivem Code. Wer die Prüfung abschaltet, verliert den Schutz vor Man-in-the-Middle-Angriffen – und genau der ist der Hauptgrund für TLS.