Controllo di accesso in Azure Data Lake Storage Gen2Access control in Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 implementa un modello di controllo di accesso che supporta il controllo degli accessi in base al ruolo di Azure (RBAC) e gli elenchi di controllo di accesso (ACL) di tipo POSIX.Azure Data Lake Storage Gen2 implements an access control model that supports both Azure role-based access control (RBAC) and POSIX-like access control lists (ACLs). Questo articolo offre un riepilogo delle nozioni di base del modello di controllo di accesso per Data Lake Storage Gen2.This article summarizes the basics of the access control model for Data Lake Storage Gen2.

Controllo degli accessi in base al ruoloRole-based access control

RBAC usa le assegnazioni di ruolo per applicare in modo efficace i set di autorizzazioni alle entità di sicurezza.RBAC uses role assignments to effectively apply sets of permissions to security principals. Un' entità di sicurezza è un oggetto che rappresenta un utente, un gruppo, un'entità servizio o un'identità gestita definita in Azure Active Directory (ad) che richiede l'accesso alle risorse di Azure.A security principal is an object that represents a user, group, service principal, or managed identity that is defined in Azure Active Directory (AD) that is requesting access to Azure resources.

In genere, le risorse di Azure sono vincolate alle risorse di primo livello, ad esempio: Account di archiviazione di Azure).Typically, those Azure resources are constrained to top-level resources (For example: Azure Storage accounts). Nel caso di archiviazione di Azure e di conseguenza Azure Data Lake Storage Gen2 questo meccanismo è stato esteso alla risorsa contenitore (file system).In the case of Azure Storage, and consequently Azure Data Lake Storage Gen2, this mechanism has been extended to the container (file system) resource.

Per informazioni su come assegnare i ruoli alle entità di sicurezza nell'ambito dell'account di archiviazione, vedere concedere l'accesso ai dati di Accodamento e BLOB di Azure con RBAC nel portale di Azure.To learn how to assign roles to security principals in the scope of your storage account, see Grant access to Azure blob and queue data with RBAC in the Azure portal.

L'effetto delle assegnazioni di ruolo negli elenchi di controllo di accesso a livello di file e directoryThe impact of role assignments on file and directory level access control lists

Quando si utilizzano assegnazioni di ruolo RBAC è un meccanismo potente per controllare le autorizzazioni di accesso, si tratta di un meccanismo con granularità grossolana rispetto agli ACL.While using RBAC role assignments is a powerful mechanism to control access permissions, it is a very coarsely grained mechanism relative to ACLs. La granularità minima per il controllo degli accessi in base al ruolo è a livello di contenitore e verrà valutata con una priorità più alta rispetto agli ACL.The smallest granularity for RBAC is at the container level and this will be evaluated at a higher priority than ACLs. Se pertanto si assegna un ruolo a un'entità di sicurezza nell'ambito di un contenitore, l'entità di sicurezza dispone del livello di autorizzazione associato a tale ruolo per tutte le directory e i file in tale contenitore, indipendentemente dalle assegnazioni ACL.Therefore, if you assign a role to a security principal in the scope of a container, that security principal has the authorization level associated with that role for ALL directories and files in that container, regardless of ACL assignments.

Quando a un'entità di sicurezza vengono concesse le autorizzazioni per i dati RBAC tramite un ruolo predefinitoo tramite un ruolo personalizzato, queste autorizzazioni vengono valutate per prime all'autorizzazione di una richiesta.When a security principal is granted RBAC data permissions through a built-in role, or through a custom role, these permissions are evaluated first upon authorization of a request. Se l'operazione richiesta è autorizzata dalle assegnazioni RBAC dell'entità di sicurezza, l'autorizzazione viene immediatamente risolta e non vengono eseguiti controlli ACL aggiuntivi.If the requested operation is authorized by the security principal's RBAC assignments then authorization is immediately resolved and no additional ACL checks are performed. In alternativa, se l'entità di sicurezza non dispone di un'assegnazione RBAC o se l'operazione della richiesta non corrisponde all'autorizzazione assegnata, vengono eseguiti i controlli ACL per determinare se l'entità di sicurezza è autorizzata a eseguire l'operazione richiesta.Alternatively, if the security principal does not have an RBAC assignment, or the request's operation does not match the assigned permission, then ACL checks are performed to determine if the security principal is authorized to perform the requested operation.

