Elenchi di controllo dell'accesso (ACL)

Utilizzo

Questa pagina fornisce una panoramica degli elenchi di controllo dell'accesso (ACL). A altri modi per controllare l'accesso a bucket e oggetti, Panoramica del controllo dell'accesso.

Dovresti usare gli elenchi di controllo dell'accesso?

Nella maggior parte dei casi, dovresti evitare di utilizzare gli ACL e abilita l'accesso uniforme a livello di bucket per i tuoi bucket, impedendo l'utilizzo degli ACL:

  • Gli ACL non possono essere utilizzati esclusivamente per controllare l'accesso a Google Cloud perché non è possibile impostare ACL sul progetto o sulle risorse nel complesso al di fuori di Cloud Storage.
  • L'attivazione dell'accesso uniforme a livello di bucket crea un'interfaccia di controllo dell'accesso più semplice e consente di utilizzare funzionalità aggiuntive di Google Cloud. Per ulteriori informazioni, vedi devi utilizzare l'accesso uniforme a livello di bucket.
  • Il criterio dell'organizzazione relativo alla condivisione limitata per i domini e i criteri dell'organizzazione personalizzati non impediscono l'accesso concesso dalle ACL, potenzialmente conducendo ad accesso indesiderato.
  • Quando utilizzi ACL in progetti che hanno condizioni IAM impostate a livello di progetto o superiore, possono verificarsi comportamenti e accessi imprevisti.

Ti consigliamo di utilizzare gli ACL nei seguenti casi:

  • Devi personalizzare l'accesso ai singoli oggetti all'interno di un bucket, ad esempio se l'utente in questione deve avere il controllo completo dell'oggetto in questione, ad altri oggetti nel bucket.
  • Utilizzi esclusivamente l'API XML o hai bisogno di interoperabilità con Amazon S3.

Identity and Access Management (IAM) e gli ACL lavorano in tandem per concedere l'accesso ai bucket e agli oggetti. Ciò 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 Gli ACL e le autorizzazioni concesse dagli ACL non appaiono in IAM criteri. Per ulteriori informazioni, consulta la Relazione IAM con gli ACL.

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, puoi applicare gli ACL a singoli bucket e oggetti. Ogni ACL è costituito 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 chiamato ceduto), 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 a cui vuoi che chiunque possa accedere per accedere agli oggetti, ma che tu voglia anche che il tuo collaboratore possa aggiungere o rimuovere oggetti dal bucket. In questo caso, l'ACL sarà composta da due voci:

  • In una voce, devi concedere a READER l'autorizzazione per un ambito di allUsers.

  • Nell'altra voce, concedi l'autorizzazione WRITER all'ambito del 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 dell'elemento è 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 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 visualizzato un errore 403 Forbidden restituito.

Tieni presente che sebbene gli ACL possano essere utilizzati per gestire la maggior parte delle azioni che coinvolgono bucket e di oggetti, la capacità di creare un bucket deriva dalla possibilità autorizzazione per il progetto.

Autorizzazioni

Le autorizzazioni descrivono cosa si può 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 tabella seguente:

Bucket Oggetti
READER Consente a un utente di elencare i contenuti di un bucket. Inoltre, consente a un utente di lettura dei 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'READER autorizzazione. Consente inoltre a un utente di creare, sostituire ed eliminare di oggetti in un bucket, inclusa la creazione di oggetti utilizzando caricamenti. N/D. Non puoi applicare questa autorizzazione agli oggetti.
OWNER Conferisce a un utente tutto l'accesso concesso dall'autorizzazione WRITER. Consente inoltre a un utente di leggere e scrivere i metadati del bucket, inclusi gli ACL, e di utilizzare i tag nel bucket. Conferisce a un utente tutto l'accesso concesso dall'autorizzazione READER. Consente inoltre all'utente di leggere e scrivere metadati degli oggetti, inclusi gli ACL.
Predefinito I bucket hanno i valori predefiniti ACL project-private applicato quando vengono creati. I bucket sono sempre di proprietà del gruppo project-owners. Gli oggetti hanno lo stato predefinito ACL project-private applicato quando vengono caricati. Gli oggetti sono sempre di proprietà dell'autore della richiesta originale che li ha caricati.

In questa pagina in genere facciamo riferimento alle autorizzazioni come READER, WRITER, e OWNER, ovvero come vengono specificati nell'API JSON e nel Console Google Cloud. Se utilizzi l'API XML, le autorizzazioni equivalenti sono 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 alla 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-di-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
Singola identità 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 viene utilizzato la console Google Cloud è 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 gli account di servizio. Per ulteriori informazioni, consulta la panoramica di IAM. Tieni presente che, sebbene questo identificatore sia 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 a quell'account. Puoi specificare un ambito utilizzando qualsiasi indirizzo email associato a un account utente.

    Cloud Storage memorizza gli indirizzi email forniti nelle ACL finché le voci non vengono rimosse o sostituite. Se un utente cambia gli indirizzi email, devi aggiornare le voci ACL in modo che riflettano queste 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 al seguente indirizzo email: gs-announce@googlegroups.com. Puoi trovare associato a un gruppo Google facendo clic su Informazioni. sulla home page di ogni gruppo Google.

    Come gli indirizzi email degli account utente, Cloud Storage memorizza i gruppi indirizzi email così come sono forniti negli ACL fino a quando le voci non vengono rimosse. Non devi preoccuparti di aggiornare gli indirizzi email di Google Gruppi, perché sono permanenti e difficilmente possono cambiare.

  • Valori di comodità per i progetti:

    I valori di convenienza ti consentono di concedere l'accesso collettivo ai visualizzatori, editor e proprietari. 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, dovresti evitare di utilizzare valori di praticità 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.

  • Identità della forza lavoro:

    La federazione delle identità della forza lavoro ti consente di utilizzare un provider di identità (IdP) esterno per autenticare e autorizzare un gruppo di utenti che utilizzano IAM, in modo che possano accedere ai servizi Google Cloud.

