Vue d'ensemble de la liste de contrôle d'accès (ACL)

Les listes de contrôle d'accès Amazon S3 (ACLs) vous permettent de gérer l'accès aux compartiments et aux objets. Chaque compartiment et objet est ACL associé à une sous-ressource. Il définit le Comptes AWS ou les groupes auxquels l'accès est accordé et le type d'accès. Lorsqu'une demande est reçue concernant une ressource, Amazon S3 vérifie que le demandeur dispose des autorisations d'accès nécessaires. ACL

La propriété des objets S3 est un paramètre au niveau du compartiment Amazon S3 que vous pouvez utiliser à la fois pour contrôler la propriété des objets chargés dans votre compartiment et pour les désactiver ou les activer. ACLs Par défaut, Object Ownership est défini sur le paramètre imposé par le propriétaire du bucket, et tous ACLs sont désactivés. Lorsqu'ils ACLs sont désactivés, le propriétaire du compartiment possède tous les objets du compartiment et gère l'accès à ceux-ci exclusivement à l'aide de politiques de gestion des accès.

La majorité des cas d'utilisation modernes d'Amazon S3 ne nécessitent plus l'utilisation deACLs. Nous vous recommandons de rester ACLs désactivé, sauf dans des circonstances exceptionnelles où vous devez contrôler l'accès à chaque objet individuellement. Lorsque cette ACLs option est désactivée, vous pouvez utiliser des politiques pour contrôler l'accès à tous les objets de votre compartiment, quelle que soit la personne qui les a chargés dans votre compartiment. Pour de plus amples informations, veuillez consulter Contrôle de la propriété des objets et désactivation ACLs pour votre compartiment.

Important

Si votre compartiment utilise le paramètre Propriétaire du compartiment appliqué pour la propriété des objets S3, vous devez utiliser des politiques pour accorder l’accès à votre compartiment et aux objets qu’il contient. Lorsque le paramètre Bucket owner forced est activé, les demandes de définition de listes de contrôle d'accès (ACLs) ou de mise à jour ACLs échouent et renvoient le code AccessControlListNotSupported d'erreur. Les demandes de lecture ACLs sont toujours prises en charge.

Lorsque vous créez un compartiment ou un objet, Amazon S3 crée une valeur par défaut ACL qui accorde au propriétaire de la ressource le contrôle total de la ressource. Cela est illustré dans l'exemple de compartiment suivant ACL (l'objet par défaut ACL a la même structure) :

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>*** Owner-Canonical-User-ID ***</ID>
    <DisplayName>owner-display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
               xsi:type="Canonical User">
        <ID>*** Owner-Canonical-User-ID ***</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy> 

L'exemple ACL inclut un Owner élément qui identifie le propriétaire par son ID Compte AWS utilisateur canonique. Pour obtenir des instructions pour trouver votre ID d'utilisateur canonique, consultez Trouver un nom d'utilisateur Compte AWS canonique. L'Grantélément identifie le bénéficiaire (soit un groupe prédéfini, Compte AWS soit un groupe prédéfini) et l'autorisation accordée. Cette valeur par défaut ACL comporte un Grant élément pour le propriétaire. Vous accordez des autorisations en ajoutant des éléments Grant, avec chaque accord identifiant le bénéficiaire et l'autorisation.

Note

Et ACL peut avoir jusqu'à 100 subventions.

Qui est un bénéficiaire ?

Un bénéficiaire peut être un Compte AWS ou l'un des groupes Amazon S3 prédéfinis. Vous autorisez l' Compte AWS utilisation de l'adresse e-mail ou de l'ID utilisateur canonique. Toutefois, si vous fournissez une adresse e-mail dans votre demande de subvention, Amazon S3 trouve l'ID utilisateur canonique de ce compte et l'ajoute auACL. Le résultat contient ACLs toujours l'ID utilisateur canonique du Compte AWS, et non l'adresse e-mail du Compte AWS.

Lorsque vous accordez des droits d'accès, vous spécifiez chaque bénéficiaire sous la forme d'une paire type="value", où le type est l'un des suivants :

• id— Si la valeur spécifiée est l'ID utilisateur canonique d'un Compte AWS

• uri : si vous accordez des autorisations à un groupe prédéfini

• emailAddress : si la valeur spécifiée est l'adresse e-mail d'un Compte AWS

Important

