Das Problem der Secrets-Verteilung

Secrets Sprawl bezeichnet die unkontrollierte Verbreitung sensibler Zugangsdaten in einer Organisation. Ein Secret ist alles, was Zugriff gewährt: API-Schlüssel, Datenbankpasswörter, OAuth-Tokens, private TLS-Schlüssel, SSH-Schlüssel und Verschlüsselungsschlüssel.

Sprawl entsteht, wenn diese Secrets an Orten verstreut werden, an denen sie niemals liegen sollten:

• Quellcode und Konfigurationsdateien
• CI/CD-Pipelines und Umgebungsvariablen
• Container-Images und Infrastructure-as-Code
• Chatnachrichten, Wikis und Ticketsysteme

Sobald ein Secret an vielen Orten vorhanden ist, verlieren Sie die Möglichkeit, es zuverlässig nachzuverfolgen, zu rotieren oder zu widerrufen.

Die häufigste Ursache ist ein hardcodiertes Secret, also eine Zugangsinformation, die direkt in den Quellcode geschrieben wurde. Während der Entwicklung wirkt das praktisch, wird aber zu einem dauerhaften Sicherheitsrisiko.

So sieht ein hardcodiertes Datenbankpasswort im Anwendungscode aus:

Jede Person mit Lesezugriff auf diese Datei hat nun das Produktionspasswort. Dazu gehören alle Entwickler, jeder CI-Runner und alle, die das Repository später klonen.

Eine kritische Gefahr hardcodierter Secrets ist die Versionskontrollhistorie. Selbst wenn Sie ein Secret in einem späteren Commit löschen, bleibt es dauerhaft in der Git-Historie jedes Klons erhalten.

Sie können ein geleaktes Secret jederzeit aus der Historie wiederherstellen:

Deshalb behebt das Löschen eines Secrets aus dem neuesten Commit das Leck nicht. Das Secret muss als kompromittiert betrachtet und sofort rotiert werden.

Wenn ein Repository mit hardcodierten Secrets auf einen öffentlichen Host wie GitHub hochgeladen wird, durchsuchen automatisierte Bots es innerhalb von Sekunden bis wenigen Minuten.

Zu den Folgen in der Praxis gehören:

• Explodierende Cloud-Rechnungen Geleakte AWS-Schlüssel wurden verwendet, um Krypto-Mining-Flotten zu starten, wodurch über Nacht Kosten von mehreren zehntausend Dollar entstanden.
• Datenlecks Offenlegte Datenbankzugangsdaten führten zur vollständigen Exfiltration der Daten.
• Laterale Bewegung Ein einziges geleaktes Token wurde genutzt, um tiefer in die Infrastruktur vorzudringen.

Cloud-Anbieter und GitHub führen inzwischen Secret Scanning durch, das geleakte Schlüssel automatisch erkennt und manchmal automatisch widerruft. Darauf dürfen Sie sich jedoch nicht als Sicherheitsnetz verlassen.

Container schaffen einen weniger offensichtlichen Verbreitungsweg. Secrets, die während des Builds fest in ein Image eingebaut werden, werden in Image-Layern gespeichert und an jede Registry und jeden Host ausgeliefert, die bzw. der das Image abruft.

Ein häufiger Fehler besteht darin, eine Secret-Datei zu kopieren und sie in einem späteren Layer zu löschen. Das Secret existiert trotzdem noch im früheren Layer:

Jede Person, die das Image abruft, kann diesen Layer extrahieren und den Schlüssel auslesen. Verwenden Sie stattdessen Build-Secrets oder eine Injektion zur Laufzeit.

Secrets aus dem Code in Umgebungsvariablen zu verschieben, ist zwar ein Fortschritt, aber keine vollständige Lösung. Umgebungsvariablen verhindern das Hardcodieren, schaffen jedoch neue Wege für eine Offenlegung:

• Sie können in Crash-Dumps und Fehler-Stacktraces auftauchen.
• Andere Prozesse können sie unter Linux über /proc/<pid>/environ sehen.
• Debugging-Tools können sie protokollieren, wenn sie die vollständige Umgebung ausgeben.
• Sie können in Klartext-.env-Dateien gespeichert werden, die versehentlich committed werden.

Umgebungsvariablen sind für wenig sensible Konfigurationen akzeptabel. Besonders schützenswerte Secrets gehören jedoch in einen dedizierten Secret-Manager mit Zugriffskontrolle und Auditierung.

Secret-Sprawl macht die Incident Response nahezu unmöglich. Wenn ein Secret überall vorhanden ist, lassen sich zwei Fragen nicht beantworten:

• Wo befindet es sich? Was Sie nicht finden, können Sie nicht rotieren.
• Wer hat es verwendet? Ohne zentralisierte Zugriffsprotokolle können Sie den Umfang eines Sicherheitsvorfalls nicht bestimmen.

