Présentation Spécification de conditions : utilisation de clés de condition Rubriques en relation

Utilisation IAM de conditions politiques pour un contrôle d'accès précis

Lorsque vous accordez des autorisations dans DynamoDB, vous pouvez spécifier des conditions pour déterminer comment une politique d'autorisation doit prendre effet.

Présentation

Dans DynamoDB, vous avez la possibilité de définir des conditions lorsque vous accordez des autorisations à l'aide d'IAMune politique (voir). Gestion des identités et des accès pour Amazon DynamoDB Par exemple, vous pouvez :

Accordez des autorisations pour permettre aux utilisateurs d'accéder en lecture seule à certains éléments et attributs dans une table ou un index secondaire.
Accordez des autorisations pour permettre aux utilisateurs d'accéder en écriture seule à certains attributs d'une table, en fonction de l'identité de cet utilisateur.

Dans DynamoDB, vous pouvez spécifier les conditions d'IAMune politique à l'aide de clés de condition, comme illustré dans le cas d'utilisation présenté dans la section suivante.

Note

Certains AWS services prennent également en charge les conditions basées sur des balises, mais DynamoDB ne le fait pas.

Cas d'utilisation des autorisations

Outre le contrôle de l'accès aux actions DynamoDBAPI, vous pouvez également contrôler l'accès à des éléments de données et à des attributs individuels. Par exemple, vous pouvez effectuer les opérations suivantes :

Accorder des autorisations sur une table, mais restreindre l'accès à des éléments spécifiques de cette table en fonction de certaines valeurs de clé primaire. A titre d'exemple, une application de réseau social pour les jeux, où les données de jeu enregistrées de tous les utilisateurs sont stockées dans une seule table, mais où aucun utilisateur ne peut accéder aux éléments de données qu'il ne possède pas, comme illustré ci-après :
Masquer les informations afin que seul un sous-ensemble d'attributs soit visible de l'utilisateur. Un exemple peut être une application qui affiche les données de vol des aéroports proches, en fonction de l'emplacement de l'utilisateur. Les noms des compagnies aériennes, les heures d'arrivée et de départ, et les numéros de vol sont tous affichés. Cependant, les attributs tels que les noms des pilotes ou le nombre de passagers sont masqués, comme illustré ci-après :

Pour mettre en œuvre ce type de contrôle d'accès précis, vous devez rédiger une politique d'autorisation qui spécifie les conditions d'accès aux informations d'identification de sécurité et aux IAM autorisations associées. Vous appliquez ensuite la politique aux utilisateurs, aux groupes ou aux rôles que vous créez à l'aide de la IAM console. Votre IAM politique peut restreindre l'accès à des éléments individuels d'un tableau, l'accès aux attributs de ces éléments, ou les deux à la fois.

Le cas échéant, vous pouvez utiliser la fédération d'identité web pour contrôler l'accès par les utilisateurs authentifiés par Login with Amazon, Facebook ou Google. Pour de plus amples informations, veuillez consulter Utilisation de la fédération d'identité web.

Vous utilisez l'IAMConditionélément pour mettre en œuvre une politique de contrôle d'accès précise. En ajoutant un élément Condition à une politique d'autorisations, vous pouvez autoriser ou rejeter l'accès à des éléments et attributs dans des index et des tables DynamoDB, en fonction de vos besoins particuliers.

Par exemple, imaginons une application de jeux pour appareils mobiles à partir de laquelle les utilisateurs peuvent sélectionner une grande diversité de jeux. L'application utilise une table nommée DynamoDB nommée GameScores pour suivre les scores élevés et d'autres données utilisateur. Chaque élément de la table est identifié de façon unique par un ID d'utilisateur et le nom du jeu auquel l'utilisateur a joué. La table GameScores possède une clé primaire composée d'une clé de partition (UserId) et d'une clé de tri (GameTitle). Les utilisateurs ne peuvent accéder qu'aux données de jeu associées à leur ID utilisateur. Un utilisateur qui souhaite jouer à un jeu doit appartenir à un IAM rôle nomméGameRole, auquel une politique de sécurité est attachée.

Pour gérer les autorisations utilisateur de cette application, vous pouvez écrire une politique d'autorisations telle que la suivante :


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

En plus de l'octroi d'autorisations pour des actions DynamoDB spécifiques (élément Action) sur la table GameScores (élément Resource), l'élément Condition utilise les clés de condition suivantes spécifiques de DynamoDB qui limitent les autorisations comme suit :

