Secrets Management

Secrets Management im Überblick

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")

Technisch betrachtet

Tools

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:

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

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.