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.
# Sécurité des données sur Amazon ElastiCache
Pour garantir la sécurité de vos données, Amazon ElastiCache et Amazon EC2 fournissent des mécanismes de protection contre tout accès non autorisé à vos données sur le serveur.
Amazon ElastiCache for Memcached fournit des fonctionnalités de chiffrement pour les données contenues dans les caches exécutant les versions 1.6.12 ou ultérieures de Memcached.
Amazon ElastiCache avec Valkey et Redis OSS fournit des fonctionnalités de chiffrement pour les données des caches exécutant Valkey 7.2 ou version ultérieure, et Redis OSS versions 3.2.6 (date de fin de vie prévue, voir calendrier de [fin de vie des versions Redis OSS), 4.0.10 ou versions ultérieures](engine-versions.md#deprecated-engine-versions). Amazon prend ElastiCache également en charge l'authentification des utilisateurs avec IAM ou Valkey et Redis OSS AUTH, et l'autorisation des opérations des utilisateurs à l'aide du contrôle d'accès basé sur les rôles (RBAC).
+ 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 cache et votre application.
+ Le chiffrement au repos chiffre vos données sur disque au cours de la synchronisation et des opérations de sauvegarde.
ElastiCache prend en charge l'authentification des utilisateurs à l'aide d'IAM et de la commande Valkey et Redis OSS AUTH, et l'autorisation des opérations des utilisateurs à l'aide du contrôle d'accès basé sur les rôles (RBAC).
![\[Image : ElastiCache pour le schéma de sécurité de Valkey et Redis OSS\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-Secure-Compliant.png)
*ElastiCache pour le schéma de sécurité de Valkey et Redis OSS*
**Topics**
+ [ElastiCache chiffrement en transit (TLS)](in-transit-encryption.md)
+ [Chiffrement au repos dans ElastiCache](at-rest-encryption.md)
+ [Authentification et autorisation](auth-redis.md)
# ElastiCache chiffrement en transit (TLS)
Pour garantir la sécurité de vos données, Amazon ElastiCache 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, vous ElastiCache disposez d'un outil que vous pouvez utiliser pour protéger vos données lorsqu'elles sont déplacées d'un endroit à un autre.
Le chiffrement en transit est activé dans tous les caches sans serveur Valkey ou Redis OSS. Pour les clusters basés sur des nœuds, vous pouvez activer le chiffrement en transit sur un groupe de réplication en définissant le paramètre sur `TransitEncryptionEnabled` (`true`CLI :`--transit-encryption-enabled`) lorsque vous créez le groupe de réplication. Vous pouvez le faire, que vous créiez le groupe de réplication à l'aide de AWS Management Console, de AWS CLI, ou de l' ElastiCache API.
Le chiffrement en transit est activé pour tous les caches sans serveur. Pour les clusters basés sur des nœuds, vous pouvez activer le chiffrement en transit sur un cluster en définissant le paramètre sur `TransitEncryptionEnabled` (`true`CLI :`--transit-encryption-enabled`) lorsque vous créez le cluster à l'aide de l'opération (`CreateCacheCluster`CLI :`create-cache-cluster`).
**Topics**
+ [Présentation du chiffrement en transit](#in-transit-encryption-overview)
+ [Conditions de chiffrement en transit (Valkey et Redis OSS)](#in-transit-encryption-constraints)
+ [Conditions de chiffrement en cours de transit (Memcached)](#in-transit-encryption-constraints)
+ [Bonnes pratiques en matière de chiffrement en transit](#in-transit-encryption-best-practices)
+ [Autres options Valkey et Redis OSS](#in-transit-encryption-see-also)
+ [Activation du chiffrement en transit pour Memcached](#in-transit-encryption-enable-existing-mc)
+ [Activation du chiffrement en transit](in-transit-encryption-enable.md)
+ [Connexion à ElastiCache (Valkey) ou Amazon ElastiCache pour Redis OSS avec chiffrement en transit à l'aide de valkey-cli](connect-tls.md)
+ [Activation du chiffrement en transit sur un cluster Redis OSS basé sur des nœuds à l'aide de Python](in-transit-encryption-enable-python.md)
+ [Bonnes pratiques lors de l’activation du chiffrement en transit](enable-python-best-practices.md)
+ [Connexion à des nœuds activés avec le chiffrement en transit à l'aide d'OpenSSL (Memcached)](#in-transit-encryption-connect-mc)
+ [Création d'un client Memcached en mode TLS avec Java](#in-transit-encryption-connect-java)
+ [Création d'un client Memcached en mode TLS avec PHP](#in-transit-encryption-connect-php-mc)
## Présentation du chiffrement en transit
Le chiffrement ElastiCache en transit d'Amazon est une fonctionnalité qui vous permet de renforcer la sécurité de vos données aux points les plus vulnérables, lorsqu'elles sont en transit d'un endroit à un autre. Puisque certains traitements nécessitaient de chiffrer et de déchiffrer les données aux points de terminaison, l'activation du chiffrement en transit peut avoir un certain impact sur la performance. Vous devez référencer vos données avec et sans le chiffrement en transit pour déterminer l'impact sur la performance pour vos cas d'utilisation.
ElastiCache le chiffrement en transit met en œuvre les fonctionnalités suivantes :
+ **Connexions client chiffrées** : les connexions client aux nœuds de cache sont chiffrées à l’aide du protocole TLS.
+ **Connexions serveur chiffrées :** les données transférées entre les nœuds d’un cluster sont chiffrées.
+ **Authentification du serveur** : les clients peuvent authentifier leur connexion au bon serveur.
+ **Authentification du client** : à l'aide des fonctionnalités Valkey et Redis OSS AUTH, le serveur peut authentifier les clients.
## Conditions de chiffrement en transit (Valkey et Redis OSS)
Les contraintes suivantes relatives au chiffrement ElastiCache en transit d'Amazon doivent être prises en compte lorsque vous planifiez l'implémentation de votre cluster basé sur des nœuds :
+ Le chiffrement en transit est pris en charge sur les groupes de réplication exécutant Valkey 7.2 et versions ultérieures, et Redis OSS versions 3.2.6, 4.0.10 et ultérieures.
+ La modification du paramètre de chiffrement en transit, pour un cluster existant, est prise en charge sur les groupes de réplication exécutant Valkey 7.2 et versions ultérieures, et Redis OSS version 7 et ultérieure.
+ Le chiffrement en transit est pris en charge uniquement par les groupes de réplication exécutés dans un Amazon VPC.
+ Le chiffrement en transit n'est pas pris en charge pour les groupes de réplication exécutant les types de nœuds suivants : M1, M2.
Pour de plus amples informations, veuillez consulter [Types de nœuds pris en charge](CacheNodes.SupportedTypes.md).
+ Le chiffrement en transit est activé en définissant explicitement le paramètre `TransitEncryptionEnabled` sur `true`.
+ Assurez-vous que votre client de mise en cache prend en charge la connectivité TLS et que vous l’avez activée dans la configuration du client.
+ À compter du 26 janvier 2026, la version TLS minimale prise en charge AWS sera mise à jour vers la version 1.2 ElastiCache pour Valkey version 7.2 et supérieure, et ElastiCache pour Redis OSS version 6 et supérieure. Les clients doivent mettre à jour leur logiciel client avant cette date. Cette mise à jour vous aide à répondre aux besoins en matière de sécurité, de conformité et de réglementation.
## Conditions de chiffrement en cours de transit (Memcached)
Les contraintes suivantes relatives au chiffrement ElastiCache en transit d'Amazon doivent être prises en compte lorsque vous planifiez l'implémentation de votre cluster basé sur des nœuds :
+ Le chiffrement en transit est pris en charge sur les clusters exécutant Memcached versions 1.6.12 et ultérieures.
+ Le chiffrement en transit prend en charge le protocole TLS (Transport Layer Security) versions 1.2 et 1.3.
+ Le chiffrement en transit est pris en charge uniquement par les clusters exécutés dans un Amazon VPC.
+ Le chiffrement en transit n'est pas pris en charge pour les groupes de réplication exécutant les types de nœuds suivants : M1, M2, M3, R3, T2.
Pour de plus amples informations, veuillez consulter [Types de nœuds pris en charge](CacheNodes.SupportedTypes.md).
+ Le chiffrement en transit est activé en définissant explicitement le paramètre `TransitEncryptionEnabled` sur `true`.
+ Vous pouvez activer le chiffrement en transit sur un cluster uniquement lors de la création du cluster. Vous ne pouvez pas activer et désactiver le chiffrement en transit en modifiant un cluster.
+ Assurez-vous que votre client de mise en cache prend en charge la connectivité TLS et que vous l’avez activée dans la configuration du client.
## Bonnes pratiques en matière de chiffrement en transit
+ Puisque le traitement nécessitait de chiffrer et de déchiffrer les données aux points de terminaison, l'implémentation du chiffrement en transit peut réduire la performance. Référencez le chiffrement en transit en comparaison avec l'absence de chiffrement sur vos propres données pour déterminer l'impact sur la performance pour votre cas d'utilisation.
+ La création de nouvelles connexions étant parfois coûteuse, vous pouvez réduire l'impact du chiffrement en transit sur les performances en conservant vos connexions TLS.
## Autres options Valkey et Redis OSS
Pour plus d'informations sur les options disponibles pour Valkey et Redis OSS, consultez les liens suivants.
+ [Chiffrement au repos dans ElastiCache](at-rest-encryption.md)
+ [Authentification avec la commande Valkey et Redis OSS AUTH](auth.md)
+ [Contrôle d'accès basé sur les rôles (RBAC)](Clusters.RBAC.md)
+ [Amazon VPCs et la ElastiCache sécurité](VPCs.md)
+ [Identity and Access Management pour Amazon ElastiCache](IAM.md)
## Activation du chiffrement en transit pour Memcached
Pour activer le chiffrement en transit lors de la création d'un cluster Memcached à l'aide de la Console de gestion AWS, effectuez les sélections suivantes :
+ Choisissez Memcached comme moteur.
+ Choisissez la version de moteur 1.6.12 ou ultérieure.
+ Sous **Encryption in transit** (Chiffrement en transit), choisissez **Enable** (Activer).
Pour le step-by-step processus, voir[Création d'un cluster pour Valkey ou Redis OSS](Clusters.Create.md).
# Activation du chiffrement en transit
Le chiffrement en transit est activé pour tous les caches sans serveur. Sur un cluster basé sur des nœuds, vous pouvez activer le chiffrement en transit à l'aide de AWS Management Console la AWS CLI ou de l'API. ElastiCache
## Activation du chiffrement en transit à l'aide du AWS Management Console
### Activation du chiffrement en transit pour un nouveau cluster basé sur des nœuds à l'aide du AWS Management Console
Lorsque vous concevez votre propre cluster, le chiffrement en transit est activé pour les configurations « Dev/Test » et « Production » avec la méthode « Création facile ». Lorsque vous choisissez vous-même la configuration, effectuez les sélections suivantes :
+ Choisissez la version de moteur 3.2.6, 4.0.10 ou ultérieure.
+ Cochez la case en regard de **Activer** pour l’option **Chiffrement en transit**.
Pour le step-by-step processus, consultez ce qui suit :
+ [Création d'un cluster Valkey (mode cluster désactivé) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ [Création d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
### Activation du chiffrement en transit pour un cluster basé sur des nœuds existant à l'aide du AWS Management Console
L'activation du chiffrement en transit est un processus en deux étapes. Vous devez d'abord définir le mode de chiffrement en transit sur `preferred`. Ce mode permet à vos clients Valkey ou Redis OSS de se connecter en utilisant des connexions chiffrées et non chiffrées. Après avoir migré tous vos clients Valkey ou Redis OSS pour utiliser des connexions chiffrées, vous pouvez modifier la configuration de votre cluster pour définir le mode de cryptage du transit sur. `required` Définir le mode de chiffrement en transit sur `required` supprimera toutes les connexions non chiffrées et n'autorisera que les connexions chiffrées.
**Définissez votre **mode de cryptage Transit** sur **Préféré****
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Choisissez **les caches Valkey ou les caches** **Redis OSS** dans les ElastiCache **ressources** répertoriées dans le volet de navigation, sur la gauche.
1. Choisissez le cache que vous souhaitez mettre à jour.
1. Choisissez la liste déroulante **Actions**, puis **Modify** (Modifier).
1. Choisissez **Enable** (Activer) sous **Encryption in transit** (Chiffrement en transit) dans la section **Security** (Sécurité).
1. Choisissez **Preferred** (Préféré) comme **Transit encryption mode** (Mode de chiffrement en transit).
1. Choisissez **Preview changes** (Prévisualiser les modifications), puis enregistrez vos modifications.
Après avoir migré tous vos clients Valkey ou Redis OSS pour utiliser des connexions chiffrées :
**Définissez le **mode de cryptage de votre Transit** sur **Obligatoire****
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Choisissez **les caches Valkey ou les caches** **Redis OSS** dans les ElastiCache **ressources** répertoriées dans le volet de navigation, sur la gauche.
1. Choisissez le cache que vous souhaitez mettre à jour.
1. Choisissez la liste déroulante **Actions**, puis **Modify** (Modifier).
1. Choisissez **Required** (Obligatoire) comme **Transit encryption mode** (Mode de chiffrement en transit) dans la section **Security** (Sécurité).
1. Choisissez **Preview changes** (Prévisualiser les modifications), puis enregistrez vos modifications.
## Activation du chiffrement en transit à l'aide du AWS CLI
Pour activer le chiffrement en transit lors de la création d'un groupe de réplication Valkey ou Redis OSS à l'aide du paramètre AWS CLI, utilisez le paramètre. `transit-encryption-enabled`
### Activation du chiffrement en transit sur un nouveau cluster basé sur des nœuds pour Valkey ou Redis OSS (mode cluster désactivé) (CLI)
Utilisez l'AWS CLI opération `create-replication-group` et les paramètres suivants pour créer un groupe de réplication Valkey ou Redis OSS avec des répliques pour lesquelles le chiffrement en transit est activé :
**Paramètres clés :**
+ **--engine**—Ça doit être `valkey` ou. `redis`
+ **--engine-version**—Si le moteur est Redis OSS, il doit être 3.2.6, 4.0.10 ou version ultérieure.
+ **--transit-encryption-enabled** : obligatoire. Si vous activez le chiffrement en transit, vous devez également fournir une valeur pour le paramètre `--cache-subnet-group`.
+ **--num-cache-clusters** : 1 au minimum. La valeur maximale pour ce paramètre est 6.
Pour plus d’informations, consultez les ressources suivantes :
+ [Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro ()AWS CLI](Replication.CreatingReplGroup.NoExistingCluster.Classic.md#Replication.CreatingReplGroup.NoExistingCluster.Classic.CLI)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
### Activation du chiffrement en transit sur un nouveau cluster basé sur des nœuds pour Valkey ou Redis OSS (mode cluster activé) (CLI)
Utilisez l'AWS CLI opération `create-replication-group` et les paramètres suivants pour créer un groupe de réplication Valkey ou Redis OSS (mode cluster activé) sur lequel le chiffrement en transit est activé :
**Paramètres clés :**
+ **--engine**—Ça doit être `valkey` ou. `redis`
+ **--engine-version**—Si le moteur est Redis OSS, il doit être 3.2.6, 4.0.10 ou version ultérieure.
+ **--transit-encryption-enabled** : obligatoire. Si vous activez le chiffrement en transit, vous devez également fournir une valeur pour le paramètre `--cache-subnet-group`.
+ Pour spécifier la configuration des groupes de nœud du groupe de réplication, utilisez l'un des ensembles de paramètres suivants :
+ **--num-node-groups** : spécifie le nombre de partitions (groupes de nœuds) de ce groupe de réplication. La valeur maximale pour ce paramètre est 500.
**--replicas-per-node-group** : spécifie le nombre de nœuds de réplicas dans chaque groupe de nœuds. La valeur spécifiée ici est appliquée à toutes les partitions de ce groupe de réplication. La valeur maximale pour ce paramètre est 5.
+ **--node-group-configuration** : spécifie la configuration de chaque partition de manière indépendante.
Pour plus d’informations, consultez les ressources suivantes :
+ [Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à partir de zéro ()AWS CLI](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
### Activation du chiffrement en transit pour un cluster existant à l'aide de la AWS CLI
L'activation du chiffrement en transit est un processus en deux étapes. Vous devez d'abord définir le mode de chiffrement en transit sur `preferred`. Ce mode permet à vos clients Valkey ou Redis OSS de se connecter en utilisant des connexions chiffrées et non chiffrées. Après avoir migré tous vos clients Valkey ou Redis OSS pour utiliser des connexions chiffrées, vous pouvez modifier la configuration de votre cluster pour définir le mode de cryptage du transit sur. `required` Définir le mode de chiffrement en transit sur `required` supprimera toutes les connexions non chiffrées et n'autorisera que les connexions chiffrées.
Utilisez l'AWS CLI opération `modify-replication-group` et les paramètres suivants pour mettre à jour un groupe de réplication Valkey ou Redis OSS (mode cluster activé) pour lequel le chiffrement en transit est désactivé.
**Pour activer le chiffrement en transit**
1. Réglé transit-encryption-mode sur`preferred`, à l'aide des paramètres suivants
+ **--transit-encryption-enabled** : obligatoire.
+ **--transit-encryption-mode** : doit être défini sur `preferred`.
1. Réglez transit-encryption-mode sur`required`, en utilisant les paramètres suivants :
+ **--transit-encryption-enabled** : obligatoire.
+ **--transit-encryption-mode** : doit être défini sur `required`.
# Connexion à ElastiCache (Valkey) ou Amazon ElastiCache pour Redis OSS avec chiffrement en transit à l'aide de valkey-cli
Pour accéder aux données depuis ElastiCache les caches Redis OSS activés avec le chiffrement en transit, vous utilisez des clients qui fonctionnent avec le protocole SSL (Secure Socket Layer). Vous pouvez également utiliser valkey-cli sur TLS/SSL Amazon Linux et Amazon Linux 2. Si votre client ne prend pas en charge le protocole TLS, vous pouvez utiliser la `stunnel` commande sur l'hôte de votre client pour créer un tunnel SSL vers les nœuds Redis OSS.
## Connexion cryptée avec Linux
Pour utiliser valkey-cli pour vous connecter à un cluster Valkey ou Redis OSS activé avec le chiffrement en transit sur Amazon Linux 2 ou Amazon Linux, procédez comme suit.
1. Téléchargez et compilez l'utilitaire valkey-cli. Cet utilitaire est inclus dans la distribution du logiciel Valkey.
1. À l'invite de commande de votre EC2 instance, tapez les commandes appropriées pour la version de Linux que vous utilisez.
**Amazon Linux 2**
Si vous utilisez Amazon Linux 2, entrez ceci :
```
sudo yum -y install openssl-devel gcc
wget https://github.com/valkey-io/valkey/archive/refs/tags/7.2.6.tar.gz
tar xvzf valkey-7.2.6.tar.gz
cd valkey-7.2.6
make distclean
make valkey-cli BUILD_TLS=yes
sudo install -m 755 src/valkey-cli /usr/local/bin/
```
**Amazon Linux**
Si vous utilisez Amazon Linux, saisissez ce qui suit :
```
sudo yum install gcc jemalloc-devel openssl-devel tcl tcl-devel clang wget
wget https://github.com/valkey-io/valkey/archive/refs/tags/8.0.0.tar.gz
tar xvzf valkey-8.0.0.tar.gz
cd valkey-8.0.0
make valkey-cli CC=clang BUILD_TLS=yes
sudo install -m 755 src/valkey-cli /usr/local/bin/
```
Sur Amazon Linux, vous pouvez également avoir besoin de suivre les étapes suivantes :
```
sudo yum install clang
CC=clang make
sudo make install
```
1. Après avoir téléchargé et installé l'utilitaire valkey-cli, il est recommandé d'exécuter la commande facultative. `make-test`
1. Pour vous connecter à un cluster avec le chiffrement et l'authentification activés, entrez cette commande :
```
valkey-cli -h Primary or Configuration Endpoint --tls -a 'your-password' -p 6379
```
**Note**
Si vous installez redis6 sur Amazon Linux 2023, vous pouvez désormais utiliser `redis6-cli` la commande au lieu de : `valkey-cli`
```
redis6-cli -h Primary or Configuration Endpoint --tls -p 6379
```
## Connexion cryptée avec Stunnel
Pour utiliser valkey-cli pour vous connecter à un cluster Redis OSS activé avec le chiffrement en transit à l'aide de Stunnel, procédez comme suit.
1. Utilisez SSH pour vous connecter à votre client et installer `stunnel`.
```
sudo yum install stunnel
```
1. Exécutez la commande suivante pour créer et modifier le fichier `'/etc/stunnel/valkey-cli.conf'` simultanément afin d'ajouter un ElastiCache point de terminaison du cluster Redis OSS à un ou plusieurs paramètres de connexion, en utilisant le résultat fourni ci-dessous comme modèle.
```
vi /etc/stunnel/valkey-cli.conf
fips = no
setuid = root
setgid = root
pid = /var/run/stunnel.pid
debug = 7
delay = yes
options = NO_SSLv2
options = NO_SSLv3
[valkey-cli]
client = yes
accept = 127.0.0.1:6379
connect = primary.ssltest.wif01h.use1.cache.amazonaws.com:6379
[valkey-cli-replica]
client = yes
accept = 127.0.0.1:6380
connect = ssltest-02.ssltest.wif01h.use1.cache.amazonaws.com:6379
```
Dans cet exemple, le fichier de configuration comporte deux connexions : `valkey-cli` et `valkey-cli-replica`. Les paramètres sont définis comme suit :
+ **client** est défini sur Yes (Oui) pour indiquer que cette instance stunnel est un client.
+ **accept** est défini sur l'adresse IP du client. Dans cet exemple, le serveur principal est défini sur la valeur par défaut de Redis OSS 127.0.0.1 sur le port 6379. Le réplica doit appeler un port différent et défini sur 6380. Vous pouvez utiliser les ports éphémères 1024–65535. Pour de plus amples informations, veuillez consulter [Ports éphémères](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports) dans le *Guide de l'utilisateur Amazon VPC.*
+ **connect** est défini sur le point de terminaison du serveur Redis OSS. Pour de plus amples informations, veuillez consulter [Recherche de points de terminaison de connexion dans ElastiCache](Endpoints.md).
1. Démarrer `stunnel`.
```
sudo stunnel /etc/stunnel/valkey-cli.conf
```
Utilisez la commande `netstat` pour confirmer que les tunnels ont démarré.
```
sudo netstat -tulnp | grep -i stunnel
tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 3189/stunnel
tcp 0 0 127.0.0.1:6380 0.0.0.0:* LISTEN 3189/stunnel
```
1. Connectez-vous au nœud Redis OSS crypté à l'aide du point de terminaison local du tunnel.
+ Si aucun mot de passe AUTH n'a été utilisé lors ElastiCache de la création du cluster Redis OSS, cet exemple utilise le valkey-cli pour se connecter au serveur Redis OSS en utilisant le chemin complet ElastiCache pour valkey-cli, sur Amazon Linux :
```
/home/ec2-user/redis-7.2.5/src/valkey-cli -h localhost -p 6379
```
Si le mot de passe AUTH a été utilisé lors de la création du cluster Redis OSS, cet exemple utilise valkey-cli pour se connecter au serveur Redis OSS en utilisant le chemin complet pour valkey-cli, sur Amazon Linux :
```
/home/ec2-user/redis-7.2.5/src/valkey-cli -h localhost -p 6379 -a my-secret-password
```
OU
+ Changez le répertoire en redis-7.2.5 et procédez comme suit :
Si aucun mot de passe AUTH n'a été utilisé lors ElastiCache de la création du cluster Redis OSS, cet exemple utilise le valkey-cli pour se connecter au serveur Redis OSS en utilisant le chemin complet ElastiCache pour valkey-cli, sur Amazon Linux :
```
src/valkey-cli -h localhost -p 6379
```
Si le mot de passe AUTH a été utilisé lors de la création du cluster Redis OSS, cet exemple utilise valkey-cli pour se connecter au serveur Valkey ou Redis OSS en utilisant le chemin complet pour valkey-cli, sur Amazon Linux :
```
src/valkey-cli -h localhost -p 6379 -a my-secret-password
```
Cet exemple utilise Telnet pour se connecter au serveur Valkey Redis OSS.
```
telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
auth MySecretPassword
+OK
get foo
$3
bar
```
1. Pour arrêter et fermer les tunnels SSL, arrêtez le processus stunnel `pkill`.
```
sudo pkill stunnel
```
# Activation du chiffrement en transit sur un cluster Redis OSS basé sur des nœuds à l'aide de Python
Le guide suivant explique comment activer le chiffrement en transit sur un cluster Redis OSS 7.0 créé à l'origine avec le chiffrement en transit désactivé. Les clients TCP et TLS continuent de communiquer avec le cluster pendant ce processus sans interruption de service.
Boto3 obtient les informations d'identification nécessaires (`aws_access_key_id`, `aws_secret_access_key` et `aws_session_token`) à partir des variables d'environnement. Ces informations d'identification sont collées à l'avance dans le même terminal bash où nous exécutons `python3` pour traiter le code Python présenté dans ce guide. Le code de l'exemple ci-dessous a été traité à partir d'une EC2 instance lancée dans le même VPC qui sera utilisé pour y créer le cluster ElastiCache Redis OSS.
**Note**
Les exemples suivants utilisent le SDK boto3 pour les opérations de ElastiCache gestion (création de clusters ou d'utilisateurs) et redis-py-cluster redis-py/ pour le traitement des données.
Vous devez utiliser au moins la version Boto3 (=\$1) 1.26.39 pour utiliser la migration TLS en ligne avec l'API de modification du cluster.
ElastiCache prend en charge la migration TLS en ligne uniquement pour les clusters dotés de Valkey version 7.2 ou supérieure ou de Redis OSS version 7.0 ou supérieure. Ainsi, si vous avez un cluster exécutant une version Redis OSS antérieure à 7.0, vous devrez mettre à niveau la version Redis OSS de votre cluster. Pour plus d'informations sur ces différences de version, consultez [Principales différences de comportement entre les versions du moteur et de compatibilité avec Redis OSS](VersionManagementConsiderations.md).
**Topics**
+ [Définissez les constantes de chaîne qui lanceront le cluster ElastiCache Valkey ou Redis OSS](#enable-python-define-constants)
+ [Définir les classes pour la configuration du cluster](#enable-python-define-classes)
+ [Définir une classe qui représente le cluster lui-même](#enable-python-define-classes-cluster)
+ [(Facultatif) Créez une classe wrapper pour démontrer la connexion du client au cluster Valkey ou Redis OSS](#enable-python-create-wrapper)
+ [Créer la fonction principale qui montre le processus de modification de la configuration du chiffrement en transit](#enable-python-main-function)
## Définissez les constantes de chaîne qui lanceront le cluster ElastiCache Valkey ou Redis OSS
Définissons d'abord quelques constantes de chaîne Python simples qui contiendront les noms des AWS entités requises pour créer le ElastiCache cluster`security-group`, telles que`Cache Subnet group`, et `default parameter group` a. Toutes ces AWS entités doivent être créées à l'avance sur votre AWS compte dans la région que vous souhaitez utiliser.
```
#Constants definitions
SECURITY_GROUP = "sg-0492aa0a29c558427"
CLUSTER_DESCRIPTION = "This cluster has been launched as part of the online TLS migration user guide"
EC_SUBNET_GROUP = "client-testing"
DEFAULT_PARAMETER_GROUP_REDIS_7_CLUSTER_MODE_ENABLED = "default.redis7.cluster.on"
```
## Définir les classes pour la configuration du cluster
Définissons maintenant quelques classes Python simples qui représenteront la configuration d'un cluster, qui contiendra des métadonnées sur le cluster, telles que la version de Valkey ou Redis OSS, le type d'instance et si le chiffrement en transit (TLS) est activé ou désactivé.
```
#Class definitions
class Config:
def __init__(
self,
instance_type: str = "cache.t4g.small",
version: str = "7.0",
multi_az: bool = True,
TLS: bool = True,
name: str = None,
):
self.instance_type = instance_type
self.version = version
self.multi_az = multi_az
self.TLS = TLS
self.name = name or f"tls-test"
def create_base_launch_request(self):
return {
"ReplicationGroupId": self.name,
"TransitEncryptionEnabled": self.TLS,
"MultiAZEnabled": self.multi_az,
"CacheNodeType": self.instance_type,
"Engine": "redis",
"EngineVersion": self.version,
"CacheSubnetGroupName": EC_SUBNET_GROUP ,
"CacheParameterGroupName": DEFAULT_PARAMETER_GROUP_REDIS_7_CLUSTER_MODE_ENABLED ,
"ReplicationGroupDescription": CLUSTER_DESCRIPTION,
"SecurityGroupIds": [SECURITY_GROUP],
}
class ConfigCME(Config):
def __init__(
self,
instance_type: str = "cache.t4g.small",
version: str = "7.0",
multi_az: bool = True,
TLS: bool = True,
name: str = None,
num_shards: int = 2,
num_replicas_per_shard: int = 1,
):
super().__init__(instance_type, version, multi_az, TLS, name)
self.num_shards = num_shards
self.num_replicas_per_shard = num_replicas_per_shard
def create_launch_request(self) -> dict:
launch_request = self.create_base_launch_request()
launch_request["NumNodeGroups"] = self.num_shards
launch_request["ReplicasPerNodeGroup"] = self.num_replicas_per_shard
return launch_request
```
## Définir une classe qui représente le cluster lui-même
Définissons maintenant quelques classes Python simples qui représenteront le cluster ElastiCache Valkey ou Redis OSS lui-même. Cette classe aura un champ client qui contiendra un client boto3 pour les opérations de ElastiCache gestion telles que la création du cluster et l'interrogation de l'API. ElastiCache
```
import botocore.config
import boto3
# Create boto3 client
def init_client(region: str = "us-east-1"):
config = botocore.config.Config(retries={"max_attempts": 10, "mode": "standard"})
init_request = dict()
init_request["config"] = config
init_request["service_name"] = "elasticache"
init_request["region_name"] = region
return boto3.client(**init_request)
class ElastiCacheClusterBase:
def __init__(self, name: str):
self.name = name
self.elasticache_client = init_client()
def get_first_replication_group(self):
return self.elasticache_client.describe_replication_groups(
ReplicationGroupId=self.name
)["ReplicationGroups"][0]
def get_status(self) -> str:
return self.get_first_replication_group()["Status"]
def get_transit_encryption_enabled(self) -> bool:
return self.get_first_replication_group()["TransitEncryptionEnabled"]
def is_available(self) -> bool:
return self.get_status() == "available"
def is_modifying(self) -> bool:
return self.get_status() == "modifying"
def wait_for_available(self):
while True:
if self.is_available():
break
else:
time.sleep(5)
def wait_for_modifying(self):
while True:
if self.is_modifying():
break
else:
time.sleep(5)
def delete_cluster(self) -> bool:
self.elasticache_client.delete_replication_group(
ReplicationGroupId=self.name, RetainPrimaryCluster=False
)
def modify_transit_encryption_mode(self, new_transit_encryption_mode: str):
# generate api call to migrate the cluster to TLS preffered or to TLS required
self.elasticache_client.modify_replication_group(
ReplicationGroupId=self.name,
TransitEncryptionMode=new_transit_encryption_mode,
TransitEncryptionEnabled=True,
ApplyImmediately=True,
)
self.wait_for_modifying()
class ElastiCacheClusterCME(ElastiCacheClusterBase):
def __init__(self, name: str):
super().__init__(name)
@classmethod
def launch(cls, config: ConfigCME = None) -> ElastiCacheClusterCME:
config = config or ConfigCME()
print(config)
new_cluster = ElastiCacheClusterCME(config.name)
launch_request = config.create_launch_request()
new_cluster.elasticache_client.create_replication_group(**launch_request)
new_cluster.wait_for_available()
return new_cluster
def get_configuration_endpoint(self) -> str:
return self.get_first_replication_group()["ConfigurationEndpoint"]["Address"]
#Since the code can throw exceptions, we define this class to make the code more readable and
#so we won't forget to delete the cluster
class ElastiCacheCMEManager:
def __init__(self, config: ConfigCME = None):
self.config = config or ConfigCME()
def __enter__(self) -> ElastiCacheClusterCME:
self.cluster = ElastiCacheClusterCME.launch(self.config)
return self.cluster
def __exit__(self, exc_type, exc_val, exc_tb):
self.cluster.delete_cluster()
```
## (Facultatif) Créez une classe wrapper pour démontrer la connexion du client au cluster Valkey ou Redis OSS
Créons maintenant une classe encapsuleur pour le client `redis-py-cluster`. Cette classe encapsuleur permet de pré-remplir le cluster avec certaines clés, puis d'exécuter des commandes `get` répétées de manière aléatoire.
**Note**
Il s'agit d'une étape facultative, mais elle simplifie le code de la fonction principale qui sera ajoutée à une étape ultérieure.
```
import redis
improt random
from time import perf_counter_ns, time
class DowntimeTestClient:
def __init__(self, client):
self.client = client
# num of keys prefilled
self.prefilled = 0
# percent of get above prefilled
self.percent_get_above_prefilled = 10 # nil result expected when get hit above prefilled
# total downtime in nano seconds
self.downtime_ns = 0
# num of success and fail operations
self.success_ops = 0
self.fail_ops = 0
self.connection_errors = 0
self.timeout_errors = 0
def replace_client(self, client):
self.client = client
def prefill_data(self, timelimit_sec=60):
end_time = time() + timelimit_sec
while time() < end_time:
self.client.set(self.prefilled, self.prefilled)
self.prefilled += 1
# unsuccesful operations throw exceptions
def _exec(self, func):
try:
start_ns = perf_counter_ns()
func()
self.success_ops += 1
elapsed_ms = (perf_counter_ns() - start_ns) // 10 ** 6
# upon succesful execution of func
# reset random_key to None so that the next command
# will use a new random key
self.random_key = None
except Exception as e:
elapsed_ns = perf_counter_ns() - start_ns
self.downtime_ns += elapsed_ns
# in case of failure- increment the relevant counters so that we will keep track
# of how many connection issues we had while trying to communicate with
# the cluster.
self.fail_ops += 1
if e.__class__ is redis.exceptions.ConnectionError:
self.connection_errors += 1
if e.__class__ is redis.exceptions.TimeoutError:
self.timeout_errors += 1
def _repeat_exec(self, func, seconds):
end_time = time() + seconds
while time() < end_time:
self._exec(func)
def _new_random_key_if_needed(self, percent_above_prefilled):
if self.random_key is None:
max = int((self.prefilled * (100 + percent_above_prefilled)) / 100)
return random.randint(0, max)
return self.random_key
def _random_get(self):
key = self._new_random_key_if_needed(self.percent_get_above_prefilled)
result = self.client.get(key)
# we know the key was set for sure only in the case key < self.prefilled
if key < self.prefilled:
assert result.decode("UTF-8") == str(key)
def repeat_get(self, seconds=60):
self._repeat_exec(self._random_get, seconds)
def get_downtime_ms(self) -> int:
return self.downtime_ns // 10 ** 6
def do_get_until(self, cond_check):
while not cond_check():
self.repeat_get()
# do one more get cycle once condition is met
self.repeat_get()
```
## Créer la fonction principale qui montre le processus de modification de la configuration du chiffrement en transit
Maintenant, définissons la fonction principale, qui effectue les opérations suivantes :
1. Créez le cluster à l'aide du client boto3 ElastiCache .
1. Initialisez le client `redis-py-cluster` qui se connecte au cluster avec une connexion TCP claire sans TLS.
1. Le client `redis-py-cluster` préremplit le cluster avec certaines données.
1. Le client Boto3 déclenche la migration TLS d'un protocole non compatible avec TLS vers un protocole TLS préféré.
1. Pendant la migration du cluster vers TLS `Preferred`, le client TCP `redis-py-cluster` envoie des opérations `get` répétées au cluster jusqu'à ce que la migration soit terminée.
1. Une fois la migration vers TLS `Preferred` terminée, nous affirmons que le cluster prend en charge le chiffrement en transit. Ensuite, nous créons un client `redis-py-cluster` qui se connecte au cluster via TLS.
1. Nous envoyons certaines commandes `get` en utilisant le nouveau client TLS et l'ancien client TCP.
1. Le client Boto3 déclenche la migration TLS d'un protocole TLS `Preferred` vers un protocole TLS obligatoire.
1. Lorsque la migration du cluster vers le protocole TLS est requise, le client redis-py-cluster TLS enverra des `get` opérations répétées au cluster jusqu'à ce que la migration soit terminée.
```
import redis
def init_cluster_client(
cluster: ElastiCacheClusterCME, prefill_data: bool, TLS: bool = True) -> DowntimeTestClient:
# we must use for the host name the cluster configuration endpoint.
redis_client = redis.RedisCluster(
host=cluster.get_configuration_endpoint(), ssl=TLS, socket_timeout=0.25, socket_connect_timeout=0.1
)
test_client = DowntimeTestClient(redis_client)
if prefill_data:
test_client.prefill_data()
return test_client
if __name__ == '__main__':
config = ConfigCME(TLS=False, instance_type="cache.m5.large")
with ElastiCacheCMEManager(config) as cluster:
# create a client that will connect to the cluster with clear tcp connection
test_client_tcp = init_cluster_client(cluster, prefill_data=True, TLS=False)
# migrate the cluster to TLS Preferred
cluster.modify_transit_encryption_mode(new_transit_encryption_mode="preferred")
# do repeated get commands until the cluster finishes the migration to TLS Preferred
test_client_tcp.do_get_until(cluster.is_available)
# verify that in transit encryption is enabled so that clients will be able to connect to the cluster with TLS
assert cluster.get_transit_encryption_enabled() == True
# create a client that will connect to the cluster with TLS connection.
# we must first make sure that the cluster indeed supports TLS
test_client_tls = init_cluster_client(cluster, prefill_data=True, TLS=True)
# by doing get commands with the tcp client for 60 more seconds
# we can verify that the existing tcp connection to the cluster still works
test_client_tcp.repeat_get(seconds=60)
# do get commands with the new TLS client for 60 more seconds
test_client_tcp.repeat_get(seconds=60)
# migrate the cluster to TLS required
cluster.modify_transit_encryption_mode(new_transit_encryption_mode="required")
# from this point the tcp clients will be disconnected and we must not use them anymore.
# do get commands with the TLS client until the cluster finishes migartion to TLS required mode.
test_client_tls.do_get_until(cluster.is_available)
```
# Bonnes pratiques lors de l’activation du chiffrement en transit
## Avant d'activer le chiffrement en transit : veillez à gérer correctement les enregistrements DNS
**Note**
Nous modifions et supprimons les anciens points de terminaison au cours de ce processus. Une utilisation incorrecte des points de terminaison peut amener le client Valkey ou Redis OSS à utiliser des points de terminaison anciens et supprimés, ce qui l'empêchera de se connecter au cluster.
Lors de la migration du cluster d'un point de terminaison No-TLS vers TLS préféré, l'ancien enregistrement DNS du point de terminaison de configuration du cluster est conservé et les nouveaux enregistrements DNS du point de terminaison de configuration du cluster sont générés dans un format différent. Les clusters compatibles TLS utilisent un format d'enregistrement DNS différent de celui des clusters activés par TLS. ElastiCache conservera les deux enregistrements DNS lorsqu'un cluster est configuré `encryption mode: Preferred` afin que les applications et les autres clients Valkey ou Redis OSS puissent passer de l'un à l'autre. Les modifications suivantes sont apportées aux enregistrements DNS au cours du processus de migration TLS :
### Description des modifications apportées aux enregistrements DNS lors de l'activation du chiffrement en transit
**Pour les clusters CME**
Lorsqu'un cluster est réglé sur « mode de chiffrement en transit : préféré » :
+ Le point de terminaison de configuration de cluster d'origine pour le cluster No-TLS restera actif. Il n'y a aucun temps d'arrêt lorsque le cluster est reconfiguré du mode de chiffrement TLS « sans » au mode « préféré ».
+ De nouveaux points de terminaison TLS Valkey ou Redis OSS seront générés lorsque le cluster est défini sur le mode TLS préféré. Ces nouveaux points de terminaison seront résolus de la même manière IPs que les anciens (non TLS).
+ Le nouveau point de terminaison de configuration TLS Valkey ou Redis OSS sera exposé dans la ElastiCache console et dans la réponse à l'API. `describe-replication-group`
Lorsqu'un cluster est réglé sur « mode de chiffrement en transit : obligatoire » :
+ Les anciens points de terminaison non compatibles avec le protocole TLS sont supprimés. Les points de terminaison de cluster TLS ne sont pas interrompus.
+ Vous pouvez en récupérer un nouveau `cluster-configuration-endpoint` depuis ElastiCache la console ou depuis l'`describe-replication-group`API.
**Pour les clusters CMD avec basculement automatique activé ou désactivé**
Lorsqu'un groupe de réplication est réglé sur « mode de chiffrement en transit : préféré » :
+ Le point de terminaison principal d'origine et le point de terminaison du lecteur pour un cluster non compatible avec TLS restent actifs.
+ De nouveaux points de terminaison principaux et du lecteur TLS sont générés lorsque le cluster est réglé sur le mode TLS `Preferred`. Ces nouveaux points de terminaison adoptent la ou les mêmes adresses IP que les anciens (non TLS).
+ Le nouveau point de terminaison principal et le nouveau point de terminaison du lecteur seront exposés dans la ElastiCache console et dans la réponse à l'`describe-replication-group`API.
Lorsqu'un groupe de réplication est réglé sur « mode de chiffrement en transit : obligatoire » :
+ Les anciens points de terminaison principaux et du lecteur non compatibles avec TLS sont supprimés. Les points de terminaison de cluster TLS ne sont pas interrompus.
+ Vous pouvez récupérer les nouveaux points de terminaison principaux et lecteurs depuis ElastiCache la console ou depuis l'`describe-replication-group`API.
### L'utilisation suggérée des enregistrements DNS
**Pour les clusters CME**
+ Utilisez le point de terminaison de configuration du cluster plutôt que les enregistrements DNS par nœud dans le code de votre application. Il n'est pas recommandé d'utiliser directement les noms DNS par nœud, car ils changeront au cours de la migration et le code de l'application interrompra la connexion au cluster.
+ Ne codez pas en dur un point de terminaison de configuration de cluster dans votre application, car il changera au cours de ce processus.
+ Coder en dur le point de terminaison de configuration du cluster dans votre application est une mauvaise pratique, car il peut être modifié au cours de ce processus. Une fois le chiffrement en transit terminé, interrogez le point de terminaison de configuration du cluster avec l'`describe-replication-group`API (comme illustré ci-dessus (en gras)) et utilisez le DNS que vous obtenez en réponse à partir de ce moment.
**Pour les clusters CMD avec basculement automatique activé**
+ Utilisez le point de terminaison principal et le point de terminaison du lecteur plutôt que les noms DNS par nœud dans le code de votre application, car les anciens noms DNS par nœud sont supprimés et de nouveaux sont générés lors de la migration du cluster d'un protocole non compatible avec TLS vers TLS préféré. L'utilisation directe de noms DNS par nœud n'est pas recommandée si vous choisissez d'ajouter des réplicas à votre cluster à l'avenir. De plus, lorsque le basculement automatique est activé, les rôles du cluster principal et des répliques sont modifiés automatiquement par le ElastiCache service. Il est suggéré d'utiliser le point de terminaison principal et le point de terminaison du lecteur pour vous aider à suivre ces modifications. Enfin, l'utilisation du point de terminaison du lecteur vous permet de répartir vos lectures provenant des réplicas de manière égale entre les réplicas du cluster.
+ Il est déconseillé de coder en dur le point de terminaison principal et le point de terminaison du lecteur dans votre application, car cela peut être modifié au cours du processus de migration TLS. Une fois la migration vers TLS-Preferred terminée, interrogez le point de terminaison principal et le point de terminaison du lecteur avec l' describe-replication-groupAPI et utilisez le DNS que vous obtenez en réponse à partir de ce moment. De cette façon, vous pouvez suivre l'évolution des points de terminaison de manière dynamique.
**Pour les clusters CMD avec basculement automatique désactivé**
+ Utilisez le point de terminaison principal et le point de terminaison du lecteur plutôt que les noms DNS par nœud dans le code de votre application. Lorsque le basculement automatique est désactivé, c'est vous qui effectuez le dimensionnement, les correctifs, le basculement et les autres procédures gérées automatiquement par le ElastiCache service lorsque le basculement automatique est activé. Vous pouvez ainsi plus facilement effectuer un suivi manuel des différents points de terminaison. Puisque les anciens noms DNS par nœud sont supprimés et que de nouveaux sont générés lors de la migration du cluster du mode non compatible avec TLS vers TLS préféré, n'utilisez pas directement les noms DNS par nœud. Cela est obligatoire pour que les clients puissent se connecter au cluster pendant la migration vers TLS. Vous bénéficiez également de la répartition uniforme des lectures entre les réplicas lorsque vous utilisez le point de terminaison du lecteur et du suivi des enregistrements DNS lors de l'ajout ou de la suppression de réplicas dans le cluster.
+ Il est déconseillé de coder en dur le point de terminaison de configuration du cluster dans votre application car il peut être modifié au cours du processus de migration TLS.
## Pendant le chiffrement en transit : faites attention à la fin du processus de migration
Le passage au mode de chiffrement en transit n'est pas immédiat et peut prendre un certain temps. Cela est particulièrement vrai pour les grands clusters. Ce n'est que lorsque le cluster termine la migration vers TLS préféré qu'il est en mesure d'accepter et de gérer à la fois les connexions TCP et TLS. Par conséquent, vous ne devez pas créer de clients qui essaient d'établir des connexions TLS avec le cluster tant que le chiffrement en transit n'est pas terminé.
Il existe plusieurs manières d'être averti lorsque le chiffrement en transit est terminé avec succès ou a échoué : (non illustré dans l'exemple de code ci-dessus) :
+ Utilisation du service SNS pour recevoir une notification lorsque le chiffrement est terminé
+ Utilisation de l'API `describe-events` qui émet un événement lorsque le chiffrement est terminé
+ Affichage d'un message dans la ElastiCache console indiquant que le chiffrement est terminé
Vous pouvez également implémenter une logique dans votre application pour savoir si le chiffrement est terminé. Dans l'exemple ci-dessus, nous avons vu plusieurs manières de nous assurer que le cluster termine la migration :
+ Attendre le début du processus de migration (le statut du cluster passe à « en cours de modification ») et attendre que la modification soit terminée (le statut du cluster redevient « disponible »)
+ Affirmer que le cluster a `transit_encryption_enabled` défini sur True en interrogeant l'API `describe-replication-group`.
### Après avoir activé le chiffrement en transit : veillez à ce que les clients que vous utilisez soient correctement configurés
Lorsque le cluster est en mode TLS préféré, votre application doit ouvrir des connexions TLS vers le cluster et utiliser uniquement ces connexions. Ainsi, votre application ne connaît pas d'interruption lors de l'activation du chiffrement en transit. Vous pouvez vous assurer qu'il n'existe pas de connexions TCP plus claires avec le moteur Valkey ou Redis OSS à l'aide de la commande info dans la section SSL.
```
# SSL
ssl_enabled:yes
ssl_current_certificate_not_before_date:Mar 20 23:27:07 2017 GMT
ssl_current_certificate_not_after_date:Feb 24 23:27:07 2117 GMT
ssl_current_certificate_serial:D8C7DEA91E684163
tls_mode_connected_tcp_clients:0 (should be zero)
tls_mode_connected_tls_clients:100
```
## Connexion à des nœuds activés avec le chiffrement en transit à l'aide d'OpenSSL (Memcached)
Pour accéder aux données depuis ElastiCache les nœuds Memcached dotés du chiffrement en transit, vous devez utiliser des clients qui fonctionnent avec le protocole SSL (Secure Socket Layer). Vous pouvez également utiliser openssl s\$1client sur Amazon Linux et Amazon Linux 2.
Pour utiliser openssl s\$1client afin de se connecter à un cluster Memcached activé avec le chiffrement en transit sur Amazon Linux 2 ou Amazon Linux :
```
/usr/bin/openssl s_client -connect memcached-node-endpoint:memcached-port
```
## Création d'un client Memcached en mode TLS avec Java
Pour créer un client en mode TLS, procédez comme suit pour initialiser le client avec le code approprié : SSLContext
```
import java.security.KeyStore;
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;
import net.spy.memcached.AddrUtil;
import net.spy.memcached.ConnectionFactoryBuilder;
import net.spy.memcached.MemcachedClient;
public class TLSDemo {
public static void main(String[] args) throws Exception {
ConnectionFactoryBuilder connectionFactoryBuilder = new ConnectionFactoryBuilder();
// Build SSLContext
TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init((KeyStore) null);
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(null, tmf.getTrustManagers(), null);
// Create the client in TLS mode
connectionFactoryBuilder.setSSLContext(sslContext);
MemcachedClient client = new MemcachedClient(connectionFactoryBuilder.build(), AddrUtil.getAddresses("mycluster.fnjyzo.cfg.use1.cache.amazonaws.com:11211"));
// Store a data item for an hour.
client.set("theKey", 3600, "This is the data value");
}
}
```
## Création d'un client Memcached en mode TLS avec PHP
Pour créer un client en mode TLS, procédez comme suit pour initialiser le client avec le code approprié : SSLContext
```
setOption(Memcached::OPT_CLIENT_MODE, Memcached::DYNAMIC_CLIENT_MODE);
/* Add the memcached's cluster server/s */
$tls_client->addServer($server_endpoint, $server_port);
/* Configure the client to use TLS */
if(!$tls_client->setOption(Memcached::OPT_USE_TLS, 1)) {
echo $tls_client->getLastErrorMessage(), "\n";
exit(1);
}
/* Set your TLS context configurations values.
* See MemcachedTLSContextConfig in memcached-api.php for all configurations */
$tls_config = new MemcachedTLSContextConfig();
$tls_config->hostname = '*.mycluster.fnjyzo.use1.cache.amazonaws.com';
$tls_config->skip_cert_verify = false;
$tls_config->skip_hostname_verify = false;
/* Use the created TLS context configuration object to create OpenSSL's SSL_CTX and set it to your client.
* Note: These TLS context configurations will be applied to all the servers connected to this client. */
$tls_client->createAndSetTLSContext((array)$tls_config);
/* test the TLS connection with set-get scenario: */
/* store the data for 60 seconds in the cluster.
* The client will decide which cache host will store this item.
*/
if($tls_client->set('key', 'value', 60)) {
print "Successfully stored key\n";
} else {
echo "Failed to set key: ", $tls_client->getLastErrorMessage(), "\n";
exit(1);
}
/* retrieve the key */
if ($tls_client->get('key') === 'value') {
print "Successfully retrieved key\n";
} else {
echo "Failed to get key: ", $tls_client->getLastErrorMessage(), "\n";
exit(1);
}
```
Pour plus d'informations sur l'utilisation du client PHP, consultez [Installation du client de ElastiCache cluster pour PHP](Appendix.PHPAutoDiscoverySetup.md).
# Chiffrement au repos dans ElastiCache
Pour garantir la sécurité de vos données, Amazon ElastiCache et Amazon S3 proposent différentes méthodes pour restreindre l'accès aux données de votre cache. Pour plus d’informations, consultez [Amazon VPCs et la ElastiCache sécurité](VPCs.md) et [Identity and Access Management pour Amazon ElastiCache](IAM.md).
ElastiCache le chiffrement au repos est une fonctionnalité visant à renforcer la sécurité des données en chiffrant les données sur disque. Il est toujours activé sur un cache sans serveur. Lorsque cette fonctionnalité est activée, elle chiffre les aspects suivants :
+ Le disque lors des opérations de synchronisation, de sauvegarde et d'échange
+ Sauvegardes stockées dans Amazon S3
Les données stockées sur SSDs (disques SSD) dans des clusters compatibles avec la hiérarchisation des données sont toujours chiffrées.
ElastiCache propose un chiffrement par défaut (géré par le service) au repos, ainsi que la possibilité d'utiliser vos propres clés AWS KMS symétriques gérées par le client dans le [service de gestion des AWS clés (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). Lorsque le cache est sauvegardé, sous les options de chiffrement, choisissez d’utiliser la clé de chiffrement par défaut ou une clé gérée par le client. Pour de plus amples informations, veuillez consulter [Activation du chiffrement au repos](#at-rest-encryption-enable).
**Important**
L'activation du chiffrement au repos sur un cluster Valkey ou Redis OSS basé sur des nœuds existant implique la suppression de votre groupe de réplication existant, **après avoir** exécuté la sauvegarde et la restauration sur le groupe de réplication.
Le chiffrement au repos ne peut être activé sur un cache que lorsqu’il est créé. Puisque du traitement est nécessaire pour chiffrer et déchiffrer les données, activer le chiffrement au repos peut avoir un certain impact sur les performances durant ces opérations. Vous devez référencer vos données avec et sans le chiffrement au repos pour déterminer l'impact sur la performance pour vos cas d'utilisation.
**Topics**
+ [Conditions du chiffrement au repos](#at-rest-encryption-constraints)
+ [Utilisation de clés gérées par le client à partir de AWS KMS](#using-customer-managed-keys-for-elasticache-security)
+ [Activation du chiffrement au repos](#at-rest-encryption-enable)
+ [Voir aussi](#at-rest-encryption-see-also)
## Conditions du chiffrement au repos
Les contraintes suivantes relatives ElastiCache au chiffrement au repos doivent être prises en compte lorsque vous planifiez la mise en œuvre du ElastiCache chiffrement au repos :
+ Le chiffrement au repos est pris en charge sur les groupes de réplication exécutant Valkey 7.2 et versions ultérieures, ainsi que sur les versions Redis OSS (version 3.2.6 prévue pour EOL, voir [calendrier de fin de vie des versions Redis OSS), 4.0.10 ou versions ultérieures](engine-versions.md#deprecated-engine-versions).
+ Le chiffrement au repos est pris en charge uniquement pour les groupes de réplication s'exécutant dans un Amazon VPC.
+ Le chiffrement au repos est pris en charge uniquement pour les groupes de réplication exécutant les types de nœud suivants.
+ R7g, R6gd, R6g, R5, R4, R3
+ M7g, M6g, M5, M4, M3
+ T4, T3, T2
+ C7gn
Pour plus d'informations, consultez [Types de nœuds pris en charge](CacheNodes.SupportedTypes.md)
+ Le chiffrement au repos est activé par la définition explicite du paramètre `AtRestEncryptionEnabled` sur `true`.
+ Le chiffrement au repos peut être activé sur un groupe de réplication uniquement lorsque vous créez le groupe de réplication. Vous ne pouvez pas activer et désactiver le chiffrement au repos en modifiant un groupe de réplication. Pour plus d'informations sur l'implémentation du chiffrement au repos sur un groupe de réplication existant, consultez [Activation du chiffrement au repos](#at-rest-encryption-enable).
+ Si un cluster utilise un type de nœud de la famille r6gd, les données stockées sur SSD sont chiffrées, que le chiffrement au repos soit activé ou non.
+ L'option permettant d'utiliser une clé gérée par le client pour le chiffrement au repos n'est pas disponible dans les régions AWS GovCloud (us-gov-east us-gov-west-1 et -1).
+ Si un cluster utilise un type de nœud de la famille r6gd, les données stockées sur un SSD sont chiffrées à l'aide de la cléAWS KMS gérée par le client choisie (ou du chiffrement géré par le service dans les régions).AWS GovCloud
+ Avec Memcached, le chiffrement au repos n'est pris en charge que sur les caches sans serveur.
+ Lorsque vous utilisez Memcached, l'option permettant d'utiliser une clé gérée par le client pour le chiffrement au repos n'est pas disponible dans les AWS GovCloud régions (us-gov-east-1 et us-gov-west -1).
L'implémentation du chiffrement au repos peut réduire la performance lors des opérations de sauvegarde et de synchronisation de nœud. Référencez le chiffrement au repos en comparaison avec l'absence de chiffrement sur vos propres données pour déterminer l'impact sur la performance pour votre cas d'utilisation.
## Utilisation de clés gérées par le client à partir de AWS KMS
ElastiCache prend en charge les clés AWS KMS 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 de plus amples informations, veuillez consulter [Clés AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) dans le *Guide du développeur AWS Key Management Service*. Les clés doivent être créées dans AWS KMS avant de pouvoir être utilisées avec ElastiCache.
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*.
ElastiCache vous permet de vous intégrer àAWS KMS. 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 ElastiCache l'intégration d'Amazon àAWS KMS.
La clé de `kms:ViaService` condition limite l'utilisation d'une cléAWS KMS (clé KMS) aux demandes provenant de AWS services spécifiques. À utiliser `kms:ViaService` avec ElastiCache, incluez les deux ViaService noms dans la valeur de la clé de condition : `elasticache.AWS_region.amazonaws.com` et`dax.AWS_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'[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)utiliser pour suivre les demandes qu'Amazon ElastiCache envoie AWS Key Management Service en votre 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 ElastiCache créées en appelant l'appel d'API [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html)KMS.
Une fois un groupe de réplication chiffré à l'aide d'une clé gérée par le client, toutes les sauvegardes pour le groupe de réplication sont chiffrées comme suit :
+ Les sauvegardes quotidiennes automatiques sont chiffrées à l'aide de la clé gérée par le client associée au cluster.
+ La sauvegarde finale créée quand le groupe de réplication est supprimé est également chiffrée à l'aide de la clé gérée par le client associée au groupe de réplication.
+ Les sauvegardes manuellement créées sont chiffrées par défaut pour utiliser la clé KMS associée au groupe de réplication. Vous pouvez la remplacer en choisissant une autre clé gérée par le client.
+ Copier une sauvegarde revient à utiliser une clé gérée par le client associée à la sauvegarde de la 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 lorsque vous exportez des sauvegardes vers le compartiment Amazon S3 sélectionné. Cependant, toutes les sauvegardes exportées vers Amazon S3 sont chiffrées à l'aide du [Chiffrement côté client](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). Vous pouvez choisir de copier le fichier de sauvegarde vers un nouvel objet S3 et le chiffrer à l'aide d'une clé KMS gérée par le client, copier le fichier vers un autre compartiment S3 configuré avec le chiffrement par défaut à l'aide d'une clé KMS ou changer une option de chiffrement dans le fichier lui-même.
Vous pouvez toujours utiliser des clés gérées par le client pour chiffrer des sauvegardes manuellement créées pour les groupes de réplication qui n'utilisent pas de clés gérées par le client pour le chiffrement. Avec cette option, le fichier de sauvegarde stocké dans Amazon S3 est chiffré à l'aide d'une clé KMS, même quand les données ne sont pas chiffrées sur le groupe de réplication original.
La restauration à partir d'une sauvegarde vous permet de choisir parmi les options de chiffrement disponibles, comme pour les choix de chiffrement disponibles lors de la création d'un nouveau groupe de réplication.
+ Si vous supprimez la clé ou si vous la [désactivez](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) et [révoquez les octrois](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) pour la clé que vous avez utilisée pour chiffrer un cache, ce dernier 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 afin de créer une sauvegarde à des fins d'archive.
+ 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 ElastiCache données. Les ElastiCache caches Amazon 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 [Rotation des clés AWS KMS](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 ElastiCache cache à l'aide d'une clé KMS nécessite une autorisation par cache. Cet octroi est utilisé pendant toute la durée de vie du cache. De plus, un octroi par sauvegarde est utilisé pendant la création de la sauvegarde. Cet octroi est retiré une fois la sauvegarde créée.
+ Pour plus d'informations sur les AWS autorisations et les limites KMS, consultez la section [Limites](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) du *guide du développeur du service de gestion des AWS clés*.
## Activation du chiffrement au repos
Le chiffrement au repos est activé pour tous les caches sans serveur.
Lorsque vous créez un cluster basé sur des nœuds, vous pouvez activer le chiffrement au repos en définissant le paramètre sur. `AtRestEncryptionEnabled` `true` Vous ne pouvez pas activer le chiffrement au repos sur les groupes de réplication existants.
Vous pouvez activer le chiffrement au repos lorsque vous créez un ElastiCache cache. Vous pouvez le faire à l'aide de AWS Management Console, de AWS CLI, ou de l' ElastiCache API.
Lorsque vous créez un cache, vous pouvez sélectionner l’une des options suivantes :
+ **Par défaut** : cette option utilise le chiffrement au repos géré par service.
+ **Clé gérée par le client** : cette option vous permet de fournir la clé ID/ARN depuis AWS KMS pour le chiffrement au repos.
Pour savoir comment créer des clés racines AWS KMS, consultez la section [Créer des 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*
**Contents**
+ [Activation du chiffrement au repos à l'aide du AWS Management Console](#at-rest-encryption-enable-con)
+ [Activation du chiffrement au repos à l'aide du AWS CLI](#at-rest-encryption-enable-cli)
### Activation du chiffrement au repos sur un cluster Valkey ou Redis OSS basé sur un nœud existant
Vous ne pouvez activer le chiffrement au repos que lorsque vous créez un groupe de réplication Valkey ou Redis OSS. Si vous disposez déjà d'un groupe de réplication sur lequel vous souhaitez activer le chiffrement au repos, procédez comme suit.
**Pour activer le chiffrement au repos sur un groupe de réplication existant**
1. Créez une sauvegarde manuelle de votre groupe de réplication existant. Pour de plus amples informations, veuillez consulter [Réalisation de sauvegardes manuelles](backups-manual.md).
1. Créez un groupe de réplication en restaurant la sauvegarde. Sur le nouveau groupe de réplication, activez le chiffrement au repos. Pour de plus amples informations, veuillez consulter [Restauration à partir d’une sauvegarde dans un nouveau cache](backups-restoring.md).
1. Dans votre application, mettez à jour les points de terminaison pour pointer vers le nouveau groupe de réplication.
1. Supprimez l'ancien groupe de réplication. Pour plus d’informations, consultez [Supprimer un cluster dans ElastiCache](Clusters.Delete.md) ou [Suppression d'un groupe de réplication](Replication.DeletingRepGroup.md).
### Activation du chiffrement au repos à l'aide du AWS Management Console
#### Activation du chiffrement au repos sur un cache sans serveur (console)
Le chiffrement au repos est activé pour tous les caches sans serveur. Par défaut, une clé KMS AWS appartenant à l'utilisateur est utilisée pour chiffrer les données. Pour choisir votre propre AWS KMS clé, effectuez les sélections suivantes :
+ Développez la section **Paramètres par défaut**.
+ Choisissez **Personnaliser les paramètres par défaut** dans la section **Paramètres par défaut**.
+ Choisissez **Personnaliser vos paramètres de sécurité** dans la section **Sécurité**.
+ Choisissez **Clé CMK gérée par le client** sous le paramètre **Clé de chiffrement**.
+ Sélectionnez une clé sous le paramètre **CléAWS KMS**.
#### Activation du chiffrement au repos sur un cluster basé sur un nœud (console)
Lorsque vous concevez votre propre cache, le chiffrement au repos est activé à l’aide de la clé **Par défaut** pour les configurations « Dev/Test » et « Production » avec la méthode « Création facile ». Lorsque vous choisissez vous-même la configuration, effectuez les sélections suivantes :
+ Choisissez la version 3.2.6, 4.0.10 ou ultérieure en tant que version de moteur.
+ Cochez la case en regard de **Activer** pour l’option **Chiffrement au repos**.
+ Choisissez **Clé par défaut** ou **Clé CMK gérée par le client**.
Pour la step-by-step procédure, reportez-vous à la section suivante :
+ [Création d'un cluster Valkey (mode cluster désactivé) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ [Création d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
### Activation du chiffrement au repos à l'aide du AWS CLI
Pour activer le chiffrement au repos lors de la création d'un cluster Valkey ou Redis OSS à l'aide du AWS CLI at-rest-encryption-enabled paramètre *--* lors de la création d'un groupe de réplication.
#### Activation du chiffrement au repos sur un cluster (CLI) Valkey ou Redis OSS (mode cluster désactivé)
L'opération suivante crée le groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) `my-classic-rg` avec trois nœuds (*-- num-cache-clusters*), une réplique principale et deux répliques en lecture. Le chiffrement au repos est activé pour ce groupe de réplication (*-- at-rest-encryption-enabled*).
Les paramètres suivants, ainsi que leurs valeurs, sont nécessaires à l'activation du chiffrement sur ce groupe de réplication :
**Paramètres clés**
+ **--engine**—Ça doit être `valkey` ou. `redis`
+ **--engine-version**—Si le moteur est Redis OSS, il doit être 3.2.6, 4.0.10 ou version ultérieure.
+ **--at-rest-encryption-enabled** : requis pour activer le chiffrement au repos.
**Example 1 : Cluster Valkey ou Redis OSS (mode cluster désactivé) avec répliques**
Pour Linux, macOS ou Unix :
```
aws elasticache create-replication-group \
--replication-group-id my-classic-rg \
--replication-group-description "3 node replication group" \
--cache-node-type cache.m4.large \
--engine redis \
--at-rest-encryption-enabled \
--num-cache-clusters 3
```
Pour Windows :
```
aws elasticache create-replication-group ^
--replication-group-id my-classic-rg ^
--replication-group-description "3 node replication group" ^
--cache-node-type cache.m4.large ^
--engine redis ^
--at-rest-encryption-enabled ^
--num-cache-clusters 3 ^
```
Pour plus d'informations, consultez les éléments suivants :
+ [Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster désactivé) à partir de zéro ()AWS CLI](Replication.CreatingReplGroup.NoExistingCluster.Classic.md#Replication.CreatingReplGroup.NoExistingCluster.Classic.CLI)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
#### Activation du chiffrement au repos sur un cluster pour Valkey ou Redis OSS (mode cluster activé) (CLI)
L'opération suivante crée le groupe de réplication Valkey ou Redis OSS (mode cluster activé) `my-clustered-rg` avec trois groupes de nœuds ou partitions (*--*). num-node-groups Chacun possède trois nœuds, un nœud principal et deux répliques de lecture (*-- replicas-per-node-group*). Le chiffrement au repos est activé pour ce groupe de réplication (*-- at-rest-encryption-enabled*).
Les paramètres suivants, ainsi que leurs valeurs, sont nécessaires à l'activation du chiffrement sur ce groupe de réplication :
**Paramètres clés**
+ **--engine**—Ça doit être `valkey` ou. `redis`
+ **--engine-version**—Si le moteur est Redis OSS, il doit être 4.0.10 ou version ultérieure.
+ **--at-rest-encryption-enabled** : requis pour activer le chiffrement au repos.
+ **--cache-parameter-group** : doit indiquer `default-redis4.0.cluster.on` ou l'un de ses dérivés afin de faire de ce cluster un groupe de réplication activé sur le mode.
**Example 2 : Un cluster Valkey ou Redis OSS (mode cluster activé)**
Pour Linux, macOS ou Unix :
```
aws elasticache create-replication-group \
--replication-group-id my-clustered-rg \
--replication-group-description "redis clustered cluster" \
--cache-node-type cache.m3.large \
--num-node-groups 3 \
--replicas-per-node-group 2 \
--engine redis \
--engine-version 6.2 \
--at-rest-encryption-enabled \
--cache-parameter-group default.redis6.x.cluster.on
```
Pour Windows :
```
aws elasticache create-replication-group ^
--replication-group-id my-clustered-rg ^
--replication-group-description "redis clustered cluster" ^
--cache-node-type cache.m3.large ^
--num-node-groups 3 ^
--replicas-per-node-group 2 ^
--engine redis ^
--engine-version 6.2 ^
--at-rest-encryption-enabled ^
--cache-parameter-group default.redis6.x.cluster.on
```
Pour plus d'informations, consultez les éléments suivants :
+ [Création d'un groupe de réplication Valkey ou Redis OSS (mode cluster activé) à partir de zéro ()AWS CLI](Replication.CreatingReplGroup.NoExistingCluster.Cluster.md#Replication.CreatingReplGroup.NoExistingCluster.Cluster.CLI)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
## Voir aussi
+ [Amazon VPCs et la ElastiCache sécurité](VPCs.md)
+ [Identity and Access Management pour Amazon ElastiCache](IAM.md)
# Authentification et autorisation
AWS Identity and Access Management (IAM) est un service Web qui vous permet de contrôler en toute sécurité l'accès aux ressources. AWS ElastiCache prend en charge l'authentification des utilisateurs à l'aide d'IAM et de la commande Valkey et Redis OSS AUTH, et l'autorisation des opérations des utilisateurs à l'aide du contrôle d'accès basé sur les rôles (RBAC).
**Topics**
+ [Contrôle d'accès basé sur les rôles (RBAC)](Clusters.RBAC.md)
+ [Authentification avec la commande Valkey et Redis OSS AUTH](auth.md)
+ [Désactivation du contrôle d'accès sur un cache ElastiCache Valkey ou Redis OSS](in-transit-encryption-disable.md)
# Contrôle d'accès basé sur les rôles (RBAC)
Avec la commande Valkey et Redis OSS AUTH décrite dans la section, [Authentification avec la commande Valkey et Redis OSS AUTH](auth.md) vous pouvez utiliser le contrôle d'accès basé sur les rôles (RBAC). Le RBAC est également le seul moyen de contrôler l’accès aux caches sans serveur. Ceci est disponible pour Valkey 7.2 et versions ultérieures, ainsi que pour Redis OSS 6.0 à 7.2.
Le RBAC vous permet de :
+ Contrôlez l'accès au cache par le biais de groupes d'utilisateurs. Ces groupes d’utilisateurs sont conçus comme un moyen d’organiser l’accès aux caches.
+ Avec *AuthN*, utilisez des mots de passe par utilisateur plutôt que par des jetons d'authentification par cluster.
+ Avec *AuthZ*, affinez les autorisations utilisateur.
+ Basez l'accès à votre cluster sur ACLs.
Contrairement à Valkey et Redis OSS AUTH, où tous les clients authentifiés ont un accès complet au cache si leur jeton est authentifié, le RBAC vous permet d'affecter des utilisateurs à des ensembles en fonction des rôles souhaités par les utilisateurs. Ces ensembles sont conçus pour organiser l'accès aux caches.
Avec RBAC, vous créez des utilisateurs et leur attribuez des autorisations spécifiques à l'aide d'une chaîne d'accès, comme décrit ci-dessous. Vous assignez les utilisateurs à des ensembles correspondant à un rôle spécifique (administrateurs, ressources humaines) qui sont ensuite déployés dans un ou plusieurs ElastiCache caches. Ce faisant, vous pouvez établir des limites de sécurité entre les clients utilisant le ou les mêmes caches Valkey ou Redis OSS, et empêcher les clients d'accéder aux données des autres.
Le RBAC est conçu pour prendre en charge l'introduction de l'[ACL](https://valkey.io/topics/acl/) dans Redis OSS 6. Lorsque vous utilisez RBAC avec votre cache ElastiCache Valkey ou Redis OSS, certaines limites s'appliquent :
+ Un groupe d'utilisateurs configuré pour le moteur « VALKEY » ne peut contenir que des utilisateurs utilisant un mécanisme d'authentification (mot de passe ou IAM). Cela signifie que tous les utilisateurs du moteur « VALKEY », ainsi que tous les autres utilisateurs du moteur « Redis » dont la configuration est configurée pour s'authentifier par mot de passe ou IAM, peuvent faire partie de ce groupe d'utilisateurs.
+ Lors de l'utilisation de RBAC avec des clusters Valkey, les deux groupes d'utilisateurs avec le moteur « VALKEY » et avec le moteur « REDIS » peuvent être utilisés.
+ Lorsque vous utilisez RBAC avec des clusters Redis OSS, seuls les groupes d'utilisateurs dotés du moteur « REDIS » peuvent être utilisés.
+ 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/AmazonElastiCache/latest/APIReference/API_CreateUser.html)ou par [ModifyUser](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyUser.html)appels.
+ Pour les droits des utilisateurs, vous activez ou désactivez les utilisateurs à l'aide du `on` et `off` dans le cadre de la chaîne d'accès. Si ni l’un ni l’autre n’est spécifié dans la chaîne d’accès, l’utilisateur se voit attribuer `off` et ne dispose pas de droits d’accès au cache.
+ Vous ne pouvez pas utiliser de commandes interdites ou renommées dans le cadre de la chaîne d'accès. Si vous spécifiez une commande interdite ou renommée, une exception est émise. Si vous souhaitez utiliser des listes de contrôle d'accès (ACLs) pour une commande renommée, spécifiez le nom d'origine de la commande, c'est-à-dire le nom de la commande avant qu'elle ne soit renommée.
+ 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 ElastiCache pour Valkey et Redis, OSS 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 ACL appliquées à chaque utilisateur. ElastiCache prend en charge la `ACL LIST` commande, mais n'inclut pas le support pour le hachage des mots de passe comme le fait Redis OSS. Avec ElastiCache, vous pouvez utiliser l'[DescribeUsers](https://docs.aws.amazon.com/AmazonElastiCache/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/AmazonElastiCache/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 ElastiCache Valkey et Redis OSS 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) ElastiCache pour Valkey et Redis OSS ne prend en charge aucune autre commande ACL basée sur l'écriture.
+ Les limites suivantes s'appliquent :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonElastiCache/latest/dg/Clusters.RBAC.html)
**RBAC avec Valkey**
Lorsque vous utilisez le contrôle d'accès basé sur les rôles avec Valkey, les utilisateurs et les groupes d'utilisateurs sont créés avec le type de moteur « VALKEY ». Cela est recommandé, car par défaut, Valkey avec RBAC offre une sécurité accrue par rapport à Redis OSS. Les clusters Valkey provisionnés et sans serveur prennent en charge les associations d'utilisateurs et de groupes d'utilisateurs VALKEY.
Les principales fonctionnalités de Valkey Access Control incluent :
+ Les utilisateurs de Valkey sont limités aux associations de groupes d'utilisateurs Valkey uniquement.
+ Les groupes d'utilisateurs Valkey peuvent contenir des utilisateurs Valkey et des utilisateurs Redis OSS protégés par mot de passe ou activés pour l'authentification IAM.
+ Les utilisateurs de Valkey doivent utiliser la protection par mot de passe ou l'authentification IAM.
+ Les groupes d'utilisateurs VALKEY ne peuvent être associés qu'aux clusters VALKEY
+ Il n'y a aucune exigence utilisateur par défaut. Lorsque le groupe d'utilisateurs Valkey est attaché à des clusters, l'exigence utilisateur par défaut est automatiquement désactivée. Les clients verront que l'utilisateur par défaut est désactivé lorsqu'ils utilisent la commande ACL LIST.
Vous trouverez ci-dessous de plus amples informations sur l'utilisation de RBAC ElastiCache pour Valkey et Redis OSS.
**Topics**
+ [Définition des autorisations à l'aide d'une chaîne d'accès](#Access-string)
+ [Appliquer le RBAC à un cache ElastiCache pour Valkey ou Redis OSS](#rbac-using)
+ [Migration d'AUTH vers RBAC](#Migrate-From-RBAC-to-Auth)
+ [Migration de RBAC vers AUTH](#Migrate-From-RBAC-to-AUTH-1)
+ [Rotation automatique des mots de passe pour les utilisateurs](User-Secrets-Manager.md)
+ [Authentification avec IAM](auth-iam.md)
## Définition des autorisations à l'aide d'une chaîne d'accès
Pour spécifier les autorisations d'accès à un cache ElastiCache Valkey ou Redis OSS, vous créez une chaîne d'accès et vous l'attribuez à un utilisateur via 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 s'il y a des redondances 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.
+ `+@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 groupes d'utilisateurs avec la console et la CLI](#Users-management).
Si vous migrez une charge de travail existante vers ElastiCache, 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.
Pour Redis OSS version 6.2 et versions ultérieures, la syntaxe de chaîne d'accès suivante est également prise en charge :
+ `&*` : l'accès est accordé à tous les canaux disponibles.
Pour Redis OSS version 7.0 et supérieure, la syntaxe de chaîne d'accès suivante est également prise en charge :
+ `|` : peut être utilisé pour bloquer des sous-commandes (par exemple « -config\$1set »).
+ `%R~` : ajoute le modèle de clé de lecture spécifié. Il se comporte de la même manière que le modèle de clé normal, mais il n'autorise que la lecture à partir de clés correspondant au modèle donné. Pour plus d'informations, consultez [key permissions](https://valkey.io/topics/acl/) (Autorisations de clés).
+ `%W~` : ajoute le modèle de clé d'écriture spécifié. Il se comporte de la même manière que le modèle de clé normal, mais il n'autorise que l'écriture à partir de clés correspondant au modèle donné. Consultez la section [Autorisations relatives aux clés ACL](https://valkey.io/topics/acl/) pour plus d'informations.
+ `%RW~` : alias pour `~`.
+ `()` : crée un nouveau sélecteur auquel comparer les règles. Les sélecteurs sont évalués en fonction des autorisations utilisateur et de l'ordre dans lequel ils sont définis. Si une commande correspond aux autorisations utilisateur ou à n'importe quel sélecteur, elle est autorisée. Pour plus d'informations, consultez [ACL selectors](https://valkey.io/topics/acl/) (Sélecteurs ACL).
+ `clearselectors` : supprime tous les sélecteurs associés à l'utilisateur.
## Appliquer le RBAC à un cache ElastiCache pour Valkey ou Redis OSS
ElastiCache Pour l'utiliser pour Valkey ou Redis OSS RBAC, vous devez suivre les étapes suivantes :
1. Créez un ou plusieurs utilisateurs.
1. Créez un groupe d'utilisateurs puis ajoutez-y des utilisateurs.
1. Attribuez le groupe d’utilisateurs à un cache ayant le chiffrement en transit activé.
Ces étapes sont décrites en détail comme suit.
**Topics**
+ [Création d'utilisateurs et de groupes d'utilisateurs avec la console et la CLI](#Users-management)
+ [Gestion des groupes d'utilisateurs avec la console et la CLI](#User-Groups)
+ [Attribution de groupes d’utilisateurs à des caches sans serveur](#Users-groups-to-serverless-caches)
+ [Attribution de groupes d'utilisateurs à des groupes de réplication](#Users-groups-to-RGs)
### Création d'utilisateurs et de groupes d'utilisateurs avec la console et la CLI
Les informations utilisateur pour les utilisateurs RBAC sont un ID utilisateur, 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. L'ID utilisateur est unique à l'utilisateur, et le nom d'utilisateur est celui qui est transmis au moteur.
Assurez-vous que les autorisations d'utilisateur que vous fournissez correspondent à l'objectif visé du groupe d'utilisateurs. Par exemple, si vous créez un groupe d'utilisateurs appelé `Administrators`, tout utilisateur que vous ajoutez à ce groupe doit avoir sa chaîne d'accès définie pour un accès complet aux clés et aux commandes. Pour les utilisateurs d'un groupe d'utilisateurs `e-commerce`, vous pouvez définir leurs chaînes d'accès en lecture seule.
ElastiCache configure automatiquement un utilisateur par défaut avec son ID utilisateur et son nom d'utilisateur `"default"` et l'ajoute à tous les groupes d'utilisateurs. 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.
Pour ajouter un contrôle d’accès approprié à un cache, remplacez cet utilisateur par défaut par un nouvel utilisateur qui n’est pas activé ou qui utilise un mot de passe fort. Pour modifier l'utilisateur par défaut, créez un nouvel utilisateur avec le nom d'utilisateur défini sur `default`. Vous pouvez ensuite l'échanger avec l'utilisateur par défaut d'origine.
Les procédures suivantes montrent comment échanger l'utilisateur `default` d'origine avec un autre utilisateur `default` qui a une chaîne d'accès modifiée.
**Pour modifier l'utilisateur par défaut sur la console**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Choisissez **Gestion des groupes d’utilisateurs** dans le volet de navigation.
1. Pour **ID de groupe d’utilisateurs**, choisissez l’ID que vous souhaitez modifier. Assurez-vous de sélectionner le lien et non pas la case à cocher.
1. Sélectionnez **Modifier**.
1. Dans la fenêtre **Modifier**, choisissez **Gérer**. Pour « sélectionner l'utilisateur que vous souhaitez », sélectionnez l'utilisateur dont le nom d'utilisateur est le **nom d'utilisateur** par défaut.
1. Choisissez **Choisir**.
1. Sélectionnez **Modifier**. Lorsque vous effectuez cette opération, toutes les connexions existantes à un cache que possède l’utilisateur par défaut d’origine sont interrompues.
**Pour modifier l'utilisateur par défaut à l'aide du AWS CLI**
1. Créez un utilisateur avec le nom d'utilisateur `default` à l'aide des commandes suivantes.
Pour Linux, macOS ou Unix :
```
aws elasticache create-user \
--user-id "new-default-user" \
--user-name "default" \
--engine "VALKEY" \
--passwords "a-str0ng-pa))word" \
--access-string "off +get ~keys*"
```
Pour Windows :
```
aws elasticache create-user ^
--user-id "new-default-user" ^
--user-name "default" ^
--engine "VALKEY" ^
--passwords "a-str0ng-pa))word" ^
--access-string "off +get ~keys*"
```
1. Créez un groupe d'utilisateurs et ajoutez l'utilisateur que vous avez créé précédemment.
Pour Linux, macOS ou Unix :
```
aws elasticache create-user-group \
--user-group-id "new-group-2" \
--engine "VALKEY" \
--user-ids "new-default-user"
```
Pour Windows :
```
aws elasticache create-user-group ^
--user-group-id "new-group-2" ^
--engine "VALKEY" ^
--user-ids "new-default-user"
```
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 caches sont maintenues.
Tenez compte en particulier de ces contraintes liées au mot de passe utilisateur lorsque vous utilisez RBAC ElastiCache pour Valkey et Redis OSS :
+ 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
Utilisez la procédure suivante pour gérer les utilisateurs sur la console.
**Pour gérer les utilisateurs sur la console**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Sur le ElastiCache tableau de bord Amazon, choisissez **Gestion des utilisateurs**. Les options suivantes sont disponibles :
+ **Créer un utilisateur** : lors de la création d’un utilisateur, vous entrez un ID utilisateur, un nom d’utilisateur, un mode d’authentification et 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.
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 caches sont maintenues.
+ **Modifier l’utilisateur** : permet de mettre à jour les paramètres d’authentification d’un utilisateur ou de modifier sa chaîne d’accès.
+ **Supprimer un utilisateur** : le compte sera supprimé de tous les groupes d’utilisateurs auxquels il appartient.
Utilisez les procédures suivantes pour gérer les utilisateurs avec l'AWS CLI.
**Pour modifier un utilisateur à l'aide de la CLI**
+ Utilisez la commande `modify-user` pour mettre à jour le mot de passe ou les mots de passe d'un utilisateur ou modifier les autorisations d'accès d'un utilisateur.
Lorsqu’un utilisateur est modifié, les groupes d’utilisateurs associés à l’utilisateur sont mis à jour, ainsi que les caches associés au groupe d’utilisateurs. Toutes les connexions existantes sont maintenues. Voici quelques exemples.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-user \
--user-id user-id-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode Type=iam
```
Pour Windows :
```
aws elasticache modify-user ^
--user-id user-id-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode Type=iam
```
**Note**
Nous vous déconseillons d'utiliser l'option `nopass`. Si vous le faites, nous vous recommandons de définir les autorisations de l'utilisateur en lecture seule avec accès à un ensemble limité de clés.
**Pour supprimer un utilisateur à l'aide de la CLI**
+ Utilisez la commande `delete-user` pour supprimer un utilisateur. Le compte est supprimé et retiré des groupes d'utilisateurs auxquels il appartient. Voici un exemple.
Pour Linux, macOS ou Unix :
```
aws elasticache delete-user \
--user-id user-id-2
```
Pour Windows :
```
aws elasticache delete-user ^
--user-id user-id-2
```
Pour afficher une liste des utilisateurs, appelez l'opération [describe-users](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-users.html).
```
aws elasticache describe-users
```
### Gestion des groupes d'utilisateurs avec la console et la CLI
Vous pouvez créer des groupes d’utilisateurs pour organiser et contrôler l’accès des utilisateurs à un ou plusieurs caches, comme indiqué ci-dessous.
Utilisez la procédure suivante pour gérer des groupes d'utilisateurs à l'aide de la console.
**Pour gérer les groupes d'utilisateurs à l'aide de la console**
1. Connectez-vous à la ElastiCache console Amazon AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Sur le ElastiCache tableau de bord Amazon, choisissez **User group management**.
Les opérations suivantes sont disponibles pour créer de nouveaux groupes d'utilisateurs :
+ **Créer** : lorsque vous créez un groupe d’utilisateurs, vous ajoutez des utilisateurs, puis affectez les groupes d’utilisateurs à des caches. Par exemple, vous pouvez créer un groupe d’utilisateurs `Admin` pour les utilisateurs qui ont des rôles d’administration sur un cache.
**Important**
Si vous n'utilisez pas de groupe d'utilisateurs Valkey ou Redis OSS, vous devez inclure un utilisateur par défaut lors de la création d'un groupe d'utilisateurs.
+ **Add Users (Ajouter des utilisateurs)** : ajoute des utilisateurs au groupe d'utilisateurs.
+ **Remove Users (Supprimer des utilisateurs)** : supprime des utilisateurs du groupe d'utilisateurs. Lorsque des utilisateurs sont supprimés d’un groupe d’utilisateurs, toutes les connexions existantes qu’ils ont à un cache sont interrompues.
+ **Delete (Supprimer)** : utilisez cette option pour supprimer un groupe d'utilisateurs. Notez que le groupe d'utilisateurs lui-même, et non les utilisateurs appartenant au groupe, sera supprimé.
Pour les groupes d'utilisateurs existants, procédez comme suit :
+ **Add Users (Ajouter des utilisateurs)** : ajoute des utilisateurs existants au groupe d'utilisateurs.
+ **Delete Users (Supprimer des utilisateurs)** : supprime les utilisateurs existants du groupe d'utilisateurs.
**Note**
Les utilisateurs sont supprimés du groupe d'utilisateurs, mais pas supprimés du système.
Utilisez les procédures suivantes pour gérer des groupes d'utilisateurs à l'aide de la CLI.
**Pour créer un groupe d'utilisateurs et ajouter un utilisateur à l'aide de la CLI**
+ Utilisez la commande `create-user-group`, comme illustré ci-dessous.
Pour Linux, macOS ou Unix :
```
aws elasticache create-user-group \
--user-group-id "new-group-1" \
--engine "VALKEY" \
--user-ids user-id-1, user-id-2
```
Pour Windows :
```
aws elasticache create-user-group ^
--user-group-id "new-group-1" ^
--engine "VALKEY" ^
--user-ids user-id-1, user-id-2
```
**Pour modifier un groupe d'utilisateurs en ajoutant de nouveaux utilisateurs ou en supprimant des membres actuels à l'aide de la CLI**
+ Utilisez la commande `modify-user-group`, comme illustré ci-dessous.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-user-group --user-group-id new-group-1 \
--user-ids-to-add user-id-3 \
--user-ids-to-remove user-id-2
```
Pour Windows :
```
aws elasticache modify-user-group --user-group-id new-group-1 ^
--user-ids-to-add user-id-3 ^
--user-ids-to-removere user-id-2
```
**Note**
Toutes les connexions ouvertes appartenant à un utilisateur supprimé d'un groupe d'utilisateurs sont interrompues par cette commande.
**Pour supprimer un groupe d'utilisateurs à l'aide de la CLI**
+ Utilisez la commande `delete-user-group`, comme illustré ci-dessous. Le groupe d'utilisateurs lui-même, et non les utilisateurs appartenant au groupe, est supprimé.
Pour Linux, macOS ou Unix :
```
aws elasticache delete-user-group /
--user-group-id
```
Pour Windows :
```
aws elasticache delete-user-group ^
--user-group-id
```
Pour voir la liste des groupes d'utilisateurs, vous pouvez appeler l'[describe-user-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-user-groups.html)opération.
```
aws elasticache describe-user-groups \
--user-group-id test-group
```
### Attribution de groupes d’utilisateurs à des caches sans serveur
Après avoir créé un groupe d’utilisateurs et ajouté des utilisateurs, la dernière étape de la mise en œuvre du RBAC consiste à attribuer le groupe d’utilisateurs à un cache sans serveur.
#### Attribution de groupes d’utilisateurs à des caches sans serveur à l’aide de la console
Pour ajouter un groupe d'utilisateurs à un cache sans serveur à l'aide du AWS Management Console, procédez comme suit :
+ Pour le cluster en mode désactivé, veuillez consulter [Création d'un cluster Valkey (mode cluster désactivé) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ Pour le cluster en mode activé, veuillez consulter [Création d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
#### Affectation de groupes d'utilisateurs à des caches sans serveur à l'aide du AWS CLI
L'AWS CLI opération suivante crée un cache sans serveur en utilisant le **user-group-id** paramètre avec la valeur`my-user-group-id`. Remplacez le groupe de sous-réseaux `sng-test` par un groupe de sous-réseaux existant.
**Paramètres clés**
+ **--engine**— Ça doit être `VALKEY` ou`REDIS`.
+ **--user-group-id** : cette valeur fournit l’ID du groupe d’utilisateurs comprenant les utilisateurs disposant d’autorisations d’accès spécifiées pour le cache.
Pour Linux, macOS ou Unix :
```
aws elasticache create-serverless-cache \
--serverless-cache-name "new-serverless-cache" \
--description "new-serverless-cache" \
--engine "VALKEY" \
--user-group-id "new-group-1"
```
Pour Windows :
```
aws elasticache create-serverless-cache ^
--serverless-cache-name "new-serverless-cache" ^
--description "new-serverless-cache" ^
--engine "VALKEY" ^
--user-group-id "new-group-1"
```
L'AWS CLI opération suivante modifie un cache sans serveur avec le **user-group-id** paramètre associé à la valeur. `my-user-group-id`
Pour Linux, macOS ou Unix :
```
aws elasticache modify-serverless-cache \
--serverless-cache-name serverless-cache-1 \
--user-group-id "new-group-2"
```
Pour Windows :
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name serverless-cache-1 ^
--user-group-id "new-group-2"
```
Notez que les modifications apportées à un cache sont mises à jour de manière asynchrone. Vous pouvez surveiller cette progression en consultant les événements. Pour de plus amples informations, veuillez consulter [Affichage des ElastiCache événements](ECEvents.Viewing.md).
### Attribution de groupes d'utilisateurs à des groupes de réplication
Après avoir créé un groupe d'utilisateurs et ajouté des utilisateurs, la dernière étape de la mise en œuvre de RBAC consiste à attribuer le groupe d'utilisateurs à un groupe de réplication.
#### Attribution de groupes d'utilisateurs à des groupes de réplication à l'aide de la console
Pour ajouter un groupe d'utilisateurs à une réplication à l'aide du AWS Management Console, procédez comme suit :
+ Pour le cluster en mode désactivé, veuillez consulter [Création d'un cluster Valkey (mode cluster désactivé) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ Pour le cluster en mode activé, veuillez consulter [Création d'un cluster Valkey ou Redis OSS (mode cluster activé) (console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
#### Affectation de groupes d'utilisateurs à des groupes de réplication à l'aide du AWS CLI
L'AWS CLI opération suivante crée un groupe de réplication avec le chiffrement en transit (TLS) activé et le **user-group-ids** paramètre avec la valeur`my-user-group-id`. Remplacez le groupe de sous-réseaux `sng-test` par un groupe de sous-réseaux existant.
**Paramètres clés**
+ **--engine**— Ça doit être `valkey` ou`redis`.
+ **--engine-version** : doit être la version 6.0 ou ultérieure.
+ **--transit-encryption-enabled** : obligatoire pour l'authentification et l'association d'un groupe d'utilisateurs.
+ **--user-group-ids** : cette valeur fournit l’ID du groupe d’utilisateurs comprenant les utilisateurs disposant d’autorisations d’accès spécifiées pour le cache.
+ **--cache-subnet-group** : obligatoire pour associer un groupe d'utilisateurs.
Pour Linux, macOS ou Unix :
```
aws elasticache create-replication-group \
--replication-group-id "new-replication-group" \
--replication-group-description "new-replication-group" \
--engine "VALKEY" \
--cache-node-type cache.m5.large \
--transit-encryption-enabled \
--user-group-ids "new-group-1" \
--cache-subnet-group "cache-subnet-group"
```
Pour Windows :
```
aws elasticache create-replication-group ^
--replication-group-id "new-replication-group" ^
--replication-group-description "new-replication-group" ^
--engine "VALKEY" ^
--cache-node-type cache.m5.large ^
--transit-encryption-enabled ^
--user-group-ids "new-group-1" ^
--cache-subnet-group "cache-subnet-group"
```
L'AWS CLI opération suivante modifie un groupe de réplication avec le chiffrement en transit (TLS) activé et le **user-group-ids** paramètre avec la valeur. `my-user-group-id`
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id replication-group-1 \
--user-group-ids-to-remove "new-group-1" \
--user-group-ids-to-add "new-group-2"
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id replication-group-1 ^
--user-group-ids-to-remove "new-group-1" ^
--user-group-ids-to-add "new-group-2"
```
Notez le `PendingChanges` dans la réponse. Toutes les modifications apportées à un cache sont mises à jour de manière asynchrone. Vous pouvez surveiller cette progression en consultant les événements. Pour de plus amples informations, veuillez consulter [Affichage des ElastiCache événements](ECEvents.Viewing.md).
## Migration d'AUTH vers RBAC
Si vous utilisez AUTH comme décrit dans [Authentification avec la commande Valkey et Redis OSS AUTH](auth.md) et que vous souhaitez migrer vers l'utilisation de RBAC, suivez les procédures suivantes.
Utilisez la procédure suivante pour migrer d'AUTH vers RBAC à l'aide de la console.
**Pour migrer de Valkey ou Redis OSS AUTH vers RBAC à l'aide de la console**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans la liste située dans le coin supérieur droit, choisissez la AWS région dans laquelle se trouve le cache que vous souhaitez modifier.
1. Dans le volet de navigation, choisissez le moteur qui s'exécute sur le cache que vous souhaitez modifier.
La liste des caches pour le moteur choisi s’affiche.
1. Dans la liste des caches, choisissez le nom du cache que vous souhaitez modifier.
1. Pour **Actions**, choisissez **Modifier**.
La fenêtre **Modifier** apparaît.
1. Pour **Contrôle d’accès**, choisissez **Liste de contrôle d’accès de groupe d’utilisateurs**.
1. Pour **Liste de contrôle d’accès de groupe d’utilisateurs**, choisissez un groupe d’utilisateurs.
1. Choisissez **Prévisualiser les modifications**, puis **Modifier** sur l’écran suivant.
Utilisez la procédure suivante pour migrer de Valkey ou Redis OSS AUTH vers RBAC à l'aide de la CLI.
**Pour migrer d'AUTH vers RBAC à l'aide de la CLI**
+ Utilisez la commande `modify-replication-group`, comme illustré ci-dessous.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group --replication-group-id test \
--auth-token-update-strategy DELETE \
--user-group-ids-to-add user-group-1
```
Pour Windows :
```
aws elasticache modify-replication-group --replication-group-id test ^
--auth-token-update-strategy DELETE ^
--user-group-ids-to-add user-group-1
```
## Migration de RBAC vers AUTH
Si vous utilisez RBAC et souhaitez migrer vers Redis OSS AUTH, consultez. [Migration de RBAC vers AUTH](auth.md#Migrate-From-RBAC-to-AUTH)
**Note**
Si vous devez désactiver le contrôle d'accès à un ElastiCache cache, vous devez le faire via le AWS CLI. Pour de plus amples informations, veuillez consulter [Désactivation du contrôle d'accès sur un cache ElastiCache Valkey ou Redis OSS](in-transit-encryption-disable.md).
# Rotation automatique des mots de passe pour les utilisateurs
Vous pouvez AWS Secrets Manager ainsi remplacer les informations d'identification codées en dur dans votre code (y compris les mots de passe) par un appel d'API à Secrets Manager pour récupérer le secret par programmation. Cela permet de garantir que le secret ne peut pas être mis en péril par une personne qui examine votre code, étant donné que le secret n'y figure pas. En outre, vous pouvez configurer Secrets Manager afin d'effectuer automatiquement une rotation du secret, selon une planification que vous spécifiez. Cela vous permet de remplacer les secrets à long terme par ceux à court terme, ce qui réduit considérablement le risque de mise en péril.
À l'aide de Secrets Manager, vous pouvez automatiquement faire pivoter vos ElastiCache mots de passe Redis OSS (c'est-à-dire les secrets) à l'aide d'une AWS Lambda fonction fournie par Secrets Manager.
Pour plus d'informations AWS Secrets Manager, voir [Qu'est-ce que c'est AWS Secrets Manager ?](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)
## Comment ElastiCache utilise les secrets
Valkey 7.2 et versions ultérieures ont un ensemble de fonctionnalités équivalent à celui de Redis OSS 7.0. Dans Redis OSS 6, ElastiCache introduit [Contrôle d'accès basé sur les rôles (RBAC)](Clusters.RBAC.md) pour sécuriser le cluster Valkey ou Redis OSS. Cette fonction permet de limiter certaines connexions en termes de commandes pouvant être exécutées et de clés accessibles. Avec RBAC, lorsque le client crée un utilisateur avec des mots de passe, les valeurs des mots de passe doivent être saisies manuellement en texte clair et visibles de l'opérateur.
Avec Secrets Manager, les applications récupèrent le mot de passe depuis Secrets Manager plutôt que de le saisir manuellement et de le stocker dans la configuration de l'application. Pour plus d’informations sur la procédure à utiliser, consultez [Comment ElastiCache les utilisateurs sont associés au secret](#How-User-Secrets-Manager-Associate).
L'utilisation de secrets entraîne des frais. Pour plus d'informations sur la tarification, consultez [Tarification d'AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/).
## Comment ElastiCache les utilisateurs sont associés au secret
Secrets Manager conservera une référence pour l'utilisateur associé dans le champ `SecretString` du secret. Il n'y aura aucune référence au secret vu de ElastiCache côté.
```
{
"password": "strongpassword",
"username": "user1",
"user_arn": "arn:aws:elasticache:us-east-1:xxxxxxxxxx918:user:user1" //this is the bond between the secret and the user
}
```
## Fonction de rotation Lambda
Pour activer la rotation automatique des mots de passe de Secrets Manager, vous allez créer une fonction Lambda qui interagira avec l'API [modify-user](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-user.html) pour mettre à jour les mots de passe de l'utilisateur.
Pour plus d'informations sur la façon dont cela fonctionne, consultez [Fonctionnement de la rotation](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html#rotate-secrets_how).
**Note**
Pour certains AWS services, afin d'éviter toute confusion dans le scénario adjoint, il est AWS recommandé d'utiliser à la fois les clés de condition `aws:SourceArn` et les clés de condition `aws:SourceAccount` globale. Cependant, si vous incluez la condition `aws:SourceArn` dans votre stratégie de fonction de rotation Lambda, la fonction de rotation ne peut être utilisée que pour effectuer la rotation du secret spécifié par cet ARN. Nous vous recommandons d'inclure uniquement la clé de contexte `aws:SourceAccount` afin de pouvoir utiliser la fonction de rotation pour plusieurs secrets.
Pour tout problème que vous pourriez rencontrer, consultez [Résoudre les problèmes liés à la rotation de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/troubleshoot_rotation.html).
## Comment créer un ElastiCache utilisateur et l'associer à Secrets Manager
Les étapes suivantes illustrent comment créer un utilisateur et l'associer à Secrets Manager :
1. **Créer un utilisateur inactif**
Pour Linux, macOS ou Unix :
```
aws elasticache create-user \
--user-id user1 \
--user-name user1 \
--engine "REDIS" \
--no-password \ // no authentication is required
--access-string "*off* +get ~keys*" // this disables the user
```
Pour Windows :
```
aws elasticache create-user ^
--user-id user1 ^
--user-name user1 ^
--engine "REDIS" ^
--no-password ^ // no authentication is required
--access-string "*off* +get ~keys*" // this disables the user
```
Vous verrez une réponse similaire à ceci :
```
{
"UserId": "user1",
"UserName": "user1",
"Status": "active",
"Engine": "redis",
"AccessString": "off ~keys* -@all +get",
"UserGroupIds": [],
"Authentication": {
"Type": "no_password"
},
"ARN": "arn:aws:elasticache:us-east-1:xxxxxxxxxx918:user:user1"
}
```
1. **Créer un secret**
Pour Linux, macOS ou Unix :
```
aws secretsmanager create-secret \
--name production/ec/user1 \
--secret-string \
'{
"user_arn": "arn:aws:elasticache:us-east-1:123456xxxx:user:user1",
"username":"user1"
}'
```
Pour Windows :
```
aws secretsmanager create-secret ^
--name production/ec/user1 ^
--secret-string ^
'{
"user_arn": "arn:aws:elasticache:us-east-1:123456xxxx:user:user1",
"username":"user1"
}'
```
Vous verrez une réponse similaire à ceci :
```
{
"ARN": "arn:aws:secretsmanager:us-east-1:123456xxxx:secret:production/ec/user1-eaFois",
"Name": "production/ec/user1",
"VersionId": "aae5b963-1e6b-4250-91c6-ebd6c47d0d95"
}
```
1. **Configurer une fonction Lambda pour la rotation de votre mot de passe**
1. Connectez-vous à la console Lambda AWS Management Console et ouvrez-la à l'adresse [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/elasticache/)
1. Dans le volet de navigation, choisissez **Functions** (Fonctions), puis la fonction que vous avez créée. Choisissez le nom de la fonction, et non la case à cocher située à gauche.
1. Cliquez sur l’onglet **Configuration**.
1. Dans **General configuration** (Configuration générale), choisissez **Edit** (Modifier), puis définissez **Timeout** (Expiration) sur 12 minutes minimum.
1. Choisissez **Enregistrer**.
1. Choisissez **Environment variables** (Variables d'environnement), puis définissez les paramètres suivants :
1. SECRETS\$1MANAGER\$1ENDPOINT : https://secretsmanager.**REGION**.amazonaws.com
1. SECRET\$1ARN : l'Amazon Resource Name (ARN) du secret que vous avez créé à l'étape 2.
1. USER\$1NAME — Nom d'utilisateur de l' ElastiCache utilisateur,
1. Choisissez **Enregistrer**.
1. Choisissez **Permissions** (Autorisations).
1. Sous **Execution role** (Rôle d'exécution), choisissez le nom du rôle de la fonction Lambda à afficher sur la console IAM.
1. La fonction Lambda aura besoin de l'autorisation suivante pour modifier les utilisateurs et définir le mot de passe :
ElastiCache
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticache:DescribeUsers",
"elasticache:ModifyUser"
],
"Resource": "arn:aws:elasticache:us-east-1:123456789012:user:user1"
}
]
}
```
------
Secrets Manager
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret",
"secretsmanager:PutSecretValue",
"secretsmanager:UpdateSecretVersionStage"
],
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:XXXX"
},
{
"Effect": "Allow",
"Action": "secretsmanager:GetRandomPassword",
"Resource": "*"
}
]
}
```
------
1. Configurer la rotation des secrets de Secrets Manager
1. **À l'aide de AWS Management Console, voir [Configurer la rotation automatique pour les AWS secrets de Secrets Manager à l'aide de la console](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html)**
Pour plus d'informations sur comment planifier une rotation, consultez [Programmer des expressions en rotation avec Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_schedule.html).
1. **À l'aide du AWS CLI, voir [Configuration de la rotation automatique pour AWS Secrets Manager utiliser le AWS Command Line Interface](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets-cli.html)**
# 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 à ElastiCache Valkey ou Redis OSS à l'aide d'identités AWS IAM, lorsque votre cache 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é. Vous pouvez également utiliser l'authentification IAM pour configurer un contrôle d'accès précis pour chaque ElastiCache cache et chaque ElastiCache utilisateur, conformément aux principes d'autorisation du moindre privilège. L'authentification IAM ElastiCache fonctionne en fournissant un jeton d'authentification IAM de courte durée au lieu d'un mot de passe ElastiCache utilisateur de longue durée dans l'OSS ou la commande Valkey ou Redis. `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 caches Valkey ou Redis OSS.
Pour utiliser AWS IAM avec ElastiCache, vous devez d'abord créer un ElastiCache utilisateur dont le mode d'authentification est défini sur IAM. Vous pouvez ensuite créer ou réutiliser une identité IAM. L'identité IAM a besoin d'une politique associée pour accorder l'`elasticache:Connect`action au ElastiCache cache et à l' ElastiCache utilisateur. 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 comme mot de passe dans votre client Valkey ou Redis OSS lorsque vous vous connectez à votre cache. Un client Valkey ou Redis OSS prenant en charge le fournisseur d'informations d'identification peut générer automatiquement les informations d'identification temporaires pour chaque nouvelle connexion. ElastiCache effectuera l'authentification IAM pour les demandes de connexion des ElastiCache utilisateurs 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 ElastiCache de Valkey 7.2 ou version ultérieure ou de Redis OSS version 7.0 et supérieure.
+ Pour les ElastiCache utilisateurs compatibles IAM, les propriétés du nom d'utilisateur et de l'identifiant utilisateur doivent être identiques.
+ Le jeton d'authentification IAM est valide pendant 15 minutes. Pour les connexions de longue durée, nous vous recommandons d'utiliser un client Valkey ou Redis OSS qui prend en charge une interface de fournisseur d'informations d'identification.
+ Une connexion authentifiée IAM ElastiCache pour Valkey ou Redis OSS 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 prend en charge les clés de contexte de condition globale suivantes :
+ Lorsque vous utilisez l’authentification IAM avec des caches sans serveur, `aws:VpcSourceIp`, `aws:SourceVpc`, `aws:SourceVpce`, `aws:CurrentTime`, `aws:EpochTime` et `aws:ResourceTag/%s` (à partir des caches sans serveur et des utilisateurs associés) sont prises en charge.
+ Lorsque vous utilisez l’authentification IAM avec des groupes de réplication, `aws:SourceIp` et `aws:ResourceTag/%s` (à partir des groupes de réplication et des utilisateurs associés) sont prises en charge.
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éez un cache.
```
aws elasticache create-serverless-cache \
--serverless-cache-name cache-01 \
--description "ElastiCache IAM auth application" \
--engine redis
```
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" : [
"elasticache:Connect"
],
"Resource" : [
"arn:aws:elasticache:us-east-1:123456789012:serverlesscache:cache-01",
"arn:aws:elasticache:us-east-1:123456789012:user:iam-user-01"
]
}
]
}
```
------
1. Créez un rôle IAM.
```
aws iam create-role \
--role-name "elasticache-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Créez la politique IAM.
```
aws iam create-policy \
--policy-name "elasticache-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 "elasticache-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/elasticache-allow-all"
```
1. Créez un compte utilisateur prenant en charge IAM.
```
aws elasticache create-user \
--user-name iam-user-01 \
--user-id iam-user-01 \
--authentication-mode Type=iam \
--engine redis \
--access-string "on ~* +@all"
```
1. Créez un groupe d'utilisateurs et attachez l'utilisateur.
```
aws elasticache create-user-group \
--user-group-id iam-user-group-01 \
--engine redis \
--user-ids default iam-user-01
aws elasticache modify-serverless-cache \
--serverless-cache-name cache-01 \
--user-group-id iam-user-group-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 lorsque vous vous connectez à un cache Valkey ou Redis OSS, comme indiqué dans l'exemple ci-dessous.
```
String userId = "insert user id";
String cacheName = "insert cache name";
boolean isServerless = true;
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 ElastiCache with Redis OSS.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userId, cacheName, region, isServerless);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct Redis OSS URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userId, iamAuthToken)
.build();
// Create a new Lettuce Redis OSS client
RedisClient client = RedisClient.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 PARAM_RESOURCE_TYPE = "ResourceType";
private static final String RESOURCE_TYPE_SERVERLESS_CACHE = "ServerlessCache";
private static final String ACTION_NAME = "connect";
private static final String SERVICE_NAME = "elasticache";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userId;
private final String cacheName;
private final String region;
private final boolean isServerless;
public IAMAuthTokenRequest(String userId, String cacheName, String region, boolean isServerless) {
this.userId = userId;
this.cacheName = cacheName;
this.region = region;
this.isServerless = isServerless;
}
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(userId));
if (isServerless) {
request.addParameters(PARAM_RESOURCE_TYPE, Collections.singletonList(RESOURCE_TYPE_SERVERLESS_CACHE));
}
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, cacheName));
}
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 à ElastiCache l'aide du fournisseur d'informations d'authentification IAM.
```
String userId = "insert user id";
String cacheName = "insert cache name";
boolean isServerless = true;
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 ElastiCache with Redis OSS.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userId, cacheName, region, isServerless);
// Create a Redis OSS credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userId, iamAuthTokenRequest, awsCredentialsProvider);
// Construct Redis OSS URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce Redis OSS client
RedisClient client = RedisClient.create(redisURI);
client.connect();
```
Vous trouverez ci-dessous un exemple de client Lettuce Redis OSS 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 userId;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userId,
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(userId, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
}
```
# Authentification avec la commande Valkey et Redis OSS AUTH
**Note**
Le **AUTH** a été remplacé par. [Contrôle d'accès basé sur les rôles (RBAC)](Clusters.RBAC.md) Tous les caches sans serveur doivent utiliser le contrôle RBAC pour l’authentification.
Les jetons d'authentification ou mots de passe Valkey et Redis OSS permettent à Valkey et Redis OSS d'exiger un mot de passe avant d'autoriser les clients à exécuter des commandes, améliorant ainsi la sécurité des données. Le **AUTH** n'est disponible que pour les clusters basés sur des nœuds.
**Topics**
+ [Présentation de AUTH ElastiCache pour Valkey et Redis OSS](#auth-overview)
+ [Appliquer l'authentification à un cluster ElastiCache pour Valkey et Redis OSS](#auth-using)
+ [Modification du jeton AUTH sur un cluster existant](#auth-modifyng-token)
+ [Migration de RBAC vers AUTH](#Migrate-From-RBAC-to-AUTH)
## Présentation de AUTH ElastiCache pour Valkey et Redis OSS
Lorsque vous utilisez le **AUTH** avec votre cluster ElastiCache for Valkey et Redis OSS, certaines améliorations sont apportées.
Tenez compte en particulier de ces contraintes liées au jeton AUTH ou au mot de passe lorsque vous utilisez AUTH :
+ Les jetons, ou mots de passe, doivent comporter de 16 à 128 caractères imprimables.
+ Les caractères non alphanumériques sont limités à (\$1, &, \$1, \$1, ^, <, >, -).
+ AUTH ne peut être activé que pour les clusters Valkey ou Redis OSS compatibles avec le chiffrement en transit.
Pour configurer un jeton fort, nous vous recommandons de suivre une stratégie de mot de passe stricte, par exemple en exigeant les éléments suivants :
+ Les jetons ou mots de passe doivent inclure au moins trois des types de caractères suivants :
+ Caractères majuscules
+ Caractères minuscules
+ Chiffres
+ Caractères non alphanumériques (`!`, `&`, `#`, `$`, `^`, `<`, `>`, `-`)
+ Les jetons ou mots de passe ne doivent pas contenir un mot du dictionnaire ou un mot du dictionnaire légèrement modifié.
+ Les jetons ou mots de passe ne doivent pas être identiques ou similaires à un jeton récemment utilisé.
## Appliquer l'authentification à un cluster ElastiCache pour Valkey et Redis OSS
Vous pouvez demander aux utilisateurs de saisir un jeton (mot de passe) sur un serveur Valkey ou Redis OSS protégé par des jetons. Pour ce faire, incluez le paramètre `--auth-token` (API : `AuthToken`) avec le jeton correct lorsque vous créez votre groupe ou cluster de réplication. Incluez-le également dans toutes les commandes suivantes vers le groupe ou le cluster de réplication.
L'AWS CLI opération suivante crée un groupe de réplication avec le chiffrement en transit (TLS) activé et le **AUTH** jeton`This-is-a-sample-token`. Remplacez le groupe de sous-réseaux `sng-test` par un groupe de sous-réseaux existant.
**Paramètres clés**
+ **--engine**— Ça doit être `valkey` ou`redis`.
+ **--engine-version**— Si le moteur est Redis OSS, il doit être 3.2.6, 4.0.10 ou version ultérieure.
+ **--transit-encryption-enabled** : obligatoire pour l'authentification et l'éligibilité HIPAA.
+ **--auth-token** : obligatoire pour l'éligibilité HIPAA. Cette valeur doit être le jeton correct pour ce serveur Valkey ou Redis OSS protégé par des jetons.
+ **--cache-subnet-group** : obligatoire pour l'éligibilité HIPAA.
Pour Linux, macOS ou Unix :
```
aws elasticache create-replication-group \
--replication-group-id authtestgroup \
--replication-group-description authtest \
--engine redis \
--cache-node-type cache.m4.large \
--num-node-groups 1 \
--replicas-per-node-group 2 \
--transit-encryption-enabled \
--auth-token This-is-a-sample-token \
--cache-subnet-group sng-test
```
Pour Windows :
```
aws elasticache create-replication-group ^
--replication-group-id authtestgroup ^
--replication-group-description authtest ^
--engine redis ^
--cache-node-type cache.m4.large ^
--num-node-groups 1 ^
--replicas-per-node-group 2 ^
--transit-encryption-enabled ^
--auth-token This-is-a-sample-token ^
--cache-subnet-group sng-test
```
## Modification du jeton AUTH sur un cluster existant
Pour faciliter la mise à jour de votre authentification, vous pouvez modifier le **AUTH** jeton utilisé sur un cluster. Vous pouvez effectuer cette modification si la version du moteur est Valkey 7.2 ou supérieure ou Redis 5.0.6 ou supérieure. ElastiCache le chiffrement en transit doit également être activé.
La modification du jeton d'authentification prend en charge deux stratégies : ROTATE et SET. La stratégie ROTATE ajoute un jeton AUTH supplémentaire au serveur tout en conservant le jeton précédent. La stratégie SET met à jour le serveur pour qu'il ne prenne en charge qu'un seul jeton AUTH. Effectuez ces appels de modification avec le paramètre `--apply-immediately` pour appliquer les modifications immédiatement.
### Rotation du jeton AUTH
Pour mettre à jour un serveur Valkey ou Redis OSS avec un nouveau **jeton AUTH**, appelez l'`ModifyReplicationGroup`API avec le `--auth-token` paramètre comme nouveau **AUTH** jeton et `--auth-token-update-strategy` avec la valeur ROTATE. Une fois la modification ROTATE terminée, le cluster prendra en charge le jeton AUTH précédent en plus de celui spécifié dans le `auth-token` paramètre. Si aucun jeton AUTH n'a été configuré sur le groupe de réplication avant la rotation du jeton AUTH, le cluster prend en charge le jeton AUTH spécifié dans le `--auth-token` paramètre, en plus de prendre en charge la connexion sans authentification. Voir [Définition du jeton AUTH](#auth-modifying-set) pour mettre à jour le jeton AUTH requis à l'aide de la stratégie de mise à jour SET.
**Note**
Si vous ne configurez pas le jeton AUTH auparavant, une fois la modification terminée, le cluster ne prendra en charge aucun jeton AUTH en plus de celui spécifié dans le paramètre auth-token.
Si cette modification est effectuée sur un serveur qui prend déjà en charge deux jetons AUTH, le jeton AUTH le plus ancien sera également supprimé lors de cette opération. Cela permet à un serveur de prendre en charge jusqu'à deux jetons AUTH les plus récents à un moment donné.
À ce stade, vous pouvez procéder en mettant à jour le client pour qu'il utilise le dernier jeton AUTH. Une fois les clients mis à jour, vous pouvez utiliser la stratégie SET pour la rotation des jetons **AUTH** (expliqué dans la section suivante) pour commencer exclusivement à utiliser le nouveau jeton.
L'AWS CLI opération suivante modifie un groupe de réplication pour faire pivoter le **AUTH** jeton`This-is-the-rotated-token`.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id authtestgroup \
--auth-token This-is-the-rotated-token \
--auth-token-update-strategy ROTATE \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id authtestgroup ^
--auth-token This-is-the-rotated-token ^
--auth-token-update-strategy ROTATE ^
--apply-immediately
```
### Définition du jeton AUTH
Pour mettre à jour un serveur Valkey ou Redis OSS afin de prendre en charge un seul **AUTH** jeton requis, appelez l'opération `ModifyReplicationGroup` API avec le `--auth-token` paramètre ayant la même valeur que le dernier jeton AUTH et le `--auth-token-update-strategy` paramètre avec la valeur. `SET` La stratégie SET ne peut être utilisée qu'avec un cluster doté de 2 jetons AUTH ou d'un jeton AUTH optionnel issu d'une stratégie ROTATE auparavant. Une fois la modification terminée, le serveur ne prend en charge que le jeton AUTH spécifié dans le paramètre auth-token.
L'AWS CLI opération suivante modifie un groupe de réplication pour attribuer au jeton AUTH la valeur. `This-is-the-set-token`
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id authtestgroup \
--auth-token This-is-the-set-token \
--auth-token-update-strategy SET \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id authtestgroup ^
--auth-token This-is-the-set-token ^
--auth-token-update-strategy SET ^
--apply-immediately
```
### Activation de l'authentification sur un cluster existant
Pour activer l'authentification sur un serveur Valkey ou Redis OSS existant, appelez l'opération `ModifyReplicationGroup` API. Appelez `ModifyReplicationGroup` avec le paramètre `--auth-token` en tant que nouveau jeton et le paramètre `--auth-token-update-strategy` avec la valeur ROTATE.
Une fois la modification ROTATE terminée, le cluster prend en charge le **AUTH** jeton spécifié dans le `--auth-token` paramètre, en plus de prendre en charge la connexion sans authentification. Une fois que toutes les applications clientes sont mises à jour pour s'authentifier auprès de Valkey ou Redis OSS avec le jeton AUTH, utilisez la stratégie SET pour marquer le jeton AUTH comme requis. L'activation de l'authentification n'est prise en charge que sur les serveurs Valkey et Redis OSS avec le chiffrement en transit (TLS) activé.
## Migration de RBAC vers AUTH
Si vous authentifiez des utilisateurs avec Valkey ou Redis OSS Role-Based Access Control (RBAC) comme décrit dans[Contrôle d'accès basé sur les rôles (RBAC)](Clusters.RBAC.md), et que vous souhaitez migrer vers AUTH, suivez les procédures suivantes. Vous pouvez migrer à l'aide de la console ou de la CLI.
**Pour migrer de RBAC vers AUTH à l'aide de la console**
1. Connectez-vous à la ElastiCache console AWS Management Console et ouvrez-la à l'adresse [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Dans la liste située dans le coin supérieur droit, choisissez la AWS région dans laquelle se trouve le cluster que vous souhaitez modifier.
1. Dans le volet de navigation, choisissez le moteur s'exécutant sur le cluster que vous voulez modifier.
Une liste de clusters du moteur choisi s'affiche.
1. Dans la liste des clusters, choisissez le nom du cluster que vous souhaitez modifier.
1. Pour **Actions**, choisissez **Modifier**.
La fenêtre **Modifier** apparaît.
1. Pour le **contrôle d'accès**, choisissez l'accès **utilisateur par défaut Valkey AUTH ou l'accès utilisateur par défaut** **Redis OSS AUTH.**
1. Sous le jeton **Valkey AUTH ou le jeton** **Redis OSS AUTH, définissez un nouveau jeton**.
1. Choisissez **Prévisualiser les modifications**, puis **Modifier** sur l’écran suivant.
**Pour migrer de RBAC vers AUTH à l'aide du AWS CLI**
Utilisez l'une des commandes suivantes pour configurer un nouveau **AUTH** jeton facultatif pour votre groupe de réplication Valkey ou Redis OSS. Notez qu'un jeton d'authentification facultatif autorisera un accès non authentifié au groupe de réplication jusqu'à ce que le jeton d'authentification soit marqué comme obligatoire, en utilisant la stratégie `SET` de mise à jour décrite à l'étape suivante.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id test \
--remove-user-groups \
--auth-token This-is-a-sample-token \
--auth-token-update-strategy ROTATE \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id test ^
--remove-user-groups ^
--auth-token This-is-a-sample-token ^
--auth-token-update-strategy ROTATE ^
--apply-immediately
```
Après avoir exécuté la commande ci-dessus, vous pouvez mettre à jour vos applications Valkey ou Redis OSS pour vous authentifier auprès du groupe de ElastiCache réplication à l'aide du jeton AUTH optionnel nouvellement configuré. Pour terminer la rotation du jeton d'authentification, utilisez la stratégie de mise à jour décrite `SET` dans la commande suivante ci-dessous. Cela sera marqué sur le jeton AUTH optionnel selon les besoins. Lorsque la mise à jour du jeton d'authentification sera terminée, l'état du groupe de réplication s'affichera comme tel `ACTIVE` et toutes les connexions à ce groupe de réplication nécessiteront une authentification.
Pour Linux, macOS ou Unix :
```
aws elasticache modify-replication-group \
--replication-group-id test \
--auth-token This-is-a-sample-token \
--auth-token-update-strategy SET \
--apply-immediately
```
Pour Windows :
```
aws elasticache modify-replication-group ^
--replication-group-id test ^
--remove-user-groups ^
--auth-token This-is-a-sample-token ^
--auth-token-update-strategy SET ^
--apply-immediately
```
Pour de plus amples informations, veuillez consulter [Authentification avec la commande Valkey et Redis OSS AUTH](#auth).
**Note**
Si vous devez désactiver le contrôle d'accès sur un ElastiCache cluster, consultez[Désactivation du contrôle d'accès sur un cache ElastiCache Valkey ou Redis OSS](in-transit-encryption-disable.md).
# Désactivation du contrôle d'accès sur un cache ElastiCache Valkey ou Redis OSS
Suivez les instructions ci-dessous pour désactiver le contrôle d'accès sur un cache compatible TLS avec Valkey ou Redis OSS. Votre cache aura l'un des deux types de configuration suivants : accès utilisateur par défaut AUTH ou liste de contrôle d'accès des groupes d'utilisateurs (RBAC). Si votre cache a été créé avec la configuration AUTH, vous devez le remplacer par la configuration RBAC avant de pouvoir désactiver le cache en supprimant les groupes d’utilisateurs. Si votre cache a été créé avec la configuration RBAC, vous pouvez directement le désactiver.
**Pour désactiver un cache sans serveur Valkey ou Redis OSS configuré avec RBAC**
1. Supprimez les groupes d’utilisateurs pour désactiver le contrôle d’accès.
```
aws elasticache modify-serverless-cache --serverless-cache-name --remove-user-group
```
1. (Facultatif) Vérifiez qu’aucun groupe d’utilisateurs n’est associé au cache sans serveur.
```
aws elasticache describe-serverless-caches --serverless-cache-name
{
"..."
"UserGroupId": ""
"..."
}
```
**Pour désactiver un cache Valkey ou Redis OSS configuré avec un jeton AUTH**
1. Remplacez le jeton AUTH par RBAC et spécifiez le groupe d'utilisateurs à ajouter.
```
aws elasticache modify-replication-group --replication-group-id --auth-token-update-strategy DELETE --user-group-ids-to-add
```
1. Vérifiez que le jeton AUTH a été désactivé et qu'un groupe d'utilisateurs a été ajouté.
```
aws elasticache describe-replication-groups --replication-group-id
{
"..."
"AuthTokenEnabled": false,
"UserGroupIds": [
""
]
"..."
}
```
1. Supprimez les groupes d’utilisateurs pour désactiver le contrôle d’accès.
```
aws elasticache modify-replication-group --replication-group-id --user-group-ids-to-remove
{
"..."
"PendingModifiedValues": {
"UserGroups": {
"UserGroupIdsToAdd": [],
"UserGroupIdsToRemove": [
""
]
}
"..."
}
```
1. (Facultatif) Vérifiez qu'aucun groupe d'utilisateurs n'est associé au cluster. Le champ `AuthTokenEnabled` doit également indiquer « false ».
```
aws elasticache describe-replication-groups --replication-group-id
"AuthTokenEnabled": false
```
**Pour désactiver un cluster Valkey ou Redis OSS configuré avec RBAC**
1. Supprimez les groupes d’utilisateurs pour désactiver le contrôle d’accès.
```
aws elasticache modify-replication-group --replication-group-id --user-group-ids-to-remove
{
"..."
"PendingModifiedValues": {
"UserGroups": {
"UserGroupIdsToAdd": [],
"UserGroupIdsToRemove": [
""
]
}
"..."
}
```
1. (Facultatif) Vérifiez qu'aucun groupe d'utilisateurs n'est associé au cluster. Le champ `AuthTokenEnabled` doit également indiquer « false ».
```
aws elasticache describe-replication-groups --replication-group-id
"AuthTokenEnabled": false
```