dynamodb:LeadingKeys – Cette clé de condition permet aux utilisateurs d'accéder uniquement aux éléments dans lesquels la valeur de clé de partition correspond à leur ID utilisateur. Cet ID, ${www.amazon.com:user_id}, est une variable de substitution. Pour plus d'informations sur les variables de substitution, consultez Utilisation de la fédération d'identité web.
dynamodb:Attributes – Cette clé de condition limite l'accès aux attributs spécifiés afin que seules les actions figurant dans la politique d'autorisations puissent renvoyer des valeurs pour ces attributs. En outre, la clause StringEqualsIfExists garantit que l'application fournisse toujours une liste d'attributs spécifiques sur lesquels agir et que l'application ne peut pas demander tous les attributs.

Lorsqu'une IAM politique est évaluée, le résultat est toujours vrai (l'accès est autorisé) ou faux (l'accès est refusé). Si une partie d'un élément Condition a la valeur false, l'ensemble de la politique a la valeur false et l'accès est refusé.

Important

Si vous utilisez dynamodb:Attributes, vous devez spécifier les noms de tous les attributs de clé primaire et de clé d'index de la table et tous les index secondaires répertoriés dans la politique. Sinon, DynamoDB ne peut pas utiliser ces attributs de clé pour exécuter l'action demandée.

IAMles documents de politique ne peuvent contenir que les caractères Unicode suivants : tabulation horizontale (U+0009), fil d'alimentation (U+000A), retour de chariot (U+000D) et caractères compris entre U+0020 et U+00FF.

Spécification de conditions : utilisation de clés de condition

AWS fournit un ensemble de clés de condition prédéfinies (clés AWS de condition étendues) pour tous les AWS services prenant en charge IAM le contrôle d'accès. Par exemple, vous pouvez utiliser la clé de condition aws:SourceIp pour vérifier l'adresse IP du demandeur avant de permettre l'exécution d'une action. Pour plus d'informations et une liste des touches « wide AWS », consultez la section Clés disponibles pour les conditions dans le guide de IAM l'utilisateur.

Le tableau suivant illustre les clés de condition spécifiques du service DynamoDB qui s'appliquent à DynamoDB

Clé de condition DynamoDB	Description
`dynamodb:LeadingKeys`	Représente le premier attribut de clé d'une table, c'est-à-dire la clé de partition. Le nom de la clé `LeadingKeys` est pluriel, même si la clé est utilisée avec des actions à élément unique. En outre, vous devez utiliser le modificateur `ForAllValues` lorsque vous utilisez `LeadingKeys` dans une condition.
`dynamodb:Select`	Représente le paramètre `Select` d'une demande `Query` ou `Scan`. `Select` peut avoir l'une des valeurs suivantes : `ALL_ATTRIBUTES` `ALL_PROJECTED_ATTRIBUTES` `SPECIFIC_ATTRIBUTES` `COUNT`
`dynamodb:Attributes`	Représente une liste des noms d'attributs d'une demande ou des attributs renvoyés par une demande. `Attributes`les valeurs sont nommées de la même manière et ont la même signification que les paramètres de certaines actions API DynamoDB, comme indiqué ci-dessous : `AttributesToGet` Utilisé(e) par : `BatchGetItem, GetItem, Query, Scan` `AttributeUpdates` Utilisé(e) par : `UpdateItem` `Expected` Utilisé(e) par : `DeleteItem, PutItem, UpdateItem` `Item` Utilisé(e) par : `PutItem` `ScanFilter` Utilisé(e) par : `Scan`
`dynamodb:ReturnValues`	Représente le paramètre `ReturnValues` d'une demande. `ReturnValues` peut avoir l'une des valeurs suivantes : `ALL_OLD` `UPDATED_OLD` `ALL_NEW` `UPDATED_NEW` `NONE`
`dynamodb:ReturnConsumedCapacity`	Représente le paramètre `ReturnConsumedCapacity` d'une demande. `ReturnConsumedCapacity` peut avoir l'une des valeurs suivantes : `TOTAL` `NONE`

Limitation de l'accès utilisateur

De nombreuses politiques d'IAMautorisation autorisent les utilisateurs à accéder uniquement aux éléments d'une table où la valeur de la clé de partition correspond à l'identifiant de l'utilisateur. Par exemple, l'application de jeu précédente limite l'accès de cette façon afin que les utilisateurs ne puissent accéder qu'aux données de jeu associées à leur ID utilisateur. Les variables de IAM substitution ${www.amazon.com:user_id}${graph.facebook.com:id}, et ${accounts.google.com:sub} contiennent des identifiants utilisateur pour Login with Amazon, Facebook et Google. Pour savoir comment une application se connecte à l'un de ces fournisseurs d'identité et obtient ces identificateurs, consultez Utilisation de la fédération d'identité web.

Note

Chacun des exemples de la section suivante définit la clause Effect sur Allow et spécifie uniquement les actions, ressources et paramètres autorisés. L'accès n'est autorisé qu'à ce qui est explicitement indiqué dans la IAM politique.

Dans certains cas, il est possible de réécrire ces politiques afin qu'elles soient basées sur le refus (autrement dit, définition de la clause Effect sur Deny et inversion de toute la logique de la politique). Cependant, nous vous recommandons d'éviter d'utiliser des politiques basées sur un rejet avec DynamoDB, car elles sont difficiles à écrire correctement en comparaison des politiques basées sur une autorisation. En outre, les modifications futures apportées à la API DynamoDB (ou les modifications apportées aux entrées API existantes) peuvent rendre inefficace une politique basée sur le refus.

Exemples de politique : utilisation de conditions pour un contrôle d'accès détaillé

Cette section présente plusieurs politiques d'implémentation d'un contrôle précis des accès aux tables et index DynamoDB.

Note

Tous les exemples utilisent la région us-west-2 et contiennent un compte fictif. IDs

La vidéo ci-dessous explique le contrôle d'accès détaillé dans DynamoDB à l'aide de conditions de politique. IAM

1 : accorder des autorisations qui limitent l'accès aux éléments avec une valeur de clé de partition spécifique

La politique d'autorisation suivante accorde les autorisations qui permettent un ensemble d'actions DynamoDB sur la table GamesScore. Elle utilise la clé de condition dynamodb:LeadingKeys pour limiter les actions utilisateur uniquement sur les éléments dont la valeur de la clé de partition UserID correspond à la connexion avec l'ID utilisateur Login with Amazon unique pour cette application.

Important

La liste des actions n'inclut pas les autorisations pour Scan, car Scan retourne tous les éléments, quelles que soient les clés principales.


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

Note

Lorsque vous utilisez des variables de politique, vous devez spécifier explicitement la version 2012-10-17 de la politique. La version par défaut du langage de la politique d'accès, 2008-10-17, ne prend pas en charge les variables de politique.

Pour implémenter l'accès en lecture seule, vous pouvez supprimer les actions susceptibles de modifier les données. Dans la politique suivante, seules les actions qui fournissent l'accès en lecture seule sont incluses dans la condition.


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

Important

Si vous utilisez dynamodb:Attributes, vous devez spécifier les noms de tous les attributs de clé primaire et de clé d'index pour la table et tous les index secondaires répertoriés dans la politique. Sinon, DynamoDB ne peut pas utiliser ces attributs de clé pour exécuter l'action demandée.

2 : accorder les autorisations qui limitent l'accès aux attributs spécifiques d'une table

La politique d'autorisation suivante n'autorise l'accès qu'à deux attributs spécifiques d'une table en ajoutant la clé de condition dynamodb:Attributes. Ces attributs peuvent être lus, écrits ou évalués dans une écriture conditionnelle ou un filtre d'analyse.


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

Note

La politique adopte une approche de liste d'autorisations (ou liste verte), qui autorise l'accès à un ensemble nommé d'attributs. Vous pouvez écrire une politique équivalente qui refuse à la place l'accès aux autres attributs. Nous ne recommandons pas cette approche de liste de rejet (ou liste rouge). Les utilisateurs peuvent déterminer les noms de ces attributs rejetés en suivant le principe de moindre privilège (ou privilège minimum), tel qu'expliqué dans Wikipedia à l'adresse https://fr.wikipedia.org/wiki/Principe_de_moindre_privil%C3%A8ge, et utiliser une approche de liste d'autorisations afin d'énumérer toutes les valeurs autorisées au lieu de spécifier les attributs rejetés.

Cette politique n'autorise pas PutItem, DeleteItem ou BatchWriteItem. Ces actions remplacent toujours la totalité de l'élément précédent, ce qui permet aux utilisateurs de supprimer les valeurs précédentes des attributs auxquels ils ne sont pas autorisés à accéder.

La clause StringEqualsIfExists de la politique d'autorisation garantit ce qui suit :

Si l'utilisateur spécifie le paramètre Select, sa valeur doit être SPECIFIC_ATTRIBUTES. Cette exigence empêche l'APIaction de renvoyer des attributs non autorisés, tels que ceux provenant d'une projection d'index.
Si l'utilisateur spécifie le paramètre ReturnValues, sa valeur doit être NONE, UPDATED_OLD ou UPDATED_NEW. Cette action est obligatoire, car l'action UpdateItem effectue également des opérations de lecture implicites pour vérifier si un élément existe avant de le remplacer, et afin que les valeurs d'attribut précédentes puissent être retournées en cas de demande. Une telle restriction de ReturnValues garantit que les utilisateurs puissent uniquement lire ou écrire les attributs autorisés.
La clause StringEqualsIfExists garantit qu'un seul de ces paramètres, Select ou ReturnValues, peut être utilisé par demande dans le contexte des actions autorisées.

Voici quelques variations sur cette politique :

Pour autoriser uniquement les actions en lecture, vous pouvez supprimer UpdateItem de la liste des actions autorisées. Comme aucune des actions restantes n'accepte ReturnValues, vous pouvez supprimer ReturnValues de la condition. Vous pouvez également modifier StringEqualsIfExists en StringEquals, car le paramètre Select a toujours une valeur (ALL_ATTRIBUTES, sauf mention contraire).
Pour autoriser les actions d'écriture uniquement, vous pouvez supprimer tout sauf UpdateItem dans la liste des actions autorisées. Comme UpdateItem n'utilise pas le paramètre Select, vous pouvez supprimer Select de la condition. Vous pouvez également modifier StringEqualsIfExists en StringEquals, car le paramètre ReturnValues a toujours une valeur (NONE, sauf mention contraire).
Pour autoriser tous les attributs dont le nom correspond à un modèle, utilisez StringLike au lieu de StringEquals et utilisez un caractère générique de correspondance du modèle multi-caractère (*).

3 : accorder les autorisations pour empêcher les mises à jour de certains attributs

La politique d'autorisation suivante limite l'accès utilisateur à la seule mise à jour des attributs spécifiques identifiés par la clé de condition dynamodb:Attributes. La condition StringNotLike empêche qu'une application ne mette à jour les attributs spécifiés à l'aide de la clé de condition 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"
               ]
            }
         }
      }
   ]
}

