Eine neue Entwicklerin fängt an oder ein externer Entwickler steigt ins Projekt ein, und als Erstes wird die .env gebraucht, mit der das Projekt läuft. Diese Datei mischt meist harmlose Einstellungen mit den sensibelsten Werten, die das Team besitzt. Genau deshalb landet sie so oft in einer Direktnachricht oder als E-Mail-Anhang mit dem Betreff „config“.
Wer eine Konfigurationsdatei sicher an einen Entwickler übergeben will, behandelt sie als zwei Dinge: Einstellungen, die auf jedem Weg reisen dürfen, und Geheimnisse, die genau einmal über einen Kanal reisen, der keine Kopien behält. Dieser Leitfaden zeigt, wie Sie beides trennen, wie Sie den geheimen Teil verschicken und was Sie dem Entwickler mitgeben, damit die Datei auch nach der Ankunft sicher bleibt.
Lesen Sie die Datei, als wäre jede Zeile öffentlich
Öffnen Sie die Datei und ordnen Sie jede Zeile einer von zwei Gruppen zu.
- Einstellungen: Log-Level, Ports, Feature-Flags, Endpunkte außerhalb der Produktion, öffentliche Client-IDs. Sie gehören als Beispieldatei ins Repository und dürfen auf jedem beliebigen Weg verschickt werden.
- Geheimnisse: Datenbankpasswörter, API-Schlüssel, Signing-Secrets, private Schlüssel, OAuth-Client-Secrets und alles andere, was Zugriff gewährt. Suchen Sie nach
PASSWORD,SECRET,TOKEN,KEYundPRIVATEund lesen Sie danach den Rest. Ein Connection-String mit eingebettetem Passwort gibt sich nämlich nicht zu erkennen.
Fragen Sie dann, woran der Entwickler arbeitet. Lokale Entwicklung gegen Staging braucht die Staging-Werte. Sie braucht keine Produktionsschlüssel und auch nicht den Live-Schlüssel des Zahlungsanbieters, nur weil zufällig einer in der Datei steht.
Halten Sie Geheimnisse aus der eingecheckten Datei heraus
Die eingecheckte .env.example dokumentiert jede Variable mit einem Platzhalter. Die echten Werte kommen zur Laufzeit aus der Umgebung, aus einem Secrets Manager oder aus dem Secret-Speicher der Plattform. Mit diesem Muster besteht die Datei, die Sie übergeben, nur noch aus den geheimen Werten, und die lokale Kopie des Entwicklers ist der einzige Ort, an dem alles zusammenkommt.
# .env.example (committed)
DATABASE_URL=postgres://app:CHANGE_ME@staging-db.internal:5432/app
STRIPE_SECRET_KEY=sk_test_CHANGE_ME
SESSION_SECRET=CHANGE_ME
LOG_LEVEL=debug
Tragen Sie .env in die .gitignore ein, bevor irgendjemand eine echte Datei hat, und richten Sie am besten einen Pre-Commit-Hook wie gitleaks ein, damit ein versehentlicher Commit sofort scheitert.
Geben Sie dem Entwickler wenn möglich eigene Zugangsdaten
Eine Übergabe ist auch eine Gelegenheit, mit dem Teilen aufzuhören. Unterstützt die Datenbank individuelle Benutzer, legen Sie einen für den Entwickler an, mit den Rechten, die seine Arbeit braucht, und einem Ablaufdatum. Bietet die API eingeschränkte Schlüssel an, stellen Sie einen auf seinen Namen aus. Der Leitfaden zum Datenbank-Login für Externe beschreibt dieses Vorgehen. Zugangsdaten, die für eine Person erstellt wurden, lassen sich für diese eine Person wieder entfernen.
So übergeben Sie die geheimen Werte
Zwei Wege funktionieren, und bei beiden bleibt die Datei nicht in einer Nachricht liegen.
Fügen Sie die geheimen Zeilen in einen Einmal-Link ein. Öffnen Sie das Secret-Link-Tool, fügen Sie nur die Zeilen mit Geheimnissen ein und erstellen Sie den Link. Der Text wird in Ihrem Browser verschlüsselt, bevor er gespeichert wird. Die gespeicherte Kopie wird beim ersten Öffnen des Links gelöscht, und öffnet niemand den Link, läuft er nach einer Stunde, 24 Stunden oder sieben Tagen ab. Ohne Konto passen bis zu 10.000 Zeichen hinein, das reicht für die meisten .env-Dateien um ein Vielfaches.
Hängen Sie die ganze Datei an einen Secret-Link. Mit einem angemeldeten LinkPilot-Konto können Sie bis zu drei Dateien mit je 9 MB an ein Geheimnis anhängen. Jede Datei wird in Ihrem Browser mit einem Schlüssel verschlüsselt, der aus dem Schlüssel des Geheimnisses abgeleitet ist. Der Server hat die Datei also nie im Klartext, und der Anhang wird nach dem einzigen Download gelöscht. Dieser Weg ist besser, wenn die Datei Byte für Byte ankommen muss, etwa eine JSON-Datei für ein Dienstkonto oder ein Keystore.
In beiden Fällen gilt:
- Prüfen Sie die Identität des Entwicklers über den Einstellungs- oder Vertragskanal, nicht über die Adresse, die nach der Datei gefragt hat.
- Legen Sie den Ablauf auf den Zeitraum fest, den er tatsächlich braucht. Eine Stunde, wenn er gerade wartet, einen Tag, wenn er in einer anderen Zeitzone sitzt.
- Setzen Sie das Limit für Aufrufe auf eins.
- Fügen Sie mit einem Pro-Konto eine Passphrase hinzu, wenn es um Produktionswerte geht, und schicken Sie sie über einen anderen Kanal.
- Schicken Sie den Link mit einer kurzen Notiz, was er enthält und wohin die Datei gehört. Die nicht geheimen Einstellungen schicken Sie getrennt, oder Sie verweisen auf die Beispieldatei im Repository.
Eine Einladung in einen Tresor ist der bessere Weg, wenn der Entwickler fest angestellt ist und Ihr Team bereits einen Secrets Manager mit Zugriff pro Person betreibt. Den Einmal-Link nutzen Sie für die Zeit, bis das eingerichtet ist, und für alle, die nie Zugang zum Tresor bekommen.
Sagen Sie dem Entwickler, wohin die Datei gehört
Auch eine saubere Übergabe kann schlecht enden, wenn die Datei in einem geteilten Ordner landet. Schicken Sie mit den Verbindungsdaten diese Hinweise mit:
- Speichern Sie sie als
.envim Stammverzeichnis des Projekts und nirgendwo sonst. Prüfen Sie vor dem ersten Commit, dass.gitignoresie abdeckt. - Fügen Sie keine Werte in Tickets oder Chats ein, um zu fragen, ob sie stimmen. Melden Sie eine fehlende oder ungültige Variable nur mit ihrem Namen, dann stellt der Absender einen neuen Wert aus.
- Am Ende wird erneuert. Endet die Zusammenarbeit, werden die Werte in dieser Datei erneuert. Sagen Sie das von Anfang an, damit niemand überrascht ist.
Erst bestätigen lassen, dann aufräumen
Bitten Sie den Entwickler, Dateinamen, Umgebung und ein nicht geheimes Merkmal zu bestätigen, etwa einen Versionskommentar in der ersten Zeile. Meldet ein Einmal-Link, dass er geöffnet wurde, bevor der Entwickler dazu kam, gilt jeder Wert darin als offengelegt und wird erneuert.
Ist die Übergabe abgeschlossen, widerrufen Sie jeden Link, der nie geöffnet wurde, entfernen Sie temporäre Kopien, die Sie irgendwo abgelegt haben, und halten Sie fest, wer wann die Werte welcher Umgebung bekommen hat. Diese Aufzeichnung ist Ihr Audit-Trail. Die Datei selbst sollte nur auf dem Rechner existieren, der sie braucht.