Power BI: Row-Level Security w 2026 — 9 pułapek (userprincipalname, role, composite models)

Wprowadzenie: RLS w Power BI w 2026 — co się zmieniło i dlaczego wciąż boli

Row-Level Security w Power BI nadal jest podstawowym mechanizmem ograniczania widoczności danych do właściwych użytkowników, zespołów i obszarów biznesowych. Sama idea pozostaje prosta: ten sam raport może pokazywać różne wycinki danych w zależności od tego, kto go otwiera. W praktyce jednak rok 2026 nie przyniósł końca problemów z RLS — przeciwnie, wraz z rosnącą złożonością modeli semantycznych, integracji tożsamości i architektur hybrydowych łatwiej o błędy, które nie są widoczne na pierwszy rzut oka.

Największa zmiana nie polega na tym, że RLS działa dziś zupełnie inaczej, lecz na tym, że działa w coraz bardziej złożonym środowisku. Power BI jest częściej wdrażany w organizacjach z wieloma źródłami danych, z modelami mieszanymi, z raportami opartymi o współdzielone modele semantyczne oraz z rozbudowanym zarządzaniem dostępem w chmurze. To oznacza, że zabezpieczenie na poziomie wiersza nie jest już tylko kwestią wpisania prostego warunku filtrowania. Trzeba rozumieć, jak zachowuje się tożsamość użytkownika, jak propagują się filtry w modelu i gdzie kończy się realna ochrona, a zaczyna jedynie wrażenie bezpieczeństwa.

W 2026 roku RLS najczęściej stosuje się w kilku typowych scenariuszach:

• ograniczanie danych handlowych do regionu, oddziału lub opiekuna klienta,
• separacja danych między jednostkami organizacyjnymi lub spółkami,
• udostępnianie jednego raportu wielu odbiorcom bez duplikowania modeli,
• wspieranie zgodności i minimalizacji dostępu do danych wrażliwych,
• kontrola widoczności danych w rozwiązaniach self-service, gdzie wielu użytkowników pracuje na tym samym modelu.

Brzmi to dojrzale i przewidywalnie, ale najwięcej problemów bierze się z rozjazdu między projektem logicznym a rzeczywistym wykonaniem. To, co działa w Power BI Desktop, nie zawsze zachowuje się identycznie po publikacji do usługi. To, co wygląda poprawnie w prostym modelu importowanym, może dawać nieoczywiste skutki w modelu z DirectQuery albo w rozwiązaniu opartym na composite models. Dodatkowo sam fakt przypisania użytkownika do roli nie gwarantuje jeszcze, że filtr ograniczy dokładnie te rekordy, które powinien.

Właśnie dlatego RLS wciąż „boli”. Nie dlatego, że jest nowy lub niedojrzały, ale dlatego, że jest wrażliwy na detale. Błąd w identyfikacji użytkownika, niepełne mapowanie uprawnień, źle zaprojektowana relacja albo niewłaściwe założenie co do działania miar mogą prowadzić do dwóch równie groźnych rezultatów: użytkownik zobaczy za mało danych i zgłosi problem biznesowy albo zobaczy za dużo i powstanie incydent bezpieczeństwa.

Warto też odróżnić dwa poziomy myślenia o RLS. Pierwszy to poziom biznesowy: kto ma widzieć jakie dane i według jakiej reguły. Drugi to poziom techniczny: w jaki sposób model semantyczny, role, relacje i kontekst zapytań faktycznie wymuszają tę regułę. Dopiero zgodność tych dwóch poziomów daje rozwiązanie, któremu można ufać.

W 2026 roku dobre wdrożenie RLS wymaga więc nie tylko znajomości funkcji i ustawień, ale także ostrożności projektowej. Trzeba przewidzieć różnice między środowiskami, zadbać o spójność tożsamości, świadomie modelować uprawnienia i rozumieć ograniczenia wynikające z architektury danych. Bez tego nawet poprawnie skonfigurowany mechanizm może zachowywać się inaczej, niż zakładał autor raportu.

Najważniejsza zasada na start jest prosta: RLS nie jest dodatkiem do modelu, tylko częścią jego logiki. Jeśli potraktuje się go jako późny etap konfiguracji, zaczyna generować wyjątki, obejścia i trudne do wykrycia luki. Jeśli uwzględni się go od początku, staje się przewidywalnym elementem architektury raportowania.

Pułapki 1–2: USERPRINCIPALNAME() vs USERNAME() — tożsamość, formaty loginów, różnice między Desktop/Service/Gateway

W praktyce Row-Level Security bardzo często psuje się nie dlatego, że logika filtra jest zła, ale dlatego, że model porównuje nie ten identyfikator użytkownika, który faktycznie trafia do Power BI w danym środowisku. Dwie najczęściej mylone funkcje to USERPRINCIPALNAME() oraz USERNAME(). Na pierwszy rzut oka obie odpowiadają na pytanie „kto ogląda raport?”, ale ich zachowanie nie jest identyczne i właśnie stąd biorą się pierwsze kosztowne pomyłki.

USERPRINCIPALNAME() zwykle zwraca login w formacie zbliżonym do adresu e-mail, czyli taki, jaki organizacje najczęściej przechowują w katalogu tożsamości i tabelach uprawnień. Z kolei USERNAME() może zwracać inny format, zależny od miejsca uruchomienia, sposobu uwierzytelniania i konfiguracji. W jednych scenariuszach będzie wyglądał podobnie do UPN, w innych przyjmie postać domena-konto, a to oznacza, że prosty warunek RLS może działać poprawnie w teście i całkowicie zawieść po publikacji.

