Maßnahmen gegen ein geleaktes Geheimnis in deinem Repository

Einführung

Geheimnisse wie API-Schlüssel, Token und Anmeldeinformationen können erhebliche Sicherheitsrisiken für dein Team und deine Organisation darstellen, wenn sie versehentlich in der Codebasis offengelegt oder nicht ordnungsgemäß gespeichert werden.

Du solltest alle geleakten Geheimnisse sofort als kompromittiert betrachten, und es ist wichtig, dass du die richtigen Gegenmaßnahmen einleitest, z. B. das Widerrufen des Geheimnisses. Das Entfernen des Geheimnisses aus der Codebasis, das Pushen eines neuen Commits oder das Löschen und Neuerstellen des Repositorys verhindern noch nicht, dass das Geheimnis ausgenutzt wird.

In dieser Anleitung erfährst du, wie du vorgehst, wenn du versehentlich ein Geheimnis in deinem Repository committet hast oder wenn du über einen Geheimnisleak in deinem Repository benachrichtigt wurdest.

Voraussetzungen

• Du hast mindestens Schreibzugriff auf das Repository.
• Optional: Secret scanning ist für das Repository aktiviert.

  Hinweis

  Secret scanning ist kostenlos für öffentliche Repositorys. Es ist im Umfang von GitHub Secret Protection für private Repositorys in GitHub Team- und GitHub Enterprise Cloud-Plänen enthalten.

Schritt 1. Ermitteln des Geheimnisses und Sammeln von Kontext

Sammle so viele Informationen wie möglich über das geleakte Geheimnis. Dies hilft dabei, das Risiko zu bewerten und die beste Vorgehensweise für die Behebung zu ermitteln.

1. Bestimme den Geheimnistyp und dessen Anbieter.
   • Ist das Geheimnis beispielsweise ein personal access token (PAT) von GitHub, ein OpenAI-API-Schlüssel oder ein privater SSH-Schlüssel?
2. Suche das Repository, die Datei und die Zeile, die das geleakte Geheimnis enthält.
3. Ermittle den Geheimnisbesitzer. Dies ist die Person oder das Team, die bzw. das das Geheimnis erstellt hat oder dafür verantwortlich ist.
   • Überprüfe die CODEOWNERS-Datei des Repositorys, um das zuständige Team zu ermitteln.
   • Verwende git log -S, um den Commitverlauf deines Repositorys zu durchsuchen, um zu ermitteln, wer das Geheimnis committet hat.

Schritt 2. Risikobewertung

Die Gegenmaßnahmen hängen von den Risikofaktoren ab, die mit dem Geheimnisleak verbunden sind.

Secret scanning kann bei der Bewertung des Risikos helfen, das mit einer Warnung einhergeht. Wenn du jedoch secret scanning noch nicht aktiviert hast, kannst du trotzdem eine Risikobewertung basierend auf den verfügbaren Informationen durchführen.

Option 1. Secret scanning ist aktiviert

Überprüfe die secret scanning-Warnung, die dem Leak zugeordnet ist, die Warnungsbezeichnungen und alle verfügbaren Metadaten:

1. Überprüfe den Gültigkeitsstatus des Geheimnisses, um festzustellen, ob das Geheimnis noch aktiv ist. Die Warnung enthält einen Status, der beschreibt, ob das Geheimnis aktiv, inaktiv oder seine Gültigkeit unbekannt ist.

   Hinweis

   • Gültigkeitsprüfungen sind nur für bestimmte Geheimnistypen verfügbar. Informationen dazu, ob der Geheimnistyp unterstützt wird, findest du unter Unterstützte Scanmuster für geheime Schlüssel.
   • Der Geheimnisanbieter ist immer die zuverlässigste Quelle, um die Gültigkeit eines Geheimnisses zu bestimmen.
2. Suche nach der Bezeichnung public exposure, um zu ermitteln, ob das Geheimnis in einem öffentlichen Repository geleakt wurde.
3. Suche nach der Bezeichnung multiple leaks, um zu ermitteln, ob das Geheimnis an mehreren Stellen offengelegt wurde.
4. Wenn es sich bei dem Geheimnis um ein PAT von GitHub handelt, überprüfe die Warnungsmetadaten auf Informationen zum Zeitpunkt der letzten Verwendung des Geheimnisses und zum Zugriffsbereich.
5. Bewerte, welche Dienste oder Anwendungen vom Geheimnis abhängig sind, und berücksichtige potenzielle Downtime oder Unterbrechungen, wenn du das Geheimnis sofort widerrufen würdest.

