Implementacja dynamicznych zabezpieczeń na poziomie wiersza w Power BI i Microsoft Fabric: architektura, wzorce DAX i ład korporacyjny klasy enterprise

By Mirko Peters · 2025-11-21 · Updated 2025-11-26

Wdróż dynamiczne zabezpieczenia na poziomie wiersza w Power BI i Microsoft Fabric, aby kontrolować dostęp użytkowników do danych, zapewnić zgodność z przepisami i dostosować się do zmian w organizacji.

Automatically translated with AI from the original post. Read the English original

Dynamiczne zabezpieczenia na poziomie wiersza warto traktować jako system, który się zmienia. Rozwija się i ewoluuje razem z organizacją. O tym, jak działają zabezpieczenia w Power BI i Microsoft Fabric, decyduje projekt modelu danych, wyrażenia DAX, tożsamość użytkownika i ład. Jeśli skonfigurujesz je właściwie, możesz decydować, kto ma dostęp do określonych danych.

Najważniejsze wnioski

• Dynamiczne zabezpieczenia na poziomie wiersza dostosowują się do potrzeb firmy. Pozwalają wybrać, kto może zobaczyć określone dane. Działają, sprawdzając tożsamość każdego użytkownika.

• Do zabezpieczeń w chmurze używaj funkcji USERPRINCIPALNAME(). Ta funkcja pozwala użytkownikom widzieć wyłącznie własne dane. Pomaga chronić informacje.

• Regularnie sprawdzaj konfigurację zabezpieczeń i grupy użytkowników. Zapobiega to sytuacji, w której osoby widzą dane, których widzieć nie powinny. Pomaga to chronić dane.

• Twórz przejrzyste tabele zabezpieczeń do obsługi uprawnień użytkowników. Ułatwia to kontrolowanie, kto widzi co, w miarę rozwoju firmy.

• Testuj reguły zabezpieczeń w chmurze z udziałem prawdziwych użytkowników. Dzięki temu masz pewność, że dane są bezpieczne. Użytkownicy widzą wyłącznie to, do czego mają prawo.

Ponowne przemyślenie systemów zabezpieczeń na poziomie wiersza

Zabezpieczenia jako system oparty na modelu

Zabezpieczenia na poziomie wiersza to system łączący różne elementy platformy analitycznej. Projektując model danych, zaczynasz budować bezpieczeństwo danych. Sposób konfigurowania tabel, ich relacji i ról wpływa na to, jak użytkownicy widzą dane. Jeśli firma się rozrasta lub do pracy dołączają nowe zespoły, trzeba zaktualizować reguły zabezpieczeń. Zabezpieczeń na poziomie wiersza nie konfiguruje się raz na zawsze. Zmieniają się wraz z biznesem i odpowiadają na nowe potrzeby.

Wskazówka: Regularnie sprawdzaj model danych. Dobry model ułatwia zabezpieczenia i pomaga unikać błędów.

Twój model powinien mieć przejrzyste relacje oraz specjalne tabele zabezpieczeń. Dzięki temu łatwiej kontrolować, kto widzi określone dane, a prywatne informacje pozostają chronione. Dynamiczne zabezpieczenia na poziomie wiersza mogą dopasować to, co widzi użytkownik, do jego grupy lub stanowiska w usłudze Fabric. Dzięki temu uprawnienia można szybko zmieniać, gdy zmienia się firma.

Statyczne a dynamiczne zabezpieczenia na poziomie wiersza

Istnieją dwa główne sposoby konfigurowania zabezpieczeń danych: statyczne i dynamiczne zabezpieczenia na poziomie wiersza. Statyczne zabezpieczenia opierają się na stałych regułach. Dla każdej grupy tworzysz role i filtry. Sprawdza się to w małych zespołach lub wtedy, gdy dostęp rzadko się zmienia. Dynamiczne zabezpieczenia na poziomie wiersza wykorzystują informacje o zalogowanym użytkowniku oraz tabele mapowania. Sprawdzają użytkownika i od razu zmieniają widoczne dane. Jest to lepsze rozwiązanie dla dużych firm z wieloma użytkownikami i zmieniającymi się regułami.

Poniżej znajduje się tabela pokazująca różnice:

Dynamiczne zabezpieczenia na poziomie wiersza dają więcej możliwości kontrolowania dostępu. Wykorzystują funkcje takie jak USERPRINCIPALNAME() oraz tabele mapowania, aby przypisać użytkowników do właściwych danych. Zabezpieczenia statyczne są proste, ale słabo sprawdzają się, gdy firma rośnie lub często się zmienia.

• Statyczne zabezpieczenia na poziomie wiersza ograniczają dane za pomocą stałych reguł.

• Dynamiczne zabezpieczenia na poziomie wiersza zmieniają to, co widzi użytkownik, w zależności od tego, kim jest.

• Dynamiczne zabezpieczenia najlepiej sprawdzają się w dużych firmach z wieloma regułami.

Aby chronić dane, wybierz podejście najlepsze dla swoich potrzeb. Dobre planowanie i solidny model pomagają chronić prywatne dane i bezpieczeństwo analityki.

Wzorce dynamicznych zabezpieczeń na poziomie wiersza w Fabric

Funkcje DAX: USERPRINCIPALNAME() a USERNAME()

Ważne jest zrozumienie, jak działa tożsamość w usłudze Fabric. Do konfigurowania zabezpieczeń na poziomie wiersza służą dwie główne funkcje: USERPRINCIPALNAME() i USERNAME(). Obie sprawdzają, kto przegląda raport. USERPRINCIPALNAME() zwraca adres e-mail użytkownika z chmury. USERNAME() często zwraca nazwę konta lokalnego, głównie w programie Power BI Desktop. Jeśli użyjesz USERNAME() w chmurze, może to nie działać poprawnie, co obniża bezpieczeństwo danych.

Wskazówka: W dynamicznym zabezpieczeniu na poziomie wiersza w usłudze Fabric zawsze wybieraj funkcję USERPRINCIPALNAME(). Ta funkcja dopasowuje chmurowy adres e-mail użytkownika i chroni Twoje dane.

Jeśli użyjesz niewłaściwej funkcji, użytkownicy mogą zobaczyć dane, których nie powinni widzieć. Zabezpieczenia musisz testować w chmurze, a nie tylko w Desktop.

Bezpieczne wzorce DAX i antywzorce

Zależy Ci na tym, aby Twoje dane były bezpieczne. Potrzebujesz solidnych wzorców DAX do dynamicznego zabezpieczenia na poziomie wiersza. Najlepszym sposobem jest użycie tabel mapujących i dynamicznych reguł. Dzięki temu kontrolujesz, kto może zobaczyć jakie dane.

• Filtry wierszy pomagają ograniczyć to, co użytkownicy mogą zobaczyć. Możesz blokować dane według regionu, działu lub konta.

• Maski kolumn pozwalają ukrywać lub zmieniać dane w zależności od tego, kim jest użytkownik.

Dobry wzorzec DAX wykorzystuje wyszukiwanie, aby dopasować użytkowników do ich grupy. Sprawdza się to dobrze w firmach z wieloma grupami. Oto dobry przykład:

Organizations[Id] = LOOKUPVALUE(
    AspNetUsers[OrganizationId],
    AspNetUsers[Email],
    USERPRINCIPALNAME()
)

Ten wzorzec sprawdza adres e-mail użytkownika i odnajduje jego grupę. Dzięki temu możesz pokazywać wyłącznie właściwe dane. Ten sposób jest lepszy niż samo dopasowywanie adresów e-mail. Dobrze sprawdza się wraz z rozwojem firmy i chroni Twoje dane.

Uwaga: Nie wpisuj adresów e-mail na sztywno i nie używaj kolumn obliczeniowych do kontroli dostępu. Takie podejścia mogą przestać działać, gdy użytkownicy zmienią dane lub firma się rozrośnie.

Niektóre złe wzorce mogą prowadzić do wycieku danych:

• Używanie USERNAME() w chmurze.

• Wpisywanie na sztywno adresów e-mail użytkowników lub domen.

• Umieszczanie logiki zabezpieczeń w kolumnach obliczeniowych.

Zawsze używaj dynamicznych reguł i tabel mapujących. Dzięki temu model danych pozostaje prosty, a Twoje dane bezpieczne.

Hierarchie i funkcja PATH()

Czasem potrzebujesz zabezpieczeń dla menedżerów, zespołów lub działów. Hierarchie pomagają to zrobić. Funkcja PATH() w DAX pozwala budować powiązania nadrzędny–podrzędny. Możesz jej użyć, aby kontrolować, kto widzi jakie dane na każdym poziomie.

Na przykład możesz utworzyć tabelę z identyfikatorami pracowników i menedżerów. PATH() buduje łańcuch od każdego pracownika do jego przełożonego. Następnie używasz DAX, aby filtrować dane dla każdego poziomu.

PATH(Employee[EmployeeID], Employee[ManagerID])

Ta funkcja pomaga skonfigurować dynamiczne zabezpieczenie na poziomie wiersza w dużych firmach. Możesz pozwolić menedżerom widzieć dane swojego zespołu. Możesz też ograniczyć zwykłym pracownikom dostęp do zbyt dużej ilości danych.

Wskazówka: Używaj PATH() do zabezpieczeń opartych na hierarchiach. Dzięki temu model danych jest elastyczny, a Twoje dane bezpieczne.

Filtrów wierszy, masek kolumn i funkcji hierarchii możesz używać razem. Pomaga to chronić prywatne dane i kontrolować dostęp w miarę rozwoju firmy.

Architektura ról i relacji

Projektowanie tabel zabezpieczeń

Musisz utworzyć tabele zabezpieczeń dla dynamicznego zabezpieczenia na poziomie wiersza. Pokazują one, którzy użytkownicy mogą widzieć jakie dane. Użyj kolumn na adres e-mail użytkownika, grupę i poziom dostępu. Taka konfiguracja pomaga chronić dane wraz z rozwojem firmy.
Tworząc role, rozdzielaj role ścisłe i otwarte. Jeśli jedna rola pozwala komuś zobaczyć wszystko, inne role z zabezpieczeniem na poziomie wiersza mogą nie działać poprawnie. Musisz zapobiegać sytuacji, w której role się wzajemnie znoszą, aby chronić dane.

• Twórz tabele zabezpieczeń z czytelnymi kolumnami dla użytkownika i uprawnień.

• Trzymaj role osobno, aby się nie nakładały i nie powodowały problemów.

• Regularnie sprawdzaj tabele zabezpieczeń, aby nadążać za zmianami.

Relacje w modelu danych

Sposób budowy modelu danych wpływa na kontrolę dostępu. Stosuj jednokierunkowe relacje między tabelami. Dzięki temu model jest prosty, a błędom łatwiej zapobiec.
Lepiej korzystać ze specjalnych tabel zabezpieczeń niż umieszczać uprawnienia w tabelach faktów. Tabelę zabezpieczeń możesz połączyć z innymi tabelami, takimi jak dział czy region. Dzięki temu możesz filtrować dane dla każdego użytkownika lub grupy.

Wskazówka: Używaj tabel mostkowych, aby powiązać użytkowników z danymi. Pomaga to działać dynamicznemu zabezpieczeniu na poziomie wiersza i chroni Twoje dane.

Granularność ról: małe kontra duże role

Musisz zdecydować, jak szczegółowe mają być Twoje role. Małe role dają większą kontrolę. Dostęp możesz przydzielać według stanowiska lub grupy. Duże role obejmują więcej osób, ale mogą być ryzykowne, gdy coś się zmienia.
Regularnie sprawdzaj, kto ma każdą rolę. Dzięki temu dane są bezpieczne, a w razie potrzeby możesz wprowadzić zmiany.
Wybieraj małe role, aby mieć większą kontrolę i łatwiej aktualizować uprawnienia. Duże role mogą sprawdzić się w prostych grupach, ale w dużych firmach potrafią sprawiać problemy.

Przypisania użytkowników i grup w Fabric

Grupy Azure AD a pojedyncze osoby

Dostęp w usłudze Fabric przyznajesz, dodając użytkowników do grup Azure AD. Dzięki temu możesz kontrolować dane dla wielu osób naraz. Korzystanie z grup jest bezpieczniejsze niż dodawanie każdej osoby osobno. Grupy ułatwiają zarządzanie systemem i wymagają mniej pracy. Gdy zmienia się zespół, szybko zaktualizujesz grupy. Powiązanie grup z rolami upraszcza modelowanie danych. Reguły zabezpieczeń na poziomie wierszy pozostają przejrzyste i proste.

Wskazówka: Używaj grup Azure AD do kontroli dostępu. Pomaga to ograniczyć liczbę błędów i oszczędza czas.

Nakładające się grupy i ukryty dostęp

Uważaj na nakładające się grupy. Czasem użytkownik należy do więcej niż jednej grupy. Może to pozwolić mu zobaczyć dane, do których nie powinien mieć dostępu. Ukryty dostęp występuje wtedy, gdy ten błąd pozwala użytkownikom zobaczyć dodatkowe dane. Aby temu zapobiec, często sprawdzaj listy grup. Użyj tabel, aby śledzić, którzy użytkownicy należą do każdej grupy. Dobre modelowanie danych pomaga wcześnie wykrywać problemy. Usuwaj użytkowników z grup, których już nie potrzebują, aby chronić dane.

Uwaga: Ukryty dostęp może ujawnić prywatne dane. Usuń nakładanie się grup, aby system był bezpieczny.

Zaplanowane przeglądy dostępu

Zaplanuj regularne przeglądy dostępu. Co pewien czas sprawdzaj, kto należy do każdej grupy. Poproś właścicieli grup o wskazanie, kto powinien mieć dostęp. Dzięki temu dynamiczne zabezpieczenia na poziomie wierszy działają poprawnie wraz z rozwojem firmy. Do tych kontroli wykorzystaj narzędzia usługi Fabric. Usuwaj nieaktualnych użytkowników, aby zwiększyć bezpieczeństwo danych. Dzięki temu system analityczny pozostaje uporządkowany i bezpieczny. Uczyń przeglądy dostępu stałym elementem pracy z analityką biznesową.

• Wyznacz terminy przeglądu wszystkich grup.

• Użyj narzędzi usługi Fabric, aby sprawdzić grupy.

• Poproś właścicieli o potwierdzenie, kto należy do każdej grupy.

Alert: Regularne przeglądy pomagają wykryć błędy, zanim wywołają problemy.

Rozpoznawanie tożsamości: Desktop a Fabric

Funkcje tożsamości a różnice w chmurze

Ważne jest, aby wiedzieć, jak działa tożsamość w usłudze Power BI Desktop i Microsoft Fabric. W usłudze Power BI Desktop funkcja USERNAME() zwykle zwraca nazwę Twojego komputera. W usłudze Microsoft Fabric funkcja USERPRINCIPALNAME() zwraca Twój adres e-mail z chmury. Ta różnica ma duże znaczenie dla bezpieczeństwa danych. Jeśli użyjesz USERNAME() w chmurze, dane mogą zobaczyć niewłaściwe osoby. W raportach w chmurze zawsze używaj USERPRINCIPALNAME(). Pomaga to chronić dane i jest zgodne z systemem tożsamości Twojej firmy.

Wskazówka: Testuj reguły zabezpieczeń na poziomie wierszy w chmurze. Testy na komputerze stacjonarnym nie pokazują rzeczywistego dostępu użytkowników.

Właściciel zestawu danych i ustawienia dzierżawy

Musisz wiedzieć, kto jest właścicielem Twojego zestawu danych. Właściciel może zmieniać ustawienia odświeżania i wpływać na to, kto widzi dane. Zmiana właściciela może oznaczać zmianę tego, kto ma dostęp do prywatnych danych. Ważne są także ustawienia dzierżawy. To one określają, jak działa tożsamość w Twojej firmie. Sprawdź ustawienia dzierżawy przed publikacją raportów. Upewnij się, że model danych jest zgodny z zasadami bezpieczeństwa Twojej firmy.

Typowe przyczyny wycieków RLS

Możesz utracić kontrolę nad zabezpieczeniami na poziomie wierszy, jeśli nie testujesz w chmurze. Czasem użytkownicy widzą więcej danych, niż powinni. Może się tak zdarzyć, jeśli użyjesz niewłaściwej funkcji tożsamości lub zapomnisz zaktualizować członkostwo w grupach. Wycieki mogą wystąpić także wtedy, gdy zmienisz model danych bez sprawdzenia tabel zabezpieczeń. Zawsze przeglądaj konfigurację zabezpieczeń danych po wprowadzeniu zmian. Stosuj testy w chmurze i regularne audyty, aby wcześnie wykrywać problemy.

Alert: Wycieki danych mogą ujawnić prywatne informacje. Regularnie przeglądaj konfigurację, aby chronić swoją organizację.

Testowanie, audyt i zarządzanie

Testowanie RLS w chmurze

Musisz przetestować zabezpieczenia na poziomie wiersza w chmurze. Dzięki temu masz pewność, że dane są bezpieczne dla prawdziwych użytkowników. Narzędzie „View As” w Desktop pokazuje tylko podgląd. Nie pokazuje, jak zasady działają w Microsoft Fabric. Po opublikowaniu raportu przetestuj go z prawdziwymi użytkownikami i grupami. Pozwoli to zobaczyć, jakie dane może przeglądać każda osoba. Użyj kont testowych, aby sprawdzić, czy użytkownicy widzą tylko swoje dane. Zawsze testuj ponownie po zmianie ról lub aktualizacji modelu. Testy w chmurze pomagają wykryć problemy, zanim zaszkodzą firmie.

Wskazówka: Zawsze testuj z prawdziwymi użytkownikami w chmurze, a nie tylko w Desktop. Dzięki temu bezpieczeństwo danych pozostaje na wysokim poziomie.

Automatyzacja audytów i przeglądów

Możesz użyć automatyzacji, aby ułatwić audyty i przeglądy w Fabric. Automatyzacja regularnie sprawdza uprawnienia w obszarach roboczych, przepływy danych i etykiety poufności. Microsoft Purview udostępnia pulpity, na których śledzisz zasady na całej platformie. Możesz korzystać z dzienników aktywności i interfejsów API administracji, aby wykrywać problemy ze zgodnością. Automatyzacja pomaga wcześnie wykrywać problemy i oszczędza czas. Audytorzy mogą zobaczyć pełną ścieżkę wrażliwych kolumn od źródła aż po raport. Dzięki temu przeglądy są szybsze i dokładniejsze. Automatyzacja ułatwia też i obniża koszty przestrzegania przepisów, takich jak RODO i HIPAA.

• Skonfiguruj automatyczne kontrole uprawnień i przepływów danych.

• Używaj pulpitów do monitorowania zmian w zasadach bezpieczeństwa.

• Sprawdzaj dzienniki aktywności, aby szybko znajdować problemy.

Dokumentacja i zarządzanie zmianami

Aby system bezpieczeństwa danych był przejrzysty, potrzebna jest dobra dokumentacja. Zapisuj zasady bezpieczeństwa, listy grup i zmiany ról. Aktualizuj notatki przy każdej zmianie modelu lub dodaniu nowych użytkowników. Przejrzyste zapisy pomagają śledzić, kto ma dostęp do jakich danych. Ułatwiają też nowym członkom zespołu poznanie systemu. Zarządzanie zmianami oznacza, że aktualizacje są sprawdzane i zatwierdzane, zanim trafią na produkcję. Dzięki temu zabezpieczenia na poziomie wiersza pozostają bezpieczne w miarę rozwoju firmy.

Alert: Dbaj o aktualność dokumentacji. Chroni to dane i pozwala szybko usuwać problemy.

Zabezpieczenia na poziomie wiersza warto traktować jako element, który zmienia się wraz z rozwojem danych i firmy. Dobrze zaprojektowane zabezpieczenia pomagają chronić prywatne informacje. Stosowanie sprawdzonych wzorców DAX oraz dobre zarządzanie tożsamością użytkowników chroni dane. Regularne sprawdzanie zabezpieczeń i dokumentowanie zmian pozwala wcześnie wykrywać problemy. Jeśli zaplanujesz to z wyprzedzeniem, będziesz mieć kontrolę nad tym, kto widzi dane, i zabezpieczysz swoją analitykę.

• Regularnie sprawdzaj konfigurację zabezpieczeń.

• Zmieniaj zasady, aby lepiej chronić dane.

• Zawsze stawiaj prywatność na pierwszym miejscu.

Często zadawane pytania

Czym jest dynamiczne zabezpieczenie na poziomie wiersza w Power BI i Fabric?

Dynamiczne zabezpieczenie na poziomie wiersza pozwala kontrolować dostęp do danych w zależności od tego, kto przegląda raport. Używasz funkcji DAX i tabel mapowania, aby przypisać użytkownikom odpowiednie dane.

Dlaczego warto używać USERPRINCIPALNAME() zamiast USERNAME()?

USERPRINCIPALNAME() zwraca adres e-mail użytkownika w chmurze. Sprawdza się to najlepiej w Power BI i Fabric. USERNAME() może zwrócić lokalną nazwę, co w chmurze może prowadzić do problemów z bezpieczeństwem.

Jak grupy Azure AD pomagają w zabezpieczeniach?

Grupy Azure AD pozwalają zarządzać dostępem wielu użytkowników naraz. Dodajesz użytkowników do grup i przypisujesz im role. Dzięki temu konfiguracja zabezpieczeń jest prostsza i bezpieczniejsza.

Czym jest tabela zabezpieczeń i po co jest potrzebna?

Tabela zabezpieczeń zawiera listę użytkowników, grup i uprawnień. Służy do kontrolowania, kto ma dostęp do określonych danych. Pomaga to chronić dane w miarę rozwoju firmy.

Jak często należy testować zabezpieczenia na poziomie wiersza w chmurze?

Zabezpieczenia na poziomie wiersza należy testować za każdym razem, gdy zmieniasz role, grupy lub model danych. Testy w chmurze pokazują, co widzą prawdziwi użytkownicy, i pomagają wcześnie wykrywać problemy.