

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Panoramica delle liste di controllo accessi (ACL)
<a name="acl-overview"></a>

Le liste di controllo degli accessi di Amazon S3 (ACLs) consentono di gestire l'accesso a bucket e oggetti. A ogni bucket e oggetto è allegata una ACL come sottorisorsa. Definisce a quali Account AWS gruppi è concesso l'accesso e il tipo di accesso. Quando viene ricevuta una richiesta relativa a una risorsa, Amazon S3 controlla la lista ACL corrispondente per verificare che il richiedente disponga delle autorizzazioni di accesso necessarie. 

S3 Object Ownership è un'impostazione a livello di bucket di Amazon S3 che puoi utilizzare sia per controllare la proprietà degli oggetti caricati nel tuo bucket sia per disabilitarli o abilitarli. ACLs Per impostazione predefinita, Object Ownership è impostata sull'impostazione imposta dal proprietario del Bucket e tutti sono disabilitati. ACLs Quando ACLs sono disabilitati, il proprietario del bucket possiede tutti gli oggetti nel bucket e ne gestisce l'accesso esclusivamente utilizzando le politiche di gestione degli accessi.

 La maggior parte dei casi d'uso moderni in Amazon S3 non richiede più l'uso di. ACLs Ti consigliamo di rimanere ACLs disabilitato, tranne nei casi in cui devi controllare l'accesso per ogni oggetto singolarmente. ACLs Disabilitando, puoi utilizzare le policy per controllare l'accesso a tutti gli oggetti nel tuo bucket, indipendentemente da chi ha caricato gli oggetti nel tuo bucket. Per ulteriori informazioni, consulta [Controllo della proprietà degli oggetti e disattivazione ACLs del bucket](about-object-ownership.md).

**Importante**  
Se il bucket per uso generico utilizza l’impostazione Proprietario del bucket applicato per Proprietà dell’oggetto S3, è necessario utilizzare le policy per fornire l’accesso al bucket per uso generico e agli oggetti in esso contenuti. Con l'impostazione forzata del proprietario del Bucket abilitata, le richieste di impostazione degli elenchi di controllo degli accessi (ACLs) o di aggiornamento hanno ACLs esito negativo e restituiscono il codice di errore. `AccessControlListNotSupported` Le richieste di lettura ACLs sono ancora supportate.

