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 dans MemoryDB
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. Les administrateurs IAM contrôlent qui peut être *authentifié* (connecté) et *autorisé (autorisé*) à utiliser les ressources MemoryDB. 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)
+ [Comment fonctionne MemoryDB avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
+ [Résolution des problèmes d'identité et d'accès à MemoryDB](security_iam_troubleshoot.md)
+ [Contrôle d’accès](#iam.accesscontrol)
+ [Vue d'ensemble de la gestion des autorisations d'accès à vos ressources MemoryDB](iam.overview.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 des problèmes d'identité et d'accès à MemoryDB](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Comment fonctionne MemoryDB avec IAM](security_iam_service-with-iam.md))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de politiques basées sur l'identité pour MemoryDB](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 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 AWS CLI ou AWS 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*.
# Comment fonctionne MemoryDB avec IAM
Avant d'utiliser IAM pour gérer l'accès à MemoryDB, découvrez quelles fonctionnalités IAM peuvent être utilisées avec MemoryDB.
**Fonctionnalités IAM que vous pouvez utiliser avec MemoryDB**
| Fonctionnalité IAM | Support de MemoryDB |
| --- | --- |
| [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) | Non |
| [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) | Oui |
| [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 MemoryDB et des autres AWS services avec la plupart des fonctionnalités IAM, consultez la section [AWS Services compatibles avec IAM dans le guide de l'utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*
## Politiques basées sur l'identité pour MemoryDB
**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 politiques basées sur l'identité pour MemoryDB
Pour consulter des exemples de politiques basées sur l'identité de MemoryDB, consultez. [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
## Politiques basées sur les ressources dans MemoryDB
**Prend en charge les politiques basées sur les ressources :** non
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 MemoryDB
**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 voir la liste des actions MemoryDB, voir [Actions définies par MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions) dans la référence d'autorisation de service.*
Les actions de politique dans MemoryDB utilisent le préfixe suivant avant l'action :
```
MemoryDB
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"MemoryDB:action1",
"MemoryDB:action2"
]
```
Vous pouvez aussi spécifier plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante :
```
"Action": "MemoryDB:Describe*"
```
Pour consulter des exemples de politiques basées sur l'identité de MemoryDB, consultez. [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
## Ressources relatives aux politiques pour MemoryDB
**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 MemoryDB et leurs caractéristiques ARNs, consultez la section [Ressources définies par MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-resources-for-iam-policies) dans la référence d'autorisation de service.* Pour savoir avec quelles actions vous pouvez spécifier l'ARN de chaque ressource, voir [Actions définies par MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions).
Pour consulter des exemples de politiques basées sur l'identité de MemoryDB, consultez. [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
## Clés de conditions de politique pour MemoryDB
**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 consulter des exemples de politiques basées sur l'identité de MemoryDB, consultez. [Exemples de politiques basées sur l'identité pour MemoryDB](security_iam_id-based-policy-examples.md)
### Utilisation de clés de condition
Vous pouvez spécifier des conditions pour déterminer comment une politique IAM prend effet. Dans MemoryDB, vous pouvez utiliser l'`Condition`élément d'une politique JSON pour comparer les clés dans le contexte de la demande avec les valeurs clés que vous spécifiez dans votre politique. Pour plus d'informations, consultez [Éléments de politique JSON IAM : condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html).
*Pour consulter la liste des clés de condition de MemoryDB, voir Clés de [condition pour MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-policy-keys) dans la référence d'autorisation de service.*
Pour obtenir la liste de toutes les clés de condition globales, veuillez consulter [Clés de contexte de condition globales AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
#### Spécification de conditions : Utilisation de clés de condition
Pour mettre en œuvre un contrôle précis, vous pouvez rédiger une politique d'autorisation IAM qui spécifie les conditions permettant de contrôler un ensemble de paramètres individuels pour certaines demandes. Vous pouvez ensuite appliquer la politique aux utilisateurs, groupes ou rôles IAM que vous créez à l'aide de la console IAM.
Pour appliquer une condition, vous ajoutez les informations de condition à la déclaration de politique IAM. Par exemple, pour interdire la création d'un cluster MemoryDB avec le protocole TLS désactivé, vous pouvez spécifier la condition suivante dans votre déclaration de politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "false"
}
}
}
]
}
```
------
Pour plus d'informations sur le balisage, consultez[Marquer vos ressources MemoryDB](tagging-resources.md).
Pour plus d'informations sur l'utilisation d'opérateurs de condition de politique, veuillez consulter [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md).
#### Exemples de politique : Utilisation de conditions pour un contrôle de paramètre détaillé
Cette section présente des exemples de politiques pour implémenter un contrôle d'accès précis sur les paramètres MemoryDB répertoriés précédemment.
1. **memorydb : TLSEnabled** — Spécifiez que les clusters seront créés uniquement avec le protocole TLS activé.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"arn:aws:memorydb:*:*:parametergroup/*",
"arn:aws:memorydb:*:*:subnetgroup/*",
"arn:aws:memorydb:*:*:acl/*"
]
},
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "true"
}
}
}
]
}
```
------
1. **memorydb : UserAuthenticationMode :** — Spécifiez que les utilisateurs peuvent être créés avec un mode d'authentification de type spécifique (IAM par exemple).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:Createuser"
],
"Resource": [
"arn:aws:memorydb:*:*:user/*"
],
"Condition": {
"StringEquals": {
"memorydb:UserAuthenticationMode": "iam"
}
}
}
]
}
```
------
Dans les cas où vous définissez des politiques basées sur le « refus », il est recommandé d'utiliser l'[StringEqualsIgnoreCase](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String)opérateur pour éviter tous les appels avec un type de mode d'authentification utilisateur spécifique, quel que soit le cas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateUser"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"memorydb:UserAuthenticationMode": "password"
}
}
}
]
}
```
------
## Listes de contrôle d'accès (ACLs) dans MemoryDB
**Supports ACLs :** Oui
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 basé sur les attributs (ABAC) avec MemoryDB
**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 d'informations d'identification temporaires avec MemoryDB
**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 interservices pour MemoryDB
**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).
## Rôles de service pour MemoryDB
**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 pour un rôle de service peut interrompre les fonctionnalités de MemoryDB. Modifiez les rôles de service uniquement lorsque MemoryDB fournit des instructions à cet effet.
## Rôles liés à un service pour MemoryDB
**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.
# Exemples de politiques basées sur l'identité pour MemoryDB
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources MemoryDB. 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 plus de détails sur les actions et les types de ressources définis par MemoryDB, y compris le ARNs format de chaque type de ressource, voir [Actions, ressources et clés de condition pour MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html) dans la référence d'autorisation de service.*
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console MemoryDB](#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)
## Bonnes pratiques en matière de politiques
Les politiques basées sur l'identité déterminent si quelqu'un peut créer, accéder ou supprimer des ressources MemoryDB 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 MemoryDB
Pour accéder à la console MemoryDB, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et d'afficher les détails des ressources MemoryDB 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 MemoryDB, attachez également la MemoryDB `ConsoleAccess` ou la politique `ReadOnly` AWS gérée aux entités. 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": "*"
}
]
}
```
# Résolution des problèmes d'identité et d'accès à MemoryDB
Utilisez les informations suivantes pour diagnostiquer et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec MemoryDB et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans MemoryDB](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes ressources MemoryDB](#security_iam_troubleshoot-cross-account-access)
## Je ne suis pas autorisé à effectuer une action dans MemoryDB
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 `MemoryDB:GetWidget` fictives.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: MemoryDB: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 `MemoryDB:GetWidget`.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez un message d'erreur indiquant que vous n'êtes pas autorisé à effectuer l'`iam:PassRole`action, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à MemoryDB.
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 effectuer une action dans MemoryDB. 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 à mon AWS compte à accéder à mes ressources MemoryDB
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 MemoryDB prend en charge ces fonctionnalités, consultez. [Comment fonctionne MemoryDB 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*.
## Contrôle d’accès
Vous pouvez disposer d'informations d'identification valides pour authentifier vos demandes, mais vous ne pouvez pas créer de ressources MemoryDB ou y accéder sans autorisation. Par exemple, vous devez disposer des autorisations nécessaires pour créer un cluster MemoryDB.
Les sections suivantes décrivent comment gérer les autorisations pour MemoryDB. Nous vous recommandons de lire d’abord la présentation.
+ [Vue d'ensemble de la gestion des autorisations d'accès à vos ressources MemoryDB](iam.overview.md)
+ [Utilisation de politiques basées sur l'identité (politiques IAM) pour MemoryDB](iam.identitybasedpolicies.md)
# Vue d'ensemble de la gestion des autorisations d'accès à vos ressources MemoryDB
Chaque AWS ressource appartient à un AWS compte, et les autorisations de création ou d'accès à une ressource sont régies par des politiques d'autorisation. Un compte administrateur peut attacher des politiques d'autorisations à des identités IAM (c'est-à-dire des utilisateurs, des groupes et des rôles). En outre, MemoryDB prend également en charge l'attachement de politiques d'autorisation aux ressources.
**Note**
Un *administrateur de compte* (ou utilisateur administrateur) est un utilisateur doté des privilèges d’administrateur. Pour plus d'informations, consultez [Bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l'utilisateur IAM*.
Pour activer l’accès, ajoutez des autorisations à vos utilisateurs, groupes ou rôles :
+ Utilisateurs et groupes dans AWS IAM Identity Center :
Créez un jeu d’autorisations. Suivez les instructions de la rubrique [Création d’un jeu d’autorisations](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) du *Guide de l’utilisateur AWS IAM Identity Center *.
+ Utilisateurs gérés dans IAM par un fournisseur d’identité :
Créez un rôle pour la fédération d’identité. Suivez les instructions de la rubrique [Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*.
+ Utilisateurs IAM :
+ Créez un rôle que votre utilisateur peut assumer. Suivez les instructions de la rubrique [Création d’un rôle pour un utilisateur IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l’utilisateur IAM*.
+ (Non recommandé) Attachez une politique directement à un utilisateur ou ajoutez un utilisateur à un groupe d’utilisateurs. Suivez les instructions de la rubrique [Ajout d’autorisations à un utilisateur (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) du *Guide de l’utilisateur IAM*.
**Topics**
+ [Ressources et opérations de MemoryDB](#iam.overview.resourcesandoperations)
+ [Présentation de la propriété des ressources](#access-control-resource-ownership)
+ [Gestion de l’accès aux ressources](#iam.overview.managingaccess)
+ [Utilisation de politiques basées sur l'identité (politiques IAM) pour MemoryDB](iam.identitybasedpolicies.md)
+ [Autorisations de niveau ressource](iam.resourcelevelpermissions.md)
+ [Utilisation de rôles liés à un service pour MemoryDB](using-service-linked-roles.md)
+ [AWS politiques gérées pour MemoryDB](security-iam-awsmanpol.md)
+ [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md)
## Ressources et opérations de MemoryDB
*Dans MemoryDB, la ressource principale est un cluster.*
Ces ressources sont associées à des noms de ressources Amazon (ARNs) uniques, comme indiqué ci-dessous.
**Note**
Pour que les autorisations au niveau des ressources soient efficaces, le nom de la ressource sur la chaîne ARN doit être en minuscules.
****
| Type de ressource | Format ARN |
| --- | --- |
| Utilisateur | arn:aws:memorydb ::user/user1 *us-east-1:123456789012* |
| Liste de contrôle d'accès (ACL) | arn:aws:memorydb ::acl/myacl *us-east-1:123456789012* |
| Cluster | arn:aws:memorydb ::cluster/my-cluster *us-east-1:123456789012* |
| Instantané | arn:aws:memorydb ::snapshot/my-snapshot *us-east-1:123456789012* |
| Groupe de paramètres | arn:aws:memorydb ::parametergroup/ *us-east-1:123456789012* my-parameter-group |
| Groupe de sous-réseaux | arn:aws:memorydb ::subnetgroup/ *us-east-1:123456789012* my-subnet-group |
MemoryDB fournit un ensemble d'opérations permettant de travailler avec les ressources MemoryDB. [Pour une liste des opérations disponibles, consultez la section Actions MemoryDB.](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)
## Présentation de la propriété des ressources
*Le propriétaire d'une ressource* est le AWS compte qui a créé la ressource. En d'autres termes, le propriétaire de la ressource est le AWS compte de l'entité principale qui authentifie la demande qui crée la ressource. Une *entité principale* peut être le compte root, un utilisateur IAM ou un rôle IAM. Les exemples suivants illustrent comment cela fonctionne :
+ Supposons que vous utilisiez les informations d'identification du compte root de votre AWS compte pour créer un cluster. Dans ce cas, votre AWS compte est le propriétaire de la ressource. Dans MemoryDB, la ressource est le cluster.
+ Supposons que vous créiez un utilisateur IAM dans votre AWS compte et que vous accordiez des autorisations pour créer un cluster à cet utilisateur. Dans ce cas, l'utilisateur peut créer un cluster. Toutefois, votre AWS compte, auquel appartient l'utilisateur, est propriétaire de la ressource du cluster.
+ Supposons que vous créiez un rôle IAM dans votre AWS compte avec les autorisations nécessaires pour créer un cluster. Dans ce cas, toute personne capable d'assumer ce rôle peut créer un cluster. Votre AWS compte, auquel appartient le rôle, est propriétaire de la ressource du cluster.
## Gestion de l’accès aux ressources
Une *politique d'autorisation* décrit qui a accès à quoi. La section suivante explique les options disponibles pour créer des politiques d'autorisations.
**Note**
Cette section décrit l'utilisation d'IAM dans le contexte de MemoryDB. Elle ne fournit pas d’informations détaillées sur le service IAM. Pour une documentation complète sur IAM, consultez [Qu'est-ce que IAM ?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) dans le *Guide de l'utilisateur IAM*. Pour plus d'informations sur la syntaxe et les descriptions des stratégies IAM, consultez [Référence de stratégie AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) dans le *Guide de l'utilisateur IAM*.
Les politiques attachées à une identité IAM sont appelées des politiques *basées sur l'identité* (politiques IAM). Les stratégies attachées à une ressource sont appelées stratégies *basées sur une ressource*.
**Topics**
+ [Politiques basées sur une identité (politiques IAM)](#iam.overview.managingaccess.identitybasedpolicies)
+ [Spécification des éléments d'une politique : actions, effets, ressources et mandataires](#iam.overview.policyelements)
+ [Spécification de conditions dans une politique](#iam.specifyconditions)
### Politiques basées sur une identité (politiques IAM)
Vous pouvez attacher des politiques à des identités IAM. Par exemple, vous pouvez effectuer les opérations suivantes :
+ **Attacher une politique d'autorisations à un utilisateur ou à un groupe dans votre compte** : un administrateur de compte peut utiliser une politique d'autorisations associée à un utilisateur particulier pour accorder des autorisations. Dans ce cas, les autorisations permettent à cet utilisateur de créer une ressource MemoryDB, telle qu'un cluster, un groupe de paramètres ou un groupe de sécurité.
+ **Attacher une politique d'autorisations à un rôle (accorder des autorisations entre comptes)** : vous pouvez attacher une politique d'autorisation basée sur une identité à un rôle IAM afin d'accorder des autorisations entre comptes. Par exemple, l'administrateur du compte A peut créer un rôle pour accorder des autorisations entre comptes à un autre AWS compte (par exemple, le compte B) ou à un AWS service comme suit :
1. L'administrateur du Compte A crée un rôle IAM et attache une politique d'autorisation à ce rôle qui accorde des autorisations sur les ressources dans le Compte A.
1. L'administrateur du Compte A attache une politique d'approbation au rôle identifiant le Compte B comme principal pouvant assumer ce rôle.
1. L'administrateur du compte B peut ensuite déléguer les autorisations nécessaires pour assumer le rôle à n'importe quel utilisateur du compte B. Cela permet aux utilisateurs du compte B de créer des ressources ou d'accéder à des ressources dans le compte A. Dans certains cas, vous souhaiterez peut-être accorder à un AWS service des autorisations lui permettant d'assumer le rôle. Pour soutenir cette approche, le principal dans la politique d'approbation peut également être un mandataire du service AWS .
Pour en savoir plus sur l'utilisation d'IAM pour déléguer des autorisations, consultez [Gestion des accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) dans le *Guide de l'utilisateur IAM*.
Voici un exemple de politique qui permet à un utilisateur d'effectuer l'`DescribeClusters`action pour votre AWS compte. MemoryDB prend également en charge l'identification de ressources spécifiques à l'aide de la ressource ARNs pour les actions d'API. (Cette approche est également appelée autorisations au niveau des ressources.)
Pour plus d'informations sur l'utilisation de politiques basées sur l'identité avec MemoryDB, consultez. [Utilisation de politiques basées sur l'identité (politiques IAM) pour MemoryDB](iam.identitybasedpolicies.md) Pour de plus amples informations sur les utilisateurs, les groupes, les rôles et les autorisations, veuillez consulter [Identités (utilisateurs, groupes et rôles)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) dans le *Guide de l'utilisateur IAM*.
### Spécification des éléments d'une politique : actions, effets, ressources et mandataires
Pour chaque ressource MemoryDB (voir[Ressources et opérations de MemoryDB](#iam.overview.resourcesandoperations)), le service définit un ensemble d'opérations d'API (voir [Actions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)). Pour accorder des autorisations pour ces opérations d'API, MemoryDB définit un ensemble d'actions que vous pouvez spécifier dans une politique. Par exemple, pour la ressource de cluster MemoryDB, les actions suivantes sont définies : `CreateCluster``DeleteCluster`, et. `DescribeClusters` Une opération d’API peut exiger des autorisations pour plusieurs actions.
Voici les éléments les plus élémentaires d'une politique :
+ **Ressource** : dans une politique, vous utilisez un Amazon Resource Name (ARN) pour identifier la ressource à laquelle la politique s'applique. Pour de plus amples informations, veuillez consulter [Ressources et opérations de MemoryDB](#iam.overview.resourcesandoperations).
+ **Action :** vous utilisez des mots clés d’action pour identifier les opérations de ressource que vous voulez accorder ou refuser. Par exemple, en fonction de ce qui est spécifié`Effect`, l'`memorydb:CreateCluster`autorisation autorise ou refuse à l'utilisateur l'autorisation d'effectuer l'opération MemoryDB`CreateCluster`.
+ **Effet** – Vous spécifiez l’effet produit lorsque l’utilisateur demande l’action spécifique, qui peut être une autorisation ou un refus. Si vous n’accordez pas explicitement l’accès pour (autoriser) une ressource, l’accès est implicitement refusé. Vous pouvez également explicitement refuser l’accès à une ressource. Par exemple,vous pouvez le faire afin de vous assurer qu'un utilisateur n'y a pas accès, même si une politique différente accorde cet accès.
+ **Principal** : dans les politiques basées sur une identité (politiques IAM), l'utilisateur auquel la politique est attachée est le principal implicite. Pour les politiques basées sur une ressource, vous spécifiez l'utilisateur, le compte, le service ou une autre entité qui doit recevoir les autorisations (s'applique uniquement aux politiques basées sur une ressource).
Pour en savoir plus sur la syntaxe des stratégies IAM et pour obtenir des descriptions, consultez [Référence de stratégie IAM AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) dans le *Guide de l'utilisateur IAM*.
Pour un tableau présentant toutes les actions de l'API MemoryDB, consultez. [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md)
### Spécification de conditions dans une politique
Lorsque vous accordez des autorisations, vous pouvez utiliser le langage des politiques IAM afin de spécifier les conditions définissant à quel moment une politique doit prendre effet. Par exemple, il est possible d'appliquer une politique après seulement une date spécifique. Pour plus d'informations sur la spécification de conditions dans un langage de politique, consultez [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) dans le *Guide de l'utilisateur IAM*.
# Utilisation de politiques basées sur l'identité (politiques IAM) pour MemoryDB
Cette rubrique fournit des exemples de politiques basées sur une identité dans lesquelles un administrateur de compte peut attacher des politiques d'autorisation aux identités IAM (c'est-à-dire aux utilisateurs, groupes et rôles).
**Important**
Nous vous recommandons de lire d'abord les rubriques qui expliquent les concepts et options de base pour gérer l'accès aux ressources MemoryDB. Pour de plus amples informations, veuillez consulter [Vue d'ensemble de la gestion des autorisations d'accès à vos ressources MemoryDB](iam.overview.md).
Les sections de cette rubrique couvrent les sujets suivants :
+ [Autorisations requises pour utiliser la console MemoryDB](#iam.identitybasedpolicies.minconpolicies)
+ [AWS-politiques gérées (prédéfinies) pour MemoryDB](security-iam-awsmanpol.md#iam.identitybasedpolicies.predefinedpolicies)
+ [Exemples de politiques gérées par le client](#iam.identitybasedpolicies.customermanagedpolicies)
Un exemple de politique d'autorisation est exposé ci-dessous.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowClusterPermissions",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:DescribeClusters",
"memorydb:UpdateCluster"],
"Resource": "*"
},
{
"Sid": "AllowUserToPassRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::123456789012:role/EC2-roles-for-cluster"
}
]
}
```
------
La politique possède deux énoncés:
+ La première instruction accorde des autorisations pour les actions MemoryDB (`memorydb:CreateCluster`,`memorydb:DescribeClusters`, et`memorydb:UpdateCluster`) sur tout cluster appartenant au compte.
+ La deuxième instruction accorde des autorisations pour l'action IAM (`iam:PassRole`) sur le nom du rôle IAM spécifié à la fin de la valeur `Resource`.
La politique ne spécifie pas l'élément `Principal` car, dans une politique basée sur une identité, vous ne spécifiez pas le principal qui obtient l'autorisation. Quand vous attachez une politique à un utilisateur, l'utilisateur est le principal implicite. Lorsque vous attachez une politique d'autorisation à un rôle IAM, le principal identifié dans la politique d'approbation de ce rôle obtient les autorisations.
Pour un tableau présentant toutes les actions de l'API MemoryDB et les ressources auxquelles elles s'appliquent, consultez. [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md)
## Autorisations requises pour utiliser la console MemoryDB
Le tableau de référence des autorisations répertorie les opérations de l'API MemoryDB et indique les autorisations requises pour chaque opération. Pour plus d'informations sur les opérations de l'API MemoryDB, consultez. [Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions](iam.APIReference.md)
Pour utiliser la console MemoryDB, accordez d'abord des autorisations pour des actions supplémentaires, comme indiqué dans la politique d'autorisation suivante.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "MinPermsForMemDBConsole",
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeVpcs",
"ec2:DescribeAccountAttributes",
"ec2:DescribeSecurityGroups",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"s3:ListAllMyBuckets",
"sns:ListTopics",
"sns:ListSubscriptions" ],
"Resource": "*"
}
]
}
```
------
La console MemoryDB a besoin de ces autorisations supplémentaires pour les raisons suivantes :
+ Les autorisations pour les actions MemoryDB permettent à la console d'afficher les ressources MemoryDB dans le compte.
+ La console a besoin d'autorisations pour effectuer les `ec2` actions permettant d'interroger Amazon EC2 afin de pouvoir afficher les zones de disponibilité VPCs, les groupes de sécurité et les attributs de compte.
+ Les autorisations relatives aux `cloudwatch` actions permettent à la console de récupérer CloudWatch les métriques et les alarmes Amazon et de les afficher dans la console.
+ Les autorisations pour les actions `sns` permettent à la console de récupérer les abonnements et les rubriques Amazon Simple Notification Service (Amazon SNS), et de les afficher dans la console.
## Exemples de politiques gérées par le client
Si vous n'utilisez pas de politique par défaut et que vous choisissez d'utiliser une politique gérée personnalisée, vous devez assurer l'un des deux points suivants. Vous devez soit avoir les autorisations d'appeler `iam:createServiceLinkedRole` (pour plus d'informations, veuillez consulter [Exemple 4 : Autoriser un utilisateur à appeler l'API IAM CreateServiceLinkedRole](#create-service-linked-role-policy)). Ou vous auriez dû créer un rôle lié au service MemoryDB.
Combinés aux autorisations minimales nécessaires pour utiliser la console MemoryDB, les exemples de politiques présentés dans cette section accordent des autorisations supplémentaires. Les exemples sont également pertinents pour le AWS SDKs et le AWS CLI. Pour plus d'informations sur les autorisations nécessaires pour utiliser la console MemoryDB, consultez. [Autorisations requises pour utiliser la console MemoryDB](#iam.identitybasedpolicies.minconpolicies)
Pour plus d'informations sur la configuration des utilisateurs et des groupes IAM, veuillez consulter [Création de votre premier groupe d'utilisateurs et d'administrateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) dans le *Guide de l'utilisateur IAM*.
**Important**
Veillez à toujours tester vos politiques IAM de manière approfondie avant de les utiliser. Certaines actions MemoryDB qui semblent simples peuvent nécessiter d'autres actions pour les prendre en charge lorsque vous utilisez la console MemoryDB. Par exemple, `memorydb:CreateCluster` accorde des autorisations pour créer des clusters MemoryDB. Toutefois, pour effectuer cette opération, la console MemoryDB utilise un certain nombre d'`List`actions `Describe` et pour remplir les listes de consoles.
**Topics**
+ [Exemple 1 : autoriser un utilisateur à accéder en lecture seule aux ressources MemoryDB](#example-allow-list-current-memorydb-resources)
+ [Exemple 2 : autoriser un utilisateur à effectuer des tâches courantes d'administrateur système MemoryDB](#example-allow-specific-memorydb-actions)
+ [Exemple 3 : Autoriser un utilisateur à accéder à toutes les actions de l'API MemoryDB](#allow-unrestricted-access)
+ [Exemple 4 : Autoriser un utilisateur à appeler l'API IAM CreateServiceLinkedRole](#create-service-linked-role-policy)
### Exemple 1 : autoriser un utilisateur à accéder en lecture seule aux ressources MemoryDB
La politique suivante accorde des autorisations pour les actions MemoryDB qui permettent à un utilisateur de répertorier des ressources. En général, vous attachez ce type de politique d'autorisations à un groupe de gestionnaires.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MemDBUnrestricted",
"Effect":"Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"],
"Resource":"*"
}
]
}
```
------
### Exemple 2 : autoriser un utilisateur à effectuer des tâches courantes d'administrateur système MemoryDB
Les tâches courantes des administrateurs système incluent la modification des clusters, des paramètres et des groupes de paramètres. Un administrateur système peut également souhaiter obtenir des informations sur les événements MemoryDB. La politique suivante accorde à un utilisateur l'autorisation d'effectuer des actions MemoryDB pour ces tâches courantes d'administrateur système. Généralement, vous attachez ce type de politique d'autorisations au groupe d'administrateurs système.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MDBAllowSpecific",
"Effect": "Allow",
"Action": [
"memorydb:UpdateCluster",
"memorydb:DescribeClusters",
"memorydb:DescribeEvents",
"memorydb:UpdateParameterGroup",
"memorydb:DescribeParameterGroups",
"memorydb:DescribeParameters",
"memorydb:ResetParameterGroup"
],
"Resource": "*"
}
]
}
```
------
### Exemple 3 : Autoriser un utilisateur à accéder à toutes les actions de l'API MemoryDB
La politique suivante permet à un utilisateur d'accéder à toutes les actions MemoryDB. Nous vous conseillons d'accorder ce type de politique d'autorisations uniquement à un utilisateur administrateur.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MDBAllowAll",
"Effect":"Allow",
"Action":[
"memorydb:*" ],
"Resource":"*"
}
]
}
```
------
### Exemple 4 : Autoriser un utilisateur à appeler l'API IAM CreateServiceLinkedRole
La politique suivante permet à un utilisateur d'appeler l'API `CreateServiceLinkedRole` IAM. Nous vous recommandons d'accorder ce type de politique d'autorisations à l'utilisateur qui invoque des opérations mutatives de MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"CreateSLRAllows",
"Effect":"Allow",
"Action":[
"iam:CreateServiceLinkedRole"
],
"Resource":"*",
"Condition":{
"StringLike":{
"iam:AWS ServiceName":"memorydb.amazonaws.com"
}
}
}
]
}
```
------
# Autorisations de niveau ressource
Vous pouvez restreindre la portée des autorisations en spécifiant des ressources dans une politique IAM. De nombreuses actions d' AWS CLI API prennent en charge un type de ressource qui varie en fonction du comportement de l'action. Chaque déclaration de politique IAM accorde une autorisation pour une action effectuée sur une ressource. Lorsque l'action n'agit pas sur une ressource nommée, ou lorsque vous accordez l'autorisation d'effectuer l'action sur toutes les ressources, la valeur de la ressource de la politique est un caractère générique (\$1). Pour la plupart des actions d'API, vous pouvez limiter les ressources qu'un utilisateur peut modifier en spécifiant l'Amazon Resource Name (ARN) d'une ressource ou un modèle ARN qui correspond à plusieurs ressources. Pour limiter les autorisations par ressource, spécifiez la ressource par son ARN.
**Format ARN des ressources MemoryDB**
**Note**
Pour que les autorisations au niveau des ressources soient effectives, le nom de la ressource dans la chaîne ARN doit être en minuscules.
+ Utilisateur — arn:aws:memorydb ::user/user1 *us-east-1:123456789012*
+ ACL — arn:aws:memorydb ::acl/my-acl *us-east-1:123456789012*
+ Cluster — arn:aws:memorydb ::cluster/my-cluster *us-east-1:123456789012*
+ Snapshot — arn:aws:memorydb ::snapshot/my-snapshot *us-east-1:123456789012*
+ Groupe de paramètres — arn:aws:memorydb ::parametergroup/ *us-east-1:123456789012* my-parameter-group
+ Groupe de sous-réseaux — arn:aws:memorydb ::subnetgroup/ *us-east-1:123456789012* my-subnet-group
**Topics**
+ [Exemple 1 : accorder à un utilisateur un accès complet à des types de ressources MemoryDB spécifiques](#example-allow-list-current-memorydb-resources-resource)
+ [Exemple 2 : refuser à un utilisateur l'accès à un cluster.](#example-allow-specific-memorydb-actions-resource)
## Exemple 1 : accorder à un utilisateur un accès complet à des types de ressources MemoryDB spécifiques
La politique suivante autorise explicitement l'accès `account-id` complet spécifié à toutes les ressources de type groupe de sous-réseaux, groupe de sécurité et cluster.
```
{
"Sid": "Example1",
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:subnetgroup/*",
"arn:aws:memorydb:us-east-1:account-id:securitygroup/*",
"arn:aws:memorydb:us-east-1:account-id:cluster/*"
]
}
```
## Exemple 2 : refuser à un utilisateur l'accès à un cluster.
L'exemple suivant refuse explicitement l'`account-id`accès spécifié à un cluster particulier.
```
{
"Sid": "Example2",
"Effect": "Deny",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:cluster/name"
]
}
```
# Utilisation de rôles liés à un service pour MemoryDB
[MemoryDB utilise des rôles liés à un service Gestion des identités et des accès AWS (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un rôle lié à un service est un type unique de rôle IAM directement lié à un AWS service, tel que MemoryDB. Les rôles liés au service MemoryDB sont prédéfinis par MemoryDB. Ils comprennent toutes les autorisations requises par le service pour appeler des services AWS au nom de vos clusters.
Un rôle lié à un service facilite la configuration de MemoryDB car il n'est pas nécessaire d'ajouter manuellement les autorisations nécessaires. Les rôles existent déjà dans votre AWS compte, mais ils sont liés à des cas d'utilisation de MemoryDB et disposent d'autorisations prédéfinies. Seul MemoryDB peut assumer ces rôles, et seuls ces rôles peuvent utiliser la politique d'autorisation prédéfinie. Vous pouvez supprimer les rôles uniquement après la suppression préalable de leurs ressources connexes. Cela protège vos ressources MemoryDB car vous ne pouvez pas supprimer par inadvertance les autorisations nécessaires pour accéder aux ressources.
Pour plus d’informations sur les autres services qui prennent en charge les 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) et recherchez les services avec un **Oui ** dans la colonne **Rôle lié à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.
**Contents**
+ [Autorisations de rôles liés à un service](#service-linked-role-permissions)
+ [Création d'un rôle lié à un service (IAM)](#create-service-linked-role-iam)
+ [Utilisation de la console IAM](#create-service-linked-role-iam-console)
+ [Utilisation de la CLI IAM](#create-service-linked-role-iam-cli)
+ [Utilisation de l'API IAM](#create-service-linked-role-iam-api)
+ [Modification de la description d'un rôle lié à un service](#edit-service-linked-role)
+ [Utilisation de la console IAM](#edit-service-linked-role-iam-console)
+ [Utilisation de la CLI IAM](#edit-service-linked-role-iam-cli)
+ [Utilisation de l'API IAM](#edit-service-linked-role-iam-api)
+ [Supprimer un rôle lié à un service pour MemoryDB](#delete-service-linked-role)
+ [Nettoyage d'un rôle lié à un service](#service-linked-role-review-before-delete)
+ [Suppression d'un rôle lié à un service (console IAM)](#delete-service-linked-role-iam-console)
+ [Suppression d'un rôle lié à un service (CLI IAM)](#delete-service-linked-role-iam-cli)
+ [Suppression d'un rôle lié à un service (API IAM)](#delete-service-linked-role-iam-api)
## Autorisations de rôle liées à un service pour MemoryDB
MemoryDB utilise le rôle lié à un service nommé **AWSServiceRoleForMemoryDB. Cette politique permet à MemoryDB** de gérer les AWS ressources en votre nom, selon les besoins de gestion de vos clusters.
La AWSService RoleForMemory politique d'autorisation des rôles liés au service de base de données permet à MemoryDB d'effectuer les actions suivantes sur les ressources spécifiées :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
Pour de plus amples informations, veuillez consulter [AWS politique gérée : Mémoire DBService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-memorydbServiceRolePolicy).
**Pour autoriser une entité IAM à créer des rôles liés à un service de AWSService RoleForMemory base de données**
Ajoutez la déclaration de politique suivante aux autorisations de cette entité IAM :
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
**Pour autoriser une entité IAM à supprimer des rôles liés à un service de AWSService RoleForMemory base de données**
Ajoutez la déclaration de politique suivante aux autorisations de cette entité IAM :
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
Vous pouvez également utiliser une politique AWS gérée pour fournir un accès complet à MemoryDB.
## Création d'un rôle lié à un service (IAM)
Vous pouvez créer un rôle lié à un service à l'aide de la console IAM, de la CLI ou de l'API.
### Création d'un rôle lié à un service (console IAM)
Vous pouvez utiliser la console IAM pour créer un rôle lié à un service.
**Pour créer un rôle lié à un service (console)**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation de gauche de la console IAM, sélectionnez **Rôles**. Ensuite, choisissez **Create new role (Créer un nouveau rôle)**.
1. Sous **Sélectionner un type d’entité de confiance**, choisissez **AWS Service**.
1. Sous **Ou sélectionnez un service pour afficher ses cas d'utilisation**, choisissez **MemoryDB**.
1. Choisissez **Suivant : Autorisations**.
1. Sous **Policy name (Nom de la politique)**, notez que la `MemoryDBServiceRolePolicy` est nécessaire pour ce rôle. Choisissez **Suivant : balises**.
1. Notez que les balises ne sont pas prises en charge pour les rôles liés à un service. Choisissez **Next: Review (Suivant : vérifier)**.
1. (Facultatif) Dans le champ **Description du rôle**, modifiez la description du nouveau rôle lié à un service.
1. Passez en revue les informations du rôle, puis choisissez **Créer un rôle**.
### Création d'un rôle lié à un service (CLI IAM)
Vous pouvez utiliser les opérations IAM depuis le AWS Command Line Interface pour créer un rôle lié à un service. Ce rôle peut inclure la politique d'approbation et les politiques en ligne dont le service a besoin pour endosser le rôle.
**Pour créer un rôle lié à un service (CLI)**
Utilisez l'opération suivante :
```
$ aws iam [create-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) --aws-service-name memorydb.amazonaws.com
```
### Création d'un rôle lié à un service (API IAM)
Vous pouvez utiliser l'API IAM pour créer un rôle lié à un service. Ce rôle peut contenir la politique d'approbation et les politiques en ligne dont le service a besoin pour endosser le rôle.
**Pour créer un rôle lié à un service (API)**
Utilisez l'appel d'API [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html). Dans la demande, spécifiez un nom de service sous la forme `memorydb.amazonaws.com`.
## Modification de la description d'un rôle lié à un service pour MemoryDB
MemoryDB ne vous permet pas de modifier le rôle lié au service de AWSService RoleForMemory base de données. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM.
### Modification de la description d'un rôle lié à un service (console IAM)
Vous pouvez utiliser la console IAM pour modifier la description d'un rôle lié à un service.
**Pour modifier la description d'un rôle lié à un service (console)**
1. Dans le volet de navigation de gauche de la console IAM, sélectionnez **Rôles**.
1. Choisissez le nom du rôle à modifier.
1. A l'extrême droite de **Description du rôle**, choisissez **Edit (Modifier)**.
1. Saisissez une nouvelle description dans la zone et choisissez **Save (Enregistrer)**.
### Modification de la description d'un rôle lié à un service (CLI IAM)
Vous pouvez utiliser les opérations IAM depuis le AWS Command Line Interface pour modifier la description d'un rôle lié à un service.
**Pour changer la description d'un rôle d'un rôle lié à un service (CLI)**
1. (Facultatif) Pour afficher la description actuelle d'un rôle, utilisez l'opération AWS CLI `[get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)` for IAM.
**Example**
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name AWSServiceRoleForMemoryDB
```
Utilisez le nom du rôle, pas l'ARN, pour faire référence aux opérations de la CLI. Par exemple, si un rôle a l'ARN : `arn:aws:iam::123456789012:role/myrole`, faites référence au rôle en tant que **myrole**.
1. Pour mettre à jour la description d'un rôle lié à un service, utilisez l'opération AWS CLI for IAM. `[update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)`
Pour Linux, macOS ou Unix :
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) \
--role-name AWSServiceRoleForMemoryDB \
--description "new description"
```
Pour Windows :
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) ^
--role-name AWSServiceRoleForMemoryDB ^
--description "new description"
```
### Modification de la description d'un rôle lié à un service (API IAM)
Vous pouvez utiliser l'API IAM pour modifier la description d'un rôle lié à un service.
**Pour changer la description d'un rôle lié à un service (API)**
1. (Facultatif) Pour afficher la description courante d'un rôle, utilisez l'opération d'API IAM [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&AUTHPARAMS
```
1. Pour mettre à jour la description d'un rôle, utilisez l'opération d'API IAM [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&Description="New description"
```
## Supprimer un rôle lié à un service pour MemoryDB
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n’avez aucune entité inutilisée qui n’est pas surveillée ou gérée activement. Cependant, vous devez nettoyer votre rôle lié à un service avant de pouvoir le supprimer.
MemoryDB ne supprime pas le rôle lié au service pour vous.
### Nettoyage d'un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vérifiez d'abord qu'aucune ressource (cluster) n'est associée au rôle.
**Pour vérifier si une session est active pour le rôle lié à un service dans la console IAM**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation de gauche de la console IAM, sélectionnez **Rôles**. Choisissez ensuite le nom (et non la case à cocher) du rôle de AWSService RoleForMemory base de données.
1. Sur la page **Récapitulatif** du rôle sélectionné, choisissez l'onglet **Access Advisor**.
1. Dans l'onglet **Access Advisor**, consultez l'activité récente pour le rôle lié à un service.
**Pour supprimer les ressources MemoryDB qui nécessitent une base de AWSService RoleForMemory données (console)**
+ Pour supprimer un cluster, consultez les rubriques suivantes :
+ [En utilisant le AWS Management Console](getting-started.md#clusters.deleteclusters.viewdetails)
+ [En utilisant le AWS CLI](getting-started.md#clusters.delete.cli)
+ [Utilisation de l'API MemoryDB](getting-started.md#clusters.delete.api)
### Suppression d'un rôle lié à un service (console IAM)
Vous pouvez utiliser la console IAM pour supprimer un rôle lié à un service.
**Pour supprimer un rôle lié à un service (console)**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation de gauche de la console IAM, sélectionnez **Rôles**. Cochez ensuite la case en regard du nom du rôle que vous souhaitez supprimer, sans sélectionner le nom ou la ligne.
1. Pour les actions sur les **Rôle** en haut de la page, sélectionnez **Supprimer**.
1. Sur la page de confirmation, passez en revue les données du dernier accès au service, qui indiquent la date à laquelle chacun des rôles sélectionnés a accédé à un AWS service pour la dernière fois. Cela vous permet de confirmer si le rôle est actif actuellement. Si vous souhaitez continuer, sélectionnez **Oui, supprimer** pour lancer la tâche de suppression du rôle.
1. Consultez les notifications de la console IAM pour surveiller la progression de la suppression du rôle lié à un service. Dans la mesure où la suppression du rôle lié à un service IAM est asynchrone, une fois que vous soumettez le rôle afin qu’il soit supprimé, la suppression peut réussir ou échouer. Si la tâche échoue, vous pouvez choisir **View details** (Afficher les détails) ou **View Resources** (Afficher les ressources) à partir des notifications pour connaître le motif de l'échec de la suppression.
### Suppression d'un rôle lié à un service (CLI IAM)
Vous pouvez utiliser les opérations IAM depuis le AWS Command Line Interface pour supprimer un rôle lié à un service.
**Pour supprimer un rôle lié à un service (CLI)**
1. Si vous ne connaissez pas le nom du rôle lié à un service que vous souhaitez supprimer, saisissez la commande suivante. Cette commande répertorie les rôles et leurs noms de ressources Amazon (ARNs) dans votre compte.
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name role-name
```
Utilisez le nom du rôle, pas l'ARN, pour faire référence aux opérations de la CLI. Par exemple, si un rôle a l'ARN `arn:aws:iam::123456789012:role/myrole`, vous faites référence au rôle en tant que **myrole**.
1. Dans la mesure où un rôle lié à un service ne peut pas être supprimé s'il est utilisé ou si des ressources lui sont associées, vous devez envoyer une demande de suppression. Cette demande peut être refusée si ces conditions ne sont pas satisfaites. Vous devez capturer le `deletion-task-id` de la réponse afin de vérifier l'état de la tâche de suppression. Saisissez la commande suivante pour envoyer une demande de suppression d'un rôle lié à un service.
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) --role-name role-name
```
1. Tapez la commande suivante pour vérifier l'état de la tâche de suppression.
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) --deletion-task-id deletion-task-id
```
L’état de la tâche de suppression peut être `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` ou `FAILED`. Si la suppression échoue, l’appel renvoie le motif de l’échec, afin que vous puissiez apporter une solution.
### Suppression d'un rôle lié à un service (API IAM)
Vous pouvez utiliser l'API IAM pour supprimer un rôle lié à un service.
**Pour supprimer un rôle lié à un service (API)**
1. Pour envoyer une demande de suppression pour un rôle lié à un service, appelez [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html). Dans la demande, spécifiez le nom d'un rôle.
Dans la mesure où un rôle lié à un service ne peut pas être supprimé s'il est utilisé ou si des ressources lui sont associées, vous devez envoyer une demande de suppression. Cette demande peut être refusée si ces conditions ne sont pas satisfaites. Vous devez capturer le `DeletionTaskId` de la réponse afin de vérifier l'état de la tâche de suppression.
1. Pour vérifier l'état de la suppression, appelez [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). Dans la demande, spécifiez le `DeletionTaskId`.
L’état de la tâche de suppression peut être `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED` ou `FAILED`. Si la suppression échoue, l’appel renvoie le motif de l’échec, afin que vous puissiez apporter une solution.
# AWS politiques gérées pour MemoryDB
Pour ajouter des autorisations aux utilisateurs, aux groupes et aux rôles, il est plus facile d'utiliser des politiques AWS gérées que de les rédiger vous-même. Il faut du temps et de l’expertise pour [créer des politiques gérées par le client IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) qui ne fournissent à votre équipe que les autorisations dont elle a besoin. Pour démarrer rapidement, vous pouvez utiliser nos politiques AWS gérées. Ces politiques couvrent les cas d'utilisation courants et sont disponibles dans votre AWS compte. Pour plus d'informations sur les politiques AWS gérées, voir les [politiques AWS gérées](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *guide de l'utilisateur IAM*.
AWS les services maintiennent et mettent à jour les politiques AWS gérées. Vous ne pouvez pas modifier les autorisations dans les politiques AWS gérées. Les services ajoutent occasionnellement des autorisations à une politique gérée par AWS pour prendre en charge de nouvelles fonctionnalités. Ce type de mise à jour affecte toutes les identités (utilisateurs, groupes et rôles) auxquelles la politique est attachée. Les services sont très susceptibles de mettre à jour une politique gérée par AWS quand une nouvelle fonctionnalité est lancée ou quand de nouvelles opérations sont disponibles. Les services ne suppriment pas les autorisations d'une politique AWS gérée. Les mises à jour des politiques n'endommageront donc pas vos autorisations existantes.
En outre, AWS prend en charge les politiques gérées pour les fonctions professionnelles qui couvrent plusieurs services. Par exemple, la politique **ReadOnlyAccess** AWS gérée fournit un accès en lecture seule à tous les AWS services et ressources. Lorsqu'un service lance une nouvelle fonctionnalité, il AWS ajoute des autorisations en lecture seule pour les nouvelles opérations et ressources. Pour obtenir la liste des politiques de fonctions professionnelles et leurs descriptions, consultez la page [politiques gérées par AWS pour les fonctions de tâche](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
## AWS politique gérée : Mémoire DBService RolePolicy
Vous ne pouvez pas associer la politique de DBService RolePolicy AWS gestion de la mémoire aux identités de votre compte. Cette politique fait partie du rôle lié au service AWS MemoryDB. Ce rôle permet au service de gérer les interfaces réseau et les groupes de sécurité de votre compte.
MemoryDB utilise les autorisations définies dans cette politique pour gérer les groupes de sécurité et les interfaces réseau EC2. Cela est nécessaire pour gérer les clusters MemoryDB.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
## AWS-politiques gérées (prédéfinies) pour MemoryDB
AWS répond à de nombreux cas d'utilisation courants en fournissant des politiques IAM autonomes créées et administrées par. AWS Les politiques gérées octroient les autorisations requises dans les cas d’utilisation courants et vous évitent d’avoir à réfléchir aux autorisations qui sont requises. 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 à MemoryDB :
### AmazonMemoryDBReadOnlyAccess
Vous pouvez associer la politique `AmazonMemoryDBReadOnlyAccess` à vos identités IAM. Cette politique accorde des autorisations administratives qui permettent un accès en lecture seule à toutes les ressources MemoryDB.
**AmazonMemoryDBReadOnlyAccess**- Accorde un accès en lecture seule aux ressources MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"
],
"Resource": "*"
}]
}
```
------
### AmazonMemoryDBFullAccès
Vous pouvez associer la politique `AmazonMemoryDBFullAccess` à vos identités IAM. Cette politique accorde des autorisations administratives qui permettent un accès complet à toutes les ressources de MemoryDB.
**AmazonMemoryDBFullAccès** : accorde un accès complet aux ressources de MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws-cn:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
Vous pouvez également créer vos propres politiques IAM personnalisées pour autoriser les actions de l'API MemoryDB. Vous pouvez attacher ces politiques personnalisées aux utilisateurs ou groupes IAM qui nécessitent ces autorisations.
## Mises à jour de MemoryDB pour les politiques gérées AWS
Consultez les détails des mises à jour des politiques AWS gérées pour MemoryDB depuis que ce service a commencé à suivre ces modifications. Pour recevoir des alertes automatiques concernant les modifications apportées à cette page, abonnez-vous au flux RSS sur la page d'historique des documents de MemoryDB.
| Modifier | Description | Date |
| --- | --- | --- |
| [AWS politique gérée : Mémoire DBService RolePolicy](#security-iam-awsmanpol-memorydbServiceRolePolicy)— Ajout d'une politique | Memory DBService RolePolicy a ajouté l'autorisation pour memorydb :. ReplicateMultiRegionClusterData Cette autorisation permettra au rôle lié au service de répliquer les données pour les clusters multirégionaux MemoryDB. | 01/12/2024 |
| [AmazonMemoryDBFullAccès](#iam.identitybasedpolicies.predefinedpolicies-fullaccess)— Ajout d'une politique | MemoryDB a ajouté de nouvelles autorisations pour décrire et répertorier les ressources prises en charge. Ces autorisations sont requises pour que MemoryDB puisse interroger toutes les ressources prises en charge dans un compte. | 07/10/2021 |
| [AmazonMemoryDBReadOnlyAccess](#iam.identitybasedpolicies.predefinedpolicies-readonly)— Ajout d'une politique | MemoryDB a ajouté de nouvelles autorisations pour décrire et répertorier les ressources prises en charge. Ces autorisations sont requises pour que MemoryDB puisse créer des applications basées sur un compte en interrogeant toutes les ressources prises en charge dans un compte. | 07/10/2021 |
| MemoryDB a commencé à suivre les modifications | Lancement de service | 19/08/2021 |
# Autorisations de l'API MemoryDB : référence aux actions, aux ressources et aux conditions
Lorsque vous configurez le [contrôle d'accès](iam.md#iam.accesscontrol) et que vous écrivez des politiques d'autorisation à associer à une stratégie IAM (basée sur l'identité ou sur les ressources), utilisez le tableau suivant comme référence. Le tableau répertorie chaque opération de l'API MemoryDB et les actions correspondantes pour lesquelles vous pouvez accorder des autorisations pour effectuer l'action. Vous spécifiez les actions dans le champ `Action` de la politique ainsi qu’une valeur des ressources dans le champ `Resource` de la politique. Sauf indication contraire, la ressource est requise. Certains champs incluent à la fois une ressource obligatoire et des ressources facultatives. Lorsqu'il n'y a pas d'ARN de ressource, la ressource de la politique est un caractère générique (\$1).
**Note**
Pour indiquer une action, utilisez le préfixe `memorydb:` suivi du nom de l'opération d'API (par exemple, `memorydb:DescribeClusters`).
Utilisez les barres de défilement pour voir le reste du tableau.
**API MemoryDB et autorisations requises pour les actions**
| Opérations de l'API MemoryDB | Autorisations requises (actions API) | Ressources |
| --- | --- | --- |
| [BatchUpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_BatchUpdateCluster.html) | `memorydb:BatchUpdateCluster` | Cluster |
| [CopySnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CopySnapshot.html) | `memorydb:CopySnapshot` `memorydb:TagResource` `s3:GetBucketLocation` `s3:ListAllMyBuckets` | Instantané (source, cible) \$1 \$1 |
| [CreateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateCluster.html) | `memorydb:CreateCluster` `memorydb:TagResource` `s3:GetObject` Si vous utilisez le paramètre `SnapshotArns`, chaque membre de la liste `SnapshotArns` doit avoir sa propre autorisation `s3:GetObject` avec l'ARN `s3` comme ressource. | Groupe de paramètres. (Facultatif) cluster, instantané, identifiants de groupe de sécurité et groupe de sous-réseaux `arn:aws:s3:::my_bucket/snapshot1.rdb` Où*my\$1bucket*/*snapshot1*représente un compartiment S3 et un instantané à partir desquels vous souhaitez créer le cluster. |
| [CreateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateParameterGroup.html) | `memorydb:CreateParameterGroup` `memorydb:TagResource` | Groupe de paramètres |
| [CreateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSubnetGroup.html) | `memorydb:CreateSubnetGroup` `memorydb:TagResource` | Groupe de sous-réseaux | \$1 |
| [CreateSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSnapshot.html) | `memorydb:CreateSnapshot` `memorydb:TagResource` | Instantané, cluster |
| [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) | `memorydb:CreateUser` `memorydb:TagResource` | Utilisateur |
| [Créer un ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateACL.html) | `memorydb:CreateACL` `memorydb:TagResource` | Liste de contrôle d'accès (ACL) |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | Cluster |
| [DeleteCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteCluster.html) | `memorydb:DeleteCluster` | Cluster. (Facultatif) Instantané |
| [DeleteParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteParameterGroup.html) | `memorydb:DeleteParameterGroup` | Groupe de paramètres |
| [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html) | `memorydb:DeleteSubnetGroup` | Groupe de sous-réseaux |
| [DeleteSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSnapshot.html) | `memorydb:DeleteSnapshot` | Instantané |
| [DeleteUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteUser.html) | `memorydb:DeleteUser` | Utilisateur |
| [Supprimer l'ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteACL.html) | `memorydb:DeleteACL` | ACL |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeEngineVersions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEngineVersions.html) | `memorydb:DescribeEngineVersions` | Aucun ARN de ressource :\$1 |
| [DescribeParameterGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameterGroups.html) | `memorydb:DescribeParameterGroups` | Groupe de paramètres |
| [DescribeParameters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameters.html) | `memorydb:DescribeParameters` | Groupe de paramètres |
| [DescribeSubnetGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSubnetGroups.html) | `memorydb:DescribeSubnetGroups` | Groupe de sous-réseaux | \$1 |
| [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) | `memorydb:DescribeEvents` | Aucun ARN de ressource :\$1 |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeServiceUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html) | `memorydb:DescribeServiceUpdates` | Aucun ARN de ressource :\$1 |
| [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html) | `memorydb:DescribeSnapshots` | Instantané |
| [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) | `memorydb:DescribeUsers` | Utilisateur |
| [DécrireACLs](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeACLs.html) | `memorydb:DescribeACLs` | ACLs |
| [ListAllowedNodeTypeUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListAllowedNodeTypeUpdates.html) | `memorydb:ListAllowedNodeTypeUpdates` | Cluster |
| [ListTags](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListTags.html) | `memorydb:ListTags` | (Facultatif) cluster, instantané |
| [UpdateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateParameterGroup.html) | `memorydb:UpdateParameterGroup` | Groupe de paramètres |
| [UpdateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateSubnetGroup.html) | `memorydb:UpdateSubnetGroup` | Groupe de sous-réseaux |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | grappe. (Facultatif) Groupe de paramètres, groupe de sécurité |
| [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) | `memorydb:UpdateUser` | Utilisateur |
| [Mettre à jour l'ACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateACL.html) | `memorydb:UpdateACL` | ACL |
| [UntagResource](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UntagResource.html) | `memorydb:UntagResource` | (Facultatif) Cluster, instantané |
| [ResetParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ResetParameterGroup.html) | `memorydb:ResetParameterGroup` | Groupe de paramètres |
| [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html) | `memorydb:FailoverShard` | grappe, fragment |