Seguridad de las tablas globales de DynamoDB

Las réplicas de tablas globales son tablas de DynamoDB, por lo que se utilizan los mismos métodos para controlar el acceso a las réplicas que se utilizan para las tablas de una sola región, incluyendo las políticas de identidad y las políticas basadas en recursos de AWS Identity and Access Management (IAM). En este tema, se describe cómo proteger las tablas globales de varias cuentas de DynamoDB mediante permisos de IAM y cifrado de AWS Key Management Service (AWS KMS). Obtendrá información sobre las políticas basadas en recursos y los roles vinculados a servicios (SLR) que permiten la replicación y el escalado automático entre regiones y entre cuentas, los permisos de IAM necesarios para crear, actualizar y eliminar tablas globales, para tablas de coherencia final de varias regiones (MREC). También obtendrá información sobre las claves de cifrado de AWS KMS para administrar de forma segura la replicación entre regiones.

Proporciona información detallada sobre las políticas basadas en recursos y los permisos necesarios para establecer la replicación de tablas entre cuentas y regiones. Comprender este modelo de seguridad es fundamental para los clientes que necesitan implementar soluciones de replicación de datos seguras y entre cuentas.

Autorización de la entidad principal del servicio para la replicación

Las tablas globales de varias cuentas de DynamoDB utilizan un enfoque de autorización distinto, ya que la replicación se realiza más allá de los límites de las cuentas. Esto se consigue mediante la entidad principal del servicio de replicación de DynamoDB: replication.dynamodb.amazonaws.com. Cada cuenta participante debe incluir explícitamente esa entidad principal en la política de recursos de la tabla de réplicas, lo que concede permisos que puedan restringirse a réplicas específicas en función de las condiciones del contexto de origen de las claves como aws:SourceAccount, aws:SourceArn, etc. (consulte las claves de condición globales de AWS para obtener más información). Los permisos son bidireccionales, lo que significa que todas las réplicas deben concederse permisos de forma explícita entre sí antes de poder establecer la replicación en un par de réplicas concreto.

Los permisos de las entidades principales de servicio siguientes son esenciales para la replicación entre cuentas:

Cada réplica debe conceder los permisos anteriores a todas las demás réplicas y a sí misma, es decir, las condiciones del contexto de origen deben incluir el conjunto completo de réplicas que componen la tabla global. Estos permisos se verifican para cada nueva réplica cuando se agrega a una tabla global de varias cuentas. Esto verifica que las operaciones de replicación las realice solo el servicio DynamoDB autorizado y solo entre las tablas previstas.

Roles vinculados a servicios para tablas globales de varias cuentas

Las tablas globales de varias cuentas de DynamoDB replican la configuración en todas las réplicas, de modo que cada réplica se configura de forma idéntica con un rendimiento coherente y proporciona una experiencia de conmutación por error perfecta. La replicación de la configuración se controla mediante el permiso ReplicateSettings de la entidad principal de servicio, pero también confiamos en roles vinculados a servicios (SLR) para gestionar determinadas capacidades de replicación y escalado automático entre cuentas y entre regiones. Estos roles se configuran solo una vez por cuenta de AWS. Una vez creados, los mismos roles sirven en todas las tablas globales de la cuenta. Para obtener más información acerca de los roles vinculados a servicios, consulte Uso de roles vinculados a servicios en la Guía del usuario de IAM.

Rol vinculado al servicio de administración de configuración

Amazon DynamoDB crea automáticamente el rol vinculado al servicio (SLR) AWSServiceRoleForDynamoDBGlobalTableSettingsManagement cuando se crea la primera réplica de una tabla global de varias cuentas en la cuenta. Este rol administra la replicación de la configuración entre regiones y cuentas por usted.

Al aplicar políticas basadas en recursos a las réplicas, confirme que no deniega ninguno de los permisos definidos en AWSServiceRoleForDynamoDBGlobalTableSettingsManagement a la entidad principal de SLR, ya que esto podría interferir con la administración de la configuración y podría afectar la replicación si el rendimiento no coincide en todas las réplicas o GSI. Si deniega los permisos de SLR necesarios, la replicación hacia y desde las réplicas afectadas podría detenerse y el estado de la tabla de réplicas cambiará a REPLICATION_NOT_AUTHORIZED. Para tablas globales de varias cuentas, si una réplica permanece en el estado REPLICATION_NOT_AUTHORIZED durante más de 20 horas, la réplica se convierte irreversiblemente en una tabla de DynamoDB de una sola región. SLR tiene los siguientes permisos:

Rol vinculado a un servicio de escalado automático

Al configurar una tabla global para el modo de capacidad aprovisionada, se debe configurar el escalado automático para la tabla global. El escalado automático de DynamoDB utiliza el servicio de escalado automático de aplicaciones de AWS para ajustar dinámicamente la capacidad de rendimiento aprovisionada en las réplicas de tabla global. El servicio de escalado automático de aplicaciones crea un rol vinculado a un servicio (SLR) denominado AWSServiceRoleForApplicationAutoScaling_DynamoDBTable. Este rol vinculado al servicio se crea automáticamente en la cuenta de AWS al configurar el escalado automático para una tabla de DynamoDB. Permite el escalado automático de aplicaciones para administrar la capacidad de la tabla aprovisionada y crear alarmas de CloudWatch.