Quando crei un bucket o un oggetto, Amazon S3 crea una lista ACL predefinita che concede al proprietario della risorsa il controllo completo su di essa. Questa situazione è illustrata nella seguente ACL del bucket di esempio (l'oggetto ACL predefinito ha la medesima struttura):

**Example**  

```
 1. <?xml version="1.0" encoding="UTF-8"?>
 2. <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
 3.   <Owner>
 4.     <ID>*** Owner-Canonical-User-ID ***</ID>
 5.   </Owner>
 6.   <AccessControlList>
 7.     <Grant>
 8.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 9.                xsi:type="Canonical User">
10.         <ID>*** Owner-Canonical-User-ID ***</ID>
11.       </Grantee>
12.       <Permission>FULL_CONTROL</Permission>
13.     </Grant>
14.   </AccessControlList>
15. </AccessControlPolicy>
```

L'ACL di esempio include un elemento `Owner` che identifica il proprietario tramite l'ID utente canonico dell' Account AWS. Per istruzioni sulla ricerca dell'ID utente canonico, consulta [Trovare un ID utente Account AWS canonico](#finding-canonical-id). L'`Grant`elemento identifica il beneficiario (un gruppo Account AWS o un gruppo predefinito) e l'autorizzazione concessa. Questa ACL predefinita possiede un elemento `Grant` per il proprietario. Per concedere le autorizzazioni aggiungere elementi `Grant`; ognuno di questi elementi identifica l'assegnatario e l'autorizzazione. 

**Nota**  
Un ACL può avere fino a 100 di questi elementi.

**Topics**
+ [Che cosa si intende per assegnatario?](#specifying-grantee)
+ [Quali autorizzazioni è possibile concedere?](#permissions)
+ [Valori `aclRequired` per le richieste di Amazon S3](#aclrequired-s3)
+ [ACL di esempio](#sample-acl)
+ [ACL predefinita](#canned-acl)

## Che cosa si intende per assegnatario?
<a name="specifying-grantee"></a>

Quando si concedono i diritti di accesso, si specifica ogni assegnatario come coppia `type="value"` in cui `type` è uno dei seguenti:
+ `id`— Se il valore specificato è l'ID utente canonico di un Account AWS
+ `uri`: se si concedono autorizzazioni a un gruppo predefinito

**avvertimento**  
Quando concedi ad altri Account AWS l'accesso alle tue risorse, tieni presente che Account AWS possono delegare le proprie autorizzazioni agli utenti tramite i propri account. Questa operazione è nota con il nome di *accesso multiaccount*. Per informazioni sull'utilizzo dell'accesso multiaccount, consulta [Creazione di un ruolo per delegare le autorizzazioni a un utente IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) nella *Guida per l'utente di IAM*. 

### Trovare un ID utente Account AWS canonico
<a name="finding-canonical-id"></a>

L'ID utente canonico è associato al tuo Account AWS. Questo ID è una stringa di caratteri lunga, ad esempio:

`79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be`

Per informazioni su come trovare l'ID utente canonico per l'account, consulta la sezione [Trovare l'ID utente canonico per Account AWS](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) nella *Guida di riferimento per la gestione dell'account AWS *.

Puoi anche cercare l'ID utente canonico di un utente Account AWS leggendo l'ACL di un bucket o di un oggetto a cui dispone delle autorizzazioni di accesso. Account AWS Quando a un individuo Account AWS vengono concesse le autorizzazioni tramite una richiesta di concessione, viene aggiunta una voce di autorizzazione all'ACL con l'ID utente canonico dell'account. 

**Nota**  
Se rendi pubblico il bucket (non consigliato) qualsiasi utente non autenticato può caricare oggetti nel bucket. Questi utenti anonimi non dispongono di un Account AWS. Quando un utente anonimo carica un oggetto nel tuo bucket Amazon S3 aggiunge un ID utente canonico speciale (`65a011a29cdf8ec533ec3d1ccaae921c`) in quanto proprietario dell'oggetto nell'ACL. Per ulteriori informazioni, consulta [Proprietà di bucket e oggetti di Amazon S3](access-policy-language-overview.md#about-resource-owner).

### Gruppi predefiniti di Amazon S3
<a name="specifying-grantee-predefined-groups"></a>

Amazon S3 include un set di gruppi predefiniti. Quando concedi l'accesso tramite account a un gruppo, specifichi uno degli Amazon URIs S3 anziché un ID utente canonico. Amazon S3 fornisce i seguenti gruppi predefiniti:
+ ****Gruppo Authenticated Users**** – Rappresentato da `http://acs.amazonaws.com/groups/global/AuthenticatedUsers`.

  Questo gruppo rappresenta tutto. Account AWS**L'autorizzazione di accesso a questo gruppo consente Account AWS a chiunque di accedere alla risorsa.** Tuttavia, tutte le richieste devono essere firmate (autenticate).
**avvertimento**  
Quando concedi l'accesso al **gruppo Authenticated Users**, qualsiasi utente AWS autenticato al mondo può accedere alla tua risorsa.
+ ****Gruppo All Users**** – Rappresentato da `http://acs.amazonaws.com/groups/global/AllUsers`.

  **L'autorizzazione di accesso per questo gruppo consente a qualsiasi persona al mondo di accedere alla risorsa.** Le richieste possono essere firmate (autenticate) o non firmate (anonime). Le richieste non firmate mancano dell'intestazione di autenticazione.
**avvertimento**  
È vivamente consigliato non concedere mai al **gruppo All Users** autorizzazioni `WRITE`, `WRITE_ACP` o `FULL_CONTROL`. Ad esempio, sebbene le autorizzazioni `WRITE` non consentano ai non proprietari di sovrascrivere o eliminare oggetti esistenti, le autorizzazioni `WRITE` consentono comunque a chiunque di archiviare oggetti nel bucket, i quali vengono fatturati. Per ulteriori dettagli su queste autorizzazioni, consulta la sezione [Quali autorizzazioni è possibile concedere?](#permissions).
+ ****Gruppo Log Delivery**** – Rappresentato da `http://acs.amazonaws.com/groups/s3/LogDelivery`.

  L'autorizzazione `WRITE` per un bucket consente a questo gruppo di scriver log di credenziali d'accesso al server (consulta [Registrazione delle richieste con registrazione dell'accesso al server](ServerLogs.md)) per il bucket.

**Nota**  
Quando si utilizza ACLs, un beneficiario può essere uno Account AWS o uno dei gruppi Amazon S3 predefiniti. Tuttavia, l'assegnatario non può essere un utente IAM. Per ulteriori informazioni sugli utenti AWS e sulle autorizzazioni in IAM, consulta [Utilizzo di AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/).

## Quali autorizzazioni è possibile concedere?
<a name="permissions"></a>

La seguente tabella elenca il set di autorizzazioni che Amazon S3 supporta in una lista ACL. L'insieme di autorizzazioni ACL è lo stesso per le ACL degli oggetti e dei bucket. Tuttavia, a seconda del contesto (bucket ACL o oggetto ACL), queste autorizzazioni si riferiscono a specifiche operazioni sui bucket o sugli oggetti. La tabella elenca le autorizzazioni e ne descrive il significato nel contesto degli oggetti e dei bucket. 

Per ulteriori informazioni sulle autorizzazioni ACL nella console di Amazon S3, consulta [Configurazione ACLs](managing-acls.md).


| Autorizzazione | Concessione a livello di bucket | Concessione a livello di oggetto | 
| --- | --- | --- | 
| READ | Consente all'assegnatario di elencare gli oggetti del bucket | Consente all'assegnatario di leggere i dati dell'oggetto e i relativi metadata | 
| WRITE | Consente all'assegnatario di creare nuovi oggetti del bucket. Per i proprietari di bucket e oggetti di oggetti esistenti, consente anche di eliminare e sovrascrivere tali oggetti. | Non applicabile. | 
| READ\$1ACP | Consente all'assegnatario di leggere l'ACL del bucket | Consente all'assegnatario di leggere l'ACL dell'oggetto | 
| WRITE\$1ACP | Consente all'assegnatario di scrivere l'ACL del bucket interessato | Consente all'assegnatario di scrivere l'ACL dell'oggetto interessato | 
| FULL\$1CONTROL | Consente al beneficiario le autorizzazioni READ, WRITE, READ\$1ACP e WRITE\$1ACP sul bucket | Consente al beneficiario le autorizzazioni READ, READ\$1ACP e WRITE\$1ACP sull'oggetto | 

**avvertimento**  
Prestare attenzione a concedere le autorizzazioni di accesso ai bucket e agli oggetti S3. Ad esempio, la concessione dell'accesso `WRITE` a un bucket consente all'assegnatario di creare oggetti nel bucket. È vivamente consigliato di leggere tutta questa sezione [Panoramica delle liste di controllo accessi (ACL)](#acl-overview) prima di concedere autorizzazioni.

### Mappatura delle autorizzazioni ACL e delle autorizzazioni della policy di accesso
<a name="acl-access-policy-permission-mapping"></a>

Come illustrato nella tabella precedente, un'ACL concede solo un insieme finito di autorizzazioni rispetto al numero di autorizzazioni che possono essere definite in una policy d'accesso predefinita (consulta [Azioni di policy per Amazon S3](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-actions)). Ognuna di queste autorizzazioni permette di eseguire una o più operazioni di Amazon S3.

La seguente tabella mostra come ogni autorizzazione ACL è mappata sulle autorizzazioni corrispondenti della policy d'accesso predefinita. Come si può vedere, la policy di accesso predefinita concede un numero maggiore di autorizzazioni rispetto all'ACL. Si utilizzano ACLs principalmente per concedere autorizzazioni di base, simili alle read/write autorizzazioni del file system. Per ulteriori informazioni su quando utilizzare una lista ACL, consulta [Identity and Access Management per Amazon S3](security-iam.md).

Per ulteriori informazioni sulle autorizzazioni ACL nella console di Amazon S3, consulta [Configurazione ACLs](managing-acls.md).


| Autorizzazione ACL | Autorizzazioni corrispondenti della policy d'accesso predefinita quando l'autorizzazione ACL viene concessa su un bucket  | Autorizzazioni corrispondenti della policy d'accesso predefinita quando l'autorizzazione ACL viene concessa su un oggetto | 
| --- | --- | --- | 
| READ | s3:ListBucket, s3:ListBucketVersions e s3:ListBucketMultipartUploads  | s3:GetObject e s3:GetObjectVersion | 
| WRITE |  `s3:PutObject` Il proprietario del bucket può creare, sovrascrivere ed eliminare qualsiasi oggetto nel bucket e il proprietario dell'oggetto ha `FULL_CONTROL` sull'oggetto. Inoltre, quando l'assegnatario è il proprietario del bucket, la concessione dell'autorizzazione `WRITE` nell'ACL di un bucket consente l'esecuzione dell'operazione `s3:DeleteObjectVersion` su qualsiasi versione del bucket.   | Non applicabile. | 
| READ\$1ACP | s3:GetBucketAcl  | s3:GetObjectAcl e s3:GetObjectVersionAcl | 
| WRITE\$1ACP | s3:PutBucketAcl | s3:PutObjectAcl e s3:PutObjectVersionAcl | 
| FULL\$1CONTROL | Equivale alla concessione delle autorizzazioni ACL READ, WRITE, READ\$1ACP e WRITE\$1ACP. Di conseguenza, questa autorizzazione ACL è mappata su una combinazione delle autorizzazioni corrispondenti della policy d'accesso predefinita. | Equivale alla concessione delle autorizzazioni ACL READ, READ\$1ACP e WRITE\$1ACP. Di conseguenza, questa autorizzazione ACL è mappata su una combinazione delle autorizzazioni corrispondenti della policy d'accesso predefinita. | 

### Chiavi di condizione
<a name="acl-specific-condition-keys"></a>

Quando si concedono autorizzazioni per le policy di accesso, è possibile utilizzare le chiavi di condizione per limitare il valore dell'ACL su un oggetto utilizzando una policy del bucket. Le seguenti chiavi di contesto corrispondono a. ACLs È possibile utilizzare queste chiavi di contesto per richiedere l'utilizzo di un'ACL specifica in una richiesta:
+ `s3:x-amz-grant-read` – Richiedere l'accesso in lettura.
+ `s3:x-amz-grant-write` – Richiedere l'accesso in scrittura.
+ `s3:x-amz-grant-read-acp` – Richiedere l'accesso in lettura alla lista ACL del bucket.
+ `s3:x-amz-grant-write-acp` ‐ Richiedere l'accesso in scrittura alla lista ACL del bucket.
+ `s3:x-amz-grant-full-control` – Richiedere il controllo completo.
+ `s3:x-amz-acl` – Richiedere una lista [ACL predefinita](#canned-acl).

Per policy di esempio con intestazioni specifiche delle liste ACL, consulta [Concessione di s3: PutObject autorizzazione con una condizione che richiede al proprietario del bucket di ottenere il pieno controllo](example-bucket-policies-condition-keys.md#grant-putobject-conditionally-1). Per un elenco completo delle chiavi di condizione specifiche per Amazon S3, consulta [ Azioni, risorse e chiavi di condizione per Amazon S3](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html) nella *Riferimento alle autorizzazioni di servizio*.

Per ulteriori informazioni sulle autorizzazioni alle operazioni API S3 per tipi di risorse S3, consulta [Autorizzazioni necessarie per le operazioni API di Amazon S3](using-with-s3-policy-actions.md).

## Valori `aclRequired` per le richieste di Amazon S3
<a name="aclrequired-s3"></a>

Per identificare le richieste Amazon S3 che richiedono ACLs l'autorizzazione, puoi utilizzare il `aclRequired` valore nei log di accesso al server Amazon S3 oppure. AWS CloudTrail Il `aclRequired` valore visualizzato nei CloudTrail nostri log di accesso al server di Amazon S3 dipende dalle operazioni richiamate e da determinate informazioni sul richiedente, sul proprietario dell'oggetto e sul proprietario del bucket. Se non è ACLs necessario, o se stai impostando l'ACL `bucket-owner-full-control` predefinito o se le richieste sono consentite dalla tua policy bucket, la stringa di `aclRequired` valore è "`-`" nei log di accesso al server di Amazon S3 ed è assente in. CloudTrail

Le tabelle seguenti elencano `aclRequired` i valori previsti nei CloudTrail nostri log di accesso al server Amazon S3 per le varie operazioni API di Amazon S3. Puoi utilizzare queste informazioni per capire da cosa dipende ACLs l'autorizzazione delle operazioni di Amazon S3. Nelle tabelle seguenti, A, B e C rappresentano i diversi account associati al richiedente, al proprietario dell'oggetto e al proprietario del bucket. Le voci con un asterisco (\$1) indicano uno degli account A, B o C. 

**Nota**  
Le operazioni `PutObject` nella tabella seguente, se non diversamente specificato, indicano richieste che non impostano un'ACL, a meno che l'ACL non sia un'ACL `bucket-owner-full-control`. Un valore nullo per `aclRequired` indica che `aclRequired` è assente nei log. AWS CloudTrail 

 La tabella seguente mostra i valori per`aclRequired`. CloudTrail 


| Nome operazione | Richiedente | Proprietario dell'oggetto. | Proprietario del bucket  | La policy di bucket garantisce l'accesso | `aclRequired` value | Motivo | 
| --- | --- | --- | --- | --- | --- | --- | 
| GetObject | A | A | A | Sì o No | null | Accesso allo stesso account | 
| GetObject | A | B | A | Sì o No | null | È stato imposto l'accesso allo stesso account con il proprietario del bucket | 
| GetObject | A | A | B | Sì | null | Accesso multi-account garantito dalla policy di bucket | 
| GetObject | A | A | B | No | Sì | L'accesso multi-account si basa su ACL | 
| GetObject | A | A | B | Sì | null | Accesso multi-account garantito dalla policy di bucket | 
| GetObject | A | B | B | No | Sì | L'accesso multi-account si basa su ACL | 
| GetObject | A | B | C | Sì | null | Accesso multi-account garantito dalla policy di bucket | 
| GetObject | A | B | C | No | Sì | L'accesso multi-account si basa su ACL | 
| PutObject | A | Non applicabile | A | Sì o No | null | Accesso allo stesso account | 
| PutObject | A | Non applicabile | B | Sì | null | Accesso multi-account garantito dalla policy di bucket | 
| PutObject | A | Non applicabile | B | No | Sì | L'accesso tra account si basa su ACL | 
| PutObject con un ACL (ad eccezione di bucket-owner-full-control) | \$1 | Non applicabile | \$1 | Sì o No | Sì | Richiesta di autorizzazioni ACL | 
| ListObjects | A | Non applicabile | A | Sì o No | null | Accesso allo stesso account | 
| ListObjects | A | Non applicabile | B | Sì | null | Accesso multi-account garantito dalla policy di bucket | 
| ListObjects | A | Non applicabile | B | No | Sì | L'accesso multi-account si basa su ACL | 
| DeleteObject | A | Non applicabile | A | Sì o No | null | Accesso allo stesso account | 
| DeleteObject | A | Non applicabile | B | Sì | null | Accesso multi-account garantito dalla policy di bucket | 
| DeleteObject | A | Non applicabile | B | No | Sì | L'accesso tra account si basa su ACL | 
| PutObjectAcl | \$1 | \$1 | \$1 | Sì o No | Sì | Richiesta di autorizzazioni ACL | 
| PutBucketAcl | \$1 | Non applicabile | \$1 | Sì o No | Sì | Richiesta di autorizzazioni ACL | 

 

**Nota**  
Le operazioni `REST.PUT.OBJECT` nella tabella seguente, se non diversamente specificato, indicano richieste che non impostano un ACL, a meno che l'ACL non sia un `bucket-owner-full-control` ACL. Una stringa di valori `aclRequired` di "`-`" indica un valore nullo nei log di accesso al server Amazon S3.

 La tabella seguente mostra i valori di `aclRequired` per i log di accesso al server Amazon S3. 


| Nome operazione | Richiedente | Proprietario dell'oggetto. | Proprietario del bucket  | La policy di bucket garantisce l'accesso | `aclRequired` value | Motivo | 
| --- | --- | --- | --- | --- | --- | --- | 
| REST.GET.OBJECT | A | A | A | Sì o No | - | Accesso allo stesso account | 
| REST.GET.OBJECT | A | B | A | Sì o No | - | È stato imposto l'accesso allo stesso account con il proprietario del bucket | 
| REST.GET.OBJECT | A | A | B | Sì | - | Accesso tra account a causa della politica tra account | 
| REST.GET.OBJECT | A | A | B | No | Sì | L'accesso multi-account si basa su ACL | 
| REST.GET.OBJECT | A | B | B | Sì | - | Accesso tra account a causa della politica tra account | 
| REST.GET.OBJECT | A | B | B | No | Sì | L'accesso multi-account si basa su ACL | 
| REST.GET.OBJECT | A | B | C | Sì | - | Accesso tra account a causa della politica tra account | 
| REST.GET.OBJECT | A | B | C | No | Sì | L'accesso multi-account si basa su ACL | 
| REST.PUT.OBJECT | A | Non applicabile | A | Sì o No | - | Accesso allo stesso account | 
| REST.PUT.OBJECT | A | Non applicabile | B | Sì | - | Accesso tra account a causa della politica tra account | 
| REST.PUT.OBJECT | A | Non applicabile | B | No | Sì | L'accesso tra account si basa su ACL | 
| REST.PUT.OBJECT con un ACL (ad eccezione di bucket-owner-full-control) | \$1 | Non applicabile | \$1 | Sì o No | Sì | Richiesta di autorizzazioni ACL | 
| REST.GET.BUCKET | A | Non applicabile | A | Sì o No | - | Accesso allo stesso account | 
| REST.GET.BUCKET | A | Non applicabile | B | Sì | - | Accesso tra account a causa della politica tra account | 
| REST.GET.BUCKET | A | Non applicabile | B | No | Sì | L'accesso multi-account si basa su ACL | 
| REST.DELETE.OBJECT | A | Non applicabile | A | Sì o No | - | Accesso allo stesso account | 
| REST.DELETE.OBJECT | A | Non applicabile | B | Sì | - | Accesso tra account a causa della politica tra account | 
| REST.DELETE.OBJECT | A | Non applicabile | B | No | Sì | L'accesso tra account si basa su ACL | 
| REST.PUT.ACL | \$1 | \$1 | \$1 | Sì o No | Sì | Richiesta di autorizzazioni ACL | 

## ACL di esempio
<a name="sample-acl"></a>

La seguente ACL di esempio su un bucket identifica il proprietario della risorsa e un insieme di concessioni. Il suo formato è la rappresentazione XML di una lista ACL in REST API di Amazon S3. Il proprietario del bucket ha il `FULL_CONTROL` della risorsa. Inoltre, l'ACL mostra come vengono concesse le autorizzazioni su una risorsa a due Account AWS, identificati da un ID utente canonico, e a due dei gruppi Amazon S3 predefiniti discussi nella sezione precedente.

**Example**  

```
 1. <?xml version="1.0" encoding="UTF-8"?>
 2. <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
 3.   <Owner>
 4.     <ID>Owner-canonical-user-ID</ID>
 5.   </Owner>
 6.   <AccessControlList>
 7.     <Grant>
 8.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
 9.         <ID>Owner-canonical-user-ID</ID>
10.       </Grantee>
11.       <Permission>FULL_CONTROL</Permission>
12.     </Grant>
13.     
14.     <Grant>
15.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
16.         <ID>user1-canonical-user-ID</ID>
17.       </Grantee>
18.       <Permission>WRITE</Permission>
19.     </Grant>
20. 
21.     <Grant>
22.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
23.         <ID>user2-canonical-user-ID</ID>
24.       </Grantee>
25.       <Permission>READ</Permission>
26.     </Grant>
27. 
28.     <Grant>
29.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
30.         <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> 
31.       </Grantee>
32.       <Permission>READ</Permission>
33.     </Grant>
34.     <Grant>
35.       <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
36.         <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI>
37.       </Grantee>
38.       <Permission>WRITE</Permission>
39.     </Grant>
40. 
41.   </AccessControlList>
42. </AccessControlPolicy>
```

## ACL predefinita
<a name="canned-acl"></a>

*Amazon S3 supporta una serie di sovvenzioni predefinite, note come predefinite. ACLs* Ogni ACL predefinita ha un insieme predefinito di assegnatari e autorizzazioni. La tabella seguente elenca il set di sovvenzioni predefinite ACLs e le sovvenzioni predefinite associate. 


| ACL predefinita | Si applica a | Autorizzazioni aggiunte a un'ACL | 
| --- | --- | --- | 
| private | Bucket e oggetto | Il proprietario ottiene il FULL\$1CONTROL. Nessun altro ha diritti di accesso (impostazione predefinita). | 
| public-read | Bucket e oggetto | Il proprietario ottiene il FULL\$1CONTROL. Il gruppo AllUsers (consulta [Che cosa si intende per assegnatario?](#specifying-grantee)) ottiene l'accesso READ.  | 
| public-read-write | Bucket e oggetto | Il proprietario ottiene il FULL\$1CONTROL. Il gruppo AllUsersottiene l'accesso READ e WRITE. In genere la concessione di queste autorizzazioni su un bucket non è consigliata. | 
| aws-exec-read | Bucket e oggetto | Il proprietario ottiene il FULL\$1CONTROL. Amazon EC2 ottiene l'accesso di tipo READ per la richiesta GET con cui ottenere un bundle Amazon Machine Image (AMI) da Amazon S3. | 
| authenticated-read | Bucket e oggetto | Il proprietario ottiene il FULL\$1CONTROL. Il gruppo AuthenticatedUsers ottiene l'accesso READ. | 
| bucket-owner-read | Oggetto | Il proprietario dell'oggetto ottiene il FULL\$1CONTROL. Il proprietario del bucket ottiene l'accesso READ. Se specifichi questa lista ACL predefinita durante la creazione di un bucket, Amazon S3 la ignora. | 
| bucket-owner-full-control | Oggetto  | Sia il proprietario dell'oggetto che il proprietario del bucket ottengono il FULL\$1CONTROL dell'oggetto. Se specifichi questa lista ACL predefinita durante la creazione di un bucket, Amazon S3 la ignora. | 
| log-delivery-write | Bucket  | Il gruppo LogDelivery ottiene le autorizzazioni WRITE e READ\$1ACP sul bucket. Per ulteriori informazioni sui log, consulta ([Registrazione delle richieste con registrazione dell'accesso al server](ServerLogs.md)). | 

**Nota**  
È possibile specificare solo una di queste opzioni predefinite nella richiesta ACLs .

Per specificare un'ACL predefinita nella richiesta si utilizza l'intestazione di richiesta `x-amz-acl`. Quando Amazon S3 riceve una richiesta contenente una lista ACL predefinita, aggiunge le concessioni predefinite alla lista ACL della risorsa. 