Konfigurowanie zabezpieczeń na poziomie wiersza
Deweloperzy modeli danych konfigurują zabezpieczenia na poziomie wiersza przez utworzenie co najmniej jednej roli. Rola ma unikatową nazwę w modelu i zwykle zawiera co najmniej jedną regułę. Reguły wymuszają filtry w tabelach modelu przy użyciu wyrażeń filtrów języka DAX (Data Analysis Expressions).
Uwaga
Domyślnie model danych nie ma ról. Model danych bez ról oznacza, że użytkownicy (którzy mają uprawnienia do wykonywania zapytań dotyczących modelu danych) mają dostęp do wszystkich danych modelu.
Porada
Można zdefiniować rolę, która nie zawiera żadnych reguł. W tym przypadku rola zapewnia dostęp do wszystkich wierszy wszystkich tabel modelu. Ta konfiguracja roli byłaby odpowiednia dla użytkownika administratora, który może wyświetlać wszystkie dane.
W przypadku modeli opracowanych w usłudze Microsoft Power BI Desktop można tworzyć, weryfikować role i zarządzać nimi w Power BI Desktop. W przypadku modeli microsoft Azure Analysis Services lub SQL Server Analysis Services można tworzyć role, weryfikować je i zarządzać nimi przy użyciu narzędzi SQL Server Data Tools (SSDT).
Ponadto można tworzyć role i zarządzać nimi przy użyciu SQL Server Management Studio lub za pomocą narzędzia zewnętrznego, takiego jak tabelaryczna Redaktor.
Stosowanie star podmiotów zabezpieczeń projektu schematu
Pierwszym krokiem do osiągnięcia skutecznego rozwiązania zabezpieczeń na poziomie wiersza jest opracowanie dobrze zaprojektowanego modelu. Zalecamy stosowanie star podmiotów zabezpieczeń projektu schematu w celu utworzenia modelu składającego się z tabel wymiarów i faktów. Często usługa Power BI wymusza reguły filtrowania tabel wymiarów, a relacje modelu skutecznie propagują te filtry do tabel faktów.
Na poniższej ilustracji przedstawiono diagram modelu danych analizy sprzedaży Tailspin Toys. Przedstawia on projekt schematu star zawierający jedną tabelę faktów o nazwie Sales. Pozostałe cztery tabele to tabele wymiarów, które obsługują analizę miar sprzedaży według daty, stanu, regionu i produktu. Relacje modelu łączą wszystkie tabele. Te relacje propagują filtry (bezpośrednio lub pośrednio) do tabeli Sales .
Ten projekt modelu obsługuje przykłady przedstawione w tym module.
Definiowanie reguł
Wyrażenia reguł są oceniane w kontekście wiersza. Kontekst wiersza oznacza, że wyrażenie jest obliczane dla każdego wiersza przy użyciu wartości kolumn tego wiersza. Gdy wyrażenie zwraca wartość TRUE, użytkownik może "zobaczyć" wiersz.
Porada
Aby dowiedzieć się więcej na temat kontekstu wiersza, zobacz moduł Dodawanie tabel obliczeniowych i kolumn do Power BI Desktop modeli. W tym module opisano proces dodawania obliczeń modelu, ale zawiera również jednostkę, która wprowadza i opisuje kontekst wiersza.
Możesz zdefiniować reguły, które są statyczne lub dynamiczne.
Reguły statyczne
Reguły statyczne używają wyrażeń języka DAX odwołujących się do stałych.
Rozważmy następującą regułę zastosowaną do tabeli Region , która ogranicza dostęp do danych do sprzedaży w Nowej Anglii:
'Region'[Region] = "New England"
Poniższe kroki wyjaśniają proces wymuszania reguły przez usługę Power BI.
Przefiltruj tabelę Region , co spowoduje jedno widoczne wiersze (w przypadku Nowej Anglii).
Użyj relacji modelu, aby propagować filtr tabeli Region do tabeli State , co powoduje sześć widocznych wierszy (region Nowej Anglii zawiera sześć stanów).
Użyj relacji modelu, aby propagować filtr tabeli State do tabeli Sales , co powoduje tysiące widocznych wierszy (faktów sprzedaży dla stanów należących do regionu Nowej Anglii).
Najprostsza statyczna reguła, którą można utworzyć, ogranicza dostęp do wszystkich wierszy tabeli. Rozważmy następującą regułę zastosowaną do tabeli Sales Details (szczegóły sprzedaży ) (nie przedstawiono jej na diagramie modelu):
FALSE()
Ta reguła gwarantuje, że użytkownicy nie będą mogli uzyskać dostępu do danych tabeli. Reguła może być przydatna, gdy sprzedawcy mogą wyświetlać zagregowane wyniki sprzedaży (z tabeli Sales ), ale nie szczegóły na poziomie zamówienia.
Definiowanie reguł statycznych jest proste i skuteczne. Rozważ użycie reguł statycznych, jeśli musisz utworzyć tylko kilka z nich, tak jak w przypadku aplikacji Tailspin Toys, która ma tylko sześć regionów. Należy jednak pamiętać o pewnych wadach: skonfigurowanie reguł statycznych może wymagać znacznego nakładu pracy w celu utworzenia i skonfigurowania. Reguły statyczne wymagają również zaktualizowania i ponownego opublikowania zestawu danych po wprowadzeniu nowych regionów.
Jeśli istnieje kilka reguł konfiguracji i przewidujesz, że w przyszłości zostaną dodane nowe reguły, rozważ użycie reguł dynamicznych.
Reguły dynamiczne
Reguły dynamiczne używają określonych funkcji języka DAX, które zwracają wartości środowiskowe (w przeciwieństwie do stałych). Wartości środowiskowe są zwracane z następujących określonych funkcji języka DAX:
USERNAME lub USERPRINCIPALNAME: w przypadku korzystania ze scenariusza dla organizacji te funkcje zwracają wartość tekstową opisową uwierzytelnionego użytkownika. W przypadku korzystania ze scenariusza Dla klientów zwracają wartość tekstową przekazywaną przez aplikację.
CUSTOMDATA: W przypadku korzystania ze scenariusza for your organization ta funkcja zwraca właściwość CustomData przekazaną w parametry połączenia. W przypadku korzystania ze scenariusza For your customers zwraca wartość tekstową przekazywaną przez aplikację.
Uwaga
Funkcja USERNAME zwróci użytkownika w formacie DOMAIN\username , gdy jest używany w Power BI Desktop. Jednak w przypadku użycia w usługa Power BI zostanie zwrócony format głównej nazwy użytkownika (UPN), na przykład username@tailspintoys.com. Alternatywnie możesz użyć USERPRINCIPALNAME funkcji , która zawsze zwraca użytkownika w formacie UPN.
Rozważ poprawiony projekt modelu, który zawiera teraz (ukrytą) tabelę AppUser . Każdy wiersz tabeli AppUser opisuje nazwę użytkownika i region. Relacja modelu z tabelą Region propaguje filtry z tabeli AppUser .
Poniższa reguła zastosowana do tabeli AppUser ogranicza dostęp do danych do regionów uwierzytelnionego użytkownika:
'AppUser'[UserName] = USERPRINCIPALNAME()
Definiowanie reguł dynamicznych jest proste i skuteczne, gdy tabela modelu przechowuje wartości nazw użytkowników. Reguły dynamiczne umożliwiają wymuszanie projektu zabezpieczeń na poziomie wiersza opartym na danych . Na przykład gdy sprzedawcy są dodawani do lub usuwani z tabeli AppUser (lub są przypisani do różnych regionów), to podejście projektowe działa.
Ważne
W przypadku korzystania ze scenariusza USERNAMEfor your customers funkcja i USERPRINCIPALNAME nie musi zwracać rzeczywistej nazwy użytkownika. Zamiast tego aplikacja może przekazać dowolną wartość tekstowa, aby filtrować model.
Walidacja ról
Podczas tworzenia ról upewnij się, że testujesz je, aby upewnić się, że stosują poprawne filtry. W przypadku modeli danych utworzonych w Power BI Desktop funkcja Wyświetl jako umożliwia wyświetlanie raportu w przypadku wymuszania różnych ról i przekazywania różnych wartości nazwy użytkownika.
Konfigurowanie mapowań ról
Mapowanie ról odbywa się inaczej w zależności od scenariusza osadzania.
W przypadku korzystania ze scenariusza Dla organizacji należy skonfigurować mapowania ról z wyprzedzeniem użytkowników, którzy uzyskują dostęp do zawartości usługi Power BI. Mapowanie ról obejmuje przypisywanie Microsoft Azure Active Directory obiektów zabezpieczeń do ról. Obiekty zabezpieczeń mogą być kontami użytkowników lub grupami zabezpieczeń.
Porada
Jeśli to możliwe, dobrym rozwiązaniem jest mapowanie ról na grupy zabezpieczeń. W ten sposób będzie istnieć mniej mapowań, a następnie można delegować zarządzanie członkostwem w grupie do administratorów sieci.
W przypadku Power BI Desktop opracowanych modeli mapowanie ról jest zwykle wykonywane w usługa Power BI. W przypadku modeli Azure Analysis Services lub SQL Server Analysis Services mapowanie ról jest zwykle wykonywane w programie SQL Server Management Studio (SSMS).
W przypadku korzystania ze scenariusza For your customers aplikacja wykonuje mapowanie ról w czasie wykonywania. Logika aplikacji ustawia co najmniej jedną efektywną tożsamość w celu wymuszania zabezpieczeń na poziomie wiersza. Ustawienie skutecznych tożsamości zostało opisane w dalszej części tego modułu.
Aby uzyskać więcej informacji na temat konfigurowania zabezpieczeń na poziomie wiersza, zobacz następujące artykuły: