View a markdown version of this page

Sécurité des tables globales DynamoDB - Amazon DynamoDB
Rôles liés au service Global TablesAutorisations IAM pour les tables globales AWS KMS Chiffrement global des tables

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 DynamoDB à l'aide des autorisations IAM et du chiffrement AWS Key Management Service ()AWS KMS. Vous découvrirez les rôles liés aux services (SLR) qui permettent la réplication entre régions et la mise à l'échelle automatique, les autorisations IAM nécessaires pour créer, mettre à jour et supprimer des tables globales, ainsi que les différences entre les tables de cohérence éventuelle multi-régions (MREC) et les tables de cohérence renforcée multi-régions (MRSC). 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é.

Service-linked rôles pour les tables globales

Les tables globales DynamoDB s'appuient sur des rôles liés aux services (SLR) pour gérer les fonctionnalités de réplication interrégionale et de mise à l'échelle automatique.

Vous ne devez configurer ces rôles 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 en savoir plus sur l’utilisation des rôles liés à un service, consultez Utilisation des rôles liés à un service dans le Guide de l’utilisateur IAM.

Rôle lié à un service pour la réplication

Amazon DynamoDB crée automatiquement le rôle AWSServiceRoleForDynamoDBReplication lié aux services (SLR) lorsque vous créez votre première table globale. Ce rôle gère la réplication entre régions pour vous.

Lorsque vous appliquez des politiques basées sur les ressources à des répliques, assurez-vous de ne refuser aucune des autorisations définies dans le principal du AWSServiceRoleForDynamoDBReplicationPolicy SLR, car cela interromprait la réplication. Si vous refusez les autorisations SLR requises, la réplication vers et depuis les réplicas concernés s’arrêtera et le statut de la table de réplicas passera à REPLICATION_NOT_AUTHORIZED.

  • Pour les tables globales MREC (Multi-region Eventual Consistence), si une réplique reste dans REPLICATION_NOT_AUTHORIZED cet état pendant plus de 20 heures, elle est convertie de manière irréversible en une table DynamoDB à région unique.

  • Pour les tables globales MRSC (Multiregion Strong Cohérence), le refus des autorisations requises entraîne des opérations AccessDeniedException d'écriture et de lecture très cohérentes. Si un réplica reste dans REPLICATION_NOT_AUTHORIZED cet état pendant plus de sept jours, il devient définitivement inaccessible et les opérations d'écriture et de lecture très cohérentes continueront d'échouer avec une erreur. Certaines opérations de gestion, telles que la suppression des réplicas, seront couronnées de succès.

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é. AWSServiceRoleForApplicationAutoScaling_DynamoDBTable 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, assurez-vous de ne refuser aucune autorisation définie dans le principal de l'AWSApplicationAutoscalingDynamoDBTablePolicyapplication Auto Scaling SLR, car cela interromprait la fonctionnalité de dimensionnement automatique.

Exemples de politiques IAM pour les rôles liés aux services

Une politique IAM avec la condition suivante n'a aucune incidence sur les autorisations requises pour le SLR de réplication DynamoDB et AWS le SLR Auto Scaling. Cette condition peut être ajoutée à des politiques par ailleurs largement restrictives afin d'éviter toute interruption involontaire de la réplication ou de la mise à l'échelle automatique.

L'exemple suivant montre comment exclure les principaux de rôle liés à un service des instructions de refus :

"Condition": {
    "StringNotEquals": {
        "aws:PrincipalArn": [
            "arn:aws::iam::111122223333:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication",
            "arn:aws::iam::111122223333:role/aws-service-role/dynamodb.application-autoscaling.amazonaws.com/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable"
        ]
    }
}

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.

Note

Toutes les autorisations décrites doivent être appliquées à l'ARN de ressource de table spécifique dans la ou les régions concernées. L'ARN de la ressource de table suit le formatarn:aws:dynamodb:region:account-id:table/table-name, dans lequel vous devez spécifier les valeurs réelles de votre région, de votre identifiant de compte et de votre nom de table.

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

Les tables globales DynamoDB prennent en charge deux modes de cohérence : cohérence finale multirégionale (MREC) et cohérence forte multirégion (MRSC). Les tables globales MREC peuvent avoir plusieurs répliques dans un certain nombre de régions, ce qui permet d'assurer une cohérence éventuelle. Les tables globales MRSC nécessitent exactement trois régions (trois répliques ou deux répliques et un témoin) et offrent une cohérence élevée avec un objectif de point de restauration (RPO) nul.

Les autorisations requises pour créer des tables globales varient selon que vous créez une table globale avec ou sans témoin.

