Exemples de clés de condition Amazon S3 - Amazon Simple Storage Service

Exemples de clés de condition Amazon S3

Vous pouvez utiliser le langage d'access policy pour spécifier des conditions lorsque vous accordez des autorisations. Vous pouvez utiliser l'élément Condition facultatif ou le bloc Condition pour spécifier des conditions lorsqu'une stratégie est appliquée.

Pour les stratégies qui utilisent des clés de condition Amazon S3 pour les opérations d'objet et de compartiment, consultez les exemples suivants. Pour de plus amples informations sur l'utilisation des clés de condition, consultez la section Clés de condition Amazon S3. Pour obtenir la liste complète des actions, clés de condition et ressources Amazon S3 que vous pouvez spécifier dans les stratégies, veuillez consulter Actions, ressources et clés de condition pour Amazon S3.

Exemples - Clés de condition Amazon S3 pour les opérations sur les objets

Cette section fournit des exemples qui vous montrent comment utiliser des clés de condition spécifiques à Amazon S3 pour les opérations sur les objets. Pour obtenir la liste complète des actions, clés de condition et ressources Amazon S3 que vous pouvez spécifier dans les stratégies, veuillez consulter Actions, ressources et clés de condition pour Amazon S3.

Plusieurs exemples de stratégies montrent comment vous pouvez utiliser des clés de condition avec des opérations PUT Object. Les opérations PUT Object autorisent les entê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. Vous pouvez également accorder des autorisations basées sur l'ACL avec l'opération PutObjectAcl. Pour de plus amples informations, veuillez consulter PutObjectAcl dans la Référence d'API Amazon S3 Amazon Simple Storage Service. Pour en savoir plus sur les listes ACL, consultez Présentation de la liste de contrôle d'accès (ACL).

Exemple 1 : Octroi de l'autorisation s3:PutObject avec une condition qui nécessite que le propriétaire du compartiment ait 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 de plus amples informations, veuillez consulter PUT Object.

