Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieses Handbuch enthält Einrichtungsschritte für ein Sandkastenprojekt, das Ihnen hilft, GitHub Advanced Security (GHAS) und Microsoft Defender for Cloud umfassend mit einem einfachen Anwendungsfall zu integrieren.
Diese Integration trägt dazu bei, die Cloud-native Anwendungssicherheit Microsoft zu maximieren, indem Laufzeitrisiken und Kontext mit dem ursprünglichen Code korreliert werden, um eine schnellere KI-basierte Behebung zu ermöglichen.
Wenn Sie diesem Leitfaden folgen, führen Sie folgende Schritte aus:
- Richten Sie Ihr GitHub-Repository für Defender for Cloud-Unterstützung ein.
- Erstellen Sie einen Laufzeitrisikofaktor.
- Verknüpfen Sie Code mit Laufzeitressourcen.
- Testen Sie echte Anwendungsfälle in Defender für Cloud.
Voraussetzungen
| Aspect | Detaildaten |
|---|---|
| Umweltanforderungen | - GitHub-Konto mit einem Connector, der in Defender für Cloud erstellt wurde - GHAS-Lizenz - Defender Cloud Security Posture Management (DCSPM) auf dem Abonnement aktiviert - Microsoft Security Copilot (optional für automatisierte Korrekturen) |
| Rollen und Berechtigungen | – Berechtigungen für Sicherheitsadministratoren – Sicherheitsadministrator für das Azure-Abonnement (zum Anzeigen von Ergebnissen in Defender for Cloud) - GitHub-Organisationsbesitzer |
| Cloudumgebungen | Nur in kommerziellen Clouds verfügbar (nicht in Azure Government, Azure betrieben von 21Vianet 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 das Sandkastenbeispiel GitHub Repository, das bereits über alle Inhalte verfügt, um ein anfälliges Containerimage zu erstellen.
Stellen Sie vor dem Einrichten eines Repositorys folgendes sicher:
- Definieren Sie einen Connector für die GitHub Organisation, die Sie im Defender for Cloud-Portal verwenden möchten. Führen Sie die Schritte in "Verbinden Ihrer GitHub-Umgebung mit Microsoft Defender für Cloud" aus.
- Konfigurieren Sie die Agentlose Codeüberprüfung für Ihren GitHub Connector. Führen Sie die Schritte unter Konfigurieren von agentlosen Codeüberprüfungen (Vorschau) aus.
- Verwenden Sie ein privates Repository für die Integration.
- Klonen Sie das folgende Repository für Ihre GitHub Organisation:
- https://github.com/build25-woodgrove/mdc-customer-playbook Dieses Repository hat GHAS aktiviert und ist in einen Azure Mandanten integriert, der Defender CSPM aktiviert hat.
Führen Sie im Repository die folgenden Schritte aus:
- Gehen Sie zu Einstellungen.
- Wählen Sie im linken Bereich " Geheime Schlüssel" und "Variablenaktionen > " aus. Wählen Sie dann "Neuer Repositoryschlüssel" aus.
- Fügen Sie die folgenden geheimen Schlüssel auf Repository- oder Organisationsebene hinzu:
| Variabel | Beschreibung |
|---|---|
| ACR_ENDPOINT | Der Authentifizierungsserver der Containerregistrierung. |
| ACR_USERNAME | Der Benutzername für die Containerregistrierung. |
| ACR_PASSWORD | Das Kennwort der Containerregistrierung. |
Note
Sie können beliebige Namen für diese Variablen auswählen. Sie müssen kein bestimmtes Muster befolgen.
Sie finden diese Informationen im Azure-Portal, indem Sie die folgenden Schritte ausführen:
- Wählen Sie die Container Registry, die Sie bereitstellen möchten.
- Wählen Sie unter "Einstellungen" die Zugriffstasten aus.
- Im Bereich "Zugriffstasten " werden die Schlüssel für den Authentifizierungsserver, den Benutzernamen und das Kennwort angezeigt.
Wählen Sie in Ihrem Repository Aktionen, dann den Workflow Erstellen und Übertragen an ACR aus, und anschließend Workflow ausführen.
Überprüfen Sie, ob das Image in Ihrer Container-Registry bereitgestellt wurde. Für das Beispiel-Repository sollte sich das Image in einer Registry mit dem Tag mdc-mock-0001mdc-ghas-integration befinden.
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 Azure Kubernetes Service (AKS):
Festlegen des Clusterabonnements:
az account set --subscription $subscriptionID
Legen Sie die Anmeldeinformationen für den Cluster fest:
az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing
Stellen Sie das Image bereit:
kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration
Schritt 2: Erstellen des Beispielrisikofaktors (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 Ressourcen als unternehmenskritisch zu bezeichnen.
- Wechseln Sie im Defender for Cloud-Portal zu " Umgebungseinstellungen>Ressourcenkritischität".
- Wählen Sie im rechten Bereich den Link aus, um Microsoft Defender zu öffnen.
- Wählen Sie " Neue Klassifizierung erstellen" aus.
- Geben Sie einen Namen und eine Beschreibung ein.
- Wählen Sie im Abfrage-Generator die Cloudressource aus. Schreiben Sie eine Abfrage, um Ressourcenname gleich dem Namen des Containers festzulegen, den Sie für die Validierung in Ihrem Cluster bereitgestellt haben. Wählen Sie dann Weiter aus.
- Wenn Microsoft Defender Ihre Ressource bereits erkannt hat, wird auf der Seite "Vorschauobjekte " der Name des Containers mit einem Objekttyp von K8s-Container oder K8s-Pod angezeigt. Auch wenn der Name noch nicht sichtbar ist, fahren Sie mit dem nächsten Schritt fort.
- Wählen Sie eine Kritischitätsstufe aus, und überprüfen Sie dann Ihre Klassifizierungsregel, und übermitteln Sie sie.
Note
Microsoft Defender wendet die Kritischitätsbezeichnung auf den Container an, nachdem der Container erkannt wurde. Dieser Vorgang kann bis zu 24 Stunden dauern.
Schritt 3: Überprüfen, ob Ihre Umgebung bereit ist
Die Überprüfung bestätigt, dass Ihre Umgebung ordnungsgemäß konfiguriert ist, um Code für Laufzeitempfehlungen anzuzeigen und umsetzbare Ergebnisse zu generieren.
Während dieses Schritts überprüft Defender den gesamten Code in Bezug auf die Laufzeitsichtbarkeit.
- Microsoft Defender for Cloud überwacht kontinuierlich Quellcoderepositorys auf Sicherheitsrisiken.
- Build-Artefakte, wie etwa Container-Images, werden vor der Bereitstellung in Container-Registries gescannt.
- Laufzeitarbeitslasten, die in Kubernetes-Clustern bereitgestellt werden, werden auf Sicherheitsrisiken überwacht.
- Defender for Cloud korreliert und verfolgt jedes Artefakt vom Code über Build und Bereitstellung bis zur Laufzeit und zurück.
Note
Es kann bis zu 24 Stunden dauern, nachdem die vorherigen Schritte angewendet wurden, bis die folgenden Ergebnisse angezeigt werden.
Testen Sie, ob die agentenlose Überprüfung von GitHub das Repository erkennt.
Wechseln Sie zum Cloud Security Explorer, und führen Sie die Abfrage aus. Die Überprüfungsabfragen testen, ob Defender Artefakte identifizieren können, die von Ihren Pipelines und Workloads erstellt wurden. Wenn die Abfragen Ergebnisse zurückgeben, gibt sie an, dass Scan und Korrelation erwartungsgemäß funktionieren.
Note
Wenn keine Ergebnisse zurückgegeben werden, könnte das darauf hinweisen, dass Artefakte noch nicht generiert sind, der Scanvorgang nicht konfiguriert ist oder Berechtigungen fehlen.
- Überprüfen Sie, ob Defender für Cloud (in Azure Container Registry) das Containerimage gescannt und zum Erstellen eines Containers verwendet hat.
- Fügen Sie in Ihrer Abfrage die Bedingungen für Ihre spezifische Bereitstellung hinzu.
- Überprüfen Sie, ob der Container ausgeführt wird und dass Defender für Cloud den AKS-Cluster gescannt hat.
- Überprüfen Sie, ob die Risikofaktoren auf der Defender für Cloud-Seite ordnungsgemäß konfiguriert sind. Suchen Sie in der Defender for Cloud-Bestandsübersicht nach Ihrem Containernamen, und er sollte als kritisch markiert sein.
Note
Dieser Schritt ist nur erforderlich, wenn Risikofaktoren nicht bereits in Ihrer Umgebung konfiguriert sind.
Durch eine erfolgreiche Validierung wird sichergestellt, dass nachfolgende Schritte wie Empfehlungen, Kampagnen und GitHub Problemgenerierung aussagekräftige Ergebnisse liefern.