0Pricing
Cyber Security Academy · Lektion

Dynamische Secrets und Leasing

Kurzlebige, automatisch ablaufende Zugangsdaten

Dynamische Secrets und Leasing ist eine kostenlose Cyber Security Academy-Lektion auf CoddyKit. Dies ist Lektion 3 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.

Statische und dynamische Secrets

Ein statisches Secret wird einmal erstellt und anschließend unbegrenzt wiederverwendet – etwa dasselbe Datenbankpasswort, das zehn Services jahrelang gemeinsam nutzen. Statische Secrets sind der Standard und zugleich das Problem: Sie sind langlebig, weit verbreitet und schwer zu rotieren.

Ein dynamisches Secret wird bei Bedarf generiert, ist für genau einen Consumer eindeutig und läuft automatisch ab. Statt ein Passwort zu speichern, erstellt der Vault bei jeder Anfrage ein vollständig neues Credential.

Diese eine Änderung löst die schwierigsten Probleme des Secrets-Managements: Die Rotation wird automatisch, und der Blast Radius jedes Leaks schrumpft nahezu auf null.

Funktionsweise dynamischer Secrets

Dynamische Secrets setzen voraus, dass der Vault über privilegierten Zugriff auf das Backend-System verfügt. Der Ablauf für eine Datenbank sieht so aus:

  • Ein Administrator konfiguriert den Vault mit einem Root-Datenbank-Credential und einer Vorlage zur Erstellung.
  • Eine Anwendung authentifiziert sich und fordert ein Credential an.
  • Der Vault führt CREATE USER in der Datenbank aus und gibt einen neuen Benutzernamen samt Passwort zurück.
  • Wenn die Lease abläuft, führt der Vault automatisch DROP USER aus.

Die Anwendung sieht niemals ein langlebiges Passwort. Sie erhält ein temporäres Credential, das an ihre Identität und ihre Lease gebunden ist.

# Configure Vault's database engine with a creation statement
vault write database/roles/billing-readonly \
  db_name=appdb \
  creation_statements="CREATE ROLE \"{{name}}\" LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON billing TO \"{{name}}\";" \
  default_ttl="1h" max_ttl="24h"

Dynamische Zugangsdaten anfordern

Wenn eine Anwendung Zugriff auf eine Datenbank benötigt, fordert sie beim Vault ein Credential an. Die Antwort enthält einen eindeutigen, gerade erstellten Benutzernamen und ein Passwort sowie eine Lease, die angibt, wie lange sie gültig sind.

Jeder Consumer erhält ein eigenes Credential. Wenn zwei Pods desselben Services starten, bekommen sie zwei unterschiedliche Benutzernamen. Dadurch wird ein Audit pro Consumer auf Datenbankebene möglich.

vault read database/creds/billing-readonly

# Example response:
# lease_id     database/creds/billing-readonly/abc123
# lease_duration  1h
# password     A1b-2Cd3-temp-xyz
# username     v-approle-billing-9f3a2

Leases: Der Vertrag über die Gültigkeitsdauer

Eine Lease ist ein Vertrag, der festlegt, wie lange ein Secret gültig ist. Jedes dynamische Secret besitzt eine TTL (time to live) und optional eine max TTL.

  • default_ttl gibt an, wie lange das Credential vor seinem Ablauf gültig ist.
  • max_ttl ist die absolute Obergrenze, auch bei Verlängerungen.

Wenn die Lease abläuft, widerruft der Vault das Credential und löscht den Datenbankbenutzer aktiv. Der Ablauf ist nicht nur ein Statusmerkmal, sondern löst eine tatsächliche Bereinigung aus. Dadurch werden geleakte dynamische Secrets selbstheilend: Ein gestohlenes Credential ist innerhalb des TTL-Zeitfensters unbrauchbar.

Leases verlängern und widerrufen

Lang laufende Anwendungen, deren Laufzeit über eine Lease hinausgeht, müssen diese vor ihrem Ablauf verlängern. Die Verlängerung erhöht die TTL bis zur maximalen TTL. Danach muss die Anwendung ein neues Credential anfordern.

Betreiber können eine Lease auch sofort widerrufen – als Notausschalter während eines Sicherheitsvorfalls. Beim Widerruf einer Lease wird das zugrunde liegende Credential sofort gelöscht, unabhängig von der verbleibenden TTL.

