Freigeben über

Bereitstellen der Integration von GitHub Advanced Security in Microsoft Defender für Cloud

Dieser Leitfaden führt Sie durch alle Setupschritte, die Ihnen helfen, die Cloud-native Anwendungssicherheit von Microsoft optimal zu machen, indem Sie GitHub Advanced Security (GHAS) und Microsoft Defender for Cloud (MDC) integrieren.

Wenn Sie diesem Leitfaden folgen, führen Sie folgende Schritte aus:

  • Richten Sie Ihr GitHub-Repo für Microsoft Defender for Cloud (MDC) ein
  • Erstellen eines Laufzeitrisikofaktors
  • Testen realer Anwendungsfälle in MDC
  • Verknüpfen von Code mit Cloudressourcen
  • Starten sie eine Sicherheitskampagne auf GitHub, indem Sie den Laufzeitkontext nutzen, um die GHAS-Sicherheitswarnungen basierend auf dem Laufzeitkontext zu priorisieren.
  • Erstellen eines GitHub Issues vom MDC aus, um die Korrektur zu starten
  • Schließen der Schleife zwischen Engineering- und Sicherheitsteams

Voraussetzungen

Aspekt Einzelheiten
Umweltanforderungen - GitHub-Konto mit einem Connector, der in Microsoft Defender für Cloud (MDC) erstellt wurde
- GitHub Advanced Security (GHAS)-Lizenz
– Defender CSPM im Abonnement aktiviert
- GitHub Security Copilot (optional für automatisierte Korrekturen)
Rollen und Berechtigungen – Berechtigungen für Sicherheitsadministratoren
– Sicherheitsleser im Azure-Abonnement (zum Anzeigen von Ergebnissen in MDC)
- GitHub-Organisationsbesitzer
Cloudumgebungen - Nur in kommerziellen Clouds verfügbar (nicht in US Gov, China Gov oder anderen souveränen Clouds)

Vorbereiten der Umgebung

Schritt 1: Einrichten des GitHub-Repositorys und Ausführen des Workflows

Verwenden Sie zum Testen der Integration Ihre eigenen Repositorys oder ein Beispiel-GitHub-Repository, das bereits über alle Inhalte verfügt, um ein anfälliges Containerimage zu erstellen.

Hinweis

Stellen Sie sicher, dass das Für die Integration verwendete Repository privat ist.

Wenn Sie ein Beispiel-Repository verwenden möchten, klonen Sie das folgende Repository in Ihrer GitHub-Organisation. Dieses Repository hat GHAS aktiviert und ist in einen Azure-Mandanten mit aktiviertem DCSPM eingebunden:build25-woodgrove/mdc-customer-playbook. Dieses Repository ist für Kunden, um die Integration von Microsoft Defender for Cloud und GHAS zu testen.

Führen Sie im Repository die folgenden Schritte aus:

  1. Wechseln Sie zu Einstellungen.
  2. Wählen Sie im linken Bereich " Geheime Schlüssel" und "Variablenaktionen>" aus.
  3. Fügen Sie die folgenden geheimen Schlüssel auf Repository- oder Organisationsebene hinzu:
Variable Description
ACR_ENDPOINT Der Anmeldeserver der Azure-Containerregistrierung
ACR_PASSWORD Das Kennwort für die Azure-Containerregistrierung
ACR_USERNAME Der Benutzername für die Azure-Containerregistrierung

Screenshot der GitHub-Schnittstelle mit ausgewähltem Menü

Hinweis

Die Namen können frei gewählt werden und müssen nicht einem bestimmten Muster folgen.

Sie finden diese Informationen im Azure-Portal, indem Sie die folgenden Schritte ausführen:

  1. Wählen Sie die ACR, die Sie bereitstellen möchten.

  2. Wählen Sie unter "Einstellungen" die Zugriffstasten aus.

    Screenshot des Azure-Portals mit der Seite

  3. Wählen Sie in Ihrem Repository "Aktionen" aus.

  4. Wählen Sie den Workflow "Erstellen" und "An ACR übertragen" aus , und führen Sie den Workflow aus.

    Screenshot des Abschnitts

  5. Überprüfen Sie, ob das Image in Ihrer Azure-Containerregistrierung bereitgestellt wurde.

  6. Für das bereitgestellte Beispiel-Repository: Das Image sollte sich in einem Registry namens mdc-mock-0001 mit dem Tag mdc-ghas-integration befinden.

  7. Stellen Sie das gleiche Image als ausgeführten Container auf Ihrem Cluster bereit. Eine Möglichkeit, diesen Schritt abzuschließen, besteht darin, eine Verbindung mit dem Cluster herzustellen und den kubectl run Befehl zu verwenden. Hier ist ein Beispiel für AKS:

    1. Festlegen des Clusterabonnements:

      az account set --subscription $subscriptionID

    2. Legen Sie die Anmeldeinformationen für den Cluster fest:

      az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing

    3. Stellen Sie das Image bereit:

      kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration

Schritt 2: Erstellen des ersten Risikofaktors – Geschäftskritische Regel

Einer der Risikofaktoren, die Defender für Cloud für diese Integration erkennt, ist business criticality. Organisationen können Regeln erstellen, um verschiedene Ressourcen als unternehmenskritisch zu bezeichnen.

  1. Wechseln Sie im Microsoft Defender für Cloud-Portal (Azure-Portal) zu " Umgebungseinstellungen", und wählen Sie "Ressourcenkritischität" aus.

  2. Wählen Sie im rechten Bereich den Link aus, um Microsoft Defender zu öffnen.

    Screenshot der Benutzeroberfläche von Microsoft Defender für Cloud mit der Kachel

  3. Wählen Sie " Neue Klassifizierung erstellen" aus.

    Screenshot der Microsoft Defender XDR-Einstellungsseite mit rot hervorgehobenem Link

  4. Geben Sie einen Namen und eine Beschreibung ein.

  5. Wählen Sie die Cloudressource im Abfrage-Generator aus.

  6. Schreiben Sie eine Abfrage, um den Ressourcennamen auf den Namen des Containers festzulegen, den Sie für die Überprüfung im Cluster bereitgestellt haben, und wählen Sie "Weiter" aus.

    Screenshot des Microsoft Defender Abfrage-Builders mit dem Filter Ressourcenname gleich ‚mdc-ghas-container‘, der unter Cloud-Ressourcen angewendet wurde.

  7. Wenn Microsoft Defender Ihre Ressource bereits erkannt hat, wird auf der Seite "Vorschauobjekte " der Name des Containers mit dem Objekttyp "K8s-container" oder "K8s-pod" angezeigt. Auch wenn sie noch nicht auf der Seite "Vorschauobjekte" sichtbar ist, fahren Sie mit dem nächsten Schritt fort. Microsoft Defender wendet die Kritischitätsbezeichnung auf den Container an, nachdem er erkannt wurde. Dieser Vorgang kann bis zu 24 Stunden dauern.

  8. Wählen Sie eine Kritikalitätsstufe aus, überprüfen und übermitteln Sie Ihre Klassifizierungsregel.

Schritt 3: Überprüfen, ob Ihre Umgebung bereit ist

Hinweis

Es kann bis zu 24 Stunden dauern, nachdem die vorherigen Schritte angewendet wurden, bis die folgenden Ergebnisse angezeigt werden.

  1. Testen Sie, ob das agentenlose Scannen von GitHub das Repository erfasst.

  2. Wechseln Sie zum Cloud Security Explorer, und führen Sie die Abfrage aus. Screenshot des Abfrage-Generators im Cloud Security Explorer mit Filtern, die auf GitHub-Repositorys und Containerimages festgelegt sind, mit Suchergebnissen.

  3. Überprüfen Sie, ob der MDC (in ACR) das Containerimage gescannt und zum Erstellen eines Containers verwendet hat. Fügen Sie in Ihrer Abfrage die Bedingungen für Ihre spezifische Bereitstellung hinzu. Screenshot des Cloud Security Explorer mit einer Abfrage mit Filtern für GitHub-Repositorys und Containerimages, in denen Scanergebnisse angezeigt werden.

  4. Überprüfen Sie, dass der Container ausgeführt wird und MDC den AKS-Cluster gescannt hat. Screenshot des Abfrage-Generators für Cloud Security Explorer mit Filtern für GitHub-Repositorys und Containerimages mit Ergebnissen mit Sicherheitsrisiken und Containernutzung.

  5. Überprüfen Sie, ob die Risikofaktoren auf MDC-Seite ordnungsgemäß konfiguriert sind. Suchen Sie auf der MDC-Bestandsseite nach Ihrem Containernamen, und Sie sollten ihn als kritisch gekennzeichnet sehen.

Schritt 4: Erstellen einer GitHub-Kampagne

Da der Workflow ein Image bereitstellt, das einen ausgeführten Container mit einem der Risikofaktoren (geschäftskritisch) erstellt, können Entwickler Risikofaktoren in GitHub sehen.

Hinweis

