Uso de condições de política do IAM para controle de acesso refinado - Amazon DynamoDB

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:

    Um caso de uso que concede acesso em nível de tabela a um usuário, mas restringe o acesso a itens de dados específicos.
  • 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:

    Um caso de uso que exibe apenas um subconjunto de dados para os usuários, mas oculta determinados atributos dos dados.

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 Conditionusa 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áusula StringEqualsIfExists 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 LeadingKeys é no plural, mesmo se ela for usada com ações de um único item. Além disso, você deve usar o modificador ForAllValues ao utilizar LeadingKeys em uma condição.

dynamodb:Select

Representa o parâmetro Select de uma Query ou solicitação Scan. Select pode ter qualquer um dos seguintes valores:

  • ALL_ATTRIBUTES

  • ALL_PROJECTED_ATTRIBUTES

  • SPECIFIC_ATTRIBUTES

  • COUNT

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 Attributes são nomeados da mesma forma e têm o mesmo significado que os parâmetros de determinadas ações da API do DynamoDB, conforme mostrado a seguir:

  • AttributesToGet

    Usado por: BatchGetItem, GetItem, Query, Scan

  • AttributeUpdates

    Usado por: UpdateItem

  • Expected

    Usado por: DeleteItem, PutItem, UpdateItem

  • Item

    Usado por: PutItem

  • ScanFilter

    Usado por: Scan

dynamodb:ReturnValues

Representa o parâmetro ReturnValues de uma solicitação. ReturnValues pode ter qualquer um dos seguintes valores:

  • ALL_OLD

  • UPDATED_OLD

  • ALL_NEW

  • UPDATED_NEW

  • NONE

dynamodb:ReturnConsumedCapacity

Representa o parâmetro ReturnConsumedCapacity de uma solicitação. ReturnConsumedCapacity pode ter um dos seguintes valores:

  • TOTAL

  • NONE

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 e usar uma abordagem de lista de permissões para enumerar todos os valores permitidos, em vez de especificar os atributos negados.

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 ser SPECIFIC_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 ser NONE, UPDATED_OLD ou UPDATED_NEW. Isso é necessário porque a ação UpdateItem 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. Restringir ReturnValues 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 ou ReturnValues – 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 aceitam ReturnValues, você pode remover ReturnValues da condição. Também é possível alterar StringEqualsIfExists para StringEquals, pois o parâmetro Select 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. Como UpdateItem não usa o parâmetro Select, você pode remover Select da condição. Você também tem que alterar StringEqualsIfExists para StringEquals porque o parâmetro ReturnValues 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 de StringEquals, 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ção dynamodb:ReturnValues. A chave de condição restringe ReturnValues na solicitação para especificar apenas NONE, UPDATED_OLD ou UPDATED_NEW e não inclui ALL_OLD ou ALL_NEW.

  • As ações PutItem e DeleteItem 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 modificar attribute-A ou attribute-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 em TopScoreDateTimeIndex, 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âmetro Select como SPECIFIC_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 definir ReturnValues como ALL_OLD ou ALL_NEW e ele não pode executar operações de gravação condicional com base em outros atributos.

Tópicos relacionados da