MQTT Sicherheitsleitfaden

Sichern Sie MQTT von der Geräteidentität zum Topic

Eine Produktions-MQTT-Bereitstellung erfordert mehrschichtige Kontrollen: TLS, Client-Authentifizierung, explizite ACL-Autorisierung, geschützte Geheimnisse, Netzwerkgrenzen und Beweise, wenn etwas schief geht.

Entdecken Sie ZugangskontrollenSehen Sie sich die Grundlagen von MQTT an
Bedrohungsmodell

Beginnen Sie mit den Fehlermodi, die MQTT allein nicht verhindern kann

Das Protokoll ist absichtlich leichtgewichtig. Sicherheit entsteht durch die damit verbundenen Bereitstellungsoptionen.

Abhören des Netzwerks

Unverschlüsseltes MQTT kann Zugangsdaten, Topic-Namen und Payloads für jeden im Netzwerkpfad sichtbar machen.

Client-Impersonation

Gemeinsame Anmeldeinformationen und vorhersehbare Client-IDs machen es schwierig, ein echtes Gerät von einem Angreifer zu unterscheiden.

Zu umfassender Topic-Zugriff

Ein gültiger Client kann dennoch Schaden anrichten, wenn er möglicherweise Befehle veröffentlicht oder sich über unabhängige Mandanten und Gerätegruppen hinweg abonniert.

Missbrauch der Verfügbarkeit

Verbindungsüberschwemmungen, Wildcard-Abonnements, der Missbrauch beibehaltener Nachrichten und Reconnect-Stürme können die Ressourcen des Brokers erschöpfen.
Sicherheitsgrenze
SicherheitsgrenzeRelevante BedrohungPrimäre KontrolleRestrisiko
GerätExtrahierte Geheimnisse, geklonte Firmware oder eine gestohlene Einheit geben sich als Client aus.Ein geschütztes Credential pro Gerät, Secure Boot und sichere Speicherung, sofern verfügbar, sowie individueller Widerruf.Ein gültiges kompromittiertes Gerät kann weiterhin jede Aktion ausführen, die seine aktuelle Richtlinie zulässt.
BrokerErraten von Anmeldeinformationen, Sitzungsübernahme, breite Abonnements und Ressourcenerschöpfung.TLS, Authentifizierung, Client-ID-Prüfungen, Topic-Richtlinie zur Standardverweigerung, Kontingente und Überwachungsereignisse.TLS und ACLs beheben weder eine unsichere Payload-Verarbeitung noch verhindern sie Verfügbarkeitsangriffe.
Control PlaneEin Betreiberkonto oder Automatisierungstoken ändert Richtlinien, stellt Anmeldeinformationen aus oder unterdrückt Beweise.Starke Bedienerauthentifizierung, Rollen mit den geringsten Rechten, Änderungsprüfung und unveränderlicher Audit-Export.Ein ausreichend privilegiertes Konto bleibt ein attraktives Ziel. Trennen Sie Zuständigkeiten und schützen Sie den Wiederherstellungszugang.
NetzwerkAbfangen, Routenmanipulation, Scanning und Verbindungsfluten erreichen den Endpunkt.Zertifikats- und Hostnamenvalidierung, eingeschränkter Eingang, Segmentierung und Ratenbegrenzungen.Die Verschlüsselung verbirgt keine Endpunktmetadaten und garantiert auch keine Upstream-Netzwerkverfügbarkeit.
Verteidigung in der Tiefe

Sicherheitskontrollen in der richtigen Reihenfolge aufbauen

  1. 01

    Transport verschlüsseln und validieren

    Erfordern Sie TLS 1.2 oder höher, validieren Sie den Broker-Hostnamen und die Zertifikatskette und entfernen Sie den einfachen Listener-Zugriff aus Produktionsnetzwerken.

  2. 02

    Geben Sie jedem Gerät eine Identität

    Geben Sie unabhängige Anmeldeinformationen aus, damit ein kompromittiertes Gerät widerrufen werden kann, ohne dass eine ganze Flotte ausgetauscht werden muss.

  3. 03

    Autorisieren Sie jede Topic-Aktion

    Bewerten Sie Veröffentlichung und Abonnement separat, binden Sie Filter an eine Geräterolle und verweigern Sie Zugriffe, die nicht explizit erforderlich sind.

Rotieren und widerrufen

Protokollieren Sie jede Ausstellung, begrenzen Sie die Exposition, rotieren Sie planmäßig oder nach einem Vorfall und stellen Sie sicher, dass ein Widerruf schnell wirksam wird.

Beschränken Sie das Netzwerk

Begrenzen Sie den Broker-Zugriff mit Firewalls, privaten Netzwerkpfaden, Rate Limits und Segmentierung auf das für den Workload erforderliche Maß.

Control Plane überwachen

Zeichnen Sie fehlgeschlagene Authentifizierungen, abgelehnte Topics, Anmeldedatenänderungen, Wiederverbindungsspitzen und ungewöhnliche Abonnement-Fanouts auf.
Client-Authentifizierung

Wählen Sie die Identitätsstärke aus den Gerätebeschränkungen

