Entfernen vertraulicher Daten aus einem Repository

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 von git 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 entfernt git 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 Bedarf git 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 Enterprise Cloud
• 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 Cloud über den uns über das GitHub-Support-Portal dauerhaft entfernen lassen.

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

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.

1. 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.

2. 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.
   

3. Navigiere zum Arbeitsverzeichnis des Repositorys.

   cd YOUR-REPOSITORY
   

4. 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.

5. Stelle sicher, dass du alles entfernt hast, das du aus dem Repositoryverlauf entfernen möchtest.

6. 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
   

7. 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)
   

8. 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 Enterprise Cloud zu pushen, musst du einige weitere Schritte ausführen, um die Daten vollständig aus GitHub Enterprise Cloud zu entfernen.

1. Wenn das Repository mithilfe von GitHub Enterprise Importer migriert wurde, gibt es möglicherweise einige Git-Verweise, die nicht dem Standard entsprechen und dem Muster refs/github-services folgen, wodurch weder das BFG-Tool noch git filter-repo entfernt werden können. Entferne in diesem Fall diese Verweise, indem du die folgenden Befehle in deiner lokalen Kopie des Repositorys ausführst:

   # fetch all refs
   git ls-remote | grep refs/github-services | cut -f2 | sort -t'/' -k3,4n > github-services-refs.txt
   
   # inspect and validate refs to be deleted
   cat github-services-refs.txt
   
   # delete refs in batches
   export BATCH_SIZE=512
   cat github-services-refs.txt | xargs -n $BATCH_SIZE git push origin --delete
   

2. 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 Enterprise Cloud zu entfernen. Bitte geben Sie den Namen des Repositorys und/oder einen Link zu dem Commit an, der entfernt werden soll.

3. 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 . 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.

Weitere Informationen

• git filter-repo-Manpage
• Pro Git: Git-Tools – Erneutes Generieren des Verlaufs
• Informationen zur Geheimnisüberprüfung