Secrets Management: Passwörter, API-Keys und Zertifikate sicher verwalten

Was Secrets sind und warum sie besonders geschützt werden müssen

Secrets sind vertrauliche Informationen, die den Zugang zu Systemen, Diensten und Daten ermöglichen. Dazu gehören Datenbankpasswörter und Connection Strings, API-Keys für externe Dienste (Zahlungsanbieter, Cloud-APIs, E-Mail-Provider), SSH-Schlüssel für Serverzugriff, TLS/SSL-Zertifikate und ihre privaten Schlüssel, Encryption Keys für Datenverschlüsselung, Service-Account-Credentials für automatisierte Prozesse, OAuth-Client-Secrets und Token-Signing-Keys sowie Backup-Verschlüsselungspasswörter.

Secrets sind besonders schützenswert, weil sie direkten Zugang zu deiner Infrastruktur ermöglichen. Ein kompromittiertes Datenbankpasswort gibt dem Angreifer vollen Zugriff auf alle Daten. Ein kompromittierter API-Key ermöglicht Aktionen im Namen deines Unternehmens. Das Thema berührt direkt dein Berechtigungskonzept. Ein kompromittierter SSH-Schlüssel öffnet die Tür zu deinen Servern.

Anders als ein Phishing-Angriff, der einen einzelnen Benutzeraccount kompromittiert, betrifft ein kompromittiertes Service-Secret oft die gesamte Anwendung oder Infrastruktur. Ein einziger exponierter Datenbank-Connection-String kann den Zugang zu allen Kundendaten ermöglichen.

Wo Secrets typischerweise falsch aufbewahrt werden

Die meisten Secrets-Kompromittierungen passieren nicht durch ausgefeilte Angriffe, sondern durch grundlegende Fehler bei der Aufbewahrung.

Im Quellcode

Der klassische Fehler: Ein Entwickler schreibt den API-Key direkt in den Code. const API_KEY = "sk_live_abc123...". Selbst wenn der Key später entfernt wird, bleibt er in der Git-History. Wer Zugriff auf das Repository hat (und das können viele Personen sein, besonders bei Open-Source-Projekten), kann den Key aus der History extrahieren.

GitHub scannt seit 2022 öffentliche Repositories automatisch auf exponierte Secrets (GitHub Secret Scanning) und benachrichtigt den Token-Aussteller. Aber bei privaten Repositories, selbst gehosteten Git-Servern oder anderen Plattformen fehlt dieser Schutz häufig.

In Umgebungsvariablen

Umgebungsvariablen sind besser als Secrets im Code, aber nicht ideal. Umgebungsvariablen erscheinen in /proc/[pid]/environ auf Linux-Systemen und können von jedem Prozess desselben Benutzers gelesen werden. Sie tauchen in Prozesslisten auf. Sie werden in Crash-Dumps und Debug-Logs mitgeschrieben. Docker inspiziert sie per docker inspect. Kubernetes Pods zeigen sie per kubectl describe pod.

Umgebungsvariablen sind ein akzeptabler Zwischenschritt auf dem Weg zu einem echten Secrets-Management-System, aber keine Dauerlösung für sensible Produktionsgeheimnisse.

In Konfigurationsdateien

Unverschlüsselte Konfigurationsdateien (config.yaml, .env, application.properties) mit Datenbankpasswörtern und API-Keys sind ein verbreitetes Muster. Das Problem: Diese Dateien werden oft versehentlich in Git committet (trotz .gitignore, das gerne mal vergessen wird), auf Servern mit zu weitreichenden Dateiberechtigungen abgelegt oder in Backup-Archiven mitgesichert, wo sie weniger geschützt sind.

In Deployment-Tools

CI/CD-Pipelines brauchen Zugang zu Secrets, um Anwendungen zu deployen. Jenkins-Credentials, GitLab-CI-Variablen, GitHub-Actions-Secrets speichern diese Informationen. Wenn die Pipeline-Konfiguration nicht sorgfältig geschützt ist, können Entwickler Secrets über manipulierte Pipeline-Schritte exfiltrieren (z.B. echo $SECRET in einem Build-Log).

Prinzipien des Secrets Managements

Zentralisierung

