Phase 6: Rollout und Skalierung der Geheimnisüberprüfung

Sie können schnell Sicherheitsfunktionen in großem Maßstab mit einem security configuration, einer Sammlung von Sicherheitsaktivierungseinstellungen, die Sie auf Repositorys in einer Organisation anwenden können, aktivieren. Sie können die Merkmale von Advanced Security auf Organisationsebene mit global settings anpassen. Weitere Informationen findest du unter Informationen zum Aktivieren von Sicherheitsfunktionen in großem Umfang.

In diesem Artikel wird ein hochrangiger Prozess erläutert, der sich auf die Aktivierung secret scanning aller Repositorys in einer Organisation konzentriert. Die in diesem Artikel beschriebenen Prinzipien können weiterhin angewendet werden, auch wenn Sie einen gestaffelteren Ansatz für die Aktivierung secret scanning einzelner Repositorys ergreifen.

Mit einer GitHub Copilot Enterprise Lizenz können Sie auch um GitHub Copilot Gespräch Hilfe bitten, um Warnungen in den Repositorys Ihrer Organisation besser zu verstehen secret scanning. Weitere Informationen finden Sie unter Fragen an GitHub Copilot in GitHub stellen.

1. Auf neu committete Geheimnisse konzentrieren

Wenn Sie secret scanning aktivieren, sollten Sie sich darauf konzentrieren, alle neu zugefügten Anmeldedaten zu beheben, die durch das Secret Scanning erkannt wurden. Wenn du dich darauf konzentrierst, committete Anmeldeinformationen zu bereinigen, könnten Entwickler weiterhin versehentlich neue Anmeldeinformationen pushen. Das bedeutet, dass deine Gesamtanzahl an Geheimnissen in etwa auf demselben Niveau bleibt und nicht wie beabsichtigt abnimmt. Deshalb muss das Kompromittieren neuer Anmeldeinformationen unbedingt verhindert werden, ehe es darum geht, bestehende Geheimnisse zu widerrufen.

Es gibt verschiedene Ansätze, um neu committete Anmeldeinformationen in Angriff zu nehmen, doch eine davon wäre zum Beispiel:

