Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Zmigruj kontrolę uprawnień obszaru roboczego tak, aby podczas dodawania każdego podmiotu głównego wybierać jego uprawnienia, zamiast automatycznie dziedziczyć uprawnienia z grupy systemowej users. Zapewnia to precyzyjną kontrolę nad dostępem do obszaru roboczego i umożliwia dodawanie użytkowników będących wyłącznie odbiorcami bez przyznawania uprawnień do edycji i tworzenia. Stanie się to zachowaniem domyślnym dla wszystkich obszarów roboczych. Możesz dokonać migracji wcześniej, aby przetestować ją według własnego harmonogramu.
Migracja zmienia sposób działania grup systemowych users i admins oraz przenosi istniejące uprawnienia do nowej grupy, dzięki czemu jednostki zabezpieczeń zachowają dotychczasowy dostęp. Ta strona obejmuje nowe zachowanie, kroki migracji i wymagane akcje przed migracją.
Overview
Każdy obszar roboczy ma dwie grupy systemowe: users, w tym wszystkie podmioty zabezpieczeń, którym udzielono dostępu do obszaru roboczego, i admins, w tym administratorzy obszaru roboczego. Dziś każdy podmiot dodany do obszaru roboczego dziedziczy uprawnienia przyznane elementowi users. Domyślnie te uprawnienia są następujące:
- Dostęp do obszaru roboczego: twórz i używaj notatników, zadań, potoków, aplikacji i nie tylko.
- Dostęp do Databricks SQL: Tworzenie i korzystanie z pulpitów nawigacyjnych, Agentów Genie, alertów i nie tylko.
Po zmianie:
Uprawnienia każdego podmiotu wybierasz podczas jego dodawania. Można dodawać podmioty na dowolnym poziomie dostępu, w tym użytkowników będących wyłącznie odbiorcami, bez automatycznego dziedziczenia przez nich uprawnień do tworzenia zawartości.
Grupa
usersnie ma uprawnień, aadminsgrupa ma wszystkie uprawnienia obszaru roboczego. Żadna z nich nie może zostać zmieniona.Nie można zagnieżdżać grup
usersiadminsw innych grupach.
Istniejące konta zachowują obecny poziom dostępu. Azure Databricks automatycznie przenosi uprawnienia uprzednio przyznane grupie users do nowej lokalnej dla obszaru roboczego grupy klonowanej o domyślnej nazwie users-clone-<TIMESTAMP>, gdzie <TIMESTAMP> oznacza czas migracji. Możesz zmienić nazwę grupy podczas migracji i zarządzać nią tak jak każda inna grupa lokalna obszaru roboczego. Grupa admins nie wymaga migracji, ponieważ automatycznie otrzymuje wszystkie uprawnienia obszaru roboczego.
Osi czasu
Stanie się to zachowaniem domyślnym dla wszystkich obszarów roboczych. Zmiana odbywa się w trzech fazach:
- 15 czerwca 2026 r. — dostępna opcja wyrażenia zgody. Migrowanie obszaru roboczego na wczesnym etapie w celu przetestowania nowego zachowania.
- 27 lipca 2026 r. — Automatycznie włączone w obszarach roboczych, w których nie wybrano ani włączenia, ani rezygnacji. Nadal możesz tymczasowo zrezygnować do momentu rozpoczęcia wymuszania.
- 14 września 2026 r. — obowiązuje we wszystkich obszarach roboczych. Rezygnacja z uczestnictwa nie jest już dostępna.
Aby uzyskać więcej informacji, zobacz Nadchodzące zmiany zachowania: wybieranie uprawnień podczas dodawania podmiotów zabezpieczeń do obszarów roboczych.
Przed rozpoczęciem
Aby przeprowadzić migrację obszaru roboczego i zarządzać nowym zachowaniem, musisz być administratorem obszaru roboczego.
Note
Ta zmiana nie dotyczy obszarów roboczych Azure Government. Te obszary robocze nie są migrowane.
Przed włączeniem nowego zachowania w obszarze roboczym wykonaj następujące czynności:
- Automatyzacja: jeśli zarządzasz uprawnieniami grupy systemu za pomocą interfejsów API programu Terraform, interfejsów API SCIM obszaru roboczego lub skryptów niestandardowych, zaktualizuj przepływy pracy do grup kont docelowych, a nie grup systemowych. Po Azure Databricks włączeniu nowego zachowania próby zmodyfikowania uprawnień grupy systemu kończą się niepowodzeniem.
-
Zagnieżdżone grupy systemowe: jeśli
userslubadminsjest zagnieżdżone jako element innej grupy, usuń to zagnieżdżenie. Nowe zachowanie nie zezwala na zagnieżdżanie. -
Synchronizacja SCIM: Jeśli synchronizacja SCIM usuwa grupy obszaru roboczego, których nie rozpoznaje, zaktualizuj jego konfigurację, aby zachować grupę klonowaną na potrzeby migracji (
users-clone-<TIMESTAMP>). Jeśli synchronizacja usunie grupę klonowania, podmioty zmigrowane do niej utracą uprawnienia.
Migrowanie obszaru roboczego
Nowym zachowaniem zarządzasz za pomocą ustawienia Nowe zachowanie: wybieraj uprawnienia podczas dodawania podmiotów zabezpieczeń do obszarów roboczych w ustawieniach obszaru roboczego.
Aby przenieść obszar roboczy do nowego sposobu działania:
Jako administrator obszaru roboczego zaloguj się do obszaru roboczego Azure Databricks.
Kliknij swoją nazwę użytkownika na górnym pasku i wybierz pozycję Ustawienia.
Kliknij kartę Zaawansowane.
W obszarze Kontrola dostępu znajdź pozycję Nowe zachowanie: wybierz uprawnienia podczas dodawania podmiotów zabezpieczeń do obszarów roboczych. Status wskazuje starsze zachowanie (może być wymagane podjęcie działania).
Kliknij przycisk Zarządzaj.
W oknie dialogowym sprawdź bieżące przyznane uprawnienia dla grup
usersiadmins. W obszarze Zachowanie dla tego obszaru roboczego wybierz pozycję Użyj nowego zachowania.W polu Nazwa klonowanej grupy wprowadź nazwę grupy, która otrzymuje uprawnienia przyznane elementowi
users, lub pozostaw wartość domyślną. Ta grupa zachowuje uprawnienia istniejących podmiotów.
Kliknij Zapisz.
Azure Databricks przenosi uprawnienia z
usersdo grupy klonowanej. Użytkownicy i grupy przypisani bezpośrednio do obszaru roboczego są dodawani do grupy klonu, aby zachowali dostęp. Do tych tożsamości należą bezpośrednio dodani użytkownicy i nazwy główne usług, a także wszystkie grupy kont przypisane do obszaru roboczego.
Po zakończeniu migracji ustawienie pokazuje, że obszar roboczy znajduje się w nowym zachowaniu.
Weryfikowanie zmian
Po zakończeniu migracji sprawdź, czy zmiany zostały zastosowane poprawnie:
- Jako administrator obszaru roboczego zaloguj się do obszaru roboczego Azure Databricks.
- Kliknij swoją nazwę użytkownika na górnym pasku i wybierz pozycję Ustawienia.
- Kliknij kartę Tożsamość i dostęp .
- Obok pozycji Grupy kliknij pozycję Zarządzaj.
- Sprawdź następujące kwestie:
- Sklonowana grupa istnieje i ma uprawnienia, które grupa
usersmiała przed migracją. - Grupa klonów zawiera podmioty, które zostały bezpośrednio dodane do obszaru roboczego za pomocą
users, w tym bezpośrednio dodanych użytkowników, podmioty usług oraz wszelkie grupy kont przypisane do obszaru roboczego. - Grupa
usersnie ma uprawnień, aadminsgrupa ma wszystkie uprawnienia obszaru roboczego.
- Sklonowana grupa istnieje i ma uprawnienia, które grupa
Note
Grupa klonów zawiera tylko bezpośrednich członków, więc może wyświetlać mniej członków niż grupa users, która obejmuje wszystkie osoby dodane poprzez członkostwo w grupach kont. Nie oznacza to utraty dostępu przez nikogo. Podmioty, które dołączyły do obszaru roboczego za pośrednictwem grupy kont, nadal są uwzględnione, ponieważ ta grupa kont jest dodawana do grupy klonowanej. Grupy lokalne obszaru roboczego nie są kopiowane, ponieważ nie udzielają członkostwa w obszarze roboczym.
Zagadnienia i najlepsze rozwiązania
Podczas migracji obszaru roboczego należy wziąć pod uwagę następujące kwestie:
- Dodawanie podmiotów zabezpieczeń po migracji: Po włączeniu nowego sposobu działania należy wybrać uprawnienia każdego podmiotu zabezpieczeń podczas dodawania go do obszaru roboczego. Aby przyznać uprawnienia do tworzenia zawartości, wybierz Dostęp do obszaru roboczego lub Dostęp do usługi Databricks SQL. Aby dodać odbiorcę z dostępem tylko do odczytu, nadaj tylko dostęp konsumenta. Aby uzyskać więcej informacji, zobacz Co to jest dostęp konsumentów? i Use Genie One (Korzystanie z usługi Genie One).
-
Zarządzanie grupą klonów: Grupa
users-clone-<TIMESTAMP>jest standardową grupą lokalną dla obszaru roboczego. Zarządzaj członkostwem i uprawnieniami, takimi jak każda inna grupa. Zobacz Zarządzanie grupami. -
Rezygnacja: Jeśli zrezygnujesz po migracji, grupa
users-clone-<TIMESTAMP>pozostanie. Możesz zachować i zarządzać nim lub usunąć je ręcznie. - Koordynacja z dostawcami tożsamości: jeśli używasz aprowizacji SCIM do synchronizowania użytkowników i grup, należy koordynować tę zmianę z procesami zarządzania tożsamościami, aby grupa klonowania została zachowana. Zobacz Synchronizuj użytkowników i grupy z Microsoft Entra ID za pomocą SCIM.
Co dalej
Po przeprowadzeniu migracji obszaru roboczego warto wykonać następujące zadania:
- Zarządzanie członkostwem w grupie w celu udzielenia uprawnień tworzenia podmiotom zabezpieczeń przez dodanie ich do grupy klonowania. Zobacz Zarządzanie grupami.
- Przejrzyj i dostosuj uprawnienia dla poszczególnych użytkowników lub grup. Zobacz Zarządzanie uprawnieniami.
- Dowiedz się więcej o środowisku dostępu użytkowników. Zobacz Co to jest dostęp użytkowników? i Użyj usługi Genie One.
- Konfigurowanie mechanizmów zarządzania danymi dla użytkowników indywidualnych. Zobacz Filtry wierszy i maski kolumn.