Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Gestion des identités et des accès AWS (IAM) et DynamoDB
Gestion des identités et des accès AWS est un AWS service qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Des administrateurs contrôlent les personnes qui peuvent être authentifiées (connectées) et autorisées (disposant d’autorisations) pour utiliser des ressources Amazon DynamoDB et DynamoDB Accelerator. Vous pouvez utiliser IAM pour gérer les autorisations d’accès et implémenter des politiques de sécurité pour Amazon DynamoDB et DynamoDB Accelerator. IAM est un AWS service que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Gestion des identités et des accès pour Amazon DynamoDB](security-iam.md)
+ [Utilisation de conditions de politique IAM pour un contrôle d’accès précis](specifying-conditions.md)
# Gestion des identités et des accès pour Amazon DynamoDB
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Des administrateurs IAM contrôlent les personnes qui *s’authentifient* (sont connectées) et *sont autorisées* (disposent d’autorisations) à utiliser des ressources DynamoDB. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Fonctionnement d’Amazon DynamoDB avec IAM](security_iam_service-with-iam.md)
+ [Exemples de stratégies basées sur l’identité pour Amazon DynamoDB](security_iam_id-based-policy-examples.md)
+ [Résolution de problèmes pour l’identité et l’accès Amazon DynamoDB](security_iam_troubleshoot.md)
+ [Politique IAM pour empêcher l’achat de capacité réservée DynamoDB](iam-policy-prevent-purchase-reserved-capacity.md)
## Public ciblé
La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction de votre rôle :
+ **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution de problèmes pour l’identité et l’accès Amazon DynamoDB](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Fonctionnement d’Amazon DynamoDB avec IAM](security_iam_service-with-iam.md))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de stratégies basées sur l’identité pour Amazon DynamoDB](security_iam_id-based-policy-examples.md))
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS
Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.
Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.
### Compte AWS utilisateur root
Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*.
### Identité fédérée
Il est recommandé d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à Services AWS l'aide d'informations d'identification temporaires.
Une *identité fédérée* est un utilisateur provenant de l'annuaire de votre entreprise, de votre fournisseur d'identité Web ou Directory Service qui y accède à Services AWS l'aide d'informations d'identification provenant d'une source d'identité. Les identités fédérées assument des rôles qui fournissent des informations d’identification temporaires.
Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Pour plus d’informations, consultez [Qu’est-ce que IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
### Utilisateurs et groupes IAM
Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.
### Rôles IAM
Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle d'utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération d' AWS API AWS CLI ou d'API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Gestion de l’accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.
### Politiques basées sur l’identité
Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources.
Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.
### Autres types de politique
AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# Fonctionnement d’Amazon DynamoDB avec IAM
Avant d’utiliser IAM pour gérer l’accès à DynamoDB, découvrez les fonctions IAM que vous pouvez utiliser avec DynamoDB.
| Fonctionnalité IAM | Support DynamoDB |
| --- | --- |
| [Politiques basées sur l’identité](#security_iam_service-with-iam-id-based-policies) | Oui |
| [Politiques basées sur les ressources](#security_iam_service-with-iam-resource-based-policies) | Oui |
| [Actions de politique](#security_iam_service-with-iam-id-based-policies-actions) | Oui |
| [Ressources de politique](#security_iam_service-with-iam-id-based-policies-resources) | Oui |
| [Clés de condition de politique](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Oui |
| [ACLs](#security_iam_service-with-iam-acls) | Non |
| [ABAC (étiquettes dans les politiques)](#security_iam_service-with-iam-tags) | Oui |
| [Informations d’identification temporaires](#security_iam_service-with-iam-roles-tempcreds) | Oui |
| [Autorisations de principal](#security_iam_service-with-iam-principal-permissions) | Oui |
| [Rôles de service](#security_iam_service-with-iam-roles-service) | Oui |
| [Rôles liés à un service](#security_iam_service-with-iam-roles-service-linked) | Oui |
*Pour obtenir une vue d'ensemble du fonctionnement de DynamoDB et des AWS autres services avec la plupart des fonctionnalités IAM, [AWS consultez la section Services compatibles avec IAM dans le Guide de l'utilisateur](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) IAM.*
## Politiques basées sur l’identité pour DynamoDB
**Prend en charge les politiques basées sur l’identité :** oui
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
### Exemples de stratégies basées sur l’identité pour DynamoDB
Pour voir des exemples de politiques DynamoDB basées sur l’identité, veuillez consulter [Exemples de stratégies basées sur l’identité pour Amazon DynamoDB](security_iam_id-based-policy-examples.md).
## Politiques basées sur une ressource dans DynamoDB
**Prend en charge les politiques basées sur les ressources** : oui
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS
Pour permettre un accès intercompte, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Actions de politique pour DynamoDB
**Prend en charge les actions de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Pour afficher la liste des actions DynamoDB, veuillez consulter [Actions définies par Amazon DynamoDB](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-actions-as-permissions) dans la *Référence de l’autorisation de service*.
Les actions de politique dans DynamoDB utilisent le préfixe suivant avant l’action :
```
aws
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"aws:action1",
"aws:action2"
]
```
Pour voir des exemples de politiques DynamoDB basées sur l’identité, veuillez consulter [Exemples de stratégies basées sur l’identité pour Amazon DynamoDB](security_iam_id-based-policy-examples.md).
## Ressources de politique pour DynamoDB
**Prend en charge les ressources de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
*Pour consulter la liste des types de ressources DynamoDB et ARNs leurs caractéristiques, [consultez la section Ressources définies par Amazon DynamoDB dans le Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-resources-for-iam-policies).* Pour savoir les actions avec lesquelles vous pouvez spécifier l’ARN de chaque ressource, consultez [Actions définies par Amazon DynamoDB](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-actions-as-permissions).
Pour voir des exemples de politiques DynamoDB basées sur l’identité, veuillez consulter [Exemples de stratégies basées sur l’identité pour Amazon DynamoDB](security_iam_id-based-policy-examples.md).
## Clés de condition de politique pour DynamoDB
**Prend en charge les clés de condition de politique spécifiques au service :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Pour afficher la liste des clés de condition DynamoDB, veuillez consulter [Clés de condition pour Amazon DynamoDB](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-policy-keys) dans la *Référence de l’autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez [Actions définies par Amazon DynamoDB](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-actions-as-permissions).
Pour voir des exemples de politiques DynamoDB basées sur l’identité, veuillez consulter [Exemples de stratégies basées sur l’identité pour Amazon DynamoDB](security_iam_id-based-policy-examples.md).
## Listes de contrôle d'accès (ACLs) dans DynamoDB
**Supports ACLs :** Non
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
## Contrôle d’accès par attributs (ABAC) avec DynamoDB
**Prise en charge d’ABAC (balises dans les politiques) :** Oui
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs appelés balises. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation des informations d’identification temporaires avec DynamoDB
**Prend en charge les informations d’identification temporaires :** oui
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Autorisations principales entre services pour DynamoDB
**Prend en charge les sessions d’accès direct (FAS) :** oui
Les sessions d'accès direct (FAS) utilisent les autorisations du principal appelant et Service AWS, combinées Service AWS à la demande d'envoi de demandes aux services en aval. Pour plus de détails sur la politique relative à la transmission de demandes FAS, consultez la section [Sessions de transmission d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Fonctions de service pour DynamoDB
**Prend en charge les rôles de service :** oui
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
**Avertissement**
La modification des autorisations d’une fonction du service peut altérer la fonctionnalité de DynamoDB. Ne modifiez des fonctions du service que quand DynamoDB vous le conseille.
## Rôles liés à un service pour DynamoDB
**Prend en charge les rôles liés à un service :** oui
Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés au service apparaissent dans votre Compte AWS fichier et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Pour plus d’informations sur la création ou la gestion des rôles liés à un service, consultez [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Recherchez un service dans le tableau qui inclut un `Yes` dans la colonne **Rôle lié à un service**. Choisissez le lien **Oui** pour consulter la documentation du rôle lié à ce service.
### Rôles liés au service pris en charge dans DynamoDB
Les rôles liés au service suivants sont pris en charge dans DynamoDB.
+ DynamoDB utilise le **AWSServiceRoleForDynamoDBReplication**rôle lié à un service pour la réplication des tables globales entre elles. Régions AWS Consultez [Sécurité des tables globales DynamoDB](globaltables-security.md) pour plus d'informations sur le rôle **AWSServiceRoleForDynamoDBReplication**lié à un service.
+ DynamoDB Accelerator (DAX) utilise le ** AWSServiceRoleForrôle DAX lié à un service pour configurer et gérer un cluster** DAX. [Utilisation des rôles IAM liés à un service pour DAX](using-service-linked-roles.md)Pour plus d'informations sur le rôle lié au service **AWSServiceRoleForDAX**, reportez-vous à la section.
Outre ces rôles liés au service DynamoDB, DynamoDB utilise le service Application Auto Scaling pour gérer automatiquement les paramètres de débit sur les tables avec mode de capacité provisionné. Le service Application Auto Scaling utilise le rôle lié au service ** AWSServiceRoleForApplicationAutoScaling\$1DynamoDBTable**pour gérer les paramètres de débit sur les tables DynamoDB pour lesquelles le dimensionnement automatique est activé. Pour plus d’informations, consultez [Rôles liés à un service pour Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html).
# Exemples de stratégies basées sur l’identité pour Amazon DynamoDB
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou modifier les ressources DynamoDB. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
*Pour en savoir plus sur les actions et les types de ressources définis par DynamoDB, y compris le format de ARNs chaque type de ressource, [consultez la section Actions, ressources et clés de condition pour Amazon DynamoDB dans la référence d'autorisation de service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html).*
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console DynamoDB](#security_iam_id-based-policy-examples-console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Utilisation des politiques basées sur une identité avec Amazon DynamoDB](using-identity-based-policies.md)
## Bonnes pratiques en matière de politiques
Les stratégies basées sur l’identité déterminent si une personne peut créer, consulter ou supprimer des ressources DynamoDB dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation de la console DynamoDB
Pour accéder à la console Amazon DynamoDB, vous devez disposer d’un ensemble minimum d’autorisations. Ces autorisations doivent vous permettre de répertorier et d'afficher les détails relatifs aux ressources DynamoDB de votre. Compte AWS Si vous créez une politique basée sur l’identité qui est plus restrictive que l’ensemble minimum d’autorisations requis, la console ne fonctionnera pas comme prévu pour les entités (utilisateurs ou rôles) tributaires de cette politique.
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API qu’ils tentent d’effectuer.
Pour garantir que les utilisateurs et les rôles peuvent toujours utiliser la console DynamoDB, associez également DynamoDB ou la politique gérée aux `ConsoleAccess` entités `ReadOnly` AWS . Pour plus d’informations, consultez [Ajout d’autorisations à un utilisateur](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) dans le *Guide de l’utilisateur IAM*.
## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Utilisation des politiques basées sur une identité avec Amazon DynamoDB
Cette rubrique traite de l'utilisation des politiques basées sur l'identité Gestion des identités et des accès AWS (IAM) avec Amazon DynamoDB et fournit des exemples. Les exemples montrent comment un administrateur de comptes peut attacher des politiques d’autorisations à des identités IAM (utilisateurs, groupes et rôles), et ainsi accorder des autorisations d’effectuer des opérations sur des ressources Amazon DynamoDB.
Les sections de cette rubrique couvrent les sujets suivants :
+ [Autorisations IAM requises pour utiliser la console Amazon DynamoDB](#console-permissions)
+ [AWS politiques IAM gérées (prédéfinies) pour Amazon DynamoDB](#access-policy-examples-aws-managed)
+ [Exemples de politiques gérées par le client](#access-policy-examples-for-sdk-cli)
Un exemple de politique d’autorisation est exposé ci-dessous.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DescribeQueryScanBooksTable",
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource": "arn:aws:dynamodb:us-west-2:111122223333:table/Books"
}
]
}
```
------
La politique précédente comporte une déclaration qui accorde des autorisations pour trois actions DynamoDB `dynamodb:DescribeTable` (`dynamodb:Query`,, `dynamodb:Scan` et) sur une table de `us-west-2` AWS la région, qui appartient au compte spécifié par AWS . `account-id` L’*Amazon Resource Name (ARN)* dans la valeur `Resource` spécifie la table à laquelle les autorisations s’appliquent.
## Autorisations IAM requises pour utiliser la console Amazon DynamoDB
Pour utiliser la console DynamoDB, un utilisateur doit disposer d'un ensemble minimal d'autorisations lui permettant d'utiliser les ressources DynamoDB de son AWS compte. Outre ces autorisations DynamoDB, la console nécessite d’autres autorisations :
+ CloudWatch Autorisations Amazon pour afficher les statistiques et les graphiques.
+ AWS Data Pipeline autorisations d'exportation et d'importation de données DynamoDB.
+ Gestion des identités et des accès AWS autorisations d'accès aux rôles nécessaires pour les exportations et les importations.
+ Amazon Simple Notification Service est autorisé à vous avertir chaque fois qu'une CloudWatch alarme est déclenchée.
+ AWS Lambda autorisations pour traiter les enregistrements DynamoDB Streams.
Si vous créez une politique IAM plus restrictive que les autorisations minimales requises, la console ne fonctionnera pas comme prévu pour les utilisateurs dotés de cette politique IAM. Pour garantir que ces utilisateurs peuvent toujours utiliser la console DynamoDB, associez également la politique gérée à `AmazonDynamoDBReadOnlyAccess` AWS l'utilisateur, comme décrit dans. [AWS politiques IAM gérées (prédéfinies) pour Amazon DynamoDB](#access-policy-examples-aws-managed)
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l'API Amazon DynamoDB.
**Note**
Si vous faites référence à un point de terminaison VPC, vous devez également autoriser l'appel d' DescribeEndpoints API pour le ou les principaux IAM demandeurs avec l'action IAM (dynamodb :). DescribeEndpoints Pour de plus amples informations, veuillez consulter [Politique requise pour les points de terminaison](inter-network-traffic-privacy.md#inter-network-traffic-DescribeEndpoints).
## AWS politiques IAM gérées (prédéfinies) pour Amazon DynamoDB
AWS répond à certains cas d'utilisation courants en fournissant des politiques IAM autonomes créées et administrées par. AWS Ces politiques AWS gérées accordent les autorisations nécessaires pour les cas d'utilisation courants afin que vous puissiez éviter d'avoir à rechercher les autorisations nécessaires. Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
Les politiques AWS gérées suivantes, que vous pouvez associer aux utilisateurs de votre compte, sont spécifiques à DynamoDB et sont regroupées par scénario d'utilisation :
+ **AmazonDynamoDBReadOnlyAccess**— Accorde un accès en lecture seule aux ressources DynamoDB via le. AWS Management Console
+ **AmazonDynamoDBFullAccès** : accorde un accès complet aux ressources DynamoDB par le biais du. AWS Management Console
Vous pouvez consulter ces politiques d'autorisations AWS gérées en vous connectant à la console IAM et en y recherchant des politiques spécifiques.
**Important**
La bonne pratique consiste à créer des politiques IAM personnalisées qui accordent le [moindre privilège](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) aux utilisateurs, rôles ou groupes IAM qui en ont besoin.
## Exemples de politiques gérées par le client
Cette section contient des exemples de politiques qui accordent des autorisations pour diverses actions DynamoDB. Ces politiques fonctionnent lorsque vous utilisez AWS SDKs ou le AWS CLI. Lorsque vous utilisez la console, vous devez accorder des autorisations supplémentaires spécifiques de la console. Pour de plus amples informations, veuillez consulter [Autorisations IAM requises pour utiliser la console Amazon DynamoDB](#console-permissions).
**Note**
Tous les exemples de politique suivants utilisent l'une des AWS régions et contiennent des noms de comptes IDs et de tables fictifs.
Exemples :
+ [Politique IAM pour accorder des autorisations à toutes les actions DynamoDB sur une table](grant-permissions-to-any-action-on-table.md)
+ [Politique IAM pour accorder des autorisations en lecture seule sur des éléments dans une table DynamoDB](read-only-permissions-on-table-items.md)
+ [Politique IAM pour accorder l’accès à une table DynamoDB spécifique et à ses index](iam-policy-specific-table-indexes.md)
+ [Politique IAM pour lire, écrire, mettre à jour et supprimer l’accès sur une table DynamoDB](iam-policy-example-data-crud.md)
+ [Politique IAM pour séparer les environnements DynamoDB dans le même compte AWS](iam-policy-separate-environments.md)
+ [Politique IAM pour empêcher l’achat de capacité réservée DynamoDB](iam-prevent-purchase-reserved-capacity.md)
+ [Politique IAM pour accorder un accès en lecture pour un flux DynamoDB uniquement (pas pour la table)](iam-policy-read-stream-only.md)
+ [Politique IAM permettant à une AWS Lambda fonction d'accéder aux enregistrements de flux DynamoDB](iam-policy-example-lamda-process-dynamodb-streams.md)
+ [Politique IAM pour l’accès en lecture et écriture à un cluster DynamoDB Accelerator (DAX)](iam-policy-example-read-write-dax-access.md)
Le *Guide de l’utilisateur IAM* inclut [trois exemples DynamoDB supplémentaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html) :
+ [Amazon DynamoDB : autorise l’accès à une table spécifique](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_specific-table.html)
+ [Amazon DynamoDB : autorise l’accès à des colonnes spécifiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_columns.html)
+ [Amazon DynamoDB : autorise l’accès de niveau ligne à DynamoDB en fonction de l’ID Amazon Cognito](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_rows.html)
# Politique IAM pour accorder des autorisations à toutes les actions DynamoDB sur une table
La politique suivante accorde des autorisations pour *toutes* les actions DynamoDB sur une table nommée `Books`. L'ARN de ressource spécifié dans le `Resource` identifie une table dans une AWS région spécifique. Si vous remplacez le nom de table `Books` dans l’ARN `Resource` par un caractère générique (\$1), *toutes* les actions DynamoDB sont autorisées sur *toutes* les tables du compte. Considérez attentivement les implications possibles en matière de sécurité avant d’utiliser un caractère générique sur cette politique ou toute politique IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllAPIActionsOnBooks",
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
**Note**
Voici un exemple d’utilisation d’un caractère générique (\$1) pour autoriser *toutes* les actions, y compris l’administration, les opérations de données, la surveillance et l’achat de capacité réservée DynamoDB. Au lieu de cela, une bonne pratique consiste à spécifier explicitement chaque action à autoriser, et uniquement ce dont cet utilisateur, ce rôle ou ce groupe ont besoin.
# Politique IAM pour accorder des autorisations en lecture seule sur des éléments dans une table DynamoDB
La politique d’autorisations suivante accorde des autorisations pour les actions DynamoDB `GetItem`, `BatchGetItem`, `Scan`, `Query` et `ConditionCheckItem` uniquement, et définit ainsi un accès en lecture seule sur la table `Books`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyAPIActionsOnBooks",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:ConditionCheckItem"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
]
}
```
------
# Politique IAM pour accorder l’accès à une table DynamoDB spécifique et à ses index
La politique suivante accorde des autorisations pour effectuer des actions de modification de données sur une table DynamoDB appelée `Books` et tous ses index. Pour plus d’informations sur le fonctionnement des index, consultez [Amélioration de l’accès aux données avec les index secondaires dans DynamoDB](SecondaryIndexes.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessTableAllIndexesOnBooks",
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem",
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:ConditionCheckItem"
],
"Resource": [
"arn:aws:dynamodb:us-west-2:123456789012:table/Books",
"arn:aws:dynamodb:us-west-2:123456789012:table/Books/index/*"
]
}
]
}
```
------
# Politique IAM pour lire, écrire, mettre à jour et supprimer l’accès sur une table DynamoDB
Utilisez cette politique si vous devez autoriser votre application à créer, lire, mettre à jour et supprimer des données dans des tables, index et flux Amazon DynamoDB. Remplacez le nom de la AWS région, votre identifiant de compte et le nom de la table ou le caractère générique (\$1) le cas échéant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DynamoDBIndexAndStreamAccess",
"Effect": "Allow",
"Action": [
"dynamodb:GetShardIterator",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:DescribeStream",
"dynamodb:GetRecords",
"dynamodb:ListStreams"
],
"Resource": [
"arn:aws:dynamodb:us-west-2:123456789012:table/Books/index/*",
"arn:aws:dynamodb:us-west-2:123456789012:table/Books/stream/*"
]
},
{
"Sid": "DynamoDBTableAccess",
"Effect": "Allow",
"Action": [
"dynamodb:BatchGetItem",
"dynamodb:BatchWriteItem",
"dynamodb:ConditionCheckItem",
"dynamodb:PutItem",
"dynamodb:DescribeTable",
"dynamodb:DeleteItem",
"dynamodb:GetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:UpdateItem"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
},
{
"Sid": "DynamoDBDescribeLimitsAccess",
"Effect": "Allow",
"Action": "dynamodb:DescribeLimits",
"Resource": [
"arn:aws:dynamodb:us-west-2:123456789012:table/Books",
"arn:aws:dynamodb:us-west-2:123456789012:table/Books/index/*"
]
}
]
}
```
------
Pour étendre cette politique à toutes les tables DynamoDB de AWS toutes les régions pour ce compte, utilisez un caractère générique (\$1) pour la région et le nom de la table. Par exemple :
```
"Resource":[
"arn:aws:dynamodb:*:123456789012:table/*",
"arn:aws:dynamodb:*:123456789012:table/*/index/*"
]
```
# Politique IAM pour séparer les environnements DynamoDB dans le même compte AWS
Supposons que vous ayez des environnements séparés gérant chacun sa propre version d’une table nommée `ProductCatalog`. Si vous créez deux `ProductCatalog` tables dans le même AWS compte, le travail dans un environnement peut affecter l'autre environnement en raison de la façon dont les autorisations sont configurées. Par exemple, les quotas relatifs au nombre d'opérations simultanées sur le plan de contrôle (telles que`CreateTable`) sont définis au niveau du AWS compte.
Par conséquent, chaque action effectuée dans un environnement réduit le nombre d’opérations disponibles dans l’autre. Il existe également un risque que le code d’un environnement puisse accéder accidentellement aux tables de l’autre.
**Note**
Si vous souhaitez séparer les charges de travail de test et de production afin de contrôler les répercussions potentielles d’un incident, une bonne pratique consiste à créer des comptes AWS distincts pour les charges de travail de test et de production. Pour plus d’informations, consultez [Gestion et séparation de comptes AWS](https://docs.aws.amazon.com//wellarchitected/latest/security-pillar/aws-account-management-and-separation.html).
Supposons également que vous ayez deux développeurs, Amit et Alice, qui testent la table `ProductCatalog`. Au lieu que chaque développeur ait besoin d'un AWS compte distinct, vos développeurs peuvent partager le même AWS compte de test. Dans ce compte de test, vous pouvez créer une copie de la même table pour que chaque développeur puisse y travailler, comme `Alice_ProductCatalog` et `Amit_ProductCatalog`. Dans ce cas, vous pouvez créer les utilisateurs Alice et Amit dans le AWS compte que vous avez créé pour l'environnement de test. Vous pouvez ensuite accorder à ces utilisateurs l’autorisation d’effectuer des actions DynamoDB sur les tables qu’ils possèdent.
Pour accorder ces autorisations utilisateur IAM, vous pouvez procéder de l’une des façons suivantes :
+ Créez une politique distincte pour chaque utilisateur, puis attachez chaque politique à son utilisateur séparément. Par exemple, vous pouvez attacher la politique suivante à l’utilisateur Alice pour l’autoriser à accéder à toutes les actions DynamoDB sur la table `Alice_ProductCatalog` :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllAPIActionsOnAliceTable",
"Effect": "Allow",
"Action": [
"dynamodb:DeleteItem",
"dynamodb:DescribeContributorInsights",
"dynamodb:RestoreTableToPointInTime",
"dynamodb:ListTagsOfResource",
"dynamodb:CreateTableReplica",
"dynamodb:UpdateContributorInsights",
"dynamodb:CreateBackup",
"dynamodb:DeleteTable",
"dynamodb:UpdateTableReplicaAutoScaling",
"dynamodb:UpdateContinuousBackups",
"dynamodb:TagResource",
"dynamodb:DescribeTable",
"dynamodb:GetItem",
"dynamodb:DescribeContinuousBackups",
"dynamodb:BatchGetItem",
"dynamodb:UpdateTimeToLive",
"dynamodb:BatchWriteItem",
"dynamodb:ConditionCheckItem",
"dynamodb:UntagResource",
"dynamodb:PutItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:UpdateItem",
"dynamodb:DeleteTableReplica",
"dynamodb:DescribeTimeToLive",
"dynamodb:RestoreTableFromBackup",
"dynamodb:UpdateTable",
"dynamodb:DescribeTableReplicaAutoScaling",
"dynamodb:GetShardIterator",
"dynamodb:DescribeStream",
"dynamodb:GetRecords",
"dynamodb:DescribeLimits",
"dynamodb:ListStreams"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Alice_ProductCatalog/*"
}
]
}
```
------
Ensuite, vous pouvez créer une politique similaire avec une autre ressource (table `Amit_ProductCatalog`) pour l’utilisateur Amit.
+ Au lieu d’attacher les politiques à des utilisateurs individuels, vous pouvez utiliser les variables des politiques IAM pour écrire une seule politique et l’attacher à un groupe. Vous devez créer un groupe et, pour cet exemple, y ajouter les utilisateurs Alice et Amit. L’exemple suivant accorde des autorisations pour exécuter toutes les actions DynamoDB sur la table `${aws:username}_ProductCatalog`. La variable de politique `${aws:username}` est remplacée par le nom utilisateur du demandeur lors de l’évaluation de la politique. Par exemple, si Alice envoie une demande pour ajouter un élément, l’action est autorisée uniquement si Alice ajoute les éléments à la table `Alice_ProductCatalog`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ActionsOnUserSpecificTable",
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem",
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Scan",
"dynamodb:Query",
"dynamodb:ConditionCheckItem"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_ProductCatalog"
},
{
"Sid": "AdditionalPrivileges",
"Effect": "Allow",
"Action": [
"dynamodb:ListTables",
"dynamodb:DescribeTable",
"dynamodb:DescribeContributorInsights"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/*"
}
]
}
```
------
**Note**
Lorsque vous utilisez des variables de politique IAM, vous devez spécifier explicitement la version `2012-10-17` du langage de politique IAM dans la politique. La version par défaut du langage de politique IAM (`2008-10-17`) ne prend pas en charge les variables de politique.
Au lieu d’identifier une table spécifique en tant que ressource comme vous le feriez normalement, vous pouvez utiliser un caractère générique (\$1) pour accorder des autorisations sur toutes les tables dont le nom est préfixé avec le nom de l’utilisateur qui effectue la demande, comme illustré dans l’exemple suivant.
```
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/${aws:username}_*"
```
# Politique IAM pour empêcher l’achat de capacité réservée DynamoDB
Avec une capacité réservée Amazon DynamoDB, vous payez un droit initial unique, et vous engagez à payer pour un niveau d’utilisation minimal, avec à la clé la réalisation d’économies considérables au fil du temps. Vous pouvez utiliser le AWS Management Console pour consulter et acheter la capacité réservée. Cependant, il se peut que vous ne souhaitiez pas que tous les utilisateurs au sein de votre organisation puissent acheter de la capacité réservée. Pour plus d’informations sur la capacité réservée, consultez [Tarification Amazon DynamoDB](https://aws.amazon.com/dynamodb/pricing).
DynamoDB fournit les opérations d’API suivantes pour contrôler l’accès à la gestion de la capacité réservée :
+ `dynamodb:DescribeReservedCapacity` – Renvoie les achats de capacité réservée qui sont actuellement en vigueur.
+ `dynamodb:DescribeReservedCapacityOfferings` – Renvoie des détails sur les plans de capacité réservée actuellement proposés par AWS.
+ `dynamodb:PurchaseReservedCapacityOfferings` – Effectue un achat réel de capacité réservée.
Il AWS Management Console utilise ces actions d'API pour afficher les informations sur les capacités réservées et effectuer des achats. Vous ne pouvez pas appeler ces opérations à partir d’un programme d’application, car elles ne sont accessibles qu’à partir de la console. Cependant, vous pouvez autoriser ou rejeter l’accès à ces opérations dans une politique d’autorisations IAM.
La politique suivante permet aux utilisateurs de consulter les achats et les offres de capacité réservée en utilisant le AWS Management Console , mais les nouveaux achats sont refusés.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReservedCapacityDescriptions",
"Effect": "Allow",
"Action": [
"dynamodb:DescribeReservedCapacity",
"dynamodb:DescribeReservedCapacityOfferings"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:*"
},
{
"Sid": "DenyReservedCapacityPurchases",
"Effect": "Deny",
"Action": "dynamodb:PurchaseReservedCapacityOfferings",
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:*"
}
]
}
```
------
Notez que cette politique utilise le caractère générique (\$1) pour décrire les autorisations pour tous, et pour rejeter l'achat de capacité réservée DynamoDB pour tous.
# Politique IAM pour accorder un accès en lecture pour un flux DynamoDB uniquement (pas pour la table)
Lorsque vous activez DynamoDB Streams sur une table, des informations sont capturées sur chaque modification apportée à des éléments dans celle-ci. Pour de plus amples informations, veuillez consulter [Modifier la récupération de données pour DynamoDB Streams](Streams.md).
Dans certains cas, vous pouvez être amené à empêcher une application de lire les données d’une table DynamoDB, tout en autorisant l’accès aux flux de celle-ci. Par exemple, vous pouvez configurer AWS Lambda pour interroger un flux et appeler une fonction Lambda lorsque des mises à jour d'éléments sont détectées, puis effectuer un traitement supplémentaire.
Les actions suivantes sont disponibles pour contrôler l’accès à DynamoDB Streams :
+ `dynamodb:DescribeStream`
+ `dynamodb:GetRecords`
+ `dynamodb:GetShardIterator`
+ `dynamodb:ListStreams`
L’exemple de politique suivant accorde aux utilisateurs des autorisations d’accès aux flux d’une table nommée `GameScores`. Le caractère générique final (\$1) dans l’ARN correspond à tout flux associé à la table.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessGameScoresStreamOnly",
"Effect": "Allow",
"Action": [
"dynamodb:DescribeStream",
"dynamodb:GetRecords",
"dynamodb:GetShardIterator",
"dynamodb:ListStreams"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/stream/*"
}
]
}
```
------
Notez que cette politique donne accès aux flux de la table `GameScores`, mais pas à la table proprement dite.
# Politique IAM permettant à une AWS Lambda fonction d'accéder aux enregistrements de flux DynamoDB
Si vous souhaitez que certaines actions soient effectuées en fonction des événements d'un flux DynamoDB, vous pouvez écrire AWS Lambda une fonction déclenchée par ces événements. Une fonction Lambda telle que celle-ci a besoin d’autorisations pour lire les données d’un flux DynamoDB. Pour plus d’informations sur l’utilisation de Lambda avec DynamoDB Streams, consultez [Streams et déclencheurs DynamoDB AWS Lambda](Streams.Lambda.md).
Pour accorder des autorisations à Lambda, utilisez la politique d’autorisations associée au rôle IAM de la fonction Lambda (également appelée rôle d’exécution). Spécifiez cette politique lorsque vous créez la fonction Lambda.
Par exemple, vous pouvez associer la politique d’autorisations et le rôle d’exécution suivants pour accorder les autorisations Lambda nécessaires pour exécuter les actions DynamoDB Streams répertoriées.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "APIAccessForDynamoDBStreams",
"Effect": "Allow",
"Action": [
"dynamodb:GetRecords",
"dynamodb:GetShardIterator",
"dynamodb:DescribeStream",
"dynamodb:ListStreams"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/stream/*"
}
]
}
```
------
Pour plus d’informations, consultez [Autorisations AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html) dans le *Manuel du développeur AWS Lambda *.
# Politique IAM pour l’accès en lecture et écriture à un cluster DynamoDB Accelerator (DAX)
La politique suivante autorise l’accès en lecture, en écriture, en mise à jour et en suppression à un cluster DynamoDB Accelerator (DAX), mais pas à la table DynamoDB associée. Pour utiliser cette politique, remplacez le nom de la AWS région, votre identifiant de compte et le nom de votre cluster DAX.
**Note**
Cette politique permet d’accéder au cluster DAX, mais pas à la table DynamoDB associée. Assurez-vous que votre cluster DAX dispose de la politique appropriée pour effectuer ces mêmes opérations sur la table DynamoDB en votre nom.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonDynamoDBDAXDataOperations",
"Effect": "Allow",
"Action": [
"dax:GetItem",
"dax:PutItem",
"dax:ConditionCheckItem",
"dax:BatchGetItem",
"dax:BatchWriteItem",
"dax:DeleteItem",
"dax:Query",
"dax:UpdateItem",
"dax:Scan"
],
"Resource": "arn:aws:dax:eu-west-1:123456789012:cache/MyDAXCluster"
}
]
}
```
------
Pour étendre cette politique afin de couvrir l'accès au DAX pour toutes les AWS régions pour un compte, utilisez un caractère générique (\$1) pour le nom de la région.
```
"Resource": "arn:aws:dax:*:123456789012:cache/MyDAXCluster"
```
# Résolution de problèmes pour l’identité et l’accès Amazon DynamoDB
Utilisez les informations suivantes pour identifier et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec DynamoDB et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans DynamoDB](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite autoriser des personnes extérieures à moi Compte AWS à accéder à mes ressources DynamoDB](#security_iam_troubleshoot-cross-account-access)
## Je ne suis pas autorisé à effectuer une action dans DynamoDB
S'il vous AWS Management Console indique que vous n'êtes pas autorisé à effectuer une action, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni votre nom d’utilisateur et votre mot de passe.
L’exemple d’erreur suivant se produit quand l’utilisateur `mateojackson` tente d’utiliser la console pour afficher des informations détaillées sur une ressource `my-example-widget` fictive, mais ne dispose pas des autorisations `aws:GetWidget` fictives.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: aws:GetWidget on resource: my-example-widget
```
Dans ce cas, Mateo demande à son administrateur de mettre à jour ses politiques pour lui permettre d’accéder à la ressource `my-example-widget` à l’aide de l’action `aws:GetWidget`.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez une erreur selon laquelle vous n’êtes pas autorisé à exécuter l’action, vos stratégies doivent être mises à jour afin de vous permettre de transmettre un rôle à DynamoDB.
Certains vous Services AWS permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.
L’exemple d’erreur suivant se produit lorsqu’un utilisateur IAM nommé `marymajor` essaie d’utiliser la console pour exécuter une action dans DynamoDB. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je souhaite autoriser des personnes extérieures à moi Compte AWS à accéder à mes ressources DynamoDB
Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.
Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si DynamoDB prend en charge ces fonctionnalités, consultez [Fonctionnement d’Amazon DynamoDB avec IAM](security_iam_service-with-iam.md).
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
# Politique IAM pour empêcher l’achat de capacité réservée DynamoDB
Avec une capacité réservée Amazon DynamoDB, vous payez un droit initial unique, et vous engagez à payer pour un niveau d’utilisation minimal, avec à la clé la réalisation d’économies considérables au fil du temps. Vous pouvez utiliser le AWS Management Console pour consulter et acheter la capacité réservée. Cependant, il se peut que vous ne souhaitiez pas que tous les utilisateurs au sein de votre organisation puissent acheter de la capacité réservée. Pour plus d’informations sur la capacité réservée, consultez [Tarification Amazon DynamoDB](https://aws.amazon.com/dynamodb/pricing).
DynamoDB fournit les opérations d’API suivantes pour contrôler l’accès à la gestion de la capacité réservée :
+ `dynamodb:DescribeReservedCapacity` – Renvoie les achats de capacité réservée qui sont actuellement en vigueur.
+ `dynamodb:DescribeReservedCapacityOfferings` – Renvoie des détails sur les plans de capacité réservée actuellement proposés par AWS.
+ `dynamodb:PurchaseReservedCapacityOfferings` – Effectue un achat réel de capacité réservée.
Il AWS Management Console utilise ces actions d'API pour afficher les informations sur les capacités réservées et effectuer des achats. Vous ne pouvez pas appeler ces opérations à partir d’un programme d’application, car elles ne sont accessibles qu’à partir de la console. Cependant, vous pouvez autoriser ou rejeter l’accès à ces opérations dans une politique d’autorisations IAM.
La politique suivante permet aux utilisateurs de consulter les achats et les offres de capacité réservée en utilisant le AWS Management Console , mais les nouveaux achats sont refusés.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReservedCapacityDescriptions",
"Effect": "Allow",
"Action": [
"dynamodb:DescribeReservedCapacity",
"dynamodb:DescribeReservedCapacityOfferings"
],
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:*"
},
{
"Sid": "DenyReservedCapacityPurchases",
"Effect": "Deny",
"Action": "dynamodb:PurchaseReservedCapacityOfferings",
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:*"
}
]
}
```
------
Notez que cette politique utilise le caractère générique (\$1) pour décrire les autorisations pour tous, et pour rejeter l’achat de capacité réservée DynamoDB pour tous.
# Utilisation de conditions de politique IAM 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 de
Dans DynamoDB, vous avez la possibilité de spécifier des conditions lorsque vous accordez des autorisations à l’aide d’une politique IAM (voir [Gestion des identités et des accès pour Amazon DynamoDB](security-iam.md)). Par exemple, vous pouvez effectuer les actions suivantes :
+ 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 des conditions dans une politique IAM à l’aide de clés de condition, comme illustré dans le cas d’utilisation de la section suivante.
### Cas d’utilisation des autorisations
Outre le contrôle de l’accès aux actions d’API DynamoDB, vous pouvez contrôler l’accès à des éléments et attributs de données 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 :
![\[Cas d’utilisation qui accorde un accès au niveau de la table à un utilisateur, mais restreint l’accès à des éléments de données spécifiques.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/info-hiding-horizontal.png)
+ 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 :
![\[Cas d’utilisation qui affiche uniquement un sous-ensemble de données aux utilisateurs, mais masque certains attributs des données.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/info-hiding-vertical.png)
Pour mettre en place ce genre de contrôle précis des accès, vous écrivez une politique d’autorisations IAM qui spécifie les conditions d’accès aux informations d’identification de sécurité et aux autorisations associées. Vous appliquez la stratégie aux utilisateurs, groupes ou rôles que vous créez à l’aide de la console IAM. Votre politique IAM peut restreindre l’accès à des éléments individuels d’une table, aux attributs dans ces éléments, ou aux 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](WIF.md).
Vous utilisez l’élément IAM `Condition` pour mettre en place une politique de contrôle d’accès détaillée. 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.
La vidéo ci-dessous explique le contrôle des accès précis dans DynamoDB à l’aide des conditions de politique IAM.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/LbEmo_yulb0?si=VTSlNHVocAEYwhJi)
## Comprendre le contrôle d'accès détaillé dans DynamoDB
Le contrôle d'accès détaillé dans DynamoDB vous permet de créer des limites d'autorisations précises à plusieurs niveaux :
1. **Contrôle d'accès au niveau des éléments :** limitez les utilisateurs à accéder uniquement aux éléments contenant des valeurs clés spécifiques, correspondant généralement à leur identité ou à l'étendue de leurs autorisations.
1. **Contrôle d'accès au niveau des attributs :** limitez les attributs (colonnes) que les utilisateurs peuvent afficher ou modifier, ce qui vous permet de protéger les informations sensibles tout en autorisant l'accès aux données non sensibles au sein des mêmes éléments.
1. **Contrôles spécifiques à l'opération :** appliquez différentes règles d'autorisation en fonction du type d'opération effectuée.
Ces contrôles sont mis en œuvre par le biais de politiques IAM à l'aide de clés de condition spécifiques à DynamoDB.
## 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 qui prennent en charge le contrôle d'accès IAM. 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 », consultez la AWS section [Clés disponibles pour les conditions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) dans le guide de l'utilisateur IAM.
Les clés de condition spécifiques au service DynamoDB qui s'appliquent à DynamoDB sont les suivantes.
**`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. `Select` peut avoir l’une des valeurs suivantes :
+ `ALL_ATTRIBUTES`
+ `ALL_PROJECTED_ATTRIBUTES`
+ `SPECIFIC_ATTRIBUTES`
+ `COUNT`
Bien qu'elle soit souvent associée aux opérations de requête et de numérisation, cette clé de condition s'applique à toutes les opérations DynamoDB qui renvoient des attributs d'élément et est essentielle pour contrôler l'accès aux attributs dans toutes les actions d'API. L'utilisation de contraintes StringEqualsIfExists ou similaires sur cette clé de condition appliquera des contraintes sur les opérations où cette clé de condition s'applique, tout en l'ignorant sur les opérations où elle ne s'applique pas.
**`dynamodb:Attributes`**
Représente une liste des attributs *de niveau supérieur* auxquels une demande accède. Une demande accède à un attribut de niveau supérieur si celui-ci, ou tout attribut imbriqué qu'il contient, est spécifié dans les paramètres de la demande. Par exemple, dans le `GetItem` cas d'une demande spécifiant un `ProjectionExpression` de`"Name, Address.City"`, la `dynamodb:Attributes` liste inclurait « Nom » et « Adresse ». Si le `Attributes` paramètre est énuméré dans une politique de contrôle d'accès précise, envisagez également de le restreindre `ReturnValues` et de définir des `Select` paramètres afin de garantir un accès restreint aux attributs spécifiés dans le cadre de plusieurs actions d'API telles que `GetItem``Query`, et. `Scan`
Cette condition est évaluée uniquement sur les attributs spécifiés dans la demande (comme dans a ProjectionExpression), et non sur les attributs de la réponse. Si non ProjectionExpression est fourni dans la demande, tous les attributs seront renvoyés, quelles que soient les restrictions d'attributs prévues dans la politique. Consultez la section « S'assurer que les restrictions basées sur les attributs sont appliquées » ci-dessous pour plus de détails sur la manière de sécuriser correctement l'accès aux attributs.
**`dynamodb:ReturnValues`**
Représente le `ReturnValues` paramètre d'une demande. Selon l'action de l'API, il `ReturnValues` peut s'agir de 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`
**`dynamodb:FirstPartitionKeyValues`**
Représente le premier attribut clé d'une table, en d'autres termes, la première clé de partition. Le nom de la clé `FirstPartitionKeyValues` est pluriel, même si la clé est utilisée avec des actions à élément unique. En outre, vous devez utiliser le `ForAllValues` modificateur lorsque vous l'utilisez `FirstPartitionKeyValues` dans une condition. `FirstPartitionKeyValues`et `LeadingKeys` peut être utilisé comme échangeable.
**`dynamodb:SecondPartitionKeyValues`**
Similaire à `dynamodb:FirstPartitionKeyValues`. Représente la deuxième clé de partition des ressources. Le nom de la clé `SecondPartitionKeyValues` est pluriel, même si la clé est utilisée avec des actions à élément unique.
**`dynamodb:ThirdPartitionKeyValues`**
Similaire à `dynamodb:FirstPartitionKeyValues`. Représente la troisième clé de partition des ressources. Le nom de la clé `ThirdPartitionKeyValues` est pluriel, même si la clé est utilisée avec des actions à élément unique.
**`dynamodb:FourthPartitionKeyValues`**
Similaire à `dynamodb:FirstPartitionKeyValues`. Représente la quatrième clé de partition des ressources. Le nom de la clé `FourthPartitionKeyValues` est pluriel, même si la clé est utilisée avec des actions à élément unique.
### Veiller à ce que les restrictions basées sur les attributs soient appliquées
Lorsque vous utilisez des conditions basées sur les attributs pour restreindre l'accès à des attributs spécifiques, il est important de comprendre comment ces conditions sont évaluées :
+ **Les conditions d'attribut sont évaluées uniquement sur les attributs spécifiés dans la demande**, et non sur les attributs de la réponse.
+ **Pour les opérations de lecture sans ProjectionExpression** (GetItem, Query, Scan, etc.), tous les attributs seront renvoyés quelles que soient les restrictions d'attributs de votre politique. Pour éviter cette exposition potentielle de données sensibles, implémentez à la fois des conditions d'attribut (`dynamodb:Attributes`) et une condition nécessitant des attributs spécifiques doit être demandée (`dynamodb:Select`).
+ **Pour les opérations d'écriture** (PutItem, UpdateItem, DeleteItem), le ReturnValues paramètre peut renvoyer des éléments complets, exposant potentiellement des attributs restreints même si l'opération d'écriture elle-même est conforme à votre politique. Pour éviter cette exposition, implémentez à la fois des conditions d'attribut (`dynamodb:Attributes`) et des restrictions sur ReturnValues (`dynamodb:ReturnValues`) dans votre politique.
### Limitation de l’accès utilisateur
La plupart des politiques d’autorisation IAM permettent aux utilisateurs d’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 substitution IAM `${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](WIF.md).
**Important**
Le contrôle d’accès précis n’est pas pris en charge pour restreindre la réplication des tables globales. L’application de conditions de politique pour un contrôle d’accès précis aux [principaux de service DynamoDB ou aux rôles liés à un service](globaltables-security.md) utilisés pour la réplication de tables globales peut interrompre la réplication au sein d’une table globale.
**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 est autorisé uniquement à ce qui est explicitement indiqué dans la politique IAM.
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, de futures modifications de l’API DynamoDB (ou des modifications apportées à des entrées d’API existantes) peuvent rendre une politique basée sur un rejet inefficace.
### 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
#### Exemple 1. Contrôle d'accès de base basé sur des clés de partition avec restrictions d'attributs
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 DynamoDB `GameScores` nommée pour suivre les meilleurs scores et les 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 une partie doit appartenir à un rôle IAM 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 :
------
#### [ JSON ]
****
```
{
"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](WIF.md).
+ `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.
Quand une politique IAM est évaluée, le résultat est toujours true (accès autorisé) ou false (accès 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.
Les documents de la politique IAM peuvent contenir uniquement les caractères Unicode suivants : tabulation horizontale (U\$10009), saut de ligne (U\$1000A), retour chariot (U\$1000D) et caractères de la plage U\$10020 à U\$100FF.
#### Exemple 2 : accorder des autorisations qui limitent l'accès aux éléments ayant 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.
------
#### [ JSON ]
****
```
{
"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 stratégie, vous devez spécifier explicitement la version 2012-10-17 dans la politique. La version par défaut du langage d'access policy, 2008-10-17, ne prend pas en charge les variables de stratégie.
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.
------
#### [ JSON ]
****
```
{
"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.
#### Exemple 3 : accorder des autorisations qui limitent l'accès à des 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.
------
#### [ JSON ]
****
```
{
"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 le nom de ces attributs refusés en suivant le principe du moindre privilège, comme expliqué dans Wikipedia à l'adresse http://en.wikipedia. org/wiki/Principle\$1of\$1least\$1privilege, et utilisez une approche de liste d'autorisation pour énumérer toutes les valeurs autorisées, plutôt que de spécifier les attributs refusé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’action d’API de retourner les attributs qui ne sont pas autorisés, par exemple à partir 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 (\$1).
#### Exemple 4 : accorder des autorisations pour empêcher la mise à 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`.
------
#### [ JSON ]
****
```
{
"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"
]
},
"StringEqualsIfExists":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES",
"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`.
+ L'`StringEqualsIfExists`opérateur s'assure que si la demande `dynamodb:ReturnValues` est présente `dynamodb:Select` ou est présente, elle doit correspondre aux valeurs spécifiées. Cela empêche les opérations de renvoyer des articles complets.
+ Lorsque vous limitez les mises à jour d'attributs, vous devez également contrôler les données qui peuvent être renvoyées afin d'empêcher la divulgation d'informations sur les attributs protégés.
+ 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-ci APIs.
#### Exemple 5 : accorder des autorisations pour interroger uniquement les attributs projetés dans 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`.
------
#### [ JSON ]
****
```
{
"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.
------
#### [ JSON ]
****
```
{
"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"
}
}
}
]
}
```
------
#### Exemple 6 : accorder des autorisations pour 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 `dynamodb:LeadingKeys` condition pour restreindre les autorisations aux seuls éléments dont la valeur de clé de partition correspond à l'identifiant Facebook de l'utilisateur.
------
#### [ JSON ]
****
```
{
"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`) ne peuvent modifier que l'attribut-A ou l'attribut-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.
#### Exemple 7 : Refuser les autorisations pour limiter l'accès à des attributs spécifiques d'une table
La politique suivante refuse l'accès aux attributs sensibles et garantit que cette restriction ne peut pas être contournée en omettant une expression de projection. Il permet un accès général à la `CustomerData` table tout en refusant explicitement l'accès aux `CreditCardNumber` attributs `SSN` et à ses attributs.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData"
},
{
"Effect":"Deny",
"Action":[
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData",
"Condition":{
"ForAnyValue:StringEquals":{
"dynamodb:Attributes":[
"SSN",
"CreditCardNumber"
]
}
}
},
{
"Effect":"Deny",
"Action":[
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData",
"Condition":{
"StringNotEqualsIfExists":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES"
}
}
}
]
}
```
------
## Rubriques en relation
+ [Gestion des identités et des accès pour Amazon DynamoDB](security-iam.md)
+ [Autorisations d’API DynamoDB : Référence des actions, ressources et conditions](api-permissions-reference.md)
# Utilisation de la fédération d’identité web
Si vous écrivez une application ciblée pour un grand nombre d’utilisateurs, vous pouvez, le cas échéant, utiliser la *fédération d’identité web* pour l’authentification et l’autorisation. La fédération d’identité web élimine le besoin de créer des utilisateurs individuels. Au lieu de cela, les utilisateurs peuvent se connecter à un fournisseur d'identité, puis obtenir des informations d'identification de sécurité temporaires auprès de AWS Security Token Service (AWS STS). L'application peut ensuite utiliser ces informations d'identification pour accéder aux AWS services.
La fédération d’identité Web prend en charge les fournisseurs d’identité suivants :
+ Login with Amazon
+ Facebook
+ Google
## Ressources supplémentaires pour la fédération d’identité web
Les ressources suivantes peuvent vous aider à en savoir plus sur la fédération d’identité web :
+ La publication [Web Identity Federation using the AWS SDK pour .NET](https://aws.amazon.com/blogs/developer/web-identity-federation-using-the-aws-sdk-for-net) sur le blog des développeurs AWS explique comment utiliser une fédération d’identité web avec Facebook. Il inclut des extraits de code en C\$1 qui montrent comment assumer un rôle IAM avec une identité Web et comment utiliser des informations d'identification de sécurité temporaires pour accéder à une ressource. AWS
+ L’[Applications mobiles AWS SDK for iOS](https://aws.amazon.com/sdkforios/) et l’[AWS Mobile SDK pour Android](https://aws.amazon.com/sdkforandroid/) contiennent des exemples d’applications. Ces dernières incluent le code qui montre comment appeler les fournisseurs d’identité et comment utiliser les informations qu’ils fournissent pour obtenir et utiliser les informations d’identification de sécurité temporaires.
+ L'article [Fédération d'identité Web avec applications mobiles](https://aws.amazon.com/articles/4617974389850313) traite de la fédération d'identité Web et montre un exemple d'utilisation de la fédération d'identité Web pour accéder à une AWS ressource.
## Exemple de politique pour la fédération d’identité web
Pour montrer comment utiliser la fédération d'identité Web avec DynamoDB, consultez *GameScores*le tableau introduit dans. [Utilisation de conditions de politique IAM pour un contrôle d’accès précis](specifying-conditions.md) Voici la clé primaire pour *GameScores*.
****
| Nom de la table | Type de clé primaire | Type et nom de la clé de partition | Type et nom de la clé de tri |
| --- | --- | --- | --- |
| GameScores (UserId, GameTitle, ...) | Composite | Nom de l'attribut : UserId Type : Chaîne | Nom de l'attribut : GameTitle Type : Chaîne |
Supposons maintenant qu’une application de jeu pour appareils mobiles utilise cette table et qu’elle doive prendre en charge des milliers, voire des millions, d’utilisateurs. À cette échelle, il devient très difficile de gérer les utilisateurs individuels des applications et de garantir que chaque utilisateur ne peut accéder qu'à ses propres données dans le *GameScores*tableau. Heureusement, comme la plupart des utilisateurs possèdent des comptes avec un fournisseur d’identité tiers, tel que Facebook, Google ou Login with Amazon. Il est donc logique de tirer parti de l’un de ces fournisseurs pour les tâches d’authentification.
Pour procéder ainsi avec la fédération d’identité web, le développeur d’application doit inscrire l’application auprès d’un fournisseur d’identité (Login with Amazon, par exemple) et obtenir un ID d’application unique. Ensuite, le développeur doit créer un rôle IAM. (Dans cet exemple, ce rôle est nommé *GameRole*.) Un document de politique IAM doit être joint au rôle, spécifiant les conditions dans lesquelles l'application peut accéder à la *GameScores*table.
Lorsqu’un utilisateur veut jouer à un jeu, il se connecte à son compte Login with Amazon depuis l’application de jeu. L'application appelle ensuite AWS Security Token Service (AWS STS), fournit l'identifiant de l'application Login with Amazon et demande d'adhésion *GameRole*. AWS STS renvoie des AWS informations d'identification temporaires à l'application et lui permet d'accéder au *GameScores*tableau, sous réserve du document *GameRole*de politique.
Le schéma suivant illustre comment ces éléments s’ajustent les uns aux autres.
![\[Le flux de travail d’une application de jeu. L'application utilise Amazon ID AWS STS pour obtenir des informations d'identification temporaires pour accéder à une table DynamoDB.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/wif-overview.png)
**Présentation de la fédération d’identité web**
1. L’application appelle un fournisseur d’identité tiers pour authentifier l’utilisateur et l’application. Le fournisseur d’identité retourne un jeton d’identité web à l’application.
1. L'application appelle AWS STS et transmet le jeton d'identité Web en entrée. AWS STS autorise l'application et lui donne des identifiants d' AWS accès temporaires. L'application est autorisée à assumer un rôle IAM (*GameRole*) et à accéder aux AWS ressources conformément à la politique de sécurité du rôle.
1. L'application appelle DynamoDB pour accéder à la table. *GameScores* Parce qu'elle a assumé le *GameRole*, l'application est soumise à la politique de sécurité associée à ce rôle. Le document de politique empêche l’application d’accéder aux données qui n’appartiennent pas à l’utilisateur.
Encore une fois, voici la politique de sécurité *GameRole*qui a été présentée dans [Utilisation de conditions de politique IAM pour un contrôle d’accès précis](specifying-conditions.md) :
------
#### [ JSON ]
****
```
{
"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"
}
}
}
]
}
```
------
La `Condition` clause détermine quels éléments *GameScores*sont visibles par l'application. A cette fin, elle compare l’ID de Login with Amazon aux valeurs de clé de partition `UserId` dans `GameScores`. Seuls les éléments appartenant à l’utilisateur actuel peuvent être traités à l’aide de l’une des actions DynamoDB répertoriées dans cette politique. Il n’est pas possible d’accéder aux autres éléments de la table. En outre, seuls les attributs spécifiques répertoriés dans la politique sont accessibles.
# Préparation de l’utilisation de la fédération d’identité web
Si vous êtes un développeur d’applications et que vous souhaitez utiliser la fédération d’identité web pour votre application, procédez comme suit :
1. **Inscrivez-vous en tant que développeur avec un fournisseur d’identité tiers.** Les liens externes suivants fournissent des informations sur l’inscription avec les fournisseurs d’identité pris en charge :
+ [Login with Amazon Developer Center](http://login.amazon.com/)
+ [Inscription](https://business.facebook.com/business/loginpage) sur le site de Facebook
+ [Utilisation de la OAuth version 2.0 pour accéder à Google APIs](https://developers.google.com/accounts/docs/OAuth2) sur le site de Google
1. **Inscrivez votre application auprès du fournisseur d’identité.** Lorsque vous procédez ainsi, le fournisseur vous fournit un ID unique pour votre application. Si vous voulez que votre application fonctionne avec plusieurs fournisseurs d’identité, vous devez obtenir un ID d’application de chaque fournisseur.
1. **Créez un ou plusieurs rôles IAM.**Vous avez besoin d’un rôle pour chaque fournisseur d’identité de chaque application. Par exemple, vous pouvez créer un rôle qui peut être assumé par une application où l’utilisateur s’est connecté à l’aide de Login with Amazon, un deuxième rôle pour une même application où l’utilisateur s’est connecté à l’aide de Facebook et un troisième rôle pour l’application où les utilisateurs se connectent à l’aide de Google.
Dans le cadre du processus de création de rôle, vous devez attacher une politique IAM au rôle. Votre document de politique doit définir les ressources DynamoDB que votre application requiert, ainsi que les autorisations d’accès à ces ressources.
Pour plus d’informations, consultez [À propos de la fédération d’identité web](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html) dans le *Guide de l’utilisateur IAM*.
**Note**
Au lieu de cela AWS Security Token Service, vous pouvez utiliser Amazon Cognito. Amazon Cognito est le service préféré pour la gestion des informations d’identification temporaires pour les applications mobiles. Pour plus d’informations, consultez [Obtention des informations d’identification](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-credentials.html) dans le *Guide du développeur Amazon Cognito.*
## Génération d’une politique IAM à l’aide de la console DynamoDB
La console DynamoDB peut vous aider à créer une politique IAM à utiliser avec une fédération d’identité web. Pour ce faire, vous choisissez une table DynamoDB et spécifiez le fournisseur d’identité, les actions et les attributs à inclure dans la politique. La console DynamoDB génère ensuite une politique que vous pouvez attacher à un rôle IAM.
1. Connectez-vous à la console DynamoDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Dans le volet de navigation, choisissez **Tables**.
1. Dans la liste des tables, sélectionnez la table pour laquelle vous souhaitez créer la politique IAM.
1. Sélectionnez le bouton **Actions**, puis choisissez **Créer une stratégie de contrôle d’accès**.
1. Sélectionnez le fournisseur d’identité, les actions et les attributs de la politique.
Lorsque les paramètres sont définis comme vous le souhaitez, choisissez **Générer une stratégie**. La politique générée s’affiche.
1. Choisissez **Consulter la documentation**, puis suivez les étapes nécessaires pour attacher la stratégie générée à un rôle IAM.
# Écriture de votre application pour utiliser la fédération d’identité web
Pour utiliser une fédération d’identité web, votre application doit endosser le rôle IAM que vous avez créé. À partir de là, les applications satisfont la politique d’accès attachée au rôle.
Lors de l’exécution, si votre application utilise la fédération d’identité web, elle doit suivre cette procédure :
1. **S’authentifier auprès d’un fournisseur d’identité tiers.** Votre application doit appeler le fournisseur d’identité à l’aide d’une interface fournie. La façon exacte dont vous authentifiez l’utilisateur dépend du fournisseur et de la plateforme sur laquelle votre application s’exécute. Généralement, si l’utilisateur n’est pas déjà connecté, le fournisseur d’identité veille à afficher une page de connexion pour ce fournisseur.
Une fois que le fournisseur d’identité a authentifié l’utilisateur, le fournisseur renvoie un jeton d’identité web à votre application. Le format de ce jeton dépend du fournisseur, mais il s’agit généralement d’une très longue chaîne de caractères.
1. **Obtenez des informations d'identification AWS de sécurité temporaires.** Pour ce faire, votre application envoie une demande `AssumeRoleWithWebIdentity` à AWS Security Token Service (AWS STS). Cette demande contient les éléments suivants :
+ Le jeton d’identité web de l’étape précédente
+ L’ID d’application du fournisseur d’identité
+ L’ARN (Amazon Resource Name) du rôle IAM que vous avez créé pour ce fournisseur d’identité pour cette application
AWS STS renvoie un ensemble d'informations d'identification de AWS sécurité qui expirent après un certain temps (3 600 secondes, par défaut).
Voici un exemple de demande et de réponse d’une action `AssumeRoleWithWebIdentity` dans AWS STS. Le jeton d’identité web a été obtenu depuis le fournisseur d’identité Login with Amazon.
```
GET / HTTP/1.1
Host: sts.amazonaws.com
Content-Type: application/json; charset=utf-8
URL: https://sts.amazonaws.com/?ProviderId=www.amazon.com
&DurationSeconds=900&Action=AssumeRoleWithWebIdentity
&Version=2011-06-15&RoleSessionName=web-identity-federation
&RoleArn=arn:aws:iam::123456789012:role/GameRole
&WebIdentityToken=Atza|IQEBLjAsAhQluyKqyBiYZ8-kclvGTYM81e...(remaining characters omitted)
```
```
amzn1.account.AGJZDKHJKAUUSW6C44CHPEXAMPLE
AQoDYXdzEMf//////////wEa8AP6nNDwcSLnf+cHupC...(remaining characters omitted)
8Jhi60+EWUUbbUShTEsjTxqQtM8UKvsM6XAjdA==
2013-10-01T22:14:35Z
06198791C436IEXAMPLE
arn:aws:sts::123456789012:assumed-role/GameRole/web-identity-federation
AROAJU4SA2VW5SZRF2YMG:web-identity-federation
c265ac8e-2ae4-11e3-8775-6969323a932d
```
1. **Accédez aux AWS ressources.** La réponse de AWS STS contient les informations que votre application requiert pour accéder aux ressources DynamoDB :
+ Les champs `AccessKeyID`, `SecretAccessKey` et `SessionToken` contiennent les informations d’identification de sécurité qui sont valides pour cet utilisateur et cette application uniquement.
+ Le champ `Expiration` indique le délai des informations d’identification, au terme duquel elles ne sont plus valides.
+ Le champ `AssumedRoleId` contient le nom d’un rôle IAM spécifique de la session qui a été endossé par l’application. L’application respecte les contrôles d’accès décrits dans document de politique IAM pendant la durée de la session.
+ Le champ `SubjectFromWebIdentityToken` contient l’ID unique qui s’affiche dans une variable de politique IAM pour ce fournisseur d’identité particulier. Voici les variables de politique IAM pour les fournisseurs pris en charge, ainsi que quelques exemples de valeurs associées à ceux-ci :
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/WIF.RunningYourApp.html)
Pour des exemples de politiques IAM où ces variables de politique sont utilisées, consultez [Exemples de politique : utilisation de conditions pour un contrôle d’accès détaillé](specifying-conditions.md#FGAC_DDB.Examples).
Pour plus d'informations sur le mode de génération des AWS STS informations d'identification d'accès temporaires, consultez la section [Demande d'informations d'identification de sécurité temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html) dans le *guide de l'utilisateur IAM*.
# Autorisations d’API DynamoDB : Référence des actions, ressources et conditions
Lorsque vous configurez [Gestion des identités et des accès pour Amazon DynamoDB](security-iam.md) et écrivez une politique d’autorisations que vous pouvez attacher à une identité IAM (politiques basées sur une identité), vous pouvez vous référer à la liste [Actions, resources, et clés de condition pour Amazon DynamoDB](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html) dans le *Guide de l’utilisateur IAM*. La page répertorie chaque opération de l'API DynamoDB, les actions correspondantes pour lesquelles vous pouvez accorder des autorisations pour effectuer l'action, ainsi que AWS la ressource pour laquelle vous pouvez accorder les autorisations. Vous spécifiez les actions dans le champ `Action` de la politique ainsi que la valeur des ressources dans le champ `Resource` de la politique.
Vous pouvez utiliser des AWS clés de condition larges dans vos politiques DynamoDB pour exprimer des conditions. Pour obtenir la liste complète des clés AWS-wide, consultez la [référence aux éléments de politique IAM JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) dans le guide de l'*utilisateur IAM*.
Outre les clés de AWS condition générales, DynamoDB possède ses propres clés spécifiques que vous pouvez utiliser dans des conditions. Pour de plus amples informations, veuillez consulter [Utilisation de conditions de politique IAM pour un contrôle d’accès précis](specifying-conditions.md).
## Rubriques en relation
+ [Gestion des identités et des accès pour Amazon DynamoDB](security-iam.md)
+ [Utilisation de conditions de politique IAM pour un contrôle d’accès précis](specifying-conditions.md)