Key Rotation

Einfach erklärt

Key Rotation tauscht Credentials risikobasiert aus und kann Schaden bei Leaks begrenzen.

Ohne Rotation:
Key geleakt → Angreifer kann Zugang behalten, bis der Leak erkannt und behoben wird

Mit Rotation:
Key geleakt → Laufzeit und Rotation begrenzen das Zeitfenster, abhängig vom Intervall

Technischer Deep Dive

Secrets-Manager-Rotation

# Automatische Rotation konfigurieren
secrets-manager rotate-secret \
    --secret-id DATABASE_SECRET \
    --rotation-handler ROTATION_HANDLER \
    --rotation-rules ROTATION_POLICY

Zero-Downtime Rotation

1. Neuen Key generieren
2. Beide Keys parallel gültig
3. Anwendungen auf neuen Key umstellen
4. Alten Key deaktivieren

Rotationsstrategien im Vergleich

Strategie	Ablauf	Geeignet für
Geplante Rotation	Regelmäßiger Austausch nach Zeitplan oder Policy	Langlebige Credentials, Compliance-Vorgaben
Ereignisbasierte Rotation	Sofortige Rotation nach Leak, Offboarding oder Incident	Sicherheitsvorfälle, Personalwechsel
Dynamische Secrets	Credentials werden pro Anfrage frisch erzeugt und laufen automatisch ab	Datenbanken, Cloud-Zugriffe mit kurzlebigen Tokens

Je kürzer die Lebensdauer eines Secrets, desto weniger wichtig wird die manuelle Rotation – dynamische, kurzlebige Credentials sind deshalb das Zielbild vieler moderner Architekturen.

Key Rotation in KI- und LLM-Systemen

KI-Anwendungen bringen eigene Rotationsanforderungen mit:

• LLM-Provider-Keys: API-Keys für Sprachmodell-Dienste sind direkt kostenwirksam. Ein geleakter Key erlaubt Inferenz auf fremde Rechnung – regelmäßige Rotation und Budgetlimits begrenzen den Schaden.
• Viele Integrationen, viele Keys: Typische KI-Stacks kombinieren LLM-APIs, Vektordatenbanken, Embedding-Dienste und Webhooks. Jede Integration braucht ein eigenes Secret mit eigenem Rotationsplan – ein zentrales Inventar verhindert vergessene Altlasten.
• Agenten als Maschinenidentitäten: KI-Agenten, die selbstständig Tools aufrufen, sollten kurzlebige, automatisch rotierte Credentials nutzen. So bleibt ein kompromittierter Agent nur für ein kurzes Zeitfenster handlungsfähig.
• Keys nie im Prompt: Credentials gehören nicht in System-Prompts oder Modellkontexte. Taucht ein Key dort auf, gilt er als potenziell geleakt und muss rotiert werden.

Typische Stolperfallen

Fehler	Folge	Besser
Rotation ohne Overlap-Periode	Ausfälle, weil Anwendungen noch den alten Key nutzen	Beide Keys parallel gültig halten, dann alten deaktivieren
Kein Inventar der Key-Nutzer	Rotation bricht unbekannte Abhängigkeiten	Dokumentieren, welche Systeme welchen Key verwenden
Rotation nur manuell	Wird aufgeschoben oder vergessen	Automatisierung über Secrets Manager
Alter Key bleibt aktiv	Leak-Fenster schließt sich nie	Deaktivierung als fester Schritt im Prozess
Rotation ohne Monitoring	Fehler fallen erst bei Nutzern auf	Fehlerraten nach Rotation gezielt beobachten

Abgrenzung zu verwandten Begriffen

• Secrets Management ist der übergeordnete Prozess: sichere Speicherung, Zugriffskontrolle und Audit. Key Rotation ist einer seiner Teilprozesse.
• Key Revocation ist der sofortige Entzug eines Schlüssels ohne Übergangsphase – die Notfallvariante der Rotation.
• Zertifikatserneuerung folgt derselben Logik, ist aber durch feste Ablaufdaten getrieben und heute meist automatisiert (etwa über ACME-Protokolle).