elenchi di controllo dell'accesso (ACL)

Utilizzo

Questa pagina fornisce una panoramica degli elenchi di controllo dell'accesso (ACL), che ti consentono di controllare l'accesso a singoli bucket o oggetti. Per scoprire altri modi per controllare l'accesso a bucket e oggetti, leggi Panoramica del controllo dell'accesso.

Quando utilizzare gli elenchi di controllo dell'accesso?

Nella maggior parte dei casi, devi evitare di utilizzare gli ACL e devi attivare l'accesso uniforme a livello di bucket per i tuoi bucket, il che impedisce l'utilizzo degli ACL:

  • Le ACL non possono essere utilizzate esclusivamente per controllare l'accesso alle tue risorse Google Cloud, perché non possono essere impostate sull'intero progetto o sulle risorse esterne a Cloud Storage.
  • L'attivazione dell'accesso uniforme a livello di bucket crea una superficie di controllo dell'accesso più semplice e ti consente di utilizzare funzionalità Google Cloud aggiuntive. Per saperne di più, consulta Quando utilizzare l'accesso uniforme a livello di bucket.
  • La policy dell'organizzazione Condivisione limitata per i domini e le policy dell'organizzazione personalizzate non impediscono l'accesso concesso dalle ACL, il che potrebbe portare ad accessi indesiderati.
  • Quando utilizzi gli elenchi di controllo dell'accesso nei progetti in cui sono impostate condizioni IAM a livello di progetto o superiore, possono verificarsi comportamenti e accessi imprevisti.

Molto probabilmente vorrai utilizzare gli ACL nei seguenti casi:

  • Devi personalizzare l'accesso ai singoli oggetti all'interno di un bucket, ad esempio se vuoi che l'utente che carica un oggetto abbia il controllo completo su quell'oggetto, ma un accesso ridotto agli altri oggetti nel bucket.
  • Utilizzi esclusivamente l'API XML o hai bisogno dell'interoperabilità con Amazon S3.

Che cos'è un elenco di controllo dell'accesso?

Un elenco di controllo dell'accesso (ACL) è un meccanismo che puoi utilizzare per definire chi ha accesso ai tuoi bucket e ai tuoi oggetti, nonché il livello di accesso. In Cloud Storage, gli ACL vengono applicati a singoli bucket e oggetti. Ogni ACL è composta da una o più voci. Una voce concede a un utente (o gruppo) specifico la possibilità 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 beneficiario), 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 anche che il tuo collaboratore possa aggiungere o rimuovere oggetti dal bucket. In questo caso, la tua ACL sarà composta da due voci:

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

  • Nell'altra voce, concedi l'autorizzazione WRITER all'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 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 l'ACL del bucket o dell'oggetto e determina se consentire o rifiutare la richiesta di accesso. Se la ACL concede all'utente l'autorizzazione per l'operazione richiesta, la richiesta viene consentita. Se la lista di controllo degli accessi non concede all'utente l'autorizzazione dell'utente per l'operazione richiesta, la richiesta non va a buon fine e viene restituito un errore 403 Forbidden.

Tieni presente che, sebbene le ACL possano essere utilizzate per gestire la maggior parte delle azioni che coinvolgono bucket e oggetti, la possibilità di creare un bucket deriva dal possesso della autorizzazione di progetto appropriata.

Autorizzazioni

Le autorizzazioni descrivono cosa può essere fatto a un determinato oggetto o bucket.

Cloud Storage ti consente di assegnare le seguenti autorizzazioni concentriche per i bucket e gli oggetti, come mostrato 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 tutto l'accesso concesso 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 i metadati del bucket, incluse le ACL, e di lavorare con i tag sul bucket. Concede a un utente tutto l'accesso concesso dall'autorizzazione READER. Consente inoltre a un utente di leggere e scrivere i metadati degli oggetti, inclusi gli ACL.
Predefinito I bucket hanno l'ACL project-private predefinita quando vengono creati. 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 ci riferiamo alle autorizzazioni come READER, WRITER e OWNER, che sono il modo in cui vengono specificate nell'API JSON e nella Google Cloud console. Se utilizzi l'API XML, le autorizzazioni equivalenti sono rispettivamente READ, WRITE e FULL_CONTROL.

Ambiti

Gli ambiti specificano chi dispone di una determinata autorizzazione.

Un'ACL è costituita da una o più voci, ognuna delle quali concede autorizzazioni a un ambito. Puoi specificare un ambito ACL utilizzando una delle seguenti entità:

Ambito ("beneficiario") Tipo/i di entità Esempio
Identificatore speciale per tutte le entità Utente allUsers
Identificatore speciale per tutti gli account validi Utente allAuthenticatedUsers
Indirizzo email dell'account utente Utente jeffersonloveshiking@gmail.com
Indirizzo email del service account Utente my-service-account@my-project.iam.gserviceaccount.com
Indirizzo email del gruppo Google Gruppo work-group@googlegroups.com
Valori di convenienza per i progetti Progetto owners-123456789012
Dominio Google Workspace Dominio dana@example.com
Dominio Cloud Identity Dominio dana@example.com

  • 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 , viene etichettato come tipo di entità Public.

  • Identificatore speciale per tutti gli account validi:

    L'identificatore di ambito speciale allAuthenticatedUsers rappresenta la maggior parte degli account autenticati, inclusi i service account. Per saperne di più, consulta Entità IAM. Tieni presente che, sebbene questo identificatore sia un tipo di entità User, quando utilizzi la console Google Cloud viene etichettato come tipo di entità Public.

  • Indirizzo email dell'account utente:

    Ogni utente che dispone di un account utente deve avere un indirizzo email univoco associato a quell'account. Puoi specificare un ambito utilizzando qualsiasi indirizzo email associato a un account utente.

    Cloud Storage memorizza gli indirizzi email così come vengono forniti nelle ACL finché le voci non vengono rimosse o sostituite. Se un utente cambia indirizzo email, devi aggiornare le voci ACL in modo da riflettere queste modifiche.

  • Indirizzo email del service account:

    A ogni service account è associato un indirizzo email univoco. Puoi specificare un ambito utilizzando l'indirizzo email associato al service account.

  • Indirizzo email del gruppo Google:

    Ogni gruppo Google ha un indirizzo email univoco associato al gruppo. Ad esempio, il gruppo Cloud Storage Announce 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 dei gruppi Google, perché sono permanenti ed è improbabile che cambino.

  • Valori di convenienza per i progetti:

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

    In genere, dovresti evitare di utilizzare i valori di convenienza negli ambienti di produzione, perché richiedono la concessione di 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 modo, ogni account email assume la forma USERNAME@YOUR_DOMAIN.com. Puoi specificare un ambito utilizzando qualsiasi nome di dominio internet associato a Google Workspace o Cloud Identity.

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 specifichi un ACL, la maggior parte degli strumenti ti 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 l'autorizzazione READER e una con l'autorizzazione WRITER su un bucket, l'utente avrà l'autorizzazione WRITER sul bucket.

Nell'API XML non è possibile fornire due voci ACL con lo stesso ambito. Ad esempio, la concessione a un utente dell'autorizzazione READ e dell'autorizzazione WRITE su un bucket genera un errore. Concedi invece all'utente l'autorizzazione WRITE, che concede anche l'autorizzazione READ.

ACL e IAM

Identity and Access Management (IAM) e gli ACL funzionano in tandem 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 a un oggetto. In generale, le autorizzazioni concesse dai criteri IAM non vengono visualizzate negli ACL e le autorizzazioni concesse dagli ACL non vengono visualizzate nei criteri IAM. Per saperne di più, consulta Relazione di IAM con gli ACL.

Comportamento con i criteri di negazione IAM

Una policy di negazione IAM sostituisce qualsiasi accesso applicabile che altrimenti verrebbe concesso da un ACL che hai impostato, quando la policy di negazione e l'ACL hanno come target la stessa autorizzazione.

Ad esempio, se un progetto ha una policy di negazione che impedisce a un utente di disporre dell'autorizzazione storage.objects.get e crei un elenco di controllo degli accessi che concede all'utente il ruolo READER su un oggetto all'interno di un bucket in quel progetto, l'utente non potrà visualizzare l'oggetto nel bucket. Tuttavia, se la policy di negazione specifica l'autorizzazione storage.buckets.get e l'ACL concede il ruolo WRITER sul bucket, l'utente non potrà recuperare i metadati del bucket, ma potrà comunque elencare, creare ed eliminare oggetti nel bucket.

ACL predefinite

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 più voci ACL contemporaneamente a un bucket o a un oggetto.

