Warum Ihr Datenbankpasswort niemals in einer Konfigurationsdatei leben sollte

Sie entwickeln eine neue Anwendung. Am Anfang legen Sie alle variablen Daten in eine Datei: Datenbankname, Serveradresse, API-URLs. Die Datei landet in Git, wird ins Repository gepusht und auf dem Server deployed. Alles an einem Ort – das fühlt sich praktisch an. Dann fügen Sie ein Datenbankpasswort in dieselbe Datei ein. Später einen API-Token. Dann einen Verschlüsselungsschlüssel. Plötzlich wird aus dieser einen Konfigurationsdatei ein Sicherheitsrisiko, das Ihr gesamtes System gefährden kann.

In diesem Moment wird klar: Nicht alle Konfigurationsdaten sind gleich. Manche Daten geben anderen, wenn sie offengelegt werden, die Schlüssel zu Ihrem Königreich. Diese Daten nennt man Secrets. Und Secrets wie normale Konfiguration zu behandeln, ist einer der häufigsten und gefährlichsten Fehler, den Teams machen.

Der Unterschied zwischen Konfiguration und Secret

Normale Konfigurationsdaten umfassen Dinge wie Servernamen, Anwendungsports oder Feature-Flags. Wenn jemand außerhalb Ihres Teams weiß, dass Ihre Anwendung auf Port 8080 läuft, ist das keine Katastrophe. Allein die Kenntnis der Portnummer reicht nicht aus, um sich in Ihre Datenbank einzuloggen.

Secrets sind anders. Ein Datenbankpasswort, ein API-Token oder ein Verschlüsselungsschlüssel kann von einem Angreifer genutzt werden, um Ihr System zu imitieren, auf Ihre Daten zuzugreifen oder Ihre Infrastruktur zu zerstören. Die Auswirkungen eines durchgesickerten Secrets sind sofort und schwerwiegend.

Dennoch behandeln viele Teams Secrets immer noch wie normale Konfiguration. Sie legen Passwörter in .env-Dateien ab und committen sie in Git. Sie speichern API-Tokens in Anwendungskonfigurationsdateien und pushen sie ins Repository. Sie behalten SSH-Schlüssel in Projektordnern und sichern alles in der Cloud. Das liegt nicht daran, dass das Team nachlässig ist. Meistens haben sie die Konsequenzen einfach noch nicht erlebt.

Was passiert, wenn ein Secret durchsickert

Im Jahr 2022 gab es mehrere prominente Vorfälle, bei denen AWS-Tokens in öffentlichen Repositories zurückgelassen wurden. Angreifer nutzten diese Tokens, um Cryptocurrency-Mining-Instanzen zu starten. Die Rechnungen beliefen sich innerhalb weniger Stunden auf Zehntausende von Dollar. In anderen Fällen führten durchgesickerte Datenbankpasswörter dazu, dass Kundendaten heruntergeladen und im Dark Web verkauft wurden.

Diese Vorfälle begannen nicht mit einem ausgeklügelten Angriff. Sie begannen mit einem einfachen Fehler: Ein Secret wurde wie eine Konfigurationsdatei behandelt. Das Secret war da, sichtbar für jeden, der Zugriff auf das Repository hatte. Sobald das Repository öffentlich war, war auch das Secret öffentlich.

Die Git-Historie macht das noch schlimmer. Selbst wenn Sie eine Datei löschen, die ein Secret enthielt, bleibt das Secret in der Commit-Historie erhalten. Jeder, der das Repository klont, kann git log ausführen und das Passwort finden, von dem Sie dachten, Sie hätten es entfernt. Es gibt keine einfache Möglichkeit, die Git-Historie vollständig zu bereinigen, besonders wenn das Repository geteilt oder geforkt wurde.

Wie sich Konfiguration und Secrets in der Praxis unterscheiden

Die Unterschiede zwischen Konfiguration und Secrets beeinflussen, wie Sie sie in Ihrer täglichen Arbeit und in Ihrer CI/CD-Pipeline handhaben.

Wer sie sehen kann: Konfiguration kann für alle Entwickler im Team sichtbar sein. Secrets sollten nur für Personen oder Systeme sichtbar sein, die sie unbedingt benötigen. Nicht jeder Entwickler muss das Produktionsdatenbankpasswort kennen.

