Samouczek: Modelowanie ekskluzywnego dostępu za pomocą RBAC

Używaj kontroli dostępu opartej na rolach (RBAC), aby wymusić wyłączny dostęp do zbiorów danych, które muszą pozostać oddzielone od siebie. Gdy każdy zbiór danych jest dostępny tylko przez wyznaczoną rolę, użytkownicy i agenci AI muszą przyjąć tę rolę, aby uzyskać do niego dostęp. Aby uzyskać dostęp do innego zbioru danych, muszą zmienić rolę, więc pojedyncze zapytanie nie może łączyć danych między przypadkami użycia, projektami, badaniami klinicznymi czy klientami. Łączenie zbiorów danych, które muszą pozostać oddzielne, bywa nazywane toksycznym połączeniem.

Scenario

Badacz pracuje nad dwoma badaniami klinicznymi w jednym obszarze roboczym. Potrzebują dostępu do obu badań, ale ich praca nad jednym badaniem nie może wykorzystywać danych drugiego. Konfigurujesz osobną rolę dla każdego przypadku testowego, testujesz zapytania dozwolone i niedozwolone oraz ograniczasz udostępnianie zasobów przestrzeni roboczej utworzonych jako którąkolwiek z ról.

Badacz pozostaje przypisany do przestrzeni roboczej i może wejść do niej jako siebie. Aby wymagać przyjęcia roli w celu uzyskania dostępu do obszaru roboczego, zobacz Samouczek: Wymagaj od użytkowników przyjęcia roli w celu uzyskania dostępu do obszaru roboczego.

Przykład wykorzystuje dwa rodzaje grup. To etykiety objaśniające, a nie formalna terminologia usługi Azure Databricks:

• Rola dostępu: Pusta grupa, która posiada uprawnienia do danych z badania. Tworzysz role-study-1 i role-study-2. Pozostaw je puste. Członkowie dziedziczą uprawnienia grupy, dzięki czemu mogą czytać dane bez przyjmowania roli.
• Grupa członkowska: trial-researchers, której członkowie mogą pełnić obie role dostępu. Posiada uprawnienie Assume, a nie uprawnienia do danych wersji próbnej. Grupa członkowska jest opcjonalna. Możesz także przyznać uprawnienie Assume bezpośrednio poszczególnym użytkownikom lub jednostkom usługi.

Badacz może przełączać się między rolami, ale każda rola może czytać tylko tabelę własnego badania:

Na diagramie grupa Badania 1 odpowiada role-study-1, a grupa Badania 2 odpowiada role-study-2.

Prerequisites

• Przestrzeń robocza z włączonym Unity Catalog i włączonym RBAC. Zobacz Włączanie RBAC.
• Uprawnienia administratora konta lub przestrzeni roboczej do tworzenia ról, udzielania uprawnień Assume oraz zarządzania przydziałami przestrzeni roboczych. Zobacz Kto może zarządzać grupami?.
• Uprawnienia administratora przestrzeni roboczej do konfigurowania uprawnień, dostępu obliczeniowego oraz ograniczeń udostępniania.
• Istniejący katalog testowy z zarządzaną pamięcią masową, dostępny z przestrzeni roboczej. Administrator, który tworzy dane, musi być właścicielem katalogu. Ten samouczek używa trials z nowymi schematami study_1 i study_2. Używaj katalogu bez szerokich grantów, który dałby badaczowi lub dowolnej z tych ról dostęp do obu zbiorów danych. Zobacz Tworzenie katalogów.
• Hurtownia SQL z uprawnieniem Can use przyznanym właścicielowi katalogu, który tworzy testowe zbiory danych. Osoba, która udziela dostępu do magazynu, potrzebuje uprawnień administratora workspace lub uprawnienia „Can manage on the warehouse”.
• Grupa kont zawierająca badaczy, nazwana trial-researchers w tym przykładzie. Jeden z członków uczestniczy w walidacji, korzystając z własnego logowania. Ten badacz nie może być administratorem, właścicielem katalogu ani członkiem grupy z szerokim dostępem do danych.
• Folder obszaru roboczego dla notatnika testowego każdej roli. Administrator obszaru roboczego konfiguruje dostęp do tych folderów w kroku 3.
• W kroku 8 czytnik audytu skonfigurowany zgodnie z opisem w Verify audit attribution.