Pierwsza pułapka polega więc na założeniu, że tożsamość użytkownika ma zawsze ten sam format. To błędne założenie. Power BI Desktop, Power BI Service i połączenia przechodzące przez gateway nie zawsze prezentują użytkownika w ten sam sposób. Jeśli tabela bezpieczeństwa zawiera adresy e-mail, a funkcja zwraca nazwę konta w innym formacie, filtr nie znajdzie dopasowania. Efekt bywa dwojaki: użytkownik nie widzi nic albo widzi dane niezgodnie z oczekiwaniem projektu.

Druga pułapka to przekonanie, że test lokalny w Desktop wystarcza. Nie wystarcza. W Desktop można uzyskać wynik, który wygląda poprawnie, ale po wdrożeniu do usługi ten sam model zaczyna filtrować dane inaczej, bo zmienia się kontekst tożsamości. To jeden z najbardziej mylących problemów RLS: logika biznesowa wydaje się dobra, a mimo to publikacja zmienia rezultat. W organizacjach korzystających z hybrydowej tożsamości, wielu domen, aliasów lub starszych mechanizmów logowania ryzyko takiej rozbieżności jeszcze rośnie.

Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. W 2026 roku problem nie zniknął, choć środowiska są dojrzalsze. Powód jest prosty: nowoczesne modele coraz częściej łączą wiele źródeł danych, różne tryby połączeń i więcej niż jeden punkt uwierzytelniania. Im bardziej złożona architektura, tym większa szansa, że identyfikator użytkownika będzie wyglądał inaczej zależnie od miejsca wykonania zapytania. Dlatego wybór między USERPRINCIPALNAME() i USERNAME() nie jest detalem technicznym, tylko decyzją projektową wpływającą na bezpieczeństwo i przewidywalność działania raportu.

• USERPRINCIPALNAME() jest zwykle bezpieczniejszym wyborem tam, gdzie uprawnienia mapowane są do adresów e-mail lub identyfikatorów Entra ID.
• USERNAME() bywa użyteczne, ale częściej wymaga ostrożności, bo jego format jest bardziej zależny od środowiska.
• Desktop nie jest źródłem prawdy dla testów tożsamości; wynik trzeba potwierdzić także w usłudze.
• Gateway i źródła lokalne mogą wprowadzać dodatkowe różnice w tym, jak interpretowany jest użytkownik.
• Spójność formatu między funkcją DAX a tabelą uprawnień jest ważniejsza niż samo to, która funkcja wydaje się „popularniejsza”.

Najpraktyczniejsza zasada jest prosta: zanim zbudujesz regułę RLS, ustal jaki dokładnie identyfikator użytkownika będzie porównywany i w jakim formacie pojawi się on po publikacji. W wielu modelach to nie RLS jest trudny, tylko błędne założenie o tożsamości. A gdy to założenie jest nietrafione, nawet poprawnie zaprojektowany filtr zachowuje się jakby był zepsuty.

Pułapki 3–4: Mapowanie ról i tabele uprawnień — modelowanie, granularity, wielorole, brakujące rekordy

W wielu wdrożeniach problem z RLS nie wynika z samej składni DAX, ale z tego, jak zaprojektowano mapowanie użytkownika do zakresu danych. To właśnie tutaj najczęściej pojawiają się dwa kosztowne błędy: zbyt uproszczone role oraz źle zaprojektowana tabela uprawnień. Efekt bywa skrajny: użytkownik widzi za dużo, nie widzi nic albo działa to poprawnie tylko dla części przypadków.

W praktyce warto oddzielić dwie rzeczy:

• rolę techniczną — czyli definicję reguły RLS w modelu,
• mapowanie biznesowe — czyli informację, kto ma dostęp do jakiego zakresu danych.

Gdy te dwa poziomy zostaną zmieszane, model szybko przestaje być skalowalny. Tworzenie osobnej roli dla każdego działu, regionu lub użytkownika zwykle wygląda prosto tylko na początku. Przy większej liczbie wyjątków prowadzi do ręcznego utrzymania, trudnego testowania i większego ryzyka błędów.

Pułapka 3: Role projektowane „na skróty” zamiast sensownego mapowania

Najczęstszy antywzorzec to założenie, że role mają odzwierciedlać strukturę organizacyjną 1:1. Przykład: osobna rola dla sprzedaży, osobna dla finansów, osobna dla regionu północ, osobna dla regionu południe, a potem kolejne kombinacje wyjątków. Taki układ szybko robi się nieczytelny.

Znacznie bezpieczniejsze jest podejście, w którym:

• definiujesz niewielką liczbę ról technicznych,
• dostęp do konkretnych wierszy trzymasz w tabeli uprawnień,
• logika bezpieczeństwa opiera się na relacjach i mapowaniu użytkownika do kluczy biznesowych.

W uproszczeniu: rola nie powinna przechowywać listy wyjątków „na sztywno”, jeśli te wyjątki zmieniają się operacyjnie. Lepiej, aby rola odwoływała się do tabeli, którą można aktualizować bez przebudowy całej logiki bezpieczeństwa.

Typowy uproszczony wzorzec wygląda tak:

[Login] = USERPRINCIPALNAME()

ale sama zgodność loginu z rekordem w tabeli użytkowników to jeszcze za mało. Trzeba zdecydować, do czego użytkownik jest mapowany: regionu, jednostki organizacyjnej, klienta, magazynu, spółki, a czasem kilku z tych poziomów jednocześnie.

Jak projektować tabelę uprawnień

Dobra tabela uprawnień jest zwykle tabelą pomostową między użytkownikiem a zakresem danych. Powinna być zaprojektowana tak, aby odpowiadała realnym regułom biznesowym, a nie wygodzie chwilowego obejścia problemu.

Najczęściej zawiera:

