MQTT-OT-Sicherheit für Industrieanlagen und Netze

Bei der MQTT-OT-Sicherheit geht es darum, Daten aus einer Industrieanlage herauszubekommen, ohne einen neuen Weg hinein zu schaffen. Dieser Leitfaden behandelt die Netzwerkmuster, die funktionieren, etwa nur ausgehende Verbindungen, DMZ-Gateways und Segmentierung, sowie den sauberen Umgang mit Zugangsdaten und das Monitoring für Anlagendaten, die an einen Cloud-Broker gesendet werden. Am Ende haben Sie ein Referenzdesign und eine Checkliste, die Sie mit Ihren OT- und IT-Teams besprechen können.

Warum OT-Netze einen anderen Ansatz brauchen

Netze der Betriebstechnik (OT) steuern Anlagen, die bewegen, heizen, mischen und schneiden. Sie unterscheiden sich von der Büro-IT in einer Weise, die jede Sicherheitsentscheidung prägt:

Verfügbarkeit hat Vorrang. Eine Sicherheitsmaßnahme, die die Produktion stoppt, gilt oft als größeres Risiko als die Bedrohung, gegen die sie schützt.
Lange Lebenszyklen. SPSen und HMIs bleiben viele Jahre im Einsatz, oft mit Firmware, die sich nicht schnell patchen lässt.
Ältere Protokolle. Modbus, älteres Profinet und viele serielle Protokolle haben überhaupt keine Authentifizierung.
Physische Folgen. Ein gefälschter Befehl kann Anlagen beschädigen oder Menschen verletzen, nicht nur Daten preisgeben.

MQTT eignet sich gut für dieses Umfeld, weil es die übliche Richtung des Traffics umkehrt. Statt dass eine Cloud-Anwendung in die Anlage hineingreift, um Maschinen abzufragen, schiebt ein Gateway in der Anlage die Daten nach außen. Richtig umgesetzt bedeutet das: keine eingehende Firewall-Regel in das OT-Netz.

Das Grundprinzip: nur ausgehende Verbindungen

Jeder MQTT-Client baut eine TCP-Verbindung zum Broker auf, niemals umgekehrt. Ein Anlagen-Gateway, das an einen Cloud-Broker publiziert, braucht daher genau eine Firewall-Regel: ausgehendes TCP zum Broker-Hostnamen auf Port 8883.

Designentscheidung	Benötigte eingehende Regeln ins OT-Netz	Typisches Risiko
Cloud-App fragt SPSen über VPN ab	VPN plus Protokoll-Ports	Eine Kompromittierung der Cloud erreicht die SPSen direkt
Remote Desktop auf das HMI für den Datenexport	RDP oder Fernzugriff des Herstellers	Diebstahl von Zugangsdaten ermöglicht interaktive Steuerung
Gateway publiziert MQTT ausgehend	Keine	Beschränkt auf das, was das Gateway publiziert und annimmt
Gateway publiziert und nimmt Befehle an	Keine, aber ein Befehlsweg existiert	Erfordert strikte Validierung auf dem Gateway

Nur ausgehend bedeutet nicht risikofrei. Das Gateway hat weiterhin eine TCP-Session mit der Außenwelt, und wenn es Befehls-Topics abonniert, können Daten zurückfließen. Die Designfrage lautet daher: Was nimmt das Gateway an, und wie validiert es das?

Referenzarchitektur

Ein mehrschichtiges Design, das zu den meisten Anlagen passt und sich lose an den Ebenen des Purdue-Modells orientiert:

Ebene 0–1: Feldgeräte und SPSen. Keine Route ins Internet. Sprechen ausschließlich Industrieprotokolle.
Ebene 2: Leitebene. HMIs und SCADA. Ebenfalls keine Route ins Internet.
Ebene 3/3.5: Industrielle DMZ. Hier sitzt das Edge-Gateway. Es liest aus Ebene 2 (zum Beispiel über OPC UA oder Modbus TCP) durch eine Firewall, die nur genau diese Datenflüsse erlaubt.
Ebene 4–5: Unternehmen und Cloud. Das Gateway publiziert über TLS an den Cloud-MQTT-Broker. Dashboards, Analytics und Historians abonnieren von hier aus.

Einzelnes Gateway oder DMZ-Broker?

Zwei gängige Varianten funktionieren gut:

Das Gateway publiziert direkt an den Cloud-Broker. Die einfachste Option: eine ausgehende Verbindung, Store-and-Forward auf dem Gateway für Ausfälle.
Ein lokaler DMZ-Broker bildet die Brücke zur Cloud. Maschinen oder Gateways publizieren an einen Broker in der DMZ, und ein einzelner Bridge- oder Relay-Client leitet ausgewählte Topics nach außen weiter. Das schafft einen lokalen Puffer und einen zentralen Punkt, an dem sich Traffic prüfen und filtern lässt, um den Preis eines weiteren Systems, das gepatcht und überwacht werden muss.