Option 2. Secret scanning ist nicht aktiviert

Wenn du secret scanning für das Repository noch nicht aktiviert hast, führe eine Risikobewertung anhand der folgenden Schritte aus:

1. Überprüfe die Sichtbarkeit des Repositorys. Ist das Repository öffentlich?
2. Suche nach Anzeichen dafür, dass das Geheimnis kürzlich verwendet wurde. Gibt es aktuelle Commits oder Pull Requests, die auf das Geheimnis verweisen? Gibt es Protokolle oder Überwachungspfade, aus denen hervorgeht, dass das Geheimnis verwendet wird?
3. Bewerte die Datei, die das Geheimnis und den umgebenden Kontext enthält. Wird das Geheimnis in einem Produktionsbereitstellungsskript (höheres Risiko) oder einer Testdatei (geringeres Risiko) verwendet? Ist das Geheimnis Datenbankanmeldeinformationen oder einem Administratorschlüssel zugeordnet (höheres Risiko)?
4. Bewerte, welche Dienste oder Anwendungen vom Geheimnis abhängig sind, und berücksichtige potenzielle Downtime oder Unterbrechungen, wenn du das Geheimnis sofort widerrufen würdest.

Schritt 3. Strategische Gegenmaßnahmen

Der nächste Schritt hängt von der Risikobewertung ab, die du im vorherigen Schritt durchgeführt hast.

Schnelles Handeln für Geheimnisse mit hohem Risiko

Automatisierte Scanner können in wenigen Minuten öffentlich gemachte Geheimnisse finden. Diese können innerhalb weniger Stunden von Akteuren mit schlechten Absichten ausgenutzt werden. Je länger ein aktives Geheimnis offengelegt ist, desto größer ist das Risiko schwerwiegender Sicherheitsverletzungen.

Wenn das Geheimnis ein hohes Risiko darstellt (d. h., das Geheimnis ist noch aktiv, wird in einem öffentlichen Repository offengelegt, oder es sind Produktionsanmeldeinformation), empfehlen wir Folgendes:

1. Priorisiere den sofortigen Widerruf des Geheimnisses. Weitere Informationen findest du in Schritt 4.

   Hinweis

   Wenn du Bedenken hast, dass Downtime für Dienste entsteht, solltest du zuerst ein neues Geheimnis mit den gleichen Berechtigungen generieren, die Anwendung auf das neue Token umstellen und dann das alte Geheimnis widerrufen.

2. Kommuniziere mit dem Geheimnisbesitzer (in Schritt 1 ermittelt), den Repositoryadministratoren und Sicherheitsleads während oder nach dem Widerruf.

Planung für Geheimnisse mit mittlerem bis geringem Risiko

Wenn das Geheimnis ein mittleres bis geringes Risiko aufweist (d. h., das Geheimnis ist nicht mehr aktiv, wird in einem privaten Repository offengelegt, oder es sind Test- oder Entwicklungsanmeldeinformation), kannst du die Gegenmaßnahmen entsprechend planen:

1. Suche anhand der in Schritt 1 gesammelten Informationen das zuständige Team für das Geheimnis, und benachrichtige es über den Geheimnisleak.
2. Erläutere, was wann geleakt wurde. Erläutere, dass du das Geheimnis widerrufst, ein neues Geheimnis generieren musst und dass betroffene Dienste aktualisiert werden müssen.
3. Informiere die Repositoryadministratoren und Sicherheitsleads über den Leak, und erläutere alle erforderlichen oder bereits durchgeführten Korrekturmaßnahmen.
4. Plane eine Zeit für Widerruf und Rotation zusammen mit dem entsprechenden Team, um einen reibungslosen Übergang zu koordinieren.

Es ist wichtig, auch für Geheimnisse mit mittlerem bis geringem Risiko Maßnahmen zu ergreifen, da sie immer noch ein Risiko für Sicherheit und Compliance darstellen können, wenn sie offengelegt bleiben.

Schritt 4. Widerrufen des Geheimnisses

