Power BI i RLS/OLS: 11 błędów w bezpieczeństwie modeli, które ujawniają dane „bokiem”

1. Wprowadzenie: model bezpieczeństwa w Power BI (RLS vs OLS) i powierzchnie ekspozycji danych

Bezpieczeństwo w Power BI najczęściej kojarzy się z prostą zasadą: „użytkownik widzi tylko to, do czego ma dostęp”. W praktyce to kilka warstw kontroli, które działają na różnych poziomach: od uprawnień do obszaru roboczego i zestawu danych, przez filtrowanie wierszy, aż po ograniczanie widoczności kolumn i metadanych. Problem polega na tym, że model może wyglądać na poprawnie zabezpieczony w raporcie, a mimo to ujawniać dane „bokiem” poprzez funkcje analityczne, wizualizacje, metadane, miary lub integracje.

W kontekście modeli semantycznych Power BI kluczowe są dwa mechanizmy: RLS (Row-Level Security) oraz OLS (Object-Level Security). Oba mają inne przeznaczenie, inny zakres działania i inne typowe pułapki, które mogą prowadzić do niezamierzonej ekspozycji informacji.

RLS: ograniczanie danych na poziomie wierszy

RLS służy do tego, aby różni użytkownicy widzieli różne wycinki tych samych tabel — najczęściej według regionu, jednostki organizacyjnej, klienta, projektu lub innych atrybutów. RLS działa jak filtr danych: użytkownik otrzymuje tylko te wiersze, które spełniają warunki przypisanej roli (lub ról).

RLS jest zwykle pierwszym wyborem, gdy:

• to samo rozwiązanie ma obsłużyć wielu odbiorców z różnymi zakresami danych,
• kontrola dostępu ma zależeć od atrybutów w danych (np. przypisania użytkownika do jednostki),
• raport ma pozostać jeden, ale „przefiltrowany” per odbiorca.

Istotne jest jednak to, że RLS nie jest „maskowaniem” wrażliwych pól — jeśli wiersz jest widoczny, to wszystkie jego dostępne kolumny (o ile nie są ukryte innym mechanizmem) mogą stać się dostępne również poprzez działania poza samą stroną raportu.

OLS: ograniczanie obiektów (tabel/kolumn/miar)

OLS odpowiada za kontrolę widoczności i dostępności elementów modelu: tabel, kolumn, a czasem również miar. Jego zadaniem jest ograniczenie tego, co użytkownik może w ogóle „zobaczyć” i wykorzystać z modelu semantycznego, niezależnie od tego, jakie wiersze mógłby otrzymać w ramach RLS.

OLS jest przydatny, gdy:

• w modelu istnieją kolumny wrażliwe (np. identyfikatory, dane finansowe, dane osobowe) i nie mogą być dostępne nawet częściowo,
• chcesz udostępnić uproszczony, „bezpieczny” widok modelu dla części odbiorców,
• raporty korzystają z jednego zestawu danych, ale różne grupy mają mieć różny zakres semantyki (nie tylko różny filtr wierszy).

Warto pamiętać, że OLS rozwiązuje inny problem niż RLS: nie decyduje, które wiersze są zwracane, tylko jakie obiekty są w ogóle dostępne do odczytu i analizy.

RLS i OLS razem: dwie warstwy, jeden cel

Najbezpieczniejsze modele traktują RLS i OLS jako mechanizmy uzupełniające. RLS ogranicza zakres danych, a OLS ogranicza powierzchnię modelu, którą użytkownik może eksplorować. Dzięki temu nawet jeśli użytkownik ma dostęp do części wierszy, nie uzyska automatycznie dostępu do wszystkich pól, które mogłyby posłużyć do identyfikacji, korelacji lub wnioskowania o danych wrażliwych.

„Powierzchnie ekspozycji danych” w Power BI: skąd biorą się wycieki „bokiem”

Wyciek w Power BI rzadko wygląda jak „ktoś zobaczył cudzą stronę raportu”. Znacznie częściej polega na tym, że użytkownik wykorzystuje legalnie dostępne funkcje, aby dotrzeć do informacji, które nie były intencją projektanta modelu. Do typowych powierzchni ekspozycji należą:

• Interakcje w raporcie — filtrowanie, drążenie, pokazywanie szczegółów, tooltipy i inne mechanizmy, które mogą ujawnić więcej, niż widać „na pierwszy rzut oka”.
• Eksploracja modelu przez narzędzia klienckie — funkcje analityczne i integracje pozwalające odpytywać dataset poza wizualizacjami raportu (tam, gdzie „ukryte” nie znaczy „niedostępne”).
• Metadane i struktura modelu — nazwy tabel/kolumn, hierarchie, atrybuty i relacje, które same w sobie mogą ujawniać kontekst biznesowy lub wrażliwe znaczenie pól.
• Miary i logika obliczeń — źle zaprojektowane obliczenia mogą umożliwiać wnioskowanie o wartościach, do których użytkownik nie powinien mieć dostępu, nawet jeśli „nie widzi” surowych danych.
• Agregacje i wyniki pośrednie — w niektórych sytuacjach da się odtworzyć informacje jednostkowe na podstawie wyników zagregowanych, gdy brakuje odpowiednich ograniczeń lub progów.
• Udostępnienia i uprawnienia — nawet poprawnie skonfigurowany model może być narażony, jeśli dostęp do datasetu lub funkcji eksportu jest szerszy niż zakładano.

Dlatego bezpieczeństwo w Power BI nie kończy się na „ustawieniu RLS”. To raczej projektowanie i weryfikacja całego modelu pod kątem tego, w jaki sposób dane mogą być odczytywane i rekonstruowane — zarówno w raporcie, jak i poza nim. RLS i OLS są fundamentem, ale to dopiero początek świadomego podejścia do ochrony danych w modelach semantycznych.

2. Fundamenty poprawnej konfiguracji: role, mapowanie użytkowników, propagacja filtrów i relacje w modelu

Bezpieczeństwo modelu w Power BI najczęściej „psuje się” nie przez jeden spektakularny błąd, ale przez drobne niedopasowania w fundamentach: jak zdefiniowano role, w jaki sposób użytkownik jest mapowany do reguł, oraz czy filtry faktycznie propagują się po relacjach tak, jak zakładamy. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. Te elementy decydują, czy RLS realnie zawęża dane w całym modelu, czy tylko w jednym miejscu — pozostawiając boczne ścieżki dostępu.

Role: projektuj pod zasady dostępu, nie pod widoki raportu

Rola w kontekście RLS to zestaw reguł filtrujących dane, a nie „wariant raportu” czy „układ stron”. Podstawowa dobra praktyka to budowanie ról wokół rzeczywistych zasad dostępu (np. region, jednostka organizacyjna, portfel klientów), a nie wokół tego, co użytkownik ma oglądać na wizualizacjach.

• Role statyczne sprawdzają się, gdy granice dostępu są mało zmienne i łatwe do opisania prostą regułą.
• Role dynamiczne są właściwe, gdy dostęp zależy od tożsamości użytkownika i atrybutów przypisanych do niego w danych (np. lista dozwolonych jednostek). Wymagają jednak szczególnie starannego modelowania mapowania użytkownik → uprawnienia.
• OLS uzupełnia RLS tam, gdzie sam filtr wierszy nie wystarcza, bo nawet ograniczone wiersze mogą ujawniać metadane lub miary oparte o wrażliwe kolumny. Na poziomie fundamentów ważne jest rozdzielenie: RLS odpowiada za „które rekordy”, OLS za „które pola/obiekty”.

Mapowanie użytkowników: jedno źródło prawdy i spójny identyfikator

Najbardziej krytycznym elementem konfiguracji dynamicznego RLS jest sposób, w jaki model rozpoznaje użytkownika i łączy go z odpowiednimi uprawnieniami. Należy dążyć do jednego, spójnego mechanizmu mapowania i jednego formatu identyfikatora użytkownika w całym rozwiązaniu.

