Segurança de tabelas globais do DynamoDB

As réplicas de tabelas globais são tabelas do DynamoDB, então você usa os mesmos métodos para controlar o acesso às réplicas que usa para tabelas de região única, incluindo políticas de identidade e políticas baseadas em recursos do AWS Identity and Access Management (IAM). Este tópico aborda como proteger tabelas globais de várias contas do DynamoDB usando permissões do IAM e a criptografia do AWS Key Management Service (AWS KMS). Você aprenderá mais sobre políticas baseadas em recursos e perfis vinculados ao serviço (SLR) que permitem a replicação e o ajuste de escala automático entre contas e entre regiões, bem como sobre as permissões do IAM necessárias para criar, atualizar e excluir tabelas globais, para ter tabelas com consistência final multirregional (MREC). Você também aprenderá mais sobre chaves de criptografia do AWS KMS para gerenciar a replicação entre regiões com segurança.

Este tópico contém informações detalhadas sobre as políticas e permissões baseadas em recursos necessárias para estabelecer a replicação de tabelas entre contas e entre regiões. Compreender esse modelo de segurança é fundamental para clientes que precisam implementar soluções seguras de replicação de dados entre contas.

Autorização de replicação à entidade principal do serviço

As tabelas globais de várias contas do DynamoDB usam uma abordagem de autorização distinta porque a replicação é realizada entre os limites da conta. Isso é feito usando a entidade principal do serviço de replicação do DynamoDB: replication.dynamodb.amazonaws.com. Cada conta participante deve dar permissão explícita a essa entidade principal na política de recursos da tabela-réplica, concedendo a ela permissões que podem se restringir a réplicas específicas de acordo com as condições de contexto da origem em chaves como aws:SourceAccount, aws:SourceArn etc. Para ver detalhes, consulte Chaves de condição globais da AWS. As permissões são bidirecionais, o que significa que todas as réplicas devem conceder permissões explicitamente umas às outras para que a replicação seja estabelecida em qualquer par específico de réplicas.

As seguintes permissões de entidade principal de serviço são essenciais para a replicação entre contas:

Cada réplica deve conceder as permissões acima a todas as outras réplicas e a si mesma; isto é, as condições de contexto da origem devem incluir o conjunto completo de réplicas que compõe a tabela global. Essas permissões são verificadas para cada nova réplica quando ela é adicionada a uma tabela global de várias contas. Esse processo verifica se as operações de replicação são realizadas somente pelo serviço autorizado do DynamoDB e apenas entre as tabelas pretendidas.

Perfis vinculados ao serviço para tabelas globais de várias contas

As tabelas globais de várias contas do DynamoDB replicam as configurações em todas as réplicas para que cada réplica seja configurada de forma idêntica com um throughput consistente e ofereça uma experiência de failover contínua. A replicação das configurações é controlada por meio da permissão ReplicateSettings da entidade principal do serviço, mas também dependemos de perfis vinculados ao serviço (SLRs) para gerenciar determinados recursos de replicação e ajuste de escala automático entre contas e entre regiões. É necessário configurar esses perfis somente uma vez por conta da AWS. Depois de criados, os mesmos perfis atendem a todas as tabelas globais da sua conta. Para ter mais informações sobre perfis vinculados ao serviço, consulte Criar um perfil vinculado ao serviço no Guia do usuário do IAM.

Perfil vinculado ao serviço de gerenciamento de configurações

O Amazon DynamoDB cria automaticamente o perfil vinculado ao serviço (SLR) AWSServiceRoleForDynamoDBGlobalTableSettingsManagement quando a primeira réplica de tabela global de várias contas é criada na conta. Esse perfil gerencia a replicação de configurações entre contas e entre regiões para você.

Ao aplicar políticas baseadas em recursos às réplicas, não negue nenhuma das permissões definidas em AWSServiceRoleForDynamoDBGlobalTableSettingsManagement à entidade principal do SLR, pois isso pode interferir no gerenciamento de configurações e prejudicar a replicação se o throughput não corresponder entre as réplicas ou os GSIs. Se você negar as permissões de SLR necessárias, a replicação entre as réplicas afetadas será interrompida e o status da tabela-réplica mudará para REPLICATION_NOT_AUTHORIZED. No caso de tabelas globais de várias contas, se uma réplica permanecer no estado REPLICATION_NOT_AUTHORIZED por mais de vinte horas, ela será convertida irreversivelmente em uma tabela do DynamoDB de região única. O SLR tem as seguintes permissões:

Função vinculada a serviço do IAM para ajuste de escala automático

Quando você configura uma tabela global para o modo de capacidade provisionada, também deve configurar o ajuste de escala automático para ela. O ajuste de escala automático do DynamoDB usa o serviço AWS Application Auto Scaling para ajustar dinamicamente a capacidade de throughput em suas réplicas de tabela global. O serviço Application Auto Scaling cria um perfil vinculado ao serviço (SLR) chamado AWSServiceRoleForApplicationAutoScaling_DynamoDBTable. Esse perfil vinculado ao serviço é criado automaticamente em sua conta da AWS quando você configura o ajuste de escala automático para uma tabela do DynamoDB. Isso permite que o Application Auto Scaling gerencie a capacidade provisionada da tabela e crie alarmes do CloudWatch.

