Unified RBAC in Microsoft Defender Neues Modell, ein alter Begriff

Wer sein Microsoft-Defender-Portal in den letzten Monaten geöffnet hat, ist hoffentlich der neue Menüpunkt „Permissions and roles“ unter System/Einstellungen aufgefallen. Hier gibt es je einen Aktivierungsschalter pro Workload-Typ und darunter einem Link, der dann zur neuen Defender-eigenen Rollenverwaltung führt. Wer parallel noch mit älteren Schulungsunterlagen oder eigenen Notizen arbeitet, stolpert zumindest in der deutschen Lokalisierung fast zwangsläufig über denselben Begriff in zwei völlig unterschiedlichen Bedeutungen: „Berechtigungsgruppen“.

Dieser Artikel klärt – vor allem für Gelegenheitsbesucher des Defender-Portals -, was das neue Unified RBAC ist, wie sich Aktivierungsdialog und Rollenverwaltung zueinander verhalten, was „vor“ Unified RBAC galt und warum genau dieser Begriff für Verwirrung sorgen könnte.

Zur Klärung, worauf die Verwirrung beruht, Hilft es, ein Blick auf die verschiedenen Rollenmodelle für Microsoft Cloud Dienste zu erhalten.

Vielen Benutzern dürften Entra-Rollen und ggf. auch Azure-RBAC vertraut sein. In beiden Fällen ist eine Rolle ein Konstrukt, das Privilegien bündelt, welche sich dann einem bestimmten Security Principal aus dem Entra ID (Benutzer, Gruppe, Dienstprinzipal oder „verwaltete Azure Identität“) oder für einen ausgewählten Scope zuweisen lassen. Bei Entra ID ist der erlaubte Scope Im Normalfall die Mandantenebene, es sei denn, Sie arbeiten explizit mit „AUs“ (Admininistrative Units), so genannten Verwaltungseinheiten. Bei Azure erstreckt sich der Scope hierarchisch über die Azure-Organisationseben (Veraltungsgruppen, Abonnements, Ressourcengruppen und Ressourcen). Dass dieses Konzept vertraut sein dürfte, Erschwert es aber auch, Andere berechnungsmodelle, die für andere Cloud-Dienste schon vorher existiert haben Oder jetzt für Defender eingeführt worden, zu verstehen und einzuordnen.

Es gibt nämlich streng genommen für die folgenden MS-Cloud-Dienste eigenständige Rollenmodelle.

„Azure-RBAC“ gilt nur den Workload-Typ „Sentinel“

Wer also mit Microsoft Entra ID oder Azure vertraut ist, bringt ein klares Rollenverständnis mi. Eine Rolle ist ein Bündel von Berechtigungen, das einem Security Principal – einem Benutzer oder einer Gruppe – auf einem bestimmten Scope zugewiesen wird, verwaltet über die IAM-Oberfläche einer Azure-Ressource.

Dieses Modell heißt Azure RBAC (ARM-basiert) und gilt für praktisch alle Azure-Ressourcen einheitlich. Wer mit diesem Verständnis zum ersten Mal ins Defender-Portal wechselt, geht instinktiv davon aus, dass dort ein ähnliches Modell gilt. Dem ist aber nicht so.

Von den fünf großen Defender-Workloads nutzt tatsächlich nur Microsoft Sentinel echtes Azure RBAC. Hierbei werden Rollen wie „Sentinel Reader“, „Responder“ oder „Contributor“ auf dem jeweiligen Log-Analytics-Workspace als Azure-Ressource zugewiesen. Das läuft exakt über dieselbe IAM-Oberfläche, wie bei jeder anderen Azure-Ressource auch.

Die vier übrigen Defender-Workloads jedoch liefen historisch jeweils über ein eigenes, produktinternes Berechtigungssystem, das mit ARM (Azure Resource Manager= überhaupt nichts zu tun hat:

• Defender for Endpoint nutz(te) dazu eigene Rollenobjekte plus Gerätegruppen als Scope-
• Defender for Office 365 nutzt klassischen Email-&-Collaboration-Rollengruppen aus der Exchange-/Compliance-Welt
• Defender for Cloud Apps hat ein eigenes Admin-Modell in der (mittlerweile weitgehend in Entra integrierten) Cloud-App-Security-Oberfläche.
• Am einfachsten gestrickt ist Defender for Identity: Dort gibt es überhaupt kein eigenes Rollensystem, sondern nur drei feste, automatisch angelegte Entra-Sicherheitsgruppen (Admins, Users, Viewers). Die Gruppenmitgliedschaft selbst ist bereits die Berechtigung, verwaltet direkt in Entra ID statt im Defender-Portal.

Ein weiterer Grund, warum diese Unterschiede im Alltag oft unbemerkt bleiben: Globale Administratoren (und meist auch Security Administrators) erhalten in jedem dieser Systeme – alt wie neu – automatisch vollen oder nahezu vollen Zugriff, unabhängig davon, ob überhaupt eine Rolle zugewiesen wurde.

Dieser eingebaute „Break-Glass“-Mechanismus ist beabsichtigtes Produktverhalten, keine Eigenheit eines unkonfigurierten Mandanten. Wer im Tagesgeschäft ausschließlich als Global Administrator arbeitet, stößt entsprechend nie an eine Berechtigungsgrenze und bekommt dadurch auch nie mit, welches der beiden Rollenmodelle für einen Workload gerade tatsächlich gilt.

Was Unified RBAC eigentlich zusammenführt

Das neue Microsoft Defender Unified RBAC ist ein zentrales Berechtigungsmodell, das die Zugriffssteuerung mehrerer bislang getrennter Sicherheitsprodukte in einer einzigen Oberfläche im Defender-Portal bündelt:

• Defender for Endpoint,
• Defender for Office 365,
• Defender for Identity,
• Defender Vulnerability Management,
• Defender for Cloud Apps,
• Microsoft Security Exposure Management
• und – seit relativ kurzer Zeit – auch Microsoft Sentinel.

Statt einen Security-Analysten in vier oder fünf unterschiedlichen Rollenmodellen einzeln zu berechtigen, definiert man eine Rolle, die workloadübergreifend gilt.

Jede Rollenzuweisung besteht dabei aus drei Bausteinen:

1. den Permissions (ausgewählte Berechtigungen aus Kategorien wie Security operations, Security posture, Authorization & settings oder Detection tuning, jeweils als „Read“ oder „Manage“),
2. den Assignments (die Microsoft-Entra-ID-Gruppen oder Benutzer, die die Rolle erhalten) und den
3. Data sources (die Workloads bzw. Gerätegruppen, auf die sich die Rolle bezieht).

Erst die Kombination aus „welche Aktion“, „wer“ und „auf welchen Daten“ ergibt eine vollständige, wirklich granulare Zuweisung. Da ist deutlich feiner, als es die alte Welt aus wenigen, breiten Rollen je Produkt erlaubte.

Zwei Ansichten hinter demselben Menüpunkt

Ein häufiger Stolperstein liegt schon in der Navigation selbst: So verbergen sich im Defender-Portal unter „System/Einstellungen/Microsoft Defender XDR/Berechtigungen und Rollen“ zwei unterschiedliche Ansichten hintereinander.

Zuerst erscheint eine Aktivierungsübersicht mit einem Schalter je Workload – Defender for Endpoint, Defender for Identity, Email & collaboration (also Defender for Office 365), Cloud Apps sowie Microsoft Sentinel, dort sogar einzeln je Log-Analytics-Workspace.

Erst über den Link am unteren Ende dieses Aktivierungsdialogs „Zu Berechtigungen und Rollen wechseln“ gelangt man zur eigentlichen Rollenverwaltung, in der Rollen angelegt, importiert und zugewiesen werden.

Beide Ansichten liegen unter demselben Oberpunkt, sind aber zwei unterschiedliche Schritte desselben Vorgangs – wer das nicht weiß, sucht die Rollenliste leicht an der falschen Stelle.

Technisch bedeutet „Workload aktivieren“: Ab diesem Zeitpunkt entscheidet für genau diesen Workload ausschließlich das Unified-RBAC-Modell über den Zugriff und das bisherige, produktspezifische Modell wird nicht mehr ausgewertet. Deshalb gilt eine klare Reihenfolge:

• Rollen und ihre Zuweisungen sollten vor der Aktivierung eines Workloads bereits stehen, sonst verlieren Analysten im Moment der Aktivierung faktisch ihren Zugriff, weil das neue Modell noch keine passenden Rollen kennt.
• Ob und wie sich ein bereits aktivierter Workload wieder vollständig auf das alte Modell zurückstellen lässt, ist in der öffentlichen Microsoft-Dokumentation nicht abschließend beschrieben. Wer das erwägt, sollte es vorher in einer Testumgebung verifizieren, statt sich auf ungetestete Annahmen zu verlassen.

Ein Detail verdient dabei besondere Aufmerksamkeit, weil es leicht zu einem Fehlschluss führt. Zeigt der Aktivierungsdialog bei Microsoft Sentinel „Keine aktiven Arbeitsbereiche“ an, bedeutet das ausschließlich, dass für keinen der womöglich längst verbundenen Log-Analytics-Workspaces Unified RBAC aktiviert wurde und nicht, dass kein Workspace existiert oder verbunden ist.

Ein Workspace kann parallel aktiv für SIEM-Zwecke genutzt werden und trotzdem in dieser Übersicht als „keine aktiven Arbeitsbereiche“ erscheinen. Er wird dann für die Berechtigung schlicht weiterhin über klassisches Azure RBAC gesteuert, bis Unified RBAC für ihn separat über „Arbeitsbereiche verwalten“ aktiviert wird.

Vor 2025: ein Rollenmodell pro Produkt

Um die heutige Struktur einzuordnen, lohnt der Blick zurück. „Vor“ Unified RBAC hatte jedes Defender-Produkt sein eigenes, unabhängiges Berechtigungsmodell: Defender for Endpoint verwaltete Zugriff über gerätegruppen-basierte Rollen direkt im Produkt.

• Defender for Office 365 nutzte die „Email & collaboration roles“, also klassische Rollengruppen wie „Organization Management“ oder „Security Reader“, verwaltet auf einer eigenen Seite im Portal.
• Microsoft Sentinel wurde über Azure-RBAC-Rollen (ARM-Rollen) im Azure-Portal berechtigt.
• Und globale Microsoft-Entra-ID-Rollen wie Security Administrator wirkten quer über alles, allerdings recht  grob, ohne Feinsteuerung nach Aufgabe oder Datenbereich.

Ein Analyst, der in mehreren Produkten arbeiten sollte, musste entsprechend in mehreren, völlig getrennten Modellen berechtigt werden.

Der Begriff „Berechtigungsgruppen“ hat zwei Bedeutungen

Beim Begriff „Berechtigungsgruppen“ ist nun mit dem neuen Modell zumindest in der deutschen Lokalisierung eine in der Praxis regelmäßig gegebene Verwechslungsgefahr entstanden. Berechtigungsgruppen bezeichnen nämlich im Defender-Kontext zwei unterschiedliche Dinge.

Zum einem handelt es sich dabei um die alten, produktspezifischen Rollengruppen aus der Zeit vor Unified RBAC – etwa die Email-&-Collaboration-Rollengruppen für Defender for Office 365, mit eigener Verwaltungsseite und eigenständigem Mitgliedschaftsmodell.

Zum anderen versteht man darunter die internen Kategorien innerhalb des neuen, einheitlichen Modells selbst, wie z. B.  „Security operations“, „Security posture“, „Authorization & settings“, „Detection tuning“ und weitere. Diese neuen Kategorien sind kein Nachfolger der alten Rollengruppen, sondern eine völlig neue, feinere Gliederung innerhalb des einen, workloadübergreifenden Modells.

Praktisch relevant wird das vor allem beim Umstieg. Sobald Unified RBAC für Email & collaboration aktiviert wird, verschwindet die alte Rollengruppen-Seite vollständig aus dem Portal. Bestehende Rollengruppen müssen vor der Aktivierung entweder importiert oder als neue Unified-RBAC-Rollen nachgebaut werden. Sonst gehen bestehende Zuweisungen faktisch verloren.

Wer die aus älteren Unterlagen bekannten Rollengruppen im Portal nicht mehr findet, sucht entweder an der neuen, aber falschen Stelle oder die Migration für diesen Mandanten wurde bereits durchgeführt und die alte Seite existiert schlicht nicht mehr.

Die Migration verläuft schrittweise

Microsoft rollt Unified RBAC bewusst gestaffelt aus, nicht als erzwungenen Wechsel für alle Bestandskunden gleichzeitig. Seit 2025 ist es der Standard-Berechtigungsmodus für neue Defender-for-Endpoint- und Defender-for-Identity-Mandanten. Im März 2026 kam die Unterstützung für Microsoft Sentinel hinzu, inklusive zeilenbasierter Zugriffssteuerung (Row-Level Security). Rollenzuweisungen synchronisieren sich dabei bidirektional mit Azure RBAC, sobald Unified RBAC für einen Workspace aktiviert ist, wird es zur maßgeblichen Berechtigungsquelle.

Ab Juli 2026 wurde Unified RBAC zusätzlich zum Standard für neue Organisationen mit Defender for Office 365 Plan 2. Bestehende Mandanten behalten ihr bisheriges Modell, bis die Migration aktiv ausgelöst wird. Ein Automatismus, der ohne Zutun umstellt, existiert nicht.

Eine Ausnahme von der Konsolidierung bilden Exchange Online PowerShell und das Security & Compliance PowerShell: Beide nutzen weiterhin die klassischen Exchange-Online- und Email-&-Collaboration-Rollen und werden von Unified RBAC nicht berührt. Ebenfalls außen vor bleiben Data Loss Prevention und Insider Risk Management, die über die separate Microsoft-Purview-Berechtigungsstruktur laufen.

Warum sich die Konsolidierung lohnt

Der Treiber hinter der Vereinheitlichung ist nicht nur Bequemlichkeit, sondern Risikoreduktion. In der alten, fragmentierten Welt sammelten Mitarbeitende über Jahre in mehreren Produkten Berechtigungen an, ohne dass jemand den Gesamtüberblick behielt. Das ist ein klassisches Muster für Privilege Creep und überprivilegierte Konten sind ein bevorzugtes Ziel von Angreifern.

Unified RBAC schafft eine einzige Stelle, an der sich sämtliche Defender-Berechtigungen einer Person ablesen, prüfen und regelmäßig zertifizieren lassen mit spürbarem Effekt auf Nachvollziehbarkeit und Reaktionsgeschwindigkeit bei Rollenwechseln oder Austritten.

💡 Tipp: Sie planen die Migration auf Unified RBAC in Ihrer eigenen Umgebung oder wollen das Zusammenspiel aus Rollen, Data Sources und Legacy-Modellen praktisch durcharbeiten? → Zum Kursangebot