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.
Vous pouvez utiliser des clés de condition dans les politiques de compartiment pour contrôler l’accès à Amazon S3.
Rubriques
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 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.
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 politique 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
.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
AccountB-ID
: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 politique 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é.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
AccountB-ID
: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::AccountB-ID
: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 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:
.
{ "Version":"2012-10-17", "Statement": [ { "Sid":"AddCannedAcl", "Effect":"Allow", "Principal": { "AWS": [ "arn:aws:iam::
Account1-ID
:root", "arn:aws:iam::Account2-ID
: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.