Das Air-Gapped-Paradigma: Sicherheitsarchitekturen für isolierte On-Premise-Umgebungen
David Hussain 5 Minuten Lesezeit

Das Air-Gapped-Paradigma: Sicherheitsarchitekturen für isolierte On-Premise-Umgebungen

In der Diskussion über die Cloud-Transformation herrscht oft das Narrativ vor, dass die Zukunft der IT ausschließlich in global vernetzten, öffentlichen Cloud-Infrastrukturen liegt. Doch für Betreiber kritischer Infrastrukturen (KRITIS), Verteidigungsunternehmen, forschungsnahe Industrien oder stark regulierte Branchen im Finanz- und Gesundheitswesen sieht die Realität völlig anders aus. Wenn Systeme nukleare Leitstände, medizinische Kernbereiche oder sensible Staatsgeheimnisse steuern, ist das Risiko einer Internetanbindung schlicht untragbar.

In der Diskussion über die Cloud-Transformation herrscht oft das Narrativ vor, dass die Zukunft der IT ausschließlich in global vernetzten, öffentlichen Cloud-Infrastrukturen liegt. Doch für Betreiber kritischer Infrastrukturen (KRITIS), Verteidigungsunternehmen, forschungsnahe Industrien oder stark regulierte Branchen im Finanz- und Gesundheitswesen sieht die Realität völlig anders aus. Wenn Systeme nukleare Leitstände, medizinische Kernbereiche oder sensible Staatsgeheimnisse steuern, ist das Risiko einer Internetanbindung schlicht untragbar.

Die ultimative Sicherheitsstufe für solche hochsensiblen Workloads ist das Air-Gapped-Paradigma – der Betrieb von IT-Infrastrukturen in physisch und logisch vollkommen vom Internet abgeschotteten Umgebungen. Doch auch in diesen „digitalen Festungen" wollen und müssen moderne Entwicklungsteams agile Technologien wie Docker, containerd und Kubernetes nutzen. Die architektonische Herausforderung lautet: Wie betreibt man eine hochverfügbare Container Registry, wenn kein einziges Paket jemals „nach Hause telefonieren" oder öffentliche Repositories (wie Docker Hub) abfragen darf?

Die Herausforderung im isolierten Netz: Das Abhängigkeits-Dilemma

Moderne Softwareentwicklung lebt von externen Abhängigkeiten. Ein typisches containerisiertes Anwendungs-Projekt zieht im Hintergrund dutzende Base-Images, Bibliotheken und Hilfs-Tools aus dem Internet.

Wird ein Kubernetes-Cluster eins zu eins in eine Air-Gapped-Umgebung verpflanzt, bricht diese Pipeline an drei Stellen sofort zusammen:

1. Das „Pull-Vakuum" an den Nodes

Wenn ein Kubernetes-Node den Befehl erhält, einen neuen Pod zu starten, versucht die lokale Container-Runtime (containerd), das entsprechende Image herunterzuladen. In einem Air-Gapped-System läuft dieser Versuch unweigerlich in einen Netzwerk-Timeout. Ohne eine lokale, voll funktionsfähige Spiegel-Instanz bleibt das Cluster komplett handlungsunfähig.

2. Die Blockade von Software-Updates und Patches

Sicherheitsrelevante Vorgaben wie NIS-2, DORA oder der Cyber Resilience Act (CRA) fordern auch in geschlossenen Netzen ein proaktives Schwachstellen- und Update-Management. Wenn der integrierte CVE-Scanner in der Registry jedoch keine Internetverbindung besitzt, um seine internen Schwachstellen-Datenbanken zu aktualisieren, altert das Sicherheitsniveau des Systems mit jedem Tag, an dem es isoliert ist.

3. Das Fehlen von globaler Ausfallsicherheit (Disaster Recovery)

Air-Gapped bedeutet nicht zwangsläufig, dass es nur ein einziges Rechenzentrum gibt. Große Organisationen betreiben oft mehrere isolierte Standorte. Ohne eine automatisierte, netzwerkinterne Replikation zwischen den Standorten artet das Synchronisieren von Software-Ständen in manuelle, fehleranfällige Datenträger-Exporte (Turnschuh-Netzwerk via USB-Stick/Festplatte) aus.

Die Architektur der souveränen Festung: Harbor im Air-Gapped-Betrieb

Um moderne Cloud-Native-Workflows ohne Internet-Kompromisse in isolierte Netze zu bringen, wird eine On-Premises-Infrastruktur aufgebaut, bei der die Container Registry als autarkes Software-Asset agiert. Das technologische Fundament hierfür bildet eine verwaltete Harbor-Registry, gekoppelt mit einem lokalen S3-kompatiblen Objektspeicher (z. B. via Ceph).

1. Das Schleusen-Prinzip für den Datentransfer (Secure Ingestion)

Da kein direkter Datenfluss aus dem Internet erlaubt ist, wird ein streng kontrollierter, asynchroner Import-Prozess etabliert. Images werden in einer separaten, internetfähigen Staging-Umgebung gebaut, vollautomatisch gescannt und kryptografisch signiert. Anschließend werden die OCI-Artefakte als tar-Archive exportiert, über eine physische Datenschleuse (Datadiode oder dedizierte Transfer-Medien) geprüft und in die isolierte Harbor-Registry des Air-Gapped-Netzes eingespielt.

2. Autarkes Storage-Backend via S3 auf eigener Infrastruktur

