MQTT-Zugangsdaten ohne Ausfallzeit rotieren

Um MQTT-Zugangsdaten ohne Ausfallzeit zu rotieren, brauchen Sie zwei gleichzeitig gültige Sätze von Zugangsdaten, Geräte, die von den neuen auf die alten zurückfallen können, und einen Prüfschritt, bevor irgendetwas widerrufen wird. Dieser Leitfaden zeigt Ihnen diese Strategie mit zwei parallelen Zugangsdaten Schritt für Schritt, einschließlich Gerätecode und der richtigen Reihenfolge beim Ausstellen und Widerrufen von Zugangsdaten auf einem verwalteten MQTT-Broker.

Warum MQTT-Zugangsdaten überhaupt rotieren?

Statische Zugangsdaten bleiben auf Geräten lange im Umlauf. Über die Jahre wandern sie durch Build-Pipelines, Support-Laptops, zurückgegebene Hardware und Übergaben an Dienstleister. Rotation begrenzt, wie lange eine geleakte Kopie nützlich bleibt. Außerdem brauchen Sie einen erprobten Rotationsprozess für ungeplante Ereignisse:

• Ein Gerät wird gestohlen, zurückgegeben oder außer Betrieb genommen.
• Ein Firmware-Image mit eingebetteten Geheimnissen wurde versehentlich veröffentlicht.
• Ein Mitarbeiter oder Integrator mit Zugriff auf Zugangsdaten verlässt das Unternehmen.
• Ein Sicherheitsaudit, ein Kundenvertrag oder ein Regelwerk wie IEC 62443 oder die Umsetzung von NIS2 verlangt regelmäßige Rotation.

Der schlechteste Zeitpunkt, einen Rotationsprozess zu entwerfen, ist mitten in einem Sicherheitsvorfall. Wer ihn regelmäßig durchführt, hält ihn funktionsfähig.

Warum naive Rotation zu Ausfällen führt

Der verlockende Ansatz lautet: Passwort auf dem Broker ändern und dann das neue an die Geräte verteilen. Jedes Gerät, das das Update noch nicht erhalten hat, ist ausgesperrt, und ein von MQTT ausgesperrtes Gerät kann das Update oft auch nicht empfangen, weil der Update-Kanal MQTT ist. Am Ende steht für jedes Offline-Gerät ein Einsatz vor Ort, im Werk oder an der Außenstation.

Auch die umgekehrte Reihenfolge scheitert: Wenn die Geräte zuerst umschalten und der Broker die neuen Zugangsdaten noch nicht kennt, können sie sich nicht verbinden. Der einzige sichere Weg ist ein Überlappungszeitraum, in dem beide Zugangsdaten funktionieren.

Die Rotationsstrategie mit zwei parallelen Zugangsdaten

Die Phasen gelten für jeden Broker. Was sich unterscheidet, ist die Art, wie Zugangsdaten ausgestellt und widerrufen werden.

Phase 1: Neue Zugangsdaten ausstellen

Bei einem selbst betriebenen Mosquitto-Broker bedeutet das, einen zweiten Benutzer zur Passwortdatei hinzuzufügen. Bei ConnectMQ stellen Sie im Portal einen neuen Satz Zugangsdaten für das Gerät aus. Jeder Satz hat einen eigenen Benutzernamen, ein eigenes Passwort und eine eigene Client ID, weil Client IDs an die ausgestellten Zugangsdaten gebunden sind. Erfassen Sie die Zuordnung vom physischen Gerät zu alter und neuer Client ID in Ihrem Inventar, bevor Sie weitermachen.

Diese Bindung hat eine praktische Folge: Während der Rotation ändert das Gerät nicht nur sein Passwort, sondern sein gesamtes Identitätstripel. Stellen Sie sicher, dass alle Konsumenten, die sich an der Client ID orientieren, etwa ein Presence-Monitoring auf $SYS/broker/connection/{clientId}/state oder Ihr eigenes Inventar, während der Überlappung beide IDs kennen.

Phase 2: Auf dem Gerät bereitstellen

Liefern Sie die neuen Zugangsdaten über die bestehende, authentifizierte und per TLS geschützte Verbindung aus. Ein typisches Muster ist ein Befehls-Topic, auf das nur dieses Gerät hört:

