Entfernen vertraulicher Daten aus einem Repository

Wenn Sie den Verlauf Ihres Repositorys mithilfe von Tools wie git filter-repo oder dem BFG Repo-Cleaner ändern, ist es wichtig, die Auswirkungen zu verstehen, insbesondere im Hinblick auf offene Pull Requests und vertrauliche Daten.

Das Tool git filter-repo und der BFG Repo-Cleaner generieren einen neuen Verlauf deines Repositorys, wodurch die SHAs für vorhandene Commits, die du bearbeitest, und alle abhängigen Commits geändert werden. Geänderte Commit-SHAs können sich auf offene Pull Requests in deinem Repository auswirken. Wir empfehlen, alle geöffneten Pull Requests zusammenzuführen oder zu schließen, bevor du Dateien aus deinem Repository entfernst.

Du kannst die Datei mit git rm aus dem letzten Commit entfernen. Informationen zum Entfernen einer Datei, die mit dem letzten Commit hinzugefügt wurde, findest du unter Informationen zu großen Dateien auf GitHub.

Informationen zur Offenlegung vertraulicher Daten

In diesem Artikel erfahren Sie, wie du Commits mit vertraulichen Daten so konfigurierst, dass diese über keinen Branch oder Tag in deinem Repository auf Ihre GitHub Enterprise Server-Instance erreichbar sind. Diese Commits können jedoch weiterhin an anderer Stelle zugänglich sein:

In allen Klonen oder Forks Ihres Repositorys
Direkt über ihre SHA-1-Hashes in zwischengespeicherten Ansichten auf GitHub Enterprise Server
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 Enterprise Server über den Ihrer Websiteadministratoren dauerhaft entfernen lassen.

Sobald du einen Commit an GitHub Enterprise Server gepusht hast, solltest du alle vertraulichen Daten im Commit als kompromittiert betrachten. Wenn der Commit ein Kennwort enthielt, ändere es. Wenn der Commit einen Schlüssel enthielt, generiere einen neuen.

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.

Berücksichtige diese Einschränkungen und Herausforderungen bei deiner Entscheidung, den Verlauf deines Repositorys neu zu generieren.

Datei aus dem Verlauf deines Repositorys löschen

Du kannst eine Datei endgültig aus dem Verlauf deines Repositorys löschen, indem du entweder das Tool git filter-repo oder das Open-Source-Tool BFG Repo-Cleaner verwendest.

Note

Wenn sich vertrauliche Daten in einer Datei befinden, die als Binärdatei identifiziert wird, müssen Sie die Datei aus dem Verlauf entfernen, da Sie sie nicht ändern können, um die Daten zu entfernen oder zu ersetzen.

Benutze BFG

Der BFG Repo-Cleaner ist ein von der Open-Source-Community entwickeltes und verwaltetes Tool. Es stellt eine schnellere und einfachere Alternative zu git filter-repo dar, um unerwünschte Daten zu entfernen.

Um beispielsweise deine Datei mit vertraulichen Daten zu entfernen und deinen letzten Commit unberührt zu lassen, führe folgenden Befehl aus:

bfg --delete-files YOUR-FILE-WITH-SENSITIVE-DATA

Um den gesamten, in passwords.txt enthaltenen Text dort zu ersetzen, wo er im Verlauf deines Repositorys aufgeführt ist, musst du folgenden Code ausführen:

bfg --replace-text passwords.txt

Nachdem die vertraulichen Daten entfernt wurden, musst du einen Push deiner Änderungen an GitHub Enterprise Server erzwingen. Durch den erzwungenen Push wird der Repositoryverlauf neu generiert, wodurch vertrauliche Daten aus dem Commitverlauf entfernt werden. Wenn du einen Push erzwingst, werden möglicherweise Commits überschrieben, auf denen andere Personen ihre Arbeit aufgebaut haben.

git push --force

Informationen zur vollständigen Verwendung sowie eine Downloadanleitung findest du in der Dokumentation für BFG Repo-Cleaner.

Verwenden 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 Befehl brew 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://HOSTNAME/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.

Fügen Sie Ihre Datei mit vertraulichen Daten zu .gitignore hinzu, um sicherzustellen, dass Sie sie nicht versehentlich erneut committen.

$ echo "YOUR-FILE-WITH-SENSITIVE-DATA" >> .gitignore
$ git add .gitignore
$ git commit -m "Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore"
> [main 051452f] Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore
>  1 files changed, 1 insertions(+), 0 deletions(-)

Überprüfen Sie noch einmal, ob Sie alles Gewünschte aus dem Verlauf Ihres Repositorys entfernt haben und ob alle Ihre Branches ausgecheckt sind.
Das Tool git filter-repo entfernt Ihre konfigurierten Remotes automatisch. Verwenden Sie den Befehl git remote set-url, um Ihre Remotes wiederherzustellen, und ersetzen Sie dabei OWNER und REPO durch Ihre Repository-Details. Weitere Informationen findest du unter Remote-Repositorys verwalten.
```
git remote add origin https://github.com/OWNER/REPOSITORY.git
```
Wenn du mit dem Zustand deines Repositorys zufrieden bist, und du das entsprechende Remoterepository gesetzt hast erzwinge einen Push deiner lokalen Änderungen, um dein Repository auf Ihre GitHub Enterprise Server-Instance zu überschreiben, ebenso wie alle von dir gepushten Branches. 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://HOSTNAME/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://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY.git
>  + 48dc599...051452f main -> main (forced update)

Vollständiges Entfernen der Daten aus GitHub

Nachdem du die vertraulichen Daten entweder mit dem BFG-Tool oder mit git filter-repo entfernt und deine Änderungen in GitHub Enterprise Server gepusht hast, musst du noch einige weitere Schritte ausführen, um die Daten vollständig aus GitHub Enterprise Server zu entfernen.

