Contrôle d’accès à DAX - Amazon DynamoDB
Fonction du service IAM pour DAXPolitique IAM pour autoriser l’accès au cluster DAXÉtude de cas : accès à DynamoDB et à DAXAccès à DynamoDB, mais pas d’accès avec DAXAccès à DynamoDB et à DAXAccès à DynamoDB via DAX, mais aucun accès direct à DynamoDB

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. Même si les deux services utilisent AWS Identity and Access Management (IAM) pour implémenter leurs politiques de sécurité respectives, les modèles de sécurité pour DAX et DynamoDB diffèrent.

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.) 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 plus d’informations, consultez Gestion des identités et des accès pour Amazon DynamoDB.

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 voulez créer un cluster DAX nommé DAXCluster01. Vous créez le rôle de service DAXServiceRole et l’associez à DAXCluster01. La politique pour DAXServiceRole définirait les actions DynamoDB que DAXCluster01 pourrait effectuer pour le compte des utilisateurs qui interagissent avec DAXCluster01.

Lorsque vous créez un rôle de service, vous devez spécifier une relation d’approbation entre DAXServiceRole et le service DAX proprement dit. 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 d’approbation pour DAXServiceRole :

JSON
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "dax.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Cette relation d’approbation permet à un cluster DAX d’endosser le rôle DAXServiceRole 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 attachez à DAXServiceRole. 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 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.

Par exemple, supposons que vous souhaitez accorder l’accès à DAXCluster01 à une utilisatrice prénommée Alice. Dans un premier temps, vous créez une politique IAM (AliceAccessPolicy) qui définit les clusters DAX et les actions d’API DAX auxquelles la destinataire peut accéder. Vous devez ensuite octroyer l’accès en attachant cette stratégie à l’utilisatrice Alice.

Le document de stratégie suivant octroie au destinataire un accès total à 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.

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 attachée à DAXServiceRole. DAXAccessPolicy définit les API et ressources DynamoDB et DAX auxquelles DAXCluster01 est autorisé à accéder.

  • 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.

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 attachée à ce rôle (BobAccessPolicy) détermine les tables DynamoDB auxquelles le rôle BobUserRole peut accéder, ainsi que les API que BobUserRole peut invoquer.

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 BobUserRole a besoin d’un accès en lecture-écriture à DynamoDB, la politique suivante peut convenir.

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.

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 comprend une instruction pour l’accès à DAX (DAXAccessStmt) et une autre pour l’accès à DynamoDB (DynamoDBAccessStmt). Ces déclarations permettraient à Bob d’envoyer des demandes GetItem, BatchGetItem, Queryet 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 fournir un accès en lecture-écriture à une table DynamoDB, tout en autorisant un 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"
        }
    ]
}

Accès en lecture-écriture à DynamoDB et à DAX

supposons maintenant que Bob a besoin d’un accès en lecture-écriture à la table Books, directement à partir de DynamoDB ou indirectement à partir de 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"
        }
    ]
}

Par ailleurs, DAXServiceRole aurait besoin d’une politique IAM qui permette à DAXCluster01 d’effectuer des actions en lecture-écriture sur 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"
            ],
            "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.

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 du cluster DAX, vous devez avoir une parfaite compréhension de l’accès de bout en bout pour vous assurer du respect du principe du privilège minimum. 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.