devices/<deviceId>/cmd/credentials    # backend -> device, QoS 1, not retained
devices/<deviceId>/evt/credentials    # device -> backend, acknowledgement

Veröffentlichen Sie Zugangsdaten niemals als Retained Message und niemals auf einem gemeinsam genutzten oder per Wildcard lesbaren Topic. Wenn Ihr Broker keine Berechtigungen pro Topic durchsetzt, halten Sie nicht vertrauenswürdige Clients vollständig von ihm fern oder liefern Sie Zugangsdaten über einen separaten Kanal aus, etwa Ihren OTA-Update-Dienst. Das Gerät schreibt die neuen Zugangsdaten in einen geschützten Speicher, in einen anderen Slot als die aktuellen, und bestätigt mit einem Hash, nicht mit dem Passwort selbst.

Phase 3: Mit Fallback umschalten

Das Gerät verbindet sich mit den neuen Zugangsdaten neu. Lehnt der Broker sie ab, fällt das Gerät auf die alten zurück und meldet den Fehler. Dieser Schritt macht die Rotation sicher.

import json
import os
import ssl
import time
import paho.mqtt.client as mqtt

HOST = "YOUR_BROKER_HOST"
STORE = "/var/lib/mydevice/credentials.json"   # mit Berechtigungen 0600 schützen

def load():
    with open(STORE) as f:
        return json.load(f)   # {"active": {...}, "pending": {...} or null}

def save(data):
    tmp = STORE + ".tmp"
    with open(tmp, "w") as f:
        json.dump(data, f)
    os.replace(tmp, STORE)    # atomarer Tausch, übersteht Stromausfall während des Schreibens

def try_connect(cred, timeout=15):
    result = {}
    def on_connect(client, userdata, flags, reason_code, properties):
        result["rc"] = reason_code
    c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                    client_id=cred["client_id"], protocol=mqtt.MQTTv5)
    c.username_pw_set(cred["username"], cred["password"])
    c.tls_set(cert_reqs=ssl.CERT_REQUIRED)
    c.on_connect = on_connect
    c.connect(HOST, 8883, keepalive=60)
    c.loop_start()
    deadline = time.time() + timeout
    while "rc" not in result and time.time() < deadline:
        time.sleep(0.2)
    if result.get("rc") is not None and not result["rc"].is_failure:
        return c
    c.loop_stop()
    c.disconnect()
    return None

def connect_with_rotation():
    data = load()
    if data.get("pending"):
        client = try_connect(data["pending"])
        if client:
            data["previous"] = data["active"]   # als Fallback behalten, bis widerrufen
            data["active"], data["pending"] = data["pending"], None
            save(data)
            return client
        print("New credential rejected, falling back")
    client = try_connect(data["active"])
    if client is None and data.get("previous"):
        client = try_connect(data["previous"])
    return client

Behalten Sie die alten Zugangsdaten als previous, bis das Backend dem Gerät mitteilt, dass sie widerrufen wurden. Löschen Sie sie dann aus dem Speicher.

Phase 4: Prüfen

Bevor Sie etwas widerrufen, vergewissern Sie sich, dass die Flotte umgestellt ist. Nützliche Signale:

1. Die Bestätigung jedes Geräts auf seinem Topic evt/credentials.
2. Präsenz der neuen Client ID auf $SYS/broker/connection/{clientId}/state und Abwesenheit der alten.
3. Ihr Inventarbericht: Geräte, die nach dem Zeitfenster noch die alten Zugangsdaten nutzen.

Untersuchen Sie Nachzügler einzeln. Offline-Geräte sind häufig; sie schalten beim nächsten Verbindungsaufbau um, solange Sie nicht zu früh widerrufen.

Phase 5: Widerrufen

Entfernen Sie den alten Satz Zugangsdaten im Portal (oder löschen Sie den Benutzer und laden Sie Mosquitto neu). Weisen Sie die Geräte anschließend an, den Slot previous zu löschen. Ab diesem Zeitpunkt ist eine geleakte Kopie der alten Zugangsdaten wertlos.

Checkliste für die Rotation

