Najlepsze rozwiązania dotyczące tożsamości

Ten artykuł zawiera opinię na temat tego, jak najlepiej skonfigurować tożsamość w usłudze Azure Databricks. Zawiera on przewodnik dotyczący migracji do federacji tożsamości, który umożliwia zarządzanie wszystkimi użytkownikami, grupami i jednostkami usługi na koncie usługi Azure Databricks.

Aby zapoznać się z omówieniem modelu tożsamości usługi Azure Databricks, zobacz Tożsamości usługi Azure Databricks.

Aby uzyskać informacje na temat bezpiecznego uzyskiwania dostępu do interfejsów API usługi Azure Databricks, zobacz Zarządzanie uprawnieniami osobistego tokenu dostępu.

Konfigurowanie użytkowników, jednostek usługi i grup

Istnieją trzy typy tożsamości usługi Azure Databricks:

• Użytkownicy: tożsamości użytkowników rozpoznawane przez usługę Azure Databricks i reprezentowane przez adresy e-mail.
• Jednostki usługi: tożsamości do użycia z zadaniami, zautomatyzowanymi narzędziami i systemami, takimi jak skrypty, aplikacje i platformy ciągłej integracji/ciągłego wdrażania.
• Grupy: grupy upraszczają zarządzanie tożsamościami, ułatwiając przypisywanie dostępu do obszarów roboczych, danych i innych zabezpieczanych obiektów.

Usługa Databricks zaleca tworzenie jednostek usługi w celu uruchamiania zadań produkcyjnych lub modyfikowania danych produkcyjnych. Jeśli wszystkie procesy działające na danych produkcyjnych są uruchamiane przy użyciu jednostek usługi, interakcyjni użytkownicy nie potrzebują żadnych uprawnień do zapisu, usuwania ani modyfikowania w środowisku produkcyjnym. Eliminuje to ryzyko przypadkowego zastąpienia danych produkcyjnych przez użytkownika.

Najlepszym rozwiązaniem jest przypisanie dostępu do obszarów roboczych i zasad kontroli dostępu w środowisku Unity Catalog do grup, a nie do poszczególnych użytkowników. Wszystkie tożsamości usługi Azure Databricks można przypisać jako członków grup, a członkowie dziedziczą uprawnienia przypisane do ich grupy.

Poniżej przedstawiono role administracyjne, które mogą zarządzać tożsamościami usługi Azure Databricks:

• Administratorzy kont mogą dodawać użytkowników, jednostki usługi i grupy do konta i przypisywać im role administratora. Mogą oni zapewnić użytkownikom dostęp do obszarów roboczych, o ile te obszary robocze używają federacji tożsamości.
• Administratorzy obszaru roboczego mogą dodawać użytkowników, jednostki usługi do konta usługi Azure Databricks. Mogą również dodawać grupy do konta usługi Azure Databricks, jeśli ich obszary robocze są włączone na potrzeby federacji tożsamości. Administratorzy obszaru roboczego mogą grant użytkownikom, podmiotom usługi i grupom dostęp do swoich obszarów roboczych.
• Menedżerowie grup mogą zarządzać członkostwem w grupach. Mogą również przypisywać innym użytkownikom rolę menedżera grupy.
• Menedżerowie jednostki usługi mogą zarządzać rolami w jednostce usługi.

Usługa Databricks zaleca, aby w każdym obszarze roboczym istniała ograniczona liczba administratorów kont i administratorów obszaru roboczego.

Sync użytkowników i grup z Microsoft Entra ID do swojego konta Azure Databricks

