Wo Secrets leben: Von Konfigurationsdateien zum Vault

Sie richten eine neue Anwendung ein. Sie erstellen eine .env-Datei mit Datenbank-Zugangsdaten, API-Keys und Serveradressen. Es funktioniert auf Ihrem Rechner. Sie committen die Datei in Git, damit Ihr Teamkollege die gleiche Umgebung aufsetzen kann. Ein paar Monate später läuft die Anwendung in Produktion, und jemand schiebt versehentlich diese .env-Datei in ein öffentliches Repository. Innerhalb weniger Minuten steht Ihr Produktions-Datenbank-Passwort im Internet.

Dieses Szenario ist nicht selten. Es passiert, weil die einfachste Art, Secrets zu speichern, auch die gefährlichste ist. Der Weg von der Speicherung in Konfigurationsdateien hin zu dedizierten Secret-Management-Tools ist eine Reise, die jedes Team früher oder später macht – oft nachdem es auf die harte Tour gelernt hat.

Das Problem mit Konfigurationsdateien

Wenn Sie zum ersten Mal Anwendungen bauen, fühlt es sich natürlich an, alles in eine Konfigurationsdatei zu packen. Ihre .env, config.json oder application.properties wird zu einer Mischung aus allem. Nicht-sensitive Serveradressen stehen neben extrem sensitiven Datenbank-Passwörtern. Die gesamte Datei landet in Git, und jeder mit Repository-Zugriff kann alles sehen.

Dieser Ansatz funktioniert gut, wenn Sie der einzige Entwickler sind und die Anwendung auf Ihrem Laptop läuft. Sobald Ihr Team wächst oder die Anwendung echte Nutzer erreicht, zeigen sich die Risse. Jeder Entwickler, der das Repository klont, kann Produktions-Passwörter sehen. Selbst wenn das Repository privat ist, bleiben Secrets dauerhaft in der Git-Historie. Das Löschen der Datei aus dem letzten Commit entfernt sie nicht aus älteren Commits. Das Secret ist für immer dort, für jeden zugänglich, der weiß, wie man die Git-Historie durchsucht.

Der nächste Schritt, den die meisten Teams gehen, ist die Trennung von Secrets und regulärer Konfiguration. Die Konfigurationsdatei bleibt in Git, aber sensitive Werte werden durch Platzhalter wie DB_PASSWORD=changeme ersetzt. Die echten Werte leben woanders: in einer nicht eingecheckten Datei, in Umgebungsvariablen auf dem Server oder in einem per Chat geteilten Dokument. Das ist besser als Secrets in Git zu speichern, bringt aber neue Probleme mit sich. Es gibt keine Aufzeichnung darüber, wer auf das Secret zugegriffen hat. Ein Passwort zu rotieren bedeutet, es manuell an mehreren Stellen zu aktualisieren. Wenn die Secret-Datei verloren geht oder beschädigt wird, gibt es kein verwaltetes Backup, um sie wiederherzustellen.

Was ein dedizierter Secret Store ändert

Teams, die mit mehreren Anwendungen und Umgebungen umgehen, suchen irgendwann nach Werkzeugen, die speziell für Secrets entwickelt wurden. Vault, AWS Secrets Manager, Azure Key Vault und GCP Secret Manager sind darauf ausgelegt, sensitive Daten richtig zu behandeln. Secrets sind keine Dateien auf der Festplatte mehr. Sie werden zu Objekten, die Anwendungen über eine API abrufen.

Der Wechsel von Dateien zu einem Secret Store ändert drei grundlegende Dinge:

Hier ist ein kurzes Beispiel, wie Sie ein Datenbank-Passwort mit HashiCorp Vault speichern und abrufen:

# Ein Secret speichern
vault kv put secret/myapp DB_PASSWORD=supersecret

# Das Secret abrufen
vault kv get secret/myapp

# Ausgabe:
# ====== Data ======
# Key              Value
# ---              -----
# DB_PASSWORD      supersecret

Zugriffskontrolle. Bei einer Konfigurationsdatei kann jeder, der die Datei lesen kann, das Secret sehen. Mit einem Vault definieren Sie, welche Anwendung oder Pipeline auf welches Secret zugreifen darf. Eine CI-Pipeline für die Staging-Umgebung kann Staging-Zugangsdaten abrufen, aber nicht an Produktions-Secrets kommen. Diese Granularität ist mit Dateien unmöglich.

Audit-Trail. Dateien protokollieren nicht, wer sie gelesen hat. Ein Vault zeichnet jede Zugriffsanfrage auf: wer gefragt hat, welches Secret angefordert wurde und wann das passiert ist. Wenn ein Secret durchsickert, können Sie nachvollziehen, welche Anwendungen oder Benutzer um den Zeitpunkt des Vorfalls darauf zugegriffen haben.