In beiden Fällen kommuniziert die Fertigungsebene nie direkt mit dem Internet.

Unified Namespace als Sicherheitsgrenze

Während das Purdue-Modell die Netzebenen beschreibt, liefert ISA-95 (IEC 62264) die fachliche Struktur der Daten. In Industrie-4.0-Projekten wird daraus auf dem Broker ein Unified Namespace (UNS): Die Hierarchie Enterprise, Site, Area, Line und Cell wird zur Topic-Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Für die Sicherheit ist das ein Gewinn, denn Berechtigungen lassen sich entlang dieser Struktur vergeben: Das Gateway der Linie 1 darf nur unter acme/werk-stuttgart/montage/linie-1/# publizieren, ein Dashboard liest nur, und Befehls-Topics bleiben einer eigenen Identität vorbehalten. Mehr zum Konzept finden Sie unter Sparkplug B und Unified Namespace. Hintergründe dazu, wie ein Broker Daten weiterleitet, finden Sie unter was ein MQTT-Broker tut.

Segmentierungsregeln, auf die es ankommt

Schreiben Sie Firewall-Regeln so, dass sich jede einzelne begründen lässt:

# OT-Firewall (zwischen Ebene 2 und DMZ)
ALLOW  gateway-01  -> plc-line1:4840/tcp   (OPC UA read)
ALLOW  gateway-01  -> plc-line2:502/tcp    (Modbus TCP read)
DENY   any         -> any                   (default)

# Perimeter-Firewall (DMZ zum Internet)
ALLOW  gateway-01  -> YOUR_BROKER_HOST:8883/tcp   (MQTT over TLS)
ALLOW  gateway-01  -> ntp-server:123/udp          (time sync for TLS)
DENY   any         -> any                          (default)
DENY   internet    -> DMZ                          (no inbound)

Behalten Sie diese Punkte im Blick:

Bevorzugen Sie Hostnamen mit Egress-Filterung an einem Proxy oder einer Next-Generation-Firewall, wenn sich die IP-Adressen des Brokers ändern können.
Erlauben Sie nur Port 8883. Unverschlüsseltes MQTT auf 1883 sollte die Anlage niemals verlassen.
Die genaue Uhrzeit ist wichtig: Die Prüfung von TLS-Zertifikaten schlägt auf Gateways mit falscher Uhr fehl.
Protokollieren Sie abgelehnte Verbindungen von der OT-Seite; unerwartete ausgehende Versuche sind ein frühes Warnsignal.

Sauberer Umgang mit Zugangsdaten auf Gateways

Anlagen-Gateways laufen oft jahrelang unbeaufsichtigt, daher müssen Zugangsdaten vom ersten Tag an sorgfältig behandelt werden.

Eine Identität pro Gateway. Wird ein Gateway kompromittiert, widerrufen Sie es, ohne die anderen anzufassen.
Getrennte Identitäten für getrennte Rollen. Ein Telemetrie-Publisher und ein Befehlsempfänger sollten sich keine Zugangsdaten teilen.
Geheimnisse außerhalb des Quellcodes speichern, in einer geschützten Konfigurationsdatei oder im Secret Store des Betriebssystems, lesbar nur für das Dienstkonto des Gateways.
Planmäßig und anlassbezogen rotieren, etwa bei Personalwechseln oder Verdacht auf Kompromittierung. Der Leitfaden zum Rotieren von MQTT-Zugangsdaten zeigt einen Ansatz mit minimaler Ausfallzeit.
Anlagen-Zugangsdaten niemals auf öffentlichen Brokern wiederverwenden. Nutzen Sie den öffentlichen MQTT-Broker nur für Tests und Prototypen, mit Wegwerf-Client-IDs und fiktiven Daten, niemals mit Produktionsdaten.

Bei ConnectMQ erhält jeder Broker generierte Zugangsdaten, und Client IDs sind an diese Zugangsdaten gebunden, sodass eine geleakte Client ID allein nicht für eine Verbindung genutzt werden kann. Wiederholte fehlgeschlagene Logins führen zu einer IP-Sperre, was das Erraten von Passwörtern für die Konten Ihrer Gateways begrenzt.

Befehle sicher handhaben

Wenn der Business Case Sollwerte oder Rezepturänderungen aus der Ferne erfordert, behandeln Sie den Befehlsweg als separaten Conduit mit höherem Risiko:

Verwenden Sie dedizierte Befehls-Topics und eine separate Subscriber-Identität.
Validieren Sie jeden Befehl auf dem Gateway gegen eine Allowlist: welcher Tag, welcher Bereich, welche Einheiten.
Verlangen Sie ein Antwort- oder Bestätigungs-Topic, damit Bediener sehen, was tatsächlich passiert ist. Response Topics in MQTT 5 helfen hier.
Behalten Sie eine lokale Übersteuerung bei und stellen Sie sicher, dass Anlagen in einen sicheren Zustand gehen, wenn der Broker nicht erreichbar ist.
Leiten Sie niemals rohe Payloads an eine SPS weiter.