Es reicht nicht aus, das Geheimnis einfach aus der Codebasis zu entfernen. Die wichtigste Gegenmaßnahme ist das Widerrufen des Geheimnisses beim Anbieter des Geheimnisses. Durch das Widerrufen des Geheimnisses wird das Potenzial für dessen Ausnutzung drastisch verringert.

1. Suche anhand der in Schritt 1 gesammelten Informationen die Website oder Dokumentation des Geheimnisanbieters.

2. Befolge die Anweisungen des Anbieters zum Widerrufen des Geheimnisses. Dies umfasst in der Regel die Anmeldung beim Portal des Anbieters und das Navigieren zu dem Abschnitt, in dem das Geheimnis verwaltet wird.

   Wenn du keinen Zugriff auf das Anbieterportal hast, wende dich an den Geheimnisbesitzer oder den entsprechenden Repositoryadministrator, um Hilfe beim Widerrufen des Geheimnisses zu erhalten.

3. Generiere ggf. ein neues Geheimnis, um das widerrufene Geheimnis zu ersetzen. Dies ist häufig erforderlich, um die Funktionalität für Dienste wiederherzustellen, die auf dem ursprünglichen Geheimnis basierten.

Schritt 5: Ermitteln und Aktualisieren betroffener Dienste

Als Nächstes musst du Updates für alle betroffenen Dienste koordinieren, die das geleakte Geheimnis verwenden, und diese mit dem neuen Geheimnis aktualisieren.

Ermitteln

1. Verwende die Codesuche von GitHub, um den gesamten Code, alle Issues und Pull Requests auf das Geheimnis zu überprüfen.
   • Suche mit org:YOUR-ORG "SECRET-STRING" organisationsweit.
   • Durchsuche dein Repository mit repo:YOUR-REPO "SECRET-STRING".
2. Überprüfe die gespeicherten Bereitstellungsschlüssel, Geheimnisse und Variablen des Repositorys.
   • Klicke auf „Settings“ und dann unter „Security“ auf Secrets and variables oder Deploy keys.
3. Suche nach installierten GitHub Apps und Integrationen, die das Geheimnis verwenden könnten.

Koordinate

1. Weise Copilot an, Issues (und Subissues) für jeden Task zu erstellen, der an der Aktualisierung eines betroffenen Diensts beteiligt ist. Weitere Informationen findest du unter Verwenden von GitHub Copilot zum Erstellen von Issues.
2. Wenn es mehrere Projektbeteiligte gibt, erstelle ein Projektboard für die Issues, um den Fortschritt nachzuverfolgen und die Kommunikation zu erleichtern.

Aktualisieren und Überprüfen

1. Aktualisiere die Anwendung mit dem neuen Geheimnis, und stelle sicher, dass sie die neuen Anmeldeinformationen ordnungsgemäß verwendet.

   Tipp

   Eine sichere Möglichkeit zum Bereitstellen vertraulicher Anmeldeinformationen für deine Anwendung ist ein Tresor. Beispielsweise kannst du vertrauliche Anmeldeinformationen für GitHub-Aktionen und -Workflows über den Speicher „Secrets and variables“ auf der Einstellungsseite deines Repositorys verfügbar machen.

2. Teste betroffene Dienste, um sicherzustellen, dass sie mit dem neuen Geheimnis ordnungsgemäß funktionieren.

Schritt 6. Überprüfung auf nicht autorisierten Zugriff

Sobald die Dienste wiederhergestellt sind, ist es wichtig, nach nicht autorisiertem Zugriff zu suchen, der während der Offenlegung des Geheimnisses aufgetreten ist.

1. Überprüfe die Überwachungsprotokolle von GitHub auf Ereignisse im Zusammenhang mit dem Geheimnis und seiner Verwendung.

   • Sicherheitsprotokoll für dein persönliches Konto Weitere Informationen findest du unter Sicherheitsprotokoll überprüfen.
   • Überwachungsprotokoll für deine Organisation Weitere Informationen findest du unter Auditprotokoll deiner Organisation überprüfen.
   • Überwachungsprotokoll für dein Unternehmen Weitere Informationen findest du unter Überwachungsprotokollereignisse für Ihre Enterprise.

   Für die Überwachungsprotokolle auf Organisationsebene und auf Unternehmensebene kannst du speziell nach Ereignissen im Zusammenhang mit einem Zugriffstoken suchen. Weitere Informationen findest du unter Identifizieren von Überwachungsprotokollereignissen, die von einem Zugriffstoken ausgeführt werden (Organisationen) und Identifizieren von Überwachungsprotokollereignissen, die von einem Zugriffstoken ausgeführt werden (Unternehmen).

   Der Zugriff auf die Überwachungsprotokolle von GitHub hängt von deiner Rolle ab. Daher musst du dich möglicherweise an einen Organisationsbesitzer oder Unternehmensadministrator wenden, wenn du nicht über die erforderlichen Berechtigungen verfügst.

