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, notamment Gestion des identités et des accès AWS politiques d'identité (IAM) et 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 (AWS KMS) cryptage. 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 en apprendrez également plus sur AWS KMS clés de chiffrement pour 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 par des conditions de contexte source sur des clés telles que aws:SourceAccount, aws:SourceArn, etc. — voir AWS clés de condition 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 le ReplicateSettings autorisation sur le principal du service, mais DynamoDB s'appuie é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 aux services, consultez Utilisation de rôles liés à des services dans le guide de l'utilisateur IAM.

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

Amazon DynamoDB crée automatiquement le AWSServiceRoleForDynamoDBGlobalTableSettingsManagement rôle lié à un service (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 à des répliques, vérifiez que vous ne refusez aucune des autorisations définies dans AWSServiceRoleForDynamoDBGlobalTableSettingsManagement au principal du SLR, car cela pourrait interférer avec la gestion des paramètres et nuire à 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 l'état de la table de répliques passe à REPLICATION_NOT_AUTHORIZED. Pour les tables globales multicomptes, si une réplique reste dans le REPLICATION_NOT_AUTHORIZED état pendant plus de 20 heures, la réplique est convertie 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 AWS Service 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é AWSServiceRoleForApplicationAutoScalingTableau _DynamoDB. Ce rôle lié à un service est automatiquement créé dans votre AWS compte lorsque vous configurez pour la première fois la mise à l'échelle automatique pour une table DynamoDB. Il permet à Application Auto Scaling de gérer la capacité des tables provisionnées et de créer 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 AWSApplicationAutoscalingDynamoDBTablePolicy au principal de l'application Auto Scaling SLR, car cela interromprait la fonctionnalité de mise à l'échelle 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 sections suivantes couvrent ces sujets étape par étape :

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 du UpdateTable API, vous avez besoin de l'autorisation suivante sur la ressource de table dans 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 du UpdateTimeToLive API, 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 UpdateTableReplicaAutoScaling API, vous devez disposer des autorisations suivantes sur la ressource de table dans toutes les régions contenant des répliques :

Dissocier une réplique

Pour dissocier votre réplique, vous devez disposer des deux dynamodb:UpdateTable et dynamodb:DisassociateTableReplica Autorisations IAM sur l'ARN de la table du réplica. Disassociation conserve sa table et ses données régionales. Pour modifier la protection contre la dissociation, vous devez disposer du dynamodb:UpdateTable Autorisation IAM.

Envoyez les deux demandes depuis le propre compte de la réplique à sa région. L'adhésion à une table globale n'autorise pas à dissocier une réplique appartenant à un autre compte.

Pour un exemple de politique, les prérequis et les instructions, voir Dissociation d'une réplique de table globale.

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 utiliser UpdateTable pour supprimer une table de répliques dans une région distante et chaque réplique doit être supprimée via DeleteTable API depuis le 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 Service de gestion des clés (AWS KMS).

Multi-account les tables globales qui utilisent des CMK nécessitent la politique de clés de chaque réplica pour accorder des autorisations au principal du service de réplication DynamoDB (replication.dynamodb.amazonaws.com) pour accéder à la clé de réplication et de 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 une réplique reste dans le INACCESSIBLE_ENCRYPTION_CREDENTIALS état pendant plus de 20 heures, la réplique est convertie de manière irréversible en une table DynamoDB à région unique.

Exemple AWS KMS policy

Le AWS KMS la politique permet à DynamoDB d'accéder à la fois AWS KMS clés de réplication entre les répliques A et B. Les AWS KMS les clés associées au réplica DynamoDB de 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"
                ]
            }
        }
      }
   ]
 }