Skip to main content

Behebung eines durchgesickerten Geheimnisses in Ihrem Repository

Erfahren Sie, wie Sie effektiv auf ein durchgesickertes Geheimnis in Ihrem GitHub-Repository reagieren können.

Einleitung

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.

Jedes durchgesickerte Geheimnis ist als sofort gefährdet zu betrachten, und es ist unerlässlich, dass Sie geeignete Gegenmaßnahmen ergreifen, wie beispielsweise die Rücknahme 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 diesem Lernprogramm erfahren Sie, was Sie tun müssen, wenn Sie versehentlich sensible Informationen in Ihr Repository hochgeladen haben oder wenn Sie auf ein Geheimnisleck in Ihrem Repository hingewiesen wurden.

Voraussetzungen

  • Sie haben 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

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

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

Tipp

Wenn Sie secret scanning für Ihr Repository aktiviert haben, kann Ihnen die secret scanning-Warnung die meisten dieser Details liefern.

Schritt 2. Risikobewertung

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

Secret scanning kann Ihnen bei der Risikobewertung im Zusammenhang mit einer Warnung helfen. Wenn Sie secret scanning noch nicht aktiviert haben, können Sie dennoch eine Risikobewertung auf Basis der Ihnen zur Verfügung stehenden Informationen durchführen.

Option 1: Secret scanning ist aktiviert

Überprüfen Sie die mit dem Datenleck verknüpfte secret scanning-Warnung und achten Sie dabei auf die Warnbezeichnungen und alle verfügbaren Metadaten:

  1. Überprüfen Sie 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, finden Sie unter Unterstützte Scanmuster für Secrets.
    • Der Geheimnisanbieter ist immer die zuverlässigste Quelle, um die Gültigkeit eines Geheimnisses zu bestimmen.
  2. Prüfen Sie, ob das Label public exposure vorhanden ist, um festzustellen, ob das Geheimnis in einem öffentlichen Repository durchgesickert ist.
  3. Prüfen Sie, ob das Label multiple leaks vorhanden ist, um festzustellen, ob das Geheimnis an mehreren Stellen offengelegt wird.
  4. Wenn es sich bei dem Geheimnis um ein GitHub PAT handelt, überprüfen Sie die Warnungsmetadaten auf Informationen darüber, wann das Geheimnis zuletzt verwendet wurde und welchen Zugriffsbereich es hat.
  5. Prüfen Sie, welche Dienste oder Anwendungen von dem Geheimnis abhängig sind, und bedenken Sie das Potenzial für Ausfallzeiten oder Störungen, falls Sie das Geheimnis sofort widerrufen würden.

Option 2. Secret scanning ist nicht aktiviert

Falls Sie secret scanning für das Repository noch nicht aktiviert haben, führen Sie eine Risikobewertung auf der Grundlage der folgenden Punkte durch:

  1. Überprüfen Sie die Sichtbarkeit des Repositorys. Ist das Repository öffentlich?
  2. Suchen Sie 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. Bewerten Sie 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. Prüfen Sie, welche Dienste oder Anwendungen von dem Geheimnis abhängig sind, und bedenken Sie das Potenzial für Ausfallzeiten oder Störungen, falls Sie das Geheimnis sofort widerrufen würden.

Schritt 3. Strategische Gegenmaßnahmen

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

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. Priorisieren Sie den sofortigen Widerruf des Geheimnisses. Weitere Informationen finden Sie unter Schritt 4.

    Hinweis

    Wenn Sie sich Sorgen um Ausfallzeiten der Dienste machen, sollten Sie zunächst ein neues Geheimnis mit denselben Berechtigungen generieren, die Anwendung dazu bringen, das neue Token zu verwenden, und dann das alte Geheimnis widerrufen.

  2. Kommunizieren Sie mit dem Geheimnisinhaber (identifiziert in Schritt 1), den Repository-Administratoren und den Sicherheitsverantwortlichen 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), können Sie die Gegenmaßnahmen entsprechend planen:

  1. Ermitteln Sie anhand der in Schritt 1 gesammelten Informationen das für das Geheimnis verantwortliche Team und machen Sie es auf das Geheimnisleck aufmerksam.
  2. Erläutern, was wann durchgesickert ist. Erklären Sie, dass Sie das Geheimnis widerrufen, ein neues Geheimnis generieren und die betroffenen Dienste aktualisieren müssen.
  3. Informieren Sie die Repository-Administratoren und Sicherheitsverantwortlichen über das Datenleck und erläutern Sie, welche Abhilfemaßnahmen erforderlich sind oder bereits ergriffen wurden.
  4. Legen Sie gemeinsam mit dem zuständigen Team einen Zeitpunkt für den Widerruf und die Rotation fest, um einen reibungslosen Übergang zu gewährleisten.

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. Suchen Sie anhand der in Schritt 1 gesammelten Informationen die Website oder Dokumentation des Geheimnisanbieters.

  2. Befolgen Sie 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.

    Sollten Sie keinen Zugriff auf das Anbieterportal haben, wenden Sie sich an den Geheimnisinhaber oder den zuständigen Repository-Administrator, um Hilfe beim Widerruf des Geheimnisses zu erhalten.

  3. Generieren Sie 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.

Hinweis

GitHub widerruft automatisch personal access tokens (PATs) von GitHub, die in öffentlichen Repositorys geleakt wurden.

Bei durchgesickerten GitHub PATs in privaten Repositories können Sie das Leck direkt aus der secret scanning Warnung heraus an GitHub melden, indem Sie auf Leck melden klicken.

Wenn bei anderen Geheimnistypen ein Geheimnis, das einem der unterstützten Partnermuster von GitHub entspricht, in einem öffentlichen Repository geleakt wird, meldet GitHub den Leak automatisch an den Geheimnisanbieter, der das Geheimnis sofort widerrufen kann.

Schritt 5: Ermitteln und Aktualisieren betroffener Dienste

Als nächstes müssen Sie die Aktualisierungen aller betroffenen Dienste mithilfe des durchgesickerten Geheimnisses koordinieren und diese mit dem neuen Geheimnis aktualisieren.

Ermitteln

  1. Verwenden Sie die Codesuche von GitHub, um den gesamten Code, alle Issues und Pull Requests nach dem Geheimnis zu durchsuchen.
    • Durchsuchen Sie Ihre gesamte Organisation mit org:YOUR-ORG "SECRET-STRING".
    • Durchsuchen Sie Ihr Repository mit repo:YOUR-REPO "SECRET-STRING".
  2. Überprüfen Sie die im Repository gespeicherten Bereitstellungsschlüssel, Geheimnisse und Variablen.
    • Klicken Sie auf „Einstellungen“ und anschließend unter „Sicherheit“ auf Geheimnisse und Variablen oder Schlüssel bereitstellen.
  3. Prüfen Sie, ob GitHub Apps installiert sind und ob Integrationen vorhanden sind, die das Geheimnis verwenden könnten.

Coordinate

  1. Weisen Sie Copilot an, für jede Aufgabe, die mit der Aktualisierung eines betroffenen Dienstes verbunden ist, Vorgänge (und Untervorgänge) zu erstellen.
  2. Sind mehrere Interessengruppen beteiligt, sollte ein Projektboard für die einzelnen Punkte erstellt werden, um den Fortschritt zu verfolgen und die Kommunikation zu erleichtern.

Aktualisieren und Überprüfen

  1. Aktualisieren Sie Ihre Anwendung mit dem neuen Geheimnis und stellen Sie sicher, dass Ihre Anwendung die neuen Anmeldeinformationen ordnungsgemäß verwendet.

    Tipp

    Eine sichere Möglichkeit zum Bereitstellen vertraulicher Anmeldeinformationen für Ihre Anwendung ist ein Tresor. Beispielsweise können Sie sensible Anmeldeinformationen für GitHub-Aktionen und Workflows über den Speicher „Geheimnisse und Variablen“ auf der Einstellungsseite Ihres Repositorys verfügbar machen.

  2. Testen Sie die betroffenen Dienste, um sicherzustellen, dass sie mit dem neuen Geheimnis ordnungsgemäß funktionieren.

