Microsoft Defender XDR mit Copilot Studio verbinden

KI-Agenten sind besonders dann interessant, wenn sie nicht nur allgemeine Fragen beantworten, sondern auf die tatsächlich vorhandenen Security-Daten eines Unternehmens zugreifen können.

Genau hier kommt das Model Context Protocol, kurz MCP, ins Spiel. Über MCP können wir einem Agenten Werkzeuge zur Verfügung stellen, mit denen dieser beispielsweise Incidents, Alerts, Geräte, Benutzer oder Advanced-Hunting-Ergebnisse aus Microsoft Defender XDR abfragen kann.

In diesem Beitrag zeige ich, wie Ihr einen eigenen Defender XDR MCP Server in eurem eigenen Azure- und Microsoft-365-Tenant bereitstellt und anschließend mit einem Agenten in Copilot Studio verbindet. Der Server läuft dabei auf Azure Container Apps. Der Zugriff erfolgt im Benutzerkontext und orientiert sich weiterhin an den vorhandenen Entra- und Defender-Rollen des angemeldeten Benutzers. Der MCP Server wird damit nicht zum neuen Superadministrator im Tenant.

Das Deployment umfasst folgende Az-Ressourcen:

• Azure Container Registry und Container Apps
• Azure Key Vault
• Log Analytics Workspace und Application Insights
• Server-App-Registrierung für die MCP-API
• Copilot-Client-App-Registrierung für die Anmeldung

Copilot Studio meldet den Benutzer über Microsoft Entra ID an und übergibt das Access Token an den MCP Server. Dieser validiert das Token und ruft Microsoft Graph, die Defender-for-Endpoint-API und optional die Defender-for-Cloud-Apps-API im Namen des angemeldeten Benutzers auf.

Wichtig: Der Server speichert keine Benutzertokens. Welche Informationen ein Benutzer abrufen und welche Aktionen er ausführen kann, hängt weiterhin von seinen Entra-, Defender- und gegebenenfalls Sentinel-Rollen ab.

Ladet euch zuerst den MCP Server aus diesem GitHub Repo. Die organisationsspezifischen Einstellungen befinden sich in der Datei deploy.settings.psd1. Beim ersten Start erzeugt das Deployment-Skript diese Datei automatisch aus der Vorlage deploy.settings.example.psd1. 

Ich würde allerdings empfehlen, die Datei vor dem ersten Deployment selbst anzulegen:

Copy-Item deploy.settings.example.psd1 deploy.settings.psd1

Anschließend könnt ihr die Einstellungen an eure Umgebung anpassen. Zu den wichtigsten Werten gehören:

ResourceGroup = 'rg-defender-mcp-prod'
Location      = 'westeurope'

ContainerApp             = 'ca-defender-mcp-prod'
ContainerAppsEnvironment = 'cae-defender-mcp-prod'
LogAnalyticsWorkspace    = 'log-defender-mcp-prod'

AppRegEnvironment = 'prod'
AllowedGroupIds   = @()

Falls Ihr eigene Naming Conventions verwendet, ist jetzt der richtige Zeitpunkt, diese einzutragen. Für Container Registry und Key Vault können die Namen automatisch generiert werden. Das ist sinnvoll, da beide Namen global eindeutig sein müssen.

Als Nächstes melden wir uns mit der Azure CLI im richtigen Tenant an und wählen die gewünschte Subscription:

az login --tenant <tenant-id>
az account set --subscription <subscription-id>

Das Skript prüft, ob der angemeldete Tenant mit der in den Einstellungen hinterlegten TenantId übereinstimmt. Wer regelmäßig zwischen mehreren Tenants oder Testumgebungen wechselt, weiß, warum eine Prüfung hier sinnvoll ist.

Das eigentliche Deployment starten wir mit folgendem Befehl:

./deploy.ps1 -ConfigureAppRegistration

Wenn Ihr ebenso Aktionen / Schreibrechte aktivieren wollt, nehmt folgenden Befehl:

./deploy.ps1 -ConfigureAppRegistration -GrantWritePermissions

Beim ersten Durchlauf prüft das Skript zunächst:

• PowerShell-, Azure-CLI- und Bicep-Version
• Azure-Anmeldung, Tenant und Subscription
• Deployment-Einstellungen
• Erforderliche Resource Provider

Anschließend werden die Azure-Ressourcen, das Container-Image und die beiden App-Registrierungen erstellt beziehungsweise konfiguriert. Das Client Secret der Server-App sowie der Signing Key werden direkt im Key Vault gespeichert und erscheinen nicht in der Konsolenausgabe.

Am Ende führt das Skript einen Smoke Test durch und gibt die Werte aus, die wir im nächsten Schritt für Copilot Studio benötigen. Ihr könnt das Skript auch erneut ausführen. Bereits vorhandene Ressourcen werden wiederverwendet und fehlende Komponenten ergänzt.

Kommen wir nun zum interessanten Part, der Verbindung mit Copilot Studio. Öffnet den gewünschten Agenten und navigiert zu: Tools > Tool hinzufügen > Model Context Protocol.

Als Server-URL tragt Ihr den vom Deployment-Skript ausgegebenen Endpunkt ein:

https://<container-app>.<domain>/mcp

Als Authentifizierung wählen wir OAuth 2.0 > Manuell. Die tatsächlichen Werte findet Ihr im Output vom Deployment-Skript. Anbei einmal beispielhaft:

Das Client Secret müsst Ihr einmal manuell an der Client App erzeugen und dann in der Anlage im Copilot Studio hinterlegen. Nach dem Speichern zeigt Copilot Studio eine Redirect URL an. Diese könnt Ihr über folgenden Command ergänzen:

./deploy.ps1 -AddRedirectUri '<redirect-url>'

Anschließend erstellen wir die Verbindung und melden uns an.

AllowedGroupIds = @( 

  '<object-id-der-security-gruppe>'

)

Das Skript weist die Gruppen beiden Enterprise Apps zu und aktiviert „Assignment required“.

Nach einem erfolgreichen Funktionstest kann zusätzlich der Netzwerkzugriff auf die Power-Platform-Connector-Ranges beschränkt werden:

./deploy.ps1 -RestrictIngressToPowerPlatform

Vorher solltet Ihr im Audit Log prüfen, von welchen IP-Adressen die Connector-Aufrufe tatsächlich kommen.

Mit dem Defender XDR MCP Server können wir Defender-Daten und administrative Security-Funktionen als Werkzeuge in Copilot Studio bereitstellen.

Entscheidend ist dabei aus meiner Sicht nicht nur, dass der Agent auf die Daten zugreifen kann. Entscheidend ist, wie dieser Zugriff umgesetzt wird:

• Anmeldung über Microsoft Entra ID
• Aufrufe im Kontext des Benutzers
• Keine Speicherung von Benutzertokens
• Durchsetzung der vorhandenen Entra- und Defender-Rollen
• Getrennte Lese- und Schreibberechtigungen
• Bestätigung vor administrativen Aktionen
• Einschränkung über Gruppen und Netzwerkregeln
• Auditierung der Tool-Aufrufe

Damit erhalten wir keinen pauschal berechtigten Security-Agenten, sondern einen Agenten, der sich innerhalb der vorhandenen Rollen- und Berechtigungsstruktur bewegt. Oder anders formuliert: Der Agent kann viel. Aber eben nur das, was der angemeldete Benutzer ohnehin darf.