• identyfikator użytkownika lub login,
• klucz zakresu dostępu, np. region, dział, jednostkę, klienta,
• opcjonalnie typ uprawnienia,
• opcjonalnie daty obowiązywania, jeśli dostęp jest czasowy.

Kluczowa decyzja dotyczy ziarnistości takiej tabeli.

Pułapka 4: Zła granularność i brakujące rekordy

Jeśli tabela uprawnień jest zbyt ogólna, użytkownik może dostać szerszy dostęp niż powinien. Jeśli jest zbyt szczegółowa, model staje się ciężki, trudny do utrzymania i podatny na luki wynikające z braków w danych referencyjnych.

Przykładowe poziomy granularności:

Najlepszy poziom zależy od tego, na jakim poziomie naprawdę podejmowane są decyzje o dostępie. Jeśli biznes nadaje uprawnienia per region, nie ma sensu schodzić od razu do poziomu dokumentu. Jeśli jednak istnieją częste wyjątki dla konkretnych klientów lub jednostek, zbyt gruba granularność będzie powodować nadmiarowy dostęp.

Drugi częsty problem to brakujące rekordy w tabeli uprawnień. Taki brak może oznaczać dwie zupełnie różne rzeczy:

• bezpieczny brak dostępu — użytkownik nie powinien widzieć nic,
• błąd danych administracyjnych — użytkownik powinien mieć dostęp, ale mapowanie nie zostało uzupełnione.

Z perspektywy bezpieczeństwa domyślna zasada powinna być prosta: brak mapowania oznacza brak dostępu. To podejście minimalizuje ryzyko ujawnienia danych. Jednocześnie operacyjnie trzeba umieć odróżnić poprawny brak od błędu konfiguracji, bo inaczej dział wsparcia będzie dostawał zgłoszenia typu „raport jest pusty”, bez szybkiej diagnozy przyczyny.

Wielorole i użytkownicy z kilkoma zakresami dostępu

W rzeczywistych modelach jeden użytkownik rzadko pasuje do jednego prostego wzorca. Często ma dostęp do kilku regionów, kilku spółek albo łączy funkcję operacyjną z nadzorczą. Wtedy pojawia się problem wieloról — nie tylko w sensie przypisania do wielu ról w Power BI, ale też wielu rekordów mapujących w tabeli uprawnień.

Najbezpieczniej zakładać, że użytkownik może mieć wiele dozwolonych zakresów, a model powinien to obsłużyć jawnie. Oznacza to zwykle relację typu wiele-do-wielu lub tabelę pomostową, która nie wymusza sztucznego „jednego głównego przypisania”. Próba spłaszczania takich przypadków do jednej kolumny lub jednej wartości kończy się utratą części uprawnień albo dodawaniem wyjątków poza modelem.

Warto też pamiętać, że biznesowe „role” i role RLS to nie zawsze to samo. Na przykład:

• rola biznesowa może oznaczać stanowisko lub funkcję,
• rola RLS ma ograniczać zakres wierszy widocznych w danych.

To rozróżnienie pomaga uniknąć modelu, w którym nazwy ról brzmią sensownie dla organizacji, ale nie przekładają się jasno na filtr danych.

Na co uważać przy modelowaniu

• Nie koduj wyjątków bezpośrednio w wielu rolach, jeśli można je trzymać w danych.
• Nie zakładaj pojedynczego przypisania użytkownika, jeśli w praktyce dostęp bywa wielokrotny.
• Nie projektuj tabeli uprawnień na poziomie bardziej ogólnym niż realna polityka dostępu.
• Nie traktuj brakujących rekordów jako drobnego błędu jakości danych — w RLS to element krytyczny.
• Nie mieszaj pojęć organizacyjnych z techniczną logiką filtracji, jeśli utrudnia to utrzymanie modelu.

Dobrze zaprojektowane mapowanie ról i tabel uprawnień powinno być jednocześnie:

• czytelne dla osoby utrzymującej model,
• elastyczne wobec zmian organizacyjnych,
• restrykcyjne domyślnie, gdy danych mapujących brakuje,
• spójne z rzeczywistym poziomem nadawania dostępu.

Jeżeli ten etap zostanie zaprojektowany źle, późniejsze poprawki w DAX, relacjach czy testach zwykle tylko maskują problem, zamiast go rozwiązać u źródła.

Pułapki 5–6: Relacje i kierunki filtrowania — aktywne/nieaktywne relacje, bidirectional filters, propagacja filtrów

W praktyce RLS bardzo często „psuje się” nie przez samą definicję roli, ale przez to, jak filtr ma przejść przez model. Reguła wygląda poprawnie, tabela uprawnień zawiera właściwe wiersze, a mimo to użytkownik widzi za dużo albo za mało danych. Powód bywa prosty: filtr bezpieczeństwa nie propaguje się tak, jak zakładano.

W Power BI w 2026 nadal obowiązuje ta sama brutalna zasada: RLS działa tak dobrze, jak dobrze zaprojektowane są relacje. Jeśli ścieżka filtrowania jest niejednoznaczna, oparta na relacji nieaktywnej albo wymaga wymuszenia dwukierunkowego przepływu filtrów, szybko pojawiają się trudne do wykrycia błędy. Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności.

Pułapka 5: Relacja istnieje, ale filtr bezpieczeństwa nie dociera tam, gdzie trzeba

Najczęstsze założenie brzmi: „skoro tabele są połączone, to RLS na pewno zadziała”. Niestety nie zawsze. Sam fakt istnienia relacji nie gwarantuje poprawnej propagacji filtra bezpieczeństwa. Znaczenie mają przede wszystkim:

• czy relacja jest aktywna,
• w jakim kierunku płynie filtr,
• czy istnieje jednoznaczna ścieżka między tabelą uprawnień a tabelą faktów,
• czy model nie zawiera alternatywnych dróg filtrowania.

