Secrets Management

Einfach erklärt

Secrets Management hält sensible Daten sicher – außerhalb des Codes.

SCHLECHT:
api_key = "sk-1234567890abcdef"  # Im Code!
DATABASE_URL=postgres://user:pass@host  # In .env committed

GUT:
api_key = secrets_manager.get("api-key")
DATABASE_URL = vault.read("database/creds")

Technischer Deep Dive

Tools

Tool	Use Case
HashiCorp Vault	Enterprise, Self-hosted
AWS Secrets Manager	AWS-native
Azure Key Vault	Azure-native
GCP Secret Manager	GCP-native
Doppler	Developer-friendly SaaS

Vault Beispiel

import hvac

client = hvac.Client(url='https://vault.example.com')
client.token = os.environ['VAULT_TOKEN']

# Secret lesen
secret = client.secrets.kv.read_secret_version(path='myapp/database')
db_password = secret['data']['data']['password']

Statische vs. dynamische Secrets

Moderne Secrets Manager unterscheiden zwei Arten von Geheimnissen:

Typ	Eigenschaft	Beispiel
Statisch	Manuell erstellt, gültig bis zur Rotation	API-Key eines externen Dienstes
Dynamisch	On-Demand generiert, kurze Lebensdauer	Temporäre Datenbank-Credentials

Dynamische Secrets sind das sicherere Modell: Der Secrets Manager erzeugt bei jeder Anfrage frische Credentials mit begrenzter Gültigkeit. Wird ein solches Secret geleakt, ist es oft schon abgelaufen, bevor ein Angreifer es nutzen kann. Voraussetzung ist, dass das Zielsystem (z. B. eine Datenbank) programmatische Benutzerverwaltung unterstützt.

Secrets Management in KI- und LLM-Systemen

Gerade KI-Anwendungen sind auf viele externe Credentials angewiesen: API-Keys für LLM-Provider, Zugangsdaten für Vektordatenbanken, Tokens für Embedding-Dienste und Webhooks. Dabei gelten einige Besonderheiten:

• LLM-API-Keys sind direkt geldwert: Ein geleakter Key erlaubt es Angreifern, auf fremde Rechnung Inferenz zu betreiben. Solche Keys tauchen regelmäßig in öffentlichen Repositories auf und werden automatisiert gescannt.
• Prompts können Secrets leaken: Wer Konfigurationsdaten oder Credentials in System-Prompts oder RAG-Kontexte einbettet, riskiert, dass das Modell sie in Antworten ausgibt. Secrets gehören nie in den Kontext eines Modells.
• Agenten brauchen eigene Identitäten: KI-Agenten, die Tools aufrufen, sollten wie Service Accounts behandelt werden – mit eigenen, minimal berechtigten Credentials statt geteilten Admin-Keys.
• Scoped Keys nutzen: Viele LLM-Provider erlauben es, Keys auf bestimmte Projekte, Modelle oder Budgets zu begrenzen. Das reduziert den Schaden bei Kompromittierung erheblich.

Typische Fehler in der Praxis

Fehler	Warum problematisch	Besser
.env versehentlich committed	Secrets landen dauerhaft in der Git-Historie	.env in .gitignore, Pre-Commit-Scanning
Secrets in Logs	Debug-Ausgaben protokollieren Credentials im Klartext	Log-Redaction, strukturiertes Logging
Ein Key für alles	Kein Blast-Radius-Limit, Rotation betrifft alle Systeme	Pro Service und Umgebung eigene Secrets
Secrets in CI-Variablen ohne Maskierung	Build-Logs zeigen Werte an	Maskierte Variablen, OIDC statt Langzeit-Keys
Kein Ablaufdatum	Vergessene Keys bleiben jahrelang gültig	Lebensdauer begrenzen, Inventar pflegen

Wichtig: Ein einmal in Git committetes Secret gilt als kompromittiert – auch nach dem Löschen des Commits bleibt es in der Historie und in Forks auffindbar. Die einzige korrekte Reaktion ist die sofortige Rotation.

Abgrenzung zu verwandten Begriffen

• Konfigurationsmanagement verwaltet unkritische Einstellungen (Feature Flags, URLs) – Secrets Management schützt vertrauliche Werte mit Verschlüsselung, Zugriffskontrolle und Audit.
• Key Rotation ist ein Teilprozess des Secrets Managements: der geplante Austausch von Credentials.
• IAM regelt, wer auf Secrets zugreifen darf – der Secrets Manager setzt diese Regeln technisch durch.