Model uprawnień
Usługa Microsoft Fabric ma elastyczny model uprawnień, który umożliwia kontrolowanie dostępu do danych w organizacji. W tym artykule opisano różne typy uprawnień w usłudze Fabric oraz sposób ich współpracy w celu kontrolowania dostępu do danych w organizacji.
Obszar roboczy to jednostka logiczna do grupowania elementów w sieci szkieletowej. Role obszaru roboczego definiują uprawnienia dostępu dla obszarów roboczych. Chociaż elementy są przechowywane w jednym obszarze roboczym, mogą być udostępniane innym użytkownikom w sieci Szkieletowej. Gdy udostępniasz elementy sieci szkieletowej, możesz zdecydować, które uprawnienia mają nadać użytkownikowi, któremu udostępniasz element. Niektóre elementy, takie jak raporty usługi Power BI, umożliwiają jeszcze bardziej szczegółową kontrolę nad danymi. Raporty można skonfigurować tak, aby w zależności od ich uprawnień użytkownicy, którzy je wyświetlają, widzieli tylko część przechowywanych danych.
Role obszaru roboczego
Role obszaru roboczego służą do kontrolowania dostępu do obszarów roboczych i zawartości w nich. Administrator sieci szkieletowej może przypisywać role obszaru roboczego do poszczególnych użytkowników lub grup. Role obszaru roboczego są ograniczone do określonego obszaru roboczego i nie mają zastosowania do innych obszarów roboczych, pojemności, w których znajduje się obszar roboczy, ani dzierżawy.
Istnieją cztery role obszaru roboczego i mają zastosowanie do wszystkich elementów w obszarze roboczym. Użytkownicy, którzy nie mają żadnej z tych ról, nie mogą uzyskać dostępu do obszaru roboczego. Istnieją następujące role:
Osoba przeglądająca — może wyświetlać całą zawartość w obszarze roboczym, ale nie może jej modyfikować.
Współautor — może wyświetlać i modyfikować całą zawartość w obszarze roboczym.
Członek — może wyświetlać, modyfikować i udostępniać całą zawartość w obszarze roboczym.
Administrator — może wyświetlać, modyfikować, udostępniać i zarządzać całą zawartością w obszarze roboczym, w tym zarządzać uprawnieniami.
W tej tabeli przedstawiono niewielki zestaw możliwości, które ma każda rola. Aby uzyskać pełną i bardziej szczegółową listę, zobacz Role obszaru roboczego usługi Microsoft Fabric.
| Możliwość | Administracja | Element członkowski | Współautor | Przeglądający |
|---|---|---|---|---|
| Usuwanie obszaru roboczego | ✅ | ❌ | ❌ | ❌ |
| Dodawanie administratorów | ✅ | ❌ | ❌ | ❌ |
| Dodaj członków | ✅ | ✅ | ❌ | ❌ |
| Zapisywanie danych | ✅ | ✅ | ✅ | ❌ |
| Tworzenie elementów | ✅ | ✅ | ✅ | ❌ |
| Odczyt danych | ✅ | ✅ | ✅ | ✅ |
Uprawnienia do elementu
Uprawnienia elementu służą do kontrolowania dostępu do poszczególnych elementów sieci szkieletowej w obszarze roboczym. Uprawnienia do elementu są ograniczone do określonego elementu i nie mają zastosowania do innych elementów. Uprawnienia do elementów umożliwiają kontrolowanie, kto może wyświetlać, modyfikować i zarządzać poszczególnymi elementami w obszarze roboczym. Uprawnienia do elementów umożliwiają użytkownikowi dostęp do pojedynczego elementu w obszarze roboczym, do którego nie mają dostępu.
Gdy udostępniasz element użytkownikowi lub grupie, możesz skonfigurować uprawnienia do elementu. Udostępnianie elementu domyślnie przyznaje użytkownikowi uprawnienie do odczytu dla tego elementu. Uprawnienia do odczytu umożliwiają użytkownikom wyświetlanie metadanych dla tego elementu i wyświetlanie skojarzonych z nim raportów. Jednak uprawnienia do odczytu nie zezwalają użytkownikom na dostęp do danych bazowych w usługach SQL lub OneLake.
Różne elementy sieci szkieletowej mają różne uprawnienia. Aby dowiedzieć się więcej o uprawnieniach dla każdego elementu, zobacz:
Uprawnienia obliczeniowe
Uprawnienia można również ustawić w ramach określonego aparatu obliczeniowego w sieci szkieletowej, w szczególności za pośrednictwem punktu końcowego analizy SQL lub w modelu semantycznym. Uprawnienia aparatu obliczeniowego umożliwiają bardziej szczegółową kontrolę dostępu do danych, taką jak zabezpieczenia na poziomie tabeli i wiersza.
Punkt końcowy analizy SQL — punkt końcowy analizy SQL zapewnia bezpośredni dostęp SQL do tabel w usłudze OneLake i może mieć zabezpieczenia skonfigurowane natywnie za pomocą poleceń SQL. Te uprawnienia dotyczą tylko zapytań wykonanych za pośrednictwem języka SQL.
Model semantyczny — modele semantyczne umożliwiają definiowanie zabezpieczeń przy użyciu języka DAX. Ograniczenia zdefiniowane przy użyciu języka DAX dotyczą użytkowników wykonujących zapytania za pośrednictwem modelu semantycznego lub raportów usługi Power BI opartych na modelu semantycznym.
Więcej informacji można znaleźć w następujących artykułach:
Uprawnienia usługi OneLake (role dostępu do danych)
Usługa OneLake ma własne uprawnienia do zarządzania dostępem do plików i folderów w usłudze OneLake za pośrednictwem ról dostępu do danych usługi OneLake. Role dostępu do danych usługi OneLake umożliwiają użytkownikom tworzenie ról niestandardowych w usłudze Lakehouse i udzielanie uprawnień do odczytu tylko określonym folderom podczas uzyskiwania dostępu do usługi OneLake. Dla każdej roli OneLake użytkownicy mogą przypisywać użytkowników, grupy zabezpieczeń lub przydzielać automatyczne przypisanie na podstawie roli obszaru roboczego.
Dowiedz się więcej na temat modelu kontroli dostępu do danych w usłudze OneLake i zapoznaj się z przewodnikami z instrukcjami.
Kolejność operacji
Sieć szkieletowa ma trzy różne poziomy zabezpieczeń. Aby uzyskać dostęp do danych, użytkownik musi mieć dostęp na każdym poziomie. Każdy poziom ocenia sekwencyjnie, aby określić, czy użytkownik ma dostęp. Reguły zabezpieczeń, takie jak zasady usługi Microsoft Information Protection, oceniają na danym poziomie, aby zezwolić na dostęp lub go uniemożliwić. Kolejność operacji podczas oceniania zabezpieczeń sieci szkieletowej to:
- Uwierzytelnianie entra: sprawdza, czy użytkownik może uwierzytelnić się w dzierżawie firmy Microsoft Entra.
- Dostęp do sieci szkieletowej: sprawdza, czy użytkownik może uzyskać dostęp do usługi Microsoft Fabric.
- Zabezpieczenia danych: sprawdza, czy użytkownik może wykonać żądaną akcję w tabeli lub pliku.
Przykłady
Ta sekcja zawiera dwa przykłady sposobu konfigurowania uprawnień w sieci szkieletowej.
Przykład 1. Konfigurowanie uprawnień zespołu
Aplikacja Wingtip Toys jest skonfigurowana z jedną dzierżawą dla całej organizacji i trzema pojemnościami. Każda pojemność reprezentuje inny region. Wingtip Toys działa w Stany Zjednoczone, Europie i Azji. Każda pojemność ma obszar roboczy dla każdego działu w organizacji, w tym działu sprzedaży.
Dział sprzedaży ma kierownika, kierownika zespołu sprzedaży i członków zespołu sprzedaży. Wingtip Toys zatrudnia również jednego analityka dla całej organizacji.
W poniższej tabeli przedstawiono wymagania dotyczące poszczególnych ról w dziale sprzedaży oraz sposób konfigurowania uprawnień w celu ich włączenia.
| Rola | Wymaganie | Ustawienia |
|---|---|---|
| Menedżer | Wyświetlanie i modyfikowanie całej zawartości w dziale sprzedaży w całej organizacji | Rola członka dla wszystkich obszarów roboczych sprzedaży w organizacji |
| Lider zespołu | Wyświetlanie i modyfikowanie całej zawartości w dziale sprzedaży w określonym regionie | Rola członka obszaru roboczego sprzedaży w regionie |
| Członek zespołu ds. sprzedaży | ||
| Analityk | Wyświetlanie całej zawartości w dziale sprzedaży w całej organizacji | Rola osoby przeglądanej dla wszystkich obszarów roboczych sprzedaży w organizacji |
Wingtip ma również kwartalny raport, który zawiera listę przychodów ze sprzedaży na członka sprzedaży. Ten raport jest przechowywany w obszarze roboczym finansów. Korzystając z zabezpieczeń na poziomie wiersza, raport jest konfigurowany tak, aby każdy członek sprzedaży mógł zobaczyć tylko własne dane sprzedaży. Potencjalni potencjalni klienci mogą zobaczyć dane sprzedaży wszystkich członków sprzedaży w ich regionie, a menedżer sprzedaży może zobaczyć dane sprzedaży wszystkich członków sprzedaży w organizacji.
Przykład 2. Uprawnienia obszaru roboczego i elementu
Gdy udostępnisz element lub zmienisz jego uprawnienia, role obszaru roboczego nie zmieniają się. W przykładzie w tej sekcji przedstawiono sposób interakcji uprawnień obszaru roboczego i elementu.
Veronica i Marty współpracują ze sobą. Veronica jest właścicielem raportu, który chce podzielić się z Martą. Jeśli Veronica udostępni raport Marty, Marty będzie mogła uzyskać do niego dostęp niezależnie od roli obszaru roboczego, którą ma.
Załóżmy, że Marty ma rolę osoby przeglądanej w obszarze roboczym, w którym jest przechowywany raport. Jeśli Veronica zdecyduje się usunąć uprawnienia do elementów Marty z raportu, Marty nadal będzie mogła wyświetlać raport w obszarze roboczym. Marty będzie również mógł otworzyć raport z obszaru roboczego i wyświetlić jego zawartość. Dzieje się tak, ponieważ Marty ma uprawnienia do wyświetlania obszaru roboczego.
Jeśli Veronica nie chce, aby Marty wyświetlała raport, usunięcie uprawnień do elementów Marty z raportu nie wystarczy. Veronica musi również usunąć uprawnienia widza Marty z obszaru roboczego. Bez uprawnień osoby przeglądającego obszar roboczy Marty nie będzie mógł zobaczyć, że raport istnieje, ponieważ nie będzie mógł uzyskać dostępu do obszaru roboczego. Marty również nie będzie mogła korzystać z linku do sprawozdania, ponieważ nie ma dostępu do raportu.
Teraz, gdy Marty nie ma roli widza obszaru roboczego, jeśli Veronica zdecyduje się udostępnić raport jej ponownie, Marty będzie mógł go wyświetlić za pomocą linku Veronica udostępnia jej, bez dostępu do obszaru roboczego.
Przykład 3. Uprawnienia aplikacji Power BI
Podczas udostępniania raportów usługi Power BI często chcesz, aby adresaci mieli dostęp tylko do raportów, a nie do elementów w obszarze roboczym. W tym celu możesz używać aplikacji usługi Power BI lub udostępniać raporty bezpośrednio użytkownikom.
Ponadto można ograniczyć dostęp osoby przeglądającej do danych przy użyciu zabezpieczeń na poziomie wiersza(RLS), a zabezpieczenia na poziomie wiersza umożliwiają tworzenie ról, które mają dostęp do niektórych części danych, oraz ograniczanie wyników zwracanych tylko do tożsamości użytkownika.
Działa to dobrze w przypadku korzystania z modeli importu, ponieważ dane są importowane w modelu semantycznym, a adresaci mają dostęp do tego w ramach aplikacji. Dzięki funkcji DirectLake raport odczytuje dane bezpośrednio z usługi Lakehouse, a odbiorca raportu musi mieć dostęp do tych plików w jeziorze. Można to zrobić na kilka sposobów:
- Nadaj
ReadDatauprawnienie bezpośrednio lakehouse. - Przełącz poświadczenie źródła danych z Logowanie jednokrotne (SSO) na stałą tożsamość, która ma dostęp do plików w usłudze Lake.
Ponieważ zabezpieczenia na poziomie wiersza są definiowane w modelu semantycznym, dane będą najpierw odczytywane, a następnie będą filtrowane wiersze.
Jeśli jakiekolwiek zabezpieczenia są zdefiniowane w punkcie końcowym analizy SQL, na podstawie którego jest tworzony raport, zapytania automatycznie wracają do trybu DirectQuery. Jeśli nie chcesz tego domyślnego zachowania rezerwowego, możesz utworzyć nową usługę Lakehouse przy użyciu skrótów do tabel w oryginalnej usłudze Lakehouse, a nie zdefiniować zabezpieczeń na poziomie wiersza ani ols w usłudze SQL w nowej usłudze Lakehouse.