Ein Entwickler pusht „.env.produktion“ „vorübergehend“, um die Blockierung eines Kollegen aufzuheben. Privates Repository – dann Consultant-Fork, Leck in GitHub-Aktionsprotokollen oder versehentlich öffentlich gemachtes Repository. AWS- und Stripe-Schlüssel sind für immer im Git-Verlauf aktiv. Durch das Zurücksetzen des Commits wird nicht widerrufen, was die Crawler bereits indiziert haben.
Bereitstellungsgeheimnisse – API-Schlüssel, Datenbankkennwörter, Messaging-Tokens – befinden sich nicht im Repository. Punkt. Die operative Frage ist, wo sie leben und wie sie sich ohne Panik wenden.
Nicht verhandelbare Regeln
Fügen Sie „.env*“ in „.gitignore“ ein und prüfen Sie in der kontinuierlichen Integration, dass ein Commit fehlschlägt, wenn ein geheimes Muster erkannt wird. Pflegen Sie ein „.env.example“ ohne Werte – nur Dokumentation der erforderlichen Schlüssel. Planen Sie die Rotation nach der Abreise, einem verdächtigen Leck oder dem Ende des Betriebs. geringste Berechtigung anwenden: Der AWS-Schlüssel ist auf eine Aktion beschränkt, nicht auf den globalen Administrator. Senden Sie niemals Geheimnisse in URLs, Sentry oder Tracking-Tickets.
| Anti-Muster | Ersatz |
|---|---|
.env in git | Forge-Geheimnisse + Serverdatei |
| Produktschlüssel im Staging | Dedizierte Testkonten |
| Geheimnis im Docker-Image | Laufzeitinjektion |
| Schlüsselfreigabe per Messaging | Gemeinsamer Team-Tresor |
Nach Umgebung
In local behält jeder Entwickler eine persönliche „.env“-Datei, die nie festgeschrieben wird. Verwenden Sie bei der kontinuierlichen Integration verschlüsselte Geheimnisse von GitHub oder GitLab. bei der Bereitstellung per SSH oder Plattform-API injizieren. In der Serverproduktion eine „/var/www/.env“-Datei mit Berechtigungen, die für das Bereitstellungskonto reserviert sind, oder eine systemd-Umgebungsdatei außerhalb des Webstammverzeichnisses. Auf verwalteter Plattform verschlüsselte Dashboard-Umgebungsvariablen mit Audit-Trail. Koppeln Sie es mit CI/CD-Kleinprojekt, ohne die Umgebung im ausführlichen Modus zu protokollieren.
Proaktive Erkennung
Scannen Sie mit gitleaks oder trufflehog im Pre-Commit oder CI. Aktivieren Sie die GitHub-Geheimniserkennung, wenn das Repository öffentlich wird. Überprüfen Sie vierteljährlich, wer Zugriff auf Produktionsschlüssel hat.
Rotation ohne Unterbrechung
Verwenden Sie doppelte Aktivierungs-API-Schlüssel, wenn der Anbieter dies zulässt (z. B. Stripe). Für die Basis: sekundärer Benutzer, Umschalten der Verbindungszeichenfolge, Widerruf des alten. Dokumentieren Sie den Auftrag – testen Sie ihn zunächst in der Vorproduktion.
Der Gipfel: Das Privatdepot ist kein Tresor
Siehe KMS-Schlüsselverwaltung für sensible Lasten über „.env“ hinaus.
Entscheide dich und gehe ohne blinden Fleck voran
Scannen Sie zunächst den Git-Verlauf mit Gitleaks oder einem gleichwertigen Tool. Widerrufen und rotieren Sie alle offengelegten oder fragwürdigen Schlüssel – nicht nur den letzten Commit. Zentralisieren Sie Geheimnisse der kontinuierlichen Integration und pflegen Sie eine aktuelle „.env.example“. Vorproduktions- und Produktions-IDs strikt trennen. Bilden Sie das Team: Bewahren Sie niemals Geheimnisse in einem Ticket oder Chat auf. Vergleichen Sie Plattformhosts mit dokumentierter Geheimnisverwaltung über das Verzeichnis.
Häufig gestellte Fragen
.env versehentlich begangen?
Sofort widerrufen und drehen – das Rückgängigmachen des Git-Commits reicht nicht aus, der Verlauf bleibt geheim.
Geheimnisse in CI?
Verschlüsselte Geheimnisse der Schmiede, die niemals in Protokollen angezeigt werden – auch nicht im Debug.
Gleiches .env-Staging und Produkt?
Nein – getrennte Testschlüssel und Live-Schlüssel, wenn möglich getrennte Cloud-Konten.
Tresor erforderlich?
Nein für ein kleines Team; Forge-Geheimnisse plus .env-Server reichen oft für bis zu zehn gemeinsame Geheimnisse.
Schlüssel nicht länger im Repository zu verstecken bedeutet zu akzeptieren, dass Git kein Tresor ist – und dass Rotation eine Funktion und keine Strafe ist.