# Datenaustausch zwischen 2 Steuerungen in unterschiedlichen IP-Bereichen — der OT-konforme Ansatz > Praxisfall mit 2 CPU S7-1500F, SCALANCE SC, PN/PN Coupler und industrieller DMZ. So verbinden Sie 2 sensible Infrastrukturen unter Einhaltung von Purdue, IEC 62443 und NIS2. - Quelle : https://industryhub.site/de/articles/echange-data-2-automates-ot - Veröffentlicht : 2026-01-15 - Autor : IndustryHub - Sprache : Deutsch - Stichwörter : siemens, s7-1500, scalance, profinet, opc-ua, segmentation, purdue, iec-62443 ## Der Kontext Eine große Raffinerie betreibt zwei sensible Anlagen: - **Anlage A — Atmosphärische Destillation**: gesteuert durch eine **CPU Siemens S7-1517F-3 PN/DP** im Subnetz `10.20.10.0/24`. ATEX-Atmosphäre Zone 1, SIL 2 auf den Prozesssicherheiten. - **Anlage B — Hydrocracker**: gesteuert durch eine **CPU Siemens S7-1518F-4 PN/DP** im Subnetz `10.20.20.0/24`. ATEX-Atmosphäre Zone 1, SIL 3 auf bestimmten ESD-Kreisen. Die fachliche Anforderung ist einfach: **Anlage B muss kontinuierlich 12 Prozessvariablen aus Anlage A lesen** (Schnitttemperaturen, Durchflüsse, Kolonnenfüllstand), um die eigene Regelung zu optimieren. Akzeptable Latenz: 200 ms. Keine Hin-und-Rück-Kommandos — Datenfluss **ausschließlich A → B**. Die Cybersicherheitsanforderung ist es nicht: Es ist ausgeschlossen, beide Steuerungen in denselben IP-Bereich zu legen. Eine Kompromittierung von A darf **nicht** ermöglichen, auf B überzugehen (Pivoting). Triton/Trisis (2017) hat gezeigt, dass ein Angreifer, einmal im SIS der Anlage A, die Explosionsschutzfunktionen hätte deaktivieren können. Das ist die typische Situation von **Zehntausenden Industriestandorten** weltweit. ## Was man NICHT tun darf Drei klassische Anti-Patterns, die das fachliche Problem lösen, aber die OT-Sicherheitslage zerstören. | Anti-Pattern | Warum es „funktioniert" | Warum es gefährlich ist | |---|---|---| | **Beide CPU ins selbe VLAN legen** | „Einfach, sie kommunizieren direkt per S7" | Ein VLAN ist keine echte Segmentierung. Eine kompromittierte SPS sieht die andere. Und `Put/Get S7` erfordert die Freigabe gefährlicher Funktionen (Force Outputs, Stop CPU). | | **Datenverkehr über die IT-Firewall der Zentrale routen** | „Die zentrale Firewall sieht alles" | Die IT-Firewall ist nicht für Industrieprotokolle qualifiziert. Sie lässt S7 ohne Inspektion durch und wird zum Single Point of Failure. Schlimmer noch: Ein WAN-Ausfall unterbricht die Regelung. | | **Site-to-Site-IPsec-VPN zwischen beiden Anlagen** | „Verschlüsselter Tunnel, logische Isolation" | Sobald der Tunnel steht, sehen sich beide Netze gegenseitig. Eine Ransomware, die A verschlüsselt, breitet sich in 30 Sekunden auf B aus (vgl. NotPetya / Maersk 2017). | ## Die 3 OT-konformen Optionen ``` ┌────────────────────────────────────────────────────────────────────────────────┐ │ Option 1 — PN/PN COUPLER ▶ Physische Verkabelung, kein IP-Routing │ │ │ │ CPU A ── PROFINET ── ┤PN/PN├ ── PROFINET ── CPU B │ │ │ │ + Maximale Sicherheit (galvanisch, absolute Isolation) │ │ + Keine IP-/Firewall-Konfiguration — Plug & Play │ │ + Zertifiziert für SIL bei Wahl der Safety-Variante │ │ − Begrenzter Durchsatz (1 408 Byte / Richtung) │ │ − Direktes Kabel → nur für benachbarte Anlagen geeignet │ │ − Kein Audit, keine nativen Logs │ └────────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────────────────────────┐ │ Option 2 — OPC UA über SCALANCE SC + INDUSTRIELLE DMZ ◀ EMPFOHLEN ▶ │ │ │ │ Anlage A ┌───────────── DMZ ───────────┐ Anlage B │ │ 10.20.10.0/24 │ 10.20.99.0/24 │ 10.20.20.0/24 │ │ │ │ │ │ CPU A ───SC1──┤ FW1 │── OPC-UA-Proxy ──┤ FW2 │── SC2 ─── CPU B │ │ (OPC UA │ │ (OPC UA │ │ Server) │ │ Client) │ │ │ │ + Verschlüsselung Sign + Encrypt OPC UA Ende-zu-Ende │ │ + Gegenseitige Authentifizierung per Zertifikat X.509 │ │ + Feingranulare Firewall-Regeln (ein Port, eine IP, ein Zertifikat) │ │ + Vollständiges Audit (wer, wann, welche Variablen) │ │ + Skalierbar: 3. Anlage ergänzbar, ohne A oder B anzufassen │ │ − Aufwändigere Konfiguration (Zertifikate, Regeln) │ └────────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────────────────────────────────────────────┐ │ Option 3 — UNIDIREKTIONALE DATENDIODE │ │ │ │ CPU A ──TX── ▶▶▶ DIODE ▶▶▶ ──RX── CPU B (optische Hardware) │ │ │ │ + Ultimative Sicherheit: Rückmeldung physisch unmöglich │ │ + Ideal für Nuklear, Verteidigung, funktionale Sicherheit SIL 4 │ │ − Hohe Kosten (10–50 k€ pro Diode) │ │ − Kein Handshake — Protokoll muss Verluste tolerieren │ │ − Keine Quittierung → schwierige Fehlersuche │ └────────────────────────────────────────────────────────────────────────────────┘ ``` Für unseren Fall (kontinuierlicher Datenfluss A → B, 12 Variablen, 200 ms Latenz, ohne Nuklear) ist **Option 2 der richtige Kompromiss**: robust, auditierbar, erweiterbar. Genau das setzen wir um. ## Gewählte Architektur — OPC UA + industrielle DMZ ``` ═════════════════════════════════════════════════════════════════════════════════ ANLAGE A INDUSTRIELLE DMZ ANLAGE B 10.20.10.0/24 (VLAN 10) 10.20.99.0/24 (VLAN 99) 10.20.20.0/24 (VLAN 20) ═════════════════════════════════════════════════════════════════════════════════ CPU S7-1517F-3 PN/DP IPC547G — OPC-UA-Proxy CPU S7-1518F-4 PN/DP 10.20.10.10 10.20.99.10 10.20.20.10 OPC UA Server, SIMATIC OPC UA OPC UA Client Port 4840 Aggregating Server → 10.20.99.10 │ │ │ │ PROFINET │ Ethernet │ PROFINET │ │ │ SCALANCE XC208 SCALANCE XC208 SCALANCE XC208 10.20.10.20 10.20.99.20 10.20.20.20 │ │ │ │ Ethernet-Uplink │ │ Ethernet-Uplink │ (Glasfaser) │ (DMZ intern) │ (Glasfaser) │ │ │ ┌────┴───────────┐ │ ┌───────┴─────────┐ │ SCALANCE │ │ │ SCALANCE │ │ SC632-2C │ │ │ SC632-2C │ │ FW1 │ ─.99.1 ────────┼─────────────── .99.2─ │ FW2 │ │ eth0 : .10.1 │ │ │ eth0 : .99.2 │ │ eth1 : .99.1 │ │ eth1 : .20.1 │ └────────────────┘ └─────────────────┘ ═════════════════════════════════════════════════════════════════════════════════ Allow FW1 : Proxy 10.20.99.10 ──► CPU A 10.20.10.10 tcp/4840 (OPC UA Sign+Encrypt) Allow FW2 : CPU B 10.20.20.10 ──► Proxy 10.20.99.10 tcp/4840 (OPC UA Sign+Encrypt) Sonstiger Datenverkehr → DENY + log SIEM ═════════════════════════════════════════════════════════════════════════════════ ``` **Eingesetzte Hardware-Komponenten:** | Referenz | Rolle | Menge | |---|---|---| | `6ES7517-3FP00-0AB0` — S7-1517F-3 PN/DP | CPU Anlage A (SIL 2) | 1 | | `6ES7518-4FP00-0AB0` — S7-1518F-4 PN/DP | CPU Anlage B (SIL 3) | 1 | | `6GK5208-0BA00-2AC2` — SCALANCE XC208 | Managed Industrial Switch (1× pro Zone: A, DMZ, B) | 3 | | `6GK5632-2GS00-2AC2` — SCALANCE SC632-2C | Industrielle L3-Firewall / DPI OPC UA (FW1 zwischen A↔DMZ, FW2 zwischen DMZ↔B) | 2 | | `6AG4112-2HH40-1AS2` — IPC547G | Industrie-PC für OPC-UA-Proxy in der DMZ | 1 | **Architekturprinzipien, die Sie sich merken sollten:** 1. **Die industrielle DMZ (10.20.99.0/24) ist ein eigenständiges Subnetz**, weder A noch B. Sie enthält den OPC-UA-Proxy — nicht A, nicht B. 2. **Kein direkter Datenfluss A ↔ B**. Jede Kommunikation läuft über den Proxy, und jede Firewall erlaubt nur **einen einzigen** unidirektionalen Fluss. 3. **Der Proxy aggregiert**: Er liest die 12 Variablen aus A und stellt sie B bereit. Stellt B eine anomale Anfrage, weist der Proxy sie ab — er „tunnelt" nicht zu A durch. 4. **Zwei getrennte Firewalls in Reihe** — FW1 zwischen Anlage A und DMZ, FW2 zwischen DMZ und Anlage B. Das ist die **Tiefenverteidigung im Netzwerk**: Eine Firewall zu kompromittieren reicht nicht, um die andere Anlage zu erreichen. 5. **PROFINET bleibt innerhalb jeder Anlage** (SPS ↔ Switch). PROFINET RT (Layer 2) durchquert NIEMALS eine L3-Firewall — es ist OPC UA, in TCP/IP gekapselt, das die Brücke zwischen den Zonen schlägt. ## Adressierungs- und VLAN-Plan | Subnetz | VLAN | Verwendung | Zugelassene Hosts | |---|---|---|---| | `10.20.10.0/24` | 10 | OT Anlage A (PROFINET, S7) | CPU A, HMI A, verteilte Sensoren A | | `10.20.20.0/24` | 20 | OT Anlage B (PROFINET, S7) | CPU B, HMI B, verteilte Sensoren B | | `10.20.99.0/24` | 99 | Industrielle DMZ | OPC-UA-Proxy, Jump Server, NDR | | `10.20.100.0/24` | 100 | Management der Switches/Firewalls | Ausschließlich Admin-Konsole | Die VLANs werden auf den SCALANCE XC208 mit **Trunk** zu den SCALANCE SC632-2C konfiguriert. Kein Inter-VLAN-Routing auf Switch-Ebene — die Firewall entscheidet. ## Konfiguration Schritt für Schritt ### Schritt 1 — OPC UA Server auf CPU A aktivieren (TIA Portal V19+) In den Eigenschaften der CPU S7-1517F: 1. **Protection & Security → Connection mechanisms**: `Permit access with PUT/GET communication` deaktivieren. (Wir schalten S7 Legacy ab — es läuft AUSSCHLIESSLICH über OPC UA.) 2. **OPC UA → Server → General**: `Activate OPC UA server` aktivieren. Port `4840` (Standard). 3. **OPC UA → Server → Security**: - `Security policy`: ausschließlich **`Basic256Sha256 — Sign and Encrypt`**. Alle Richtlinien `None` und `Sign only` deaktivieren. - `User authentication`: `Allow guest access` deaktivieren. `Allow authentication via user name and password` aktivieren + Benutzerliste freischalten. - Einen dedizierten Benutzer anlegen, z. B.: `opcua-proxy-readonly` mit einem starken, im Passwort-Tresor gespeicherten Kennwort (Vault, CyberArk). 4. **OPC UA → Server → Server interfaces**: eine Schnittstelle anlegen, die AUSSCHLIESSLICH die 12 benötigten Variablen exponiert (und nichts anderes). Wir erstellen einen benutzerdefinierten Objekttyp, der diese 12 Variablen enthält. Das Prinzip **Allow-List**: Es wird nur veröffentlicht, was explizit erforderlich ist. Veröffentlicht man den gesamten CPU-Speicher, erhält der Proxy viel zu viel Einblick. ### Schritt 2 — Das X.509-Zertifikat des Proxys auf CPU A installieren ```text # Erzeugung des CSR auf CPU A (TIA Portal) TIA Portal → CPU A → Certificate Manager → Generate certificate signing request (CSR) → Subject: CN=cpu-A-opcua, O=Raffinerie, C=FR # Der CSR wird von der internen PKI signiert (Microsoft AD CS, HashiCorp Vault, # oder Siemens SIMATIC Logon Service Center). # Import des signierten Zertifikats auf CPU A und des Proxy-Zertifikats # in die "Trusted certificates" der CPU. ``` **Immer gegenseitige Zertifikate.** Der Proxy authentifiziert die CPU, die CPU authentifiziert den Proxy. Jährliche Erneuerung, automatisiert über die PKI. ### Schritt 3 — Den OPC-UA-Proxy konfigurieren (Siemens SIMATIC OPC UA Aggregating Server) Auf dem IPC547G in der DMZ installieren wir den **SIMATIC OPC UA Aggregating Server** (gleichwertige Alternativen: Kepware KEPServerEX, Matrikon UA Tunneller). ```yaml # Aggregator-Konfiguration (vereinfachter Auszug) endpoints: # Auf der B-Seite exponierter Endpoint (Schnittstelle 10.20.99.10) - name: server-for-unit-b url: opc.tcp://10.20.99.10:4840 security: Basic256Sha256 auth: certificate-only allowed_clients: - cn=cpu-B-opcua,o=Raffinerie # NUR das Zertifikat von B wird akzeptiert # Client zur CPU A (Ausgang 10.20.99.10 → 10.20.10.10) upstream: - name: cpu-a url: opc.tcp://10.20.10.10:4840 security: Basic256Sha256 user: opcua-proxy-readonly password_vault: vault://kv/opc-ua/cpu-a # Mapping: was auf der A-Seite gelesen wird, wird auf der B-Seite exponiert variables: - source: "ns=3;s=UnitA.T_Coupe1" target: "Variables/TCoupe1" access: read-only - source: "ns=3;s=UnitA.T_Coupe2" target: "Variables/TCoupe2" access: read-only # ... 10 weitere ``` Drei zentrale Punkte: - **`read-only`** auf allen exponierten Variablen. Selbst wenn B kompromittiert ist, kann es nicht in A schreiben. - **Authentifizierung certificate-only**: kein Passwort, das auf der B-Seite gestohlen werden könnte. - **Logging aktiviert**: jede Sitzung, jeder Lesevorgang wird im SIEM protokolliert (per Syslog an Splunk / Wazuh). ### Schritt 4 — Die beiden SCALANCE SC632-2C konfigurieren Der SCALANCE SC ist eine industrielle L3-Firewall, die OPC UA nativ spricht (Stateful Inspection des Protokolls). Wir setzen **zwei getrennte Firewalls in Reihe** ein — ein einziger Hin-und-Rück-Fluss pro Datenfluss, eine einzige Allow-Regel pro Firewall. ```text # ═══════════════════════════════════════════════════════════════ # FW1 — zwischen Anlage A (eth0 = 10.20.10.1) und DMZ (eth1 = 10.20.99.1) # ═══════════════════════════════════════════════════════════════ # Einziger erlaubter Fluss: Proxy DMZ ──► CPU A (OPC-UA-Lesezugriff) allow src 10.20.99.10 dst 10.20.10.10 tcp/4840 proto OPC-UA-secure allow src 10.20.10.10 dst 10.20.99.10 established # Antworten deny src any dst any log # ═══════════════════════════════════════════════════════════════ # FW2 — zwischen DMZ (eth0 = 10.20.99.2) und Anlage B (eth1 = 10.20.20.1) # ═══════════════════════════════════════════════════════════════ # Einziger erlaubter Fluss: CPU B ──► Proxy DMZ (OPC-UA-Client-Sitzung) allow src 10.20.20.10 dst 10.20.99.10 tcp/4840 proto OPC-UA-secure allow src 10.20.99.10 dst 10.20.20.10 established # Antworten deny src any dst any log ``` **Zwei effektive Allow-Regeln** (eine pro Firewall), alles Übrige wird abgewiesen und ins SIEM protokolliert. Das ist das Prinzip des **Least-Privilege im Netzwerk**. **Sofortige Validierungstests:** - Von einem beliebigen Arbeitsplatz der Anlage A, `ping 10.20.20.10` (CPU B) → **Timeout**: FW1 blockiert jeden nicht explizit erlaubten Ausgang. ✓ - Von einem beliebigen Arbeitsplatz der Anlage B, `ping 10.20.10.10` (CPU A) → **Timeout**: doppelte Blockade durch FW2, dann FW1. ✓ - Vom DMZ-Proxy, `ping 10.20.10.10` → **OK**: die FW1-Regel erlaubt es. - Vom DMZ-Proxy, `ping 10.20.20.10` → **Timeout**: der Proxy muss NIEMALS zu B initiieren (B ruft den Proxy auf). FW2 blockiert. Liefert einer dieser 4 Tests nicht das erwartete Ergebnis, gibt es ein Loch in der Deny-Regel — zu beheben, BEVOR der Produktivbetrieb startet. ### Schritt 5 — Deep Packet Inspection OPC UA aktivieren Der SCALANCE SC bietet eine DPI-Option, die zusätzlich zum TCP-Header den OPC-UA-Inhalt inspiziert. Vorteile: - Weist `Write`-Anfragen ab, selbst wenn Port und IP erlaubt sind - Weist Anfragen an nicht autorisierte Knoten ab (Allow-List von NodeIDs) - Erkennt Versuche massiven Browsings (Angreifer-Enumeration) ```text # Auf dem SC632 angewendete DPI-Richtlinie OPC UA methods_allowed: [Read, Browse, TranslateBrowsePath] methods_denied: [Write, Call, AddNodes, DeleteNodes] namespace_allow: ["ns=3;s=UnitA.*"] # nur unsere Allow-List rate_limit: "100 req / s" # Erkennung brutalen Browsings ``` ### Schritt 6 — Die NDR-/OT-IDS-Sonde aktivieren Ein Dragos, Nozomi oder Claroty CTD wird per Mirror-Port am SCALANCE XC208 auf der DMZ-Seite angeschlossen. Er: - Erstellt das automatische Inventar (CPU A, CPU B, Proxy) - Lernt die Baseline des OPC-UA-Verkehrs über 7 Tage - Alarmiert bei jeder Abweichung: neuer Client, neu gelesene Variable, neues zeitliches Muster Das OT-IDS ist es, das ein Triton rechtzeitig erkennt. Unverzichtbar unter NIS2 (Artikel 21 § 2 b). ### Schritt 7 — Testen und validieren | Test | Methode | Erwartetes Ergebnis | |---|---|---| | Variable von B aus lesen | OPC-UA-Client-Baustein in CPU B → liest `UnitA.T_Coupe1` | Korrekter Wert, Latenz < 200 ms | | Direkter Ping CPU B → CPU A | `ping 10.20.10.10` vom IPC im VLAN 20 | **Timeout** (von Firewall abgewiesen) | | Schreibversuch von B aus | OPC-UA-Write-Aufruf auf eine Variable von A | **BadUserAccessDenied** | | Versuch massiven Browsings | Skript, das 10 000 Nodes in 1 s browst | DPI-Blockade ab 100 req/s, SIEM-Alarm | | Gefälschtes Client-Zertifikat | Verbindung mit nicht importiertem, selbstsigniertem Zertifikat | **BadCertificateUntrusted** | ## Anschließend durchzuführende Cyber-Prüfungen - [ ] **IDS-Inventar**: CPU A, CPU B und Proxy erscheinen korrekt. Kein unerwartetes Gerät. - [ ] **Zentralisierte OPC-UA-Logs**: 100 % der Sitzungen sind im SIEM sichtbar, mit Zeitstempel und Identität. - [ ] **Ausfalltest des Proxys**: Fällt der Proxy aus, arbeitet B mit seinem letzten bekannten Wert weiter (Fallback-Logik im Programm der CPU B). - [ ] **Zertifikatsrotation**: Ein PKI-Cron erneuert die Zertifikate 30 Tage vor Ablauf. - [ ] **Backup**: Das Image des Proxy-IPC547G wird vierteljährlich Air-Gapped gesichert. - [ ] **Schriftlicher Incident-Plan**: Wird A kompromittiert, wer isoliert den Proxy? Prozedur ≤ 15 min. - [ ] **Lieferanten-Audit**: Die Siemens-Wartung läuft über einen PAM-Jump-Server (Wallix), nicht über direkten Zugriff auf den Proxy. ## Klassische Fallstricke 1. **„Nur für diesen Test"** — man fügt 5 Minuten lang eine Firewall-Regel `allow any any` zum Debuggen hinzu. Man vergisst sie. Sie bleibt 3 Jahre. Immer ein Ticket eröffnen und die Regel nach dem Debugging wieder entfernen. 2. **Selbstsigniertes Zertifikat** auf dem Proxy in Produktion. Funktioniert, aber die Warnung wird von den Bedienern ignoriert, die schließlich alles wegklicken. Immer PKI-signiert. 3. **Geteiltes Konto `opcua-proxy-readonly`** über alle Proxys hinweg. Wird ein Proxy kompromittiert, erlaubt das Passwort das Lesen der anderen CPU. Ein Konto pro Paar `(Proxy, CPU)`. 4. **Keine Fallback-Logik auf der B-Seite**: Fällt der Proxy aus, erhält die Regelung B `Bad`-Werte und geht in den sicheren Zustand — ungeplanter Stillstand. Immer `if quality != Good then use_last_known_value` implementieren. 5. **DMZ „vorerst"** im selben VLAN wie die IT. Die industrielle DMZ ist eine DEDIZIERTE Zone — weder IT noch OT. Teilt man sie mit der IT, kann NotPetya hineinspringen. 6. **PROFINET im Routing**: NIEMALS PROFINET RT zwischen VLANs routen. Der L2-Multicast überlebt das nicht. PROFINET bleibt intern in jeder Anlage, OPC UA schlägt die Brücke. ## Zum Weiterlesen - Der Hub [OT-Cybersicherheit](/de/technologies/cybersecurity-ot) behandelt das Purdue-Modell und den Abschnitt Multi-Site-Interconnect im Detail. - Der Hub [PLC](/de/technologies/plc) beschreibt die Siemens-CPU S7-1500F und ihre OPC-UA-Fähigkeiten. - Der Hub [Industrielle Netzwerke](/de/technologies/fieldbuses) vergleicht PROFINET, OPC UA und die übrigen Protokolle. - Das Datenblatt [IEC 62443](/de/standards/iec-62443) liefert den vollständigen normativen Rahmen dieser Architektur. **Eine letzte Sache:** Was wir gerade getan haben, wirkt beim ersten Hinsehen wie Überausstattung. Vier Firewall-Schnittstellen, ein Proxy, Zertifikate, DPI… Vergleichen Sie das mit den Kosten eines Triton auf Ihrem Hydrocracker. Das Gespräch ist schnell geführt.