0Pricing
Cyber Security Academy · Lektion

Vaults und Secret Stores

Secrets mit Tools wie Vault zentralisieren

Vaults und Secret Stores ist eine kostenlose Cyber Security Academy-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cyber Security Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Was ein Secret Store löst

Ein Secret Store (oder Vault) ist ein zentralisierter, gehärteter Dienst, dessen einzige Aufgabe darin besteht, den Zugriff auf Secrets zu speichern, zu kontrollieren und zu auditieren. Er ersetzt die verstreuten Dateien und Umgebungsvariablen, die Secret-Sprawl verursachen.

Ein guter Secret-Manager bietet vier zentrale Funktionen:

  • Zentralisierte Speicherung Eine maßgebliche Quelle der Wahrheit.
  • Zugriffskontrolle Feingranulare Richtlinien dafür, wer und was die einzelnen Secrets lesen darf.
  • Auditprotokollierung Eine Aufzeichnung jedes Zugriffs für die Incident Response.
  • Verschlüsselung Secrets werden bei der Speicherung und bei der Übertragung verschlüsselt.

Beispiele sind HashiCorp Vault, AWS Secrets Manager, Azure Key Vault und GCP Secret Manager.

Aufbau von HashiCorp Vault

HashiCorp Vault ist ein beliebter Open-Source-Secret-Manager. Die Funktionen sind in einbindbare Secrets Engines gegliedert, die an Pfaden eingebunden werden.

  • KV engine speichert statische Schlüssel-Wert-Secrets.
  • Database engine erzeugt dynamische, kurzlebige Datenbankzugangsdaten.
  • PKI engine stellt TLS-Zertifikate bei Bedarf aus.
  • Transit engine bietet Verschlüsselung als Dienst, ohne Schlüssel offenzulegen.

Sie interagieren mit Vault über eine HTTP-API oder die CLI. Jeder Pfad wird durch Richtlinien gesteuert, die festlegen, wer dort lesen oder schreiben darf.

# Enable a KV v2 secrets engine at the 'secret/' path
vault secrets enable -path=secret kv-v2

# Write and read a static secret
vault kv put secret/app/db password='S3cr3t' user='app'
vault kv get secret/app/db

Das Seal-/Unseal-Modell

Vault schützt seine Daten mit einem Seal-/Unseal-Mechanismus. Beim Start ist Vault versiegelt: Der Dienst weiß, wo sich die verschlüsselten Daten befinden, kann sie aber nicht entschlüsseln.

Der Hauptschlüssel, mit dem der Speicher entschlüsselt wird, ist seinerseits mit einem Unseal-Schlüssel verschlüsselt. Mithilfe von Shamir's Secret Sharing wird dieser Unseal-Schlüssel in mehrere Teilstücke aufgeteilt, die an verschiedene Betreiber verteilt werden.

Ein konfigurierbarer Schwellenwert, zum Beispiel 3 von 5 Teilstücken, muss bereitgestellt werden, um den Schlüssel zu rekonstruieren und Vault zu entsiegeln. Keine einzelne Person kann Vault allein entsiegeln, wodurch der Dienst vor einer Kompromittierung durch Insider geschützt wird.

# Initialize Vault: 5 key shares, threshold of 3 to unseal
vault operator init -key-shares=5 -key-threshold=3

# Each operator supplies one shard until threshold is met
vault operator unseal <shard-1>
vault operator unseal <shard-2>
vault operator unseal <shard-3>

Authentifizierung: Wer sind Sie?

Bevor ein Client ein Secret lesen kann, muss er sich authentifizieren, um ein Token zu erhalten. Vault unterstützt zahlreiche Authentifizierungsmethoden, die auf unterschiedliche Identitäten zugeschnitten sind:

  • AppRole für Anwendungen und CI-Systeme (role ID + secret ID).
  • Kubernetes verwendet das Service-Account-Token des Pods.
  • AWS/GCP/Azure IAM vertraut der Identität der Cloud-Plattform.
  • OIDC/LDAP für menschliche Benutzer über SSO.

Das zentrale Prinzip: Die Identität stammt aus der Plattform, nicht aus einem langlebigen Passwort. Ein Kubernetes-Pod weist seine Identität mit seinem eigenen Service-Account-Token nach – es gibt kein Bootstrap-Secret, das geleakt werden könnte.

# App authenticates via AppRole to receive a token
vault write auth/approle/login \
  role_id="db-app-role" \
  secret_id="$WRAPPED_SECRET_ID"
# Response includes client_token used for subsequent reads

