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, Identity and Access Management (IAM) è la metodo consigliato per controllare l'accesso alle tue risorse:
- IAM fornisce controllo dell'accesso su tutto Google Cloud.
- IAM ha un maggiore controllo sulle azioni consentite agli utenti per l'esecuzione.
- Autorizzazioni IAM concesse alle risorse padre, ad esempio vengono ereditati dalle risorse figlio, come bucket e oggetti, permettendoti di gestire più facilmente l'accesso alle risorse.
- Le autorizzazioni IAM possono essere applicate alle cartelle gestite, mentre non possono essere ACL.
- Non è possibile usare gli ACL esclusivamente per controllare l'accesso alle risorse, Non è possibile impostare ACL nel progetto o in altre risorse padre.
Utilizzo esclusivo di IAM e abilitazione dell'accesso uniforme a livello di bucket consente di utilizzare altre funzionalità di sicurezza di Google Cloud, la condivisione limitata al dominio, la federazione delle identità per la forza lavoro e Condizioni IAM.
Ti consigliamo di utilizzare gli ACL nei seguenti casi:
- Devi personalizzare l'accesso ai singoli oggetti all'interno di un bucket. Gli ACL possono per singoli oggetti, mentre le autorizzazioni IAM possono essere a livello di bucket o superiore.
- Utilizzi esclusivamente l'API XML o hai bisogno dell'interoperabilità con Amazon S3.
IAM e ACL collaborano per concedere l'accesso ai bucket di oggetti, il che significa che un utente ha bisogno solo dell'autorizzazione pertinente di una delle questi sistemi per accedere a un bucket o 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 ha accesso ai bucket e agli oggetti, nonché al livello di accesso di cui dispongono. Nella Cloud Storage, applichi ACL a singoli bucket e oggetti. Ciascuna ACL consiste in una o più voci. Una voce assegna a un utente (o gruppo) specifico di eseguire azioni specifiche. Ogni voce è composta da due parti informazioni:
Un'autorizzazione, che definisce quali azioni possono essere eseguite (ad esempio, lettura o scrittura).
Un ambito (a volte indicato come concesso), che definisce chi può eseguire le azioni specificate (ad esempio, un utente o un gruppo utenti).
Ad esempio, supponiamo che tu abbia un bucket che vuoi rendere accessibile a chiunque accedere agli oggetti, ma vuoi che il collaboratore possa aggiungere o rimuovere gli oggetti dal bucket. In questo caso, l'ACL sarà costituito da due voci:
In una voce, devi concedere a
READER
l'autorizzazione per un ambito diallUsers
.Nell'altra voce, devi concedere a
WRITER
l'autorizzazione per l'ambito del tuo collaboratore (ci sono diversi modi per specificare questa persona, ad esempio tramite 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 conteggiata una voce ACL, indipendentemente indica quanti utenti fanno parte del gruppo o del dominio.
Quando un utente richiede l'accesso a un bucket o a un oggetto, Cloud Storage
legge l'ACL del bucket o dell'oggetto e determina se consentire o meno
la richiesta di accesso. Se l'ACL concede all'utente l'autorizzazione per l'oggetto
operativa, 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 è possibile fare per un determinato oggetto o bucket.
Cloud Storage ti consente di assegnare i seguenti elementi concentrici autorizzazioni per i bucket e gli oggetti, come illustrato 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 |
Concede a un utente tutti gli accessi concessi dall'WRITER
autorizzazione. Consente inoltre a un utente di leggere e scrivere
metadati del bucket,
inclusi gli ACL, oltre che lavorare con i tag nel bucket. |
Concede a un utente tutti gli accessi concessi dall'READER
autorizzazione. 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à
Gruppo project-owners . |
Gli oggetti hanno lo stato predefinito ACL project-private applicato quando vengono caricati. Gli oggetti sono sempre di proprietà dell'originale che ha caricato l'oggetto. |
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, uno equivalente
sono rispettivamente 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 | collaboratore@gmail.com |
Indirizzo email del gruppo Google | Gruppo | work-group@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 |
Identità singola 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à nella Internet. Tieni presente che, anche se questo identificatore è un tipo di entitàUser
, quando utilizzando la console Google Cloud, viene etichettata come tipo di entitàPublic
.Identificatore speciale per tutti gli account validi:
L'identificatore di ambito speciale
allAuthenticatedUsers
rappresenta la maggior parte tutti gli account autenticati, inclusi quelli di servizio. Per ulteriori informazioni, consulta la panoramica di IAM. Tieni presente che, sebbene questo identificatore sia un Tipo di entitàUser
, quando viene utilizzata nella console Google Cloud è etichettata come un tipo di entitàPublic
.Indirizzo email account utente:
Ogni utente che dispone di un account utente deve avere un indirizzo email univoco. associati 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 ACL finché le voci non vengono rimosse o sostituite. Se un utente cambia l'email indirizzi, devi aggiornare le voci ACL per riflettere queste modifiche.
Indirizzo email del gruppo Google:
Ogni gruppo Google ha un indirizzo email univoco associato a il 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é gli indirizzi email dei gruppi Google sono permanenti ed è improbabile che vengano modificati.
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 sonoeditors-867489160491
. Puoi trovare il tuo progetto nella home page della console Google Cloud.In genere dovresti evitare di utilizzare valori di convenienza in produzione ambienti, 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 con un nome di dominio Internet. In questo modo, account email assume il formato USERNAME@YOUR_DOMAIN.com. È possibile specificare un ambito utilizzando qualsiasi nome di dominio internet associato con Google Workspace o Cloud Identity.
Identità forza lavoro:
La federazione delle identità per la forza lavoro consente di utilizzare un'identità esterna per autenticare e autorizzare un gruppo di utenti utilizzando IAM, per consentire agli utenti di accedere a Google Cloud i servizi di machine learning.
Autorizzazioni e ambiti concentrici
Quando specifichi gli ACL in Cloud Storage, non è necessario elencare più
per concedere più autorizzazioni. Cloud Storage utilizza concentrici
autorizzazioni, perciò 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
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
l'ambito di attività. Ad esempio, la concessione dell'autorizzazione READ
e dell'autorizzazione WRITE
a un utente
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 seguente, tieni presente che:
Il gruppo di proprietari del progetto ha la proprietà dei bucket del progetto e l'utente che crea un oggetto ne possiede la proprietà. Se un oggetto è stato creato da un utente anonimo, il gruppo di proprietari del progetto detiene .
Nella tabella, le descrizioni dell'API JSON relative alle autorizzazioni,
OWNER
,WRITER
, eREADER
. Gli ambiti equivalenti dell'API XML sonoFULL_CONTROL
,WRITE
eREAD
.JSON API/ gcloud storage
API XML Descrizione private
private
Concede al proprietario del bucket o dell'oggetto l'autorizzazione OWNER
per un in un bucket o un oggetto.bucketOwnerRead
bucket-owner-read
Concede al proprietario dell'oggetto l'autorizzazione OWNER
e alla dell'autorizzazioneREADER
del proprietario del bucket. È 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'autorizzazioneOWNER
. Questo è l'ACL predefinito per i bucket appena creati. Questa è anche l'impostazione predefinita per gli oggetti appena creati, a meno che non sia stato specificato l'ACL degli oggetti predefinito per quel bucket è cambiato.authenticatedRead
authenticated-read
Concede l'autorizzazione OWNER
al proprietario del bucket o dell'oggetto e assegna a tutti i titolari di account utente autenticatiREADER
autorizzazione.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. Quando si applica a un oggetto, chiunque su internet può leggere l'oggetto senza eseguire l'autenticazione. 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
Concede al proprietario del bucket l'autorizzazione OWNER
, poi a tutte utenti, autenticati e anonimi,READER
e AutorizzazioneWRITER
. Questo 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. Per
far sì che gli aggiornamenti siano visibili immediatamente,
imposta i metadati Cache-Control
per gli oggetti su
Cache-Control:private, max-age=0, no-transform
.
ACL predefiniti
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 predefiniti
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
specificare un ACL predefinito quando crei
al bucket è applicato l'ACL projectPrivate
predefinito.
ACL degli 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. In caso contrario
specifica un ACL, Cloud Storage applica l'ACL degli oggetti predefinito del bucket
all'oggetto. Ogni bucket ha un ACL per gli oggetti predefinito, che viene applicato
tutti gli oggetti caricati nel bucket senza un ACL predefinito o un ACL specificato
nella richiesta (solo API JSON). Il valore iniziale per l'ACL degli oggetti 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 qualsiasi ACL di oggetto quando lo carichi, verrai indicato come proprietario del e l'ACL
projectPrivate
predefinito viene applicato all'oggetto predefinito. 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 diOWNER
autorizzazioni, Cloud Storage riassegna automaticamente l'autorizzazione aOWNER
.Il gruppo dei proprietari del progetto e degli editor del progetto dispone dell'autorizzazione
OWNER
per dell'oggetto.Il gruppo dei membri del team del progetto dispone dell'autorizzazione
READER
per l'oggetto.
Caricamenti anonimi
Se un utente non autenticato (anonimo) carica un oggetto, è possibile se un bucket concede l'autorizzazione
WRITER
oOWNER
del gruppoallUsers
, gli ACL dei bucket predefiniti 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 ACL, che ti impediscono di impostare ACL che rendono i dati inaccessibile:
Non puoi applicare un ACL che specifica un bucket diverso o proprietario dell'oggetto.
La proprietà di bucket e oggetti non può essere modificata modificando gli ACL. Se applicare un nuovo ACL a un bucket o un oggetto, assicurati che il bucket o l'oggetto proprietario rimane invariato nel nuovo ACL.
Il proprietario del bucket o dell'oggetto ha sempre l'autorizzazione
OWNER
del un bucket o un oggetto.Il proprietario di un bucket è il gruppo di proprietari del progetto e il proprietario di un è l'utente che ha caricato l'oggetto o i proprietari del progetto gruppo 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 concedeOWNER
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 creato in
La proprietà di Cloud Storage, bucket e 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 il proprietario 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
- Scopri come utilizzare gli ACL.
- Scopri come semplificare il controllo dell'accesso utilizzando accesso uniforme a livello di bucket.
- Scopri le best practice per l'utilizzo degli ACL.