1.        **Benachrichtigen:** Verwende Webhooks, um sicherzustellen, dass alle neuen Secret Warnungen so schnell wie möglich von den richtigen Teams gesehen werden. Ein Webhook wird ausgelöst, wenn eine Geheimniswarnung entweder erstellt, behoben oder erneut geöffnet wird. Anschließend kannst du die Nutzdaten des Webhooks analysieren und in die von dir und deinem Team genutzten Tools wie Slack, Teams, Splunk oder E-Mail integrieren. Weitere Informationen findest du unter [AUTOTITLE](/webhooks-and-events/webhooks/about-webhooks) und [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#secret_scanning_alert).
   

2.        **Nachverfolgen:** Erstelle einen Korrekturprozess auf hoher Ebene, der für alle Secret-Typen funktioniert. Sie können sich beispielsweise an den Entwickler wenden, der das Geheimnis und den technischen Leiter von diesem Projekt begangen hat, die Gefahren hervorheben, Geheimnisse in GitHub zu speichern, und sie auffordern, den erkannten Geheimschlüssel zu widerrufen und zu aktualisieren.
   

   Hinweis

   Dieser Schritt kann automatisiert werden. Bei großen Unternehmen und Organisationen mit Hunderten von Repositorys ist eine manuelle Nachverfolgung nicht praktikabel. Du kannst eine Automatisierung in den im ersten Schritt beschriebenen Webhookprozess einführen. Die Nutzdaten des Webhooks enthalten Repository- und Organisationsinformationen zum kompromittieren Geheimnis. Mithilfe dieser Informationen kannst du die aktuellen Maintainer des Repositorys kontaktieren und eine E-Mail/SMS an die verantwortlichen Personen richten oder ein Issue eröffnen.

3.        **Bildung:** Erstelle ein internes Training, das dem Entwickler zugewiesen wird, der das Secret erstellt hat. In diesem Schulungsdokument kannst du die Risiken erklären, die durch das Committen von Geheimnissen entstehen, und sie auf deine bewährten Methoden zur sicheren Verwendung von Geheimnissen in der Entwicklung verweisen. Wenn ein Entwickler nicht aus der Erfahrung lernt und weiterhin Geheimnisse committet, kannst du einen Eskalationsprozess einrichten, aber in der Regel funktioniert eine Schulung wie gewünscht.
   

Wiederhole die letzten beiden Schritte für alle neuen kompromittierten Geheimnisse. Dieser Prozess ermutigt Entwickler, die Verantwortung für das sichere Verwalten der in ihrem Code verwendeten Geheimnisse zu übernehmen, und ermöglicht es dir, die Reduzierung neu committeter Geheimnisse zu messen.

2. Aktivieren des Push-Schutzes

Nachdem Sie aktiviert secret scanninghaben, sollten Sie auch den Pushschutz aktivieren. Bei Pushschutz secret scanning werden Pushs auf unterstützte geheime Schlüssel überprüft und Pusheingaben GitHub blockiert, bevor die geheimen Schlüssel anderen Benutzern offengelegt werden. Wie du den Push-Schutz aktivierst, erfährst du unter Aktivieren des Push-Schutzes für dein Repository.

Nach der Aktivierung kannst du folgende Aktionen ausführen:

1.        **Anleitungen bereitstellen:** Konfigurieren Sie einen benutzerdefinierten Link in der Nachricht, die Mitwirkende sehen, wenn ihr Push von secret scanning blockiert wird. Die verknüpfte Ressource kann Anleitungen für Mitwirkende zum Auflösen des blockierten Pushs bereitstellen. Weitere Informationen finden Sie unter [AUTOTITLE](/code-security/secret-scanning/enabling-secret-scanning-features/enabling-push-protection-for-your-repository).
   

2.        **Benachrichtigen:** Definieren Sie einen Webhook, der speziell Warnungen zur Geheimnisüberprüfung erstellt nachverfolgt, wenn jemand den Push-Schutz mithilfe der Alert-Eigenschaft `"push_protection_bypassed": true` umgeht. Oder verwenden Sie die API, um Updates abzurufen, für die Warnungen zur Geheimnisüberprüfung das Ergebnis einer Pushschutzumgehung war, indem Sie die Liste der Ergebnisse filtern für `"push_protection_bypassed": true`. Weitere Informationen finden Sie unter [AUTOTITLE](/code-security/getting-started/auditing-security-alerts).
   

3.        **Überwachung:** Mit der Sicherheitsübersicht kannst du dir Metriken zur Leistung des Push-Schutzes in den Repositories deiner Organisation anzeigen lassen, damit du schnell die Repositories identifizieren kannst, in denen du eventuell Maßnahmen ergreifen musst. Weitere Informationen finden Sie unter [AUTOTITLE](/code-security/concepts/secret-security/push-protection-metrics).
   

3. Zuvor committete Geheimnisse beginnend mit dem kritischsten bereinigen

Nachdem Sie einen Prozess eingerichtet haben, um das Hinzufügen von Geheimnissen zu Ihren Codebasen zu reduzieren, können Sie mit der Behebung von Geheimnissen beginnen, die vor der Einführung GitHub Advanced Security übertragen wurden.

Die Definition deiner wichtigsten Geheimnisse hängt von den Prozessen und Integrationen deiner Organisation ab. Ein Unternehmen macht sich z. B. wahrscheinlich keine Gedanken über ein Geheimnis des Typs „Slack Incoming Webhook“, wenn es Slack gar nicht nutzt. Es kann hilfreich sein, sich zunächst auf die fünf kritischsten Typen von Anmeldeinformationen für deine Organisation zu konzentrieren.

Sobald du die Entscheidung über die Geheimnistypen getroffen hast, kannst du Folgendes tun:

1. Einen Prozess zur Bereinigung jedes Geheimnistyps einrichten. Die tatsächlichen Verfahren für die einzelnen Geheimnistypen unterscheiden sich oft erheblich. Notiere den Prozess für jeden Geheimnistyp in einem Dokument oder einer internen Wissensdatenbank.

   Hinweis

   Wenn du den Prozess für den Entzug von Secrets erstellst, solltest du versuchen, die Verantwortung für den Entzug von Secrets dem Team zu übertragen, das das Repository verwaltet, und nicht einem zentralen Team. Einer der Grundsätze von GHAS ist, dass Entwickler die Verantwortung für Sicherheit übernehmen und für die Behebung von Sicherheitsproblemen zuständig sind, insbesondere wenn sie diese selbst verursacht haben.

2. Wenn du den Prozess eingerichtet hast, den Teams für das Widerrufen von Anmeldeinformationen befolgen sollen, kannst du Informationen über die Geheimnistypen und andere Metadaten, die den kompromittierten Geheimnissen zuzuordnen sind, zusammentragen, damit du erkennen kannst, wen du über den neuen Prozess informieren musst.

   Sie können diese Informationen in der Sicherheitsübersicht sammeln. Weitere Informationen zur Verwendung der Sicherheitsübersicht finden Sie unter Filtern von Warnungen in der Sicherheitsübersicht.

   Folgende Informationen möchtest du möglicherweise sammeln:

   • Organization

   • Repository

   • Geheimnistyp

   • Geheimer Wert

   • Maintainer des Repositorys zur Kontaktaufnahme

   Hinweis

   Verwende die Benutzeroberfläche, wenn du nur wenige Secrets dieser Art entzogen hast. Wenn es Hunderte kompromittierter Geheimnisse gibt, kannst du die Informationen mithilfe der API sammeln. Weitere Informationen finden Sie unter REST-API-Endpunkte für das Secret Scanning.

3. Nachdem du Informationen über kompromittierte Geheimnisse gesammelt hast, erstelle einen zielgerichteten Kommunikationsplan für die Benutzer, die die Repositorys mit den jeweiligen Geheimnistypen betreuen. Du kannst eine E-Mail oder SMS senden oder auch ein GitHub-Issue in den betroffenen Repositorys einrichten. Wenn du die von diesen Tools zur Verfügung gestellten APIs nutzen kannst, um die Mitteilungen automatisch zu senden, wird die Skalierung für mehrere Geheimnistypen einfacher.

4. Das Programm um weitere Geheimnistypen und benutzerdefinierte Muster erweitern

Du kannst jetzt über die fünf kritischsten Geheimnistypen hinaus eine umfassendere Liste erstellen, und zwar mit einem zusätzlichen Schwerpunkt auf Schulung. Du kannst den vorherigen Schritt wiederholen und zuvor committete Geheimnisse für die verschiedenen anvisierten Geheimnistypen bereinigen.

Du kannst auch weitere der benutzerdefinierten Muster einbeziehen, die in den früheren Phasen gesammelt wurden, und Sicherheits- und Entwicklerteams einladen, weitere Muster zu übermitteln, indem du einen Prozess zur Übermittlung neuer Muster einrichtest, sobald neue Geheimnistypen erstellt werden. Weitere Informationen finden Sie unter Definieren von benutzerdefinierten Mustern für die Geheimnisüberprüfung.

Während du deine Prozesse zur Bereinigung anderer Geheimnistypen weiterentwickelst, solltest du damit beginnen, proaktive Schulungsmaterialien zu erstellen, die in deiner Organisation für alle GitHub-Entwickler freigegeben werden können. Bis zu diesem Zeitpunkt lag der Schwerpunkt vor allem auf der Reaktion. Es ist eine ausgezeichnete Idee, den Fokus auf Proaktivität zu verlagern und Entwickler dazu zu ermutigen, Anmeldeinformationen gar nicht erst auf GitHub zu pushen. Dies kann auf verschiedene Weise geschehen, aber die Erstellung eines kurzen Dokuments, in dem die Risiken und Gründe erläutert werden, wäre ein guter Anfang.