MQTT Audit Logging: Was Sie protokollieren sollten und warum

MQTT Audit Logging bedeutet, festzuhalten, wer sich verbunden hat, wessen Verbindung fehlgeschlagen ist, was sich an der Konfiguration geändert hat und welche Aktionen relevant waren. So können Sie Vorfälle untersuchen und Auditoren zeigen, dass Ihre Kontrollen funktionieren. Dieser Leitfaden erklärt, welche Ereignisse Sie protokollieren sollten, welche Felder jeder Eintrag braucht, wie lange Sie die Daten aufbewahren und wie Sie eine Log-Pipeline rund um einen verwalteten MQTT-Broker aufbauen. Der Fokus liegt auf Sicherheits- und Betriebsereignissen, nicht auf der Speicherung jedes einzelnen Payloads.

Audit-Logs versus Nachrichtendaten

Es hilft, drei Arten von Aufzeichnungen zu unterscheiden:

• Audit-Logs: sicherheitsrelevante Ereignisse wie Logins, fehlgeschlagene Logins, Änderungen an Zugangsdaten und administrative Aktionen. Klein, strukturiert, für einen definierten Zeitraum aufbewahrt.
• Betriebslogs: Verbindungsabbrüche, Fehler, erreichte Quotas und Performance-Signale, die den Betrieb am Laufen halten.
• Nachrichtenhistorie: die Telemetrie selbst, meist in einer Zeitreihendatenbank oder einem Historian für Analysen gespeichert.

Wer diese Arten vermischt, bekommt Probleme. Payload-Archive sind groß, können personenbezogene oder vertrauliche Daten enthalten und begraben genau die Sicherheitsereignisse, die Sie bei einer Untersuchung brauchen. Halten Sie Audit-Logs schlank und fokussiert.

Was Sie protokollieren sollten

Die letzte Zeile verdient besondere Aufmerksamkeit. Telemetrie braucht selten einen Audit Trail, Befehle, die den Zustand von Anlagen ändern, dagegen oft. Protokollieren Sie den Befehl, die sendende Identität und die Bestätigung, nicht nur die Tatsache, dass eine Nachricht durchgelaufen ist. Ist Ihr Topic-Baum als Unified Namespace (UNS) nach der ISA-95-Hierarchie Enterprise → Site → Area → Line → Cell aufgebaut, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/cmd, lassen sich die Befehlszweige gezielt pro Werk, Bereich oder Linie erfassen und auswerten.

Felder, die jeder Eintrag braucht

Unabhängig von der Quelle sollten Sie Einträge auf eine einheitliche Struktur normalisieren:

{
  "ts": "2026-10-16T09:41:07.312Z",
  "event": "client.disconnected",
  "source": "connectmq-monitor",
  "client_id": "gw-plant1-01",
  "username": "gw-plant1-01",
  "ip": "203.0.113.24",
  "reason_code": "0x8E",
  "details": { "previous_state": "connected" }
}

Verwenden Sie UTC-Zeitstempel mit Millisekunden, halten Sie Ereignisnamen stabil und protokollieren Sie niemals Passwörter, Tokens oder vollständige Payloads mit personenbezogenen Daten.

Woher die Ereignisse stammen

In einem selbst betriebenen Setup sind die Logdateien des Brokers die primäre Quelle. Mosquitto beispielsweise protokolliert Verbindungen, Trennungen und Authentifizierungsfehler, wenn die entsprechenden log_type-Optionen aktiviert sind, und Sie übertragen diese Dateien an ein zentrales System.

Bei einem verwalteten MQTT-Broker kombinieren Sie, was die Plattform bereitstellt, mit dem, was Ihre eigenen Clients und Anwendungen aufzeichnen. Dabei ist es wichtig, genau zu unterscheiden, was woher kommt. Bei ConnectMQ sind die sichtbaren Quellen:

• Verbindungsstatus-Topics: $SYS/broker/connection/{clientId}/state meldet, ob ein Client verbunden ist. Sie können es abonnieren und aufzeichnen.
• Portal-Dashboard und Geräteansicht: betrieblicher Einblick in verbundene Clients und Topics.
• Schwellenwert-Alarmregeln und Alarmprotokoll: eine Aufzeichnung, wann Daten von Ihnen definierte Schwellenwerte überschritten haben.
• MQTT-5-Reason-Codes: werden Clients bei einer Ablehnung zurückgegeben, darunter 0x97 für eine überschrittene Quota, und können von Ihren Clients protokolliert werden.
• Plattform-Schutzmechanismen: Flood Protection und IP-Sperren nach wiederholten fehlgeschlagenen Logins laufen auf Broker-Seite.