Notez ce qui suit :

L'action UpdateItem, comme les autres actions d'écriture, nécessite un accès en lecture aux éléments de façon à pouvoir retourner les valeurs avant et après la mise à jour. Dans la politique, vous limitez l'action à n'accéder qu'aux attributs qui sont autorisés à être mis à jour en spécifiant la clé de condition dynamodb:ReturnValues. La clé de condition limite ReturnValues dans la demande pour spécifier uniquement NONE, UPDATED_OLD ou UPDATED_NEW et n'inclut pas ALL_OLD ou ALL_NEW.
Les actions PutItem et DeleteItem remplacent un ensemble complet, ce qui permet aux applications de modifier n'importe quel attribut. Ainsi, lorsque vous limitez une application à la mise à jour d'attributs spécifiques uniquement, vous ne devez pas accorder d'autorisation pour ceux-ciAPIs.

4 : accorder les autorisations de n'interroger que les attributs projetés d'un index

La politique d'autorisations suivante autorise les requêtes sur un index secondaire (TopScoreDateTimeIndex) à l'aide de la clé de condition dynamodb:Attributes. La politique limite aussi les requêtes à ne demander que les attributs spécifiques qui ont été projetés sur l'index.

Pour demander que l'application spécifie une liste d'attributs dans la requête, la politique spécifie également la clé de condition dynamodb:Select pour exiger que le paramètre Select de l'action DynamoDB Query soit SPECIFIC_ATTRIBUTES. La liste des attributs est limitée à une liste spécifique qui est fournie à l'aide de la clé de condition 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"
            }
         }
      }
   ]
}