1. Das Inventar ordnet jedes Gerät seiner aktuellen Client ID zu.
2. Neue Zugangsdaten werden ausgestellt und erfasst, bevor sich irgendein Gerät ändert.
3. Zugangsdaten werden nur über TLS, an ein gerätespezifisches Topic oder einen gerätespezifischen Kanal und nie als Retained Message ausgeliefert.
4. Das Gerät speichert die neuen Zugangsdaten mit einem atomaren Schreibvorgang in einem separaten Slot.
5. Das Gerät fällt bei Ablehnung auf die alten Zugangsdaten zurück und meldet dies.
6. Das Überlappungsfenster ist lang genug für Geräte, die tagelang offline sind.
7. Widerruf erst nach der Prüfung und Löschung auf dem Gerät erst nach dem Widerruf.
8. Den Prozess planmäßig durchführen, nicht nur bei Vorfällen.

Stolperfallen

• Enge Retry-Schleifen mit falschem Passwort. ConnectMQ sperrt IP-Adressen nach wiederholten fehlgeschlagenen Logins. Ein ganzes Werk hinter einer NAT-Adresse kann durch ein paar fehlerhafte Geräte gesperrt werden. Verwenden Sie exponentielles Backoff und fallen Sie schnell zurück.
• Zwei Geräte mit denselben Zugangsdaten. Da die Client ID an die Zugangsdaten gebunden ist, übernehmen zwei Geräte mit demselben Satz gegenseitig ihre Session und trennen sich in einer Endlosschleife. Jedes Gerät braucht einen eigenen Satz.
• Verbindungskontingent während der Überlappung. Wenn Geräte kurzzeitig beide Verbindungen halten oder Sie neue Zugangsdaten von einem Laptop aus testen, zählen diese gegen das Verbindungslimit Ihres Plans.
• Clients jenseits der Geräte vergessen. Node-RED-Flows, Telegraf-Agenten und Backend-Dienste besitzen ebenfalls Zugangsdaten. Rotieren Sie sie nach demselben Zeitplan.

Die Speicherung auf dem Gerät ist genauso wichtig wie der Rotationsprozess. Optionen für ESP32 und Linux finden Sie unter MQTT-Zugangsdaten auf Geräten schützen, und wie die ersten Zugangsdaten sicher auf das Gerät gelangen, erfahren Sie unter sichere IoT-Geräte-Provisionierung.

Starten Sie mit ConnectMQ

Ein verwalteter MQTT-Broker nimmt Ihnen Passwortdateien und Zertifikatserneuerungen ab, sodass Sie sich auf die Geräteseite der Rotation konzentrieren können. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, und testen Sie den kompletten Ablauf mit zwei parallelen Zugangsdaten an ein paar Geräten, bevor Sie ihn ausrollen. Hintergründe dazu, wie Zugangsdaten in CONNECT übertragen werden, finden Sie unter MQTT-Authentifizierung mit Benutzername und Passwort, und wie das in ein Produktiv-Setup passt, lesen Sie im Artikel über den Betrieb eines Cloud-MQTT-Brokers.

Häufig gestellte Fragen

Wie oft sollte ich MQTT-Zugangsdaten rotieren?

Es gibt kein universelles Intervall. Wählen Sie eines, das Ihr Prozess dauerhaft tragen kann, häufig jährlich oder bei jedem größeren Firmware-Release, und rotieren Sie immer sofort nach einem vermuteten Leak oder wenn ein Gerät Ihre Kontrolle verlässt.

Kann ich Zugangsdaten auf Geräten rotieren, die offline sind?

Ja, solange die alten Zugangsdaten gültig bleiben, bis die Geräte wieder online sind. Das Gerät schaltet bei seiner nächsten Verbindung um, und Sie widerrufen erst danach.

Warum ändert sich die Client ID bei der Rotation auf ConnectMQ?

ConnectMQ bindet Client IDs an ausgestellte Zugangsdaten, daher bringt ein neuer Satz Zugangsdaten eine eigene Client ID mit. Aktualisieren Sie jedes Presence-Monitoring oder Inventar, das sich an der Client ID orientiert.

Was passiert, wenn die neuen Zugangsdaten abgelehnt werden?

Das Gerät sollte auf die alten Zugangsdaten zurückfallen, sich neu verbinden und den Fehler melden, damit Sie die ausgestellten Zugangsdaten korrigieren können, bevor Sie es erneut versuchen.