Kontrolle statt Risiko – Warum sicherer Remote-Zugriff in der OT kein Widerspruch sein muss
Remote-Zugriff in OT-Umgebungen ist kein „Nice-to-have“ mehr. Ohne ihn stehen Maschinen still, Serviceeinsätze ziehen sich, Hersteller können ihre Anlagen kaum effizient betreiben.
Trotzdem begegnet mir in der Praxis immer wieder dasselbe Spannungsfeld: Security vs. Komfort.
Die gute Nachricht vorweg: Das ist kein echter Widerspruch.
Die schlechte: Für viele fühlt es sich noch so an.
Generische Accounts: ein häufiges Szenario
Stellen wir uns vor: Ein zentrales Speichersystem im Produktionsnetz fällt aus. Bei der Analyse zeigt sich, dass zahlreiche Änderungen an der Systemkonfiguration vorgenommen wurden – am Netzwerk, an der Speicherzuweisung, an weiteren Parametern.
Die Analyse zeigt:
- Die Konfigurationen wurden über einen generischen Account durchgeführt
- Es gibt keine eindeutige Benutzeridentität
- Das Quellsystem der administrativen Verbindung ist nicht nachvollziehbar
- Es existieren weder Logs noch Sitzungsaufzeichnungen
Kurz: Intransparenz und fehlende Kontrolle.
Das eigentliche Problem ist die fehlende Kontrolle
Remote-Zugriff an sich ist für mich nicht das Hauptrisiko. Er ist aus unserem Alltag nicht mehr wegzudenken. Das eigentliche Risiko liegt in der fehlenden Kontrolle. In der Intransparenz. In fehlenden Prozessen.
Typische Schwachstellen im Kontext von Remote-Zugriffen sind unter anderem:
- Geteilte oder generische Accounts
- Überprivilegierte Accounts
- Unzureichende Authentifizierung
- Dauerhafte Verbindungen
- Fehlende Freigabeprozesse und technische Kontrollen
- Unzureichende Protokollierung
- Fehlende oder unzureichende Netzwerksegmentierung
Das ist übrigens kein Bauchgefühl. Diese Risiken fordern uns alle heraus, mal mehr, mal weniger. Sie decken sich übrigens mit den Anforderungen der IEC-62443.
Warum scheitern Sicherheitskonzepte in der Praxis?
In den meisten Fällen ist nicht die Technologie das Problem. Es gibt hervorragende Lösungen am Markt – für große wie kleine Umgebungen, für komplexe wie einfache Anforderungen.
Die Herausforderung liegt im organisatorischen Bereich:
- Akzeptanz im Betrieb. Wenn Sicherheitslösungen den Arbeitsalltag komplizierter machen, werden sie umgangen.
- Unklare Prozesse. Wer darf wann auf welche Systeme zugreifen? Wann muss eine Anforderung gestellt werden? Wer gibt sie frei? Wer trägt die Verantwortung? Ohne klare Prozesse scheitert auch die beste Technologie.
- Historisch gewachsene Strukturen. Viele Umgebungen sind nicht designed, sondern gewachsen. Das ist eher die Regel als die Ausnahme – und genau das macht Security-Architekturen anspruchsvoll. Lösbar ist es trotzdem.
Daraus folgt: Sichere Fernwartung ist nie nur eine technische, sondern vor allem eine organisatorische Aufgabe.
Was können wir tun?
Kontrolle schaffen, ohne den Betrieb auszubremsen. Diese Grundprinzipien helfen, bedarfsgerecht angewendet:
- Identität statt Anonymität
- Keine geteilten Accounts
- Klare Benutzeridentitäten
- MFA als Standard
- Zugriff nur, wenn er gebraucht wird
- Just-in-Time-Zugriffe
- Klare Freigabeprozesse
- Zeitlich begrenzte Sessions
- Netzwerkarchitektur
- Trennung von IT, OT und DMZ
- Kein direkter Zugriff aus der Ferne in die OT-Umgebung
- Übergänge nur über klar definierte Punkte (Jump Hosts, Gateways)
- Transparenz schaffen
- Monitoring
- Session Recording
- Umfangreiche, möglichst zentrale Protokollierung
- Akzeptanz schaffen
- Menschen mitnehmen
- Lösungen bedienbar gestalten
- Prozesse verständlich halten
VPN, Jump Host oder PAM?
Welche Lösung ist die richtige? Wir kennen die Antwort schon: Es kommt darauf an.
Typische Optionen sind:
- Klassisches VPN (mit der Frage: Wo terminiert der Tunnel?)
- Jump Host / Bastion Host
- Remote Access Gateways
- Privileged Access Management
Diese Ansätze lassen sich auf unterschiedlichen Wegen kombinieren. Den einen richtigen Weg für alle gibt es nicht. Die Wahl muss situativ und zielgerichtet getroffen werden.
Fazit
Aus meiner Sicht gibt es für jede Umgebung eine passende Lösung. Was zählt, sind klare Zielsetzungen und eine gründliche Planung. Ich bin ein großer Freund von Proof-of-Concepts: Nicht alles lässt sich in der Theorie abbilden. Nehmen Sie sich die Zeit. Denn einmal eingeführt, lässt sich eine Fehlentscheidung nur mühsam revidieren.