• Jednoznaczny identyfikator: wybierz i konsekwentnie stosuj pojedynczy klucz (np. UPN/e-mail w organizacji) jako podstawę przypisań. Mieszanie formatów (alias, e-mail, różne domeny) tworzy luki, w których reguły nie działają tak, jak oczekujesz.
• Jedno miejsce definiowania uprawnień: tabela mapująca użytkowników do jednostek dostępu powinna być traktowana jak polityka bezpieczeństwa w danych. Rozproszone listy, ręczne dopiski „tu i tam” oraz osobne źródła prawdy zwiększają ryzyko niespójności.
• Odporność na zmiany organizacyjne: mapowanie powinno wytrzymać rotacje, zmiany nazw, migracje kont. Jeśli bezpieczeństwo opiera się na kruchych atrybutach, to prędzej czy później pojawią się konta, które widzą za dużo lub za mało.

Propagacja filtrów: zrozum kierunek i „zasięg” ograniczeń

RLS działa tak dobrze, jak dobrze działa propagacja filtrów w modelu. Kluczowe jest to, czy filtr nałożony w jednym miejscu rzeczywiście ogranicza wszystkie tabele, z których raport może pobierać dane. W praktyce ryzyko pojawia się wtedy, gdy filtr „utknie” po drodze: przez nieodpowiedni kierunek relacji, brak relacji, relację nieaktywną lub konstrukcję modelu, która omija ścieżkę filtrowania.

• Zasięg filtrowania: upewnij się, że tabele, na których opierają się wizualizacje, miary i hierarchie, są w pełni „podpięte” pod ograniczenia wynikające z roli.
• Jednoznaczna ścieżka: tam, gdzie to możliwe, projektuj model tak, by filtr miał naturalną i przewidywalną drogę z tabeli uprawnień lub wymiaru do faktów.
• Świadome użycie dwukierunkowego filtrowania: bywa potrzebne, ale zwiększa złożoność i może tworzyć nieoczywiste przenikanie filtrów. W fundamentach chodzi o minimalizację „magii” i maksymalizację przewidywalności.

Relacje w modelu: bezpieczeństwo jest tak mocne, jak najsłabsze połączenie

Relacje to kręgosłup zarówno analityki, jak i bezpieczeństwa. Dla RLS liczy się nie tylko to, czy relacja istnieje, ale także jej kardynalność, aktywność oraz to, czy model nie zawiera alternatywnych dróg dostępu do tych samych danych.

• Preferuj czytelny układ wymiar–fakt: im bardziej model przypomina klasyczny układ (wymiary filtrują fakty), tym łatwiej przewidzieć, gdzie zadziała filtr bezpieczeństwa.
• Unikaj „wysp”: tabele odłączone lub połączone nietypowo mogą stać się bocznym źródłem informacji (np. poprzez liczniki, sumy, listy wartości), nawet jeśli główne fakty są filtrowane.
• Uważaj na relacje nieaktywne: jeśli logika raportu korzysta z alternatywnych relacji, musisz mieć pewność, że nie tworzą one ścieżek omijających ograniczenia.
• Spójność kluczy: niedopasowane typy, brudne klucze, duplikaty w wymiarach czy niejednoznaczne mapowania to częsta przyczyna sytuacji, w której filtr bezpieczeństwa zachowuje się inaczej niż „w głowie” projektanta.

RLS i OLS w modelu: rozdziel odpowiedzialności

Na poziomie fundamentów warto myśleć o RLS i OLS jako o dwóch warstwach kontroli, które nie zastępują się nawzajem:

• RLS ma ograniczać dane po rekordach wszędzie tam, gdzie te rekordy mogą się pojawić w raporcie.
• OLS ma ograniczać ekspozycję pól i obiektów modelu, gdy sama redukcja wierszy nie jest wystarczająca (np. gdy metadane, agregacje lub miary mogłyby ujawnić informacje wrażliwe).

Jeżeli te fundamenty są spójne — role odzwierciedlają politykę dostępu, mapowanie użytkowników jest jednoznaczne, a relacje zapewniają pełną propagację filtrów — większość „bocznych wycieków” przestaje być możliwa już na etapie projektu modelu.

3. 11 typowych błędów prowadzących do wycieku danych — część 1 (1–6)

Poniższe błędy są częste, bo w Power BI „działa” wiele konfiguracji, które wyglądają poprawnie w raporcie, ale ujawniają dane przez inne powierzchnie: tabele w wizualach, drillthrough, tooltipy, paginated reports, „Analyze in Excel”, API/connector, a czasem nawet przez same miary (różnice w agregatach). Każdy punkt zawiera: ryzyko, bezpieczny wzorzec oraz testy weryfikacyjne.

1) RLS tylko na raporcie / workspace, a nie na dataset (semantic model)

Ryzyko: Najczęstszy „wyciek bokiem”. Ograniczenia są mylone z uprawnieniami do raportu lub workspace. Użytkownik może mieć dostęp do datasetu (np. przez uprawnienie Build, aplikację, udostępnienie datasetu, „Analyze in Excel”), a wtedy zobaczy dane bez oczekiwanego ograniczenia, jeśli RLS nie jest skonfigurowany i przypisany na poziomie modelu.

Bezpieczny wzorzec:

• Traktuj dataset/semantic model jako źródło prawdy dla bezpieczeństwa; RLS definiuj i utrzymuj w modelu.
• Ogranicz przydzielanie Build i bezpośrednich uprawnień do datasetu tylko do osób, które rzeczywiście muszą tworzyć raporty.
• Jeśli publikujesz przez aplikację, upewnij się, że konsumenci nie dostają niepotrzebnych uprawnień do datasetu.

Testy weryfikacyjne:

• Zaloguj się kontem testowym i spróbuj: Analyze in Excel / połączenia z datasetem w Excelu lub innym kliencie. Sprawdź, czy filtr RLS jest egzekwowany.
• Sprawdź w ustawieniach datasetu: kto ma Read, kto ma Build, kto jest Member/Contributor workspace.

2) RLS „na faktach”, brak prawidłowej tabeli wymiaru bezpieczeństwa (Security Dimension)

Ryzyko: Filtr RLS zdefiniowany bezpośrednio na tabeli faktów (np. Sales) jest kruchy: łatwo go ominąć przez inne ścieżki relacji, miary korzystające z innych tabel, a także przez błędy w relacjach. Dodatkowo rośnie ryzyko niezamierzonej ekspozycji w tabelach wymiarów (np. Klienci, Produkty), jeśli one nie są objęte skuteczną propagacją filtra.

Bezpieczny wzorzec:

• Projektuj tabelę bezpieczeństwa (np. User↔Tenant/Region/Customer) jako wymiar, który filtruje resztę modelu.
• Utrzymuj RLS jako filtr na tej tabeli (np. po UPN), a nie „po drodze” na faktach.
• Dbaj o jednoznaczne klucze i relacje, aby filtr z wymiaru bezpieczeństwa jednoznacznie ograniczał fakty.

Przykład (uzupełniająco):

// RLS na tabeli Security
Security[UPN] = USERPRINCIPALNAME()

Testy weryfikacyjne:

• W raporcie dodaj tabelę z wymiarami (np. Customer, Product) i sprawdź, czy lista jest ograniczona zgodnie z oczekiwaniem, nie tylko agregaty na faktach.
• Utwórz miarę liczącą liczbę klientów/produktów i porównaj wyniki dla różnych kont testowych.

3) Błędna lub niekompletna propagacja filtrów (relacje, kierunek filtrowania, brak ścieżki)

Ryzyko: RLS działa tak dobrze, jak działa propagacja filtrów w modelu. Jeśli między tabelą z regułą a tabelą z danymi nie ma ścieżki relacji, relacja jest nieaktywna, ma zły kierunek filtrowania, albo filtr „gubi się” na mostach (many-to-many), użytkownik zobaczy dane spoza swojego zakresu.

Bezpieczny wzorzec:

• Upewnij się, że od tabeli bezpieczeństwa istnieje jednoznaczna, aktywna ścieżka do tabel faktów.
• Unikaj przypadkowego Both (dwukierunkowego) filtrowania; stosuj je świadomie, bo może otworzyć nieoczekiwane ścieżki filtracji.
• W modelach z mostami rozważ wzorce z tabelami pośrednimi i kontrolą relacji, zamiast „na siłę” włączać obustronne filtrowanie.

Testy weryfikacyjne:

• W Model view zweryfikuj: aktywność relacji, kierunki filtrów oraz czy istnieje ścieżka od tabeli Security do każdego faktu.
• Przetestuj wizualizacje, które korzystają z różnych tabel faktów; wyciek często pojawia się tylko w części raportu.

4) Many-to-many i „ambiguous paths”: filtr z RLS daje się obejść przez alternatywną ścieżkę