Autorisations pour créer des tables globales

Les autorisations suivantes sont requises à la fois pour la création initiale de tables globales et pour l'ajout ultérieur de répliques. Ces autorisations s'appliquent à la fois aux tables globales Multi-Region Eventual Consistency (MREC) et Multi-Region Strong Consistency (MRSC).

  • Les tables globales nécessitent une réplication entre régions, que DynamoDB gère via le rôle AWSServiceRoleForDynamoDBReplication lié aux services (SLR). L'autorisation suivante permet à DynamoDB de créer ce rôle automatiquement lorsque vous créez une table globale pour la première fois :

    • iam:CreateServiceLinkedRole

  • Pour créer une table globale ou ajouter une réplique à l'aide de l'UpdateTableAPI, vous devez disposer de l'autorisation suivante sur la ressource de la table source :

    • dynamodb:UpdateTable

  • Vous devez disposer des autorisations suivantes sur la ressource de table dans les régions pour que les répliques soient ajoutées :

    • dynamodb:CreateTable

    • dynamodb:CreateTableReplica

    • dynamodb:Query

    • dynamodb:Scan

    • dynamodb:UpdateItem

    • dynamodb:PutItem

    • dynamodb:GetItem

    • dynamodb:DeleteItem

    • dynamodb:BatchWriteItem

Autorisations supplémentaires pour les tables globales MRSC utilisant un témoin

Lorsque vous créez une table globale Multi-Region Strong Consistency (MRSC) avec une région témoin, vous devez disposer de l'autorisation suivante sur la ressource de table dans toutes les régions participantes (y compris les régions répliques et la région témoin) :

  • dynamodb:CreateGlobalTableWitness

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

La politique basée sur l'identité suivante vous permet de créer une table globale MREC ou MRSC nommée « utilisateurs » dans trois régions, notamment en créant le rôle lié au service de réplication DynamoDB requis.

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCreatingUsersGlobalTable",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateTable",
        "dynamodb:CreateTableReplica",
        "dynamodb:UpdateTable",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:UpdateItem",
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/users",
        "arn:aws:dynamodb:us-east-2:123456789012:table/users",
        "arn:aws:dynamodb:us-west-2:123456789012:table/users"
      ]
    },
    {
      "Sid": "AllowCreatingSLR",
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication"
      ]
    }
  ]
}

La politique basée sur l'identité suivante vous permet de créer des répliques de tables globales DynamoDB dans des régions spécifiques à l'aide de la clé de RequestedRegion condition aws :, y compris en créant le rôle lié au service de réplication DynamoDB requis.

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAddingReplicasToSourceTable",
      "Effect": "Allow",
      "Action": [
        "dynamodb:UpdateTable"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-1"
          ]
        }
      }
    },
    {
      "Sid": "AllowCreatingReplicas",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateTable",
        "dynamodb:CreateTableReplica",
        "dynamodb:UpdateTable",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:UpdateItem",
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-2",
            "us-west-2"
          ]
        }
      }
    },
    {
      "Sid": "AllowCreatingSLR",
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication"
      ]
    }
  ]
}

La politique basée sur l'identité suivante vous permet de créer une table globale DynamoDB MRSC nommée « utilisateurs » avec des répliques dans us-east-1 et us-east-2 et un témoin dans us-west-2, y compris en créant le rôle lié au service de réplication DynamoDB requis.

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCreatingUsersGlobalTableWithWitness",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateTable",
        "dynamodb:CreateTableReplica",
        "dynamodb:CreateGlobalTableWitness",
        "dynamodb:UpdateTable",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:UpdateItem",
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/users",
        "arn:aws:dynamodb:us-east-2:123456789012:table/users"
      ]
    },
    {
      "Sid": "AllowCreatingSLR",
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication"
      ]
    }
  ]
}

Cette politique basée sur l'identité vous permet de créer une table globale MRSC avec des répliques limitées à des régions spécifiques à l'aide de la clé de RequestedRegion condition aws : création illimitée de témoins dans toutes les régions, y compris la création du rôle lié au service de réplication DynamoDB requis.

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCreatingReplicas",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateTable",
        "dynamodb:CreateTableReplica",
        "dynamodb:UpdateTable",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:UpdateItem",
        "dynamodb:PutItem",
        "dynamodb:GetItem",
        "dynamodb:DeleteItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-east-2"
          ]
        }
      }
    },
    {
      "Sid": "AllowCreatingWitness",
      "Effect": "Allow",
      "Action": [
        "dynamodb:CreateGlobalTableWitness"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowCreatingSLR",
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:aws:iam::123456789012:role/aws-service-role/replication.dynamodb.amazonaws.com/AWSServiceRoleForDynamoDBReplication"
      ]
    }
  ]
}