Autorisierung mit Richtlinien

Die Authentifizierung weist die Identität nach; Richtlinien legen fest, was diese Identität tun darf. Vault-Richtlinien werden in HCL geschrieben und folgen dem Prinzip der geringsten Rechte: Sie gewähren nur Zugriff auf die Pfade und Funktionen, die ein Workload benötigt.

Mit dieser Richtlinie kann ein Dienst ausschließlich sein eigenes Datenbank-Secret lesen und nichts anderes:

Funktionen entsprechen API-Verben: read, create, update, delete und list. Verweigern Sie standardmäßig und gewähren Sie Zugriff ausdrücklich.

# policy: billing-app.hcl
path "secret/data/billing/*" {
  capabilities = ["read"]
}
path "database/creds/billing-readonly" {
  capabilities = ["read"]
}
# everything else is implicitly denied

Cloud-native Secret Stores

Wenn Sie in einer einzelnen Cloud arbeiten, nimmt Ihnen der verwaltete Store des Anbieters den operativen Aufwand ab: keine Seal-/Unseal-Verwaltung und keine zu patchenden Server:

  • AWS Secrets Manager lässt sich in IAM integrieren und unterstützt integrierte Rotations-Lambdas.
  • Azure Key Vault speichert Secrets, Schlüssel und Zertifikate mit RBAC.
  • GCP Secret Manager bietet versionierte Secrets, die durch IAM-Bindings geschützt werden.

Der Zugriff wird durch das IAM der Cloud gesteuert. Ein Workload liest ein Secret mit seiner bestehenden Rolle, ohne separates Passwort. Der Nachteil sind die Anbieterabhängigkeit und die schwächere Unterstützung mehrerer Clouds im Vergleich zu Vault.

# Read a secret from AWS Secrets Manager (workload uses its IAM role)
aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text

# GCP equivalent
gcloud secrets versions access latest --secret=billing-db

Verschlüsselung als Dienst

Manchmal möchten Sie ein Secret überhaupt nicht speichern, sondern Anwendungsdaten verschlüsseln, ohne dass Ihre Anwendung jemals den Verschlüsselungsschlüssel besitzt. Genau das erledigt die Transit engine von Vault.

Die Anwendung sendet Klartext an Vault, erhält Chiffretext zurück und sieht den Schlüssel nie. Die Entschlüsselung funktioniert auf dieselbe Weise. Das wird Verschlüsselung als Dienst genannt.

Der Vorteil: Die Schlüssel befinden sich ausschließlich in Vault, können zentral rotiert werden, und eine kompromittierte Anwendung kann keinen Schlüssel offenlegen, den sie nie besessen hat.

# Encrypt data without the app ever seeing the key
vault write transit/encrypt/orders-key \
  plaintext=$(echo -n 'card=4111...' | base64)
# returns: ciphertext=vault:v1:abc123...

# Decrypt later
vault write transit/decrypt/orders-key ciphertext='vault:v1:abc123...'

Secrets in Workloads injizieren

Ein Vault ist nur dann nützlich, wenn Anwendungen Secrets ohne Hardcoding des Pfads oder Tokens nutzen können. Übliche Injektionsmuster sind:

  • Sidecar/Agent Ein Vault Agent läuft neben der Anwendung, authentifiziert sich und schreibt Secrets in ein gemeinsam genutztes In-Memory-Volume.
  • CSI driver Kubernetes mountet Secrets über den Secrets Store CSI driver als Dateien.
  • SDK fetch Die Anwendung ruft beim Start direkt die Vault-API auf.

Bevorzugen Sie das Mounten in ein In-Memory-Dateisystem (tmpfs) gegenüber Umgebungsvariablen und vermeiden Sie es, Secrets auf der Festplatte zu speichern, wo sie bestehen bleiben können.

# Vault Agent template renders a secret to an in-memory file
template {
  contents = "DB_PASS={{ with secret \"secret/app/db\" }}{{ .Data.data.password }}{{ end }}"
  destination = "/run/secrets/db.env"
}

Audit-Protokollierung und Nachvollziehbarkeit

Jeder Lese-, Schreib- und Authentifizierungsvorgang in einem Vault sollte in einem Audit-Log erfasst werden. Dadurch lässt sich das Secrets-Management während eines Sicherheitsvorfalls nachvollziehbar und belegbar machen.

Audit-Logs beantworten die entscheidenden Fragen: wer auf welches Secret zugegriffen hat, wann und von wo. Vault hasht sensible Werte in Logs, damit das Log selbst keine Secrets preisgibt.

