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. # Contrôle d'accès à DAX DynamoDB Accelerator (DAX) est conçu pour fonctionner avec DynamoDB, afin d’ajouter en toute fluidité une couche de mise en cache à vos applications. Toutefois, DAX et DynamoDB ont des mécanismes de contrôle d’accès distincts. Les deux services utilisent Gestion des identités et des accès AWS (IAM) pour implémenter leurs politiques de sécurité respectives, mais les modèles de sécurité pour DAX et DynamoDB sont différents. *Nous vous recommandons vivement de vous familiariser avec les deux modèles de sécurité*. Vous pourrez ainsi implémenter des mesures de sécurité appropriées pour vos applications qui utilisent DAX. Cette section décrit les mécanismes de contrôle d’accès fournis par DAX et propose des exemples de politiques IAM que vous pouvez personnaliser en fonction de vos besoins. Avec DynamoDB, vous pouvez créer des politiques IAM qui limitent les actions qu’un utilisateur peut effectuer sur des ressources DynamoDB individuelles. Par exemple, vous pouvez créer un rôle d’utilisateur qui ne permet à l’utilisateur d’effectuer des actions en lecture seule que sur une table DynamoDB déterminée. (Pour plus d’informations, consultez [Gestion des identités et des accès pour Amazon DynamoDB](security-iam.md).) En comparaison, le modèle de sécurité DAX est axé sur la sécurité du cluster et sur la capacité de celui-ci à effectuer pour vous des actions d’API DynamoDB. **Avertissement** Si vous utilisez actuellement des rôles et politiques IAM pour limiter l’accès aux données des tables DynamoDB, l’utilisation de DAX peut **contrecarrer** ces politiques. Par exemple, un utilisateur peut avoir accès à une table DynamoDB via DAX mais ne pas bénéficier d’un accès explicite à cette même table en accédant directement à DynamoDB. Pour de plus amples informations, veuillez consulter [Gestion des identités et des accès pour Amazon DynamoDB](security-iam.md). DAX n’applique pas de séparation au niveau de l’utilisateur sur les données dans DynamoDB. Au lieu de cela, les utilisateurs héritent des autorisations de la politique IAM du cluster DAX quand ils accèdent à ce dernier. Autrement dit, au moment d’accéder à des tables DynamoDB via DAX, les seuls contrôles d’accès en vigueur sont les autorisations dans la politique IAM du cluster DAX. Aucune autre autorisation n’est reconnue. Si une isolation est requise, nous vous recommandons de créer des clusters DAX supplémentaires et de définir la portée de la politique IAM de chaque cluster en conséquence. Par exemple, vous pouvez créer plusieurs clusters DAX et autoriser chacun d’eux à accéder à une seule table. ## Fonction du service IAM pour DAX Lorsque vous créez un cluster DAX, vous devez l’associer à un rôle IAM. C’est ce qui s’appelle le *rôle de service* du cluster. Supposons que vous souhaitiez créer un nouveau cluster DAX nommé *DAXCluster01*. *Vous pouvez créer un rôle de service nommé DAXService Role et l'associer à *DAXCluster01*.* La politique relative à *DAXServiceRole* définirait les actions DynamoDB *DAXCluster01*qui pourraient être effectuées pour le compte des utilisateurs avec lesquels ils interagissent. *DAXCluster01* Lorsque vous créez un rôle de service, vous devez spécifier une relation de confiance entre le *DAXServicerôle* et le service DAX lui-même. Une relation d’approbation détermine les entités qui peuvent endosser un rôle et utiliser ses autorisations. Voici un exemple de document de relation de confiance pour *DAXServiceRole* : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "dax.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ Cette relation de confiance permet à un cluster DAX d'assumer un *DAXServicerôle* et d'effectuer des appels d'API DynamoDB en votre nom. *Les actions d'API DynamoDB autorisées sont décrites dans un document de politique IAM, que vous joignez à Role. DAXService* Voici un exemple de document politique : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DaxAccessPolicy", "Effect": "Allow", "Action": [ "dynamodb:DescribeTable", "dynamodb:PutItem", "dynamodb:GetItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:BatchGetItem", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem" ], "Resource": [ "arn:aws:dynamodb:us-west-2:123456789012:table/Books" ] } ] } ``` ------ Cette politique permet à DAX d’exécuter toutes les actions d’API DynamoDB sur une table DynamoDB. L’action `dynamodb:DescribeTable` est requise pour que DAX puisse gérer les métadonnées sur la table, tandis que les autres actions sont celles de lecture et d’écriture effectuées sur des éléments de la table. La table, nommée `Books`, se trouve dans la région us-west-2 et est détenue par l’ID de compte AWS `123456789012`. **Note** DAX prend en charge des mécanismes pour prévenir le problème d’adjoint confus lors de l’accès interservice. Pour de plus amples informations, veuillez consulter [Le problème du député confus](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) dans le *Guide de l’utilisateur IAM*. ## Politique IAM pour autoriser l’accès au cluster DAX Après avoir créé un cluster DAX, vous devez accorder des autorisations à un utilisateur pour lui permettre d’accéder au cluster DAX. Supposons, par exemple, que vous souhaitiez accorder l'accès *DAXCluster01*à un utilisateur nommé Alice. Vous devez d'abord créer une politique IAM (*AliceAccessPolicy*) qui définit les clusters DAX et les actions d'API DAX auxquels le destinataire peut accéder. Vous devez ensuite octroyer l’accès en attachant cette stratégie à l’utilisatrice Alice. Le document de politique suivant donne au destinataire un accès complet à *DAXCluster01*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "dax:*" ], "Effect": "Allow", "Resource": [ "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" ] } ] } ``` ------ Si le document de politique autorise l’accès au cluster DAX, il n’accorde aucune autorisation DynamoDB. (Les autorisations DynamoDB sont conférées par le rôle de service DAX) Pour l’utilisatrice Alice, vous devez d’abord créer `AliceAccessPolicy` avec le document de stratégie présenté ci-dessus. Vous devez ensuite attacher la stratégie à Alice. **Note** Au lieu d’attacher la politique à un utilisateur, vous pouvez l’attacher à un rôle IAM. De cette manière, tous les utilisateurs qui endossent ce rôle bénéficient des autorisations que vous avez définies dans la stratégie. La politique utilisateur, en combinaison avec le rôle de service DAX, détermine les ressources DynamoDB et les actions d’API auxquelles la destinataire peut accéder via DAX. ## Étude de cas : accès à DynamoDB et à DAX Le scénario suivant permet de mieux comprendre les politiques IAM à utiliser avec DAX. (Des allusions seront faites à ce scénario tout au long de cette section.) Le schéma suivant offre un aperçu général du scénario. ![\[Présentation générale d’un scénario de politique IAM pour l’utilisation de DAX.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/dax-access-control-scenario.png) Ce scénario réunit les entités suivantes : + Un utilisateur (Bob). + Un rôle IAM (`BobUserRole`). Bob endosse ce rôle au moment de l’exécution. + Une politique IAM (`BobAccessPolicy`). Cette politique est attachée à `BobUserRole`. `BobAccessPolicy` définit les ressources DynamoDB et DAX auxquelles `BobUserRole` est autorisé à accéder. + Un cluster DAX (`DAXCluster01`). + Un rôle de service IAM (`DAXServiceRole`). Ce rôle permet à `DAXCluster01` d’accéder à DynamoDB. + Une politique IAM (`DAXAccessPolicy`). Cette politique est jointe à`DAXServiceRole`. `DAXAccessPolicy`définit le APIs DynamoDB et les ressources `DAXCluster01` auxquelles l'accès est autorisé. + Une table DynamoDB (`Books`). La combinaison des déclarations de stratégie dans `BobAccessPolicy` et `DAXAccessPolicy` détermine ce que Bob peut faire avec la table `Books`. Par exemple, Bob peut être autorisé à accéder à `Books` directement (via le point de terminaison DynamoDB), indirectement (via le cluster DAX) ou les deux à la fois. Bob peut aussi être autorisé à lire les données de `Books`, à écrire des données dans `Books` ou les deux à la fois. ## Accès à DynamoDB, mais pas d’accès avec DAX ![\[Présentation d’une politique IAM qui permet un accès direct à une table, mais bloque tout accès indirect à l’aide d’un cluster DAX.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/dax-access-control-ddb-only.png) Il est possible d’autoriser un accès direct à une table DynamoDB tout en empêchant tout accès indirect à l’aide d’un cluster DAX. Pour un accès direct à DynamoDB, les autorisations pour le rôle `BobUserRole` sont déterminées par la politique `BobAccessPolicy` (attachée au rôle). ### Accès en lecture seule à DynamoDB (uniquement) *Bob* peut accéder à DynamoDB avec le rôle `BobUserRole`. La politique IAM associée à ce rôle (`BobAccessPolicy`) détermine les tables DynamoDB auxquelles il est possible d'accéder et `BobUserRole` APIs celles qu'elles peuvent invoquer. `BobUserRole` Penchons-nous sur le document de stratégie suivant pour `BobAccessPolicy`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ Lorsque ce document est attaché à `BobAccessPolicy`, il autorise `BobUserRole` à accéder au point de terminaison DynamoDB et à effectuer des opérations en lecture seule sur la table `Books`. DAX n’apparaissant pas dans cette politique, l’accès via DAX est rejeté. ### Accès en lecture-écriture à DynamoDB (uniquement) Si read/write l'accès à DynamoDB est `BobUserRole` requis, la politique suivante fonctionnera. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ A nouveau, DAX n’apparaissant pas dans cette politique, l’accès via DAX est rejeté. ## Accès à DynamoDB et à DAX ![\[Politique IAM qui accorde l’accès à la fois à une table DynamoDB et à un cluster DAX.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/dax-access-control-ddb-and-dax.png) Pour autoriser l’accès à un cluster DAX, vous devez inclure des actions spécifiques de DAX dans une politique IAM. Les actions spécifiques de DAX correspondent à leurs homologues de même nom dans l’API DynamoDB : + `dax:GetItem` + `dax:BatchGetItem` + `dax:Query` + `dax:Scan` + `dax:PutItem` + `dax:UpdateItem` + `dax:DeleteItem` + `dax:BatchWriteItem` + `dax:ConditionCheckItem` Il en va de même pour la clé de condition `dax:EnclosingOperation`. ### Accès en lecture seule à DynamoDB et à DAX Supposons que Bob a besoin d’un accès en lecture seule à la table `Books`, à partir de DynamoDB et de DAX. La stratégie suivante (attachée à `BobUserRole`) confèrerait cet accès. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ La politique comporte une instruction pour l'accès DAX (`DAXAccessStmt`) et une autre pour Dynamo DBaccess (`DynamoDBAccessStmt`). Ces déclarations permettraient à Bob d’envoyer des demandes `GetItem`, `BatchGetItem`, `Query`et `Scan` à `DAXCluster01`. Toutefois, le rôle de service pour `DAXCluster01` nécessiterait également un accès en lecture seule à la table `Books` dans DynamoDB. La politique IAM suivante, attachée à `DAXServiceRole`, répondrait à cette exigence. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ ### Accès en lecture-écriture à DynamoDB et en lecture seule avec DAX Pour un rôle d'utilisateur donné, vous pouvez donner read/write accès à une table DynamoDB, tout en autorisant l'accès en lecture seule via DAX. Pour Bob, la politique IAM pour `BobUserRole` doit autoriser les actions de lecture et d’écriture de DynamoDB sur la table `Books`, tout en prenant également en charge les actions en lecture seule via `DAXCluster01`. L’exemple de document de stratégie suivant confèrerait cet accès à `BobUserRole`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ Par ailleurs, `DAXServiceRole` aurait besoin d’une politique IAM permettant à `DAXCluster01` d’effectuer des actions en lecture seule sur la table `Books`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ ### Read/write access to DynamoDB and read/writeaccès au DAX Supposons maintenant que Bob ait besoin read/write d'accéder à la `Books` table, directement depuis DynamoDB ou indirectement depuis. `DAXCluster01` La stratégie suivante (attachée à `BobAccessPolicy`, confèrerait cet accès. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:ConditionCheckItem" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ En outre, `DAXServiceRole` cela nécessiterait une politique IAM permettant d'`DAXCluster01`effectuer des read/write actions sur la `Books` table. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ ## Accès à DynamoDB via DAX, mais aucun accès direct à DynamoDB Dans ce scénario, Bob peut accéder à la table `Books` via DAX, mais il n’a pas d’accès direct à la table `Books` dans DynamoDB. Par conséquent, lorsque Bob a accès à DAX, il a également accès à une table DynamoDB à laquelle il n’aurait autrement pas accès. Lorsque vous configurez une politique IAM pour le rôle de service DAX, n’oubliez pas qu’un utilisateur ayant accès au cluster DAX en vertu de la politique d’accès utilisateur a également accès aux tables spécifiées dans celle-ci. Dans ce cas, `BobAccessPolicy` bénéficie d’un accès aux tables spécifiées dans `DAXAccessPolicy`. ![\[Scénario dans lequel un utilisateur peut accéder à une table via un cluster DAX sans accès direct à DynamoDB.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/dax-access-control-dax-only.png) Si vous utilisez actuellement des rôles et des politiques IAM pour limiter l’accès aux tables et aux données DynamoDB, l’utilisation de DAX peut contrecarrer ces politiques. Dans la politique suivante, Bob a accès à une table DynamoDB via DAX, mais il ne bénéficie pas d’un accès direct explicite à cette même table dans DynamoDB. Le document de stratégie suivant (`BobAccessPolicy`), attaché à `BobUserRole`, confèrerait cet accès. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:ConditionCheckItem" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" } ] } ``` ------ Cette politique d’accès n’inclut aucune autorisation d’accès direct à DynamoDB. Avec `BobAccessPolicy`, la politique `DAXAccessPolicy` suivante accorde à `BobUserRole` l’accès à la table DynamoDB `Books`, même si `BobUserRole` ne peut pas accéder directement à la table `Books`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] } ``` ------ Comme le montre cet exemple, lorsque vous configurez le contrôle d'accès pour la politique d'accès utilisateur et la politique d'accès au cluster DAX, vous devez bien comprendre l' end-to-endaccès afin de garantir le respect du principe du moindre privilège. Assurez-vous également que le fait d'accorder à un utilisateur l'accès à un cluster DAX ne va pas à l'encontre de politiques de contrôle d'accès définies antérieurement.