Exiger l'en-tête x-amz-full control

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. Cependant, si Dave (qui obtient l'autorisation) appartient au Compte AWS qui possède le compartiment, 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" } } } ] }

Tester la stratégie avec AWS CLI

Si vous possédez deux Comptes AWS, vous pouvez tester la stratégie en utilisant la AWS Command Line Interface (AWS CLI). Vous attachez la stratégie et, à l'aide des informations d'identification de Dave, vous testez l'autorisation en utilisant la commande put-object de l'AWS CLI. 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 de la AWS CLI, consultez 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'en-tête x-amz-acl

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 en utilisant la AWS CLI, vous spécifiez le paramètre --acl. La AWS CLI ajoute ensuite l'en-tête x-amz-acl au moment d'envoyer la demande.

aws s3api put-object --bucket examplebucket --key HappyFace.jpg --body c:\HappyFace.jpg --acl "bucket-owner-full-control" --profile AccountBadmin

Exemple 2 : Octroi de l'autorisation s3:PutObject demandant que les objets soient stockés en utilisant le chiffrement côté serveur

Supposons que le Compte A possède un compartiment. L'administrateur du compte souhaite accorder à Jane, une utilisatrice du Compte A, l'autorisation de télécharger des objets avec comme condition que Jane demande toujours le chiffrement côté serveur afin qu'Amazon S3 enregistre les objets chiffrés. L'administrateur du compte A peut accomplir cela en utilisant la clé de condition s3:x-amz-server-side-encryption comme illustré. La paire de clé-valeur dans le bloc Condition spécifie la clé s3:x-amz-server-side-encryption.

"Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "AES256" }

Lors du test de l'autorisation en utilisant la AWS CLI, vous devez ajouter le paramètre obligatoire à l'aide du paramètre --server-side-encryption.

aws s3api put-object --bucket example1bucket --key HappyFace.jpg --body c:\HappyFace.jpg --server-side-encryption "AES256" --profile AccountBadmin

Exemple 3 : Octroi de l'autorisation s3:PutObject de copier des objets avec une restriction sur la source de copie

Dans la demande PUT Object, quand vous spécifiez un objet source, il s'agit d'une opération de copie (veuillez consulter PUT Object - Copy). En conséquence, le propriétaire du compartiment peut octroyer une autorisation utilisateur pour copier des objets avec des restrictions sur la source, par exemple :

  • Autoriser la copie d'objets uniquement à partir du compartiment sourcebucket.

  • Autoriser la copie d'objets à partir du compartiment source, et uniquement les objets dont le préfixe de nom de clé commence par public/ f (par exemple, sourcebucket/public/*).

  • Autoriser la copie uniquement d'un objet spécifique à partir du compartiment source (par exemple, sourcebucket/example.jpg).

La stratégie de compartiment suivante accorde à l'utilisateur (Dave) l'autorisation s3:PutObject. Celle-ci lui permet de copier des objets uniquement à la condition que la demande inclue l'en-tête s3:x-amz-copy-source et que la valeur de l'en-tête spécifie le préfixe de nom de clé /awsexamplebucket1/public/*.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "cross-account permission to user in your own account", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*" }, { "Sid": "Deny your user permission to upload object if copy source is not /bucket/folder", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringNotLike": { "s3:x-amz-copy-source": "awsexamplebucket1/public/*" } } } ] }

Tester la stratégie avec AWS CLI

Vous pouvez tester l'autorisation en utilisant la commande AWS CLI de copy-object. Vous spécifiez la source en ajoutant le paramètre --copy-source, le préfixe du nom de clé doit correspondre au préfixe autorisé dans la stratégie. Vous devez fournir à l'utilisateur Dave les informations d'identification en utilisant le paramètre --profile. Pour plus d'informations sur la configuration de la AWS CLI, consultez Développement avec Amazon S3 à l'aide de la AWS CLI.

aws s3api copy-object --bucket awsexamplebucket1 --key HappyFace.jpg --copy-source examplebucket/public/PublicHappyFace1.jpg --profile AccountADave

Octroyer une autorisation pour copier uniquement un objet spécifique

La stratégie précédente utilise la condition StringNotLike. Pour octroyer l'autorisation de copier uniquement un objet spécifique, vous devez changer la condition de StringNotLike à StringNotEquals, puis spécifier la clé d'objet exacte comme indiqué.

"Condition": { "StringNotEquals": { "s3:x-amz-copy-source": "awsexamplebucket1/public/PublicHappyFace1.jpg" } }

Exemple 4 : Octroi de l'accès à une version spécifique d'un objet

Supposons que le Compte A possède un compartiment activé pour la version. Le compartiment a plusieurs versions de l'objet HappyFace.jpg. L'administrateur de compte souhaite maintenant octroyer à son utilisateur Dave l'autorisation d'obtenir uniquement une version spécifique de l'objet. L'administrateur de compte peut accomplir cela en octroyant à Dave l'autorisation s3:GetObjectVersion de manière conditionnelle comme indiqué. La paire de clé-valeur dans le bloc Condition spécifie la clé de condition s3:VersionId. Dans ce cas, Dave doit connaître l'ID exact de la version de l'objet pour récupérer l'objet.

Pour de plus amples informations, veuillez consulter GetObject dans la Référence d'API Amazon Simple Storage Service..

{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Dave" }, "Action": "s3:GetObjectVersion", "Resource": "arn:aws:s3:::examplebucketversionenabled/HappyFace.jpg" }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Dave" }, "Action": "s3:GetObjectVersion", "Resource": "arn:aws:s3:::examplebucketversionenabled/HappyFace.jpg", "Condition": { "StringNotEquals": { "s3:VersionId": "AaaHbAQitwiL_h47_44lRO2DDfLlBO5e" } } } ] }

Tester la stratégie avec AWS CLI

Vous pouvez tester les autorisations en utilisant la commande AWS CLI de get-object avec le paramètre --version-id identifiant la version d'objet spécifique. La commande récupère l'objet et l'enregistre dans le fichier OutputFile.jpg.

aws s3api get-object --bucket examplebucketversionenabled --key HappyFace.jpg OutputFile.jpg --version-id AaaHbAQitwiL_h47_44lRO2DDfLlBO5e --profile AccountADave

Exemple 5 : Restreindre les chargements d'objets aux objets avec une classe de stockage spécifique

Supposons que le compte A, représenté par l'ID de compte 123456789012, possède un compartiment. L'administrateur du compte souhaite restreindre Dave, un utilisateur du Compte A, pour qu'il ne puisse charger que des objets dans le compartiment qui seront stockés avec la classe de stockage STANDARD_IA. Pour restreindre les chargements d'objets vers une classe de stockage spécifique, l'administrateur de compte A peut utiliser la clé de condition s3:x-amz-storage-class, comme illustré dans l'exemple de stratégie de compartiment suivant.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Dave" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*", "Condition": { "StringEquals": { "s3:x-amz-storage-class": [ "STANDARD_IA" ] } } } ] }

Exemple 6 : Octroi d'autorisations basées sur des balises d'objets

Pour obtenir des exemples sur l'utilisation des clés de condition de balisage d'objet avec des opérations Amazon S3, veuillez consulter Stratégies de balisage et de contrôle d'accès.

Exemple 7 : Restriction de l'accès par l'ID de Compte AWS du propriétaire du compartiment

Vous pouvez utiliser la clé aws:ResourceAccount ou s3:ResourceAccount pour écrire des politiques IAM ou des politiques de point de terminaison du cloud privé virtuel qui restreignent l'accès des utilisateurs ou des applications aux compartiments Amazon S3 appartenant à un ID de Compte AWS spécifique. Vous pouvez utiliser cette clé de condition si vous souhaitez empêcher les clients de votre VPC d'accéder aux compartiments dont vous n'êtes pas le propriétaire.

Cependant, n'oubliez pas que certains services AWS reposent sur l'accès aux compartiments gérés AWS. Par conséquent, l'utilisation de la clé aws:ResourceAccount ou s3:ResourceAccount dans votre politique IAM risque également d'avoir un impact sur l'accès à ces ressources.

Pour plus d'informations et d'exemples, veuillez consulter les ressources suivantes :

Vous pouvez utiliser la clé de condition aws:ResourceAccount ou s3:ResourceAccount pour écrire des politiques IAM ou des politiques de point de terminaison du cloud privé virtuel qui restreignent l'accès des utilisateurs ou des applications aux compartiments Amazon S3 appartenant à un ID de Compte AWS spécifique. Vous pouvez utiliser cette clé de condition si vous souhaitez empêcher les clients de votre VPC d'accéder aux compartiments dont vous n'êtes pas le propriétaire.

Pour de plus amples informations et d'exemples, veuillez consulter les ressources suivantes :

Exemple 8 : exiger une version minimale de TLS

Vous pouvez utiliser la clé de condition s3:TLSVersion pour écrire des stratégies IAM, VPCE (Virtual Private Cloud Endpoint) ou de compartiment pour restreindre l'accès des utilisateurs ou des applications aux compartiments Amazon S3 en fonction de la version TLS utilisée par le client. Vous pouvez utiliser cette clé de condition pour écrire des stratégies qui nécessitent une version TLS minimale.

Cet exemple de stratégie de compartiment refuse les demandes PutObject des clients dont la version TLS est inférieure à la 1.2, par exemple 1.1 ou 1.0.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-BUCKET1", "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*" ], "Condition": { "NumericLessThan": { "s3:TlsVersion": 1.2 } } } ] }

Cet exemple de stratégie de compartiment autorise les requêtes PutObject par des clients dont la version TLS est supérieure à la 1.1, par exemple 1.2, 1.3 ou supérieure.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-BUCKET1", "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*" ], "Condition": { "NumericGreaterThan": { "s3:TlsVersion": 1.1 } } } ] }

Exemples - Clés de condition Amazon S3 pour les opérations sur les compartiments

Cette section fournit des exemples de stratégies qui vous montrent comment utiliser des clés de condition spécifiques à Amazon S3 pour les opérations sur les compartiments.

Exemple 1 : Octroyer une autorisation à un utilisateur pour créer un compartiment uniquement dans une Région spécifique

Supposons qu'un administrateur de Compte AWS veut octroyer à son utilisateur (Dave) l'autorisation de créer un compartiment uniquement dans la Région Amérique du Sud (São Paulo). L'administrateur de compte peut attacher la stratégie d'utilisateur suivant octroyant l'autorisation s3:CreateBucket avec une condition comme indiqué. La paire de clé-valeur dans le bloc Condition spécifie la clé s3:LocationConstraint et la Région sa-east-1 comme sa valeur.

Note

Dans cet exemple, le propriétaire du compartiment octroie l'autorisation à un de ses utilisateurs. Par conséquent une stratégie de compartiment ou une stratégie d'utilisateur peuvent être utilisées. Cette exemple illustre une stratégie d'utilisateur.

Pour obtenir la liste des Régions Amazon S3, veuillez consulter Régions et points de terminaison dans les Références générales AWS.

{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::*", "Condition": { "StringLike": { "s3:LocationConstraint": "sa-east-1" } } } ] }

Ajouter un refus explicite

La stratégie précédente limite la création, par l'utilisateur, d'un compartiment dans une autre Région à l'exception de sa-east-1. Toutefois, une autre stratégie peut accorder à cet utilisateur l'autorisation de créer des compartiments dans une autre Région. Par exemple, si l'utilisateur appartient à un groupe, une stratégie peut être attachée à ce groupe, autorisant tous les utilisateurs du groupe à créer des compartiments dans une autre Région. Pour garantir que l'utilisateur n'obtienne pas l'autorisation de créer des compartiments dans une autre Région, vous pouvez ajouter une instruction de refus explicite dans la stratégie ci-dessus.

L'instruction Deny utilise la condition StringNotLike. C'est-à-dire qu'une demande de création de compartiment est refusée si la contrainte d'emplacement n'est pas sa-east-1. Le refus explicite n'autorise pas l'utilisateur à créer un compartiment dans une autre Région, peu importe l'autre autorisation que l'utilisateur obtient. La stratégie ci-dessous inclut une déclaration de refus explicite.

{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::*", "Condition": { "StringLike": { "s3:LocationConstraint": "sa-east-1" } } }, { "Sid":"statement2", "Effect":"Deny", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::*", "Condition": { "StringNotLike": { "s3:LocationConstraint": "sa-east-1" } } } ] }

Tester la stratégie avec AWS CLI

Vous pouvez tester la stratégie en utilisant la commande create-bucket de la AWS CLI suivante. Cet exemple utilise le fichier bucketconfig.txt pour spécifier la contrainte d'emplacement. Notez le chemin de fichiers Windows. Vous devez mettre à jour le nom du compartiment et le chemin comme approprié. Vous devez fournir les informations d'identification utilisateur en utilisant le paramètre --profile. Pour plus d'informations sur la configuration et l'utilisation de la AWS CLI, consultez Développement avec Amazon S3 à l'aide de la AWS CLI.

aws s3api create-bucket --bucket examplebucket --profile AccountADave --create-bucket-configuration file://c:/Users/someUser/bucketconfig.txt

Le fichier bucketconfig.txt spécifie la configuration comme suit.

{"LocationConstraint": "sa-east-1"}

Exemple 2 : Obtention d'une liste d'objets dans un compartiment avec un préfixe spécifique

Vous pouvez utiliser la clé de condition s3:prefix pour limiter la réponse de l'API GET Bucket (ListObjects) aux noms de clés avec un préfixe spécifique. Si vous êtes le propriétaire du compartiment, vous pouvez limiter un utilisateur pour répertorier le contenu d'un préfixe spécifique dans le compartiment. Cette clé de condition est utile si les objets du compartiment sont organisés par préfixe de nom de clé. La console Amazon S3 utilise des préfixes de nom de clé pour afficher un concept de dossier. Seule la console prend en charge le concept de dossiers ; l'API Amazon S3 ne prend en charge que les compartiments et les objets. Pour de plus amples informations sur l'utilisation de préfixes et de délimiteurs pour filtrer les autorisations d'accès, veuillez consulter Contrôle de l'accès à un compartiment avec des stratégies d'utilisateur.

Par exemple, si vous avez deux objets avec les noms de clés public/object1.jpg et public/object2.jpg, la console affiche les objets dans le dossier public. Dans l'API Amazon S3, il s'agit d'objets avec des préfixes, pas d'objets dans des dossiers. Cependant, dans l'API Amazon S3, si vous organisez vos clés d'objet en utilisant de tels préfixes, vous pouvez octroyer l'autorisation s3:ListBucket avec la condition s3:prefix, ce qui permet à l'utilisateur d'obtenir une liste des noms de clés avec ces préfixes spécifiques.

Dans cet exemple, le propriétaire du compartiment et le compte parent auquel appartient l'utilisateur sont identiques. Ainsi, le propriétaire du compartiment peut utiliser une stratégie de compartiment ou une stratégie d'utilisateur. Pour plus d'informations sur les autres clés de condition que vous pouvez utiliser avec l'API GET Bucket (ListObjects), consultez ListObjects.

Stratégie utilisateur

La stratégie d'utilisateur suivante octroie l'autorisation s3:ListBucket (veuillez consulter GET Bucket (List Objects)) avec une condition qui nécessite que l'utilisateur spécifie le préfixe prefix dans la demande avec la valeur projects.

{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Action": "s3:ListBucket", "Resource":"arn:aws:s3:::awsexamplebucket1", "Condition" : { "StringEquals" : { "s3:prefix": "projects" } } }, { "Sid":"statement2", "Effect":"Deny", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1", "Condition" : { "StringNotEquals" : { "s3:prefix": "projects" } } } ] }

La condition restreint l'utilisateur à répertorier les clés d'objets avec le préfixe projects. Le refus explicite ajouté refuse la demande de l'utilisateur de répertorier les clés avec un autre préfixe, peu importe les autres autorisations dont dispose l'utilisateur. Par exemple, il est possible que l'utilisateur obtienne l'autorisation de répertorier les clés d'objets sans aucune restriction, grâce aux mises à jour de la stratégie d'utilisateur précédente ou via une stratégie de compartiment. Dans la mesure où le refus explicite a toujours priorité, la demande de l'utilisateur de répertorier des clés autres que le préfixe projects est refusée.

Stratégie de compartiment

Si vous ajoutez l'élément Principal à la stratégie utilisateur ci-dessus, identifiant l'utilisateur, vous avez maintenant une stratégie de compartiment comme indiqué.

{ "Version":"2012-10-17", "Statement":[ { "Sid":"statement1", "Effect":"Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/bucket-owner" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1", "Condition" : { "StringEquals" : { "s3:prefix": "projects" } } }, { "Sid":"statement2", "Effect":"Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/bucket-owner" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::awsexamplebucket1", "Condition" : { "StringNotEquals" : { "s3:prefix": "projects" } } } ] }

Tester la stratégie avec AWS CLI

Vous pouvez tester la stratégie en utilisant la commande list-object de la AWS CLI suivante. Dans la commande, vous fournissez les informations d'identification utilisateur en utilisant le paramètre --profile. Pour plus d'informations sur la configuration et l'utilisation de la AWS CLI, consultez Développement avec Amazon S3 à l'aide de la AWS CLI.

aws s3api list-objects --bucket awsexamplebucket1 --prefix examplefolder --profile AccountADave

Si le compartiment est activé pour la version, pour répertorier les objets dans le compartiment, vous devez accorder l'autorisation s3:ListBucketVersions dans la stratégie précédente, au lieu de l'autorisation s3:ListBucket. Cette autorisation prend également en charge la clé de condition s3:prefix.

Exemple 3 : Définition du nombre maximal de clés

Vous pouvez utiliser la clé de condition s3:max-keys pour définir le nombre maximal de clés que le demandeur peut retourner dans une demande GET Bucket (ListObjects) ou ListObjectVersions. Par défaut, l'API retourne jusqu'à 1 000 clés. Pour obtenir la liste des opérateurs de conditions numériques que vous pouvez utiliser avec s3:max-keys et les exemples qui les accompagnent, veuillez consulter Opérateurs de conditions numériques dans le Guide de l'utilisateur IAM.