W klasycznym układzie filtr RLS powinien przechodzić z tabeli użytkowników lub uprawnień do wymiarów, a następnie do faktów. Jeśli po drodze pojawia się relacja nieaktywna, Power BI nie użyje jej automatycznie do egzekwowania bezpieczeństwa.

To ważne: relacja nieaktywna może być przydatna analitycznie, ale z punktu widzenia RLS bardzo często staje się źródłem błędnego założenia, że „model przecież wie, jak połączyć dane”. Nie — dla bezpieczeństwa liczy się realna, aktywna ścieżka filtrowania.

Typowy objaw tej pułapki: użytkownik ma ograniczenie zdefiniowane w tabeli uprawnień, ale raport nadal pokazuje wszystkie rekordy z tabeli faktów. Wtedy problemem często nie jest DAX w roli, lecz brak skutecznej ścieżki propagacji.

Aktywne i nieaktywne relacje — kiedy robi się niebezpiecznie

Nieaktywne relacje same w sobie nie są błędem modelowania. Często występują tam, gdzie jedna tabela faktów łączy się z wymiarem na kilka sposobów, na przykład przez różne daty. Problem pojawia się wtedy, gdy projekt modelu zakłada, że RLS „jakoś skorzysta” z tej alternatywnej relacji.

W kontekście bezpieczeństwa warto trzymać się prostszej zasady: ścieżka filtrowania dla RLS powinna być możliwie jednoznaczna, aktywna i łatwa do prześledzenia. Im więcej wyjątków i alternatywnych połączeń, tym większe ryzyko, że użytkownik zobaczy dane poza swoim zakresem albo odwrotnie — straci dostęp do danych, które powinien widzieć.

Warto też uważać na modele, w których jedna tabela uprawnień filtruje wiele obszarów raportowych różnymi drogami. Taki układ potrafi działać poprawnie w jednym widoku i błędnie w innym, szczególnie gdy do gry wchodzą dodatkowe wymiary.

Pułapka 6: Bidirectional filters jako „szybka naprawa”, która komplikuje bezpieczeństwo

Gdy filtr nie przechodzi tam, gdzie powinien, kuszące jest ustawienie relacji na Both i uznanie problemu za rozwiązany. Rzeczywiście, dwukierunkowe filtrowanie bywa pomocne w wybranych scenariuszach, ale w RLS jest to jeden z najczęstszych powodów trudnych do zdiagnozowania efektów ubocznych.

Dlaczego? Bo bidirectional filters zmieniają nie tylko zachowanie raportu, ale też sposób, w jaki ograniczenia mogą rozlewać się po modelu. Filtr bezpieczeństwa zaczyna docierać do tabel, których pierwotnie nie planowano obejmować, albo wracać inną ścieżką, powodując zawężenie wyników w nieoczekiwanych miejscach.

Najbardziej problematyczne są sytuacje, w których dwukierunkowy filtr:

• powoduje niezamierzone zawężenie danych w innych częściach modelu,
• tworzy alternatywne ścieżki propagacji,
• maskuje słaby projekt relacji, zamiast go naprawić,
• utrudnia przewidzenie, dlaczego dany użytkownik widzi właśnie taki wynik.

W modelach z RLS kierunek filtrowania powinien być decyzją architektoniczną, a nie wygodnym przełącznikiem użytym po to, by wizualizacja „zaczęła działać”.

Propagacja filtrów: nie tylko czy działa, ale jak daleko działa

W RLS liczy się nie tylko to, czy filtr przechodzi z tabeli A do tabeli B, ale również przez ile warstw modelu przechodzi i jakie ma skutki uboczne. Im dłuższa i bardziej złożona ścieżka, tym większe ryzyko niespodzianek.

Bezpieczniejszy model to taki, w którym można łatwo odpowiedzieć na pytania:

• z której tabeli startuje filtr bezpieczeństwa,
• przez jakie relacje przechodzi,
• które tabele są nim objęte bezpośrednio,
• czy istnieje więcej niż jedna droga dojścia do tej samej tabeli,
• czy filtr nie wraca do punktu wyjścia inną ścieżką.

Jeśli na którekolwiek z tych pytań trudno odpowiedzieć bez dłuższego śledzenia modelu, to zwykle znak ostrzegawczy. Dobrze zaprojektowane RLS nie powinno wymagać zgadywania, którędy filtr dotrze do faktów.

Na co zwrócić uwagę w praktyce

• Preferuj aktywne, jednoznaczne relacje na ścieżce bezpieczeństwa.
• Unikaj traktowania bidirectional filters jako domyślnego rozwiązania problemów z RLS.
• Sprawdzaj pełną trasę propagacji, a nie tylko początkową tabelę z rolą.
• Uważaj na wiele dróg filtrowania między tabelą uprawnień a faktami.
• Oddziel logikę analityczną od logiki bezpieczeństwa, jeśli model robi się zbyt złożony.

W 2026 najwięcej problemów z RLS nadal nie wynika z samej składni ról, lecz z modelu, który analitycznie „działa”, ale bezpieczeństwa nie przenosi w sposób przewidywalny. A w przypadku bezpieczeństwa przewidywalność jest ważniejsza niż sprytne obejścia.

Pułapki 7–8: Composite models i DirectQuery — ograniczenia, kontekst zapytań, źródła mieszane, wydajność

W 2026 roku Row-Level Security w Power BI nadal działa dobrze w prostych modelach importowanych, ale zaczyna boleć tam, gdzie architektura jest bardziej złożona: przy composite models i DirectQuery. Problem zwykle nie polega na samym zdefiniowaniu roli, tylko na tym, gdzie faktycznie wykonywany jest filtr, jak zachowuje się kontekst zapytania i jakie ograniczenia narzuca połączenie różnych trybów magazynowania oraz źródeł danych.

