Elenchi di controllo di accesso (ACL) in Azure Data Lake Storage

Azure Data Lake Storage implementa un modello di controllo di accesso che supporta sia il controllo degli accessi in base al ruolo di Azure che gli elenchi di controllo di accesso (ACL) di tipo POSIX. Questo articolo descrive gli elenchi di controllo di accesso in Data Lake Storage. Per informazioni su come incorporare il Controllo degli accessi in base al ruolo di Azure insieme agli elenchi di controllo di accesso e su come il sistema li valuta per prendere decisioni di autorizzazione, vedere Modello di controllo di accesso in Azure Data Lake Storage.

Informazioni sugli elenchi di controllo di accesso

È possibile associare un'entità di sicurezza a un livello di accesso per file e directory. Ogni associazione viene acquisita come voce in un elenco di controllo di accesso (ACL). Per ogni file e directory nell'account di archiviazione è presente un elenco di controllo di accesso. Quando un'entità di sicurezza tenta un'operazione su un file o una directory, un controllo dell'elenco di controllo di accesso determina se l'entità di sicurezza (utente, gruppo, entità servizio o identità gestita) ha il livello di autorizzazione corretto per eseguire l'operazione.

Come impostare gli elenchi di controllo di accesso

Per configurare le autorizzazioni a livello di file e directory, consultare uno dei seguenti articoli:

Tipi di ACL

Esistono due tipologie di elenchi di controllo di accesso: ACL di accesso e ACL predefiniti.

gli elenchi ACL di accesso controllano l'accesso a un oggetto. Sia i file che le directory hanno ACL di accesso.

Gli ACL predefiniti sono modelli di ACL associati a una directory che determinano gli ACL di accesso per tutti gli elementi figlio creati in tale directory. I file non hanno ACL predefiniti.

Sia gli ACL di accesso che gli ACL predefiniti presentano la stessa struttura.

Livelli di autorizzazione

Le autorizzazioni per directory e file in un contenitore sono Lettura, Scritturae Esecuzione, e possono essere usate su file e directory, come illustrato nella tabella seguente:

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.

Ereditarietà delle autorizzazioni

Nel modello di tipo POSIX usato da Data Lake Storage, 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 se le autorizzazioni vengono impostate dopo che l'elemento figlio è già stato creato. Le autorizzazioni vengono ereditate solo se le autorizzazioni predefinite sono state impostate per gli elementi padre prima che gli elementi figlio siano stati creati.

Scenari comuni correlati alle autorizzazioni ACL

La tabella seguente mostra le voci ACL necessarie per consentire a un'entità di sicurezza di 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.

Eliminazione di file e directory

Come illustrato nella tabella precedente, le autorizzazioni di scrittura per il file non sono necessarie per eliminarle, purché le autorizzazioni della directory siano impostate correttamente. Tuttavia, per eliminare una directory e tutto il relativo contenuto, la directory padre deve disporre delle autorizzazioni Write + Execute. Sono necessarie autorizzazioni di Lettura + Scrittura + Esecuzione per la directory da eliminare e per ogni directory al suo interno.

Utenti e identità

Ogni file e directory ha autorizzazioni distinte per le entità seguenti:

• Utente proprietario
• Gruppo proprietario
• Utenti non anonimi
• Gruppi con nome
• Entità servizio denominate
• Identità gestite denominate
• 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, può fare riferimento a un utente, un'entità servizio, un'identità gestita 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. 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.

Se viene creato un contenitore, un file o una directory 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 vengono impostati su $superuser.

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.

Gruppo proprietario

Negli ACL POSIX ogni utente è associato a un gruppo primario. L'utente "Alice", ad esempio, può appartenere al gruppo "finanza". Alice può anche appartenere a più gruppi, ma uno solo è sempre designato come il suo 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.

Assegnazione del gruppo proprietario per un nuovo file o directory

• Caso 1: directory radice /. Questa directory viene creata quando viene creato un contenitore Data Lake Storage. In questo caso il gruppo proprietario viene impostato sull'utente che ha creato il contenitore se l'operazione è stata eseguita usando OAuth. Se il contenitore viene creato usando la chiave condivisa, una firma di accesso condiviso dell'account o una firma di accesso condiviso del servizio, il proprietario e il gruppo proprietario vengono impostati su $superuser.
• Caso 2 (tutti gli altri casi): Quando viene creato un nuovo elemento, il gruppo proprietario viene copiato dalla directory 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

Modalità di valutazione delle autorizzazioni

