Entfernen vertraulicher Daten aus einem Repository
Wenn du den Verlauf deines Repositorys mithilfe von Tools wie git filter-repo
änderst, ist die Kenntnis über die Auswirkungen wichtig. Das erfolgreiche erneute Generieren des Verlaufs erfordert eine sorgfältige Koordination mit Projektmitarbeitern und weist eine Reihe von Nebeneffekten auf, die behandelt werden müssen.
Es ist wichtig zu beachten, dass es sich bei den vertraulichen Daten, die du entfernen musst, häufig um ein Geheimnis handelt (z. B. Kennwort/Token/Anmeldeinformationen). Als ersten Schritt musst du dieses Geheimnis widerrufen und/oder rotieren. Sobald das Geheimnis widerrufen oder rotiert wurde, kann es nicht mehr für den Zugriff verwendet werden. Das reicht möglicherweise aus, um dein Problem zu lösen. Das Durchlaufen der zusätzlichen Schritte, um den Verlauf erneut zu generieren und das Geheimnis zu entfernen, ist möglicherweise nicht erforderlich.
Nebeneffekte beim erneuten Generieren des Verlaufs
Es gibt zahlreiche Nebeneffekte beim erneuten Generieren des Verlaufs. Diese schließen Folgendes ein:
- Hohes Risiko einer erneuten Kontamination: Es ist bedauerlicherweise einfach, die vertraulichen Daten erneut in das Repository zu pushen und mehr Schaden anzurichten. Wenn ein Mitentwickler über einen Klon auf dem Stand vor dem erneuten Generieren verfügt und nach dem erneuten Generieren einfach
git pull
gefolgt vongit push
ausgeführt wird, werden die vertraulichen Daten zurückgegeben. Er muss seinen Klon verwerfen und erneut klonen oder mehrere Schritte sorgfältig befolgen, um seinen Klon zunächst zu bereinigen. - Risiko des Verlusts der Arbeit anderer Entwickler: Wenn andere Entwickler während der Bereinigungsversuche weiterhin Branches aktualisieren, die die vertraulichen Daten enthalten, musst du die Bereinigung wiederholen oder ihre Arbeit verwerfen.
- Geänderte Commithashes: Durch das erneute Generieren des Verlaufs werden die Hashes der Commits, die die vertraulichen Daten eingeführt haben, und alle darauffolgenden Commits geändert. Alle Tools oder Automatisierungen, die von Commithashes ohne Änderungen abhängen, werden beschädigt oder weisen Probleme auf.
- Herausforderungen beim Branchschutz: Wenn du Branchschutzmaßnahmen hast, die erzwungene Pushs verhindern, müssen diese Schutzmaßnahmen (zumindest vorübergehend) deaktiviert werden, damit die vertraulichen Daten entfernt werden.
- Fehlerhafte Diff-Ansicht für geschlossene Pull Requests: Durch das Entfernen der vertraulichen Daten müssen die internen Verweise entfernt werden, die zum Anzeigen der Diff-Ansicht in Pull Requests verwendet werden, damit diese Diffs nicht angezeigt werden können. Das gilt nicht nur für den Pull Request, der die vertraulichen Daten eingeführt hat, sondern für jeden Pull Request, der auf einer Version des Verlaufs nach dem Mergen der vertraulichen Daten basiert, selbst wenn diese späteren Pull Requests keine Datei mit vertraulichen Daten hinzugefügt oder geändert haben.
- Schlechte Interaktion mit offenen Pull Requests: Geänderte Commit-SHAs führen zu einem anderen Pull-Request-Diff, und Kommentare zum alten Pull-Request-Diff können ihre Gültigkeit verlieren und verloren gehen, was zu Verwirrung von Autoren und Prüfern führen kann. Wir empfehlen, alle geöffneten Pull Requests zusammenzuführen oder zu schließen, bevor du Dateien aus deinem Repository entfernst.
- Verlorene Signaturen bei Commits und Tags: Signaturen für Commits oder Tags hängen von Commithashes ab. Da Commithashes durch das erneute Generieren des Verlaufs geändert werden, sind Signaturen nicht mehr gültig, und die Signaturen werden durch viele Tools zum erneuten Generieren des Verlaufs (einschließlich
git filter-repo
) einfach entfernt. Tatsächlich entferntgit filter-repo
ebenfalls Commitsignaturen und Tagsignaturen für Commits vor dem Entfernen vertraulicher Daten. (Technisch gesehen kann das mit der Option--refs
umgangen werden, um bei Bedarfgit filter-repo
anzuwenden. Du musst jedoch sicherstellen, dass du alle Verweise angibst, die vertrauliche Daten in ihrem Verlauf enthalten und die Commits enthalten, die die vertraulichen Daten in deinem Bereich eingeführt haben). - Andere werden direkt zu den vertraulichen Daten geführt: Git wurde mit kryptografischen Überprüfungen entwickelt, die in Commitidentifizierer integriert sind, damit böswillige Akteure nicht in einen Server gelangen und den Verlauf ändern können, ohne bemerkt zu werden. Das ist aus Sicherheitsperspektive hilfreich, aus der Perspektive vertraulicher Daten bedeutet das jedoch, dass das Löschen vertraulicher Daten einen aufwändigen Prozess darstellt. Zudem bedeutet es, dass bei Änderungen des Verlaufs Benutzer mit einem vorhandenen Klon, die mit dem Prozess vertraut sind, die Abweichungen des Verlaufs bemerken und sie verwenden können, um die vertraulichen Daten immer noch in ihrem Klon zu finden, die du aus dem zentralen Repository entfernt hast.
Informationen zur Offenlegung vertraulicher Daten
Das Entfernen vertraulicher Daten aus einem Repository umfasst vier allgemeine Schritte:
- Erneutes Generieren des Repositorys mithilfe von git-filter-repo
- Aktualisieren des Repositorys auf GitHub mithilfe des lokal erneut generierten Verlaufs
- Koordination mit Kollegen zum Bereinigen weiterer vorhandener Klone
- Verhindern von Wiederholungen und Vermeiden zukünftiger Lecks vertraulicher Daten
Wenn du deinen Verlauf lediglich neu generierst und einen erzwungenen Push durchführst, sind die Commits mit vertraulichen Daten möglicherweise noch an anderer Stelle zugänglich:
- In allen Klonen oder Forks Ihres Repositorys
- Direkt über ihre SHA-1-Hashes in zwischengespeicherten Ansichten auf GitHub
- Durch allePull Requests, die darauf verweisen
Du kannst vertrauliche Daten nicht aus Klonen entfernen, die andere Benutzer von deinem Repository erstellt haben, aber du kannst zwischengespeicherte Ansichten und Verweise auf die vertraulichen Daten in Pull Requests auf GitHub über den uns über das GitHub-Support-Portal dauerhaft entfernen lassen.
Important
GitHub-Support entfernt keine nicht vertraulichen Daten und hilft nur bei der Entfernung vertraulicher Daten in Fällen, in denen wir feststellen, dass das Risiko nicht durch Drehen betroffener Anmeldeinformationen verringert werden kann.
Wenn der Commit, der die vertraulichen Daten eingeführt hat, in allen Forks vorhanden ist, kann weiterhin darauf zugegriffen werden. Sie müssen sich mit den Besitzern der Forks abstimmen und sie bitten, die vertraulichen Daten zu entfernen oder die Verzweigung vollständig zu löschen. GitHub können keine Kontaktinformationen für diese Besitzer bereitstellen.
Berücksichtige diese Einschränkungen und Herausforderungen bei deiner Entscheidung, den Verlauf deines Repositorys neu zu generieren.
Löschen einer Datei aus dem Verlauf deines Repositorys mithilfe von git-filter-repo
Warning
Wenn Sie git filter-repo
ausführen, nachdem Sie für Änderungen einen Stash ausgeführt haben, können Sie ihre Änderungen nicht mit anderen Stashbefehlen abrufen. Vor dem Ausführen von git filter-repo
sollten Sie den Stash aufheben, den Sie für Ihre vorgenommenen Änderungen ausgeführt haben. Führe git stash show -p | git apply -R
aus, um deinen letzten Stash aufzuheben. Weitere Informationen findest du unter Git Tools – Stashen und Bereinigen.
Um zu veranschaulichen, wie git filter-repo
funktioniert, zeigen wir Ihnen, wie Sie Ihre Datei mit vertraulichen Daten aus dem Verlauf Ihres Repositorys entfernen und .gitignore
hinzufügen, um sicherzustellen, dass sie nicht versehentlich erneut committet wird.
-
Installiere die neueste Version des Tools git filter-repo. Du kannst
git-filter-repo
manuell oder mithilfe eines Paket-Managers installieren. Verwenden Sie beispielsweise den Befehlbrew install
, um das Tool mit HomeBrew zu installieren.brew install git-filter-repo
Weitere Informationen findest du in INSTALL.md im Repository
newren/git-filter-repo
. -
Wenn Sie keine lokale Kopie des Repositorys mit den vertraulichen Daten im Verlauf haben, müssen Sie das Repository auf Ihrem lokalen Computer klonen.
$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY > Initialized empty Git repository in /Users/YOUR-FILE-PATH/YOUR-REPOSITORY/.git/ > remote: Counting objects: 1301, done. > remote: Compressing objects: 100% (769/769), done. > remote: Total 1301 (delta 724), reused 910 (delta 522) > Receiving objects: 100% (1301/1301), 164.39 KiB, done. > Resolving deltas: 100% (724/724), done.
-
Navigiere zum Arbeitsverzeichnis des Repositorys.
cd YOUR-REPOSITORY
-
Führe den folgenden Befehl aus, und ersetze
PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA
durch den Pfad zur Datei, die du entfernen möchtest, nicht nur durch den Dateinamen. Diese Argumente werden:-
erzwingen, dass Git den gesamten Verlauf eines jeden Branchs und Tags verarbeitet, ohne ihn auszuchecken
-
die angegebene Datei sowie alle leeren Commits entfernen, die als Ergebnis generiert wurden
-
einige Konfigurationen entfernen, wie zum Beispiel die Remote-URL, die in der Datei .git/config gespeichert ist Du solltest diese Datei zur späteren Wiederherstellung im Voraus sichern.
-
vorhandene Tags überschreiben
$ git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA Parsed 197 commits New history written in 0.11 seconds; now repacking/cleaning... Repacking your repo and cleaning out old unneeded objects Enumerating objects: 210, done. Counting objects: 100% (210/210), done. Delta compression using up to 12 threads Compressing objects: 100% (127/127), done. Writing objects: 100% (210/210), done. Building bitmaps: 100% (48/48), done. Total 210 (delta 98), reused 144 (delta 75), pack-reused 0 Completely finished after 0.64 seconds.
Important
Wenn die Datei mit vertraulichen Daten in anderen Pfaden zu finden war (weil sie verschoben oder umbenannt wurde), müssen Sie diesen Befehl auch für diese Pfade ausführen.
-
-
Stelle sicher, dass du alles entfernt hast, das du aus dem Repositoryverlauf entfernen möchtest.
-
Das Tool
git filter-repo
entfernt Ihre konfigurierten Remotes automatisch. Verwenden Sie den Befehlgit remote set-url
, um Ihre Remotes wiederherzustellen, und ersetzen Sie dabeiOWNER
undREPO
durch Ihre Repository-Details. Weitere Informationen finden Sie unter Remote-Repositorys verwalten.git remote add origin https://github.com/OWNER/REPOSITORY.git
-
Sobald du mit dem Status deines Repositorys zufrieden bist und die entsprechenden Remotedaten festgelegt hast, führe einen erzwungenen Push deiner lokalen Änderungen durch, um dein Repository auf GitHub.com zu überschreiben. Ein erzwungener Push ist erforderlich, um vertrauliche Daten aus deinem Commitverlauf zu entfernen.
$ git push origin --force --all > Counting objects: 1074, done. > Delta compression using 2 threads. > Compressing objects: 100% (677/677), done. > Writing objects: 100% (1058/1058), 148.85 KiB, done. > Total 1058 (delta 590), reused 602 (delta 378) > To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git > + 48dc599...051452f main -> main (forced update)
-
Um die vertrauliche Datei aus Deinen getaggten Releases zu entfernen, musst du auch einen Push für deine Git-Tags erzwingen:
$ git push origin --force --tags > Counting objects: 321, done. > Delta compression using up to 8 threads. > Compressing objects: 100% (166/166), done. > Writing objects: 100% (321/321), 331.74 KiB | 0 bytes/s, done. > Total 321 (delta 124), reused 269 (delta 108) > To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git > + 48dc599...051452f main -> main (forced update)
Vollständiges Entfernen der Daten aus GitHub
Nachdem du git filter-repo
verwendet hast, um die vertraulichen Daten zu entfernen und deine Änderungen an GitHub zu pushen, musst du einige weitere Schritte ausführen, um die Daten vollständig aus GitHub zu entfernen.
-
Kontaktieren Sie den uns über das GitHub-Support-Portal, und bitten Sie darum, zwischengespeicherte Ansichten und Referenzen auf die sensiblen Daten in Pull Requests auf GitHub zu entfernen. Gib den Namen des Repositorys und/oder einen Link zu dem Commit an, der entfernt werden soll.
Important
GitHub-Support entfernt keine nicht vertraulichen Daten und hilft nur bei der Entfernung vertraulicher Daten in Fällen, in denen wir feststellen, dass das Risiko nicht durch Drehen betroffener Anmeldeinformationen verringert werden kann.
-
Teile deinen Projektmitarbeitern, dass sie für alle Branches, die sie aus deinem alten (nicht mehr gültigen) Repositoryverlauf erstellt haben, ein Rebase, keinen Merge durchführen sollen. Durch einen Merge-Commit würde womöglich der gesamte unbrauchbare Verlauf wiederhergestellt, den zu entfernen du Dir gerade so viel Mühe gemacht hast.
Versehentliche Commits künftig vermeiden
Indem du verhinderst, dass Mitwirkende versehentlich Commits ausführen, kannst du die Offenlegung vertraulicher Informationen verhindern. Weitere Informationen findest du unter Best Practices zum Verhindern von Datenlecks in deiner Organisation.
Es gibt ein paar Schritte, mit denen du es vermeiden kannst, Elemente zu committen oder zu pushen, die nicht freigegeben werden sollten:
- Wenn es wahrscheinlich ist, dass die vertraulichen Daten in einer Datei gefunden werden, die nicht von Git nachverfolgt werden soll, füge die entsprechenden Dateinamen zu
.gitignore
hinzu, und stelle sicher, dass du diese Änderung an.gitignore
pushst, damit weitere Entwickler geschützt sind. - Vermeide die Hartcodierung von Geheimnissen im Code. Verwende Umgebungsvariablen oder Geheimverwaltungsdienste wie Azure Key Vault, AWS Secrets Manager oder HashiCorp Vault, um Geheimnisse zur Laufzeit zu verwalten und zu injizieren.
- Erstelle einen Hook vor dem Commit, um nach vertraulichen Daten zu suchen, bevor diese an beliebiger Stelle committet oder gepusht werden, oder verwende in einem Hook vor dem Commit ein bekanntes Tool wie git-secrets oder gitleaks. (Bitte alle Projektmitarbeiter darum, den von dir ausgewählten Hook vor dem Commit einzurichten.)
- Verwende ein visuelles Programm wie GitHub Desktop oder gitk, um die Änderungen zu committen. In visuellen Programmen ist meist leichter erkennbar, welche Dateien durch einen Commit hinzugefügt, gelöscht und geändert werden.
- Vermeide die allgemeingültigen Befehle
git add .
undgit commit -a
für die Befehlszeile – verwende stattdessengit add filename
undgit rm filename
, um die Dateien einzeln bereitzustellen. - Verwende
git add --interactive
, um die Änderungen in jeder Datei einzeln zu überprüfen und zu stagen. - Verwende
git diff --cached
, um die für den Commit gestageten Änderungen zu überprüfen. Das ist genau der Unterschied, dengit commit
erzeugt, solange du nicht das-a
Flag verwendest. - Aktivieren Sie den Push-Schutz für das Repository, um Push-Vorgänge mit hardcodierten Geheimnissen zu erkennen und zu verhindern, die sie in der Codebasis festgeschrieben werden. Weitere Informationen finden Sie unter Informationen zum Pushschutz.