Šifrování
Šifrované při přenosu, v klidu a za běhu. Každý bajt, každá hranice. Customer-managed klíče u self-hosted; u managed nasazení plánované na Q3–Q4 2026.
Při přenosu
Externí spojení
- Výhradně TLS 1.3 na veškerém ingressu. TLS 1.2 vypnuté.
- HSTS s dlouhým max-age
- Certificate pinning na mobilních klientech
- HTTP Strict Transport Security (HSTS) preloaded na stellarbase.ai
- Perfect forward secrecy přes ECDHE ciphery
Interní service mesh
- mTLS mezi každou interní službou
- Per-service certifikáty rotované automaticky
- Service mesh (Istio / Linkerd) vynucuje šifrování
- Žádný plaintext provoz v interní síti
Spojení do zdrojových systémů
- Každý konektor používá provider-native TLS
- Přihlašovací údaje (OAuth tokeny, API klíče) uložené šifrovaně
- IP allowlisting podporovaný pro citlivé zdroje
V klidu
Primární data
- Postgres: AES-256-GCM transparent data encryption
- Object storage (S3 / MinIO): server-side encryption (SSE-KMS nebo SSE-S3)
- Vector index: šifrovaný na úrovni filesystému
- Zálohy: šifrované samostatným klíčem pro obranu před cross-compromise
Per-tenant izolace
- Data každého tenanta jsou šifrovaná samostatným tenant-level klíčem
- Kompromitace klíče jednoho tenanta neumožní dešifrovat data jiného
- Hierarchie klíčů: data klíč → tenant klíč → master klíč (chráněný KMS)
Audit log
Audit log je v klidu šifrovaný v append-only úložišti se samostatnými klíči. Chain of custody je kryptograficky ověřitelný.
Za běhu
„Za běhu” znamená během zpracování, ne jen v klidu a při přenosu:
- Secrets vymazané z paměti po dokončení requestu
- GPU paměť scrubbovaná mezi tenant requesty
- Dočasné soubory (pokud existují) šifrované a smazané po použití
- Logy scrubbované od secrets a PII přes pattern matching + StellarGate
Správa klíčů
Managed nasazení
Klíče žijí v managed KMS (AWS KMS / Google CKM / HashiCorp Vault podle našeho datového centra). HSM-backed. Čtvrtletní rotace klíčů dle politiky. Nezměnitelná audit stopa každé operace s klíčem.
Self-hosted nasazení
Bring your own KMS. Podporované backendy:
- HashiCorp Vault
- AWS KMS / Google CKM / Azure Key Vault (pro cloud-deployed self-hosted)
- PKCS#11 HSM (on-prem)
- Thales CipherTrust
- Gemalto SafeNet
Vy řídíte kadenci rotace, přístupovou politiku a nouzovou revokaci.
Customer-managed klíče (BYOK)
🛠 Ve vývoji — Q3–Q4 2026. Customer-managed klíče (BYOK) u managed nasazení jsou plánované na Q3–Q4 2026; nabízené na enterprise plánech.
Pro zákazníky, kteří potřebují kontrolu nad klíči i u managed nasazení, je BYOK dostupný na enterprise plánech. Váš klíč obaluje tenant klíč; my nikdy nevidíme váš surový klíčový materiál.
Rotace klíčů
| Úroveň | Defaultní rotace |
|---|---|
| TLS certifikáty | 90 dní (Let’s Encrypt) nebo dle vaší CA |
| Service mesh certs | 24 hodin |
| Data encryption keys | Čtvrtletně |
| Master key | Ročně |
| API klíče / tokeny | Konfigurované zákazníkem; doporučujeme čtvrtletně |
Revokace klíčů
🛠 Připravené v Q4 2026. Revokace jediného credential funguje dnes. Runbooky pro tenant-scope a full-system revokaci budou připravené v Q4 2026.
Nouzová revokace klíčů je zdokumentovaný runbook. Možnosti scope:
- Jedna credentials — jeden API klíč revokován, ostatní nedotčeno
- Tenant — veškerý přístup k šifrovaným datům jednoho tenanta zablokován
- Celý systém — master klíč revokován, data nečitelná, dokud se klíč neobnoví (použít jen u potvrzené breach)
Audit dešifrování
Každá dešifrovací operace je logovaná. Pattern analýza alarmuje na neobvyklý přístup (mimo pracovní dobu, z neobvyklých lokalit, v neobvyklých objemech).
Kryptografické volby
Preferujeme široce nasazené, dobře auditované primitivy:
- AES-256-GCM pro symetrické šifrování
- RSA-4096 nebo ECDSA P-384 pro asymetrické
- SHA-256 / SHA-3 pro hashování
- Argon2id pro hashování hesel (kde se to hodí)
- TLS 1.3 s moderními ciphersuites
Žádná vlastní kryptografie. Žádná „novel” schémata. Nic, co nebylo veřejně reviewed minimálně pět let.