Ein Secret wurde committet: warum Löschen der Datei nicht reicht und wie die Reihenfolge der Reaktion aussieht

Ziel

Eindämmen von Zugangsdaten, die in ein Repository committet wurden, in der Reihenfolge, die den Schaden begrenzt, auch wenn ein Agent den Commit erstellt hat.

Voraussetzungen

Rechte, die Zugangsdaten beim Aussteller zu widerrufen; Schreibzugriff auf das Repository; Zugriff auf die Nutzungsprotokolle des Ausstellers.

Schritte

1. Zuerst widerrufen oder erneuern. GitHubs Anleitung zum Entfernen sensibler Daten rät, das Secret als kompromittiert zu behandeln und zu erneuern; das Umschreiben der Historie kommt erst danach. Davon ausgehen, dass automatisierte Scanner öffentliche Pushes beobachten.
2. Die Ersatz-Zugangsdaten an jede legitime konsumierende Stelle ausrollen. Konsumierende Stellen, die dadurch ausfallen, zeigen, wo die alten Zugangsdaten verwendet wurden.
3. Die Protokolle des Ausstellers auf Verwendung der alten Zugangsdaten seit dem Commit-Zeitpunkt prüfen, von unerwarteten Adressen oder mit ungewöhnlichen Aktionen. Die Funde festhalten.
4. Die Datei aus dem aktuellen Baum entfernen und, falls sie nie verfolgt werden soll, in .gitignore aufnehmen.
5. Falls das Repository es erfordert, die Historie mit einem dafür gebauten Werkzeug umschreiben; GitHub dokumentiert dafür git-filter-repo. Mit Mitwirkenden abstimmen: jeder Klon muss neu geklont oder rebased werden, und erneut gepushte alte Branches würden das Secret wieder einführen.
6. Den Hosting-Anbieter bitten, zwischengespeicherte Ansichten und Pull-Request-Referenzen zu bereinigen, sofern dessen Prozess das unterstützt; Forks und bestehende Klone bleiben ausserhalb der eigenen Kontrolle.
7. CI-Protokolle, Build-Artefakte, Container-Images und Chatnachrichten durchsuchen, die den Wert möglicherweise erfasst haben.
8. Einen Pre-Commit- oder Push-Zeit-Secret-Scanner einführen, um ein Wiederauftreten zu verhindern, und den Vorfall mit Zeitangaben dokumentieren.

Erwartetes Ergebnis

Der offengelegte Wert ist nutzlos, bevor die Bereinigung beginnt; die Historie ist dort bereinigt, wo es zählt; es ist bekannt, ob die Zugangsdaten verwendet wurden.

Grenzen und Prüfbasis

Das Umschreiben der Historie kann bereits erstellte Kopien nicht zurückholen; der Widerruf ist der einzige Schritt, der sie neutralisiert. Manche Secrets (Signaturschlüssel, langlebige Zertifikate) erfordern eine Neuausstellung und eine erneute Verteilung von Vertrauen, was länger dauert als das Erneuern eines API-Schlüssels.