Ryzyko: Relacje many-to-many oraz niejednoznaczne ścieżki (ambiguous) potrafią sprawić, że filtr bezpieczeństwa nie ogranicza danych tak, jak zakładasz, albo ogranicza je w jednym miejscu, a w innym nie. W skrajnym przypadku użytkownik może zobaczyć pełną listę wartości w wymiarze (np. wszyscy klienci), mimo że agregaty wyglądają „w miarę” poprawnie.

Bezpieczny wzorzec:

• Minimalizuj many-to-many w obszarze objętym bezpieczeństwem; jeśli potrzebujesz, buduj jawne tabele mostowe i testuj propagację filtrów na wymiarach.
• Usuwaj niejednoznaczne ścieżki (dublujące relacje) prowadzące od wymiaru bezpieczeństwa do tych samych faktów.
• Jeżeli model musi mieć wiele ścieżek, kontroluj je świadomie (np. przez nieaktywne relacje i selektywne użycie w miarach), ale pamiętaj, że to zwiększa ryzyko błędów w RLS.

Testy weryfikacyjne:

• Dodaj do raportu tabelę z kluczami/wartościami z wymiarów połączonych many-to-many i sprawdź, czy nie pokazują „pełnego słownika”.
• Sprawdź zachowanie slicerów: jeśli slicer pokazuje wartości spoza zakresu użytkownika, to sygnał alarmowy (nawet jeśli po kliknięciu agregaty się „zgadzają”).

5) Zaufanie do „ukrywania” w raporcie zamiast OLS/RLS (ukryte kolumny, ukryte strony, brak dostępu przez wizual)

Ryzyko: Ukryte pola, niewidoczne strony czy brak użycia kolumny w wizualach nie są mechanizmem bezpieczeństwa. Użytkownik z dostępem do datasetu może zobaczyć ukryte obiekty w narzędziach klienckich lub podczas budowy własnych raportów. Podobnie: ukrycie tabel/kolumn w modelu nie blokuje ich odczytu, jeśli nie zastosowano OLS.

Bezpieczny wzorzec:

• Traktuj „hide in report/model” wyłącznie jako UX, nie security.
• Dla obiektów, które nie mogą być widoczne dla danej roli, stosuj OLS (na tabelach/kolumnach), a dla wierszy danych — RLS.
• Ogranicz możliwość tworzenia własnych raportów (Build) tam, gdzie nie jest to wymagane.

Testy weryfikacyjne:

• Na koncie testowym spróbuj zbudować prosty raport na bazie datasetu i sprawdź, czy widzisz „ukryte” tabele/kolumny.
• Zweryfikuj, czy OLS faktycznie blokuje dostęp (np. pole nie jest dostępne do użycia).

6) Dynamiczne RLS oparte o niepewne atrybuty (email display name, domena, fragment UPN) lub niespójne mapowanie

Ryzyko: Dynamiczne reguły oparte o atrybuty, które mogą się zmieniać (np. wyświetlana nazwa), bywają niespójne między Entra ID, danymi źródłowymi i modelem. Równie ryzykowne są „sprytne” skróty: dopasowanie po domenie, po fragmencie UPN, po aliasie. Efekt: użytkownik dostaje za szeroki dostęp (kolizje dopasowań) albo błędnie traci dostęp (brak dopasowania) — a przy niektórych kolizjach może zobaczyć dane innej osoby/jednostki.

Bezpieczny wzorzec:

• Mapuj użytkownika po stabilnym identyfikatorze: zwykle UPN (USERPRINCIPALNAME) albo dedykowany klucz użytkownika zsynchronizowany z katalogu.
• Unikaj dopasowań typu „contains”, „endswith(domena)”, aliasów i nazw wyświetlanych.
• W tabeli Security wymuś unikalność mapowania (1 użytkownik → właściwy zakres), a dane mapujące trzymaj w kontrolowanym źródle.

Przykład (uzupełniająco):

// Unikaj dopasowań po fragmencie
// Zamiast: CONTAINSSTRING(Security[Email], USERPRINCIPALNAME())
Security[UPN] = USERPRINCIPALNAME()

Testy weryfikacyjne:

• Przetestuj konta z podobnymi aliasami/UPN (np. imie.nazwisko i imie.nazwisko2) oraz zmiany UPN (scenariusz po zmianie nazwiska).
• Wykonaj test „negatywny”: konto, które nie powinno mieć dostępu do żadnych danych, powinno zwracać puste wyniki (0 wierszy, brak wartości w slicerach).

Błąd	Typowy objaw	Najczęstsza powierzchnia „wycieku bokiem”
RLS nie na dataset	Raport wygląda OK, ale dane da się wyciągnąć poza raportem	Analyze in Excel / własny raport / API
RLS na faktach	Agregaty się zgadzają, ale słowniki/wymiary pokazują za dużo	Tablice wymiarów, slicery
Zła propagacja filtrów	Jedne strony raportu są „bezpieczne”, inne nie	Wizuale oparte o inne fakty
Many-to-many/ambiguous	Niespójne listy wartości, alternatywne ścieżki filtrów	Slicery, drillthrough
Ukrywanie zamiast OLS	„Ukryte” pola nadal dostępne w modelu	Build/klienci zewnętrzni
Niepewne identyfikatory	Kolizje dopasowań lub brak dopasowań	Dynamiczne RLS

4. 11 typowych błędów prowadzących do wycieku danych — część 2 (7–11)

Poniższe błędy nie polegają na „braku RLS”, tylko na tym, że dane da się odczytać inną ścieżką: przez obiekty pomocnicze w modelu, nieoczywiste interakcje DAX, integracje (np. Analyze in Excel) albo funkcje raportowe, które omijają założenia projektanta. W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami — bo „wszystko działa” w jednym raporcie, a mimo to dane potrafią wypłynąć w innym kontekście. Dla każdego punktu: ryzyko, bezpieczny wzorzec i testy, które realnie wykrywają wyciek.

7) Miary, które „rozbroiły” filtr RLS (ALL/REMOVEFILTERS na złej tabeli)

Ryzyko: Najczęstszy wyciek „bokiem” w DAX: miara usuwa filtry z tabeli, na której opiera się RLS (lub z tabeli pośredniej), przez co agregaty liczą się ponad uprawnieniami. Użytkownik może nie zobaczyć szczegółów, ale zobaczy sumy, średnie, KPI obejmujące dane spoza swojej roli.

Bezpieczny wzorzec: Gdy musisz usuwać filtry, rób to precyzyjnie i na właściwym wymiarze, a nie na tabeli zabezpieczającej. Preferuj:

• usuwanie filtrów tylko z kolumn/osi wizualizacji, nie z tabeli, która niesie uprawnienia,
• wzorce typu KEEPFILTERS / ALLEXCEPT (z dużą ostrożnością),
• oddzielne miary „administracyjne” wyłącznie dla ról uprzywilejowanych.

Przykład ryzykowny (usuwa filtr z tabeli, która typowo bywa używana w RLS):

Total Sales (unsafe) =
CALCULATE ( [Sales Amount], REMOVEFILTERS ( 'SecurityMap' ) )

Testy weryfikacyjne:

• Przetestuj każdą „specjalną” miarę (YTD, rankingi, % udziału) w kontekście użytkownika z ograniczonym dostępem i porównaj z wynikiem dla roli pełnej.
• Włącz tabelę z wartościami po kluczach (np. region/klient) i sprawdź, czy suma z miary nie przekracza sumy z widocznych wierszy.
• Sprawdź miary, w których występuje: ALL, REMOVEFILTERS, ALLSELECTED, CROSSFILTER, TREATAS, USERELATIONSHIP.

8) Dynamiczny RLS oparty na USERPRINCIPALNAME(): błędy normalizacji i dopasowania (case, domeny, goście, multi-tenant)

Ryzyko: Dynamiczny RLS zwykle mapuje użytkownika (UPN) do uprawnień w tabeli. Jeżeli dopasowanie jest „kruche” (różne domeny, wielkość liter, sufiksy gości, znaki diakrytyczne, aliasy), możesz dostać dwa scenariusze:

• nadmiarowy dostęp (użytkownik dopasuje się do cudzego wpisu lub do wiersza „catch-all”),
• brak dostępu (a wtedy ktoś dorobi obejście: rola awaryjna, broad access, ręczne dodawanie).

