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.

Sécurité des tables globales DynamoDB

Les répliques de tables globales sont des tables DynamoDB. Vous utilisez donc les mêmes méthodes pour contrôler l'accès aux répliques que pour les tables à région unique, y compris les politiques d'identité Gestion des identités et des accès AWS (IAM) et les politiques basées sur les ressources. Cette rubrique explique comment sécuriser les tables globales multicomptes DynamoDB à l'aide des autorisations IAM et AWS Key Management Service du chiffrement ().AWS KMS Vous découvrirez les politiques basées sur les ressources et les rôles liés aux services (SLR) qui permettent la réplication entre comptes entre régions et la mise à l'échelle automatique, ainsi que les autorisations IAM nécessaires pour créer, mettre à jour et supprimer des tables globales, pour une éventuelle cohérence multirégionale (MREC). Vous découvrirez également les clés de AWS KMS chiffrement permettant de gérer la réplication entre régions en toute sécurité.

Il fournit des informations détaillées sur les politiques basées sur les ressources et les autorisations requises pour établir la réplication de tables entre comptes et entre régions. Comprendre ce modèle de sécurité est essentiel pour les clients qui ont besoin de mettre en œuvre des solutions sécurisées de réplication de données entre comptes.

Autorisation du principal de service pour la réplication

Les tables globales multicomptes de DynamoDB utilisent une approche d'autorisation distincte car la réplication s'effectue au-delà des limites des comptes. Pour ce faire, utilisez le principal du service de réplication de DynamoDB :. replication.dynamodb.amazonaws.com Chaque compte participant doit explicitement autoriser ce principal dans la politique de ressources de la table de répliques, en lui donnant des autorisations qui peuvent être limitées à des répliques spécifiques en fonction des conditions du contexte source sur des clés telles que aws:SourceAccountaws:SourceArn, etc. — voir les clés de condition AWS globales pour plus de détails. Les autorisations sont bidirectionnelles, ce qui signifie que toutes les répliques doivent s'accorder explicitement des autorisations les unes aux autres avant que la réplication puisse être établie sur une paire de répliques donnée.

Les autorisations principales de service suivantes sont essentielles pour la réplication entre comptes :

Chaque réplica doit accorder les autorisations ci-dessus à toutes les autres répliques et à lui-même, c'est-à-dire que les conditions du contexte source doivent inclure l'ensemble complet des répliques qui composent la table globale. Ces autorisations sont vérifiées pour chaque nouveau réplica lorsqu'il est ajouté à une table globale multi-comptes. Cela permet de vérifier que les opérations de réplication sont effectuées uniquement par le service DynamoDB autorisé et uniquement entre les tables prévues.

Service-linked rôles pour les tables globales multicomptes

Les tables globales multicomptes DynamoDB répliquent les paramètres de toutes les répliques afin que chaque réplica soit configurée de manière identique avec un débit constant et offrent une expérience de basculement fluide. La réplication des paramètres est contrôlée par l'ReplicateSettingsautorisation du principal du service, mais nous nous appuyons également sur des rôles liés aux services (SLR) pour gérer certaines fonctionnalités de réplication interrégionale et de dimensionnement automatique entre comptes. Ces rôles ne sont configurés qu'une seule fois par AWS compte. Une fois créés, les mêmes rôles sont utilisés dans toutes les tables globales de votre compte. Pour plus d'informations sur les rôles liés à un service, consultez la section Utilisation des rôles liés à un service dans le Guide de l'utilisateur IAM.

Rôle lié au service de gestion des paramètres

Amazon DynamoDB crée automatiquement le rôle AWSServiceRoleForDynamoDBGlobalTableSettingsManagement lié aux services (SLR) lorsque vous créez votre première réplique de table globale multi-comptes dans le compte. Ce rôle gère pour vous la réplication interrégionale des paramètres entre comptes.

Lorsque vous appliquez des politiques basées sur les ressources aux répliques, vérifiez que vous ne refusez aucune des autorisations définies dans le principal du SLR, car cela pourrait interférer avec la gestion des paramètres et nuire AWSServiceRoleForDynamoDBGlobalTableSettingsManagement à la réplication si le débit ne correspond pas entre les répliques ou les GSI. Si vous refusez les autorisations requises pour le reflex, la réplication depuis et vers les répliques concernées peut s'arrêter et le statut de la table de répliques passe à. REPLICATION_NOT_AUTHORIZED Pour les tables globales multicomptes, si un réplica reste dans REPLICATION_NOT_AUTHORIZED cet état pendant plus de 20 heures, il est converti de manière irréversible en une table DynamoDB à région unique. Le reflex dispose des autorisations suivantes :

Rôle lié à un service pour l’autoscaling

Lors de la configuration d'une table globale pour le mode de capacité provisionnée, la mise à l'échelle automatique doit être configurée pour la table globale. La mise à l'échelle automatique de DynamoDB utilise le service AWS Application Auto Scaling pour ajuster dynamiquement la capacité de débit provisionnée sur vos répliques de tables globales. Le service Application Auto Scaling crée un rôle lié à un service (SLR) nommé _DynamoDBTable. AWSServiceRoleForApplicationAutoScaling Ce rôle lié à un service est automatiquement créé dans votre AWS compte lorsque vous configurez pour la première fois le dimensionnement automatique pour une table DynamoDB. Il permet à Application Auto Scaling de gérer la capacité des tables provisionnées et de créer des CloudWatch alarmes.