2. Überprüfe die Überwachungsprotokolle des Geheimnisanbieters.

   • Beispielsweise kannst du für Amazon Web Services-Geheimnisse (AWS) die CloudTrail-Protokolle auf nicht autorisierte Zugriffsversuche mithilfe des geleakten Geheimnisses überprüfen. Weitere Informationen findest du unter Was ist AWS CloudTrail? in der AWS CloudTrail-Dokumentation.

Schritt 7. Bereinigen des Repositorys

Obwohl du das Geheimnis in der Codebasis jetzt widerrufen und aktualisiert hast, ist es möglicherweise noch im Commitverlauf deines Repositorys vorhanden. Im Idealfall solltest du nach allen Instanzen des Geheimnisses suchen und diese aus deinem Repository entfernen.

Das Bereinigen des Git-Verlaufs kann jedoch ein destruktiver und disruptiver Prozess sein, da es dazu führen kann, dass Änderungen erzwungenermaßen in das Repository gepusht werden.

Berücksichtige zusammen mit den Sicherheitsleads deines Repositorys sorgfältig die Auswirkungen der Bereinigung des Repositoryverlaufs auf die Compliance- oder Sicherheitsverpflichtungen. Weitere Informationen findest du unter Entfernen vertraulicher Daten aus einem Repository.

Schritt 8: Beheben der Warnung

1. Schließe die secret scanning-Warnung im Repository, indem du Close as auswählst und die Warnung als „Revoked“ kennzeichnest.
2. Dokumentiere den Incident in der Wissensdatenbank oder im Incident-Management-System deines Teams, einschließlich der Schritte zur Behebung des Leaks und aller gewonnenen Erkenntnisse.

Schritt 9 Verhindern weiterer Leaks

Gegen Geheimnisleaks anzugehen ist häufig disruptiv, kompliziert und zeitaufwändig. Der Fokus sollte beim Umgang mit Geheimnissen immer auf der Vermeidung von Leaks um jeden Preis liegen:

1. Stelle sicher, dass der Pushschutz (Teil von GitHub Secret Protection) für das Repository aktiviert ist, sofern noch nicht geschehen. Befasse dich mit der Implementierung strenger Umgehungskontrollen, sodass nur vertrauenswürdige Benutzer den Pushschutz umgehen können. Weitere Informationen findest du unter Informationen zum Pushschutz.
2. Stelle sicher, dass für dein persönliches Konto „Push protection for users“ aktiviert ist. Dadurch bist du vor versehentlichem Pushen unterstützter Geheimnisse an beliebige öffentliche Repositorys geschützt.
3. Befürworte oder implementiere Best Practices für die Geheimnisverwaltung in deinem Team oder deiner Organisation:
   • Verwende Umgebungsvariablen, um Geheimnisse zu speichern, anstatt sie in der Codebasis hartzucodieren.
   • Verwende Geheimnisverwaltungstools wie den Speicher „Secrets and variables“ von GitHub auf der Einstellungsseite deines Repositorys, um Geheimnisse sicher zu speichern und zu verwalten.
   • Rotiere Geheimnisse regelmäßig, um die Auswirkungen potenzieller Leaks zu minimieren.
4. Dokumentiere Incidents und Korrekturschritte, damit dein Team aus früheren Fehlern lernen und zukünftige Methoden verbessern kann.
5. Setze dich für regelmäßige Fortbildungen und Sicherheitsschulungen ein, und führe sie durch. Ein Beispiel ist der Kurs GitHub Advanced Security auf Microsoft Learn.

Weiterführende Themen

• Informationen zur Geheimnisüberprüfung
• Informationen zum Pushschutz
• Unterstützte Scanmuster für geheime Schlüssel
• Informationen zu GitHub Advanced Security