IEC 62443 und MQTT: Industrielles Messaging mit Zonen und Conduits absichern

Beim Design nach IEC 62443 für MQTT geht es darum, einen MQTT-Datenfluss in das Zonen-und-Conduit-Modell einzuordnen, mit dem industrielle Sicherheitsteams bereits arbeiten. Dieser Leitfaden bildet die wichtigsten Konzepte von IEC 62443 auf eine typische Architektur aus SPSen, Edge-Gateways und einem Cloud-Broker ab, damit Sie Ihr Design in der Sprache erklären können, die Ihre OT-Security-Prüfer erwarten. Es handelt sich um einen technischen Leitfaden, nicht um Rechts- oder Zertifizierungsberatung: Konformität wird für Ihr System und Ihre Organisation bewertet und nicht durch ein einzelnes Produkt verliehen.

Eine kurze Einführung in IEC 62443

IEC 62443 ist eine Normenreihe zur Sicherheit industrieller Automatisierungs- und Steuerungssysteme (IACS). Sie richtet sich an mehrere Zielgruppen: Betreiber, die Anlagen betreiben, Systemintegratoren, die Lösungen bauen, und Produkthersteller, die Komponenten liefern. Für das Messaging-Design sind einige Konzepte besonders wichtig:

• Zonen: Gruppen von Assets mit gemeinsamen Sicherheitsanforderungen, etwa eine Zelle mit SPSen oder ein Unternehmens-IT-Netz.
• Conduits: die Kommunikationswege zwischen Zonen, mit eigenen Sicherheitsanforderungen.
• Foundational Requirements (FR): sieben Kategorien, die die technischen Anforderungen gliedern: Identifikation und Authentifizierung, Nutzungskontrolle, Systemintegrität, Vertraulichkeit der Daten, eingeschränkter Datenfluss, rechtzeitige Reaktion auf Ereignisse und Verfügbarkeit von Ressourcen.
• Security Level (SL): Zielwerte von SL 1 bis SL 4, die beschreiben, wie fähigen Angreifern eine Zone oder ein Conduit standhalten muss, von gelegentlichem Missbrauch bis zu ausgefeilten Angriffen mit erheblichen Ressourcen.
• Risikobewertung: der Prozess (beschrieben in Teil 3-2), der Zonen, Conduits und Ziel-Security-Level festlegt.

Für MQTT-Projekte sind mehrere Teile relevant. Teil 3-3 listet Sicherheitsanforderungen an Systeme auf, Teil 4-2 behandelt Anforderungen an Komponenten, und Teil 2-1 betrifft das Sicherheitsprogramm des Betreibers. Im DACH-Raum gewinnt die Normenreihe zusätzlich an Gewicht, weil sie häufig als Referenzrahmen herangezogen wird, um Anforderungen aus NIS2 und dem EU Cyber Resilience Act für OT-Umgebungen und Produkte zu strukturieren.

Warum MQTT zum Zonen-und-Conduit-Modell passt

MQTT hat eine Eigenschaft, die Sicherheitsarchitekten schätzen: Clients verbinden sich immer ausgehend mit dem Broker. Ein SPS-Gateway publiziert an einen Broker; nichts muss sich eingehend mit der Anlage verbinden. Dadurch lässt sich der Kommunikationsweg leicht als einzelner Conduit mit definierter Richtung, definiertem Protokoll und Port beschreiben.

Vergleichen Sie das mit Polling-Protokollen, bei denen ein zentrales System in das Anlagennetz hineingreift, um Werte zu lesen. Jede Abfrage ist ein eingehender Datenfluss, der durch Firewalls erlaubt werden muss. Bei MQTT initiiert die Anlage die Verbindung, und die Firewall kann eingehend geschlossen bleiben.

Eine MQTT-Architektur auf Zonen und Conduits abbilden

Eine typische industrielle MQTT-Architektur hat vier Zonen:

Dazu kommen drei Conduits:

1. Conduit Steuerung–Edge: reiner Lesezugriff des Gateways auf die SPSen über ein Industrieprotokoll.
2. Conduit Edge–Broker: MQTT über TLS auf Port 8883, nur ausgehend, vom Gateway oder der DMZ zum Broker.
3. Conduit Broker–Konsument: MQTT über TLS von Analytics-Anwendungen und Dashboards zum Broker.