Kontaktieren Sie den Ihrer Websiteadministratoren, und bitten Sie darum, zwischengespeicherte Ansichten und Referenzen auf die sensiblen Daten in Pull Requests auf GitHub Enterprise Server zu entfernen. Bitte geben Sie den Namen des Repositorys und/oder einen Link zu dem Commit an, der entfernt werden soll. Weitere Informationen darüber, wie Site-Administratoren nicht erreichbare Git-Objekte entfernen können, finden Sie unter "Befehlszeilenprogramme." Weitere Informationen dazu, wie Website-Administratoren erreichbare Commits identifizieren können, finden Sie unter "Identifizieren erreichbarer Commits".
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.
Wenn Sie git filter-repo verwendet haben, können Sie diesen Schritt übergehen.

Wenn Sie das BFG-Tool verwendet haben, können Sie nach dem Umschreiben die Verweise im lokalen Repository auf den alten Verlauf, der dereferenziert und gelöscht werden soll, mit den folgenden Befehlen (mithilfe von Git 1.8.5 oder neuer) bereinigen:
```
$ git reflog expire --expire=now --all
$ git gc --prune=now
> Counting objects: 2437, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (1378/1378), done.
> Writing objects: 100% (2437/2437), done.
> Total 2437 (delta 1461), reused 1802 (delta 1048)
```
Note

Sie können dies auch erreichen, indem Sie Ihren gefilterten Verlauf in ein neues oder leeres Repository pushen und dann einen neuen Klon von GitHub Enterprise Server erstellst.

Identifizieren erreichbarer Commits

Um unerwünschte oder sensible Daten vollständig aus einem Repository zu entfernen, muss der Commit, der die Daten zuerst eingeführt hat, in Zweigen, Tags, Pull-Requests und Forks vollständig referenzfrei sein. Ein einzelner Verweis an einer beliebigen Stelle verhindert, dass die automatische Speicherbereinigung die Daten vollständig löscht.

Sie können auf vorhandene Referenzen überprüfen, indem Sie die folgenden Befehle verwenden, wenn sie über SSH mit der Anwendung verbunden sind. Sie benötigen die SHA des Commits, der ursprünglich die vertraulichen Daten eingeführt hat.

ghe-repo OWNER/REPOSITORY -c 'git ref-contains COMMIT_SHA_NUMBER'
ghe-repo OWNER/REPOSITORY -c 'cd ../network.git && git ref-contains COMMIT_SHA_NUMBER'

Wenn einer dieser Befehle Ergebnisse zurückgibt, müssen Sie diese Referenzen entfernen, bevor der Commit erfolgreich die automatische Speicherbereinigung ausführen kann. Der zweite Befehl identifiziert Referenzen, die in Forks des Repositorys vorhanden sind (wenn das Repository keine Forks enthält, können Sie die Ausführung überspringen).

Ergebnisse, die mit refs/heads/ oder refs/tags/ beginnen, weisen auf Zweige bzw. Tags hin, die noch Verweise auf den beanstandeten Commit enthalten, was darauf hindeutet, dass das geänderte Repository nicht vollständig von dem Commit bereinigt wurde oder dass er nicht gepusht wurde.
Ergebnisse, die mit refs/pull/ oder refs/__gh__/pull beginnen, weisen auf Pull-Requests hin, die auf den beanstandeten Commit verweisen. Diese Pull-Requests müssen gelöscht werden, damit der Commit für die automatische Speicherbereinigung zulässig ist. Ein Pull-Request kann im Admin-Dashboard der Website unter https://HOSTNAME/stafftools/repositories/OWNER/REPOSITORY/PULL_REQUESTS/<PULL-REQUEST-NUMBER> gelöscht werden, wobei <PULL-REQUEST-NUMBER> durch die Nummer des Pull-Requests ersetzt wird.

Wenn Verweise in allen Forks gefunden werden, sehen die Ergebnisse ähnlich aus, beginnen jedoch mit refs/remotes/NWO/. Um die Fork anhand des Namens zu identifizieren, können Sie den folgenden Befehl ausführen.

ghe-nwo NWO

Dasselbe Verfahren mit dem BFG-Tool oder git filter-repo kann verwendet werden, um die vertraulichen Daten aus den Forks des Repositorys zu entfernen. Alternativ können die Forks vollständig gelöscht werden, und bei Bedarf kann das Repository nach Abschluss der Bereinigung des Stamm-Repositorys erneut verzweigt werden.

Nachdem Sie die Verweise des Commits entfernt haben, führen Sie die Befehle erneut aus, um die Überprüfung durchzuführen.

Wenn keine Ergebnisse aus einem der ref-contains Befehle vorliegen, können Sie die automatische Speicherbereinigung mit dem --prune Flag ausführen, um die nicht referenzierten Commits zu entfernen, indem Sie den folgenden Befehl ausführen.

ghe-repo-gc -v --prune OWNER/REPOSITORY

Sobald die automatische Speicherbereinigung den Commit erfolgreich entfernt hat, sollten Sie das Site-Admin-Dashboard des Repositorys unter https://HOSTNAME/stafftools/repositories/OWNER/REPOSITORY aufrufen, Netzwerk auswählen und dann auf Git-Cache ungültig machen klicken, um alle zwischengespeicherten Daten zu entfernen.

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.

Durch einige einfache Tricks vermeidest du den versehentlichen Commit von Änderungen, die nicht festgeschrieben werden sollen:

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 . und git commit -a für die Befehlszeile – verwende stattdessen git add filename und git 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, den git 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 findest du unter Informationen zum Pushschutz.