Le identità vengono valutate nell'ordine seguente:

1. Superuser
2. utente proprietario
3. Identità denominata utente, entità servizio o gestita
4. Gruppo proprietario o gruppo denominato
5. Tutti gli altri utenti

Se a un'entità di sicurezza si applica più di una di queste identità, viene concesso il livello di autorizzazione associato alla prima identità. Ad esempio, se un'entità di sicurezza è sia l'utente proprietario che un utente denominato, viene applicato il livello di autorizzazione associato all'utente proprietario.

I gruppi denominati vengono considerati tutti insieme. Se un'entità di sicurezza è membro di più gruppi denominati, il sistema valuta ogni gruppo fino a quando non viene concessa l'autorizzazione desiderata. Se nessuno dei gruppi denominati fornisce l'autorizzazione desiderata, il sistema passa a valutare una richiesta rispetto all'autorizzazione associata a tutti gli altri utenti.

Lo pseudocodice seguente rappresenta l'algoritmo di controllo dell'accesso per gli account di archiviazione. Questo algoritmo mostra l'ordine in cui vengono valutate le identità.

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 )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # 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 dell'accesso, la maschera limita l'accesso agli utenti non anonimi, al gruppo proprietario e ai gruppi non anonimi.

Per un nuovo contenitore di Data Lake Storage Gen2, la maschera per l'ACL di accesso della directory radice ("/") è impostata sul valore predefinito 750 per le directory e 640 per i file. Nella tabella seguente viene illustrata la notazione simbolica di questi livelli di autorizzazione.

File non ricevono il bit X perché è irrilevante per i file in un sistema solo di archiviazione.

La maschera può essere specificata in base alle singole chiamate. 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. Se una maschera viene specificata per una determinata richiesta, esegue l'override completo della maschera predefinita.

Sticky bit

Lo sticky bit è una funzionalità più avanzata di un contenitore POSIX. Nel contesto di Data Lake Storage, è improbabile che lo sticky bit sia necessario. In sintesi, se il bit sticky è abilitato in una directory, un elemento figlio può essere eliminato o rinominato solo dall'utente proprietario dell'elemento figlio, dal proprietario della directory o dall'utente con privilegi avanzati ($superuser).

Lo sticky bit non viene visualizzato nel portale di Azure. Per altre informazioni sul bit permanente e su come impostarlo, vedere Che cos'è il bit sticky Data Lake Storage?.

Autorizzazioni predefinite per nuovi file e directory

Quando si crea un nuovo file o una nuova directory in una directory esistente, l'ACL predefinito per la directory padre determina quanto segue:

• ACL predefinito e ACL di accesso di una directory figlio.
• ACL di accesso di un file figlio (i file non hanno un ACL predefinito).

umask

Quando si crea un ACL predefinito, umask viene applicato all'ACL di accesso per determinare le autorizzazioni iniziali di un ACL predefinito. Se nella directory padre è definito un elenco di controllo di accesso predefinito, umask viene effettivamente ignorato e l'ACL predefinito della directory padre viene invece usato per definire questi valori iniziali.

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.

La proprietà umask per Azure Data Lake Storage è un valore costante impostato su 007. Questo valore viene convertito in:

Domande frequenti

È necessario abilitare il supporto per gli ACL?

No. Il controllo di accesso tramite gli elenchi di controllo di accesso è abilitato per un account di archiviazione purché la funzionalità dello spazio dei nomi gerarchico sia attiva.

Se lo spazio dei nomi gerarchico è disattivato, vengono applicate le regole di autorizzazione del controllo degli accessi in base al ruolo Azure.

Qual è il modo migliore per applicare gli elenchi di controllo di accesso?

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 LogsWriter all'elenco di controllo di accesso della directory /LogData con autorizzazioni di rwx.
• Aggiungere il gruppo LogsReader all'elenco di controllo di accesso della directory /LogData con autorizzazioni di r-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.

Come vengono valutate le autorizzazioni di Controllo degli accessi in base al ruolo di Azure e ACL?

Per informazioni su come il sistema valuta il controllo degli accessi in base al ruolo di Azure e gli ACL insieme per prendere decisioni di autorizzazione per le risorse dell'account di archiviazione, vedere Come vengono valutate le autorizzazioni.

Quali sono i limiti per le assegnazioni di ruolo di Azure e le voci ACL?

