Uso de condições de política do IAM para controle de acesso refinado
Ao conceder permissões no DynamoDB, você pode especificar as condições que determinam como uma política de permissões entra em vigor.
Visão geral
No DynamoDB, você tem a opção de especificar condições ao conceder permissões usando uma política do IAM (consulte Gerenciamento de identidade e acesso no Amazon DynamoDB). Por exemplo, é possível:
-
Conceder permissões a fim de permitir acesso somente leitura aos usuários para determinados itens e atributos em uma tabela ou um índice secundário.
-
Conceder permissões para permitir somente acesso de gravação aos usuários para determinados atributos em uma tabela com base na identidade desse usuário.
No DynamoDB, você pode especificar as condições em uma política do IAM usando chaves de condição, como ilustrado no caso de uso na seção a seguir.
nota
Alguns serviços da AWS também oferecem suporte a condições baseadas em tags; no entanto, o DynamoDB não.
Caso de uso de permissões
Além de controlar o acesso a ações de API do DynamoDB, você também pode controlar o acesso a itens de dados e atributos individuais. Por exemplo, você pode fazer o seguinte:
-
Conceder permissões em uma tabela, mas restringir o acesso a itens específicos dessa tabela com base em determinados valores de chave primária. Um exemplo pode ser uma aplicação de rede social para jogos, onde todos os dados de jogos salvos dos usuários são armazenados em uma única tabela, mas nenhum usuário pode acessar itens de dados que não possui, como mostrado na ilustração a seguir:
-
Oculte informações para que apenas um subconjunto de atributos fique visível para o usuário. Um exemplo pode ser uma aplicação que exibe os dados de voo para aeroportos próximos, com base na localização do usuário. Nomes de companhias aéreas e horas de partida, além de números de voo, são exibidos. No entanto, atributos como nomes de piloto ou número de passageiros são ocultos, como mostrado na ilustração a seguir:
Para implementar esse tipo de controle de acesso refinado, grave uma política de permissões do IAM que especifica condições para acessar as credenciais de segurança e as permissões associadas. Em seguida, aplique a política aos usuários, grupos ou funções do que você criar usando o console do IAM. Sua política do IAM pode restringir o acesso a cada item de uma tabela, aos atributos desses itens ou a ambos ao mesmo tempo.
Se preferir, você pode usar federação de identidades na web para controlar o acesso dos usuários que serão autenticados por meio do Login with Amazon, Facebook ou Google. Para ter mais informações, consulte Usar federação de identidades na Web.
Use o elemento Condition
do IAM para implementar uma política de controle de acesso refinada. Ao adicionar um elemento Condition
a uma política de permissões, você pode permitir ou negar o acesso a itens e atributos em tabelas e índices do DynamoDB com base em seus requisitos comerciais específicos.
Como um exemplo, considere um aplicativo de jogos móveis que permite que os jogadores selecionem e joguem uma variedade de jogos diferentes. A aplicação usa uma tabela do DynamoDB chamada GameScores
para manter o controle das pontuações máximas e outros dados do usuário. Cada item na tabela é exclusivamente identificado por um ID de usuário e o nome do jogo que o usuário jogou. A tabela GameScores
tem uma chave primária que consiste em uma chave de partição (UserId
) e a chave de classificação (GameTitle
). Os usuários só têm acesso aos dados de jogos associados ao seu ID de usuário. Um usuário que deseja jogar um jogo deve pertencer a um perfil do IAM chamada GameRole
, a qual tem uma política de segurança anexada a ela.
Para gerenciar permissões de usuário neste aplicativo, grave uma política de permissões, como a seguinte:
{ "Version":"2012-10-17", "Statement":[ { "Sid":"AllowAccessToOnlyItemsMatchingUserID", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ], "dynamodb:Attributes":[ "UserId", "GameTitle", "Wins", "Losses", "TopScore", "TopScoreDateTime" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] }
Além de conceder permissões para ações específicas do DynamoDB (elemento Action
) na tabela GameScores
(elemento Resource
), o elemento Condition
usa as chaves de condição a seguir específicas do DynamoDB que limitam as permissões, da seguinte forma:
-
dynamodb:LeadingKeys
: esta chave de condição permite que os usuários acessem apenas os itens nos quais o valor de chave de partição coincide com seu ID de usuário. Este ID,${www.amazon.com:user_id}
, é uma variável de substituição. Para obter mais informações sobre variáveis de substituição, consulte Usar federação de identidades na Web. -
dynamodb:Attributes
: esta chave de condição limita o acesso aos atributos especificados para que apenas as ações listadas na política de permissões possam retornar valores para esses atributos. Além disso, a cláusulaStringEqualsIfExists
garante que o aplicativo sempre deve fornecer uma lista de atributos específicos nos quais atuar e que o aplicativo não pode solicitar todos os atributos.
Quando uma política do IAM é avaliada, o resultado é sempre verdadeiro (o acesso é permitido) ou falso (o acesso é negado). Se qualquer parte do elemento Condition
é falsa, toda a política é avaliada como falsa e o acesso é negado.
Importante
Caso você use dynamodb:Attributes
, deve especificar os nomes de todos os atributos de chave de índice e chave primária da tabela, além de quaisquer índices secundários que estejam listados na política. Caso contrário, o DynamoDB não poderá usar esses atributos de chave para executar a ação solicitada.
Os documentos de política do IAM podem conter apenas os seguintes caracteres Unicode: guia horizontal (U+0009), linefeeds (U+000A), retorno de carro (U+000D) e caracteres no intervalo U+0020 a U+00FF.
Especificar condições: usar chaves de condição
A AWS fornece um conjunto de chaves de condição predefinidas (chaves de condição no âmbito da AWS) para todos os serviços da AWS que oferecem suporte ao IAM para controle de acesso. Por exemplo, você pode usar a condição de chave aws:SourceIp
para verificar o endereço IP do solicitante antes de permitir que uma ação seja executada. Para obter mais informações e uma lista das chaves no âmbito da AWS, consulte Chaves disponíveis para condições no Guia do usuário do IAM.
A tabela a seguir mostra as chaves de condição específicas do serviço DynamoDB que se aplicam ao DynamoDB.
Chave de condição do DynamoDB | Descrição |
---|---|
dynamodb:LeadingKeys |
Representa o primeiro atributo de chave de uma tabela – em outras palavras, a chave de partição. O nome da chave |
dynamodb:Select |
Representa o parâmetro
|
dynamodb:Attributes |
Representa uma lista dos nomes de atributos em uma solicitação, ou os atributos que são retornados de uma solicitação. Os valores de
|
dynamodb:ReturnValues |
Representa o parâmetro
|
dynamodb:ReturnConsumedCapacity |
Representa o parâmetro
|
Limite de acesso de usuário
Muitas políticas de permissões do IAM permitem que os usuários acessem esses itens em uma tabela, na qual o valor de chave de partição coincide com o identificador do usuário. Por exemplo, o aplicativo de jogo anterior limita o acesso dessa forma, para que os usuários possam acessar somente os dados do jogo que estão associados ao ID de usuário deles. As variáveis de substituição do IAM ${www.amazon.com:user_id}
, ${graph.facebook.com:id}
e ${accounts.google.com:sub}
contêm identificadores do usuário para o Login with Amazon, no Facebook e no Google. Para saber como um aplicativo se conecta a um desses provedores de identidade e obtém esses identificadores, consulte Usar federação de identidades na Web.
nota
Cada um dos exemplos na seção a seguir define a cláusula Effect
como Allow
e especifica apenas as ações, os recursos e os parâmetros permitidos. O acesso é permitido apenas para o que está listado explicitamente na política do IAM.
Em alguns casos, é possível reescrever essas políticas para que elas sejam baseadas em negação (ou seja, definindo a cláusula Effect
como Deny
e invertendo toda a lógica na política). No entanto, recomendamos que você evite usar políticas baseadas em negação com o DynamoDB pois elas são difíceis de escrever corretamente em comparação às políticas baseadas em permissão. Além disso, futuras alterações na API do DynamoDB (ou alterações nas entradas existentes da API) podem tornar ineficaz uma política baseada em negação.
Políticas de exemplo: usar condições para controle de acesso refinado
Esta seção mostra várias políticas para a implementação de um controle de acesso refinado em tabelas e índices do DynamoDB.
nota
Todos os exemplos usam a Região us-west-2 e contêm IDs de conta fictícios.
O vídeo a seguir explica o controle de acesso refinado no DynamoDB usando condições de política do IAM.
1: conceder permissões que limitam o acesso a itens com um valor específico de chave de partição
A política de permissões a seguir concede permissões que permitem um conjunto de ações do DynamoDB na tabela GamesScore
. Ela usa a chave de condição dynamodb:LeadingKeys
para limitar as ações do usuário apenas aos itens cujo valor da chave de partição UserID
coincida com o ID do usuário único do Login with Amazon desse aplicativo.
Importante
A lista de ações não inclui permissões para Scan
porque Scan
retorna todos os itens, independentemente das principais chaves.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"FullAccessToUserItems", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ] } } } ] }
nota
Ao usar variáveis de política, você deve especificar explicitamente a versão 2012-10-17
na política. A versão padrão da linguagem de políticas de acesso, 2008-10-17
, não é compatível com as variáveis de política.
Para implementar o acesso somente leitura, você pode remover as ações que podem modificar os dados. Na política a seguir, somente as ações que fornecem acesso somente leitura são incluídas na condição.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"ReadOnlyAccessToUserItems", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ] } } } ] }
Importante
Caso você use dynamodb:Attributes
, deve especificar os nomes de todos os atributos de chave de índice e chave primária da tabela, além de quaisquer índices secundários que estejam listados na política. Caso contrário, o DynamoDB não poderá usar esses atributos de chave para executar a ação solicitada.
2: conceder permissões que limitam o acesso a determinados atributos em uma tabela
A política de permissões a seguir permite o acesso apenas a dois atributos em uma tabela, adicionando a chave de condição dynamodb:Attributes
. Esses atributos podem ser lidos, gravados ou avaliados em um filtro de verificação ou gravação condicional.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"LimitAccessToSpecificAttributes", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:BatchGetItem", "dynamodb:Scan" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:Attributes":[ "UserId", "TopScore" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES", "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] }
nota
A política usa uma abordagem de lista de permissões, o que permite o acesso a um conjunto nomeado de atributos. Mas você pode escrever uma política equivalente que nega o acesso a outros atributos. Não recomendamos essa abordagem com lista de proibições. Os usuários podem determinar os nomes desses atributos negados seguindo o princípio do privilégio mínimo, conforme explicado na Wikipedia em http://en.wikipedia.org/wiki/Principle_of_least_privilege
Essa política não permite PutItem
, DeleteItem
ou BatchWriteItem
. Essas ações sempre substituem o item anterior inteiro, o que permitira aos usuários excluir os valores anteriores que eles não tem permissão para acessar.
A cláusula StringEqualsIfExists
na política de permissões garante o seguinte:
-
Se o usuário especifica o parâmetro
Select
, seu valor deve serSPECIFIC_ATTRIBUTES
. Essa exigência impede que a ação da API retorne quaisquer atributos que não sejam permitidos, tal como de uma projeção do índice. -
Se o usuário especifica o parâmetro
ReturnValues
, então seu valor deve serNONE
,UPDATED_OLD
ouUPDATED_NEW
. Isso é necessário porque a açãoUpdateItem
também executa operações de leitura implícitas para verificar se um item existe antes de substituí-lo, e de forma que os valores de atributo anteriores possam ser retornados, se solicitado. RestringirReturnValues
dessa forma garante que os usuários possam apenas ler ou gravar atributos permitidos. -
A cláusula
StringEqualsIfExists
garante que apenas um desses parâmetros –Select
ouReturnValues
– pode ser usado por solicitação, no contexto das ações permitidas.
Veja a seguir algumas variações desta política:
-
Para permitir apenas as ações de leitura, você pode remover
UpdateItem
da lista de ações permitidas. Como nenhuma das ações restantes aceitamReturnValues
, você pode removerReturnValues
da condição. Também é possível alterarStringEqualsIfExists
paraStringEquals
, pois o parâmetroSelect
sempre tem um valor (ALL_ATTRIBUTES
, a menos que especificado de outra forma). -
Para permitir apenas as ações de gravação, você pode remover tudo menos
UpdateItem
da lista de ações permitidas. ComoUpdateItem
não usa o parâmetroSelect
, você pode removerSelect
da condição. Você também tem que alterarStringEqualsIfExists
paraStringEquals
porque o parâmetroReturnValues
sempre tem um valor (NONE
, a menos que especificado de outra forma). -
Para permitir todos os atributos cujo nome corresponde a um padrão, use
StringLike
em vez deStringEquals
, e use um caractere curinga de correspondência de padrão multicaractere (*).
3: conceder permissões para evitar atualizações em determinadas atributos
A política de permissões a seguir limita o acesso do usuário à atualização apenas dos atributos identificados pela chave de condição dynamodb:Attributes
. A condição StringNotLike
impede que um aplicativo atualize os atributos especificados usando a condição de chave dynamodb:Attributes
.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"PreventUpdatesOnCertainAttributes", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem" ], "Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores", "Condition":{ "ForAllValues:StringNotLike":{ "dynamodb:Attributes":[ "FreeGamesAvailable", "BossLevelUnlocked" ] }, "StringEquals":{ "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] }
Observe o seguinte:
-
A ação
UpdateItem
, como outras ações de gravação, exige acesso de leitura aos itens para que possa retornar valores antes e depois da atualização. Na política, é possível limitar a ação para acessar somente os atributos que podem ser atualizados, especificando a chave de condiçãodynamodb:ReturnValues
. A chave de condição restringeReturnValues
na solicitação para especificar apenasNONE
,UPDATED_OLD
ouUPDATED_NEW
e não incluiALL_OLD
ouALL_NEW
. -
As ações
PutItem
eDeleteItem
substituem um item inteiro e, assim, permite que os aplicativos modifiquem quaisquer atributos. Portanto, ao limitar um aplicativo para atualizar somente atributos específicos, você não deve conceder permissão para essas APIs.
4: conceder permissões para consultar somente atributos projetados em um índice
ATopScoreDateTimeIndex
política de permissões a seguir permite consultas em um índice secundário () usando a chave de condição dynamodb:Attributes
. A política também limita as consultas para solicitar somente atributos específicos que foram projetados no índice.
Para solicitar que a aplicação especifique uma lista de atributos na consulta, a política também especifica a chave de condição dynamodb:Select
para exigir que o parâmetro Select
da ação Query
do DynamoDB seja SPECIFIC_ATTRIBUTES
. A lista de atributos é limitada a uma lista específica que é fornecida por meio da chave de condição dynamodb:Attributes
.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"QueryOnlyProjectedIndexAttributes", "Effect":"Allow", "Action":[ "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:Attributes":[ "TopScoreDateTime", "GameTitle", "Wins", "Losses", "Attempts" ] }, "StringEquals":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] }
A política de permissões a seguir é semelhante, mas a consulta deve solicitar todos os atributos que foram projetados no índice.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"QueryAllIndexAttributes", "Effect":"Allow", "Action":[ "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "StringEquals":{ "dynamodb:Select":"ALL_PROJECTED_ATTRIBUTES" } } } ] }
5: conceder permissões para limitar o acesso a determinados atributos e valores de chave de partição
A política de permissões a seguir permite ações específicas do DynamoDB (especificadas no elemento Action
) em uma tabela e em um índice de tabela (especificadas no elemento Resource
). A política usa a chave de condição dynamodb:LeadingKeys
para restringir as permissões apenas aos itens cujo valor de chave de partição corresponde ao ID do usuário no Facebook.
{ "Version":"2012-10-17", "Statement":[ { "Sid":"LimitAccessToCertainAttributesAndKeyValues", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:BatchGetItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores", "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${graph.facebook.com:id}" ], "dynamodb:Attributes":[ "attribute-A", "attribute-B" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES", "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] }
Observe o seguinte:
-
As ações de gravação permitidas pela política (
UpdateItem
) só podem modificarattribute-A
ouattribute-B
. -
Como a política permite
UpdateItem
, um aplicativo pode inserir novos itens, e os atributos ocultos serão nulos em novos itens. Se esses atributos estiverem projetados emTopScoreDateTimeIndex
, a política terá o benefício adicional de impedir consultas que causem buscas na tabela. -
Os aplicativos não podem ler quaisquer atributos que não estejam listados em
dynamodb:Attributes
. Com essa política em vigor, uma aplicação deve definir o parâmetroSelect
comoSPECIFIC_ATTRIBUTES
em solicitações de leitura, e apenas os atributos da lista de permissões podem ser solicitados. Para solicitações de gravação, o aplicativo não pode definirReturnValues
comoALL_OLD
ouALL_NEW
e ele não pode executar operações de gravação condicional com base em outros atributos.