Schritt 6. Auf unbefugten Zugriff prüfen

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üfen Sie die Audit-Logs von GitHub auf Ereignisse, die mit dem Geheimnis und seiner Verwendung zusammenhängen.

    In den Audit-Protokollen auf Organisations- und Unternehmensebene können Sie gezielt nach Ereignissen suchen, die mit einem Zugriffstoken in Zusammenhang stehen. Weitere Informationen finden Sie 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 Audit-Logs von GitHub hängt von Ihrer Rolle ab. Sollten Sie nicht über die erforderlichen Berechtigungen verfügen, müssen Sie sich möglicherweise an den Organisationsinhaber oder Unternehmensadministrator wenden.

  2. Überprüfen Sie die Audit-Protokolle des Geheimnisanbieters.

    • Beispielsweise können Sie bei Amazon Web Services (AWS)-Geheimnissen die CloudTrail-Protokolle auf unautorisierte Zugriffsversuche überprüfen, die auf dem durchgesickerten Geheimnis beruhen. Weitere Informationen finden Sie unter Was ist AWS CloudTrail? in der AWS CloudTrail-Dokumentation.

Schritt 7. Bereinigen des Repositorys

Obwohl Sie das Geheimnis in Ihrer Codebasis nun widerrufen und aktualisiert haben, kann das Geheimnis weiterhin in der Commit-Historie Ihres Repositorys vorhanden sein. Idealerweise sollten Sie alle Vorkommen des Geheimnisses in Ihrem Repository suchen und entfernen.

Das Bereinigen des Git-Verlaufs kann jedoch ein destruktiver und störender Prozess sein, da er das erzwungene Übertragen von Änderungen in das Repository beinhalten kann.

Wägen Sie gemeinsam mit den Sicherheitsverantwortlichen Ihres Repositorys sorgfältig ab, welche Auswirkungen die Bereinigung des Repository-Verlaufs auf Ihre Compliance- oder Sicherheitsverpflichtungen hat. Weitere Informationen findest du unter Entfernen vertraulicher Daten aus einem Repository.

Schritt 8: Beheben Sie die Warnung

  1. chließen Sie die secret scanning-Warnung im Repository, indem Sie Schließen als auswählen und die Warnung als "Widerrufen" markieren.
  2. Dokumentieren Sie den Vorfall in der Wissensdatenbank oder im Incident-Management-System Ihres Teams, einschließlich der zur Behebung des Lecks unternommenen Schritte und aller daraus gewonnenen Erkenntnisse.

Schritt 9 Weitere Leckagen verhindern

Der Umgang mit Geheimnislecks ist oft störend, kompliziert und zeitaufwändig. Der Fokus beim Umgang mit Geheimnissen sollte immer darauf liegen, Leaks um jeden Preis zu verhindern:

  1. Stellen Sie sicher, dass der Push-Schutz (Teil von GitHub Secret Protection) für das Repository aktiviert ist, falls dies noch nicht der Fall ist. Prüfen Sie die Implementierung strenger Umgehungskontrollen, sodass nur vertrauenswürdige Benutzer den Push-Schutz umgehen können. Weitere Informationen findest du unter Informationen zum Pushschutz.
  2. Stellen Sie sicher, dass Sie für Ihr persönliches Konto den „Push-Schutz für Benutzer“ aktiviert haben. Dieser schützt Sie davor, versehentlich unterstützte Geheimnisse in irgendein öffentliches Repository zu übertragen.
  3. Setzen Sie sich für bewährte Verfahren im Umgang mit Geheimnissen in Ihrem Team oder Ihrer Organisation ein oder implementieren Sie diese:
    • Verwenden Sie Umgebungsvariablen, um Geheimnisse zu speichern, anstatt sie fest im Quellcode zu verankern.
    • Verwenden Sie Tools zur Geheimnisverwaltung wie den Speicher „Geheimnisse und Variablen“ von GitHub auf der Einstellungsseite Ihres Repositorys, um Geheimnisse sicher zu speichern und zu verwalten.
    • Um die Auswirkungen potenzieller Lecks zu minimieren, sollten Geschäftsgeheimnisse regelmäßig ausgetauscht werden.
  4. Dokumentieren Sie Vorfälle und Abhilfemaßnahmen, damit Ihr Team aus Fehlern der Vergangenheit lernen und zukünftige Vorgehensweisen verbessern kann.
  5. Setzen Sie sich für regelmäßige Weiterbildungs- und Sicherheitsschulungen ein und nehmen Sie daran teil. Ein Beispiel ist der Kurs GitHub Advanced Security auf Microsoft Learn.

Weiterführende Lektüre

  •         [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)
    
  •         [AUTOTITLE](/code-security/secret-scanning/introduction/about-push-protection)
    
  •         [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns)
    
  •         [AUTOTITLE](/get-started/learning-about-github/about-github-advanced-security)