Nota

Se all'entità di sicurezza è stata assegnata l'assegnazione di ruolo predefinita del proprietario dei dati del BLOB di archiviazione, l'entità di sicurezza viene considerata un utente con privilegi avanzati e viene concesso l'accesso completo a tutte le operazioni di mutazione, inclusa l'impostazione del proprietario di una directory o file e ACL per le directory e i file di cui non sono proprietari.If the security principal has been assigned the Storage Blob Data Owner built-in role assignment, then the security principal is considered a super-user and is granted full access to all mutating operations, including setting the owner of a directory or file as well as ACLs for directories and files for which they are not the owner. L'accesso utente con privilegi avanzati è il solo modo autorizzato di cambiare il proprietario di una risorsa.Super-user access is the only authorized manner to change the owner of a resource.

Autenticazione con chiave condivisa e firma di accesso condiviso (SAS)Shared Key and Shared Access Signature (SAS) authentication

Azure Data Lake Storage Gen2 supporta la chiave condivisa e i metodi SAS per l'autenticazione.Azure Data Lake Storage Gen2 supports Shared Key and SAS methods for authentication. Una caratteristica di questi metodi di autenticazione è che nessuna identità è associata al chiamante e pertanto non è possibile eseguire l'autorizzazione basata sull'autorizzazione dell'entità di sicurezza.A characteristic of these authentication methods is that no identity is associated with the caller and therefore security principal permission-based authorization cannot be performed.

Nel caso della chiave condivisa, il chiamante ottiene di fatto l'accesso "utente con privilegi avanzati", vale a dire l'accesso completo a tutte le operazioni su tutte le risorse, inclusa l'impostazione del proprietario e la modifica degli elenchi di controllo di accesso.In the case of Shared Key, the caller effectively gains ‘super-user’ access, meaning full access to all operations on all resources, including setting owner and changing ACLs.

I token di firma di accesso condiviso includono le autorizzazioni consentite come parte del token.SAS tokens include allowed permissions as part of the 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.The permissions included in the SAS token are effectively applied to all authorization decisions, but no additional ACL checks are performed.

Elenchi di controllo di accesso per file e directoryAccess control lists on files and directories

È possibile associare un'entità di sicurezza a un livello di accesso per file e directory.You can associate a security principal with an access level for files and directories. Queste associazioni vengono acquisite in un elenco di controllo di accesso (ACL) .These associations are captured in an access control list (ACL). Ogni file e directory nell'account di archiviazione dispone di un elenco di controllo di accesso.Each file and directory in your storage account has an access control list.

Se è stato assegnato un ruolo a un'entità di sicurezza a livello di account di archiviazione, è possibile usare gli elenchi di controllo di accesso per concedere a tale entità di sicurezza l'accesso con privilegi elevati a file e directory specifici.If you assigned a role to a security principal at the storage account-level, you can use access control lists to grant that security principal elevated access to specific files and directories.

Non è possibile usare gli elenchi di controllo di accesso per fornire un livello di accesso inferiore rispetto a un livello concesso da un'assegnazione di ruolo.You can't use access control lists to provide a level of access that is lower than a level granted by a role assignment. Ad esempio, se si assegna il ruolo di collaboratore dati BLOB di archiviazione a un'entità di sicurezza, non è possibile usare gli elenchi di controllo di accesso per impedire che l'entità di sicurezza scriva in una directory.For example, if you assign the Storage Blob Data Contributor role to a security principal, then you can't use access control lists to prevent that security principal from writing to a directory.

Impostare le autorizzazioni a livello di file e directory usando gli elenchi di controllo di accessoSet file and directory level permissions by using access control lists

