--- title: "Secrets mit git filter-repo aus der Git-Historie entfernen" description: "Schlüssel oder Passwort committet? Erst widerrufen, dann mit git-filter-repo aus der Git-Historie entfernen, GitHub bereinigen, neue Lecks verhindern." url: https://example-petstore.com/de/guides/remove-secrets-from-git language: de --- # Ein Secret aus der Git-Historie entfernen Ein Schlüssel, ein Token oder ein Passwort ist in einem Commit gelandet. Die Datei in einem neuen Commit zu löschen, hilft nicht: Der alte Commit enthält sie weiterhin, in jedem Clone und jedem Fork. Diese Anleitung zeigt die richtige Reihenfolge: zuerst widerrufen, dann die Historie umschreiben, die Hosting-Plattform bereinigen und dafür sorgen, dass es nicht wieder passiert. ## Zuerst: das Secret widerrufen Betrachten Sie ein committetes Secret als offengelegt, auch in einem privaten Repository: Clones, Forks, CI-Logs und Backups können bereits eine Kopie enthalten, und automatisierte Scanner erfassen neue Commits in öffentlichen Repositorys innerhalb von Minuten. 1. Widerrufen oder erneuern Sie den Schlüssel, das Token oder das Passwort bei dem Dienst, der es ausgestellt hat. 2. Legen Sie die neuen Zugangsdaten in der Konfiguration oder einem Secrets Manager ab, nicht im Code. 3. Prüfen Sie die Logs des Dienstes auf Nutzung, die Sie nicht zuordnen können. Wo Sie Schlüssel bei gängigen Anbietern widerrufen: [Offengelegte Zugangsdaten: was jetzt zu tun ist](https://example-petstore.com/de/guides/leaked-credentials). Das Umschreiben der Historie kommt danach, niemals stattdessen. ## Historie umschreiben oder nicht Ein widerrufenes Secret gewährt keinen Zugriff mehr, und laut GitHub kann das genügen. Das Umschreiben lohnt sich trotzdem, wenn: - sich das Secret nicht widerrufen lässt oder die Datei weitere sensible Daten enthält, etwa personenbezogene Daten oder Kundendaten; - das Repository öffentlich ist oder öffentlich werden soll; - Scanner das alte Secret nicht länger melden sollen. Das Umschreiben ändert die ID jedes späteren Commits. Alle Beteiligten müssen ihre Arbeit rebasen, offene Pull Requests können ihre Review-Kommentare verlieren, und Commit-Signaturen werden entfernt. Stimmen Sie einen Zeitpunkt mit allen Beteiligten ab, und mergen oder schließen Sie offene Pull Requests vorher. ## Jedes Vorkommen finden ``` # Welche Commits haben die Zeichenfolge hinzugefügt oder entfernt? git log --all --oneline -S 'the-secret-value' # In welchen Dateien kam sie vor? git grep 'the-secret-value' $(git rev-list --all) # Die gesamte Historie nach bekannten Secret-Formaten durchsuchen gitleaks git -v ``` Notieren Sie jeden Dateipfad, unter dem das Secret vorkam, auch frühere Namen, falls die Datei verschoben oder umbenannt wurde. ## Umschreiben mit git-filter-repo `git-filter-repo` ist das Werkzeug, das GitHub empfiehlt. Verwenden Sie Version 2.47 oder neuer, die die Option `--sensitive-data-removal` bietet, und arbeiten Sie in einem frischen Clone. ``` # Installieren (oder den Paketmanager verwenden) brew install git-filter-repo # macOS pip install git-filter-repo # überall mit Python git clone https://github.com/YOUR-ORG/YOUR-REPO cd YOUR-REPO # Option 1: eine ganze Datei aus der gesamten Historie entfernen git-filter-repo --sensitive-data-removal --invert-paths --path config/secrets.yml # Option 2: das Secret überall ersetzen, wo es vorkommt git-filter-repo --sensitive-data-removal --replace-text ../replacements.txt ``` Die Ersetzungsdatei enthält einen Wert pro Zeile. Standardmäßig wird jeder Treffer zu `***REMOVED***`; mit `==>` legen Sie die Ersetzung selbst fest, und `regex:` sucht nach einem Muster: ``` # ../replacements.txt (außerhalb des Repositorys) sk_live_51Hx0000000000000000000000 AKIA0000000000000000==>AWS_ACCESS_KEY_ID_REMOVED regex:password\s*=\s*"[^"]+"==>password = "REMOVED" ``` Prüfen Sie das Ergebnis mit `git log --all -S 'the-secret-value'`: Der Befehl sollte nichts ausgeben. Überschreiben Sie danach das Remote: ``` git push --force --mirror origin ``` Ein Branch-Schutz, der Force-Pushes blockiert, muss dafür vorübergehend deaktiviert werden. Nach dem Push lässt sich das Umschreiben nicht mehr rückgängig machen. ## GitHub bereinigen Nach dem Force-Push sind alte Commits weiterhin über Pull Requests, zwischengespeicherte Ansichten und Forks erreichbar. - **Pull Requests und zwischengespeicherte Ansichten:** Wenden Sie sich an den GitHub Support und nennen Sie die Anzahl der betroffenen Pull Requests (`grep -c '^refs/pull/.*/head$' .git/filter-repo/changed-refs`) sowie die „First Changed Commit(s)“, die git-filter-repo ausgegeben hat. GitHub hilft nur, wenn das Rotieren der Zugangsdaten das Risiko nicht beseitigen kann. - **Forks:** Commits in Forks bleiben dort erhalten. Bitten Sie die Eigentümer, den Fork zu löschen oder zu bereinigen; GitHub gibt deren Kontaktdaten nicht weiter. - **Clones von Kolleginnen und Kollegen:** Alle müssen ihre Branches auf die neue Historie rebasen, nicht mergen. Ein einziger Merge holt die alten Commits zurück. Auf GitLab, Bitbucket oder einem selbst gehosteten Server sind die Schritte ähnlich; in der Dokumentation der jeweiligen Plattform steht, wie sie alte Objekte und zwischengespeicherte Ansichten entfernt. ## Alternative: BFG BFG Repo-Cleaner ist ein älteres, Java-basiertes Werkzeug, das noch immer verbreitet ist. Es arbeitet mit einem Mirror-Clone und lässt standardmäßig den neuesten Commit unverändert. Entfernen Sie das Secret daher zuerst in einem normalen Commit aus der aktuellen Version. ``` git clone --mirror https://github.com/YOUR-ORG/YOUR-REPO.git java -jar bfg.jar --replace-text replacements.txt YOUR-REPO.git cd YOUR-REPO.git git reflog expire --expire=now --all && git gc --prune=now --aggressive git push ``` ## Das nächste Leck verhindern - **Push Protection:** Auf GitHub blockiert Secret Scanning mit Push Protection einen Push, der ein bekanntes Secret-Format enthält, bevor er das Repository erreicht. - **Eine Prüfung vor jedem Commit:** Führen Sie gitleaks oder git-secrets als Pre-Commit-Hook aus, und in der CI für alle, die ihn überspringen. - **Konfiguration statt Code:** Lesen Sie Secrets aus Umgebungsvariablen oder einem Secrets Manager, und tragen Sie `.env` und ähnliche Dateien vor dem ersten Commit in `.gitignore` ein. - **Vor dem Commit hinsehen:** Stagen Sie Dateien einzeln und prüfen Sie `git diff --cached`, statt `git add .` oder `git commit -a` zu verwenden. Ging dieser Schlüssel außerdem an eine Platzhalteradresse wie api.example-petstore.com? Dann hat er auch einen Server erreicht, den Sie nicht kontrollieren: [API-Clients und SDKs konfigurieren](https://example-petstore.com/de/guides/api-base-url). ## Verwandte Anleitungen ### [Offengelegte Zugangsdaten: was jetzt zu tun ist](https://example-petstore.com/de/guides/leaked-credentials) Schlüssel, Tokens oder Passwörter wurden an eine Beispieldomain gesendet. Widerrufen und ersetzen Sie sie – mit direkten Links zu den Widerrufsseiten gängiger Anbieter. ### [API-Clients und SDKs konfigurieren](https://example-petstore.com/de/guides/api-base-url) Halten Sie Basis-URLs aus dem Code heraus, lassen Sie sie auf den echten Dienst verweisen und fügen Sie eine Prüfung hinzu, die verhindert, dass Beispieladressen in die Produktion gelangen. ## Quellen - [Removing sensitive data from a repository](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository) GitHub Docs - [About push protection](https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection) GitHub Docs - [git-filter-repo](https://github.com/newren/git-filter-repo) GitHub - [BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/) Roberto Tyley - [Gitleaks](https://github.com/gitleaks/gitleaks) GitHub