Amazon Simple Storage Service
Manuel du développeur (Version de l'API 2006-03-01)

Présentation de la liste de contrôle d'accès (ACL)

Les listes de contrôle d'accès (ACL) d'Amazon S3 vous permettent d'accéder aux compartiments et objets. Chaque compartiment et objet possède une liste ACL qui lui est attachée comme sous-ressource. Elle définit quels comptes ou groupes AWS bénéficient d'un accès et le type d'accès. Lors de la réception d'une demande sur une ressource, Amazon S3 vérifie la liste ACL correspondante pour s'assurer que le demandeur possède les autorisations d'accès nécessaires.

Lorsque vous créez un compartiment ou un objet, Amazon S3 crée une liste ACL par défaut qui octroie au propriétaire de la ressource le contrôle total sur celle-ci. Ce comportement est illustré dans l'exemple de liste ACL de compartiment suivant (la liste ACL d'objet par défaut possède 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 de liste ACL inclut un élément Owner qui identifie le propriétaire par l'ID d'utilisateur canonique du compte AWS. Pour obtenir des instructions pour rechercher votre ID d'utilisateur canonique, consultez Recherche d'un ID d'utilisateur canonique de compte AWS. L'élément Grant identifie le bénéficiaire (un compte AWS ou groupe prédéfini), et l'autorisation accordée. Cette liste ACL par défaut possède un élément Grant 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

Une liste ACL peut avoir 100 accords maximum.

Qui est le bénéficiaire ?

Un bénéficiaire peut être un compte AWS ou l'un des groupes prédéfinis d'Amazon S3. Vous accordez l'autorisation à un compte AWS à l'aide de l'adresse e-mail ou l'ID d'utilisateur canonique. Toutefois, si vous fournissez une adresse e-mail dans la demande d'accord, Amazon S3 trouve l'ID d'utilisateur canonique pour ce compte et l'ajoute à la liste ACL. Les listes ACL obtenues contiennent toujours l'ID d'utilisateur canonique pour le compte AWS, pas les adresses e-mail du 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 :

  • USA Est (Virginie du Nord)

  • USA Ouest (Californie du Nord)

  • USA Ouest (Oregon)

  • Asie-Pacifique (Singapour)

  • Asie-Pacifique (Sydney)

  • Asie-Pacifique (Tokyo)

  • UE (Irlande)

  • Amérique du Sud (São Paulo)

Pour obtenir la liste de toutes les régions et points de terminaison Amazon S3 pris en charge, consultez Régions et points de terminaison dans le document Référence générale AWS.

Avertissement

Lorsque vous accordez à d'autres comptes AWS l'accès aux ressources, sachez que les comptes AWS peuvent déléguer leurs autorisations aux utilisateurs sous leurs comptes. Il s'agit d'un accès entre comptes. Pour en savoir plus sur l'utilisation de l'accès entre comptes, consultez Création d'un rôle pour déléguer des autorisations à un utilisateur IAM dans le IAM Guide de l'utilisateur.

Recherche d'un ID d'utilisateur canonique de compte AWS

L'ID d'utilisateur canonique est associé au compte AWS. Il s'agit d'une chaîne longue, telle que 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be. Pour plus d'informations sur la recherche de l'ID d'utilisateur canonique pour votre compte, consultez Recherche de l'ID d'utilisateur canonique de votre compte.

Vous pouvez également rechercher l'ID d'utilisateur canonique d'un compte AWS en lisant la liste ACL d'un compartiment ou d'un objet pour lequel le compte AWS possède les autorisations d'accès. Lorsqu'un compte AWS individuel bénéficie des autorisations par une demande d'accord, une entrée d'accord est ajoutée à la liste ACL avec l'ID d'utilisateur canonique du compte AWS.

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 charge un objet dans votre compartiment, Amazon S3 ajoute un ID utilisateur canonique spécial (65a011a29cdf8ec533ec3d1ccaae921c) comme propriétaire de l'objet dans la liste ACL. Pour plus d'informations, consultez Titularité d'objet et de compartiment Amazon S3.

Groupes prédéfinis d'Amazon S3

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

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

    Ce groupe représente tous les comptes AWS. Une autorisation d'accès à ce groupe permet à n'importe quel compte AWS d'accéder aux ressources. Toutefois, toutes les demandes doivent être signées (authentifiées).

    Avertissement

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

  • Groupe de tous les utilisateurs–: il est 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, les autorisations WRITE permettent à chacun de stocker des objets dans votre compartiment, ce pour quoi vous êtes facturé. Cela permettrait également aux autres utilisateurs de supprimer des objets que vous voudriez conserver. Pour plus de détails sur ces autorisations, reportez-vous à la section suivante Quelles autorisations puis-je accorder ?.

  • Groupe de livraison des journaux–: il est 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 Journalisation des accès au serveur Amazon S3) dans le compartiment.