Per impostare le autorizzazioni a livello di file e directory, vedere gli articoli seguenti:To set file and directory level permissions, see any of the following articles:

Se si desidera utilizzare questo strumento:If you want to use this tool: Vedere questo articolo:See this article:
Esplora archivi AzureAzure Storage Explorer Impostare autorizzazioni a livello di file e directory usando Azure Storage Explorer con Azure Data Lake Storage Gen2Set file and directory level permissions using Azure Storage Explorer with Azure Data Lake Storage Gen2
API RESTREST API Percorso-aggiornamentoPath - Update

Importante

Se l'entità di sicurezza è un'entità servizio , è importante usare l'ID oggetto dell'entità servizio e non l'ID oggetto della registrazione dell'app correlata.If the security principal is a service principal, it's important to use the object ID of the service principal and not the object ID of the related app registration. Per ottenere l'ID oggetto dell'entità servizio, aprire l'interfaccia della riga di comando di Azure, quindi az ad sp show --id <Your App ID> --query objectIdusare il comando seguente:.To get the object ID of the service principal open the Azure CLI, and then use this command: az ad sp show --id <Your App ID> --query objectId. Assicurarsi di sostituire il <Your App ID> segnaposto con l'ID app della registrazione dell'app.make sure to replace the <Your App ID> placeholder with the App ID of your app registration.

Tipi di elenchi di controllo di accessoTypes of access control lists

Esistono due tipi di elenchi di controllo di accesso: ACL di accesso e ACL predefiniti.There are two kinds of access control lists: access ACLs and default ACLs.

gli elenchi ACL di accesso controllano l'accesso a un oggetto.Access ACLs control access to an object. Sia i file che le directory hanno ACL di accesso.Files and directories both have access ACLs.

Gli ACL predefiniti sono modelli di ACL associati a una directory che determina gli ACL di accesso per tutti gli elementi figlio creati in tale directory.Default ACLs are templates of ACLs associated with a directory that determine the access ACLs for any child items that are created under that directory. I file non hanno ACL predefiniti.Files do not have default ACLs.

Sia gli ACL di accesso che gli ACL predefiniti presentano la stessa struttura.Both access ACLs and default ACLs have the same structure.

Nota

La modifica dell'ACL predefinito per un elemento padre non influisce sull'ACL di accesso o sull'ACL predefinito degli elementi figlio già esistenti.Changing the default ACL on a parent does not affect the access ACL or default ACL of child items that already exist.

Livelli di autorizzazioneLevels of permission

Le autorizzazioni per un oggetto contenitore sono di lettura, scritturaed esecuzionee possono essere usate nei file e nelle directory, come illustrato nella tabella seguente:The permissions on a container object are Read, Write, and Execute, and they can be used on files and directories as shown in the following table:

FileFile DirectoryDirectory
Lettura (R)Read (R) È possibile leggere il contenuto di un fileCan read the contents of a file Per elencare il contenuto della directory, sono necessarie le autorizzazioni di Lettura ed EsecuzioneRequires Read and Execute to list the contents of the directory
Scrittura (W)Write (W) È possibile scrivere o aggiungere in un fileCan write or append to a file Per creare elementi figlio in una directory, sono necessarie le autorizzazioni di Scrittura ed EsecuzioneRequires Write and Execute to create child items in a directory
Esecuzione (X)Execute (X) Nessun valore nel contesto di Data Lake Storage Gen2Does not mean anything in the context of Data Lake Storage Gen2 È necessaria per attraversare gli elementi figlio di una directoryRequired to traverse the child items of a directory

Nota

Se si concedono le autorizzazioni usando solo ACL (nessun controllo degli accessi in base al ruolo), per concedere a un'entità servizio l'accesso in lettura o scrittura a un file, è necessario concedere all'entità servizio le autorizzazioni di esecuzione per il contenitore e a ogni cartella nella gerarchia di cartelle che condurre al file.If you are granting permissions by using only ACLs (no RBAC), then to grant a service principal read or write access to a file, you'll need to give the service principal Execute permissions to the container, and to each folder in the hierarchy of folders that lead to the file.

