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.
Nota
Gli elenchi di controllo di accesso si applicano solo alle entità di sicurezza nello stesso tenant. Gli ACL non si applicano agli utenti che usano l'autorizzazione con chiave condivisa perché nessuna identità è associata al chiamante e pertanto non è possibile eseguire l'autorizzazione basata sulle autorizzazioni dell'entità di sicurezza. Lo stesso vale per i token di firma di accesso condiviso (SAS) tranne quando viene usato un token di firma di accesso condiviso delegato dall'utente. In tal caso, Archiviazione di Azure esegue un controllo ACL POSIX rispetto all'ID oggetto prima di autorizzare l'operazione purché venga usato il parametro facoltativo. Per altre informazioni, vedere Creare una firma di accesso condiviso per la delega utente.
Come impostare gli elenchi di controllo di accesso
Per configurare le autorizzazioni a livello di file e directory, consultare uno dei seguenti articoli:
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. Per ottenere l'ID oggetto dell'entità servizio, aprire l'interfaccia della riga di comando di Azure e quindi usare questo comando: az ad sp show --id <Your App ID> --query objectId. Assicurarsi di sostituire il segnaposto <Your App ID> con l'ID app della registrazione dell'app. L'entità servizio viene considerata come un utente denominato. Questo ID verrà aggiunto all'elenco di controllo di accesso come qualsiasi utente denominato. Gli utenti denominati sono descritti più avanti in questo articolo.
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.
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.
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:
| file | Directory | |
|---|---|---|
| Lettura (R) | È possibile leggere il contenuto di un file | Per elencare il contenuto della directory, sono necessarie le autorizzazioni di Lettura ed Esecuzione |
| Scrittura (W) | È possibile scrivere o aggiungere in un file | Per creare elementi figlio in una directory, sono necessarie le autorizzazioni di Scrittura ed Esecuzione |
| Esecuzione (X) | Nessun valore nel contesto di Data Lake Storage | È necessaria per attraversare gli elementi figlio di una directory |
Nota
Se si concedono autorizzazioni usando solo elenchi di controllo di accesso (senza controllo degli accessi in base al ruolo di Azure), per concedere a un'entità di sicurezza l'accesso in lettura o scrittura a un file, è necessario concedere all'entità di sicurezza le autorizzazioni Esegui alla cartella radice del contenitore e a ogni cartella nella gerarchia di cartelle che portano al file.
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 |
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.
Importante
Questa tabella presuppone che si usino solo elenchi di controllo di accesso senza assegnazioni di ruolo di Azure. Per visualizzare una tabella simile che combina il controllo degli accessi in base al ruolo di Azure con gli ACL, vedere Tabella delle autorizzazioni: Combinazione di controllo degli accessi in base al ruolo di Azure, controllo degli accessi in base al ruolo e ACL di Azure.
| Operazione | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|
| Read Data.txt | --X |
--X |
--X |
R-- |
| Append to Data.txt | --X |
--X |
--X |
RW- |
| Delete Data.txt | --X |
--X |
-WX |
--- |
| Elimina /Oregon/ | -WX |
RWX |
RWX |
--- |
| Elimina /Oregon/Portland/ | --X |
-WX |
RWX |
--- |
| Create Data.txt | --X |
--X |
-WX |
--- |
| Elenco / | R-X |
--- |
--- |
--- |
| Elencare /Oregon/ | --X |
R-X |
--- |
--- |
| Elencare /Oregon/Portland/ | --X |
--X |
R-X |
--- |
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.
Nota
La directory radice "/" non può mai essere eliminata.
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.
Nota
L'utente proprietario non può modificare l'utente proprietario di un file o di una directory. Solo gli utenti con privilegi avanzati possono modificare l'utente proprietario di un file o una directory.
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
Nota
Il gruppo proprietario non può modificare gli ACL di un file o di una directory. Mentre il gruppo proprietario è impostato sull'utente che ha creato l'account nel caso della directory radice, Caso 1 descritto sopra, un singolo account utente non è valido per fornire autorizzazioni tramite il gruppo proprietario. È possibile assegnare questa autorizzazione a un gruppo utenti valido, se applicabile.
Modalità di valutazione delle autorizzazioni
Le identità vengono valutate nell'ordine seguente:
- Superuser
- utente proprietario
- Identità denominata utente, entità servizio o gestita
- Gruppo proprietario o gruppo denominato
- 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.
| Entità | Directories | File |
|---|---|---|
| utente proprietario | rwx |
rw- |
| gruppo proprietario | r-x |
r-- |
| Altro | --- |
--- |
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:
| componente umask | Forma numerica | Forma breve | significato |
|---|---|---|---|
| umask.owning_user | 0 | --- |
Per l'utente proprietario, copiare l'ACL di accesso dell'elemento padre nell'ACL predefinito dell'elemento figlio |
| umask.owning_group | 0 | --- |
Per il gruppo proprietario, copiare l'ACL di accesso dell'elemento padre nell'ACL predefinito dell'elemento figlio |
| umask.other | 7 | RWX |
Per altri, rimuovere tutte le autorizzazioni sull'ACL di accesso dell'elemento figlio |
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
LogsWriterall'elenco di controllo di accesso della directory /LogData con autorizzazioni dirwx. - Aggiungere il gruppo
LogsReaderall'elenco di controllo di accesso della directory /LogData con autorizzazioni dir-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.
Importante
Azure Data Lake Storage Gen2 dipende dall'ID Microsoft Entra per gestire i gruppi di sicurezza. Microsoft Entra ID consiglia di limitare l'appartenenza a un gruppo per una determinata entità di sicurezza a meno di 200. Questa raccomandazione è dovuta a una limitazione dei token JSON Web (JWT) che forniscono informazioni sull'appartenenza ai gruppi di un'entità di sicurezza all'interno delle applicazioni Microsoft Entra. Il superamento di questo limite potrebbe causare problemi di prestazioni imprevisti con Data Lake Storage Gen2. Per altre informazioni, vedere configurare le attestazioni di gruppo per le applicazioni 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.
| Meccanismo | Ambito | Limiti | Livello di autorizzazione supportato |
|---|---|---|---|
| Controllo degli accessi in base al ruolo di Azure | Account di archiviazione, contenitori. Assegnazioni di ruolo di Azure tra risorse a livello di sottoscrizione o gruppo di risorse. |
4000 assegnazioni di ruolo di Azure in una sottoscrizione | Ruoli di Azure (predefiniti o personalizzati) |
| ACL | Directory, file | 32 voci ACL (in effetti 28 voci ACL) per 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. | Autorizzazione ACL |
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.
Nota
Non sono necessarie autorizzazioni di Scrittura per eliminare i file nelle directory. La directory radice "/" non può mai essere eliminata.
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 = 00001111-aaaa-2222-bbbb-3333cccc44444. 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 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