Klassisches IPSec/OpenVPN-VPN vs. Zero-Trust-Architektur (Eziwan)
| Kriterium | Klassisches VPN (IPSec/OpenVPN) | Zero Trust (Eziwan) |
|---|---|---|
| Vertrauensmodell | ✗ Implizites Vertrauen in das Netzwerk | ✓ Niemals vertrauen, immer überprüfen |
| Sicherheitsbereich | ✗ Netzwerkperimeter (Castle-and-Moat) | ✓ Identität + Gerät + Kontext |
| Authentification | — Vorab vereinbarter Schlüssel / Zertifikat | ✓ MFA + Zertifikat + Kontext |
| Rechteverwaltung | ✗ Globaler Zugriff auf das Subnetz | ✓ Mikrosegmentierung nach Ressourcen |
| Prüfpfad | ✗ Einfache Protokolle zu Anmeldung und Abmeldung. | ✓ Detaillierte Protokollierung von Aktionen |
| Einfache Bereitstellung | ✗ Komplex (Firewall, PKI, NAT-Regeln) | ✓ Einfach mit modernem Gateway (ZTP) |
| Kompatibilität mit älteren OT-Systemen | ✓ Ausgezeichnet (transparent) | ✓ Funktioniert gut mit Edge Enforcement |
| Einhaltung der NIS2-Vorschriften | ✗ Teilweise mit Ausgleichszahlungen | ✓ Native Ausrichtung |
| Konformität mit IEC 62443 | — Je nach Konfiguration möglich | ✓ Empfohlene Architektur |
| Anschaffungskosten | ✗ Hoch (Hub, Firewall) | ✓ Mäßig (Cloud-Gateway) |
| Skalierbarkeit | ✗ Eingeschränkt (Konus) | ✓ Horizontal, cloud-nativ |
| Risiko der Lateralisation | ✗ Hoch (Zugriff auf das gesamte Netzwerk) | ✓ Gering (Mikrosegmentierung) |
| Einführungszeit | ✗ 2–4 Wochen (typischer Standort) | ✓ 1–3 Tage (mit ZTP-Gateway) |
Das klassische VPN basiert auf einem Perimeter-Modell: Sobald der Nutzer mit dem Tunnel verbunden ist, hat er Zugriff auf das gesamte Netzwerk oder ein großes Teilnetz. Dies ist das „Castle-and-Moat“-Modell – von außen schwer zu durchdringen, aber sobald man einmal drinnen ist, sind die Bewegungen innerhalb des Netzwerks nahezu uneingeschränkt. Im OT-Kontext bedeutet dies, dass ein VPN-Techniker potenziell nicht nur auf die SPS zugreifen kann, die er warten muss, sondern auch auf SCADA-Systeme, HMIs und andere kritische Geräte. Zero Trust kehrt dieses Modell um: Keine Verbindung gilt standardmäßig als vertrauenswürdig, auch nicht aus dem internen Netzwerk heraus.
Die Zero-Trust-Mikrosegmentierung ermöglicht die Festlegung präziser Richtlinien: „Techniker X darf an Werktagen von 9 bis 17 Uhr auf die SPS Y zugreifen, und zwar ausschließlich von einem zugelassenen Gerät aus.“ Ein solcher Detaillierungsgrad ist mit einem herkömmlichen VPN nicht möglich. Für OT-Umgebungen, in denen ein Cybersicherheitsvorfall physische Folgen haben kann (Produktionsausfall, Unfälle), ist diese Präzision von entscheidender Bedeutung. Eziwan setzt diese Richtlinie auf Gateway-Ebene um, und zwar transparent für industrielle Legacy-Geräte.
Die NIS2-Richtlinie verpflichtet Betreiber kritischer Infrastrukturen und wichtige Einrichtungen dazu, Maßnahmen zum Cybersicherheits-Risikomanagement einzuführen, darunter Zugangskontrolle, Protokollierung und Geschäftskontinuität. Die Norm IEC 62443 (Standard für industrielle Cybersicherheit) empfiehlt eine Segmentierung nach Zonen und Kanälen. Die Zero-Trust-Architektur entspricht von Haus aus diesen beiden Standards. Ein IPSec-VPN kann diese Anforderungen zwar erfüllen, erfordert jedoch zusätzliche Konfigurationen (externe Protokollierung, komplexe Firewall-Regeln, Zertifikatsverwaltung), die die Komplexität und das Fehlerrisiko erhöhen.
Das ist die Schwachstelle eines herkömmlichen VPNs: Eine Siemens S7-300-Steuerung, eine Schneider Magelis-Bedienoberfläche oder ein über Modbus TCP angeschlossener Frequenzumrichter haben keine Möglichkeit, einen Zero-Trust-Agenten auszuführen. Die Eziwan-Lösung löst dieses Problem durch „Edge Enforcement“: Die Zero-Trust-Richtlinie wird auf Ebene des Netzwerk-Gateways angewendet, und die industriellen Geräte sehen lediglich ein standardmäßiges lokales Ethernet-Netzwerk. Dieser Ansatz verbindet die universelle Kompatibilität des VPN mit der Sicherheit von Zero Trust.
Eine herkömmliche IPSec-VPN-Bereitstellung für einen Industriestandort erfordert: einen VPN-Konzentrator (Hardware oder VM), eine konfigurierte Firewall, eine PKI für die Zertifikate, eine Benutzer- und Schlüsselverwaltung sowie die Wartung dieser gesamten Infrastruktur. Eziwan macht den VPN-Konzentrator, die PKI und einen Großteil der Firewall-Konfiguration überflüssig. Dank Zero-Touch-Provisioning (ZTP) lässt sich ein neues Gateway in weniger als einer Stunde bereitstellen – im Gegensatz zu einer herkömmlichen VPN-Infrastruktur, bei der dies mehrere Tage dauert.
Diese dokumentierten Vorfälle verdeutlichen, warum das klassische VPN-Modell für industrielle Netzwerke nicht ausreicht
Ein Angreifer nutzte einen TeamViewer-Zugang (eine Fernzugriffssoftware ohne MFA), um zu versuchen, den Natronlaugegehalt im Trinkwasser auf ein gefährliches Niveau zu erhöhen. Der ungesicherte Fernzugriff war der direkte Angriffsvektor.
Lektion: Ohne MFA und ohne Protokollierung der Fernzugriffe lässt sich eine legitime Verbindung nicht von einem Angriff unterscheiden.
Die Gruppe „Industroyer2“ drang über VPN-Zugangsdaten, die bei einem Phishing-Angriff auf einen Subunternehmer gestohlen worden waren, in das OT-Netzwerk eines Energieversorgers ein. Die Folge: drei Tage Produktionsausfall, 4,2 Mio. € Verlust.
Lektion: VPN-Zugangsdaten, die mit einem Auftragnehmer geteilt werden, stellen einen Single Point of Failure dar. Ein Zero-Trust-Ansatz hätte den Zugriff auf die Netzwerkperipherie des Auftragnehmers eingeschränkt.
Eine fehlerhafte NAT-Regel auf einem IPsec-VPN-Hub hat versehentlich Siemens-SCADA-Benutzeroberflächen direkt im Internet zugänglich gemacht. Da sie von Shodan indexiert wurden, wurden sie innerhalb von weniger als 48 Stunden kompromittiert. Bei der „Outbound-Only“-Architektur von Eziwan ist kein eingehender Port geöffnet.
Lektion: Die Komplexität von IPsec/NAT-Konfigurationen führt zu menschlichen Fehlern. Der „Outbound-Only“-Modus beseitigt diese Angriffsfläche.
Dragos-Bericht 2024: 60 % der im Internet exponierten OT-Geräte verwendeten noch immer Standard-Anmeldedaten. Ein kommunales Wasserversorgungsnetz wurde durch einen einfachen Brute-Force-Angriff auf einen offenen VPN-Port kompromittiert – dies wurde im Rahmen eines NIS2-Konformitätsaudits festgestellt.
Lektion: Standard-Anmeldedaten bei Outbound-Only-VPNs sind die am häufigsten ausgenutzte Sicherheitslücke in der Branche. Eine Outbound-Only-Architektur macht diesen Angriffsvektor unmöglich.
Migration ohne Betriebsunterbrechung – typische Dauer: 1 bis 3 Wochen
Listen Sie alle aktiven Fernzugriffe auf: IPSec-VPN, OpenVPN, TeamViewer, direktes RDP. Ermitteln Sie die Nutzer, die zugänglichen Geräte und die Nutzungshäufigkeit. Dauer: 1–2 Tage.
Installieren Sie das Eziwan-Gateway im OT-Netzwerk, ohne das bestehende VPN zu verändern. Automatische ZTP-Konfiguration in weniger als einer Stunde. Beide Systeme laufen konfliktfrei nebeneinander. Dauer: 30 Minuten.
Legen Sie die Richtlinien fest: Welcher Benutzer greift auf welches Gerät zu, zu welchen Zeiten und von welchen Endgeräten aus? Importieren Sie die Liste der bestehenden Benutzer, sofern verfügbar. Dauer: 1–2 Tage.
Stellen Sie die Benutzer nacheinander auf den OpenVPN-Client von Eziwan um. Das alte VPN bleibt zwei Wochen lang als Ausweichlösung aktiv. Überprüfen Sie die kritischen Zugriffe, bevor Sie das VPN abschalten. Dauer: 1–2 Wochen.
Sobald alle Benutzer migriert und überprüft wurden, schließen Sie die eingehenden VPN-Ports in Ihrer Firewall. Vergewissern Sie sich mit einem externen Shodan-Scan, dass nichts mehr exponiert ist. Dauer: 30 Minuten.
Ein Site-to-Site-VPN erweitert das Netzwerk und setzt Vertrauen voraus, sobald der Tunnel aufgebaut ist. Das industrielle Zero-Trust-Modell kehrt diese Logik um: kein implizites Vertrauen, identitäts- und ressourcenbasierter Zugriff, ausgehender Tunnel ohne eingehenden Port. Hier sind der normative Rahmen und die Zielarchitektur.
Referenz-Zero-Trust-Architektur: kontinuierliche Überprüfung, Prinzip der geringsten Berechtigungen, Mikrosegmentierung, Zugriffsentscheidungen auf Basis von Richtlinien und Sitzungen.
Sicherheitsanforderungen für OT: Zonen und Kanäle, starke Authentifizierung, Datenverschlüsselung, Protokollierung – die Grundlage für den industriellen Fernzugriff.
Schreibt für kritische Einheiten eine Zugriffsverwaltung, Rückverfolgbarkeit und Meldung von Vorfällen vor; der Fernzugriff muss durchgängig nachverfolgbar sein.
Empfiehlt die Trennung der Datenflüsse, den Verzicht auf eingehende Ports im OT-Bereich und eine strikte Trennung zwischen IT und OT über ein kontrolliertes Gateway.
Bewährte verschlüsselte Tunnel. Im Zero-Trust-Modell dienen sie als ausgehende Verbindungen zu einem Broker und nicht als permanente Netzwerkbrücken.
Gegenseitige Authentifizierung mittels X.509-Zertifikaten: Jedes Gerät und jeder Betreiber weist vor jedem Zugriff seine Identität nach.
Reverse-Tunnel-Modell: Das Gateway initiiert die Verbindung zum Broker (am Standort sind keine eingehenden Ports geöffnet). Der Betreiber greift nur auf die ausdrücklich autorisierten Geräte zu, und zwar für die Dauer einer protokollierten Sitzung – nicht auf das gesamte Subnetz.
| Kriterium | Klassisches VPN | Zero-Trust-OT |
|---|---|---|
| Eingehender Port auf dem OT | Häufig erforderlich | Keine (ausgehender Tunnel) |
| Zugangsbereich | Gesamtes Subnetz | Einheitsressource |
| Confiance | Implizit nach dem Tunnel | Wird kontinuierlich überprüft |
| Authentification | Gemeinsamer Schlüssel/Identifikator | Identität + MFA + mTLS |
| Rückverfolgbarkeit | Rohdaten der Netzwerkprotokolle | Protokollierung nach Sitzung/Ressource |
| Widerruf der Zugriffsberechtigung | Gesamt (Schlüssel) | Detailliert, unmittelbar |
Das VPN ist nicht überholt: Es wird zu einem Baustein für den verschlüsselten Datenverkehr im Rahmen einer Zero-Trust-Strategie und ist nicht mehr die Sicherheitsgrenze.
Ersatz heterogener VPN-Clients durch einen Zero-Trust-Broker: keine Öffnung der Firewall auf Kundenseite, Zugriff pro Gerät und pro Techniker.
Industrielles 4G/LTE-Gateway mit OpenVPN/IPSec-VPN ohne eingehende Ports. Bereitstellung in weniger als einer Stunde, NIS2-konform.