La politique d'autorisation suivante est similaire, mais la requête doit demander tous les attributs qui ont été projetés sur l'index.


{
   "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 : accorder les autorisations de limiter l'accès à certains attributs et valeurs de clé de partition

La politique d'autorisation suivante autorise des actions spécifiques de DynamoDB (spécifiées dans l'élément Action) sur une table et un index de table (spécifiés dans l'élément Resource). La politique utilise la clé de condition dynamodb:LeadingKeys pour limiter les autorisations aux seuls éléments dont la valeur de clé de partition correspond à l'ID Facebook de l'utilisateur.


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

Notez ce qui suit :

Les actions d'écriture autorisées par la politique (UpdateItem) peuvent uniquement modifier attribute-A ou attribute-B.
Comme la politique autorise UpdateItem, une application peut insérer de nouveaux éléments et les attributs cachés ont la valeur null dans les nouveaux éléments. Si ces attributs sont projetés dans TopScoreDateTimeIndex, la politique présente l'avantage supplémentaire d'empêcher les requêtes qui génèrent des extractions de la table.
Les applications ne peuvent pas lire d'autres attributs que ceux listés dans dynamodb:Attributes. Avec cette politique en place, une application doit définir le paramètre Select sur SPECIFIC_ATTRIBUTES dans les demandes de lecture, et seuls des attributs figurant dans la liste verte peuvent être demandés. Pour les demandes d'écriture, l'application ne peut pas définir ReturnValues sur ALL_OLD ou ALL_NEW, et elle ne peut pas effectuer d'opérations d'écriture conditionnelle basées sur d'autres attributs.

Rubriques en relation

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Empêcher l'achat de capacité réservée

Utilisation de la fédération d'identité web