Entfernen vertraulicher Daten aus einem Repository

Vertrauliche Daten können aus dem Verlauf eines Repositorys entfernt werden, wenn eine sorgfältige Koordination mit allen Personen möglich ist, die es geklont haben, und du bereit bist, dich den Nebeneffekte zu widmen.

In diesem Artikel

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 Pushes 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 bei Erstellern und Reviewern 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 direkt zu vertraulichen Daten führen: Git wurde mit kryptografischen Überprüfungen entwickelt, die in Commitidentifizierer integriert sind, damit böswillige Akteure nicht auf 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 den Klonen deines Repositorys anderer Benutzer entfernen. Stattdessen musst du ihnen die Anweisungen unter Make sure other copies are cleaned up: clones of colleagues im git filter-repo-Leitfaden senden, damit sie es selbst tun. Du kannst jedoch zwischengespeicherte Ansichten und Verweise auf die vertraulichen Daten in Pull Requests für GitHub dauerhaft entfernen, indem du uns über das GitHub-Support-Portal kontaktierst.

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 eines lokalen Repositorys mithilfe von git-filter-repo

  1. Installiere das neueste Release des git filter-repo-Tools. Du benötigst eine Version mit dem --sensitive-data-removal-Flag, also mindestens Version 2.47. 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. Klone das Repository auf deinen lokalen Computer. Weitere Informationen findest du unter Ein Repository klonen.

    git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY

  3. Navigiere zum Arbeitsverzeichnis des Repositorys.

    cd YOUR-REPOSITORY

  4. Führen Sie einen git filter-repo-Befehl aus, um die vertraulichen Daten zu bereinigen.

    Wenn du eine bestimmte Datei aus allen Branches/Tags/Verweise löschen möchtest, führe den folgenden Befehl aus, indem du PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA durch den Git-Pfad zur Datei ersetzt, die du entfernen möchtest, nicht nur den Dateinamen (z. B. src/module/phone-numbers.txt):

    git filter-repo --sensitive-data-removal --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA

    Important

    Wenn die Datei mit vertraulichen Daten in anderen Pfaden vorhanden ist (da sie verschoben oder umbenannt wurde), musst du entweder ein zusätzliches --path-Argument für diese Datei hinzufügen oder diesen Befehl ein zweites Mal ausführen, um den alternativen Pfad zu benennen.

    Wenn du den gesamten Text ersetzen möchtest, der sich in ../passwords.txt in den nicht binären Dateien deines Repositoryverlaufs befindet, führe den folgenden Befehl aus:

    git filter-repo --sensitive-data-removal --replace-text ../passwords.txt

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

  6. Finde heraus, wie viele Pull Requests durch die Neugenerierung des Verlaufs beeinträchtigt werden. Du benötigst diese Informationen unten.

    $ grep -c '^refs/pull/.*/head$' .git/filter-repo/changed-refs
4

    Du kannst -c weglassen, um zu sehen, welche Pull Requests betroffen sind:

    $ grep '^refs/pull/.*/head$' .git/filter-repo/changed-refs
refs/pull/589/head
refs/pull/602/head
refs/pull/604/head
refs/pull/605/head

    Diese Ausgabe enthält die Pull-Request-Nummer zwischen dem zweiten und dritten Schrägstrich. Wenn die Anzahl der betroffenen Pull Requests größer ist als erwartet, kannst du diesen Klon ohne Nachteile verwerfen und entweder das Neugenerieren wiederholen oder das Entfernen vertraulicher Daten abbrechen. Sobald du mit dem nächsten Schritt fortfährst, wird die Neugenerierung unumkehrbar.

  7. Sobald du mit dem Status deines Repositorys zufrieden bist, führe einen erzwungenen Push deiner lokalen Änderungen durch, um dein Repository auf GitHub.com zu überschreiben. Obwohl --force durch --mirror impliziert wird, fügen wir sie unten als Erinnerung ein, dass du die Aktualisierung aller Branches, Tags und Verweise erzwingen musst, und alle Änderungen verworfen werden, die andere möglicherweise an diesen Verweisen vorgenommen haben, während du das Repository bereinigt hast.

    git push --force --mirror origin

    Mit diesem Befehl werden alle Verweise, die mit refs/pull/ beginnen, nicht gepusht, da GitHub diese als schreibgeschützt kennzeichnet. Diese Pushfehler werden im nächsten Abschnitt behandelt. Wenn ein anderer Verweis nicht gepusht wird, ist der Branchschutz wahrscheinlich für diesen Branch aktiviert, und du musst ihn vorübergehend deaktivieren und den Push wiederholen. Wiederhole diesen Vorgang, bis nur noch Aktualisierungsfehler für Verweise, die mit refs/pull/ beginnen, vorhanden sind.

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.

  1. Wende dich an uns über das GitHub-Support-Portal, und gib die folgenden Informationen an:

    • Name des Besitzers und des betroffenen Repositorys (z. B. DEIN-BENUTZERNAME/DEIN-REPOSITORY)
    • Die Anzahl der betroffenen Pull Requests, die im vorherigen Schritt gefunden wurden. Diese wird vom Support verwendet, um nachzuvollziehen, wie viel davon betroffen ist.
    • Der bzw. die von git filter-repo gemeldete(n) erste(n) geänderte(n) Commit(s) (Suche in der Ausgabe nach NOTE: First Changed Commit(s).)
    • Wenn NOTE: There were LFS Objects Orphaned by this rewrite in der git-filter-repo-Ausgabe (direkt nach dem ersten geänderten Commit) angezeigt wird, merke an, dass verwaiste LFS-Objekte vorhanden sind, und lade die benannte Datei ebenfalls in das Ticket hoch.

    Wenn du alle Verweise außer PRs erfolgreich bereinigt hast und keine Forks Verweise auf die vertraulichen Daten haben, ergreift der Support die folgenden Maßnahmen:

    • Dereferenzieren oder Löschen betroffener PRs auf GitHub

    • Ausführen einer Garbage Collection auf dem Server, um die vertraulichen Daten aus dem Speicher zu löschen

    • Entfernen zwischengespeicherter Ansichten

    • Wenn LFS-Objekte beteiligt sind: Löschen und/oder Bereinigen der verwaisten LFS-Objekte

    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 das Rotieren betroffener Anmeldeinformationen verringert werden kann.

  2. Projektmitarbeiter müssen für alle Branches, die sie aus deinem alten (nicht mehr gültigen) Repositoryverlauf erstellt haben, ein Rebase ausführen, keinen Merge. 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. Sie müssen möglicherweise auch zusätzliche Schritte unternehmen. Weitere Informationen findest du unter Make sure other copies are cleaned up: clones of colleagues im git filter-repo-Leitfaden.

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 finden Sie unter Informationen zum Pushschutz.

Weiterführende Themen