Bezpieczny wzorzec:

• Stosuj jednoznaczny identyfikator (jeśli to możliwe: obiekt AAD/Entra, a nie tylko e-mail). Jeśli musi być UPN/e-mail — normalizuj (trim, lower), unikaj dopasowań częściowych.
• Nie używaj wpisów „dla wszystkich” w tej samej tabeli mapowań, co wpisy indywidualne (częsty błąd logiczny).
• Jeśli występują konta gościnne (B2B), przetestuj ich rzeczywisty format UPN w Twoim tenancie.

Testy weryfikacyjne:

• Co najmniej 5 kont testowych: standardowy, z inną domeną, gość (B2B), użytkownik z aliasem, konto serwisowe.
• Test „kolizji”: dwa wpisy w tabeli mapowań różniące się tylko wielkością liter/spacjami — wynik ma być deterministyczny i bezpieczny.
• Test „brak dopasowania”: jeśli użytkownik nie znajduje się w mapowaniu, wynik musi być zero danych, a nie fallback do szerokiego dostępu.

9) Liczysz na to, że OLS „ukryje” kolumnę, a raport i tak ją wyciąga przez inne obiekty (miary, kalkulacje, tooltipy)

Ryzyko: OLS ma chronić przed odczytem określonych obiektów (tabel/kolumn), ale praktyczne „wycieki” zdarzają się, gdy:

• w modelu istnieją miary lub kolumny kalkulowane, które pośrednio ujawniają wartość ukrytej kolumny (np. flagi, progi, segmenty),
• tooltipy, drillthrough lub strony szczegółowe korzystają z pól, których „nie widać” w głównym widoku,
• autor raportu testował tylko w Desktop, a użytkownik konsumuje dane przez inny klient (np. Excel, inne API), gdzie zachowanie OLS/RLS bywa zaskakujące.

Bezpieczny wzorzec:

• Traktuj OLS jako dodatkową warstwę, nie jako jedyny mechanizm ochrony danych wrażliwych; jeśli dana jest naprawdę wrażliwa, rozważ jej separację (osobny model/dataset).
• Przejrzyj zależności: miary, które odwołują się do kolumn potencjalnie objętych OLS lub do tabel „pomocniczych” z wrażliwymi atrybutami.
• Ujednolić „bezpieczne” zestawy pól do użycia w tooltipach i drillthrough.

Testy weryfikacyjne:

• Test jako rola z OLS: otwórz wszystkie strony, tooltipy, drillthrough, zakładki (bookmarks) i sprawdź, czy nigdzie nie pojawia się informacja pośrednia.
• Weryfikacja miar: wyszukaj w modelu odwołania do wrażliwych kolumn i sprawdź, czy nie da się zrekonstruować wartości (np. przez różnice, rankingi, filtry warunkowe).
• Test w kliencie alternatywnym (np. Excel/Analyze) dla tej samej roli — nie zakładaj, że zachowanie jest identyczne jak w raporcie.

10) Uprawnienia „bokiem”: Build/Analyze, udostępnianie datasetu i niekontrolowane ścieżki dostępu

Ryzyko: Użytkownik nie musi wejść w raport, żeby dostać się do danych. Wystarczy, że ma uprawnienia do datasetu (np. Build) i może analizować dane w innym narzędziu lub stworzyć własny raport. Jeśli RLS/OLS jest niepełne lub przetestowane tylko w kontekście konkretnego raportu, dane mogą wyciec przez:

• Analyze in Excel / połączenie z modelem,
• kopiowanie raportu i edycję wizualizacji,
• łączenie z innymi datasetami i „mieszanie” kontekstów,
• pobieranie danych z wizualizacji (export) w scenariuszach, których nie uwzględniono.

Bezpieczny wzorzec:

• Minimalizuj nadawanie Build tylko do osób, które muszą tworzyć własne raporty, i tylko do datasetów przygotowanych pod self-service.
• Traktuj dataset jako produkt: osobny dla konsumpcji (ściśle kontrolowany) i osobny dla twórców (z odpowiednio zaprojektowanymi rolami i polami).
• Jeśli użytkownik ma mieć dostęp wyłącznie do gotowego raportu, upewnij się, że nie dostaje uprawnień umożliwiających obejście raportu.

Testy weryfikacyjne:

• Sprawdź, czy osoba z rolą „konsument” potrafi połączyć się do datasetu z zewnętrznego klienta lub stworzyć nowy raport.
• Test uprawnień na obiekcie datasetu i workspace (szczególnie Contributor/Member vs Viewer) dla kont testowych.
• Przetestuj „Export data” (summarized/underlying) i sprawdź, czy eksport nie ujawnia pól spoza oczekiwań.

11) „Bezpiecznie, bo ukryte”: pole ukryte, tabela pomocnicza, albo kolumna techniczna ujawnia klucze i pozwala odtworzyć dane

Ryzyko: Ukrycie kolumny/tabeli w modelu (Hide in report view) nie jest zabezpieczeniem. Jeśli użytkownik ma możliwość analizy datasetu lub autor raportu ma dostęp edycyjny, ukryte pola mogą zostać użyte do:

• powiązania danych i odtworzenia wrażliwych atrybutów (np. przez klucze, ID, kombinacje cech),
• ujawnienia struktury (np. istnienie klientów/kontraktów) nawet bez pełnych danych opisowych,
• budowy wizualizacji, która wykorzysta techniczne kolumny do „wyciągnięcia” listy encji.

Bezpieczny wzorzec:

• Jeśli pole jest wrażliwe — kontroluj je przez OLS lub usuń z datasetu przeznaczonego do szerokiej konsumpcji.
• Minimalizuj obecność identyfikatorów, które nie są potrzebne do raportowania (zwłaszcza globalne ID, klucze naturalne, numery dokumentów).
• Stosuj „publiczny” słownik pól: tylko te, które są dozwolone w raportach self-service.

Testy weryfikacyjne:

• Test z perspektywy użytkownika z uprawnieniem do budowy: czy potrafi znaleźć i użyć ukrytych pól w nowym raporcie lub w analizie.
• Przegląd modelu pod kątem kolumn technicznych (ID, GUID, numery) i ocena, czy ich ujawnienie umożliwia rekonstrukcję danych.
• Test „rekonstrukcji”: spróbuj zbudować tabelę z samych kluczy + kilku niegroźnych atrybutów i sprawdź, czy da się jednoznacznie zidentyfikować encje, które powinny pozostać anonimowe.

Błąd (7–11)	Najczęstszy skutek	Co testować najpierw
7) ALL/REMOVEFILTERS na złej tabeli	Agregaty ponad RLS	Miary KPI, rankingi, YTD w roli ograniczonej
8) Kruche dopasowanie USERPRINCIPALNAME	Nadmiarowy dostęp lub fallback	Konta gości/aliasy + scenariusz „brak dopasowania”
9) OLS omijane pośrednio	Wyciek przez miary/tooltip/drillthrough	Tooltipy, strony szczegółowe, zależności miar
10) Build/Analyze i alternatywne ścieżki	Ominięcie raportu	Analyze in Excel, tworzenie własnego raportu, eksport
11) „Ukryte” pola i techniczne klucze	Rekonstrukcja encji	Użycie ukrytych pól w nowym raporcie / analiza kluczy

5. Testowanie i audyt bezpieczeństwa: scenariusze testów, konta testowe, narzędzia i automatyzacja weryfikacji RLS/OLS

RLS/OLS w Power BI bywa „poprawnie skonfigurowane” tylko na papierze — dopóki nie zostanie sprawdzone w warunkach zbliżonych do produkcyjnych. Testy bezpieczeństwa modelu powinny odpowiadać na dwa pytania: czy użytkownik widzi wyłącznie dozwolone wiersze (RLS) oraz czy nie ma dostępu do niedozwolonych obiektów (OLS). Audyt z kolei ma potwierdzić, że ten stan utrzymuje się mimo zmian w modelu, uprawnieniach, raportach i integracjach.

5.1. Co testować: różne „powierzchnie” dostępu do danych

W praktyce te same role RLS/OLS należy weryfikować w kilku punktach wejścia, bo każda ścieżka może inaczej egzekwować uprawnienia lub ujawniać metadane.

