Berechtigungsmodell
Microsoft Fabric verfügt über ein flexibles Berechtigungsmodell, mit dem Sie den Zugriff auf Daten in Ihrer Organisation steuern können. In diesem Artikel werden die verschiedenen Arten von Berechtigungen in Fabric erläutert. Es wird auch erklärt, wie sie zusammenarbeiten, um den Zugriff auf Daten in Ihrer Organisation zu regeln.
Ein Arbeitsbereich ist eine logische Entität zum Gruppieren von Elementen in Fabric. Arbeitsbereichsrollen legen die Zugriffsberechtigungen für Arbeitsbereiche fest. Auch wenn Elemente in einem bestimmten Arbeitsbereich gespeichert sind, können sie für andere Benutzer in Fabric freigegeben werden. Wenn Sie Fabric-Elemente freigeben, können Sie entscheiden, welche Berechtigungen sie dem Benutzer erteilen möchten, für den Sie das Element freigeben. Einige Elemente wie Power BI-Berichte ermöglichen eine noch genauere Kontrolle der Daten. Berichte können so eingerichtet werden, dass die Benutzer, die sie einsehen, je nach ihren Berechtigungen nur einen Teil der Daten sehen können.
Arbeitsbereichsrollen
Arbeitsbereichsrollen werden dazu verwendet, den Zugriff auf Arbeitsbereiche und die darin enthaltenen Inhalte zu steuern. Fabric-Administratoren können einzelnen Benutzern oder Gruppen Arbeitsbereichsrollen zuweisen. Arbeitsbereichsrollen sind auf einen bestimmten Arbeitsbereich beschränkt. Sie gelten nicht für andere Arbeitsbereiche, die Kapazität des Arbeitsbereichs oder den Mandanten.
Es gibt vier Arbeitsbereichsrollen, die für sämtliche Elemente im Arbeitsbereich gelten. Benutzer, die über keine dieser Rollen verfügen, können nicht auf den Arbeitsbereich zugreifen. Die Rollen lauten:
Zuschauer – Kann sich alle Inhalte im Arbeitsbereich anzeigen lassen, diese aber nicht ändern.
Mitwirkender – Kann sich alle Inhalte im Arbeitsbereich anzeigen lassen und diese ändern.
Mitglied – Kann sich alle Inhalte im Arbeitsbereich anzeigen lassen, diese ändern und für andere freigeben.
Admin – Kann sich alle Inhalte im Arbeitsbereich anzeigen lassen, diese ändern, für andere freigeben und verwalten, einschließlich der Berechtigungen.
Diese Tabelle zeigt einige der Funktionalitäten, die mit den verschiedenen Rollen einher gehen. Eine vollständige und ausführlichere Liste finden Sie unter Microsoft Fabric-Arbeitsbereichsrollen.
| Funktionalität | Admin | Mitglied | Mitwirkender | Zuschauer |
|---|---|---|---|---|
| Löschen des Arbeitsbereichs | ✅ | ❌ | ❌ | ❌ |
| Administratoren hinzufügen | ✅ | ❌ | ❌ | ❌ |
| Hinzufügen von Mitgliedern | ✅ | ✅ | ❌ | ❌ |
| Schreiben von Daten | ✅ | ✅ | ✅ | ❌ |
| Erstellen von Elementen | ✅ | ✅ | ✅ | ❌ |
| Lesen von Daten | ✅ | ✅ | ✅ | ✅ |
Elementberechtigungen
Elementberechtigungen werden dazu verwendet, den Zugriff auf einzelne Fabric-Elemente in einem Arbeitsbereich zu kontrollieren. Elementberechtigungen sind auf ein bestimmtes Element beschränkt und gelten nicht für andere Elemente. Verwenden Sie Elementberechtigungen, um zu regeln, wer einzelne Elemente in einem Arbeitsbereich anzeigen, ändern und verwalten kann. Sie können Elementberechtigungen dazu nutzen, einem Benutzer Zugriff auf ein einzelnes Element in einem Arbeitsbereich zu gewähren, auf das er keinen Zugriff hat.
Wenn Sie das Element für einen Benutzer oder eine Gruppe freigeben, können Sie die Elementberechtigungen konfigurieren. Durch das Freigeben eines Elements erhält der Benutzer standardmäßig die Leseberechtigung für dieses Element. Mit Hilfe von Leseberechtigungen können Benutzer die Metadaten für dieses Element und alle damit verbundenen Berichte abrufen. Leseberechtigungen gestatten den Benutzern jedoch keinen Zugriff auf die zugrunde liegenden Daten in SQL oder OneLake.
Die Berechtigungen sind für jedes Fabric-Element unterschiedlich. Weitere Informationen zu den Berechtigungen für die verschiedenen Elemente finden Sie hier:
Computeberechtigungen
Berechtigungen können auch innerhalb einer bestimmten Compute-Engine in Fabric festgelegt werden, und zwar über den SQL-Analyseendpunkt oder in einem semantischen Modell. Compute-Engine-Berechtigungen ermöglichen eine genauere Datenzugriffskontrolle, z. B. mehr Sicherheit auf Tabellen- und Zeilenebene.
SQL-Analyseendpunkt – Der SQL-Analyseendpunkt bietet direkten SQL-Zugriff auf Tabellen in OneLake und kann die Sicherheit über SQL-Befehle nativ konfigurieren. Diese Berechtigungen gelten nur für Abfragen, die über SQL laufen.
Semantikmodell – Semantische Modelle ermöglichen die Festlegung der Sicherheit mit Hilfe von DAX. Einschränkungen, die mit Hilfe von DAX festgelegt wurden, gelten für Benutzer, die Abfragen über das semantische Modell oder Power BI-Berichte vornehmen, die auf dem semantischen Modell basieren.
Weitere Informationen finden Sie in den folgenden Artikeln:
OneLake-Berechtigungen (Datenzugriffsrollen)
OneLake hat eigene Berechtigungen zur Verwaltung von Dateien und Ordnern in OneLake durch OneLake-Datenzugriffsrollen. OneLake-Datenzugriffsrollen ermöglichen Benutzer*innen das Erstellen benutzerdefinierter Rollen innerhalb eines Lakehouses und das Erteilen von Leseberechtigungen nur für die angegebenen Ordner beim Zugriff auf OneLake. Für jede OneLake-Rolle können Benutzer Zuweisungen für andere Benutzer und Sicherheitsgruppen vornehmen oder eine automatische Zuweisung basierend auf der Arbeitsbereichsrolle veranlassen.
Erfahren Sie mehr über das OneLake-Datenzugriffssteuerungsmodell und zeigen Sie die Schrittanleitungen an.
Reihenfolge der Operationen
Fabric verfügt über drei verschiedene Sicherheitsstufen. Benutzer*innen müssen auf jeder Stufe Zugriff haben, um auf die Daten zuzugreifen. Jede Stufe wertet sequenziell aus, um festzustellen, ob Benutzer*innen Zugriff haben. Sicherheitsregeln wie Microsoft Information Protection-Richtlinien werden auf einer bestimmten Stufe ausgewertet, um den Zugriff zuzulassen oder zu verbieten. Die Reihenfolge des Vorgangs bei der Auswertung der Fabric-Sicherheit lautet:
- Entra-Authentifizierung: Überprüft, ob Benutzer*innen sich beim Microsoft Entra-Mandanten authentifizieren können.
- Fabric-Zugriff: Überprüft, ob Benutzer*innen auf Microsoft Fabric zugreifen können.
- Datensicherheit: Überprüft, ob Benutzer*innen die angeforderte Aktion für eine Tabelle oder Datei ausführen können.
Beispiele
In diesem Abschnitt finden Sie zwei Beispiele dafür, wie Berechtigungen in Fabric eingerichtet werden können.
1. Beispiel: Einrichten von Teamberechtigungen
Wingtip Toys ist mit einem Mandanten für die gesamte Organisation und mit drei Kapazitäten eingerichtet. Jede Kapazität steht für eine andere Region. Wingtip Toys ist in den USA, Europa und Asien tätig. Die Kapazitäten verfügen über einen Arbeitsbereich für jede Abteilung der Organisation, einschließlich der Vertriebsabteilung.
Die Vertriebsabteilung hat einen Manager, einen Vertriebsteamleiter und Vertriebsteammitglieder. Wingtip Toys beschäftigt außerdem einen Analysten für die gesamte Organisation.
Die folgende Tabelle zeigt die Anforderungen für die einzelnen Rollen in der Vertriebsabteilung und wie Berechtigungen dafür festgelegt werden können.
| Role | Anforderung | Setup |
|---|---|---|
| Manager | Anzeigen und Ändern aller Inhalte in der Vertriebsabteilung in der gesamten Organisation | Eine Mitgliedsrolle für sämtliche Vertriebsarbeitsbereiche in der Organisation |
| Teamleitung | Anzeigen und Ändern aller Inhalte in der Vertriebsabteilung in einer bestimmten Region | Eine Mitgliedsrolle für den Vertriebsarbeitsbereich in der Region |
| Mitglieder von Vertriebsteams | ||
| Analyst | Abrufen aller Inhalte in der Vertriebsabteilung in der gesamten Organisation | Eine Zuschauerrolle für sämtliche Vertriebsarbeitsbereiche in der Organisation |
Wingtip bietet außerdem einen Quartalsbericht, in dem die Umsatzerlöse pro Vertriebsmitglied aufgelistet werden. Dieser Bericht wird in einem Finanzarbeitsbereich gespeichert. Mithilfe der Sicherheit auf Zeilenebene wird der Bericht so eingerichtet, dass jedes Vertriebsmitglied nur die eigenen Verkaufszahlen sehen kann. Teamleiter können die Verkaufszahlen aller Verkaufsmitglieder in ihrer Region sehen, und der Vertriebsleiter kann die Verkaufszahlen aller Verkaufsmitglieder der Organisation sehen.
2. Beispiel: Arbeitsbereichs- und Elementberechtigungen
Wenn Sie ein Element freigeben oder dessen Berechtigungen ändern, ändern sich Arbeitsbereichsrollen nicht. Das Beispiel in diesem Abschnitt zeigt, wie Arbeitsbereichs- und Elementberechtigungen interagieren.
Veronica und Marta arbeiten zusammen. Veronica ist Besitzerin eines Berichts, den sie für Marta freigeben möchte. Wenn Veronica den Bericht für Marta freigibt, kann Marta unabhängig von ihrer Arbeitsbereichsrolle darauf zugreifen.
Angenommen, Marta hat eine Anzeigerolle im Arbeitsbereich, in dem der Bericht gespeichert ist. Wenn Veronica entscheidet, Martas Artikelberechtigungen aus dem Bericht zu entfernen, kann Marta den Bericht weiterhin im Arbeitsbereich ansehen. Außerdem kann Marta den Bericht im Arbeitsbereich öffnen und dessen Inhalt anzeigen. Das liegt daran, dass Marta über Anzeigeberechtigungen für den Arbeitsbereich verfügt.
Wenn Veronica nicht möchte, dass Marta den Bericht anzeigen kann, reicht es nicht aus, Martas Elementberechtigungen aus dem Bericht zu entfernen. Vielmehr muss Veronica auch Martas Anzeigeberechtigungen aus dem Arbeitsbereich entfernen. Ohne die Anzeigeberechtigungen für den Arbeitsbereich kann Marta nicht sehen, dass der Bericht vorliegt, da sie nicht auf den Arbeitsbereich zugreifen kann. Den Link zum Bericht kann Marta ebenfalls nicht nutzen, da sie keinen Zugriff auf den Bericht hat.
Marta verfügt nun über keine Anzeigerolle für den Arbeitsbereich mehr. Wenn Veronika den Bericht erneut für sie freigibt, kann Marta ihn über den Link, den Veronika an sie weiterleitet, anzeigen, ohne Zugriff auf den Arbeitsbereich zu haben.
Beispiel 3: Power BI-App-Berechtigungen
Beim Freigeben von Power BI-Berichten möchten Sie häufig, dass Ihre Empfänger*innen nur Zugriff auf die Berichte und nicht auf Artikel im Arbeitsbereich haben. Hierfür können Sie Power BI-Apps verwenden oder Berichte direkt für Benutzer*innen freigeben.
Darüber hinaus können Sie den Anzeigezugriff auf Daten mithilfe von Sicherheit auf Zeilenebene (RLS) einschränken. Mit RLS können Sie Rollen erstellen, die Zugriff auf bestimmte Teile Ihrer Daten haben, und die Ergebnisse darauf einschränken, worauf die Benutzeridentität zugreifen kann.
Dies funktioniert gut, wenn Importmodelle verwendet werden, da die Daten in das semantische Modell importiert werden und die Empfänger*innen Zugriff darauf als Teil der App haben. Mit DirectLake liest der Bericht die Daten direkt aus dem Lakehouse und Berichtsempfänger*innen müssen Zugriff auf diese Dateien im Lake haben. Dafür gibt es mehrere Möglichkeiten:
- Erteilen Sie die
ReadData-Berechtigung direkt auf dem Lakehouse. - Stellen Sie die Anmeldedaten für die Datenquelle von Single Sign-On (SSO) auf eine feste Identität mit Zugriff auf die Dateien im Lake um.
Da RLS im semantischen Modell definiert ist, werden die Daten zuerst gelesen und dann werden die Zeilen gefiltert.
Wenn eine Sicherheitsstufe im SQL-Analyseendpunkt definiert ist, auf dem der Bericht basiert, greifen die Abfragen automatisch auf den DirectQuery-Modus zurück. Wenn Sie dieses Standardfallbackverhalten nicht wünschen, können Sie ein neues Lakehouse mithilfe von Verknüpfungen zu den Tabellen im ursprünglichen Lakehouse erstellen und RLS oder OLS in SQL im neuen Lakehouse nicht definieren.