Warum Git Log Geheimnisse preisgibt, selbst nachdem sie „gelöscht“ wurden
Löschen einer Zeile aus einer Datei und commitDurch die Änderung werden die sensiblen Daten nicht wirklich aus Ihrem Repository entfernt. Wenn dieses Geheimnis, ein API-Schlüssel, eine Anmeldeinformation oder ein Token, jemals committed, es lebt in Ihrem Git-Verlauf. Jeder, der git log -p, Git Showoder das Untersuchen von Unterschieden aus der Vergangenheit commits kann es immer noch abrufen.
Auch wenn Sie eine Datei überschreiben oder den Wert ersetzen, Git Protokoll behält die vollständige Herkunft jeder Änderung bei. Dies ist beabsichtigt. Das gesamte Modell von Git basiert auf unveränderlichen commit Verlauf und verteilte Kopien. Sofern Sie den Verlauf nicht explizit neu schreiben, sind Ihre Geheimnisse immer noch vorhanden. Hier ist ein praktischer Fall:
⚠️ Lehrreiches Beispiel, nicht in der Produktion ausführen
Zu spät. Die Git Protokoll zeigt immer noch diesen Schlüssel in der ersten commit.
Missverständnisse rund um Git Stash und Git Rebase
Viele Entwickler gehen davon aus Git Stash hilft, Geheimnisse zu verbergen oder zu bereinigen. Stimmt nicht. Git Stash nur Regale Arbeitsverzeichnis ändert sich vorübergehend; es berührt nie commit Geschichte. Wenn ein Geheimnis jemals committed, das anschließende Speichern von Änderungen trägt nicht zur Bereinigung bei.
Wie wäre es mit Git Rebase? Obwohl es die Geschichte neu schreiben kann, muss es vorher geschehencisely. Einfach laufen git rebase -i und Neuordnung oder Zusammenquetschen commits entfernt keine Geheimnisse, es sei denn, Sie bearbeiten oder löschen sie explizit. Und wenn auch nur ein Klon oder Fork mit dem Original existiert commits, dein Geheimnis lebt weiter.
Schlimmer noch: Durch ein Rebasing ohne korrektes Force-Pushing oder eine erneute Abstimmung mit Mitarbeitern können die offengelegten Anmeldeinformationen durch Zusammenführungen erneut eingeführt werden.
⚠️ Lehrbeispiel, nicht in realen Umgebungen verwenden
⚠️ Lehrreiches Beispiel, nicht auf Produktions-Repos ausführen
Bearbeiten Sie das commit enthält das Geheimnis, aber vergessen Sie, es zu entfernen. Ihre Git Protokoll könnte aussehen sauberer, aber der vertrauliche Inhalt ist immer noch wiederherstellbar.
Reale Risiken durch vergessene Anmeldeinformationen im Git-Verlauf
Dies ist nicht theoretisch. Angreifer scannen aktiv öffentliche und private Repos nach Geheimnissen, die sich in commit Historien. GitHub-Forks, Mirror-Repos und zwischengespeicherte CI/CD pipelines können alle diese vergessenen Token beherbergen.
- Ein durchgesickerter API-Schlüssel von einem alten Git Protokoll führte bei einem Startup zu Cloud-Abrechnungen in Höhe von Tausenden.
- OAuth-Token committed, dann „gelöscht“, wurden verwendet, um Benutzerkonten zu kapern.
- Tief in Forks von Open-Source-Projekten vergrabene Geheimnisse lösten schwerwiegende Sicherheitsvorfälle aus.
Diese Probleme skalieren in CI/CDJeder Job, der ein Repo klont, läuft Git Protokoll unter der Haube, und jedes Build-Artefakt kann potenziell Spuren von offengelegten Geheimnissen enthalten.
Bereinigen sensibler Daten mit git filter-repo
Wenn der Schaden bereits entstanden ist, ist das zuverlässigste Werkzeug zur Reinigung Git Filter-Repo. nicht wie Git Rebase, die umschreibt individuelle commits, Git Filter-Repo kann das gesamte commit Verlauf basierend auf Dateipfaden, Mustern oder Inhalten.
Beispiel: Um alle Vorkommen von config.json die Geheimnisse enthalten könnten:
⚠️ Lehrreiches Beispiel, überprüfen Sie es in einem Test-Repo, bevor Sie es in der Produktion verwenden
Oder um alle zu entfernen commits, die eine bestimmte Zeichenfolge enthalten (z. B. AWS_SECRET_ACCESS_KEY):
⚠️ Lehrreiches Beispiel, überprüfen Sie es in einem Test-Repo, bevor Sie es in der Produktion verwenden
Seien Sie vorsichtig: Dies wird umschreiben commit Hashes. Sie müssen alle Mitarbeiter erzwingen und informieren. Alle Automatisierungs- oder Bereitstellungsschlüssel, die an commit Hashes werden unterbrochen.
Auch Werkzeuge wie BFG Repo-Reiniger bieten ähnliche Möglichkeiten, sind aber weniger flexibel und gelten bei komplexen Fällen mittlerweile als veraltet.
Verhindern von Geheimlecks, bevor sie Git erreichen
Vorbeugen ist besser als Aufräumen. So verhindern Sie, dass Geheimnisse jemals ans Licht kommen Git Protokoll:
1. Pre-commit Hooks
Verwenden Sie Werkzeuge wie pre-commit, Gitleaksden Talisman nach Geheimnissen zu suchen, bevor commits:
2. CI/CD Pipeline aktionen
Integrieren geheime Erkennung in Ihre CI-Jobs. Builds schlagen fehl, wenn Geheimnisse gefunden werden. Machen Sie dies zu einer Richtlinie.
3. Geheimnisverwaltung
Codieren Sie Anmeldeinformationen niemals fest. Verwenden Sie vom ersten Tag an Umgebungsvariablen, Tresore oder geheime Manager.
4. Abhängigkeiten prüfen
Vertrauen Sie Paketen von Drittanbietern nicht blind. Geheimnisse können durchsickern durch npm-, PyPI- oder Docker-Ebenen.
Letzter Fix: Geheimnisse mit Git-Filter-Repo bereinigen
Das Löschen von Geheimnissen aus dem Code reicht nicht aus. Git Protokoll behält eine vollständige Aufzeichnung, es sei denn, Sie ergreifen gezielte Maßnahmen, um die Geschichte neu zu schreiben. Verlassen Sie sich nicht auf Git Stash oder halbgar Git Rebase Versuche. Verwenden Git Filter-Repo wenn Sie eine gründliche Bereinigung benötigen und Richtlinien und Scans durchsetzen müssen, bevor Geheimnisse überhaupt in Ihr Repository gelangen.
Zur proaktiven Erkennung geheimer Informationen sollten Sie Tools wie Xygeni um Ihre zu sichern pipelines, durchsetzen commit Hygiene und verhindern Sie kostspielige Lecks, bevor sie an die Oberfläche kommen. Git vergisst nie, aber Sie können sicherstellen, dass es sich gar nicht erst an Ihre Geheimnisse erinnert.