Powierzchnia	Co weryfikować	Dlaczego ma znaczenie dla RLS/OLS
Raport (wizualizacje)	Widoczność rekordów, sum, drill-through, tooltipy	RLS zwykle działa poprawnie, ale „boczne” ujawnienia mogą pojawić się w interakcjach
Tabele/Model (dataset)	Lista tabel/kolumn/miar, możliwość przeglądania danych	OLS ma ukrywać obiekty; bez testów łatwo przeoczyć ekspozycję metadanych
Tryb „Analyze in Excel” / połączenia zewnętrzne	Widoczność pól i danych w kliencie zewnętrznym	Inne narzędzia potrafią ujawnić więcej niż raport (np. listę pól, hierarchie)
Eksport danych	Eksport podsumowany i szczegółowy, „Show as a table”, kopiowanie	Możliwy wyciek przy eksporcie, jeśli ograniczenia nie są spójne z intencją
API / integracje	Odpowiedzi API w kontekście użytkownika	W automatyzacji i integracjach często pomija się testy ról i tożsamości

5.2. Scenariusze testowe: minimalny zestaw, który łapie większość wycieków

Scenariusze powinny być oparte o role i przypadki użycia, a nie o pojedyncze wizualizacje. Poniżej zestaw testów, które warto utrzymywać jako stały „pakiet regresji” po każdej zmianie modelu lub uprawnień.

• Test negatywny (deny-by-default): użytkownik bez przypisanej roli nie widzi danych (lub widzi tylko publiczne, jeśli tak zaprojektowano).
• Test brzegowy zakresu: użytkownik o najwęższym dostępie widzi wyłącznie jeden klient/oddział/region; brak „przecieków” w sumach i w drill-down.
• Test wieloról: użytkownik przypisany do kilku ról (lub kilku grup) ma dostęp zgodny z oczekiwaną logiką (np. suma uprawnień, a nie ich przecięcie — zależnie od przyjętego wzorca).
• Test hierarchii i relacji: sprawdź, czy filtracja propaguje się przez relacje tak, jak zakładasz (w obie strony tylko jeśli to świadomie dopuszczone).
• Test „miary vs dane szczegółowe”: czy miary nie ujawniają informacji o niedozwolonych rekordach poprzez różnice, wskaźniki lub metryki pośrednie.
• Test obiektów ukrytych (OLS): użytkownik nie widzi tabel/kolumn/miar, które mają być zablokowane — zarówno w raporcie, jak i w narzędziach zewnętrznych.
• Test eksportów: sprawdź, co dokładnie da się wyeksportować (podsumowanie vs szczegóły) i czy eksport respektuje RLS/OLS.
• Test „pusty”: rola zwracająca zero wierszy nie powoduje błędów, które mogłyby ujawnić metadane lub wartości (np. poprzez komunikaty).
• Test użytkownika uprzywilejowanego: weryfikacja, kto realnie ma obejście (Admin/Member/Contributor/Build) i czy jest to zgodne z polityką.

5.3. Konta testowe i mapowanie tożsamości

Najczęstszy błąd w testach RLS to sprawdzanie „na sobie” w roli autora raportu. To nie jest wiarygodne środowisko: uprawnienia właściciela, rola w workspace, a nawet sposób publikacji mogą maskować problemy. Zamiast tego przygotuj kontrolowany zestaw tożsamości:

• Co najmniej 4 konta testowe: (1) brak dostępu, (2) minimalny dostęp, (3) typowy dostęp, (4) szeroki dostęp.
• Oddzielne konta dla scenariuszy wieloról: jedno konto, które należy do dwóch grup równolegle (jeśli to wspierasz).
• Kontrola mapowania: jeżeli RLS zależy od UPN/e-maila, dopilnuj zgodności formatu tożsamości (różne domeny/aliasy) i przetestuj „nietypowe” przypadki.
• Testy na grupach, nie tylko na użytkownikach: większość wdrożeń mapuje role do grup; testy muszą odtwarzać tę praktykę.

W audycie warto mieć prostą macierz: tożsamość → rola → oczekiwany zakres danych. Taki artefakt ułatwia powtarzalność testów i wykrywanie regresji po zmianach w organizacji (np. migracje domen, zmiany UPN, konsolidacje grup).

5.4. Narzędzia do testowania: ręcznie, półautomatycznie i „na pipeline”

Dobór narzędzi zależy od tego, czy celem jest jednorazowa walidacja, czy powtarzalny audyt. Poniżej praktyczny podział.

• Power BI Desktop (View as): szybka weryfikacja logiki ról na etapie budowy; traktuj jako test wstępny, nie końcowy.
• Power BI Service (Test as role / oglądanie jako użytkownik): test „prawie produkcyjny”, bo obejmuje publikację, uprawnienia do datasetu i zachowanie raportu online.
• DAX Studio / narzędzia klienckie do zapytań: kontrola tego, co da się faktycznie odpytać w kontekście roli; przydatne do sprawdzania OLS i metadanych (tam, gdzie jest to możliwe).
• Analyze in Excel / inne klienckie narzędzia: test, czy użytkownik nie widzi „więcej” niż w raporcie (pola, hierarchie, tabele przestawne, szczegóły).
• REST API / skrypty administracyjne: inwentaryzacja uprawnień, wykrywanie niepożądanych ustawień i zmian; dobre do audytu cyklicznego.

5.5. Automatyzacja weryfikacji RLS/OLS: co da się zautomatyzować sensownie

Automatyzacja testów bezpieczeństwa powinna być pragmatyczna: nie wszystko da się zweryfikować w 100% bez interakcji użytkownika, ale można znacząco ograniczyć ryzyko poprzez stałe, powtarzalne kontrole.

• Testy kontraktowe wyników: dla wybranych ról uruchamiaj zestaw zapytań kontrolnych i porównuj wyniki z oczekiwanym „podpisem” (np. liczba rekordów, suma sprzedaży dla kontrolnej jednostki).
• Testy metadanych (OLS): weryfikuj, czy „zabronione” obiekty nie są widoczne w listach pól/metadata endpoints (tam, gdzie masz do tego techniczną możliwość).
• Kontrola konfiguracji: automatycznie sprawdzaj ustawienia datasetu/raportu (uprawnienia Build, eksporty, integracje) jako część checklisty CI/CD.
• Regresja po zmianach modelu: każdy merge/publikacja powinny uruchamiać testy dla najważniejszych ról (przynajmniej minimalna i typowa).

Poniżej przykładowy szkic zapytania kontrolnego (tylko jako idea), które można wykorzystać w podejściu kontraktowym — celem jest uzyskanie stabilnego wskaźnika dla roli, a nie pełnego odtworzenia raportu:

-- Przykład: proste „podpisy” kontrolne
EVALUATE
ROW(
  "RowCount_Fact", COUNTROWS('Fact'),
  "Sum_Amount", CALCULATE(SUM('Fact'[Amount]))
)

5.6. Audyt: jak utrzymać pewność, że bezpieczeństwo nie „rozjechało się” w czasie

Audyt RLS/OLS to nie jednorazowe wydarzenie, tylko proces. Minimalny, praktyczny zakres audytu obejmuje:

• Inwentaryzację ról i mapowań: które role istnieją, kto (użytkownicy/grupy) jest do nich przypisany i czy te przypisania są nadal uzasadnione.
• Przegląd zmian w modelu: nowe tabele/kolumny/miary mogą ominąć założenia bezpieczeństwa, jeśli nie uwzględniono ich w testach regresji.
• Przegląd uprawnień do datasetu: szczególnie uprawnień pozwalających budować nowe raporty lub łączyć się zewnętrznie, jeśli organizacja tego nie chce.
• Przegląd ustawień eksportu i integracji: czy polityka organizacji jest odzwierciedlona w ustawieniach tenant/workspace/dataset.
• Dowody z testów: zapis wyników (np. daty, konto testowe, oczekiwany/uzyskany wynik) — to przyspiesza diagnozę i ułatwia zgodność.

Efektem testów i audytu powinien być powtarzalny „pakiet” kontroli: kilka kont testowych, lista scenariuszy, zautomatyzowane zapytania kontrolne oraz cykliczny przegląd uprawnień. To zwykle wystarcza, by wykryć większość wycieków zanim trafią na produkcję — albo zanim zostaną odkryte przez użytkowników.

6. Minimum security checklist przed publikacją

