Row Level Security — jeden raport, różne dane dla różnych osób

Czym jest Row Level Security w praktyce

Row Level Security (RLS) to filtr nakładany na dane w modelu Power BI — zależny od tego, kto ogląda raport. Nie zmienia wyglądu raportu, nie zmienia jego struktury. Zmienia tylko to, które wiersze danych są widoczne dla konkretnej osoby.

Weźmy konkretny przykład: portfel 8 budynków, 3 regionalni dyrektorzy i 8 zarządców obiektów. Wszyscy dostają ten sam link do raportu. Ale każdy widzi coś innego.

Jak to działa od strony użytkownika

Zarządca budynku B3 otwiera raport — widzi dane tylko dla B3. Nie widzi żadnego komunikatu o filtrowaniu. Nie wie, że coś jest ukryte. Raport wygląda tak, jakby dotyczył tylko jego budynku — bo dla niego tak właśnie jest.

Dyrektor Regionu Północ otwiera ten sam link — widzi B1, B2 i B3 razem. Może porównywać budynki w swoim regionie. CFO otwiera ten sam link — widzi wszystkie osiem. Nikt nie widzi danych innych osób i nikt nie wie, że inni widzą coś innego.

Z perspektywy zarządzającego raportem: jeden raport do utrzymania. Jeśli dodaję nowy wykres albo zmieniam definicję wskaźnika — zmieniam raz i działa dla wszystkich ról jednocześnie. Bez RLS utrzymanie 8 osobnych raportów oznacza 8-krotną pracę przy każdej zmianie.

Jak wygląda konfiguracja od kuchni

Konfiguruję RLS w trzech krokach — bez wchodzenia w szczegóły techniczne, bo to nie jest istotne dla klienta:

1. 1 Definiuję role — np. "Zarządca", "Dyrektor Regionalny", "CFO". Każda rola ma zestaw uprawnień do danych.
2. 2 Tabela mapowania — klient dostarcza lub zatwierdza tabelę: adres e-mail użytkownika → budynek(i). Zarządca Jan Kowalski widzi B3, Dyrektor Anna Nowak widzi B1, B2, B3. Ta tabela jest źródłem uprawnień.
3. 3 Testy z prawdziwymi kontami — przed wdrożeniem sprawdzam widok każdej roli i każdego użytkownika. Klient zatwierdza, że widzi to co powinien.

Utrzymanie w czasie jest proste: nowy zarządca albo zmiana przypisania budynku to aktualizacja jednej tabeli — kilkanaście minut, bez dotykania samego raportu.

Kiedy RLS ma sens — a kiedy nie

Ile czasu zajmuje wdrożenie

Wdrożenie RLS to kilka dni pracy — zależy od złożoności hierarchii uprawnień. Prosta struktura (jedna rola poniżej CFO, jedno mapowanie użytkownik–budynek) to jeden dzień. Złożona hierarchia z kilkoma poziomami, różnymi regułami dla różnych typów danych i testami dla kilkunastu kont to kilka dni.

Co wchodzi w zakres: projektowanie ról i hierarchii, budowa tabeli mapowania, konfiguracja filtrów, testy z prawdziwymi kontami, dokumentacja uprawnień dla administratora. Utrzymanie — aktualizacja mapowania przy zmianach organizacyjnych — jest szybkie i może wchodzić w umowę serwisową.

Jedna pułapka — RLS tam, gdzie go nie potrzeba

Regularnie słyszę prośby o RLS "bo to brzmi poważnie". Zanim zacznę konfigurację, pytam zawsze: kto konkretnie nie powinien widzieć czego — i dlaczego? Zdarza się, że odpowiedź brzmi "no właściwie wszyscy powinni widzieć to samo". W takim przypadku wdrożenie RLS komplikuje utrzymanie raportu bez żadnej korzyści.

Warto też wiedzieć, że RLS to filtr prezentacyjny w warstwie Power BI — nie mechanizm ochrony przed dostępem do surowych danych w bazie. Ktoś z bezpośrednim dostępem do bazy analitycznej nadal może odczytać wszystkie dane. RLS rozwiązuje problem "kto co widzi w raporcie" — nie problem "kto ma dostęp do danych". To dwa różne zagadnienia.

Podsumowanie

RLS to narzędzie do konkretnego problemu: wiele osób, różne zakresy danych, jeden raport do utrzymania. Nie jest domyślnym elementem każdego projektu BI — jest rozwiązaniem konkretnego wymagania. Zanim zdecydujesz, że go potrzebujesz, warto zadać jedno pytanie: ile osób korzysta z raportów i czy naprawdę powinny widzieć różne dane?

Najczęstsze pytania