Usługa Databricks zaleca używanie aprowizacji SCIM do automatycznego sync użytkowników i grup z identyfikatora Entra firmy Microsoft do konta usługi Azure Databricks. Program SCIM usprawnia dołączanie nowego pracownika lub zespołu przy użyciu identyfikatora Entra firmy Microsoft w celu tworzenia użytkowników i grup w usłudze Azure Databricks oraz zapewniania im odpowiedniego poziomu dostępu. Gdy użytkownik opuści organizację lub nie potrzebuje już dostępu do usługi Azure Databricks, administratorzy mogą remove użytkownika z Microsoft Entra ID, a użytkownik zostaje dezaktywowany w usłudze Azure Databricks. Zapewnia to spójny proces odłączania i uniemożliwia nieautoryzowanym użytkownikom dostęp do poufnych danych.

Należy dążyć do zsynchronizowania wszystkich użytkowników i grup w usłudze Microsoft Entra ID z konsolą konta, a nie poszczególnymi obszarami roboczymi. W ten sposób wystarczy skonfigurować tylko jedną aplikację aprowizacji SCIM, aby zachować spójność wszystkich tożsamości we wszystkich obszarach roboczych na koncie. Zobacz Włączanie wszystkich użytkowników identyfikatora Entra firmy Microsoft w celu uzyskania dostępu do usługi Azure Databricks.

Ważne

Jeśli masz już łączniki SCIM, które sync tożsamości bezpośrednio do obszarów roboczych, należy wyłączyć te łączniki SCIM po włączeniu łącznika SCIM na poziomie konta. Zobacz Uaktualnianie do federacji tożsamości.

Jeśli u dostawcy tożsamości znajduje się poniżej 10 000 użytkowników, usługa Databricks zaleca przypisanie grupy u dostawcy tożsamości zawierającego wszystkich użytkowników do aplikacji SCIM na poziomie konta. Określonych użytkowników, grup i jednostek usługi można następnie przypisać z konta do określonych obszarów roboczych w usłudze Azure Databricks przy użyciu federacji tożsamości.

Włączanie federacji tożsamości

Federacja tożsamości umożliwia konfigurowanie użytkowników, jednostek usługi i grup w konsoli konta, a następnie przypisywanie tych tożsamości dostępu do określonych obszarów roboczych. Upraszcza to administrowanie usługą Azure Databricks i zarządzanie danymi.

Ważne

Usługa Databricks zaczęła automatyczne włączanie nowych obszarów roboczych dla federacji tożsamości i Unity Catalog w dniu 9 listopada 2023 r., a wdrożenie przebiega stopniowo w różnych kontach. Jeśli obszar roboczy jest domyślnie włączony dla federacji tożsamości, nie można go wyłączyć. Aby uzyskać więcej informacji, zobacz Automatyczne włączanie Unity Catalog.

W przypadku federacji tożsamości można skonfigurować użytkowników usługi Azure Databricks, jednostki usługi i grupy raz w konsoli konta, zamiast powtarzać konfigurację oddzielnie w każdym obszarze roboczym. Zmniejsza to problemy podczas dołączania nowego zespołu do usługi Azure Databricks i umożliwia utrzymanie jednej aplikacji aprowizacji SCIM przy użyciu identyfikatora Entra firmy Microsoft na koncie usługi Azure Databricks zamiast oddzielnej aplikacji aprowizacji SCIM dla każdego obszaru roboczego. Gdy użytkownicy, jednostki usługi i grupy zostaną dodane do konta, możesz przypisać im uprawnienia do obszarów roboczych. Tożsamości na poziomie konta można przypisywać tylko do obszarów roboczych, które są włączone na potrzeby federacji tożsamości.

Aby włączyć obszar roboczy dla federacji tożsamości, zobacz Jak administratorzy włączają federację tożsamości w obszarze roboczym?. Po zakończeniu przypisywania federacja tożsamości jest oznaczona jako Włączona na karcie Konfiguracja obszaru roboczego w konsoli konta.

