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.
Die Integration von GHAS und Defender for Cloud hilft dabei, die cloudnativen Anwendungssicherheit von Microsoft zu maximieren, indem sie Laufzeitrisiken und Kontext mit dem ursprünglich erstellten Code korreliert, um eine schnellere KI-gestützte 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 | Details |
|---|---|
| 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.
Bevor Sie ein Repository einrichten:
- 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:
Dieses Repository ist GHAS aktiviert und an einen Azure-Tenant eingebunden, der Defender Cloud Security Posture Management 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:
Variable 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 können den Container-Registry-Authentifizierungsserver, den Benutzernamen und das Passwort im Azure-Portal finden, indem Sie diese Schritte befolgen:
- 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.
Deploye das mdc-mock-0001:mdc-ghas-integration Image als laufenden Container auf deinem Cluster. Eine Möglichkeit, das Container-Image in deinem Cluster bereitzustellen, besteht darin, eine Verbindung mit dem Cluster herzustellen und den Befehl kubectl run zu verwenden. Hier ist ein Beispiel für Azure Kubernetes Service (AKS):
Festlegen des Clusterabonnements:
az account set --subscription $subscriptionIDLegen Sie die Anmeldeinformationen für den Cluster fest:
az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existingStellen 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
Defender wendet das Kritikalitätslabel auf den Container an, nachdem er den Container erkannt hat. Dieser Vorgang kann bis zu 24 Stunden dauern.
Schritt 3: Überprüfen, ob Ihre Umgebung bereit ist
Die Validierung bestätigt, dass Ihre Umgebung korrekt konfiguriert ist, um Code-to-Runtime-Empfehlungen anzuzeigen und umsetzbare Ergebnisse zu generieren.
Während der Validierung überprüft Defender die vollständige Code-zu-Laufzeit-Sichtbarkeit.
- Defender for Cloud überwacht Quellcode-Repositories kontinuierlich auf Sicherheitslücken.
- Build-Artefakte, wie z. B. 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.
Gehe zum Cloud Security Explorer und führe die in der folgenden Liste beschriebenen Validierungsabfragen aus. Diese Validierungsabfragen testen, ob Defender for Cloud Artefakte identifizieren kann, die durch Ihre Pipelines und Workloads erzeugt werden. 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, dass Defender for Cloud in Azure Container Registry das Container-Image gescannt und verwendet hat, um einen Container zu erstellen.
- 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
Die Validierung der Risikofaktor-Konfiguration ist nur erforderlich, wenn die Risikofaktoren in Ihrer Umgebung nicht bereits konfiguriert sind.
Durch eine erfolgreiche Validierung wird sichergestellt, dass nachfolgende Schritte wie Empfehlungen, Kampagnen und GitHub Problemgenerierung aussagekräftige Ergebnisse liefern.