Elenchi di controllo di accesso (ACL)

Vai agli esempi

Questa pagina fornisce una panoramica degli elenchi di controllo di accesso (ACL). Per conoscere altri modi di controllare l'accesso ai bucket e agli oggetti, consulta la Panoramica del controllo dell'accesso.

Vuoi utilizzare gli elenchi di controllo di accesso?

Nella maggior parte dei casi, Identity and Access Management (IAM) è il metodo consigliato per controllare l'accesso alle risorse. Fornisce il controllo degli accessi in tutto Google Cloud e consente di ereditare le autorizzazioni concesse alle risorse padre, come i progetti, da risorse figlio, come bucket e oggetti. Consulta la sezione relativa all'utilizzo delle autorizzazioni IAM per guide all'utilizzo di IAM in Cloud Storage.

IAM e ACL lavorano in tandem per concedere l'accesso ai bucket e agli oggetti: un utente deve avere solo l'autorizzazione da IAM o da un ACL per accedere a un bucket o a un oggetto.

È molto probabile che tu voglia utilizzare gli ACL se devi personalizzare l'accesso ai singoli oggetti all'interno di un bucket, poiché le autorizzazioni IAM si applicano a tutti gli oggetti all'interno di un bucket. Tuttavia, dovresti comunque utilizzare IAM per qualsiasi accesso che sia comune a tutti gli oggetti in un bucket, in quanto ciò riduce la quantità di micro-gestione che devi eseguire.

Che cos'è un elenco di controllo di accesso?

Un elenco di controllo di accesso (ACL) è un meccanismo che puoi utilizzare per definire chi ha accesso ai tuoi bucket e oggetti, nonché al loro livello di accesso. In Cloud Storage, puoi applicare gli ACL a singoli bucket e oggetti. Ogni ACL è formato da una o più voci. Una voce offre a un utente o a un gruppo specifico la possibilità di eseguire azioni specifiche. Ogni voce è composta da due informazioni:

  • Un'autorizzazione, che definisce le azioni che possono essere eseguite (ad esempio, leggere o scrivere).

  • Un ambito (a volte indicato come assegnatario), che definisce chi può eseguire le azioni specificate (ad esempio un utente o un gruppo di utenti specifico).

Ad esempio, supponiamo che tu abbia un bucket da cui vuoi che chiunque possa accedere agli oggetti, ma vuoi che il tuo collaboratore possa aggiungere o rimuovere oggetti dal bucket. In questo caso, l'ACL sarà costituito da due voci:

  • In una voce, concedi a READER l'autorizzazione a un ambito di allUsers.

  • Nell'altra voce, concedi a WRITER l'autorizzazione all'ambito del tuo collaboratore (ci sono diversi modi per specificare questa persona, ad esempio in base al 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 conteggiato come 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 il bucket o l'ACL 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 l'autorizzazione all'utente per l'operazione richiesta, la richiesta non riesce e viene restituito un errore 403 Forbidden.

Tieni presente che, mentre gli ACL possono essere utilizzati per gestire la maggior parte delle azioni che riguardano bucket e oggetti, la possibilità di creare un bucket deriva dall'autorizzazione al progetto appropriata.

Autorizzazioni

Le autorizzazioni descrivono cosa è possibile fare per un determinato oggetto o bucket.

Cloud Storage ti consente di assegnare le seguenti autorizzazioni concentriche per i bucket e gli oggetti, come mostrato 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 dei bucket, esclusi gli ACL. Consente a un utente di scaricare i dati di un oggetto.
WRITER Consente a un utente di elencare, creare, sostituire ed eliminare oggetti in un bucket 1. N/D. Non è possibile applicare questa autorizzazione agli oggetti.
OWNER Concede all'utente READER e WRITER le autorizzazioni per il bucket. Consente inoltre a un utente di leggere e scrivere metadati del bucket, inclusi gli ACL. Concede all'utente l'accesso READER. Consente inoltre a un utente di leggere e scrivere metadati di oggetti, inclusi gli ACL.
Predefinito Nei bucket, viene applicata l'ACL predefinito project-private quando vengono creati. I bucket sono sempre di proprietà del gruppo project-owners. Agli oggetti viene applicata l'ACL project-private predefinito quando vengono caricati. Gli oggetti sono sempre di proprietà del richiedente originale che ha caricato l'oggetto.

