Format Atlas

Ratgeber

Wo Konfiguration und Geheimnisse aufbewahren?

Trennen Sie gewöhnliche Einstellungen von Zugangsdaten und wählen Sie je nach Zugriffsbedarf einen passenden Speicherort für lokale Entwicklung, CI und Produktivbetrieb.

Welches Format sollten Sie wählen?

Wählen Sie nach der Rolle der Datei in Ihrem Arbeitsablauf.

  • Gemeinsame Standardwerte → Beispiele ohne Geheimnisse im Repository versionieren
  • Lokale Einstellungen einzelner Entwickler → .env verwenden, sofern unterstützt, und von Git ausschließen
  • CI-Zugangsdaten → Secret-Speicher des CI-Anbieters nutzen und Zugriffe begrenzen
  • Produktivbetrieb und Container → Secret-Funktion der Laufzeitplattform nutzen und nur benötigte Dienste berechtigen
  • Mögliche Offenlegung → Zugangsdaten widerrufen oder erneuern; die Datei zu löschen reicht nicht

Einstellungen und Geheimnisse unterscheiden

Nicht sensible Einstellungen wie Dienst-URLs oder Funktionsschalter müssen anders behandelt werden als Zugangsdaten wie Passwörter, API-Schlüssel und private Schlüssel. Hinterlegen Sie keine echten Zugangsdaten fest im Code und committen Sie keine Dateien mit echten Werten in ein gemeinsames Repository. Prüfen Sie zuerst, welche Konfigurationswege die Anwendung unterstützt.

Lokale .env-Dateien von Git ausschließen

Wenn Ihre Werkzeuge es unterstützen, speichern Sie lokale Werte je Entwickler in einer .env-Datei und teilen Sie eine .env.example mit Variablennamen und Platzhaltern. Nehmen Sie die echte .env-Datei in .gitignore auf und prüfen Sie, ob Git sie nicht bereits verfolgt. Eine Git-Ausschlussregel ist kein sicherer Tresor und entfernt auch keine Werte aus der bestehenden Historie.

CI-Secrets mit minimalen Berechtigungen verwenden

Hinterlegen Sie Zugangsdaten in CI-Systemen wie GitHub Actions über die Secret-Funktion des Anbieters und nicht in Workflow-Dateien. Beschränken Sie den Zugriff auf die benötigten Repositorys, Umgebungen und Jobs, erteilen Sie Tokens nur die erforderlichen Rechte und vermeiden Sie die Ausgabe von Werten. Eine automatische Maskierung garantiert nicht, dass alle umgewandelten Werte oder Kommandoausgaben verborgen bleiben.

Secrets aus der Produktivumgebung bereitstellen

Verwenden Sie im Produktivbetrieb bevorzugt den Secret-Speicher des Hosting- oder Cloud-Anbieters und begrenzen Sie, welche Deployments und Dienste Werte auslesen dürfen. Docker Compose kann Secrets als Dateien in ausdrücklich berechtigte Dienste einbinden; Funktionen und Einschränkungen unterscheiden sich je nach Plattform. Prüfen Sie daher die Dokumentation Ihrer tatsächlichen Laufzeitumgebung. Wenn verfügbar, kommen kurzlebige Zugangsdaten wie OIDC statt langlebiger Schlüssel infrage.

Offengelegte Zugangsdaten widerrufen oder erneuern

Wenn ein Secret möglicherweise in einem Commit, CI-Log oder Chat aufgetaucht ist, reicht es nicht, nur die sichtbare Kopie zu löschen. Widerrufen oder erneuern Sie zuerst den betroffenen Schlüssel oder Token und prüfen Sie anschließend Zugriffsprotokolle und eine mögliche Nutzung. Kümmern Sie sich danach um Repository-Historie und Logs und verschärfen Sie die Zugriffsregeln, damit es nicht erneut passiert.

Geeignete Formate

.env

Geeignet für: Lokale Werte mit Werkzeugen laden, die .env-Dateien unterstützen

Weniger geeignet für: Geheimnisse ungeschützt teilen oder speichern

.gitignore

Geeignet für: Verhindern, dass noch nicht verfolgte lokale .env-Dateien versehentlich hinzugefügt werden

Weniger geeignet für: Secrets widerrufen oder bereits von Git verfolgte Werte aus der Historie entfernen

Vor dem Export prüfen

  • .env und .gitignore allein schützen Geheimnisse nicht. Prüfen Sie auch den Git-Status, CI-Logs, Sicherungskopien und den Secret-Speicher der Laufzeitumgebung.
  • Maskierung verbirgt möglicherweise keine umgewandelten Werte und nicht jede Kommandoausgabe.
  • Bei einem möglichen Leak Zugangsdaten widerrufen oder erneuern, statt nur die Datei zu löschen.

Ratgeber

Ein Konfigurationsformat wählenPrüfe zuerst, welche Formate das Zielwerkzeug akzeptiert. Bei mehreren Möglichkeiten wähle ein Format, das das Team sicher prüfen und pflegen kann.Ein Zertifikat- oder Schlüsselformat wählenPrüfe zuerst das vom Ziel geforderte Format und unterscheide ausgestelltes Zertifikat, Zertifikatsantrag und privaten Schlüssel.

Quellen und Spezifikationen