Mise à jour de tables globales

Pour modifier les paramètres de réplication d'une table globale existante à l'aide de l'UpdateTableAPI, 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 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 :

    • application-autoscaling:DeleteScalingPolicy

    • application-autoscaling:DeleteScheduledAction

    • application-autoscaling:DeregisterScalableTarget

    • application-autoscaling:DescribeScalableTargets

    • application-autoscaling:DescribeScalingActivities

    • application-autoscaling:DescribeScalingPolicies

    • application-autoscaling:DescribeScheduledActions

    • application-autoscaling:PutScalingPolicy

    • application-autoscaling:PutScheduledAction

    • application-autoscaling:RegisterScalableTarget

  • 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

    Notez que Time to Live (TTL) n'est pris en charge que pour les tables globales configurées avec Evental Multi-Region Consistency (MREC). Pour plus d'informations sur le fonctionnement des tables globales avec TTL, consultez la rubrique Fonctionnement des tables globales DynamoDB.

Suppression de tables globales et suppression de répliques

Pour supprimer une table globale, vous devez supprimer toutes les répliques. Les autorisations requises pour cette opération varient selon que vous supprimez une table globale avec ou sans région témoin.

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. Ces autorisations s'appliquent à la fois aux tables globales Multi-Region Eventual Consistency (MREC) et Multi-Region Strong Consistency (MRSC).

  • Pour supprimer des répliques d'une table globale à l'aide de l'UpdateTableAPI, vous devez disposer de l'autorisation suivante sur la ressource de table de la région à partir de laquelle vous effectuez l'appel d'API :

    • dynamodb:UpdateTable

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

    • dynamodb:DeleteTable

    • dynamodb:DeleteTableReplica

Autorisations supplémentaires pour les tables globales MRSC utilisant un témoin

Pour supprimer une table globale MRSC (Multi-region strong consistency) avec un témoin, vous devez disposer de l'autorisation suivante sur la ressource de table dans toutes les régions participantes (y compris les régions répliques et la région témoin) :

  • dynamodb:DeleteGlobalTableWitness

Exemples de politiques IAM pour supprimer les répliques d'une table globale

Cette politique basée sur l'identité vous permet de supprimer une table globale DynamoDB nommée « utilisateurs » et ses répliques dans trois régions :

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:UpdateTable",
        "dynamodb:DeleteTable",
        "dynamodb:DeleteTableReplica"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/users",
        "arn:aws:dynamodb:us-east-2:123456789012:table/users",
        "arn:aws:dynamodb:us-west-2:123456789012:table/users"
      ]
    }
  ]
}

Cette politique basée sur l'identité vous permet de supprimer la réplique et le témoin d'une table globale MRSC nommée « utilisateurs » :

JSON
{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:UpdateTable",
        "dynamodb:DeleteTable",
        "dynamodb:DeleteTableReplica",
        "dynamodb:DeleteGlobalTableWitness"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:123456789012:table/users",
        "arn:aws:dynamodb:us-east-2:123456789012:table/users"
      ]
    }
  ]
}

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

Tous les réplicas d’une table globale doivent être configurés avec le même type de clé KMS (clé détenue par AWS , clé gérée par AWS ou clé gérée par le client).

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 un réplica parce que vous supprimez ce réplica, vous devez d’abord supprimer le réplica, attendre que le statut de la table de l’une des répliques restantes soit changé en ACTIVE, puis désactiver ou supprimer la clé.

Dans le cas d’une table globale configurée pour une cohérence finale multirégionale (MREC), 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 vers et depuis le réplica s’arrêtera et le statut du réplica passera à INACCESSIBLE_ENCRYPTION_CREDENTIALS. Si un réplica d’une table globale MREC reste dans l’état INACCESSIBLE_ENCRYPTION_CREDENTIALS pendant plus de 20 heures, le réplica est converti de manière irréversible en une table DynamoDB à région unique.

Dans le cas d’une table globale configurée pour une forte cohérence multirégionale (MREC), 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 vers et depuis le réplica s’arrêtera, les tentatives d’exécution d’écriture ou de lectures fortement cohérentes renverront une erreur, et l’état du réplica passera à INACCESSIBLE_ENCRYPTION_CREDENTIALS. Si un réplica d’une table globale MRSC reste dans l’état INACCESSIBLE_ENCRYPTION_CREDENTIALS pendant plus de sept jours, en fonction des autorisations spécifiques révoquées, le réplica sera archivé ou deviendra définitivement inaccessible.