So heben Sie die Freigabe sensibler Dateien von Git auf

Stellen Sie Dateien bereit, fügen Sie eine Commit-Nachricht hinzu und drücken Sie. Nein - warte! Nicht diese Datei. Und jetzt müssen wir anfangen zu googeln.

Jeder Entwickler hat in der Vergangenheit versehentlich vertrauliche Dateien festgeschrieben. Wie können wir die Situation beheben und sicherstellen, dass sie nicht erneut auftritt?

In diesem Artikel werde ich erklären, was zu tun ist, wenn Sie versehentlich eine vertrauliche Datei festschreiben, und die erforderlichen Git-Befehle zum Anpassen des Verlaufs einschließen.

Schadenskontrolle

Sie haben also versehentlich eine vertrauliche Datei festgeschrieben. Nennen wir es .env . Es sind zwei wichtige Fragen zu beantworten:

  • Haben Sie das Commit in ein Remote-Repository verschoben?
  • Ist das Remote-Repository öffentlich?

Noch nicht geschoben

Wenn Sie noch nicht gepusht haben, ist die Situation überhaupt nicht kritisch. Sie können zu einem vorherigen Commit zurückkehren :

git reset HEAD^ --soft 

Ihre Dateien bleiben in der Arbeitskopie, damit Sie die vertraulichen Dateien / Informationen reparieren können. Wenn Sie das Commit beibehalten und nur die vertrauliche Datei entfernen möchten, gehen Sie wie folgt vor :

git rm .env --cached git commit --amend 

Sie können das --amendnur beim letzten Festschreiben verwenden. Wenn Sie zusätzlich eine Reihe von Commits hinzugefügt haben, verwenden Sie:

git rebase -i HEAD~{how many commits to go back?} 

Auf diese Weise können Sie das fehlerhafte Commit beheben und alle verbleibenden Commits nach dem Fix wiedergeben, damit Sie sie nicht verlieren.

Schon geschoben

Wenn Sie gepusht haben, gibt es einen wichtigen Unterschied zwischen öffentlichen und privaten Repositories.

Wenn Ihr Repository privat ist und keine Bots oder Personen vorhanden sind, denen Sie beim Zugriff nicht vertrauen, können Sie das letzte Commit mit den beiden obigen Befehlen problemlos ändern.

Wenn Sie eine Reihe von Commits über das problematische verschoben haben, können Sie weiterhin die Filterdatei oder den BFG-Repo-Cleaner verwenden, um die vertrauliche Datei aus dem Git-Verlauf zu entfernen :

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all 

Beachten Sie jedoch zwei wichtige Aspekte dieser Änderungen:

  • Sie ändern tatsächlich die Geschichte

    Wenn andere Personen, andere Zweige, andere Gabeln oder offene Pull-Anforderungen vorhanden sind, die vom aktuellen Status des Repositorys abhängen, werden Sie diese unterbrechen. Behandeln Sie in diesen Fällen das Repository so, als wäre es öffentlich, und vermeiden Sie es, den Verlauf zu ändern.

  • Sie müssen den Cache leeren

    Sie müssen sich immer an den Support Ihres Git-Speicheranbieters wenden und ihn bitten, den Cache Ihres Repositorys zu leeren. Obwohl Sie das problematische Festschreiben behoben oder den Verlauf neu geschrieben haben, bleibt das alte Festschreiben mit der vertraulichen Datei im Cache. Sie müssen die ID kennen, um darauf zugreifen zu können, aber es ist immer noch verfügbar, bis Sie den Cache leeren.

Muss ich Schlüssel neu generieren, wenn sie in ein öffentliches Repository verschoben werden?

Kurz gesagt, ja. Wenn Ihr Repository öffentlich ist oder Sie aus irgendeinem anderen Grund nicht glauben, dass es ein sicherer Ort ist, müssen Sie die vertraulichen Informationen als gefährdet betrachten.

Selbst wenn Sie die Daten aus Ihrem Repository entfernen, können Sie nichts gegen Bots und andere Gabeln des Repos unternehmen. Was sind die nächsten Schritte?

  • Deaktivieren Sie alle Schlüssel und / oder Passwörter

    Tun Sie dies als ersten Schritt. Sobald Sie die Tasten deaktivieren, werden vertrauliche Informationen unbrauchbar.

  • Gitignore einstellen

    Fügen Sie alle vertraulichen Dateien zu .gitignore hinzu, um sicherzustellen, dass git sie nicht verfolgt.

  • Entfernen Sie die vertrauliche Datei
  • Legen Sie das Update mit einer aussagekräftigen Erklärung fest

    Versuchen Sie nicht, den Fehler zu verbergen. Andere Mitarbeiter und Sie in einem Monat werden die Erklärung zu schätzen wissen, was passiert ist und was durch dieses Commit behoben wird.

Best Practices beim Speichern vertraulicher Daten in Git

Um eine solche Situation in Zukunft zu vermeiden, finden Sie hier einige Tipps zum Speichern sensibler Daten:

Bewahren Sie vertrauliche Daten in einer ENV-Datei (oder einer ähnlichen Datei auf anderen Plattformen) auf.

Bewahren Sie API-Schlüssel und andere vertrauliche Daten in einer einzigen ENV-Datei auf. Auf diese Weise legen Sie nicht versehentlich einen neuen Schlüssel fest, wenn die .env-Datei bereits von git ausgeschlossen ist.

Ein weiterer großer Vorteil ist, dass Sie über eine globale Prozessvariable auf alle Schlüssel zugreifen können.

Verwenden Sie nach Möglichkeit API-Schlüssel

API-Schlüssel lassen sich leicht generieren und deaktivieren, wenn sie kompromittiert werden. Verwenden Sie sie nach Möglichkeit und vermeiden Sie die Verwendung von Anmeldeinformationen / Kennwörtern.

Fügen Sie Ihrem Build-Tool API-Schlüssel hinzu

API-Schlüssel werden normalerweise während der Anwendungserstellung benötigt. Mit Build-Tools wie Netlify können Sie diese Schlüssel in den sicheren Bereichen ihrer Verwaltung hinzufügen. Diese Schlüssel werden automatisch über die globale Prozessvariable in Ihre App eingefügt.

Fügen Sie dem Gitignore eine ENV-Datei hinzu

Stellen Sie sicher, dass Git keine Dateien mit vertraulichen Informationen verfolgt.

Geben Sie die Datei .env.template an

Die Vorlagendatei weist andere Mitarbeiter an, die erforderlichen API-Schlüssel hinzuzufügen, ohne dass sie lange Dokumente lesen müssen.

Ändern Sie den Verlauf auf der Fernbedienung nicht

Verwenden Sie dies als Faustregel. Wenn Sie die oben genannten Regeln befolgt haben, müssen Sie den Verlauf nicht ändern.

Ich hoffe, diese Informationen haben Ihnen geholfen, auf der sicheren Seite zu bleiben. Haben Sie eine persönliche Erfahrung mit unverbindlichem Engagement oder vielleicht eine gute Lektion gelernt ? Sprich mit mir auf Twitter :-)