Air-Gapped-Deployments für Verteidigungssoftware: Herausforderungen und Best Practices

Ein Air Gap bezeichnet die physische Isolierung eines Computersystems oder Netzwerks von unsicheren Netzwerken, einschließlich des öffentlichen Internets. Air-Gapped-Systeme verfügen über keine kabelgebundenen oder drahtlosen Verbindungen zu externen Netzwerken; die Datenübertragung erfordert die physische Bewegung zugelassener Speichermedien oder unidirektionaler Datenübertragungsgeräte. Air Gaps sind die grundlegendste Sicherheitsmaßnahme für die sensibelsten eingestuften Informationssysteme: Kein Maß an Softwaresicherheit kann eine physische Netzwerkverbindung kompensieren, wenn das Bedrohungsmodell staatliche Akteure mit ausgefeilten offensiven Cyberfähigkeiten umfasst.

Die Bereitstellung und Pflege moderner Software auf Air-Gapped-Systemen erfordert einen grundlegend anderen Ingenieursansatz als internetverbundene Deployments. Die Komfortfunktionen, auf die Entwicklungsteams angewiesen sind — automatisierte Paketmanager, die Abhängigkeiten aus öffentlichen Repositories abrufen, Container-Images von Docker Hub, CI/CD-Pipelines, die externe SaaS-Dienste nutzen — versagen alle in Air-Gapped-Umgebungen. Die Software muss ohne diese Verbindungen funktionieren, und der Entwicklungs- und Betriebsprozess muss von Anfang an so konzipiert sein, dass er dies unterstützt.

Was Air Gap bedeutet und wo er erforderlich ist

Air Gaps sind überall dort erforderlich, wo die Klassifizierung oder Sensibilität der verarbeiteten Daten oder der kontrollierten Systeme eine physische Netzwerkisolierung rechtfertigt. Im militärischen Kontext:

Sensitive Compartmented Information Facilities (SCIFs) sind physisch gesicherte Räume oder Gebäude, in denen eingestufte Informationen oberhalb von SECRET — insbesondere SCI (Sensitive Compartmented Information) — verarbeitet und besprochen werden können. Computersysteme innerhalb eines SCIF, die SCI-Level-Daten verarbeiten, müssen von Netzwerken isoliert sein, die nicht auf demselben Klassifizierungsniveau akkreditiert sind.

Eingestufte operative Netzwerke — SECRET oder höher — sind von nicht eingestuften Netzwerken isoliert. Die Datenübertragung zwischen Klassifizierungsebenen erfordert eine Cross-Domain Solution (CDS): ein Hardware-Software-System, das Informationstransferregeln zwischen den beiden Netzwerkebenen durchsetzt.

Waffensystemsteuerungen und eingebettete Systeme — Feuerleitsysteme, Navigationssysteme, Radar- und Sensorsteuerungen — sind als Teil ihrer Sicherheitsarchitektur von operativen Netzwerken isoliert. Software-Updates für diese Systeme werden über die Wartungsschnittstelle der Plattform mit zugelassenen Medien bereitgestellt.

Software-Deployment ohne Internet: Artefakt-Registries und Paket-Mirrors

In einer Air-Gapped-Umgebung muss jede Softwareabhängigkeit, die eine Anwendung benötigt, vor dem Deployment in der Umgebung vorhanden sein. Zur Deployment-Zeit kann nichts aus dem Internet abgerufen werden. Dies erfordert den Aufbau eines internen Artefakt-Ökosystems, das die externen Ressourcen spiegelt, auf die die Anwendung sonst angewiesen wäre.

Harbor ist die CNCF-graduierte Open-Source-Container-Registry und die Standardwahl für interne Container-Image-Registries in Air-Gapped-Verteidigungsumgebungen. Harbor bietet: Image-Speicherung und -Replikation, Image-Schwachstellenscanning (über Trivy), Content Trust (digitale Signaturverifizierung für Images) und rollenbasierte Zugriffskontrollen. Das Befüllen der Harbor-Registry erfordert einen Prozess zum Import vorab genehmigter, vorab gescannter Container-Images von außerhalb des Air Gaps über zugelassene Medien.

Offline-Paket-Mirrors replizieren öffentliche Paket-Repositories zur Verwendung innerhalb des Air Gaps. Für Python bedient ein interner PyPI-Mirror (mit Tools wie bandersnatch oder devpi) pip-Anfragen aus der Umgebung heraus. Für npm bedient eine Nexus- oder Artifactory-Instanz (oder das Open-Source-Tool Verdaccio) npm-Anfragen. Der Paket-Mirror muss durch den genehmigten Medienübertragungsprozess befüllt und aktuell gehalten werden.