Federacja tożsamości jest włączona na poziomie obszaru roboczego i można mieć kombinację federacyjnych i nienależących do tożsamości obszarów roboczych. W przypadku tych obszarów roboczych, które nie są włączone dla federacji tożsamości, administratorzy obszarów roboczych zarządzają użytkownikami obszaru roboczego, jednostkami usługi i grupami w całości w zakresie obszaru roboczego (starszy model). Nie mogą używać konsoli konta ani interfejsów API na poziomie konta do przypisywania użytkowników z konta do tych obszarów roboczych, ale mogą używać dowolnego interfejsu na poziomie obszaru roboczego. Za każdym razem, gdy nowy użytkownik lub jednostka usługi zostanie dodany do obszaru roboczego przy użyciu interfejsów na poziomie obszaru roboczego, ten użytkownik lub jednostka usługi jest synchronizowany z poziomem konta. Dzięki temu można mieć jedną spójną set użytkowników i jednostek usługi na koncie.

Jednak po dodaniu grupy do obszaru roboczego bez tożsamości federacyjnego przy użyciu interfejsów na poziomie obszaru roboczego ta grupa jest grupą lokalną obszaru roboczego i nie jest dodawana do konta. Należy dążyć do używania grup kont, a nie grup lokalnych obszaru roboczego. Grupom lokalnym obszaru roboczego nie można udzielić zasad kontroli dostępu ani uprawnień do innych obszarów roboczych w środowisku Unity Catalog.

Uaktualnianie do federacji tożsamości

Jeśli włączasz federację tożsamości w istniejącym obszarze roboczym, wykonaj następujące czynności:

1. Migrowanie aprowizacji SCIM na poziomie obszaru roboczego do poziomu konta

   Jeśli masz aprowizację SCIM na poziomie obszaru roboczego set obszarze roboczym, należy set aprowizację SCIM na poziomie konta i wyłączyć aprowizację SCIM na poziomie obszaru roboczego. SCIM na poziomie obszaru roboczego będzie nadal tworzyć i update grupy lokalne obszaru roboczego. Usługa Databricks zaleca używanie grup kont zamiast grup lokalnych obszaru roboczego, aby korzystać z scentralizowanego przypisywania obszaru roboczego i zarządzania dostępem do danych przy użyciu środowiska Unity Catalog. SCIM na poziomie obszaru roboczego nie rozpoznaje również grup kont przypisanych do obszaru roboczego federacyjnego tożsamości, a wywołania interfejsu API SCIM na poziomie obszaru roboczego nie powiedzą się, jeśli będą obejmować grupy kont. Aby uzyskać więcej informacji na temat wyłączania protokołu SCIM na poziomie obszaru roboczego, zobacz Migrowanie aprowizacji SCIM na poziomie obszaru roboczego do poziomu konta.

2. Konwertowanie grup lokalnych obszaru roboczego na grupy kont

   Usługa Databricks zaleca konwertowanie istniejących grup lokalnych obszaru roboczego na grupy kont. Aby uzyskać instrukcje, zobacz Migrowanie grup obszarów roboczych lokalnych do grup kont.

Przypisywanie uprawnień obszaru roboczego grup

Teraz, gdy federacja tożsamości jest włączona w obszarze roboczym, możesz przypisać użytkowników, jednostki usługi i grupy w uprawnieniach konta w tym obszarze roboczym. Usługa Databricks zaleca przypisywanie uprawnień grup do obszarów roboczych zamiast przypisywania uprawnień obszaru roboczego do użytkowników indywidualnie. Wszystkie tożsamości usługi Azure Databricks można przypisać jako członków grup, a członkowie dziedziczą uprawnienia przypisane do ich grupy.

Dowiedz się więcej

• Zarządzanie użytkownikami, jednostkami usługi i grupami— dowiedz się więcej o modelu tożsamości usługi Azure Databricks.
• Sync użytkownicy i grupy z Microsoft Entra ID, get zaczęli korzystać z aprowizacji SCIM.
• Unity Catalog najlepsze praktyki, dowiedz się, jak najlepiej skonfigurować CatalogUnity.