Condividi tramite

Controllo di accesso in Azure Data Lake Storage Gen1

  • Articolo

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

Elenchi di controllo di accesso su file e cartelle

Esistono due tipi di elenchi di controllo di accesso (ACL), ACL di accesso e ACL predefiniti.

  • ACL di accesso: controllano l'accesso a un oggetto. I file e le cartelle hanno entrambi ACL di accesso.

  • ACL predefiniti: un "modello" di ACL associato a una cartella che determina gli ACL di accesso per tutti gli elementi figlio creati in tale cartella. I file non hanno ACL predefiniti.

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

Nota

La modifica dell'ACL predefinito di un elemento padre non influisce sull'ACL di accesso o sull'ACL predefinito degli elementi figlio già esistenti.

Autorizzazioni

Le autorizzazioni per un oggetto file system sono Read, Writee Executee possono essere usate in file e cartelle, come illustrato nella tabella seguente:

Documento Cartella
Lettura (R) È possibile leggere il contenuto di un file Richiede leggi e esegui per elencare i contenuti della cartella
Scrivi (W) È possibile scrivere o aggiungere in un file Richiede write e Execute per creare elementi figlio in una cartella
Esegui (X) Non significa nulla nel contesto di Data Lake Storage Gen1 Necessario per percorrere gli elementi figli di una cartella

Forme brevi per le autorizzazioni

La forma RWX viene usata per indicare Lettura + Scrittura + Esecuzione. Esiste una forma numerica ridotta in cui Lettura=4, Scrittura=2 ed Esecuzione=1 e la cui somma rappresenta le autorizzazioni. Di seguito sono riportati alcuni esempi.

Forma numerica Forma breve Significato
7 RWX Lettura + Scrittura + Esecuzione
5 R-X Lettura + Esecuzione
4 R-- Leggi
0 --- Nessuna autorizzazione

Le autorizzazioni non ereditano

Nel modello in stile POSIX usato da Data Lake Storage Gen1 le autorizzazioni per un elemento vengono archiviate nell'elemento stesso. In altre parole, le autorizzazioni per un elemento non possono essere ereditate dagli elementi padre.

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

Operazione Oggetto / Seattle/ Portland/ Data.txt
Leggi Data.txt --X --X --X R--
Aggiunta a Data.txt --X --X --X -W-
Cancella Data.txt --X --X -WX ---
Creazione Data.txt --X --X -WX ---
Elenco / R-X --- --- ---
Elenco /Seattle/ --X R-X --- ---
Elenco /Seattle/Portland/ --X --X R-X ---

Nota

Le autorizzazioni di scrittura per il file non sono necessarie per eliminarlo, purché le due condizioni precedenti siano vere.

Utenti e identità

Ogni file e cartella dispone di autorizzazioni distinte per queste identità:

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

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

Utente con privilegi avanzati

Un utente con privilegi avanzati ha i diritti più elevati di tutti gli utenti nell'account Data Lake Storage Gen1. Un utente con privilegi avanzati:

  • Ha autorizzazioni RWX per tutti i file e le cartelle.
  • Può modificare le autorizzazioni per qualsiasi file o cartella.
  • Può modificare l'utente o il gruppo proprietario di qualsiasi file o cartella.

Tutti gli utenti che fanno parte del ruolo Proprietari per un account Data Lake Storage Gen1 diventano automaticamente super-utenti.

Utente proprietario

L'utente che ha creato l'elemento ne è automaticamente l'utente proprietario. Un utente proprietario può:

  • Modificare le autorizzazioni di un file di sua proprietà.
  • Modificare il gruppo proprietario di un file di sua proprietà, a condizione che l'utente proprietario sia anche membro del gruppo di destinazione.

Nota

L'utente proprietario non può modificare l'utente proprietario di un file o di una cartella. Solo gli utenti con privilegi avanzati possono modificare l'utente proprietario di un file o di una cartella.

Gruppo proprietario

Background

Negli ACL POSIX ogni utente è associato a un "gruppo primario". Ad esempio, l'utente "alice" potrebbe appartenere al gruppo "finance". Alice può anche appartenere a più gruppi, ma un gruppo è sempre designato come gruppo primario. Quando Alice crea un file in POSIX, come gruppo proprietario del file viene impostato il gruppo primario di Alice, in questo caso "finanza". Il gruppo proprietario si comporta in modo analogo alle autorizzazioni assegnate per altri utenti o gruppi.

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

Assegnazione del gruppo proprietario per un nuovo file o una nuova cartella

  • Caso 1: cartella radice "/". Questa cartella viene creata quando viene creato un account Data Lake Storage Gen1. In questo caso, il gruppo proprietario è impostato su un GUID tutto zerato. Questo valore non consente alcun accesso. È un segnaposto fino a quando non viene assegnato un gruppo.
  • caso 2 (ogni altro caso): quando viene creato un nuovo elemento, il gruppo proprietario viene copiato dalla cartella padre.

Modifica del gruppo proprietario