Poniższa lista to minimum, które warto przejść przed publikacją (lub republish) raportu/datasetu w Power BI. Celem jest ograniczenie „bocznych” ścieżek ujawnienia danych: przez model, uprawnienia w usłudze, eksporty, integracje oraz funkcje klienckie (np. Analyze in Excel).

6.1. Model (dataset semantic model): co może wyciec „z definicji”

• Wrażliwe kolumny: sprawdź, czy w modelu nie ma kolumn, które nie powinny być widoczne dla części użytkowników (np. stawki, marże, identyfikatory). Jeśli nie są potrzebne do obliczeń/relacji – usuń je z modelu.
• OLS tam, gdzie trzeba ukryć obiekt: jeśli dana tabela/kolumna ma być niewidoczna dla części odbiorców, zweryfikuj, czy używasz OLS (a nie wyłącznie „ukrycia” w raporcie).
• Ukryte ≠ zabezpieczone: elementy „Hidden” w modelu wciąż mogą być dostępne przez narzędzia klienckie, DAX/MDX lub integracje – potraktuj je jak publiczne, jeśli nie są objęte OLS.
• Miary i ekspresje: sprawdź, czy miary nie ujawniają wrażliwych wartości wprost (np. przez nieintencjonalne agregacje) i czy nie odwołują się do obiektów, które powinny być ukryte.
• Metadane: oceń, czy nazwy tabel/kolumn nie zdradzają informacji (np. „Salary”, „Bonus”). Jeśli to problem – rozważ neutralne nazewnictwo tam, gdzie to uzasadnione.
• Brak zbędnych tabel pomocniczych: usuń/odłącz tabele staging, logi odświeżeń, surowe dumpy, jeśli nie są konieczne w warstwie semantycznej.

6.2. Raport: ekspozycja przez wizualizacje i funkcje użytkownika

• Eksport danych: sprawdź ustawienia eksportu (podsumowane/niepodsumowane) w kontekście wrażliwych pól. Jeśli eksport jest dopuszczony, upewnij się, że nie umożliwia obejścia intencji (np. wydobycia zbyt szczegółowych danych).
• Drillthrough, tooltip pages, bookmarks: przejrzyj strony drillthrough i tooltipy pod kątem pól, które mogą pojawić się użytkownikowi „przy okazji”.
• Personalize visuals: jeśli jest włączone, użytkownik może dodać pola do wizualizacji; upewnij się, że nie odsłoni to danych, które miały być tylko „ukryte”.
• Q&A: jeśli używasz Q&A, zweryfikuj, czy nie ułatwia ono dotarcia do pól, których nie chcesz eksponować.
• Custom visuals: zweryfikuj, czy użyte wizualizacje są zaufane i czy ich użycie jest zgodne z polityką bezpieczeństwa (w tym przegląd uprawnień i źródeł).

6.3. Uprawnienia w Power BI Service: „kto ma co”

Najczęstsze wycieki po publikacji wynikają z nieintencjonalnego przydziału uprawnień. Minimalizuj zakres i trzymaj się zasady least privilege.

• Workspace roles: przejrzyj członkostwo w obszarze roboczym. Unikaj nadawania roli Member/Contributor osobom, które powinny tylko konsumować raporty.
• Dataset permissions: sprawdź, kto ma Build (tworzenie własnych raportów na dataset). To uprawnienie często otwiera „boczne” scenariusze eksploracji danych.
• Report permissions: rozdziel uprawnienia do raportu od uprawnień do datasetu, jeśli to ma znaczenie (np. użytkownik ma widzieć raport, ale nie budować własnych analiz).
• App vs direct share: preferuj dystrybucję przez aplikacje i grupy (Entra ID), ogranicz „udostępnianie ad hoc” do wyjątków.
• Udostępnianie zewnętrzne (B2B): jeśli stosowane, zweryfikuj reguły i grupy, a także czy RLS/OLS działa zgodnie z oczekiwaniami dla gości.
• Subskrypcje, e-mail, załączniki: sprawdź, czy subskrypcje nie wysyłają danych poza kontrolowany kanał (np. zrzuty ekranu/obrazy do osób, które nie powinny ich dostać).

6.4. Integracje i kanały dostępu: gdzie użytkownik może „wyjść poza raport”

Powierzchnia	Co sprawdzić przed publikacją	Minimalne działanie
Analyze in Excel / Excel Pivot	Czy użytkownicy mają Build i czy mogą przeglądać model poza raportem	Ogranicz Build do ról analitycznych; stosuj OLS dla obiektów, które nie mogą być widoczne
„Build new report” w usłudze	Czy dataset jest discoverable i kto może budować raporty	Kontroluj Build i dostęp do datasetu; rozważ certyfikację/promowanie tylko zatwierdzonych modeli
Power BI Desktop (połączenie live)	Czy użytkownicy mogą podłączyć się do datasetu i eksplorować pola/miary	Build tylko dla upoważnionych; OLS dla wrażliwych obiektów
XMLA / narzędzia zewnętrzne	Czy organizacja dopuszcza użycie narzędzi typu DAX Studio/Tabular Editor przez użytkowników	Ogranicz do admin/BI dev; pilnuj ról i uprawnień do datasetu
Export/CSV, copy table	Czy eksport nie ujawnia poziomu szczegółowości ponad założenia	Wyłącz eksport tam, gdzie to konieczne; przetestuj eksport dla kont o różnych rolach
Teams/SharePoint osadzenia	Czy osadzenie nie rozszerza grona odbiorców ponad kontrolowane grupy	Stosuj grupy i aplikacje; audytuj uprawnienia do miejsc osadzenia

6.5. Ustawienia dzierżawy i polityki (tenant settings): zgodność z bezpieczeństwem

• Eksport danych: weryfikacja ustawień na poziomie tenant oraz ewentualnych wyjątków dla grup.
• Użycie wizualizacji niestandardowych: czy polityka organizacji pozwala na import i użycie; jeśli tak – czy jest kontrola źródła.
• Publish to web: upewnij się, że funkcja jest wyłączona lub restrykcyjnie kontrolowana, jeśli dane nie są publiczne.
• Integracje z narzędziami zewnętrznymi: kontrola, kto może używać połączeń/analityki poza Power BI.

6.6. Dane i odświeżanie: poświadczenia, gateway, zakres danych

• Poświadczenia źródeł: sprawdź, czy dataset używa konta serwisowego/poświadczeń zgodnych z polityką (bez kont osobistych w produkcji).
• Gateway: zweryfikuj, kto jest administratorem gateway i kto może dodawać/edytować źródła danych.
• Zakres danych w Power Query: potwierdź, że do modelu nie trafiają nadmiarowe rekordy „na zapas”, jeśli nie są potrzebne (minimalizacja danych).
• Parametry i środowiska: upewnij się, że parametry wskazują właściwe środowisko (prod), a testowe endpointy nie są przypadkowo publikowane.

6.7. Szybkie testy przed publikacją (smoke tests)

• Test kontami o różnych rolach: zweryfikuj, że użytkownik bez uprawnień nie widzi datasetu/raportu, a użytkownik z uprawnieniami widzi dokładnie to, co powinien.
• Test „poza raportem”: dla roli konsumenckiej sprawdź, czy dostęp jest możliwy przez Analyze in Excel / „Build new report” / eksport.
• Test eksportu: wykonaj eksport z kluczowych stron (w tym drillthrough/tooltip) i porównaj zakres danych z założeniami.
• Test metadanych: sprawdź listę pól w panelu pól (i w narzędziach klienckich, jeśli dopuszczone) pod kątem obiektów, które nie powinny być widoczne.

6.8. Minimalny „gate” publikacyjny (do skopiowania jako checklist)

• [ ] Usunięto zbędne kolumny/tabele z modelu; wrażliwe obiekty zabezpieczono OLS (jeśli dotyczy)
• [ ] Zweryfikowano ustawienia eksportu i funkcje typu Personalize visuals / Q&A (jeśli używane)
• [ ] Uprawnienia workspace/dataset/report ustawione zgodnie z least privilege; Build tylko dla upoważnionych
• [ ] Sprawdzono integracje: Analyze in Excel, „Build new report”, live connect, XMLA (w zakresie organizacji)
• [ ] Tenant settings zgodne z polityką (w szczególności eksporty i Publish to web)
• [ ] Poświadczenia/gateway/parametry odświeżania zweryfikowane; brak kont osobistych w produkcji
• [ ] Wykonano smoke testy dla ról: raport + eksport + scenariusze „poza raportem”