Das stärkste Schema ist dasjenige, das das Gerät während seines gesamten Lebenszyklus sicher speichern, rotieren, validieren und wiederherstellen kann.

Authentifizierungsmethode
AuthentifizierungsmethodeGeeignet fürStärkeBetriebsanforderung
Eindeutiger Benutzername und PasswortBegrenzte Geräte und unkomplizierte FlottenGut, wenn TLS validiert wird und jedes Gerät ein starkes, eindeutiges Secret nutztSichere Speicherung, Ratenbegrenzung, Rotation und Widerruf
Client-Zertifikat (mTLS)Verwaltete Hardware und hochsichere GeräteidentitätStarke kryptografische Identität während des TLS-HandshakesPKI-Ausgabe, geschützte private Schlüssel, Erneuerung und Widerruf
Kurzlebiges TokenGateways und Anwendungen mit einem IdentitätsanbieterBei korrekter Validierung umfangreich und zeitlich begrenztVertrauenswürdige Token-Ausstellung, sichere Zeitbasis, Erneuerung und Audience-Prüfung
Ausführbare Mosquitto TLS-Basislinie (Dateipfade ersetzen)
listener 8883
allow_anonymous false
password_file /etc/mosquitto/passwords
acl_file /etc/mosquitto/acl

cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/broker.crt
keyfile /etc/mosquitto/certs/broker.key
tls_version tlsv1.2
Ausführbare Client-Verifizierung (synthetischer Endpunkt)
mosquitto_sub \
  -h mqtt.example.invalid -p 8883 \
  --cafile ./ca.crt \
  -u sensor-042 -P 'REPLACE_ME' \
  -i sensor-042-check \
  -t 'factory/shanghai/line-1/sensor-042/command' \
  -d
Geringstes Privileg

Machen Sie die Topic-Richtlinie überprüfbar

Drücken Sie den Gerätevertrag als enge Veröffentlichungs- und Abonnementfilter aus und testen Sie dann vor der Einführung sowohl zulässige als auch abgelehnte Topics.

Richtlinie für Sensorgeräte
# Mosquitto ACL: username is the unique device identity
pattern write factory/shanghai/line-1/%u/telemetry
pattern write factory/shanghai/line-1/%u/state

# It may receive only its own commands
pattern read factory/shanghai/line-1/%u/command

# Unlisted topics are denied by default
Überprüfen Sie die Veröffentlichungs- und Abonnementberechtigungen unabhängig voneinander.
Binden Sie Topic-Filter an die authentifizierte Geräteidentität.
Fügen Sie negative Tests für Schwestergeräte, Befehls-Topics und globale Wildcards hinzu.
Verwenden Sie überprüfte Vorlagen für Geräte mit derselben Rolle wieder.
Überwachen Sie Richtlinienänderungen und Anmeldeinformationsänderungen.
Üben Sie das Sperren eines Geräts, ohne die anderen Geräte zu stören.
RELEASE-GATE

Zugangsdaten rotieren, ohne durch gemeinsam genutzte Secrets einen Ausfall zu verursachen

Broker- und Identitätsanbieter-APIs unterscheiden sich. Verwenden Sie diese herstellerneutrale Sequenz als betriebliches Runbook und ordnen Sie dann jeden Schritt Ihrer Plattform zu.

  1. 01

    Inventarisieren Sie die Identität und den Explosionsradius

    Notieren Sie den Gerätebesitzer, die Richtlinie, die letzte Verwendung, den Geheimtyp, den Ausgabezeitpunkt, den Ablauf und einen getesteten Wiederherstellungspfad.

  2. 02

    Stellen Sie einen zweiten Ausweis mit begrenzter Überlappung aus

    Lassen Sie die alten Anmeldeinformationen nur für einen kurzen Migrationszeitraum aktiv. Geben Sie dem Ersatz dieselbe oder eine engere Topic-Richtlinie, niemals einen breiteren Zugang.

  3. 03

    Beweisen Sie den neuen Weg vor der Umstellung

    Stellen Sie die Verbindung mit vollständiger TLS-Validierung wieder her, bestätigen Sie den zulässigen Datenverkehr, führen Sie negative Topic-Tests durch und erfassen Sie die neue Identität in Protokollen.

  4. 04

    Widerrufen Sie die alten Anmeldeinformationen und beenden Sie Sitzungen

    Deaktivieren Sie die serverseitige Identität, trennen Sie bestehende Sitzungen und stellen Sie sicher, dass Wiederherstellungs- und Veröffentlichungsversuche fehlschlagen.

  5. 05

    Schließen Sie die Beweisschleife

    Entfernen Sie das alte Geheimnis von Geräten und Speichern, zeichnen Sie den Abschluss auf und warnen Sie bei jeder späteren Verwendung der widerrufenen Identität.

Kompromisspfad: Zuerst widerrufen, dann untersuchen

Verzichten Sie bei mutmaßlichem Diebstahl auf die geplante Übergangsphase: Deaktivieren Sie die Identität, beenden Sie aktive Sessions, sichern Sie Broker- und Control-Plane-Logs, grenzen Sie betroffene Richtlinien ein, stellen Sie Ersatz-Zugangsdaten erst nach erneuter Geräteprüfung aus und überwachen Sie eine mögliche Wiederverwendung.

