Management von Geheimnissen

Verwaltung von Geheimnissen

1) Warum und was wir als „Geheimnis“ betrachten

Secret - jedes Material, dessen Offenlegung zu einer Kompromittierung des Systems oder der Daten führt: Passwörter, API-Token, OAuth/JWT private Keys, SSH-Schlüssel, Zertifikate, Verschlüsselungsschlüssel (KEK/DEK), Webhook-Signaturschlüssel, DSN-Datenbanken/Caches, Lieferantenschlüssel (Payments, Mail/SMS-Anbieter), Cookie-Salze/pepper, Bot/Chat-Token, Lizenzen.
Die Geheimnisse leben im Kode, konfige, die Umgebung, die Containergestalten, CI/CD, Terraform/Ansible, die Hohlwege/Dumpe - die Aufgabe des Managements der Geheimnisse: die Berücksichtigung → die Aufbewahrung → die Zustellung → die Nutzung → die Rotation → die Rezension → das Audit → die Verwertung.

2) Prinzipien der Architektur

Zentralisierung. Eine vertrauenswürdige Schicht (Vault/Cloud Secret Manager/KMS) zum Speichern, Ausgeben und Prüfen.
Kleinste Privilegien (PoLP). Zugriff nur auf die gewünschten Dienste/Rollen, für einen Mindestzeitraum.
Ein kurzes Leben. Dynamische/temporäre Geheimnisse mit TTL/lease werden bevorzugt.
Crypto-agility. Möglichkeit, Algorithmen/Schlüssellängen ohne Ausfallzeiten zu ändern.
Trennen Sie Geheimnisse von Code/Bildern. Keine Passwörter in Repositories, keine Docker-Images.
Beobachtbarkeit und Audit. Jeder Vorgang zum Ausgeben/Lesen von Geheimnissen wird protokolliert und benachrichtigt.
Automatische Rotation. Rotation ist ein Prozess in der Pipeline, keine manuelle Aktion.

3) Typische Lösungen und Komponentenrollen

KMS/HSM. Das wurzelständige Vertrauen, der Operation der Chiffrierung/Umschlages der Schlüssel (envelope).
Secret Manager/Vault. Secret Version Storage, ACL, Audit, Dynamic Secrets (DB, Cloud-IAM, PKI), Rotationsmuster.
PKI/CA. Ausstellung von kurzlebigen mTLS/SSH/JWT Signaturzertifikaten.
Agent/sidecar. Rantime-Lieferung von Geheimnissen (tmpfs-Dateien, In-Memory k/v, Hot-Reload).
CSI-Treiber/Operatoren. Integration mit Kubernetes (Secret Store CSI Driver, cert-manager).
Verschlüsselungsschicht in Git. SOPS/age, git-crypt (für Infrastrukturcode).

4) Klassifizierung und Politik

• TTL/Lease und Rotationsfrequenz;
• Ausgabemethode (Dynamik vs Statik), Format, Medium;
• Zugriffspolitik (wer/wo/wann/warum), Anforderungen an mTLS und gegenseitige Authentifizierung;
• Audit (was wir protokollieren, wie viel wir speichern, wer Revuit ist);
• break-glass Verfahren und Rückruf.

5) Lebenszyklus des Geheimnisses

1. Erstellung: über die Secret Manager API mit Metadaten (Eigentümer, Tags, Umfang).
2. Speicherung: in verschlüsselter Form (envelope: DEK wrapped by KEK from KMS/HSM).
3. Lieferung: auf Antrag eines autorisierten Subjekts (OIDC/JWT, SPIFFE/SVID, mTLS).
4. Verwendung: ausschließlich im Speicher/in tmpfs; Verbot von Protokollierung/Dumps.
5. Rotation: durch TTL oder Ereignis (Kompromittierung); Unterstützung für parallele Versionen (N-1).
6. Rückruf/Sperrung: Sofortiger Ablauf der Lease, Disable des Accounts/Schlüssels im Zielsystem.
7. Entsorgung: Vernichtung von Versionen/Material, klare Audit-Kette.

6) Dynamische Geheimnisse (standardmäßig empfohlen)

• DB-Anmeldeinformationen (Postgres/MySQL) mit TTL 15-60 min.
• Temporäre Cloud-Schlüssel (AWS/GCP/Azure) nach Service-Rolle.
• SSH-Zertifikate (Laufzeit 5-30 min), X.509-Zertifikate (Stunde/Tag).
• Temporäre JWTs zum Signieren von Anfragen, Session-Tickets von Brokern.
• Vorteile: minimaler Blast-Radius, vereinfachter Rückruf (nichts wird auf der Welt „bleiben“).

7) Lieferung von Geheimnissen an die Rantime

• Secret Store CSI Driver → das Einhängen von Geheimnissen von einem externen Manager in einen Pod als Dateien (tmpfs).
• Vermeiden Sie Kubernetes Secret als einzige Quelle (base64 ≠ Verschlüsselung); Aktivieren Sie bei Bedarf den KMS-Anbieter für etcd.
• Sidecar-Agent (Vault Agent/Secrets Store) mit Auto-Reneval-Lease und Hot-Reload.
• VM/Bare-metal: Systemagent + mTLS zum Vault/Secret Manager, Cache im Speicher, minimale TCB.
• Serverless: Integration der Cloud mit transparenter Substitution von Geheimnissen als Umgebungsvariablen/Dateien, aber Vermeidung von langlebigen envvars - vorzugsweise Dateien/im Speicher.

Beispiel (Kubernetes + CSI, konzeptionell)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) CI/CD und IaC Integrationen

CI: Worker erhalten kurzlebige Token von OIDC (Workload Identity). Verbot von „maskierten“ Geheimnissen, die in die Protokolle fallen; Schritt „Scan von Lecks“ (trufflehog/gitleaks).
CD: deploy nimmt Geheimnisse zum Zeitpunkt des Layouts, schreibt sie nicht in Artefakte.
IaC: Terraform speichert Variablen im Secret Manager; Zustand (state) ist verschlüsselt und zugriffsbeschränkt.
SOPS/Alter: für Repos - verschlüsselte Manifeste speichern, Schlüssel - unter KMS.

Beispiel (SOPS-Fragment)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) Zugriffsrichtlinien und Authentifizierung von Arbeitslasten

Workload identity: SPIFFE/SPIRE, Kubernetes SA→OIDC→IAM-роль, mTLS.
Temporäre Token: kurze TTL, schmaler Umfang.
ABAC/RBAC im Secret Manager: „wer das Geheimnis von X in der Umgebung von Y lesen kann“ ist getrennt von „wer erstellen/rotieren kann“.
Multi-Leasing: separate Namespaces/Schlüsselringe pro Mieter; Einzelrichtlinien und Berichterstattung.

10) Rotation, Versionen und Kompatibilität

Trennen Sie die ID des Geheimnisses und seiner Version ('secret/app/db # v17').
Unterstützen Sie zwei aktive Versionen (N und N-1) für nonstop Rotation.
Rotation ist ereignisbezogen: bei Kündigung, Kompromittierung, Anbieterwechsel, Algorithmenmigration.
Automatisieren: cron/Rotations-Backend im Vault/Secret Manager + Webhook-Trigger für App-Relaunch/Reneval.

Mini-Rezept „zwei Schlüssel“ Rotation Webhook

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) Speicherung außerhalb des Rantimes: Backups und Artefakte

Niemals in Artefakte (Bilder, Logarchive, Dumps) geraten.
Secret Manager Backups - Verschlüsselung, Speicherschlüssel außerhalb der gleichen Kontur (Trennung von Pflichten).
Tags und DLP-Scans: Entdecken Sie Geheimnisse in S3/Blob/GCS, Git, CI-Artefakten.

12) Beobachtbarkeit, Audit und SLO

Metriken: Anzahl der Ausgaben/Geheimnis/Service, Anteil der abgelaufenen Lease, durchschnittliche TTL, Rotationszeit, Konvergenzzeit (Sekunden/Minuten vor der „Annahme“ einer neuen Version).
Audit-Protokolle: wer/was/wann/woher/warum; Speicherung separat, auch verschlüsselt.
SLO: 99% der Ausgaben <200 ms; 0 Lecks in den Protokollen; 100% der Geheimnisse besitzen/TTL/Tags; 100% kritische Geheimnisse - dynamisch oder Rotation ≤ 30 Tage.
Alerts: Secret erlischt <7 Tage (für Statiker), Anstieg der Authentifizierungsfehler zum Tresor, keine Geheimlesungen> N Tage (tot), unerwartete Geo-/ASN-Quellen.

13) Häufige Fehler und wie man sie vermeidet

Geheimnisse in Git/Bildern. Verwenden Sie SOPS/age und Scanner; Politik verbieten „nackte“ Zeilen.
Envvars als Langzeitträger. Bevorzugen Sie tmpfs/in-memory-Dateien; Reinigen Sie die Umgebung mit Gabeln/Dumps.
Die gleichen Geheimnisse für dev/stage/prod. Nach Umgebung aufteilen.
Langlebige statische Passwörter. Wechseln Sie zu Dynamic/Short Living.
Ein einziger Generalschlüssel „für alles“. Teilen Sie nach Mietern/Projekten/Dienstleistungen.
Kein Hot-Reload. Die Anwendung erfordert einen Neustart → das Fenster der Sicherheitsanfälligkeit während der Rotation.

14) Beispiele für Integrationen (schematisch)

Vault dynamischer Zugriff auf Postgres

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

JWT-Signatur von Anforderungen (kurze Laufzeit)

Der private Schlüssel wird im Secret Manager gespeichert; Der Dienst fordert ein kurzlebiges Signing-Token an und der lokale Agent signiert Payload (der Schlüssel wird nicht als String an die Anwendung übergeben).

SSH-Zertifikate für Administratoren

Ausgabe von SSH-cert für 10 Minuten über SSO (OIDC), ohne Verteilung persistenter Schlüssel.

15) Sicherheit an den Rändern

Logs/Traces/Metriken: Desinfektionsmittel, Filter für bekannte Schlüssel/Muster; „geheime“ Felder - Maskierung im APM.
Dumps/Crash-Berichte: Standardmäßig ausschneiden; bei Bedarf verschlüsseln und reinigen.
Client-Anwendungen/Mobile: Offline-Geheimnisse minimieren, Plattformspeicher (Keychain/Keystore) verwenden, an das Gerät binden, TLS-Pinning mit Notausrollen.

16) Compliance

PCI DSS: Verbot der Speicherung von PAN/Geheimnissen ohne Verschlüsselung; strenge Zugangskontrolle und Rotation.
ISO 27001/SOC 2: Anforderungen an Asset Management, Logging, Zugriffskontrolle, Konfigurationsänderungen.
DSGVO/lokale Regulierungsbehörden: Minimierung, Zugriff bei Bedarf, Audit.

17) Prozesse und Runbook

Inbetriebnahme

1. Inventarisierung von Secrets (Repositories, CIs, Images, Runtime, Backups).
2. Klassifizierung und Tags (Owner, Environment, Tenant, Rotation-Policy).
3. Speicherauswahl (Vault/Cloud SM) + Integration mit KMS/HSM.
4. Einrichten der Ausgabe durch Workload Identity (OIDC/SPIRE).
5. Aktivieren Sie dynamische Geheimnisse für DB/Cloud/PKI.
6. Auto-Rotation und Hot-Reload; Alerts auf Auslöschung.
7. Aufbau von Leck-Scannern und Data Catalog/DS.

Notfallszenarien

Verdacht auf Leck: Zugangsstoppliste, sofortige Rotation, Widerruf von Zertifikaten/Schlüsseln, Neuausstellung von Token, Aktivierung eines erweiterten Audits, RCA.
Secret Manager nicht verfügbar: lokaler Cache im Speicher mit kleiner TTL, Funktionsdegradation, Einschränkung neuer Verbindungen, manuelle Break-Glass-Schritte.
Root-Key-Kompromittierung: Key-Hierarchie-Regeneration, Rewrap aller DEKs, Überprüfung aller Ausgaben über das Risikofenster hinaus.

18) Checklisten

Vor dem Verkauf

• Geheimnisse aus Code/Images entfernt; Leckage-Scanner sind enthalten.
• Für kritische Geheimnisse sind dynamische Mechanismen aktiviert.
• Lieferung über sidecar/CSI/tmpfs mit Hot-Reload, ohne langlebige Envvars.
• IAM/ABAC-Richtlinien konfiguriert, Bindung an Workload-Identität.
• Auto-Rotation und Doppelversionen (N, N-1) für Kompatibilität.
• Metriken/Warnungen/Audit enthalten; Die Degradationstests sind bestanden.

Betrieb

• Monatsbericht: Eigentümer, TTL, abgelaufene Geheimnisse, ungenutzt.
• Periodische Rotationen und Pentests von Kriechwegen (Protokolle, Dumps, Artefakte).
• Crypto-Agility-Plan und Notfall-CA/root-Ersatz.

19) FAQ

F: Ist Secret Manager ohne KMS ausreichend?
A: Für die Basisebene - ja, aber es ist besser, Envelope-Verschlüsselung zu verwenden: KEK in KMS/HSM, Geheimnisse - verpackt. Dies vereinfacht den Rückruf und die Compliance.

F: Was soll ich wählen - Statik oder Dynamik?
A: Die Standardeinstellung ist Dynamik. Lassen Sie Statik nur dort, wo es keine unterstützten Anbieter gibt, und brennen Sie TTL auf Tage/Stunden + automatische Rotation.

Q: Wie man sicher Geheimnisse in Microservice wirft?
О: Workload identity → mTLS к Secret Manager → sidecar/CSI → файлы в tmpfs + hot-reload. Keine Protokolle, keine envvars „für immer“.

F: Ist es möglich, Geheimnisse in Kubernetes Secret zu bewahren?
A: Nur bei aktivierter etcd-Verschlüsselung mit KMS-Provider und strengen Richtlinien. Bevorzugen Sie externen Speicher und CSI.

F: Wie kann man den Zugang eines Mieters „Krypto-löschen“?
A: Seine Richtlinien in Secret Manager zurückziehen/blockieren, alle Leases deaktivieren, Schlüssel rotieren/regenerieren; Bei Verwendung von KMS - Deaktivieren Sie die entsprechenden KEK-Wraps.

• „At Rest Verschlüsselung“
• „Verschlüsselung im Transit“
• „Schlüsselmanagement und Rotation“
• „S2S-Authentifizierung“
• „Signieren und Verifizieren von Anfragen“