7. Dobre praktyki utrzymania: monitoring, zarządzanie zmianą, dokumentacja ról i cykliczne przeglądy

Bezpieczeństwo w Power BI nie kończy się na poprawnym ustawieniu RLS/OLS i opublikowaniu raportu. Model żyje: zmieniają się źródła danych, relacje, miary, grupy użytkowników, a także sposób, w jaki odbiorcy konsumują dane (aplikacje, eksporty, integracje). Utrzymanie polega na tym, by wyłapywać odchylenia, kontrolować zmiany i regularnie weryfikować założenia zanim drobna modyfikacja otworzy „boczną” ścieżkę ujawnienia danych.

Monitoring: widoczność i wczesne ostrzeganie

Monitoring ma dwa cele: po pierwsze wykryć nietypowe zachowania (np. nagły wzrost eksportów, nietypowe odpytywanie datasetu), po drugie potwierdzać, że mechanizmy kontroli dostępu działają zgodnie z oczekiwaniami po zmianach.

• Obserwuj użycie datasetów i raportów: kto, kiedy i jak często korzysta z zasobów. Skokowe wzrosty użycia, szczególnie w godzinach poza standardem, mogą sygnalizować nadużycia lub błędne udostępnienia.
• Śledź operacje wysokiego ryzyka: eksport danych, pobieranie plików, użycie integracji klienckich i narzędzi zewnętrznych. Sama obecność takich operacji nie jest zła, ale powinna być spodziewana i uzasadniona rolą odbiorcy.
• Monitoruj zmiany uprawnień: dodanie użytkownika do roli, zmiana członkostwa w grupach, zmiana ustawień workspace/app oraz przejęcie własności artefaktów to zdarzenia, które powinny być rejestrowane i okresowo przeglądane.
• Ustal progi i alerty: nie chodzi o „alert na wszystko”, tylko o sygnały dla zdarzeń, które najczęściej poprzedzają wyciek: masowe eksporty, nietypowe odpytywanie, częste błędy dostępu, nagłe zmiany w rolach.
• Odseparuj monitoring od zespołu tworzącego, jeśli to możliwe: minimalizuje to ryzyko konfliktu interesów i ułatwia niezależną ocenę stanu bezpieczeństwa.

Zarządzanie zmianą: bezpieczeństwo jako element procesu wdrożeniowego

Najwięcej „bocznych” wycieków powstaje nie w dniu projektowania, tylko przy pozornie niewinnych zmianach: nowa tabela, nowa relacja, zmiana kierunku filtrowania, dopięcie wymiaru, dodanie miary, przebudowa hierarchii lub nowe wymaganie biznesowe. Dlatego zmiana w modelu powinna przechodzić przez proces, który zawiera elementy bezpieczeństwa.

• Klasyfikuj zmiany pod kątem ryzyka: zmiany w relacjach, tabelach uprawnień, logice ról i miarach traktuj jako wysokiego ryzyka i wymagające dodatkowej weryfikacji.
• Stosuj środowiska (np. deweloperskie/testowe/produkcyjne) i ograniczaj „ręczne poprawki” na produkcji. Im mniej zmian ad hoc, tym mniejsze prawdopodobieństwo rozjechania się konfiguracji.
• Wymagaj przeglądu (peer review) dla zmian w obszarach wrażliwych: role, relacje, tabele mapujące użytkowników, miary wpływające na filtrację lub agregację.
• Utrzymuj spójne zasady publikacji: publikacja powinna być powtarzalna, a nie zależna od pojedynczej osoby. Dobrą praktyką jest też jasne rozdzielenie: kto buduje, kto zatwierdza, kto publikuje.
• Uwzględniaj wpływ zmian na konsumpcję danych: to samo RLS/OLS może zachować się inaczej, gdy raporty zaczynają wykorzystywać nowe wizualizacje, nowe ścieżki drill-through lub integracje.

Dokumentacja ról: jeden język dla biznesu i zespołu technicznego

RLS/OLS to reguły, które muszą być zrozumiałe i odtwarzalne. Bez dokumentacji szybko pojawiają się „role historyczne”, nikt nie pamięta, po co powstały wyjątki, a zmiany w organizacji nie mają odzwierciedlenia w modelu.

• Opisuj role językiem biznesowym: kto ma mieć dostęp do jakiego zakresu danych i dlaczego. Sama nazwa roli bez uzasadnienia to za mało.
• Rozdziel „założenia” od „implementacji”: jedno to polityka dostępu (co jest dozwolone), drugie to sposób realizacji w modelu (jak to jest zrobione). To pomaga wykryć rozjazdy między intencją a wykonaniem.
• Dokumentuj wyjątki: każdy wyjątek powinien mieć właściciela biznesowego, datę przeglądu i kryterium wygaśnięcia. Wyjątki bez terminu są najczęstszym źródłem trwałych luk.
• Ustal właścicieli: rola powinna mieć właściciela biznesowego (odpowiedzialnego za to, kto powinien mieć dostęp) oraz właściciela technicznego (odpowiedzialnego za poprawność implementacji).
• Utrzymuj słownik pojęć i danych wrażliwych: co jest danymi poufnymi, co jest ograniczone do działów/regionów, jakie kolumny wymagają szczególnej ochrony. To ułatwia spójne decyzje w czasie rozwoju modelu.

Cykliczne przeglądy: kontrola driftu i zgodności z rzeczywistością

Nawet najlepiej zaprojektowany model z czasem „dryfuje”: zmienia się struktura organizacyjna, powstają nowe jednostki, użytkownicy zmieniają role, a dataset rośnie o nowe obszary danych. Cykliczne przeglądy mają zatrzymać ten drift, zanim doprowadzi do niezamierzonego ujawnienia informacji.

• Przegląd ról i członkostw: okresowo potwierdzaj, że użytkownicy i grupy są przypisani do właściwych ról, a dostęp osób, które zmieniły stanowisko lub opuściły organizację, został odebrany.
• Przegląd zmian w modelu: sprawdzaj, czy nowe tabele, relacje, miary i kolumny nie stworzyły nieoczekiwanych ścieżek dostępu. Szczególnie ważne są nowe obszary danych dodawane „szybko”, pod presją biznesu.
• Przegląd raportów i sposobów użycia: to, że dataset jest zabezpieczony, nie znaczy, że wszystkie raporty używające go są równie bezpieczne w kontekście eksportów, udostępnień i integracji.
• Weryfikacja zgodności z politykami: jeśli organizacja ma wewnętrzne zasady klasyfikacji danych i minimalnych uprawnień, przegląd powinien potwierdzać zgodność oraz wskazywać odchylenia.
• Retencja i usuwanie: role, które nie są używane, konta testowe, tymczasowe wyjątki i stare artefakty to „dług bezpieczeństwa”. Przeglądy powinny kończyć się konkretnymi decyzjami: zostaje, zmieniamy, usuwamy.

Praktyczny rytm utrzymania

Aby utrzymanie nie było jednorazową akcją, warto wprowadzić prosty, powtarzalny rytm:

• Po każdej zmianie o wysokim ryzyku: przegląd bezpieczeństwa i potwierdzenie, że dostęp jest zgodny z założeniami.
• Regularnie (np. miesięcznie/kwartalnie): przegląd ról, członkostw, wyjątków i nietypowych zdarzeń w użyciu.
• Po zmianach organizacyjnych: aktualizacja mapowania użytkowników i walidacja, czy nowe struktury (regiony, działy, jednostki) są odzwierciedlone w modelu.
• Przed kluczowymi publikacjami: szybka kontrola, czy nowe funkcje raportów lub nowe integracje nie zwiększają powierzchni ekspozycji danych.

W efekcie RLS/OLS przestaje być „ustawieniem”, a staje się procesem. To właśnie proces — monitoring, kontrola zmian, dokumentacja i przeglądy — minimalizuje ryzyko, że dane wypłyną „bokiem” przy kolejnej iteracji modelu.

Checklist wdrożeniowy oraz „najczęstsze symptomy i naprawy”

Ta sekcja to praktyczna lista kontrolna do wdrożenia bezpieczeństwa w Power BI oraz szybki przewodnik „objaw → możliwa przyczyna → naprawa”. Zakłada rozróżnienie dwóch warstw: RLS (ogranicza wiersze danych widoczne dla użytkownika) oraz OLS (ukrywa obiekty modelu: tabele/kolumny/miary), które w praktyce chronią przed innymi typami „wycieków bokiem”.

