Procedure consigliate per l'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, vedere Identità di Azure Databricks.

Per informazioni su come accedere in modo sicuro alle API di Azure Databricks, vedere Autenticazione dell'API sicura.

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à da usare con processi, strumenti automatizzati e sistemi come script, app e piattaforme CI/CD.
• Gruppi: i gruppi semplificano la gestione delle identità, semplificando 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 assegnarli ruoli di amministratore. Possono concedere agli utenti l'accesso alle aree di lavoro, purché tali aree di lavoro usino la federazione delle identità.
• Gli amministratori dell'area di lavoro possono aggiungere utenti, 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 concedere agli utenti, alle entità servizio e ai gruppi l'accesso alle aree di lavoro.
• 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 di contenere un numero limitato di amministratori di account per account e amministratori dell'area di lavoro in ogni area di lavoro.

Sincronizzare utenti e gruppi da Microsoft Entra ID (in precedenza Azure Active Directory) all'account Azure Databricks

Databricks consiglia di usare il provisioning SCIM per sincronizzare automaticamente utenti e gruppi da Microsoft Entra ID (in precedenza Azure Active Directory) 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 nell'ID Microsoft Entra 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 che intendono usare Azure Databricks nella console dell'account anziché nelle 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.

Importante

Se si dispone già di connettori SCIM che sincronizzano le identità direttamente nelle aree di lavoro, è necessario disabilitare tali connettori SCIM quando il connettore SCIM a livello di account è abilitato. Vedere Eseguire l'aggiornamento alla federazione delle identità.

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 utenti, entità servizio e gruppi nella console dell'account e quindi assegnare tali identità all'accesso a aree di lavoro specifiche. Ciò semplifica l'amministrazione e la governance dei dati di Azure Databricks.

Importante

Se l'account è stato creato dopo il 9 novembre 2023, la federazione delle identità è abilitata in tutte le nuove aree di lavoro per impostazione predefinita e non può essere disabilitata.

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 l'ID Microsoft Entra 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 federate federate e non identità. 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 federata non identità 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. I gruppi locali dell'area di lavoro non possono essere concessi criteri di controllo di accesso nel catalogo unity 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 a 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. 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. Convertire i gruppi locali dell'area di lavoro in gruppi di account

   Databricks consiglia di convertire i gruppi locali dell'area di lavoro esistenti in gruppi di account. Per istruzioni, vedere Eseguire la migrazione di gruppi locali dell'area di lavoro a gruppi di account.

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, altre informazioni sul modello di identità di Azure Databricks.
• Sincronizzare utenti e gruppi da Microsoft Entra ID, iniziare a usare il provisioning SCIM.
• Procedure consigliate per il catalogo unity, informazioni su come configurare al meglio il catalogo Unity.