Air-gapped-Systeme: kritische Software ganz ohne Internet betreiben

Manche Systeme dürfen nie mit dem Internet sprechen: ein Live-Sendeablauf, ein Spitalnetz, eine Produktionslinie, ein Labor mit exportkontrollierten Daten. Lange hiess das: Verzicht auf moderne Werkzeuge. Das ist vorbei. Kubernetes, GitOps, signierte Images und sauberes Monitoring laufen auch in einer Enklave ohne jeden Weg nach draussen, wenn man die Grenze als Prozess versteht und nicht nur als fehlendes Kabel. So baue und betreibe ich solche Umgebungen.

Dominik Heinrich

7. November 202610 Min. Lesezeit

1. Was ein Air Gap wirklich ist

Das Wort steht für drei sehr unterschiedliche Dinge, und der Unterschied zählt. Ein physischer Air Gap heisst: kein Netzwerkpfad, Daten wandern nur auf Datenträgern, die jemand hinüberträgt. Ein Einweg-Gateway, oft Datendiode genannt, erzwingt die Richtung in Hardware: Daten fliessen in die Enklave hinein, oder für Monitoring hinaus, aber nie zurück. Eine logische Trennung ist eine Firewall, die alles blockieren soll, also Segmentierung, nicht Isolation: Eine falsche Regel, und die Lücke ist zu. NIST SP 800-82, der US-Leitfaden für die Sicherheit von Betriebstechnik, behandelt Segmentierung und unidirektionale Gateways genau deshalb als getrennte Werkzeuge. Bevor Sie etwas entwerfen, schreiben Sie auf, welche der drei Varianten Sie wirklich haben, denn Update-Prozess, Monitoring und Bedrohungsmodell folgen daraus.

Tipp aus der Praxis

Zeichnen Sie die echten Datenflüsse auf eine Seite, inklusive USB-Sticks, Laptops von Servicetechnikern und Fernwartungs-Tools. Auf dieser Seite sieht man meist die Lücke, von der niemand wusste.

2. Wann Sie einen brauchen, und wann nicht

Air Gaps lohnen sich dort, wo ein Vorfall katastrophal wäre oder Vorschriften es verlangen: klassifizierte Netze und Verteidigung, industrielle Steuerungen in Energie und Produktion, Live-Produktion im Rundfunk, wo ein Angriff Sie vom Sender nimmt, Medizingeräte, Zahlungs- und Handelssysteme sowie exportkontrollierte Forschungsdaten. Sie kosten echt etwas: Updates kommen gebündelt statt laufend, jedes neue Werkzeug braucht eine Offline-Lösung, und an der Grenze braucht es Disziplin. Darum entscheide ich pro System, nicht pro Unternehmen. Meist kommen nur die Kronjuwelen hinter die Lücke, alles rundherum bleibt verbunden und sauber segmentiert. Die Kontrollen aus NIST SP 800-53 zu Grenzschutz und Informationsflüssen sind eine gute Checkliste, um diese Entscheidung mit Auditoren zu begründen.

3. Die Architektur: drei Zonen und eine Richtung

Jedes Setup, das ich baue, hat dieselben drei Zonen. Die verbundene Zone holt, was Sie von aussen brauchen: Container-Images, Helm-Charts, Betriebssystem-Updates, Git-Repositories. Die Transferzone ist ein kleiner, gehärteter Bereich, in dem alles auf Schwachstellen geprüft, in einer Software-Stückliste (SBOM) beschrieben und signiert wird, bevor es in ein Paket mit Prüfsummen-Manifest kommt. Die Enklave empfängt nur dieses Paket, prüft es erneut und stellt es aus eigener Registry und eigenem Git bereit. Werkzeuge wie Zarf fassen die Idee in ihrem Motto gut zusammen, verbunden entwickeln und getrennt ausrollen, und verpacken genau diesen Ablauf. Ob mit so einem Werkzeug oder ein paar Skripten, die Regel bleibt: Nichts in der Enklave greift nach draussen, alles kommt durch eine kontrollierte Tür herein.

Air-gapped Kubernetes: verbundene Zone mit Hersteller-Registries, Git und Updates; Transferzone, die scannt, eine SBOM erzeugt und signiert; Einweg-Transfer in eine Enklave mit privater Registry, internem Git mit GitOps, einem Kubernetes-Cluster mit Linux-Pods und Windows-VMs auf KubeVirt, internem Monitoring, lokaler Zeitquelle und Notfallzugang, ohne Weg ins Internet. — Wie Software in eine air-gapped Kubernetes-Enklave gelangt: draussen geprüft und signiert, in eine Richtung bewegt, drinnen erneut verifiziert. Klicken für volle Grösse.

4. Images, Charts und SBOMs, fixiert und signiert