Checklist wdrożeniowy (przed publikacją i przed nadaniem dostępu)

• Zdefiniuj zakres ochrony: co ma być izolowane przez RLS (np. region, klient, jednostka) i co ma być ukryte przez OLS (np. kolumny wrażliwe, techniczne tabele, miary pomocnicze).
• Ustal „źródło prawdy” dla tożsamości: jednoznacznie określ, czy filtrujesz po UPN/e-mail, identyfikatorze użytkownika, czy członkostwie w grupie; unikaj mieszania sposobów mapowania w różnych miejscach modelu.
• Projektuj role od ogółu do szczegółu: zacznij od najmniejszej liczby ról, następnie doprecyzuj; preferuj role oparte o atrybuty (mapowanie użytkownik→domena danych), zamiast ręcznego wpisywania wyjątków.
• Sprawdź spójność relacji i kierunków filtracji: upewnij się, że filtr z tabeli bezpieczeństwa propaguje się do wszystkich tabel faktów, które mają być ograniczane; unikaj sytuacji, w której część modelu zostaje poza zasięgiem filtra.
• Zidentyfikuj powierzchnie ekspozycji: raport, dataset, aplikacja, eksport danych, integracje (np. Analyze in Excel), endpointy/połączenia; potwierdź, że wybrany model RLS/OLS jest spójny z tym, jak użytkownicy będą konsumować dane.
• Uprawnienia do datasetu: sprawdź, kto ma prawa „Build” i „Read”; minimalizuj uprawnienia pozwalające na samodzielne tworzenie zawartości na bazie datasetu, jeśli nie jest to wymagane.
• Widoczność obiektów w modelu: jeżeli użytkownicy nie powinni nawet wiedzieć o istnieniu części danych (np. kolumn wrażliwych), zaplanuj OLS zamiast polegać wyłącznie na ukryciu w raporcie.
• Spójność między raportami: jeśli kilka raportów korzysta z tego samego datasetu, potwierdź, że każdy z nich nie wprowadza alternatywnych ścieżek dostępu (np. strony „diagnostyczne”, wizualizacje techniczne, niepotrzebne drill-through).
• Standard testów ról: przygotuj minimalny zestaw przypadków testowych (użytkownik z jednym zakresem, z wieloma zakresami, bez zakresu, użytkownik „spoza mapowania”); przetestuj w usługach (Service), nie tylko lokalnie.
• Plan awaryjny: zdefiniuj, co ma się stać, gdy użytkownik nie ma przypisania (domyślnie brak danych); zaplanuj komunikat w raporcie, by ograniczyć zgłoszenia typu „nic nie widzę”.

Najczęstsze symptomy i naprawy (szybka diagnostyka)

• Symptom: użytkownik widzi „wszystko”, mimo że ma być ograniczony.
  Najczęstsze przyczyny: rola nieprzypisana w usłudze; użytkownik korzysta z innego konta/UPN; dataset udostępniony w sposób omijający oczekiwania (np. inne uprawnienia niż zakładano).
  Naprawa: zweryfikuj przypisanie do roli w Service, tożsamość logowania, oraz sposób nadania dostępu do datasetu/aplikacji; potwierdź, że testujesz dokładnie to konto, które ma produkcyjnie korzystać.
• Symptom: użytkownik widzi „za mało” albo „puste raporty”.
  Najczęstsze przyczyny: brak mapowania użytkownika w tabeli bezpieczeństwa; filtr trafia w „ślepą uliczkę” (nie propaguje się do faktów); relacje nie obejmują wszystkich tabel użytych w wizualizacjach.
  Naprawa: sprawdź, czy dla danego użytkownika istnieje wpis mapujący; prześledź drogę filtra od tabeli bezpieczeństwa do tabel z danymi; usuń/napraw przerwane relacje i niespójne klucze.
• Symptom: część stron/visuali jest poprawnie ograniczona, ale inne pokazują dane spoza zakresu („wyciek bokiem”).
  Najczęstsze przyczyny: w raporcie użyto tabeli/miary, która nie jest objęta propagacją filtra; istnieje alternatywna ścieżka relacji; model zawiera obiekty, które powinny być ukryte (OLS), ale są dostępne w polach.
  Naprawa: zidentyfikuj, z jakich tabel korzystają „podejrzane” wizualizacje; zapewnij, że wszystkie te tabele są filtrowane tym samym mechanizmem RLS; tam, gdzie wymagane, wprowadź OLS dla wrażliwych obiektów modelu.
• Symptom: użytkownik nie widzi danych w raporcie, ale potrafi je wydobyć przez eksport/połączenie zewnętrzne lub tworzenie własnych raportów.
  Najczęstsze przyczyny: poleganie na „ukryciu” elementów w raporcie zamiast ochrony w modelu; zbyt szerokie uprawnienia do datasetu (np. możliwość budowania); brak OLS dla wrażliwych kolumn/tabel.
  Naprawa: przenieś ochronę na poziom modelu (RLS/OLS) zgodnie z celem; ogranicz uprawnienia do datasetu do minimum; oceń, czy konkretne integracje powinny być dozwolone dla danej grupy użytkowników.
• Symptom: różne osoby w tej samej roli widzą inne wyniki bez oczywistego powodu.
  Najczęstsze przyczyny: niespójne identyfikatory użytkownika (np. e-mail vs UPN vs różne domeny); niejednoznaczne mapowanie (duplikaty wpisów); różnice w członkostwie w grupach synchronizowanych z opóźnieniem.
  Naprawa: ujednolić identyfikator tożsamości w całym rozwiązaniu; usuń duplikaty i wprowadź walidacje w danych mapujących; ustal zasady aktualizacji członkostw i czas propagacji.
• Symptom: użytkownik widzi nazwy kolumn/tabel lub metadane, których „nie powinien widzieć”, mimo że wartości są ograniczone.
  Najczęstsze przyczyny: zastosowano tylko RLS (ograniczenie wierszy), ale wymagane jest ukrycie samego obiektu; pozostawiono techniczne tabele/kolumny dostępne w polach.
  Naprawa: użyj OLS do ukrycia obiektów modelu; zredukuj widoczność pól do niezbędnego minimum i uporządkuj model pod kątem ekspozycji metadanych.
• Symptom: po zmianie modelu/odświeżeniu nagle „psuje się” bezpieczeństwo (ktoś widzi więcej lub mniej niż wcześniej).
  Najczęstsze przyczyny: zmiany relacji lub kluczy bez aktualizacji logiki ról; dodanie nowych tabel/miar bez objęcia ich zasadami; nieprzetestowane warianty po wdrożeniu.
  Naprawa: traktuj zmiany w modelu jak zmianę w mechanizmie bezpieczeństwa; po każdej modyfikacji wykonuj zestaw testów regresji ról; dodane obiekty oceniaj pod kątem RLS i OLS.
• Symptom: użytkownik powinien widzieć dane z wielu zakresów (np. kilka regionów), ale widzi tylko jeden lub wyniki są niepełne.
  Najczęstsze przyczyny: mapowanie użytkownik→zakres jest modelowane jak relacja „jeden do jednego” zamiast „wiele”; błędna logika łączeń w danych mapujących.
  Naprawa: przeprojektuj mapowanie jako relację umożliwiającą wiele przypisań; zweryfikuj integralność danych mapujących oraz to, czy agregacje nie „gubią” części uprawnień.
• Symptom: osoby administrujące workspace’em przypadkowo omijają założenia testów bezpieczeństwa i raport „wydaje się” poprawny.
  Najczęstsze przyczyny: testy wykonywane na kontach z podwyższonymi uprawnieniami; brak kont testowych odzwierciedlających realnych użytkowników.
  Naprawa: testuj na dedykowanych kontach bez uprawnień administracyjnych; odseparuj rolę „twórcy” od roli „konsumenta” podczas weryfikacji.

Wskazówka operacyjna: jeśli nie potrafisz jednoznacznie odpowiedzieć, czy problem dotyczy zakresu wierszy (RLS) czy ekspozycji obiektów (OLS), zacznij od zidentyfikowania, czy użytkownik widzi niepoprawne rekordy, czy raczej ma dostęp do niepożądanych pól/kolumn/miar. To najszybciej zawęża obszar poszukiwań.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.