Zum Inhalt

// sicherheit

Verschlüsselung

Gilt für

Produkt: Demo · Cloud · Server · Zielgruppe: Sicherheits- / Compliance-Prüfer

TLS in der Übertragung (Ingress, AISRV↔Inferenz, Konnektoren, Verzeichnis, Mail), Verschlüsselung im Ruhezustand und Schlüsselverwaltung. Die ehrliche Kurzfassung: In der Übertragung ist alles verschlüsselbar und in Produktion verschlüsselt; im Ruhezustand verschlüsselt die Anwendung derzeit nicht selbst – das leistet die Speicherebene, und das muss Ihr Sicherheitskonzept ausweisen.

In der Übertragung

Pfad Verschlüsselung Konfiguration (Server)
Browser / API-Client → Ingress HTTPS (TLS) – Pflicht in Produktion TLS-Modus im Chart: cert-manager (automatische Zertifikate), existing-secret (eigenes Zertifikat, auch von interner CA), local nur für Evaluierung – Helm Charts verwenden
Frontend → Keycloak (OIDC) HTTPS über denselben Ingress (/auth) VITE_BB_OIDC_DOMAIN mit HTTPS-Adresse
AISRV → Inferenz Innerhalb eines Clusters interner Dienstverkehr; TLS, sobald der Pfad Hosts oder Sicherheitszonen überschreitet – dann Pflicht AISRV_LLM_URL mit https://; private CA in den basebox-Workload importieren (Inferenz anbinden)
AISRV → ragsrv → ragsrv-support Interner Clusterverkehr mit API-Schlüsseln –
MCP-Konnektor → Zielsystem Systemspezifisch, in der Regel HTTPS; IMAP über 993 (TLS) Basis-URLs mit https://; Zertifikate der Zielsysteme von öffentlicher oder abgestimmter privater CA
Websuche-Konnektor → Suchanbieter HTTPS zu den Anbieter-Hosts (api.staan.ai) Egress-Allowlist am Gateway
Keycloak → LDAP LDAPS (636) empfohlen; StartTLS möglich; 389 unverschlüsselt nur im geschützten Netz LDAP-Anbindung
AISRV → SMTP STARTTLS (587) oder TLS (465) AISRV_SMTP_*
Dienste → PostgreSQL Interner Clusterverkehr; CloudNativePG kann TLS erzwingen Cluster-Konfiguration

In der Cloud konfiguriert basebox alle diese Pfade; Nutzerzugriff erfolgt ausschließlich über HTTPS auf <ihre-organisation>.basebox.ai, API-Zugriff über HTTPS auf aims.basebox.ai, und Pfade in Ihr Netz (Konnektoren, Mail, Verzeichnis) sind TLS-geschützt – Zertifikate Ihrer Zielsysteme von öffentlicher CA oder eine mit basebox abgestimmte private CA (Netzanbindung).

Im Ruhezustand

Ebene Status Wer verantwortet
Anwendung (Datenbankfelder, Dateien) Nicht implementiert – die Anwendung speichert Klartext in PostgreSQL und auf dem Medien-Volume (Infrastruktur-Richtlinie, Sicherheitshinweis) basebox (geplant)
Zugangsdaten Passwörter lokaler Konten als Hash in Keycloak; Konnektor-Zugangsdaten je Nutzer nur schreibend gespeichert, nie in Logs; API-Schlüssel des Zielsystems bei organisationsweiten Konnektoren in der Konfigurationsdatenbank basebox
Kubernetes-Secrets In etcd; Verschlüsselung von etcd im Ruhezustand ist eine Cluster-Einstellung Server: Platform Operator · Cloud: basebox
Speicherebene (Datenträger, Storage Class, Volumes) Verschlüsselte Datenträger oder verschlüsselnde Storage Class – die wirksame Kontrolle heute Server: Platform Operator · Cloud: basebox
Backups Dumps und Objektspeicher-Ziele müssen selbst verschlüsselt und zugriffsbeschränkt werden Betreiber

Für die Prüfung heißt das: Die Anforderung „Verschlüsselung im Ruhezustand" erfüllt eine basebox-Installation über die Speicherebene, nicht über die Anwendung. Dokumentieren Sie auf einem Server, welche Datenträger verschlüsselt sind (etwa LUKS auf den Volumes der Datenbanken und Medien) und wo die Schlüssel liegen. Zusätzlich empfiehlt der Sicherheitshinweis, keine sensiblen Daten ungeschützt in Prompts oder Wissensquellen einzugeben, deren Vertraulichkeit allein von der Speicherverschlüsselung abhängt.

Schlüsselverwaltung

Schlüssel / Geheimnis Ort Rotation
TLS-Zertifikat des Ingress Kubernetes-Secret; bei cert-manager automatisch erneuert Automatisch oder mit Ablauf des eigenen Zertifikats
Datenbank-Passwörter (*-database) Kubernetes-Secrets, von CloudNativePG verwaltet Cluster-Verfahren
Keycloak-Admin, basebox-Admin Kubernetes-Secrets (keycloak-admin-secret, basebox-admin-secret) Nach Ihrem Passwortprozess
Inferenz-API-Schlüssel Secret (external-inference-api o. ä.), per secretKeyRef in AISRV – nie in Values-Dateien Bei Wechsel Secret ändern, AISRV neu starten
Registry-Zugang für Images/Charts Secret / Helm-Registry-Login Bei Wechsel
API-Schlüssel der Nutzer/Entwickler In der Anwendung erzeugt, widerrufbar Durch Administrator (API-Schlüssel)
Konnektor-Zugangsdaten je Nutzer Anwendung, nur schreibend Durch den Nutzer; Widerruf im Zielsystem wirkt sofort

Wer Kubernetes-Secrets lesen darf, kann alle Plattform-Geheimnisse lesen – begrenzen Sie das über RBAC auf den Platform Operator. Bei Betrieb durch basebox gehört diese Rolle zum Wartungszugang (Fernwartung).

Was Sie prüfen können

kubectl -n basebox get ingress                    # TLS-Hosts und Secret
kubectl -n basebox get secret <tls-secret> -o jsonpath='{.type}'   # kubernetes.io/tls
curl -vI https://<basebox-host>/ 2>&1 | grep -i 'TLS\|issuer'
kubectl -n basebox get deploy aisrv -o yaml | grep -A2 AISRV_LLM_URL    # https bei externem Endpunkt

Auf Speicherebene: lsblk/cryptsetup status auf dem Knoten bzw. die Verschlüsselungseigenschaft Ihrer Storage Class.

Häufige Fragen

Ist basebox „Ende-zu-Ende verschlüsselt"? Nein, und das kann eine Anwendung, die Inhalte an ein Sprachmodell weitergibt, prinzipiell nicht sein: Die Plattform muss Prompts im Klartext verarbeiten. Schutz entsteht aus Transportverschlüsselung, Speicherverschlüsselung, Zugriffskontrolle und – auf Server – der Grenze des Kundennetzes.

Wann kommt Verschlüsselung im Ruhezustand in der Anwendung? Sie ist in der Infrastruktur-Richtlinie als geplant geführt. Einen Termin nennt diese Dokumentation nicht; fragen Sie support@basebox.ai.

Reicht die Speicherverschlüsselung für Patientendaten? Das ist eine Frage Ihres Schutzbedarfs und Ihrer Aufsicht. Technisch ist sie in Verbindung mit Zugriffskontrolle, dediziertem Server und kurzer Aufbewahrung eine übliche Kontrolle; die Bewertung liegt bei Ihnen als Verantwortlichem.

Nächster Schritt: Aufbewahrung