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.
# Protection des données dans MemoryDB
Le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) de s'applique à la protection des données dans. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *.
À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*.
+ Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec ou d'autres Services AWS utilisateurs de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
# Sécurité des données dans MemoryDB
Pour garantir la sécurité de vos données, MemoryDB et Amazon EC2 fournissent des mécanismes de protection contre tout accès non autorisé à vos données sur le serveur.
MemoryDB fournit également des fonctionnalités de chiffrement pour les données des clusters :
+ Le chiffrement des données en transit chiffre vos données lorsqu'elles sont déplacées d'un emplacement à un autre, par exemple de nœuds vers un cluster ou entre votre cluster et votre application.
+ Le chiffrement au repos chiffre le journal des transactions et vos données sur disque lors des opérations de capture instantanée.
Vous pouvez également l'utiliser [Authentification des utilisateurs à l'aide de listes de contrôle d'accès () ACLs](clusters.acls.md) pour contrôler l'accès des utilisateurs à vos clusters.
**Topics**
+ [Sécurité des données dans MemoryDB](encryption.md)
+ [Chiffrement au repos dans MemoryDB](at-rest-encryption.md)
+ [Chiffrement en transit (TLS) dans MemoryDB](in-transit-encryption.md)
+ [Authentification des utilisateurs à l'aide de listes de contrôle d'accès () ACLs](clusters.acls.md)
+ [Authentification avec IAM](auth-iam.md)
# Chiffrement au repos dans MemoryDB
Pour garantir la sécurité de vos données, MemoryDB et Amazon S3 proposent différentes méthodes pour restreindre l'accès aux données de vos clusters. Pour plus d’informations, consultez [MemoryDB et Amazon VPC](vpcs.md) et [Gestion des identités et des accès dans MemoryDB](iam.md).
Le chiffrement au repos de MemoryDB est toujours activé pour renforcer la sécurité des données en chiffrant les données persistantes. Il chiffre les aspects suivants :
+ Données du journal des transactions
+ Disque pendant les opérations de synchronisation, de capture d'écran et de swap
+ Instantanés stockés dans Amazon S3
MemoryDB propose un chiffrement par défaut (géré par le service) au repos, ainsi que la possibilité d'utiliser vos propres clés racine symétriques gérées par le client dans le [service de gestion des AWS clés (](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)KMS).
Les données stockées sur SSDs (disques SSD) dans des clusters compatibles avec la hiérarchisation des données sont toujours chiffrées par défaut.
Pour plus d'informations sur le chiffrement en transit, veuillez consulter [Chiffrement en transit (TLS) dans MemoryDB](in-transit-encryption.md).
**Topics**
+ [Utilisation de clés gérées par le client à partir de AWS KMS](#using-customer-managed-keys-for-memorydb-security)
+ [consultez aussi](#at-rest-encryption-see-also)
## Utilisation de clés gérées par le client à partir de AWS KMS
MemoryDB prend en charge les clés racines symétriques gérées par le client (clé KMS) pour le chiffrement au repos. Les clés KMS gérées par le client sont des clés de chiffrement que vous créez, détenez et gérez dans votre AWS compte. Pour plus d'informations, voir [Customer Root Keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) dans le *Guide du développeur du service de gestion des AWS clés*. Les clés doivent être créées dans AWS KMS avant de pouvoir être utilisées avec MemoryDB.
Pour savoir comment créer des clés racines AWS KMS, consultez la section [Création de clés](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) dans le *guide du développeur du service de gestion des AWS clés*.
MemoryDB vous permet de vous intégrer à KMS. AWS Pour plus d'informations, veuillez consulter [Utilisation d'octrois](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) dans le *Guide du développeur AWS Key Management Service*. Aucune action du client n'est requise pour activer l'intégration de MemoryDB avec AWS KMS.
La clé de `kms:ViaService` condition limite l'utilisation d'une clé AWS KMS aux demandes provenant de AWS services spécifiques. À utiliser `kms:ViaService` avec MemoryDB, incluez les deux ViaService noms dans la valeur de la clé de condition :. `memorydb.amazon_region.amazonaws.com` Pour plus d'informations, voir [kms : ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service).
Vous pouvez l'utiliser [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)pour suivre les demandes que MemoryDB envoie en votre AWS Key Management Service nom. Tous les appels d'API AWS Key Management Service liés aux clés gérées par le client ont CloudTrail des journaux correspondants. Vous pouvez également voir les autorisations créées par MemoryDB en appelant l'appel d'API [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html)KMS.
Une fois qu'un cluster est chiffré à l'aide d'une clé gérée par le client, tous les instantanés du cluster sont chiffrés comme suit :
+ Les instantanés quotidiens automatiques sont chiffrés à l'aide de la clé gérée par le client associée au cluster.
+ L'instantané final créé lorsque le cluster est supprimé est également chiffré à l'aide de la clé gérée par le client associée au cluster.
+ Les instantanés créés manuellement sont chiffrés par défaut pour utiliser la clé KMS associée au cluster. Vous pouvez la remplacer en choisissant une autre clé gérée par le client.
+ La copie d'un instantané utilise par défaut la clé gérée par le client associée à l'instantané source. Vous pouvez la remplacer en choisissant une autre clé gérée par le client.
**Note**
Les clés gérées par le client ne peuvent pas être utilisées lors de l'exportation d'instantanés vers le compartiment Amazon S3 que vous avez sélectionné. Cependant, tous les instantanés exportés vers Amazon S3 sont chiffrés à l'aide [du chiffrement côté serveur](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). Vous pouvez choisir de copier le fichier instantané sur un nouvel objet S3 et de le chiffrer à l'aide d'une clé KMS gérée par le client, de copier le fichier dans un autre compartiment S3 configuré avec le chiffrement par défaut à l'aide d'une clé KMS ou de modifier une option de chiffrement dans le fichier lui-même.
Vous pouvez également utiliser des clés gérées par le client pour chiffrer des instantanés créés manuellement qui n'utilisent pas de clés gérées par le client pour le chiffrement. Avec cette option, le fichier de capture enregistré dans Amazon S3 est chiffré à l'aide d'une clé KMS, même si les données ne sont pas chiffrées sur le cluster d'origine.
La restauration à partir d'un instantané vous permet de choisir parmi les options de chiffrement disponibles, à l'instar des options de chiffrement disponibles lors de la création d'un nouveau cluster.
+ Si vous supprimez la clé ou si vous la [désactivez](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) et que vous [révoquez les autorisations](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) relatives à la clé que vous avez utilisée pour chiffrer un cluster, celui-ci devient irrécupérable. En d'autres termes, il ne peut pas être modifié ou restauré après une panne matérielle. AWS KMS supprime les clés racines uniquement après une période d'attente d'au moins sept jours. Une fois la clé supprimée, vous pouvez utiliser une autre clé gérée par le client pour créer un instantané à des fins d'archivage.
+ La rotation automatique des clés préserve les propriétés de vos clés racines AWS KMS, de sorte que la rotation n'a aucun effet sur votre capacité à accéder à vos données MemoryDB. Les clusters MemoryDB chiffrés ne prennent pas en charge la rotation manuelle des clés, qui implique la création d'une nouvelle clé racine et la mise à jour des références à l'ancienne clé. Pour en savoir plus, consultez [Rotating Customer root keys](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) dans le *Guide du développeur du service de gestion des AWS clés*.
+ Le chiffrement d'un cluster MemoryDB à l'aide d'une clé KMS nécessite une autorisation par cluster. Cette subvention est utilisée pendant toute la durée de vie du cluster. En outre, une subvention par instantané est utilisée lors de la création de l'instantané. Cette subvention est retirée une fois le cliché créé.
+ Pour plus d'informations sur les autorisations et les limites AWS KMS, consultez la section [Quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) du *Guide du développeur du service de gestion des AWS clés*.
## consultez aussi
+ [Chiffrement en transit (TLS) dans MemoryDB](in-transit-encryption.md)
+ [MemoryDB et Amazon VPC](vpcs.md)
+ [Gestion des identités et des accès dans MemoryDB](iam.md)
# Chiffrement en transit (TLS) dans MemoryDB
Pour garantir la sécurité de vos données, MemoryDB et Amazon EC2 fournissent des mécanismes de protection contre tout accès non autorisé à vos données sur le serveur. En fournissant une fonctionnalité de chiffrement en transit, MemoryDB vous fournit un outil que vous pouvez utiliser pour protéger vos données lorsqu'elles sont déplacées d'un endroit à un autre. Par exemple, vous pouvez déplacer des données d'un nœud principal vers un nœud de réplication en lecture au sein d'un cluster, ou entre votre cluster et votre application.
**Topics**
+ [Présentation du chiffrement en transit](#in-transit-encryption-overview)
+ [Consultez aussi](#in-transit-encryption-see-also)
## Présentation du chiffrement en transit
Le chiffrement en transit de MemoryDB est une fonctionnalité qui renforce la sécurité de vos données aux points les plus vulnérables, c'est-à-dire lorsqu'elles sont en transit d'un endroit à un autre.
Le chiffrement en transit de MemoryDB implémente les fonctionnalités suivantes :
+ **Connexions cryptées : les connexions** au serveur et au client sont cryptées par le protocole TLS (Transport Layer Security).
+ **Réplication chiffrée** : les données transférées entre un nœud primaire et des nœuds en réplica sont chiffrées.
+ **Authentification du serveur** : les clients peuvent authentifier leur connexion au bon serveur.
Depuis le 20/07/2023, TLS 1.2 est la version minimale prise en charge pour les clusters nouveaux et existants. Utilisez ce [lien](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/) pour en savoir plus sur le protocole TLS 1.2 à l'adresse AWS.
Pour plus d'informations sur la connexion aux clusters MemoryDB, consultez. [Connexion aux nœuds MemoryDB à l'aide de redis-cli](getting-started.md#connect-tls)
## Consultez aussi
+ [Chiffrement au repos dans MemoryDB](at-rest-encryption.md)
+ [Authentification des utilisateurs à l'aide de listes de contrôle d'accès () ACLs](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)
+ [MemoryDB et Amazon VPC](vpcs.md)
+ [Gestion des identités et des accès dans MemoryDB](iam.md)
# Authentification des utilisateurs à l'aide de listes de contrôle d'accès () ACLs
Vous pouvez authentifier les utilisateurs à l'aide de listes de contrôle d'accès (ACLs).
ACLs vous permettent de contrôler l'accès au cluster en regroupant les utilisateurs. Ces listes de contrôle d'accès sont conçues pour organiser l'accès aux clusters.
Avec ACLs, vous créez des utilisateurs et leur attribuez des autorisations spécifiques à l'aide d'une chaîne d'accès, comme décrit dans la section suivante. Vous assignez les utilisateurs à des listes de contrôle d'accès alignées sur un rôle spécifique (administrateurs, ressources humaines) qui sont ensuite déployées sur un ou plusieurs clusters MemoryDB. Vous pouvez ainsi établir des limites de sécurité entre les clients utilisant le ou les mêmes clusters MemoryDB et empêcher les clients d'accéder aux données des autres.
ACLs sont conçus pour prendre en charge l'introduction de l'[ACL](https://valkey.io/docs/topics/acl/) dans Redis OSS 6. Lorsque vous l'utilisez ACLs avec votre cluster MemoryDB, certaines limites s'appliquent :
+ Vous ne pouvez pas spécifier de mots de passe dans une chaîne d'accès. Vous définissez des mots de passe avec [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html)ou par [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html)appels.
+ Pour les droits d'utilisateur, vous passez `on` et `off` dans le cadre de la chaîne d'accès. Si aucune des deux n'est spécifiée dans la chaîne d'accès, l'utilisateur est affecté au cluster `off` et ne dispose pas de droits d'accès.
+ Vous ne pouvez pas utiliser de commandes interdites. Si vous spécifiez une commande interdite, une exception sera émise. Pour obtenir la liste de ces commandes, consultez[Commandes limitées](restrictedcommands.md).
+ Vous ne pouvez pas utiliser la commande `reset` dans le cadre d'une chaîne d'accès. Vous spécifiez les mots de passe avec les paramètres de l'API, et MemoryDB gère les mots de passe. Par conséquent, vous ne pouvez pas utiliser `reset` car il supprimerait tous les mots de passe d'un utilisateur.
+ Redis OSS 6 introduit la commande [ACL LIST](https://valkey.io/commands/acl-list). Cette commande renvoie une liste d'utilisateurs ainsi que les règles de liste ACL appliquées à chaque utilisateur. MemoryDB prend en charge la `ACL LIST` commande, mais ne prend pas en charge le hachage des mots de passe comme le fait Redis OSS. Avec MemoryDB, vous pouvez utiliser l'[DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html)opération pour obtenir des informations similaires, y compris les règles contenues dans la chaîne d'accès. Cependant, [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html)ne permet pas de récupérer le mot de passe utilisateur.
[Les autres commandes en lecture seule prises en charge par MemoryDB incluent [ACL WHOAMI, ACL USERS](https://valkey.io/commands/acl-whoami) et [ACL CAT](https://valkey.io/commands/acl-users).](https://valkey.io/commands/acl-cat) MemoryDB ne prend en charge aucune autre commande ACL basée sur l'écriture.
L'utilisation ACLs avec MemoryDB est décrite plus en détail ci-dessous.
**Topics**
+ [Définition des autorisations à l'aide d'une chaîne d'accès](#access-string)
+ [Capacités de recherche vectorielle](#access-vss)
+ [Appliquer ACLs à un cluster pour MemoryDB](#rbac-using)
## Définition des autorisations à l'aide d'une chaîne d'accès
Pour spécifier les autorisations d'accès à un cluster MemoryDB, vous créez une chaîne d'accès et vous l'attribuez à un utilisateur en utilisant le AWS CLI ou. AWS Management Console
Les chaînes d'accès sont définies comme une liste de règles délimitées par des espaces qui sont appliquées à l'utilisateur. Elles définissent les commandes qu'un utilisateur peut exécuter et les clés qu'un utilisateur peut utiliser. Pour exécuter une commande, un utilisateur doit avoir accès à la commande en cours d'exécution et à toutes les clés accessibles par la commande. Les règles sont appliquées de gauche à droite de manière cumulative, et une chaîne plus simple peut être utilisée à la place de celle fournie en cas de redondance dans la chaîne fournie.
Pour plus d'informations sur la syntaxe des règles de liste ACL, veuillez consulter [Listes ACL](https://valkey.io/topics/acl).
Dans l'exemple suivant, la chaîne d'accès représente un utilisateur actif ayant accès à toutes les clés et commandes disponibles.
`on ~* &* +@all`
La syntaxe de la chaîne d'accès se décompose comme suit :
+ `on` : l'utilisateur est un utilisateur actif.
+ `~*` : l'accès est accordé à toutes les clés disponibles.
+ `&*`— L'accès est donné à toutes les chaînes pubsub.
+ `+@all` : l'accès est accordé à toutes les commandes disponibles.
Les paramètres précédents sont les moins restrictifs. Vous pouvez modifier ces paramètres pour les rendre plus sécurisés.
Dans l'exemple suivant, la chaîne d'accès représente un utilisateur dont l'accès est restreint à l'accès en lecture sur les clés commençant par un keyspace « app:: »
`on ~app::* -@all +@read`
Vous pouvez affiner ces autorisations en listant les commandes auxquelles l'utilisateur a accès :
`+command1` : l'accès de l'utilisateur aux commandes est limité à *`command1`*.
`+@category` : l'accès de l'utilisateur est limité à une catégorie de commandes.
Pour plus d'informations sur l'attribution d'une chaîne d'accès à un utilisateur, veuillez consulter [Création d'utilisateurs et de listes de contrôle d'accès à l'aide de la console et de la CLI](#users-management).
Si vous migrez une charge de travail existante vers MemoryDB, vous pouvez récupérer la chaîne d'accès en appelant`ACL LIST`, en excluant l'utilisateur et tout hachage de mot de passe.
## Capacités de recherche vectorielle
En [Recherche vectorielle](vector-search.md) effet, toutes les commandes de recherche appartiennent à la `@search` catégorie et aux catégories existantes `@read``@write`, `@fast` et `@slow` sont mises à jour pour inclure les commandes de recherche. Si un utilisateur n'a pas accès à une catégorie, il n'a accès à aucune commande de cette catégorie. Par exemple, si l'utilisateur n'y a pas accès`@search`, il ne peut exécuter aucune commande liée à la recherche.
Le tableau suivant indique le mappage des commandes de recherche vers les catégories appropriées.
| Commandes VSS | @read | @write | @fast | @slow |
| --- | --- | --- | --- | --- |
| FT.CREATE | | Y | Y | |
| FT.DROPINDEX | | Y | Y | |
| FT.LIST | Y | | | Y |
| FT.INFO | Y | | Y | |
| FT.SEARCH | Y | | | Y |
| FT.AGGREGATE | Y | | | Y |
| FT.PROFILE | Y | | | Y |
| FT.ALIASADD | | Y | Y | |
| FT.ALIASDEL | | Y | Y | |
| FT.ALIASUPDATE | | Y | Y | |
| FT.\$1ALIASLIST | Y | | | Y |
| FT.EXPLAIN | Y | | Y | |
| FT.EXPLAINCLI | Y | | Y | |
| FT.CONFIG | Y | | Y | |
## Appliquer ACLs à un cluster pour MemoryDB
Pour utiliser MemoryDB ACLs, vous devez suivre les étapes suivantes :
1. Créez un ou plusieurs utilisateurs.
1. Créez une ACL et ajoutez des utilisateurs à la liste.
1. Assignez l'ACL à un cluster.
Ces étapes sont décrites en détail ci-dessous.
**Topics**
+ [Création d'utilisateurs et de listes de contrôle d'accès à l'aide de la console et de la CLI](#users-management)
+ [Gestion des listes de contrôle d'accès avec la console et la CLI](#user-groups)
+ [Affectation de listes de contrôle d'accès aux clusters](#users-groups-to-clusterss)
### Création d'utilisateurs et de listes de contrôle d'accès à l'aide de la console et de la CLI
Les informations utilisateur pour ACLs les utilisateurs sont un nom d'utilisateur, et éventuellement un mot de passe et une chaîne d'accès. La chaîne d'accès fournit le niveau d'autorisation relatif aux clés et commandes. Le nom est propre à l'utilisateur et est transmis au moteur.
Assurez-vous que les autorisations utilisateur que vous fournissez correspondent à l'objectif de l'ACL. Par exemple, si vous créez une ACL appelée`Administrators`, la chaîne d'accès de tout utilisateur que vous ajoutez à ce groupe doit être définie de manière à avoir un accès complet aux touches et aux commandes. Pour les utilisateurs d'une `e-commerce` ACL, vous pouvez définir leurs chaînes d'accès en lecture seule.
MemoryDB configure automatiquement un utilisateur par défaut par compte avec un nom d'utilisateur. `"default"` Il ne sera associé à aucun cluster sauf s'il est explicitement ajouté à une ACL. Vous ne pouvez pas le supprimer ou le modifier. Cet utilisateur est destiné à être compatible avec le comportement par défaut des versions précédentes de Redis OSS et dispose d'une chaîne d'accès qui lui permet d'appeler toutes les commandes et d'accéder à toutes les touches.
Une ACL « open access » immuable sera créée pour chaque compte contenant l'utilisateur par défaut. Il s'agit de la seule ACL dont l'utilisateur par défaut peut être membre. Lorsque vous créez un cluster, vous devez sélectionner une ACL à associer au cluster. Bien que vous ayez la possibilité d'appliquer l'ACL « libre accès » à l'utilisateur par défaut, nous vous recommandons vivement de créer une ACL avec des utilisateurs dont les autorisations sont limitées à leurs besoins commerciaux.
Les clusters sur lesquels le protocole TLS n'est pas activé doivent utiliser l'ACL « open access » pour fournir une authentification ouverte.
ACLs peut être créé sans aucun utilisateur. Une ACL vide n'aurait aucun accès à un cluster et ne pourrait être associée qu'à des clusters compatibles TLS.
Lors de la création d'un utilisateur, vous pouvez configurer jusqu'à deux mots de passe. Lorsque vous modifiez un mot de passe, toutes les connexions existantes aux clusters sont conservées.
Tenez compte en particulier de ces contraintes liées au mot de passe utilisateur lors de l'utilisation ACLs de MemoryDB :
+ Les mots de passe doivent comporter de 16 à 128 caractères imprimables.
+ Les caractères non alphanumériques suivants ne sont pas autorisés : `,` `""` `/` `@`.
#### Gestion des utilisateurs avec la console et la CLI
##### Création d'un utilisateur (console)
**Pour créer des utilisateurs sur la console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, sélectionnez **Utilisateurs**.
1. Sélectionnez **Créer un utilisateur**
1. Sur la page **Créer un utilisateur**, entrez un **nom**.
Les contraintes d'attribution de noms de cluster sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
1. Sous **Mots de passe**, vous pouvez saisir jusqu'à deux mots de passe.
1. Sous **Chaîne d'accès**, entrez une chaîne d'accès. La chaîne d'accès définit le niveau d'autorisation accordé à l'utilisateur pour les clés et commandes.
1. Pour les **tags**, vous pouvez éventuellement appliquer des tags pour rechercher et filtrer vos utilisateurs ou suivre vos AWS coûts.
1. Choisissez **Créer**.
##### Création d'un utilisateur à l'aide du AWS CLI
**Pour créer un utilisateur à l'aide de la CLI**
+ Utilisez la commande [create-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-user.html) pour créer un utilisateur.
Pour Linux, macOS ou Unix :
```
aws memorydb create-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode \
Passwords="abc",Type=password
```
Pour Windows :
```
aws memorydb create-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode \
Passwords="abc",Type=password
```
##### Modifier un utilisateur (console)
**Pour modifier les utilisateurs sur la console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, sélectionnez **Utilisateurs**.
1. Cliquez sur le bouton radio à côté de l'utilisateur que vous souhaitez modifier, puis choisissez **Actions** -> **Modifier**
1. Si vous souhaitez modifier un mot de passe, cliquez sur le bouton radio **Modifier les mots de passe**. Notez que si vous avez deux mots de passe, vous devez saisir les deux lorsque vous modifiez l'un d'entre eux.
1. Si vous mettez à jour la chaîne d'accès, entrez la nouvelle.
1. Sélectionnez **Modifier**.
##### Modifier un utilisateur à l'aide de AWS CLI
**Pour modifier un utilisateur à l'aide de la CLI**
1. Utilisez la commande [update-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-user.html) pour modifier un utilisateur.
1. Lorsqu'un utilisateur est modifié, les listes de contrôle d'accès associées à l'utilisateur sont mises à jour, ainsi que tous les clusters associés à l'ACL. Toutes les connexions existantes sont maintenues. Voici quelques exemples.
Pour Linux, macOS ou Unix :
```
aws memorydb update-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*"
```
Pour Windows :
```
aws memorydb update-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*"
```
##### Afficher les détails de l'utilisateur (console)
**Pour afficher les détails de l'utilisateur sur la console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, sélectionnez **Utilisateurs**.
1. Choisissez l'utilisateur sous **Nom d'utilisateur** ou utilisez le champ de recherche pour trouver l'utilisateur.
1. Dans **Paramètres utilisateur**, vous pouvez consulter la chaîne d'accès, le nombre de mots de passe, le statut et le nom de ressource Amazon (ARN) de l'utilisateur.
1. Sous **Listes de contrôle d'accès (ACL)**, vous pouvez consulter l'ACL à laquelle appartient l'utilisateur.
1. Sous **Tags**, vous pouvez consulter tous les tags associés à l'utilisateur.
##### Afficher les détails de l'utilisateur à l'aide du AWS CLI
Utilisez la commande [describe-users](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-users.html) pour afficher les détails d'un utilisateur.
```
aws memorydb describe-users \
--user-name my-user-name
```
##### Supprimer un utilisateur (console)
**Pour supprimer des utilisateurs sur la console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, sélectionnez **Utilisateurs**.
1. Cliquez sur le bouton radio à côté de l'utilisateur que vous souhaitez modifier, puis choisissez **Actions** -> **Supprimer**
1. Pour confirmer, entrez `delete` dans la zone de texte de confirmation, puis choisissez **Supprimer**.
1. Pour annuler, choisissez **Cancel (Annuler)**.
##### Supprimer un utilisateur à l'aide du AWS CLI
**Pour supprimer un utilisateur à l'aide de la CLI**
+ Utilisez la commande [delete-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-user.html) pour supprimer un utilisateur.
Le compte est supprimé et retiré de toutes les listes de contrôle d'accès auxquelles il appartient. Voici un exemple.
Pour Linux, macOS ou Unix :
```
aws memorydb delete-user \
--user-name user-name-2
```
Pour Windows :
```
aws memorydb delete-user ^
--user-name user-name-2
```
### Gestion des listes de contrôle d'accès avec la console et la CLI
Vous pouvez créer des listes de contrôle d'accès pour organiser et contrôler l'accès des utilisateurs à un ou plusieurs clusters, comme indiqué ci-dessous.
Utilisez la procédure suivante pour gérer les listes de contrôle d'accès à l'aide de la console.
#### Création d'une liste de contrôle d'accès (ACL) (console)
**Pour créer une liste de contrôle d'accès à l'aide de la console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, choisissez **Listes de contrôle d'accès (ACL)**.
1. Choisissez **Create ACL**.
1. Sur la page **Créer une liste de contrôle d'accès (ACL)**, entrez un nom d'ACL.
Les contraintes d'attribution de noms de cluster sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
1. Sous **Utilisateurs sélectionnés**, effectuez l'une des opérations suivantes :
1. Créez un nouvel utilisateur en choisissant **Créer un utilisateur**
1. Ajoutez des utilisateurs en choisissant **Gérer**, puis en sélectionnant des utilisateurs dans la boîte de dialogue **Gérer les utilisateurs**, puis en sélectionnant **Choisir**.
1. Pour les **balises**, vous pouvez éventuellement appliquer des balises pour rechercher et filtrer vos coûts ACLs ou suivre vos AWS coûts.
1. Choisissez **Créer**.
#### Création d'une liste de contrôle d'accès (ACL) à l'aide du AWS CLI
Utilisez les procédures suivantes pour créer une liste de contrôle d'accès à l'aide de la CLI.
**Pour créer une nouvelle ACL et ajouter un utilisateur à l'aide de la CLI**
+ Utilisez la commande [create-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-acl.html) pour créer une ACL.
Pour Linux, macOS ou Unix :
```
aws memorydb create-acl \
--acl-name "new-acl-1" \
--user-names "user-name-1" "user-name-2"
```
Pour Windows :
```
aws memorydb create-acl ^
--acl-name "new-acl-1" ^
--user-names "user-name-1" "user-name-2"
```
#### Modifier une liste de contrôle d'accès (ACL) (console)
**Pour modifier une liste de contrôle d'accès à l'aide de la console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, choisissez **Listes de contrôle d'accès (ACL)**.
1. Choisissez l'ACL que vous souhaitez modifier, puis choisissez **Modifier**
1. Sur la page **Modifier**, sous **Utilisateurs sélectionnés**, effectuez l'une des opérations suivantes :
1. Créez un nouvel utilisateur en choisissant **Create user** à ajouter à l'ACL.
1. Ajoutez ou supprimez des utilisateurs en choisissant **Gérer**, puis en sélectionnant ou désélectionnant des utilisateurs dans la boîte de dialogue **Gérer les utilisateurs**, puis en sélectionnant **Choisir**.
1. Sur la page **Créer une liste de contrôle d'accès (ACL)**, entrez un nom d'ACL.
Les contraintes d'attribution de noms de cluster sont les suivantes :
+ Doit contenir entre 1 et 40 caractères alphanumériques ou traits d'union.
+ Doit commencer par une lettre.
+ Ils ne peuvent pas comporter deux traits d'union consécutifs.
+ Ils ne peuvent pas se terminer par un trait d'union.
1. Sous **Utilisateurs sélectionnés**, effectuez l'une des opérations suivantes :
1. Créez un nouvel utilisateur en choisissant **Créer un utilisateur**
1. Ajoutez des utilisateurs en choisissant **Gérer**, puis en sélectionnant des utilisateurs dans la boîte de dialogue **Gérer les utilisateurs**, puis en sélectionnant **Choisir**.
1. Choisissez **Modifier** pour enregistrer vos modifications ou **Annuler** pour les ignorer.
#### Modification d'une liste de contrôle d'accès (ACL) à l'aide du AWS CLI
**Pour modifier une ACL en ajoutant de nouveaux utilisateurs ou en supprimant des membres actuels à l'aide de la CLI**
+ Utilisez la commande [update-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-acl.html) pour modifier une ACL.
Pour Linux, macOS ou Unix :
```
aws memorydb update-acl --acl-name new-acl-1 \
--user-names-to-add user-name-3 \
--user-names-to-remove user-name-2
```
Pour Windows :
```
aws memorydb update-acl --acl-name new-acl-1 ^
--user-names-to-add user-name-3 ^
--user-names-to-remove user-name-2
```
**Note**
Cette commande met fin à toutes les connexions ouvertes appartenant à un utilisateur supprimé d'une ACL.
#### Affichage des détails de la liste de contrôle d'accès (ACL) (console)
**Pour afficher les détails de l'ACL sur la console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, choisissez **Listes de contrôle d'accès (ACL)**.
1. Choisissez l'ACL sous le **nom de l'ACL** ou utilisez le champ de recherche pour trouver l'ACL.
1. Sous **Utilisateurs**, vous pouvez consulter la liste des utilisateurs associés à l'ACL.
1. Sous **Clusters associés**, vous pouvez consulter le cluster auquel appartient l'ACL.
1. Sous **Tags**, vous pouvez consulter tous les tags associés à l'ACL.
#### Affichage des listes de contrôle d'accès (ACL) à l'aide du AWS CLI
Utilisez la commande [describe-acls](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-acls.html) pour afficher les détails d'une ACL.
```
aws memorydb describe-acls \
--acl-name test-group
```
#### Supprimer une liste de contrôle d'accès (ACL) (console)
**Pour supprimer des listes de contrôle d'accès à l'aide de la console**
1. Connectez-vous à la console MemoryDB AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Dans le volet de navigation de gauche, choisissez **Listes de contrôle d'accès (ACL)**.
1. Choisissez l'ACL que vous souhaitez modifier, puis choisissez **Supprimer**
1. Sur la page **Supprimer**, entrez `delete` dans la case de confirmation et choisissez **Supprimer** ou **Annuler** pour éviter de supprimer l'ACL.
C'est l'ACL elle-même, et non les utilisateurs appartenant au groupe, qui est supprimée.
#### Suppression d'une liste de contrôle d'accès (ACL) à l'aide du AWS CLI
**Pour supprimer une ACL à l'aide de la CLI**
+ Utilisez la commande [delete-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-acl.html) pour supprimer une ACL.
Pour Linux, macOS ou Unix :
```
aws memorydb delete-acl /
--acl-name
```
Pour Windows :
```
aws memorydb delete-acl ^
--acl-name
```
Les exemples précédents renvoient la réponse suivante.
```
aws memorydb delete-acl --acl-name "new-acl-1"
{
"ACLName": "new-acl-1",
"Status": "deleting",
"EngineVersion": "6.2",
"UserNames": [
"user-name-1",
"user-name-3"
],
"clusters": [],
"ARN":"arn:aws:memorydb:us-east-1:493071037918:acl/new-acl-1"
}
```
### Affectation de listes de contrôle d'accès aux clusters
Après avoir créé une ACL et ajouté des utilisateurs, la dernière étape de la mise en œuvre ACLs consiste à attribuer l'ACL à un cluster.
#### Affectation de listes de contrôle d'accès à des clusters à l'aide de la console
Pour ajouter une ACL à un cluster à l'aide du AWS Management Console, voir[Création d'un cluster MemoryDB](getting-started.md#clusters.create).
#### Affectation de listes de contrôle d'accès à des clusters à l'aide du AWS CLI
L' AWS CLI opération suivante crée un cluster avec le chiffrement en transit (TLS) activé et le **acl-name** paramètre avec la valeur`my-acl-name`. Remplacez le groupe de sous-réseaux `subnet-group` par un groupe de sous-réseaux existant.
**Paramètres clés**
+ **--engine-version**— Doit être 6,2.
+ **--tls-enabled**— Utilisé pour l'authentification et pour associer une ACL.
+ **--acl-name**— Cette valeur fournit des listes de contrôle d'accès composées d'utilisateurs dotés d'autorisations d'accès spécifiées pour le cluster.
Pour Linux, macOS ou Unix :
```
aws memorydb create-cluster \
--cluster-name "new-cluster" \
--description "new-cluster" \
--engine-version "6.2" \
--node-type db.r6g.large \
--tls-enabled \
--acl-name "new-acl-1" \
--subnet-group-name "subnet-group"
```
Pour Windows :
```
aws memorydb create-cluster ^
--cluster-name "new-cluster" ^
--cluster-description "new-cluster" ^
--engine-version "6.2" ^
--node-type db.r6g.large ^
--tls-enabled ^
--acl-name "new-acl-1" ^
--subnet-group-name "subnet-group"
```
L' AWS CLI opération suivante modifie un cluster dont le chiffrement en transit (TLS) est activé et dont le **acl-name** paramètre contient la valeur. `new-acl-2`
Pour Linux, macOS ou Unix :
```
aws memorydb update-cluster \
--cluster-name cluster-1 \
--acl-name "new-acl-2"
```
Pour Windows :
```
aws memorydb update-cluster ^
--cluster-name cluster-1 ^
--acl-name "new-acl-2"
```
# Authentification avec IAM
**Topics**
+ [Présentation de](#auth-iam-overview)
+ [Limitations](#auth-iam-limits)
+ [Configuration](#auth-iam-setup)
+ [Connexion](#auth-iam-Connecting)
## Présentation de
Avec l'authentification IAM, vous pouvez authentifier une connexion à MemoryDB à l'aide d'identités AWS IAM, lorsque votre cluster est configuré pour utiliser Valkey ou Redis OSS version 7 ou supérieure. Cela vous permet de renforcer votre modèle de sécurité et de simplifier de nombreuses tâches administratives de sécurité. Avec l'authentification IAM, vous pouvez configurer un contrôle d'accès précis pour chaque cluster MemoryDB individuel et chaque utilisateur de MemoryDB et suivre les principes d'autorisation du moindre privilège. L'authentification IAM pour MemoryDB fonctionne en fournissant un jeton d'authentification IAM de courte durée au lieu d'un mot de passe utilisateur MemoryDB de longue durée dans la commande or. `AUTH` `HELLO` Pour plus d'informations sur le jeton d'authentification IAM, reportez-vous au [processus de signature Signature version 4](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) du Guide de référence AWS général et à l'exemple de code ci-dessous.
Vous pouvez utiliser les identités IAM et leurs politiques associées pour restreindre davantage l'accès à Valkey ou Redis OSS. Vous pouvez également accorder l'accès aux utilisateurs depuis leurs fournisseurs d'identité fédérés directement aux clusters MemoryDB.
Pour utiliser AWS IAM avec MemoryDB, vous devez d'abord créer un utilisateur MemoryDB avec le mode d'authentification défini sur IAM, puis vous pouvez créer ou réutiliser une identité IAM. L'identité IAM a besoin d'une politique associée pour accorder l'`memorydb:Connect`action au cluster MemoryDB et à l'utilisateur MemoryDB. Une fois configuré, vous pouvez créer un jeton d'authentification IAM à l'aide des AWS informations d'identification de l'utilisateur ou du rôle IAM. Enfin, vous devez fournir le jeton d'authentification IAM de courte durée sous forme de mot de passe dans votre client Valkey ou Redis OSS lorsque vous vous connectez à votre nœud de cluster MemoryDB. Un client prenant en charge le fournisseur d'informations d'identification peut générer automatiquement les informations d'identification temporaires pour chaque nouvelle connexion. MemoryDB effectuera l'authentification IAM pour les demandes de connexion des utilisateurs de MemoryDB compatibles IAM et validera les demandes de connexion avec IAM.
## Limitations
Les limites suivantes s'appliquent avec l'authentification IAM :
+ L'authentification IAM est disponible lors de l'utilisation de Valkey ou du moteur Redis OSS version 7.0 ou supérieure.
+ Le jeton d'authentification IAM est valide pendant 15 minutes. Pour les connexions de longue durée, nous vous recommandons d'utiliser un client Redis OSS qui prend en charge une interface de fournisseur d'informations d'identification.
+ Une connexion authentifiée IAM à MemoryDB sera automatiquement déconnectée au bout de 12 heures. La connexion peut être prolongée de 12 heures en envoyant une commande `AUTH` ou `HELLO` avec un nouveau jeton d'authentification IAM.
+ L'authentification IAM n'est pas prise en charge dans les commandes `MULTI EXEC`.
+ Actuellement, l'authentification IAM ne prend pas en charge toutes les clés de contexte de condition globale. Pour plus d'informations sur les clés de contexte de condition globale, consultez [Clés de contexte de condition globale AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le Guide de l'utilisateur IAM.
## Configuration
Pour configurer une authentification IAM :
1. Créer un cluster
```
aws memorydb create-cluster \
--cluster-name cluster-01 \
--description "MemoryDB IAM auth application"
--node-type db.r6g.large \
--engine-version 7.0 \
--acl-name open-access
```
1. Créez un document de stratégie d'approbation IAM, comme indiqué ci-dessous, pour votre rôle afin d'autoriser votre compte à assumer le nouveau rôle. Enregistrez la politique dans un fichier nommé *trust-policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. Créez un document de politique IAM, comme indiqué ci-dessous. Enregistrez la politique dans un fichier nommé *policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"memorydb:connect"
],
"Resource" : [
"arn:aws:memorydb:us-east-1:123456789012:cluster/cluster-01",
"arn:aws:memorydb:us-east-1:123456789012:user/iam-user-01"
]
}
]
}
```
------
1. Créez un rôle IAM.
```
aws iam create-role \
--role-name "memorydb-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Créez la politique IAM.
```
aws iam create-policy \
--policy-name "memorydb-allow-all" \
--policy-document file://policy.json
```
1. Attachez la politique gérée IAM au rôle.
```
aws iam attach-role-policy \
--role-name "memorydb-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/memorydb-allow-all"
```
1. Créez un compte utilisateur prenant en charge IAM.
```
aws memorydb create-user \
--user-name iam-user-01 \
--authentication-mode Type=iam \
--access-string "on ~* +@all"
```
1. Créez une ACL et attachez l'utilisateur.
```
aws memorydb create-acl \
--acl-name iam-acl-01 \
--user-names iam-user-01
aws memorydb update-cluster \
--cluster-name cluster-01 \
--acl-name iam-acl-01
```
## Connexion
**Se connecter avec un jeton comme mot de passe**
Vous devez d'abord générer le jeton d'authentification IAM de courte durée à l'aide d'une [Demande pré-signée AWS SigV4](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). Ensuite, vous fournissez le jeton d'authentification IAM comme mot de passe lors de la connexion à un cluster MemoryDB, comme indiqué dans l'exemple ci-dessous.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request and signed it using the AWS credentials.
// The pre-signed request URL is used as an IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userName, iamAuthToken)
.build();
// Create a new Lettuce client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Vous trouverez ci-dessous la définition de `IAMAuthTokenRequest`.
```
public class IAMAuthTokenRequest {
private static final HttpMethodName REQUEST_METHOD = HttpMethodName.GET;
private static final String REQUEST_PROTOCOL = "http://";
private static final String PARAM_ACTION = "Action";
private static final String PARAM_USER = "User";
private static final String ACTION_NAME = "connect";
private static final String SERVICE_NAME = "memorydb";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userName;
private final String clusterName;
private final String region;
public IAMAuthTokenRequest(String userName, String clusterName, String region) {
this.userName = userName;
this.clusterName = clusterName;
this.region = region;
}
public String toSignedRequestUri(AWSCredentials credentials) throws URISyntaxException {
Request request = getSignableRequest();
sign(request, credentials);
return new URIBuilder(request.getEndpoint())
.addParameters(toNamedValuePair(request.getParameters()))
.build()
.toString()
.replace(REQUEST_PROTOCOL, "");
}
private Request getSignableRequest() {
Request request = new DefaultRequest<>(SERVICE_NAME);
request.setHttpMethod(REQUEST_METHOD);
request.setEndpoint(getRequestUri());
request.addParameters(PARAM_ACTION, Collections.singletonList(ACTION_NAME));
request.addParameters(PARAM_USER, Collections.singletonList(userName));
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, clusterName));
}
private void sign(SignableRequest request, AWSCredentials credentials) {
AWS4Signer signer = new AWS4Signer();
signer.setRegionName(region);
signer.setServiceName(SERVICE_NAME);
DateTime dateTime = DateTime.now();
dateTime = dateTime.plus(Duration.standardSeconds(TOKEN_EXPIRY_SECONDS));
signer.presignRequest(request, credentials, dateTime.toDate());
}
private static List toNamedValuePair(Map> in) {
return in.entrySet().stream()
.map(e -> new BasicNameValuePair(e.getKey(), e.getValue().get(0)))
.collect(Collectors.toList());
}
}
```
**Se connecter avec un fournisseur d'informations d'identification**
Le code ci-dessous montre comment s'authentifier auprès de MemoryDB à l'aide du fournisseur d'identifiants d'authentification IAM.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request. Once this request is signed it can be used as an
// IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
// Create a credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userName, iamAuthTokenRequest, awsCredentialsProvider);
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce cluster client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Vous trouverez ci-dessous un exemple de client de cluster Lettuce qui intègre un fournisseur d'informations d'identification pour générer automatiquement des informations d'identification temporaires IAMAuth TokenRequest en cas de besoin.
```
public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider {
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final AWSCredentialsProvider awsCredentialsProvider;
private final String userName;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userName,
IAMAuthTokenRequest iamAuthTokenRequest,
AWSCredentialsProvider awsCredentialsProvider) {
this.userName = userName;
this.awsCredentialsProvider = awsCredentialsProvider;
this.iamAuthTokenRequest = iamAuthTokenRequest;
this.iamAuthTokenSupplier = Suppliers.memoizeWithExpiration(this::getIamAuthToken, TOKEN_EXPIRY_SECONDS, TimeUnit.SECONDS);
}
@Override
public Mono resolveCredentials() {
return Mono.just(RedisCredentials.just(userName, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
```