Elenchi di controllo dell'accesso (ACL)

Utilizzo

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 di allUsers.

  • 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 come editors-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 e READER. Gli ambiti dell'API XML equivalenti sono FULL_CONTROL, WRITE e READ.

    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'autorizzazione READER. 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'autorizzazione OWNER. 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'autorizzazione READER.
    publicRead public-read Concede al proprietario del bucket o dell'oggetto l'autorizzazione OWNER 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 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 autorizzazioni READER e WRITER. 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 a OWNER al proprietario, Cloud Storage la riassegna automaticamente a OWNER.

    • 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 o OWNER del gruppo allUsers, 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'autorizzazione OWNER 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