Wo sie gespeichert werden: Konfiguration kann in Git leben. Secrets dürfen niemals in Git gespeichert werden. Sie gehören in ein dediziertes Secret-Speichersystem, das sie im Ruhezustand und während der Übertragung verschlüsselt.

Wie sie rotiert werden: Konfiguration muss selten rotiert werden. Sie ändern einen Servernamen, wenn Sie Ihre Infrastruktur migrieren, und das war es. Secrets müssen regelmäßig rotiert werden. Sie sollten Datenbankpasswörter alle paar Monate rotieren und sofort rotieren, wenn es Anzeichen für ein Leck gibt.

Wie Pipelines damit umgehen: In einer CI/CD-Pipeline kann Konfiguration direkt aus einer Datei im Repository gelesen werden. Die Pipeline nimmt die Datei und verwendet sie. Secrets erfordern einen anderen Ansatz. Die Pipeline muss sie aus einem sicheren Speichersystem abrufen, in den Build- oder Deploy-Prozess injizieren und sicherstellen, dass sie niemals in Logs, Artefakten oder deployed Dateien auftauchen.

Die praktischen Konsequenzen der Verwechslung

Wenn Sie Secrets wie Konfiguration behandeln, schaffen Sie eine Kette von Problemen, die schwer rückgängig zu machen sind.

Erstens verlieren Sie die Kontrolle darüber, wer Zugriff hat. Wenn das Secret in Git ist, hat jeder mit Repository-Zugriff das Secret. Dazu gehören Auftragnehmer, ehemalige Mitarbeiter, die noch Zugriff haben, und potenziell Angreifer, wenn das Repository öffentlich ist.

Zweitens erschweren Sie die Rotation. Wenn das Secret über mehrere Konfigurationsdateien, Branches und Deployment-Umgebungen verstreut ist, bedeutet Rotieren, jede Kopie zu finden und zu aktualisieren. Sie werden unweigerlich eine übersehen, und dieses alte Passwort bleibt irgendwo gültig.

Drittens zerstören Sie Ihre Audit-Trail. Wenn ein Secret durchsickert, müssen Sie wissen, wer wann Zugriff hatte. Wenn das Secret in Git war, lautet die Antwort „jeder, der jemals Repository-Zugriff hatte“. Das ist kein brauchbarer Audit-Trail.

Eine einfache Methode zur Unterscheidung

Bevor Sie Daten in eine Konfigurationsdatei aufnehmen, stellen Sie sich eine Frage: „Wenn jemand außerhalb meines Teams das sieht, kann er es nutzen, um auf mein System zuzugreifen?“

Wenn die Antwort nein ist, handelt es sich wahrscheinlich um Konfiguration. Servernamen, Portnummern, Feature-Flags und Log-Level sind Konfiguration.

Wenn die Antwort ja ist, handelt es sich um ein Secret. Datenbankpasswörter, API-Tokens, SSH-Schlüssel, Verschlüsselungsschlüssel und Service-Account-Credentials sind Secrets.

Dieser einfache Test verhindert die meisten häufigen Fehler, die Teams machen.

Praktische Checkliste für den Umgang mit Secrets

Wenn Sie Ihr nächstes Projekt einrichten oder Ihr aktuelles überprüfen, gehen Sie diese Checkliste durch:

• Werden alle Secrets außerhalb von Git gespeichert? Verwenden Sie einen dedizierten Secret-Manager oder Vault.
• Werden Secrets zur Laufzeit injiziert und nicht in Images oder Artefakte eingebrannt?
• Beziehen Ihre CI/CD-Pipelines Secrets aus einer sicheren Quelle, nicht aus Repository-Dateien?
• Sind Secrets von Logs, Fehlermeldungen und Debug-Ausgaben ausgeschlossen?
• Haben Sie einen Rotationsplan für jede Art von Secret?
• Gibt es einen Prozess, um Secrets sofort zu rotieren, wenn ein Leck vermutet wird?
• Können Sie den Zugriff auf Secrets für bestimmte Personen oder Systeme entziehen, ohne andere zu beeinträchtigen?

Das Fazit

Wenn ein Datenelement von jemand anderem genutzt werden kann, um Sie oder Ihr System zu imitieren, ist es keine Konfiguration. Es ist ein Secret. Behandeln Sie es anders. Speichern Sie es getrennt. Rotieren Sie es regelmäßig. Und committen Sie es niemals in Git. Die Kosten, diese Lektion auf die harte Tour zu lernen, sind weit höher als der Aufwand, es von Anfang an richtig zu machen.