Statt Secrets an verschiedenen Orten zu verstreuen (hier eine .env-Datei, dort eine Jenkins-Credential, da ein verschlüsseltes Ansible-Vault-File), sammelst du alle Secrets an einem zentralen Ort. Dieser zentrale Ort ist deine Single Source of Truth für Secrets. Anwendungen und Systeme beziehen ihre Secrets ausschließlich von dort.

Verschlüsselung

Secrets werden immer verschlüsselt gespeichert, sowohl at Rest (auf der Festplatte) als auch in Transit (bei der Übertragung). Selbst wenn ein Angreifer Zugriff auf den Speicher des Secrets-Management-Systems erhält, kann er die Secrets nicht lesen.

Zugriffskontrolle

Nicht jede Anwendung und nicht jeder Entwickler braucht Zugriff auf alle Secrets. Das Prinzip der minimalen Berechtigung gilt auch hier: Die Produktionsanwendung hat Zugriff auf die Produktions-Datenbankpasswörter, aber nicht auf die Entwicklungs-Secrets. Der Entwickler hat Zugriff auf die Entwicklungs-Secrets, aber nicht auf die Produktions-Secrets. Die CI/CD-Pipeline hat Zugriff auf die Deploy-Credentials, aber nicht auf die Backup-Verschlüsselungspasswörter.

Auditierung

Jeder Zugriff auf ein Secret wird protokolliert: Wer hat wann welches Secret gelesen? Das ermöglicht die Nachvollziehbarkeit und die Erkennung verdächtiger Zugriffsmuster (z.B. ein Entwickler-Account, der nachts um 3 Uhr Produktions-Secrets liest).

Rotation

Secrets haben eine begrenzte Lebensdauer. Sie werden regelmäßig rotiert (durch neue ersetzt), um den Zeitraum zu begrenzen, in dem ein kompromittiertes Secret nutzbar ist. Idealerweise ist die Rotation automatisiert und erfordert keinen manuellen Eingriff.

Tools im Vergleich

HashiCorp Vault

Vault ist der De-facto-Standard für Secrets Management in mittleren und großen Umgebungen. Es ist ein zentraler Dienst, der Secrets speichert, den Zugriff kontrolliert und die Nutzung protokolliert.

Funktionsumfang: Verschlüsselte Speicherung von Key-Value-Secrets, dynamische Secrets (Vault generiert kurzlebige Datenbankzugänge auf Anfrage und widerruft sie automatisch), Encryption as a Service (Anwendungen können Daten über die Vault-API verschlüsseln und entschlüsseln, ohne den Schlüssel zu kennen), PKI (Vault kann TLS-Zertifikate ausstellen und automatisch rotieren), Transit-Engine (verschlüsselt Daten, ohne sie zu speichern) und Identity-basierte Zugriffskontrolle.

Dynamische Secrets sind eine besonders kraftvolle Funktion. Statt ein statisches Datenbankpasswort in Vault zu speichern, konfigurierst du Vault so, dass es bei jeder Anfrage einen neuen, kurzlebigen Datenbankbenutzer erstellt. Dieser Benutzer hat eine Lebensdauer von z.B. 1 Stunde. Nach Ablauf wird er automatisch gelöscht. Wenn ein Secret kompromittiert wird, ist es nur für kurze Zeit gültig.

Deployment-Optionen: Self-hosted (Open Source, kostenlos), HCP Vault (managed Cloud-Service von HashiCorp, kostenpflichtig). Self-hosted erfordert einen Betriebsaufwand (Hochverfügbarkeit, Backup, Updates), bietet aber volle Kontrolle.

Geeignet für: Unternehmen mit mehreren Anwendungen und Umgebungen, die eine zentrale, leistungsfähige Secrets-Management-Lösung brauchen. Umgebungen mit Kubernetes, wo Vault über den Vault Agent Injector oder Vault CSI Provider integriert wird.

AWS Secrets Manager

AWS Secrets Manager ist ein verwalteter Dienst von AWS für die Speicherung und Rotation von Secrets.

Funktionsumfang: Verschlüsselte Speicherung von Secrets (AES-256 über AWS KMS), automatische Rotation von Secrets (mit Lambda-Funktionen), native Integration mit AWS-Diensten (RDS, Redshift, DocumentDB), Versionierung von Secrets und feingranulare Zugriffskontrolle über IAM-Policies.