Übertragen Sie Audit-Logs an ein manipulationssicheres, getrenntes System (SIEM), damit ein Angreifer, der den Vault-Host kompromittiert, nicht auch die Beweise für seine Zugriffe löschen kann.

# Enable a file audit device (HMAC-hashes secret values)
vault audit enable file file_path=/var/log/vault/audit.log

# Forward to a SIEM/syslog endpoint for tamper resistance
vault audit enable syslog tag="vault" facility="AUTH"

Den Vault selbst schützen

Ein zentraler Speicher bündelt das Risiko: Fällt der Vault aus, fällt alles aus. Sichern Sie ihn als Ihr wichtigstes Asset ab:

  • Betreiben Sie alle Endpunkte mit TLS; setzen Sie die API niemals unverschlüsselt aus.
  • Halten Sie den Vault in einem privaten Netzwerk hinter strengen Firewall-Regeln.
  • Aktivieren Sie das automatische Entsiegeln über ein Cloud-KMS, um die manuelle Handhabung von Schlüsselfragmenten zu vermeiden, und schützen Sie diesen KMS-Schlüssel besonders sorgfältig.
  • Verwenden Sie kurze Token-TTLs und verlängerbare Leases, damit gestohlene Tokens schnell ablaufen.
  • Installieren Sie Patches zeitnah und überwachen Sie Audit-Logs auf Anomalien.

Der Vault tauscht viele Ausfallpunkte gegen einen einzigen, dafür äußerst gut geschützten.

Den richtigen Speicher auswählen

Es gibt kein einziges bestes Tool. Stimmen Sie den Speicher auf Ihre Umgebung ab:

  • Eine Cloud, einfache Anforderungen: Verwenden Sie den nativen Manager (AWS/Azure/GCP), um den Betriebsaufwand möglichst gering zu halten.
  • Multi-Cloud oder On-Premises: HashiCorp Vault bietet eine konsistente, portable Abstraktion.
  • Dynamische Secrets oder Verschlüsselung als Service erforderlich: Die Engines von Vault sind am leistungsfähigsten.
  • Kubernetes-lastig: Kombinieren Sie einen Speicher mit dem CSI-Treiber oder einem Operator wie External Secrets.

Unabhängig von Ihrer Wahl bleibt das Ziel gleich: eine zentrale, auditierte und zugriffskontrollierte Quelle der Wahrheit anstelle verstreuter Klartextwerte.

Kurzer Wissenstest

Testen Sie Ihr Verständnis des Schutzmodells von Vault.

Zusammenfassung: Vaults und Secret Stores

Sie haben gelernt, wie sich verstreute Secrets durch einen zentralen, auditierten Speicher ersetzen lassen.

  • Ein Secret Store bietet zentrale Speicherung, Zugriffskontrolle, Audit-Protokollierung und Verschlüsselung.
  • HashiCorp Vault verwendet austauschbare Secrets Engines sowie ein Versiegelungs-/Entsiegelungsmodell, das durch Shamir's Secret Sharing geschützt wird.
  • Auth-Methoden leiten die Identität aus der Plattform ab (Kubernetes, IAM, AppRole), und Richtlinien erzwingen das Prinzip der geringsten Berechtigungen.
  • Cloud-native Speicher tauschen Portabilität gegen einen geringen Betriebsaufwand ein (AWS, Azure, GCP).
  • Die Transit Engine bietet Verschlüsselung als Service, sodass Anwendungen niemals Schlüssel besitzen.
  • Injizieren Sie Secrets über Agents oder CSI in einen In-Memory-Speicher, protokollieren Sie jeden Zugriff und sichern Sie den Vault als Ihr wichtigstes Asset ab.

Als Nächstes machen wir Secrets noch sicherer, indem wir sie dynamisch und kurzlebig generieren.

Häufig gestellte Fragen

Ist die Lektion „Vaults und Secret Stores“ kostenlos?

Ja — der vollständige Text von „Vaults und Secret Stores“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cyber Security Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Vaults und Secret Stores“?

Secrets mit Tools wie Vault zentralisieren Du übst Cyber Security Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cyber Security Academy zu starten?

Keine Vorkenntnisse erforderlich. Cyber Security Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Vaults und Secret Stores“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cyber Security Academy-Lektion Code schreiben und ausführen?

Ja. Jede Cyber Security Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Das Problem der Secrets-Verteilung
  2. Vaults und Secret Stores
  3. Dynamische Secrets und Leasing
  4. Schlüsselrotation und Erkennung
← Zurück zu Cyber Security Academy