1 Non è possibile modificare le seguenti proprietà dei metadati del bucket: acl, cors, defaultObjectAcl, lifecycle, logging, versioning e website.

In questa pagina, di solito ci riferiamo alle autorizzazioni READER, WRITER e OWNER, ovvero al modo in cui sono specificate nell'API JSON e in Google Cloud Console. 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 l'autorizzazione) ad accedere all'API Google Cloud Storage per tuo conto, l'accesso è limitato dall'ambito OAuth devstorage.read_only, devstorage.read_write e devstorage.full_control. La tabella riportata di seguito riassume la terminologia delle autorizzazioni che solitamente riscontri:

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 ha una determinata autorizzazione.

Un ACL è costituito da una o più voci, dove ciascuna 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 Google Utente collaborator@gmail.com
Indirizzo email Google Gruppi Group work-group@googlegroups.com
Valori di convenienza per i progetti Progetto owners-123456789012
Dominio G Suite Dominio USERNAME@YOUR_DOMAIN.com
Dominio Cloud Identity Dominio USERNAME@YOUR_DOMAIN.com
Identificatore speciale per tutti i proprietari di Account Google Utente allAuthenticatedUsers
Identificatore speciale per tutti gli utenti Utente allUsers
  • Indirizzo email dell'Account Google:

    A ogni utente con un Account Google deve essere associato un indirizzo email univoco. Puoi specificare un ambito utilizzando un indirizzo email associato a un Account Google, ad esempio un indirizzo gmail.com.

    Cloud Storage memorizza gli indirizzi email così come vengono forniti negli ACL fino alla rimozione o sostituzione delle voci. Se un utente cambia gli indirizzi email, devi aggiornare le voci degli elenchi ACL per includere 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. Puoi trovare l'indirizzo email associato a un gruppo Google facendo clic su Informazioni sulla home page di ogni gruppo Google.

    Analogamente agli indirizzi email degli Account Google, Cloud Storage memorizza gli indirizzi email dei gruppi così come vengono forniti negli ACL fino alla rimozione delle voci. Non devi preoccuparti di aggiornare gli indirizzi email di Google Gruppi, perché gli indirizzi email di Google Gruppi sono permanenti e difficilmente cambiano.

  • Valori relativi alla comodità per i progetti:

    I valori di convenienza ti consentono di concedere l'accesso collettivo a visualizzatori, editor e proprietari dei tuoi progetti. I valori di convenienza combinano un ruolo di progetto e un numero di progetto associato. Ad esempio, nel progetto 867489160491 gli editor sono identificati come editors-867489160491. Puoi trovare il numero del tuo progetto nella home page di Google Cloud Console.

    In genere, evita di utilizzare valori di convenienza negli ambienti di produzione, poiché richiedono la concessione di ruoli di base, una pratica sconsigliata negli ambienti di produzione.

  • G Suite o Cloud Identity:

    I clienti di G Suite e Cloud Identity possono associare i loro account email a un nome di dominio Internet. In questo caso, ogni account email avrà il formato USERNAME@YOUR_DOMAIN.com. Puoi specificare un ambito utilizzando qualsiasi nome di dominio Internet associato a G Suite o Cloud Identity.

  • Identificatore speciale per tutti i proprietari di Account Google:

    Questo identificatore di ambito speciale rappresenta chiunque sia autenticato con un Account Google. L'identificatore dell'ambito speciale per tutti i proprietari di Account Google è allAuthenticatedUsers. Tieni presente che, sebbene questo identificatore sia un tipo di entità User, quando utilizzi la console è etichettato come tipo di entità Public.

  • Identificatore speciale per tutti gli utenti:

    Questo identificatore di ambito speciale rappresenta chiunque si trovi su Internet, con o senza un Account Google. L'identificatore dell'ambito speciale per tutti gli utenti è allUsers. Tieni presente che, sebbene questo identificatore sia un tipo di entità User, quando utilizzi la console è 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 le autorizzazioni concentriche, quindi quando concedi l'autorizzazione WRITER, concedi anche l'autorizzazione READER e, se concedi l'autorizzazione OWNER, concedi anche l'autorizzazione READER e WRITER.