Al aplicar políticas basadas en recursos a las réplicas, asegúrese de no denegar ninguno de los permisos definidos en la AWSApplicationAutoscalingDynamoDBTablePolicy a la entidad principal de SLR de escalado automático de aplicaciones, ya que esto interrumpiría la funcionalidad de escalado automático.

Uso de las tablas globales de AWS IAM

En las siguientes secciones, se describen los permisos necesarios para las distintas operaciones de las tablas globales y se proporcionan ejemplos de políticas que le ayudarán a configurar el acceso adecuado para los usuarios y aplicaciones.

A continuación, se muestran los temas paso a paso que cubrimos en las secciones siguientes:

Creación de tablas globales y agregación de réplicas

Permisos para crear tablas globales

Cuando se agrega una nueva réplica a una tabla regional para formar una tabla global de varias cuentas o a una tabla global de varias cuentas existente, la entidad principal de IAM que realice la acción debe contar con la autorización de todos los miembros existentes. Todos los miembros existentes deben incluir el siguiente permiso en su política de tablas para que la adición de réplicas se realice correctamente:

Este control preciso permite que solo las cuentas autorizadas participen en la configuración de la tabla global.

Políticas de IAM de ejemplo para crear tablas globales

Actualización de una tabla global de varias cuentas

Para modificar la configuración de réplica de una tabla global existente mediante la API de UpdateTable, necesita el siguiente permiso en el recurso de tabla de la región en la que va a realizar la llamada a la API: dynamodb:UpdateTable

Además, puede actualizar otras configuraciones de tablas globales, como las políticas de escalado automático y la configuración del tiempo de vida. Se requieren los siguientes permisos para estas operaciones de actualización adicionales:

Para actualizar la configuración de Periodo de vida con la API de UpdateTimeToLive, debe tener el siguiente permiso en el recurso de la tabla en todas las regiones que contienen réplicas: dynamodb:UpdateTimeToLive

Para actualizar una política de escalado automático de réplicas con la API de UpdateTableReplicaAutoScaling, debe tener los siguientes permisos en el recurso de la tabla en todas las regiones que contengan réplicas:

Eliminación de tablas globales y réplicas

Para eliminar una tabla global, debe eliminar todas las réplicas. A diferencia de la tabla global con la misma cuenta, no puede utilizar UpdateTable para eliminar una tabla de réplica en una región remota y cada réplica se debe eliminar mediante la API DeleteTable de la cuenta que la controla.

Permisos para eliminar tablas globales y réplicas

Los siguientes permisos son necesarios para eliminar réplicas individuales y para eliminar por completo tablas globales. Al eliminar una configuración de tabla global, solo se elimina la relación de replicación entre tablas de distintas regiones. No se eliminará la tabla de DynamoDB de la última región restante. La tabla de la última región sigue existiendo como tabla estándar de DynamoDB con los mismos datos y configuraciones.

Necesita los siguientes permisos en el recurso de tabla en cada región en la que vaya a eliminar una réplica:

Uso de las tablas globales de AWS KMS

Como todas las tablas de DynamoDB, las réplicas de tablas globales siempre cifran los datos en reposo mediante claves de cifrado almacenadas en AWS Key Management Service (AWS KMS).

Las tablas globales de varias cuentas que utilizan CMK requieren que la política de claves de cada réplica otorgue permisos a la entidad principal del servicio de replicación de DynamoDB (replication.dynamodb.amazonaws.com) para acceder a la clave para la administración de la replicación y la configuración. Los siguientes permisos son necesarios:

Importante

DynamoDB requiere acceso a la clave de cifrado de la réplica para eliminarla. Si desea desactivar o eliminar una clave administrada por el cliente que se utiliza para cifrar una réplica porque va a eliminar la réplica, primero debe eliminar la réplica, esperar a que la tabla se elimine del grupo de replicación llamando a describir en una de las demás réplicas y luego desactivar o eliminar la clave.

Si desactiva o revoca el acceso de DynamoDB a una clave administrada por el cliente que se utiliza para cifrar una réplica, la replicación hacia y desde la réplica se detendrá y el estado de la réplica cambiará a INACCESSIBLE_ENCRYPTION_CREDENTIALS. Si una réplica permanece en el estado INACCESSIBLE_ENCRYPTION_CREDENTIALS durante más de 20 horas, la réplica se convierte irreversiblemente en una tabla de DynamoDB de una sola región.

Ejemplo de política de AWS KMS

La política de AWS KMS permite a DynamoDB acceder a ambas claves de AWS KMS para la replicación entre las réplicas A y B. Las claves de AWS KMS adjuntas a la réplica de DynamoDB en cada cuenta deben actualizarse con la siguiente política:

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