Forme brevi per le autorizzazioniShort forms for permissions

La forma RWX viene usata per indicare Lettura + Scrittura + Esecuzione.RWX is used to indicate Read + Write + Execute. Esiste una forma numerica ridotta in cui Lettura=4, Scrittura=2 ed Esecuzione=1 e la cui somma rappresenta le autorizzazioni.A more condensed numeric form exists in which Read=4, Write=2, and Execute=1, the sum of which represents the permissions. Di seguito sono riportati alcuni esempi.Following are some examples.

Forma numericaNumeric form Forma breveShort form SignificatoWhat it means
77 RWX Lettura + Scrittura + EsecuzioneRead + Write + Execute
55 R-X Lettura + EsecuzioneRead + Execute
44 R-- LetturaRead
00 --- Nessuna autorizzazioneNo permissions

Ereditarietà delle autorizzazioniPermissions inheritance

Nel modello di tipo POSIX usato da Data Lake Storage Gen2, le autorizzazioni per un elemento vengono archiviate nell'elemento stesso.In the POSIX-style model that's used by Data Lake Storage Gen2, permissions for an item are stored on the item itself. In altre parole, le autorizzazioni per un elemento non possono essere ereditate dagli elementi padre se le autorizzazioni vengono impostate dopo che l'elemento figlio è già stato creato.In other words, permissions for an item cannot be inherited from the parent items if the permissions are set after the child item has already been created. Le autorizzazioni vengono ereditate solo se le autorizzazioni predefinite sono state impostate per gli elementi padre prima che gli elementi figlio siano stati creati.Permissions are only inherited if default permissions have been set on the parent items before the child items have been created.

La tabella seguente elenca alcuni scenari comuni che consentono di comprendere quali autorizzazioni sono necessarie per eseguire determinate operazioni su un account di archiviazione.The following table lists some common scenarios to help you understand which permissions are needed to perform certain operations on a storage account.

OperazioneOperation / Oregon/Oregon/ Portland/Portland/ Data.txtData.txt
Read Data.txtRead Data.txt --X --X --X R--
Append to Data.txtAppend to Data.txt --X --X --X RW-
Delete Data.txtDelete Data.txt --X --X -WX ---
Create Data.txtCreate Data.txt --X --X -WX ---
Elenco /List / R-X --- --- ---
Elencare /Oregon/List /Oregon/ --X R-X --- ---
Elencare /Oregon/Portland/List /Oregon/Portland/ --X --X R-X ---

Nota

Purché vengano soddisfatte le due condizioni precedenti, non sono necessarie autorizzazioni di scrittura per il file per eliminarlo.Write permissions on the file are not required to delete it, so long as the previous two conditions are true.

Utenti e identitàUsers and identities

Ogni file e directory ha autorizzazioni distinte per le entità seguenti:Every file and directory has distinct permissions for these identities:

  • Utente proprietarioThe owning user
  • Gruppo proprietarioThe owning group
  • Utenti non anonimiNamed users
  • Gruppi con nomeNamed groups
  • Entità servizio denominateNamed service principals
  • Identità gestite denominateNamed managed identities
  • Tutti gli altri utentiAll other users

Le identità di utenti e gruppi sono identità di Azure Active Directory (Azure AD).The identities of users and groups are Azure Active Directory (Azure AD) identities. Se non diversamente specificato, un utente, nel contesto di data Lake storage Gen2, può fare riferimento a un utente Azure ad, a un'entità servizio, a un'identità gestita o a un gruppo di sicurezza.So unless otherwise noted, a user, in the context of Data Lake Storage Gen2, can refer to an Azure AD user, service principal, managed identity, or security group.

Utente proprietarioThe owning user

