Eine MQTT-DMZ ist die Netzwerkzone, in der Anlagendaten das Netz der Betriebstechnik (OT) auf dem Weg zu Cloud- und Unternehmenssystemen verlassen, ohne dass irgendetwas von außen den Weg zurück hinein findet. In diesem Leitfaden erfahren Sie, warum MQTT so gut in eine DMZ passt, welche drei Platzierungsmuster sich in der Praxis bewähren, welche Firewall-Regeln Sie konkret beantragen sollten, und Sie erhalten eine funktionierende Bridge-Konfiguration, die OT-Daten über TLS an einen Cloud-Broker weiterleitet.
Warum MQTT gut zu einer industriellen DMZ passt
Die meisten industriellen Sicherheitsarchitekturen folgen einer Variante des Purdue-Modells oder den Zonen und Conduits nach IEC 62443. Die Ebenen 0 bis 2 enthalten Sensoren, SPSen und HMIs, Ebene 3 den Standortbetrieb wie SCADA und Historians, und zwischen Ebene 3 und dem Unternehmensnetz (Ebene 4 und höher) liegt eine industrielle DMZ, oft als Ebene 3.5 bezeichnet. Die Regel der DMZ ist einfach: Kein Datenverkehr läuft direkt hindurch. Jeder Datenfluss endet in der DMZ, und von dort beginnt ein neuer. Für viele Betreiber in der DACH-Region gewinnt diese Trennung zusätzlich an Gewicht, weil NIS2 und die Anforderungen ihrer Kunden eine nachweisbare Segmentierung zwischen OT und IT verlangen.
Klassische Integrationsprotokolle tun sich mit dieser Regel schwer. Abfragebasierte Protokolle wie OPC DA, Modbus TCP oder eine Abfrageschnittstelle eines Historians erwarten, dass der Konsument eine Verbindung zum Produzenten öffnet. Das bedeutet eine eingehende Verbindung ins OT-Netz, genau das, was das Sicherheitsteam vermeiden will.
MQTT kehrt die Richtung um. Jeder Teilnehmer ist ein Client, der sich nach außen mit einem Broker verbindet. Ein Gateway auf der OT-Seite öffnet eine ausgehende TCP-Verbindung, authentifiziert sich und veröffentlicht. Konsumenten in der IT oder in der Cloud verbinden sich ebenfalls nach außen mit dem Broker und abonnieren. Niemand muss jemals einen lauschenden Port in der Fertigung öffnen. Sobald Sie verstehen, was ein MQTT-Broker macht, nämlich als Treffpunkt dieser ausgehenden Verbindungen zu dienen, lässt sich das DMZ-Design viel leichter durchdenken.
Drei Platzierungsmuster für eine MQTT-DMZ
Es gibt nicht das eine richtige Design. Das passende Muster hängt davon ab, wie streng Ihre Zonenrichtlinie ist und wie viele Standorte Sie haben.
| Muster | Wo der Broker steht | Datenfluss aus der OT | Am besten geeignet für |
|---|---|---|---|
| A. Direkt ausgehend | Nur in der Cloud | OT-Gateway verbindet sich durch die Firewall nach außen mit dem Cloud-Broker | Kleine Standorte, Pilotprojekte, Standorte ohne formale DMZ |
| B. Bridge-Broker in der DMZ | Lokaler Broker in der DMZ, per Bridge mit der Cloud verbunden | OT-Gateway verbindet sich mit dem DMZ-Broker; DMZ-Broker verbindet sich nach außen mit der Cloud | Standorte mit strikter Regel „kein Datenfluss quert die DMZ“ |
| C. Gateway in der DMZ | Gateway-Software in der DMZ, Cloud-Broker | OT-Gateway oder OPC-UA-Server wird von einem DMZ-Gateway gelesen, das an die Cloud veröffentlicht | Werke, die auf Ebene 2 oder 3 nichts installieren können |
Muster A: nur ausgehend zu einem Cloud-Broker
Das Gateway sitzt auf Ebene 3 und öffnet direkt eine TLS-Verbindung auf Port 8883 zu einem Cloud-MQTT-Broker. Die Firewall erlaubt ein ausgehendes Ziel und einen Port. Rückverkehr fließt nur über diese aufgebaute Session. Dieses Muster ist schnell umgesetzt und für viele Werke völlig akzeptabel, technisch quert dabei aber eine Session die DMZ, was manche Richtlinien verbieten.
Muster B: ein Bridge-Broker in der DMZ
Ein kleiner Broker wie Mosquitto läuft auf einem gehärteten Host in der DMZ. OT-Gateways verbinden sich von unten mit ihm, und der DMZ-Broker öffnet seine eigene ausgehende Bridge-Verbindung zur Cloud. Zwei getrennte Sessions, zwei getrennte Sätze von Zugangsdaten, und der DMZ-Host ist die einzige Maschine, die jemals mit dem Internet spricht. Fällt die Cloud-Verbindung aus, puffert die Bridge QoS-1-Nachrichten lokal, was sich gut mit Store-and-Forward mit MQTT auf den Gateways ergänzt.
Muster C: ein Protokoll-Gateway in der DMZ
Manchmal lässt sich innerhalb der OT-Zone nichts Neues installieren. Dann liest ein Gateway in der DMZ eine vorhandene Schnittstelle, zum Beispiel einen OPC-UA-Server, der über eine eng gefasste Regel für die DMZ freigegeben ist, und veröffentlicht MQTT nach oben. Es ist das am wenigsten elegante Muster, weil nun die DMZ eine Verbindung in die OT hinein aufbaut, doch die Cloud bleibt weiterhin vollständig vom Werk isoliert. Unser Leitfaden zum IIoT-Edge-Gateway erklärt, wie Sie dieses Gateway auswählen.
Firewall-Regeln für eine MQTT-DMZ
Welches Muster Sie auch wählen: Schreiben Sie die Regeln vor dem Änderungsantrag auf. Firewall-Teams genehmigen präzise Regeln schneller als vage.
| Regel | Quelle | Ziel | Port | Richtung |
|---|---|---|---|---|
| 1 | OT-Gateway (Ebene 3) | DMZ-Broker | TCP 8883 (oder 1883 innerhalb eines vertrauenswürdigen Segments) | OT zur DMZ |
| 2 | DMZ-Broker | Hostname des Cloud-Brokers | TCP 8883 | DMZ ins Internet |
| 3 | IT-Konsumenten | Hostname des Cloud-Brokers | TCP 8883 oder 8084 (WSS) | Unternehmensnetz ins Internet |
| 4 | Beliebig | OT-Zone | Beliebig | Verweigern |
| 5 | Internet | DMZ-Broker | Beliebig | Verweigern |
Einige praktische Hinweise:
- Verwenden Sie in der ausgehenden Regel den Hostnamen des Brokers, keine IP-Adresse, oder ein FQDN-Objekt, wenn Ihre Firewall das unterstützt. Cloud-IPs können sich ändern.
- Erlauben Sie dem DMZ-Host die DNS-Auflösung, entweder über einen internen Resolver oder einen bestimmten Upstream.
- Halten Sie den Klartext-Port 1883 komplett vom Internet fern. Verwenden Sie für alles, was den Standort verlässt, Port 8883 mit TLS.
- Liegt ein TLS-inspizierender Proxy im Pfad, nehmen Sie den Hostnamen des Brokers aus. Die Inspektion bricht die Zertifikatsprüfung und langlebige MQTT-Sessions.
- Lange Leerlauf-Timeouts sind wichtig. Manche Firewalls verwerfen inaktive TCP-Sessions nach wenigen Minuten, setzen Sie den MQTT-Keepalive daher unter den Leerlauf-Timeout der Firewall, zum Beispiel auf 60 Sekunden.
Beispiel: eine Mosquitto-Bridge aus der DMZ zu einem Cloud-Broker
Die folgende Konfiguration setzt Muster B um. Der DMZ-Broker lauscht nur auf seiner zur OT gerichteten Schnittstelle und leitet ausgewählte Topics per Bridge über TLS an einen ConnectMQ-Broker weiter. Ersetzen Sie die Zugangsdaten durch Benutzername, Passwort und Client-ID, die im Portal generiert wurden.
# /etc/mosquitto/conf.d/dmz.conf
# Nur auf der zur OT-Zone gerichteten Schnittstelle lauschen
listener 8883 10.20.0.5
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/dmz-broker.crt
keyfile /etc/mosquitto/certs/dmz-broker.key
allow_anonymous false
password_file /etc/mosquitto/passwd
# Ausgehende Bridge zum Cloud-Broker
connection connectmq-cloud
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
bridge_capath /etc/ssl/certs
bridge_insecure false
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
try_private false
keepalive_interval 60
restart_timeout 10 120
# Nur Anlagentelemetrie weiterleiten, ausschließlich nach oben
topic factory1/# out 1 "" connectmq/
In der topic-Zeile wird die DMZ-Richtlinie in Software durchgesetzt: out bedeutet, dass Nachrichten nur vom DMZ-Broker zur Cloud fließen, nie zurück nach unten. Ein lokales Topic factory1/line1/cnc1/telemetry kommt in der Cloud als connectmq/factory1/line1/cnc1/telemetry an.
Hier zeigt sich, warum sich die DMZ und ein Unified Namespace (UNS) gut ergänzen. Ist der Topic-Baum nach der ISA-95-Equipment-Hierarchie aufgebaut (Enterprise, Site, Area, Line, Cell), etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, dann entspricht jeder Standort genau einem Teilbaum. Der DMZ-Broker eines Werks bridgt nur seinen eigenen Zweig, zum Beispiel acme/werk-stuttgart/#, und der Cloud-Broker setzt die Zweige aller Werke zum unternehmensweiten UNS zusammen. Die Zonengrenze und die Grenze im Namespace fallen so zusammen, was Firewall-Anträge, Zugriffsrechte und Audits deutlich vereinfacht. Mehr zur Struktur lesen Sie in Sparkplug B und Unified Namespace. Verwenden Sie try_private false, weil die Gegenseite keine weitere Mosquitto-Instanz ist, und belassen Sie bridge_insecure false, damit das Let's-Encrypt-Zertifikat des Cloud-Endpunkts gegen den CA-Speicher des Systems geprüft wird.
Testen Sie den Pfad vom DMZ-Host aus, bevor Sie SPS-Daten einbeziehen:
# On the DMZ host: publish a local test message
mosquitto_pub -h 10.20.0.5 -p 8883 --cafile /etc/mosquitto/certs/ca.crt \
-u gateway01 -P 'local-secret' -i dmz-test-01 \
-t factory1/test/hello -m '{"status":"ok"}' -q 1
# From any machine with access to the cloud broker: confirm it arrived
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-reader \
-t 'connectmq/factory1/#' -v
Beachten Sie, dass ConnectMQ Client-IDs an ausgestellte Zugangsdaten bindet. Der zweite Client benötigt daher einen eigenen Satz Zugangsdaten aus dem Portal statt einer ausgedachten ID. Für Experimente, bevor Sie Zugangsdaten haben, können Sie die Bridge auf den öffentlichen MQTT-Broker auf Port 1883 mit einem eindeutigen Präfix wie connectmq/demo/<random-id>/ ausrichten. Er ist nur für Tests und Prototypen gedacht: Senden Sie niemals echte Anlagendaten an den öffentlichen MQTT-Broker.
Sollten Befehle jemals nach unten fließen?
Telemetrie nach oben ist der einfache Teil. Die schwierigere Frage ist, ob überhaupt etwas zurück nach unten kommen sollte: Sollwertänderungen, Rezeptdownloads, Quittierungen. Eine gute Voreinstellung für einen ersten Einsatz lautet: nein. Belassen Sie die Bridge bei out und lassen Sie Bediener Sollwerte über das vorhandene HMI oder SCADA ändern.
Wenn Sie einen Downlink brauchen, gestalten Sie ihn bewusst:
- Bridgen Sie ein einziges, eng gefasstes Befehls-Topic mit
in, zum Beispielconnectmq/factory1/line1/cmd/+, niemals eine Wildcard über den gesamten Baum. - Lassen Sie ein Gateway auf Ebene 3 jeden Befehl gegen eine Allowlist von Tags und Wertebereichen prüfen, bevor es in die SPS schreibt.
- Verlangen Sie ein Response-Topic und Correlation Data (eine MQTT-5-Funktion), damit jeder Befehl eine protokollierte Bestätigung erzeugt.
- Lassen Sie die SPS für Sicherheitsverriegelungen verantwortlich. Ein Cloud-Befehl sollte eine Änderung anfordern, nicht die Logik umgehen.
Häufige Fehler bei der MQTT-DMZ
Den DMZ-Broker mit anonymem Zugriff betreiben. Die DMZ ist trotzdem eine gemeinsam genutzte Zone. Verlangen Sie auf dem zur OT gerichteten Listener Benutzernamen und Passwörter und idealerweise Client-Zertifikate.
# in beide Richtungen bridgen. Das ist der schnellste Weg, eine sorgfältig entworfene DMZ auf Anwendungsebene in ein flaches Netz zu verwandeln. Bridgen Sie nur die Teilbäume, die Sie brauchen, und nur in der Richtung, die Sie brauchen.
Die Session vergessen. Mit cleansession false behält die Cloud-Seite die Abonnements der Bridge und gepufferte QoS-1-Nachrichten über kurze Unterbrechungen hinweg. Mit einer Clean Session kann alles verloren gehen, was während eines Reconnect-Fensters veröffentlicht wird.
Broker-seitige Limits ignorieren. Ein Schwall historischer Daten nach einem Ausfall kann Kontingente pro Client überschreiten. Begrenzen Sie die Wiedergaberate auf dem Gateway und werten Sie die Reason Codes aus, die der Broker zurückgibt.
Wo ein verwalteter MQTT-Broker ins Spiel kommt
Sowohl bei Muster A als auch bei Muster B ist der Cloud-Endpunkt eine Komponente, die Sie andernfalls selbst aufbauen, exponieren, patchen und überwachen müssten. Ein verwalteter MQTT-Broker verlagert diese dem Internet zugewandte Angriffsfläche aus Ihrem Rechenzentrum. ConnectMQ bietet TLS auf 8883, Mandantenisolation, Flood-Schutz und IP-Sperren nach wiederholt fehlgeschlagenen Anmeldungen, sodass Ihre DMZ nur eine einzige ausgehende Regel benötigt. Für Organisationen, die den Broker in ihrem eigenen Cloud-Konto betreiben möchten, gibt es außerdem eine BYOC-Option, die in Ihrem Auftrag verwaltet wird.
Das Gesamtbild, wie die DMZ mit Gateways, Sparkplug B und dem UNS zusammenspielt, finden Sie in unserem umfassenden Leitfaden zu Industrial IoT mit MQTT. Wenn Ihre Standorte über Mobilfunknetze statt über eine Werks-Firewall angebunden sind, lesen Sie auch über MQTT über Mobilfunk.
Starten Sie mit ConnectMQ
Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte. In wenigen Minuten erhalten Sie einen generierten Benutzernamen, ein Passwort und eine Client-ID, mehr brauchen Sie nicht, um eine DMZ-Bridge auf die Cloud auszurichten und zu beobachten, wie Ihre Anlagen-Topics im Live-Topic-Explorer ankommen. Wenn Sie über die kostenlose Stufe hinauswachsen, lassen Sie die Pläne Serverless (Paid), Dedicated und BYOC skalieren, ohne die DMZ neu entwerfen zu müssen.
Häufig gestellte Fragen
Benötigt MQTT eingehende Firewall-Ports ins OT-Netz?
Nein. Jeder MQTT-Teilnehmer ist ein Client, der sich nach außen mit einem Broker verbindet, das OT-Netz braucht also nur eine ausgehende Regel zum DMZ-Broker oder Cloud-Broker. Nichts im Internet baut eine Verbindung ins Werk auf.
Sollte ich für eine MQTT-DMZ Port 1883 oder 8883 verwenden?
Verwenden Sie 8883 mit TLS für jede Verbindung, die den Standort verlässt oder eine Zonengrenze quert. Klartext auf 1883 ist nur innerhalb eines einzelnen vertrauenswürdigen Segments akzeptabel, und selbst dort wird TLS empfohlen.
Brauche ich einen Broker in der DMZ?
Nicht immer. Eine direkte ausgehende Verbindung von einem Gateway auf Ebene 3 zu einem Cloud-Broker ist oft akzeptabel. Ein Bridge-Broker in der DMZ ist die bessere Wahl, wenn Ihre Richtlinie verbietet, dass irgendeine Session die DMZ quert, oder wenn Sie lokale Pufferung wünschen.
Können Cloud-Anwendungen über die DMZ Befehle an SPSen zurücksenden?
Das können sie, aber nur über ein eng gefasstes, ausdrücklich gebridgetes Befehls-Topic und ein Gateway, das jeden Befehl prüft, bevor es in die SPS schreibt. Viele Werke beginnen mit Telemetrie ausschließlich nach oben und ergänzen den Downlink später.