Kosten: 0,40 USD pro Secret pro Monat + 0,05 USD pro 10.000 API-Aufrufe. Für 50 Secrets: ca. 20 USD pro Monat.

Geeignet für: Unternehmen, die primär auf AWS setzen und eine verwaltete Lösung ohne Betriebsaufwand bevorzugen.

Azure Key Vault

Azure Key Vault ist das Azure-Pendant zu AWS Secrets Manager.

Funktionsumfang: Speicherung von Secrets, Schlüsseln und Zertifikaten, HSM-gestützte Schlüsselspeicherung (Hardware Security Module), Integration mit Azure-Diensten (App Service, Functions, AKS), Zugriffsprotokollierung über Azure Monitor.

Geeignet für: Unternehmen, die primär auf Azure und Microsoft 365 setzen.

SOPS (Secrets OPerationS)

SOPS ist ein Open-Source-Tool von Mozilla, das Dateien (YAML, JSON, ENV, INI) selektiv verschlüsselt. Es verschlüsselt nur die Werte in einer Datei, nicht die Schlüsselnamen. Dadurch bleiben die Dateien in Git versionierbar und diff-bar.

Funktionsumfang: Selektive Verschlüsselung von Dateiwerten, Unterstützung für verschiedene Verschlüsselungs-Backends (AWS KMS, GCP KMS, Azure Key Vault, age, PGP), Git-freundlich (verschlüsselte Dateien können normal committet und gemergt werden), kein zentraler Dienst nötig.

Workflow: Du erstellst eine Konfigurationsdatei mit Secrets, verschlüsselst sie mit sops --encrypt, committst die verschlüsselte Datei in Git. Im Deployment entschlüsselt die CI/CD-Pipeline die Datei mit sops --decrypt und stellt die Secrets der Anwendung bereit.

Geeignet für: Kleinere Teams und Projekte, die keine zentrale Vault-Infrastruktur betreiben möchten, aber Secrets trotzdem sicher in Git versionieren wollen.

Doppler

Doppler ist ein cloudbasierter Secrets-Management-Dienst, der auf Entwicklerfreundlichkeit ausgelegt ist.

Funktionsumfang: Web-Dashboard und CLI für Secrets-Verwaltung, Umgebungstrennung (Development, Staging, Production), Integrationen mit CI/CD-Systemen, Cloud-Providern und Frameworks, Secrets-Injection in Anwendungen (über CLI-Wrapper oder SDKs), Audit-Logging und Versionierung.

Kosten: Kostenlos für bis zu 5 Benutzer und unbegrenzte Secrets. Team-Plan ab 4 USD pro Benutzer pro Monat.

Geeignet für: Kleine bis mittlere Teams, die eine unkomplizierte, cloud-native Lösung suchen.

Secrets Management in der CI/CD-Pipeline

Im Rahmen des Secure Development Lifecycle ist die CI/CD-Pipeline ein besonders sensibler Bereich, weil sie Zugang zu Secrets braucht (Deploy-Credentials, Container-Registry-Zugang, Datenbank-Migrations-Passwörter), Pipeline-Logs häufig für viele Entwickler sichtbar sind und Pipeline-Konfigurationen oft weniger streng gereviewed werden als Anwendungscode.

Best Practices für Pipeline-Secrets

Niemals Secrets in Pipeline-Logs ausgeben. Die meisten CI/CD-Systeme maskieren bekannte Secrets in Logs, aber die Maskierung ist nicht immer zuverlässig. Prüfe deine Logs regelmäßig auf exponierte Secrets.

Kurzlebige Credentials verwenden. Statt statische Deploy-Credentials in der Pipeline zu hinterlegen, verwende OIDC-basierte Authentifizierung (GitHub Actions kann sich direkt bei AWS, Azure oder GCP authentifizieren, ohne statische Credentials) oder kurzlebige Tokens, die Vault bei Bedarf ausstellt.

Secrets nur den Schritten bereitstellen, die sie brauchen. In GitHub Actions kannst du Secrets pro Job oder Step begrenzen. Nicht jeder Step braucht den Datenbank-Admin-Zugang.

Pipeline-Konfigurationen als Code reviewen. Änderungen an der Pipeline-Konfiguration (.github/workflows, .gitlab-ci.yml, Jenkinsfile) sollten denselben Review-Prozess durchlaufen wie Anwendungscode.

