Exemples de stratégies basées sur les ressources de S3 Vectors
Note
Amazon S3 Vectors est en version préliminaire pour Amazon Simple Storage Service et sujet à modification.
Les stratégies basées sur une ressource sont attachées à une ressource. Vous pouvez créer des politiques basées sur les ressources pour les compartiments de vecteur. Les politiques basées sur les ressources pour S3 Vectors utilisent le format de politique AWS standard en JSON que vous attachez directement aux compartiments de vecteur pour contrôler l’accès au compartiment et à son contenu.
Contrairement aux politiques basées sur l’identité associées aux utilisateurs, aux groupes ou aux rôles, les politiques basées sur les ressources sont associées à la ressource elle-même (le compartiment de vecteur) et peuvent accorder des autorisations aux principaux depuis d’autres comptes AWS. Elles sont donc idéales pour les scénarios dans lesquels vous devez partager des données vectorielles au-delà des limites de l’organisation ou mettre en œuvre des contrôles d’accès précis en fonction de la ressource spécifique à laquelle vous accédez.
Les politiques basées sur les ressources sont évaluées en combinaison avec les politiques basées sur l’identité, et les autorisations effectives sont déterminées par l’union de toutes les politiques applicables. Cela signifie qu’un principal doit obtenir l’autorisation de la part de la politique basée sur l’identité (attachée à son utilisateur/rôle) et de la politique basée sur les ressources (attachée au compartiment) pour effectuer une action, sauf si la politique basée sur les ressources accorde explicitement l’autorisation.
Exemple 1 : stratégie d’accès intercompte
Cette stratégie explique comment accorder des autorisations spécifiques aux utilisateurs de différents comptes AWS :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "CrossAccountBucketAccess", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:123456789012:role/Admin" }, "Action": [ "s3vectors:CreateIndex", "s3vectors:ListIndexes", "s3vectors:QueryVectors", "s3vectors:PutVectors", "s3vectors:DeleteIndex" ], "Resource": [ "arn:aws:s3vectors::aws-region111122223333:bucket/amzn-s3-demo-vector-bucket/*", "arn:aws:s3vectors::aws-region111122223333:bucket/amzn-s3-demo-vector-bucket" ] } ] }
Exemple 2 : refus des actions au niveau de l’index vectoriel
Cette politique explique comment refuser des actions spécifiques au niveau de l’index vectoriel à un rôle IAM :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyIndexLevelActions", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam:123456789012:role/External-Role-Name" }, "Action": [ "s3vectors:QueryVectors", "s3vectors:PutVectors", "s3vectors:DeleteIndex", "s3vectors:GetVectors", "s3vectors:GetIndex", "s3vectors:DeleteVectors", "s3vectors:CreateIndex", "s3vectors:ListVectors" ], "Resource": "arn:aws:s3vectors::aws-region111122223333:bucket/amzn-s3-demo-vector-bucket/*" } ] }
Exemple 3 : refus des opérations de modification à la fois au niveau de l’index vectoriel et au niveau du compartiment
Cette politique explique comment refuser les demandes de modification pour les actions d’index vectoriel et de niveau compartiment en spécifiant plusieurs ressources :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyModificationActionsAtBucketandIndexLevels", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam:123456789012:role/External-Role-Name" }, "Action": [ "s3vectors:CreateVectorBucket", "s3vectors:DeleteVectorBucket", "s3vectors:PutVectorBucketPolicy", "s3vectors:DeleteVectorBucketPolicy", "s3vectors:CreateIndex", "s3vectors:DeleteIndex", "s3vectors:PutVectors", "s3vectors:DeleteVectors" ], "Resource": [ "arn:aws:s3vectors::aws-region111122223333:bucket/amzn-s3-demo-vector-bucket/*", "arn:aws:s3vectors::aws-region111122223333:bucket/amzn-s3-demo-vector-bucket" ] } ] }