Quando specifichi un ACL utilizzando Google Cloud Console, l'API JSON o gsutil, puoi 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 di un'autorizzazione utente READ e WRITE a un bucket genera un errore. Concedi all'utente l'autorizzazione WRITE, che a sua volta concede anche l'autorizzazione READ.

ACL predefiniti

Un ACL predefinito o "consociato" è un alias per un set di voci ACL specifiche che puoi utilizzare per applicare rapidamente più voci ACL a un bucket o oggetto.

La tabella riportata di seguito elenca gli ACL predefiniti e mostra quali voci ACL vengono applicate per ogni ACL predefinito. Quando utilizzi la tabella di seguito, tieni presente che:

  • Il gruppo di proprietari del progetto ha la proprietà dei bucket nel progetto e l'utente che crea un oggetto ha la proprietà di tale oggetto. Se un oggetto è stato creato da un utente anonimo, il gruppo di proprietari del progetto ha la proprietà dell'oggetto.

  • Nella tabella vengono utilizzate le descrizioni delle autorizzazioni JSON, OWNER, WRITER e READER. Gli ambiti API XML equivalenti sono FULL_CONTROL, WRITE e READ.

    API JSON API XML/gsutil Descrizione
    private private Concede l'autorizzazione OWNER al bucket o al proprietario dell'oggetto per un bucket o un oggetto.
    bucketOwnerRead bucket-owner-read Concede l'autorizzazione OWNER al proprietario dell'oggetto e all'autorizzazione READER del proprietario del bucket. Viene utilizzato solo con 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 loro ruoli. Chiunque faccia parte del team ha l'autorizzazione READER. I proprietari e gli editor del progetto dispongono dell'autorizzazione OWNER. Questo è l'ACL predefinito per i bucket appena creati. Si tratta anche dell'ACL predefinito per gli oggetti appena creati, a meno che l'ACL dell'oggetto predefinito per il bucket sia stato modificato.
    authenticatedRead authenticated-read Concede l'autorizzazione OWNER al bucket o al proprietario dell'oggetto e a tutti i proprietari autenticati dell'Account Google READER.
    publicRead public-read Concede l'autorizzazione OWNER al bucket o al proprietario dell'oggetto e a tutti gli utenti, sia autenticati che anonimi, l'autorizzazione READER. Quando lo applichi a un oggetto, chiunque su Internet può leggere l'oggetto senza effettuare l'autenticazione. Quando lo applichi a un bucket, chiunque su Internet può elencare gli oggetti senza eseguire l'autenticazione.

    * 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 fornisce a tutti gli utenti, sia autenticati che anonimi, l'autorizzazione READER e WRITER. Questo ACL si applica solo ai bucket. Quando applichi questo criterio a un bucket, chiunque su Internet può elencare, creare, sostituire ed eliminare 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 pubblicati con un'intestazione Cache-Control che consente di memorizzare gli oggetti nella cache per 3600 secondi. Se devi assicurarti che gli aggiornamenti diventino immediatamente visibili, 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 vengono caricati oggetti, se non assegni loro esplicitamente un ACL, verrà assegnato loro l'ACL predefinito. Puoi modificare l'ACL predefinito assegnato a un oggetto; la procedura è descritta nella sezione Modificare gli 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 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 del progetto che utilizzano un'ACL predefinita.

Se crei un bucket con il bucket ACL predefinito, ovvero non specifichi un ACL predefinito quando crei il bucket, al bucket è applicato l'ACL predefinito projectPrivate.

ACL di oggetto predefiniti

