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.
# 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.