Air-Gap CI/CD

Im isolierten Netz steht alles, was eine Pipeline sonst aus dem Internet holt: Build-Server, Container-Registry, ein Mirror für Plugins und Pakete, ein Artefakt-Repository und inzwischen auch das KI-Modell. Neue Inhalte gelangen nur über eine Schleuse hinein. Außerhalb des Netzes werden Updates heruntergeladen, auf Schadcode geprüft und signiert. Anschließend überträgt ein kontrollierter Kanal sie in den Mirror, etwa eine Datendiode oder ein freigegebener Transfer-Server, und im Netz prüft die Pipeline die Signatur, bevor sie ein Paket nutzt. Air-Gap beschreibt streng genommen die vollständige physische Trennung. In der Praxis sind solche kontrollierten Schleusen der Normalfall.

Mehrere Gründe führen dazu, dass mehr Unternehmen ihre Pipelines so betreiben. Das Zonenmodell der IEC 62443 sieht für OT-Netze ohnehin Segmentierung vor. Betreiber kritischer Anlagen und viele Industriekunden verlangen vertraglich, dass Quellcode und Build-Daten ihr Netz nicht verlassen. NIS2 schreibt kein Air-Gap vor, fordert in Artikel 21 aber Risikomanagement einschließlich der Sicherheit der Lieferkette. Wer jede Abhängigkeit über eine geprüfte Schleuse bezieht, kann diese Kette belegen. Und KI-Assistenz braucht keine Cloud-API mehr: Lokal betriebene Modelle, etwa über Ollama, laufen auch im abgeschotteten Netz.

Aufwendig sind die Versorgung und die Aktualität. Jedes Update, jedes Plugin und jedes Basis-Image muss den Import-Prozess durchlaufen, und bei lokalen KI-Modellen sind das Dateien von mehreren Gigabyte. Die Isolation schützt nur so lange, wie der Mirror gepflegt wird. Ohne feste Import-Termine konserviert das Air-Gap die Sicherheitslücken von vor zwei Jahren, und niemand merkt es, weil kein Scanner von außen hineinschaut. Plattformen, die von Anfang an für Air-Gap-Betrieb gebaut sind, wie IndustrialFlow, bringen Mirror, Import-Prozess und Offline-KI mit, statt sie nachträglich aufzusetzen.