Was macht ein OT-Proxy-Agent in der CI/CD-Pipeline?
Ein OT-Proxy-Agent läuft in der Fertigungs-DMZ und überbrückt die Netzwerksegmentierung zwischen IT- und OT-Zone, ohne sie aufzuweichen. Deployment-Befehle werden über TLS-gesicherte Tunnel mit Zertifikats-Auth weitergeleitet, der Agent prüft Maschinenstatus via OPC UA, hält Wartungsfenster ein und protokolliert jede Aktion im Audit-Log. So bleibt das IEC 62443-Zonen- und Conduit-Modell intakt, während CI/CD-Pipelines trotzdem in OT-Zielsysteme deployen können.
Auch bekannt als: OT-Proxy · Proxy-Agent für OT-Netze
Ist OT-Proxy-Agent bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Ein Deployment über den OT-Proxy-Agent läuft in vier Schritten. Die Pipeline in der IT legt einen freigegebenen Auftrag mit signiertem Artefakt ab. Der Agent in der Fertigungs-DMZ, der Pufferzone zwischen IT- und OT-Netz, holt sich diesen Auftrag über eine Verbindung, die er selbst aufbaut. Anschließend prüft er über OPC UA oder eine herstellerspezifische Schnittstelle, ob die Zielmaschine im sicheren Zustand ist und das Wartungsfenster offen steht. Erst dann bringt er das Artefakt in die OT-Zone und schreibt jeden Schritt in ein manipulationssicheres Audit-Log. Weil der Agent die Verbindungen aufbaut, braucht es keinen eingehenden Port aus der IT in Richtung Steuerungsebene, und die nach IEC 62443 eingerichtete Segmentierung bleibt intakt.
Die Verbindungen sind per TLS verschlüsselt, beide Seiten weisen sich gegenseitig mit Zertifikaten aus. Nur Pipelines mit gültigem Zertifikat können überhaupt Aufträge erteilen. Damit wird der Agent zum Unterschied zwischen einer Pipeline, die in der IT endet, und einer, die bis zur Maschine reicht. Wie groß dieser Unterschied ist, merkt ein Team beim ersten Deployment, das ohne USB-Stick, ohne Turnschuh-Administration und ohne Loch in der Segmentierung auf der Maschine ankommt.
Die Stolpersteine liegen weniger in der Technik als in der Governance. Wer Zertifikate und Berechtigungen nachlässig verwaltet, untergräbt genau die Sicherheit, die der Agent herstellen soll. Der Agent selbst muss gehärtet, versioniert und überwacht werden, denn er ist ein hochprivilegierter Knoten an der Zonengrenze. Ein nie rotiertes Zertifikat an genau dieser Stelle ist der eine Audit-Befund, der das ganze Konzept entwertet.
Deployment über die DMZ ohne eingehende Verbindung
Ein Werk wollte automatisierte Deployments, aber die Security-Abteilung lehnte jede eingehende Verbindung aus der IT in die Fertigung ab. Der Agent in der Fertigungs-DMZ fragt die Pipeline deshalb in festen Abständen nach freigegebenen Aufträgen und baut die Verbindung dafür selbst auf. Die Firewall-Regel für eingehenden Verkehr bleibt geschlossen, und Deployments laufen trotzdem ohne manuellen Schritt.
Deployment abgelehnt, weil die Anlage produziert
Eine Pipeline stößt nachmittags ein Rollout an, während die Zielanlage noch einen Auftrag fertigt. Der Agent liest per OPC UA den Betriebszustand, erkennt die laufende Produktion und verweigert das Deployment mit einem Eintrag im Audit-Log. Im nächsten Wartungsfenster läuft derselbe Auftrag durch, ohne dass jemand ihn neu anstoßen muss.
Wozu brauchen Sie einen OT-Proxy-Agent?
Ein OT-Proxy-Agent überbrückt die IT/OT-Segmentierung, ohne sie aufzuweichen — der passende Einstieg hängt an Ihrem Ziel. Zwei Klicks ordnen ein.
Was wollen Sie erreichen?
- Warum nicht direkt aus der CI/CD-Pipeline in die OT deployen?
- Weil ein direkter Pfad von der IT in die OT-Zone die Netzwerksegmentierung nach IEC 62443 aufweicht. Ein Angreifer, der einen Build-Server übernimmt, hätte dann einen offenen Weg bis zur Steuerung. Der OT-Proxy-Agent kapselt den Übergang in der DMZ, baut seine Verbindungen selbst auf und lässt nur autorisierte, protokollierte Aufträge bis zur Steuerungsebene durch.
- Wie wird der OT-Proxy-Agent abgesichert?
- Mit gegenseitiger Zertifikats-Authentifizierung, TLS-verschlüsselter Kommunikation, einem minimalen Berechtigungsmodell und manipulationssicheren Audit-Logs. Der Agent selbst wird gehärtet, versioniert und überwacht wie jede andere kritische Komponente. Als privilegierter Knoten an der Zonengrenze ist er ein attraktives Angriffsziel.
- Funktioniert das Konzept auch in air-gapped Umgebungen?
- Ja, dort ist es sogar besonders sinnvoll. Ohne permanente Verbindung zwischen IT und OT erreichen freigegebene Artefakte den Agenten über einen definierten Transferweg, etwa eine Datendiode oder ein geprüftes Transfermedium. Der Agent prüft Signatur und Freigabe, bevor er etwas ausrollt, und protokolliert den Vorgang. Das passt zu Air-Gap- und KRITIS-Szenarien mit strengen Anforderungen an die Datenresidenz.
Wo steht Ihr Team bei OT-Proxy-Agent?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu OT-Proxy-Agent: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01JenkinsJenkins Agents nutzen(externe Seite, öffnet in neuem Tab)
Wie Agents an den Controller angebunden werden und wer die Verbindung aufbaut.
- /02NISTNIST SP 800-82 Rev. 3(externe Seite, öffnet in neuem Tab)
Vorgaben für Übergänge zwischen Büro- und Anlagennetz, auf denen ein Proxy-Agent aufsetzt.
- /03International Society of AutomationISA/IEC 62443 Normenreihe(externe Seite, öffnet in neuem Tab)
Definiert Conduits als einzig zulässigen Weg zwischen zwei Sicherheitszonen.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance