Der vergessene Fernwartungszugang

Nopphon_1987 | shutterstock.com

Wenn ich in einer historisch gewachsenen Industrieanlage eine Bestandsaufnahme der Fernzugänge durchführe, begegnen mir immer wieder dieselben Artefakte:

• der VPN-Tunnel des Maschinenherstellers aus dem Projekt von vor acht Jahren,





• der Mobilfunkrouter im Schaltschrank, an dessen Bestellung sich niemand mehr erinnert oder





• das Fernwartungs-Tool auf der Engineering-Workstation, dessen Lizenz noch auf einen längst ausgeschiedenen Servicetechniker läuft.

Bislang habe ich Bestandsaufnahmen dieser Art in der Energiewirtschaft, der Fertigungsbranche und der Pharmaindustrie begleitet – und noch keine erlebt, die keinen vergessenen Zugang zutage gefördert hätte. Diese wurden nicht mit bösen Hintergedanken eingerichtet, sondern lösten einst ein reales Verfügbarkeitsproblem. Heute bieten sie allerdings unbeaufsichtigten Zugang zu Produktionssystemen.

In diesem Beitrag vermittle ich warum Zugänge dieser Art trotz aller Warnungen oft „überleben“ – und an welchem Punkt die Infrastrukturbetreiber ansetzen können, um das künftig zu ändern.

Darum überleben industrielle Hintertüren

Dass das eben beschriebene Szenario nicht bloß theoretischer Natur ist, lässt sich auch mit harten Zahlen unterfüttern: Laut dem aktuellen SANS-Whitepaper „State of ICS/OT Security“ (Download gegen Daten) bildeten nicht-autorisierte externe Zugriffe (häufig über Remote-Wartungskanäle für Dienstleister) den Startpunkt für rund 50 Prozent aller Sicherheitsvorfälle in Industrieumgebungen. Gleichzeitig fördert die Erhebung auch zutage, dass weniger als 15 Prozent der Infrastrukturbetreiber über robuste Remote-Access-Kontrollen verfügen.

Hinzu kommt noch regulatorischer Druck: Seit Anfang Dezember 2025 ist das NIS-2-Umsetzungsgesetz ohne Übergangsfrist in Kraft. Dieses verpflichtet rund 30.000 regulierte Organisationen in Deutschland ausdrücklich dazu, ihre Lieferketten abzusichern, Access-Control-Konzepte zu entwickeln und durchzusetzen sowie Multi-Faktor-Authentifizierung zu nutzen. Für die Umsetzung dieser Maßnahmen haftet die Geschäftsleitung persönlich. Ein Fernwartungszugang für Drittanbieter liegt in der Schnittmenge der genannten Pflichten – und ist damit kein Maintenance-Nischenthema mehr, sondern ein Prüfstein für Compliance.

Wenn ich die Verantwortlichen im Unternehmen ganz direkt frage, warum so ein Tunnel für Dienstleister immer noch offen ist, höre ich selten Ausreden. Genannt werden vor allem vier strukturelle Begründungen.  

• Die Gewährleistungskopplung: Viele Hersteller knüpfen Garantien – etwa bezüglich Reaktionszeiten – daran, dass ihre eigenen Standards für die Fernwartung genutzt werden.





• Die Machtasymmetrie: Ein einzelner Betreiber verhandelt mit einem globalen Maschinenbauer, dessen Servicebedingungen für Hunderte von Kunden identisch sind.





• Die Brownfield-Realität: Die Zugänge sind über Jahre in Einzelprojekten entstanden, die Verantwortung diffundiert zwischen Instandhaltung, IT und Einkauf – niemand fühlt sich zuständig.





• Die Verfügbarkeitslogik: Der offene Tunnel wirkt wie eine Versicherung gegen Stillstand. Das Cyberrisiko ist abstrakt, der Produktionsausfall konkret – und über die Kennzahlen des Werksleiters entscheidet der Ausfall, nicht das Audit.

