Ukryte wycieki danych w Power BI: jak sprawdzić uprawnienia modelu, zanim będzie za późno

Co dokładnie oznacza „boczny” wyciek danych w Power BI i skąd się bierze?

„Boczny” wyciek danych w Power BI to sytuacja, w której użytkownik nie otrzymuje danych „wprost” przez widok raportu, do którego ma dostęp, ale jest w stanie pośrednio je odczytać lub odtworzyć inną ścieżką dostępu w tym samym rozwiązaniu (raporcie/modelu/datasets). Kluczowe jest to, że omija on intencję projektanta raportu (np. ukryte wizualizacje, brak wyświetlania pewnych pól) i dociera do informacji poprzez elementy, które nadal mają techniczny dostęp do danych.

Źródłem takiego wycieku jest najczęściej rozjazd między tym, co „widać” w raporcie, a tym, co jest faktycznie dozwolone przez zabezpieczenia modelu. Power BI rozdziela warstwę prezentacji (raport) od warstwy danych (model/dataset). Jeśli ograniczenia opierają się wyłącznie na projekcie raportu (np. ukryciu pól, stron, wizualizacji, wyłączeniu interakcji) zamiast na egzekwowalnych regułach w modelu (uprawnienia do datasetu, RLS/OLS), użytkownik może uzyskać dostęp do danych poprzez inne funkcje lub artefakty, które nadal korzystają z tego samego datasetu.

W praktyce „boczny” wyciek bierze się z tego, że użytkownik ma szerszy poziom uprawnień do datasetu lub jego metadanych niż zakłada autor raportu, albo że w modelu nie ograniczono dostępu do określonych tabel/kolumn/wierszy, mimo że raport tego nie pokazuje. Wtedy alternatywne sposoby eksploracji (np. budowanie własnych wizualizacji na bazie datasetu, analizowanie danych poza gotowym układem raportu, wykorzystywanie pól w innych kontekstach raportu) mogą ujawnić wartości, które miały pozostać niewidoczne.

Jakie uprawnienia są najczęściej mylone i prowadzą do niekontrolowanego dostępu do danych?

Najczęstsze pomyłki wynikają z mieszania trzech warstw: uprawnień do przestrzeni roboczej (kto może publikować i zarządzać artefaktami), uprawnień do samego zestawu danych/modelu semantycznego (kto może budować na nim raporty i odczytywać dane) oraz uprawnień do raportu/aplikacji (kto może tylko oglądać konkretną wizualizację). W praktyce to właśnie błędne założenie, że dostęp do raportu ogranicza dostęp do danych „pod spodem”, prowadzi do niekontrolowanego ujawniania informacji.

Najbardziej ryzykowne jest mylenie roli „Viewer” w workspace z bezpiecznym, ograniczonym podglądem. Viewer może mieć możliwość odczytu zestawu danych użytego w raportach w tej przestrzeni i w konsekwencji otworzyć drogę do dostępu poza sam raport (np. przez analizę w Excelu lub tworzenie własnych raportów), jeśli jednocześnie ma włączone uprawnienia do budowania na modelu.

Drugą częstą pomyłką jest traktowanie uprawnienia „Build” jako technicznego dodatku „dla developerów”, podczas gdy w praktyce jest to uprawnienie do korzystania z modelu jako źródła danych. Jeśli użytkownik dostaje „Build” do szeroko udostępnionego modelu, może tworzyć własne raporty i zestawiać dane w sposób nieprzewidziany przez autorów raportów, a tym samym ominąć ograniczenia wynikające z samej konstrukcji raportu.

Trzecie źródło niekontrolowanego dostępu to utożsamianie członkostwa w rolach workspace typu „Member” lub „Contributor” z możliwością „edytowania raportów”, bez świadomości, że takie role zwykle wiążą się z szerokim dostępem do artefaktów w przestrzeni, w tym do zestawów danych oraz możliwości ich ponownego użycia i dystrybucji. W efekcie użytkownik, który miał tylko współtworzyć raport, może uzyskać dostęp do danych szerszy niż docelowi odbiorcy raportu.