Lorsque vous appliquez des politiques basées sur les ressources à des répliques, vérifiez que vous ne refusez aucune autorisation définie dans le principal de l'AWSApplicationAutoscalingDynamoDBTablePolicyapplication Auto Scaling SLR, car cela interromprait la fonctionnalité de dimensionnement automatique.

Utilisation des tables globales AWS IAM

Les sections suivantes décrivent les autorisations requises pour différentes opérations sur les tables globales et fournissent des exemples de politiques pour vous aider à configurer l'accès approprié pour vos utilisateurs et applications.

Les sujets suivants sont abordés étape par étape dans les sections ci-dessous :

Création de tables globales et ajout de répliques

Autorisations pour créer des tables globales

Lorsqu'un nouveau réplica est ajouté à une table régionale pour former une table globale multi-comptes ou à une table globale multi-comptes existante, le principal IAM effectuant l'action doit être autorisé par tous les membres existants. Tous les membres existants doivent accorder l'autorisation suivante dans leur politique de table pour que l'ajout de répliques réussisse :

Ce contrôle précis permet uniquement aux comptes autorisés de participer à la configuration globale de la table.

Exemples de politiques IAM pour la création de tables globales

Mettre à jour une table globale multicomptes

Pour modifier les paramètres de réplication d'une table globale existante à l'aide de l' UpdateTable API, vous devez disposer de l'autorisation suivante sur la ressource de table de la région où vous effectuez l'appel d'API : dynamodb:UpdateTable

Vous pouvez également mettre à jour d'autres configurations de tables globales, telles que les politiques de dimensionnement automatique et les paramètres Time to Live. Les autorisations suivantes sont requises pour ces opérations de mise à jour supplémentaires :

Pour mettre à jour les paramètres Time to Live à l'aide de l'UpdateTimeToLiveAPI, vous devez disposer de l'autorisation suivante sur la ressource de table dans toutes les régions contenant des répliques : dynamodb:UpdateTimeToLive

Pour mettre à jour la politique de dimensionnement automatique d'une réplique avec l'UpdateTableReplicaAutoScalingAPI, vous devez disposer des autorisations suivantes sur la ressource de table dans toutes les régions contenant des répliques :

Suppression de tables globales et suppression de répliques

Pour supprimer une table globale, vous devez supprimer toutes les répliques. Contrairement à Global Table pour un même compte, vous ne pouvez pas UpdateTable supprimer une table de répliques dans une région distante et chaque réplique doit être supprimée via l'DeleteTableAPI du compte qui la contrôle.

Autorisations pour supprimer des tables globales et supprimer des répliques

Les autorisations suivantes sont requises à la fois pour supprimer des répliques individuelles et pour supprimer complètement des tables globales. La suppression d'une configuration de table globale supprime uniquement la relation de réplication entre les tables de différentes régions. Elle ne supprime pas la table DynamoDB sous-jacente dans la dernière région restante. La table de la dernière région continue d'exister en tant que table DynamoDB standard avec les mêmes données et paramètres.

Vous devez disposer des autorisations suivantes sur la ressource de table dans chaque région où vous supprimez une réplique :

Utilisation des tables globales AWS KMS

Comme toutes les tables DynamoDB, les répliques de tables globales chiffrent toujours les données au repos à l'aide de clés de chiffrement stockées dans AWS Key Management Service ().AWS KMS

Multi-account les tables globales qui utilisent des CMK nécessitent la politique de clés de chaque réplica pour autoriser le principal du service de réplication DynamoDB (replication.dynamodb.amazonaws.com) à accéder à la clé pour la réplication et la gestion des paramètres. Les autorisations suivantes sont requises :

Important

DynamoDB a besoin d’accéder à la clé de chiffrement du réplica pour supprimer un réplica. Si vous souhaitez désactiver ou supprimer une clé gérée par le client utilisée pour chiffrer une réplique parce que vous supprimez la réplique, vous devez d'abord supprimer la réplique, attendre que la table soit supprimée du groupe de réplication en appelant describe dans l'une des autres répliques, puis désactiver ou supprimer la clé.

Si vous désactivez ou révoquez l'accès de DynamoDB à une clé gérée par le client utilisée pour chiffrer un réplica, la réplication depuis et vers le réplica s'arrête et le statut du réplica passe à. INACCESSIBLE_ENCRYPTION_CREDENTIALS Si un réplica reste dans INACCESSIBLE_ENCRYPTION_CREDENTIALS cet état pendant plus de 20 heures, il est converti de manière irréversible en une table DynamoDB à région unique.

Exemple AWS KMS policy

La AWS KMS politique permet à DynamoDB d'accéder aux deux AWS KMS clés pour la réplication entre les répliques A et B. Les AWS KMS clés associées au réplica DynamoDB dans chaque compte doivent être mises à jour conformément à la politique suivante :

JSON

{
    "Version":"2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": { "Service": "replication.dynamodb.amazonaws.com" },
        "Action": [
            "kms:Decrypt",
            "kms:ReEncrypt*",
            "kms:GenerateDataKey*",
            "kms:DescribeKey"
        ],
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "aws:SourceAccount": [ "111122223333", "444455556666" ],
                "aws:SourceArn": [
                    "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
                    "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB"
                ]
            }
        }
      }
   ]
 }