Ein Absicherungskonzept, das diese Kräfte ignoriert, bleibt Papier. Deshalb ordne ich die Maßnahmen in meinen Projekten bewusst so an: Transparenz zuerst, dann Vertrag, Technik und schließlich Betrieb.

Industrielle Access-Hygiene in der Praxis

Dabei beginne ich mit einer Liste, die darüber Auskunft gibt, wer aktuell aus welchem Grund Zugriff über welchen Kanal hat und seit wann. Die Quellen sind dabei unspektakulär: Firewall-Regelwerke, VPN-Konten, externe Accounts im Verzeichnisdienst, Mobilfunkverbindungen in Schaltschränken, installierte Fernwartungs-Tools. Ergänzend kommen Gespräche mit der Instandhaltung dazu, denn ein erheblicher Teil der Zugänge existiert nur in Köpfen, nicht in Dokumenten. Im Ergebnis steht ein Zugangsregister mit Eigentümer, Zweck, Zugriffspfad und Befristung. Accounts für die sich kein interner Eigentümer findet, werden nach Ablauf einer definierten Einspruchsfrist abgeschaltet. Das betrifft im Regelfall einen zweistelligen Prozentsatz der bestehenden Zugänge. In diesen Fällen „kostet“ es also lediglich eine Abstimmungsrunde, um die Risiken zu reduzieren.

Für das was übrig bleibt, gilt der Grundsatz Anforderungen vor Zugang. Bevor ein solcher eingerichtet wird, müssen Leistungsumfang und Vertraulichkeit geregelt werden. Bei missionskritischen Zulieferern oder Dienstleistern sollten zudem zusätzlich Security-Anforderungen auch vertraglich festgelegt werden. Zwei Details machen dabei den Unterschied zwischen belastbaren und symbolischen Verträgen:

• eine Vererbungspflicht, die dem Lieferanten auferlegt, dieselben Sicherheitskontrollen an seine Subunternehmer weiterzureichen, bevor diese Zugriff erhalten, und





• ein definierter Ersatz für verweigerte Auditrechte, etwa unabhängige Prüfberichte, die der Dienstleister jährlich vorlegt. Statt eigene Kataloge zu erfinden, referenziere ich die IEC 62443-2-4, die genau diese Anforderungen an Service-Provider normiert.

Bei Richtlinienprüfungen werfe ich zuerst einen Blick auf ein unscheinbares Detail: das Modalverb. Denn in den Regelwerken, die ich in den vergangenen Jahren für Energie-, Industrie- und Pharmaunternehmen geprüft oder mitgeschrieben habe, definiert die Unterscheidung zwischen „muss“ und „sollte“, wie die Realität aussieht: Ist die Befristung externer Konten als Muss-Regel mit automatischem Ablauf formuliert, verfallen die Konten tatsächlich. Wird dieselbe Anforderung als Empfehlung mit Jahresfrist festgehalten, finden sich beim nächsten Audit dieselben Karteileichen wie bei dem zuvor. Oder anders formuliert: Im ersten Fall wirkt das Regelwerk, im zweiten ist es lediglich Dekoration.

An dieser Stelle begegnet mir immer wieder das hartnäckige Gegenargument, dass ohne den Standard-Remote-Zugang die Gewährleistung erlischt. Dieses Problem lässt sich in meiner Erfahrung auf drei verschiedene Weisen lösen:

• Verhandlungsfenster nutzen: Neubeschaffung, Retrofit und die Verlängerung von Serviceverträgen sind die Momente, in denen sich Anforderungen durchsetzen lassen.





• Rechtslage neu bewerten: Der Betreiber ist gesetzlich dazu verpflichtet, seine Lieferkette abzusichern. Ein Standardzugang, der dem entgegensteht, stellt insofern ein rechtliches Risiko dar – zunehmend auch für den Hersteller, der als Teil der Lieferkette in den Pflichtenkreis seiner Kunden rückt.





• Kompensieren, wo sich nichts durchsetzen lässt: Ein Fernwartungszugang ließe sich beispielsweise auf ein betreibereigenes Gateway beschränken, das standardmäßig von den Produktionssystemen getrennt ist und gesondert überwacht wird. Entscheidend ist an dieser Stelle, dass eine Risikoentscheidung getroffen und dokumentiert wird – statt den Status Quo weiter still zu dulden.