W praktyce wiele wdrożeń wygląda poprawnie w modelu logicznym, a mimo to daje zaskakujące efekty: wolne raporty, niepełną propagację filtrów, różnice między danymi importowanymi i zdalnymi albo trudne do wyjaśnienia rozjazdy między testami a produkcją. To właśnie tutaj pojawiają się dwie częste pułapki:

• Pułapka 7: założenie, że RLS działa tak samo w composite model jak w klasycznym modelu importowanym,
• Pułapka 8: niedoszacowanie kosztu wydajnościowego i semantycznego, jaki wnosi DirectQuery pod RLS.

Pułapka 7: Composite models nie zachowują się jak „zwykły model z dodatkami”

Composite model łączy różne tryby przechowywania danych, najczęściej Import i DirectQuery, a czasem także połączenia do semantycznych modeli Power BI lub Analysis Services. Z perspektywy RLS oznacza to, że filtr bezpieczeństwa nie zawsze przechodzi przez model w tak prosty sposób, jak oczekuje autor raportu.

Najważniejszy problem: ten sam filtr logiczny może być realizowany w różnych miejscach. Część danych jest filtrowana lokalnie w modelu, część w źródle zdalnym, a część przez mechanizmy pośrednie zależne od relacji, typu tabeli i trybu storage mode. Im bardziej mieszany model, tym większe ryzyko, że bezpieczeństwo i wydajność zaczną się ze sobą ścierać.

Typowe źródła problemów w composite models:

• źródła mieszane — logika bezpieczeństwa opiera się na danych z jednej tabeli, ale filtrowane fakty pochodzą z innego źródła lub trybu,
• ograniczona możliwość „przepchnięcia” filtra do zdalnego źródła,
• niejednolite zachowanie relacji między tabelami importowanymi i DirectQuery,
• lokalne tabele pomocnicze, które wyglądają jak część modelu bezpieczeństwa, ale nie zawsze skutecznie zawężają dane po stronie źródła.

W praktyce oznacza to, że projekt oparty na tabeli uprawnień zaimportowanej do modelu może działać intuicyjnie dla danych importowanych, ale już nie tak przejrzyście dla faktów pobieranych na żądanie z zewnętrznego źródła. Użytkownik widzi raport, który „teoretycznie” ma filtr bezpieczeństwa, lecz każde kliknięcie uruchamia dodatkowy łańcuch decyzji: co liczy model lokalny, co liczy źródło i czy filtr da się skutecznie zastosować po obu stronach.

Szczególnie zdradliwy jest moment, w którym model zaczyna łączyć:

• lokalne tabele wymiarów,
• zdalne fakty w DirectQuery,
• dodatkowe miary lub kalkulacje odwołujące się do obu warstw.

Wtedy RLS przestaje być wyłącznie regułą dostępu, a staje się częścią architektury zapytań. Jeśli model nie został zaprojektowany pod tę logikę, łatwo o sytuację, w której raport jest poprawny funkcjonalnie, ale niestabilny wydajnościowo.

Pułapka 8: DirectQuery pod RLS często działa poprawnie, ale kosztuje więcej, niż zakładano

DirectQuery kusi aktualnością danych i ograniczeniem importu, ale pod RLS bywa bezlitosny dla wydajności. Każdy filtr bezpieczeństwa może zwiększać złożoność zapytania wysyłanego do źródła. Jeżeli użytkownik otwiera stronę z wieloma wizualizacjami, a każda z nich wymaga osobnego zapytania uwzględniającego RLS, liczba operacji szybko rośnie.

To ważna różnica praktyczna:

• w Import koszt bezpieczeństwa jest częściej „zamortyzowany” przez silnik modelu w pamięci,
• w DirectQuery koszt bezpieczeństwa bardzo często jest płacony podczas każdego odświeżenia wizualizacji.

Najczęstsze objawy źle oszacowanego DirectQuery pod RLS to:

• długie otwieranie stron raportu,
• różne czasy odpowiedzi dla różnych użytkowników,
• wąskie gardła po stronie źródła danych,
• nagłe pogorszenie wydajności po dodaniu tabeli uprawnień lub dodatkowego wymiaru filtrującego.

Powód jest prosty: RLS nie jest „darmowym warunkiem WHERE”. W zależności od modelu może wymagać dodatkowych złączeń, translacji filtrów i bardziej złożonego planu wykonania po stronie źródła. Jeśli do tego dochodzą funkcje zależne od tożsamości użytkownika, relacje przez wiele tabel albo mieszane źródła, koszt potrafi rosnąć nieliniowo.

Drugim problemem jest kontekst zapytania. W DirectQuery raport nie pracuje na pełnym lokalnym zestawie danych, tylko stale odwołuje się do źródła. To oznacza, że nawet poprawna reguła RLS może dawać inne odczucie pracy niż w modelu importowanym: krótsze timeouty, mniej tolerancji na skomplikowane logiki i większą wrażliwość na każdy dodatkowy filtr.

Warto też pamiętać, że przy źródłach mieszanych użytkownik nie ocenia modelu warstwami. On widzi po prostu raport, który dla jednych stron działa szybko, a dla innych wolno. Jeśli część modelu jest importowana, a część działa przez DirectQuery, to właśnie bezpieczeństwo bywa jednym z głównych czynników ujawniających tę niespójność.

Na co uważać projektowo

Bez wchodzenia w głębokie wzorce implementacyjne, przy composite models i DirectQuery warto przyjąć kilka zasad ostrożności:

