Eingecheckte Secret-Dateien

Was ist Eingecheckte Secret-Dateien?

Ein einzelnes fest im Quellcode hinterlegtes Secret ist ein Problem; eine ganze Datei voller Secrets einzuchecken ist schlimmer. Ohne .gitignore kann ein Repository .env-Dateien, private Schlüssel und JSON-Dateien mit Service-Account-Zugangsdaten schon ab dem ersten Commit erfassen, und jeder Klon trägt eine Kopie dieser Historie. Sie klonen ein öffentliches Repository, lesen die eingecheckte .env-Datei und greifen auf eine aktive Staging-Umgebung zu. Danach nehmen Sie die Dateien mit git rm --cached aus der Versionskontrolle, widerrufen den geleakten API-Schlüssel und stellen einen neuen aus, ergänzen eine .gitignore und committen eine Pre-Commit-Konfiguration, die Secret-Dateinamen blockiert, sobald jeder Entwickler sie installiert.

Was Sie lernen in Eingecheckte Secret-Dateien

• Erkennen, dass eine fehlende oder unvollständige .gitignore dazu führt, dass eine komplette Secret-Datei — eine .env, ein privater Schlüssel oder eine Service-Account-JSON — schon mit dem ersten Commit eingecheckt und erfasst wird
• Verstehen, warum jeder Klon eines öffentlichen Repos eine Kopie einer erfassten Secret-Datei enthält und sich die Offenlegung deshalb nicht durch späteres Löschen der Datei rückgängig machen lässt
• Das Einchecken einer Secret-DATEI unter Versionskontrolle von einem fest im Quellcode hinterlegten Secret unterscheiden — und wissen, dass beides nicht ins Repo gehört
• Die Aufräumarbeiten durchführen: die Dateien mit git rm --cached aus der Versionskontrolle nehmen und die offengelegten Schlüssel rotieren, weil jedes gepushte Secret als kompromittiert gilt
• Eine Wiederholung verhindern — mit einer .gitignore, die Secret-Dateien abdeckt, plus einem Pre-Commit-Hook, der bekannte Secret-Dateinamen blockiert, bevor sie eingecheckt werden; der Hook ist in jedem Klon installiert und durch serverseitigen Push-Schutz abgesichert

Eingecheckte Secret-Dateien — Trainingsschritte

1. Das Ziel auskundschaften

   Heute hat Bob Tavonn im Visier, ein Startup für Zahlungsintegrationen, das einen Teil seines Codes offen veröffentlicht. Er beginnt beim öffentlichen Repository und verschafft sich einen Überblick darüber, womit das Unternehmen arbeitet, bevor er nach einem Einstieg sucht. Ein öffentliches Repo ist ein Geschenk für jemanden wie Bob: das ganze Projekt, jede einzelne Datei, mit einem einzigen Befehl herunterladbar.

2. Das Repo klonen

   Bob klont das Repository auf seinen eigenen Rechner, um jede erfasste Datei offline und in aller Ruhe zu lesen. Alles, was das Repo erfasst, kommt beim Klonen mit. Wurde jemals eine Secret-Datei eingecheckt, liegt sie in der Kopie, die er sich gerade geholt hat.

3. Die erfassten Dateien auflisten

   Bob lässt sich auflisten, was das Repository alles erfasst. Ihn interessiert nicht, was auf der Festplatte liegt, sondern welche Dateien tatsächlich unter Versionskontrolle stehen — denn genau die trägt jeder Klon mit sich.

4. Die Secret-Datei lesen

   Bob öffnet die eingecheckte Umgebungsdatei. Anders als bei einem einzelnen fest im Code hinterlegten Schlüssel ist hier nicht nur ein Wert in eine Codezeile kopiert worden, sondern eine ganze Datei voller Secrets steht unter Versionskontrolle. Alles, was der Service für den Betrieb braucht, steht hier im Klartext.

5. Die Staging-Umgebung erreichen

   Ein geleakter Schlüssel bleibt Theorie, solange er nichts öffnet. Aus dem Klon hat Bob bereits alles beisammen: Die eingecheckte .env liefert ihm die Basis-URL der API in PUBLIC_API_URL und einen aktiven Schlüssel, und die mitgeklonten Routen in src/routes/payments.js definieren den Zahlungs-Feed unter /v1/transactions . Er baut die Anfrage zusammen und übergibt den Schlüssel in einem Authorization-Header, genau wie es ein echter Client täte. Geheim waren die Endpunkte nie — sie stehen im öffentlichen Quellcode. Der Schlüssel war es, und genau den hat ihm die eingecheckte Datei in die Hand gedrückt; der Server hat also keinen Grund, die Anfrage abzulehnen.

6. Die Zahlungsdaten liegen offen

   Der Server hat dem Schlüssel vertraut und geantwortet. Bob liest Tavonns Zahlungsdatensätze aus der Staging-Umgebung — von außerhalb des Unternehmens und ohne ein eigenes Konto.

7. Wissenscheck

8. Der Alarm trifft ein

   Sie verantworten Tavonns Repo payments-service. Über Nacht hat der Secret-Scanner des Sicherheitsteams das öffentliche Repository gemeldet und Ihnen eine E-Mail geschickt. Der Befund ist eindeutig: Im öffentlichen Repo liegt eine eingecheckte .env -Datei mit aktiven Schlüsseln. Eine .gitignore , die solche Dateien ausschließt, fehlt.

9. Erfasst, ganz ohne .gitignore

   Prüfen Sie zuerst selbst, welche Dateien Git im Repo erfasst: Die .env -Datei und der Service-Account-Schlüssel stehen unter Versionskontrolle. Eine .gitignore fehlt in der Liste. Eine Datei auf der Festplatte ist das eine. Eine von Git erfasste Datei steht in der Commit-Historie und liegt in jedem Klon.

10. Die Secret-Dateien aus der Versionskontrolle nehmen

    Mit git rm --cached sorgen Sie dafür, dass Git die Secret-Dateien nicht mehr erfasst: Der Befehl nimmt sie aus dem Index, lässt sie aber auf der Festplatte liegen, damit der Service lokal weiterläuft. Sie committen und pushen die Änderung, und die Dateien verschwinden aus dem aktuellen Repo. Das fühlt sich nach der Lösung an. Sie ist es nicht — warum, zeigt der nächste Schritt.