L'utente che ha creato l'elemento ne è automaticamente l'utente proprietario.The user who created the item is automatically the owning user of the item. Un utente proprietario può:An owning user can:

  • Modificare le autorizzazioni di un file di sua proprietà.Change the permissions of a file that is owned.
  • Modificare il gruppo proprietario di un file di sua proprietà, a condizione che l'utente proprietario sia anche membro del gruppo di destinazione.Change the owning group of a file that is owned, as long as the owning user is also a member of the target group.

Nota

L'utente proprietario non può modificare l'utente proprietario di un file o di una directory.The owning user cannot change the owning user of a file or directory. Solo gli utenti con privilegi avanzati possono modificare l'utente proprietario di un file o una directory.Only super-users can change the owning user of a file or directory.

Gruppo proprietarioThe owning group

Negli ACL POSIX ogni utente è associato a un gruppo primario.In the POSIX ACLs, every user is associated with a primary group. È ad esempio possibile che l'utente "Alice" appartenga al gruppo "Finance".For example, user "Alice" might belong to the "finance" group. Alice potrebbe anche appartenere a più gruppi, ma un gruppo viene sempre designato come gruppo primario.Alice might also belong to multiple groups, but one group is always designated as their primary group. Quando Alice crea un file in POSIX, come gruppo proprietario del file viene impostato il gruppo primario di Alice, in questo caso "finanza".In POSIX, when Alice creates a file, the owning group of that file is set to her primary group, which in this case is "finance." Il gruppo proprietario si comporta in modo analogo alle autorizzazioni assegnate per altri utenti o gruppi.The owning group otherwise behaves similarly to assigned permissions for other users/groups.

Assegnazione del gruppo proprietario per un nuovo file o directoryAssigning the owning group for a new file or directory
  • Caso 1: directory radice "/".Case 1: The root directory "/". Questa directory viene creata quando viene creato un contenitore Data Lake Storage Gen2.This directory is created when a Data Lake Storage Gen2 container is created. In questo caso, il gruppo proprietario viene impostato sull'utente che ha creato il contenitore se è stato eseguito tramite OAuth.In this case, the owning group is set to the user who created the container if it was done using OAuth. Se il contenitore viene creato usando una chiave condivisa, una firma di accesso condiviso dell'account o una firma di accesso condiviso del servizio, il proprietario e il gruppo proprietario sono impostati su $superuser.If the container is created using Shared Key, an Account SAS, or a Service SAS, then the owner and owning group are set to $superuser.
  • Caso 2 (qualsiasi altro caso): quando viene creato un nuovo elemento, il gruppo proprietario viene copiato dalla directory padre.Case 2 (Every other case): When a new item is created, the owning group is copied from the parent directory.
Modifica del gruppo proprietarioChanging the owning group

Il gruppo proprietario può essere modificato da:The owning group can be changed by:

  • Qualsiasi utente con privilegi avanzati.Any super-users.
  • Utente proprietario, se è anche membro del gruppo di destinazioneThe owning user, if the owning user is also a member of the target group.

Nota

Il gruppo proprietario non può modificare gli ACL di un file o di una directory.The owning group cannot change the ACLs of a file or directory. Mentre il gruppo proprietario è impostato sull'utente che ha creato l'account nel caso della directory radice, caso 1 precedente, un singolo account utente non è valido per fornire le autorizzazioni tramite il gruppo proprietario.While the owning group is set to the user who created the account in the case of the root directory, Case 1 above, a single user account isn't valid for providing permissions via the owning group. È possibile assegnare questa autorizzazione a un gruppo utenti valido, se applicabile.You can assign this permission to a valid user group if applicable.

Algoritmo di controllo dell'accessoAccess check algorithm

Lo pseudocodice seguente rappresenta l'algoritmo di controllo dell'accesso per gli account di archiviazione.The following pseudocode represents the access check algorithm for storage accounts.

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 directory
  # Note: the "sticky bit" isn't illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

# Handle the owning user. Note that mask isn't 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.permissions & 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 mascheraThe mask