Note

Lorsque vous utilisez des listes ACL, le bénéficiaire peut être un compte AWS ou l'un des groupes prédéfinis d'Amazon S3. Toutefois, le bénéficiaire ne peut pas être un utilisateur IAM. Pour en savoir plus sur les utilisateurs et autorisations AWS dans IAM, consultez Utilisation d'AWS Identity and Access Management.

Quelles autorisations puis-je accorder ?

Le tableau suivant liste l'ensemble des autorisations qu'Amazon S3 prend en charge dans une liste ACL. Toutes les autorisations de liste ACL sont identiques pour les listes ACL d'objet et de compartiment. Toutefois, selon le contexte (liste ACL de compartiment ou liste ACL d'objet), ces autorisations de liste ACL accordent des autorisations pour des opérations spécifiques de compartiment ou d'objet. Le tableau répertorie les autorisations et décrit ce qu'elles signifient pour des objets et des compartiments.

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, de remplacer et de supprimer n'importe quel objet du compartiment Ne s'applique pas
READ_ACP Elles permettent au bénéficiaire de lire la liste ACL du compartiment Elles permettent au bénéficiaire de lire la liste ACL de l'objet
WRITE_ACP Elles permettent au bénéficiaire d'écrire la liste ACL pour le compartiment applicable Elles permettent au bénéficiaire d'écrire la liste ACL pour l'objet applicable
FULL_CONTROL Elles permettent au bénéficiaire de profiter des autorisations READ, WRITE, READ_ACP et WRITE_ACP sur le compartiment Elles permettent au bénéficiaire de profiter des 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, remplacer et supprimer des objets dans le compartiment. Nous vous recommandons vivement de lire l'ensemble de la section Présentation de la liste de contrôle d'accès (ACL) avant d'accorder des autorisations.

Mappage des autorisations de liste ACL et de stratégie d'accès