La tabella seguente fornisce una visualizzazione riepilogativa dei limiti da considerare quando si usa il controllo degli accessi in base al ruolo di Azure per gestire le autorizzazioni con granularità grossolana (autorizzazioni applicabili agli account di archiviazione o ai contenitori) e l'uso degli elenchi di controllo di accesso per gestire le autorizzazioni "granulari" (autorizzazioni applicabili a file e directory). Usare i gruppi di sicurezza per le assegnazioni 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.

Data Lake Storage supporta l'ereditarietà del controllo degli accessi in base al ruolo di Azure?

Le assegnazioni di ruolo di Azure ereditano. Le assegnazioni passano dalle risorse sottoscrizione, gruppo di risorse e account di archiviazione alla risorsa contenitore.

Data Lake Storage supporta l'ereditarietà degli ACL?

Gli ACL predefiniti possono essere usati per impostare gli ACL per le nuove sottodirectory e i file creati nella directory padre. Per aggiornare gli elenchi di controllo di accesso per gli elementi figlio esistenti, è necessario aggiungere, aggiornare o rimuovere gli ACL in modo ricorsivo per la gerarchia di directory desiderata. Per indicazioni, vedere la sezione Come impostare gli elenchi di controllo di accesso di questo articolo.

Quali autorizzazioni sono necessarie per eliminare in modo ricorsivo una directory e il relativo contenuto?

• Il chiamante ha le autorizzazioni di "utente con privilegi avanzati",

O

• Sono necessarie autorizzazioni di Scrittura + Esecuzione per la directory padre.
• Sono necessarie autorizzazioni di Lettura + Scrittura + Esecuzione per la directory da eliminare e per ogni directory al suo interno.

Chi è il proprietario di un file o una directory?

Il creatore di un file o una directory ne diventa il proprietario. Nel caso della directory radice, è l'identità dell'utente che ha creato il contenitore.

Quale gruppo viene impostato come gruppo proprietario di un file o una directory al momento della creazione?

Il gruppo proprietario viene copiato da quello della directory padre in cui si crea il nuovo file o la nuova directory.

Se l'utente proprietario di un file non ha le autorizzazioni RWX di cui ha bisogno. Come si deve procedere?

L'utente proprietario può modificare le autorizzazioni del file in modo da assegnarsi tutte le autorizzazioni RWX necessarie.

Perché in alcuni casi vengono visualizzati GUID negli elenchi di controllo di accesso?

Viene visualizzato un GUID se la voce rappresenta un utente e tale 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. 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). Per pulire gli elenchi di controllo di accesso, eliminare manualmente queste voci GUID.

Come si impostano correttamente gli ACL per un'entità servizio?

Quando si definiscono elenchi di controllo di accesso per le entità servizio, è importante usare l'ID oggetto (OID) dell'entità servizio per la registrazione dell'app creata. È importante notare che le app registrate hanno un'entità servizio separata nel tenant specifico di Microsoft Entra. Le app registrate hanno un OID visibile nel portale di Azure, ma l'entità servizio ha un altro OID (diverso). Articolo Per ottenere l'OID per l'entità servizio corrispondente a una registrazione dell'app, è possibile usare il comando az ad sp show. Specificare l'ID applicazione come parametro. Ecco un esempio di recupero dell'OID per l'entità servizio che corrisponde a una registrazione dell'app con ID app = ffffff-eeee-dddd-cccc-bbbbbbbbb0. Eseguire il comando seguente nell'interfaccia della riga di comando di Azure:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

Verrà visualizzato OID.

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. Assicurarsi di selezionare Salva

È possibile impostare l'ACL di un contenitore?

No. Un contenitore non dispone di un elenco di controllo di accesso. Tuttavia, è possibile impostare l'ACL della directory radice del contenitore. Ogni contenitore ha una directory radice e condivide lo stesso nome del contenitore. Ad esempio, se il contenitore è denominato my-container, la directory radice è denominata my-container/.

L'API REST di Archiviazione di Azure contiene un'operazione denominata Imposta ACL contenitore, ma tale operazione non può essere usata per impostare l'ACL di un contenitore o la directory radice di un contenitore. Questa operazione viene invece usata per indicare se è possibile accedere ai BLOB in un contenitore con una richiesta anonima. È consigliabile richiedere l'autorizzazione per tutte le richieste ai dati BLOB. Per altre informazioni, vedere Panoramica: Correzione dell'accesso in lettura anonimo per i dati BLOB.

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 in Ubuntu

Vedi anche

• Modello di controllo di accesso in Azure Data Lake Storage