Network Segmentation – Zonen & Conduits (IEC 62443) erklärt

Was sind Zonen und Conduits?

Zonen und Conduits sind das zentrale Sicherheitsmodell der Norm IEC 62443 für industrielle Automatisierungs- und Steuerungssysteme (IACS). Sie beschreiben, wie ein Produktionsnetzwerk in klar abgegrenzte Schutzbereiche aufgeteilt wird — und wie die Kommunikation zwischen diesen Bereichen kontrolliert stattfindet.

Das Grundprinzip: Nicht jedes System darf mit jedem anderen kommunizieren. Stattdessen gilt das Prinzip der minimalen Kommunikation — nur Verbindungen, die betrieblich notwendig sind, werden explizit erlaubt.

Was ist eine Zone?

Eine Zone ist eine logische oder physische Gruppe von Systemen und Komponenten, die ähnliche Sicherheitsanforderungen teilen — zum Beispiel gleiche Kritikalität, gleiche Verfügbarkeitsanforderungen oder vergleichbare Bedrohungsszenarien.

Innerhalb einer Zone gilt ein gemeinsames Vertrauensniveau. Was außerhalb liegt, wird als potenziell anders oder unvertrauenswürdig behandelt und unterliegt klaren Zugriffsbeschränkungen.

Typische Zonen in der industriellen Produktion

Was ist ein Conduit?

Ein Conduit ist der kontrollierte Kommunikationspfad zwischen zwei oder mehr Zonen. Es handelt sich nicht um ein einzelnes Kabel oder Gerät, sondern um die Gesamtheit aller technischen Kontrollmechanismen, die diesen Kommunikationskanal absichern: Firewall-Regeln, Proxies, Protokoll-Broker, VPN-Verbindungen, Intrusion Detection Systeme.

Merksatz: Zone = Schutzbereich. Conduit = kontrollierter Übergang.

Warum sind Zonen & Conduits betrieblich und sicherheitstechnisch relevant?

Zonen und Conduits setzen das Prinzip der minimalen Rechtevergabe (Least Privilege) auf Netzwerkebene um. Die Konsequenzen sind konkret messbar:

Die Angriffsfläche sinkt, weil Angreifer sich nicht ungehindert durch das Netzwerk bewegen können (kein Lateral Movement). Ausfälle bleiben lokal begrenzt — eine kompromittierte Produktionszelle reißt nicht das gesamte Werk mit. Integrationen werden prüfbar: Es ist jederzeit dokumentiert, wer mit wem sprechen darf und warum.

Für Cloud-MES-Integrationen ist das Zonenmodell besonders relevant: Es definiert, an welchem Übergabepunkt (typischerweise über die Industrial DMZ) Produktionsdaten für übergeordnete Systeme verfügbar gemacht werden — ohne dass das OT-Kernnetz exponiert wird.

Typische Architekturbeispiele

Produktionslinie ↔ MES

Zwei Zonen: Cell/Area (SPS, HMI) und Site Operations (MES, Historian). Der Conduit zwischen ihnen erlaubt ausschließlich definierte Datenflüsse — Produktionsstatus aufwärts, Auftragsdaten abwärts — über kontrollierte Übergabestellen statt offener Routen.

OT ↔ IT über Industrial DMZ

Drei Zonen: OT-Core, DMZ, IT-Enterprise. Zwei separate Conduits (OT ↔ DMZ und DMZ ↔ IT) stellen sicher, dass IT-seitige Prozesse wie Updates, Cloud-Anbindungen oder Business Intelligence keinen direkten Einfluss auf das Produktionsnetz haben.

Fernwartung / Remote Access

Eine dedizierte Remote-Access-Zone mit Jump Host als einzigem Einstiegspunkt. Der Conduit erlaubt zeitlich begrenzte, genehmigte Sessions in definierte Zielbereiche — mit vollständiger Protokollierung. Vendor-VPNs, die direkt im OT-Subnetz enden, entsprechen diesem Modell ausdrücklich nicht.

Zonen & Conduits aufbauen: Pragmatisches Vorgehen in 4 Schritten