L'utilisation d'adresses e-mail pour spécifier un bénéficiaire est prise en charge uniquement dans les Régions AWS suivantes :

• US East (N. Virginia)

• USA Ouest (Californie du Nord)

• US West (Oregon)

• Asie-Pacifique (Singapour)

• Asie-Pacifique (Sydney)

• Asia Pacific (Tokyo)

• Europe (Ireland)

• South America (São Paulo)

Pour obtenir la liste de toutes les régions et de tous les points de terminaison Amazon S3 pris en charge, consultez Régions et points de terminaison dans Référence générale d'Amazon Web Services.

Exemple : adresse e-mail

Par exemple, l'x-amz-grant-readen-tête suivant accorde aux adresses e-mail Comptes AWS identifiées l'autorisation de lire les données des objets et leurs métadonnées :

x-amz-grant-read: emailAddress="[e-mail]", emailAddress="[e-mail]"

Avertissement

Lorsque vous accordez à d'autres personnes l' Comptes AWS accès à vos ressources, sachez qu'elles Comptes AWS peuvent déléguer leurs autorisations aux utilisateurs de leurs comptes. Il s'agit d'un accès entre comptes. Pour plus d'informations sur l'utilisation de l'accès entre comptes, voir Création d'un rôle pour déléguer des autorisations à un IAM utilisateur dans le guide de l'IAMutilisateur.

Trouver un nom d'utilisateur Compte AWS canonique

L'ID d'utilisateur canonique est associé au Compte AWS. Cet ID est composé d'une longue chaîne de caractères, par exemple :

79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be

Pour plus d'informations sur la façon de trouver l'ID utilisateur canonique de votre compte, voir Trouver l'ID utilisateur canonique correspondant à votre compte Compte AWS dans le Guide de référence de gestion de AWS compte.

Vous pouvez également rechercher l'ID utilisateur canonique d'un Compte AWS en lisant le nom ACL d'un bucket ou d'un objet auquel il Compte AWS possède des autorisations d'accès. Lorsqu'une personne Compte AWS obtient des autorisations par le biais d'une demande de subvention, une entrée de subvention est ajoutée à ACL celle-ci avec l'ID utilisateur canonique du compte.

Note

Si vous rendez votre compartiment public (non recommandé), n'importe quel utilisateur non authentifié pourra y charger des objets. Ces utilisateurs anonymes ne disposent pas d'un Compte AWS. Lorsqu'un utilisateur anonyme télécharge un objet dans votre compartiment, Amazon S3 ajoute un ID utilisateur canonique spécial (65a011a29cdf8ec533ec3d1ccaae921c) en tant que propriétaire de l'objet dans le. ACL Pour de plus amples informations, veuillez consulter Propriété du compartiment et de l'objet Amazon S3.

Groupes prédéfinis Amazon S3

Amazon S3 possède un ensemble de groupes prédéfinis. Lorsque vous accordez l'accès à un compte à un groupe, vous spécifiez l'un des Amazon S3 URIs au lieu d'un ID utilisateur canonique. Amazon S3 fournit les groupes prédéfinis suivants :

• Groupe des utilisateurs authentifiés – Représenté par http://acs.amazonaws.com/groups/global/AuthenticatedUsers.

  Ce groupe représente tout le monde Comptes AWS. L'autorisation d'accès à ce groupe permet Compte AWS à n'importe qui d'accéder à la ressource. Toutefois, toutes les demandes doivent être signées (authentifiées).

  Avertissement

  Lorsque vous accordez l'accès au groupe Utilisateurs authentifiés, n'importe quel utilisateur AWS authentifié dans le monde peut accéder à votre ressource.

• Groupe de tous les utilisateurs – Représenté par http://acs.amazonaws.com/groups/global/AllUsers.

  Une autorisation d'accès à ce groupe permet à tout le monde d'accéder à la ressource. Les demandes peuvent être signées (authentifiées) ou non (anonymes). Les demandes non signées omettent l'en-tête Authentification dans la demande.

  Avertissement

  Nous vous recommandons vivement de ne pas jamais accorder au groupe de tous les utilisateurs les autorisations WRITE, WRITE_ACP ou FULL_CONTROL. Par exemple, bien que les autorisations WRITE ne permettent pas aux non-propriétaires de remplacer ou de supprimer des objets existants, les autorisations WRITE permettent toujours à quiconque de stocker des objets dans votre compartiment, ce pour quoi vous êtes facturé. Pour plus de détails sur ces autorisations, consultez la section suivante Quelles autorisations puis-je octroyer ?.

• Groupe de livraison des journaux – Représenté par http://acs.amazonaws.com/groups/s3/LogDelivery.

  Une autorisation WRITE sur un compartiment permet à ce groupe d'écrire des journaux d'accès au serveur (consultez Enregistrement de demandes avec journalisation des accès au serveur) dans le compartiment.

Note

Lors de l'utilisationACLs, un bénéficiaire peut être un Compte AWS ou l'un des groupes Amazon S3 prédéfinis. Toutefois, le bénéficiaire ne peut pas être un IAM utilisateur. Pour plus d'informations sur AWS les utilisateurs et les autorisations associéesIAM, consultez la section Utilisation AWS Identity and Access Management.

Quelles autorisations puis-je octroyer ?

Le tableau suivant répertorie l'ensemble des autorisations prises en charge par Amazon S3 dans unACL. L'ensemble des ACL autorisations est le même pour un objet ACL et un bucketACL. Toutefois, en fonction du contexte (compartiment ACL ou objetACL), ces ACL autorisations octroient des autorisations pour des buckets ou des opérations sur des objets spécifiques. Le tableau répertorie les autorisations et décrit ce qu'elles signifient pour des objets et des compartiments.

Pour plus d'informations sur ACL les autorisations dans la console Amazon S3, consultezConfiguration ACLs.

Autorisation	Lorsqu'elles sont accordées sur un compartiment	Lorsqu'elles sont accordées sur un objet
READ	Elles permettent au bénéficiaire de lister les objets dans le compartiment	Elles permettent au bénéficiaire de lire les données de l'objet et ses métadonnées
WRITE	Elles permettent au bénéficiaire de créer des objets dans le compartiment. Pour les propriétaires de compartiments et d'objets existants, elles permettent également de supprimer et de remplacer ces objets.	Ne s’applique pas
READ_ACP	Permet au bénéficiaire de lire le seau ACL	Permet au bénéficiaire de lire l'objet ACL
WRITE_ACP	Permet au bénéficiaire d'écrire le nom ACL pour le compartiment applicable	Permet au bénéficiaire d'écrire le ACL pour l'objet applicable
FULL_CONTROL	Elle accorde au bénéficiaire les autorisations READ, WRITE, READ_ACP et WRITE_ACP sur le compartiment	Elle accorde au bénéficiaire les autorisations READ, READ_ACP et WRITE_ACP sur l'objet

Avertissement

Soyez vigilant lorsque vous accordez des autorisations d'accès à vos compartiments et objets S3. Par exemple, l'octroi de l'accès WRITE à un compartiment permet au bénéficiaire de créer des objets dans le compartiment. Nous vous recommandons vivement de lire l'ensemble de la section Vue d'ensemble de la liste de contrôle d'accès (ACL) avant d'accorder des autorisations.

Cartographie des ACL autorisations et des autorisations liées à la politique d'accès

Comme indiqué dans le tableau précédent, un n'ACLautorise qu'un ensemble limité d'autorisations, par rapport au nombre d'autorisations que vous pouvez définir dans une politique d'accès (voirActions politiques pour Amazon S3). Chacune de ces autorisations permet une ou plusieurs opérations Amazon S3.

Le tableau suivant montre comment chaque ACL autorisation correspond aux autorisations de politique d'accès correspondantes. Comme vous pouvez le constater, la politique d'accès accorde plus d'autorisations qu'ACLelle ne le fait. Vous l'utilisez ACLs principalement pour accorder des autorisations de lecture/écriture de base, similaires aux autorisations de système de fichiers. Pour plus d'informations sur les circonstances dans lesquelles utiliser unACL, consultezIdentity and Access Management pour Amazon S3.

Pour plus d'informations sur ACL les autorisations dans la console Amazon S3, consultezConfiguration ACLs.