Verschlüsselung im Ruhezustand und während der Übertragung. Konfigurationsdateien speichern Secrets im Klartext auf der Festplatte. Ein Vault verschlüsselt Secrets beim Speichern und beim Senden über das Netzwerk. Selbst wenn jemand Zugriff auf den zugrunde liegenden Speicher erhält, kann er die Secrets ohne die Verschlüsselungsschlüssel nicht lesen.

Die Betriebskosten der Nutzung eines Vaults

Secret-Management-Tools sind nicht kostenlos, und die Kosten sind nicht nur finanzieller Natur. Ihr Team muss lernen, wie man das Tool bedient. Wenn der Vault ausfällt, können Anwendungen keine Secrets abrufen und funktionieren möglicherweise gar nicht mehr. Sie benötigen Strategien für Hochverfügbarkeit, Caching oder Fallback-Mechanismen, damit ein Vault-Ausfall nicht Ihr Produktionssystem lahmlegt.

Cloud-verwaltete Secret Stores reduzieren den Betriebsaufwand, führen aber Preise pro Anfrage oder pro Secret ein. Ein Team, das Tausende von Secret-Anfragen pro Minute stellt, muss prüfen, ob die Kosten tragbar sind. Selbst gehostete Optionen wie Vault geben Ihnen mehr Kontrolle, erfordern aber dedizierten Aufwand für Wartung, Upgrades und Sicherheit.

Die richtige Wahl für Ihr Team treffen

Es gibt keine allgemeingültige Antwort darauf, wo Secrets gespeichert werden sollten. Die richtige Wahl hängt von Ihrer Teamgröße, der Anzahl der Anwendungen und Ihrer Risikotoleranz ab.

Das folgende Flussdiagramm kann Ihnen helfen zu entscheiden, welcher Ansatz für Ihre aktuelle Situation geeignet ist:

flowchart TD A[Start: Wie viele Apps und Entwickler?] --> B{Teamgröße & Komplexität} B -->|Kleines Team, eine App| C[.env-Datei, nicht in Git eingecheckt] B -->|Wachsendes Team, mehrere Apps| D[Umgebungsvariablen aus der CI] B -->|Großes Team, reguliert| E[Dedizierten Vault nutzen, z. B. HashiCorp Vault] C --> F[Risiko: manuelle Rotation, kein Audit] D --> G[Besser: zentrale Konfiguration, etwas Audit] E --> H[Am besten: Zugriffskontrolle, Audit, Verschlüsselung]

Ein kleines Team mit einer Anwendung und wenigen Umgebungen kann eine separate, nicht in Git eingecheckte Datei verwenden, solange alle die Risiken verstehen. Entscheidend ist, dass die Wahl bewusst getroffen wird und nicht einfach aus Bequemlichkeit geschieht.

Ein Team mit mehreren Anwendungen, mehreren Umgebungen und mehreren Entwicklern wird von einem dedizierten Secret Store profitieren. Der Aufwand für die Einrichtung amortisiert sich beim ersten Mal, wenn Sie eine Berechtigung über alle Umgebungen hinweg rotieren oder nachvollziehen müssen, wer auf ein später durchgesickertes Secret zugegriffen hat.

Das wichtige Prinzip ist Konsistenz. Welche Methode Sie auch wählen, wenden Sie sie einheitlich an. Die Vermischung von Ansätzen – einige Secrets in Dateien, einige in Umgebungsvariablen, einige in einem Vault – führt zu Verwirrung und erhöht die Wahrscheinlichkeit einer versehentlichen Offenlegung.

Praktische Checkliste für die Secret-Speicherung

  • Sind Secrets von der regulären Konfiguration getrennt?
  • Sind Secrets von der Versionskontrolle ausgeschlossen (.gitignore prüfen)?
  • Können Sie eine Berechtigung rotieren, ohne den Anwendungscode zu ändern?
  • Wissen Sie, welche Anwendungen und Pipelines auf jedes Secret zugreifen können?
  • Haben Sie Protokolle, die zeigen, wer wann auf ein Secret zugegriffen hat?
  • Wenn Ihr Secret Store ausfällt, kann Ihre Anwendung trotzdem starten oder zumindest kontrolliert fehlschlagen?

Was als Nächstes kommt

Zu wissen, wo Secrets gespeichert werden sollen, ist nur die halbe Arbeit. Die nächste Frage ist, wie Ihre Pipeline diese Secrets abruft, ohne sie selbst in der Pipeline-Konfiguration zu speichern. Eine CI/CD-Pipeline, die Secrets in Logs ausgibt, in für alle Schritte sichtbaren Umgebungsvariablen speichert oder in Workspace-Dateien zwischenspeichert, ist nicht besser als eine in Git eingecheckte Konfigurationsdatei. Die Speichermethode ist wichtig, aber wie Secrets durch Ihren Bereitstellungsprozess fließen, ist genauso wichtig.