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:
- 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.
- Kein direkter Datenfluss A ↔ B. Jede Kommunikation läuft über den Proxy, und jede Firewall erlaubt nur einen einzigen unidirektionalen Fluss.
- 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.
- 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.
- 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:
- Protection & Security → Connection mechanisms:
Permit access with PUT/GET communicationdeaktivieren. (Wir schalten S7 Legacy ab — es läuft AUSSCHLIESSLICH über OPC UA.) - OPC UA → Server → General:
Activate OPC UA serveraktivieren. Port4840(Standard). - OPC UA → Server → Security:
Security policy: ausschließlichBasic256Sha256 — Sign and Encrypt. Alle RichtlinienNoneundSign onlydeaktivieren.User authentication:Allow guest accessdeaktivieren.Allow authentication via user name and passwordaktivieren + Benutzerliste freischalten.- Einen dedizierten Benutzer anlegen, z. B.:
opcua-proxy-readonlymit einem starken, im Passwort-Tresor gespeicherten Kennwort (Vault, CyberArk).
- 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
# 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).
# 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-onlyauf 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.
# ═══════════════════════════════════════════════════════════════
# 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)
# 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
- „Nur für diesen Test” — man fügt 5 Minuten lang eine Firewall-Regel
allow any anyzum Debuggen hinzu. Man vergisst sie. Sie bleibt 3 Jahre. Immer ein Ticket eröffnen und die Regel nach dem Debugging wieder entfernen. - Selbstsigniertes Zertifikat auf dem Proxy in Produktion. Funktioniert, aber die Warnung wird von den Bedienern ignoriert, die schließlich alles wegklicken. Immer PKI-signiert.
- 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). - 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. Immerif quality != Good then use_last_known_valueimplementieren. - 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.
- 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 behandelt das Purdue-Modell und den Abschnitt Multi-Site-Interconnect im Detail.
- Der Hub PLC beschreibt die Siemens-CPU S7-1500F und ihre OPC-UA-Fähigkeiten.
- Der Hub Industrielle Netzwerke vergleicht PROFINET, OPC UA und die übrigen Protokolle.
- Das Datenblatt 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.