Autorizzazioni e ambiti concentrici

Quando specifichi gli ACL in Cloud Storage, non è necessario elencare più per concedere più autorizzazioni. Cloud Storage utilizza concentrici autorizzazioni, quindi quando concedi l'autorizzazione WRITER, concedi anche READER e, se concedi l'autorizzazione OWNER, concedi anche READER e Autorizzazione WRITER.

Quando specifichi un ACL, la maggior parte degli strumenti ti consente specificare più ambiti per la stessa voce. L'autorizzazione più permissiva è l'accesso concesso all'ambito. Ad esempio, se fornisci due voci per un valore un utente, uno con autorizzazione READER e l'altro con autorizzazione WRITER su 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 dell'autorizzazione READ e dell'autorizzazione WRITE su 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, è l'alias di un insieme di voci ACL specifiche che puoi utilizzare per applicare rapidamente molte voci ACL una volta sola in un bucket o un oggetto.

La tabella seguente elenca gli ACL predefiniti e mostra le voci ACL 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 ne ha la proprietà. Se un oggetto è stato creato da un utente anonimo, la proprietà dell'oggetto è del gruppo Proprietari del progetto.

  • Nella tabella, le descrizioni dell'API JSON relative alle 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 Conferisce al proprietario del bucket o dell'oggetto l'autorizzazione OWNER per un bucket o un oggetto.
    bucketOwnerRead bucket-owner-read Conferisce al proprietario dell'oggetto l'autorizzazione OWNER e al proprietario del bucket l'autorizzazione READER. È 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 fa parte del team e dispone dell'autorizzazione READER. Progetto proprietari ed editor del progetto hanno l'autorizzazione OWNER. Si tratta dell'ACL predefinita per i bucket appena creati. Si tratta anche dell'ACL predefinito per gli oggetti appena creati, a meno che l'ACL predefinito per gli oggetti per quel bucket non sia stato modificato.
    authenticatedRead authenticated-read Conferisce al proprietario del bucket o dell'oggetto l'autorizzazione OWNER e a tutti i titolari di account utente autenticati l'autorizzazione READER.
    publicRead public-read Concede l'autorizzazione OWNER al proprietario del bucket o dell'oggetto e offre a tutti gli utenti, autenticati e anonimi, READER autorizzazione. Se lo applichi a un oggetto, chiunque su internet può leggerlo senza autenticarsi. Quando la applichi a una un bucket, chiunque su internet può elencare gli oggetti senza con l'autenticazione.

    * Vedere la nota alla fine della tabella sulla memorizzazione nella cache.
    publicReadWrite public-read-write Conferisce al proprietario del bucket l'autorizzazione OWNER e a tutti gli utenti, sia autenticati che anonimi, le autorizzazioni READER e WRITER. Questa ACL si applica solo ai bucket. Quando lo si applica 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 Cache-Control che consente di memorizzare gli oggetti 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 predefinite

Quando vengono creati i bucket o caricati gli oggetti, se non specifichi esplicitamente assegnare loro un ACL, verrà loro assegnato l'ACL predefinito. Puoi modificare predefinito assegnato a un oggetto; il processo è descritto in Modifica degli ACL degli oggetti predefiniti. Tieni presente che quando modifichi l'impostazione predefinita ACL, ovvero gli ACL di oggetti già esistenti nel bucket o nei bucket esistono già nel progetto e rimangono invariate.

ACL dei bucket predefinite

Tutti i bucket sono di proprietà del gruppo di proprietari del progetto. Inoltre, i proprietari del progetto dispone dell'autorizzazione OWNER per tutti i bucket all'interno del progetto che utilizzano un oggetto ACL predefinito.

Se crei un bucket con l'ACL predefinito, ovvero non specifichi un'ACL predefinita al momento della creazione, al bucket viene applicata l'ACL projectPrivate predefinita.

ACL di oggetti predefiniti

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

In base alla modalità di caricamento degli 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 dell'oggetto al momento del caricamento, il tuo nome viene visualizzato 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 proprietà dell'oggetto solo sostituendo un oggetto.

    • In qualità di proprietario dell'oggetto, hai ottenuto l'autorizzazione OWNER per l'oggetto. Se cerchi di concedere al proprietario meno di OWNER autorizzazioni, Cloud Storage riassegna automaticamente l'autorizzazione a OWNER.

    • Il gruppo di proprietari e editor di progetto dispone dell'autorizzazione OWNER sull'oggetto.

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

  • Caricamenti anonimi

    Se un utente non autenticato (anonimo) carica un oggetto, cosa possibile se un bucket concede l'autorizzazione allUsers al gruppo WRITER o OWNER, alle autorizzazioni ACL del bucket predefinite viene applicato l'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 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 di oggetto diverso.

    La proprietà dei bucket e degli 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 ha sempre l'autorizzazione OWNER del bucket o dell'oggetto.

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

Non puoi applicare ACL che modificano la proprietà di un bucket o di un oggetto (che non deve essere confuso con l'autorizzazione OWNER). Una volta creati in Cloud Storage, la proprietà dei bucket e degli oggetti è permanente. Puoi: tuttavia, modifica in modo efficace 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 proprietaria dell'oggetto. Ricorda che, per sostituire oggetto della sostituzione, la persona che esegue la sostituzione (e ottiene la proprietà l'oggetto) deve avere l'autorizzazione WRITER o OWNER per il bucket in cui viene caricato l'oggetto.

Passaggi successivi