In vielen Tenants, die ich betreue, sind die Berechtigungen in Microsoft Defender XDR ein Dauerbrenner. Häufig arbeiten die Teams noch mit Entra-Global-Admins oder den vorkonfigurierten Security-Administrator-Rollen. Das ist ein Erbe aus der Zeit, in der jede Defender-Workload ihr eigenes Rollenmodell mitbrachte. Mit Defender Unified RBAC (Role-Based Access Control) hat Microsoft hier endlich aufgeräumt. Die Berechtigungen für fast alle Sicherheitsworkloads werden jetzt an einer zentralen Stelle im Defender-Portal gesteuert. Der Alltag im SOC wird dadurch spürbar sicherer und einheitlicher, und Rechte lassen sich wesentlich feiner zuweisen als mit den groben Entra-Rollen.

Unified RBAC bringt mehr als eine neue Oberfläche im Defender-Portal

Unified RBAC für Defender XDR liegt im Defender-Portal unter System → Berechtigungen → Microsoft Defender XDR → Rollen. Dort lassen sich eigene Rollen anlegen, außerdem kann man bestehende Rollen aus den Workloads importieren. Automatisch passiert die Umstellung allerdings nicht. Man muss Unified RBAC für jede Workload bewusst aktivieren, etwa für Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps oder Vulnerability Management (Details zur Aktivierung). Erst dann greifen die granularen Defender-Berechtigungen, und die alten Workload-Rollen sind wirkungslos. Gerade bei größeren Security-Teams ist dieser Migrationsschritt ein eigenes Projekt, das man gut vorbereiten sollte.

Besonders schätze ich, dass ich bei der Rollenzuweisung nicht bei den Benutzern stehen bleiben muss. Den Zugriff kann ich zusätzlich auf Gerätegruppen, Datenquellen oder Applikationen beschränken. Der Analyst im SOC-Level 1 sieht dann beispielsweise nur die Alerts bestimmter Gerätegruppen, während der Threat Hunter weiter reichende Rechte für ausgewählte Datenbereiche erhält.

Das neue Rollenmodell ist flexibel, hat aber seine Fallstricke

Microsoft hat das Rollenmodell von Defender Unified RBAC bewusst von den klassischen Entra-Rollen getrennt. Bekannte Rollen wie Security Reader, Security Operator oder Security Administrator werden deshalb nicht automatisch übernommen. Stattdessen lege ich in Unified RBAC genau fest, welche Aktionen eine Rolle in welcher Workload ausführen darf, zum Beispiel beim Gerätemanagement, bei der Vorfallsbearbeitung, bei Live Response oder bei Custom Detections. Im SOC lässt sich auf diese Weise eine saubere Abstufung nach SOC-Level (L1, L2, L3) abbilden.

Die SOC-Tiers auf eigene Rollen abzubilden ist technisch nicht schwierig, in der Praxis aber entscheidend:

  • L1 bekommt Leserechte und kann Vorfälle triagieren
  • L2 darf Response-Aktionen ausführen (z. B. Gerät isolieren, Live Response)
  • L3 bekommt volle Rechte für Investigations und Custom Detection Rules

Wie man eigene RBAC-Rollen erstellt, beschreibt Microsoft hier recht übersichtlich: Benutzerdefinierte Defender-Rollen.

Einen Fehler sehe ich immer wieder: Die Standardrolle „Security Administrator“ wird weiterhin großzügig verteilt, meist aus reiner Gewohnheit. Das ist riskant. Mit dieser Rolle darf man alles, und sie gehört ausschließlich in die Hände des engsten Admin-Kreises. Sinnvoller sind eigene Rollen, die auf bestimmte Aufgaben zugeschnitten und jederzeit nachvollziehbar dokumentiert sind.

Das Diagramm zeigt den Aufbau von Unified RBAC in Defender XDR

In der folgenden Übersicht sind die wichtigsten Komponenten von Unified RBAC und ihre Beziehungen dargestellt. Am wichtigsten finde ich das Scoping, mit dem sich eine Rolle auf bestimmte Gerätegruppen oder Datenquellen beschränken lässt:

flowchart TD
  RBACUI["RBAC-Verwaltung"] --> Rollen["Defender XDR-Rollen"]
  Rollen --> Scopes["Scopes (z. B. Gerätegruppen)"]
  Rollen --> Workloads["Workloads (Endpoint, O365, Identity, Cloud Apps)"]
  Benutzer["Benutzer / Gruppen"] --> Rollen
  Rollen --> Rechte["Berechtigungen (z. B. Vorfälle, Live Response)"]

Abbildung: Unified RBAC in Defender XDR mit zentraler Zuweisung, Scoping und Workload-Zuordnung.

Nach der Migration merkt man schnell, wie viel sauberer und nachvollziehbarer die Rechtevergabe geworden ist. Bei Audits hilft das enorm, und auch die Rollen selbst sind deutlich transparenter als vorher.

Automatisierungskonten werden bei der Umstellung gern übersehen

Service- und Automatisierungskonten verdienen besondere Aufmerksamkeit, etwa für Playbooks, benutzerdefinierte Erkennungsregeln (siehe Blogbeitrag) oder Live-Response-Skripte (siehe Playbook-Leitfaden). Viele dieser Automatisierungen laufen heute mit sehr weitreichenden Rechten, nicht selten als Security Administrator oder sogar mit globalen Entra-Rechten. Sobald Unified RBAC aktiv ist, muss man diese Konten ausdrücklich den passenden Defender-Rollen zuordnen. Sonst laufen sie ins Leere oder brechen mit fehlenden Berechtigungen ab.

Praxis-Tipp: Automatisierungskonten sollten eigene, stark eingeschränkte Rollen erhalten. Ein Konto für mehrere Workloads oder Aufgaben zu verwenden, ist keine gute Idee. Wird ein Automatisierungskonto kompromittiert, bleibt der Schaden so begrenzt.

Am besten vergibt man die Rollen an Automatisierungskonten über Entra-ID-Gruppen, die in Unified RBAC hinterlegt sind. Die Zuweisung bleibt dadurch übersichtlich und lässt sich gut nachvollziehen.

Die Migration verlangt Planung und regelmäßige Kontrolle

Technisch ist die Migration auf Defender Unified RBAC recht einfach, den strategischen Aufwand unterschätzen aber viele. Man sollte genau prüfen, welche Workload-Rollen noch aktiv sind und wodurch sie ersetzt werden. Nach der Aktivierung von Unified RBAC spielt das alte Workload-Rollenmodell keine Rolle mehr, dann zählen ausschließlich die Defender-Rollen. Wer schrittweise vorgeht und erst importiert, dann testet und zuletzt aktiviert, vermeidet die meisten unerwünschten Berechtigungsprobleme.

Die Rollenzuweisungen sollte man regelmäßig überprüfen, idealerweise automatisiert per Skript oder Audit-Report. Eigene Rollenmodelle lassen sich vorab mit dem integrierten Berechtigungstest simulieren (siehe Dokumentation).

Viele Security-Teams nehmen Unified RBAC zum Anlass, die Berechtigungsstruktur im Security-Bereich grundsätzlich zu entrümpeln und spürbar restriktiver zu gestalten. Die feine Granularität bietet sich dafür geradezu an. Vor allem in komplexeren Umgebungen mit mehreren SOC-Teams, Partnern oder Automatisierungen lohnt sich dieser Aufwand.

Weniger Rechte sorgen im SOC für mehr Kontrolle

Für mich gehört Unified RBAC in Defender XDR zu den wichtigsten Verbesserungen der letzten Jahre. Berechtigungen lassen sich jetzt so vergeben, wie es die Praxis verlangt: fein abgestuft und über alle relevanten Security-Workloads hinweg nachvollziehbar. Pauschal vergebene Entra-Security-Admins und unklare Workload-Rollen gehören damit der Vergangenheit an, vorausgesetzt, man migriert das Modell sorgfältig und überprüft es regelmäßig. Nach meiner Erfahrung lohnt sich ein pragmatisches, aber konsequentes Vorgehen beim Rollout. Das SOC wird dadurch sicherer, arbeitet effizienter und behält den Überblick, und davon haben am Ende alle Beteiligten etwas.