Das sind Betriebssignale, kein Compliance-Audit-Trail. Für einen vollständigen Audit Trail protokollieren Sie Ereignisse auf Client- und Anwendungsseite in einem Speicher, den Sie kontrollieren, und dokumentieren administrative Abläufe in Ihren eigenen Änderungsprotokollen. Das ist eine übliche Aufteilung der geteilten Verantwortung bei verwalteten Diensten; wie sich die Zuständigkeiten verteilen, lesen Sie im Leitfaden zum verwalteten MQTT-Broker.

Eine einfache Audit-Pipeline aufbauen

Ein kleiner Dienst, der Verbindungsstatus-Topics abonniert und strukturierte Zeilen in eine Datei oder einen Log-Shipper schreibt, liefert Ihnen eine verlässliche Verbindungshistorie. Dieses Beispiel nutzt paho-mqtt 2.x und überwacht eine bekannte Liste von Client IDs:

import json
import logging
from datetime import datetime, timezone
import paho.mqtt.client as mqtt

WATCHED_CLIENTS = ["gw-plant1-01", "gw-plant1-02", "dashboard-01"]

logging.basicConfig(filename="mqtt-audit.jsonl", level=logging.INFO, format="%(message)s")

def audit(event, **fields):
    entry = {"ts": datetime.now(timezone.utc).isoformat(timespec="milliseconds"),
             "event": event, "source": "connectmq-monitor", **fields}
    logging.info(json.dumps(entry))

def on_connect(client, userdata, flags, reason_code, properties):
    audit("monitor.connected", reason_code=str(reason_code))
    for cid in WATCHED_CLIENTS:
        client.subscribe(f"$SYS/broker/connection/{cid}/state", qos=1)

def on_message(client, userdata, msg):
    cid = msg.topic.split("/")[3]
    audit("client.state", client_id=cid, state=msg.payload.decode("utf-8", "replace"))

def on_disconnect(client, userdata, flags, reason_code, properties):
    audit("monitor.disconnected", reason_code=str(reason_code))

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()
client.on_connect = on_connect
client.on_message = on_message
client.on_disconnect = on_disconnect
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_forever()

Die JSON-Lines-Datei kann von jedem Log-Shipper eingesammelt und an das SIEM oder die Log-Plattform weitergeleitet werden, die Ihr Unternehmen bereits nutzt. Beachten Sie, dass der Monitor auch seine eigenen Verbindungstrennungen protokolliert: Lücken im Audit Trail sind selbst wichtige Ereignisse.

Auch auf Client-Seite protokollieren

Geräte und Anwendungen sehen Ereignisse, die der Broker Ihnen nie meldet, etwa ihre eigenen fehlgeschlagenen Verbindungsversuche und abgelehnte Publishes. Lassen Sie jeden Client Folgendes protokollieren:

1. Verbindungsversuche mit dem resultierenden Reason Code.
2. Abgelehnte Subscriptions (SUBACK-Codes ab 0x80).
3. Abgelehnte Publishes, insbesondere 0x97 (Quota überschritten) und 0x87 (nicht autorisiert).
4. Empfangene Befehle, Validierungsergebnisse und ausgeführte Aktionen.
5. Ereignisse zur Rotation von Zugangsdaten.

Bei Gateways in Werken sollten Sie diese Logs an einen zentralen Collector senden, statt sie nur auf dem Gerät zu behalten. Der Leitfaden zur MQTT-OT-Sicherheit zeigt, wie das gelingt, ohne eingehende Ports zu öffnen.

Aufbewahrung, Integrität und Datenschutz

Audit-Logs sind nur nützlich, wenn sie vollständig, vertrauenswürdig und rechtmäßig gespeichert sind.

• Aufbewahrung: Legen Sie einen Zeitraum auf Basis Ihrer regulatorischen, vertraglichen und ermittlungsbezogenen Anforderungen fest und dokumentieren Sie ihn. Löschen Sie Logs, wenn der Zeitraum endet.
• Integrität: Schreiben Sie in Append-only-Speicher oder ein System, das das Löschen einschränkt, und begrenzen Sie, wer Logs ändern darf.
• Zeitsynchronisation: Nutzen Sie NTP auf jedem protokollierenden Host; abweichende Uhren machen Zeitleisten unbrauchbar.
• Datenschutz: IP-Adressen und Benutzernamen können personenbezogene Daten im Sinne der DSGVO sein. Erheben Sie nur, was Sie brauchen, schützen Sie den Zugriff und wenden Sie Ihre Datenschutzrichtlinie an. Wo Logs Rückschlüsse auf Beschäftigte zulassen, etwa Bedienaktionen an Maschinen, ist in vielen Unternehmen zudem der Betriebsrat einzubinden.
• Zugriff: Protokollieren Sie auch den Zugriff auf die Logs selbst.

Aus Logs Alarme machen

Logs, die niemand liest, verbessern die Sicherheit nicht. Beginnen Sie mit einigen besonders wertvollen Alarmen:

1. Viele fehlgeschlagene Authentifizierungen für einen Benutzernamen oder von einer IP in kurzer Zeit.
2. Ein bekanntes Gerät verbindet sich aus einem unerwarteten Netzwerk.
3. Ein Gateway ist länger getrennt als seine erwartete maximale Ausfallzeit.
4. Wiederholte Quota- oder Rate-Limit-Ablehnungen bei einem Client.
5. Jeder Befehl auf einem Steuer-Topic außerhalb der Arbeitszeiten oder von einer unerwarteten Identität.

Diese Alarme entsprechen weitgehend den Ideen der kontinuierlichen Verifizierung in Zero Trust für IoT-Messaging und den Erwartungen an die Ereignisüberwachung in Frameworks wie IEC 62443. Auch die NIS2-Richtlinie verlangt von vielen Betreibern in der EU, Sicherheitsvorfälle zu erkennen und zu behandeln, was ohne belastbare Logs kaum möglich ist.

Checkliste für Audit Logging

1. Definierte Liste von Sicherheitsereignissen und Verantwortlichen für jede Quelle.
2. Einheitliche JSON-Struktur mit UTC-Zeitstempeln.
3. Überwachter Verbindungsstatus für jeden kritischen Client.
4. Clientseitige Protokollierung von Reason Codes, Ablehnungen und Befehlen.
5. Administrative Änderungen im Change-Management-Prozess erfasst.
6. Zentraler, zugriffsgeschützter Speicher mit dokumentierter Aufbewahrungsfrist.
7. Alarme bei fehlgeschlagenen Logins, unerwarteten Trennungen und Raten-Anomalien.
8. Regelmäßige Prüfung, ob die Pipeline selbst läuft.

Überwachen Sie Ihren Broker mit ConnectMQ

Erstellen Sie einen privaten Broker im kostenlosen Serverless-Plan unter app.connectmq.com (ohne Kreditkarte), verbinden Sie den obigen Monitor mit Ihren generierten Zugangsdaten und beobachten Sie, wie Verbindungsereignisse erscheinen. Wenn Sie zunächst ohne Zugangsdaten experimentieren möchten, probieren Sie den kostenlosen öffentlichen MQTT-Broker mit Testdaten aus. Der Artikel zu den Best Practices für MQTT-Sicherheit behandelt die Kontrollen, die Ihre Logs bestätigen sollten.

Häufig gestellte Fragen

Sollte ich für das Auditing jede MQTT-Nachricht protokollieren?

In der Regel nicht. Protokollieren Sie Sicherheits- und Verwaltungsereignisse sowie Befehle auf Steuer-Topics. Speichern Sie Telemetrie getrennt in einem Historian oder einer Datenbank, wenn Sie sie für Analysen brauchen.

Welches MQTT-Ereignis ist für das Audit am wichtigsten?

Fehlgeschlagene Authentifizierungsversuche, denn sie decken Rateversuche, geleakte oder abgelaufene Zugangsdaten und falsch konfigurierte Geräte frühzeitig auf.

Wie lange sollten MQTT-Audit-Logs aufbewahrt werden?

Darauf gibt es keine pauschale Antwort. Die Aufbewahrung hängt von Ihren regulatorischen, vertraglichen und ermittlungsbezogenen Anforderungen ab. Legen Sie also einen Zeitraum fest, dokumentieren Sie ihn und setzen Sie die Löschung nach Ablauf durch.

Kann ich Verbindungsereignisse von einem verwalteten MQTT-Broker erhalten?

Bei ConnectMQ können Sie $SYS/broker/connection/{clientId}/state für den Verbindungsstatus abonnieren und dies mit clientseitigen Logs der Reason Codes kombinieren, um Ihre eigene Verbindungshistorie aufzubauen.