Viele Anlagen entscheiden, dass der Cloud-Weg lesend bleibt und Schreibzugriffe nur über lokale HMIs erfolgen. Das ist eine legitime und verbreitete Wahl.

Monitoring und Verfügbarkeit

Sicherheit in der OT umfasst Verfügbarkeit. Planen Sie für diese Situationen:

Ausfall von Broker oder Internet: Das Gateway puffert lokal und sendet mit Backoff erneut, sobald die Verbindung zurück ist. Message Expiry verhindert, dass veraltete Daten Stunden später erneut eingespielt werden.
Ausfall des Gateways: Abonnieren Sie bei ConnectMQ $SYS/broker/connection/{clientId}/state oder nutzen Sie eine Last-Will-Nachricht, damit Dashboards das Gateway als offline anzeigen.
Ungewöhnlicher Traffic: Ein Gateway, das plötzlich mit der zehnfachen normalen Rate publiziert oder sich von einer neuen IP-Adresse verbindet, sollte untersucht werden.
Quota-Limits: Der MQTT-5-Reason-Code 0x97 zeigt Ihnen, dass eine Plan-Quota überschritten wurde, sodass Sie dies von Netzwerkproblemen unterscheiden können.

Das Dashboard im ConnectMQ-Portal, die Geräteansicht nach ISA-95-Ebene, die zur UNS-Struktur passt, und Schwellwert-Alarmregeln helfen Betriebsteams, das zu sehen, ohne eigene Werkzeuge zu bauen.

OT-Sicherheits-Checkliste für MQTT

Keine eingehenden Firewall-Regeln in das OT-Netz für MQTT.
Das Gateway sitzt in einer DMZ und liest über eng gefasste Regeln von den SPSen.
Nur TLS auf Port 8883 verlässt den Standort, mit Prüfung des Serverzertifikats und genauer Uhrzeit.
Eine eindeutige, widerrufbare Identität pro Gateway und pro Rolle.
Befehlswege sind getrennt, validiert und fail-safe oder gar nicht vorhanden.
Gateways puffern bei Ausfällen und verbinden sich mit Backoff neu.
Verbindungsstatus und Nachrichtenraten der Gateways werden überwacht.
Zuständigkeiten zwischen Anlage, IT und Broker-Anbieter sind dokumentiert.

Für die Normenseite desselben Themas lesen Sie IEC 62443 und MQTT; dort wird auch das Konzept von Zonen und Conduits erklärt, auf das sich DMZ und Befehlsweg oben abbilden lassen. Betreiber, die unter NIS2 fallen, können die Checkliste zudem als Baustein ihrer Risikomanagementmaßnahmen dokumentieren. Der Leitfaden zu Industrial IoT mit MQTT behandelt die Datenmodellierung, und Best Practices für MQTT-Sicherheit die allgemeine Härtung von Clients.

Verbinden Sie Ihre Anlage sicher mit ConnectMQ

Sie können dieses Design an einem Nachmittag mit einem einzelnen Gateway testen. Erstellen Sie unter app.connectmq.com einen privaten Broker im kostenlosen Serverless-Plan (ohne Kreditkarte), öffnen Sie eine ausgehende Regel für Port 8883 und publizieren Sie Ihr erstes ISA-95-Topic des UNS über TLS. Wenn Sie für die Produktion Isolation brauchen, behält ein verwalteter MQTT-Broker in einem Dedicated- oder BYOC-Deployment dieselbe Client-Konfiguration bei.

Häufig gestellte Fragen

Muss man für MQTT eingehende Ports in die Anlage öffnen?

Nein. MQTT-Clients verbinden sich ausgehend mit dem Broker, ein Anlagen-Gateway braucht also nur eine ausgehende Regel für Port 8883. Befehle, falls vorhanden, laufen über dieselbe Verbindung zurück.

Sollten sich SPSen direkt mit einem Cloud-Broker verbinden?

In der Regel nicht. Wenn SPSen in einem isolierten Netz bleiben und ein Edge-Gateway in einer DMZ sitzt, wird die Angriffsfläche begrenzt, und Sie steuern genau, was die Anlage verlässt.

Braucht man für MQTT von der Anlage in die Cloud ein VPN?

Meist nicht. MQTT über TLS mit Prüfung des Serverzertifikats und starken Client-Zugangsdaten bietet einen verschlüsselten, authentifizierten Kanal ohne VPN.

Was passiert mit den Daten, wenn die Internetverbindung abbricht?

Ein gut konzipiertes Gateway puffert Daten lokal und sendet sie nach dem Reconnect mit Backoff erneut. Message Expiry kann Werte verwerfen, die nicht mehr nützlich sind.

MQTT-OT-Sicherheit: Industrieanlagen schützen, wenn Daten in die Cloud gehen