Technisch folgt der Rest dem Single-Channel-Prinzip: Alle externen Zugriffe laufen über eine dedizierte Fernwartungs-DMZ und gehärtete Sprungserver. Direkte RDP-, SSH- oder VNC-Logins in OT-Systeme sind ebenso tabu wie herstellereigene Parallelwege über Cloud-Portale oder mitgebrachte Mobilfunkrouter. Multi-Faktor-Authentifizierung ist gesetzt. Derselbe Grundsatz gilt für On-Premises-Zugänge: Dienstleister-Devices, -Modems, und -Smartphones müssen draußen bleiben, USB-Ports sind standardmäßig deaktiviert. In OT-Umgebungen sollten ausschließlich dedizierte, betreibereigene Engineering-Devices zum Einsatz kommen.

Sammelkonten wie „Service“ oder „Wartung“ ersetze ich dabei durch personalisierte Kennungen im Verzeichnisdienst des Betreibers – nur so entstehen Zurechenbarkeit und die Möglichkeit für ein sauberes Offboarding. Reife heißt dabei nicht null Ausnahmen, sondern Ausnahmen mit Preisschild: Wo ein Altsystem technisch keine individuellen Konten unterstützt, sollten gute Regelwerke ein lückenloses Zugriffsprotokoll generieren, das jede einzelne Anmeldung einer physischen Person zuordnet und eine Genehmigung durch das Security-Team erfordert. Der Default-Zustand ist dann bei jedem Zugang grundsätzlich „deaktiviert“. Aktiviert wird er je nach Einsatzzweck durch den Asset Owner – inklusive definiertem Zeitfenster für den Zugang, das an die Vertragslaufzeit gekoppelt ist.

Die konsequentesten Umsetzungen, die mir begegnet sind, gehen noch einen Schritt weiter: Externe Konten verfallen dort automatisch nach sechs Monaten und brauchen eine aktive Neugenehmigung. Privilegierte Zugänge werden zusätzlich halbjährlich rezertifiziert – in Hochrisikozonen durch eine unabhängige Stelle. Und: Nach 90 Tagen Inaktivität wird jeder Account automatisch gelöscht. Das sorgt für eine „Beweislastumkehr“: Nicht die Sperrung eines Kontos muss dann begründet werden, sondern dessen Fortbestand.

Auch an dieser Stelle begegnen mir regelmäßig zweierlei Einwände:

1. „Was passiert bei der Störung am Samstagabend, wenn kein Asset Owner erreichbar ist?“ – die Antwort ist ein Break-Glass-Prozess – eine vordefinierte Notfallfreigabe durch die Leitwarte oder Rufbereitschaft, eng befristet, mit automatischer Alarmierung, verpflichtender Sitzungsaufzeichnung und nachträglicher Genehmigung binnen 24 Stunden. Eine besonders elegante Lösung: Regelwerke, die Notfallrechte temporär der persönlichen Kennung des Technikers zuweisen statt einem anonymen Notfallkonto – die Zurechenbarkeit bleibt erhalten – und wo dedizierte Notfallkonten unvermeidbar sind, liegen sie in einem Passwort-Tresor, dessen Öffnung selbst wieder Authentifizierung und Protokoll erzwingt. Ohne diesen Prozess scheitert jedes Just-in-Time-Modell an der ersten Nachtschicht, die es umgeht.





2. „Unsere Altsysteme können kein MFA.“ – das müssen sie auch nicht, die Kontrolle wandert an den Rand. Identitätsprüfung und MFA werden am Sprungserver erzwungen, das Altsystem sieht nur dessen Sitzung. Die Systempasswörter liegen im Kennwort-Tresor eines Privileged-Access-Management-Systems und werden dem Techniker nie angezeigt, sondern automatisch in die Sitzung injiziert. Das entschärft nebenbei das Problem, dass Gerätepasswörter den Dienstleister überleben, wenn dessen Techniker wechseln.