• upraszczaj ścieżkę filtra bezpieczeństwa — im mniej przeskoków między tabelami i trybami storage, tym lepiej,
• unikaj mieszania logiki uprawnień z wieloma warstwami pośrednimi,
• traktuj RLS jako element wydajnościowy, a nie tylko bezpieczeństwa,
• sprawdzaj zachowanie raportu dla realnych użytkowników i realnych wolumenów danych,
• zakładaj, że DirectQuery pod RLS wymaga bardziej konserwatywnego projektowania niż Import.

Jeżeli model ma działać z RLS w środowisku o dużej liczbie użytkowników, to decyzja „Import czy DirectQuery” przestaje być wyłącznie wyborem integracyjnym. Staje się decyzją o tym, jak bardzo złożona będzie egzekucja bezpieczeństwa i kto zapłaci za nią wydajnością: silnik modelu, źródło danych czy użytkownik czekający na raport.

Pułapka 9: Miary, funkcje DAX i „fałszywe poczucie bezpieczeństwa” — co RLS filtruje, a czego nie

Row-Level Security w Power BI daje silne wrażenie, że „skoro użytkownik widzi mniej wierszy, to wszystko jest już bezpieczne”. To tylko częściowo prawda. RLS filtruje dane na poziomie wierszy tabel objętych modelem i relacjami, ale nie jest uniwersalnym mechanizmem ochrony każdej informacji, jaką da się wyprowadzić z modelu, miar i logiki DAX.

Najczęstszy błąd polega na myleniu trzech rzeczy: ukrywania elementów interfejsu, filtrowania danych oraz kontroli logiki biznesowej w miarach. RLS działa w drugim obszarze. Nie zastępuje poprawnego projektowania miar, nie zabezpiecza automatycznie przed nadmiernie „sprytnymi” kalkulacjami i nie gwarantuje, że użytkownik nie zobaczy metadanych, agregatów lub wyników, które pośrednio ujawniają zbyt wiele.

Co RLS faktycznie robi

W praktyce RLS ogranicza zestaw wierszy dostępnych dla użytkownika podczas wykonywania zapytań do modelu. Jeżeli rola jest poprawnie zdefiniowana, to miary liczą się w kontekście danych, które pozostały po zastosowaniu filtra bezpieczeństwa. To ważne: RLS nie „przepisuje” miar, tylko zawęża dane wejściowe.

• Tak: użytkownik widzi tylko przypisane rekordy sprzedaży, klientów lub regionów.
• Tak: standardowa miara typu SUM(), COUNTROWS() czy AVERAGE() działa na ograniczonym zbiorze danych.
• Nie: samo istnienie RLS nie oznacza, że każda miara jest bezpieczna informacyjnie.
• Nie: ukrycie kolumny lub tabeli w modelu nie jest zabezpieczeniem danych.

Gdzie pojawia się „fałszywe poczucie bezpieczeństwa”

Problem zaczyna się wtedy, gdy miary lub konstrukcje DAX próbują obliczać wartości „ponad” bieżącym filtrem, porównywać użytkownika do całości organizacji albo zwracać wynik na bardzo małej próbce danych. Formalnie RLS nadal działa, ale rezultat biznesowy może ujawniać więcej, niż zakładano.

Typowe przykłady ryzyka:

• Agregaty na małej liczbie rekordów — użytkownik widzi średnią lub sumę dla grupy tak małej, że łatwo odgadnąć wartości jednostkowe.
• Miary porównujące do „całości” — np. udział użytkownika w całej firmie, gdy „całość” jest liczona z pominięciem części filtrów raportu.
• Miary diagnostyczne i techniczne — liczniki rekordów, testy jakości danych, flagi braków, które zdradzają strukturę niewidocznych danych.
• Eksport i analiza szczegółów — nawet poprawna miara może prowadzić do niepożądanych wniosków, jeśli raport pozwala zejść do poziomu zbyt szczegółowego.

RLS a funkcje DAX: czego nie zakładać automatycznie

Wiele nieporozumień bierze się z przekonania, że użycie funkcji modyfikujących kontekst filtra „wyłączy” RLS albo przeciwnie — że RLS zablokuje każdą próbę liczenia szerzej. W praktyce trzeba pamiętać o prostym rozróżnieniu: DAX może zmieniać kontekst filtrowania raportowego, ale nie powinien być traktowany jako zamiennik polityki bezpieczeństwa.

Przykład pułapki w myśleniu o miarach

Sama definicja miary może wyglądać niewinnie:

Sprzedaż = SUM(FactSales[Amount])

Taka miara zazwyczaj zachowa się zgodnie z RLS, bo zsumuje tylko dostępne rekordy. Ale już miara porównawcza:

Udział % = DIVIDE([Sprzedaż], CALCULATE([Sprzedaż], ALL(DimRegion)))

może być biznesowo problematyczna, jeśli użytkownik powinien znać tylko własny region, a mianownik de facto pokazuje odniesienie do szerszego obrazu organizacji. Nie chodzi tu o samą składnię, lecz o pytanie: czy taki wynik powinien być widoczny dla tej roli?

RLS nie filtruje wszystkiego, co użytkownik „może zrozumieć”

To kluczowe rozróżnienie. RLS kontroluje dostęp do wierszy, ale nie kontroluje automatycznie:

• interpretacji wyniku — z jednej liczby można wywnioskować bardzo dużo,
• poziomu wrażliwości agregatu — suma lub średnia też może być informacją poufną,
• projektu wizualizacji — karta KPI, tabela szczegółowa i macierz niosą różne ryzyka,
• semantyki miary — to autor modelu decyduje, czy wynik ujawnia coś ponad zamierzony zakres.

Najbezpieczniejsze podejście praktyczne

