Migrowanie kontrolki uprawnień obszaru roboczego

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.

    Dodaj podmiot do obszaru roboczego i wybierz każde uprawnienie osobno.

  • Grupa users nie ma uprawnień, a admins grupa ma wszystkie uprawnienia obszaru roboczego. Żadna z nich nie może zostać zmieniona.

  • Nie można zagnieżdżać grup users i admins w 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 users lub admins jest 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:

  1. Jako administrator obszaru roboczego zaloguj się do obszaru roboczego Azure Databricks.

  2. Kliknij swoją nazwę użytkownika na górnym pasku i wybierz pozycję Ustawienia.

  3. Kliknij kartę Zaawansowane.

  4. 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).

    Ustawienie kontroli dostępu pokazujące obszar roboczy przy użyciu poprzedniego zachowania.

  5. Kliknij przycisk Zarządzaj.

  6. W oknie dialogowym sprawdź bieżące przyznane uprawnienia dla grup users i admins. W obszarze Zachowanie dla tego obszaru roboczego wybierz pozycję Użyj nowego zachowania.

  7. 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.

    Okno dialogowe „Zarządzanie” z zaznaczonym nowym zachowaniem i polem nazwy grupy klonowania.

  8. Kliknij Zapisz.

    Azure Databricks przenosi uprawnienia z users do 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.

Ustawienie kontroli dostępu pokazujące obszar roboczy w nowym zachowaniu.

Weryfikowanie zmian

Po zakończeniu migracji sprawdź, czy zmiany zostały zastosowane poprawnie:

  1. Jako administrator obszaru roboczego zaloguj się do obszaru roboczego Azure Databricks.
  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. Sprawdź następujące kwestie:
    • Sklonowana grupa istnieje i ma uprawnienia, które grupa users miał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 users nie ma uprawnień, a admins grupa ma wszystkie uprawnienia obszaru roboczego.

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: