Konvergierte IT/OT-Sicherheit mit Zero-Trust-Architektur
Aktualisiert: 12. Okt.

Ein Techniker möchte von einem verwalteten Rechner aus eine HMI-Meldung prüfen. Dass sich der Rechner im Unternehmensnetz befindet, beantwortet noch nicht, ob dieser Techniker genau diese Anlage erreichen darf, welche Aktionen erlaubt sind und wann der Zugang wieder endet.
Eine Zero-Trust-Architektur macht den Zugriff auf eine Ressource von einer ausdrücklichen Entscheidung über Nutzer, Gerät, Anfrage und Richtlinie abhängig. In der Betriebstechnik (OT) muss diese Entscheidung zugleich Verfügbarkeit, Zuverlässigkeit und Sicherheit des Prozesses berücksichtigen.
Die wichtigsten Punkte
Ein Standort im Firmen- oder Werksnetz begründet kein stillschweigendes Vertrauen. Für eine konkrete Ressource sind Authentifizierung und Autorisierung erforderlich [1].
IT/OT-Konvergenz bedeutet nicht, jeden Controller direkt mit einem Identitätsdienst oder einer Cloud zu verbinden. Kontrollierte Zugangsgrenzen können lokale Steuerungsfunktionen schützen.
Router, Firewall, VPN, Jump-Host oder Zugriffsdienst können jeweils einen Teil der Durchsetzung übernehmen. Kein einzelnes Gerät belegt eine vollständige Zero-Trust-Architektur.
Netzsegmentierung bleibt sinnvoll. Ein VLAN oder eine Firewall-Regel entscheidet allein aber nicht über den Zugriff einer bestimmten Person mit einem bestimmten Gerät auf eine Ressource.
Beginnen Sie mit einem Verzeichnis der Nutzer, Anlagen, Datenflüsse, Verantwortlichen und Betriebsgrenzen. Führen Sie neue Regeln schrittweise ein und prüfen Sie sie vor der Ausweitung auf die Produktion.
Was Zero Trust verändert
Nach der Definition des NIST entsteht Vertrauen in Nutzer oder Anlagen nicht allein aus ihrem physischen Standort, ihrer Netzposition oder ihrem Eigentümer. Subjekt und Gerät werden authentifiziert und autorisiert, bevor eine Sitzung zu einer Unternehmensressource aufgebaut wird [1]. Im Mittelpunkt steht die einzelne Ressource mit der jeweiligen Zugriffsentscheidung, nicht die Annahme, dass Verkehr innerhalb eines Netzsegments sicher sei.
Das verlangt weder einen modernen Identitätsagenten auf jedem Industriecontroller noch ein Netz ohne Grenzen. Viele OT-Geräte haben feste Aufgaben, lange Einsatzzeiten und enge Wartungsfenster. Der OT-Leitfaden des NIST betont die besonderen Anforderungen an Leistung, Zuverlässigkeit und Sicherheit [2].
Setzen Sie das Zugriffsprinzip deshalb an einer Grenze um, die der Standort betreiben kann. Wo sie liegt, hängt von den Anlagen, der Steuerungsarchitektur sowie den vorhandenen Identitäts- und Überwachungsdiensten ab. Das Wort „Zero Trust“ auf einer Produktseite ersetzt diese Entwurfsentscheidung nicht.
An der IT/OT-Grenze zu prüfende Fähigkeiten
Die fünf folgenden Fähigkeitsbereiche sind Einsatzrollen, die im jeweiligen Deployment zu bewerten sind; sie sind keine Funktionen, die jeder Industrierouter garantiert bietet. Klären Sie vor einer Produktentscheidung, welche Komponente verantwortlich ist, welchen Umfang sie unterstützt und wer sie im Betrieb betreut.
Fähigkeitsbereich | Rolle im Deployment | Was zu prüfen ist |
|---|---|---|
Richtlinienentscheidung und Durchsetzung | Identitäts- und Richtliniendienste entscheiden über den Zugriff; ein geeignetes Gateway oder ein Host setzt die Entscheidung durch. | Ermitteln Sie die Komponenten für Entscheidung, Durchsetzung und Widerruf sowie deren Eingaben und Protokolle. Ein Router allein bildet nicht die gesamte Architektur ab. |
Protokollbewusste Segmentierung | Genehmigte industrielle Datenflüsse und, sofern unterstützt, bestimmte Vorgänge einschränken. | Prüfen Sie die genauen Protokollversionen, die Sichtbarkeit bei der Inspektion, Grenzen durch Verschlüsselung und zulässige Funktionen. Gehen Sie nicht davon aus, dass jeder Router Modbus-, PROFINET-, DNP3- oder OPC-UA-Befehle inspiziert. |
Bedrohungsüberwachung und Analyse | Relevante Protokolle erfassen und Aktivitäten anhand der genehmigten Datenflüsse mit geeigneten Überwachungskomponenten bewerten. | Prüfen Sie Telemetriedaten, Erkennungsumfang, Integration und verfügbare Betriebsressourcen. Integriertes maschinelles Lernen ist eine produktspezifische Funktion und keine allgemeine Eigenschaft von Routern. |
Kontrollierte Reaktion auf Vorfälle | Zugriff nach einem autorisierten Betriebsverfahren entziehen oder einen betroffenen Kommunikationspfad eindämmen. | Prüfen Sie vor automatisierten Änderungen die Auswirkungen auf Prozess und Sicherheit, die Freigabeverantwortung, Protokollierung und Rücknahme. Gehen Sie weder von einer SOAR-Integration noch von einer sicheren automatischen SPS-Isolierung aus. |
Ressourcenspezifischer Fernzugriff | Einem benannten Benutzer und einem verwalteten Gerät nur den für eine genehmigte Ressource und Aufgabe erforderlichen Zugriff gewähren. | Prüfen Sie Authentifizierung, Autorisierung, Zugriffsdauer, Sitzungsprotokollierung und Entzug der Berechtigung. Wenn ein OT-Endgerät keinen Identitätsagenten ausführen kann, verwenden Sie eine unterstützte Sicherheitsgrenze oder einen Engineering-Host. |
Bevor eine automatische Eindämmung einen OT-Kommunikationspfad ändert, prüfen Sie die Auswirkungen auf Prozessverfügbarkeit und Sicherheit, benennen Sie die verantwortliche Person und testen Sie die Rücknahme.
Zugriffsweg und Verantwortung festhalten
Zeichnen Sie vor dem Kauf einer Sicherheitslösung oder einer Änderung der Routen den Weg für eine konkrete Aufgabe. Zum Beispiel:
benannter Techniker am verwalteten Gerät → Identität und Zugriffsrichtlinie → überwachter Durchsetzungspunkt → OT-Zugangszone → freigegebener Engineering-Rechner oder Zielanlage
Für die konkrete Wartungsaufgabe wenden Sie den Ablauf für SPS- und HMI-Fernzugriff an und testen den Anwendungspfad vom Techniker zum Gerät.
Halten Sie für jeden Schritt die Nutzer- oder Dienstidentität, den erforderlichen Gerätezustand, das Ziel, das erlaubte Protokoll, die freigebende Stelle, die Zugriffszeit und die auswertbaren Protokolle fest. Unterscheiden Sie, welches System entscheidet, welches die Entscheidung durchsetzt und wer eine Freigabe widerrufen kann.
Der Weg kann Identitätsanbieter, Fernzugriffsdienst, VPN-Gateway, Firewall, OT-DMZ, Jump-Host und Engineering-Rechner umfassen. Das sind getrennte Rollen, auch wenn eine Implementierung mehrere Funktionen bündelt. Im NIST-Modell gehören Policy Engine und Policy Administrator zur Entscheidungsseite; ein Policy Enforcement Point ermöglicht, überwacht und beendet die Verbindung [1].
Begrenzen Sie den Umfang. Wer nur eine Meldung lesen soll, braucht keinen allgemeinen Weg zu sämtlichen SPS und HMIs. Trennen Sie Engineering-Zugriff vom normalen Telemetrieverkehr und von Steuerungspfaden, die den Prozess verändern können. Legen Sie fest, was beim Ausfall des Identitätsdienstes, Gateways oder WAN geschieht. Die lokale Steuerung darf nicht von einem ungeprüften Fernzugriffsdienst abhängen.
Segmentierung nutzen, ohne sie mit Vertrauen gleichzusetzen
Zonen, Firewalls, VLANs und Zugriffskontrolllisten begrenzen die Kommunikation. Sie helfen, Grenzen zwischen Unternehmens-IT, OT-Leitebene und Steuerungsnetzen zu ziehen.
Für sich genommen bestätigen sie aber weder die Person und das verwaltete Gerät einer Sitzungsanfrage noch die Zulässigkeit der beabsichtigten Handlung.
Für die Netzumsetzung planen Sie VLANs und erlaubten Inter-VLAN-Verkehr anhand der erforderlichen Quellen, Ziele und Dienste.
Verwenden Sie Netzregeln zur Durchsetzung der zuvor festgelegten Zugriffspfade. Erlauben Sie an jeder Grenze nur erforderliche Quellen, Ziele, Protokolle und Richtungen. Dokumentieren Sie Regeln und Ereignisse, damit der Standort begründen kann, weshalb ein Pfad existiert und wer ihn genehmigt hat.
Kann ein Gerät keine individuelle Anmeldung unterstützen, kann ein kontrollierter Engineering-Rechner oder Zugriffsdienst die Entscheidung gegebenenfalls vermitteln und protokollieren. Prüfen Sie dabei die Betriebsanforderungen des Geräteherstellers.
Breite Ausnahmen für ein vermeintlich „vertrauenswürdiges OT-Subnetz“ sollten nicht jedem angeschlossenen Rechner Zugang zu allen Controllern geben. Ändern Sie das Steuerungsnetz auch nicht ohne genehmigtes Wartungsfenster, getestete Sicherung und benannte Zuständigkeit für die Rücknahme. OT-Sicherheitsleitlinien betrachten Architektur, Grenzschutz und Betriebsbedingungen gemeinsam [2].
Zugriffsregeln schrittweise einführen
Anlagen und Zugänge erfassen. Listen Sie Controller, HMIs, Engineering-Rechner, Gateways, Dienste, Nutzer, Dienstleister und vorhandene Datenflüsse auf. Markieren Sie Anlagen, die nicht direkt geändert oder überwacht werden können.
Prozessgrenzen bestimmen. Identifizieren Sie lokale Funktionen für Steuerung und Sicherheit, übergeordnete Systeme mit Datenbedarf und zulässige Übergänge zwischen Zonen.
Entscheidung und Durchsetzung zuordnen. Benennen Sie, wer Nutzer und Geräte prüft, wer den Zugriff freigibt, welches Gateway oder welcher Rechner die Regel umsetzt und wer Protokolle und Widerrufe kontrolliert.
Eine minimale Regel formulieren. Beginnen Sie mit einem benannten Nutzer oder Dienst, einer Ressource, dem nötigen Protokoll und einem befristeten Zeitraum. Dokumentieren Sie Einschränkungen und Verbindungsbedingungen je Fernzugriffsart und genehmigen Sie diese Art, bevor eine Verbindung erlaubt wird [3]. Jede Ausnahme braucht einen Verantwortlichen.
Außerhalb der Produktion oder im Wartungsfenster testen. Prüfen Sie erlaubten und gesperrten Zugriff, Protokollierung, lokales Betriebsverhalten und Rücknahme. Berücksichtigen Sie beispielhafte Ausfälle des Geräts und des Zugriffsdienstes.
Erst nach Prüfung erweitern. Vergleichen Sie beobachtete Flüsse mit dem freigegebenen Entwurf. Entfernen Sie unnötige Pfade und Zugangsdaten. Wiederholen Sie die relevanten Tests nach wesentlichen Änderungen an Identität, Gateway, Firewall, Firmware oder Steuerungsnetz.
Weniger Netzrouten auf einem Dashboard sind noch kein Abnahmekriterium. Berechtigte Bediener müssen ihre genehmigte Aufgabe ausführen können; unerlaubte Pfade müssen blockiert bleiben; die lokale Steuerung muss wie vorgesehen funktionieren; und Verantwortliche müssen Störungen erkennen und beheben können.
Andere Netzentscheidungen getrennt behandeln
Zero Trust bestimmt weder das VPN-Protokoll noch den Mobilfunkanbieter oder das WAN-Umschaltverfahren. Dafür sind eigene Prüfungen der Endpunkte, Routen und Ausfälle nötig. Nutzen mehrere Maschinennetze gleiche IP-Bereiche, lösen Sie den Adresskonflikt vor einem standortübergreifenden Zugriff. Eine Policy Engine macht überlappende Routen nicht eindeutig. Der Beitrag Mehrere SPS mit derselben IP-Adresse über NAT und VPN verbinden behandelt diese Adressierungsfrage.
Hängt der Zugriff von mehreren WAN-Verbindungen ab, prüfen Sie die laufende Fernsitzung und die Wiederherstellung des Standorts beim Ausfall eines Pfads. Anwendungs- und Betriebsverantwortliche müssen festlegen, welches Verhalten ausreicht; Redundanz bedeutet nicht automatisch einen unterbrechungsfreien Wechsel. Die Entscheidung zwischen Failover, Load Balancing und Bonding für 5G und Starlink ist separat zu treffen.
Fazit: jede Zugriffsentscheidung ausdrücklich treffen
Zero Trust beschreibt eine Methode zur Entscheidung über Ressourcenzugriff. Es ist weder ein Router-Merkmal noch ein Ersatz für OT-Netzplanung. Beginnen Sie mit einem Nutzer, einem Gerät, einer betrieblichen Aufgabe und einem Ziel. Platzieren Sie die Durchsetzung dort, wo der Standort sie warten kann, begrenzen Sie den erlaubten Weg und testen Sie Freigabe wie Verweigerung, ohne die lokale Steuerung zu stören.
Bevor eine Richtlinie auf weitere Produktionsanlagen ausgedehnt wird, sollten die Verantwortlichen für Steuerung, Sicherheit und Betrieb Anlagenverzeichnis, erlaubte Flüsse, Ausfälle und Rücknahme gemeinsam prüfen.
FAQ
Bedeutet Zero Trust, dass im Netz gar nichts vertraut wird?
Nein. Netzposition oder Eigentum begründen lediglich kein stillschweigendes Vertrauen. Das NIST-Modell verlangt Authentifizierung und Autorisierung von Subjekt und Gerät vor einer Sitzung zu einer Ressource [1]. Die Richtlinie legt weiterhin fest, welche Anfragen zulässig sind.
Ersetzt Zero Trust ein VPN oder eine Firewall?
Nein. Ein VPN kann einen Kommunikationspfad schützen; eine Firewall kann eine Netzgrenze durchsetzen. Beide können Teile der Architektur sein, liefern aber nicht automatisch sämtliche Entscheidungen über Identität, Gerät, Ressource, Protokollierung und Zugriffslebenszyklus.
Sind ein VLAN oder eine OT-DMZ bereits Zero Trust?
Nein. Segmentierung begrenzt die Erreichbarkeit zwischen Systemen. Allein authentifiziert sie keine Person und kein Gerät für eine konkrete Ressourcenanfrage. Nutzen Sie sie zusammen mit Zugriffsregeln und Betriebsverfahren.
Kann ein Industrierouter die gesamte Architektur bereitstellen?
Davon ist nicht auszugehen. Router oder Firewall können einen Teil des Pfads kontrollieren, wenn genaues Modell, Firmware, Identitätsanbindung, Regelumfang und Protokolle die Anforderungen erfüllen. Eine vollständige Architektur hängt außerdem von Identitätsdiensten, Ressourcenverantwortung, Freigabe und Widerruf, Überwachung und OT-Betrieb ab.
Muss auf jeder SPS und jedem HMI Zero-Trust-Software laufen?
Nicht unbedingt. Manche OT-Geräte unterstützen keine modernen Identitätsagenten oder häufigen Updates. Definieren Sie eine kontrollierte Zugangsgrenze um solche Ressourcen und prüfen Sie, ob die vermittelnde Lösung zum Gerät und Prozess passt.
Wie beginnt ein Werk ein Zero-Trust-Projekt?
Erfassen Sie Anlagen und Datenflüsse, wählen Sie eine Fernwartungsaufgabe mit engerem Zugriffsbedarf und benennen Sie ihre verantwortliche Person. Entwerfen Sie eine begrenzte Regel und einen Durchsetzungspfad. Testen Sie erlaubte Arbeit, Sperren, Protokollierung, Dienstausfall und Rücknahme, bevor Sie den Umfang erweitern.




