Consulting Briefing

29.06.2026 • boddenberg.de

Entra ID unterstützt Purview Sensitivity Labels

Executive Summary

Kurz und schmerzlos: Microsoft hat in der Preview (Stand Juni 2026) die Tür dafür aufgemacht, Purview Sensitivity Labels nicht mehr nur auf Microsoft-365-Gruppen, Teams und SharePoint-Sites zu kleben, sondern auch auf klassische Cloud-Sicherheitsgruppen in Entra ID. Das klingt nach einer Fußnote im Changelog, ist aber ein echter Hebel: Sicherheitsgruppen sind keine Plauder-Container, sondern Autorisierungs-Primitive. Sie steuern Conditional Access, App-Zugriffe und Ressourcen-Rechte. Wenn du da ein Label dranhängst, das sagt „hier kommt kein Gast rein“, dann ist das keine Kosmetik, sondern gelebtes Zero Trust.

Der Clou: Du nutzt dasselbe Label, das du für Gruppen und Sites schon publiziert hast. Keine zweite Label-Welt, kein Parallel-Universum an Governance. Ein Schema, überall durchgezogen. Der Haken: Es ist Preview, das Label ist einmal vergeben unveränderbar, und ein paar mächtige Admin-Rollen dürfen die Regel noch aushebeln. Heißt für dich: Konzept jetzt bauen, produktiv ausrollen mit Augenmaß.

Worum geht es im Detail?

Bisher war die Welt der Container-Labels überschaubar: Du klassifizierst eine Microsoft-365-Gruppe als „Vertraulich“, und damit erbt die angeschlossene SharePoint-Site und das Team die passenden Schutzeinstellungen – Privatsphäre (public/private), externer Gastzugriff, Zugriff von nicht verwalteten Geräten, Conditional-Access-Authentifizierungskontexte. Das ist seit Jahren gelernt. Neu ist, dass dieselben Labels jetzt auch auf reine Sicherheitsgruppen wandern – also genau jene Objekte, mit denen du Zugriff auf Anwendungen und Ressourcen verteilst.

Technisch läuft die Kette so: Du baust und publizierst das Label in Purview im Scope „Groups & Sites“. Dann synchronisierst du es mit Execute-AzureADLabelSync in Richtung Entra ID – das kann bis zu 24 Stunden dauern, also nicht nervös werden, wenn das Label nicht sofort auftaucht. In Entra schaltest du das Feature per Directory-Setting frei. Und hier kommt der erste Stolperstein: Sicherheitsgruppen nutzen ein eigenes Settings-Template namens Group.Security – nicht das altbekannte Group.Unified der M365-Gruppen. Selbst wenn du EnableMIPLabels für M365-Gruppen längst auf True hast, musst du es für Sicherheitsgruppen separat aktivieren.

Abbildung 1: Die Wirkkette von der Purview-Klassifizierung bis zur erzwungenen Mitgliedschaftsprüfung in Entra ID.

Damit du das richtig einordnest, ein Wort zum Hintergrund: Ein Container-Label steuert bei Gruppen und Sites traditionell ein ganzes Bündel an Einstellungen – die Privatsphäre (public oder private und damit fest verriegelt), den externen Gastzugriff, das externe Teilen aus SharePoint-Sites, den Zugriff von nicht verwalteten Geräten und sogar Conditional-Access-Authentifizierungskontexte für MFA oder Nutzungsbedingungen. Bei reinen Sicherheitsgruppen ist die spannendste dieser Stellschrauben der Gastzugriff: Sagt das Label „kein externer Nutzer“, dann ist das auf einem Autorisierungsobjekt eine harte Aussage darüber, wer über diese Gruppe an Berechtigungen kommt – und wer eben nicht.

Ein Detail, das in der Praxis gern übersehen wird: Beim erstmaligen Zuweisen eines Labels validiert Entra die bereits vorhandene Mitgliedschaft gegen die Gast-Policy des Labels. Sitzt also schon ein Gast in der Gruppe und du willst ein „kein Gast“-Label setzen, scheitert die Operation mit einem Fehler, bis du den Gast entfernt hast. Das ist ärgerlich im Moment, aber goldwert: Es zwingt dich, beim Labeln aufzuräumen, statt eine Altlast unbemerkt mitzuschleppen. Genau diese Erstvalidierung ist der Grund, warum Microsoft die effektive – also auch transitiv über Verschachtelung vererbte – Mitgliedschaft zum Prüfzeitpunkt auflösen muss.