Die Ziel-Security-Level in der Tabelle sind bewusst nicht festgelegt. Sie ergeben sich aus Ihrer Risikobewertung, und dieselbe Architektur kann in einem Werk SL 2 und in einem anderen SL 3 sein.

Jeden Conduit dokumentieren

Halten Sie für jeden Conduit fest: Endpunkte, Richtung des Verbindungsaufbaus, Protokoll und Port, Authentifizierungsmethode, Verschlüsselung, erlaubte Topics oder Daten und was bei einem Ausfall passiert. Genau diese Details werden Prüfer erfragen.

Die Foundational Requirements auf MQTT anwenden

Befehle verdienen eine eigene Analyse

Telemetrie aus einer Anlage herauszusenden ist eine Risikostufe. Befehle in eine Anlage hineinzusenden ist eine andere. Viele Organisationen halten den Cloud-Conduit strikt lesend und behandeln Schreibzugriffe lokal. Wenn Sie Sollwerte aus der Ferne brauchen, trennen Sie sie: andere Topics, andere Zugangsdaten, Validierung auf dem Gateway und Grenzen dafür, welche Werte das Gateway an die SPS weitergibt. Die Steuerungszone sollte niemals rohe Payloads von einem Broker ausführen.

Wo ein verwalteter MQTT-Broker ins Bild passt

In diesem Modell ist der Cloud-Broker eine Zone und die Verbindung zwischen Edge und Broker ein Conduit. Ein verwalteter MQTT-Broker macht Ihr System nicht IEC-62443-konform, und Sie sollten jedem Anbieter misstrauen, der das andeutet. Was er leisten kann, sind Maßnahmen, auf die Sie in Ihrer eigenen Bewertung verweisen.

ConnectMQ bietet folgende Maßnahmen, die eine solche Bewertung unterstützen können:

• TLS auf Port 8883 und sichere WebSockets auf 8084 mit einem Let's-Encrypt-Zertifikat (FR3, FR4).
• Authentifizierung mit generierten Zugangsdaten, wobei Client IDs an diese Zugangsdaten gebunden sind (FR1).
• Mandantenisolation, ein isolierter Cluster in Dedicated-Plänen oder ein Deployment in Ihrem eigenen Cloud-Konto mit BYOC (FR5).
• Quotas pro Plan mit MQTT-5-Reason-Code 0x97, Flood Protection und IP-Sperre nach wiederholten fehlgeschlagenen Logins (FR6, FR7).
• Sichtbarkeit des Verbindungsstatus über $SYS/broker/connection/{clientId}/state sowie Dashboards und Schwellwert-Alarmregeln im Portal (FR6).

ConnectMQ bietet keine ACLs pro Topic. Nutzen Sie daher getrennte Broker oder Zugangsdaten pro Vertrauenszone, wo eine Trennung auf Topic-Ebene erforderlich ist, und setzen Sie die Filterung von Befehlen auf Ihrem Edge-Gateway durch. Dokumentieren Sie diese Zuständigkeiten in Ihrer Matrix der geteilten Verantwortung. Der Leitfaden zum Cloud-MQTT-Broker vergleicht Shared-, Dedicated- und BYOC-Modelle, was für das Zonendesign oft entscheidend ist.

Beispiel: Edge-Gateway publiziert in die Broker-Zone

Am Gateway liegt der Großteil der Sicherheitsarbeit. Ein minimales Python-Gateway, das Werte lokal liest und über TLS publiziert, könnte so aussehen:

import json
import time
import paho.mqtt.client as mqtt

BROKER = "YOUR_BROKER_HOST"  # aus dem ConnectMQ-Portal
TOPIC = "connectmq/plant1/production/line1/press1/telemetry"

def read_plc_values():
    # Durch Ihren OPC-UA- oder Modbus-Lesezugriff ersetzen; das Gateway liest nur.
    return {"pressure_bar": 182.4, "cycle_count": 50123, "state": "RUNNING"}

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()  # Broker-Zertifikat gegen die System-CAs prüfen
client.reconnect_delay_set(min_delay=2, max_delay=300)

client.connect(BROKER, 8883, keepalive=60)
client.loop_start()

while True:
    payload = read_plc_values()
    payload["ts"] = int(time.time())
    client.publish(TOPIC, json.dumps(payload), qos=1)
    time.sleep(10)

