MQTT in Industrial Control Systems Zwischen Telemetrie, Cloud und Kontrollverlust
Wenn man heute eine moderne industrielle Anlage betrachtet, findet man neben klassischer Steuerungslogik zunehmend einen zweiten Datenstrom. Nicht mehr nur zyklische Feldkommunikation, sondern Ereignisse, Zustandsdaten, Sensormesswerte, Performancekennzahlen. Und sehr häufig läuft dieser Strom über ein Protokoll namens MQTT.
MQTT ist leichtgewichtig, effizient und für verteilte Systeme optimiert. Genau deshalb hat es sich in Industrieumgebungen etabliert. Edge Systeme publizieren Zustände. Steuerungssoftware sendet Ereignisse. Monitoring Systeme abonnieren Topics. Doch MQTT ist kein reines Transportprotokoll. Es ist ein Architekturentscheid. Und falsch integriert kann es eine unsichtbare Brücke zwischen Control Zone und Internet werden.
1 Warum MQTT so attraktiv ist
MQTT arbeitet nach einem Publish Subscribe Modell. Geräte senden Daten an einen Broker. Andere Systeme abonnieren diese Daten. Das klingt harmlos. Es ist effizient. Es ist skalierbar. Aber die Architekturfrage lautet immer “wo steht der Broker?” Steht der Broker in der Control Zone, im Enterprise Netz oder in einer Cloud Umgebung? Die Position entscheidet über das Risiko.
2 Der Broker als zentraler Vertrauensknoten
Der MQTT Broker ist kein passives Element. Er ist ein zentraler Knotenpunkt. Wer Zugriff auf den Broker hat, kann:
Daten mitlesen
Falsche Daten einspeisen
Topics manipulieren
Den Datenfluss unterbrechen
Deshalb darf ein Broker niemals unkontrolliert zwischen Zonen vermitteln. In einer belastbaren Architektur gehört ein Broker in eine klar definierte Zone, häufig in eine DMZ oder eine dedizierte Datenzone. Direkte Broker Instanzen in der Control Zone mit externer Anbindung sind strukturell riskant.
3 Verschlüsselung ist Pflicht aber nicht ausreichend
MQTT selbst bietet keine starke Sicherheit. Sicherheit wird üblicherweise über TLS implementiert. Eine TLS Verbindung schützt die Daten während der Übertragung. Doch TLS allein reicht nicht. Wichtige Fragen sind:
Wie erfolgt die Client Authentisierung?
Sind Zertifikate individuell vergeben?
Gibt es eine klare Trennung der Topics?
Dürfen Clients nur bestimmte Topics veröffentlichen oder abonnieren?
Ein Broker ohne restriktive Topic Policies ist wie eine Firewall mit offenen Ports.
4 Topic Isolation als Sicherheitsmechanismus
In vielen realen Anlagen veröffentlichen unterschiedliche Subsysteme ihre Daten in einem gemeinsamen Namespace.
Beispiel:
production line 1 status
production line 2 status
maintenance alerts
safety events
Wenn alle Clients auf alle Topics zugreifen dürfen, entsteht eine laterale Angriffsfläche. Eine saubere Architektur trennt:
Produktionsdaten
Wartungsdaten
Diagnosedaten
Safety Meldungen
Nicht nur logisch, sondern zugriffsrechtlich.
5 MQTT und die Control Zone
Hier wird es spannend. Viele Betreiber möchten Zustandsdaten aus der Steuerungssoftware direkt in die Cloud übertragen. Das ist legitim. Aber nicht direkt. Eine robuste Architektur sieht wie folgt beschrieben aus:
Steuerungssoftware sendet Daten an einen internen Broker in der Control Zone. Ein dedizierter Gateway Dienst repliziert freigegebene Topics in eine DMZ. Von dort erfolgt die verschlüsselte Weiterleitung in die Cloud. Kein direkter Outbound Kanal aus der Control Zone. Diese Struktur folgt der Zonierung nach IEC 62443-3-3
6 Performance und Determinismus
MQTT wird oft für Telemetrie eingesetzt. Das ist unkritisch. Problematisch wird es, wenn MQTT für steuerungsnahe Funktionen genutzt wird. Publish Subscribe Mechanismen sind nicht deterministisch im klassischen Sinn. Verzögerungen können auftreten. Deshalb sollte MQTT nicht für harte Echtzeitsteuerung verwendet werden, sondern für Monitoring, Reporting und Optimierung.
7 Angriffszenarien verstehen
Ein kompromittierter MQTT Client kann:
Falsche Zustandsdaten senden
Systeme in falsche Entscheidungen treiben
Monitoring Systeme manipulieren
Alarmierungen auslösen oder unterdrücken
Das ist kein theoretisches Szenario. Gerade in vernetzten Anlagen mit externen Analytics Plattformen entsteht hier ein reales Risiko. Deshalb gehört MQTT zwingend in das Vulnerability und Monitoring Konzept. Broker Logs müssen überwacht werden.
Ungewöhnliche Topic Aktivität muss auffallen. Neue Clients dürfen nicht automatisch akzeptiert werden.
8 Die Rolle der Risikoanalyse
Ob MQTT in einer Zone eingesetzt wird und welche Sicherheitsmaßnahmen erforderlich sind, ergibt sich aus der Risikoanalyse nach IEC 62443 3-2. Ist die Datenübertragung sicherheitskritisch? Besteht externe Exposition? Können Daten indirekt Produktionsentscheidungen beeinflussen? Je nach Ergebnis ergibt sich der Target Security Level und damit die technische Ausgestaltung.
9 Fazit
MQTT ist kein Risiko per se. Es ist ein leistungsfähiges Werkzeug. Unsicher wird es, wenn:
Der Broker falsch positioniert ist
TLS nicht korrekt umgesetzt wird
Topic Isolation fehlt
Control Zone direkt mit externen Netzen verbunden wird
Monitoring fehlt
In einer sauberen ICS Architektur ist MQTT ein klar definierter Conduit mit restriktiven Regeln, nicht eine offene Datenautobahn. Im nächsten Artikel gehen wir noch tiefer in die Integrität von Steuerungssystemen und analysieren, wie Secure Boot, Firmware Schutz und Integritätsmechanismen in modernen PLC und Steuerungsplattformen umgesetzt werden.
Weitere Artikel
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 8 – Diverse Architekturen normgerecht umsetzen
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 7 – OPC UA und MQTT
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 5 – Referenzarchitektur
Artikelserie – Industrial Control Systems unter regulatorischen Druck – Artikel 4 – Risikoanalyse nach IEC 62443 3-2