Comme illustré dans le tableau précédent, une liste ACL permet uniquement d'accorder un ensemble limité d'autorisations, comparé au nombre d'autorisations configurables dans une stratégie d'accès (consultez Spécification des autorisations d'une stratégie). Chacune de ces autorisations permet une ou plusieurs opérations Amazon S3.

Le tableau suivant montre comment chacune des autorisations de liste ACL est mappée aux autorisations de stratégie d'accès correspondantes. Comme vous pouvez le voir, une stratégie d'accès accorde plus d'autorisations qu'une liste ACL. Vous utilisez une liste ACL principalement pour accorder des autorisations de lecture/écriture de base, similaires aux autorisations de système de fichiers. Pour en savoir plus sur l'utilisation de la liste ACL, consultez Instructions d'utilisation des options de stratégie d'accès disponibles.

Autorisation de liste ACL Autorisations de stratégie d'accès correspondantes lorsqu'une autorisation de liste ACL est accordée sur un compartiment Autorisations de stratégie d'accès correspondantes lorsqu'une autorisation de liste ACL est accordée sur un objet
READ s3:ListBucket, s3:ListBucketVersions et s3:ListBucketMultipartUploads s3:GetObject, s3:GetObjectVersion et s3:GetObjectTorrent
WRITE

s3:PutObject and s3:DeleteObject.

De plus, lorsque le bénéficiaire est le propriétaire du compartiment, l'accord d'une autorisation WRITE dans la liste ACL d'un compartiment permet d'exécuter l'action s3:DeleteObjectVersion sur n'importe quelle version de ce compartiment.

Ne s'applique pas
READ_ACP s3:GetBucketAcl s3:GetObjectAcl and s3:GetObjectVersionAcl
WRITE_ACP s3:PutBucketAcl s3:PutObjectAcl and s3:PutObjectVersionAcl
FULL_CONTROL Équivaut à accorder les autorisations de liste ACL READ, WRITE, READ_ACP et WRITE_ACP. Par conséquent, cette autorisation de liste ACL est mappée à une combinaison d'autorisations de stratégie d'accès correspondantes. Équivaut à accorder les autorisations de liste ACL READ, READ_ACP et WRITE_ACP. Par conséquent, cette autorisation de liste ACL est mappée à une combinaison d'autorisations de stratégie d'accès correspondantes.

Exemple de liste ACL

L'exemple de liste ACL suivant sur un compartiment identifie le propriétaire de la ressource et un ensemble d'accords. Le format est la représentation XML d'une liste ACL dans l'API REST d'Amazon S3. Le propriétaire du compartiment possède l'accès FULL_CONTROL sur la ressource. De plus, la liste ACL montre comment les autorisations sont accordées sur une ressource à deux comptes AWS, identifiés par l'ID d'utilisateur canonique, et à deux des groupes prédéfinis d'Amazon S3 mentionnés 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>

Liste ACL prête à l'emploi

Amazon S3 prend en charge un ensemble d'accords prédéfinis, appelées listes ACL prêtes à l'emploi. Chaque liste ACL prête à l'emploi possède un ensemble prédéfini de bénéficiaires et d'autorisations. Le tableau suivant liste l'ensemble des listes ACL prêtes à l'emploi et les accords prédéfinis associés.

Liste ACL prête à l'emploi S'applique à Autorisations ajoutées à la liste 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 le 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 Les propriétaires FULL_CONTROL. Amazon EC2 obtiennent READ l'accès pour GET faire une demande sur un groupe Amazon Machine Image(AMI) issu de 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 cette liste ACL prête à l'emploi lors de la création du 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 cette liste ACL prête à l'emploi lors de la création du 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 (Journalisation des accès au serveur Amazon S3).

Note

Vous pouvez uniquement spécifier l'une des listes ACL prêtes à l'emploi dans la demande.

Vous pouvez spécifier une liste ACL prête à l'emploi dans la demande grâce à l'en-tête x-amz-acl. Lorsqu'Amazon S3 reçoit une demande contenant une liste ACL prête à l'emploi, il ajoute les accords prédéfinis à la liste ACL de la ressource.

Procédure pour spécifier une liste ACL

Les APIs Amazon S3 vous permettent de configurer une ACL lorsque vous créez un compartiment ou un objet. Amazon S3 fournit également une API pour définir une ACL sur un compartiment ou un objet existant. Ces API vous fournissent les méthodes suivantes pour configurer une liste ACL :

  • Configurez la liste ACL grâce aux en-têtes de demande – Lorsque vous envoyez une demande pour créer une ressource (compartiment ou objet), vous configurez une liste ACL grâce aux en-têtes de demande. Grâce à ces en-têtes, vous pouvez spécifier une liste ACL prête à l'emploi ou des accords (en identifiant explicitement le bénéficiaire et les autorisations).

  • Configurez la liste ACL grâce au corps de la demande – Lorsque vous envoyez une demande pour configurer une liste ACL sur une ressource existante, vous pouvez configurer la liste ACL dans l'en-tête ou le corps de la demande.

Pour plus d'informations, consultez Gestion des listes ACL.