Sichere Verwaltung von Secrets und Umgebungsvariablen

Fest im Code hinterlegte Secrets – direkt im Quellcode eingebettete API-Schlüssel, Datenbankpasswörter, private TLS-Schlüssel und OAuth-Tokens – gehören zu den häufigsten und vermeidbarsten Sicherheitslücken. Secrets im Quellcode sind im Verlauf der Versionsverwaltung sichtbar (selbst nach ihrer Löschung), für alle Entwickler mit Zugriff auf das Repository einsehbar und werden häufig offengelegt, wenn Repositories versehentlich öffentlich gemacht werden. Tools wie GitGuardian und truffleHog durchsuchen Plattformen wie GitHub kontinuierlich nach offengelegten Secrets.

Umgebungsvariablen entfernen Secrets aus dem Quellcode, indem sie zur Laufzeit über das Host-Betriebssystem oder den Container-Orchestrator injiziert werden. Die Anwendung liest os.environ['DB_PASSWORD'] statt eines fest im Code hinterlegten Werts. Das ist besser als die direkte Hinterlegung im Quellcode, doch Umgebungsvariablen haben Schwächen: Sie erscheinen in Prozesslisten, werden an Kindprozesse vererbt, landen häufig in Crash-Dumps und Debugging-Protokollen und erfordern eine manuelle Rotation. Für die Entwicklung sind sie geeignet, für das Secrets-Management in der Produktion allein jedoch nicht ausreichend.

Secrets Manager sind speziell entwickelte Systeme zum Speichern, Rotieren und Auditieren des Zugriffs auf Secrets. Zu den führenden Lösungen gehören HashiCorp Vault (Open Source und Enterprise), AWS Secrets Manager, Azure Key Vault und Google Cloud Secret Manager. Anwendungen authentifizieren sich zur Laufzeit beim Secrets Manager, rufen das Secret ab und verwenden es – Secrets werden niemals auf der Festplatte oder in Umgebungsvariablen gespeichert. Jeder Zugriff wird protokolliert, sodass nachvollzogen werden kann, wer wann auf welches Secret zugegriffen hat.

Ein wesentlicher Vorteil von Secrets Managern gegenüber Umgebungsvariablen ist die automatische Rotation. AWS Secrets Manager kann die Passwörter von RDS-Datenbanken planmäßig automatisch rotieren (z. B. alle 30 Tage), ohne dass die Anwendung erneut bereitgestellt werden muss. Der Secrets Manager aktualisiert das Passwort in der Datenbank und gleichzeitig das gespeicherte Secret. Anwendungen, die Secrets bei jeder Verbindung abrufen, erhalten automatisch das neue Zugangselement. Dadurch entfällt die verbreitete Praxis, „dauerhafte“ Passwörter für Servicekonten zu verwenden, die niemals rotiert werden.

Die erste Verteidigungslinie gegen committete Secrets ist eine ordnungsgemäß gepflegte .gitignore-Datei, die alle Dateien ausschließt, die Secrets enthalten könnten. .gitignore verhindert jedoch nur zukünftige Commits – bereits committete Secrets bleiben in der Git-Historie erhalten. Wenn Secrets versehentlich committet wurden, müssen sie sofort als kompromittiert behandelt werden: Rotieren Sie das Secret und verwenden Sie anschließend optional Tools wie git filter-repo, um die Historie umzuschreiben (für die Compliance erforderlich, allein jedoch nicht ausreichend, da das Secret möglicherweise bereits extrahiert wurde).

Infrastructure-as-Code-Dateien (IaC-Dateien) (Terraform, CloudFormation, Kubernetes-Manifeste) enthalten häufig Secrets – Datenbankverbindungszeichenfolgen, API-Schlüssel in Deklarationen von Umgebungsvariablen und TLS-Zertifikate. Diese Dateien werden oft in die Versionsverwaltung übernommen, wodurch das Risiko einer Offenlegung von Secrets entsteht. Zu den Lösungen gehören dynamische Vault-Secrets (Vault generiert speziell für jeden Terraform-Lauf ein kurzlebiges Zugangstoken), Kubernetes Secrets (in etcd gespeichert und bei der Speicherung zwingend zu verschlüsseln) sowie der external-secrets-operator, der Secrets zur Laufzeit aus einem Secrets Manager nach Kubernetes synchronisiert.

Jede Anwendung bzw. jeder Dienst sollte nur auf die Secrets zugreifen, die er konkret benötigt – das Prinzip der geringsten Berechtigungen, angewendet auf Secrets. Eine Webanwendung benötigt das Datenbankpasswort, aber nicht den privaten CA-Schlüssel. Ein Reporting-Job benötigt schreibgeschützte Datenbankzugangsdaten und keinen Schreibzugriff. Secrets Manager setzen dies mithilfe von Zugriffsrichtlinien durch, die festlegen, welche Identitäten (IAM-Rollen, Servicekonten, AppRoles) welche Secrets lesen dürfen; sämtliche Zugriffe werden zu Prüfzwecken protokolliert.

Dynamische Secrets werden bei Bedarf für einen bestimmten Anforderer generiert und laufen automatisch ab. Vault kann ein temporäres Datenbankzugangstoken generieren, das 1 Stunde lang gültig und dem konkreten Dienst zugeordnet ist, der es angefordert hat. Nach Ablauf wird das Zugangstoken von der Datenbank automatisch widerrufen. Dadurch gibt es keine langlebigen statischen Zugangsdaten, die gestohlen werden könnten – selbst wenn ein Angreifer ein dynamisches Zugangstoken abfängt, läuft es schnell ab und ist in den Audit-Logs an die anfordernde Identität gebunden.

CI/CD-Pipelines benötigen häufig Secrets – Anmeldedaten von Cloud-Anbietern für Deployments, Docker-Registry-Token und Signaturschlüssel. Speichern Sie Secrets niemals in Pipeline-Skripten oder Konfigurationsdateien. Verwenden Sie stattdessen den integrierten Secret Store der Pipeline-Plattform (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store) oder rufen Sie Secrets zur Laufzeit mithilfe einer Maschinenidentität aus einem zentralen Vault ab. Markieren Sie Secret-Variablen in Logs als maskiert, um eine versehentliche Offenlegung in der Build-Ausgabe zu verhindern.

Secrets Manager stellen umfassende Audit-Logs für jedes Zugriffsereignis auf ein Secret bereit: welche Identität auf welches Secret zugegriffen hat, von welcher IP-Adresse, zu welchem Zeitpunkt und ob der Zugriff erfolgreich war oder verweigert wurde. Diese Logs sind für Compliance (SOC 2, PCI-DSS) und die Reaktion auf Sicherheitsvorfälle von entscheidender Bedeutung. Wenn der Verdacht besteht, dass ein Zugangstoken kompromittiert wurde, zeigen die Audit-Logs, welche Systeme wann darauf zugegriffen haben – dadurch lassen sich potenziell betroffene Systeme schnell identifizieren und Maßnahmen zur Eindämmung festlegen.

Pre-Commit-Hooks sind Skripte, die automatisch ausgeführt werden, bevor ein Git-Commit endgültig erstellt wird. Dadurch können Secrets erkannt werden, bevor sie in die Versionsverwaltung gelangen. Tools wie detect-secrets (Yelp), GitLeaks und git-secrets (AWS) lassen sich als Pre-Commit-Hooks integrieren und durchsuchen bereitgestellte Dateien nach Mustern, die API-Schlüsseln, Verbindungszeichenfolgen, privaten Schlüsseln und JWT-Token entsprechen. Wird ein Secret erkannt, wird der Commit abgelehnt und die Entwicklerin bzw. der Entwickler aufgefordert, die Zugangsdaten zu entfernen. Das pre-commit-Framework erleichtert das Hinzufügen und Teilen von Hook-Konfigurationen in Teams.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Hartcodierte Secrets im Quellcode müssen entfernt und durch Secrets Manager wie Vault oder AWS Secrets Manager ersetzt werden, die automatische Rotation entfernt langlebige Zugangsdaten, die Angreifer selbst nach einer anfänglichen Kompromittierung missbrauchen könnten, und dynamische Secrets sowie Zugriffsrichtlinien nach dem Prinzip der geringsten Berechtigungen verringern den Wert jedes einzelnen offengelegten Secrets. Als Nächstes beschäftigen wir uns mit der Sicherheit von Abhängigkeiten und der Software Composition Analysis.