Nachdem Sie Ihre Ressource als kritisch klassifiziert haben, kann es bis zu 12 Stunden dauern, bis MDC die Daten an GitHub sendet. Hiererhalten Sie weitere Informationen.

  1. Wechseln Sie in GitHub zur GitHub-Organisation, die Sie für die Setuptests verwendet haben.

  2. Wählen Sie Sicherheit>Kampagnen>Erstellen Sie eine Kampagne aus Codescan-Filtern.

    Ein Screenshot der GitHub-Oberfläche zeigt die Registerkarte Sicherheit > Kampagnen mit den Optionen zum Erstellen einer Kampagne aus Code- oder Secret-Scanfiltern.

  3. Erstellen Sie die folgende Kampagne. Diese Kampagne zeigt offene Warnungen mit mittlerem Schweregrad an, bei denen das aus dem Repository bereitgestellte Image an eine kritische Ressource gebunden ist. Ihr Test-Repository sollte mit dieser Kampagne erkannt werden.

    Ein Screenshot der Oberfläche von GitHub Campaigns zeigt Filter für offene Warnungen, den auf kritisch und mittel festgelegten Schweregrad und das Laufzeitrisiko als kritische Ressource.

  4. Wählen Sie "Speichern" und dann " Als Kampagne veröffentlichen" aus.

  5. Geben Sie die erforderlichen Informationen ein, und veröffentlichen Sie dann die Kampagne.

Schritt 5: Evaluierung von Code-to-Cloud-Empfehlungen

Nutzen Sie die SDLC-Erfahrung von C2C-Empfehlungen und die Anreicherung mit Sicherheitswarnungen, um den Status von Sicherheitsproblemen zu verstehen und die Empfehlung zur Lösung dem zuständigen Engineering-Team zuzuweisen. Dies geschieht mit Hilfe der Verbindung zwischen den Sicherheitswarnungen von Dependabot und den übereinstimmenden CVEs in der Registerkarte Runtime recommendation Associated CVE.

Anzeigen der C2C-Empfehlungen

  1. Wechseln Sie im MDC-Portal zur Registerkarte "Empfehlungen ".
  2. Suchen Sie nach dem Namen des von Ihnen erstellten Containers, und öffnen Sie eine der Empfehlungen, die besagt: **Update ***.
  3. Wenn Sie das Beispiel-Repo verwendet haben, suchen Sie nach: Empfehlung zur Aktualisierung der Brace-Erweiterung.
  4. Gehen Sie auf die Registerkarte Korrekturen Insights und sehen Sie sich das Code-to-Cloud-Diagramm an.
  5. Das Diagramm ordnet Ihren ausgeführten Container dem Image des Containers im Code-Repository und dem Code-Repository des Ursprungs in GitHub zu.

Screenshot der Registerkarte

Bidirektionale Anreicherung

  1. Wählen Sie die Registerkarte "Zugeordnete CVEs " aus. Beachten Sie, dass einige CVEs über einen Link in der Spalte "Verwandte GitHub-Warnungen" verfügen.

    Screenshot der Registerkarte

  2. Wählen Sie den Link "Auf GitHub anzeigen" aus, um die relevante GHAS-Sicherheitswarnung zu öffnen.

Technische Mobilisierung

Um die Zusammenarbeit zwischen Sicherheits- und Entwicklungsteams zu verbessern, können Sie ein GitHub-Issue für eine containerisierte Anwendung erstellen, in dem die Sicherheitsprobleme priorisiert werden, auf die sich das Entwicklungsteam konzentrieren sollte. Diese Priorisierung kann das Übergeben von Ergebnissen umfassen, die GHAS nicht aufgenommen hat, aber MDC für CVEs erkannt hat, die nicht Teil von direkten Abhängigkeiten sind (z. B. Sicherheitsrisiken im Basisimage, Betriebssystem oder Drittanbietersoftware wie NGINX).

Das GitHub Issue wird automatisch mit allen CVEs erstellt, die im Bereich der Empfehlung gefunden wurden, und zwar sowohl mit als auch ohne Dependabot-Warnungen, einschließlich anderer Runtime-Kontexte im Repo des Ursprungs.

Screenshot der Liste der GitHub-Probleme mit drei Einträgen, einschließlich 'Update brace-expansion' und 'Update openssl', die mit Sicherheits- und Schwachstellentags gekennzeichnet sind.

Wenn Sie das Problem zuweisen, wird der Problemstatus im MDC-Portal aktualisiert.

Screenshot eines GitHub-Issue mit dem Titel

Agentische Korrekturen

Wenn Sie über eine GitHub Copilot-Lizenz verfügen, können Sie das Problem mit Hilfe von GitHub Coding Agent beheben:

  1. Weisen Sie den GitHub Coding Agent dem Issue zu.
  2. Überprüfen Sie die generierte Korrektur.
  3. Wenn dies sinnvoll erscheint, wenden Sie die Behebung an.
  4. Beobachten Sie die Aktualisierung des Issue-Status im MDC auf Closed.

Verwandte Inhalte

  • Last updated on