Per impostazione predefinita, chiunque disponga dell'autorizzazione OWNER o di WRITER per un bucket può caricare oggetti in quel bucket. Quando carichi un oggetto, puoi fornire un ACL predefinito oppure non specificarne affatto. Se non specifichi un ACL, Cloud Storage applica all'oggetto l'ACL dell'oggetto predefinito del bucket. Ogni bucket ha un oggetto ACL predefinito e questo ACL viene applicato a tutti gli oggetti caricati in tale bucket senza un ACL predefinito o un ACL specificato nella richiesta (solo API JSON). Il valore iniziale per l'ACL dell'oggetto predefinito di ogni bucket è projectPrivate.

A seconda di come vengono caricati gli oggetti, gli ACL degli oggetti vengono applicati di conseguenza:

  • Caricamenti autenticati

    Se esegui una richiesta autenticata per il caricamento di un oggetto e non specifichi alcun ACL degli oggetti quando lo carichi, verrà indicato come proprietario dell'oggetto e l'ACL projectPrivate predefinito verrà applicato all'oggetto per impostazione predefinita. Ciò significa che:

    • Tu (la persona che ha caricato l'oggetto) sei indicato come proprietario dell'oggetto. Non è possibile cambiare la proprietà dell'oggetto modificando gli ACL. Puoi cambiare la proprietà dell'oggetto solo sostituendo un oggetto.

    • A te (il proprietario dell'oggetto) viene concessa l'autorizzazione OWNER per l'oggetto. Se tenta di concedere un'autorizzazione inferiore a OWNER al proprietario, Cloud Storage riassegna automaticamente l'autorizzazione a OWNER.

    • I proprietari del progetto e il gruppo di editor del progetto dispongono dell'autorizzazione OWNER per l'oggetto.

    • Il gruppo di membri del team di progetto dispone dell'autorizzazione READER per l'oggetto.

  • Caricamenti anonimi

    Se un utente non autenticato carica un oggetto (il che è possibile) se un bucket concede l'autorizzazione WRITER o OWNER del gruppo allUsers, gli ACL dei bucket predefiniti vengono applicati all'oggetto come descritto sopra.

    Gli utenti anonimi non possono specificare un ACL predefinito durante il caricamento di oggetti.

Comportamento ACL

Cloud Storage ti aiuta a rispettare le best practice applicando alcune regole di modifica ACL, che impediscono l'impostazione di ACL che rendono inaccessibili i dati:

  • Non è possibile applicare un ACL che specifica un bucket o un proprietario dell'oggetto diverso.

    Non è possibile modificare la proprietà di bucket e oggetti modificando gli ACL. Se applichi un nuovo ACL a un bucket o a un oggetto, assicurati che il bucket o il proprietario dell'oggetto rimanga invariato nel nuovo ACL.

  • Il bucket o l'oggetto ha sempre l'autorizzazione OWNER per il bucket o l'oggetto.

    Il proprietario di un bucket è il gruppo di proprietari del progetto, mentre il proprietario di un oggetto è l'utente che ha caricato l'oggetto oppure il gruppo dei 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 bucket o al proprietario dell'oggetto se ometti le autorizzazioni. Non concede al gruppo di proprietari del progetto OWNER l'autorizzazione per un oggetto (a meno che l'oggetto non sia stato creato da un utente anonimo), quindi devi includerlo esplicitamente.

Non puoi applicare gli ACL che modificano la proprietà di un bucket o un oggetto (che non deve essere confuso con l'autorizzazione OWNER). Una volta creati in Cloud Storage, la proprietà del bucket e dell'oggetto è permanente. Tuttavia, puoi modificare in modo efficace la proprietà degli oggetti (ma non i bucket) sostituendoli. La sostituzione è sostanzialmente un'operazione di eliminazione seguita immediatamente da un'operazione di caricamento. Durante un'operazione di caricamento, la persona che la esegue è il proprietario dell'oggetto. Tieni presente che per sostituire un oggetto, la persona che esegue la sostituzione (e acquisirà la proprietà dell'oggetto in questo modo) deve avere l'autorizzazione WRITER o OWNER per il bucket in cui l'oggetto viene caricato.

Passaggi successivi