Beachten Sie, was fehlt: kein eingehender Port am Gateway, keine Subscription auf Befehls-Topics, keine mit anderen Gateways geteilten Zugangsdaten. Das Topic folgt einer Hierarchie im Stil von ISA-95, wodurch auch Ihre Zonengrenzen im Datenmodell sichtbar werden. Konsequent weitergedacht entsteht daraus ein Unified Namespace (UNS): Die ISA-95-Gerätehierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Für IEC 62443 ist das praktisch, weil Zonen meist entlang derselben Ebenen geschnitten werden – eine Zelle oder Linie ist oft auch eine Zone. Getrennte Zugangsdaten oder Broker pro Werk oder Bereich lassen sich so direkt aus dem UNS ableiten. Mehr dazu im Beitrag zu Sparkplug B und dem Unified Namespace. Der Leitfaden zu Industrial IoT mit MQTT erklärt diese Struktur ausführlicher.

Review-Checkliste für ein MQTT-Design nach IEC 62443

1. Eine Risikobewertung legt Zonen, Conduits und Ziel-Security-Level für die MQTT-Flüsse fest.
2. Jede MQTT-Verbindung, die eine Zonengrenze überschreitet, nutzt TLS und prüft das Serverzertifikat.
3. Alle Verbindungen werden von der Anlagenseite nach außen aufgebaut; keine eingehenden Ports in die Steuerungszone.
4. Jedes Gateway und jede Anwendung hat eindeutige, widerrufbare Zugangsdaten.
5. Befehlswege sind von der Telemetrie getrennt und werden auf dem Gateway validiert.
6. Gateways puffern Daten, wenn der Conduit ausfällt, und erholen sich, ohne den Broker zu überfluten.
7. Verbindungsstatus, fehlgeschlagene Logins und auffällige Raten werden mit festgelegter Reaktion überwacht.
8. Die geteilten Verantwortlichkeiten mit dem Broker-Anbieter sind dokumentiert.

Für die Netzwerkseite dieser Checkliste lesen Sie MQTT-Sicherheit für OT-Netze, für die Identitätsseite den Artikel zu Zero Trust für IoT-Messaging.

Bauen Sie Ihren industriellen Daten-Conduit auf ConnectMQ

Sie können den Conduit zwischen Edge und Broker schon heute prototypisch aufbauen. Erstellen Sie unter app.connectmq.com einen privaten Broker im kostenlosen Serverless-Plan (ohne Kreditkarte), verbinden Sie ein Gateway über TLS und beobachten Sie, wie ISA-95-Topics in der Geräteansicht des Portals erscheinen. Wenn das Design Isolation erfordert, behält ein verwalteter MQTT-Broker in einem Dedicated- oder BYOC-Deployment dieselbe Client-Konfiguration bei. Die allgemeinen Best Practices für MQTT-Sicherheit gelten durchgehend.

Häufig gestellte Fragen

Ist MQTT unter IEC 62443 erlaubt?

IEC 62443 verbietet oder schreibt keine bestimmten Protokolle vor. Die Norm verlangt, dass die Kommunikation zwischen Zonen die Sicherheitsanforderungen ihres Conduits erfüllt, was MQTT über TLS mit starker Authentifizierung unterstützen kann.

Kann ein Cloud-MQTT-Broker für mein Werk nach IEC 62443 zertifiziert sein?

Zertifizierungen gelten für bestimmte Produkte, Prozesse oder Systeme gegenüber bestimmten Teilen der Norm. Die Konformität Ihres Gesamtsystems wird für Ihr Werk bewertet; ein Broker-Anbieter kann nur Maßnahmen liefern, auf die Sie in dieser Bewertung verweisen.

Sollten Befehle aus der Cloud in die Anlage fließen?

Nur wenn die Risikobewertung es zulässt. Viele Standorte halten den Cloud-Conduit lesend, und diejenigen, die Befehle erlauben, trennen sie, validieren sie auf dem Gateway und begrenzen, was geändert werden kann.

Brauche ich einen lokalen Broker in der DMZ?

Nicht immer. Ein DMZ-Broker bringt Pufferung und einen Prüfpunkt mit, während ein Gateway, das direkt über TLS an einen Cloud-Broker publiziert, einfacher ist. Risikobewertung und Ziel-Security-Level entscheiden.