EMZETT.
Login

Emzett Wiki

Secrets verwalten: Passwörter und Schlüssel sicher in Projekten

Properties1
tagsglossar, devops, sicherheit

2 Min. Lesezeit

Secrets verwalten: Passwörter und Schlüssel sicher in Projekten

Kurz: API-Schlüssel, Passwörter und Zertifikate gehören nicht ins Git-Repository; man hält sie in Umgebungsvariablen oder Secret-Managern und rotiert sie regelmäßig.

Genauer: Ein Secret ist jede Information, die Zugriff gewährt: Datenbankpasswort, API-Schlüssel, Token, private Schlüssel. Fast täglich werden Schlüssel aus öffentlichen Repositories abgegriffen (Bots scannen GitHub in Sekunden) und für Missbrauch genutzt (Cloud-Rechnungen, Datenabfluss).

Im Detail

Was nicht geht

  • Secrets im Quellcode oder in Konfigurationsdateien im Repo.
  • In Docker-Images oder Frontend-Code (jeder Nutzer sieht ihn).
  • In Chat, E-Mail, Tickets, Screenshots.
  • Dieselben Schlüssel für Entwicklung und Produktion, für alle Dienste.
  • Dauerhaft gültige, zu mächtige Schlüssel.

Wie man es besser macht

  1. Umgebungsvariablen (.env-Datei lokal, in .gitignore), CI-Secrets (GitHub Actions Secrets), Hosting-Einstellungen (Vercel, Netlify).
  2. Secret-Manager: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, 1Password/Bitwarden Secrets, Doppler, SOPS (verschlüsselte Dateien im Repo).
  3. Prinzip der geringsten Rechte: Schlüssel mit minimalen Berechtigungen, getrennte für Umgebungen und Dienste.
  4. Rotation: regelmäßig erneuern, kurzlebige Tokens, bei Verdacht sofort widerrufen.
  5. Zugriff protokollieren und überwachen.
  6. Zwei Zugangsebenen (kein einzelner Schlüssel für alles).

Schutz vor Leaks

  • Pre-Commit-Hooks und Scanner: gitleaks, trufflehog, GitHub Secret Scanning und Push-Protection.
  • Bei versehentlichem Commit: Schlüssel sofort widerrufen/erneuern (Löschen aus der Historie reicht nicht, die Daten sind schon kopiert); Historie danach bereinigen (git filter-repo) nur als zusätzliche Maßnahme.
  • Logs prüfen, dass keine Secrets ausgegeben werden; Fehlermeldungen nicht zu detailliert.
  • Beispieldateien (.env.example) ohne echte Werte bereitstellen.

Praxis für kleine Projekte

Nutze .env lokal und Einstellungen der Hosting-Plattform für Produktion. Erzeuge eigene Schlüssel pro Dienst, notiere sie im Passwortmanager (nicht in Dateien), richte Budgetwarnungen bei Cloud-Diensten ein und setze, wo möglich, IP-Beschränkungen oder Domain-Bindung für API-Schlüssel. Ein öffentlicher Browser-Schlüssel (zum Beispiel für Karten) muss auf die eigene Domain beschränkt werden.

Siehe auch: env-Dateien, Prinzip der geringsten Rechte, Passwortmanager

Backlinks