Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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.
| Fähigkeit | Administrator | Mitglied | Mitwirkender | Zuschauer |
|---|---|---|---|---|
| Löschen des Arbeitsbereichs | ✅ | ❌ | ❌ | ❌ |
| Administratoren hinzufügen | ✅ | ❌ | ❌ | ❌ |
| Hinzufügen von Mitgliedern | ✅ | ✅ | ❌ | ❌ |
| Daten schreiben | ✅ | ✅ | ✅ | ❌ |
| Erstellen von Elementen | ✅ | ✅ | ✅ | ❌ |
| Daten lesen | ✅ | ✅ | ✅ | ✅ |
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. Wenn Sie beispielsweise einen Power BI-Bericht freigeben, der den DirectLake-Modus verwendet, kann der Empfänger den Bericht anzeigen, muss aber auch über OneLake-Datenberechtigungen verfügen, um die zugrunde liegenden Delta-Tabellen direkt abzufragen. Für Szenarien, die einen tieferen Datenzugriff erfordern, gewähren Sie zusätzliche Berechtigungen auf Computeebene über den SQL Analytics-Endpunkt oder die Sicherheit des semantischen Modells.
Die Berechtigungen sind für jedes Fabric-Element unterschiedlich. Weitere Informationen zu den Berechtigungen für die verschiedenen Elemente finden Sie hier:
Rechenberechtigungen
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-Sicherheit
OneLake verfügt über eigene Berechtigungen zum Verwalten des Zugriffs auf Tabellen und Ordner in OneLake über OneLake-Sicherheit. Mit der OneLake-Sicherheit können Benutzer benutzerdefinierte Rollen in einem Seehaus erstellen und leseberechtigungen nur für die angegebenen Tabellen und Ordner gewähren, wenn Sie auf OneLake zugreifen. Für jede OneLake-Rolle können Benutzer anderen Benutzern und Sicherheitsgruppen Zuweisungen erteilen oder eine automatische Zuweisung basierend auf der Arbeitsbereichsrolle gewähren.
Erfahren Sie mehr über das OneLake-Datenzugriffssteuerungsmodell und sehen Sie sich die Anleitungen an.
Mandantenübergreifende Datenfreigabe und OneLake-Schnellzugriffe
OneLake-Verknüpfungen kopieren keine Daten; Der Zugriff wird an der Quelle erzwungen. Wenn Sie Daten über Microsoft Entra-Mandanten mithilfe der OneLake-Datenfreigabe freigeben, müssen externen Benutzern geeignete OneLake-Tabellen- oder Ordnerberechtigungen für den Zugriff auf die freigegebenen Daten erteilt werden. Verknüpfungen, die auf mandantenübergreifend geteilte Daten verweisen, folgen demselben Berechtigungsmodell: Der Quellmandant steuert den Zugriff, und die Benutzer des verbrauchenden Mandanten müssen explizite OneLake-Berechtigungen erhalten, die vom Datenbesitzer gewährt werden.
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.
Für Mandantenübergreifende Zugriffsszenarien authentifizieren sich Benutzer zuerst über ihren privaten Microsoft Entra-Mandanten. Fabric überprüft dann, ob dem Benutzer über OneLake-Datenfreigabeberechtigungen Zugriff auf die freigegebenen Daten im Quellmandanten gewährt wurde.
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 eingerichtet und verfügt über drei Funktionen. 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.
| Rolle | Anforderung | Konfiguration |
|---|---|---|
| Leiter | Anzeigen und Bearbeiten aller Inhalte der Vertriebsabteilung in der gesamten Organisation | Eine Mitgliedsrolle für sämtliche Vertriebsarbeitsbereiche in der Organisation |
| Teamleitung | Anzeigen und Ändern aller Inhalte im Vertriebsgebiet in einer bestimmten Region | Eine Mitgliederrolle für den Vertriebsbereich in der Region |
| Mitglieder von Vertriebsteams | ||
| Analytiker | Abrufen aller Inhalte in der Vertriebsabteilung in der gesamten Organisation | Eine Betrachterrolle für alle Vertriebsumgebungen 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.
Nehmen wir an, Marta hat eine Zuschauerrolle im Arbeitsbereich, in dem der Bericht gespeichert ist. Wenn Veronica entscheidet, Martas Zugriffsrechte für den Bericht zu entfernen, kann Marta den Bericht weiterhin im Arbeitsbereich anzeigen. 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. Veronica muss auch Martas Betrachterberechtigungen im 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.
Hinweis
In mandantenübergreifenden Szenarien, in denen ein Power BI-Bericht den DirectLake-Modus verwendet und auf Daten verweist, die über OneLake freigegeben wurden, muss der externe Empfänger über Leseberechtigungen auf Elementebene für den Bericht und oneLake-Datenberechtigungen für die freigegebenen Tabellen im Quellmandanten verfügen.