Dodatkowo często myli się zabezpieczenia na poziomie raportu z zabezpieczeniami na poziomie danych. Ograniczenia realizowane wyłącznie przez filtrację w raporcie nie są mechanizmem bezpieczeństwa modelu; jeżeli użytkownik ma uprawnienia do pracy z modelem, może zobaczyć dane w innym układzie niż przewidziany w raporcie. Kluczowe jest więc rozróżnienie: kto widzi raport, kto może korzystać z modelu oraz kto ma uprawnienia administracyjne do przestrzeni — i niezakładanie, że jedna z tych warstw automatycznie ogranicza pozostałe.

Jak przeprowadzić audyt ról workspace i uprawnień do raportów, aplikacji i zestawów danych?

Audyt zacznij od workspace, bo to tam najczęściej nadawane są uprawnienia, które „dziedziczą się” na elementy (raporty, zestawy danych, dataflow). W każdym workspace sprawdź listę członków i ich role w ustawieniach workspace oraz zweryfikuj, czy dostęp jest nadany użytkownikom i grupom zgodnie z zasadą minimalnych uprawnień. Szczególną uwagę poświęć roli Admin i Member (często dają szerokie możliwości zarządzania i udostępniania) oraz sytuacjom, w których dodano użytkowników bezpośrednio zamiast przez grupy Entra ID, bo utrudnia to kontrolę i recertyfikację.

Następnie przejdź na poziom konkretnych artefaktów. Dla raportów i zestawów danych sprawdź uprawnienia udostępniania (bezpośrednie „Share”), uprawnienia na zestawie danych (np. Build, jeśli raporty mogą powstawać na bazie datasetu) oraz to, czy użytkownicy mają dostęp wynikający wyłącznie z roli workspace, czy także z dodatkowych nadań. Jeżeli workspace publikuje aplikację, zweryfikuj listę odbiorców aplikacji oraz ewentualne prawa do jej ponownego udostępniania; pamiętaj, że aplikacja jest osobnym kanałem dostępu i może przyznawać wgląd do zawartości osobom, które nie są członkami workspace.

Na końcu uczyń audyt kompletnym: zidentyfikuj wszystkie ścieżki dostępu do tych samych danych i usuń nadmiarowe nadania. W praktyce oznacza to porównanie trzech warstw: (1) roli użytkownika w workspace, (2) jego uprawnień do konkretnych raportów i zestawów danych oraz (3) dostępu przez aplikację. Wynik audytu powinien jednoznacznie odpowiadać na pytania: kto ma dostęp, do czego dokładnie, jaką drogą, i czy ten dostęp jest uzasadniony.

Jak sprawdzić, czy RLS i OLS naprawdę działają w każdej ścieżce dostępu do modelu?

Najpierw trzeba rozdzielić, co tak naprawdę weryfikujesz: RLS (Row-Level Security) ogranicza wiersze danych zwracane przez model dla danego użytkownika, a OLS (Object-Level Security) ukrywa lub blokuje obiekty modelu (tabele, kolumny, miary). Skuteczność zabezpieczeń zależy od tego, czy są egzekwowane przez silnik modelu w każdej formie odpytywania, dlatego testy muszą obejmować wszystkie ścieżki, przez które ktoś może wykonać zapytanie do zestawu danych/semantic model.

W praktyce sprawdzanie polega na wykonaniu tych samych prób dostępu z perspektywy konkretnego użytkownika (albo przez impersonację/test jako rola) i porównaniu wyników w różnych kanałach: w raporcie, w innych artefaktach korzystających z tego samego modelu oraz przez bezpośrednie zapytania do modelu. RLS uznajesz za działające, jeśli w każdym kanale użytkownik widzi wyłącznie dozwolone wiersze, a nie „pełne” agregaty ani wartości, które da się wydedukować z niedozwolonych wierszy. OLS uznajesz za działające, jeśli w każdym kanale nie da się ani zobaczyć metadanych niedozwolonych obiektów (np. kolumn w polach), ani odwołać się do nich w zapytaniu (np. poprzez miary lub funkcje, które pośrednio używają ukrytych kolumn).

Żeby upewnić się, że zabezpieczenia działają w każdej ścieżce dostępu, testuj co najmniej cztery typowe wektory: konsumowanie raportu (wizualizacje i interakcje), Analyze in Excel / podłączenie klienta do modelu (tabele przestawne i własne zapytania), aplikacje/artefakty wtórne korzystające z tego samego modelu (np. inne raporty, composite models) oraz bezpośrednie odpytywanie modelu przez narzędzia umożliwiające uruchamianie zapytań DAX/MDX. Jeśli w którymkolwiek kanale użytkownik jest w stanie zwrócić więcej wierszy niż powinien (RLS) albo odwołać się do ukrytych obiektów lub ich pochodnych (OLS), to znaczy, że zabezpieczenia nie są skutecznie egzekwowane w tej ścieżce lub istnieje obejście przez inny obiekt (najczęściej miarę) korzystający z niedozwolonych danych.

Kluczowe jest też sprawdzenie, czy nie mylisz „ukrycia w raporcie” z OLS. Samo ukrycie pól, stron czy wizualizacji nie jest zabezpieczeniem modelu; test ma wykazać, że nawet przy dostępie narzędziowym do modelu użytkownik nie jest w stanie wydobyć niedozwolonych danych ani przez pola, ani przez miary. Dopiero spójny wynik we wszystkich ścieżkach (raport, klienci analityczni, inne artefakty, bezpośrednie zapytania) pozwala uznać, że RLS i OLS rzeczywiście działają end-to-end.

Jak zweryfikować ryzyko przez uprawnienie Build oraz funkcję Analyze in Excel?

Uprawnienie Build na zbiorze danych (semantic model/dataset) oznacza, że użytkownik może tworzyć na nim własne artefakty analityczne: budować nowe raporty w Power BI, tworzyć miary oraz wykonywać zapytania do modelu. W praktyce jest to „prawo do odpytywania modelu”, więc ryzyko polega na tym, że użytkownik może uzyskać dostęp do danych dostępnych w modelu (w granicach obowiązujących zabezpieczeń), także poza oryginalnym raportem.

Funkcja Analyze in Excel jest prostym testem tego ryzyka, bo pozwala podłączyć Excel do modelu i przeglądać dane w tabelach przestawnych. Jeżeli użytkownik jest w stanie użyć Analyze in Excel, to zazwyczaj oznacza, że ma możliwość odpytywania modelu (czyli efektywnie korzysta z Build) i może eksplorować dane w sposób, którego nie kontroluje układ raportu.

• Sprawdź, kto ma Build na danym modelu: w ustawieniach zbioru danych w Power BI Service przejrzyj uprawnienia (użytkownicy/grupy/role w obszarze roboczym) i zidentyfikuj wszystkie nadania, które skutkują możliwością budowania na modelu.
• Wykonaj test „Analyze in Excel” kontem testowym (lub z użytkownikiem z danej grupy): jeśli opcja jest dostępna i połączenie działa, potwierdza to, że użytkownik może eksplorować model w Excelu.
• Zweryfikuj zakres widocznych danych w Excelu: sprawdź, jakie tabele/kolumny pojawiają się w polach tabeli przestawnej i czy da się zbudować widoki ujawniające dane, których nie powinno się dać odtworzyć z poziomu raportu (np. szczegółowe atrybuty lub granulacje).
• Oceń wpływ zabezpieczeń modelu: pamiętaj, że Analyze in Excel nie „omija” zabezpieczeń, ale pokaże, co realnie widzi dany użytkownik przy bezpośredniej eksploracji modelu (czyli co wynika z konfiguracji modelu i jego uprawnień, a nie z ograniczeń wizualizacji w raporcie).

Jeżeli użytkownik nie powinien mieć możliwości samodzielnego odpytywania modelu lub pracy w Excelu na danych, traktuj dostępność Analyze in Excel jako sygnał do ograniczenia Build (lub do przeprojektowania modelu tak, aby wrażliwe dane nie były w nim dostępne dla tej grupy odbiorców).

Jak wykryć obejścia przez composite models, live connection i modele semantyczne używane ponownie?

W Power BI do obejść uprawnień najczęściej dochodzi wtedy, gdy raport nie jest bezpośrednio „przywiązany” do jednego, kontrolowanego modelu, tylko dokłada do niego własne źródła danych albo korzysta z cudzych modeli semantycznych. Composite models (zwłaszcza DirectQuery for Power BI datasets/semantic models) pozwalają połączyć istniejący model semantyczny z dodatkowymi tabelami lub innymi źródłami. Live connection z kolei „dziedziczy” zabezpieczenia modelu, ale łatwo przeoczyć, że użytkownik raportu dostaje dostęp do modelu semantycznego (datasetu) w szerszym zakresie niż zakładano. Ponowne użycie modelu semantycznego (shared dataset) może powodować, że raport staje się kanałem dostępu do danych z modelu, którego właściciel i reguły udostępniania są inne niż w docelowej przestrzeni roboczej.

