Secret-Rotation: Warum, wann und wie – ohne das System zu gefährden

Sie haben Ihre Secrets sicher in einem Vault gespeichert. Ihre Pipeline injiziert sie zur Deployment-Zeit. Alles sieht solide aus. Aber es gibt ein Problem, das Sie vielleicht nicht bedacht haben: Dasselbe Secret, monatelang oder jahrelang verwendet, ist eine Zeitbombe.

Stellen Sie sich vor, ein Entwickler fügt versehentlich einen API-Key in einen Screenshot während einer Firmenpräsentation ein. Oder eine Logdatei von vor sechs Monaten enthält noch ein Datenbankpasswort, und jemand mit unbefugtem Zugriff findet es. Je länger ein Secret lebt, desto höher ist die Wahrscheinlichkeit, dass es unbemerkt durchsickert. Rotation ist Ihr Sicherheitsnetz: Wenn ein Secret doch durchsickert, ist seine Nutzungsdauer bereits abgelaufen, bevor der Leck ausgenutzt werden kann.

Warum Secrets rotieren?

Der grundlegendste Grund für die Rotation ist die Verkürzung Ihres Angriffszeitfensters. Wenn ein API-Key ein Jahr gültig ist und im dritten Monat durchsickert, hat ein Angreifer neun Monate lang Zugriff. Wenn Sie diesen Key jedoch jede Woche rotieren, beträgt das maximale Schadensfenster sieben Tage.

Rotation ist auch für Compliance relevant. Standards wie PCI DSS und SOC 2 fordern eine regelmäßige Secret-Rotation. Aber selbst ohne regulatorischen Druck ist Rotation ein praktischer Abwehrmechanismus. Sie begrenzt den Schadensradius, zwingt Sie dazu, zu überprüfen, ob Ihre Secret-Management-Pipeline tatsächlich funktioniert, und schafft operative Muskelgedächtnis für den Umgang mit Credential-Änderungen unter ruhigen Bedingungen, nicht erst während eines Incidents.

Wann sollten Sie rotieren?

Es gibt drei Hauptszenarien, die eine Rotation auslösen.

Geplante Rotation. Dies ist der routinemäßige, vorhersehbare Zyklus. Alle 30, 60 oder 90 Tage, je nach Sensitivität des Secrets. Ein Datenbankpasswort für ein Produktionssystem könnte alle 30 Tage rotiert werden. Ein weniger kritischer interner API-Key könnte alle 90 Tage rotiert werden. Der Zeitplan sollte dem Risikoprofil dessen entsprechen, was das Secret schützt.

Incident-getriebene Rotation. Etwas ist passiert. Vielleicht haben Sie verdächtige Zugriffe in Audit-Logs entdeckt. Vielleicht ist ein Secret in einem öffentlichen GitHub-Repository aufgetaucht. Vielleicht wurde der Laptop eines Mitarbeiters kompromittiert. In diesen Fällen rotieren Sie sofort. Warten Sie nicht auf das nächste geplante Fenster. Geschwindigkeit ist wichtiger als Formalitäten.

Personalwechsel. Wenn jemand, der Zugriff auf Secrets hatte, das Team verlässt, die Rolle wechselt oder gekündigt wird, rotieren Sie alle Secrets, auf die diese Person Zugriff haben könnte. Hier geht es nicht um Vertrauen. Es geht darum, die Möglichkeit auszuschließen, dass Credentials, die sie auswendig gelernt, lokal gespeichert oder irgendwo notiert haben, nach Beendigung ihres Zugriffs noch gültig sind.

Wie rotiert man, ohne Anwendungen zu beeinträchtigen?

Hier liegt die Herausforderung. Wenn Sie ein Datenbankpasswort rotieren und alle Ihre Dienste plötzlich die Verbindung verlieren, haben Sie die Sache verschlimmert. Das Ziel ist eine Rotation ohne Ausfallzeit. Die zuverlässigste Strategie ist die Dual-Secret-Rotation, auch Rotation mit einer Übergangsphase genannt.

Dual-Secret-Rotation

Die Idee ist einfach: Ihre Anwendung akzeptiert während der Übergangszeit zwei gültige Secrets gleichzeitig. Hier ist die Schritt-für-Schritt-Anleitung:

Das folgende Sequenzdiagramm veranschaulicht den Dual-Secret-Rotationsprozess über einen Vault, einen Konfigurationsdienst und mehrere Anwendungsinstanzen hinweg:

So könnten Sie dies mit HashiCorp Vault und einer JSON-Konfigurationsdatei implementieren:

# Schritt 1: Neue Secret-Version generieren (alte behalten)
vault kv put secret/db-password \
  old_password="$(vault kv get -field=password secret/db-password)" \
  new_password="$(openssl rand -base64 32)"

# Schritt 2: Anwendungskonfiguration mit beiden Secrets aktualisieren
cat > /etc/myapp/config.json <<EOF
{
  "db": {
    "old_password": "$(vault kv get -field=old_password secret/db-password)",
    "new_password": "$(vault kv get -field=new_password secret/db-password)"
  }
}
EOF

# Schritt 3: Anwendung neu laden, um neue Konfiguration zu übernehmen
systemctl reload myapp

# Schritt 4: Nachdem alle Instanzen das neue Secret verwenden, altes entfernen
vault kv patch secret/db-password old_password=""

# Schritt 5: Konfiguration aktualisieren, um nur das neue Secret zu verwenden
cat > /etc/myapp/config.json <<EOF
{
  "db": {
    "password": "$(vault kv get -field=new_password secret/db-password)"
  }
}
EOF
systemctl reload myapp

