Geheimnisse laufen nicht ab, wenn Sie sie löschen: Git-Verlauf bereinigen

Kurz gesagt: Ein offengelegter API-Schlüssel, der in ein Repository übertragen wurde, bleibt noch lange nach dem Löschen der Datei im Verlauf erhalten. Erkennung, Rotation und das Umschreiben des Verlaufs sind gleichermaßen erforderlich — das bloße Löschen vermittelt ein falsches Gefühl von Sicherheit.

Die Falle des Lösch-Commits

Wenn ein Entwickler bemerkt, dass Zugangsdaten übertragen wurden, besteht der erste Impuls darin, die betreffende Zeile zu löschen und eine Korrektur zu pushen. Das Geheimnis befindet sich jedoch weiterhin im Git-Verlauf und kann von jedem mit Zugriff auf einen Klon abgerufen werden. Falls das Repository jemals öffentlich oder gespiegelt war, muss das Geheimnis ab dem Moment, in dem es gepusht wurde, als kompromittiert gelten.

Die einzig sichere Annahme ist, dass ein offengelegtes Geheimnis so lange aktiv bleibt, bis es rotiert wurde.

Die richtige Reihenfolge der Behebung

• Rotieren Sie die Zugangsdaten sofort — behandeln Sie sie als kompromittiert, nicht nur als offengelegt.
• Widerrufen Sie den offengelegten Schlüssel und prüfen Sie, ob er während des Offenlegungszeitraums verwendet wurde.
• Schreiben Sie den Verlauf um, um das Geheimnis aus allen erreichbaren Commits zu entfernen, und erzwingen Sie die Aktualisierung aller Spiegel.
• Fügen Sie eine Geheimnissuche vor dem Commit und in der CI hinzu, damit das nächste Geheimnis erkannt wird, bevor es in das Repository gelangt.

Die Erkennung muss kontinuierlich erfolgen

Die Offenlegung von Geheimnissen erfordert keine einmalige Bereinigung, sondern eine fortlaufende Erkennung. Eine Prüfung ausschließlich zum Commit-Zeitpunkt übersieht Geheimnisse, die auf anderen Wegen gepusht werden, während eine rein rückwirkende Prüfung den Fehler von morgen nicht erkennt. Beides ist wichtig.

Die Scans von KENSAI zeigen offengelegte Zugangsdaten zusammen mit dem Kontext an, der zur Priorisierung der Rotation erforderlich ist — welcher Schlüssel betroffen ist, wo er erreichbar ist und wie dringend die Offenlegung behoben werden muss.

So sieht gute Sicherheitshygiene in der Praxis aus

Behandeln Sie jedes Geheimnis, das jemals in ein Repository gelangt ist, als bereits offengelegt, und gestalten Sie Ihre Systeme so, dass eine solche Offenlegung verkraftbar ist. Kurzlebige, automatisch rotierte Zugangsdaten machen aus einem offengelegten Schlüssel ein Problem, das von selbst abläuft, statt zu einer offenen Tür zu werden, die monatelang offen bleibt.

Verlagern Sie die Erkennung mit Pre-Commit- und Pre-Receive-Hooks nach vorn, die ein Geheimnis blockieren, bevor es überhaupt aufgezeichnet wird, und ergänzen Sie dies durch serverseitige Scans, die alles erfassen, was dennoch durchrutscht. Das Ziel ist keine einmalige Bereinigung, sondern eine dauerhafte Kontrolle, durch die neue Offenlegungen selten und deutlich sichtbar werden und sich schnell widerrufen lassen.

Fazit

Das Löschen eines offengelegten Geheimnisses ist der unwichtigste Schritt. Rotieren Sie es zuerst, bereinigen Sie anschließend den Verlauf und richten Sie eine kontinuierliche Erkennung ein, damit sich Offenlegungszeiträume verkürzen, anstatt sich zu wiederholen.