Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Gérer l'accès avec ACLs Les listes de contrôle d'accès (ACLs) sont l'une des options basées sur les ressources que vous pouvez utiliser pour gérer l'accès à vos compartiments et objets. Vous pouvez l'utiliser ACLs pour accorder des autorisations de lecture/écriture de base à d'autres personnes. Comptes AWS Il existe des limites à la gestion des autorisations à l'aide de ACLs. Par exemple, vous ne pouvez accorder des autorisations qu'à d'autres personnes Comptes AWS ; vous ne pouvez pas accorder d'autorisations aux utilisateurs de votre compte. Vous ne pouvez pas accorder d'autorisations conditionnelles, ni refuser explicitement des autorisations. ACLs sont adaptés à des scénarios spécifiques. Par exemple, si le propriétaire d'un compartiment autorise d'autres personnes Comptes AWS à télécharger des objets, les autorisations relatives à ces objets ne peuvent être gérées Compte AWS que par le propriétaire de l'objet à l'aide de l'ACL de l'objet. 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 de ACLs. Nous vous recommandons de rester ACLs désactivé, sauf dans les cas 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](about-object-ownership.md). **Important** Si votre compartiment à usage général utilise Propriétaire du compartiment appliqué pour le paramètre Propriétaire de l’objet S3, vous devez utiliser des stratégies pour accorder l’accès à votre compartiment à usage général 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. Pour plus d'informations ACLs, consultez les rubriques suivantes. **Topics** + [Présentation de la liste de contrôle d’accès (ACL)](acl-overview.md) + [Configuration ACLs](managing-acls.md) + [Exemples de politiques pour ACLs](example-bucket-policies-condition-keys.md) # Présentation 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 possède une liste ACL qui lui est attachée comme sous-ressource. Il définit le Comptes AWS ou les groupes auxquels l'accès est accordé 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. 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 de ACLs. Nous vous recommandons de rester ACLs désactivé, sauf dans les cas 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](about-object-ownership.md). **Important** Si votre compartiment à usage général utilise Propriétaire du compartiment appliqué pour le paramètre Propriétaire de l’objet S3, vous devez utiliser des stratégies pour accorder l’accès à votre compartiment à usage général 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 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) : **Example** ``` 1. 2. 3. 4. *** Owner-Canonical-User-ID *** 5. 6. 7. 8. 10. *** Owner-Canonical-User-ID *** 11. 12. FULL_CONTROL 13. 14. 15. ``` 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 trouver votre ID d’utilisateur canonique, consultez [Trouver un nom d'utilisateur Compte AWS canonique](#finding-canonical-id). 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 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. **Topics** + [Qui est un bénéficiaire ?](#specifying-grantee) + [Quelles autorisations puis-je octroyer ?](#permissions) + [Valeurs `aclRequired` pour les demandes Amazon S3 courantes](#aclrequired-s3) + [Exemple de liste ACL](#sample-acl) + [Liste ACL prête à l’emploi](#canned-acl) ## Qui est un bénéficiaire ? 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 **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 intercompte*. Pour en savoir plus sur l’utilisation de l’accès intercompte, consultez [Création d’un rôle pour la délégation d’autorisations à un utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*. ### 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 découvrir comment trouver l’ID d’utilisateur canonique de votre compte, consultez [Recherche de l’ID d’utilisateur canonique de votre Compte AWS](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-identifiers.html#FindCanonicalId) dans le *Guide de référence sur la gestion des comptes AWS *. Vous pouvez également rechercher l'ID utilisateur canonique d'un Compte AWS en lisant l'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 à l'ACL 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 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 [Propriété du compartiment et de l’objet Amazon S3](access-policy-language-overview.md#about-resource-owner). ### 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` n’autorisent pas les non-propriétaires à remplacer ou supprimer des objets existants, les autorisations `WRITE` permettent à quiconque de stocker dans votre compartiment des objets, qui vous sont facturés. Pour plus de détails sur ces autorisations, consultez la section [Quelles autorisations puis-je octroyer ?](#permissions) suivante. + ****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](ServerLogs.md)) dans le compartiment. **Note** Lors de l'utilisation ACLs, 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 utilisateur IAM. Pour plus d’informations sur les utilisateurs et autorisations AWS dans IAM, consultez [Utilisation d’ Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/). ## Quelles autorisations puis-je octroyer ? Le tableau suivant répertorie 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. Pour plus d’informations sur les autorisations ACL dans la console Amazon S3, consultez [Configuration ACLs](managing-acls.md). | Autorisations | Lorsqu’elles sont accordées sur un compartiment | Lorsqu’elles sont accordées sur un objet | | --- | --- | --- | | READ | Elles permettent au bénéficiaire de répertorier 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\$1ACP | 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\$1ACP | 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\$1CONTROL | Elle accorde au bénéficiaire les autorisations READ, WRITE, READ\$1ACP et WRITE\$1ACP sur le compartiment | Elle accorde au bénéficiaire les autorisations READ, READ\$1ACP et WRITE\$1ACP 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 [Présentation de la liste de contrôle d’accès (ACL)](#acl-overview) avant d’accorder des autorisations. ### Mappage des autorisations de liste ACL et de stratégie d’accès Comme illustré dans la table précédente, 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 [Actions de politique pour Amazon S3](security_iam_service-with-iam.md#security_iam_service-with-iam-id-based-policies-actions)). 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 l'utilisez ACLs principalement pour accorder read/write des autorisations de base, similaires aux autorisations de système de fichiers. Pour plus d’informations sur le moment où utiliser une ACL, consultez [Gestion des identités et des accès pour Amazon S3](security-iam.md). Pour plus d’informations sur les autorisations ACL dans la console Amazon S3, consultez [Configuration ACLs](managing-acls.md). | 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 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. 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\$1ACP | s3:GetBucketAcl | s3:GetObjectAcl et s3:GetObjectVersionAcl | | WRITE\$1ACP | s3:PutBucketAcl | s3:PutObjectAcl et s3:PutObjectVersionAcl | | FULL\$1CONTROL | Équivaut à accorder les autorisations de liste ACL READ, WRITE, READ\$1ACP et WRITE\$1ACP. 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\$1ACP et WRITE\$1ACP. Par conséquent, cette autorisation de liste ACL est mappée à une combinaison d'autorisations de stratégie d'accès correspondantes. | ### Clés de condition Lorsque vous accordez des autorisations de stratégie d’accès, vous pouvez utiliser des clés de condition pour limiter la valeur de l’ACL sur un objet à l’aide d’une stratégie de compartiment. Les clés de contexte suivantes correspondent à ACLs. Vous pouvez utiliser ces clés de contexte pour exiger l’utilisation d’une liste ACL spécifique 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` ‐ Exiger un accès en lecture à l’ACL du compartiment. + `s3:x-amz-grant-write-acp` ‐ Exiger un accès en écriture à l’ACL du compartiment. + `s3:x-amz-grant-full-control` ‐ Exiger un contrôle total. + `s3:x-amz-acl` ‐ Exiger une [Liste ACL prête à l’emploi](#canned-acl). Pour des exemples de stratégies impliquant des en-têtes spécifiques à une liste ACL, consultez [Octroi de s3 : PutObject autorisation assortie d'une condition obligeant le propriétaire du bucket à obtenir le contrôle total](example-bucket-policies-condition-keys.md#grant-putobject-conditionally-1). Pour obtenir la liste complète des clés de condition spécifiques à Amazon S3, consultez [Actions, ressources et clés de condition pour Amazon S3](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html) dans la *Référence de l’autorisation de service*. Pour plus d’informations sur les autorisations relatives aux opérations d’API S3 par type de ressource S3, consultez [Autorisations requises pour les opérations d’API Amazon S3](using-with-s3-policy-actions.md). ## 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 définissez l'ACL `bucket-owner-full-control` prédéfinie, 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 opérations d'API 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 (\$1) indiquent l’un des comptes A, B ou C. **Note** Les opérations `PutObject` de la table suivante, sauf indication contraire, indiquent les demandes qui ne définissent pas de liste ACL, sauf si la liste ACL est `bucket-owner-full-control`. 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 | Accès intercompte reposant sur la liste ACL | | GetObject | A | A | B | Oui | null | Accès intercompte accordé par la politique du compartiment | | GetObject | A | B | B | Non | Oui | Accès intercompte reposant sur la liste ACL | | GetObject | A | B | C | Oui | null | Accès intercompte accordé par la politique du compartiment | | GetObject | A | B | C | Non | Oui | Accès intercompte reposant sur la liste ACL | | PutObject | A | Non applicable | A | Oui ou Non | null | Accès dans le même compte | | PutObject | A | Non applicable | B | Oui | null | Accès intercompte accordé par la politique du compartiment | | PutObject | A | Non applicable | B | Non | Oui | Accès intercompte reposant sur la liste ACL | | PutObject avec une liste ACL (sauf pour bucket-owner-full-control) | \$1 | Non applicable | \$1 | Oui ou Non | Oui | Demande autorise la liste ACL | | ListObjects | A | Non applicable | A | Oui ou Non | null | Accès dans le même compte | | ListObjects | A | Non applicable | B | Oui | null | Accès intercompte accordé par la politique du compartiment | | ListObjects | A | Non applicable | B | Non | Oui | Accès intercompte reposant sur la liste ACL | | DeleteObject | A | Non applicable | A | Oui ou Non | null | Accès dans le même compte | | DeleteObject | A | Non applicable | B | Oui | null | Accès intercompte accordé par la politique du compartiment | | DeleteObject | A | Non applicable | B | Non | Oui | Accès intercompte reposant sur la liste ACL | | PutObjectAcl | \$1 | \$1 | \$1 | Oui ou Non | Oui | Demande autorise la liste ACL | | PutBucketAcl | \$1 | Non applicable | \$1 | Oui ou Non | Oui | Demande autorise la liste ACL | **Note** Les opérations `REST.PUT.OBJECT` de la table suivante, sauf indication contraire, indiquent les demandes qui ne définissent pas de liste ACL, sauf si la liste ACL est `bucket-owner-full-control`. 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 valeurs `aclRequired` 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 | Accès intercompte reposant sur la liste 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 | Accès intercompte reposant sur la liste 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 | Accès intercompte reposant sur la liste ACL | | REST.PUT.OBJECT | A | Non applicable | A | Oui ou Non | - | Accès dans le même compte | | REST.PUT.OBJECT | A | Non applicable | B | Oui | - | Accès intercompte accordé par la politique du compartiment | | REST.PUT.OBJECT | A | Non applicable | B | Non | Oui | Accès intercompte reposant sur la liste ACL | | REST.PUT.OBJECT avec une liste ACL (sauf pour bucket-owner-full-control) | \$1 | Non applicable | \$1 | Oui ou Non | Oui | Demande autorise la liste ACL | | REST.GET.BUCKET | A | Non applicable | A | Oui ou Non | - | Accès dans le même compte | | REST.GET.BUCKET | A | Non applicable | B | Oui | - | Accès intercompte accordé par la politique du compartiment | | REST.GET.BUCKET | A | Non applicable | B | Non | Oui | Accès intercompte reposant sur la liste ACL | | REST.DELETE.OBJECT | A | Non applicable | A | Oui ou Non | - | Accès dans le même compte | | REST.DELETE.OBJECT | A | Non applicable | B | Oui | - | Accès intercompte accordé par la politique du compartiment | | REST.DELETE.OBJECT | A | Non applicable | B | Non | Oui | Accès intercompte reposant sur la liste ACL | | REST.PUT.ACL | \$1 | \$1 | \$1 | Oui ou Non | Oui | Demande autorise la liste ACL | ## 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 Amazon S3. Le propriétaire du compartiment possède l’accès `FULL_CONTROL` sur la ressource. En outre, l'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. **Example** ``` 1. 2. 3. 4. Owner-canonical-user-ID 5. 6. 7. 8. 9. Owner-canonical-user-ID 10. 11. FULL_CONTROL 12. 13. 14. 15. 16. user1-canonical-user-ID 17. 18. WRITE 19. 20. 21. 22. 23. user2-canonical-user-ID 24. 25. READ 26. 27. 28. 29. 30. http://acs.amazonaws.com/groups/global/AllUsers 31. 32. READ 33. 34. 35. 36. http://acs.amazonaws.com/groups/s3/LogDelivery 37. 38. WRITE 39. 40. 41. 42. ``` ## Liste ACL prête à l’emploi Amazon S3 prend en charge un ensemble de subventions prédéfinies, appelées « *standardisées ACLs* ». Chaque liste ACL prête à l’emploi 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. | 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\$1CONTROL. 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\$1CONTROL. Le groupe AllUsers (consultez [Qui est un bénéficiaire ?](#specifying-grantee)) obtient l’accès READ. | | public-read-write | Compartiment et objet | Le propriétaire obtient l’accès FULL\$1CONTROL. 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\$1CONTROL. Amazon EC2 obtient l’accès READ pour faire une demande GET sur une solution groupée Amazon Machine Image (AMI) issu d’Amazon S3. | | authenticated-read | Compartiment et objet | Le propriétaire obtient l’accès FULL\$1CONTROL. Le groupe AuthenticatedUsers obtient l’accès READ. | | bucket-owner-read | Objet | Le propriétaire de l’objet obtient l’accès FULL\$1CONTROL. Le propriétaire du compartiment obtient l’accès READ. Si vous spécifiez cette ACL prédéfinie 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\$1CONTROL sur l’objet. Si vous spécifiez cette ACL prédéfinie lors de la création du compartiment, Amazon S3 l'ignore. | | log-delivery-write | Compartiment | Le groupe LogDelivery obtient les autorisations WRITE et READ\$1ACP sur le compartiment. Pour plus d’informations sur les journaux, consultez ([Enregistrement de demandes avec journalisation des accès au serveur](ServerLogs.md)). | **Note** Vous ne pouvez spécifier qu'une seule de ces options ACLs prédéfinies dans votre demande. Vous pouvez spécifier une liste ACL prédéfinie dans votre demande grâce à l’en-tête `x-amz-acl`. Lorsqu’Amazon S3 reçoit une demande contenant une liste ACL prédéfinie, il ajoute les accords prédéfinis à la liste ACL de la ressource. # Configuration ACLs Cette section explique comment gérer les autorisations d'accès pour les compartiments et objets S3 à l'aide de listes de contrôle d'accès (ACLs). Vous pouvez ajouter des autorisations à votre ACL de ressources à l'aide de l'API AWS Management Console, AWS Command Line Interface (CLI), REST ou AWS SDKs. Les autorisations de compartiment et d’objet sont indépendantes les unes des autres. un objet n’hérite pas des autorisations de son compartiment. Par exemple, si vous créez un compartiment et accordez un accès en écriture à un utilisateur, vous ne pouvez pas accéder à ses objets sauf s’il vous accorde explicitement l’accès. Vous pouvez accorder des autorisations à d'autres Compte AWS utilisateurs ou à des groupes prédéfinis. L’utilisateur ou le groupe auquel vous accordez des autorisations est le « *bénéficiaire* ». Par défaut, le propriétaire, qui a créé le compartiment, dispose des autorisations complètes. Compte AWS Chaque autorisation accordée pour un utilisateur ou un groupe ajoute une entrée dans la liste ACL associée au compartiment. Les listes ACL répertorient le bénéficiaire et l’autorisation accordée. 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 de ACLs. Nous vous recommandons de rester ACLs désactivé, sauf dans les cas 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](about-object-ownership.md). **Important** Si votre compartiment à usage général utilise Propriétaire du compartiment appliqué pour le paramètre Propriétaire de l’objet S3, vous devez utiliser des stratégies pour accorder l’accès à votre compartiment à usage général 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. **Avertissement** Nous vous recommandons vivement d'éviter d'accorder un accès en écriture aux **groupes **Tout le monde (accès public)** ou Utilisateurs authentifiés (tous les utilisateurs AWS authentifiés)**. Pour en savoir plus sur les effets de l’octroi d’un accès en écriture à ces groupes, consultez [Groupes prédéfinis Amazon S3](acl-overview.md#specifying-grantee-predefined-groups). ## Utilisation de la console S3 pour définir des autorisations ACL pour un compartiment La console affiche les autorisations d’accès combinées pour les bénéficiaires en double. Pour voir la liste complète des ACLs, utilisez l'API REST Amazon S3 AWS CLI, ou AWS SDKs. Le tableau suivant présente les autorisations ACL que vous pouvez configurer pour les compartiments dans la console Amazon S3. **Autorisations ACL de la console Amazon S3 pour les compartiments** | Autorisation de la console | Autorisation de liste ACL | Accès | | --- | --- | --- | | Objets – Liste | READ | Elles permettent au bénéficiaire de répertorier les objets dans le compartiment. | | Objets – Écriture | 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. | | ACL de compartiment – Lecture | READ\$1ACP | Elles permettent au bénéficiaire de lire la liste ACL du compartiment. | | ACL de compartiment – Écriture | WRITE\$1ACP | Elles permettent au bénéficiaire d’écrire la liste ACL pour le compartiment applicable. | | Tout le monde (accès public) : Objets – Liste | READ | Elles accordent un accès public en lecture pour les objets se trouvant dans le compartiment. Lorsque vous accordez l’accès à la liste à Tout le monde (accès public), quiconque dans le monde peut accéder aux objets présents dans le compartiment. | | Tout le monde (accès public) : ACL de compartiment – Lecture | READ\$1ACP | Elles accordent un accès public en lecture pour l’ACL de compartiment. Lorsque vous accordez l’accès en lecture à Tout le monde (accès public), quiconque dans le monde peut accéder à l’ACL de compartiment. | Pour plus d’informations sur les autorisations ACL, consultez [Présentation de la liste de contrôle d’accès (ACL)](acl-overview.md). **Important** Si votre compartiment à usage général utilise Propriétaire du compartiment appliqué pour le paramètre Propriétaire de l’objet S3, vous devez utiliser des stratégies pour accorder l’accès à votre compartiment à usage général 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. **Pour définir des autorisations de listes ACL pour un compartiment** 1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Dans le volet de navigation de gauche, choisissez **Compartiments à usage général**. 1. Dans la liste **Compartiments**, choisissez le nom du compartiment pour lequel vous souhaitez définir des autorisations. 1. Choisissez **Permissions**. 1. Sous **Liste de contrôle d’accès**, choisissez **Modifier**. Vous pouvez modifier les autorisations ACL suivantes pour le compartiment : **Objets** + **List** – Permet au bénéficiaire de lister les objets dans le compartiment. + **Write (Écriture)** – Permet 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. Dans la console S3, vous pouvez uniquement accorder un accès en écriture au groupe de mise à disposition de journaux S3 et au propriétaire du compartiment (le vôtre Compte AWS). Nous vous recommandons vivement de ne pas accorder l’accès en écriture aux autres bénéficiaires. Toutefois, si vous devez accorder un accès en écriture, vous pouvez utiliser l'API AWS CLI AWS SDKs, ou REST. **ACL du compartiment** + **Read** – Permet au bénéficiaire de lire la liste ACL du compartiment. + **Write** – Permet au bénéficiaire d’écrire la liste ACL pour le compartiment applicable. 1. Pour modifier les autorisations du propriétaire du bucket, à côté du **propriétaire du bucket (votre Compte AWS)**, effacez ou sélectionnez l'une des autorisations ACL suivantes : + **Objets** — **Liste** ou **Écriture** + **ACL de compartiment** — **Lecture** ou **Écriture** Le *propriétaire* fait référence à l'utilisateur Utilisateur racine d'un compte AWS, et non à un utilisateur Gestion des identités et des accès AWS IAM. Pour plus d’informations sur l’utilisateur root, consultez [Utilisateur racine d'un compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) dans le *Guide de l’utilisateur IAM*. 1. Pour octroyer ou annuler des autorisations pour le grand public (tout le monde sur Internet), en regard de **Tout le monde (accès public)**, désactivez ou sélectionnez l’une des autorisations ACL suivantes : + **Objets** — **Liste** + **ACL de compartiment** — **Lecture** **Avertissement** Soyez vigilant lorsque vous accordez au groupe **Tout le monde** l’accès public à votre compartiment S3. Lorsque vous accordez l’accès à ce groupe, tout le monde peut accéder à votre compartiment. Nous vous recommandons vivement de ne jamais accorder un type d’accès en écriture public quel qu’il soit à votre compartiment S3. 1. Pour accorder ou annuler des autorisations à toute personne disposant d'un Compte AWS**groupe d'utilisateurs authentifiés (toute personne possédant un Compte AWS), effacez** ou sélectionnez l'une des autorisations ACL suivantes : + **Objets** — **Liste** + **ACL de compartiment** — **Lecture** 1. Pour octroyer ou annuler des autorisations à Amazon S3 pour écrire des journaux d’accès au serveur dans le compartiment, sous **Groupe de mise à disposition des journaux S3**, désactivez ou sélectionnez l’une des autorisations ACL suivantes : + **Objets** — **Liste** ou **Écriture** + **ACL de compartiment** — **Lecture** ou **Écriture** Si un compartiment est configuré en tant que compartiment cible (les journaux d’accès y seront stockés), les autorisations sur ce compartiment doivent autoriser le groupe **Livraison des journaux** à disposer d’un accès en écriture sur le compartiment. Lorsque vous activez la journalisation des accès serveur sur un compartiment, la console Amazon S3 accorde au groupe **Log Delivery (Livraison des journaux)** un droit d’accès en écriture sur le compartiment que vous avez choisi pour la réception des journaux. Pour en savoir plus sur la journalisation des accès au serveur, consultez [Activation de la journalisation des accès au serveur Amazon S3](enable-server-access-logging.md). 1. Pour accorder l'accès à une autre Compte AWS personne, procédez comme suit : 1. Choisissez **Ajouter un bénéficiaire**. 1. Dans la zone **Bénéficiaire**, saisissez l’ID canonique de l’autre Compte AWS. 1. Sélectionnez l’une des autorisations ACL suivantes : + **Objets** — **Liste** ou **Écriture** + **ACL de compartiment** — **Lecture** ou **Écriture** **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 intercompte*. Pour en savoir plus sur l’utilisation de l’accès intercompte, consultez [Création d’un rôle pour la délégation d’autorisations à un utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*. 1. Pour supprimer l'accès à un autre Compte AWS, sous **Accès pour les autres Comptes AWS**, choisissez **Supprimer**. 1. Sélectionnez **Enregistrer** pour enregistrer les modifications. ## Utilisation de la console S3 pour définir des autorisations ACL pour un objet La console affiche les autorisations d’accès combinées pour les bénéficiaires en double. Pour voir la liste complète des ACLs, utilisez l'API REST Amazon S3 AWS CLI, ou AWS SDKs. Le tableau suivant présente les autorisations ACL que vous pouvez configurer pour les objets dans la console Amazon S3. **Autorisations ACL de la console Amazon S3 pour les objets** | Autorisation de la console | Autorisation de liste ACL | Accès | | --- | --- | --- | | Objet – Lecture | READ | Elles permettent au bénéficiaire de lire les données de l’objet et ses métadonnées. | | ACL de l’objet – Lecture | READ\$1ACP | Elles permettent au bénéficiaire de lire la liste ACL de l’objet. | | ACL de l’objet – Écriture | WRITE\$1ACP | Elles permettent au bénéficiaire d'écrire la liste ACL pour l'objet applicable | Pour plus d’informations sur les autorisations ACL, consultez [Présentation de la liste de contrôle d’accès (ACL)](acl-overview.md). **Important** Si votre compartiment à usage général utilise Propriétaire du compartiment appliqué pour le paramètre Propriétaire de l’objet S3, vous devez utiliser des stratégies pour accorder l’accès à votre compartiment à usage général 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. **Pour définir des autorisations de liste ACL pour un objet** 1. Connectez-vous à la console Amazon S3 AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/). 1. Dans la liste **Buckets (Compartiments)**, choisissez le nom du compartiment qui contient l'objet. 1. Dans la liste **Objets**, sélectionnez le nom de l’objet pour lequel vous souhaitez définir des autorisations. 1. Choisissez **Permissions**. 1. Sous Liste de contrôle d’accès (ACL), sélectionnez **Modifier**. Vous pouvez modifier les autorisations ACL suivantes pour l’objet : **Objet** + **Read** – Permet au bénéficiaire de lire les données de l’objet et ses métadonnées. **Liste ACL de l’objet** + **Read** – Permet au bénéficiaire de lire la liste ACL de l’objet. + **Write** – Permet au bénéficiaire d’écrire la liste ACL pour l’objet applicable. Dans la console S3, vous ne pouvez accorder l'accès en écriture qu'au propriétaire du compartiment (le vôtre Compte AWS). Nous vous recommandons vivement de ne pas accorder l’accès en écriture aux autres bénéficiaires. Toutefois, si vous devez accorder un accès en écriture, vous pouvez utiliser l'API AWS CLI AWS SDKs, ou REST. 1. Vous pouvez gérer les autorisations d’accès aux objets pour : 1. **Accès pour le propriétaire de l’objet** Le *propriétaire* fait référence à Utilisateur racine d'un compte AWS, et non à un utilisateur Gestion des identités et des accès AWS IAM. Pour plus d’informations sur l’utilisateur root, consultez [Utilisateur racine d'un compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) dans le *Guide de l’utilisateur IAM*. Pour modifier les autorisations d'accès aux objets du propriétaire, sous **Accès pour le propriétaire de l'objet**, sélectionnez **Votre AWS compte (propriétaire)**. Activez les cases à cocher des autorisations que vous souhaitez modifier, puis choisissez **Enregistrer**. 1. **Accès pour les autres Comptes AWS** Pour accorder des autorisations à un autre AWS utilisateur Compte AWS, sous **Accès pour les autres Comptes AWS**, sélectionnez **Ajouter un compte**. Dans le champ **Entrez un identifiant**, entrez l'identifiant canonique de l' AWS utilisateur auquel vous souhaitez accorder des autorisations d'objets. Pour plus d'informations sur la recherche d'un identifiant canonique, consultez la section [Vos Compte AWS identifiants](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) dans le. *Référence générale d'Amazon Web Services* Vous pouvez ajouter jusqu’à 99 utilisateurs. Activez les cases à cocher des autorisations que vous souhaitez accorder à l’utilisateur, puis choisissez **Enregistrer**. Pour afficher des informations sur les autorisations, choisissez les icônes d’aide. 1. **Accès public** Pour permettre au grand public (tout le monde) d’accéder à votre objet, sous **Accès public**, sélectionnez **Tout le monde**. Si vous accordez des autorisations d’accès public, tout le monde peut accéder à l’objet. Activez les cases à cocher des autorisations que vous souhaitez accorder, puis choisissez **Enregistrer**. **Avertissement** Soyez vigilant lorsque vous accordez au groupe **Everyone (Tout le monde)** l’accès anonyme à vos objets Amazon S3. Lorsque vous accordez l’accès à ce groupe, tout le monde peut accéder à votre objet. Si vous avez besoin d’accorder l’accès à tout le monde, nous vous recommandons vivement d’octroyer uniquement des autorisations **Lecture d’objet**. Nous vous recommandons de *ne pas* accorder des autorisations d’écriture sur l’objet au groupe **Tout le monde**. Si vous le faites, n’importe qui peut remplacer les autorisations de liste ACL pour l’objet. ## En utilisant le AWS SDKs Cette section fournit des exemples de configuration des attributions de liste ACL sur les compartiments et les objets. **Important** Si votre compartiment à usage général utilise Propriétaire du compartiment appliqué pour le paramètre Propriétaire de l’objet S3, vous devez utiliser des stratégies pour accorder l’accès à votre compartiment à usage général 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. ------ #### [ Java ] Cette section fournit des exemples de configuration des attributions de liste ACL sur les compartiments et les objets. Le premier exemple crée un compartiment avec une liste ACL prête à l’emploi (voir [Liste ACL prête à l’emploi](acl-overview.md#canned-acl)), crée une liste personnalisée d’attributions d’autorisation, puis remplace l’ACL prête à l’emploi avec une ACL contenant les attributions personnalisées. Le second exemple montre comment modifier une ACL à l’aide de la méthode `AccessControlList.grantPermission()`. **Example Créer un compartiment et spécifier une liste ACL conservée qui octroie une autorisation au groupe de mise à disposition du journal S3** Cet exemple crée un compartiment. Dans le demande, l’exemple spécifie une liste ACL prête à l’emploi qui attribue au groupe Log Delivery l’autorisation d’écrire des journaux sur le compartiment. ``` import com.amazonaws.AmazonServiceException; import com.amazonaws.SdkClientException; import com.amazonaws.regions.Regions; import com.amazonaws.services.s3.AmazonS3; import com.amazonaws.services.s3.AmazonS3ClientBuilder; import com.amazonaws.services.s3.model.*; import java.io.IOException; import java.util.ArrayList; public class CreateBucketWithACL { public static void main(String[] args) throws IOException { Regions clientRegion = Regions.DEFAULT_REGION; String bucketName = "*** Bucket name ***"; String userEmailForReadPermission = "*** user@example.com ***"; try { AmazonS3 s3Client = AmazonS3ClientBuilder.standard() .withRegion(clientRegion) .build(); // Create a bucket with a canned ACL. This ACL will be replaced by the // setBucketAcl() // calls below. It is included here for demonstration purposes. CreateBucketRequest createBucketRequest = new CreateBucketRequest(bucketName, clientRegion.getName()) .withCannedAcl(CannedAccessControlList.LogDeliveryWrite); s3Client.createBucket(createBucketRequest); // Create a collection of grants to add to the bucket. ArrayList grantCollection = new ArrayList(); // Grant the account owner full control. Grant grant1 = new Grant(new CanonicalGrantee(s3Client.getS3AccountOwner().getId()), Permission.FullControl); grantCollection.add(grant1); // Grant the LogDelivery group permission to write to the bucket. Grant grant2 = new Grant(GroupGrantee.LogDelivery, Permission.Write); grantCollection.add(grant2); // Save grants by replacing all current ACL grants with the two we just created. AccessControlList bucketAcl = new AccessControlList(); bucketAcl.grantAllPermissions(grantCollection.toArray(new Grant[0])); s3Client.setBucketAcl(bucketName, bucketAcl); // Retrieve the bucket's ACL, add another grant, and then save the new ACL. AccessControlList newBucketAcl = s3Client.getBucketAcl(bucketName); Grant grant3 = new Grant(new EmailAddressGrantee(userEmailForReadPermission), Permission.Read); newBucketAcl.grantAllPermissions(grant3); s3Client.setBucketAcl(bucketName, newBucketAcl); } catch (AmazonServiceException e) { // The call was transmitted successfully, but Amazon S3 couldn't process // it and returned an error response. e.printStackTrace(); } catch (SdkClientException e) { // Amazon S3 couldn't be contacted for a response, or the client // couldn't parse the response from Amazon S3. e.printStackTrace(); } } } ``` **Example Mettre à jour la liste ACL sur un objet existant** L’exemple met à jour l’ACL sur un objet. L’exemple exécute les tâches suivantes : + Extrait l’ACL d’un objet + Efface la liste ACL en supprimant toutes les autorisations existantes + Ajoute deux autorisations : plein accès au propriétaire, et WRITE\$1ACP (voir [Quelles autorisations puis-je octroyer ?](acl-overview.md#permissions)) à un utilisateur identifié par une adresse e-mail + Enregistre l’ACL sur l’objet ``` import com.amazonaws.AmazonServiceException; import com.amazonaws.SdkClientException; import com.amazonaws.auth.profile.ProfileCredentialsProvider; import com.amazonaws.regions.Regions; import com.amazonaws.services.s3.AmazonS3; import com.amazonaws.services.s3.AmazonS3ClientBuilder; import com.amazonaws.services.s3.model.AccessControlList; import com.amazonaws.services.s3.model.CanonicalGrantee; import com.amazonaws.services.s3.model.EmailAddressGrantee; import com.amazonaws.services.s3.model.Permission; import java.io.IOException; public class ModifyACLExistingObject { public static void main(String[] args) throws IOException { Regions clientRegion = Regions.DEFAULT_REGION; String bucketName = "*** Bucket name ***"; String keyName = "*** Key name ***"; String emailGrantee = "*** user@example.com ***"; try { AmazonS3 s3Client = AmazonS3ClientBuilder.standard() .withCredentials(new ProfileCredentialsProvider()) .withRegion(clientRegion) .build(); // Get the existing object ACL that we want to modify. AccessControlList acl = s3Client.getObjectAcl(bucketName, keyName); // Clear the existing list of grants. acl.getGrantsAsList().clear(); // Grant a sample set of permissions, using the existing ACL owner for Full // Control permissions. acl.grantPermission(new CanonicalGrantee(acl.getOwner().getId()), Permission.FullControl); acl.grantPermission(new EmailAddressGrantee(emailGrantee), Permission.WriteAcp); // Save the modified ACL back to the object. s3Client.setObjectAcl(bucketName, keyName, acl); } catch (AmazonServiceException e) { // The call was transmitted successfully, but Amazon S3 couldn't process // it, so it returned an error response. e.printStackTrace(); } catch (SdkClientException e) { // Amazon S3 couldn't be contacted for a response, or the client // couldn't parse the response from Amazon S3. e.printStackTrace(); } } } ``` ------ #### [ .NET ] **Example Créer un compartiment et spécifier une liste ACL conservée qui octroie une autorisation au groupe de mise à disposition du journal S3** Cet exemple C\$1 crée un compartiment. Dans le demande, le code spécifie aussi une liste ACL prête à l’emploi qui attribue au groupe Log Delivery l’autorisation d’écrire les journaux sur le compartiment. Pour plus d'informations sur la configuration et l'exécution des exemples de code, consultez [Getting Started with the AWS SDK for](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html) .NET dans *AWS le Guide du développeur du SDK pour* .NET. ``` using Amazon; using Amazon.S3; using Amazon.S3.Model; using System; using System.Threading.Tasks; namespace Amazon.DocSamples.S3 { class ManagingBucketACLTest { private const string newBucketName = "*** bucket name ***"; // Specify your bucket region (an example region is shown). private static readonly RegionEndpoint bucketRegion = RegionEndpoint.USWest2; private static IAmazonS3 client; public static void Main() { client = new AmazonS3Client(bucketRegion); CreateBucketUseCannedACLAsync().Wait(); } private static async Task CreateBucketUseCannedACLAsync() { try { // Add bucket (specify canned ACL). PutBucketRequest putBucketRequest = new PutBucketRequest() { BucketName = newBucketName, BucketRegion = S3Region.EUW1, // S3Region.US, // Add canned ACL. CannedACL = S3CannedACL.LogDeliveryWrite }; PutBucketResponse putBucketResponse = await client.PutBucketAsync(putBucketRequest); // Retrieve bucket ACL. GetACLResponse getACLResponse = await client.GetACLAsync(new GetACLRequest { BucketName = newBucketName }); } catch (AmazonS3Exception amazonS3Exception) { Console.WriteLine("S3 error occurred. Exception: " + amazonS3Exception.ToString()); } catch (Exception e) { Console.WriteLine("Exception: " + e.ToString()); } } } } ``` **Example Mettre à jour la liste ACL sur un objet existant** L’exemple C\$1 met à jour l’ACL sur un objet existant. L'exemple exécute les tâches suivantes : + Extrait l’ACL d’un objet. + Efface la liste ACL en supprimant toutes les autorisations existantes. + Ajoute deux autorisations : plein accès au propriétaire, et WRITE\$1ACP à un utilisateur identifié par une adresse e-mail. + Enregistre l’ACL en envoyant une demande `PutAcl`. Pour plus d'informations sur la configuration et l'exécution des exemples de code, consultez [Getting Started with the AWS SDK for](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-setup.html) .NET dans *AWS le Guide du développeur du SDK pour* .NET. ``` using Amazon; using Amazon.S3; using Amazon.S3.Model; using System; using System.Collections.Generic; using System.Threading.Tasks; namespace Amazon.DocSamples.S3 { class ManagingObjectACLTest { private const string bucketName = "*** bucket name ***"; private const string keyName = "*** object key name ***"; private const string emailAddress = "*** email address ***"; // Specify your bucket region (an example region is shown). private static readonly RegionEndpoint bucketRegion = RegionEndpoint.USWest2; private static IAmazonS3 client; public static void Main() { client = new AmazonS3Client(bucketRegion); TestObjectACLTestAsync().Wait(); } private static async Task TestObjectACLTestAsync() { try { // Retrieve the ACL for the object. GetACLResponse aclResponse = await client.GetACLAsync(new GetACLRequest { BucketName = bucketName, Key = keyName }); S3AccessControlList acl = aclResponse.AccessControlList; // Retrieve the owner (we use this to re-add permissions after we clear the ACL). Owner owner = acl.Owner; // Clear existing grants. acl.Grants.Clear(); // Add a grant to reset the owner's full permission (the previous clear statement removed all permissions). S3Grant fullControlGrant = new S3Grant { Grantee = new S3Grantee { CanonicalUser = owner.Id }, Permission = S3Permission.FULL_CONTROL }; // Describe the grant for the permission using an email address. S3Grant grantUsingEmail = new S3Grant { Grantee = new S3Grantee { EmailAddress = emailAddress }, Permission = S3Permission.WRITE_ACP }; acl.Grants.AddRange(new List { fullControlGrant, grantUsingEmail }); // Set a new ACL. PutACLResponse response = await client.PutACLAsync(new PutACLRequest { BucketName = bucketName, Key = keyName, AccessControlList = acl }); } catch (AmazonS3Exception amazonS3Exception) { Console.WriteLine("An AmazonS3Exception was thrown. Exception: " + amazonS3Exception.ToString()); } catch (Exception e) { Console.WriteLine("Exception: " + e.ToString()); } } } } ``` ------ ## Utilisation de l'API REST Amazon S3 vous APIs permet de définir une ACL lorsque vous créez un bucket ou un objet. Amazon S3 fournit une API pour configurer une liste ACL sur un compartiment ou un objet existant. Elles APIs fournissent les méthodes suivantes pour définir une ACL : + **Configurer 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). + **Configurer 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 sur la prise en charge de la gestion par l'API REST ACLs, consultez les sections suivantes du *manuel Amazon Simple Storage Service API Reference* : + [GetBucketAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketGETacl.html) + [PutBucketAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTacl.html) + [GetObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGETacl.html) + [PutObjectAcl](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUTacl.html) + [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html) + [CreateBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUT.html) + [CopyObject](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html) + [CreateMultipartUpload](https://docs.aws.amazon.com/AmazonS3/latest/API/mpUploadInitiate.html) **Important** Si votre compartiment à usage général utilise Propriétaire du compartiment appliqué pour le paramètre Propriétaire de l’objet S3, vous devez utiliser des stratégies pour accorder l’accès à votre compartiment à usage général 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. ### En-têtes de demande spécifiques à une liste de contrôle d’accès (ACL) Vous pouvez utiliser des en-têtes pour accorder des autorisations basées sur la liste de contrôle d’accès (ACL). Par défaut, tous les objets sont privés. Seul le propriétaire dispose d’un contrôle d’accès complet. Lorsque vous ajoutez un nouvel objet, vous pouvez accorder des autorisations à des individus Comptes AWS ou à des groupes prédéfinis définis par Amazon S3. Ces autorisations sont ensuite ajoutées à la liste de contrôle d’accès (ACL) sur l’objet. Pour plus d’informations, consultez [Présentation de la liste de contrôle d’accès (ACL)](acl-overview.md). Avec cette opération, vous pouvez accorder des autorisations d’accès en utilisant l’une des deux méthodes suivantes : + **ACL prédéfini (`x-amz-acl`)** : Amazon S3 prend en charge un ensemble de paramètres prédéfinis ACLs, appelés « scannés ACLs ». Chaque liste ACL prête à l'emploi possède un ensemble prédéfini de bénéficiaires et d'autorisations. Pour de plus amples informations, veuillez consulter [Liste ACL prête à l’emploi](acl-overview.md#canned-acl). + **Autorisations d'accès** — Pour accorder explicitement des autorisations d'accès à des groupes Comptes AWS ou à des groupes spécifiques, utilisez les en-têtes suivants. Chaque en-tête correspond à des autorisations spécifiques prises en charge par Amazon S3 dans une liste ACL. Pour plus d’informations, consultez [Présentation de la liste de contrôle d’accès (ACL)](acl-overview.md). Dans l’en-tête, vous spécifiez une liste de bénéficiaires qui obtiennent l’autorisation spécifique. + x-amz-grant-read + x-amz-grant-write + x-amz-grant-read-acp + x-amz-grant-write-acp + x-amz-grant-full-contrôle ## À l'aide du AWS CLI Pour plus d'informations sur la gestion de l' ACLs utilisation du AWS CLI, voir [put-bucket-acl](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-acl.html)la *référence des AWS CLI commandes*. **Important** Si votre compartiment à usage général utilise Propriétaire du compartiment appliqué pour le paramètre Propriétaire de l’objet S3, vous devez utiliser des stratégies pour accorder l’accès à votre compartiment à usage général 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. # Exemples de politiques pour ACLs Vous pouvez utiliser des clés de condition dans les stratégies de compartiment pour contrôler l’accès à Amazon S3. **Topics** + [Octroi de s3 : PutObject autorisation assortie d'une condition obligeant le propriétaire du bucket à obtenir le contrôle total](#grant-putobject-conditionally-1) + [Octroi de s3 : PutObject autorisation avec une condition sur l' x-amz-aclen-tête](#example-acl-header) ## Octroi de s3 : PutObject autorisation assortie d'une condition obligeant le propriétaire du bucket à obtenir le contrôle total L’opération [PUT Object](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html) autorise les en-têtes spécifiques à la liste de contrôle d’accès (ACL) que vous pouvez utiliser pour accorder des autorisations basées sur les listes ACL. En utilisant ces clés, le propriétaire du compartiment peut définir une condition pour nécessiter des autorisations d’accès spécifiques quand l’utilisateur charge un objet. Supposons que le Compte A possède un compartiment et que l’administrateur du compte souhaite accorder à Dave, un utilisateur du Compte B, des autorisations pour charger des objets. Par défaut, les objets que Dave charge appartiennent au Compte B et le Compte A n’a aucune autorisation sur ces objets. Le propriétaire du compartiment payant les factures, il souhaite toutes les autorisations sur les objets que Dave charge. L’administrateur du Compte A peut accomplir cela en octroyant l’autorisation `s3:PutObject` à Dave, avec une condition que la demande inclue des en-têtes spécifiques à la liste ACL, qui soit accorde explicitement une autorisation complète, soit utilise une liste ACL prédéfinie. Pour plus d’informations, consultez [Objet PUT](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPUT.html). ### Exiger l' x-amz-full-controlen-tête Vous pouvez exiger l’en-tête `x-amz-full-control` dans la demande avec une autorisation de contrôle total pour le propriétaire du compartiment. La stratégie de compartiment suivante octroie l’autorisation `s3:PutObject` à l’utilisateur Dave avec une condition utilisant la clé de condition `s3:x-amz-grant-full-control`, qui nécessite que la demande inclut l’en-tête `x-amz-full-control`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] } ``` ------ **Note** Cet exemple porte sur l’autorisation entre comptes. Toutefois, si Dave (qui obtient l'autorisation) appartient au propriétaire du Compte AWS bucket, cette autorisation conditionnelle n'est pas nécessaire. En effet, le compte parent auquel Dave appartient possède des objets que l’utilisateur charge. **Ajouter un refus explicite** La stratégie de compartiment précédente octroie l’autorisation conditionnelle à l’utilisateur Dave du compte B. Tandis que cette stratégie est appliquée, il est possible pour Dave d’obtenir la même autorisation sans aucune condition par le biais d’autres stratégies. Par exemple, Dave peut appartenir à un groupe et vous octroyez l’autorisation `s3:PutObject` de groupe sans aucune condition. Pour éviter de telles failles d’autorisation, vous pouvez écrire une stratégie d’accès plus stricte en ajoutant un refus explicite. Dans cet exemple, vous refusez explicitement à l’utilisateur Dave l’autorisation de chargement s’il n’inclut pas les en-têtes nécessaires dans la demande octroyant des autorisations complète au propriétaire du compartiment. Le refus explicite a toujours priorité sur n’importe quelle autre autorisation accordée. Vous trouverez, ci-après, l’exemple révisé de stratégie d’accès avec un refus explicite ajouté. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::111122223333:user/AccountBadmin" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringNotEquals": { "s3:x-amz-grant-full-control": "id=AccountA-CanonicalUserID" } } } ] } ``` ------ **Testez la politique à l'aide du AWS CLI** Si vous en avez deux Comptes AWS, vous pouvez tester la politique à l'aide du AWS Command Line Interface (AWS CLI). Vous joignez la politique et utilisez les informations d'identification de Dave pour tester l'autorisation à l'aide de la AWS CLI `put-object` commande suivante. Vous fournissez les informations d’identification de Dave en ajoutant le paramètre `--profile`. Vous octroyez l’autorisation de contrôle complet au propriétaire du compartiment en ajoutant le paramètre `--grant-full-control`. Pour plus d'informations sur la configuration et l'utilisation du AWS CLI, consultez la section [Développement avec Amazon S3 à l'aide de la AWS CLI](https://docs.aws.amazon.com/AmazonS3/latest/API/setup-aws-cli.html) dans le *manuel Amazon S3 API Reference*. ``` aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --grant-full-control id="AccountA-CanonicalUserID" --profile AccountBUserProfile ``` ### Exiger l' x-amz-aclen-tête Vous pouvez exiger l’en-tête `x-amz-acl` avec une liste ACL prédéfinie octroyant une autorisation de contrôle complet au propriétaire du compartiment. Pour demander l’en-tête `x-amz-acl` dans la demande, vous pouvez remplacer la paire de clé-valeur dans le bloc `Condition` et spécifier la clé de condition `s3:x-amz-acl` comme indiqué dans l’exemple suivant. ``` "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } ``` Pour tester l'autorisation à l'aide du AWS CLI, vous devez spécifier le `--acl` paramètre. Il ajoute AWS CLI ensuite l'`x-amz-acl`en-tête lorsqu'il envoie la demande. ``` aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin ``` ## Octroi de s3 : PutObject autorisation avec une condition sur l' x-amz-aclen-tête La politique de compartiment suivante accorde l'`s3:PutObject`autorisation à deux personnes Comptes AWS si la demande inclut l'`x-amz-acl`en-tête rendant l'objet lisible par le public. Le bloc `Condition` utilise la condition `StringEquals` et elle dispose d’une paire de clé-valeur, `"s3:x-amz-acl":["public-read"]`, pour évaluation. Dans la paire de clé-valeur, `s3:x-amz-acl` est une clé propre à Amazon S3, comme indiqué par le préfixe `s3:`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AddCannedAcl", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::111122223333:root" ] }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::awsexamplebucket1/*" ], "Condition": { "StringEquals": { "s3:x-amz-acl": [ "public-read" ] } } } ] } ``` ------ **Important** Les conditions ne sont pas toutes logiques pour toutes les actions. Par exemple, il est logique d’inclure une condition `s3:LocationConstraint` sur une stratégie qui octroie l’autorisation Amazon S3 `s3:CreateBucket`. Cependant, il n’est pas logique d’inclure cette condition dans une politique qui accorde l’autorisation `s3:GetObject`. Amazon S3 peut rechercher les erreurs sémantiques pour ce type qui impliquent des conditions spécifiques à Amazon S3. Cependant, si vous créez une stratégie pour un rôle ou un utilisateur IAM et que vous incluez une condition Amazon S3 non valide sémantiquement, aucune erreur n’est rapportée, car IAM ne peut pas valider les conditions Amazon S3.