Secrets-Rotation: Warum und wie

Statische Secrets, die nie rotiert werden, sind ein Dauerproblem. Wenn ein API-Key kompromittiert wird und du ihn nie rotierst, hat der Angreifer unbegrenzten Zugang. Wenn du den Key alle 90 Tage rotierst, hat er maximal 90 Tage Zugang (vorausgesetzt, du erkennst die Kompromittierung rechtzeitig und die Rotation erfolgt planmäßig).

Automatische Rotation

Die effektivste Rotation ist die automatische. AWS Secrets Manager kann RDS-Datenbankpasswörter automatisch rotieren: Ein Lambda-Function generiert ein neues Passwort, aktualisiert es in der Datenbank und im Secrets Manager. HashiCorp Vault kann kurzlebige Datenbankbenutzer dynamisch erstellen und nach Ablauf widerrufen. Let's Encrypt erneuert TLS-Zertifikate automatisch alle 90 Tage.

Automatische Rotation eliminiert den manuellen Aufwand und das Risiko, dass die Rotation vergessen wird. Sie erfordert aber, dass alle Anwendungen, die das Secret nutzen, die Änderung automatisch übernehmen. Anwendungen, die den Datenbankpasswort beim Start aus einer Konfigurationsdatei lesen und nie wieder aktualisieren, funktionieren mit automatischer Rotation nicht.

Rotationsintervalle

Für verschiedene Secret-Typen gelten unterschiedliche Empfehlungen.

Datenbankpasswörter: 90 Tage, besser 30 Tage, am besten dynamische Secrets mit Stunden- oder Minuten-Lebensdauer.

API-Keys: 90 bis 180 Tage. Sofortige Rotation bei Verdacht auf Kompromittierung.

SSH-Schlüssel: 180 bis 365 Tage. Verwende SSH-Zertifikate mit kurzer Laufzeit statt langlebiger Schlüssel.

TLS-Zertifikate: Let's Encrypt erneuert alle 60 Tage (bei 90 Tagen Gültigkeit). Für interne Zertifikate: 90 bis 365 Tage.

Encryption Keys: 365 Tage oder länger, mit Key-Versioning (alte Daten bleiben mit dem alten Key entschlüsselbar, neue Daten werden mit dem neuen Key verschlüsselt).

Secrets in Notfallsituationen

Secrets Management muss auch im Notfall funktionieren. Wenn dein Vault-Server ausfällt oder der Cloud-Secrets-Manager nicht erreichbar ist, müssen Anwendungen trotzdem starten können.

Break-Glass-Verfahren

Halte für kritische Secrets ein Notfallverfahren bereit. Verschlüsselte Kopien der kritischsten Secrets (Datenbank-Admin-Passwort, Cloud-Admin-Credentials) in einem physischen Tresor. Ein versiegelter Umschlag mit dem Vault-Unseal-Key oder dem Master-Key für den Secrets-Manager. Dokumentation des Break-Glass-Verfahrens: Wer darf den Umschlag öffnen, unter welchen Umständen, und welche Benachrichtigungen müssen erfolgen.

Hochverfügbarkeit

Wenn Secrets Management kritisch für den Betrieb ist (und das ist es meistens), muss das System selbst hochverfügbar sein. Vault unterstützt HA-Deployment mit verschiedenen Backends (Consul, Raft). AWS Secrets Manager und Azure Key Vault sind als verwaltete Dienste inhärent hochverfügbar.

Secrets Management und Compliance

ISO 27001

Annex A, Kontrolle A.5.17 (Authentication information), fordert, dass Authentifizierungsinformationen kontrolliert zugewiesen, verwaltet und geschützt werden. Ein Secrets-Management-System mit Zugriffskontrolle, Verschlüsselung und Audit-Logging erfüllt diese Anforderung.

NIS2

NIS2 Artikel 21 fordert allgemein angemessene Sicherheitsmaßnahmen. Die sichere Verwaltung von Zugangsinformationen fällt unter die Anforderungen an Zugangskontrolle und Kryptografie.

DSGVO

