Modello di controllo di accesso in Azure Data Lake Storage
Data Lake Storage 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 dati 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 di 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 all'attributo di Azure si basa sul controllo degli accessi in base al ruolo di Azure aggiungendo condizioni di assegnazione di ruolo basate su 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 Storage.
Modalità di valutazione delle autorizzazioni
Durante l'autorizzazione basata sull'entità di sicurezza, le autorizzazioni vengono valutate come illustrato nel diagramma seguente.
- 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.
- 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).
- 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.
- 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 dati 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 dati 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 dati 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 dati 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 dati 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 dati 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 dati 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 Storage 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. Al contrario, è possibile aggiungere o rimuovere utenti ed entità servizio nel gruppo di sicurezza di 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 gruppo LogsWriter e un gruppo LogsReader. È quindi possibile assegnare le autorizzazioni in questo modo:
- Aggiungere il gruppo
LogsWriterall'elenco di controllo di accesso della directory /LogData con autorizzazioni dirwx. - Aggiungere il gruppo
LogsReaderall'elenco di controllo di accesso della directory /LogData con autorizzazioni dir-x. - Aggiungere l'oggetto entità servizio o l'identità del servizio gestita per ADF al gruppo
LogsWriters. - 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 gruppo
LogsReader.
Se un utente del team di progettazione dei servizi lascia l'azienda, è possibile rimuoverli dal gruppo LogsWriter. 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 Storage 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 Storage 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 | Account di archiviazione, 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 Storage supporta anche i metodi Shared Key e SAS 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 Storage.