Procedure consigliate per le identità

Questo articolo offre una prospettiva di opinione su come configurare meglio l'identità in Azure Databricks. Include una guida su come eseguire la migrazione alla federazione delle identità, che consente di gestire tutti gli utenti, i gruppi e le entità servizio nell'account Azure Databricks.

Per una panoramica del modello di identità di Azure Databricks, consultare Identità di Azure Databricks.

Per informazioni su come accedere in modo sicuro alle API di Azure Databricks, vedere Gestire le autorizzazioni del token di accesso personale.

Configurare utenti, entità servizio e gruppi

Esistono tre tipi di identità di Azure Databricks:

• Utenti: identità utente riconosciute da Azure Databricks e rappresentate dagli indirizzi di posta elettronica.
• Entità servizio: identità del servizio da usare con processi, strumenti automatizzati e sistemi quali script, app e piattaforme CI/CD.
• Gruppi: i gruppi semplificano la gestione delle identità, rendendo più facile l'assegnazione dell'accesso a aree di lavoro, dati e altri oggetti a protezione diretta.

Databricks consiglia di creare entità servizio per eseguire processi di produzione o modificare i dati di produzione. Se tutti i processi che agiscono sui dati di produzione vengono eseguiti usando entità servizio, gli utenti interattivi non necessitano di privilegi di scrittura, eliminazione o modifica nell'ambiente di produzione. In questo modo si elimina il rischio che un utente sovrascriva i dati di produzione per errore.

È consigliabile assegnare l'accesso alle aree di lavoro e ai criteri di controllo di accesso in Unity Catalog ai gruppi, anziché agli utenti singolarmente. Tutte le identità di Azure Databricks possono essere assegnate come membri di gruppi e i membri ereditano le autorizzazioni assegnate al proprio gruppo.

Di seguito sono riportati i ruoli amministrativi che possono gestire le identità di Azure Databricks:

• Gli amministratori dell'account possono aggiungere utenti, entità servizio e gruppi all'account e assegnare loro ruoli di amministratore. Possono concedere agli utenti l'accesso alle aree di lavoro, purché essi usino la federazione delle identità.
• Gli amministratori dell'area di lavoro possono aggiungere utenti o entità servizio all'account Azure Databricks. Possono anche aggiungere gruppi all'account Azure Databricks se le aree di lavoro sono abilitate per la federazione delle identità. Gli amministratori dell'area di lavoro possono dare accesso alle loro aree di lavoro a utenti, entità servizio e gruppi.
• I responsabili dei gruppi possono gestire l'appartenenza ai gruppi. Possono anche assegnare ad altri utenti il ruolo di gestione del gruppo.
• I responsabili dell'entità servizio possono gestire i ruoli in un'entità servizio.

Databricks consiglia un numero limitato di amministratori account in ogni account e amministratori dell'area di lavoro in ogni area di lavoro.

Sincronizzare gli utenti e i gruppi con l'account Azure Databricks da Microsoft Entra ID

Databricks consiglia di usare il provisioning SCIM per sincronizzare automaticamente tutti gli utenti e i gruppi da Microsoft Entra ID all'account Azure Databricks. SCIM semplifica l'onboarding di un nuovo dipendente o team usando Microsoft Entra ID per creare utenti e gruppi in Azure Databricks e concedere loro il livello di accesso appropriato. Quando un utente lascia l'organizzazione o non ha più bisogno dell'accesso ad Azure Databricks, gli amministratori possono terminare l'utente in Microsoft Entra ID e l'account dell'utente verrà rimosso anche da Azure Databricks. In questo modo, si garantisce un processo di offboarding coerente e impedisce agli utenti non autorizzati di accedere ai dati sensibili.

È consigliabile sincronizzare tutti gli utenti e i gruppi in Microsoft Entra ID alla console dell'account anziché alle singole aree di lavoro. In questo modo, è sufficiente configurare un'applicazione di provisioning SCIM per mantenere coerenti tutte le identità in tutte le aree di lavoro nell'account. Vedere Abilitare tutti gli utenti di Microsoft Entra ID per accedere ad Azure Databricks.

Se nel provider di identità sono presenti meno di 10.000 utenti, Databricks consiglia di assegnare un gruppo nel provider di identità che contiene tutti gli utenti all'applicazione SCIM a livello di account. È quindi possibile assegnare utenti, gruppi e entità servizio specifici dall'account a aree di lavoro specifiche all'interno di Azure Databricks usando la federazione delle identità.

Abilitare la federazione delle identità

La federazione delle identità consente di configurare gli utenti, le entità servizio e i gruppi nella console dell'account e quindi di assegnare a quelle identità l'accesso ad aree di lavoro specifiche. Ciò semplifica l'amministrazione e la governance dei dati di Azure Databricks.

Con la federazione delle identità, è possibile configurare utenti, entità servizio e gruppi di Azure Databricks una sola volta nella console dell'account, anziché ripetere la configurazione separatamente in ogni area di lavoro. Questo riduce l'attrito nell'onboarding di un nuovo team in Azure Databricks e consente di gestire un'applicazione di provisioning SCIM con Microsoft Entra ID nell'account Azure Databricks, anziché un'applicazione di provisioning SCIM separata per ogni area di lavoro. Dopo l'aggiunta di utenti, entità servizio e gruppi all'account, è possibile assegnarle autorizzazioni per le aree di lavoro. È possibile assegnare alle identità a livello di account solo l'accesso alle aree di lavoro abilitate per la federazione delle identità.

Per abilitare un'area di lavoro per la federazione delle identità, vedere Come abilitare la federazione delle identità in un'area di lavoro? Al termine dell'assegnazione, la federazione delle identità viene contrassegnata come Abilitata nella scheda Configurazione dell'area di lavoro nella console dell'account.

La federazione delle identità è abilitata a livello di area di lavoro ed è possibile avere una combinazione di aree di lavoro con e senza identità federate. Per le aree di lavoro che non sono abilitate per la federazione delle identità, gli amministratori dell'area di lavoro gestiscono gli utenti dell'area di lavoro, le entità servizio e i gruppi interamente all'interno dell'ambito dell'area di lavoro (modello legacy). Non possono usare la console dell'account o le API a livello di account per assegnare gli utenti dall'account a queste aree di lavoro, ma possono usare qualsiasi interfaccia a livello di area di lavoro. Ogni volta che un nuovo utente o un'entità servizio viene aggiunta a un'area di lavoro usando interfacce a livello di area di lavoro, tale utente o entità servizio viene sincronizzato con il livello di account. In questo modo è possibile avere un set coerente di utenti e entità servizio nell'account.

Tuttavia, quando un gruppo viene aggiunto a un'area di lavoro con identità non federata usando interfacce a livello di area di lavoro, tale gruppo è un gruppo locale dell'area di lavoro e non viene aggiunto all'account. È consigliabile usare gruppi di account anziché gruppi locali dell'area di lavoro. Ai gruppi locali dell'area di lavoro non possono essere concessi criteri di controllo di accesso in Unity Catalog o autorizzazioni per altre aree di lavoro.

Eseguire l'aggiornamento alla federazione delle identità.

Se si abilita la federazione delle identità in un'area di lavoro esistente, eseguire le operazioni seguenti:

1. Eseguire la migrazione del provisioning SCIM dal livello di area di lavoro al livello di account.

   Se si dispone di un provisioning SCIM a livello di area di lavoro configurato per l'area di lavoro, è necessario configurare il provisioning SCIM a livello di account e disattivare il provisioner SCIM a livello di area di lavoro. Lo SCIM a livello di area di lavoro continuerà a creare e aggiornare i gruppi locali dell'area di lavoro. Databricks consiglia di usare gruppi di account anziché gruppi locali dell'area di lavoro per sfruttare i vantaggi dell'assegnazione centralizzata dell'area di lavoro e della gestione degli accessi ai dati tramite Unity Catalog. SCIM a livello di area di lavoro non riconosce anche i gruppi di account assegnati all'area di lavoro federata di identità e le chiamate API SCIM a livello di area di lavoro avranno esito negativo se coinvolgono gruppi di account. Per altre informazioni su come disabilitare SCIM a livello di area di lavoro, vedere Eseguire la migrazione del provisioning SCIM a livello di area di lavoro al livello di account.

2. Eseguire la conversione dei gruppi locali dell'area di lavoro ai gruppi di account

   Databricks consiglia di convertire i gruppi locali dell'area di lavoro esistenti in gruppi di account. Si veda Eseguire la migrazione dei gruppi locali dell'area di lavoro ai gruppi di account per le istruzioni.

Assegnare le autorizzazioni dell'area di lavoro dei gruppi

Ora che la federazione delle identità è abilitata nell'area di lavoro, è possibile assegnare gli utenti, le entità servizio e i gruppi nelle autorizzazioni dell'account per tale area di lavoro. Databricks consiglia di assegnare autorizzazioni per i gruppi alle aree di lavoro invece di assegnare le autorizzazioni dell'area di lavoro agli utenti singolarmente. Tutte le identità di Azure Databricks possono essere assegnate come membri di gruppi e i membri ereditano le autorizzazioni assegnate al proprio gruppo.

Altre informazioni

• Gestire utenti, entità servizio e gruppi, ulteriori informazioni sul modello di identità di Azure Databricks.
• Sincronizzare utenti e gruppi da Microsoft Entra ID, iniziare usando il provisioning SCIM.
• Procedure consigliate per Unity Catalog, informazioni su come configurare al meglio Unity Catalog.