Wichtig ist die Abgrenzung, wofür das Ganze gilt – und wofür nicht. Unterstützt werden statische, nicht mail-aktivierte Cloud-Sicherheitsgruppen mit zugewiesener Mitgliedschaft. Außen vor bleiben dynamische Gruppen (Label lässt sich in Edge-Cases zwar setzen, die Policy wird aber nicht erzwungen – also Finger weg), mail-aktivierte Sicherheitsgruppen, Verteilerlisten und alles, was aus dem lokalen Active Directory synchronisiert oder von Exchange verwaltet wird. Und vergiss das Microsoft-365-Admin-Center und das My-Groups-Portal: Labels für Sicherheitsgruppen vergibst du im Entra Admin Center, im Azure-Portal, per PowerShell oder über Microsoft Graph.

Und damit zur unbequemen Wahrheit der Preview: Ein einmal gesetztes Label auf einer Sicherheitsgruppe lässt sich weder ändern noch entfernen. Punkt. Hast du dich vertan, bleibt dir nur, eine neue Gruppe mit dem richtigen Label anzulegen und die Mitglieder umzuziehen. Das ist kein Bug, das ist Absicht – ein Label auf einem Autorisierungsobjekt nachträglich aufzuweichen, wäre ein Sicherheitsrisiko. Aber du solltest es wissen, bevor du fröhlich durch den Tenant labelst.

Was sind Chancen? Was sind Risiken?

Fangen wir mit dem Schönen an. Die größte Chance ist Konsistenz ohne Doppelarbeit. Du hast dein Label-Schema einmal gebaut – jetzt deckt es auch die Autorisierungsebene ab. Eine Gruppe, die App-Zugriff auf eine sensible Fachanwendung steuert, kann jetzt hart erzwingen: kein Gast, niemals, auch nicht aus Versehen. Das ist proaktive Gast-Kontrolle statt nachträglicher Aufräum-Aktion. Wer schon mal einen externen Berater in einer Berechtigungsgruppe gefunden hat, in der er niemals hätte landen dürfen, weiß, wie viel das wert ist.

Der zweite Gewinn: Die Prüfung greift nicht nur beim Anlegen der Gruppe, sondern auch beim Hinzufügen von Mitgliedern. Versuchst du, einen Gast in eine Gruppe mit „kein Gast“-Label zu schieben, wird die Operation schlicht abgelehnt – ob im Portal, per PowerShell oder Graph. Das ist Governance, die nicht von der Disziplin deiner Admins abhängt, sondern vom System erzwungen wird. Genau das ist der Zero-Trust-Gedanke: nicht vertrauen, sondern verifizieren.

Damit zu den Risiken. Das größte ist die High-Privilege-Bypass-Lücke: In der Preview können diverse eingebaute Admin-Rollen und Anwendungen mit weitreichenden Graph-Berechtigungen die Policy beim Hinzufügen von Mitgliedern aushebeln. Wer also denkt, das Label sei eine wasserdichte Mauer, irrt – für privilegierte Identitäten ist es eher ein freundlicher Zaun. Microsoft sagt selbst, dass sich dieses Verhalten bis zur General Availability ändern kann. Plane also defensiv und stütze dich nicht allein auf das Label, solange die Bypass-Regelung gilt.

Das zweite Risiko ist subtiler: Policy-Änderungen am Label wirken NICHT rückwirkend auf bestehende Mitgliedschaften. Drehst du ein Label von „Gast erlaubt“ auf „Gast blockiert“, werden zwar neue Gäste abgewiesen – die bereits drin sitzenden bleiben aber, bis ein Owner oder Admin sie manuell entfernt. Wer das nicht weiß, wiegt sich in falscher Sicherheit. Microsofts Empfehlung ist eindeutig: Label-Policies nach dem Produktiveinsatz möglichst nicht mehr anfassen.

Abbildung 2: Die Nesting-Regel – eine Kind-Gruppe wird nur akzeptiert, wenn ihr Label gleich oder restriktiver ist als das der Eltern-Gruppe.

Das dritte Thema ist die Verschachtelung, und die hat es in sich. Eine Sicherheitsgruppe mit verschachtelten Kindgruppen lässt sich nicht direkt labeln. Du musst erst alle Kinder herauslösen, das Elternteil labeln, jedes Kind einzeln labeln – und zwar mit einem Label, das gleich oder stärker restriktiv ist als das des Elternteils – und dann die Kinder wieder einhängen. Eine laxere Kindgruppe unter einem strengen Elternteil? Wird abgewiesen. Das ist logisch konsistent, aber in gewachsenen, tief verschachtelten Berechtigungs-landschaften ein echtes Stück Handarbeit.

