Share via

Controllo di accesso in Azure Data Lake Storage Gen1

  • Articolo

Azure Data Lake Storage Gen1 implementa un modello di controllo di accesso derivante da HDFS, che a sua volta deriva dal modello di controllo di accesso POSIX. Questo articolo offre un riepilogo delle nozioni di base del modello di controllo di accesso per Data Lake Storage Gen1.

Elenchi di controllo di accesso per file e cartelle

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

  • ACL di accesso: questi elenchi controllano l'accesso a un oggetto. Sia i file che le cartelle hanno ACL di accesso.

  • ACL predefiniti: "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 presentano la stessa struttura.

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.

Autorizzazioni

Le autorizzazioni per un oggetto del file system sono Lettura, Scrittura ed Esecuzione e possono essere usate per file e cartelle come illustrato nella tabella seguente:

File Cartella
Lettura (R) È possibile leggere il contenuto di un file Per elencare il contenuto della cartella sono necessarie le autorizzazioni di Lettura ed Esecuzione
Scrittura (W) È possibile scrivere o aggiungere in un file Per creare elementi figlio in una cartella sono necessarie le autorizzazioni di Scrittura ed Esecuzione.
Esecuzione (X) Nessun valore nel contesto di Data Lake Storage Gen1 È necessaria per attraversare gli elementi figlio 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-- Lettura
0 --- Nessuna autorizzazione

Non ereditarietà delle autorizzazioni

Nel modello di tipo POSIX usato da Data Lake Storage Gen1, le autorizzazioni per un elemento vengono archiviate nell'elemento stesso. In altri termini, le autorizzazioni per un elemento non sono ereditabili dagli elementi padre.

Di seguito sono riportati alcuni scenari comuni che consentono di comprendere quali autorizzazioni sono necessarie per eseguire determinate operazioni su un account Data Lake Storage Gen1.

Operazione Oggetto / Seattle/ Portland/ Data.txt
Lettura Data.txt --X --X --X R--
Accoda a Data.txt --X --X --X -W-
Elimina Data.txt --X --X -WX ---
Crea Data.txt --X --X -WX ---
Elenco / R-X --- --- ---
Elenco /Seattle/ --X R-X --- ---
Elenco /Seattle/Portland/ --X --X R-X ---

Nota

Se vengono soddisfatte le due condizioni precedenti, non sono necessarie autorizzazioni di scrittura per il file per eliminarlo.

Utenti e identità

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

  • Utente proprietario
  • Gruppo proprietario
  • Utenti non anonimi
  • Gruppi con nome
  • Tutti gli altri utenti

Le identità di utenti e gruppi sono Microsoft Entra identità. Pertanto, se non diversamente specificato, un "utente", nel contesto di Data Lake Storage Gen1, può significare un utente Microsoft Entra o un gruppo di sicurezza Microsoft Entra.

Utente con privilegi avanzati

Un utente con privilegi avanzati ha diritti superiori rispetto a qualsiasi altro utente 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 i membri che fanno parte del ruolo Proprietari per un account Data Lake Storage Gen1 sono automaticamente utenti con privilegi avanzati.

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 i superuser possono modificare l'utente proprietario di un file o 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 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/gruppi.

Poiché non esiste alcun "gruppo primario" associato agli utenti in Data Lake Storage Gen1, il gruppo proprietario viene assegnato come mostrato di seguito.

Assegnazione del gruppo proprietario per un nuovo file o cartella

  • Caso 1: cartella radice "/". Questa cartella viene creata al momento della creazione di un account Data Lake Storage Gen1. In questo caso, il gruppo proprietario viene impostato su un GUID costituito solo da zeri. Questo valore non permette alcun accesso. È un segnaposto fino a quando non viene assegnato un gruppo.
  • Caso 2: tutti gli altri casi. 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 ACL di un file o di una cartella.

Per gli account creati a o prima di settembre 2018, il gruppo proprietario è impostato sull'utente che ha creato l'account nel caso della cartella radice per Caso 1, come descritto sopra. Poiché un singolo account utente non è valido per fornire autorizzazioni tramite il gruppo proprietario, non vengono concesse autorizzazioni tramite questa impostazione predefinita. È possibile assegnare questa autorizzazione a un gruppo di utenti valido.

Algoritmo di controllo dell'accesso

Lo pseudocodice seguente rappresenta l'algoritmo di controllo dell'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 dell'accesso, la maschera limita l'accesso agli utenti non anonimi, il gruppo proprietario, e i gruppi non anonimi.

Nota

Per un nuovo account Data Lake Storage Gen1, l'impostazione predefinita della maschera per l'elenco di controllo di accesso della cartella radice ("/") è RWX.

Sticky bit

Lo sticky bit è una funzionalità più avanzata di un file system POSIX. Nel contesto di Data Lake Storage Gen1, è improbabile che lo sticky bit sia necessario. In riepilogo, se il bit bastone è abilitato in una cartella, un elemento figlio può essere eliminato o rinominato dall'utente proprietario dell'elemento figlio.

Lo sticky bit non viene visualizzato nel portale di Azure.

Autorizzazioni predefinite per nuovi file e cartelle

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

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

umask

Quando si crea un file o una cartella, la proprietà umask viene usata per modificare la modalità in cui gli ACL predefiniti vengono impostati sull'elemento figlio. umask è un valore a 9 bit nelle cartelle padre che contiene un valore RWX per l'utente proprietario, il gruppo di proprietà e altri.

L'umask per Azure Data Lake Storage Gen1 è un valore costante impostato su 007. Questo valore viene convertito 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, copiare l'ACL predefinito dell'elemento padre nell'ACL di accesso dell'elemento figlio
umask.other 7 RWX Per altri, rimuovere tutte le autorizzazioni sull'ACL di accesso dell'elemento figlio

Il valore umask usato efficacemente da Azure Data Lake Storage Gen1 significa che il valore per gli altri non viene mai trasmesso per impostazione predefinita sui nuovi elementi figlio, indipendentemente da ciò che indica l'ACL predefinito.

Lo pseudocodice seguente illustra come viene applicata la proprietà umask quando si creano gli 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 frequenti sugli elenchi di controllo di accesso in Data Lake Storage Gen1

È necessario abilitare il supporto per gli ACL?

No. Il controllo di accesso tramite gli elenchi di controllo di accesso (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?

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

Nota

Non sono necessarie autorizzazioni di Scrittura per eliminare i file nelle cartelle. La cartella radice "/" non può mai essere eliminata.

Chi è il proprietario di un file o una cartella?

Il creatore di un file o una cartella ne diventa il proprietario.

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

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

Se l'utente proprietario di un file non ha le autorizzazioni RWX di cui ha bisogno, Cosa devo fare?

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

La visualizzazione degli ACL nel portale di Azure mostra i nomi utente, mentre tramite le API vengono visualizzati i GUID. Per quale motivo?

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 traducendo i GUID in nomi descrittivi, quando è possibile.

Perché a volte negli ACL vengono visualizzati i GUID quando si usa il portale di Azure?

Un GUID viene visualizzato quando l'utente non esiste più in Microsoft Entra. In genere questo accade quando l'utente ha lasciato l'azienda o se il proprio 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 l'entità servizio, qual è l'ID da usare per impostare gli elenchi di controllo di accesso?

Nel portale di Azure passare a Microsoft Entra ID -> Applicazioni aziendali e selezionare l'applicazione. La scheda Panoramica deve visualizzare un ID oggetto e questo è ciò che deve essere usato quando si aggiungono elenchi di controllo di accesso ai dati (e non ID applicazione).

Data Lake Storage Gen1 supporta l'ereditarietà degli elenchi di controllo di accesso?

No, ma gli ACL predefiniti possono essere usati per impostare gli ACL per i file e le cartelle figlio appena creati nella cartella padre.

Quali sono i limiti per le voci ACL nei file e nelle cartelle?

È possibile impostare 32 ACL per file e per 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?

Vedi anche