Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// sicherheit

Air-Gapped-Umgebungen

Gilt für

Produkt: Server · Zielgruppe: Sicherheits- / Compliance-Prüfer · Platform Operator

Betrieb eines Servers ohne Internetzugang: was funktioniert (Kernplattform, RAG, OCR, Sprache-zu-Text, lokale Inferenz), was nicht (Websuche, Online-Modelldownload, externe Dienste), und wie Software, Modelle und Updates ausgeliefert werden. Die Infrastruktur-Richtlinie führt die Airgapped-Option als standardmäßig unterstützt; Telemetrie ist ohnehin deaktiviert.

Was funktioniert

Funktion	Abgeschottet	Anmerkung
Chat mit lokalem Modell	Ja	Inferenz auf dem Server oder einem GPU-Host im selben abgeschotteten Netz
Dokumente hochladen, PDFs, Bilder, OCR	Ja	ragsrv/ragsrv-support mit vorab geladenen Modellen
Wissensbasen (RAG)	Ja	Embeddings lokal
Sprache-zu-Text	Ja	Whisper-Endpunkt lokal
Apps, Rollen, Gruppen, Audit-Log, Exporte	Ja	Kernplattform
REST- und OpenAI-kompatible API	Ja	Innerhalb des Netzes
Konnektoren zu internen Systemen	Ja	Wiki, Ticketsystem, IMAP im selben Netz
Anmeldung über LDAP / internes OIDC	Ja	Verzeichnis im selben Netz
Mail	Nur mit internem Mailserver	Einladungen und Benachrichtigungen brauchen SMTP
Websuche	Nein	Braucht den Suchanbieter – ausschalten für die Installation
Online-Modelldownload	Nein	Modelle vorab laden
Externe OIDC-Anbieter, SaaS-Konnektoren	Nein	Nur, was im Netz erreichbar ist
Automatischer Bezug von Images/Charts	Nein	Über internen Mirror
Zertifikate über `cert-manager` mit öffentlicher CA	Nein	Eigene Zertifikate (`existing-secret`) von interner CA

Wie Software hineinkommt

Container-Images und Helm-Charts aus der basebox-Registry (gitea.basebox.health) auf einem verbundenen System beziehen, in eine interne Registry spiegeln, Values auf die interne Registry zeigen lassen.
Modellgewichte vorab auf die Volumes laden (Download-Job auf einem verbundenen System, dann Kopie) und die Inferenz mit HF_HUB_OFFLINE: "1" betreiben – Inference Server → Offline-Konfiguration. Dasselbe für die Modelle der Service-Modelle (ragsrv-support-models).
Backups auf ein internes S3-kompatibles Ziel (z. B. MinIO) – der einzige Weg für CloudNativePG-Backups ohne Internet (Backup & Wiederherstellung).
Integritätsprüfung beim Transport: Image-Digests aus dem Manifest gegen die gespiegelten Images prüfen. Signierte Images sind laut Infrastruktur-Richtlinie in Vorbereitung; bis dahin sind Digests Ihr Nachweis.

Wie Updates ankommen

basebox kündigt Releases und Sicherheitsupdates per E-Mail und Release Notes an – auf ein Postfach, das Ihr Betriebsteam außerhalb des abgeschotteten Netzes liest. Der Update-Weg ist dann: Release Notes prüfen → Images/Charts spiegeln → Modelle bei Bedarf spiegeln → Backup → Upgrade nach Updates. Planen Sie den Transportweg (Datenträger, Schleuse) als Teil des Betriebsprozesses; bei Betrieb durch basebox ist der Wartungszugang selbst ein zu klärender Punkt – ein vollständig abgeschotteter Server lässt sich nur vor Ort oder über einen kontrollierten Wartungsweg betreuen (Fernwartung).

Konfiguration in Kürze

# Values-Auszug – abgeschotteter Betrieb
global:
  imageRegistry: registry.intern.example/basebox     # interner Mirror
inference:
  env:
    HF_HUB_OFFLINE: "1"
ragsrv:
  mode: gpu
ragsrv-support:
  mode: gpu
tls:
  mode: existing-secret                               # Zertifikat interner CA

Websuche in der Administration für die Installation ausschalten; Konnektoren nur für interne Systeme aktivieren (Richtlinien).

Was abgeschotteter Betrieb sicherheitlich leistet – und nicht

Leistet: Kein Pfad nach außen – weder für Daten noch für Angreifer; Websuche-Risiken entfallen vollständig; die Datenverarbeitungsgrenze ist das Netz.

Leistet nicht: Schutz vor Innentätern, fehlender Speicherverschlüsselung oder schwachen Zugriffsrechten; Sicherheitsupdates kommen nur so schnell, wie Ihr Transportweg sie bringt – ein abgeschotteter Server ohne Update-Prozess ist ein veralteter Server.

Für die Prüfung

Egress-Regel: keine. Dokumentieren Sie das als bewusste Konfiguration.
Transportweg für Images, Modelle und Updates mit Integritätsprüfung (Digests) beschreiben.
Zuständigkeit für das Lesen der Sicherheitsankündigungen und den Update-Zyklus festlegen.
Interner Mailserver, internes Verzeichnis, interne CA als Voraussetzungen benennen.

Nächster Schritt: Externe Dienste → Modellanbieter