Wykrywanie sprowadza się do dwóch kontroli: (1) ustalenia, czy raport jest oparty o model semantyczny zewnętrzny względem oczekiwanej przestrzeni/źródła oraz (2) sprawdzenia, czy raport nie jest composite (czyli czy nie ma dołączonych dodatkowych tabel/źródeł obok modelu bazowego). Praktycznie oznacza to weryfikację w usłudze Power BI, do jakiego datasetu/semantic model raport jest podpięty i czy model jest „pudełkowy” (tylko import) czy dopuszcza rozszerzanie (composite). Jeżeli raport wskazuje na model z innej przestrzeni roboczej lub na model certyfikowany/udostępniony organizacyjnie, trzeba traktować to jako sygnał ryzyka ponownego użycia danych poza pierwotnym kontekstem uprawnień.

Dodatkowo obejścia często ujawniają się po stronie ustawień źródeł danych i poświadczeń: w composite model dane mogą być pobierane z innego źródła niż to, które zabezpieczono w modelu semantycznym, a w live connection kluczowe jest to, jakie uprawnienia użytkownik ma do samego modelu semantycznego (nie tylko do raportu). Jeżeli użytkownik ma prawo budowania (Build) lub zbyt szeroki dostęp do modelu, może wykorzystać go w innych raportach albo analizie, niezależnie od intencji właściciela konkretnego raportu.

Aby to wykryć bez wchodzenia w dygresje techniczne, skup się na 3 jednoznacznych wskaźnikach w metadanych raportu i modelu: czy raport używa połączenia na żywo do modelu semantycznego, czy jest w trybie composite (rozszerza model o własne tabele/źródła), oraz czy model semantyczny jest współdzielony i używany ponownie przez wiele raportów/obszarów. Każdy z tych przypadków powinien uruchomić kontrolę: kto jest właścicielem modelu, skąd pochodzą dodatkowe źródła (jeśli są) i czy zakres uprawnień do modelu semantycznego nie jest szerszy niż zakres udostępnienia raportu.

Jak ograniczyć eksport danych i „pobieranie szczegółów”, nie psując analizy użytkownikom?

W Power BI „eksport danych” (np. do Excel/CSV) i „pobieranie szczegółów” (drillthrough/drilldown lub „Pokaż dane” do poziomu rekordów) są wygodne dla analizy, ale jednocześnie tworzą najprostszy kanał masowego wynoszenia danych. Ograniczanie tych funkcji bez psucia raportu polega na rozdzieleniu dwóch potrzeb: użytkownik ma móc analizować agregaty i trendy, a tylko tam, gdzie jest to uzasadnione, mieć kontrolowany wgląd w szczegóły.

Najbezpieczniejszą i najmniej „bolesną” dla użytkowników metodą jest oparcie dostępu do szczegółów o uprawnienia do danych, a nie o samą blokadę interfejsu. Jeśli w modelu działa RLS (Row-Level Security) i użytkownik może zobaczyć tylko „swoje” wiersze, to nawet po eksporcie lub przejściu do szczegółów nie wyciągnie danych spoza swojego zakresu. Sama blokada eksportu bez RLS zwykle prowadzi do frustracji i obchodzenia ograniczeń (np. zrzuty ekranu, kopiowanie z tabel), a nie do realnego zmniejszenia ryzyka.

Drugim krokiem jest ograniczanie wyłącznie tych operacji, które są zbędne do codziennej analizy. W praktyce najczęściej wystarczy zostawić interaktywność wizualizacji i filtrowanie, a wyłączyć eksport „bazowych” danych oraz dostęp do widoków, które pokazują rekordy transakcyjne. Tę kontrolę realizuje się na poziomie ustawień raportu/zbioru danych (opcje eksportu i „Pokaż dane”) oraz poprzez świadomy projekt: zamiast tabel z danymi szczegółowymi udostępnia się miary i agregacje, a drillthrough prowadzi do stron podsumowań, nie do list rekordów.

Jeżeli użytkownicy realnie potrzebują szczegółów, zapewnij im je w sposób kontrolowany: udostępnij dedykowaną stronę drillthrough z ograniczonym zakresem kolumn (bez pól wrażliwych), używaj miar i formatowania zamiast surowych kolumn oraz trzymaj w modelu tylko te pola, które są potrzebne do raportowania. W Power BI nie ma „magicznej” opcji, która selektywnie pozwoli eksportować tylko część kolumn z tej samej wizualizacji; jeśli pewne pola nie powinny nigdy wypłynąć, najpewniejszym rozwiązaniem jest nie udostępniać ich w modelu raportowym lub ukryć je i nie wykorzystywać w wizualach przeznaczonych dla szerokiej publiczności.

Na koniec pamiętaj o kompromisie: blokady eksportu i ograniczanie „Pokaż dane” poprawiają sytuację, ale nie zastępują kontroli dostępu do danych. Dlatego optymalny układ to: RLS jako fundament (żeby eksport nie rozszerzał zakresu danych), a na wierzchu selektywne wyłączenia eksportu i projekt raportu nastawiony na analizę na agregatach, z kontrolowanym dojściem do szczegółów tylko tam, gdzie jest to biznesowo uzasadnione.

Jak monitorować i udokumentować dostęp oraz zmiany uprawnień, żeby audyt był powtarzalny?

Żeby audyt był powtarzalny, musisz mieć dwa typy dowodów: aktualny stan uprawnień (kto ma dostęp i na jakim poziomie) oraz historię zmian (kto, kiedy i co zmienił). Kluczowe jest, aby oba były zbierane w ten sam sposób, w stałych odstępach czasu i zapisywane w formie, którą da się porównać między audytami.

W praktyce oznacza to ustanowienie jednej, niezmiennej procedury: cyklicznie eksportujesz/snapshotujesz listy ról i członków oraz mapowanie dostępu do artefaktów (workspace, raport, dataset/semantic model), a równolegle archiwizujesz zdarzenia z dzienników audytowych dotyczące zmian uprawnień. Snapshot odpowiada na pytanie „jak jest teraz?”, a log audytu na „co się zmieniło od poprzedniego przeglądu?”.

• Snapshot uprawnień (stan na dzień X): zapisuj w jednym formacie (np. CSV/JSON) co najmniej: identyfikator artefaktu, typ artefaktu, nazwę workspace, poziom roli (Admin/Member/Contributor/Viewer), użytkownika/grupę, typ podmiotu (user/group/service principal) oraz źródło przypisania (bezpośrednio czy przez grupę) — jeśli to informacja dostępna w Twoim sposobie zbierania danych.
• Historia zmian (zdarzenia): archiwizuj zdarzenia związane z nadawaniem/odbieraniem ról w workspace, udostępnianiem, zmianami członkostwa oraz zmianami ustawień dostępu; dla każdego zdarzenia utrwal: czas, wykonawcę, obiekt, akcję, stan „przed/po” (jeśli dziennik to dostarcza) i identyfikatory pozwalające jednoznacznie połączyć zdarzenie z artefaktem.
• Niepodważalność i porównywalność: wersjonuj pliki (data/czas, zakres), przechowuj w nieedytowalnym repozytorium (WORM lub co najmniej kontrola wersji + ograniczenia zapisu) i zawsze audytuj te same zakresy (te same workspaces/środowiska) według tej samej definicji „krytycznych uprawnień”.
• Rekonsyliacja (spójność): w każdym cyklu uzgadniaj snapshot z logami: każda zmiana w logu powinna mieć odzwierciedlenie w następnym snapshocie, a różnice bez odpowiadających zdarzeń traktuj jako sygnał braków w logowaniu lub zmian poza zakresem zbierania.

Powtarzalność audytu zapewnia formalizacja trzech elementów: częstotliwości (np. tygodniowo/miesięcznie), zakresu (jakie workspaces i artefakty) oraz schematu danych (te same pola i identyfikatory w każdym przebiegu). Bez stałego schematu i identyfikatorów (ID workspace/artefaktu, UPN/ID użytkownika lub grupy) porównania między okresami będą niejednoznaczne i trudne do obrony podczas kontroli.

DirectQuery zwalnia po jednej miarze DAX: najszybszy sposób namierzenia winowajcy 05 lipca 2026

Copilot w Power BI: jak kontrolować definicje metryk, żeby AI nie „wymyślało” KPI w opisie i narracji 03 lipca 2026