Questa pagina fornisce una panoramica degli elenchi di controllo dell'accesso (ACL). Per scoprire altri modi per controllare l'accesso ai bucket e agli oggetti, consulta la Panoramica del controllo dell'accesso.
Come utilizzare 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 a tutti i servizi Google Cloud.
- IAM ha un maggiore controllo sulle azioni che gli utenti sono autorizzati a eseguire.
- Le autorizzazioni IAM concesse alle risorse padre, ad esempio i progetti, vengono ereditate dalle risorse figlio, come bucket e oggetti, consentendo di 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, poiché non è possibile impostare ACL sul progetto complessivo o su altre risorse padre.
L'utilizzo esclusivo di IAM e l'abilitazione dell'accesso uniforme a livello di bucket ti consente di utilizzare altre funzionalità di sicurezza di Google Cloud, come la condivisione limitata per i domini, la federazione delle identità per la forza lavoro e le condizioni IAM.
È molto probabile che tu voglia utilizzare gli ACL nei seguenti casi:
- Devi personalizzare l'accesso ai singoli oggetti all'interno di un bucket. È possibile impostare ACL per singoli oggetti, mentre le autorizzazioni IAM possono essere concesse solo a livello di bucket o superiore.
- Stai utilizzando esclusivamente l'API XML o hai bisogno dell'interoperabilità con Amazon S3.
IAM e ACL funzionano in tandem per concedere l'accesso ai bucket e agli oggetti, il che significa che un utente deve solo ottenere l'autorizzazione pertinente da uno di questi sistemi per accedere a un bucket o a 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 bucket e agli oggetti, nonché il relativo livello di accesso. In Cloud Storage, applichi gli ACL a singoli bucket e oggetti. Ogni ACL è costituito da una o più voci. Una voce consente a un utente (o a un gruppo) specifico di eseguire azioni specifiche. 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 grantee), 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 consentire a chiunque di accedere agli oggetti, ma che vuoi anche che il collaboratore possa aggiungere o rimuovere oggetti dal bucket. In questo caso, l'ACL è costituito da due voci:
In una voce, assegneresti l'autorizzazione
READER
a 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 la sua email.
Il numero massimo di voci ACL che puoi creare per un bucket o un oggetto è 100. Quando l'ambito delle voci è un gruppo o un dominio, viene conteggiata una sola voce ACL indipendentemente dal numero di utenti presenti 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 rifiutare 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 va a buon fine 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 disponibilità dell'autorizzazione per il progetto appropriata.
Autorizzazioni
Le autorizzazioni descrivono cosa è possibile fare su un determinato oggetto o bucket.
Cloud Storage consente di assegnare le seguenti autorizzazioni concentriche per i bucket e gli oggetti, come illustrato nella seguente tabella:
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 . Consente inoltre a un utente di creare, sostituire ed eliminare
gli oggetti in un bucket, compresa la creazione di oggetti mediante caricamenti
multiparte. |
N/D. Non è possibile 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 i 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. |
Predefinito | Ai bucket viene applicato l'ACL predefinito project-private al momento della creazione. I bucket sono sempre di proprietà del gruppo project-owners . |
Agli oggetti viene applicato l'ACL predefinito project-private quando vengono caricati. Gli oggetti sono sempre di proprietà del richiedente originale che li ha caricati. |
In questa pagina in genere facciamo riferimento alle autorizzazioni READER
, WRITER
e OWNER
, ovvero come vengono specificate nell'API JSON e nella console Google Cloud. Se utilizzi l'API XML, le autorizzazioni equivalenti sono rispettivamente READ
, WRITE
e FULL_CONTROL
. Inoltre, quando
utilizzi l'autenticazione OAuth 2.0 per autenticare gli strumenti e le applicazioni
(concedere loro l'autorizzazione) per accedere a Cloud Storage per tuo conto, l'accesso è limitato dall'ambito OAuth devstorage.read_only
,
devstorage.read_write
e devstorage.full_control
. La seguente tabella riassume la terminologia relativa alle autorizzazioni che riscontri comunemente:
API JSON | API XML | Ambito OAuth2 |
---|---|---|
READER |
READ |
https://www.googleapis.com/auth/devstorage.read_only |
WRITER |
WRITE |
https://www.googleapis.com/auth/devstorage.read_write |
OWNER |
FULL_CONTROL |
https://www.googleapis.com/auth/devstorage.full_control |
Ambiti
Gli ambiti specificano chi è l'utente che ha una determinata autorizzazione.
Un ACL è costituito da una o più voci, in cui ogni voce concede le autorizzazioni per un ambito. Puoi specificare un ambito ACL utilizzando una delle seguenti entità:
Ambito ("grantee") | Tipi di entità | Esempio |
---|---|---|
Indirizzo email dell'account utente | Utente | collaborator@gmail.com |
Indirizzo email di un gruppo Google | Gruppo | work-group@googlegroups.com |
Valori di comodità per i progetti | Project | owners-123456789012 |
Dominio Google Workspace | Dominio | USERNAME@YOUR_DOMAIN.com |
Dominio Cloud Identity | Dominio | USERNAME@YOUR_DOMAIN.com |
Identificatore speciale per tutti gli account validi | Utente | allAuthenticatedUsers |
Identificatore speciale per tutte le entità | Utente | allUsers |
Indirizzo email dell'account utente:
Ogni utente che dispone di un account utente deve avere un indirizzo email univoco associato a tale account. Puoi specificare un ambito utilizzando qualsiasi indirizzo email associato a un account utente.
Cloud Storage memorizza gli indirizzi email così come vengono forniti negli ACL, fino a quando le voci non vengono rimosse o sostituite. Se un utente modifica gli indirizzi email, devi aggiornare le voci ACL per riflettere queste modifiche.
Indirizzo email del gruppo Google:
Ogni gruppo Google ha un indirizzo email univoco associato al gruppo. Ad esempio, il gruppo Annuncio Cloud Storage ha il seguente indirizzo email: gs-announce@googlegroups.com. Per trovare l'indirizzo email associato a un gruppo Google, fai clic su Informazioni nella home page di ogni gruppo Google.
Analogamente agli 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 preoccuparti di aggiornare gli indirizzi email di Google Gruppi, perché gli indirizzi email di Google Gruppi sono permanenti e probabilmente non cambiano.
Valori di convenienza per i progetti:
I valori di comodità ti consentono di concedere l'accesso collettivo a visualizzatori, editor e proprietari del 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 progetto nella home page della console Google Cloud.In genere è consigliabile evitare di utilizzare valori di convenienza negli ambienti di produzione, in quanto richiedono la concessione di ruoli di base, una pratica sconsigliata negli ambienti di produzione.
Google Workspace o Cloud Identity:
I clienti Google Workspace e Cloud Identity possono associare i propri account email a un nome di dominio internet. Quando esegui questa operazione, ogni account email ha il formato USERNAME@YOUR_DOMAIN.com. Puoi specificare un ambito utilizzando qualsiasi nome di dominio internet associato a Google Workspace o Cloud Identity.
Identificatore speciale per tutti gli account validi:
L'identificatore di ambito speciale
allAuthenticatedUsers
rappresenta la maggior parte degli account autenticati, inclusi gli account di servizio. Per ulteriori informazioni, consulta la panoramica IAM. Tieni presente che sebbene questo identificatore sia un tipo di entitàUser
, quando utilizzi la console Google Cloud è etichettato come un tipo di entitàPublic
.Identificatore speciale per tutte le entità:
L'identificatore di ambito speciale
allUsers
rappresenta qualsiasi entità su internet. Tieni presente che sebbene questo identificatore sia un tipo di entitàUser
, quando utilizzi la console Google Cloud è etichettato come tipo di entitàPublic
.
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; pertanto, se concedi l'autorizzazione WRITER
, concedi anche l'autorizzazione READER
e, se concedi l'autorizzazione OWNER
, concedi anche le autorizzazioni READER
e WRITER
.
Quando specifichi 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
in 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 a un utente delle autorizzazioni READ
e WRITE
per
un bucket genera un errore. Devi invece concedere all'utente l'autorizzazione WRITE
, che
concede anche all'utente l'autorizzazione READ
.
ACL predefiniti
Un ACL predefinito, a volte noto anche come ACL predefinito, è un alias per un insieme di voci ACL specifiche che puoi utilizzare per applicare rapidamente molte voci ACL contemporaneamente a un bucket o a un oggetto.
La tabella seguente elenca gli ACL predefiniti e mostra le voci ACL applicate per ciascun ACL predefinito. Quando utilizzi la tabella seguente, tieni presente che:
Il gruppo di proprietari del progetto è proprietario dei bucket del progetto e l'utente che crea un oggetto ne è proprietario. Se un oggetto è stato creato da un utente anonimo, il gruppo di proprietari del progetto ne sarà proprietario.
Nella tabella vengono utilizzate le descrizioni dell'API JSON delle autorizzazioni
OWNER
,WRITER
eREADER
. Gli ambiti dell'API XML equivalenti 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 l'autorizzazione OWNER
al proprietario dell'oggetto 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. Viene utilizzato solo con gli oggetti.projectPrivate
project-private
Concede l'autorizzazione al team di progetto in base ai suoi ruoli. Tutti i membri del team hanno l'autorizzazione READER
. I proprietari e gli editor del progetto dispongono dell'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 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, sia autenticati che anonimi, l'autorizzazioneREADER
. Quando lo applichi a un oggetto, chiunque su internet può leggere l'oggetto senza eseguire l'autenticazione. Se la applichi a un bucket, chiunque su internet può elencare gli oggetti senza autenticarsi.* Vedi la nota alla fine della tabella relativa alla memorizzazione nella cache.
publicReadWrite
public-read-write
Concede l'autorizzazione OWNER
al proprietario del bucket e a tutti gli utenti, sia autenticati che anonimi, le autorizzazioniREADER
eWRITER
. Questo ACL si applica solo ai bucket. Quando applichi questo comando a un bucket, chiunque su internet può elencare, creare, sostituire ed eliminare gli oggetti senza eseguire l'autenticazione.
* Vedi la nota alla fine della tabella relativa alla memorizzazione nella cache.
* Per impostazione predefinita, gli oggetti leggibili pubblicamente vengono forniti con un'intestazione Cache-Control
che consente di memorizzare nella cache per 3600 secondi. Se devi
assicurarti che gli aggiornamenti diventino visibili immediatamente, devi
impostare i metadati Cache-Control
per gli oggetti su
Cache-Control:private, max-age=0, no-transform
.
ACL predefiniti
Quando vengono creati bucket o caricati oggetti, se non assegni esplicitamente un ACL, verrà loro assegnato l'ACL predefinito. Puoi modificare l'ACL predefinito assegnato a un oggetto; il processo è descritto in Modificare gli ACL degli oggetti predefiniti. Tieni presente che, quando modifichi l'ACL predefinito, gli ACL degli oggetti già presenti nel bucket o nei bucket già presenti nel progetto rimangono invariati.
ACL predefiniti dei bucket
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 devi specificare un ACL predefinito quando crei il bucket, al bucket è applicato l'ACL projectPrivate
predefinito.
ACL degli oggetti predefiniti
Per impostazione predefinita, chiunque abbia l'autorizzazione OWNER
o WRITER
per un bucket
può caricare oggetti in quel bucket. Quando carichi un oggetto, puoi fornire un ACL predefinito o non specificarne uno. Se non specifichi un ACL, Cloud Storage applica l'ACL predefinito del bucket all'oggetto. Ogni bucket ha un ACL oggetto 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 dell'ACL dell'oggetto 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 per caricare un oggetto e non specifichi alcun ACL degli oggetti quando lo carichi, sei indicato come proprietario dell'oggetto e l'ACL predefinito
projectPrivate
viene applicato all'oggetto per impostazione predefinita. Ciò significa che:Tu (la persona che ha caricato l'oggetto) risulti indicato come proprietario dell'oggetto. La proprietà degli oggetti non può essere modificata modificando gli ACL. Puoi modificare la proprietà di un oggetto solo sostituendolo.
A te, in qualità di proprietario dell'oggetto, viene concessa l'autorizzazione
OWNER
per l'oggetto. Se cerchi di concedere un'autorizzazione inferiore aOWNER
al proprietario, Cloud Storage la riassegna automaticamente 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 ha l'autorizzazione
READER
per l'oggetto.
Caricamenti anonimi
Se un utente non autenticato (anonimo) carica un oggetto, operazione possibile se un bucket concede l'autorizzazione
WRITER
oOWNER
del gruppoallUsers
, gli ACL predefiniti del bucket 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 aiuta a rispettare le best practice applicando alcune regole di modifica degli ACL, che 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 a un oggetto, assicurati che il proprietario del bucket o dell'oggetto rimanga invariato nel nuovo ACL.
Il proprietario del bucket o dell'oggetto dispone sempre dell'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 a un oggetto, Cloud Storage aggiunge rispettivamente l'autorizzazione
OWNER
al bucket o al proprietario 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 deve essere confusa 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 è essenzialmente un'operazione
di eliminazione seguita immediatamente da un'operazione di caricamento. Durante un'operazione, l'utente che esegue il caricamento
diventa il proprietario dell'oggetto. Tieni presente che per sostituire un
oggetto, la persona che esegue la sostituzione (e ottenendo la proprietà dell'oggetto
in questo modo) deve disporre dell'autorizzazione WRITER
o OWNER
per il bucket in cui l'oggetto viene caricato.
Passaggi successivi
- Scopri come utilizzare gli ACL.
- Scopri come semplificare il controllo dell'accesso mediante l'accesso uniforme a livello di bucket.
- Scopri le best practice per l'utilizzo degli ACL.