Secrets-Rotation automatisieren: Nie rotierte Keys als offenes Risikofenster

1. Das Risikofenster statischer Secrets verstehen

Ein statisches Secret, das über Jahre unverändert bleibt, ist aus Sicht der Angriffsfläche kein einmaliges Risiko, sondern ein dauerhaftes. Jede Stelle, an der dieses Secret jemals aufgetaucht ist, sei es in einem CI-Log, einem Debugging-Screenshot, einem alten Backup oder einem Ex-Mitarbeiter-Laptop, bleibt eine potenzielle Quelle für eine Kompromittierung, solange der Wert gültig ist. Die Wahrscheinlichkeit, dass irgendeine dieser Stellen jemals in falsche Hände gerät, steigt mit jedem Tag, an dem das Secret nicht ausgetauscht wird.

Besonders gefährlich ist, dass viele Kompromittierungen unbemerkt bleiben. Ein Angreifer, der einen gültigen Datenbank-Zugang besitzt, muss nicht sofort auffällig handeln, sondern kann über Wochen oder Monate hinweg langsam Daten abziehen. Ohne Rotation bleibt dieser Zugang so lange gültig, wie das Secret selbst existiert, was in der Praxis oft Jahre bedeutet. Regelmäßige, automatisierte Rotation begrenzt diese Verweildauer strukturell, unabhängig davon, ob eine Kompromittierung überhaupt entdeckt wurde.

2. Warum manuelle Rotation in der Praxis scheitert

In vielen Teams existiert theoretisch eine Rotationsrichtlinie, die etwa eine Änderung von Datenbank-Passwörtern alle neunzig Tage vorsieht. In der Praxis wird diese Richtlinie selten konsequent umgesetzt, weil eine manuelle Rotation Koordinationsaufwand bedeutet: Man muss wissen, welche Anwendungen das Secret nutzen, einen Wartungsslot einplanen und das Risiko eines Ausfalls in Kauf nehmen, wenn eine Anwendung beim Umschalten kurzzeitig mit dem alten Wert scheitert.

Dieser Aufwand führt dazu, dass Rotation entweder ganz ausbleibt oder nur nach einem tatsächlichen Sicherheitsvorfall nachträglich durchgeführt wird, wenn der Schaden bereits entstanden ist. Automatisierung löst genau dieses Dilemma, weil sie den Koordinationsaufwand aus dem Prozess entfernt und Rotation zu einem planbaren, wiederkehrenden Vorgang macht, der ohne menschliches Zutun und ohne Ausfallzeit abläuft.

3. Wie ein Secret-Manager wie HashiCorp Vault die Rotation übernimmt

Ein Secret-Manager wie HashiCorp Vault fungiert als zentrale, dynamische Quelle für Zugangsdaten. Statt dass eine Anwendung ein festes Datenbank-Passwort in ihrer Konfiguration hinterlegt, fragt sie bei Bedarf ein kurzlebiges Zugangsdatum bei Vault an, das Vault selbst gerade erst erzeugt hat. Vault verwaltet dabei die eigentliche Rotation gegen die Datenbank direkt, sodass das lang lebende Master-Passwort niemals in einer Anwendungskonfiguration auftaucht.

Der Database-Secrets-Engine von Vault legt dazu Rollen an, die festlegen, welche Rechte ein dynamisch erzeugter Benutzer erhalten soll und wie lange dessen Gültigkeit ist. Nach Ablauf der Gültigkeit wird der Benutzer automatisch aus der Datenbank entfernt, wodurch kompromittierte Zugangsdaten von selbst nutzlos werden, ganz ohne manuelles Eingreifen.

# Vault Database Secrets Engine für PostgreSQL konfigurieren
vault secrets enable database

vault write database/config/shop-db \
    plugin_name=postgresql-database-plugin \
    allowed_roles="app-readwrite" \
    connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/shop" \
    username="vault-admin" \
    password="initiales-admin-passwort"

# Rolle mit kurzlebigen, dynamisch erzeugten Zugangsdaten anlegen
vault write database/roles/app-readwrite \
    db_name=shop-db \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' \
        VALID UNTIL '{{expiration}}'; GRANT SELECT, INSERT, UPDATE ON ALL TABLES \
        IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

# Anwendung fragt bei Bedarf ein frisches, kurzlebiges Credential an
vault read database/creds/app-readwrite

4. Die Dual-Secret-Übergangsphase ohne Downtime

Bei Secrets, die nicht dynamisch von der Datenbank selbst erzeugt werden können, etwa bei API-Keys eines externen Dienstes, funktioniert Zero-Downtime-Rotation über eine kurze Übergangsphase, in der zwei Secrets gleichzeitig gültig sind. Zunächst wird ein neuer Key beim Anbieter erzeugt, während der alte Key weiterhin aktiv bleibt. Anschließend werden alle Anwendungsinstanzen nach und nach auf den neuen Key umgestellt, während der alte Key im Hintergrund noch funktioniert.

Erst nachdem verifiziert wurde, dass keine Anwendung mehr den alten Key verwendet, etwa durch Auswertung der Zugriffslogs des Anbieters, wird der alte Key deaktiviert. Dieses Vorgehen verhindert, dass eine Anwendung, die den Key gerade zwischengespeichert hat oder verzögert neu startet, mitten in der Rotation plötzlich mit einem ungültigen Wert scheitert. Die Übergangsphase dauert typischerweise wenige Minuten bis Stunden, je nach Deployment-Geschwindigkeit der betroffenen Systeme.

5. Rotation von Datenbank-Passwörtern versus API-Keys

Datenbank-Passwörter lassen sich meist eleganter rotieren als API-Keys, weil ein Secret-Manager mit ausreichenden Rechten sowohl das Passwort in der Datenbank ändern als auch neue, kurzlebige Zugangsdaten ausgeben kann, ohne auf eine externe Instanz angewiesen zu sein. Diese enge Integration erlaubt es, die Gültigkeitsdauer sehr kurz zu halten, teilweise nur wenige Stunden, ohne dass daraus operativer Mehraufwand entsteht.

API-Keys externer Dienste hingegen erfordern in der Regel einen Aufruf der jeweiligen Anbieter-API, um einen neuen Key zu erzeugen und den alten zu widerrufen. Nicht jeder Anbieter unterstützt dabei eine parallele Gültigkeit mehrerer Keys, weshalb die Dual-Secret-Übergangsphase je nach Anbieter unterschiedlich gestaltet werden muss. Ein guter Secret-Manager kapselt diese Unterschiede hinter einer einheitlichen internen Schnittstelle, sodass Anwendungsteams sich nicht mit den Eigenheiten jedes einzelnen Anbieters beschäftigen müssen.

6. Anwendungen so gestalten, dass Rotation keine Downtime verursacht

Damit Rotation ohne Ausfallzeit funktioniert, dürfen Anwendungen Secrets niemals dauerhaft im Speicher oder in einer Konfigurationsdatei festhalten, die erst bei einem Neustart neu gelesen wird. Stattdessen sollten Secrets bei Bedarf über eine Client-Bibliothek des Secret-Managers abgefragt werden, die selbstständig erkennt, wenn ein Secret abgelaufen ist, und automatisch ein frisches nachlädt, ohne dass die Anwendung neu gestartet werden muss.

Verbindungspools zu Datenbanken stellen dabei eine besondere Herausforderung dar, weil bereits bestehende Verbindungen mit den alten Zugangsdaten authentifiziert wurden und weiterlaufen können, auch nachdem das zugrunde liegende Passwort geändert wurde. Ein sauberes Rotationsdesign lässt bestehende Verbindungen bis zu ihrem natürlichen Ende bestehen und verwendet die neuen Zugangsdaten ausschließlich für neu aufgebaute Verbindungen, sodass kein abrupter Verbindungsabbruch entsteht.

7. Monitoring und Audit-Logging der Rotation

Automatisierte Rotation darf kein Vorgang sein, der im Verborgenen abläuft, denn Fehlfunktionen würden sonst erst bemerkt, wenn Anwendungen bereits ausfallen. Ein Secret-Manager sollte deshalb jedes ausgegebene, erneuerte und widerrufene Secret in einem revisionssicheren Audit-Log erfassen, das festhält, welche Identität wann welches Secret angefordert hat und wie lange es gültig war.

Dieses Audit-Log dient nicht nur der forensischen Aufarbeitung im Falle eines Vorfalls, sondern liefert auch die Grundlage für Alarmierung, etwa wenn ein Rotationsvorgang wiederholt fehlschlägt oder ein Secret außerhalb der erwarteten Nutzungsmuster abgefragt wird. Ein Dashboard, das die Rotationshistorie aller kritischen Secrets sichtbar macht, hilft Teams zudem, blinde Flecken zu erkennen, etwa Secrets, die aus technischen Gründen nie erfolgreich rotiert wurden.

8. Typische Stolperfallen bei der Einführung automatisierter Rotation

Ein häufiger Fehler ist, mit der Rotation aller Secrets gleichzeitig zu beginnen, statt schrittweise vorzugehen. Sinnvoller ist es, zunächst ein einzelnes, gut verstandenes Secret wie ein internes Datenbank-Passwort zu automatisieren, den gesamten Prozess einschließlich Monitoring zu validieren und erst danach schrittweise weitere, kritischere Secrets wie Zahlungsanbieter-Keys zu ergänzen.

Ein weiterer häufiger Fehler ist, die Rotationsintervalle zu aggressiv zu wählen, ohne vorher zu prüfen, ob alle abhängigen Systeme tatsächlich mit kurzlebigen Credentials umgehen können. Legacy-Systeme, die Secrets fest in einer Konfigurationsdatei erwarten, benötigen oft zunächst eine Anpassung, bevor sie in einen automatisierten Rotationszyklus mit sehr kurzen Intervallen integriert werden können, ohne dass es zu Ausfällen kommt.

9. Eine realistische Roadmap für den Einstieg

Der Einstieg gelingt am besten mit einer Bestandsaufnahme aller aktiven Secrets im Unternehmen, samt Angabe, wo sie gespeichert sind und wann sie zuletzt geändert wurden. Diese Bestandsaufnahme deckt in der Praxis fast immer Secrets auf, die niemand mehr aktiv im Blick hat, etwa vergessene Test-API-Keys mit produktiven Rechten.

Anschließend lohnt es sich, mit den Secrets zu beginnen, die das größte Risiko bei einer Kompromittierung darstellen, etwa Datenbank-Zugänge mit Schreibrechten auf Kundendaten oder Zahlungsanbieter-Keys. Sobald für diese kritischen Secrets ein stabiler, automatisierter Rotationsprozess mit Monitoring steht, lässt sich der Ansatz schrittweise auf weniger kritische Secrets ausweiten, bis am Ende kein Secret im Unternehmen mehr unbegrenzt gültig ist.

10. Zusammenfassung

11. FAQ: Secrets-Rotation automatisieren: Das Wichtigste auf einen Blick