Modello di controllo di accesso in Azure Data Lake Archiviazione Gen2

Data Lake Archiviazione Gen2 supporta i meccanismi di autorizzazione seguenti:

• Autorizzazione con chiave condivisa
• Autorizzazione con firma di accesso condiviso (SAS)
• Controllo degli accessi in base al ruolo di Azure
• Controllo degli accessi in base all'attributo (ABAC di Azure)
• Elenchi di controllo di accesso (ACL)

L'autorizzazione con chiave condivisa e firma di accesso condiviso concede l'accesso a un utente (o a un'applicazione) senza richiedere loro di avere un'identità in Microsoft Entra ID. Con queste due forme di autenticazione, il controllo degli accessi in base al ruolo di Azure, il controllo degli accessi in base al ruolo di Azure e gli ACL non hanno alcun effetto.

Il controllo degli accessi in base al ruolo di Azure e l'ACL richiedono che l'utente (o l'applicazione) abbia un'identità in Microsoft Entra ID. Il controllo degli accessi in base al ruolo di Azure consente di concedere l'accesso "grossolano" ai dati dell'account di archiviazione, ad esempio l'accesso in lettura o scrittura a tutti i dati in un account di archiviazione. Il controllo degli accessi in base al ruolo di Azure consente di perfezionare le assegnazioni di ruolo del controllo degli accessi in base al ruolo aggiungendo condizioni. Ad esempio, è possibile concedere l'accesso in lettura o scrittura a tutti gli oggetti dati in un account di archiviazione con un tag specifico. Gli ACL consentono di concedere l'accesso con granularità fine, ad esempio l'accesso in scrittura a una directory o a un file specifico.

Questo articolo è incentrato sul controllo degli accessi in base al ruolo di Azure, sul controllo degli accessi in base al ruolo e sugli ACL e sul modo in cui il sistema li valuta insieme per prendere decisioni di autorizzazione per le risorse dell'account di archiviazione.

Controllo degli accessi in base al ruolo di Azure

Il controllo degli accessi in base al ruolo di Azure usa le assegnazioni di ruolo per applicare set di autorizzazioni alle entità di sicurezza. Un'entità di sicurezza è un oggetto che rappresenta un utente, un gruppo, un'entità servizio o un'identità gestita definita in Microsoft Entra ID. Un set di autorizzazioni può assegnare a un'entità di sicurezza un livello di accesso "granulare grossolano", ad esempio l'accesso in lettura o scrittura a tutti i dati in un account di archiviazione o a tutti i dati in un contenitore.

I ruoli seguenti consentono a un'entità di sicurezza di accedere ai dati in un account di archiviazione.

Ruolo	Descrizione
Proprietario dei dati del BLOB di archiviazione	Accesso completo a contenitori e dati di archiviazione BLOB. Questo accesso consente all'entità di sicurezza di impostare il proprietario di un elemento e di modificare gli elenchi di controllo di accesso di tutti gli elementi.
Collaboratore ai dati del BLOB di archiviazione	Lettura, scrittura ed eliminazione dell'accesso ai contenitori e ai BLOB di archiviazione BLOB. Questo accesso non consente all'entità di sicurezza di impostare la proprietà di un elemento, ma può modificare l'ACL di elementi di proprietà dell'entità di sicurezza.
Lettore dei dati del BLOB di archiviazione	Leggere ed elencare contenitori e BLOB di archiviazione BLOB.

I ruoli come Proprietario, Collaboratore, Lettore e Collaboratore account Archiviazione consentono a un'entità di sicurezza di gestire un account di archiviazione, ma non forniscono l'accesso ai dati all'interno di tale account. Tuttavia, questi ruoli (escluso lettore) possono ottenere l'accesso alle chiavi di archiviazione, che possono essere usate in vari strumenti client per accedere ai dati.

Controllo degli accessi in base all'attributo (ABAC di Azure)

Il controllo degli accessi in base al ruolo di Azure si basa sul controllo degli accessi in base al ruolo di Azure aggiungendo condizioni di assegnazione dei ruoli in base agli attributi nel contesto di azioni specifiche. Una condizione di assegnazione di ruolo è un controllo aggiuntivo che è possibile aggiungere facoltativamente all'assegnazione di ruolo per fornire un controllo di accesso più raffinato. Non è possibile negare esplicitamente l'accesso a risorse specifiche usando condizioni.

Per altre informazioni sull'uso del controllo degli accessi in base al ruolo di Azure per controllare l'accesso alle Archiviazione di Azure, vedere Autorizzare l'accesso alle Archiviazione BLOB di Azure usando le condizioni di assegnazione dei ruoli di Azure.

Elenchi di controllo di accesso (ACL)

Gli elenchi di controllo di accesso consentono di applicare il livello di accesso "granulare" alle directory e ai file. Un ACL è un costrutto di autorizzazione che contiene una serie di voci ACL. Ogni voce ACL associa l'entità di sicurezza a un livello di accesso. Per altre informazioni, vedere Elenchi di controllo di accesso (ACL) in Azure Data Lake Archiviazione Gen2.

Modalità di valutazione delle autorizzazioni

Durante l'autorizzazione basata sull'entità di sicurezza, le autorizzazioni vengono valutate come illustrato nel diagramma seguente.

1. Azure determina se esiste un'assegnazione di ruolo per l'entità.
   • Se esiste un'assegnazione di ruolo, le condizioni di assegnazione di ruolo (2) vengono valutate successivamente.
   • In caso contrario, gli elenchi di controllo di accesso (4) vengono valutati successivamente.
2. Azure determina se esistono condizioni di assegnazione di ruolo ABAC.
   • Se non esistono condizioni, viene concesso l'accesso.
   • Se esistono condizioni, vengono valutate per verificare se corrispondono alla richiesta (3).
3. Azure determina se tutte le condizioni di assegnazione dei ruoli ABAC corrispondono agli attributi della richiesta.
   • Se tutti corrispondono, viene concesso l'accesso.
   • Se almeno uno di essi non corrisponde, gli elenchi di controllo di accesso (4) vengono valutati successivamente.
4. Se l'accesso non è stato concesso in modo esplicito dopo aver valutato le assegnazioni e le condizioni di ruolo, gli elenchi di controllo di accesso vengono valutati.
   • Se gli elenchi di controllo di accesso consentono il livello di accesso richiesto, viene concesso l'accesso.
   • In caso contrario, l'accesso viene negato.

Importante

A causa del modo in cui le autorizzazioni di accesso vengono valutate dal sistema, non è possibile usare un elenco di controllo di accesso per limitare l'accesso già concesso da un'assegnazione di ruolo e dalle relative condizioni. Questo perché il sistema valuta prima le assegnazioni di ruolo e le condizioni di Azure e se l'assegnazione concede autorizzazioni di accesso sufficienti, gli ACL vengono ignorati.

Il diagramma seguente illustra il flusso di autorizzazione per tre operazioni comuni: elenco del contenuto della directory, lettura di un file e scrittura di un file.

Tabella delle autorizzazioni: combinazione di controllo degli accessi in base al ruolo di Azure, controllo degli accessi in base al ruolo e ACL

La tabella seguente illustra come combinare ruoli, condizioni e voci ACL di Azure in modo che un'entità di sicurezza possa eseguire le operazioni elencate nella colonna Operazione . Questa tabella mostra una colonna che rappresenta ogni livello di una gerarchia di directory fittizia. Esiste una colonna per la directory radice del contenitore (/), una sottodirectory denominata Oregon, una sottodirectory della directory Oregon denominata Portland e un file di testo nella directory Portland denominata Data.txt. La visualizzazione in tali colonne è costituita da rappresentazioni in forma breve della voce ACL necessaria per concedere le autorizzazioni. N/D (Non applicabile) viene visualizzato nella colonna se non è necessaria una voce ACL per eseguire l'operazione.

Operazione	Ruolo di Azure assegnato (con o senza condizioni)	/	Oregon/	Portland/	Data.txt
Read Data.txt	Proprietario dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Collaboratore ai dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Lettore dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	None	--X	--X	--X	R--
Append to Data.txt	Proprietario dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Collaboratore ai dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Lettore dei dati del BLOB di archiviazione	--X	--X	--X	-W-
	None	--X	--X	--X	RW-
Delete Data.txt	Proprietario dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Collaboratore ai dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Lettore dei dati del BLOB di archiviazione	--X	--X	-WX	N/D
	None	--X	--X	-WX	N/D
Create Data.txt	Proprietario dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Collaboratore ai dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Lettore dei dati del BLOB di archiviazione	--X	--X	-WX	N/D
	None	--X	--X	-WX	N/D
Elenco /	Proprietario dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Collaboratore ai dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Lettore dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	None	R-X	N/D	N/D	N/D
Elencare /Oregon/	Proprietario dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Collaboratore ai dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Lettore dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	None	--X	R-X	N/D	N/D
Elencare /Oregon/Portland/	Proprietario dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Collaboratore ai dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	Lettore dei dati del BLOB di archiviazione	N/D	N/D	N/D	N/D
	None	--X	--X	R-X	N/D

Nota

Per visualizzare il contenuto di un contenitore in Archiviazione di Azure Explorer, le entità di sicurezza devono accedere a Archiviazione Explorer usando Microsoft Entra ID e(almeno) hanno accesso in lettura (R--) alla cartella radice (\) di un contenitore. Questo livello di autorizzazione consente di elencare il contenuto della cartella radice. Se non si vuole che il contenuto della cartella radice sia visibile, è possibile assegnargli il ruolo Lettore . Con questo ruolo, sarà possibile elencare i contenitori nell'account, ma non il contenuto del contenitore. È quindi possibile concedere l'accesso a directory e file specifici usando ACL.

Gruppi di sicurezza

Usare sempre i gruppi di sicurezza Di Microsoft Entra come entità assegnata in una voce ACL. Evitare di assegnare direttamente singoli utenti o entità servizio. L'uso di questa struttura consentirà di aggiungere e rimuovere utenti o entità servizio senza la necessità di riapplicare gli elenchi di controllo di accesso a un'intera struttura di directory. È invece possibile aggiungere o rimuovere utenti e entità servizio dal gruppo di sicurezza Microsoft Entra appropriato.

Esistono molti modi diversi per configurare i gruppi. Si supponga, ad esempio, una directory denominata /LogData che contiene i dati di log generati dal server. Azure Data Factory inserisce dati in questa cartella. Utenti specifici del team di progettazione dei servizi caricano i log e gestiscono altri utenti di questa cartella e diversi cluster Databricks analizzano i log dalla cartella.

Per abilitare queste attività, è possibile creare un LogsWriter gruppo e un LogsReader gruppo. È quindi possibile assegnare le autorizzazioni in questo modo:

• Aggiungere il LogsWriter gruppo all'elenco di controllo di accesso della directory /LogData con rwx autorizzazioni.
• Aggiungere il LogsReader gruppo all'elenco di controllo di accesso della directory /LogData con r-x autorizzazioni.
• Aggiungere l'oggetto entità servizio o l'identità del servizio gestita per ADF al LogsWriters gruppo.
• Aggiungere gli utenti del team di progettazione dei servizi al gruppo LogsWriter.
• Aggiungere l'oggetto entità servizio o l'identità del servizio gestito per Databricks al LogsReader gruppo.

Se un utente del team di progettazione dei servizi lascia l'azienda, è sufficiente rimuoverli dal LogsWriter gruppo. Se l'utente non è stato aggiunto a un gruppo, ma è stata invece aggiunta una voce di elenco di controllo di accesso dedicata per l'utente, è necessario rimuovere la voce dalla directory /LogData. In questo caso, è anche necessario rimuovere la voce da tutti i file e le sottodirectory nell'intera gerarchia di directory della directory /LogData.

Per creare un gruppo e aggiungere membri, vedere Creare un gruppo di base e aggiungere membri usando Microsoft Entra ID.

Importante

Azure Data Lake Archiviazione Gen2 dipende dall'ID Microsoft Entra per gestire i gruppi di sicurezza. Microsoft Entra ID consiglia di limitare l'appartenenza a un gruppo per una determinata entità di sicurezza a meno di 200. Questa raccomandazione è dovuta a una limitazione dei token JSON Web (JWT) che forniscono informazioni sull'appartenenza ai gruppi di un'entità di sicurezza all'interno delle applicazioni Microsoft Entra. Il superamento di questo limite potrebbe causare problemi di prestazioni imprevisti con Data Lake Archiviazione Gen2. Per altre informazioni, vedere Configurare le attestazioni di gruppo per le applicazioni usando Microsoft Entra ID.

Limiti per le assegnazioni di ruolo di Azure e le voci ACL

Usando i gruppi, è meno probabile che superi il numero massimo di assegnazioni di ruolo per sottoscrizione e il numero massimo di voci ACL per file o directory. Nella tabella seguente vengono descritti questi limiti.

Meccanismo	Ambito	Limiti	Livello di autorizzazione supportato
Controllo degli accessi in base al ruolo di Azure	Archiviazione account, contenitori. Assegnazioni di ruolo di Azure tra risorse a livello di sottoscrizione o gruppo di risorse.	4000 assegnazioni di ruolo di Azure in una sottoscrizione	Ruoli di Azure (predefiniti o personalizzati)
ACL	Directory, file	32 voci ACL (in effetti 28 voci ACL) per file e per ogni directory. L'accesso e gli elenchi di controllo di accesso predefiniti dispongono ognuno di un proprio limite di 32 voci ACL.	Autorizzazione ACL

Autorizzazione con chiave condivisa e firma di accesso condiviso

Azure Data Lake Archiviazione Gen2 supporta anche metodi di firma di accesso condiviso e di firma di accesso condiviso per l'autenticazione. Una caratteristica di questi metodi di autenticazione è che nessuna identità è associata al chiamante e pertanto non è possibile eseguire l'autorizzazione basata sull'autorizzazione basata sull'entità di sicurezza.

Nel caso di Chiave condivisa, il chiamante ottiene effettivamente l'accesso "super-utente", ovvero l'accesso completo a tutte le operazioni su tutte le risorse, inclusi i dati, l'impostazione del proprietario e la modifica degli elenchi di controllo di accesso.

I token di firma di accesso condiviso includono le autorizzazioni consentite come parte del token. Le autorizzazioni incluse nel token di firma di accesso condiviso vengono di fatto applicate a tutte le decisioni di autorizzazione, ma non vengono eseguiti altri controlli ACL.

Passaggi successivi

Per altre informazioni sugli elenchi di controllo di accesso, vedere Elenchi di controllo di accesso (ACL) in Azure Data Lake Archiviazione Gen2.