Exemples de politiques pour ACLs - Amazon Simple Storage Service

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.

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:PutObjectautorisation à 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-control en-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 Compte AWS propriétaire du 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 en utilisant les méthodes suivantes AWS CLI put-objectcommande. 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, voir Développement avec Amazon S3 à l'aide de la AWS CLI.

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-acl en-tête

Vous pouvez exiger l'x-amz-aclen-tête avec un fichier prédéfini ACL accordant 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 spécifiez le --acl paramètre. Le AWS CLI ajoute ensuite l'x-amz-aclen-tête lors de l'envoi de 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-acl en-tête

La politique de compartiment suivante accorde l's3:PutObjectautorisation à deux Comptes AWS si la demande inclut l'x-amz-aclen-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.