Come illustrato nell'algoritmo di controllo dell'accesso, la maschera limita l'accesso agli utenti non anonimi, al gruppo proprietario e ai gruppi non anonimi.As illustrated in the Access Check Algorithm, the mask limits access for named users, the owning group, and named groups.

Nota

Per un nuovo contenitore di Data Lake Storage Gen2, la maschera per l'ACL di accesso della directory radice ("/") viene impostata per impostazione predefinita su 750 per le directory e 640 per i file.For a new Data Lake Storage Gen2 container, the mask for the access ACL of the root directory ("/") defaults to 750 for directories and 640 for files. File non ricevono il bit X perché è irrilevante per i file in un sistema solo di archiviazione.Files do not receive the X bit as it is irrelevant to files in a store-only system.

La maschera può essere specificata in base alle singole chiamate.The mask may be specified on a per-call basis. In questo modo sistemi diversi con un elevato utilizzo di risorse, ad esempio i cluster, possono avere maschere effettive diverse per le operazioni su file.This allows different consuming systems, such as clusters, to have different effective masks for their file operations. Se una maschera viene specificata per una determinata richiesta, esegue l'override completo della maschera predefinita.If a mask is specified on a given request, it completely overrides the default mask.

Sticky bitThe sticky bit

Il bit appiccicoso è una funzionalità più avanzata di un contenitore POSIX.The sticky bit is a more advanced feature of a POSIX container. Nel contesto di Data Lake Storage Gen2, è improbabile che lo sticky bit sia necessario.In the context of Data Lake Storage Gen2, it is unlikely that the sticky bit will be needed. In breve, se lo sticky bit è abilitato in una directory, un elemento figlio può essere solo eliminato o rinominato dall'utente proprietario dell'elemento figlio.In summary, if the sticky bit is enabled on a directory, a child item can only be deleted or renamed by the child item's owning user.

Il bit appiccicoso non viene visualizzato nella portale di Azure.The sticky bit isn't shown in the Azure portal.

Autorizzazioni predefinite per nuovi file e directoryDefault permissions on new files and directories

Quando si crea un nuovo file o una nuova directory in una directory esistente, l'ACL predefinito per la directory padre determina quanto segue:When a new file or directory is created under an existing directory, the default ACL on the parent directory determines:

  • ACL predefinito e ACL di accesso di una directory figlio.A child directory’s default ACL and access ACL.
  • ACL di accesso di un file figlio (i file non hanno un ACL predefinito).A child file's access ACL (files do not have a default ACL).

umaskumask

Quando si crea un file o una directory, la proprietà umask viene usata per modificare la modalità in cui gli ACL predefiniti vengono impostati sull'elemento figlio.When creating a file or directory, umask is used to modify how the default ACLs are set on the child item. La proprietà umask è un valore a 9 bit sulle directory padre, che contiene un valore RWX per l'utente proprietario, il gruppo proprietario e altri.umask is a 9-bit value on parent directories that contains an RWX value for owning user, owning group, and other.

La proprietà umask per Azure Data Lake Storage Gen2 è un valore costante impostato su 007.The umask for Azure Data Lake Storage Gen2 a constant value that is set to 007. Questo valore viene convertito in:This value translates to:

componente umaskumask component Forma numericaNumeric form Forma breveShort form SignificatoMeaning
umask.owning_userumask.owning_user 00 --- Per l'utente proprietario, copiare l'ACL predefinito dell'elemento padre nell'ACL di accesso dell'elemento figlioFor owning user, copy the parent's default ACL to the child's access ACL
umask.owning_groupumask.owning_group 00 --- Per il gruppo proprietario, copiare l'ACL predefinito dell'elemento padre nell'ACL di accesso dell'elemento figlioFor owning group, copy the parent's default ACL to the child's access ACL
umask.otherumask.other 77 RWX Per altri, rimuovere tutte le autorizzazioni sull'ACL di accesso dell'elemento figlioFor other, remove all permissions on the child's access ACL