Jeżeli raport ma obsługiwać dane wrażliwe, warto przyjąć zasadę: RLS jest warstwą filtrowania, a nie kompletną strategią ochrony informacji. Oznacza to, że każdą ważniejszą miarę należy oceniać nie tylko pod kątem poprawności obliczeń, ale też pod kątem tego, co użytkownik może z niej wywnioskować.

• Ograniczaj nadmiernie szczegółowe widoki tam, gdzie małe próbki danych są ryzykowne.
• Przeglądaj miary benchmarkowe, procentowe i rankingowe osobno dla każdej roli.
• Nie traktuj ukrywania pól jako mechanizmu bezpieczeństwa.
• Oddzielaj „wygodę analityczną” od „bezpieczeństwa informacji”.

Najkrócej: RLS odpowiada na pytanie „które wiersze wolno zobaczyć”, ale nie odpowiada samodzielnie na pytanie „czy wynik tej miary jest bezpieczny do pokazania”. To właśnie tu najczęściej pojawia się fałszywe poczucie bezpieczeństwa w modelach Power BI.

Diagnostyka i testy: View as, testowanie w usłudze, logowanie i audyt

W praktyce większość problemów z Row-Level Security nie wynika z samej definicji roli, ale z różnicy między tym, jak model zachowuje się w teorii, a tym, jak działa po publikacji. Dlatego diagnostyka RLS w Power BI w 2026 nadal opiera się na trzech filarach: lokalnej symulacji, weryfikacji w usłudze oraz świadomym zapisywaniu wyników testów. Bez tego łatwo uznać, że zabezpieczenia działają, choć poprawne wyniki widać tylko w jednym środowisku albo dla jednego typu użytkownika.

Najprostszy punkt startowy to View as, czyli podgląd modelu z perspektywy wybranej roli. To dobre narzędzie do szybkiego sprawdzenia, czy filtr w ogóle ogranicza dane i czy raport reaguje zgodnie z oczekiwaniem. Jego zaletą jest szybkość: pozwala natychmiast wykryć oczywiste błędy, takie jak brak filtrowania wybranych wizualizacji, puste wyniki albo zbyt szeroki zakres danych. Trzeba jednak pamiętać, że jest to symulacja, a nie pełne odtworzenie warunków działania po stronie usługi.

Właśnie dlatego samo sprawdzenie modelu lokalnie nie wystarcza. Testowanie w Power BI Service jest niezbędne, ponieważ dopiero tam spotykają się rzeczywista tożsamość użytkownika, przypisanie do ról, konfiguracja dostępu do zestawu danych oraz zachowanie raportu po publikacji. W praktyce wiele usterek ujawnia się dopiero w usłudze: użytkownik widzi za dużo, nie widzi nic albo wyniki różnią się od tych, które autor raportu obserwował w Desktop. Z perspektywy diagnostyki kluczowe jest więc rozróżnienie: View as służy do szybkiej kontroli logiki modelu, a test w usłudze do potwierdzenia realnego działania zabezpieczeń.

Dobrą praktyką jest testowanie co najmniej kilku scenariuszy dostępu, a nie tylko jednego „typowego” konta. Najczęściej warto sprawdzić:

• użytkownika, który powinien widzieć tylko własny wycinek danych,
• użytkownika z szerszym dostępem,
• użytkownika należącego do więcej niż jednej grupy lub roli,
• użytkownika, który nie powinien widzieć żadnych danych,
• konto administracyjne lub właścicielskie, jeśli jego zachowanie ma być inne niż zwykłego odbiorcy raportu.

Podczas testów nie chodzi wyłącznie o odpowiedź „działa lub nie działa”. Warto sprawdzać konkretne objawy: czy liczby na kartach się zmieniają, czy filtry list rozwijanych pokazują właściwe wartości, czy użytkownik nie może dojść do danych przez stronę drillthrough, eksport albo inny raport korzystający z tego samego modelu. Częstym błędem jest uznanie testu za zakończony po obejrzeniu jednej strony raportu, podczas gdy problem pojawia się dopiero w szczególnym widoku lub po interakcji między wizualizacjami.

Równie ważne jest logowanie i audyt, rozumiane nie jako rozbudowany system monitoringu, ale jako uporządkowany zapis tego, co zostało sprawdzone. W przypadku RLS najbardziej przydaje się prosty rejestr testów: kto był testowany, w jakim środowisku, z jaką rolą lub zakresem dostępu, jaki wynik był oczekiwany i jaki wynik faktycznie uzyskano. Taki zapis pozwala szybko wrócić do wcześniejszych ustaleń, porównać zachowanie po zmianach w modelu i odróżnić regresję od błędu obecnego od początku.

W praktyce warto zapisywać przede wszystkim:

• datę testu i wersję modelu lub raportu,
• środowisko, w którym wykonano test,
• identyfikator użytkownika lub typ konta użytego do weryfikacji,
• oczekiwany zakres danych,
• rzeczywisty wynik testu,
• wszelkie odstępstwa, takie jak puste wizualizacje, nadmiarowe rekordy albo niespójne filtrowanie,
• decyzję: zaakceptowano, do poprawy, do ponownego testu.

Audyt ma jeszcze jeden cel: pomaga wyłapać sytuacje, w których problem nie leży w samej regule RLS, ale w procesie wdrożenia. Jeśli po publikacji wyniki nagle się zmieniają, warto potwierdzić nie tylko zachowanie raportu, ale też to, czy test był wykonany na właściwym zbiorze danych, właściwym workspace i właściwej wersji modelu. W środowiskach, gdzie raporty są często aktualizowane, brak takiej kontroli szybko prowadzi do chaosu: zabezpieczenia „teoretycznie” są poprawne, ale nikt nie potrafi wskazać, co faktycznie działa na produkcji.

