Ograniczanie dostępu do danych modelu usługi Power BI
Jako modeler danych skonfiguruj zabezpieczenia na poziomie wiersza, tworząc co najmniej jedną rolę. 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.
Napiwek
Można zdefiniować rolę, która nie zawiera żadnych reguł. W takim przypadku rola zapewnia dostęp do wszystkich wierszy wszystkich tabel modelu. Ta konfiguracja roli będzie odpowiednia dla użytkownika administracyjnego, który może wyświetlać wszystkie dane.
Role można tworzyć, weryfikować i zarządzać nimi w programie Power BI Desktop. W przypadku modeli usług Azure Analysis Services lub SQL Server Analysis Services można tworzyć, weryfikować role i zarządzać nimi przy użyciu narzędzi SQL Server Data Tools (SSDT).
Role można również tworzyć i zarządzać nimi przy użyciu programu SQL Server Management Studio (SSMS) lub za pomocą narzędzia innej firmy, takiego jak Tabular Editor.
Aby lepiej zrozumieć, jak zabezpieczenia na poziomie wiersza ograniczają dostęp do danych, obejrzyj poniższy animowany obraz.
Stosowanie zasad projektowania schematu gwiazdy
Zalecamy stosowanie zasad projektowania schematu gwiazdy w celu utworzenia modelu składającego się z tabel wymiarów i faktów. Typowe jest skonfigurowanie usługi Power BI w celu wymuszenia reguł filtrowania tabel wymiarów, co umożliwia efektywne propagowanie tych filtrów do tabel faktów.
Na poniższej ilustracji przedstawiono diagram modelu danych analizy sprzedaży firmy Adventure Works. Przedstawia on projekt schematu gwiazdy składający się z pojedynczej tabeli faktów o nazwie Sales. Pozostałe tabele to tabele wymiarów, które obsługują analizę miar sprzedaży według daty, terytorium sprzedaży, klienta, odsprzedawcy, zamówienia, produktu i sprzedawcy. Zwróć uwagę na relacje modelu łączące wszystkie tabele. Te relacje propagują filtry (bezpośrednio lub pośrednio) do tabeli Sales .
Ten projekt modelu obsługuje przykłady przedstawione w tej lekcji.
Definiowanie reguł
Wyrażenia reguły 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.
Napiwek
Aby dowiedzieć się więcej na temat kontekstu wiersza, zapoznaj się z modułem Dodawanie tabel obliczeniowych i kolumn do modeli programu Power BI Desktop. Chociaż w tym module opisano dodawanie obliczeń modelu, zawiera on jednostkę wprowadzającą i opisujący 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 na środkowym regionie.
'Region'[Region] = "Midwest"
W poniższych krokach wyjaśniono, jak usługa Power BI wymusza regułę. To:
Filtruje tabelę Region , co powoduje jeden widoczny wiersz (w polu Midwest).
Używa relacji modelu do propagowania filtru tabeli Region do tabeli State , co powoduje 14 widocznych wierszy (region Środkowy najaśniejszy składa się z 14 stanów).
Używa relacji modelu do propagowania filtru tabeli State do tabeli Sales , co powoduje tysiące widocznych wierszy (faktów sprzedaży dla stanów należących do regionu Midwest).
Najprostsza reguła statyczna, 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 żadnych danych tabeli. Może to być przydatne, gdy sprzedawcy mogą zobaczyć zagregowane wyniki sprzedaży (z tabeli Sales ), ale nie szczegóły na poziomie zamówienia.
Definiowanie reguł statycznych jest proste i skuteczne. Rozważ ich użycie, jeśli musisz utworzyć tylko kilka z nich, tak jak w przypadku firmy Adventure Works, w której istnieje tylko sześć regionów USA. Należy jednak pamiętać o wadach: skonfigurowanie reguł statycznych może wymagać znacznego nakładu pracy w celu utworzenia i skonfigurowania. Wymaga to również zaktualizowania i ponownego opublikowania zestawu danych po dołączeniu nowych regionów.
Jeśli istnieje wiele reguł do skonfigurowania i przewidujesz dodanie nowych reguł w przyszłości, rozważ utworzenie 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 trzech określonych funkcji języka DAX:
USERNAME lub USERPRINCIPALNAME — zwraca uwierzytelnionego użytkownika usługi Power BI jako wartość tekstową.
CUSTOMDATA — zwraca właściwość CustomData przekazaną w parametry połączenia. Narzędzia do raportowania spoza usługi Power BI łączące się z zestawem danych przy użyciu parametry połączenia mogą ustawić tę właściwość, taką jak program Microsoft Excel.
Uwaga
Należy pamiętać, że funkcja USERNAME zwraca użytkownika w formacie DOMAIN\username w przypadku użycia w programie Power BI Desktop. Jednak w przypadku użycia w usługa Power BI zwraca on format głównej nazwy użytkownika (UPN), na przykład username@adventureworks.com. Alternatywnie można użyć funkcji USERPRINCIPALNAME, która zawsze zwraca użytkownika w formacie głównej nazwy użytkownika.
Rozważ poprawiony projekt modelu, który zawiera teraz (ukrytą) tabelę AppUser . W każdym wierszu tabeli AppUser opisano 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. Umożliwiają one wymuszanie opartego na danych projektu zabezpieczeń na poziomie wiersza. Na przykład gdy sprzedawcy są dodawani lub usuwani z tabeli AppUser (lub są przypisani do różnych regionów), to podejście projektowe działa po prostu.
Weryfikowanie ról
Podczas tworzenia ról ważne jest przetestowanie ich w celu upewnienia się, że stosują poprawne filtry. W przypadku modeli danych utworzonych w programie Power BI Desktop istnieje funkcja Wyświetl jako , która umożliwia wyświetlanie raportu, gdy są wymuszane różne role, a inne wartości nazw użytkowników są przekazywane.
Konfigurowanie mapowań ról
Mapowania ról należy skonfigurować przed uzyskaniem dostępu do zawartości usługi Power BI przez użytkowników. Mapowanie ról obejmuje przypisywanie obiektów zabezpieczeń firmy Microsoft do ról. Obiekty zabezpieczeń mogą być kontami użytkowników lub grupami zabezpieczeń.
Napiwek
Jeśli to możliwe, dobrym rozwiązaniem jest mapowanie ról na grupy zabezpieczeń. W ten sposób będzie mniej mapowań i można delegować zarządzanie członkostwem grupy do administratorów sieci.
W przypadku modeli opracowanych przez program Power BI Desktop mapowanie ról jest zwykle wykonywane w usługa Power BI. W przypadku modeli usług Azure Analysis Services lub SQL Server Analysis Services mapowanie ról jest zwykle wykonywane w programie SSMS.
Aby uzyskać więcej informacji na temat konfigurowania zabezpieczeń na poziomie wiersza, zobacz:
Używanie logowania jednokrotnego (SSO) dla źródeł trybu DirectQuery
Jeśli model danych ma tabele DirectQuery, a ich źródło danych obsługuje logowanie jednokrotne, źródło danych może wymuszać uprawnienia do danych. W ten sposób baza danych wymusza zabezpieczenia na poziomie wiersza oraz zestawy danych i raporty usługi Power BI honorują zabezpieczenia źródła danych.
Należy wziąć pod uwagę, że firma Adventure Works ma usługę Azure SQL Database dla operacji sprzedaży, które znajdują się w tej samej dzierżawie co usługa Power BI. Baza danych wymusza zabezpieczenia na poziomie wiersza w celu kontrolowania dostępu do wierszy w różnych tabelach bazy danych. Możesz utworzyć model DirectQuery łączący się z tą bazą danych bez ról i opublikować go w usługa Power BI. Po ustawieniu poświadczeń źródła danych w usługa Power BI włączysz logowanie jednokrotne. Gdy użytkownicy raportu otwierają raporty usługi Power BI, usługa Power BI przekazuje swoją tożsamość do źródła danych. Następnie źródło danych wymusza zabezpieczenia na poziomie wiersza na podstawie tożsamości użytkownika raportu.
Aby uzyskać informacje na temat zabezpieczeń na poziomie wiersza usługi Azure SQL Database, zobacz Zabezpieczenia na poziomie wiersza.
Uwaga
Tabele obliczeniowe i kolumny obliczeniowe odwołujące się do tabeli DirectQuery ze źródła danych z uwierzytelnianiem za pomocą logowania jednokrotnego nie są obsługiwane w usługa Power BI.
Aby uzyskać więcej informacji na temat źródeł danych obsługujących logowanie jednokrotne, zobacz Single sign-on (SSO) for DirectQuery sources (Logowanie jednokrotne) dla źródeł trybu DirectQuery.