ACLautorisation	Autorisations de politique d'accès correspondantes lorsque l'ACLautorisation est accordée sur un bucket	Autorisations de politique d'accès correspondantes lorsque l'ACLautorisation est accordée sur un objet
READ	s3:ListBucket, s3:ListBucketVersions et s3:ListBucketMultipartUploads	s3:GetObject et s3:GetObjectVersion
WRITE	s3:PutObject Le propriétaire du compartiment peut créer, remplacer et supprimer n'importe quel objet dans le compartiment, et le propriétaire de l'objet bénéficie du FULL_CONTROL sur son objet. En outre, lorsque le bénéficiaire est le propriétaire du bucket, l'octroi d'une WRITE autorisation dans un bucket ACL permet s3:DeleteObjectVersion d'exécuter l'action sur n'importe quelle version de ce bucket.	Ne s’applique pas
READ_ACP	s3:GetBucketAcl	s3:GetObjectAcl et s3:GetObjectVersionAcl
WRITE_ACP	s3:PutBucketAcl	s3:PutObjectAcl et s3:PutObjectVersionAcl
FULL_CONTROL	Cela équivaut à l'octroi de READWRITE,READ_ACP, et WRITE_ACP ACL d'autorisations. Par conséquent, cette ACL autorisation correspond à une combinaison d'autorisations de politique d'accès correspondantes.	Équivalent à l'octroi de READREAD_ACP, et WRITE_ACP ACL d'autorisations. Par conséquent, cette ACL autorisation correspond à une combinaison d'autorisations de politique d'accès correspondantes.

Clés de condition

Lorsque vous accordez des autorisations liées à une politique d'accès, vous pouvez utiliser des clés de condition pour limiter la valeur d'un objet ACL à l'aide d'une politique de compartiment. Les clés de contexte suivantes correspondent àACLs. Vous pouvez utiliser ces clés de contexte pour imposer l'utilisation d'un élément spécifique ACL dans une demande :

• s3:x-amz-grant-read ‐ Exiger un accès en lecture.

• s3:x-amz-grant-write ‐ Exiger un accès en écriture.

• s3:x-amz-grant-read-acp‐ Nécessite un accès en lecture au bucketACL.

• s3:x-amz-grant-write-acp‐ Nécessite un accès en écriture au compartimentACL.

• s3:x-amz-grant-full-control ‐ Exiger un contrôle total.

• s3:x-amz-acl ‐ Exiger une En conserve ACL.

Par exemple, les politiques qui impliquent des ACL en-têtes spécifiques, voir. Octroi de s3 : PutObject autorisation assortie d'une condition obligeant le propriétaire du bucket à obtenir le contrôle total Pour obtenir la liste complète des clés de condition spécifiques à Amazon S3, consultez la section Actions, ressources et clés de condition pour Amazon S3 dans la référence d'autorisation de service.

Pour plus d'informations sur les autorisations relatives aux API opérations S3 par type de ressource S3, consultezAutorisations requises pour les API opérations Amazon S3.

Valeurs aclRequired pour les demandes Amazon S3 courantes

Pour identifier les demandes Amazon S3 nécessitant ACLs une autorisation, vous pouvez utiliser la aclRequired valeur dans les journaux d'accès au serveur Amazon S3 ou AWS CloudTrail. La aclRequired valeur qui apparaît dans les journaux CloudTrail d'accès au serveur Amazon S3 dépend des opérations appelées et de certaines informations concernant le demandeur, le propriétaire de l'objet et le propriétaire du compartiment. Si aucune valeur ACLs n'est requise, ou si vous configurez le bucket-owner-full-control scanACL, ou si les demandes sont autorisées par votre politique de compartiment, la chaîne de aclRequired valeur est « - » dans les journaux d'accès au serveur Amazon S3 et est absente dans CloudTrail.

Les tableaux suivants répertorient les aclRequired valeurs attendues dans les journaux CloudTrail d'accès au serveur Amazon S3 pour les différentes API opérations Amazon S3. Vous pouvez utiliser ces informations pour comprendre de quelles opérations Amazon S3 dépendent ACLs pour obtenir une autorisation. Dans les tables suivantes, A, B et C représentent les différents comptes associés au demandeur, au propriétaire de l'objet et au propriétaire du compartiment. Les entrées suivies d'un astérisque (*) indiquent l'un des comptes A, B ou C.

Note

PutObjectles opérations décrites dans le tableau suivant, sauf indication contraire, indiquent les demandes qui ne définissent pas unACL, sauf s'il s'ACLagit d'un bucket-owner-full-controlACL. Une valeur nulle pour aclRequired indique qu'elle aclRequired est absente des AWS CloudTrail journaux.

Le tableau suivant indique les aclRequired valeurs de CloudTrail.

Nom de l'opération	Demandeur	Propriétaire de l'objet	Propriétaire du compartiment	La politique du compartiment autorise l'accès	Valeur aclRequired	Raison
GetObject	A	A	A	Oui ou Non	null	Accès dans le même compte
GetObject	A	B	A	Oui ou Non	null	Accès au même compte avec le propriétaire du compartiment obligatoire
GetObject	A	A	B	Oui	null	Accès intercompte accordé par la politique du compartiment
GetObject	A	A	B	Non	Oui	L'accès entre comptes repose sur ACL
GetObject	A	A	B	Oui	null	Accès intercompte accordé par la politique du compartiment
GetObject	A	B	B	Non	Oui	L'accès entre comptes repose sur ACL
GetObject	A	B	C	Oui	null	Accès intercompte accordé par la politique du compartiment
GetObject	A	B	C	Non	Oui	L'accès entre comptes repose sur ACL
PutObject	A	Ne s’applique pas	A	Oui ou Non	null	Accès dans le même compte
PutObject	A	Ne s’applique pas	B	Oui	null	Accès intercompte accordé par la politique du compartiment
PutObject	A	Ne s’applique pas	B	Non	Oui	L'accès entre comptes repose sur ACL
PutObjectavec un ACL (sauf pourbucket-owner-full-control)	*	Ne s’applique pas	*	Oui ou Non	Oui	Demandez des subventions ACL
ListObjects	A	Ne s’applique pas	A	Oui ou Non	null	Accès dans le même compte
ListObjects	A	Ne s’applique pas	B	Oui	null	Accès intercompte accordé par la politique du compartiment
ListObjects	A	Ne s’applique pas	B	Non	Oui	L'accès entre comptes repose sur ACL
DeleteObject	A	Ne s’applique pas	A	Oui ou Non	null	Accès dans le même compte
DeleteObject	A	Ne s’applique pas	B	Oui	null	Accès intercompte accordé par la politique du compartiment
DeleteObject	A	Ne s’applique pas	B	Non	Oui	L'accès entre comptes repose sur ACL
PutObjectAcl	*	*	*	Oui ou Non	Oui	Demandez des subventions ACL
PutBucketAcl	*	Ne s’applique pas	*	Oui ou Non	Oui	Demandez des subventions ACL

Note

REST.PUT.OBJECTles opérations décrites dans le tableau suivant, sauf indication contraire, indiquent les demandes qui ne définissent pas unACL, sauf s'il s'ACLagit d'un bucket-owner-full-controlACL. Une chaîne de valeur aclRequired « - » indique une valeur nulle dans les journaux d'accès au serveur Amazon S3.

Le tableau suivant indique les aclRequired valeurs des journaux d'accès au serveur Amazon S3.

Nom de l'opération	Demandeur	Propriétaire de l'objet	Propriétaire du compartiment	La politique du compartiment autorise l'accès	Valeur aclRequired	Raison
REST.GET.OBJECT	A	A	A	Oui ou Non	-	Accès dans le même compte
REST.GET.OBJECT	A	B	A	Oui ou Non	-	Accès au même compte avec le propriétaire du compartiment obligatoire
REST.GET.OBJECT	A	A	B	Oui	-	Accès intercompte accordé par la politique du compartiment
REST.GET.OBJECT	A	A	B	Non	Oui	L'accès entre comptes repose sur ACL
REST.GET.OBJECT	A	B	B	Oui	-	Accès intercompte accordé par la politique du compartiment
REST.GET.OBJECT	A	B	B	Non	Oui	L'accès entre comptes repose sur ACL
REST.GET.OBJECT	A	B	C	Oui	-	Accès intercompte accordé par la politique du compartiment
REST.GET.OBJECT	A	B	C	Non	Oui	L'accès entre comptes repose sur ACL
REST.PUT.OBJECT	A	Ne s’applique pas	A	Oui ou Non	-	Accès dans le même compte
REST.PUT.OBJECT	A	Ne s’applique pas	B	Oui	-	Accès intercompte accordé par la politique du compartiment
REST.PUT.OBJECT	A	Ne s’applique pas	B	Non	Oui	L'accès entre comptes repose sur ACL
REST.PUT.OBJECTavec un ACL (sauf pourbucket-owner-full-control)	*	Ne s’applique pas	*	Oui ou Non	Oui	Demandez des subventions ACL
REST.GET.BUCKET	A	Ne s’applique pas	A	Oui ou Non	-	Accès dans le même compte
REST.GET.BUCKET	A	Ne s’applique pas	B	Oui	-	Accès intercompte accordé par la politique du compartiment
REST.GET.BUCKET	A	Ne s’applique pas	B	Non	Oui	L'accès entre comptes repose sur ACL
REST.DELETE.OBJECT	A	Ne s’applique pas	A	Oui ou Non	-	Accès dans le même compte
REST.DELETE.OBJECT	A	Ne s’applique pas	B	Oui	-	Accès intercompte accordé par la politique du compartiment
REST.DELETE.OBJECT	A	Ne s’applique pas	B	Non	Oui	L'accès entre comptes repose sur ACL
REST.PUT.ACL	*	*	*	Oui ou Non	Oui	Demandez des subventions ACL

Exemple ACL

L'exemple suivant ACL sur un bucket identifie le propriétaire de la ressource et un ensemble de subventions. Le format est la XML représentation d'un ACL dans Amazon S3 RESTAPI. Le propriétaire du compartiment possède l'accès FULL_CONTROL sur la ressource. En outre, il ACL montre comment les autorisations sont accordées sur une ressource à deux Comptes AWS, identifiés par un ID utilisateur canonique, et à deux des groupes Amazon S3 prédéfinis décrits dans la section précédente.

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Owner>
    <ID>Owner-canonical-user-ID</ID>
    <DisplayName>display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>Owner-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
    
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>user1-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>WRITE</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>user2-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>READ</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
        <URI>http://acs.amazonaws.com/groups/global/AllUsers</URI> 
      </Grantee>
      <Permission>READ</Permission>
    </Grant>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
        <URI>http://acs.amazonaws.com/groups/s3/LogDelivery</URI>
      </Grantee>
      <Permission>WRITE</Permission>
    </Grant>

  </AccessControlList>
</AccessControlPolicy>

En conserve ACL

Amazon S3 prend en charge un ensemble de subventions prédéfinies, appelées « standardisées ACLs ». Chaque version ACL numérisée possède un ensemble prédéfini de bénéficiaires et d'autorisations. Le tableau suivant répertorie l'ensemble des autorisations prédéfinies ACLs et les autorisations prédéfinies associées.

En conserve ACL	S’applique à	Autorisations ajoutées à ACL
private	Compartiment et objet	Le propriétaire obtient l'accès FULL_CONTROL. Personne d'autre ne possède les droits d'accès (par défaut).
public-read	Compartiment et objet	Le propriétaire obtient l'accès FULL_CONTROL. Le groupe AllUsers (consultez Qui est un bénéficiaire ?) obtient l'accès READ.
public-read-write	Compartiment et objet	Le propriétaire obtient l'accès FULL_CONTROL. Le groupe AllUsers obtient l'accès READ et WRITE. L'accord de ce type d'accès sur un compartiment n'est généralement pas recommandé.
aws-exec-read	Compartiment et objet	Le propriétaire obtient l'accès FULL_CONTROL. Amazon EC2 a READ accès à GET un bundle Amazon Machine Image (AMI) depuis Amazon S3.
authenticated-read	Compartiment et objet	Le propriétaire obtient l'accès FULL_CONTROL. Le groupe AuthenticatedUsers obtient l'accès READ.
bucket-owner-read	Objet	Le propriétaire de l'objet obtient l'accès FULL_CONTROL. Le propriétaire du compartiment obtient l'accès READ. Si vous spécifiez ce paramètre ACL scanné lors de la création d'un compartiment, Amazon S3 l'ignore.
bucket-owner-full-control	Objet	Le propriétaire de l'objet et celui du compartiment obtiennent l'accès FULL_CONTROL sur l'objet. Si vous spécifiez ce paramètre ACL scanné lors de la création d'un compartiment, Amazon S3 l'ignore.
log-delivery-write	Compartiment	Le groupe LogDelivery obtient les autorisations WRITE et READ_ACP sur le compartiment. Pour plus d'informations sur les journaux, consultez (Enregistrement de demandes avec journalisation des accès au serveur).

Note

Vous ne pouvez spécifier qu'une seule de ces options ACLs prédéfinies dans votre demande.

Vous spécifiez un fichier ACL prédéfini dans votre demande en utilisant l'en-tête de la x-amz-acl demande. Lorsqu'Amazon S3 reçoit une demande contenant un ACL code prédéfini, il ajoute les autorisations prédéfinies à ACL la ressource.