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.
OT-Proxy in IndustrialFlowDer OT-Proxy-Agent löst ein konkretes Dilemma: CI/CD-Pipelines sollen in OT-Zielsysteme deployen, dürfen aber die nach IEC 62443 errichtete Netzwerksegmentierung nicht durchbohren. Statt einen offenen Pfad von der IT in die OT-Zone zu schaffen, läuft der Agent in der Fertigungs-DMZ und nimmt Aufträge nur ausgehend entgegen oder pollt sie ab. Die OT-Zone initiiert oder akzeptiert die Verbindung kontrolliert; ein Angreifer in der IT findet keinen offenen eingehenden Port in die Steuerungsebene.
Funktional übersetzt der Agent zwischen den Welten: Er empfängt einen abstrakten Deployment-Befehl, prüft über OPC UA oder herstellerspezifische Schnittstellen den Maschinenzustand, setzt das Artefakt nur innerhalb des erlaubten Wartungsfensters um und protokolliert jeden Schritt manipulationssicher. Die Kommunikation ist TLS-gesichert mit gegenseitiger Zertifikats-Authentifizierung, sodass nur autorisierte Pipelines überhaupt Aufträge erteilen können.
Damit ist der Agent ein zentraler Baustein OT-nativer CI/CD-Plattformen und macht den Unterschied zwischen einer Pipeline, die in der IT endet, und einer, die wirklich bis zur Maschine reicht. Stolpersteine liegen weniger in der Technik als in der Governance: Wer das Zertifikats- und Berechtigungsmanagement schludert, untergräbt genau die Sicherheit, die der Agent schützen soll. Ebenso wichtig ist, dass der Agent selbst gehärtet, versioniert und überwacht wird — er ist ein hochprivilegierter Knoten an der Zonengrenze.
Pull-basierter Deploy über die DMZ
Ein Agent in der Fertigungs-DMZ pollt die Pipeline nach freigegebenen Deployment-Aufträgen, statt eingehende Verbindungen aus der IT zu erlauben — so bleibt die OT-Zone von außen unangreifbar, während Deployments dennoch automatisiert ablaufen.
Maschinen-Gate vor dem Rollout
Vor jedem Rollout prüft der Agent per OPC UA, ob die Zielanlage im sicheren Zustand und außerhalb einer laufenden Produktion ist, und verweigert das Deployment andernfalls mit einem protokollierten Hinweis.
- 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 aufweichen und eine Angriffsfläche schaffen würde. Der OT-Proxy-Agent kapselt den Übergang in der DMZ, arbeitet bevorzugt pull-basiert und stellt sicher, dass nur autorisierte, protokollierte Aufträge die Steuerungsebene erreichen.
- Wie wird der OT-Proxy-Agent abgesichert?
- Über gegenseitige Zertifikats-Authentifizierung, TLS-verschlüsselte Kommunikation, ein minimales Berechtigungsmodell und manipulationssichere Audit-Logs. Der Agent selbst sollte gehärtet, versioniert und überwacht werden, da er als privilegierter Knoten an der Zonengrenze ein attraktives Angriffsziel ist.
- Funktioniert das Konzept auch in air-gapped Umgebungen?
- Ja, gerade dort ist es relevant. In vollständig getrennten Netzen übernimmt der Agent den kontrollierten, protokollierten Transfer freigegebener Artefakte, ohne dass eine permanente Verbindung zwischen IT und OT bestehen muss. Das passt zu Air-Gap- und KRITIS-Szenarien mit strengen Datenresidenz-Anforderungen.
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