Checkliste für den Betrieb

Produktions-MQTT-Sicherheitsbasislinie

Nutzen Sie das Release-Gate unten und laden Sie dann die vollständige druckbare Checkliste für Transport, Identität, Autorisierung, Rotation, Netzwerk, Überwachung und Reaktion auf Vorfälle herunter.

TLS ist obligatorisch

Lehnen Sie ungültige Zertifikate ab, entfernen Sie unsichere Fallbacks und überprüfen Sie Geräteuhren und Trust Stores.

Geheimnisse sind gerätebezogen

Keine werksweiten Passwörter in Firmware, Tabellenkalkulationen, Quellcode oder kopierten Konfigurationspaketen.

Richtlinien werden getestet

Der erwartete Datenverkehr ist erfolgreich und geräte-, mandantenübergreifende und nicht autorisierte Befehlspfade schlagen fehl.

Vorfälle sind beherrschbar

Betreiber können eine kompromittierte Identität identifizieren, widerrufen, untersuchen und durch ein dokumentiertes Playbook ersetzen.
Laden Sie die Produktionscheckliste herunter
Primärquellen

Standards und Implementierungsreferenzen

Die Protokollfakten und Beispiele in diesem Leitfaden basieren auf Standardisierungsgremien und Implementierungseigentümern. Die Produktfunktionen werden nachstehend separat aufgeführt.

Was RunMQTT derzeit bietet

Private RunMQTT-Broker bieten TLS- und Secure-WebSocket-Endpunkte, individuelle Benutzername-Passwort-Zugangsdaten pro Gerät, wiederverwendbare Publish/Subscribe-Richtlinien für Topics, Richtlinientests und den sofortigen Entzug des Zugriffs beim Löschen eines Geräts. Kundenverwaltete mTLS-Identitäten, externe Token-Authentifizierung, Netzwerk-Allowlists und die direkte Rotation von Zugangsdaten im Dashboard werden derzeit nicht unterstützt. Erstellen und validieren Sie stattdessen eine neue Geräteidentität und löschen Sie anschließend die alte. Der öffentliche Broker ist eine gemeinsam genutzte Test-Sandbox und keine Sicherheitskontrolle für Produktivsysteme.

FAQ zur MQTT-Sicherheit

Enthält MQTT standardmäßig eine Verschlüsselung?

Nein. MQTT definiert das Messaging-Verhalten, TLS schützt den Transport. Eine unverschlüsselte Verbindung über Port 1883 kann Zugangsdaten, Topics und Payloads im Netzwerk offenlegen.

Reicht TLS aus, um eine MQTT-Bereitstellung zu sichern?

TLS schützt Daten während der Übertragung und authentifiziert den Broker, entscheidet jedoch nicht, welche Topics ein gültiger Client verwenden darf. Koppeln Sie TLS mit eindeutiger Identität, Topic-Autorisierung, sicherer Speicherung von Anmeldeinformationen und Überwachung.

Kann die Authentifizierung mit Benutzername und Passwort sicher sein?

Ja, wenn jedes Gerät ein eindeutiges starkes Geheimnis erhält, validiert die Verbindung TLS, Geheimnisse werden sicher gespeichert, Fehlversuche werden begrenzt und Rotation und Widerruf sind betriebsmäßig möglich.

Wie sollten MQTT-Topic-Berechtigungen modelliert werden?

Trennen Sie Veröffentlichungs- und Abonnementrechte und gewähren Sie nur die engen Topic-Filter, die für eine Geräterolle erforderlich sind. Vermeiden Sie breiten Zugriff auf Feldgeräte und testen Sie jede Richtlinie anhand erwarteter und abgelehnter Topics.

Verwandte MQTT-Ressourcen

Wenden Sie das Sicherheitsmodell auf einen funktionierenden Client an und prüfen Sie dann, wie MQTT mit anderen Echtzeittechnologien zusammenpasst.

MQTT ACL-Linter

Überprüfen Sie die Wildcard-Breite, Mandanten- und Gerätegrenzen, Richtung und überlappende Regeln lokal.

MQTT-Tutorial

Verbinden, veröffentlichen, abonnieren und wählen Sie QoS nach den ersten Prinzipien.

Testen öffentlicher Broker

Üben Sie mit synthetischen Daten und verstehen Sie die Grenzen gemeinsamer Endpunkte.

MQTT QoS Labor

Testen Sie den Wiederverbindungsstatus, die Duplikatbehandlung und die Grenze der genau einmaligen Zustellung.

Verwaltete Brokerbeweise

Prüfen Sie einen datierten, reproduzierbaren Testlauf für TLS/WSS, QoS, Sessions, ACLs und kontrollierte Last.

Browser MQTT über WSS

Separate TLS-Transport-, MQTT-Identitäts-, Topic-Richtlinien- und Browser-Wiederherstellungsverantwortlichkeiten.

RunMQTT-Zugriffskontrollen

Erfahren Sie, wie Geräteidentitäten und wiederverwendbare Topic-Richtlinien in das Control Plane eingebunden sind.