Ao aplicar políticas baseadas em recursos às réplicas, verifique se você não negou nenhuma permissão definida em AWSApplicationAutoscalingDynamoDBTablePolicy à entidade principal de SLR do Application Auto Scaling, pois isso interromperá a funcionalidade de ajuste de escala automático.

Como as tabelas globais usam o IAM da AWS

As seções a seguir descrevem as permissões necessárias para diferentes operações de tabela global e contêm exemplos de políticas para ajudar você a configurar o acesso apropriado para seus usuários e aplicações.

Estes são os tópicos detalhados que abordamos nas seções abaixo:

Criar tabelas globais e adicionar réplicas

Permissões para criar tabelas globais

Quando uma nova réplica é adicionada a uma tabela regional para formar uma tabela global de várias contas ou a uma tabela global de várias contas existente, a entidade principal do IAM que executa a ação deve ser autorizada por todos os membros existentes. Todos os membros existentes precisam conceder a seguinte permissão em sua política de tabela para que a inclusão da réplica seja bem-sucedida:

Esse controle preciso permite que somente contas autorizadas participem da configuração da tabela global.

Exemplos de política do IAM para criar tabelas globais

Atualizar uma tabela global de várias contas

Para modificar as configurações de réplica de uma tabela global existente usando a API UpdateTable, é preciso ter a seguinte permissão no recurso de tabela na região em que você está fazendo a chamada de API: dynamodb:UpdateTable.

Além disso, você pode atualizar outras configurações da tabela global, como políticas de ajuste de escala automático e configurações de tempo de vida. As seguintes permissões são necessárias para essas operações adicionais de atualização:

Para atualizar as configurações de vida útil com a API UpdateTimeToLive, é necessário ter a seguinte permissão no recurso de tabela em todas as regiões que contêm réplicas: dynamodb:UpdateTimeToLive.

Para atualizar uma política de ajuste de escala automático da réplica com a API UpdateTableReplicaAutoScaling, é necessário ter as seguintes permissões no recurso de tabela em todas as regiões que contêm réplicas:

Excluir tabelas globais e remover réplicas

Para excluir uma tabela global, você deve remover todas as réplicas. Ao contrário da tabela global da mesma conta, não é possível usar UpdateTable para excluir uma tabela-réplica em uma região remota e cada réplica deve ser excluída por meio da API DeleteTable da conta que a controla.

Permissões para excluir tabelas globais e remover réplicas

As permissões a seguir são necessárias tanto para remover réplicas individuais quanto para excluir completamente as tabelas globais. A exclusão de uma configuração de tabela global só remove o relacionamento de replicação entre tabelas em diferentes regiões. Ela não exclui a tabela subjacente do DynamoDB na última região restante. A tabela na última região continua existindo como uma tabela padrão do DynamoDB com os mesmos dados e configurações.

Você precisa das seguintes permissões no recurso de tabela em cada região em que você está removendo uma réplica:

Como as tabelas globais usam AWS KMS

Como todas as tabelas do DynamoDB, as réplicas de tabela global sempre criptografam dados em repouso usando chaves de criptografia armazenadas no AWS Key Management Service (AWS KMS).

As tabelas globais de várias contas que usam CMKs exigem que a política de chave de cada réplica conceda permissões à entidade principal do serviço de replicação (replication.dynamodb.amazonaws.com) do DynamoDB para acessar a chave e usá-la na replicação e no gerenciamento de configurações. As seguintes permissões são necessárias:

Importante

O DynamoDB exige acesso à chave de criptografia da réplica para excluir uma réplica. Se você quiser desabilitar ou excluir uma chave gerenciada pelo cliente usada para criptografar uma réplica porque está excluindo a réplica, primeiro exclua a réplica, aguarde a remoção da tabela do grupo de replicação chamando describe em uma das outras réplicas e, em seguida, desabilite ou exclua a chave.

Se você desabilitar ou revogar o acesso do DynamoDB a uma chave gerenciada pelo cliente usada para criptografar uma réplica, a replicação de e para a réplica será interrompida e o status da réplica mudará para INACCESSIBLE_ENCRYPTION_CREDENTIALS. Se uma réplica permanecer no estado INACCESSIBLE_ENCRYPTION_CREDENTIALS por mais de vinte horas, ela será convertida irreversivelmente em uma tabela do DynamoDB de região única.

Exemplo de política do AWS KMS

A política AWS KMS permite que o DynamoDB acesse ambas as chaves do AWS KMS para replicação entre as réplicas A e B. As chaves do AWS KMS anexadas à réplica do DynamoDB em cada conta precisam ser atualizadas com a seguinte 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"
                ]
            }
        }
      }
   ]
 }