Controllo di accesso in Azure Data Lake Storage Gen1
Azure Data Lake Storage Gen1 implementa un modello di controllo di accesso che deriva da HDFS, che a sua volta deriva dal modello di controllo di accesso POSIX. Questo articolo riepiloga le nozioni di base del modello di controllo di accesso per Data Lake Storage Gen1.
Elenchi di controllo di accesso su file e cartelle
Esistono due tipi di elenchi di controllo di accesso (ACL), ACL di accesso e ACL predefiniti.
ACL di accesso: controllano l'accesso a un oggetto. I file e le cartelle hanno entrambi ACL di accesso.
ACL predefiniti: un "modello" di ACL associato a una cartella che determina gli ACL di accesso per tutti gli elementi figlio creati in tale cartella. I file non hanno ACL predefiniti.
Sia gli ACL di accesso che gli ACL predefiniti hanno la stessa struttura.
Nota
La modifica dell'ACL predefinito di un elemento padre non influisce sull'ACL di accesso o sull'ACL predefinito degli elementi figlio già esistenti.
Autorizzazioni
Le autorizzazioni per un oggetto file system sono Read, Writee Executee possono essere usate in file e cartelle, come illustrato nella tabella seguente:
Documento | Cartella | |
---|---|---|
Lettura (R) | È possibile leggere il contenuto di un file | Richiede leggi e esegui per elencare i contenuti della cartella |
Scrivi (W) | È possibile scrivere o aggiungere in un file | Richiede write e Execute per creare elementi figlio in una cartella |
Esegui (X) | Non significa nulla nel contesto di Data Lake Storage Gen1 | Necessario per percorrere gli elementi figli di una cartella |
Forme brevi per le autorizzazioni
La forma RWX viene usata per indicare Lettura + Scrittura + Esecuzione. Esiste una forma numerica ridotta in cui Lettura=4, Scrittura=2 ed Esecuzione=1 e la cui somma rappresenta le autorizzazioni. Di seguito sono riportati alcuni esempi.
Forma numerica | Forma breve | Significato |
---|---|---|
7 | RWX |
Lettura + Scrittura + Esecuzione |
5 | R-X |
Lettura + Esecuzione |
4 | R-- |
Leggi |
0 | --- |
Nessuna autorizzazione |
Le autorizzazioni non ereditano
Nel modello in stile POSIX usato da Data Lake Storage Gen1 le autorizzazioni per un elemento vengono archiviate nell'elemento stesso. In altre parole, le autorizzazioni per un elemento non possono essere ereditate dagli elementi padre.
Scenari comuni correlati alle autorizzazioni
Di seguito sono riportati alcuni scenari comuni che consentono di comprendere quali autorizzazioni sono necessarie per eseguire determinate operazioni in un account Data Lake Storage Gen1.
Operazione | Oggetto | / | Seattle/ | Portland/ | Data.txt |
---|---|---|---|---|---|
Leggi | Data.txt | --X |
--X |
--X |
R-- |
Aggiunta a | Data.txt | --X |
--X |
--X |
-W- |
Cancella | Data.txt | --X |
--X |
-WX |
--- |
Creazione | Data.txt | --X |
--X |
-WX |
--- |
Elenco | / | R-X |
--- |
--- |
--- |
Elenco | /Seattle/ | --X |
R-X |
--- |
--- |
Elenco | /Seattle/Portland/ | --X |
--X |
R-X |
--- |
Nota
Le autorizzazioni di scrittura per il file non sono necessarie per eliminarlo, purché le due condizioni precedenti siano vere.
Utenti e identità
Ogni file e cartella dispone di autorizzazioni distinte per queste identità:
- Utente proprietario
- Gruppo proprietario
- Utenti non anonimi
- Gruppi con nome
- Tutti gli altri utenti
Le identità di utenti e gruppi sono identità di Microsoft Entra. Pertanto, se non diversamente specificato, un "utente" nel contesto di Data Lake Storage Gen1 può significare un utente di Microsoft Entra o un gruppo di sicurezza Di Microsoft Entra.
Utente con privilegi avanzati
Un utente con privilegi avanzati ha i diritti più elevati di tutti gli utenti nell'account Data Lake Storage Gen1. Un utente con privilegi avanzati:
- Ha autorizzazioni RWX per tutti i file e le cartelle.
- Può modificare le autorizzazioni per qualsiasi file o cartella.
- Può modificare l'utente o il gruppo proprietario di qualsiasi file o cartella.
Tutti gli utenti che fanno parte del ruolo Proprietari per un account Data Lake Storage Gen1 diventano automaticamente super-utenti.
Utente proprietario
L'utente che ha creato l'elemento ne è automaticamente l'utente proprietario. Un utente proprietario può:
- Modificare le autorizzazioni di un file di sua proprietà.
- Modificare il gruppo proprietario di un file di sua proprietà, a condizione che l'utente proprietario sia anche membro del gruppo di destinazione.
Nota
L'utente proprietario non può modificare l'utente proprietario di un file o di una cartella. Solo gli utenti con privilegi avanzati possono modificare l'utente proprietario di un file o di una cartella.
Gruppo proprietario
Background
Negli ACL POSIX ogni utente è associato a un "gruppo primario". Ad esempio, l'utente "alice" potrebbe appartenere al gruppo "finance". Alice può anche appartenere a più gruppi, ma un gruppo è sempre designato come gruppo primario. Quando Alice crea un file in POSIX, come gruppo proprietario del file viene impostato il gruppo primario di Alice, in questo caso "finanza". Il gruppo proprietario si comporta in modo analogo alle autorizzazioni assegnate per altri utenti o gruppi.
Poiché non esiste alcun "gruppo primario" associato agli utenti in Data Lake Storage Gen1, il gruppo proprietario viene assegnato come indicato di seguito.
Assegnazione del gruppo proprietario per un nuovo file o una nuova cartella
- Caso 1: cartella radice "/". Questa cartella viene creata quando viene creato un account Data Lake Storage Gen1. In questo caso, il gruppo proprietario è impostato su un GUID tutto zerato. Questo valore non consente alcun accesso. È un segnaposto fino a quando non viene assegnato un gruppo.
- caso 2 (ogni altro caso): quando viene creato un nuovo elemento, il gruppo proprietario viene copiato dalla cartella padre.
Modifica del gruppo proprietario
Il gruppo proprietario può essere modificato da:
- Qualsiasi utente con privilegi avanzati.
- Utente proprietario, se è anche membro del gruppo di destinazione
Nota
Il gruppo proprietario non può modificare gli elenchi di controllo di accesso di un file o di una cartella.
Per gli account creati in data o prima di settembre 2018, il gruppo proprietario è stato impostato sull'utente che ha creato l'account nel caso della cartella radice per Caso 1precedente. Un singolo account utente non è valido per fornire autorizzazioni tramite il gruppo proprietario, pertanto non viene concessa alcuna autorizzazione da questa impostazione predefinita. È possibile assegnare questa autorizzazione a un gruppo di utenti valido.
Algoritmo di controllo di accesso
Lo pseudocodice seguente rappresenta l'algoritmo di controllo di accesso per gli account Data Lake Storage Gen1.
def access_check( user, desired_perms, path ) :
# access_check returns true if user has the desired permissions on the path, false otherwise
# user is the identity that wants to perform an operation on path
# desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
# path is the file or folder
# Note: the "sticky bit" is not illustrated in this algorithm
# Handle super users.
if (is_superuser(user)) :
return True
# Handle the owning user. Note that mask IS NOT used.
entry = get_acl_entry( path, OWNER )
if (user == entry.identity)
return ( (desired_perms & entry.permissions) == desired_perms )
# Handle the named users. Note that mask IS used.
entries = get_acl_entries( path, NAMED_USER )
for entry in entries:
if (user == entry.identity ) :
mask = get_mask( path )
return ( (desired_perms & entry.permmissions & mask) == desired_perms)
# Handle named groups and owning group
member_count = 0
perms = 0
entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
for entry in entries:
if (user_is_member_of_group(user, entry.identity)) :
member_count += 1
perms | = entry.permissions
if (member_count>0) :
return ((desired_perms & perms & mask ) == desired_perms)
# Handle other
perms = get_perms_for_other(path)
mask = get_mask( path )
return ( (desired_perms & perms & mask ) == desired_perms)
La maschera
Come illustrato nell'algoritmo di controllo di accesso, la maschera limita l'accesso per utenti nominati, il gruppo proprietario e gruppi nominati.
Nota
Per un nuovo account Data Lake Storage Gen1, per impostazione predefinita la maschera per l'ACL di accesso della cartella radice ("/") è RWX.
Il bit appiccicoso
Il bit sticky è una funzionalità più avanzata di un file system POSIX. Nel contesto di Data Lake Storage Gen1, è improbabile che sia necessario il bit permanente. In sintesi, se il bit sticky è abilitato in una cartella, un elemento figlio può essere eliminato o rinominato solo dall'utente proprietario dell'elemento figlio.
Il bit sticky non viene visualizzato nel portale di Azure.
Autorizzazioni predefinite per i nuovi file e cartelle
Quando viene creato un nuovo file o una nuova cartella in una cartella esistente, l'ACL predefinito nella cartella padre determina:
- ACL predefinito di una cartella figlio e ACL di accesso.
- ACL di accesso di un file figlio (i file non hanno un ACL predefinito).
umask
Quando si crea un file o una cartella, umask viene usato per modificare la modalità di impostazione degli ACL predefiniti nell'elemento figlio. umask è un valore a 9 bit nelle cartelle principali che definisce un valore RWX per utente proprietario, gruppo proprietarioe altri.
L'umask per Azure Data Lake Storage Gen1 è un valore fisso impostato su 007. Questo valore si traduce in
componente umask | Forma numerica | Forma breve | Significato |
---|---|---|---|
umask.owning_user | 0 | --- |
Per l'utente proprietario, copiare l'ACL predefinito dell'elemento padre nell'ACL di accesso dell'elemento figlio |
umask.owning_group | 0 | --- |
Per il gruppo proprietario, trasferire l'ACL predefinito del padre nell'ACL di accesso del figlio |
umask.other | 7 | RWX |
Per altri, rimuovere tutte le autorizzazioni sull'ACL di accesso del figlio |
Il valore umask usato da Azure Data Lake Storage Gen1 implica effettivamente che il valore per 'altri' non viene mai trasmesso per impostazione predefinita nei nuovi sottoelementi, indipendentemente da ciò che indica l'ACL predefinito.
Il seguente pseudocodice mostra come viene applicato l'umask quando si creano le ACL per un elemento figlio.
def set_default_acls_for_new_child(parent, child):
child.acls = []
for entry in parent.acls :
new_entry = None
if (entry.type == OWNING_USER) :
new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
elif (entry.type == OWNING_GROUP) :
new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
elif (entry.type == OTHER) :
new_entry = entry.clone(perms = entry.perms & (~umask.other))
else :
new_entry = entry.clone(perms = entry.perms )
child_acls.add( new_entry )
Domande comuni sugli ACL in Data Lake Storage Gen1
È necessario abilitare il supporto per gli ACL?
No. Il controllo di accesso tramite ACL è sempre attivo per un account Data Lake Storage Gen1.
Quali autorizzazioni sono necessarie per eliminare in modo ricorsivo una cartella e il relativo contenuto?
- La cartella padre deve disporre delle autorizzazioni di Write + Execute.
- La cartella da eliminare e ogni cartella al suo interno richiede autorizzazioni di Lettura + Scrittura + Esecuzione.
Nota
Non sono necessarie autorizzazioni di scrittura per eliminare i file nelle cartelle. Inoltre, la cartella radice "/" può mai essere eliminata.
Chi è il proprietario di un file o di una cartella?
L'autore di un file o di una cartella diventa il proprietario.
Quale gruppo viene impostato come gruppo proprietario di un file o di una cartella al momento della creazione?
Il gruppo proprietario viene copiato dal gruppo proprietario della cartella padre in cui viene creato il nuovo file o la nuova cartella.
Io sono l'utente proprietario di un file, ma non ho le autorizzazioni RWX necessarie. Cosa faccio?
L'utente proprietario può modificare le autorizzazioni del file in modo da assegnarsi tutte le autorizzazioni RWX necessarie.
Quando si esaminano gli elenchi di controllo di accesso nel portale di Azure vengono visualizzati i nomi utente, ma tramite le API vengono visualizzati i GUID, perché?
Le voci negli elenchi di controllo di accesso vengono archiviate come GUID che corrispondono agli utenti in Microsoft Entra ID. Le API restituiscono i GUID così come sono. Il portale di Azure tenta di semplificare l'uso degli ACL convertendo i GUID in nomi descrittivi, quando possibile.
Perché a volte vengono visualizzati i GUID negli elenchi di controllo di accesso quando si usa il portale di Azure?
Un GUID viene visualizzato quando l'utente non esiste più in Microsoft Entra. In genere ciò si verifica se l'utente non fa più parte dell'azienda o l'account è stato eliminato in Microsoft Entra ID. Assicurarsi inoltre di usare l'ID corretto per l'impostazione degli elenchi di controllo di accesso (dettagli in questione di seguito).
Quando si usa il service principal, quale ID è necessario usare per impostare gli ACL?
Nel portale di Azure, vai a Microsoft Entra ID -> Applicazioni aziendali e seleziona l'applicazione. La scheda Panoramica deve visualizzare un ID oggetto e questo è ciò che deve essere usato quando si aggiungono ACL per l'accesso ai dati (e non ID applicazione).
Data Lake Storage Gen1 supporta l'ereditarietà degli ACL?
No, ma gli ACL predefiniti possono essere usati per impostare gli ACL per i file e le cartelle figli appena creati sotto la cartella padre.
Quali sono i limiti per le voci ACL nei file e nelle cartelle?
32 ACL possono essere impostati per ogni 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. Se possibile, usare i gruppi di sicurezza per le assegnazioni ACL. Usando i gruppi, è meno probabile che superi il numero massimo di voci ACL per file o directory.
Dove è possibile reperire altre informazioni sul modello di controllo di accesso POSIX?
- POSIX Access Control Lists on Linux (Elenchi di controllo di accesso POSIX in Linux)
- HDFS Permission Guide (Guida alle autorizzazioni HDFS)
- Domande frequenti su POSIX
- POSIX 1003.1 2008
- POSIX 1003.1 2013
- POSIX 1003.1 2016
- ACL POSIX su Ubuntu