Il gruppo proprietario può essere modificato da:

  • Qualsiasi utente con privilegi avanzati.
  • Utente proprietario, se è anche membro del gruppo di destinazione

Nota

Il gruppo proprietario non può modificare gli elenchi di controllo di accesso di un file o di una cartella.

Per gli account creati in data o prima di settembre 2018, il gruppo proprietario è stato impostato sull'utente che ha creato l'account nel caso della cartella radice per Caso 1precedente. Un singolo account utente non è valido per fornire autorizzazioni tramite il gruppo proprietario, pertanto non viene concessa alcuna autorizzazione da questa impostazione predefinita. È possibile assegnare questa autorizzazione a un gruppo di utenti valido.

Algoritmo di controllo di accesso

Lo pseudocodice seguente rappresenta l'algoritmo di controllo di accesso per gli account Data Lake Storage Gen1.

def access_check( user, desired_perms, path ) : 
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permmissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
      member_count += 1
      perms | =  entry.permissions
  if (member_count>0) :
    return ((desired_perms & perms & mask ) == desired_perms)
 
  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

La maschera

Come illustrato nell'algoritmo di controllo di accesso, la maschera limita l'accesso per utenti nominati, il gruppo proprietario e gruppi nominati.

Nota

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

Il bit appiccicoso

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

Il bit sticky non viene visualizzato nel portale di Azure.

Autorizzazioni predefinite per i nuovi file e cartelle

Quando viene creato un nuovo file o una nuova cartella in una cartella esistente, l'ACL predefinito nella cartella padre determina:

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

umask

Quando si crea un file o una cartella, umask viene usato per modificare la modalità di impostazione degli ACL predefiniti nell'elemento figlio. umask è un valore a 9 bit nelle cartelle principali che definisce un valore RWX per utente proprietario, gruppo proprietarioe altri.

L'umask per Azure Data Lake Storage Gen1 è un valore fisso impostato su 007. Questo valore si traduce in

componente umask Forma numerica Forma breve Significato
umask.owning_user 0 --- Per l'utente proprietario, copiare l'ACL predefinito dell'elemento padre nell'ACL di accesso dell'elemento figlio
umask.owning_group 0 --- Per il gruppo proprietario, trasferire l'ACL predefinito del padre nell'ACL di accesso del figlio
umask.other 7 RWX Per altri, rimuovere tutte le autorizzazioni sull'ACL di accesso del figlio

Il valore umask usato da Azure Data Lake Storage Gen1 implica effettivamente che il valore per 'altri' non viene mai trasmesso per impostazione predefinita nei nuovi sottoelementi, indipendentemente da ciò che indica l'ACL predefinito.

Il seguente pseudocodice mostra come viene applicato l'umask quando si creano le ACL per un elemento figlio.

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

Domande comuni sugli ACL in Data Lake Storage Gen1

È necessario abilitare il supporto per gli ACL?

No. Il controllo di accesso tramite ACL è sempre attivo per un account Data Lake Storage Gen1.

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

  • La cartella padre deve disporre delle autorizzazioni di Write + Execute.
  • La cartella da eliminare e ogni cartella al suo interno richiede autorizzazioni di Lettura + Scrittura + Esecuzione.

Nota

Non sono necessarie autorizzazioni di scrittura per eliminare i file nelle cartelle. Inoltre, la cartella radice "/" può mai essere eliminata.

Chi è il proprietario di un file o di una cartella?

L'autore di un file o di una cartella diventa il proprietario.

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

Il gruppo proprietario viene copiato dal gruppo proprietario della cartella padre in cui viene creato il nuovo file o la nuova cartella.

Io sono l'utente proprietario di un file, ma non ho le autorizzazioni RWX necessarie. Cosa faccio?

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

Quando si esaminano gli elenchi di controllo di accesso nel portale di Azure vengono visualizzati i nomi utente, ma tramite le API vengono visualizzati i GUID, perché?

Le voci negli elenchi di controllo di accesso vengono archiviate come GUID che corrispondono agli utenti in Microsoft Entra ID. Le API restituiscono i GUID così come sono. Il portale di Azure tenta di semplificare l'uso degli ACL convertendo i GUID in nomi descrittivi, quando possibile.

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

Un GUID viene visualizzato quando l'utente non esiste più in Microsoft Entra. In genere ciò si verifica se l'utente non fa più parte dell'azienda o l'account è stato eliminato in Microsoft Entra ID. Assicurarsi inoltre di usare l'ID corretto per l'impostazione degli elenchi di controllo di accesso (dettagli in questione di seguito).

Quando si usa il service principal, quale ID è necessario usare per impostare gli ACL?

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

Data Lake Storage Gen1 supporta l'ereditarietà degli ACL?

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

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

32 ACL possono essere impostati per ogni file e per ogni directory. L'accesso e gli elenchi di controllo di accesso predefiniti dispongono ognuno di un proprio limite di 32 voci ACL. Se possibile, usare i gruppi di sicurezza per le assegnazioni ACL. Usando i gruppi, è meno probabile che superi il numero massimo di voci ACL per file o directory.

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

Vedere anche