Der Abhängigkeitsverwaltungsprozess muss explizit sein: Bevor mit der Entwicklung einer Funktion begonnen wird, die in einer Air-Gapped-Umgebung eingesetzt werden soll, muss der Entwickler alle Abhängigkeiten (einschließlich transitiver Abhängigkeiten) explizit identifizieren und überprüfen, ob sie im internen Mirror vorhanden sind. Das Hinzufügen einer neuen Abhängigkeit erfordert einen Medienübertragungsantrag und einen Genehmigungsprozess.

Patch-Management: Geprüfte Bundles und Änderungskontrolle

Patch-Management in Air-Gapped-Umgebungen kann keine automatisierten Patch-Management-Systeme verwenden, die Updates von Cloud-Diensten der Anbieter abrufen. Stattdessen erfordert das Patch-Management einen definierten, dokumentierten Prozess zum Einbringen von Patches von außerhalb des Air Gaps nach innen, deren Test in einer repräsentativen Umgebung und deren Anwendung auf kontrollierte Weise.

Patch-Bundle-Vorbereitung beginnt außerhalb des Air Gaps: Das Patch-Management-Team identifiziert erforderliche Patches, lädt sie herunter, überprüft ihre Authentizität (Prüfsummen- und digitale Signaturverifizierung) und paketiert sie für den Transfer. Das Bundle wird vom Sicherheitsteam geprüft und für den Transfer über den genehmigten Medienablauf freigegeben.

Transfer über zugelassene Wechselmedien ist der Standardmechanismus für den Transport von Patches über den Air Gap. Typische Verfahren umfassen: Verwendung ausschließlich organisationsverwalteter Medien, Virenscanning der Medien auf beiden Seiten des Air Gaps, Verwendung von Einmalmedien (optische Datenträger) für unveränderliche Prüfpfade, Dokumentation jedes Transfers.

Stufenweises Testen ist für Air-Gapped-Betriebssysteme unverhandelbar: Patches müssen in einer Staging-Umgebung, die die Produktionskonfiguration widerspiegelt, getestet werden, bevor sie in der Produktion angewendet werden. Ein Patch, der ein Air-Gapped-Produktionssystem destabilisiert, kann nicht einfach durch Abruf der Vorgängerversion aus einer Internetquelle zurückgespielt werden.

Schlüsselrotation in Air-Gapped-Umgebungen

Geheimnisse — TLS-Zertifikate, Datenbank-Credentials, API-Schlüssel — laufen ab und müssen rotiert werden. In Air-Gapped-Umgebungen funktioniert keiner dieser automatisierten Mechanismen, da sie auf Netzwerkkonnektivität zu Zertifizierungsstellen und Secret-Management-APIs angewiesen sind, die von innerhalb des Air Gaps nicht zugänglich sind.

Hardware Security Modules (HSMs) stellen den Vertrauensanker für kryptografische Operationen in Air-Gapped-Geheimdienstumgebungen dar. Ein HSM (wie ein Thales Luna oder nCipher nShield-Gerät) speichert private Schlüssel in manipulationssicherer Hardware, führt kryptografische Operationen durch, ohne Schlüsselmaterial preiszugeben, und bietet durch FIPS 140-2 Level 3 oder Level 4 validierte Sicherheit.

Offline-Vault- und Schlüsselzeremonie-Verfahren definieren, wie Geheimnisse ohne automatisierte Tools rotiert werden. Eine Schlüsselzeremonie ist ein formales, dokumentiertes Verfahren — mit mehreren autorisierten Mitarbeitern — zur Generierung, zum Laden oder zur Rotation kryptografischer Schlüssel. Für die TLS-Zertifikatsrotation umfasst die Zeremonie die Generierung einer neuen Zertifikatsanforderung, deren Signierung mit dem Offline-CA-Schlüssel (im HSM gespeichert) und die Verteilung des neuen Zertifikats über zugelassene Medien.

CI/CD für Air-Gapped-Umgebungen

Continuous-Integration- und Deployment-Pipelines können in Air-Gapped-Umgebungen mit den richtigen Tool-Entscheidungen betrieben werden. Die Pipeline-Infrastruktur muss vollständig in sich geschlossen innerhalb des Air Gaps sein, ohne Cloud-Service-Abhängigkeiten.

GitLab Community Edition, lokal bereitgestellt, ist die standardmäßige selbst gehostete Git- und CI/CD-Plattform für Air-Gapped-Umgebungen. GitLab CE bietet: Git-Repository-Hosting, Merge-Request-Workflows, CI/CD-Pipeline-Ausführung (über GitLab Runners in derselben Umgebung), Paket-Registry und Container-Registry. Es ist keine Cloud-Konnektivität erforderlich.

GitLab Runners müssen mit Zugriff auf interne Paket-Mirrors (internes PyPI, npm, Maven) konfiguriert werden, anstatt externe Paket-Repositories zu nutzen. Pipeline-Phasen, die normalerweise externe Dienste aufrufen, müssen auf interne Entsprechungen umkonfiguriert oder deaktiviert werden.