Wenn ein Datenbank-Passwort nur Minuten statt Monate lebt

Ihr Team rotiert Datenbank-Passwörter alle drei Monate. Sie fühlen sich sicherer als Teams, die überhaupt nicht rotieren. Aber hier ist die unbequeme Frage: Was passiert, wenn ein Passwort zwei Tage nach der Rotation leakt? Dieses Secret ist dann noch weitere 88 Tage gültig. Jeder, der es findet, kann fast drei Monate lang auf Ihre Produktionsdatenbank zugreifen, bevor die nächste Rotation es ungültig macht.

Diese Lücke ist nicht theoretisch. Secrets leaken durch Logdateien, kompromittierte CI-Runner, Entwickler-Laptops oder fehlkonfigurierte Backups. Ein statisches Secret mit langer Lebensdauer gibt Angreifern ein großes Zeitfenster. Je länger ein Secret lebt, desto größer ist der Schaden, den ein einzelner Leak anrichten kann.

Hier kommt das Konzept der kurzlebigen Secrets ins Spiel. Statt ein Passwort zu speichern, das monatelang gültig ist, generieren Sie eine Berechtigung bei Bedarf, nutzen sie für genau eine Aufgabe und lassen sie sofort danach verfallen.

Was ein Secret dynamisch macht

Ein dynamisches Secret ist kein gespeicherter Wert. Es ist eine Berechtigung, die genau dann erstellt wird, wenn jemand sie benötigt – mit einer Lebensdauer von Minuten oder Sekunden. Wenn die Aufgabe abgeschlossen ist, verschwindet die Berechtigung. Niemand kann sie später wiederverwenden.

Stellen Sie sich dieses Szenario vor: Ihre CI-Pipeline muss eine Migration gegen eine PostgreSQL-Datenbank ausführen. Mit einem statischen Secret liest die Pipeline ein gespeichertes Passwort aus einem Vault, verbindet sich mit der Datenbank, führt die Migration aus und trennt die Verbindung. Dieses Passwort bleibt für die zukünftige Nutzung gültig. Wenn es jemand aus den Pipeline-Logs extrahiert, kann er sich jederzeit bis zur nächsten Rotation mit der Datenbank verbinden.

Das folgende Sequenzdiagramm zeigt, wie dieser Ablauf funktioniert:

sequenceDiagram participant CI as CI Pipeline participant V as Vault participant DB as Database CI->>V: DB-Zugriff für Migration anfordern V->>DB: Temporären Benutzer + Passwort erstellen DB-->>V: Zugangsdaten V-->>CI: Temporäre Zugangsdaten zurückgeben CI->>DB: Migration ausführen DB-->>CI: Migration abgeschlossen CI->>V: Aufgabe abgeschlossen melden V->>DB: Temporären Benutzer sperren DB-->>V: Bestätigt

Mit einem dynamischen Secret sendet die Pipeline eine Anfrage an einen Vault: „Ich brauche Datenbankzugriff für diese Migration.“ Der Vault erstellt einen brandneuen Benutzernamen und ein Passwort, gewährt Lese-/Schreibrechte auf das Migrationsschema und gibt die Zugangsdaten an die Pipeline zurück. Die Pipeline nutzt sie, schließt die Migration ab, und der Vault entzieht die Berechtigung automatisch. Der Benutzername und das Passwort, die für dieses Fünf-Minuten-Fenster existierten, sind jetzt tot. Selbst wenn die Pipeline-Logs leaken, sind die Zugangsdaten wertlos.

So sieht diese Vault-Anfrage in der Praxis aus:

# Dynamische Datenbank-Zugangsdaten von Vault anfordern
VAULT_RESPONSE=$(vault read -format=json database/creds/migration-role)

# Temporären Benutzernamen und Passwort extrahieren
DB_USER=$(echo "$VAULT_RESPONSE" | jq -r '.data.username')
DB_PASS=$(echo "$VAULT_RESPONSE" | jq -r '.data.password')

# Zugangsdaten für die Migration verwenden
psql "postgresql://${DB_USER}:${DB_PASS}@db.example.com:5432/production" \
  -f ./migrations/001_initial.sql

# Die Zugangsdaten laufen automatisch nach ihrer TTL ab (z. B. 5 Minuten)
# Kein manuelles Entziehen erforderlich

Der Kernunterschied: Lebensdauer

Statische Secrets haben lange Lebensdauern. Sie speichern sie, rotieren sie regelmäßig und hoffen, dass sie zwischen den Rotationen nicht leaken. Das Risiko ist proportional zur Lebensdauer. Ein Passwort, das alle 90 Tage rotiert wird, gibt einem Angreifer ein potenzielles 90-Tage-Fenster.

Dynamische Secrets haben kurze Lebensdauern. Sie werden für einen bestimmten Zweck erstellt und zerstört, sobald dieser Zweck erfüllt ist. Das Fenster für die Ausnutzung schrumpft von Monaten auf Minuten. Wenn eine Berechtigung leakt, ist sie bereits abgelaufen, bevor sie jemand findet.

Diese Verschiebung verändert die Art und Weise, wie Sie über Secret-Management denken. Statt zu fragen „Wer kann dieses Secret lesen?“ fragen Sie „Wer kann ein neues Secret anfordern?“ Der Vault erledigt den Rest.

Wie dynamische Secrets die Zugriffskontrolle verändern

Statische Secrets zwingen Sie dazu, den Zugriff auf gespeicherte Werte zu verwalten. Sie konfigurieren, wer ein bestimmtes Passwort lesen darf, und hoffen, dass dieses Passwort nicht kopiert oder geteilt wird. Wenn ein Entwickler schreibgeschützten Zugriff auf eine Datenbank benötigt, erstellen Sie entweder eine separate statische Berechtigung oder geben ihm dieselbe Berechtigung wie alle anderen.

