RLS, czyli bezpieczeństwo na poziomie wiersza w Power BI

Bezpieczeństwo na poziomie wierszy (RLS), w kontekście Power BI, odnosi się do ograniczenia wierszy danych, które określony użytkownik może zobaczyć podczas przeglądania raportu. Pozwala to lepiej kontrolować, co użytkownicy mogą zobaczyć w opublikowanym raporcie na podstawie konta logowania do usługi Power BI.

Przykładowo, korzystając z tej techniki, kierownik regionalny może przeglądać dane dla swojego regionu, ale nie dane dla innych menedżerów regionalnych. Dzięki takiemu podejściu do ochrony danych można opublikować pojedynczy raport lub dashboard (zarządzamy i utrzymujemy wtedy tylko jeden raport) zamiast kilku takich samych zasilonych innym zestawem danych.

Istnieją różne metody korzystania z RLS w usłudze Power BI. Zabezpieczenia na poziomie wiersza można skonfigurować jako zwykły tzw. statyczny RLS lub dynamiczny RLS.

Statyczny RLS oznacza, że definiujemy logikę zabezpieczeń, w postaci ról z przypisanym wyrażeniem filtrującym dane w pliku Power BI (.pbix), a dla każdej zmiany logiki musimy otworzyć plik PBIX, zastosować zmianę, zapisać plik i ponownie go opublikować.

Do tak zdefiniowanej roli należy już tylko na portalu przypisać użytkowników (najlepiej grupy domenowe) – od tego momentu użytkownik będący w takiej roli nie zobaczy innych wierszy niż te, które spełniają warunek z roli. Jednak uwaga – uczestnictwo danego użytkownika w więcej niż jednej roli jednocześnie może zakończyć ujawnieniem wszystkich danych! Należy zatem dobrze przetestować raport i założone role.

Dynamiczny RLS polega natomiast na definicji bezpieczeństwa utworzonej w powiązaniu z kontem użytkownika już w samych danych. Na razie nie brzmi to jakoś specjalnie ciekawie, skupmy się zatem na konkretnym przykładzie.

Gdy osoba X loguje się do systemu, z tabel danych, które są załadowane dodatkowo do modelu możemy odczytać, że osoba ta powinna mieć dostęp tylko do konkretnych faktur. W tabeli dynamicznego RLS, którą utworzyliśmy mamy bowiem powiązany login użytkownika z poszczególnymi identyfikatorami faktur. Ta metoda jest możliwa w usłudze Power BI przy użyciu funkcji języka DAX UserName() lub UserPrincipalName(). W dynamicznym RLS, aby zmienić logikę, wystarczy zatem dodać/edytować/usunąć rekordy w tabelach. To wszystko!

Zanim jednak prześledzimy proces tworzenia dynamicznego RLS, najpierw podsumujmy – aby zdefiniować dynamiczny RLS i role zabezpieczeń, niezbędne są: tabela użytkowników z identyfikatorem logowania oraz grupą, do której przynależą, tabela ról, odpowiednie relacje (tabela użytkowników filtruje tabelę ról, a ta filtruje tabelę faktów), przynajmniej jedna rola z założonym filtrem DAX z funkcjami UserName i UserPrincipalName.

Tabela użytkowników

Aby dynamiczne zabezpieczenia na poziomie wiersza działały, należy utworzyć tabelę wszystkich użytkowników. Tabela ta musi zawierać wykaz wszystkich użytkowników z polem będącym ich identyfikatorem logowania do raportu usługi Power BI oraz grupą, do której dany użytkownik należy. Tabela może pochodzić np. z Active Directory czy z listy Sharepoint.

Jeśli raport jest hostowany w usłudze Power BI, identyfikator logowania to adres e-mail, którego użytkownicy używają do logowania się do usługi Power BI. Jeśli raport jest hostowany na serwerze raportów usługi Power BI, identyfikator logowania to konto sieciowe, którego używa się do logowania się do serwera raportów.

Przykładowa tabela:

Tabela ról

Następnie przechodzimy do problemu tworzenia ról, dzięki którym można filtrować dane na podstawie grupy użytkownika. Musimy stworzyć tabelę przechowującą wszystkie skojarzenia.

Relacje

Teraz musimy połączyć tę tabelę zarówno z tabelą użytkowników, jak i z właściwą tabelą faktów. Ważne jest, aby tabela ról filtrowała inne tabele w modelu danych. Filtrowanie między tabelami w Power BI jest definiowane jako relacja. Musimy mieć relację z odpowiednim kierunkiem do innych tabel z danymi w modelu danych z tabeli ról.

Filtry DAX

Ostatnim elementem jest powiązanie bieżącego użytkownika z pocztą. Osiąga się to poprzez stworzenie roli:

W tabeli „user” dodajemy następujące wyrażenie DAX (username() pobiera credentials logującego się użytkownika):

Po opublikowaniu raportu otwieramy menu zabezpieczeń danego zbioru danych.

Na tym etapie musimy połączyć rolę utworzoną w Power BI Desktop z użytkownikami usługi powerbi.com. Klikamy Add i Save.

Podsumowując, co nastąpi: dane logowania użytkownika przefiltrują tabelę użytkowników, ta z kolei tabelę ról, co z kolei odfiltruje odpowiednie dane w tabeli faktów:

Osoba 1:

Osoba 2:

Łukasz Błaszczyk – BI Developer w Transition Technologies MS