1. Generieren Sie ein neues Secret in Ihrem Vault oder Secret Store. Löschen Sie das alte nicht.
2. Aktualisieren Sie Ihre Anwendungskonfiguration, sodass sie sowohl das alte als auch das neue Secret als gültig kennt.
3. Rollen Sie die aktualisierte Konfiguration aus. Alle laufenden Instanzen akzeptieren nun beide Secrets.
4. Warten Sie, bis jede Instanz die neue Konfiguration übernommen hat und das neue Secret verwendet.
5. Entfernen Sie das alte Secret aus der Konfiguration und rollen Sie erneut aus.

Während dieses Prozesses verliert Ihre Anwendung nie die Konnektivität. Wenn eine Instanz die neue Konfiguration noch nicht erhalten hat, funktioniert sie weiterhin mit dem alten Secret. Sobald sie das Update übernimmt, kann sie eines von beiden verwenden. Nachdem das alte Secret entfernt wurde, funktioniert nur noch das neue.

Dieser Ansatz funktioniert gut für Secrets, die direkt von Anwendungen konsumiert werden: Datenbankpasswörter, API-Keys, Service-to-Service-Tokens. Die wichtigste Voraussetzung ist, dass Ihr Anwendungscode oder Ihre Middleware mehrere gültige Credentials gleichzeitig unterstützt. Die meisten modernen Datenbanktreiber und HTTP-Clients können dies handhaben.

Koordination der Rotation über mehrere Dienste hinweg

Wenn ein einzelnes Secret von vielen Diensten gemeinsam genutzt wird, wird die Rotation komplexer. Stellen Sie sich ein Datenbankpasswort vor, das von zehn Microservices verwendet wird. Sie können es nicht ohne Koordination Dienst für Dienst rotieren. Wenn Dienst A auf das neue Passwort umstellt, während Dienst B noch das alte verwendet, und die Datenbank nur das neue Passwort akzeptiert, bricht Dienst B zusammen.

Eine Lösung ist die Verwendung eines Service Mesh oder Sidecar-Proxys, der Datenbankverbindungen zentral verwaltet. Der Sidecar übernimmt die Authentifizierung gegenüber der Datenbank. Ihre Dienste verbinden sich mit dem Sidecar, nicht direkt mit der Datenbank. Wenn Sie das Datenbankpasswort rotieren, aktualisieren Sie nur die Sidecar-Konfiguration. Die Dienste bekommen von der Rotation gar nichts mit.

Ein anderer Ansatz ist die Verwendung eines dynamischen Secret-Systems, das wir gleich behandeln werden. Aber für statische Secrets, die von vielen Konsumenten gemeinsam genutzt werden, ist ein Service Mesh oder ein dedizierter Connection Pooler das praktikabelste Muster.

Was ist bei der Rotation noch wichtig?

Rotation bedeutet nicht nur, einen Wert zu ändern. Es ist ein Prozess, der unterstützende Praktiken erfordert.

Audit-Logging. Jede Rotation sollte protokolliert werden. Wer hat sie ausgelöst, wann, welches Secret wurde rotiert und was war das Ergebnis? Dies ist für die Incident-Untersuchung und Compliance-Audits unerlässlich.

Zuerst im Staging testen. Rotieren Sie niemals ein Produktions-Secret, ohne den Prozess in einer Staging-Umgebung zu verifizieren. Das Staging sollte die Secret-Konsummuster der Produktion widerspiegeln. Wenn die Rotation etwas kaputt macht, soll es im Staging passieren, nicht in der Produktion.

Einen Rollback-Plan haben. Manchmal verursacht eine Rotation unerwartete Probleme. Vielleicht propagiert das neue Secret nicht richtig. Vielleicht übernimmt ein Dienst die Konfigurationsänderung nicht. Ihre Rotationsprozedur sollte eine Möglichkeit beinhalten, schnell zum alten Secret zurückzukehren. Das bedeutet, das alte Secret so lange gültig zu halten, bis Sie sicher sind, dass das neue überall funktioniert.

Praktische Checkliste für die Secret-Rotation

• Identifizieren Sie, welche Secrets rotiert werden müssen und ihr Risikolevel
• Definieren Sie Rotationszeitpläne basierend auf dem Risiko (30/60/90 Tage)
• Implementieren Sie Dual-Secret-Unterstützung im Anwendungscode oder in der Middleware
• Testen Sie die Rotationsprozedur in der Staging-Umgebung
• Dokumentieren Sie Rollback-Schritte, bevor Sie Produktions-Secrets rotieren
• Protokollieren Sie jede Rotation mit Zeitstempel, Operator und Ergebnis
• Automatisieren Sie geplante Rotationen, wo möglich
• Etablieren Sie einen Incident-Response-Prozess für Notfall-Rotationen

Das Fazit

Ein Secret, das sich nie ändert, ist eine Schwachstelle, die nur darauf wartet, ausgenutzt zu werden. Rotation begrenzt das Schadensfenster, erfüllt Compliance-Anforderungen und zwingt Sie, Ihre Secret-Management-Praktiken scharf zu halten. Das Dual-Secret-Muster bietet Ihnen einen sicheren Weg zur Rotation ohne Ausfallzeit. Aber Rotation ist nur ein Teil des Bildes. Die nächste Frage ist, ob Sie sich von statischen Secrets ganz lösen können, hin zu Secrets, die nach einmaliger Verwendung automatisch verfallen. Hier kommen dynamische Secrets ins Spiel.