Spiegeln Sie nur, was Sie wirklich betreiben, nie eine ganze öffentliche Registry. Fixieren Sie jedes Image per Digest und jedes Chart per Version, denn Tags wandern, und später lässt sich nicht mehr prüfen, was ein Tag am Tag der Kopie bedeutete. kubeadm listet genau die Images, die eine bestimmte Kubernetes-Version braucht, und Helm holt ein Chart als Datei. Erzeugen Sie für das ganze Paket eine SBOM im Format SPDX oder CycloneDX; die CISA beschreibt die SBOM als Zutatenliste, mit der Sie beim nächsten grossen Sicherheitsproblem in Minuten beantworten, ob Sie betroffen sind. Dann signieren. In der verbundenen Zone funktioniert ein Schlüsselpaar mit cosign gut: Der private Schlüssel bleibt draussen, idealerweise auf einem Hardware-Token, nur der öffentliche Schlüssel kommt in die Enklave.

bash

# Connected zone: build one transfer bundle, pinned and signed
set -euo pipefail
mkdir -p bundle/images bundle/charts

kubeadm config images list --kubernetes-version "$K8S_VERSION" > bundle/k8s-images.txt
while read -r img; do
  skopeo copy --all "docker://$img" "oci-archive:bundle/images/$(echo "$img" | tr '/:' '__').tar"
done < bundle/k8s-images.txt

helm pull ingress-nginx/ingress-nginx --version "$CHART_VERSION" -d bundle/charts
syft dir:bundle -o spdx-json > bundle/sbom.spdx.json      # what is inside

(cd bundle && find . -type f ! -name SHA256SUMS -exec sha256sum {} + > SHA256SUMS)
cosign sign-blob --key cosign.key --bundle bundle/SHA256SUMS.bundle bundle/SHA256SUMS

Tipp aus der Praxis

Scannen Sie in der Transferzone und lehnen Sie das Paket ab, wenn ein kritischer Fund keine dokumentierte Entscheidung hat. Später in der Enklave zu korrigieren kostet das Zehnfache.

5. Die Lücke überqueren: eine Richtung, zweimal geprüft

Das Paket gelangt entweder über eine Datendiode oder auf signierten Wechseldatenträgern hinüber, getragen nach dem Vier-Augen-Prinzip. Auf der Enklaven-Seite landet es zuerst in Quarantäne. Dort prüft ein separater Host die Signatur mit dem öffentlichen Schlüssel, vergleicht jede Datei mit dem Prüfsummen-Manifest und importiert erst dann Images in die private Registry und Charts und Manifeste ins interne Git. Weil die Enklave kein öffentliches Transparenz-Log erreicht, läuft die Prüfung allein gegen den Schlüssel, was cosign ausdrücklich unterstützt. Jeder Transfer bekommt einen Log-Eintrag: wer, wann, was, welche Prüfsummen, welche Freigabe. Vereinbaren Sie einen festen Rhythmus, etwa ein Paket pro Woche, plus einen dokumentierten Notfallweg für kritische Sicherheitsupdates, damit niemand in Versuchung kommt, «nur dieses eine Mal» ein Kabel einzustecken.

bash

# Enclave side, quarantine host: verify before anything is imported
set -euo pipefail
cd /quarantine/bundle

# Signature against the public key only (no public transparency log reachable)
cosign verify-blob --key /etc/airgap/cosign.pub \
  --bundle SHA256SUMS.bundle --insecure-ignore-tlog=true SHA256SUMS

sha256sum -c SHA256SUMS            # every file, byte for byte