Il valore umask usato da Azure Data Lake Storage Gen2 significa di fatto che il valore per other non viene mai trasmesso per impostazione predefinita sui nuovi elementi figlio, indipendentemente da ciò che indica l'ACL predefinito.The umask value used by Azure Data Lake Storage Gen2 effectively means that the value for other is never transmitted by default on new children, regardless of what the default ACL indicates.

Lo pseudocodice seguente illustra come viene applicata la proprietà umask quando si creano gli ACL per un elemento figlio.The following pseudocode shows how the umask is applied when creating the ACLs for a child item.

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 frequenti sugli elenchi di controllo di accesso in Data Lake Storage Gen2Common questions about ACLs in Data Lake Storage Gen2

È necessario abilitare il supporto per gli ACL?Do I have to enable support for ACLs?

No.No. Il controllo di accesso tramite ACL è abilitato per un account di archiviazione, purché sia attivata la funzionalità di spazio dei nomi gerarchico (HNS).Access control via ACLs is enabled for a storage account as long as the Hierarchical Namespace (HNS) feature is turned ON.

Se lo spazio dei nomi gerarchico è disattivato, vengono applicate le regole di autorizzazione del controllo degli accessi in base al ruolo Azure.If HNS is turned OFF, the Azure RBAC authorization rules still apply.

Qual è il modo migliore per applicare gli elenchi di controllo di accesso?What is the best way to apply ACLs?

Usare sempre i gruppi di sicurezza di Azure AD come entità assegnate negli elenchi di controllo di accesso.Always use Azure AD security groups as the assigned principal in ACLs. Evitare di assegnare direttamente singoli utenti o entità servizio.Resist the opportunity to directly assign individual users or service principals. 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.Using this structure will allow you to add and remove users or service principals without the need to reapply ACLs to an entire directory structure. È invece sufficiente aggiungerli o rimuoverli dal gruppo di sicurezza di Azure AD appropriato.) Instead, you simply need to add or remove them from the appropriate Azure AD security group. Tenere presente che gli elenchi di controllo di accesso non vengono ereditati e quindi per riapplicare gli elenchi di controllo di accesso, è necessario aggiornare l'elenco di controllo di accesso in ogni file e sottodirectory.Keep in mind that ACLs are not inherited and so reapplying ACLs requires updating the ACL on every file and subdirectory.

Quali autorizzazioni sono necessarie per eliminare in modo ricorsivo una directory e il relativo contenuto?Which permissions are required to recursively delete a directory and its contents?

  • Il chiamante ha le autorizzazioni di "utente con privilegi avanzati"The caller has ‘super-user’ permissions,

OppureOr

  • Sono necessarie autorizzazioni di Scrittura + Esecuzione per la directory padre.The parent directory must have Write + Execute permissions.
  • Sono necessarie autorizzazioni di Lettura + Scrittura + Esecuzione per la directory da eliminare e per ogni directory al suo interno.The directory to be deleted, and every directory within it, requires Read + Write + Execute permissions.

Nota

Non sono necessarie autorizzazioni di Scrittura per eliminare i file nelle directory.You do not need Write permissions to delete files in directories. La directory radice "/" non può mai essere eliminata.Also, the root directory "/" can never be deleted.

Chi è il proprietario di un file o una directory?Who is the owner of a file or directory?

Il creatore di un file o una directory ne diventa il proprietario.The creator of a file or directory becomes the owner. Nel caso della directory radice, si tratta dell'identità dell'utente che ha creato il contenitore.In the case of the root directory, this is the identity of the user who created the container.

Quale gruppo viene impostato come gruppo proprietario di un file o una directory al momento della creazione?Which group is set as the owning group of a file or directory at creation?

Il gruppo proprietario viene copiato da quello della directory padre in cui si crea il nuovo file o la nuova directory.The owning group is copied from the owning group of the parent directory under which the new file or directory is created.

