BI

Row Level Security w modelu Tabular Analysis Services

Wrzesień 19, 2018 0
Podziel się:

W tym artykule opisuję proces wdrożenia dynamicznego zabezpieczania dostępu do danych w modelu Tabular Analysis Services.

Row Level Security umożliwia lepszą – bardziej dopasowaną do użytkownika kontrolę dostępu do danych. Tworząc poziom zabezpieczenia danych w modelu Tabular nie ograniczamy dostępu tylko do poszczególnych tabel, ale filtrujemy wiersze w tabelach określając w ten sposób poziom dostępu do danych dla zdefiniowanych ról. Do danej roli są przypisani poszczególni użytkownicy. W ten sposób definiujemy do jakiego zakresu danych poszczególni użytkownicy będą mieli dostęp.

Dodając użytkownika do danej roli określamy, po jakich poświadczeniach będzie identyfikowany podczas łączenia się do modelu – w moim przykładzie jest to login domenowy. Użytkownicy będą identyfikowani po loginie jakim posługują się logując do platformy, na której dany raport jest umieszczony (np. Reporting Services) lub łącząc się bezpośrednio do modelu z poziomu Excela, gdzie przeglądają dane przy użyciu tabeli przestawnej.

To co musimy zrobić, aby stworzyć Row Level Security (RLS) to:

  • dodać do modelu tabelę ze spisem loginów wszystkich użytkowników oraz zapewnić aby model był filtrowany na podstawie dodanych atrybutów tabeli,
  • zapewnić aby użytkownik był „rozpoznawany” podczas logowania,
  • stworzyć role z przypisanymi użytkownikami oraz zdefiniować dla każdej z nich zakres filtrowania danych w modelu (określając w ten sposób poziom dostępu do danych).

RLS wdrażamy do modelu z poziomu projektu w SQL Server Data Tools – Visual Studio.

Stworzenie tabeli ze spisem loginów użytkowników

Do modelu musimy dodać tabelę ze spisem loginów oraz powiązanym im ‘ID’, po którym użytkownicy będą jednoznacznie identyfikowani. W moim przykładowym modelu jest to tabela nazwana ‘Security table’ z atrybutami: ‘SIIUSERLOGIN’ (login) oraz ‘ID Worker’ (ID użytkownika). Atrybut ‘ID Worker’ jest wykorzystywany w całym modelu do identyfikowania użytkowników (pracowników). Nie musimy tworzyć relacji tabeli ‘Security table’ do innej tabeli w modelu, ponieważ powiązanie zapewnimy za pomocą odpowiednich funkcji DAX, definiując je podczas tworzenia roli.

Tabela użytkowników

Rys.1 Tabela użytkowników

Po rozpoznaniu użytkownika na podstawie loginu w tabeli ‘Security table’ odpowiedni wiersz z atrybutu ‘ID Worker’ identyfikujący użytkownika będzie powiązany z wybraną w modelu tabelą zawierającą atrybut ‘ID Worker’, a tabela ta będąca częścią modelu danych będzie propagowała filtr na pozostałe tabele, pokazując dane tylko dla wybranej wartości.

Powiązanie tabeli z modelem

Rys.2 Powiązanie tabeli z modelem

Należy też zwrócić uwagę na zaznaczenie opcji „Apply the Filter Direction when using Row Level Security” w ustawieniach relacji dla tabeli odpowiedzialnej za propagowanie filtru na cały model, aby filtrowanie RLS działało.

Ustawienia relacji

Rys.3 Ustawienia relacji

Stworzenie roli na poziomie Visual Studio

Aby utworzyć role otwieramy w Visual Studio okno „Role Manager” – z menu górnego paska Model -> Roles ->New. Nadajemy nazwę oraz określamy poziom dostępu np. Permission ->Read

Role Manager

Rys.4 Role Manager

W zakładce Row Filters używamy funkcji Dax do określenia zakresu filtrowania danych na poziomie wierszy w  poszczególnych tabelach. Określamy  w tym miejscu również powiązanie wartości z tabeli loginów i ID – ‘Security table’ do tabeli wybranej do propagowania filtru. Zapewniamy to wykorzystując funkcje DAX:

LOOKUPVALUE() – przypisanie danej wartości z tabeli ze spisem loginów i ID – ‘Security table’ do tabeli odpowiedzialnej za filtrowanie modelu według wyszukanej wartości. Ważne! Używając  funkcji LOOKUPVALUE nie musimy tworzyć relacji pomiędzy przeszukiwaną tabelą, a tabelą gdzie funkcję stosujemy.

USERNAME() – zwraca nazwę użytkownika z poświadczeń dostarczonych do systemu w czasie połączenia.

Zastosowanie razem funkcji LOOKUPVALUE oraz USERNAME – sczyta nazwę użytkownika z  dostarczonych poświadczeń, a następnie przeszuka tabelę ‘Security table’ i po znalezieniu loginu przypisze odpowiadającą wartość atrybutu ‘ID Worker’, jako argument do tabeli ‘Project by directworker’, która zastosuje ten filtr na wszystkie dane w modelu (wg logiki utworzonych relacji w całym modelu).

Row Filters

Rys.5 Row Filters

W zakładce Members dodajemy użytkowników, dla których filtrowanie określone dla danej roli będzie mieć zastosowanie: Role Manager->Members->Add… (domena\nazwa użytkownika)

Tabele ze spisem loginów użytkowników ‘Security table’ możemy ukryć w modelu oraz za pomocą polecenia =FALSE() (na poziomie zakładki Row Filters ) zablokować możliwość przeglądania danych, tak żeby członkowie danej roli nie mieli do niej wglądu.

Testowanie działania filtru dla poszczególnych roli

Kiedy role zostały utworzone należy przetestować poprawność działania – filtrowania danych. W tym celu potrzebujemy połączyć się do modelu jako użytkownik danej roli. Możemy dokonać tego poprzez wybranie w Visual Studio z menu górnego paska opcji „Analyze in Excel”. Następnie łącząc się z modelem z poziomu Excela możemy przeglądać model z odpowiednio przefiltrowanymi danymi  per użytkownik lub per rola.

Analyze in Excel

Rys.6 Analyze in Excel

Per użytkownik:

Model->Analyze in Excel, zaznaczamy opcje ->Other Windows User

Wpisujemy login (domena\nazwa użytkownika) wybranego członka danej roli, następnie z poziomu Excela mamy wgląd w dane jakie są widoczne dla tego użytkownika po zalogowaniu.

Per rola:

Model->Analyze in Excel, zaznaczamy opcje  ->Role

Wybieramy daną rolę, którą wcześniej stworzyliśmy, następnie z poziomu Excela mamy wgląd w dane, jakie są widoczne dla każdego użytkownika tej roli.

Oceń ten post
Kategorie: BI
Paweł Kuzioła
Autor: Paweł Kuzioła
W SII pracuję jako analityk biznesowy oraz bazodanowy. Moja praca polega na wspieraniu procesów biznesowych poprzez dostarczanie rozwiązań raportowych dla klientów zewnętrznych. W swojej pracy wykorzystuje technologie Microsoft BI

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz