.env-Dateien vor dem Commit verschlüsseln: Ein Praxisleitfaden

Die .env-Datei, die nie hätte committet werden dürfen

Jede Entwicklerin kennt das: ein Repository mit einer .env-Datei, die Datenbank-Zugangsdaten, API-Keys und ein Produktions-Secret enthält – für immer in der Git-Historie.

Git-Historie ist ein dauerhaftes Protokoll. Die Datei heute zu löschen entfernt sie nicht aus vergangenen Commits; jeder Clone, Fork oder CI-Cache kann sie weiterhin enthalten. Angreifer scannen öffentliche Repositories gezielt nach genau solchen Dateien.

Die Lösung beginnt, bevor die Datei entsteht: Committen Sie Secrets niemals im Klartext. Verschlüsselung ist der Notfallweg für Fälle, in denen eine Kopie überhaupt im Repository liegen muss.

Die besseren Optionen vor der Verschlüsselung

• gitignore – fügen Sie .env und .env.* hinzu und stagen Sie sie nie
• Umgebungsvariablen, die Ihr Host, CI oder Ihre Deployment-Plattform injiziert
• Ein Secret-Manager für Produktionswerte mit Injektion zur Laufzeit
• Nur nicht-sensitive Standardwerte in einer committeten .env.example mit Platzhaltern

Warum AES-256-GCM für Umgebungsdateien

AES-256-GCM ist ein authentifizierter Verschlüsselungsmodus: Er liefert Vertraulichkeit und erkennt jede Manipulation am Chiffretext. Wird die Datei im Repository verändert, schlägt die Entschlüsselung fehl, statt stillschweigend korrupte Werte zu liefern.

Da .env-Dateien meist kleiner Text sind, ist die Verschlüsselung als einzelnes Dokument mit Passphrase praktikabel. Die Passphrase wird mit PBKDF2 gestreckt, sodass eine schwache Passphrase dem Angreifer echte Rechenkosten pro Versuch abverlangt.

Alles kann im Browser mit der Web Crypto API geschehen – der Klartext muss nie einen Server erreichen, genau das verlangt ein Zero-Knowledge-Workflow.

Eine .env-Datei vor dem Commit verschlüsseln

1. Öffnen Sie den AES-256-GCM-Verschlüsseler.
2. Wechseln Sie in den Dateimodus und wählen Sie Ihre .env-Datei, oder fügen Sie den Inhalt in das Textfeld ein.
3. Wählen Sie passwortbasierte Verschlüsselung und vergeben Sie eine starke Passphrase – mindestens 12 zufällige Zeichen, idealerweise eine Phrase aus vier oder mehr Wörtern.
4. Verschlüsseln Sie und speichern Sie die Ausgabe als .env.enc (oder env.enc).
5. Entfernen Sie die Klartextdatei aus dem Arbeitsverzeichnis und committen Sie nur den Chiffretext, plus eine env.example, die die Variablennamen ohne Werte dokumentiert.
6. Teilen Sie die Passphrase über einen Kanal außerhalb des Repositories – einen Passwort-Manager, nicht eine Chat-Nachricht oder einen PR-Kommentar.

Entschlüsseln, wenn ein Teammitglied das Repository zieht

1. Repository abrufen und den AES-256-GCM-Verschlüsseler öffnen.
2. Die .env.enc-Datei auswählen.
3. Die geteilte Passphrase eingeben und entschlüsseln.
4. Die Werte in die lokale Umgebung übernehmen oder die Klartextdatei lokal speichern – und sicherstellen, dass Git sie ignoriert.

Rotation und Incident Response

Verschlüsselung reduziert die Exposition, aber wenn je eine .env im Klartext committet wurde, gehen Sie davon aus, dass jedes Secret darin kompromittiert ist, und rotieren Sie – auch wenn Sie die Datei später entfernen oder verschlüsseln.

Verlässt ein Teammitglied, das die Passphrase kennt, das Team, rotieren Sie die Passphrase und verschlüsseln die Datei neu. Besser: Rotieren Sie die Secrets selbst, damit der alte Chiffretext wertlos wird.

Ergänzen Sie einen CI-Check, der fehlschlägt, wenn eine Klartext-.env in einem Diff auftaucht. Ein paar Zeilen Skript sind billiger als die Aufräumarbeit nach einem Leak.

FAQ

Referenzen

• NIST SP 800-38D – Galois/Counter Mode (GCM): https://csrc.nist.gov/pubs/sp/800/38/d/final
• RFC 5116 – Authentifizierte Verschlüsselung: https://www.rfc-editor.org/rfc/rfc5116
• NIST SP 800-132 – Passwortbasierte Schlüsselableitung (PBKDF2): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
• OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html