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

Sie können die Geheimnisüberprüfung für einzelne oder alle Repositorys in einer Organisation oder einem Unternehmen aktivieren. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für dein Repository, Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation oder Verwalten von GitHub Advanced Security-Features für dein Unternehmen.

Mit GitHub-recommended security configuration, einer Sammlung von Sicherheitseinstellungen, die Sie auf Repositorys in einer Organisation anwenden können, können Sie Sicherheitsfunktionen schnell in großem Umfang aktivieren. Mit GitHub Advanced Security können Sie dann weitere Features auf Organisationsebene mit global settings anpassen. Weitere Informationen finden Sie unter Informationen zum Aktivieren von Sicherheitsfeatures im großen Stil.

In diesem Artikel wird der allgemeine Prozess zur Aktivierung der secret scanning für alle Repositorys in einer Organisation erklärt. Die in diesem Artikel beschriebenen Grundsätze können auch dann umgesetzt werden, wenn du einen gestaffelteren Ansatz für die Aktivierung der secret scanning für einzelne Repositorys wählst.

1. Auf neu committete Geheimnisse konzentrieren

Wenn du die secret scanning aktivierst, solltest du dich darauf konzentrieren, alle neu comitteten Anmeldeinformationen, die bei der Geheimnisüberprüfung entdeckt wurden, zu bereinigen. 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. Benachrichtigung: Verwende Webhooks, um sicherzustellen, dass alle Warnungen zu neuen Geheimnissen so schnell wie möglich an die richtigen Teams weitergeleitet 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 Informationen zu Webhooks und unter Webhook-Ereignisse und -Nutzlasten.

2. Nachverfolgung: Richte einen allgemeinen Bereinigungsprozess für alle Geheimnistypen ein. Du kannst dich beispielsweise mit dem Entwickler, der das Geheimnis committet hat, und seinem technischen Leiter für dieses Projekt in Verbindung setzen und sie auf die Gefahren des Committens von Geheimnissen auf GitHub mit der Bitte hinweisen, das erkannte Geheimnis zu widerrufen und zu aktualisieren.

   Note

   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. Schulung: Erstelle ein internes Schulungsdokument, das dem Entwickler zugewiesen wird, der das Geheimnis committet 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 Pushschutzes

Nachdem du secret scanning aktiviert hast, solltest du auch den Pushschutz aktivieren. Mit pushschutz überprüft secret scanning Pushes auf unterstützte geheime Schlüssel und blockiert Pusheingaben an GitHub, bevor die geheimen Daten anderen Benutzern offengelegt werden. Informationen über die Aktivierung des Push-Schutzes findest du unter Aktivieren des Pushschutzes für Ihr Repository.

Nach der Aktivierung kannst du folgende Aktionen ausführen:

1. Bereitstellen von Anleitungen: Konfiguriere einen benutzerdefinierten Link in der Nachricht, in der Mitwirkende sehen, ob dein Push durch secret scanning blockiert wird. Die verknüpfte Ressource kann Anleitungen für Mitwirkende zum Auflösen des blockierten Pushs bereitstellen. Weitere Informationen findest du unter Aktivieren des Pushschutzes für Ihr Repository.

2. Benachrichtigen: Definiere einen Webhook, der speziell Warnungen zur Geheimnisüberprüfung verfolgt, der erstellt wird, wenn jemand den Push-Schutz umgeht, indem er die Eigenschaft alert "push_protection_bypassed": true verwendet. Oder verwende die API, um Updates abzurufen, für die Warnungen zur Geheimnisüberprüfung das Ergebnis einer Pushschutzumgehung war, indem sie die Liste der Ergebnisse nach "push_protection_bypassed": truefiltert. Weitere Informationen findest du unter Prüfen von Sicherheitswarnungen.

3. Überwachen: Verwende die Sicherheitsübersicht, um Metriken zur Leistung des Pushschutzes in Repositorys in deiner Organisation anzuzeigen, sodass du schnell alle Repositorys identifizieren kannst, in denen du möglicherweise Maßnahmen ergreifen musst. Weitere Informationen findest du unter Anzeigen von Metriken für den Pushschutz bei der Geheimnisüberprüfung.

3. Zuvor committete Geheimnisse beginnend mit dem kritischsten bereinigen

Nachdem du einen Prozess eingerichtet hast, um das Hinzufügen von Geheimnissen zu deinen Codebases zu reduzieren, kannst du damit beginnen, Geheimnisse zu bereinigen, die vor der Einführung von 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.

   Note

   Wenn du den Prozess für den Widerruf von Geheimnissen erstellst, solltest du versuchen, die Verantwortung für das Widerrufen von Geheimnissen 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

   • Geheimniswert

   • Maintainer des Repositorys zur Kontaktaufnahme

   Note

   Nutze die Benutzeroberfläche, wenn es wenige kompromittierte Geheimnisse dieses Typs gibt. Wenn es Hunderte kompromittierter Geheimnisse gibt, kannst du die Informationen mithilfe der API sammeln. Weitere Informationen findest du unter REST-API-Endpunkte für die Geheimnisüberprüfung.

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 findest du 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.