Diese Version von GitHub Enterprise Server wird eingestellt am 2026-03-17. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Entfernen vertraulicher Daten aus einem Repository

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

In diesem Artikel

Wie man vertrauliche Daten aus einem Repository entfernt

Wenn du den Verlauf deines Repositorys mithilfe von Tools wie git-filter-repo änderst, ist die Kenntnis über die Auswirkungen wichtig. Das Umschreiben der Geschichte erfordert eine sorgfältige Koordination mit Kollegen und hat eine Reihe von Nebenwirkungen, die verwaltet 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 der Schlüssel widerrufen oder rotiert wurde, kann er nicht mehr für den Zugriff verwendet werden, und das könnte ausreichen, um Ihr Problem zu lösen. Das Durchlaufen der zusätzlichen Schritte, um die Historie neu zu schreiben und das Geheimnis zu entfernen, ist möglicherweise nicht erforderlich.

Nebenwirkungen des Neuschreibens der Geschichte

Es gibt zahlreiche Nebenwirkungen beim Umschreiben der Geschichte. 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 einen Klon von vor Ihrer Überarbeitung hat und nach der Überarbeitung einfach `git pull` gefolgt von `git push` ausführt, werden die vertraulichen Daten angezeigt.  Dieser muss entweder seinen Klon verwerfen und erneut klonen oder sorgfältig mehrere Schritte durchlaufen, um den Klon zuerst 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**: Das Neuschreiben der Historie wird die Hashes der Commits, die die vertraulichen Daten eingeführt haben, _und_ alle nachfolgenden Commits ändern.  Alle Tools oder Automatisierungen, die darauf angewiesen sind, dass sich Commit-Hashes nicht ändern, werden nicht funktionieren oder auf Probleme stoßen.

  •        **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**: Das Entfernen der vertraulichen Daten macht es erforderlich, die internen Verweise zu entfernen, die zum Anzeigen der Diff-Ansicht in Pull Requests verwendet werden. Dadurch werden diese Diffs nicht mehr angezeigt.  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` auch die Commit-Signaturen und Tag-Signaturen von Commits, die vor dem Entfernen der vertraulichen Daten erstellt wurden.  (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 der Koordination erfordert. Zudem bedeutet es, dass bei Änderungen des Verlaufs informierte Benutzer mit einem vorhandenen Klon die Divergenz im Verlauf bemerken und diese nutzen können, um die sensiblen Daten, die du aus dem zentralen Repository entfernt hast, dennoch schnell und einfach in ihrem Klon zu finden.

Informationen zur Offenlegung vertraulicher Daten

Das Entfernen vertraulicher Daten aus einem Repository umfasst vier allgemeine Schritte:

  • Lokales Umschreiben des Repositorys mit git-filter-repo
  • Aktualisieren Sie das Repository auf GitHub, indem Sie Ihre lokal umgeschriebene Historie verwenden.
  • Koordination mit Kollegen zum Bereinigen weiterer vorhandener Klone
  • Verhindern von Wiederholungen und Vermeiden zukünftiger Lecks vertraulicher Daten

Wenn Sie Ihren Verlauf lediglich neu schreiben und einen Push erzwingen, können die Commits mit vertraulichen Daten möglicherweise noch an anderer Stelle zugänglich sein.

  • In allen Klonen oder Forks Ihres Repositorys
  • Direkt über ihre SHA-1-Hashes in zwischengespeicherten Ansichten auf GitHub
  • Durch beliebige Pull Requests, die darauf verweisen

Du kannst vertrauliche Daten nicht aus den Klonen anderer Benutzer von deinem Repository entfernen. Stattdessen musst du ihnen die Anweisungen aus dem Kapitel Stelle sicher, dass andere Kopien bereinigt werden: Klone von Kollegen 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 Ihrer Websiteadministratoren kontaktierst.

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ücksichtigen Sie diese Einschränkungen und Herausforderungen bei Ihrer Entscheidung, den Verlauf Ihres Repositorys neu zu schreiben.

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://HOSTNAME/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

    Wichtig

    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 in nicht-binären Dateien deines Repository-Verlaufs enthaltenen Text ersetzen möchtest, der in ../passwords.txt aufgelistet ist, führe den folgenden Befehl aus:

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

  5. Stelle sicher, dass du alles, was du aus dem Repository-Verlauf entfernen wolltest, tatsächlich entfernt hast.

  6. Finde heraus, wie viele Pull Requests durch das Umschreiben der Historie 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 Umschreibung unumkehrbar.

  7. Sobald du mit dem Status deines Repositorys zufrieden bist, führe einen erzwungenen Push deiner lokalen Änderungen durch, um dein Repository auf Ihre GitHub Enterprise Server-Instance zu überschreiben. Obwohl --force durch --mirror impliziert wird, fügen wir es unten als Erinnerung ein, dass du zwangsweise alle Branches, Tags und Refs aktualisierst und dabei alle Änderungen verwerfen wirst, die andere möglicherweise an diesen Refs vorgenommen haben, während du das Repository bereinigt hast.

    git push --force --mirror origin

    Der Befehl schlägt fehl, wenn er versucht, Verweise zu pushen, die mit refs/pull/ beginnen, da GitHub diese als schreibgeschützt kennzeichnet. Diese Pushfehler werden im nächsten Abschnitt behandelt. Wenn ein anderer Verweis nicht gepusht wird, haben Sie den Schutz für diese Verzweigung vermutlich aktiviert. Sie müssen ihn vorübergehend deaktivieren und den Push wiederholen. Wiederholen Sie den Vorgang, bis nur noch Aktualisierungsfehler bei Referenzen auftreten, die mit refs/pull/ beginnen.

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 Ihrer Websiteadministratoren, 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. Das wird von deiner Websiteadministration verwendet, damit du weißt, wie viel 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 First Changed Commit) erscheint, vermerken Sie, dass LFS-Objekte verwaist sind, und laden Sie 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 enthalten, wird deine Websiteadministration folgendermaßen handeln:

    • 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 involviert sind: Löschen und/oder bereinigen Sie die verwaisten LFS-Objekte

    Weitere Informationen dazu, wie Siteadministratoren nicht erreichbare Git-Objekte entfernen können, findest du unter Befehlszeilenwerkzeuge. Weitere Informationen dazu, wie Website-Administratoren erreichbare Commits identifizieren können, findest du unter Identifizieren erreichbarer Commits.

  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 finden Sie unter Stellen Sie sicher, dass andere Kopien bereinigt werden: Klone von Kollegen im git-filter-repo-Leitfaden.

Das 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 irgendeiner Stelleverhindert, dass die Garbage Collection 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 von der Garbage Collection erfolgreich entfernt werden 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-Anforderungen müssen gelöscht werden, damit der Commit von der Garbage Collection bereinigt werden kann. 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

Die vertraulichen Daten können aus den Verzweigungen eines Repositorys entfernt werden, indem sie in den Klon eines Repositorys übertragen werden, aus dem bereinigten Repository abgerufen werden, und anschließend erneut ein Rebase aller Verzweigungen und Tags ausgeführt wird, die zusätzlich zur/m relevanten Verzweigung oder Tag die vertraulichen Daten aus dem bereinigten Repository enthalten. Alternativ können die Forks vollständig gelöscht werden, und bei Bedarf kann das Repository nach Abschluss der Bereinigung des ursprünglichen Repositorys erneut geforkt werden.

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

Wenn es keine Ergebnisse von einem der ref-contains Befehle gibt, können Sie die Garbage Collection 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.

Es gibt einige Maßnahmen, mit denen vermieden werden kann, dass für Dinge Commits oder Push-Vorgänge durchgeführt werden, die nicht offengelegt 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 vertraulicher Informationen im Code. Verwenden Sie Umgebungsvariablen oder Geheimverwaltungsdienste wie Azure Key Vault, AWS Secrets Manager oder HashiCorp Vault, um geheime Schlüssel zur Laufzeit zu verwalten und einzugeben.
  • 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. (Fordern Sie alle Mitwirkenden auf, den von Ihnen 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 in der Befehlszeile – verwende stattdessen git add filename und git rm filename, um die Dateien einzeln zu stagen.
  • 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 Push-Schutz für Ihr Repository, um zu erkennen und zu verhindern, dass Push-Vorgänge mit hardcodierten Geheimnissen in Ihre Codebasis übernommen werden. Weitere Informationen finden Sie unter Informationen zum Pushschutz.

Weiterführende Lektüre

  •         [
        `git-filter-repo`-Hauptseite](https://htmlpreview.github.io/?https://github.com/newren/git-filter-repo/blob/docs/html/git-filter-repo.html), insbesondere der Unterabschnitt „Sensitive Data Removal“ von „DISCUSSION“.

  •         [Pro Git: Git-Tools – Umschreiben der Historie](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)

  •         [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)