Schritt 1: System Under Consideration (SUC) definieren. Legen Sie fest, welche Anlagen, Netze und Services in die Betrachtung fallen — zum Beispiel Werk A, Linie 3 plus zentrale OT-Services. Ohne klaren Scope ist kein konsistentes Zonenmodell möglich.

Schritt 2: Zonen nach Schutzbedarf schneiden — nicht nach Organigramm. Entscheidend sind Verfügbarkeits-, Integritäts- und Konsequenzanforderungen, nicht organisatorische Zuständigkeiten. Ergebnis: ein erstes Zonen-Diagramm.

Schritt 3: Kommunikationsbedarfe als Conduits modellieren. Für jeden Zone-zu-Zone-Übergang festhalten: Wer initiiert die Verbindung? Welche Protokolle und Ports? In welche Richtung fließen Daten? Welche Häufigkeit (Echtzeit, periodisch, on-demand)? Welche Sicherheitskontrollen greifen (Allowlisting, Authentifizierung, Logging)?

Schritt 4: Security Level ableiten und Controls auswählen. IEC 62443 arbeitet mit risikobasierten Security Levels (SL). Das Ergebnis definiert, welche technischen Controls je Zone und Conduit durchgesetzt werden müssen.

Häufige Fehler bei der Implementierung

VLANs als ausreichende Segmentierung betrachten. VLANs ohne harte Policy-Enforcement und Monitoring sind organisatorische Ordnung, keine Sicherheitsbarriere.

Zonen nach Gerätename statt Schutzbedarf definieren. Wenn SPS, HMI, Engineering-PC und Fileserver pauschal in eine Zone landen, entstehen entweder unkontrollierbar viele Regeln oder gefährlich große Freigaben.

Conduits ohne konkrete Kommunikationsliste umsetzen. „Wir schalten eine Firewall dazwischen" ohne definierte Flows endet im Betriebsdruck regelmäßig in Any-Any-Regeln.

Keine Ownership für Regelpflege festlegen. Ohne klare Verantwortung für Review und Change-Management degeneriert das Regelwerk innerhalb weniger Monate.

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen einer Zone und einem Segment? Ein Netzwerksegment (z. B. VLAN) ist eine technische Unterteilung. Eine Zone nach IEC 62443 ist ein sicherheitsorientiertes Konstrukt, das Schutzbedarf, Bedrohungen und Anforderungen berücksichtigt — und mit einem vollständigen Satz an Sicherheitskontrollen verbunden ist. Segmente können Teil einer Zone sein, ersetzen sie aber nicht.

Muss ich für jede Maschine eine eigene Zone definieren? Nein. Zonen werden nach gleichartigem Schutzbedarf geschnitten. Mehrere Maschinen mit identischen Anforderungen können problemlos in einer Zone zusammengefasst werden. Zu feine Zonierung erzeugt unnötige Komplexität.

Wie viele Conduits sind realistisch? Das hängt vom Zonenmodell ab. In typischen Produktionsumgebungen entstehen 5–15 Conduits. Entscheidend ist nicht die Anzahl, sondern dass jeder Conduit dokumentiert, begründet und technisch durchgesetzt ist.

Wie verhält sich das Zonenmodell bei einer Cloud-MES-Integration? Die Cloud-MES-Anbindung wird typischerweise als eigener Conduit zwischen der Site Operations Zone (oder DMZ) und der Enterprise/Cloud Zone modelliert. Datenzugriff erfolgt nicht direkt auf OT-Ebene, sondern auf validierten Übergabedaten.

Checkliste für RFP und Lieferantengespräche

Wer Integrationspartner oder MES-Anbieter bewertet, sollte folgende Fragen stellen: Können Sie ein Zonen- und Conduit-Diagramm für unser Zielbild liefern, inklusive DMZ- und Remote-Access-Architektur? Welche Kommunikationsflüsse benötigen Sie wirklich — Protokolle, Richtung, Frequenz — und welche sind optional? Welche Controls setzen Sie im Conduit standardmäßig durch (Allowlisting, Authentifizierung, Logging, Monitoring)? Wie verhindern Sie, dass Änderungen im laufenden Betrieb zu unkontrollierten Freigaben führen?