Sie können sogar alle Leases unter einem Präfix widerrufen, um einen gesamten Service oder eine ganze Umgebung sofort abzuschalten.

# Renew a lease before it expires
vault lease renew database/creds/billing-readonly/abc123

# Revoke a single lease immediately (incident kill switch)
vault lease revoke database/creds/billing-readonly/abc123

# Revoke every lease under a path prefix
vault lease revoke -prefix database/creds/billing-readonly

Über Datenbanken hinaus

Dynamische Secrets sind nicht auf Datenbanken beschränkt. Vault und ähnliche Tools generieren kurzlebige Zugangsdaten für viele Systeme:

  • Cloud-IAM temporäre AWS-/GCP-/Azure-Zugriffsschlüssel über eine Assume-Role-Funktion nach dem STS-Muster.
  • SSH signierte, kurzlebige SSH-Zertifikate anstelle statischer Schlüssel.
  • PKI/TLS bei Bedarf ausgestellte Zertifikate mit kurzer Gültigkeitsdauer.
  • RabbitMQ, MongoDB, Consul kurzlebige Service-Credentials.

Das Muster ist überall gleich: anfordern, kurz verwenden, automatisch ablaufen lassen. Statische, langlebige Cloud-Schlüssel sind eine häufige Ursache für Sicherheitsverletzungen. Dynamische IAM-Credentials machen sie überflüssig.

# Generate temporary AWS credentials scoped to a role
vault read aws/creds/deploy-role
# returns short-lived access_key, secret_key, security_token

# Sign an SSH key for short-lived access (valid minutes, not forever)
vault write ssh/sign/admin public_key=@id_ed25519.pub ttl=15m

Warum dynamische Secrets den Blast Radius verkleinern

Betrachten Sie ein geleaktes Credential unter den beiden Modellen:

  • Statisch: Das Passwort bleibt gültig, bis ein Mensch den Leak bemerkt, es rotiert und bei jedem Consumer aktualisiert. Das Zeitfenster der Gefährdung beträgt Tage oder Monate.
  • Dynamisch: Das Credential läuft innerhalb seiner TTL ab (oft nach wenigen Minuten bis zu einer Stunde) und war auf einen einzigen Consumer mit minimalen Berechtigungen beschränkt. Das Zeitfenster der Gefährdung ist sehr kurz und der Schaden begrenzt.

Dynamische Secrets machen aus der Rotation ein automatisches, kontinuierliches Merkmal des Systems statt eines aufwendigen manuellen Projekts.

Der Zielkonflikt beim Root-Credential

Dynamische Secrets sind leistungsfähig, setzen aber voraus, dass der Vault für jedes Backend ein hochprivilegiertes Root-Credential besitzt, mit dem er die von ihm ausgegebenen Benutzer anlegen kann. Dadurch wird das Risiko im Vault konzentriert.

Gegenmaßnahmen:

  • Rotieren Sie das Root-Credential selbst, damit auch der Vault nicht dauerhaft das ursprüngliche Admin-Passwort behält.
  • Beschränken Sie das Root-Konto genau auf die Berechtigungen, die zum Anlegen und Löschen von Benutzern erforderlich sind – auf nichts darüber hinaus.
  • Isolieren und überwachen Sie den Vault-Host konsequent, da er nun ein besonders wertvolles Ziel darstellt.

Vault kann sein eigenes Root-Credential rotieren, sodass es nach der Einrichtung kein Mensch kennt.

# After configuring the engine, rotate the root credential
# so even operators no longer know the original password
vault write -force database/rotate-root/appdb

Ablauf in Anwendungscode behandeln

Anwendungen müssen darauf ausgelegt sein, dass sich Zugangsdaten ändern. Bei statischen Secrets liest der Code das Passwort einmal beim Start. Bei dynamischen Secrets muss der Code:

  • Ein Credential abrufen und die TTL seiner Lease notieren.
  • Die Lease verlängern oder vor ihrem Ablauf ein neues Credential abrufen.
  • Sich geordnet neu verbinden, wenn ein altes Credential widerrufen wurde.

