Geheimnisse gehören nicht in den Code. Dieser Grundsatz klingt selbstverständlich – und doch enden regelmäßig API-Keys, Datenbankpasswörter und Private Keys in öffentlichen Git-Repositories. Die Folgen reichen von ungewolltem Datenzugriff bis zu vollständig kompromittierten Cloud-Konten. Secrets Management ist das strukturierte Gegenmittel: ein systematischer Umgang mit sensiblen Zugangsdaten über den gesamten Lebenszyklus hinweg.
Was sind Secrets?
Als Secrets bezeichnet man alle Informationen, die einem System oder einer Person Zugang zu Ressourcen verschaffen und nicht in falsche Hände geraten dürfen:
- API-Keys für externe Dienste, Monitoring-Tools oder Payment-Provider
- Datenbankpasswörter und Connection Strings
- Private Keys für TLS/SSL, SSH oder Code-Signing
- OAuth-Tokens und Service-Account-Credentials
- Webhook-Secrets und Signing-Keys
- Verschlüsselungsschlüssel
Was all diese gemeinsam haben: Sie müssen verfügbar sein, damit Systeme funktionieren – aber gleichzeitig so geschützt wie möglich. Diese Spannung ist das Kernproblem des Secrets Managements.
Die häufigsten Fehler in der Praxis
Bestimmte Antipattern sind erschreckend verbreitet, selbst in erfahrenen Entwicklungsteams:
- Hardcoded Credentials: API-Keys direkt im Quellcode – sie landen im Repository und in dessen gesamter Git-Historie, die nicht einfach zu bereinigen ist.
- .env-Dateien im Repository: Lokale Umgebungsvariablen werden versehentlich committed. Ein fehlender Eintrag in .gitignore genügt, um monatelange Credentials preiszugeben.
- Secrets in CI/CD-Logs: Wenn Secrets als Kommandozeilenargumente übergeben werden, erscheinen sie im Build-Log – oft sichtbar für alle Projektmitglieder.
- Zu breite Berechtigungen: Ein einziger API-Key für alle Zwecke statt minimal berechtigter, zweckgebundener Keys mit eng definierten Zugriffsrechten.
- Kein Ablaufdatum: Credentials, die ewig gültig sind und nie rotiert werden, bieten Angreifern ein dauerhaftes Einfallstor.
- Weitergabe über Kommunikationskanäle: Sobald ein Secret per Slack, E-Mail oder Ticket geteilt wird, ist die Kontrolle über seinen Verbleib verloren.
Lösungsansätze: Von einfach bis professionell
Je nach Teamgröße und Risikoappetit gibt es unterschiedliche Reifestufen im Umgang mit Secrets:
Ebene 1: Umgebungsvariablen und .env-Konventionen
Der einfachste Schritt: Secrets nie im Code, sondern ausschließlich als Umgebungsvariablen. .env-Dateien gehören in .gitignore, eine .env.example ohne echte Werte ins Repository. Für kleine Teams reicht das als Einstieg – mit dem klaren Risiko, dass Secrets dann unkontrolliert auf Entwicklermaschinen und in Deployment-Umgebungen vorliegen.
Ebene 2: CI/CD-Systeme mit verschlüsselten Secrets
Plattformen wie GitHub Actions, GitLab CI oder Bitbucket Pipelines bieten eingebaute Secret-Stores. Credentials werden verschlüsselt gespeichert, sind in Pipelines über Variablen zugänglich und erscheinen nicht in Logs. Das ist deutlich besser als .env-Dateien im Repository – aber noch kein vollständiges Secrets-Management-System.
Ebene 3: Dedizierte Secrets-Manager
Für Produktionsumgebungen empfehlen sich spezialisierte Werkzeuge:
- HashiCorp Vault: Das meistgenutzte Open-Source-Tool. Unterstützt dynamische Secrets, Lease-Management, Richtlinien und viele Authentifizierungsmethoden. Selbst gehostet oder als Vault Enterprise und HCP Vault verfügbar.
- AWS Secrets Manager, Azure Key Vault, GCP Secret Manager: Cloud-native Lösungen, die direkt in die jeweilige IAM-Infrastruktur eingebunden sind und automatische Rotation unterstützen.
- Doppler: Ein SaaS-Dienst, der Secrets nach Umgebung trennt und sich mit vielen CI/CD-Systemen, Frameworks und Cloud-Plattformen integriert.
- Infisical: Eine quelloffene Alternative zu Doppler mit Self-Hosting-Option, zunehmend beliebt in sicherheitsbewussten Teams.
Dynamische Secrets: Der Goldstandard
Der sicherste Ansatz im Secrets Management sind dynamische Credentials: Statt einem statischen Datenbankpasswort erhält jede Anwendungsinstanz beim Start einen temporären, automatisch ablaufenden Credential. Das System – typischerweise Vault – erstellt ihn, begrenzt seine Gültigkeit auf wenige Stunden und widerruft ihn automatisch nach Ablauf. Selbst wenn ein solcher Credential kompromittiert wird, ist der Schadenszeitraum minimal begrenzt.
Vault unterstützt dynamische Secrets u.a. für PostgreSQL, MySQL, MongoDB, AWS IAM, Kubernetes Service Accounts und SSH – ein erheblicher Sicherheitsgewinn gegenüber statischen, ewig gültigen Zugangsdaten, die im schlimmsten Fall jahrelang unerkannt missbraucht werden können.
Secrets Scanning: Lecks früh erkennen
Präventiv helfen Secrets-Scanner, die Commits und Pull Requests automatisch nach Mustern von API-Keys, Passwörtern und anderen Credentials durchsuchen. Bekannte Tools:
- GitGuardian: Scannt Repositories in Echtzeit und alarmiert bei Fund. Unterstützt über 350 Secret-Typen und erkennt auch selbstdefinierte Muster.
- Trufflehog: Open-Source-Scanner für Repositories, CI-Pipelines und S3-Buckets. Überprüft gefundene Secrets auf Gültigkeit, um Rauschen zu reduzieren.
- GitHub Advanced Security / Secret Scanning: Direkt in GitHub integriert, erkennt automatisch Muster bekannter API-Key-Formate und blockiert Pushes.
Scanning sollte nicht nur präventiv bei neuen Commits eingesetzt werden. Wer ein bestehendes Repository auf Secrets untersucht, findet oft erschreckende Überreste aus Jahren vergangenen Entwicklungsalltags – Credentials, die längst hätten rotiert werden sollen.
Zugriffsrechte und das Prinzip der minimalen Berechtigung
Ein Secrets-Management-System nützt wenig, wenn jeder Dienst auf alle Secrets zugreifen kann. Sinnvoll ist das Prinzip der minimalen Berechtigung: Jede Anwendung, jeder Service und jedes Team erhält nur Zugriff auf die Credentials, die tatsächlich benötigt werden. In Vault lässt sich das über Policies feingranular abbilden. In Cloud-Umgebungen übernimmt IAM diese Rolle.
Regelmäßige Zugriffsreviews – wer hat Zugriff auf welche Secrets, und braucht er diesen noch? – sind ein oft vernachlässigter, aber wichtiger Teil des Prozesses.
Secrets Management im Kontext von KI und LLMs
Mit dem wachsenden Einsatz von KI-Agenten und LLM-basierten Automatisierungen entstehen neue Risiken. KI-Agenten brauchen oft Zugriffsrechte auf externe Dienste – und damit Secrets. Wer API-Keys in Prompts einbettet oder Agenten ohne klare Berechtigungsstruktur betreibt, öffnet neue Angriffsflächen. Secrets für KI-Agenten sollten denselben Regeln folgen wie alle anderen: minimal berechtigt, rotiert, überwacht und niemals im Klartext im Prompt.
Fazit
Secrets Management ist kein einmaliges Projekt, sondern ein laufender Prozess. Credentials müssen regelmäßig rotiert, ungenutzte Keys gesperrt und Zugriffsrechte überprüft werden. Wer heute mit Umgebungsvariablen und einem CI-Secret-Store startet und schrittweise in Richtung dynamischer Credentials und einem dedizierten Secret-Store wächst, ist auf einem guten Weg.
Das Ziel ist nicht Perfektion vom ersten Tag an – sondern systematisch weniger Angriffsfläche mit jedem weiteren Schritt.
Bildquelle: Pexels
Quellen: HashiCorp Vault Documentation, OWASP Secrets Management Cheat Sheet, GitGuardian State of Secrets Sprawl Report 2025
Auditierung und Compliance
Für Unternehmen, die regulierten Umgebungen unterliegen – etwa im Finanz- oder Gesundheitsbereich – ist Secrets Management auch eine Compliance-Anforderung. Auditlogs, die zeigen wer wann auf welchen Secret zugegriffen hat, sind für SOC 2, ISO 27001 oder PCI DSS relevant. Dedizierte Secrets-Manager bieten diese Protokollierung standardmäßig. Teams, die nur mit .env-Dateien arbeiten, haben hier eine strukturelle Lücke, die spätestens beim nächsten Audit sichtbar wird.
Die Einführung eines Secrets-Management-Systems lässt sich gut mit dem Aufbau einer Compliance-Dokumentation verknüpfen: Ein Credential-Inventar – welche Secrets existieren, wer sie verwaltet, wann sie zuletzt rotiert wurden – ist sowohl für Auditoren als auch für den internen Betrieb wertvoll.