Se l'utente proprietario di un file non ha le autorizzazioni RWX di cui ha bisogno,I am the owning user of a file but I don’t have the RWX permissions I need. Cosa devo fare?What do I do?

L'utente proprietario può modificare le autorizzazioni del file in modo da assegnarsi tutte le autorizzazioni RWX necessarie.The owning user can change the permissions of the file to give themselves any RWX permissions they need.

Perché in alcuni casi vengono visualizzati GUID negli elenchi di controllo di accesso?Why do I sometimes see GUIDs in ACLs?

Viene visualizzato un GUID se la voce rappresenta un utente e tale utente non esiste più in Azure AD.A GUID is shown if the entry represents a user and that user doesn't exist in Azure AD anymore. In genere ciò si verifica se l'utente non fa più parte dell'azienda o l'account è stato eliminato in Azure AD.Usually this happens when the user has left the company or if their account has been deleted in Azure AD. Inoltre, le entità servizio e i gruppi di sicurezza non hanno un nome dell'entità utente (UPN) per identificarli e vengono quindi rappresentati dall'attributo OID (un GUID).Additionally, service principals and security groups do not have a User Principal Name (UPN) to identify them and so they are represented by their OID attribute (a guid).

Ricerca per categorie impostare gli ACL correttamente per un'entità servizio?How do I set ACLs correctly for a service principal?

Quando si definiscono gli ACL per le entità servizio, è importante usare l'ID oggetto (OID) dell' entità servizio per la registrazione dell'app creata.When you define ACLs for service principals, it's important to use the Object ID (OID) of the service principal for the app registration that you created. È importante notare che le app registrate hanno un'entità servizio separata nel tenant di Azure AD specifico.It's important to note that registered apps have a separate service principal in the specific Azure AD tenant. Le app registrate hanno un OID visibile nel portale di Azure, ma l' entità servizio presenta un altro OID (diverso).Registered apps have an OID that's visible in the Azure portal, but the service principal has another (different) OID.

Per ottenere l'OID per l'entità servizio che corrisponde alla registrazione di un'app, è possibile usare az ad sp show il comando.To get the OID for the service principal that corresponds to an app registration, you can use the az ad sp show command. Specificare l'ID applicazione come parametro.Specify the Application ID as the parameter. Di seguito è riportato un esempio su come ottenere l'OID per l'entità servizio che corrisponde a una registrazione dell'app con ID app = 18218b12-1895-43E9-AD80-6e8fc1ea88ce.Here's an example on obtaining the OID for the service principal that corresponds to an app registration with App ID = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Eseguire il comando seguente nell'interfaccia della riga di comando di Azure:Run the following command in the Azure CLI:

$ az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId
<<OID will be displayed>>

Quando si dispone dell'OID corretto per l'entità servizio, passare alla pagina Storage Explorer Gestisci accesso per aggiungere l'OID e assegnare le autorizzazioni appropriate per l'OID.When you have the correct OID for the service principal, go to the Storage Explorer Manage Access page to add the OID and assign appropriate permissions for the OID. Assicurarsi di selezionare Salva.Make sure you select Save.

Data Lake Storage Gen2 supporta l'ereditarietà degli elenchi di controllo di accesso?Does Data Lake Storage Gen2 support inheritance of ACLs?

Le assegnazioni con controllo degli accessi in base al ruolo di Azure ereditano.Azure RBAC assignments do inherit. Le assegnazioni scorrono dalle risorse di sottoscrizione, gruppo di risorse e account di archiviazione fino alla risorsa contenitore.Assignments flow from subscription, resource group, and storage account resources down to the container resource.

Gli elenchi di controllo di accesso non ereditano.ACLs do not inherit. Gli ACL predefiniti tuttavia possono essere usati per impostare gli ACL per le sottodirectory e i file creati nella directory padre.However, default ACLs can be used to set ACLs for child subdirectories and files created under the parent directory.

Dove è possibile reperire altre informazioni sul modello di controllo di accesso POSIX?Where can I learn more about POSIX access control model?

Vedere ancheSee also