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.
IAMpolitique visant à séparer les environnements DynamoDB dans le même compte AWS
Supposons que vous ayez des environnements séparés gérant chacun sa propre version d'une table nommée ProductCatalog. Si vous créez deux ProductCatalog tables dans le même AWS compte, le travail dans un environnement peut affecter l'autre environnement en raison de la manière dont les autorisations sont configurées. Par exemple, les quotas relatifs au nombre d'opérations simultanées sur le plan de contrôle (telles queCreateTable) sont définis au niveau du AWS compte.
Par conséquent, chaque action effectuée dans un environnement réduit le nombre d'opérations disponibles dans l'autre. Il existe également un risque que le code d'un environnement puisse accéder accidentellement aux tables de l'autre.
Note
Si vous souhaitez séparer les charges de travail de test et de production afin de contrôler les répercussions potentielles d'un incident, une bonne pratique consiste à créer des comptes AWS distincts pour les charges de travail de test et de production. Pour plus d'informations, consultez Gestion et séparation de comptes AWS.
Supposons également que vous ayez deux développeurs, Amit et Alice, qui testent la table ProductCatalog. Au lieu que chaque développeur ait besoin d'un AWS compte distinct, vos développeurs peuvent partager le même AWS compte de test. Dans ce compte de test, vous pouvez créer une copie de la même table pour que chaque développeur puisse y travailler, comme Alice_ProductCatalog et Amit_ProductCatalog. Dans ce cas, vous pouvez créer les utilisateurs Alice et Amit dans le AWS compte que vous avez créé pour l'environnement de test. Vous pouvez ensuite accorder à ces utilisateurs l'autorisation d'effectuer des actions DynamoDB sur les tables qu'ils possèdent.
Pour accorder ces autorisations aux IAM utilisateurs, vous pouvez effectuer l'une des opérations suivantes :
-
Créez une politique distincte pour chaque utilisateur, puis attachez chaque politique à son utilisateur séparément. Par exemple, vous pouvez attacher la politique suivante à l'utilisateur Alice pour l'autoriser à accéder à toutes les actions DynamoDB sur la table
Alice_ProductCatalog:{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllAPIActionsOnAliceTable", "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:DescribeContributorInsights", "dynamodb:RestoreTableToPointInTime", "dynamodb:ListTagsOfResource", "dynamodb:CreateTableReplica", "dynamodb:UpdateContributorInsights", "dynamodb:CreateBackup", "dynamodb:DeleteTable", "dynamodb:UpdateTableReplicaAutoScaling", "dynamodb:UpdateContinuousBackups", "dynamodb:TagResource", "dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:DescribeContinuousBackups", "dynamodb:BatchGetItem", "dynamodb:UpdateTimeToLive", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem", "dynamodb:UntagResource", "dynamodb:PutItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:UpdateItem", "dynamodb:DeleteTableReplica", "dynamodb:DescribeTimeToLive", "dynamodb:RestoreTableFromBackup", "dynamodb:UpdateTable", "dynamodb:DescribeTableReplicaAutoScaling", "dynamodb:GetShardIterator", "dynamodb:DescribeStream", "dynamodb:GetRecords", "dynamodb:DescribeLimits", "dynamodb:ListStreams" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Alice_ProductCatalog/*" } ] }Ensuite, vous pouvez créer une politique similaire avec une autre ressource (table
Amit_ProductCatalog) pour l'utilisateur Amit. -
Au lieu d'associer des politiques à des utilisateurs individuels, vous pouvez utiliser des variables de IAM stratégie pour écrire une seule stratégie et l'associer à un groupe. Vous devez créer un groupe et, pour cet exemple, y ajouter les utilisateurs Alice et Amit. L'exemple suivant accorde des autorisations pour exécuter toutes les actions DynamoDB sur la table
${aws:username}_ProductCatalog. La variable de politique${aws:username}est remplacée par le nom utilisateur du demandeur lors de l'évaluation de la politique. Par exemple, si Alice envoie une demande pour ajouter un élément, l'action est autorisée uniquement si Alice ajoute les éléments à la tableAlice_ProductCatalog.{ "Version": "2012-10-17", "Statement": [ { "Sid": "ActionsOnUserSpecificTable", "Effect": "Allow", "Action": [ "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Scan", "dynamodb:Query", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_ProductCatalog" }, { "Sid": "AdditionalPrivileges", "Effect": "Allow", "Action": [ "dynamodb:ListTables", "dynamodb:DescribeTable", "dynamodb:DescribeContributorInsights" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/*" } ] }
Note
Lorsque vous utilisez des variables de IAM stratégie, vous devez spécifier explicitement la 2012-10-17 version du langage de IAM stratégie dans la stratégie. La version par défaut du langage de IAM stratégie (2008-10-17) ne prend pas en charge les variables de stratégie.
Au lieu d'identifier une table spécifique en tant que ressource comme vous le feriez normalement, vous pouvez utiliser un caractère générique (*) pour accorder des autorisations sur toutes les tables dont le nom est préfixé avec le nom de l'utilisateur qui effectue la demande, comme illustré dans l'exemple suivant.
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_*"