for f in images/*.tar; do
  skopeo copy --all "oci-archive:$f" "docker://registry.enclave.local/mirror/$(basename "$f" .tar)"
done

6. Kubernetes in der Enklave betreiben

Drinnen ist eine private Registry wie Harbor die einzige Quelle für Images, mit Schwachstellen-Scan und Regeln, die Images ausserhalb Ihrer Vorgaben gar nicht erst ausliefern. Die Container-Runtime jedes Nodes zeigt als Mirror darauf, sodass selbst ein Manifest, das noch docker.io nennt, intern aufgelöst wird und nie nach draussen will. Deployments kommen per GitOps mit Flux oder Argo CD aus dem internen Git, mit demselben Review, derselben Historie und demselben Rollback wie in der Cloud. Bei der Admission weist eine Policy-Engine wie Kyverno, die Sigstore-cosign-Signaturen unterstützt, jedes Image ab, das nicht mit Ihrem Schlüssel signiert ist oder nicht aus der internen Registry kommt. Für die Teams fühlt sich das erstaunlich normal an: Pull Requests, Pipelines und Dashboards, nur mit einer langsameren und besser geprüften Lieferkette dahinter.

toml

# /etc/containerd/certs.d/docker.io/hosts.toml on every node:
# anything that asks for docker.io is served by the internal Harbor proxy project
server = "https://registry-1.docker.io"

[host."https://registry.enclave.local/v2/mirror-docker.io"]
  capabilities = ["pull", "resolve"]
  override_path = true

Tipp aus der Praxis

Lassen Sie die Admission-Policy zuerst eine Woche im Audit-Modus laufen. So finden Sie das eine vergessene Sidecar-Image, bevor es einen Produktions-Rollout blockiert.

Cloud Native Deployments in Air Gapped Environments, CNCF (YouTube). Wird erst nach Ihrem Klick von YouTube geladen.

7. Windows und Legacy-Software: VMs auf KubeVirt

Echte Enklaven bestehen selten nur aus Containern. Steuerungssoftware, Hersteller-Tools und ältere Systeme laufen oft nur unter Windows. KubeVirt betreibt diese als virtuelle Maschinen direkt neben Ihren Pods, auf denselben Nodes, mit demselben GitOps, demselben Monitoring und derselben Backup-Routine, sodass Sie keine zweite Virtualisierungsplattform mit eigenem Update-Problem brauchen. Genau diesen Mix habe ich betrieben: hybrides Kubernetes über Bare Metal und Cloud für Broadcast-Workloads, Windows-Anwendungen als VMs auf KubeVirt, die sensiblen Teile air-gapped. Planen Sie drei Dinge früh ein: die virtio-Treiber, die Windows unter KubeVirt braucht, einen Weg, Windows-Updates als Teil Ihres Pakets hineinzubringen, und eine Lizenzaktivierung ohne Internet, etwa über einen Aktivierungsdienst in der Enklave.

8. Die langweiligen Teile, die zuerst kaputtgehen

Meiner Erfahrung nach scheitern air-gapped Plattformen selten an den raffinierten Teilen. Sie scheitern an Zeit, Zertifikaten und Sichtbarkeit. Ohne lokale Zeitquelle driften die Uhren, bis TLS und Tokens brechen, also bringen Sie eine eigene NTP- oder PTP-Quelle mit, etwa eine GPS-Uhr. Betreiben Sie eine interne Zertifizierungsstelle und automatisieren Sie Erneuerungen drinnen, denn niemand kann ein Zertifikat aus dem Internet holen. Monitoring, Logs und Alerting bleiben in der Enklave; mit einem Einweg-Gateway können Sie Metriken an ein zentrales Team nach aussen senden, ohne etwas nach innen zu öffnen. Testen Sie Backups regelmässig durch Wiederherstellung drinnen. Und definieren Sie den Notfallzugang vor dem ersten Vorfall: zeitlich begrenzt, zwei Personen, lückenlos protokolliert. Selbst mein kleiner Offline-Roboter, ein ESP32 mit lokaler Spracherkennung und lokalem Sprachmodell, hat mir dieselbe Lektion erteilt: von Anfang an für kein Netz bauen, dann wird der Rest Routine.

Tipp aus der Praxis

Schreiben Sie das Runbook für «der Transferweg ist zwei Wochen ausgefallen», bevor Sie es brauchen: Welche Fixes können warten, welche brauchen den Notfallweg, wer entscheidet.

9. Eine realistische Einführung

Fangen Sie nicht damit an, alles abzuschotten. Wählen Sie ein System, das es klar braucht, und bauen Sie den Transferweg dafür von Anfang bis Ende: Paket schnüren, scannen, signieren, tragen, prüfen, importieren, ausrollen. Lassen Sie diese Schleife einige Male mit harmlosen Updates laufen, bis sie langweilig und dokumentiert ist, dann ziehen die echten Workloads um. Messen Sie vom ersten Tag an zwei Zahlen: wie lange ein kritischer Sicherheitsfix von der Veröffentlichung bis zum Betrieb drinnen braucht, und wie viele Transfers abgelehnt wurden und warum. Die erste zeigt dem Management, was die Lücke an Tempo kostet, die zweite beweist, dass die Kontrollen wirklich greifen. Nach einigen Monaten finden die meisten Teams einen Rhythmus, in dem wöchentliche Pakete Routine sind und der Notfallweg nur ein paar Mal im Jahr gebraucht wird, genau dort wollen Sie hin.

Fazit
Ein Air Gap ist nur so stark wie der Prozess an seiner Grenze: Jede Überquerung geprüft, signiert und verifiziert, und alles andere bekommt drinnen ein Zuhause.

Echte Projekte dazu

Hybrides Kubernetes für Live-Broadcast

Selbst ausprobieren

Air-Gap-Check

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden

Air-gapped-Systeme: kritische Software ganz ohne Internet betreiben

1. Was ein Air Gap wirklich ist

2. Wann Sie einen brauchen, und wann nicht

Ist Ihr Air Gap mehr als eine Firewall-Regel?

3. Die Architektur: drei Zonen und eine Richtung

4. Images, Charts und SBOMs, fixiert und signiert

5. Die Lücke überqueren: eine Richtung, zweimal geprüft

6. Kubernetes in der Enklave betreiben

7. Windows und Legacy-Software: VMs auf KubeVirt

8. Die langweiligen Teile, die zuerst kaputtgehen

9. Eine realistische Einführung

Kontakt aufnehmen