Ein Secret aus der Git-Historie entfernen

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

Verwandte Anleitungen

Quellen

• Removing sensitive data from a repository GitHub Docs
• About push protection GitHub Docs
• git-filter-repo GitHub
• BFG Repo-Cleaner Roberto Tyley
• Gitleaks GitHub