Was müssen wir jetzt schon vorbereiten?

Bevor du loslegst, ein Reality-Check der Voraussetzungen. Du brauchst mindestens eine aktive Entra ID P1 Lizenz (P2 oder M365 E3/E5 tut es auch). Deine Sensitivity Labels müssen in Purview mit dem Scope „Groups & Sites“ publiziert und per Execute-AzureADLabelSync nach Entra synchronisiert sein. Den Sync-Cmdlet gibt es nur in der Security-&-Compliance-PowerShell, nicht im Graph-SDK – ein Detail, an dem schon mancher eine Stunde verloren hat. Und du brauchst das Graph-PowerShell-SDK für die Directory-Settings.

Der entscheidende Schritt: das Directory-Setting Group.Security anlegen oder aktualisieren und EnableMIPLabels auf True setzen. Auch wenn du M365-Gruppen-Labels schon nutzt – dieses Template ist getrennt und muss separat scharf geschaltet werden. Danach gilt die 24-Stunden-Regel: Nach dem Label-Sync kann es bis zu einem Tag dauern, bis das Label in Entra überhaupt auswählbar ist. Plane diesen Puffer ein, sonst suchst du Geister.

Abbildung 3: Eine pragmatische Roadmap vom Pilot bis zum tenantweiten Rollout – in der Preview gilt: erst testen, dann ausrollen.

Anekdote aus dem Beraterleben: Ein Kunde wollte das Feature an einem Freitagnachmittag „mal eben“ produktiv schalten – Label gebaut, synchronisiert, im Portal nichts zu sehen. Großes Rätselraten, Ticket fast schon offen. Lösung: Die 24-Stunden-Sync-Latenz hatte noch nicht durchgeschlagen. Am Montagmorgen war das Label da. Lektion: Dieses Feature belohnt Geduld und bestraft Hauruck. Plane den Rollout nie auf Kante.

Konkret für deine Vorbereitung heißt das: Erstens, mach eine Inventur deiner sensiblen Sicherheitsgruppen – welche steuern Zugriff auf wirklich kritische Ressourcen? Zweitens, kläre deine Nesting-Hierarchien, bevor du labelst, denn nachträgliches Umhängen ist mühsam. Drittens, definiere einen klaren Prozess für den Fall „falsches Label“ – weil Korrigieren in der Preview eben Neuanlegen bedeutet. Und viertens: Dokumentiere, welche privilegierten Rollen die Durchsetzung umgehen können, damit niemand dem Label blind vertraut.

Häufig gestellte Fragen

Kann ich ein Sensitivity Label auf einer Sicherheitsgruppe wieder ändern oder entfernen?

In der aktuellen Preview nicht. Ein einmal vergebenes Label ist auf Cloud-Sicherheitsgruppen unveränderbar. Brauchst du ein anderes Label, legst du eine neue Gruppe mit dem korrekten Label an und ziehst die Mitglieder um – dieses Verhalten kann sich bis zur General Availability aber noch ändern.

Funktionieren die Labels auch für dynamische oder mail-aktivierte Sicherheitsgruppen?

Nein. Unterstützt werden nur statische, nicht mail-aktivierte Cloud-Sicherheitsgruppen mit zugewiesener Mitgliedschaft. Dynamische Gruppen, mail-aktivierte Sicherheitsgruppen, Verteilerlisten sowie aus dem lokalen Active Directory synchronisierte Gruppen sind ausgeschlossen.

Brauche ich ein neues Label-Schema oder reichen meine bestehenden Purview-Labels?

Deine bestehenden Labels reichen. Sicherheitsgruppen nutzen exakt dieselben Labels, die du in Purview im Scope „Groups & Sites“ bereits publiziert hast – eine separate Label-Konfiguration ist nicht nötig.

Warum taucht mein neu publiziertes Label nicht sofort in Entra auf?

Weil zwischen dem Sync mit Execute-AzureADLabelSync und der Verfügbarkeit in Entra ID bis zu 24 Stunden vergehen können. Prüfe außerdem, ob EnableMIPLabels im Template Group.Security auf True steht und mindestens eine Entra ID P1 Lizenz aktiv ist.

Hält das Label wirklich jeden Gast aus der Gruppe heraus?

Für reguläre Nutzer ja – das Hinzufügen wird blockiert. In der Preview können jedoch bestimmte privilegierte Admin-Rollen und Apps mit weitreichenden Graph-Berechtigungen die Durchsetzung umgehen. Verlass dich deshalb nicht allein auf das Label, solange diese Bypass-Regelung gilt.