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 usare Azure RBAC insieme alle ACL e su come il sistema le valuta per determinare le 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 è una 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 di controllo degli accessi (ACL) gestiscono 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 elenchi di controllo di accesso 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, Scrittura ed Esecuzione. È possibile usare queste autorizzazioni per file e directory, come illustrato nella tabella seguente:

Forme brevi per le autorizzazioni

Usare RWX per visualizzare le autorizzazioni Lettura + Scrittura + Esecuzione . Esiste anche una forma numerica in cui Read=4, Write=2 e Execute=1. Aggiungere questi numeri per visualizzare le autorizzazioni. Ecco 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.

Eliminare file e directory

Come illustrato nella tabella precedente, non sono necessarie autorizzazioni di scrittura per il file 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à degli utenti e dei 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 di Microsoft Entra, un'entità servizio, un'identità gestita o un gruppo di sicurezza.

Utente con privilegi avanzati

Un utente con privilegi avanzati ha i diritti più elevati di tutti gli utenti. Un utente con privilegi avanzati:

• Dispone delle 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 si crea un contenitore, un file o una directory utilizzando una chiave condivisa, un SAS di account o un SAS di servizio, il proprietario e il gruppo proprietario vengono impostati su $superuser.

Utente proprietario

L'utente che crea l'elemento è automaticamente l'utente proprietario dell'elemento. Un utente proprietario può:

• Modificare le autorizzazioni di un file di cui sono proprietari.
• Modificare il gruppo proprietario di un file di cui sono proprietari, purché 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. In POSIX, quando Alice crea un file, il gruppo proprietario di tale file è impostato sul suo gruppo primario, che in questo caso è "finance". Il gruppo proprietario si comporta in modo analogo alle autorizzazioni assegnate per altri utenti e gruppi.

Assegnazione del gruppo proprietario per un nuovo file o directory

• Caso 1: directory principale /. 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 usa OAuth. Se l'utente crea il contenitore utilizzando una chiave condivisa, un SAS di account o un SAS di 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

Il sistema valuta le identità nell'ordine seguente:

1. Superutente
2. utente proprietario
3. Utente designato, entità di servizio o identità gestita
4. Gruppo proprietario o gruppo denominato
5. Tutti gli altri utenti

Se più di una di queste identità si applica a un'entità di sicurezza, il sistema concede 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.

Il sistema considera insieme tutti i gruppi denominati. Se un'entità di sicurezza è membro di più gruppi denominati, il sistema valuta ogni gruppo finché non trova 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

La maschera si applica solo alla voce ACL di un utente denominato, a un gruppo denominato e al gruppo proprietario. La maschera specifica quale delle autorizzazioni nella voce ACL viene utilizzata per autorizzare l'accesso. Queste autorizzazioni applicate sono denominate autorizzazioni valide della voce ACL. Il sistema ignora tutte le altre autorizzazioni nella voce ACL. Usando la maschera, è possibile stabilire un limite superiore per i livelli di autorizzazione.

È possibile specificare la maschera per ogni chiamata. Questa flessibilità consente a diversi sistemi di utilizzo, ad esempio i cluster, di avere maschere efficaci diverse per le operazioni dei file. Se si specifica una maschera in una determinata richiesta, la maschera predefinita viene sostituita completamente.

Sticky bit

Lo sticky bit è una funzionalità più avanzata di un contenitore POSIX. Nel contesto dello storage dei data lake, è improbabile che sia necessario il bit sticky. In sintesi, se si abilita il bit sticky in una directory, solo l'utente proprietario dell'elemento figlio, il proprietario della directory o l'utente con privilegi avanzati ($superuser) può eliminare o rinominare un elemento figlio.

Il portale di Azure non mostra il bit di fissaggio. Per ulteriori informazioni sullo sticky bit e su come impostarlo, vedere Che cos'è lo sticky bit in Data Lake Storage?

Autorizzazioni predefinite della directory radice

Per un nuovo contenitore Data Lake Storage, per impostazione predefinita l'elenco di controllo di accesso della directory radice ("/") è 750 per le directory e 640 per i file. Nella tabella seguente viene illustrata la notazione simbolica di questi livelli di autorizzazione.

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

Autorizzazioni predefinite per nuovi file e directory

Quando si crea un nuovo file o una directory in una directory esistente, l'ACL predefinito nella directory padre determina:

• 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, il sistema applica umask all'ACL di accesso per determinare le autorizzazioni iniziali per l'ACL predefinito. Se si definisce un ACL predefinito nella directory padre, il sistema ignora umask e usa l'ACL predefinito della directory padre per impostare i 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.

L'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. Se la funzionalità Spazio dei nomi gerarchico (HNS) è attivata, il controllo di accesso tramite ACL è abilitato per un account di archiviazione.

Se HNS è disattivato, le regole di autorizzazione di Azure RBAC vengono comunque applicate.

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

Usare sempre gruppo di sicurezza Microsoft Entra come entità di sicurezza assegnata in una voce di elenco di controllo di accesso. Resistere all'opportunità di assegnare direttamente singoli utenti o principali del 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:

• Aggiungi il gruppo LogsWriter all'ACL della directory /LogData con le autorizzazioni rwx.
• Aggiungi il gruppo LogsReader all'ACL della directory /LogData con le autorizzazioni r-x.
• Aggiungere l'oggetto principale del servizio o l'Identità del Servizio Gestita (MSI) 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 gestita 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 Azure RBAC e le ACL?

Per sapere come il sistema valuta insieme RBAC di Azure e ACL per prendere decisioni di autorizzazione sulle 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 grossolane (autorizzazioni applicabili agli account di archiviazione o ai contenitori) e si usano gli elenchi di controllo di accesso per gestire le autorizzazioni a grana fine (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.

Il Data Lake Storage supporta l'ereditarietà di Azure RBAC?

Le assegnazioni di ruolo di Azure vengono ereditate. 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 figlio e i nuovi file figlio 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 dispone di autorizzazioni utente con privilegi avanzati,

O

• La directory principale dispone dei permessi di scrittura ed esecuzione.
• La directory da eliminare e ogni directory all'interno di essa richiede le autorizzazioni Lettura, Scrittura ed Esecuzione.

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 principale, tale identità corrisponde all'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.

Sono l'utente proprietario di un file, ma non ho le autorizzazioni RWX di cui ho bisogno. Come si deve procedere?

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

Perché a volte vedo i GUID negli elenchi di controllo di accesso?

Viene visualizzato un GUID se la voce rappresenta un utente e in Microsoft Entra tale utente non esiste più. In genere ciò si verifica se l'utente non fa più parte dell'azienda o l'account è stato eliminato in Microsoft Entra ID. Inoltre, i principali di servizio e i gruppi di sicurezza non possiedono un Nome Principale Utente (UPN) per identificarli e vengono quindi rappresentati dal loro 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 principal del 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 che corrisponde 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 = 00001111-aaaa-2222-bbbb-3333cccc4444. Eseguire il comando seguente nell'interfaccia della riga di comando di Azure:

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --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 una ACL. 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 utilizzata per indicare se è possibile accedere ai blob in un contenitore tramite una richiesta anonima. È consigliabile richiedere l'autorizzazione per tutte le richieste ai dati BLOB. Per altre informazioni, vedere Panoramica: risoluzione dell'accesso anonimo in lettura ai dati BLOB.

Dove è possibile reperire altre informazioni sul modello di controllo di accesso POSIX?

• POSIX Controllo di accesso 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