Questa pagina fornisce una panoramica degli elenchi di controllo dell'accesso (ACL). Per scoprire altri modi per controllare l'accesso a bucket e oggetti, consulta Panoramica del controllo dell'accesso.
Dovresti usare gli elenchi di controllo dell'accesso?
Nella maggior parte dei casi, Identity and Access Management (IAM) è il metodo consigliato per controllare l'accesso alle risorse:
- IAM fornisce controllo dell'accesso su tutto Google Cloud.
- IAM ha un maggiore controllo sulle azioni consentite agli utenti di eseguire.
- Le autorizzazioni IAM concesse alle risorse padre, ad esempio i progetti, vengono ereditate dalle risorse figlio, come bucket e oggetti, in modo da gestire più facilmente l'accesso alle risorse.
- Le autorizzazioni IAM possono essere applicate alle cartelle gestite, mentre gli ACL non possono.
- Gli ACL non possono essere utilizzati esclusivamente per controllare l'accesso alle risorse, perché non possono essere impostati sul progetto complessivo o su altre risorse padre.
L'utilizzo esclusivo di IAM e l'abilitazione dell'accesso uniforme a livello di bucket ti consentono di utilizzare altre funzionalità di sicurezza di Google Cloud, come la condivisione limitata al dominio, la federazione delle identità per la forza lavoro e le condizioni IAM.
Ti consigliamo di utilizzare gli ACL nei seguenti casi:
- Devi personalizzare l'accesso ai singoli oggetti all'interno di un bucket. È possibile impostare gli ACL per singoli oggetti, mentre le autorizzazioni IAM possono essere concesse solo a livello di bucket o superiore.
- Devi utilizzare esclusivamente l'API XML o richiedere l'interoperabilità con Amazon S3.
IAM e ACL collaborano per concedere l'accesso ai bucket e agli oggetti, il che significa che un utente ha bisogno solo dell'autorizzazione pertinente di uno di questi sistemi per accedere a un bucket o un oggetto.
Che cos'è un elenco di controllo dell'accesso?
Un elenco di controllo dell'accesso (ACL) è un meccanismo che puoi utilizzare per definire chi può accedere ai tuoi bucket e ai tuoi oggetti, nonché il livello di accesso. In Cloud Storage, applichi gli ACL ai singoli bucket e oggetti. Ogni ACL è composto da una o più voci. Una voce dà a un utente (o gruppo) specifico la possibilità di eseguire azioni Ogni voce è composta da due informazioni:
Un'autorizzazione, che definisce quali azioni possono essere eseguite (ad esempio, lettura o scrittura).
Un ambito (a volte indicato come concesso), che definisce chi può eseguire le azioni specificate (ad esempio, un utente o un gruppo di utenti specifico).
Ad esempio, supponi di avere un bucket da cui vuoi che chiunque possa accedere agli oggetti, ma vuoi anche che il tuo collaboratore possa aggiungere o rimuovere oggetti dal bucket. In questo caso, l'ACL sarà composto da due voci:
In una voce, devi concedere a
READER
l'autorizzazione per un ambito diallUsers
.Nell'altra voce, devi concedere a
WRITER
l'autorizzazione per l'ambito del tuo collaboratore. Esistono diversi modi per specificare questa persona, ad esempio tramite il suo indirizzo email.
Il numero massimo di voci ACL che puoi creare per un bucket o un oggetto è 100. Quando l'ambito della voce è un gruppo o un dominio, viene conteggiata una voce ACL, indipendentemente dal numero di utenti nel gruppo o nel dominio.
Quando un utente richiede l'accesso a un bucket o a un oggetto, il sistema Cloud Storage legge l'ACL del bucket o dell'oggetto e determina se consentire o meno la richiesta di accesso. Se l'ACL concede all'utente l'autorizzazione per l'operazione richiesta, la richiesta è consentita. Se l'ACL non concede all'utente l'autorizzazione per l'operazione richiesta, la richiesta non riesce e viene restituito un errore 403 Forbidden
.
Tieni presente che sebbene gli ACL possano essere utilizzati per gestire la maggior parte delle azioni che coinvolgono bucket e oggetti, la possibilità di creare un bucket dipende dalla autorizzazione di progetto appropriata.
Autorizzazioni
Le autorizzazioni descrivono cosa è possibile fare per un determinato oggetto o bucket.
Cloud Storage consente di assegnare le seguenti autorizzazioni concentriche per i bucket e gli oggetti, come illustrato nella tabella seguente:
Bucket | Oggetti | |
---|---|---|
READER |
Consente a un utente di elencare i contenuti di un bucket. Consente inoltre a un utente di leggere i metadati del bucket, esclusi gli ACL. | Consente a un utente di scaricare i dati di un oggetto. |
WRITER |
Concede a un utente tutti gli accessi concessi dall'autorizzazione READER . Inoltre, consente a un utente di creare, sostituire ed eliminare oggetti in un bucket, inclusa la creazione di oggetti utilizzando caricamenti multiparte. |
N/D. Non puoi applicare questa autorizzazione agli oggetti. |
OWNER |
Concede a un utente tutti gli accessi concessi dall'autorizzazione WRITER . Consente inoltre a un utente di leggere e scrivere metadati del bucket, compresi gli ACL, e di utilizzare i tag nel bucket. |
Concede a un utente tutti gli accessi concessi dall'autorizzazione READER . Consente inoltre a un utente di leggere e scrivere metadati degli oggetti, inclusi gli ACL. |
Predefinita | Ai bucket viene applicato l'ACL predefinito project-private applicato al momento della creazione. I bucket sono sempre di proprietà del gruppo project-owners . |
Agli oggetti viene applicato l'ACL predefinito project-private applicato al momento del caricamento. Gli oggetti sono sempre di proprietà del richiedente originale che li ha caricati. |
In questa pagina, in genere facciamo riferimento alle autorizzazioni come READER
, WRITER
e OWNER
, che corrispondono a come vengono specificate nell'API JSON e nella
console Google Cloud. Se utilizzi l'API XML, le autorizzazioni
equivalente sono rispettivamente READ
, WRITE
e FULL_CONTROL
.
Ambiti
Gli ambiti specificano chi è a cui è stata assegnata una determinata autorizzazione.
Un ACL consiste in una o più voci, ciascuna delle quali concede le autorizzazioni per un ambito. Puoi specificare un ambito ACL utilizzando una delle seguenti entità:
Ambito ("grantee") | Tipi di persone giuridiche | Esempio |
---|---|---|
Identificatore speciale per tutte le entità | Utente | allUsers |
Identificatore speciale per tutti gli account validi | Utente | allAuthenticatedUsers |
Indirizzo email dell'account utente | Utente | collaborator@gmail.com |
Indirizzo email del gruppo Google | Gruppo | gruppo-lavoro@googlegroups.com |
Valori di comodità per i progetti | Progetto | owners-123456789012 |
Dominio Google Workspace | Dominio | USERNAME@YOUR_DOMAIN.com |
Dominio Cloud Identity | Dominio | USERNAME@YOUR_DOMAIN.com |
Identità singola in un pool di identità della forza lavoro | Entità | //iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com |
Tutte le identità della forza lavoro in un gruppo | PrincipalSet | //iam.googleapis.com/locations/global/workforcePools/my-pool/group/my-group |
Identificatore speciale per tutte le entità:
L'identificatore di ambito speciale
allUsers
rappresenta qualsiasi entità su internet. Tieni presente che, anche se questo identificatore è un tipo di entitàUser
, quando utilizzi la console Google Cloud è etichettato come tipo di entitàPublic
.Identificatore speciale per tutti gli account validi:
L'identificatore di ambito speciale
allAuthenticatedUsers
rappresenta gli account più autenticati, inclusi gli account di servizio. Per maggiori informazioni, consulta la panoramica di IAM. Tieni presente che, anche se questo identificatore è un tipo di entitàUser
, quando utilizzi la console Google Cloud è etichettato come tipo di entitàPublic
.Indirizzo email account utente:
Ogni utente che dispone di un account utente deve avere un indirizzo email univoco associato all'account. Puoi specificare un ambito utilizzando qualsiasi indirizzo email associato a un account utente.
Cloud Storage memorizza gli indirizzi email così come sono forniti negli ACL fino a quando le voci non vengono rimosse o sostituite. Se un utente cambia indirizzi email, devi aggiornare le voci ACL per riflettere le modifiche.
Indirizzo email del gruppo Google:
Ogni gruppo Google ha un indirizzo email univoco associato al gruppo. Ad esempio, il gruppo Annuncio di Cloud Storage ha il seguente indirizzo email: gs-announce@googlegroups.com. Puoi trovare l'indirizzo email associato a un gruppo Google facendo clic su Informazioni nella home page di ogni gruppo Google.
Come gli indirizzi email degli account utente, Cloud Storage memorizza gli indirizzi email dei gruppi così come vengono forniti negli ACL finché le voci non vengono rimosse. Non devi preoccuparti di aggiornare gli indirizzi email di Google Gruppi, perché gli indirizzi email di Google Gruppi sono permanenti ed è improbabile che cambino.
Valori di comodità per i progetti:
I valori di convenienza ti consentono di concedere l'accesso collettivo a visualizzatori, editor e proprietari del tuo progetto. I valori di convenienza combinano un ruolo di progetto e un numero di progetto associato. Ad esempio, nel progetto
867489160491
, gli editor sono identificati comeeditors-867489160491
. Puoi trovare il numero del tuo progetto nella home page della console Google Cloud.In genere dovresti evitare di utilizzare valori di convenienza negli ambienti di produzione, perché richiedono la concessione dei ruoli di base, una pratica sconsigliata negli ambienti di produzione.
Google Workspace o Cloud Identity:
I clienti di Google Workspace e Cloud Identity possono associare i propri account email a un nome di dominio internet. In questo caso, ciascun account email assumerà il formato USERNAME@YOUR_DOMAIN.com. Puoi specificare un ambito utilizzando qualsiasi nome di dominio internet associato a Google Workspace o Cloud Identity.
Identità forza lavoro:
Federazione delle identità per la forza lavoro consente di utilizzare un provider di identità (IdP) esterno per autenticare e autorizzare un gruppo di utenti utilizzando IAM, in modo che gli utenti possano accedere ai servizi Google Cloud.
Autorizzazioni e ambiti concentrici
Quando specifichi gli ACL in Cloud Storage, non è necessario elencare più ambiti per concedere più autorizzazioni. Cloud Storage utilizza autorizzazioni
concentriche, quindi quando concedi l'autorizzazione WRITER
, concedi anche l'autorizzazione READER
e, se concedi l'autorizzazione OWNER
, concedi anche le autorizzazioni READER
e
WRITER
.
Quando si specifica un ACL, la maggior parte degli strumenti consente
di specificare più ambiti per la stessa voce. L'autorizzazione più permissiva è
l'accesso concesso all'ambito. Ad esempio, se fornisci due voci per un
utente, una con autorizzazione READER
e una con autorizzazione WRITER
per un bucket,
l'utente avrà l'autorizzazione WRITER
per il bucket.
Nell'API XML, non è possibile fornire due voci ACL con lo stesso ambito. Ad esempio, la concessione dell'autorizzazione READ
e dell'autorizzazione WRITE
a un utente per un bucket genera un errore. Concedi invece all'utente l'autorizzazione WRITE
, che
concede anche all'utente l'autorizzazione READ
.
ACL predefiniti
Un ACL predefinito, talvolta noto anche come ACL predefinito, è un alias di una serie di voci ACL specifiche che puoi utilizzare per applicare rapidamente molte voci ACL contemporaneamente a un bucket o un oggetto.
La tabella seguente elenca gli ACL predefiniti e mostra quali voci ACL sono applicate a ogni ACL predefinito. Quando utilizzi la tabella seguente, tieni presente che:
Il gruppo di proprietari del progetto detiene la proprietà dei bucket del progetto e l'utente che crea un oggetto ne detiene la proprietà. Se un oggetto è stato creato da un utente anonimo, il gruppo dei proprietari del progetto ne detiene la proprietà.
Nella tabella vengono utilizzate le descrizioni delle autorizzazioni dell'API JSON,
OWNER
,WRITER
eREADER
. Gli ambiti equivalenti dell'API XML sonoFULL_CONTROL
,WRITE
eREAD
.API JSON/ gcloud storage
API XML Descrizione private
private
Concede al proprietario del bucket o dell'oggetto l'autorizzazione OWNER
per un bucket o un oggetto.bucketOwnerRead
bucket-owner-read
Concede al proprietario dell'oggetto l'autorizzazione OWNER
e al proprietario del bucket l'autorizzazioneREADER
. Viene utilizzato solo con gli oggetti.bucketOwnerFullControl
bucket-owner-full-control
Concede l'autorizzazione OWNER
ai proprietari dell'oggetto e del bucket. Questa opzione viene utilizzata solo con gli oggetti.projectPrivate
project-private
Concede l'autorizzazione al team di progetto in base ai suoi ruoli. Chiunque faccia parte del team ha l'autorizzazione READER
. I proprietari del progetto e gli editor del progetto hanno l'autorizzazioneOWNER
. Questo è l'ACL predefinito per i bucket appena creati. Questo è anche l'ACL predefinito per gli oggetti appena creati, a meno che l'ACL dell'oggetto predefinito per il bucket in questione non sia stato modificato.authenticatedRead
authenticated-read
Concede l'autorizzazione OWNER
al proprietario del bucket o dell'oggetto e a tutti i proprietari di account utente autenticati l'autorizzazioneREADER
.publicRead
public-read
Concede al proprietario del bucket o dell'oggetto l'autorizzazione OWNER
e a tutti gli utenti, autenticati e anonimi, l'autorizzazioneREADER
. Quando si applica a un oggetto, chiunque su internet può leggere l'oggetto senza eseguire l'autenticazione. Quando si applica a un bucket, chiunque su internet può elencare gli oggetti senza eseguire l'autenticazione.* Vedere la nota alla fine della tabella sulla memorizzazione nella cache.
publicReadWrite
public-read-write
Concede al proprietario del bucket l'autorizzazione OWNER
e a tutti gli utenti, autenticati e anonimi, le autorizzazioniREADER
eWRITER
. Questo ACL si applica solo ai bucket. Quando la applichi a un bucket, chiunque su internet può elencare, creare, sostituire ed eliminare gli oggetti senza eseguire l'autenticazione.
* Vedere la nota alla fine della tabella sulla memorizzazione nella cache.
* Per impostazione predefinita, gli oggetti leggibili pubblicamente vengono pubblicati con un'intestazione Cache-Control
che consente di memorizzare gli oggetti nella cache per 3600 secondi. Se hai bisogno di
assicurarti che gli aggiornamenti diventino visibili immediatamente, devi
impostare i metadati Cache-Control
degli oggetti su
Cache-Control:private, max-age=0, no-transform
.
ACL predefiniti
Quando vengono creati i bucket o vengono caricati gli oggetti, se non assegni loro un ACL in modo esplicito, verrà loro assegnato l'ACL predefinito. Puoi modificare l'ACL predefinito assegnato a un oggetto. La procedura per farlo è descritta nella sezione Modifica degli ACL degli oggetti predefiniti. Tieni presente che quando modifichi l'ACL predefinito, gli ACL degli oggetti già esistenti nel bucket o nei bucket già esistenti nel progetto rimangono invariati.
ACL dei bucket predefiniti
Tutti i bucket sono di proprietà del gruppo di proprietari del progetto. Inoltre, ai proprietari del progetto viene concessa l'autorizzazione OWNER
per tutti i bucket all'interno del loro progetto che utilizzano un ACL predefinito.
Se crei un bucket con l'ACL predefinito del bucket, ovvero non specifichi un ACL predefinito durante la creazione del bucket, al bucket è applicato l'ACL projectPrivate
predefinito.
ACL degli oggetti predefiniti
Per impostazione predefinita, chiunque abbia l'autorizzazione OWNER
o WRITER
su un bucket può caricare oggetti in quel bucket. Quando carichi un oggetto, puoi fornire un ACL predefinito o non specificare alcun ACL. Se non specifichi un ACL, Cloud Storage applica all'oggetto l'ACL predefinito degli oggetti del bucket. Ogni bucket ha un ACL degli oggetti predefinito che viene applicato a tutti gli oggetti caricati in quel bucket senza un ACL predefinito o un ACL specificato nella richiesta (solo API JSON). Il valore iniziale per l'ACL degli oggetti predefinito di ogni bucket è projectPrivate
.
In base a come vengono caricati gli oggetti, gli ACL degli oggetti vengono applicati di conseguenza:
Caricamenti autenticati
Se effettui una richiesta autenticata di caricamento di un oggetto e non specifichi nessun ACL di oggetto quando lo carichi, il tuo nome viene indicato come proprietario dell'oggetto e l'ACL
projectPrivate
predefinito viene applicato all'oggetto per impostazione predefinita. Ciò significa che:Tu (la persona che ha caricato l'oggetto) sei indicato come proprietario dell'oggetto. La proprietà degli oggetti non può essere modificata modificando gli ACL. Puoi modificare la proprietà dell'oggetto solo sostituendo un oggetto.
In qualità di proprietario dell'oggetto, hai ottenuto l'autorizzazione
OWNER
per l'oggetto. Se tenti di concedere un'autorizzazione inferiore aOWNER
al proprietario, Cloud Storage riassegna automaticamente l'autorizzazione aOWNER
.Il gruppo dei proprietari del progetto e degli editor del progetto dispone dell'autorizzazione
OWNER
per l'oggetto.Il gruppo dei membri del team del progetto dispone dell'autorizzazione
READER
per l'oggetto.
Caricamenti anonimi
Se un utente non autenticato (anonimo) carica un oggetto, come è possibile se un bucket concede l'autorizzazione
WRITER
oOWNER
al gruppoallUsers
, gli ACL del bucket predefiniti vengono applicati all'oggetto come descritto sopra.Gli utenti anonimi non possono specificare un ACL predefinito durante il caricamento degli oggetti.
Comportamento ACL
Cloud Storage ti consente di rispettare le best practice applicando alcune regole di modifica degli ACL, che ti impediscono di impostare ACL che rendono i dati inaccessibili:
Non puoi applicare un ACL che specifica un bucket o un proprietario dell'oggetto diverso.
La proprietà di bucket e oggetti non può essere modificata modificando gli ACL. Se applichi un nuovo ACL a un bucket o un oggetto, assicurati che il proprietario del bucket o dell'oggetto rimanga invariato nel nuovo ACL.
Il proprietario del bucket o dell'oggetto ha sempre l'autorizzazione
OWNER
per il bucket o l'oggetto.Il proprietario di un bucket è il gruppo di proprietari del progetto e il proprietario di un oggetto è l'utente che ha caricato l'oggetto o il gruppo di proprietari del progetto se l'oggetto è stato caricato da un utente anonimo.
Quando applichi un nuovo ACL a un bucket o un oggetto, Cloud Storage aggiunge rispettivamente l'autorizzazione
OWNER
al proprietario del bucket o dell'oggetto se ometti le concessioni. Non concede al gruppo di proprietari del progetto l'autorizzazioneOWNER
per un oggetto (a meno che l'oggetto non sia stato creato da un utente anonimo), quindi devi includerlo esplicitamente.
Non puoi applicare ACL che modificano la proprietà di un bucket o di un oggetto (che non devono essere confusi con l'autorizzazione OWNER
). Una volta creati in Cloud Storage, la proprietà di bucket e oggetti è permanente. Tuttavia, puoi modificare in modo efficace la proprietà degli oggetti (ma non dei bucket) sostituendoli. La sostituzione è un'operazione di eliminazione,
seguita immediatamente da un'operazione di caricamento. Durante un'operazione di caricamento, la persona che esegue
il caricamento diventa il proprietario dell'oggetto. Tieni presente che, per sostituire un oggetto, la persona che esegue la sostituzione (e ne acquisisce la proprietà) deve disporre dell'autorizzazione WRITER
o OWNER
per il bucket in cui viene caricato l'oggetto.
Passaggi successivi
- Scopri come utilizzare gli ACL.
- Scopri come semplificare il controllo dell'accesso utilizzando l'accesso uniforme a livello di bucket.
- Scopri le best practice per l'utilizzo degli ACL.