Sensitivity Labels und Protection Policies in Microsoft Fabric: Zugriff richtig steuern

Sensitivity Labels und Protection Policies werden in Microsoft Fabric schnell in einen Topf geworfen. Dabei lösen sie unterschiedliche Probleme: Ein Label klassifiziert ein Asset, eine Protection Policy kann daraus für unterstützte Fabric-Items eine zusätzliche Zugriffsschranke machen. Workspace-Rollen, Item-Permissions und datenbezogene Security ersetzt sie trotzdem nicht.

Stand: 31. August 2026. Microsoft führt Protection Policies weiterhin als Preview. Scope, Lizenzierung und Grenzen können sich deshalb ändern und sollten vor einem produktiven Rollout erneut geprüft werden.

Das Wichtigste in 60 Sekunden

Wer Fabric Governance sauber aufbauen will, sollte vier Ebenen auseinanderhalten:

Eine Protection Policy vergibt keine neuen Berechtigungen. Sie entscheidet für ein zugeordnetes Sensitivity Label, welche Nutzer und Gruppen ihre bereits vorhandenen Rechte an unterstützten Items behalten dürfen. Andere werden blockiert.

Kurz definiert: Ein Sensitivity Label klassifiziert ein Asset. Ein Protected Sensitivity Label bringt zusätzliche Rights-Management-Regeln mit und steuert im Fabric-/Power-BI-Service unter anderem, wer ein geschütztes Label ändern oder entfernen darf. Eine Protection Policy nutzt ein Label als Bedingung für zusätzlichen Item-Zugriffsschutz.

Sensitivity Label ist nicht gleich Zugriffsberechtigung

Sensitivity Labels aus Microsoft Purview helfen, Fabric- und Power-BI-Inhalte nach Schutzbedarf zu klassifizieren. Sie können beispielsweise sichtbar machen, dass ein Lakehouse, ein semantisches Modell oder ein Bericht vertrauliche Informationen enthält. Je nach Szenario können Labels außerdem vererbt werden und Schutzinformationen in unterstützte Exportpfade mitnehmen.

Das Label beantwortet damit zunächst die Frage: Wie schützenswert ist dieses Asset? Es beantwortet nicht automatisch die Frage: Wer darf dieses konkrete Fabric-Item öffnen?

Das wird bei Protected Sensitivity Labels besonders wichtig. Microsoft dokumentiert für Fabric und den Power BI Service, dass der zugehörige Schutz im Service vor allem regelt, wer ein geschütztes Label ändern oder entfernen darf. Für labelbasierten Zugriffsschutz auf das Fabric-Item selbst gibt es Protection Policies.

Für eine breitere Einordnung der technischen Berechtigungsarchitektur lohnt sich deshalb der Blick auf OneLake Security richtig aufbauen. Klassifizierung und Autorisierung sind zwei verschiedene Governance-Aufgaben.

Was Fabric Protection Policies tatsächlich machen

Eine Fabric Protection Policy wird in Microsoft Purview mit einem passend konfigurierten Sensitivity Label verbunden. In der Policy definiert ihr Nutzer und Gruppen, die ihren vorhandenen Zugriff auf entsprechend gelabelte Items behalten dürfen. Nutzer und Gruppen außerhalb dieser Allow-Liste werden blockiert.

Angenommen, eine Person hat keinen Zugriff auf ein Lakehouse. Wird sie in die Protection Policy aufgenommen, bekommt sie dadurch nicht plötzlich Zugriff. Umgekehrt kann eine Person Workspace- oder Item-Berechtigungen besitzen und trotzdem durch die Protection Policy blockiert werden.

Als Entscheidungslogik lässt sich das so lesen:

Für Power-BI-Semantic-Models kann anschließend beispielsweise RLS oder OLS bestimmen, welche Zeilen oder Modellobjekte eine zugelassene Person tatsächlich sieht. Bei OneLake greifen wiederum eigene Sicherheitsmechanismen. Auch bei delegierten OneLake Shortcuts bleiben Identität und tatsächliche Berechtigung eigenständige Fragen.

Die vier Schutzebenen als Governance-Modell

Die sauberste Architektur entsteht, wenn ihr die Mechanismen jeweils einer eigenen Frage zuordnet.

Wenn ihr dieses Problem lösen wollt ...	Dann ist primär relevant ...	Was es nicht ersetzt
Daten und Assets nach Sensibilität klassifizieren	Sensitivity Labels	Zugriffsberechtigungen
Änderungen an geschützten Labels kontrollieren	Protected Labels / Usage Rights	Item-Zugriff
Zugriff auf gelabelte Fabric-Items zusätzlich einschränken	Protection Policies	Workspace-/Item-Permissions
Zugriff auf Workspaces und Items vergeben	Workspace Roles / Item Permissions	Labeling und Klassifizierung
Zugriff auf Daten innerhalb eines erlaubten Assets differenzieren	OneLake Security, RLS/OLS und passende Daten-Security	Item-weite Protection Policy

Diese Trennung verhindert falsche Sicherheitsannahmen. Ein Team kann ein hervorragendes Labeling-Konzept besitzen und trotzdem zu breite Workspace-Berechtigungen haben. Umgekehrt kann ein restriktives Permission-Modell ohne konsistente Klassifizierung schwer steuerbar sein.

Voraussetzungen für Fabric Protection Policies

Bevor ihr eine Policy erstellt, müssen mehrere Grundlagen zusammenpassen. Microsoft verlangt ein passend konfiguriertes Sensitivity Label aus Microsoft Purview Information Protection. Für Fabric Protection Policies muss dieses Label unter anderem für die passenden Daten-Assets scoped sein und „Control access“ enthalten. Außerdem muss im Fabric Tenant das Anwenden von Sensitivity Labels aktiviert sein.

Die Policy selbst wird von einem Purview-/Security-Verantwortlichen mit mindestens der Rolle Information Protection Admin erstellt. Technische Identitäten gehören ebenfalls in die Vorbereitung: Service Principals können nicht direkt in der Purview-Policy hinzugefügt werden. Müssen sie weiterhin zugreifen, sollten sie über eine passende Entra-Sicherheitsgruppe in der Allow-Liste berücksichtigt werden.

Bei der Lizenzierung ist Vorsicht sinnvoll. Die Fabric-spezifische Microsoft-Dokumentation nennt Microsoft-365-E3/E5-Voraussetzungen im Kontext der Sensitivity Labels; die übergreifende Purview-Preview-Dokumentation nennt für Protection Policies zusätzlich E5 und ein Pay-as-you-go-Modell. Prüft Lizenz- und Billing-Voraussetzungen deshalb vor dem Rollout gegen euren konkreten Tenant und den aktuellen Microsoft-Vertragsstand.

Wo Protection Policies aktuell greifen – und wo nicht

Microsoft dokumentiert Protection Policies aktuell für alle nativen Fabric-Item-Typen, darunter beispielsweise Lakehouses, Notebooks und Pipelines. Zusätzlich werden Power-BI-Semantic-Models unterstützt. Andere Power-BI-Item-Typen wie Reports und Dashboards sind derzeit nicht im Protection-Policy-Scope.

Gerade Reports und Dashboards zeigen, warum „wir labeln alles“ keine vollständige Zugriffsschutzstrategie ist. Ein Label kann auf einem Power-BI-Inhalt vorhanden sein, während der Protection-Policy-Scope trotzdem nur das semantische Modell umfasst.

Preview heißt: erst pilotieren, dann standardisieren

Protection Policies sind Ende August 2026 weiterhin Preview. Bei einer Security-Funktion ist das ein starkes Argument für einen kontrollierten Pilot statt eines ungetesteten Tenant-weiten Rollouts.

Vier Grenzen gehören besonders in die Planung. Erstens werden Gäste und externe Nutzer nicht unterstützt. Zweitens wandern die labelbasierten Itemrestriktionen nicht einfach mit Deployment Pipelines oder Git Integration durch eure CI/CD-Strecke. Drittens kann eine neue Policy bis zu 24 Stunden benötigen, bis sie gelabelte Items erkennt und schützt. Viertens gibt es eine wichtige Ausnahme: Der Nutzer, der das zugeordnete Label zuletzt angewendet hat, wird von der Protection Policy nicht ausgesperrt, auch wenn er nicht in der Allow-Liste steht.

Diese Grenzen machen Protection Policies nicht unbrauchbar. Sie zeigen, dass die Funktion als Governance-Baustein mit Test-, Betriebs- und Change-Prozess geführt werden muss.

Vor der ersten Policy: Identitäten vollständig inventarisieren

Der größte operative Risikofaktor sind oft nicht die Labels selbst, sondern unbekannte Identitäten. Datenpipelines, Automationen, Anwendungen oder semantische Modelle können Service Principals verwenden. Werden diese Identitäten beim Policy-Design vergessen, kann ein funktionierender Prozess nach Aktivierung den Zugriff verlieren.

Vor jede produktive Policy gehört deshalb eine Identitätsmatrix: menschliche Nutzer, Entra-Gruppen, Service Principals, technische Owner, abhängige Anwendungen und relevante Automationen. Der Pilot soll nicht nur bestätigen, dass ein gewünschter Nutzer Zugriff hat. Er soll auch zeigen, dass unerwünschte Nutzer blockiert werden und technische Prozesse weiterhin funktionieren.

Organisatorisch kommt eine zweite Ebene hinzu. Protection Policies liegen typischerweise bei Purview-/Security-Verantwortlichen, Workspace- und Item-Berechtigungen oft beim Fabric-Team. Ein belastbares Operating Model braucht deshalb klare Rollen und Freigaben. Das passt direkt zu Power BI Governance im Self Service und einem Power BI Center of Excellence.

Ein pragmatischer Rollout in sechs Schritten

1. Schutzbedarf und Label-Taxonomie klären. Startet nicht mit der Policy-Maske. Definiert zuerst, welche Klassifikationen wirklich eine zusätzliche Zugriffsschranke benötigen. Nicht jedes Label muss automatisch ein Zugriffsszenario auslösen.

2. Bestehende Berechtigungen und Identitäten inventarisieren. Prüft Workspaces, Items, Gruppen, Service Principals und Daten-Security. Eine Protection Policy sollte nicht über ein unbekanntes Berechtigungsmodell gelegt werden.

3. Einen begrenzten Pilot wählen. Beginnt mit einem klar abgegrenzten Label und wenigen repräsentativen Fabric-Items. B2B-, CI/CD- und produktionskritische Automationsszenarien werden bewusst separat getestet.

4. Allow-Liste gruppenbasiert gestalten. Bis zu 100 Nutzer und Gruppen sind pro Policy möglich. Für ein wartbares Modell sollten Gruppen die Regel und einzelne Nutzer die Ausnahme sein. Technische Identitäten werden über passende Sicherheitsgruppen berücksichtigt.

5. Effektiven Zugriff und Abhängigkeiten testen. Prüft erlaubt und blockiert aus Sicht realer Testidentitäten. Testet nicht nur die Fabric-Oberfläche, sondern auch Pipelines, Apps, Semantic-Model-Zugriffe und abhängige Workloads. Plant wegen möglicher Durchsetzungsverzögerungen ein ausreichendes Testfenster ein.

6. Betrieb und Change-Prozess definieren. Dokumentiert, wer Labels verändert, wer Policies ändert, wie neue Gruppen oder Service Principals aufgenommen werden und wie CI/CD-Abhängigkeiten behandelt werden. Preview-Änderungen gehören in einen regelmäßigen Review.

Der Nutzen dieses Piloten ist nicht nur technische Sicherheit. Er deckt auch falsche Governance-Annahmen auf, bevor daraus Tenant-weite Zugriffsprobleme oder ungewollte Ausfälle werden.

Fünf Anti-Patterns, die ihr vermeiden solltet

„Das Label schützt den Zugriff.“ Nicht pauschal. Labeling, Protected Labels und Protection Policies sind unterschiedliche Mechanismen.

„Die Policy ersetzt Workspace-Rollen.“ Nein. Sie schränkt vorhandene Zugriffe zusätzlich ein, vergibt aber keine neuen Rechte.

„Unsere Deployment Pipeline transportiert das schon mit.“ Die Protection-Policy-Restriktionen sind aktuell nicht in Fabric CI/CD integriert.

„Service Principals funktionieren automatisch weiter.“ Nur wenn sie im Schutzmodell korrekt über Sicherheitsgruppen berücksichtigt werden.

„Wenn die Policy aktiviert ist, ist der Zugriff sofort überall korrekt.“ Microsoft weist auf eine mögliche Erkennungszeit von bis zu 24 Stunden hin.

Beispiel: Vertrauliches Finance-Lakehouse

Nehmen wir ein Lakehouse mit sensiblen Finance-Daten. Es erhält das Label „Confidential – Finance“. Eine Protection Policy erlaubt der Finance-Data-Gruppe und einer technischen Service-Principal-Gruppe, ihre bestehenden Rechte zu behalten. Andere Nutzer werden trotz vorhandener Workspace- oder Item-Berechtigung blockiert, sobald die Policy greift.

Die Policy löst aber nicht das gesamte Sicherheitsproblem. Wer gar keine Item-Berechtigung hat, bekommt sie durch die Policy nicht. Wer Zugriff behält, kann innerhalb der Datenplattform weiterhin zusätzlichen Regeln unterliegen. Und ein daraus gebauter Power-BI-Report ist nicht automatisch über dieselbe Protection Policy geschützt, weil Reports derzeit nicht zu den unterstützten Power-BI-Item-Typen gehören.

Das Vier-Ebenen-Modell bleibt deshalb die bessere Denkweise: Klassifizierung, Label-Governance, labelbasierte Zugriffsschranke und technische Berechtigung arbeiten zusammen, übernehmen aber nicht gegenseitig ihre Aufgaben.

---

Fazit

Sensitivity Labels und Protection Policies lösen unterschiedliche Probleme. Das Label klassifiziert, Protected Labels kontrollieren im Service unter anderem die Änderung geschützter Labels, und Protection Policies können für unterstützte Fabric-Items eine zusätzliche Zugriffsschranke auf Basis des Labels setzen. Die bestehende Permission- und Data-Security-Architektur bleibt trotzdem notwendig.

Für Unternehmen ist das ein sinnvoller zusätzlicher Governance-Baustein – aber noch kein „Policy an und fertig“. Der robuste Weg führt über eine saubere Label-Taxonomie, ein vollständiges Identitäts- und Permission-Inventar, einen begrenzten Pilot, reale Zugriffstests und klare Betriebsverantwortung.

---

Der nächste sinnvolle Schritt

Wenn ihr klären wollt, wie Sensitivity Labels, Protection Policies, OneLake Security und bestehende Berechtigungen in eurer Fabric-Landschaft zusammenspielen sollten, ist unsere Microsoft Fabric Beratung der passende Einstieg. Wir können das Schutzmodell gemeinsam auf eure Workspaces, Identitäten und Governance-Prozesse herunterbrechen, bevor ihr eine Preview-Funktion breit ausrollt.