Verschlüsselung
Verschlüsselt bei der Übertragung, im Ruhezustand und während der Nutzung. Jedes Byte, jede Grenze. Customer-managed Keys beim Self-Hosting; bei Managed-Bereitstellungen geplant für Q3–Q4 2026.
Bei der Übertragung
Externe Verbindungen
- Ausschließlich TLS 1.3 auf dem gesamten Ingress. TLS 1.2 deaktiviert.
- HSTS mit langer max-age
- Certificate Pinning auf mobilen Clients
- HTTP Strict Transport Security (HSTS) preloaded auf stellarbase.ai
- Perfect Forward Secrecy über ECDHE-Cipher
Interner Service Mesh
- mTLS zwischen jedem internen Dienst
- Pro-Dienst-Zertifikate werden automatisch rotiert
- Service Mesh (Istio / Linkerd) erzwingt die Verschlüsselung
- Kein Klartext-Verkehr im internen Netzwerk
Verbindungen zu Quellsystemen
- Jeder Konnektor verwendet provider-natives TLS
- Anmeldedaten (OAuth-Tokens, API-Keys) werden verschlüsselt gespeichert
- IP-Allowlisting wird für sensible Quellen unterstützt
Im Ruhezustand
Primärdaten
- Postgres: AES-256-GCM Transparent Data Encryption
- Object Storage (S3 / MinIO): Server-Side Encryption (SSE-KMS oder SSE-S3)
- Vector Index: auf Dateisystemebene verschlüsselt
- Backups: mit einem separaten Schlüssel verschlüsselt zur Abwehr von Cross-Compromise
Pro-Tenant-Isolation
- Die Daten jedes Tenants werden mit einem separaten Schlüssel auf Tenant-Ebene verschlüsselt
- Die Kompromittierung des Schlüssels eines Tenants kann die Daten eines anderen Tenants nicht entschlüsseln
- Schlüsselhierarchie: Data Key → Tenant Key → Master Key (KMS-geschützt)
Audit-Log
Das Audit-Log wird im Ruhezustand in einem Append-only-Speicher mit separaten Schlüsseln verschlüsselt. Die Chain of Custody ist kryptografisch überprüfbar.
Während der Nutzung
„Während der Nutzung“ bedeutet während der Verarbeitung, nicht nur im Ruhezustand und bei der Übertragung:
- Secrets werden nach Abschluss der Anfrage aus dem Speicher gelöscht
- GPU-Speicher wird zwischen Anfragen verschiedener Tenants bereinigt
- Temporäre Dateien (falls vorhanden) werden verschlüsselt und nach Gebrauch gelöscht
- Logs werden per Pattern Matching + StellarGate von Secrets und PII bereinigt
Schlüsselverwaltung
Managed-Bereitstellungen
Die Schlüssel liegen in einem Managed KMS (AWS KMS / Google CKM / HashiCorp Vault, je nach unserem Rechenzentrum). HSM-backed. Vierteljährliche Schlüsselrotation gemäß Richtlinie. Unveränderlicher Audit-Trail für jede Schlüsseloperation.
Selbst gehostete Bereitstellungen
Bring your own KMS. Unterstützte Backends:
- HashiCorp Vault
- AWS KMS / Google CKM / Azure Key Vault (für in der Cloud bereitgestelltes Self-Hosting)
- PKCS#11-HSMs (On-Premise)
- Thales CipherTrust
- Gemalto SafeNet
Sie steuern die Rotationskadenz, die Zugriffsrichtlinie und den Notfall-Widerruf.
Customer-managed Keys (BYOK)
🛠 In active development — Q3–Q4 2026. Customer-managed Keys (BYOK) bei Managed-Bereitstellungen sind für Q3–Q4 2026 geplant; angeboten in Enterprise-Tarifen.
Für Kunden, die auch bei Managed-Bereitstellungen Kontrolle über die Schlüssel benötigen, ist BYOK in Enterprise-Tarifen verfügbar. Ihr Schlüssel umschließt den Tenant Key; wir sehen Ihr rohes Schlüsselmaterial niemals.
Schlüsselrotation
| Ebene | Standardrotation |
|---|---|
| TLS-Zertifikate | 90 Tage (Let’s Encrypt) oder gemäß Ihrer CA |
| Service-Mesh-Certs | 24 Stunden |
| Data Encryption Keys | Vierteljährlich |
| Master Key | Jährlich |
| API-Keys / Tokens | Vom Kunden konfiguriert; wir empfehlen vierteljährlich |
Schlüsselwiderruf
🛠 Ready in Q4 2026. Der Widerruf einzelner Anmeldedaten funktioniert bereits heute. Runbooks für Tenant-Scope- und Full-System-Widerruf sind in Q4 2026 bereit.
Der Notfall-Schlüsselwiderruf ist ein dokumentiertes Runbook. Scope-Optionen:
- Einzelne Anmeldedaten — ein API-Key wird widerrufen, alles andere bleibt unberührt
- Tenant — der gesamte Zugriff auf verschlüsselte Daten eines Tenants wird blockiert
- Gesamtes System — der Master Key wird widerrufen, die Daten sind unlesbar, bis der Schlüssel wiederhergestellt ist (nur bei bestätigtem Sicherheitsvorfall verwenden)
Entschlüsselungs-Audit
Jeder Entschlüsselungsvorgang wird protokolliert. Eine Musteranalyse schlägt bei ungewöhnlichem Zugriff Alarm (außerhalb der Geschäftszeiten, von ungewöhnlichen Standorten, in ungewöhnlichen Mengen).
Kryptografische Entscheidungen
Wir bevorzugen weit verbreitete, gut auditierte Primitive:
- AES-256-GCM für symmetrische Verschlüsselung
- RSA-4096 oder ECDSA P-384 für asymmetrische
- SHA-256 / SHA-3 für Hashing
- Argon2id für das Hashing von Passwörtern (sofern zutreffend)
- TLS 1.3 mit modernen Ciphersuites
Keine eigene Kryptografie. Keine „neuartigen“ Verfahren. Nichts, das nicht mindestens fünf Jahre lang öffentlich begutachtet wurde.