La tabella seguente elenca gli ACL predefiniti e mostra le voci ACL applicate per ogni ACL predefinito. Quando utilizzi la tabella, tieni presente che:

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

  • Nella tabella vengono utilizzate le descrizioni dell'API JSON delle autorizzazioni OWNER, WRITER e READER. Gli ambiti 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 al proprietario dell'oggetto l'autorizzazione OWNER e al proprietario del bucket l'autorizzazione READER. Questo attributo viene utilizzato solo con gli oggetti.
    bucketOwnerFullControl bucket-owner-full-control Concede l'autorizzazione OWNER ai proprietari dell'oggetto e del bucket. Questo viene utilizzato solo con gli oggetti.
    projectPrivate project-private Concede l'autorizzazione al team di progetto in base ai suoi ruoli. Chiunque faccia parte del team dispone dell'autorizzazione READER. I proprietari e gli editor del progetto dispongono dell'autorizzazione OWNER. Questo è l'ACL predefinita per i bucket appena creati. Questo è anche l'ACL predefinito per gli oggetti appena creati, a meno che l'ACL oggetto predefinito per quel bucket non sia stato modificato.
    authenticatedRead authenticated-read Concede l'autorizzazione OWNER al proprietario del bucket o dell'oggetto e l'autorizzazione READER a tutti i titolari di account utente autenticati.
    publicRead public-read Concede l'autorizzazione OWNER al proprietario del bucket o dell'oggetto e l'autorizzazione READER a tutti gli utenti, autenticati e anonimi. Quando lo applichi a un oggetto, chiunque su internet può leggere l'oggetto senza autenticarsi. Quando applichi questa impostazione a un bucket, chiunque su internet può elencare gli oggetti senza autenticazione.

    * Consulta la nota alla fine della tabella relativa alla memorizzazione nella cache.
    publicReadWrite public-read-write Concede al proprietario del bucket l'autorizzazione OWNER e a tutti gli utenti, sia autenticati che anonimi, le autorizzazioni READER e WRITER. Questo ACL si applica solo ai bucket. Quando lo applichi a un bucket, chiunque su internet può elencare, creare, sostituire ed eliminare oggetti senza autenticarsi.

    * Consulta 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 nella cache gli oggetti 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 predefinite

Quando vengono creati bucket o caricati oggetti, se non assegni esplicitamente un'ACL, viene assegnata l'ACL predefinita. Puoi modificare l'ACL predefinita assegnata a un oggetto. La procedura per farlo è descritta in Modifica delle ACL predefinite degli oggetti. Tieni presente che quando modifichi l'ACL predefinita, le ACL degli oggetti già presenti nel bucket o dei bucket già presenti nel progetto rimangono invariate.

ACL dei bucket predefiniti

Tutti i bucket sono di proprietà del gruppo dei proprietari del progetto. Inoltre, ai proprietari dei progetti viene concessa l'autorizzazione OWNER per tutti i bucket all'interno del progetto che utilizzano un ACL predefinita.

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

ACL degli oggetti predefinite

Per impostazione predefinita, chiunque disponga dell'autorizzazione OWNER o WRITER per 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 oggetto predefinito del bucket. Ogni bucket ha un ACL oggetto predefinito, che viene applicato a tutti gli oggetti caricati nel bucket senza un ACL predefinito o un ACL specificato nella richiesta (solo API JSON). Il valore iniziale della ACL oggetto predefinita di ogni bucket è projectPrivate.

In base alla modalità di caricamento degli oggetti, le ACL degli oggetti vengono applicate di conseguenza:

  • Caricamenti autenticati

    Se effettui una richiesta autenticata per caricare un oggetto e non specifichi ACL per l'oggetto durante il caricamento, figurerai come proprietario dell'oggetto e all'oggetto verrà applicata l'ACL projectPrivate predefinita. Ciò significa che:

    • Tu (la persona che ha caricato l'oggetto) risulti come proprietario dell'oggetto. La proprietà degli oggetti non può essere modificata modificando gli ACL. Puoi modificare la proprietà degli oggetti solo sostituendo un oggetto.

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

    • I gruppi di proprietari ed editor del progetto dispongono dell'autorizzazione OWNER sull'oggetto.

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

  • Caricamenti anonimi

    Se un utente non autenticato (anonimo) carica un oggetto, il che è possibile se un bucket concede al gruppo allUsers l'autorizzazione WRITER o OWNER, le ACL predefinite del bucket vengono applicate all'oggetto come descritto in precedenza.

    Gli utenti anonimi non possono specificare un'ACL predefinita durante il caricamento degli oggetti.

Comportamento delle ACL

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

  • Non puoi applicare un ACL che specifica un proprietario di bucket o oggetto diverso.

    La proprietà del bucket e dell'oggetto non può essere modificata modificando gli ACL. Se applichi una nuova ACL a un bucket o a un oggetto, assicurati che il proprietario del bucket o dell'oggetto rimanga invariato nella nuova 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, mentre 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 una nuova ACL a un bucket o a 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'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 (da non confondere con l'autorizzazione OWNER). Una volta creati in Cloud Storage, la proprietà di bucket e oggetti è permanente. Tuttavia, puoi modificare efficacemente la proprietà degli oggetti (ma non dei bucket) sostituendoli. La sostituzione è fondamentalmente 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 che acquisisce la proprietà dell'oggetto in questo modo) deve disporre dell'autorizzazione WRITER o OWNER per il bucket in cui viene caricato l'oggetto.

Passaggi successivi