Bezpieczeństwo danych w Microsoft Fabric. Od dostępu do workspace po Row Level Security

Microsoft Fabric zabezpiecza dane wielowarstwowo: od uprawnień do obszaru roboczego, przez dostęp do pojedynczych obiektów i stron raportów, aż po Row Level Security, czyli kontrolę widoczności danych na poziomie pojedynczych wierszy. Do tego dochodzi centralny governance z Microsoft Purview. Na naszym webinarze o hurtowni danych 2.0 pytania o bezpieczeństwo padły jako jedne z pierwszych i trudno się dziwić: dane sprzedażowe, budżety i marże to jedne z najbardziej wrażliwych informacji w firmie. Ten artykuł porządkuje, jakimi mechanizmami Fabric je chroni.

‍

Obawa, od której wszystko się zaczyna

Podczas webinaru padło sformułowanie, które dobrze oddaje punkt widzenia biznesu: te informacje są wrażliwe i nie chciałbym, żeby wszyscy mieli do nich dostęp; chcę sam decydować, kto je ogląda.

To zdrowy odruch, a jednocześnie realne ryzyko projektów analitycznych: hurtownia, która konsoliduje dane z całej organizacji w jednym miejscu, tworzy też jedno miejsce, w którym potencjalnie wszystko widać. Dlatego architekturę bezpieczeństwa projektuje się razem z hurtownią, a nie po niej. Dobra wiadomość jest taka, że Fabric daje do tego mechanizmy o dużej granularności: od szerokich uprawnień po pojedyncze wiersze danych.

‍

Warstwy zabezpieczeń w Microsoft Fabric

Uprawnienia w Fabric układają się w warstwy, od najszerszej do najdrobniejszej.

Dostęp do obszaru roboczego. Workspace to podstawowa jednostka organizacji pracy: mieszczą się w nim Lakehouse, transformacje, modele semantyczne i raporty. Role w obszarze roboczym określają, kto może w nim tworzyć i edytować obiekty, a kto tylko przeglądać zawartość. To pierwsza linia podziału: środowisko zespołu danych może być całkowicie niewidoczne dla reszty organizacji.

Dostęp do pojedynczych obiektów. Wewnątrz obszaru roboczego uprawnienia nadaje się osobno na poziomie obiektów: kto może korzystać z Lakehouse, kto z modelu semantycznego, kto z konkretnego raportu. W praktyce to ważne rozróżnienie: użytkownik biznesowy może dostać dostęp do raportu bez jakiegokolwiek wglądu w hurtownię, z której raport korzysta.

Dostęp do stron raportu. Poziom jeszcze niżej: w ramach jednego raportu można kontrolować dostęp do poszczególnych stron. Raport zarządczy może mieć strony widoczne dla całej kadry kierowniczej i strony zarezerwowane dla zarządu.

Row Level Security. Najdrobniejsza warstwa, której poświęcamy osobną sekcję poniżej: kontrola na poziomie pojedynczych wierszy danych.

‍

‍

Row Level Security: użytkownik widzi tylko swoje dane

Row Level Security to mechanizm, który rozstrzyga większość praktycznych dylematów bezpieczeństwa w analityce. Zamiast budować osobne raporty dla każdego odbiorcy, buduje się jeden raport, a RLS dba o to, żeby każdy zobaczył w nim wyłącznie swoje dane.

Scenariusz z webinaru: kierownik regionalny otwiera raport sprzedaży i widzi swój region oraz swój budżet. Regionów innych kierowników nie zobaczy, choć fizycznie siedzą w tych samych tabelach. Ten sam raport otwarty przez dyrektora sprzedaży pokaże całość.

Technicznie RLS opiera się na rolach zdefiniowanych w modelu semantycznym: rola zawiera regułę filtrującą, na przykład dopasowanie regionu do tożsamości zalogowanego użytkownika, a przypisanie użytkowników do ról odbywa się w usłudze. Reguły działają na poziomie modelu, więc obejmują wszystko, co z modelu korzysta: raporty, tabele przestawne, zapytania.

RLS a subskrypcje raportów. Mechanizm współgra z automatyczną dystrybucją: raporty można subskrybować w formie przefiltrowanej dla konkretnych osób, tak aby każda cyklicznie otrzymywała swój wycinek danych, na przykład swój region albo swoją grupę klientów. Jedna definicja raportu, wiele spersonalizowanych i bezpiecznych widoków.

‍

Bezpieczeństwo plików generowanych z Fabric

Osobne, często pomijane pytanie: co z bezpieczeństwem, gdy dane opuszczają platformę? Padło ono również na naszym webinarze, w kontekście funkcji Analyze in Excel.

Plik Excel wygenerowany przez Analyze in Excel zapisuje się w usłudze SharePoint, a więc obowiązują go klasyczne uprawnienia SharePoint: dostępem do pliku zarządza się dokładnie tak, jak dostępem do każdego innego dokumentu w organizacji. To jednak druga linia obrony. Pierwszą są uprawnienia do samej warstwy semantycznej: zanim ktokolwiek wygeneruje taki plik, musi mieć prawo korzystania z modelu, a dane, które w pliku zobaczy, i tak podlegają regułom RLS.

Warto tę zasadę zapamiętać w ogólnej formie: w dobrze zaprojektowanym środowisku Fabric bezpieczeństwo egzekwowane jest przy źródle, na poziomie modelu i danych, a nie dopiero na poziomie plików wynikowych.

‍

Governance na poziomie organizacji

Pojedyncze uprawnienia to za mało, gdy środowisko rośnie: potrzebny jest ład, czyli governance. W klasycznej architekturze, złożonej z wielu narzędzi, polityki bezpieczeństwa trzeba było utrzymywać osobno w każdym z nich, a spójność całości była w praktyce nieosiągalna.

W Fabric administracja jest jedna dla całej platformy, a centralne zarządzanie politykami wspiera Microsoft Purview: klasyfikacja i etykietowanie danych wrażliwych, śledzenie ich przepływu przez transformacje i raporty oraz audyt tego, kto z czego korzysta. Dla organizacji podlegających wymogom regulacyjnym to często argument nie mniej ważny niż same funkcje analityczne: jeden spójny model nadzoru zamiast mozaiki polityk w kilku systemach.

‍

Dobre praktyki wdrożeniowe

Z naszych projektów wynika kilka zasad, które warto przyjąć od pierwszego dnia.

Zasada najmniejszych uprawnień. Domyślnie nikt nie ma dostępu; uprawnienia nadaje się świadomie, tam gdzie są potrzebne, i na najniższym skutecznym poziomie. Łatwiej rozszerzać dostęp niż go odbierać.

Bezpieczeństwo projektowane razem z modelem. Reguły RLS i struktura ról powinny powstawać podczas budowy modelu semantycznego, nie po niej. Atrybuty potrzebne do filtrowania, na przykład przypisanie regionów do użytkowników, muszą być przewidziane w danych.

Testowanie ról przed publikacją. Fabric pozwala podejrzeć raport z perspektywy wybranej roli. Ten test powinien być obowiązkowym punktem odbioru każdego raportu z RLS: sprawdzenie, że kierownik regionu naprawdę widzi tylko swój region, zajmuje chwilę, a chroni przed najbardziej kosztownym typem incydentu, czyli cichym wyciekiem danych wewnątrz organizacji.

Przegląd uprawnień jako proces. Ludzie zmieniają role i odchodzą, struktury się reorganizują. Cykliczny przegląd dostępów powinien być stałym elementem utrzymania środowiska.

Projekt architektury bezpieczeństwa to jeden z tych obszarów, w których doświadczenie wdrożeniowe procentuje najbardziej: granularność mechanizmów Fabric jest duża, a sztuką jest ułożenie ich w spójny, utrzymywalny system. Zespół Power Center w ANEGIS prowadzi audyty bezpieczeństwa środowisk danych oraz projektuje struktury uprawnień i RLS przy wdrożeniach hurtowni. Jeśli chcecie sprawdzić, czy Wasze dane widzą wyłącznie właściwe osoby, zapraszamy do kontaktu.

‍