Ein häufig verwendetes Muster ist ein Sidecar-Agent, der den Lebenszyklus der Lease verwaltet und eine lokale Secret-Datei neu schreibt, sodass die Anwendung lediglich ihre Konfiguration neu lädt. Auch Verbindungspools müssen erneuert werden, damit sie nicht an einem abgelaufenen Credential festhalten.

# Vault Agent auto-renews and re-templates on rotation
auto_auth { method "approle" { ... } }
template {
  contents    = "{{ with secret \"database/creds/billing-readonly\" }}{{ .Data.username }}:{{ .Data.password }}{{ end }}"
  destination = "/run/secrets/db"
  command     = "systemctl reload billing-app"
}

Wenn statische Secrets unvermeidbar sind

Nicht jedes Secret kann dynamisch sein. Einige Drittanbieter-APIs stellen einen einzigen langlebigen Schlüssel aus, der nicht bei Bedarf generiert werden kann. Wenden Sie für diese statischen Secrets kompensierende Maßnahmen an:

  • Speichern Sie sie im Vault, niemals im Code.
  • Beschränken Sie sie auf die geringsten erforderlichen Berechtigungen.
  • Rotieren Sie sie nach einem Zeitplan (das wird in der nächsten Lektion behandelt).
  • Überwachen Sie ihre Verwendung auf Anomalien.

Die Faustregel lautet: Bevorzugen Sie dynamische Secrets; wenn statische unvermeidbar sind, rotieren und auditieren Sie sie konsequent.

Dynamische Secrets in CI/CD

CI/CD-Pipelines sind ein besonders geeigneter Anwendungsfall. Traditionell enthält eine Pipeline langlebige Deployment-Schlüssel – ein äußerst lohnendes Ziel. Mit dynamischen Secrets:

  • Authentifiziert sich die Pipeline beim Vault mit ihrer OIDC-Identität (z. B. einem GitHub Actions OIDC-Token).
  • Fordert sie kurzlebige Cloud-Credentials an, die nur für die Dauer des Jobs gültig sind.
  • Lässt sie diese automatisch ablaufen, sobald der Job endet.

Es existiert niemals ein langlebiger Deployment-Schlüssel. Ein kompromittiertes Pipeline-Log gibt ein Credential preis, das bereits ungültig ist, wenn es jemand liest.

# GitHub Actions job exchanges its OIDC token for a short-lived AWS role
# No static AWS keys stored as repo secrets
permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123:role/deploy
      aws-region: eu-central-1

Kurzer Wissenstest

Testen Sie Ihr Verständnis von Leases und dynamischen Secrets.

Zusammenfassung: Dynamische Secrets und Leases

Sie haben gelernt, wie kurzlebige, automatisch ablaufende Credentials das Secrets-Management verändern.

  • Dynamische Secrets werden bei Bedarf generiert, sind für jeden Consumer eindeutig und laufen automatisch ab – anders als wiederverwendete statische Secrets.
  • Eine Lease definiert eine TTL und eine maximale TTL. Bei ihrem Ablauf widerruft der Vault das Credential und führt eine tatsächliche Bereinigung durch.
  • Leases können von lang laufenden Anwendungen verlängert oder als Notausschalter bei einem Sicherheitsvorfall sofort widerrufen werden.
  • Dynamische Secrets funktionieren für Datenbanken, Cloud-IAM, SSH, PKI und weitere Systeme. Sie verkleinern den Blast Radius und automatisieren die Rotation.
  • Der Zielkonflikt besteht in einem privilegierten Root-Credential im Vault. Rotieren und beschränken Sie es strikt.
  • Anwendungen und CI/CD müssen auf den Ablauf von Zugangsdaten vorbereitet sein. Bevorzugen Sie dynamische Secrets und rotieren Sie statische, wenn diese unvermeidbar sind.

Als Nächstes behandeln wir die Rotation von Schlüsseln und das Erkennen von Leaks, wenn diese dennoch auftreten.

Häufig gestellte Fragen

Ist die Lektion „Dynamische Secrets und Leasing“ kostenlos?

Ja — der vollständige Text von „Dynamische Secrets und Leasing“ 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 „Dynamische Secrets und Leasing“?

Kurzlebige, automatisch ablaufende Zugangsdaten 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 3 von 4.

Wie lange dauert die Lektion „Dynamische Secrets und Leasing“?

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