Najrozsądniejsze podejście do RLS w 2026 jest więc proste: najpierw symuluj, potem sprawdzaj w usłudze, a na końcu zapisuj wynik testu. Tylko połączenie tych trzech elementów daje pewność, że ograniczenia dostępu istnieją nie tylko w modelu, ale również w realnym użyciu raportu przez odbiorców.

Rekomendacje architektury i checklist wdrożeniowy

Najbardziej odporne wdrożenia RLS w Power BI nie zaczynają się od pojedynczej reguły DAX, ale od spójnej architektury uprawnień. W praktyce oznacza to rozdzielenie logiki biznesowej od logiki bezpieczeństwa, tak aby model dało się rozwijać, testować i audytować bez ciągłego przepisywania ról. W 2026 roku to podejście jest jeszcze ważniejsze, bo modele są częściej hybrydowe, współdzielone i budowane przez wiele zespołów jednocześnie.

Podstawową rekomendacją jest stosowanie security dimension albo bridge table do mapowania użytkownika na zakres dostępu. Oba wzorce służą do tego samego celu, ale mają nieco inne zastosowanie. Security dimension sprawdza się tam, gdzie dostęp da się przypisać do jednego czytelnego wymiaru, na przykład regionu, jednostki organizacyjnej lub segmentu. Bridge table jest lepszym wyborem, gdy uprawnienia są bardziej złożone, wielowartościowe albo wynikają z wielu przecięć, na przykład użytkownik ma dostęp do kilku regionów i kilku linii biznesowych jednocześnie. Najważniejsza zasada brzmi: uprawnienia powinny być danymi w modelu, a nie wiedzą ukrytą w wielu osobnych rolach.

Dobry wzorzec architektoniczny zakłada także, że tabela uprawnień jest jedynym kontrolowanym źródłem praw dostępu. Dzięki temu łatwiej utrzymać zgodność między raportami, semantycznymi modelami i środowiskami wdrożeniowymi. Jeśli różne zespoły zaczynają budować własne, lokalne wersje mapowania dostępu, bardzo szybko pojawiają się rozjazdy: ten sam użytkownik widzi co innego w dwóch raportach opartych na podobnych danych.

Warto też przyjąć kilka prostych zasad modelowania bezpieczeństwa:

• Projektuj pod minimalny zakres dostępu — użytkownik powinien widzieć tylko to, co jest niezbędne do realizacji jego roli.
• Oddziel role techniczne od logiki biznesowej — role nie powinny opisywać wyjątków i lokalnych obejść.
• Unikaj duplikowania reguł między datasetami — centralizacja zmniejsza ryzyko niespójności.
• Stawiaj na prostą ścieżkę filtrowania — im mniej pośrednich zależności, tym łatwiejsza diagnostyka.
• Traktuj bezpieczeństwo jak element modelu danych, a nie końcowy dodatek przed publikacją.

Od strony publikacji kluczowe jest rozróżnienie między tym, kto administruje dostępem, a tym, kto rozwija model. W dojrzałym procesie nie każda osoba publikująca raport powinna mieć możliwość dowolnego zmieniania mapowania ról i użytkowników. Bezpieczniejszy model pracy polega na tym, że zmiany w logice RLS, członkostwie ról i źródłach tożsamości są zarządzane w kontrolowany sposób, najlepiej z prostą ścieżką akceptacji i możliwością odtworzenia historii zmian.

Równie ważna jest zasada, by nie publikować bez weryfikacji scenariuszy dostępu. Sam fakt, że raport działa funkcjonalnie, nie oznacza jeszcze, że jest bezpieczny. Przed wdrożeniem trzeba sprawdzić nie tylko typowe przypadki, ale też użytkowników bez mapowania, użytkowników z wieloma zakresami dostępu, konta serwisowe oraz sytuacje graniczne związane ze zmianą struktury organizacyjnej lub przypisań.

Praktyczny checklist wdrożeniowy powinien obejmować co najmniej następujące punkty:

• Czy istnieje jedna, jawna tabela uprawnień opisująca relację użytkownik–zakres dostępu.
• Czy wzorzec security dimension lub bridge table został dobrany do rzeczywistej złożoności uprawnień.
• Czy logika bezpieczeństwa jest odseparowana od logiki raportowej i nie została zaszyta w wielu miejscach modelu.
• Czy dla brakujących rekordów uprawnień obowiązuje bezpieczne zachowanie domyślne, czyli brak dostępu, a nie pełen wgląd.
• Czy role są nazwane jednoznacznie i da się zrozumieć ich przeznaczenie bez analizowania całego modelu.
• Czy proces publikacji obejmuje test użytkownika końcowego, a nie tylko test autora raportu.
• Czy przypisania ról i źródło mapowania są udokumentowane i możliwe do audytu.
• Czy zmiana struktury danych lub organizacji ma zdefiniowany wpływ na model bezpieczeństwa.
• Czy właściciel biznesowy potwierdził reguły dostępu, zamiast pozostawiać interpretację wyłącznie po stronie technicznej.
• Czy istnieje procedura okresowego przeglądu uprawnień, aby usuwać dostępy, które przestały być uzasadnione.

Najlepsza architektura RLS to taka, która jest przewidywalna, centralna i testowalna. Jeżeli bezpieczeństwo opiera się na czytelnym modelu uprawnień, ograniczonej liczbie wzorców i jasnych zasadach publikacji, maleje ryzyko błędów, które w Power BI zwykle nie objawiają się awarią, tylko cichym pokazaniem niewłaściwych danych niewłaściwej osobie.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

Fabric: OneLake Shortcuts — 8 scenariuszy, w których kończysz z duplikacją danych (albo ją tworzysz) 05 sierpnia 2026

DAX: calculation groups w Tabular Editor — 11 zastosowań, które upraszczają miary o połowę 03 sierpnia 2026