Zastępuj własne nazwy katalogów, grup i przestrzeni roboczych w całym tekście. Używaj fikcyjnych danych testowych oraz nowych schematów i ról, aby czyszczenie nie wpływało na inne obciążenia.

Krok 1: Stwórz zestawy danych testowych

Jeśli którykolwiek ze schematów już istnieje, wybierz nową nazwę schematu zamiast zastępować istniejące obiekty.

Jako właściciel katalogu otwórz edytor SQL, wybierz testową hurtownię i wykonaj:

CREATE SCHEMA trials.study_1;
CREATE SCHEMA trials.study_2;

CREATE TABLE trials.study_1.patient_info (
  participant_id STRING,
  outcome STRING
) USING DELTA;

CREATE TABLE trials.study_2.patient_info (
  participant_id STRING,
  outcome STRING
) USING DELTA;

INSERT INTO trials.study_1.patient_info VALUES ('study-1-a', 'improved');
INSERT INTO trials.study_2.patient_info VALUES ('study-2-a', 'unchanged');

Identyfikatory uczestników i wyniki są fikcyjne. Uruchom oba zapytania, aby zweryfikować, czy tabele istnieją i czy hurtownia może je odczytać:

SELECT * FROM trials.study_1.patient_info LIMIT 100;
SELECT * FROM trials.study_2.patient_info LIMIT 100;

Każde zapytanie zwraca pojedynczy wiersz swojego studium.

Krok 2: Stwórz role dostępu i przyznaj uprawnienie „sts:AssumeRole”

Procedura podstawowa wykorzystuje grupy lokalne domeny dla ról dostępu. Grupy lokalne na koncie są przydatne, gdy tworzenie grupy w Azure Databricks jest prostsze niż żądanie nowej grupy z Microsoft Entra ID. Grupa członków może być lokalna dla konta lub zsynchronizowana z Microsoft Entra ID, jak pokazano na tym diagramie:

Stwórz pierwszą pustą rolę za pomocą jednej z dwóch metod:

Konsola konta

1. Jako administrator konta zaloguj się do konsoli konta.
2. Na pasku bocznym kliknij pozycję Zarządzanie użytkownikami.
3. Na karcie Grupy kliknij pozycję Dodaj grupę.
4. Wprowadź wartość role-study-1. Nie dodawaj członków.
5. Kliknij przycisk Potwierdź.
6. Przypisz grupę do testowego workspace z dostępem do Workspace i dostępem SQL Databricks. Zobacz Przypisywanie grupy do obszaru roboczego.

Ustawienia administratora obszaru roboczego

1. Jako administrator przestrzeni roboczej zaloguj się do testowej przestrzeni roboczej.
2. Kliknij swoją nazwę użytkownika na górnym pasku i wybierz pozycję Ustawienia.
3. Kliknij kartę Tożsamość i dostęp .
4. Obok pozycji Grupy kliknij pozycję Zarządzaj.
5. Kliknij Dodaj grupę, a następnie Dodaj nowe.
6. Wprowadź role-study-1 i wybierz dostęp do przestrzeni roboczej oraz dostęp do Databricks SQL. Krok 3 wyjaśnia, dlaczego ten samouczek używa obu tych metod.
7. Kliknij przycisk Dodaj. Nie dodawaj członków.

To również przypisuje grupę do przestrzeni roboczej i przyznaje Ci uprawnienie Zarządzanie na niej.

Udziel badaczom zgody na Assume

Przed przydzieleniem uprawnień do danych roli udziel badaczom zgody na objęcie tej roli:

Konsola konta

