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.

DAXcontrôle d'accès

DynamoDB Accelerator DAX () est conçu pour fonctionner avec DynamoDB afin d'ajouter facilement une couche de mise en cache à vos applications. Cependant, DynamoDB DAX et DynamoDB disposent de mécanismes de contrôle d'accès distincts. Les deux services utilisent AWS Identity and Access Management (IAM) pour implémenter leurs politiques de sécurité respectives, mais les modèles de sécurité pour DynamoDB DAX et DynamoDB sont différents.

Nous vous recommandons vivement de comprendre les deux modèles de sécurité, afin de pouvoir mettre en œuvre les mesures de sécurité appropriées pour les applications que vous utilisezDAX.

Cette section décrit les mécanismes de contrôle d'accès fournis par DAX et fournit des exemples de IAM politiques que vous pouvez adapter à vos besoins.

Avec DynamoDB, vous pouvez IAM créer des politiques 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 DAX de sécurité met l'accent sur la sécurité du cluster et sur la capacité du cluster à effectuer des actions API DynamoDB en votre nom.

IAMrôle de service pour DAX

Lorsque vous créez un DAX cluster, vous devez l'associer à un IAM rôle. C'est ce qui s'appelle le rôle de service du cluster.

Supposons que vous souhaitiez créer un nouveau DAX cluster nommé DAXCluster01. Vous pouvez créer un rôle de service nommé DAXServiceRoleet l'associer à DAXCluster01. La politique pour DAXServiceRoledéfinirait les actions DynamoDB DAXClusterque 01 pourrait effectuer, pour le compte des utilisateurs qui interagissent avec 01. DAXCluster

Lorsque vous créez un rôle de service, vous devez spécifier une relation de confiance entre le service lui-même DAXServiceRoleet le DAX service 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:

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

Cette relation de confiance permet à un DAX cluster d'assumer DAXServiceRoleet d'exécuter des appels API DynamoDB en votre nom.

Les actions API DynamoDB autorisées sont décrites dans IAM un document de politique que vous joignez. DAXServiceRole Voici un exemple de document politique :

{
    "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 d'DAXeffectuer les actions DynamoDB nécessaires sur une API table DynamoDB. L'dynamodb:DescribeTableaction est requise pour conserver les métadonnées relatives DAX à la table, tandis que les autres sont des actions de lecture et d'écriture effectuées sur les éléments de la table. La table, nomméeBooks, se trouve dans la région us-west-2 et appartient à l'identifiant du compte. AWS 123456789012

IAMpolitique autorisant l'accès au DAX cluster

Après avoir créé un DAX cluster, vous devez accorder des autorisations à un utilisateur afin que celui-ci puisse accéder au DAX cluster.

Supposons, par exemple, que vous souhaitiez accorder l'accès à DAXCluster01 à une utilisatrice nommée Alice. Vous devez d'abord créer une IAM politique (AliceAccessPolicy) qui définit les DAX clusters et DAX API les actions 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 au DAXCluster01.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "dax:*"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01"
            ]
        }
    ]
}

Le document de politique autorise l'accès au DAX cluster, mais il n'accorde aucune autorisation DynamoDB. (Les autorisations DynamoDB sont conférées par DAX le rôle de service.)

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.

La politique utilisateur, associée au rôle de DAX service, déterminent les ressources DynamoDB API et les actions via lesquelles le destinataire peut accéder. DAX

Étude de cas : accès à DynamoDB et DAX

Le scénario suivant peut vous aider à mieux comprendre les IAM politiques à utiliser avecDAX. (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.

Ce scénario réunit les entités suivantes :

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 en mesure d'y accéder Books directement (en utilisant le point de terminaison DynamoDB), indirectement (en utilisant DAX le cluster), ou les deux. 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

Il est possible d'autoriser l'accès direct à une table DynamoDB, tout en empêchant l'accès indirect via 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 IAM politique associée à ce rôle (BobAccessPolicy) détermine les tables DynamoDB auxquelles il est possible d'accéder et APIs ce BobUserRole BobUserRole qu'elles peuvent appeler.

Penchons-nous sur le document de stratégie suivant pour BobAccessPolicy.

{
    "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.

DAXn'apparaît pas dans cette politique, l'accès via DAX est donc refusé.

Accès en lecture-écriture à DynamoDB (uniquement)

Si BobUserRole a besoin d'un accès en lecture-écriture à DynamoDB, la politique suivante peut convenir.

{
    "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"
        }
    ]
}

Encore une fois, DAX cela n'apparaît pas dans cette politique, l'accès via DAX est donc refusé.

Accès à DynamoDB et à DAX

Pour autoriser l'accès à un DAX cluster, vous devez inclure DAX des actions spécifiques dans une IAM politique.

Les actions DAX spécifiques suivantes correspondent à leurs homologues portant le même nom dans API DynamoDB :

Il en va de même pour la clé de condition dax:EnclosingOperation.

Accès en lecture seule à DynamoDB et accès en lecture seule à DAX

Supposons que Bob ait besoin d'un accès en lecture seule à la Books table, depuis DynamoDB et depuis. DAX La stratégie suivante (attachée à BobUserRole) confèrerait cet accès.

{
    "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 DAX access (DAXAccessStmt) et une autre pour D ynamoDBaccess (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 IAM politique suivante, jointe àDAXServiceRole, répondrait à cette exigence.

{
    "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 l'accès en lecture seule via. DAX

Pour Bob, la IAM politique de BobUserRole devrait autoriser les actions de lecture et d'écriture de DynamoDB sur la table, tout en prenant en charge Books les actions en lecture seule via. DAXCluster01

L'exemple de document de stratégie suivant confèrerait cet accès à BobUserRole.

{
    "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"
        }
    ]
}

En outre, DAXServiceRole cela nécessiterait une IAM politique permettant d'DAXCluster01effectuer des actions en lecture seule sur la Books table.

{
    "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 accès en lecture/écriture à 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.

{
    "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 IAM politique permettant d'DAXCluster01effectuer des actions de lecture/écriture sur la Books table.

{
    "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 DAX via DynamoDB, mais pas d'accès direct à DynamoDB

Dans ce scénario, Bob peut accéder à la Books table viaDAX, mais il n'y a pas d'accès direct dans DynamoDB. Books Ainsi, lorsque Bob accède à une table DynamoDBDAX, il a également accès à une table DynamoDB à laquelle il ne serait peut-être pas en mesure d'accéder autrement. Lorsque vous configurez une IAM politique pour le rôle de DAX service, n'oubliez pas que tout utilisateur autorisé à accéder au DAX cluster via la politique d'accès utilisateur obtient l'accès aux tables spécifiées dans cette politique. Dans ce cas, BobAccessPolicy bénéficie d’un accès aux tables spécifiées dans DAXAccessPolicy.

Si vous utilisez actuellement IAM des rôles et des politiques pour restreindre l'accès aux tables et aux données DynamoDB, vous pouvez les DAX contourner. Dans la politique suivante, Bob a accès à une table DynamoDB DAX via mais n'a pas d'accès direct explicite à la même table dans DynamoDB.

Le document de stratégie suivant (BobAccessPolicy), attaché à BobUserRole, confèrerait cet accès.

{
    "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.

{
    "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 DAX cluster, 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 de donner à un utilisateur l'accès à un DAX cluster ne porte pas atteinte aux politiques de contrôle d'accès établies précédemment.