Bleibt die Beweisfähigkeit: Wer wann über welchen Weg auf welches System zugegriffen hat, muss über die Systeme des Betreibers nachweisbar sein – im eigenen SIEM, nicht in den Protokollen des Dienstleisters. Und Protokollierung meint dabei mehr, als lediglich An- und Abmeldungen zu erfassen: Erst wenn Befehle, Dateizugriffe und Parameteränderungen innerhalb der Sitzung erfasst werden, weiß man mehr, als dass „sich jemand eingeloggt“ hat. Die konsequentesten Regelwerke machen Admin-Protokolle für den Administrator selbst unveränderbar und überwachen das PAM-System seinerseits per SIEM – da ansonsten niemand mehr das Tool kontrolliert, das alles andere kontrolliert.

Kommt es zu einem Sicherheitsvorfall, müssen Betreiber, die auf Logs der Gegenseite angewiesen sind, aus der Defensive heraus verhandeln. Angesichts der persönlichen Haftung des Managements ist das kein forensisches Detail, sondern Selbstschutz. Am (Vertrags-)Ende steht dann schließlich noch der richtige Rückbau: Konten müssen deaktiviert, temporäre Firewall-Regeln entfernt sowie Token und Zertifikate deprovisioniert werden – gekoppelt an den Lieferantenstatus im Einkaufssystem, nicht an eine manuelle E-Mail. Der häufigste Befund in Access-Audits sind aktive Konten aus längst beendeten Verträgen.

OT-Risiken reduzieren mit dem 4-Stufen-Ansatz

Fünfzehn Maßnahmen parallel zu fahren, dürfte nahezu jede Organisation überfordern. Ich priorisiere die Risikoreduktion nach Aufwand in vier Stufen:

• Stufe 1 sieht die Inventur und die Abschaltung von Zugängen ohne Eigentümer vor. Das gewährleistet eine hohe Wirkung bei gleichzeitig geringem Aufwand – auch zeitlich, denn das ist in Wochen umsetzbar.





• Stufe 2 verlangt einen zentralen Zugriffskanal mit DMZ, Sprungservern und ausnahmsloser MFA vor. Auch hier steht im Ergebnis eine hohe Wirkung – bei mittlerem Aufwand. Die Umsetzungszeit liegt im Bereich von Monaten.





• Stufe 3 setzt einen Just-in-Time-Freigabeprozess mit Befristung und Break-Glass-Verfahren voraus. Hier ist der Aufwand vor allem organisatorischer Natur.





• Stufe 4 erfordert ein PAM mit Kennwort-Tresor, Sitzungsaufzeichnung und SIEM-Anbindung. Das gewährleistet Nachweisbarkeit und Auditreife. Wie groß der Abstand zwischen Anspruch und Realität gerade hier ist, verdeutlicht ebenfalls ein Blick in die vorgenannte SANS-Erhebung: Demnach haben nur circa 13 Prozent der Infrastruktubetreiber Session-Aufzeichnungen und Echtzeit-Freigaben vollständig implementiert.

Mein Fazit nach diversen Projekten dieser Art: Ein Dienstleisterzugang stellt keinen Zustand dar, sondern braucht einen Lebenszyklus – er muss beantragt, befristet, überwacht und zurückgebaut werden. Die Technik dafür ist seit Jahren verfügbar. Wer heute mit der Access-Inventur beginnt und den zentralen Kanal konsequent durchsetzt, kann bereits mit der Umsetzung von Stufe 1 und 2 einen Großteil der Risiken reduzieren – und parallel Compliance sicherstellen.

Wie sich diese Bausteine zu einem vollständigen ISMS für die Industrie zusammenfügen lassen, lesen Sie in ausführlicher Form in meinem Praxisratgeber, der im September bei Springer Vieweg erscheint. (fm)

Dieser Beitrag wurde im Rahmen des deutschsprachigen Experten-Netzwerks von Foundry veröffentlicht. Lust mitzumachen? Jetzt bewerben!