1. Jako administrator konta otwórz Zarządzanie użytkownikami> w konsoli konta i wybierz role-study-1.
2. Kliknij Uprawnienia, a następnie Udziel dostępu.
3. Wybierz trial-researchers, wybierz Załóż i kliknij Zapisz.

Ustawienia administratora obszaru roboczego

1. Jako administrator przestrzeni roboczej z uprawnieniami do zarządzania rolą, otwórz Ustawienia>Tożsamość i dostęp w testowym obszarze roboczym.
2. Obok Grupy kliknij Zarządzaj, a następnie wybierz role-study-1.
3. Kliknij Uprawnienia, a następnie Udziel dostępu.
4. Wybierz trial-researchers, wybierz Załóż i kliknij Zapisz.

Powtórz kroki, aby utworzyć rolę i nadać uprawnienie Assume dla role-study-2. Obie role są puste. Zobacz Wybieranie lub tworzenie roli, aby uzyskać wskazówki dotyczące nazewnictwa i tworzenia grup na podstawie interfejsu API.

Krok 3: Konfiguruj przestrzeń roboczą i dostęp do obliczeń

Przydzieliłeś obie role do obszaru testowego w kroku 2. Jako administrator przestrzeni roboczej sprawdź, czy zarówno obie role, jak i trial-researchers mają oba uprawnienia dostępu, w tym grupy, które już zostały przypisane:

• Dostęp do obszaru roboczego: Zapewnia dostęp do podstawowych funkcji obszaru roboczego, takich jak notatniki, zadania, modele i potoki. Ten samouczek wykorzystuje notesy do weryfikacji kontroli udostępniania.
• Dostęp do bazy danych SQL usługi Databricks: udziela dostępu do funkcji SQL usługi Databricks, w tym pulpitów nawigacyjnych, zapytań i magazynów SQL. Ten samouczek wykorzystuje edytor SQL do weryfikacji dostępu do danych.

Wszystkie uprawnienia dostępu i sposoby ich zarządzania znajdziesz w artykule o uprawnieniach do dostępu.

Jeśli trial-researchers nie jest przypisany, przypisz go do przestrzeni roboczej. Zobacz Przypisywanie grupy do obszaru roboczego.

Zachowaj przypisanie badaczy, aby mogli działać jako swoje konta użytkowników i przełączyć się z powrotem po użyciu roli.

Udziel każdej grupie dostępu do hurtowni SQL:

1. W pasku bocznym przestrzeni roboczej kliknij SQL Warehouses.
2. Otwórz okno dialogowe Uprawnienia magazynu.
3. Dodaj każdą grupę z Can use, a potem zapisz.

Stwórz osobny folder testowy dla każdej roli w lokalizacji obszaru roboczego bez szerokich odziedziczonych uprawnień. Przyznaj role-study-1 uprawnienie „Może zarządzać” do swojego folderu, a role-study-2 uprawnienie „Może zarządzać” do drugiego folderu. Role wykorzystują te foldery do tworzenia notatników w kroku 7. Zobacz Zarządzaj obiektami przestrzeni roboczej i ACL folderów.

Krok 4: Przyznaj każdej roli dostęp do przypisanego badania

Jako właściciel katalogu, uruchom:

GRANT USE CATALOG ON CATALOG trials TO `role-study-1`;
GRANT USE SCHEMA ON SCHEMA trials.study_1 TO `role-study-1`;
GRANT SELECT ON TABLE trials.study_1.patient_info TO `role-study-1`;

GRANT USE CATALOG ON CATALOG trials TO `role-study-2`;
GRANT USE SCHEMA ON SCHEMA trials.study_2 TO `role-study-2`;
GRANT SELECT ON TABLE trials.study_2.patient_info TO `role-study-2`;

Nie przyznawaj uprawnień do danych próbnych dla trial-researchers. Jego członkowie otrzymują zamiast tego uprawnienie Assume.

Przejrzyj bezpośredni i dziedziczony dostęp przed testowaniem:

• Badacz nie może posiadać żadnego innego grantu ani członkostwa w grupie, które pozwalają na odczytanie którejkolwiek z tabel przy użyciu swojej tożsamości użytkownika.
• Żadna grupa nadrzędna nie przyznaje żadnej z ról dostępu do danych w innym badaniu.
• Sprawdź granty katalogowe i schematyczne, a także uprawnienia do tabel. Uprawnienie na poziomie katalogu lub schematu SELECT dotyczy obecnych i przyszłych obiektów potomnych i może uczynić obie tabele dostępnymi. Zobacz Dziedziczenie uprawnień.

Użyj zakładki Uprawnienia w Eksploratorze katalogu, aby sprawdzić przyznane uprawnienia dla katalogu, obu schematów i obu tabel. Zobacz Zarządzanie uprawnieniami w Unity Catalog. Jeśli granty współdzielone uniemożliwiają taką konfigurację, użyj izolowanego katalogu testów lub przestrzeni roboczej. Usunięcie współdzielonego uprawnienia może zakłócić niepowiązanych użytkowników i role.

Krok 5: Ogranicz udostępnianie zasobów obszaru roboczego należących do ról

Bez ograniczenia udostępniania użytkownik działający jako rola może udostępniać zasoby przestrzeni roboczej, które są własnością tej roli. Konfiguruj ograniczenia dla obu ról:

1. Jako administrator przestrzeni roboczej kliknij swoją nazwę użytkownika i wybierz Ustawienia.
2. Kliknij Zaawansowane.
3. Znajdź opcję Ogranicz udostępnianie dla grup i kliknij przycisk edycji.
4. Dodaj role-study-1 i role-study-2. Zachowaj grupy, które już są na liście.
5. Kliknij Zapisz.

To ograniczenie obowiązuje podczas pełnienia roli z ograniczeniami. Kontroluje współdzielenie zasobów przestrzeni roboczej należących do roli. Nie kontroluje uprawnień na obiektach Unity Catalog i nie blokuje wszystkich sposobów kopiowania danych. Zobacz Kontrolki udostępniania zasobów obszaru roboczego.

Krok 6: Zweryfikuj dostęp do danych jako każda tożsamość

Jeden z Twoich badaczy wykonuje te kontrole, korzystając ze swojego własnego logowania:

1. Zaloguj się do testowego obszaru roboczego i sprawdź, czy Twoja nazwa użytkownika pojawia się pod nazwą obszaru roboczego.

2. Otwórz edytor SQL i wybierz testową hurtownię.

3. Uruchom każde zapytanie osobno:

   SELECT * FROM trials.study_1.patient_info LIMIT 100;
   SELECT * FROM trials.study_2.patient_info LIMIT 100;
   

   Oba zapytania kończą się błędem uprawnień.

4. Kliknij nazwę workspace w górnym pasku, najedź kursorem na aktualną przestrzeń workspace i wybierz role-study-1 z przełącznika ról.

5. Po ponownym załadowaniu workspace weryfikuj nazwę roli, otwórz edytor SQL, wybierz ten sam magazyn i powtórz oba zapytania. Tylko zapytanie Study 1 kończy się powodzeniem.

6. Przełącz się na role-study-2 i powtarzaj zapytania. Tylko zapytanie Study 2 odnosi sukces.

7. Przełącz się z powrotem na swoje konto użytkownika i powtórz sprawdzenia. Oba zapytania zostały ponownie odrzucone.

Brakująca tabela, niedostępny magazyn lub błąd uwierzytelniania nie świadczą o wyłącznym dostępie. Sprawdzenia katalogu właściciela w kroku 1 potwierdzają, że obie tabele istnieją. Jeśli nieoczekiwane zapytanie się powiedzie, przejrzyj uprawnienia i przynależności z etapu 4 przed dalszym działaniem.

Aby uzyskać informacje o innych sposobach przejęcia roli, zobacz Przełączanie ról RBAC. Zmiana ról w tej przeglądarce nie zmienia osobno uwierzytelnionego profilu CLI Databricks ani połączenia.

Krok 7: Zweryfikuj udostępnianie zasobów przestrzeni roboczej

Ten sam badacz powtarza te sprawdzenia dla każdej roli:

1. Przyjmij tę rolę, korzystając z przełącznika roli.
2. W Workspace kliknij prawym przyciskiem myszy folder testowy roli i wybierz Utwórz>Notebook.
3. Nazwij notatnik zgodnie z nazwą badania. Nie musisz w nim uruchamiać kodu.
4. Sprawdź, czy rola jest właścicielem nowego notatnika, a potem spróbuj go udostępnić. Udostępnianie jest niedostępne, gdy działasz w roli ograniczonej, nawet mając opcję Zarządzać na assetie.

Używaj notatnika stworzonego podczas pełnienia roli, a nie notatnika należącego do badacza. Zobacz Utwórz notatnik i Zweryfikowaj ograniczenie.

Krok 8: Zweryfikowanie atrybucji audytu

Jako użytkownik z rolą Audit Reader uruchom to zapytanie. Zastąp <workspace-id> identyfikatorem przestrzeni roboczej testowej:

SELECT event_time, service_name, action_name,
       identity_metadata.run_by, identity_metadata.run_by_display_name,
       identity_metadata.run_as, identity_metadata.run_as_display_name
FROM system.access.audit
WHERE workspace_id = '<workspace-id>'
  AND identity_metadata.run_as_display_name IN ('role-study-1', 'role-study-2')
  AND event_date >= current_date() - INTERVAL 1 DAY
ORDER BY event_time DESC;

Znajdź wydarzenia dotyczące zapytań testowych badacza i tworzenia notatnika. identity_metadata.run_by Identyfikuje badacza, który inicjował każde zdarzenie, oraz run_as określa rolę użytą w autoryzacji. Zapytanie filtruje według run_as_display_name, czyli czytelnej dla człowieka nazwy roli. Dane audytowe są aktualizowane w ciągu dnia, więc ostatnie zdarzenie może nie pojawić się od razu. Zobacz odniesienie do metadanych tożsamości.

Opcjonalnie: Zarządzanie rolami dostępu w Microsoft Entra ID

Korzystaj z tej alternatywy, gdy Twoja organizacja prowadzi zarządzanie cyklem życia grup w Microsoft Entra ID. Synchronizuj pustą grupę ról dostępu oraz grupę członków z Azure Databricks poprzez System for Cross-domain Identity Management (SCIM) provisioning. Zobacz Synchronizuj użytkowników i grupy z Microsoft Entra ID za pomocą SCIM.

Zachowaj każdą rolę dostępu pustą w Microsoft Entra ID. Dodanie tam członków synchronizuje te członkostwa z Azure Databricks, gdzie członkowie dziedziczą uprawnienia danych bez przejmowania tej roli.

Zacznij od nowych grup Microsoft Entra ID

Aby używać nowych grup Microsoft Entra ID zamiast ról lokalnych dla konta w kroku 2, wykonaj następujące kroki:

1. W Microsoft Entra ID utwórz pustą grupę dla każdej roli dostępu.
2. Zidentyfikuj lub utwórz grupę członkowską zawierającą badaczy.
3. Zsynchronizuj role dostępu i grupę użytkowników z kontem Azure Databricks.
4. Udziel grupie członków uprawnienia Assume dla każdej roli dostępu, korzystając z procedury w kroku 2.

Zmień przeznaczenie istniejącej grupy Microsoft Entra ID

Jeśli grupa zsynchronizowana z Microsoft Entra ID już posiada pożądane uprawnienia do danych w Azure Databricks, możesz zachować te granty, przekształcając grupę w rolę dostępu:

1. Utwórz nową grupę członkowską w Microsoft Entra ID. Na przykład, jeśli istniejąca grupa to clinical-trial-1-ds, stwórz clinical-trial-1-ds-members.
2. Przenieś każdego członka istniejącej grupy do nowej grupy członkowskiej, pozostawiając istniejącą grupę pustą.
3. Zsynchronizuj obie grupy z Azure Databricks i sprawdź, czy rola dostępu nie zawiera członków.
4. Udziel nowej grupie członkowskiej uprawnienia Assume dla roli dostępu. Przejrzyj inne granty lub członkostwa, które nadal mogą dać naukowcom obowiązujący dostęp do danych.

Istniejąca grupa zachowuje swoje uprawnienia do danych i uprawnienia do obszaru roboczego. Nie musisz odtwarzać tych grantów, ale sprawdź, czy odpowiadają one zamierzonej granicy badania. Zmianę członkostwa należy zaplanować z właścicielami grupy, ponieważ użytkownicy tracą dziedziczone uprawnienia po opuszczeniu oryginalnej grupy.

Zakończ konfigurację i sprawdzenia przestrzeni roboczej

Przypisz zarówno role dostępu, jak i grupę członków do przestrzeni roboczej oraz konfiguruj uprawnienia i dostęp obliczeniowy zgodnie z krokiem 3. Aby wymagać przejęcia roli przy wejściu do przestrzeni roboczej, zobacz Samouczek: Wymagaj od użytkowników przejęcia roli dla dostępu do przestrzeni roboczej.

Dla nowych ról dostępu przyznaj dostęp do danych jak w kroku 4 oraz dostęp do zasobów obszaru roboczego jak w kroku 3. W przypadku grup o zmienionym przeznaczeniu przejrzyj istniejące granty zamiast ich zastępować.

Sprawdź, czy grupa posiada uprawnienia Assume dla każdej roli dostępu. Wszyscy jej członkowie mogą wtedy przejąć tę rolę.

Konfiguruj ograniczenia udostępniania i powtarzaj kontrole danych, udostępniania i audytu opisane w krokach 5–8, używając nazw grup i zestawów danych Microsoft Entra ID.

Czyszczenie

Dla testu tymczasowego usuń jedynie zasoby i granty stworzone na potrzeby tego tutorialu:

1. Jako właściciel katalogu sprawdź, czy dwie tabele zawierają tylko dane testowe z tutoriala, a następnie wykonaj:

   DROP TABLE trials.study_1.patient_info;
   DROP TABLE trials.study_2.patient_info;
   DROP SCHEMA trials.study_1 RESTRICT;
   DROP SCHEMA trials.study_2 RESTRICT;
   

   Usunięcie schematu kończy się niepowodzeniem, jeśli pozostaną inne obiekty. Nie usuwaj istniejącego katalogu ani schematu używanego przez inne obciążenia robocze.

2. Jako administrator przestrzeni roboczej usuń testowe notatniki i foldery. Przejrzyj wszelkie inne zasoby należące do ról przed usunięciem tych zasobów.

3. Cofnij nadania uprawnień Assume i uprawnień do zasobów utworzonych dla testu, w tym nadania uprawnień do katalogu i do hurtowni. Usuń przypisania wyłącznie testowe do przestrzeni roboczych, zachowując istniejący dostęp badaczy.

4. Usuń role testowe z Ogranicz udostępnianie dla grup, pozostawiając inne wpisy nienaruszone.

5. Usuwaj nowo utworzone puste role dopiero po zweryfikowaniu, że żadne obciążenie robocze ani asset ich nie używa. W przypadku zsynchronizowanych grup wprowadź zmiany cyklu życia w Microsoft Entra ID, aby synchronizacja nie odtwarzała usuniętych grup. Zachowaj istniejące grupy członkowskie i ich użytkowników.

Jeśli przekształciłeś istniejącą grupę, zaplanuj osobny rollback, który przywróci jej oryginalne członkostwa i przydziały. Nie używaj czyszczenia zasobów testowych do usunięcia istniejącego modelu dostępu.

Następne kroki