Exemples de clés de condition Amazon S3 - 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 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 plus d’informations sur les clés de condition, consultez Clés de condition Amazon S3. Pour obtenir la liste complète des actions, des clés de condition et des ressources Amazon S3 que vous pouvez spécifier dans les politiques, consultez la section Actions, ressources et clés de condition pour Amazon S3 dans la référence d'autorisation de service.

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, des clés de condition et des ressources Amazon S3 que vous pouvez spécifier dans les politiques, consultez la section Actions, ressources et clés de condition pour Amazon S3 dans la référence d'autorisation de service.

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 lors de l'opération. PutObjectAcl Pour plus d'informations, consultez PutObjectAclle manuel Amazon S3 Amazon Simple Storage Service API Reference. Pour en savoir plus sur les listes ACL, consultez Présentation de la liste de contrôle d'accès (ACL).

Exemple 1 : Octroi d'une PutObject autorisation s3 : 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 bucket et que l'administrateur du compte souhaite accorder à Akua, un utilisateur du compte B, l'autorisation de télécharger des objets. Par défaut, les objets qu'Akua télécharge appartiennent au compte B, et le compte A n'a aucune autorisation sur ces objets. Comme le propriétaire du bucket paie les factures, il souhaite obtenir des autorisations complètes sur les objets qu'Akua télécharge. L'administrateur du compte A peut le faire en accordant l's3:PutObjectautorisation à Akua, à condition que la demande inclue des en-têtes spécifiques à l'ACL qui accordent explicitement l'autorisation complète ou utilisent une ACL prédéfinie. Pour plus d’informations, consultez Objet PUT.

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 politique de compartiment suivante accorde l's3:PutObjectautorisation à l'utilisateur Akua avec une condition utilisant la clé de s3:x-amz-grant-full-control condition, ce qui exige que la demande inclue l'x-amz-full-controlen-tête.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AccountB-ID:user/Akua" }, "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 Akua (qui obtient l'autorisation) appartient au propriétaire du Compte AWS bucket, cette autorisation conditionnelle n'est pas nécessaire. Cela est dû au fait que le compte parent auquel appartient Akua possède des objets que l'utilisateur télécharge.

Ajouter un refus explicite

La politique de compartiment précédente accorde une autorisation conditionnelle à l'utilisateur Akua dans le compte B. Tant que cette politique est en vigueur, il est possible pour Akua d'obtenir la même autorisation sans aucune condition via une autre politique. Par exemple, Akua peut appartenir à un groupe et vous lui accordez l's3:PutObjectautorisation sans aucune condition. Pour éviter ces failles d'autorisation, vous pouvez écrire une politique d'accès plus stricte en ajoutant un refus explicite. Dans cet exemple, vous refusez explicitement à l'utilisateur Akua l'autorisation de téléchargement s'il n'inclut pas les en-têtes nécessaires dans la demande accordant des autorisations complètes au propriétaire du bucket. 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 d'Akua pour tester l'autorisation à l'aide de la AWS CLI put-object commande suivante. Vous fournissez les informations d'identification d'Akua en ajoutant le --profile paramètre. 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, consultezDé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'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-aclen-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

Exemple 2 : Octroi de s3 : PutObject autorisation nécessitant des objets stockés à l'aide du 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" }}

Lorsque vous testez l'autorisation à l'aide du AWS CLI, vous devez ajouter le paramètre requis à l'aide du --server-side-encryption paramètre.

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

Exemple 3 : Octroi à s3 : PutObject autorisation 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 politique de compartiment suivante accorde l's3:PutObjectautorisation à l'utilisateur (Akua). 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/Akua" }, "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/Akua" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition": { "StringNotLike": { "s3:x-amz-copy-source": "awsexamplebucket1/public/*" } } } ] }
Testez la politique à l'aide du AWS CLI

Vous pouvez tester l'autorisation à l'aide de la AWS CLI copy-object commande. 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 les informations d'identification Akua à l'utilisateur à l'aide du --profile paramètre. Pour plus d'informations sur la configuration du AWS CLI, consultezDé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 AccountAAkua
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 du compte souhaite désormais autoriser son utilisateur Akua à obtenir uniquement une version spécifique de l'objet. L'administrateur du compte peut y parvenir en accordant une s3:GetObjectVersion autorisation conditionnelle à Akua, comme indiqué ci-dessous. La paire de clé-valeur dans le bloc Condition spécifie la clé de condition s3:VersionId. Dans ce cas, Akua doit connaître l'ID de version exact de l'objet pour récupérer l'objet.

Pour plus d'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/Akua" }, "Action": "s3:GetObjectVersion", "Resource": "arn:aws:s3:::examplebucketversionenabled/HappyFace.jpg" }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/Akua" }, "Action": "s3:GetObjectVersion", "Resource": "arn:aws:s3:::examplebucketversionenabled/HappyFace.jpg", "Condition": { "StringNotEquals": { "s3:VersionId": "AaaHbAQitwiL_h47_44lRO2DDfLlBO5e" } } } ] }
Testez la politique à l'aide du AWS CLI

Vous pouvez tester les autorisations à l'aide de la AWS CLI get-object commande avec le --version-id paramètre identifiant la version spécifique de l'objet. 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 AccountAAkua

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 empêcher Akua, un utilisateur du compte A, de ne pouvoir télécharger dans le bucket que des objets stockés avec la classe STANDARD_IA de stockage. 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/Akua" }, "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 : Restreindre l'accès en fonction de l' Compte AWS ID 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 (VPC) qui restreignent l'accès des utilisateurs, des rôles 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.

Sachez toutefois que certains AWS services dépendent de l'accès à des buckets AWS gérés. 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 :

Exemple 8 : exiger une version minimale de TLS

Vous pouvez utiliser la clé de TlsVersion condition s3 : pour écrire des politiques IAM, Virtual Private Cloud Endpoint (VPCE) ou de bucket qui limitent 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 politique de compartiment refuse les PutObject demandes des clients dont la version TLS est inférieure à 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 politique de compartiment autorise les PutObject demandes des clients dont la version TLS est supérieure à 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 Compte AWS administrateur souhaite autoriser son utilisateur (Akua) à créer un bucket 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, consultez Régions et points de terminaison dans 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" } } } ] }
Testez la politique à l'aide du AWS CLI

Vous pouvez tester la politique à l'aide de la create-bucket AWS CLI commande 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 du AWS CLI, consultezDéveloppement avec Amazon S3 à l'aide de la AWS CLI.

aws s3api create-bucket --bucket examplebucket --profile AccountAAkua --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 s3:prefix condition pour limiter la réponse de l'API GET Bucket (ListObjects) aux noms de clés dotés d'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 plus d’informations sur l’utilisation de préfixes et de délimiteurs pour filtrer les autorisations d’accès, consultez 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" } } } ] }
Testez la politique à l'aide du AWS CLI

Vous pouvez tester la politique à l'aide de la list-object AWS CLI commande 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 du AWS CLI, consultezDéveloppement avec Amazon S3 à l'aide de la AWS CLI.

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

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 s3:max-keys condition pour définir le nombre maximum de clés que le demandeur peut renvoyer dans un bucket (ListObjects) ou une ListObjectVersionsdemande GET. 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.