Controle de acesso do DAX
O DynamoDB Accelerator (DAX) foi projetado para funcionar em conjunto com o DynamoDB para adicionar de forma imperceptível uma camada de cache às suas aplicações. No entanto, o DAX e o DynamoDB têm mecanismos de controle de acesso separados. Embora esses serviços usem o AWS Identity and Access Management (IAM) para implementar suas respectivas políticas de segurança, os modelos de segurança para o DAX e o DynamoDB são diferentes.
É altamente recomendável entender ambos os modelos de segurança para que você possa implementar as medidas de segurança adequadas às suas aplicações que usam DAX.
Esta seção descreve os mecanismos de controle de acesso fornecidos pelo DAX e fornece exemplos de políticas do IAM que você pode adaptar às suas necessidades.
Com o DynamoDB, você pode criar políticas do IAM que limitam as ações que um usuário pode realizar em recursos individuais do DynamoDB. Por exemplo, você pode criar uma função de usuário que permite que o usuário execute apenas ações somente leitura em uma determinada tabela do DynamoDB. (Para ter mais informações, consulte Gerenciamento de identidade e acesso no Amazon DynamoDB.) Por comparação, o modelo de segurança do DAX se concentra na segurança do cluster e na habilidade do cluster de realizar ações de API do DynamoDB em seu nome.
Atenção
Se, no momento, você estiver usando funções e políticas do IAM para restringir o acesso aos dados de tabelas do DynamoDB, então, o uso do DAX pode subverter essas políticas. Por exemplo, um usuário poderia ter acesso a uma tabela do DynamoDB via DAX, mas não ter acesso explícito à mesma tabela acessando o DynamoDB diretamente. Para ter mais informações, consulte Gerenciamento de identidade e acesso no Amazon DynamoDB.
O DAX não impõe separação em nível do usuário em dados no DynamoDB. Em vez disso, os usuários herdam as permissões da política do IAM do cluster do DAX quando acessam o cluster. Sendo assim, ao acessar as tabelas do DynamoDB via DAX, os únicos controles de acesso que estão em vigor são as permissões da política do IAM do cluster do DAX. Nenhuma outra permissão é reconhecida.
Se você precisar de isolamento, recomendamos criar clusters do DAX adicionais e definir o escopo da política do IAM para cada cluster conforme necessário. Por exemplo, é possível criar vários clusters do DAX e permitir que cada cluster acesse apenas uma única tabela.
Perfil de serviço do IAM para o DAX
Ao criar um cluster do DAX, você deve associar o cluster a uma função do IAM. Isso é conhecido como função de serviço do cluster.
Suponha que você queria criar um novo cluster do DAX chamado DAXCluster01. Você poderia criar uma função de serviço chamada DAXServiceRole e associar a função ao DAXCluster01. A política para DAXServiceRole definiria as ações do DynamoDB que o DAXCluster01 poderia realizar, em nome dos usuários que interagem com o DAXCluster01.
Ao criar uma função de serviço, você deve especificar uma relação de confiança entre DAXServiceRole e o serviço DAX em si. Uma relação de confiança determina quais entidades podem assumir uma função e usar suas permissões. A seguir há um exemplo de documento de relação de confiança de DAXServiceRole:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "dax.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
Essa relação de confiança permite que um cluster do DAX assuma DAXServiceRole e realize chamadas à API do DynamoDB em seu nome.
As ações da API do DynamoDB permitidas são descritas em um documento da política do IAM que você anexa à função de serviço DAXServiceRole. Veja abaixo um exemplo de documento de política.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DaxAccessPolicy", "Effect": "Allow", "Action": [ "dynamodb:DescribeTable", "dynamodb:PutItem", "dynamodb:GetItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:BatchGetItem", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem" ], "Resource": [ "arn:aws:dynamodb:us-west-2:123456789012:table/Books" ] } ] }
Essa política permite que o DAX execute todas as ações da API do DynamoDB em uma tabela do DynamoDB. A ação dynamodb:DescribeTable é necessária para o DAX manter metadados sobre a tabela, e as outras são ações de leitura e gravação executadas em itens na tabela. A tabela chamada Books está na região us-west-2 e pertence ao ID 123456789012 da conta da AWS.
nota
O DAX comporta mecanismos para evitar o problema de representante confuso durante o acesso entre serviços. Para obter mais informações, consulte O problema confused deputy no Guia do usuário IAM.
Política do IAM para permitir acesso a cluster do DAX
Depois de criar um cluster do DAX, será necessário conceder permissões a um usuário para que ele possa acessar o cluster do DAX.
Por exemplo, suponha que você queira conceder acesso ao DAXCluster01 para uma usuária chamada Alice. Você primeiro criaria uma política do IAM (AliceAccessPolicy) que define os clusters do DAX e as ações da API do DAX que o destinatário pode acessar. Em seguida, você deveria conceder acesso anexando essa política à usuária Alice.
O documento de política a seguir oferece acesso total ao destinatário no DAXCluster01.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "dax:*" ], "Effect": "Allow", "Resource": [ "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" ] } ] }
O documento de política permite o acesso ao cluster do DAX, mas não concede quaisquer permissões do DynamoDB. (As permissões do DynamoDB são atribuídas pela função de serviço do DAX.)
Para a usuária Alice, você deve primeiro criar AliceAccessPolicy com o documento de política mostrado anteriormente. Em seguida, você anexaria a política à Alice.
nota
Em vez de anexar a política a um usuário, você pode anexá-la a um perfil do IAM. Desse modo, todos os usuários que assumem essa função teriam as permissões que você definiu na política.
A política de usuário, junto com a função de serviço do DAX, determina os recursos e as ações de API do DynamoDB que o destinatário pode acessar via DynamoDB.
Estudo de caso: acesso ao DynamoDB e ao DAX
O cenário a seguir pode ajudar a conhecer melhor as políticas do IAM para uso com o DAX. (Vamos falar sobre este cenário em todo o resto desta seção.) O diagrama a seguir mostra uma visão geral de alto nível do cenário.
Nesse cenário, há as seguintes entidades:
-
Um usuário (Bob).
-
Um perfil do IAM (
BobUserRole). Bob assume essa função no tempo de execução. -
Uma política do IAM (
BobAccessPolicy). Essa política está anexada aoBobUserRole. OBobAccessPolicydefine os recursos do DynamoDB e do DAX que oBobUserRoletem permissão para acessar. -
Um cluster do DAX (
DAXCluster01). -
Uma função de serviço do IAM (
DAXServiceRole). Essa função permite que oDAXCluster01acesse o DynamoDB. -
Uma política do IAM (
DAXAccessPolicy). Essa política está anexada aoDAXServiceRole. ODAXAccessPolicydefine as APIS e os recursos do DynamoDB que oDAXCluster01têm permissão para acessar. -
Uma tabela do DynamoDB (
Books)
A combinação de elementos de política no BobAccessPolicy e DAXAccessPolicy determinam o que Bob pode fazer com a tabela Books. Por exemplo, Bob poderia conseguir acessar Books diretamente (usando o endpoint do DynamoDB), indiretamente (usando o cluster do DAX) ou ambos. Bob talvez também possa ler os dados de Books, gravar dados em Books, ou as duas coisas.
Acesso ao DynamoDB, mas sem acesso com o DAX
É possível permitir acesso direto a uma tabela do DynamoDB e, ao mesmo tempo, evitar o acesso indireto usando um cluster do DAX. Para acesso direto ao DynamoDB, as permissões do BobUserRole são determinadas pela BobAccessPolicy (que está anexada à função).
Acesso somente leitura ao DynamoDB (apenas)
Bob pode acessar o DynamoDB com BobUserRole. A política do IAM anexada a essa função (BobAccessPolicy) determina as tabelas do DynamoDB que BobUserRole pode acessar e quais APIs BobUserRole pode invocar.
Considere o documento de política a seguir para BobAccessPolicy.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
Quando esse documento está anexado a BobAccessPolicy, ele permite que BobUserRole acesse o endpoint do DynamoDB e execute operações somente leitura na tabela Books.
O DAX não aparece nessa política. Logo, o acesso via DAX é negado.
Acesso de leitura/gravação ao DynamoDB (apenas)
Se BobUserRole precisar de acesso de leitura/gravação ao DynamoDB, a política a seguir funcionará.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
Novamente, o DAX não aparece nessa política, portanto, o acesso via DAX é negado.
Acesso ao DynamoDB e ao DAX
Para permitir acesso a um cluster do DAX, você deve incluir ações específicas do DAX em uma política do IAM.
As ações específicas do DAX a seguir correspondem à suas equivalentes de nome semelhante na API do DynamoDB:
-
dax:GetItem -
dax:BatchGetItem -
dax:Query -
dax:Scan -
dax:PutItem -
dax:UpdateItem -
dax:DeleteItem -
dax:BatchWriteItem -
dax:ConditionCheckItem
O mesmo é válido para a chave de condição dax:EnclosingOperation.
Acesso somente leitura ao DynamoDB e acesso somente leitura ao DAX
Suponha que Bob requeira acesso somente de leitura à tabela Books, tanto via DynamoDB quanto via DAX. A política a seguir (anexada a BobUserRole) confere esse acesso.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
A política tem uma instrução para acesso ao DAX (DAXAccessStmt) e outra instrução para o acesso ao DynamoDB (DynamoDBAccessStmt). Essas declarações permitem que Bob envie as solicitações GetItem, BatchGetItem, Query e Scan ao DAXCluster01.
No entanto, a função de serviço de DAXCluster01 também exige acesso somente de leitura à tabela Books no DynamoDB. A política do IAM a seguir anexada à DAXServiceRole cumpriria essa exigência.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
Acesso de leitura/gravação ao DynamoDB e somente de leitura com o DAX
Para uma determinada função de usuário, você pode fornecer acesso de leitura e gravação a uma tabela do DynamoDB e também permitir acesso somente de leitura via DAX.
Para Bob, a política do IAM para BobUserRole precisaria permitir ações de leitura e gravação ao DynamoDB na tabela Books, e ao mesmo tempo aceitar ações somente de leitura via DAXCluster01.
O seguinte exemplo de documento de política para BobUserRole conferiria esse acesso.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
Além disso, DAXServiceRole exigiria uma política do IAM que permite que DAXCluster01 realize ações somente de leitura na tabela Books.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
Acesso de leitura e gravação ao DynamoDB e acesso de leitura e gravação ao DAX
Agora, suponha que Bob precisasse de acesso de leitura/gravação à tabela Books diretamente do DynamoDB ou indiretamente do DAXCluster01. O seguinte documento de política anexado a BobAccessPolicy confere esse acesso.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:ConditionCheckItem" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" }, { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
Além disso, DAXServiceRole exigiria uma política do IAM que permitisse que DAXCluster01 realizasse ações de leitura/gravação na tabela Books.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
Acesso ao DynamoDB via DAX, mas sem acesso direto ao DynamoDB
Nesse cenário, Bob pode acessar a tabela Books via DAX, mas não tem acesso direto à tabela Books no DynamoDB. Portanto, quando Bob recebe acesso ao DAX, ele também obtém acesso a uma tabela do DynamoDB que, de outra forma, ele não poderia acessar. Ao configurar uma política do IAM para a função de serviço do DAX, lembre-se de que qualquer usuário que recebe acesso ao cluster do DAX por meio da política de acesso do usuário tem acesso às tabelas especificadas nessa política. Nesse caso, BobAccessPolicy ganha acesso às tabelas especificadas na DAXAccessPolicy.
Se você estiver usando funções e políticas do IAM para restringir o acesso aos dados e tabelas do DynamoDB, o uso do DAX pode subverter essas políticas. Na política a seguir, Bob tem acesso a uma tabela do DynamoDB via DAX mas não tem acesso direto explícito à mesma tabela no DynamoDB.
O documento de política a seguir (BobAccessPolicy) anexado a BobUserRole conferiria esse acesso.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXAccessStmt", "Effect": "Allow", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:ConditionCheckItem" ], "Resource": "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" } ] }
Nessa política de acesso, não há permissões para acessar o DynamoDB diretamente.
Junto com BobAccessPolicy, a DAXAccessPolicy a seguir confere ao BobUserRole o acesso à tabela Books do DynamoDB mesmo que BobUserRole não possa acessar diretamente a tabela Books.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DynamoDBAccessStmt", "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem", "dynamodb:DescribeTable", "dynamodb:ConditionCheckItem" ], "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books" } ] }
Como o exemplo mostra, ao configurar o controle de acesso para a política de acesso do usuário e a política de acesso do cluster do DAX, você tem que compreender totalmente o acesso de ponta a ponta para garantir que o princípio de privilégio mínimo seja observado. Garanta também que conceder acesso a um cluster do DAX para um usuário não subverte as políticas de controle de acesso estabelecidas anteriormente.
