Sécurité des tables globales DynamoDB - Amazon DynamoDB
Rôles liés au service des tables globalesAutorisations 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 étant des tables DynamoDB, vous utilisez les mêmes méthodes pour contrôler l'accès aux répliques que pour les tables à région unique, AWS Identity and Access Management y compris les politiques d'identité (IAM) et les politiques basées sur les ressources.

Cette rubrique explique comment sécuriser les tables globales DynamoDB à l'aide des autorisations AWS Key Management Service IAM et du chiffrement ().AWS KMS Vous découvrirez les rôles liés aux services (SLR) qui permettent la réplication entre régions et l'auto-scaling, 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 finale multirégionale (MREC) et les tables de cohérence forte multiré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é.

Rôles liés à un service pour les tables globales

Les tables globales DynamoDB s'appuient sur des rôles liés à un service SLRs () pour gérer les fonctionnalités de réplication entre régions et d'auto-scaling.

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 pour 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 AWSServiceRoleForDynamoDBReplication le rôle lié à un service (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 AWSServiceRoleForDynamoDBReplicationPolicy SLR principal, car cela interrompra 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 Evental Cohérence), si une réplique reste dans l'REPLICATION_NOT_AUTHORIZEDétat pendant plus de 20 heures, elle est convertie de manière irréversible en table DynamoDB à région unique.

  • Pour les tables globales à forte cohérence multirégionale (MRSC), le refus des autorisations requises entraîne des opérations AccessDeniedException d'écriture et de lecture très cohérentes. Si une réplique reste dans REPLICATION_NOT_AUTHORIZED cet état pendant plus de sept jours, elle 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 capacité allouée, le dimensionnement automatique doit être configuré pour la table globale. DynamoDB Auto Scaling AWS utilise le service Application Auto Scaling pour ajuster dynamiquement la capacité de débit allouée sur vos répliques de tables globales. Le service Application Auto Scaling crée un rôle lié au 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 pas refuser les autorisations définies dans le AWSApplicationAutoscalingDynamoDBTablePolicyprincipal Application Auto Scaling SLR, car cela interromprait la fonctionnalité de dimensionnement automatique.

Exemples de politiques IAM pour les rôles liés à un service

Une politique IAM présentant 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 d'interrompre involontairement la réplication ou le dimensionnement automatique.

L'exemple suivant montre comment exclure les principaux de rôles liés à un service des déclarations 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"
        ]
    }
}

Comment les tables globales utilisent AWS IAM

Les sections suivantes décrivent les autorisations requises pour les 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 la ressource de table spécifique dans la ou les régions concernées. L'ARN de la ressource de table suit le format arn: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 du nom de la 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égionale (MRSC). Les tables globales MREC peuvent avoir plusieurs répliques dans un certain nombre de régions et garantir une cohérence finale. Les tables mondiales MRSC nécessitent exactement trois régions (trois répliques ou deux répliques et un témoin) et garantissent une forte cohérence avec un objectif de point de reprise zéro (RPO).

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 la table globale et pour l'ajout de répliques ultérieurement. Ces autorisations s'appliquent à la fois aux tables globales Multi-Region Evental 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 lié à un service (AWSServiceRoleForDynamoDBReplicationSLR). 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 des autorisations suivantes 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 multirégionale à forte cohérence (MRSC) avec une région témoin, vous devez disposer des autorisations suivantes sur la ressource de la 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 créer des 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 :, notamment 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 « users » avec des répliques dans us-east-1 et us-east-2 et un témoin dans us-west-2, notamment 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 : et de la 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 dans la région dans laquelle vous effectuez l'appel d'API :

  • dynamodb:UpdateTable

Vous pouvez également mettre à jour d'autres configurations de table 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 une politique de dimensionnement automatique des répliques 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 avec 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 le Time to Live (TTL) n'est pris en charge que pour les tables globales configurées avec MREC (Multi-Region Evental Consistency). Pour plus d'informations sur le fonctionnement des tables globales avec le protocole TTL, voir Fonctionnement des tables globales DynamoDB.

Supprimer des tables globales et supprimer des 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. Cela 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 de cohérence éventuelle multirégionale (MREC) et de cohérence forte entre régions (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 dans laquelle 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 multirégionale à forte cohérence (MRSC) 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 « users » :

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 AWS dans 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.