Der Blast Radius eines einzelnen geleakten Zugangsdaten wächst mit dem Secret-Sprawl. Ein über zehn Dienste hinweg wiederverwendetes Passwort bedeutet, dass ein einziges Leck alle zehn Dienste kompromittiert. Zentralisierung und eindeutige, kurzlebige Secrets verkleinern diesen Radius erheblich.

Am günstigsten lässt sich ein Leck vor dem Eingang in die Versionskontrolle verhindern. Pre-Commit-Secret-Scanner prüfen vorgemerkte Änderungen und blockieren Commits, die Muster von Zugangsdaten enthalten.

Zu den beliebten Open-Source-Tools gehören gitleaks, trufflehog und detect-secrets. Ein typischer Pre-Commit-Hook läuft lokal:

Kombinieren Sie dies mit serverseitigem Scanning in der CI, damit auch ein Entwickler erkannt wird, der den lokalen Hook umgeht.

Wenn ein Secret an einen Ort gelangt, an den es nicht gehört, gehen Sie in dieser Reihenfolge vor. Die Rotation kommt zuerst; das Bereinigen der Historie ist zweitrangig, weil möglicherweise bereits Kopien existieren.

• 1. Rotieren Widerrufen Sie das geleakte Secret und stellen Sie sofort ein neues aus.
• 2. Prüfen Überprüfen Sie die Zugriffsprotokolle auf unbefugte Verwendung während des Zeitraums der Offenlegung.
• 3. Bereinigen Entfernen Sie das Secret aus der Historie, zum Beispiel mit git filter-repo, und führen Sie einen Force-Push durch.
• 4. Verhindern Fügen Sie Scanning hinzu und verschieben Sie das Secret in einen Secret-Manager, damit sich der Vorfall nicht wiederholt.

Überspringen Sie niemals Schritt 1. Ein Secret, das eine öffentlich zugängliche Stelle erreicht hat, ist kompromittiert, ohne Ausnahme.

Secret-Sprawl wird verschärft, wenn Secrets zu weitreichende Berechtigungen haben und zu breit geteilt werden. Die Anwendung des Prinzips der geringsten Rechte begrenzt den Schaden, falls es zu einem Leck kommt:

• Geben Sie jedem Dienst ein eigenes Zugangstoken, niemals ein gemeinsam genutztes.
• Beschränken Sie jedes Secret auf die minimal erforderlichen Berechtigungen, zum Beispiel schreibgeschützt statt administrativ.
• Bevorzugen Sie kurzlebige Zugangsdaten, die automatisch ablaufen.
• Trennen Sie Secrets nach Umgebung: Entwicklungsschlüssel dürfen niemals Zugriff auf die Produktion gewähren.

Diese Gewohnheiten machen aus einem katastrophalen Sicherheitsvorfall einen begrenzten und behebbaren Vorfall.

Tools allein lösen das Problem nicht – die Kultur tut es. Eine reife Organisation versteht Secret-Management als kontinuierliche Aufgabe:

• Grundhaltung: Niemals ein Secret im Quellcode.
• Zentralisieren Sie die Speicherung in einem verwalteten Vault mit Zugriffskontrolle und Auditprotokollen.
• Automatisieren Sie das Scanning in jeder Phase: vor dem Commit, in der CI und in der Registry.
• Machen Sie Rotation zu einer Routine und nicht zu einer Maßnahme, die nur im Notfall erfolgt.
• Schulen Sie alle Entwickler darin, Offenlegungen zu erkennen und ohne Schuldzuweisungen zu melden.

Das Ziel ist ein System, in dem es schwierig ist, ein Secret offenzulegen, und einfach, sich davon zu erholen.

Testen Sie Ihr Verständnis dafür, warum das Löschen eines geleakten Secrets nicht ausreicht.

Sie haben gelernt, warum verstreute, hardcodierte Secrets zu den häufigsten und folgenschwersten Sicherheitslücken gehören.

• Secret-Sprawl ist die unkontrollierte Verbreitung von Zugangsdaten über Code, Pipelines, Images und Chats hinweg.
• Hardcodierte Secrets bleiben dauerhaft in der Git-Historie erhalten; ihr Löschen behebt ein Leck nicht.
• Öffentliche Repositorys werden innerhalb weniger Minuten durchsucht, was zu explodierenden Cloud-Rechnungen und Sicherheitsverletzungen führen kann.
• Umgebungsvariablen und Image-Layer sind undichte Ablageorte und keine sichere Speicherung.
• Secret-Sprawl vergrößert den Blast Radius und macht Rotation sowie Incident Response unmöglich.
• Die Lösung: vor dem Commit scannen, bei einem Leck zuerst rotieren, Secrets zentral in einem Vault speichern und das Prinzip der geringsten Rechte anwenden.

Als Nächstes zentralisieren wir Secrets mit Vaults und Secret Stores auf die richtige Weise.