Die Harbor-Registry speichert die Container-Layers nicht auf lokalen Festplatten einzelner Server, sondern nutzt im Hintergrund ein hochverfügbares, On-Premises betriebenes S3-Storage-Cluster. Dadurch bleibt die Speicher-Architektur vollkommen identisch zu modernen Public-Cloud-Umgebungen: Skalierbarkeit, Verschlüsselung at rest(via Customer-Managed Keys) und Objektsicherheit werden direkt im eigenen Rechenzentrum abgebildet, ohne Abhängigkeiten zu externen Cloud-Hyperscalern.

3. Lokale Geo-Replication über geschützte Leitungen

Betreibt das Unternehmen mehrere Air-Gapped-Standorte, nutzt die Plattform die integrierte Geo-Replikations-Engine von Harbor. Sobald ein neues, verifiziertes Image an Hauptstandort A freigegeben und eingepflegt wird, pusht Harbor dieses Artefakt im Hintergrund über dedizierte, verschlüsselte Werksleitungen an die Harbor-Registries der Standorte B und C. Die lokalen Kubernetes-Cluster an allen Standorten können das Image mit maximaler Performance und ohne Latenz direkt aus ihrem eigenen LAN ziehen.

Strategischer Mehrwert: Absolute Datensouveränität (SEAL-4)

Die konsequente Umsetzung des Air-Gapped-Paradigmas auf Basis offener Open-Source-Standards wie Harbor hebt die digitale Souveränität auf das absolute Maximum – das SEAL-4-Niveau (Full Digital Sovereignty):

  • Kompromissloser Schutz vor Spionage und Sabotage: Da keine physische Netzwerkverbindung nach außen existiert, sind klassische Angriffsvektoren über das Internet (wie Remote Code Execution oder Ransomware-Injektionen aus Übersee) physikalisch ausgeschlossen. Ihre sensiblen Quellcodes und Firmengeheimnisse verlassen niemals die eigenen Mauern.
  • 100 % Autarkie im Krisenfall: Sollten globale Seekabel beschädigt werden, politische Konflikte die Netzwerkinfrastruktur beeinträchtigen oder US-amerikanische Tech-Konzerne den Zugriff auf ihre Cloud-Plattformen sperren, läuft Ihr Betrieb unverändert weiter. Ihre Lieferkette, Ihre Cluster und Ihre Anwendungen sind vollständig in Ihrer Hand.
  • Perfekte Compliance-Audits für KRITIS: Für Einrichtungen, die unter strengste Sicherheitsüberprüfungen des Staates fallen, ist das Air-Gapped-Setup oft die einzige Möglichkeit, um die geforderten Betriebskontinuitäts-Nachweise lückenlos zu erbringen. Die Architektur ist vollkommen transparent, auditierbar und frei von ausländischen Black-Box-Komponenten.

Fazit: Modernisierung erfordert keine Offenheit

Das Air-Gapped-Paradigma beweist eindrucksvoll, dass moderne, agile Software-Entwicklung mit Kubernetes und Containern nicht mit dem Verzicht auf maximale IT-Sicherheit erkauft werden muss. Durch den Einsatz von souveränen, standardkonformen On-Premises-Komponenten wie einer verwalteten Harbor-Registry auf eigenem S3-Speicher lässt sich die Geschwindigkeit der Cloud nahtlos in die Sicherheit einer physisch isolierten Festung integrieren. Unternehmen behalten die absolute Kontrolle über jeden Code-Baustein, erfüllen die schärfsten regulatorischen Vorgaben und sichern ihre operative Handlungsfähigkeit gegen jede erdenkliche geopolitische und netzwerktechnische Krise ab.

FAQ: Air-Gapped Registry-Praxis

Wie aktualisiert man die CVE-Datenbanken des Scanners in einer Air-Gapped-Registry?

Da der Scanner (z. B. Trivy oder Clair innerhalb von Harbor) die weltweiten Schwachstellen-Datenbanken nicht direkt via HTTP abrufen kann, wird ein Offline-Update-Prozess eingerichtet. Die neuesten CVE-Definitionen werden in der internetfähigen Staging-Umgebung täglich als kompakte Paketdatei heruntergeladen, über die physische Datenschleuse transferiert und per automatisiertem Skript lokal in die Harbor-Datenbank eingespielt. So bleibt das Schwachstellen-Scanning auch ohne Internetverbindung tagesaktuell.

Können wir trotz Air-Gap GitOps-Werkzeuge wie ArgoCD nutzen?

Ja, absolut. GitOps ist ein logisches Konzept und funktioniert in isolierten Netzen genauso hervorragend wie in der Cloud. Voraussetzung ist lediglich, dass neben der Container Registry auch das Git-Repository (z. B. eine lokale GitLab- oder Gitea-Instanz) On-Premises innerhalb des Air-Gapped-Netzwerks betrieben wird. ArgoCD liest die Manifeste aus dem lokalen Git und steuert das lokale Kubernetes-Cluster an, welches die Images wiederum über die lokalen imagePullSecrets aus der Harbor-Registry zieht.

Wie verhält sich die Lizenzierung von Open-Source-Software im Air-Gapped-Betrieb?

Dies ist ein riesiger Vorteil von Lösungen, die konsequent auf echten Open-Source-Standards basieren. Da Werkzeuge wie Harbor, Kubernetes und Ceph unter freien Lizenzen stehen, benötigen sie keinerlei Online-Aktivierung, keine „Heimtelefonate" zu Lizenzservern und keine Abonnements, die bei Netztrennung ungültig werden. Der Betrieb ist dauerhaft, rechtssicher und technisch uneingeschränkt möglich.

Ähnliche Artikel