Jeder Entwickler hat versehentlich Dateien mit vertraulichen Informationen versehentlich in das öffentliche Repository übertragen. Wie gehe ich mit einem solchen Problem um? Wie kann man sicherstellen, dass so etwas nicht noch einmal passiert?
In diesem Artikel werde ich Ihnen sagen, was zu tun ist, wenn eine Datei versehentlich in das Repository gelangt, das dort absolut nichts zu tun hat. Hier werde ich Git-Befehle bereitstellen, mit denen Sie den Verlauf korrigieren und einige Empfehlungen für die Organisation der sicheren Arbeit mit vertraulichen Informationen teilen können.
Entfernen vertraulicher Dateien aus dem Git-Repository ( großes Bild )
Schaden minimieren
Sie haben also versehentlich eine Datei mit vertraulichen Informationen festgeschrieben. Nennen wir diese Datei
.env. Unmittelbar danach müssen Sie sich einige Fragen stellen:
- Wurde das Commit in das Remote-Repository verschoben?
- Ist das Remote-Repository öffentlich zugänglich?
▍Commit wurde noch nicht an das Remote-Repository gesendet
Wenn Sie noch kein Commit an das Repository gesendet haben, stellt die aufgetretene Situation im Allgemeinen keine Bedrohung dar. Um alles zu reparieren, müssen Sie nur zum vorherigen Commit zurückkehren:
git reset HEAD^ --soft
Die Dateien verbleiben in der Arbeitskopie des Repositorys. Sie können die erforderlichen Änderungen am Projekt vornehmen.
Wenn Sie das Commit beibehalten möchten und nur bestimmte Dateien daraus entfernen müssen, gehen Sie folgendermaßen vor:
git rm .env --cached
git commit --amend
Dieser Parameter
--amendkann nur verwendet werden, um mit dem letzten Commit zu arbeiten. Wenn Sie nach einem fehlgeschlagenen Commit einige weitere hinzugefügt haben, verwenden Sie diesen Befehl:
git rebase -i HEAD~{ ?}
Dies behebt das falsche Commit und hilft Ihnen, die Änderungen, die andere Commits am Projekt vorgenommen haben, nicht zu verlieren.
▍Commit wurde an das Remote-Repository gesendet
Wenn Sie bereits ein Commit an ein Remote-Repository gesendet haben, müssen Sie zunächst den Unterschied zwischen öffentlichen und privaten Repositorys kennen.
Wenn Ihr Repository privat ist und für Bots oder Personen, denen Sie nicht vertrauen, nicht zugänglich ist, können Sie das letzte Commit einfach mit einigen der oben genannten Befehle optimieren.
Wenn Sie nach einem problematischen Commit andere Commits in das Repository verschoben haben, hindert dies Sie nicht daran, vertrauliche Dateien mit dem Befehl git filter-branch oder dem Tool BFG Repo-Cleaner aus Ihrem Git-Verlauf zu entfernen .
Hier ist ein Anwendungsbeispiel
git filter-branch:
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all
Beachten Sie dabei jedoch zwei wichtige Aspekte solcher Änderungen am Repository:
- Git. , - , , PR, . .
- . , , . , , , , . , ID, , .
Muss ich neue geheime Schlüssel erstellen, wenn sich ihre aktuellen Versionen im öffentlichen Repository befinden?
Wenn Sie die Frage im Titel kurz beantworten, dann - ist es notwendig. Wenn Ihr Repository öffentlich verfügbar ist oder Sie aus irgendeinem Grund der Ansicht sind, dass es kein Ort zum Speichern sensibler Daten ist, müssen Sie die darin enthaltenen vertraulichen Daten als gefährdet betrachten.
Selbst wenn Sie diese Daten aus dem Repository entfernt haben, können Sie mit Bots und Repository-Gabeln nichts anfangen. Wie gehe ich vor?
- Deaktivieren Sie alle Schlüssel oder Passwörter. Dies muss zuerst erfolgen. Nachdem Sie die Schlüssel deaktiviert haben, werden vertrauliche Informationen, die veröffentlicht wurden, unbrauchbar.
- Passen Sie die Datei an
.gitignore. Wenn Sie die.gitignoreAufzeichnungen von Dateien mit vertraulichen Informationen für Git aufnehmen, wird der Status dieser Dateien nicht überwacht. - Bereiten Sie ein Commit vor, das keine vertraulichen Dateien enthält.
- Senden Sie die Änderungen an das Repository, und geben Sie dem Commit Erläuterungen zur Situation. Versuchen Sie nicht, den Fehler zu verbergen. Alle Programmierer, die an dem Projekt arbeiten, einschließlich Sie, werden das Vorhandensein eines Commits im Repository mit einer Erläuterung der Situation und einer Beschreibung dessen, was genau mit diesem Commit behoben wurde, zu schätzen wissen.
Best Practices zum Speichern vertraulicher Dateien in Projekten, die Git zur Versionskontrolle verwenden
Um zu verhindern, dass vertrauliche Informationen verloren gehen, sollten Sie die folgenden Empfehlungen einhalten.
▍Speichern Sie vertrauliche Daten in einer ENV-Datei (oder einer ähnlichen Datei).
Bewahren Sie API-Schlüssel und ähnliche Informationen in einer einzigen Datei auf
.env. Wenn Git bei diesem Ansatz den Status der Datei nicht verfolgt .env, indem Sie dieser Datei einen neuen Schlüssel hinzufügen, werden Sie ihn nicht versehentlich in das Repository verschieben.
Ein weiterer Vorteil dieses Ansatzes besteht darin, dass Sie auf diese Weise über eine globale Variable auf alle Schlüssel zugreifen können
process.
▍Verwenden Sie nach Möglichkeit API-Schlüssel
Kompromittierte API-Schlüssel lassen sich leicht deaktivieren und neu erstellen. Wenn möglich - verwenden Sie sie und nicht so etwas wie Anmeldungen und Passwörter.
▍Speichern Sie API-Schlüssel mit Ihrem Build-Tool
API-Schlüssel werden normalerweise beim Erstellen von Anwendungen benötigt. Mit Build-Tools wie Netlify können Sie Schlüssel in sicheren Tresoren aufbewahren. Solche Schlüssel werden mithilfe einer globalen Variablen automatisch in die Anwendung eingefügt
process.
Verwaltung von Umgebungsvariablen
▍Fügen Sie den Eintrag .env zur Datei .gitignore hinzu
Stellen Sie sicher, dass Git keine Dateien verfolgt, die vertrauliche Informationen enthalten.
▍Vorbereiten Sie eine .env.template-Vorlagendatei
Mit einer solchen Vorlagendatei können diejenigen, die an einem Projekt arbeiten, API-Schlüssel zum Projekt hinzufügen, sodass die Dokumentation nicht mehr gelesen werden muss.
▍Ändern Sie den Git-Verlauf in Remote-Repositorys nicht
Versuchen Sie, sich strikt an diese Regel zu halten. Wenn Sie die oben genannten Richtlinien befolgt haben, müssen Sie Ihren Git-Verlauf nicht ändern.
Ergebnis
Ich hoffe, mein Material hilft Ihnen dabei, sicher mit vertraulichen Daten zu arbeiten.
Haben Sie jemals etwas an ein öffentliches Repository gesendet, das nicht dorthin gehen sollte?
