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 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 PUTObject autorise les en-têtes spécifiques à la liste de contrôle d'accès (ACL) que vous pouvez utiliser pour accorder des autorisations ACL basées sur des autorisations. 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 le faire en accordant l's3:PutObject
autorisation à Dave, à condition que la demande inclue ACL des en-têtes spécifiques qui accordent explicitement l'autorisation complète ou utilisent un fichier prédéfini. ACL Pour plus d'informations, consultez la section PUTObjet.
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
.
{ "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 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é.
{ "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 AWS CLI à l'aide du document de APIréférence Amazon S3.
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'x-amz-acl
en-tête avec un fichier prédéfini ACL octroyant une autorisation de contrôle total au propriétaire du bucket. 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. Toutefois, si vous créez une politique pour un IAM utilisateur ou un rôle et que vous incluez une condition Amazon S3 non valide du point de vue sémantique, aucune erreur n'est signalée car les conditions Amazon S3 IAM ne peuvent pas être validées.