Dynamische Secrets ermöglichen es Ihnen, Zugriffsrichtlinien auf Anfrageebene zu definieren. Wenn eine Pipeline Datenbankzugriff benötigt, erstellt der Vault eine Berechtigung mit genau den Rechten, die diese Pipeline benötigt. Eine reine Lesepipeline erhält eine reine Leseberechtigung. Eine Migrationspipeline erhält Schreibzugriff auf bestimmte Tabellen. Eine Analyse-Pipeline erhält Select-Only auf bestimmte Schemata.

Diese Granularität macht die Prüfung einfach. Jede Berechtigung ist an eine bestimmte Anfrage, eine bestimmte Pipeline und ein bestimmtes Zeitfenster gebunden. Sie können genau nachvollziehen, was passiert ist, wann und mit welchen Rechten.

Wann dynamische Secrets nicht passen

Dynamische Secrets sind leistungsstark, aber sie sind kein universeller Ersatz für statische Secrets. Einige Situationen erfordern weiterhin langlebige Berechtigungen.

Anwendungen, die dauerhafte Datenbankverbindungen aufrechterhalten, können keine Berechtigungen verwenden, die in Minuten ablaufen. Ein Webserver, der einen Verbindungspool offen hält, benötigt eine Berechtigung, die für die Lebensdauer der Verbindung gültig bleibt. In diesem Fall könnten Sie ein statisches Secret mit einer kürzeren Rotationsperiode verwenden oder ein Verbindungs-Pooling implementieren, das Berechtigungen aktualisieren kann, ohne aktive Verbindungen zu trennen.

Externe Systeme, die keine automatisierte Berechtigungserstellung unterstützen, stellen ebenfalls ein Problem dar. Wenn Sie sich gegenüber einer Drittanbieter-API authentifizieren müssen, die Token über einen manuellen Registrierungsprozess ausgibt, können Sie dafür keine dynamischen Berechtigungen generieren. Sie bleiben bei statischen Token hängen und müssen deren Rotation sorgfältig verwalten.

Einige Legacy-Systeme verfügen nicht über die APIs, die für die dynamische Bereitstellung von Berechtigungen erforderlich sind. Wenn Ihre Datenbank das programmatische Erstellen von Benutzern nicht unterstützt oder Ihr Cloud-Anbieter die manuelle Erstellung von IAM-Rollen erfordert, sind dynamische Secrets keine Option.

Tools, die dynamische Secrets verwalten

HashiCorp Vault ist das am weitesten verbreitete Tool für das dynamische Secret-Management. Es unterstützt die Berechtigungsgenerierung für PostgreSQL, MySQL, MongoDB, AWS, GCP und viele andere Systeme. Wenn ein Client eine Berechtigung anfordert, erstellt Vault sie, weist ihr eine Lease mit einer Time-to-Live zu und entzieht sie automatisch, wenn die Lease abläuft.

Andere Tools wie CyberArk Conjur und AWS Secrets Manager bieten ebenfalls dynamische Secret-Funktionen, obwohl die Implementierung variiert. Das wichtigste Merkmal, auf das Sie achten sollten, ist die automatische Erstellung und der automatische Entzug von Berechtigungen ohne manuelles Eingreifen.

Eine praktische Checkliste vor der Einführung dynamischer Secrets

Bevor Sie alle statischen Secrets durch dynamische ersetzen, gehen Sie diese Checkliste durch:

  • Unterstützt das Zielsystem die programmatische Berechtigungserstellung? Prüfen Sie, ob Ihre Datenbank oder Ihr Cloud-Anbieter eine API zum Erstellen temporärer Benutzer oder Rollen hat.
  • Kann Ihre Anwendung mit dem Ablauf von Berechtigungen umgehen? Wenn Ihre App langlebige Verbindungen unterhält, benötigen Sie eine Strategie zum Aktualisieren von Berechtigungen, ohne Verbindungen zu trennen.
  • Fordern Ihre Pipelines Berechtigungen bei Bedarf an? Dynamische Secrets funktionieren am besten, wenn jeder Pipeline-Durchlauf seine eigene Berechtigung anfordert, anstatt eine zwischengespeicherte wiederzuverwenden.
  • Ist Ihre Vault-Infrastruktur zuverlässig? Wenn der Vault ausfällt, kann niemand neue Berechtigungen anfordern. Planen Sie Hochverfügbarkeit ein.
  • Haben Sie geprüft, welche Pipelines tatsächlich dynamische Secrets benötigen? Einige Pipelines laufen so selten, dass ein statisches Secret mit einer kurzen Rotationsperiode einfacher zu verwalten ist.

Die konkrete Erkenntnis

Statische Secrets mit langer Lebensdauer erzeugen eine Sicherheitslücke, die mit jedem Tag zwischen den Rotationen wächst. Dynamische Secrets schließen diese Lücke, indem sie Berechtigungen nur für die Dauer einer einzelnen Aufgabe gültig machen. Der Trade-off ist Komplexität: Sie benötigen einen Vault, der die dynamische Bereitstellung unterstützt, Anwendungen, die mit kurzlebigen Berechtigungen umgehen können, und Systeme, die bei Bedarf Benutzer erstellen können. Aber für jede Berechtigung, die in einer automatisierten Pipeline oder einem kurzlebigen Prozess verwendet wird, sind dynamische Secrets der Unterschied zwischen einem Leak, der etwas ausmacht, und einem, der es nicht tut.