Wenn Secrets den Zugang zu personenbezogenen Daten ermöglichen (Datenbankpasswörter, API-Keys für Dienste, die personenbezogene Daten verarbeiten), sind sie Teil der technischen und organisatorischen Maßnahmen (TOMs) nach Artikel 32 DSGVO. Die sichere Verwaltung dieser Secrets ist eine Pflicht.

Pragmatisch starten

Wenn du heute noch kein Secrets Management hast, fang nicht mit einer Vault-Enterprise-Installation an. Starte pragmatisch.

Schritt 1: Inventar erstellen. Finde heraus, wo überall Secrets liegen. Durchsuche Git-Repositories nach hartcodierten Secrets (Tools: TruffleHog, git-secrets, gitleaks). Prüfe .env-Dateien, Konfigurationsdateien und CI/CD-Variablen.

Schritt 2: Die schlimmsten Fälle beheben. Secrets aus Git-Repositories entfernen und rotieren (die alten Secrets sind kompromittiert, auch wenn du den Commit löschst). Hartcodierte Secrets in Konfigurationsdateien oder Umgebungsvariablen verschieben.

Schritt 3: Ein einfaches Tool einführen. Für kleine Teams reicht SOPS oder Doppler. Für AWS-Umgebungen: AWS Secrets Manager. Für größere oder heterogene Umgebungen: HashiCorp Vault. In ISMS Lite dokumentierst du deine Secrets-Management-Richtlinie und die Rotationsintervalle, sodass du für Audits jederzeit nachweisen kannst, wie deine Zugangsdaten verwaltet werden.

Schritt 4: Rotation einführen. Beginne mit den kritischsten Secrets (Datenbank-Admin-Passwörter, Cloud-Admin-Credentials) und erweitere schrittweise.

Schritt 5: Pre-commit-Hooks installieren. Installiere git-secrets oder gitleaks als Pre-commit-Hook in allen Repositories. Das verhindert, dass Secrets versehentlich committet werden.

Häufige Fehler beim Secrets Management

Secrets nach Entfernung aus Git nicht rotieren. Wenn ein Secret einmal in einem Git-Commit gelandet ist, bleibt es in der History, selbst wenn du den Commit überschreibst. Die einzig sichere Maßnahme ist, das Secret als kompromittiert zu betrachten und sofort zu rotieren. Viele Teams entfernen den Commit, rotieren aber nicht, weil sie den Aufwand scheuen.

Einheitliches Passwort für alle Umgebungen. Das Datenbankpasswort in der Entwicklungsumgebung ist identisch mit dem in der Produktion, weil es "einfacher" ist. Wenn ein Entwickler auf seinem Laptop kompromittiert wird, hat der Angreifer direkten Zugang zur Produktionsdatenbank. Verwende immer separate Secrets pro Umgebung.

Keine Überwachung des Secret-Zugriffs. Vault und andere Tools protokollieren jeden Zugriff, aber niemand schaut in die Logs. Ein kompromittierter Service-Account, der plötzlich Secrets abfragt, die er normalerweise nicht benötigt, bleibt unbemerkt. Richte Alerts für ungewöhnliche Zugriffsmuster ein.

Backup-Secrets vergessen. Die Backup-Verschlüsselungspasswörter und die Vault-Unseal-Keys liegen nirgendwo sicher dokumentiert. Wenn der Vault-Server ausfällt und niemand den Unseal-Key kennt, sind alle Secrets verloren. Halte diese Meta-Secrets in einem physischen Tresor, getrennt vom digitalen System.

Zu breite Zugriffsrechte auf den Secrets-Store. Alle Entwickler haben Lesezugriff auf alle Secrets, weil die feingranulare Konfiguration aufwändig erschien. Das widerspricht dem Prinzip der minimalen Berechtigung und vergrößert die Angriffsfläche erheblich. Investiere die Zeit in eine saubere Zugriffsstruktur, es zahlt sich aus.

Weiterführende Artikel

• Secure Development Lifecycle (SDL): Sicherheit in den Entwicklungsprozess einbauen
• API-Sicherheit: Authentifizierung, Rate Limiting und Input Validation
• Container-Sicherheit: Docker und Kubernetes im Mittelstand absichern
• Berechtigungskonzept erstellen: Rollen, Rechte und Rezertifizierung
• Verschlüsselung im Unternehmen: Technologien, Standards und Umsetzung