Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Seguridad de datos en Amazon ElastiCache
Para ayudar a proteger los datos, Amazon ElastiCache y Amazon EC2 disponen de medidas que impiden el acceso no autorizado a los datos del servidor.
Amazon ElastiCache para Memcached también cuenta con características de cifrado para los datos incluidos en cachés que ejecuten las versiones 1.6.12 o posteriores de Memcached.
Amazon ElastiCache con Valkey y Redis OSS cuenta con características de cifrado para los datos en cachés que ejecuten Valkey 7.2 o versiones posteriores, y Redis OSS 3.2.6 (programada para EOL, consulte [Programa de fin de vida útil de las versiones de Redis OSS](engine-versions.md#deprecated-engine-versions)), 4.0.10 o versiones posteriores. Amazon ElastiCache también es compatible con la autenticación de usuarios mediante IAM o AUTH de Valkey y Redis OSS, así como con la autenticación de operaciones de usuarios mediante el control de acceso basado en roles (RBAC).
+ El cifrado en tránsito cifra los datos mientras se mueven de un lugar a otro; por ejemplo, entre los nodos del clúster o entre la caché y la aplicación.
+ El cifrado en reposo cifra los datos en el disco durante las operaciones de sincronización y copia de seguridad.
ElastiCache permite la autenticación de usuarios mediante IAM y el comando AUTH de Valkey y Redis OSS, así como la autorización de operaciones de usuarios mediante el control de acceso basado en roles (RBAC).
![\[Imagen: diagrama de seguridad de ElastiCache para Valkey y Redis OSS\]](http://docs.aws.amazon.com/es_es/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-Secure-Compliant.png)
*Diagrama de seguridad de ElastiCache para Valkey y Redis OSS*
**Topics**
+ [ElastiCache cifrado en tránsito (TLS)](in-transit-encryption.md)
+ [Cifrado en reposo en ElastiCache](at-rest-encryption.md)
+ [Autenticación y autorización](auth-redis.md)
# ElastiCache cifrado en tránsito (TLS)
Para ayudar a mantener sus datos seguros, Amazon ElastiCache y Amazon EC2 proporcionan mecanismos para protegerlos del acceso no autorizado a sus datos en el servidor. Al proporcionar la capacidad de cifrado en tránsito, ElastiCache le brinda una herramienta que puede usar para ayudar a proteger sus datos cuando se mueven de un lugar a otro.
Todas las cachés de Valkey o Redis OSS sin servidor tienen habilitado el cifrado en tránsito. En los clústeres basados en nodos, puede habilitar el cifrado en tránsito en un grupo de replicación estableciendo el parámetro `TransitEncryptionEnabled` en `true` (CLI: `--transit-encryption-enabled`) cuando cree el grupo de replicación. Puede hacerlo tanto si crea el grupo de replicación mediante la Consola de administración de AWSAWS CLI, la o la ElastiCache API.
Todas las cachés sin servidor tienen activado el cifrado en tránsito. Para los clústeres basados en nodos, puede habilitar el cifrado en tránsito en un clúster configurando el parámetro `TransitEncryptionEnabled` en `true` (CLI: `--transit-encryption-enabled`) al crear el clúster mediante la operación `CreateCacheCluster` (CLI: `create-cache-cluster`).
**Topics**
+ [Información general sobre el cifrado en tránsito](#in-transit-encryption-overview)
+ [Condiciones del cifrado en tránsito (Valkey y Redis OSS)](#in-transit-encryption-constraints)
+ [Condiciones del cifrado en tránsito (Memcached)](#in-transit-encryption-constraints)
+ [Prácticas recomendadas de cifrado en tránsito](#in-transit-encryption-best-practices)
+ [Más opciones de Valkey y Redis OSS](#in-transit-encryption-see-also)
+ [Habilitación del cifrado en tránsito para Memcached](#in-transit-encryption-enable-existing-mc)
+ [Habilitación del cifrado en tránsito](in-transit-encryption-enable.md)
+ [Conexión a ElastiCache (Valkey) o Amazon ElastiCache para Redis OSS con cifrado en tránsito mediante valkey-cli](connect-tls.md)
+ [Activación del cifrado en tránsito en un clúster de Redis OSS basado en nodos con Python](in-transit-encryption-enable-python.md)
+ [Procedimientos recomendados para habilitar el cifrado en tránsito](enable-python-best-practices.md)
+ [Conexión a nodos habilitados con el cifrado en tránsito mediante Openssl (Memcached)](#in-transit-encryption-connect-mc)
+ [Creación de un cliente TLS Memcached mediante Java](#in-transit-encryption-connect-java)
+ [Creación de un cliente TLS Memcached mediante PHP](#in-transit-encryption-connect-php-mc)
## Información general sobre el cifrado en tránsito
El cifrado ElastiCache en tránsito de Amazon es una función que te permite aumentar la seguridad de tus datos en los puntos más vulnerables, cuando están en tránsito de un lugar a otro. Como se requiere cierto procesamiento para cifrar y descifrar los datos en los puntos de enlace, habilitar el cifrado en tránsito puede afectar al rendimiento. Debe comparar los datos con y sin cifrado en tránsito para determinar el impacto en el rendimiento de los casos de uso.
ElastiCache el cifrado en tránsito implementa las siguientes funciones:
+ **Conexiones de cliente cifradas**: las conexiones de cliente a los nodos de caché están cifradas con TLS.
+ **Conexiones de servidor cifradas**: los datos que se mueven entre los nodos de un clúster están cifrados.
+ **Autenticación de servidores**: los clientes pueden autenticar que se encuentran conectados al servidor correcto.
+ **Autenticación de clientes**: con la característica AUTH de Valkey o Redis OSS, el servidor puede autenticar a los clientes.
## Condiciones del cifrado en tránsito (Valkey y Redis OSS)
Al planificar la implementación de un clúster basado en nodos, debes tener en cuenta las siguientes restricciones del cifrado en ElastiCache tránsito de Amazon:
+ El cifrado en tránsito es compatible con grupos de replicación que ejecuten Valkey 7.2 y versiones posteriores, y Redis OSS versiones 3.2.6, 4.0.10 y posteriores.
+ Para un clúster existente, la modificación de la configuración del cifrado en tránsito es compatible con los grupos de replicación que ejecutan Valkey 7.2 y versiones posteriores, y Redis OSS versión 7 y posteriores.
+ El cifrado en tránsito solo es compatible con los grupos de reproducción que se ejecutan en una Amazon VPC.
+ El cifrado en tránsito no es compatible con los grupos de replicación que ejecutan los siguientes tipos de nodos: M1, M2.
Para obtener más información, consulte [Tipos de nodos compatibles](CacheNodes.SupportedTypes.md).
+ El cifrado en tránsito se habilita estableciendo explícitamente el parámetro `TransitEncryptionEnabled` en `true`.
+ El cliente de almacenamiento en caché debe ser compatible con la conectividad TLS y esta debe estar habilitada en la configuración del cliente.
+ A partir del 26 de enero de 2026,AWS actualizaremos la versión mínima de TLS admitida a 1.2 ElastiCache para Valkey, versión 7.2 y superior, y ElastiCache para Redis OSS, versión 6 y superior. Los clientes deben actualizar su software cliente antes de esa fecha. Esta actualización ayuda a cumplir los requisitos normativos, de seguridad y de conformidad.
## Condiciones del cifrado en tránsito (Memcached)
Al planificar la implementación de un clúster basado en nodos, debes tener en cuenta las siguientes restricciones del cifrado en ElastiCache tránsito de Amazon:
+ El cifrado en tránsito es compatible con los clústeres que ejecutan la versión 1.6.12 y posteriores de Memcached.
+ El cifrado en tránsito admite las versiones 1.2 y 1.3 de seguridad de la capa de transporte (TLS).
+ El cifrado en tránsito solo es compatible con los clústeres que se ejecutan en una Amazon VPC.
+ El cifrado en tránsito no es compatible con los grupos de replicación que ejecutan los siguientes tipos de nodos: M1, M2, M3, R3, T2.
Para obtener más información, consulte [Tipos de nodos compatibles](CacheNodes.SupportedTypes.md).
+ El cifrado en tránsito se habilita estableciendo explícitamente el parámetro `TransitEncryptionEnabled` en `true`.
+ Solamente puede habilitar el cifrado en tránsito de un clúster en el momento de su creación. El cifrado en tránsito no se puede habilitar y desactivar modificando un clúster.
+ El cliente de almacenamiento en caché debe ser compatible con la conectividad TLS y esta debe estar habilitada en la configuración del cliente.
## Prácticas recomendadas de cifrado en tránsito
+ Debido al procesamiento requerido para cifrar y descifrar los datos en los puntos de enlace, la implementación del cifrado en tránsito puede reducir el rendimiento. Compare sus datos con y sin cifrado en tránsito para determinar el impacto en el rendimiento de la implementación.
+ Puede reducir el impacto en el rendimiento del cifrado en tránsito al mantener las conexiones TSL existentes, ya que la creación de conexiones nuevas puede consumir muchos recursos.
## Más opciones de Valkey y Redis OSS
Para obtener más información sobre las opciones disponibles para Valkey y Redis OSS, consulte los siguientes enlaces.
+ [Cifrado en reposo en ElastiCache](at-rest-encryption.md)
+ [Autenticación con el comando AUTH de Valkey o Redis OSS](auth.md)
+ [Control de acceso basado en roles (RBAC)](Clusters.RBAC.md)
+ [Amazon VPCs y la ElastiCache seguridad](VPCs.md)
+ [Identity and Access Management para Amazon ElastiCache](IAM.md)
## Habilitación del cifrado en tránsito para Memcached
Para habilitar el cifrado en tránsito al crear un clúster de Memcached a través de la Consola de administración de AWS, seleccione las siguientes opciones:
+ Elija Memcached como motor.
+ Elija la versión del motor 1.6.12 o posterior.
+ En **Encryption in transit** (Cifrado en tránsito), elija **Enable** (Habilitar).
Para conocer el step-by-step proceso, consulte. [Creación de un clúster para Valkey o Redis OSS](Clusters.Create.md)
# Habilitación del cifrado en tránsito
Todas las cachés sin servidor tienen activado el cifrado en tránsito. En un clúster basado en nodos, puede habilitar el cifrado en tránsito mediante Consola de administración de AWS la AWS CLI o la API. ElastiCache
## Habilitar el cifrado en tránsito mediante la Consola de administración de AWS
### Habilitar el cifrado en tránsito para un nuevo clúster basado en nodos mediante el Consola de administración de AWS
Al diseñar su propia caché, las configuraciones de “desarrollo/prueba” y “producción” con el método “Creación sencilla” tienen el cifrado en tránsito habilitado. Al elegir la configuración, seleccione estas opciones:
+ Elija la versión del motor 3.2.6, 4.0.10 o posterior.
+ Haga clic en la casilla de verificación situada junto a **Habilitar** en la opción **Cifrado en tránsito**.
Para ver el step-by-step proceso, consulte lo siguiente:
+ [Creación de un clúster de Valkey (modo de clúster deshabilitado) (consola)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ [Creación de un clúster de Valkey o Redis OSS (modo de clúster habilitado) (consola)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
### Habilitar el cifrado en tránsito para un clúster basado en nodos existente mediante el Consola de administración de AWS
Habilitar el cifrado en tránsito es un proceso de dos pasos, primero debe configurar el modo de cifrado de tránsito en `preferred`. Este modo permite que los clientes de Valkey o Redis OSS se conecten mediante conexiones cifradas y no cifradas. Tras migrar todos los clientes de Valkey o Redis OSS para utilizar conexiones cifradas, puede modificar la configuración del clúster para establecer el modo de cifrado de tránsito en `required`. Al configurar el modo de cifrado de tránsito en `required` se eliminarán todas las conexiones no cifradas y solo se permitirán las conexiones cifradas.
**Establecimiento de **Modo de cifrado en tránsito** en **Preferido****
1. Inicia sesión en la ElastiCache consola de Amazon Consola de administración de AWS y ábrela en [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Seleccione las **cachés de Valkey o las cachés** **OSS de Redis** en los ElastiCache **recursos** que aparecen en el panel de navegación, en la parte izquierda.
1. Elija la caché que desea actualizar.
1. Elija **Actions** (Acciones) y después **Modify (Modificar)**.
1. Elija **Enable** (Habilitar) en **Encryption in transit** (Cifrado en tránsito), en la sección **Security** (Seguridad).
1. Elija **Preferred** (Preferido) como **Transit encryption mode** (Modo de cifrado de tránsito).
1. Elija **Preview changes** (Vista previa de cambios) y guarde los cambios.
Después de migrar todos los clientes de Valkey o Redis OSS para usar conexiones cifradas:
**Establecimiento de **Modo de cifrado en tránsito** en **Obligatorio****
1. Inicia sesión en la ElastiCache consola de Amazon Consola de administración de AWS y ábrela en [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Seleccione las **cachés de Valkey o las cachés** **OSS de Redis** en los ElastiCache **recursos** que aparecen en el panel de navegación, en la parte izquierda.
1. Elija la caché que desea actualizar.
1. Elija **Actions** (Acciones) y después **Modify (Modificar)**.
1. Elija **Required** (Obligatorio) como **Transit encryption mode** (Modo de cifrado de tránsito), en la sección **Security** (Seguridad).
1. Elija **Preview changes** (Vista previa de cambios) y guarde los cambios.
## Habilitar el cifrado en tránsito mediante el AWS CLI
Para habilitar el cifrado en tránsito al crear un grupo de replicación de Valkey o Redis OSS a través de AWS CLI, utilice el parámetro `transit-encryption-enabled`.
### Habilitación del cifrado en tránsito en un nuevo clúster basado en nodos para Valkey o Redis OSS (modo de clúster deshabilitado) (CLI)
Utilice la AWS CLI operación `create-replication-group` y los siguientes parámetros para crear un grupo de replicación de OSS de Valkey o Redis con réplicas que tengan activado el cifrado en tránsito:
**Parámetros clave:**
+ **--engine**: debe ser `valkey` o `redis`.
+ **--engine-version**: si el motor es Redis OSS, debe ser la versión 3.2.6, 4.0.10 o posterior.
+ **--transit-encryption-enabled**: obligatorio. Si habilita el cifrado en tránsito, también deberá proporcionar un valor para el parámetro `--cache-subnet-group`.
+ **--num-cache-clusters**: debe ser, como mínimo, 1. El valor máximo para este parámetro es seis.
Para obtener más información, consulte los siguientes temas:
+ [Creación de un grupo de replicación de Valkey o Redis OSS (modo de clúster deshabilitado) desde cero (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)
### Habilitación del cifrado en tránsito en un nuevo clúster basado en nodos para Valkey o Redis OSS (modo de clúster habilitado) (CLI)
Utilice la AWS CLI operación `create-replication-group` y los siguientes parámetros para crear un grupo de replicación de Valkey o Redis OSS (habilitado en modo de clúster) que tenga activado el cifrado en tránsito:
**Parámetros clave:**
+ **--engine**: debe ser `valkey` o `redis`.
+ **--engine-version**: si el motor es Redis OSS, debe ser la versión 3.2.6, 4.0.10 o posterior.
+ **--transit-encryption-enabled**: obligatorio. Si habilita el cifrado en tránsito, también deberá proporcionar un valor para el parámetro `--cache-subnet-group`.
+ Utilice uno de los siguientes conjuntos de parámetros para especificar la configuración de los grupos de nodos del grupo de reproducción:
+ **--num-node-groups**: especifica el número de particiones (grupos de nodos) de este grupo de reproducción. El valor máximo de este parámetro es 500.
**--replicas-per-node-group**: especifica el número de nodos de réplica de cada grupo de nodos. El valor especificado aquí se aplica a todos los fragmentos de este grupo de reproducción. El valor máximo de este parámetro es 5.
+ **--node-group-configuration**: especifica por separado la configuración de cada partición.
Para obtener más información, consulte los siguientes temas:
+ [Creación de un grupo de replicación de Valkey o Redis OSS (modo de clúster habilitado) desde cero (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)
### Habilitación del cifrado en tránsito para un clúster existente con la AWS CLI
Habilitar el cifrado en tránsito es un proceso de dos pasos, primero debe configurar el modo de cifrado de tránsito en `preferred`. Este modo permite que los clientes de Valkey o Redis OSS se conecten mediante conexiones cifradas y no cifradas. Tras migrar todos los clientes de Valkey o Redis OSS para utilizar conexiones cifradas, puede modificar la configuración del clúster para establecer el modo de cifrado de tránsito en `required`. Al configurar el modo de cifrado de tránsito en `required` se eliminarán todas las conexiones no cifradas y solo se permitirán las conexiones cifradas.
Utilice la AWS CLI operación `modify-replication-group` y los siguientes parámetros para actualizar un grupo de replicación de Valkey o Redis OSS (habilitado en modo de clúster) que tenga desactivado el cifrado en tránsito.
**Para habilitar el cifrado en tránsito**
1. transit-encryption-modeConfigúrelo en`preferred`, mediante los siguientes parámetros
+ **--transit-encryption-enabled**: obligatorio.
+ **--transit-encryption-mode**: debe establecerse en `preferred`.
1. transit-encryption-mode`required`Configúrelo en, mediante los siguientes parámetros:
+ **--transit-encryption-enabled**: obligatorio.
+ **--transit-encryption-mode**: debe establecerse en `required`.
# Conexión a ElastiCache (Valkey) o Amazon ElastiCache para Redis OSS con cifrado en tránsito mediante valkey-cli
Para obtener acceso a los datos desde cachés de ElastiCache para Redis OSS habilitadas con el cifrado en tránsito, se utilizan clientes que usan la capa de conexión segura (SSL). También puede utilizar valkey-cli con TLS/SSL en Amazon Linux y Amazon Linux 2. Si su cliente no admite TLS, puede usar el comando `stunnel` en el host de su cliente para crear un túnel de SSL hacia los nodos de Redis OSS.
## Conexión cifrada con Linux
Para utilizar valkey-cli para conectarse a un clúster de Valkey o Redis OSS que tiene habilitado el cifrado en tránsito en Amazon Linux 2 o Amazon Linux, siga estos pasos.
1. Descargue y compile la utilidad valkey-cli. Esta utilidad se incluye en la distribución de software de Valkey.
1. En el símbolo del sistema de la instancia de EC2, escriba los comandos correspondientes a la versión de Linux que utilice.
**Amazon Linux 2**
Si utiliza Amazon Linux 2, introduzca lo siguiente:
```
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 utiliza Amazon Linux, introduzca lo siguiente:
```
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/
```
En Amazon Linux, es posible que también deba ejecutar los siguientes pasos adicionales:
```
sudo yum install clang
CC=clang make
sudo make install
```
1. Cuando haya descargado e instalado la utilidad valkey-cli, recomendamos ejecutar el comando opcional `make-test`.
1. Para conectarse a un clúster con el cifrado y la autenticación habilitados, escriba este comando:
```
valkey-cli -h Primary or Configuration Endpoint --tls -a 'your-password' -p 6379
```
**nota**
Si instala redis6 en Amazon Linux 2023, ahora puede usar el comando `redis6-cli` en lugar de `valkey-cli`:
```
redis6-cli -h Primary or Configuration Endpoint --tls -p 6379
```
## Conexión cifrada con stunnel
Para utilizar valkey-cli para conectarse a un clúster de Redis OSS habilitado con cifrado en tránsito utilizando stunnel, siga estos pasos.
1. Utilice SSH para conectarse al cliente e instalar `stunnel`.
```
sudo yum install stunnel
```
1. Ejecute el siguiente comando para crear y editar el archivo `'/etc/stunnel/valkey-cli.conf'` de forma simultánea para añadir un punto de conexión del clúster de ElastiCache para Redis OSS a uno o varios parámetros de conexión, mediante la salida que se proporciona a continuación como plantilla.
```
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
```
En este ejemplo, el archivo de configuración tiene dos conexiones, `valkey-cli` y `valkey-cli-replica`. Los parámetros se establecen como sigue:
+ **client** se establece en sí para especificar que esta instancia de stunnel es un cliente.
+ **accept** se establece en la IP del cliente. En este ejemplo, el principal se establece en el valor predeterminado de Redis OSS 127.0.0.1 en el puerto 6379. La réplica debe llamar a otro puerto y establecerlo en 6380. Puede utilizar los puertos efímeros 1024-65535. Para obtener más información, consulte [Puertos efímeros](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports) en la *Guía del usuario de Amazon VPC.*
+ **connect** se establece en el punto de conexión de servidor de Redis OSS. Para obtener más información, consulte [Búsqueda de puntos de conexión en ElastiCache](Endpoints.md).
1. Se inicia `stunnel`.
```
sudo stunnel /etc/stunnel/valkey-cli.conf
```
Use el comando `netstat` para confirmar que los túneles se han iniciado.
```
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. Conéctese al nodo de Redis OSS cifrado mediante el punto de conexión local del túnel.
+ Si no se ha utilizado ninguna contraseña de AUTH al crear el clúster de ElastiCache para Redis OSS, en este ejemplo se utiliza valkey-cli para conectarse al servidor de ElastiCache para Redis OSS utilizando la ruta completa para valkey-cli en Amazon Linux:
```
/home/ec2-user/redis-7.2.5/src/valkey-cli -h localhost -p 6379
```
Si se utilizó la contraseña de AUTH durante la creación del clúster de Redis OSS, en este ejemplo se utiliza valkey-cli para conectarse al servidor de Redis OSS utilizando la ruta completa para valkey-cli, en Amazon Linux:
```
/home/ec2-user/redis-7.2.5/src/valkey-cli -h localhost -p 6379 -a my-secret-password
```
O BIEN
+ Cambie el directorio a redis-7.2.5 y proceda del modo siguiente:
Si no se ha utilizado ninguna contraseña de AUTH al crear el clúster de ElastiCache para Redis OSS, en este ejemplo se utiliza valkey-cli para conectarse al servidor de ElastiCache para Redis OSS utilizando la ruta completa para valkey-cli en Amazon Linux:
```
src/valkey-cli -h localhost -p 6379
```
Si se utilizó la contraseña de AUTH durante la creación del clúster de Redis OSS, en este ejemplo se utiliza valkey-cli para conectarse al servidor de Valkey o Redis OSS utilizando la ruta completa para valkey-cli, en Amazon Linux:
```
src/valkey-cli -h localhost -p 6379 -a my-secret-password
```
En este ejemplo, se utiliza Telnet para conectarse al servidor de Valkey o Redis OSS.
```
telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
auth MySecretPassword
+OK
get foo
$3
bar
```
1. Para detener y cerrar los túneles SSL, ejecute `pkill` en el proceso de stunnel.
```
sudo pkill stunnel
```
# Activación del cifrado en tránsito en un clúster de Redis OSS basado en nodos con Python
La siguiente guía mostrará cómo habilitar el cifrado en tránsito en un clúster de Redis OSS 7.0 que se haya creado originalmente con el cifrado en tránsito deshabilitado. Los clientes de TCP y TLS seguirán comunicándose con el clúster durante este proceso sin tiempo de inactividad.
Boto3 obtendrá las credenciales que necesita (`aws_access_key_id`, `aws_secret_access_key` y `aws_session_token`) de las variables de entorno. Esas credenciales se pegarán previamente en el mismo terminal bash donde ejecutaremos `python3` para procesar el código Python que se muestra en esta guía. El código del ejemplo siguiente se procesó a partir de una EC2 instancia que se lanzó en la misma VPC que se utilizará para crear el clúster ElastiCache OSS de Redis en ella.
**nota**
En los siguientes ejemplos, se utiliza el SDK boto3 para las operaciones de ElastiCache administración (creación de clústeres o usuarios) y redis-py-cluster redis-py/ para la gestión de datos.
Debe utilizar al menos la versión 1.26.39 de boto3 (=\$1) para utilizar la migración de TLS en línea con la API de modificación del clúster.
ElastiCache admite la migración de TLS en línea solo para clústeres con Valkey versión 7.2 o superior o Redis OSS versión 7.0 o superior. Por lo tanto, si tiene un clúster que ejecuta una versión de Redis OSS anterior a la 7.0, deberá actualizar la versión de Redis OSS del clúster. Para obtener más información sobre las diferencias de las versiones, consulte [Diferencias de compatibilidad y comportamiento de las versiones principales del motor con Redis OSS](VersionManagementConsiderations.md).
**Topics**
+ [Defina las constantes de cadena que lanzarán el clúster OSS de ElastiCache Valkey o Redis](#enable-python-define-constants)
+ [Definir las clases para la configuración del clúster](#enable-python-define-classes)
+ [Definir una clase que representará el propio clúster](#enable-python-define-classes-cluster)
+ [(Opcional) Creación de una clase contenedora para demostrar la conexión del cliente al clúster de Valkey o Redis OSS](#enable-python-create-wrapper)
+ [Cree la función principal que muestre el proceso de cambio de la configuración de cifrado en tránsito](#enable-python-main-function)
## Defina las constantes de cadena que lanzarán el clúster OSS de ElastiCache Valkey o Redis
Primero, definamos algunas constantes de cadena de Python simples que contendrán los nombres de las AWS entidades necesarias para crear el ElastiCache clúster`security-group`, como`Cache Subnet group`, y a`default parameter group`. Todas estas AWS entidades deben crearse con antelación en su AWS cuenta en la región que desee utilizar.
```
#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"
```
## Definir las clases para la configuración del clúster
Ahora, vamos a definir algunas clases sencillas de Python que representarán una configuración de un clúster, que contendrá metadatos sobre el clúster, como la versión de Valkey o Redis OSS, el tipo de instancia y si el cifrado en tránsito (TLS) está habilitado o deshabilitado.
```
#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
```
## Definir una clase que representará el propio clúster
Ahora, definamos algunas clases sencillas de Python que representarán el propio clúster OSS de ElastiCache Valkey o Redis. Esta clase tendrá un campo de cliente que contendrá un cliente boto3 para las operaciones de ElastiCache administración, como la creación del clúster y la consulta de la 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()
```
## (Opcional) Creación de una clase contenedora para demostrar la conexión del cliente al clúster de Valkey o Redis OSS
Ahora, vamos a crear una clase contenedora para el cliente de `redis-py-cluster`. Esta clase contenedora permitirá rellenar previamente el clúster con algunas claves y luego ejecutar comandos `get` repetidos aleatorios.
**nota**
Este es un paso opcional, pero simplifica el código de la función principal que viene en un paso posterior.
```
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()
```
## Cree la función principal que muestre el proceso de cambio de la configuración de cifrado en tránsito
Ahora, definamos la función principal, que hará lo siguiente:
1. Cree el clúster con el cliente boto3. ElastiCache
1. Inicialice el cliente de `redis-py-cluster` que se conectará al clúster con una conexión TCP clara sin TLS.
1. El cliente de `redis-py-cluster` rellena previamente el clúster con algunos datos.
1. El cliente de boto3 activará la migración de TLS de sin TLS a TLS preferido.
1. Mientras se migra el clúster a TLS `Preferred`, el cliente de TCP de `redis-py-cluster` enviará operaciones `get` repetidas al clúster hasta que finalice la migración.
1. Una vez finalizada la migración a TLS `Preferred`, confirmaremos que el clúster admite el cifrado en tránsito. Después, crearemos un cliente de `redis-py-cluster` que se conectará al clúster con TLS.
1. Enviaremos algunos comandos `get` utilizando el nuevo cliente de TLS y el antiguo cliente TCP.
1. El cliente de boto3 activará la migración de TLS de TLS `Preferred` a TLS requerido.
1. Mientras se migra el clúster a TLS (es necesario), el cliente redis-py-cluster TLS enviará `get` operaciones repetidas al clúster hasta que finalice la migración.
```
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)
```
# Procedimientos recomendados para habilitar el cifrado en tránsito
## Antes de habilitar el cifrado en tránsito: asegúrese de gestionar correctamente los registros de DNS
**nota**
Durante este proceso, cambiaremos y eliminaremos los puntos de conexión antiguos. El uso incorrecto de los puntos de conexión puede provocar que el cliente de Valkey o Redis OSS utilice puntos de conexión antiguos y eliminados, lo que impedirá que se conecte al clúster.
Mientras se migra el clúster de sin TLS a TLS preferido, se conserva el registro de DNS antiguo del punto de conexión de clúster y los nuevos registros de DNS del punto de conexión de configuración del clúster se generan en un formato diferente. Los clústeres activados para TLS utilizan un formato de registros de DNS diferente al de los clústeres no activados para TLS. ElastiCache conservará ambos registros de DNS cuando un clúster esté configurado en `encryption mode: Preferred` de manera que las aplicaciones y otros clientes de Valkey o Redis OSS puedan cambiar de uno a otro. Durante el proceso de migración de TLS se producen los siguientes cambios en los registros de DNS:
### Descripción de los cambios en los registros de DNS que se producen al habilitar el cifrado en tránsito
**Para clústeres de CME**
Cuando un clúster está configurado en “modo de cifrado de tránsito: preferido”:
+ Los puntos de conexión de configuración del clúster original para el clúster no activado para TLS permanecerán activos. No habrá tiempo de inactividad cuando el clúster se vuelva a configurar del modo de cifrado TLS “ninguno” a “preferido”.
+ Se generarán nuevos puntos de conexión de TLS de Valkey o Redis OSS cuando el clúster se establezca en el modo preferido de TLS. Estos nuevos puntos de conexión se resolverán con las mismas IP que los anteriores (no TLS).
+ El nuevo punto de conexión de configuración de TLS de Valkey o Redis OSS se mostrará en la consola de ElastiCache y en la respuesta a la API `describe-replication-group`.
Cuando un clúster está configurado en “modo de cifrado de tránsito: requerido”:
+ Se eliminarán los puntos de conexión antiguos que no estén habilitados para TLS. No habrá tiempo de inactividad en los puntos de conexión del clúster de TLS.
+ Puede recuperar un nuevo `cluster-configuration-endpoint` desde la consola de ElastiCache o desde la API `describe-replication-group`.
**Para clústeres de CMD con la conmutación por error automática habilitada o la conmutación por error automática desactivada**
Cuando el grupo de replicación está establecido en “modo de cifrado de tránsito: preferido”:
+ El punto de conexión principal y el punto de conexión del lector originales del clúster que no admite TLS permanecerán activos.
+ Se generarán nuevos puntos de conexión principales y del lector de TLS cuando el clúster se establezca en el modo `Preferred` de TLS. Estos nuevos puntos de conexión se resolverán con las mismas IP que los anteriores (sin TLS).
+ El punto de conexión principal y el punto de conexión del lector nuevos se mostrarán en la consola de ElastiCache y en la respuesta a la API `describe-replication-group`.
Cuando el grupo de replicación está establecido en “modo de cifrado de tránsito: requerido”:
+ Se eliminarán los puntos de conexión principales y de lector antiguos que no sean de TLS. No habrá tiempo de inactividad en los puntos de conexión del clúster de TLS.
+ Puede recuperar nuevos puntos de conexión principales y del lector desde la consola de ElastiCache o desde la API `describe-replication-group`.
### El uso sugerido de los registros de DNS
**Para clústeres de CME **
+ Utilice el punto de conexión de configuración del clúster en lugar de los registros de DNS por nodo en el código de la aplicación. No se recomienda utilizar nombres de DNS por nodo directamente, ya que es posible que cambien y el código de la aplicación interrumpa la conexión con el clúster.
+ No codifique el punto de conexión de configuración de un clúster en la aplicación, ya que cambiará durante este proceso.
+ No se recomienda tener el punto de conexión de configuración del clúster codificado en la aplicación, ya que se puede cambiar durante este proceso. Una vez completado el cifrado en tránsito, consulte el punto de conexión de configuración del clúster con la API `describe-replication-group` (tal como se ha demostrado anteriormente [en negrita]) y utilice el DNS que obtendrá como respuesta a partir de ese momento.
**Para clústeres de CMD con la conmutación por error automática habilitada **
+ Utilice el punto de conexión principal y el punto de conexión del lector en lugar de los nombres de DNS por nodo del código de la aplicación, ya que los nombres de DNS antiguos por nodo se eliminan y se generan otros nuevos al migrar el clúster de sin TLS a TLS preferido. No se recomienda utilizar nombres de DNS por nodo directamente, ya que es posible que agregue réplicas al clúster en el futuro. Además, cuando la conmutación por error automática está habilitada, el servicio de ElastiCache cambia automáticamente los roles del clúster principal y las réplicas. Se recomienda utilizar el punto de conexión principal y el punto de conexión del lector para ayudarlo a realizar un seguimiento de esos cambios. Por último, utilizar el punto de conexión del lector le ayudará a distribuir las lecturas de las réplicas de manera equitativa entre las réplicas del clúster.
+ Tener el punto de conexión principal y el punto de conexión del lector codificados en la aplicación no es conveniente, ya que se pueden cambiar durante el proceso de migración de TLS. Una vez finalizado el cambio de migración a TLS preferido, consulte el punto de conexión principal y el punto de conexión del lector con la API describe-replication-group y utilice el DNS que obtendrá como respuesta a partir de ahora. De esta forma, podrá realizar un seguimiento de los cambios en los puntos de conexión de forma dinámica.
**Para clústeres de CMD con la conmutación por error automática desactivada **
+ Utilice el punto de conexión principal y el punto de conexión del lector en lugar de los nombres de DNS por nodo del código de la aplicación. Cuando la conmutación por error automática está desactivada, usted se encarga de escalar, aplicar parches, conmutación por error y otros procedimientos que el servicio de ElastiCache administra automáticamente cuando la conmutación por error automática está habilitada. Esto le facilita la realización manual del seguimiento de los distintos puntos de conexión. Dado que los nombres de DNS antiguos por nodo se eliminan y se generan otros nuevos al migrar el clúster de sin TLS a TLS preferido, no utilice los nombres de DNS por nodo directamente. Esto es obligatorio para que los clientes puedan conectarse al clúster durante la migración de TLS. Además, se beneficiará de distribuir las lecturas de manera uniforme entre las réplicas cuando utilice el punto de conexión del lector y de llevar un registro de los registros de DNS al agregar o eliminar réplicas del clúster.
+ Tener el punto de conexión de configuración del clúster codificado en la aplicación no es conveniente, ya que se puede cambiar durante el proceso de migración de TLS.
## Durante el cifrado en tránsito: preste atención a cuándo finaliza el proceso de migración
El cambio del modo de cifrado de tránsito no es inmediato y puede llevar algún tiempo. Esto es especialmente cierto en el caso de los clústeres grandes. Solo cuando el clúster finalice la migración a TLS preferido podrá aceptar y ofrecer conexiones de TCP y TLS. Por lo tanto, no debe crear clientes que intenten establecer conexiones de TLS con el clúster hasta que se complete el cifrado en tránsito.
Hay varias formas de recibir notificaciones cuando el cifrado en tránsito se completa correctamente o no funciona: (No se muestra en el ejemplo de código anterior):
+ Uso del servicio de SNS para recibir una notificación cuando se complete el cifrado
+ Uso de la API `describe-events` que emitirá un evento cuando se complete el cifrado
+ Ver un mensaje en la consola de ElastiCache que indica que se ha completado el cifrado
También puede implementar la lógica en la aplicación para saber si se ha completado el cifrado. En el ejemplo anterior, vimos varias formas de garantizar que el clúster finalice la migración:
+ Esperar a que comience el proceso de migración (el estado del clúster cambia a “modificándose”) y esperar a que finalice la modificación (el estado del clúster vuelve a ser “disponible”)
+ Afirmar que el clúster ha establecido `transit_encryption_enabled` en Verdadero mediante una consulta a la API `describe-replication-group`.
### Después de habilitar el cifrado en tránsito: asegúrese de que los clientes que utiliza estén configurados correctamente
Mientras el clúster esté en el modo TLS preferido, la aplicación debe abrir conexiones de TLS al clúster y utilizar solo esas conexiones. De esta forma, la aplicación no sufrirá tiempo de inactividad al habilitar el cifrado en tránsito. Puede asegurarse de que no haya conexiones de TCP más claras al motor de Valkey o Redis OSS mediante el comando info en la sección de 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
```
## Conexión a nodos habilitados con el cifrado en tránsito mediante Openssl (Memcached)
Para acceder a los datos desde ElastiCache los nodos de Memcached habilitados con el cifrado en tránsito, debe utilizar clientes que funcionen con Secure Socket Layer (SSL). También puede utilizar Openssl s\$1client en Amazon Linux y Amazon Linux 2.
Para utilizar Openssl s\$1client para conectarse a un clúster de Memcached que tiene habilitado el cifrado en tránsito en Amazon Linux 2 o Amazon Linux:
```
/usr/bin/openssl s_client -connect memcached-node-endpoint:memcached-port
```
## Creación de un cliente TLS Memcached mediante Java
Para crear un cliente en modo TLS, haga lo siguiente para inicializarlo con lo apropiado: 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");
}
}
```
## Creación de un cliente TLS Memcached mediante PHP
Para crear un cliente en modo TLS, haga lo siguiente para inicializarlo con lo que corresponda: 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);
}
```
Para obtener más información sobre el uso del cliente PHP, consulte [Instalación de ElastiCache Cluster Client para .PHP](Appendix.PHPAutoDiscoverySetup.md).
# Cifrado en reposo en ElastiCache
Para ayudar a proteger sus datos, Amazon ElastiCache y Amazon S3 ofrecen diferentes formas de restringir el acceso a los datos de la memoria caché. Para obtener más información, consulte [Amazon VPCs y la ElastiCache seguridad](VPCs.md) y [Identity and Access Management para Amazon ElastiCache](IAM.md).
ElastiCache El cifrado en reposo es una función que permite aumentar la seguridad de los datos mediante el cifrado de los datos del disco. Siempre está habilitada en una caché sin servidor. Si está habilitada, cifra los siguientes elementos:
+ Disco durante las operaciones de sincronización, copia de seguridad o intercambio
+ Copias de seguridad almacenadas en Amazon S3
Los datos almacenados SSDs (unidades de estado sólido) en clústeres habilitados para la estratificación de datos siempre están cifrados.
ElastiCache ofrece un cifrado predeterminado (gestionado por el servicio) en reposo, así como la posibilidad de utilizar sus propias claves KMS simétricas gestionadas por el cliente en AWS el [Servicio de gestión](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) de claves (AWS KMS). Cuando se haga una copia de seguridad de la caché, elija, en las opciones de cifrado, si desea usar la clave de cifrado predeterminada o una clave administrada por el cliente. Para obtener más información, consulte [Activación del cifrado en reposo](#at-rest-encryption-enable).
**importante**
Habilitar el cifrado en reposo en un clúster de Valkey o Redis OSS basado en nodos existente implica eliminar el grupo de replicación existente, **después** de ejecutar la copia de seguridad y restaurarla en el grupo de replicación.
El cifrado en reposo solo se puede habilitar en una caché en el momento de su creación. Como se requiere cierto procesamiento para cifrar y descifrar los datos, habilitar el cifrado en reposo durante estas operaciones puede afectar al rendimiento. Debe comparar los datos con y sin cifrado en reposo para determinar el impacto en el rendimiento de los casos de uso.
**Topics**
+ [Condiciones del cifrado en reposo](#at-rest-encryption-constraints)
+ [Uso de claves administradas por el cliente desde KMS AWS](#using-customer-managed-keys-for-elasticache-security)
+ [Activación del cifrado en reposo](#at-rest-encryption-enable)
+ [Véase también](#at-rest-encryption-see-also)
## Condiciones del cifrado en reposo
Al planificar la implementación del cifrado en ElastiCache reposo, se deben tener en cuenta las siguientes restricciones en relación con el ElastiCache cifrado en reposo:
+ El cifrado en reposo es compatible con los grupos de replicación que ejecutan Valkey 7.2 y versiones posteriores y Redis OSS 4.0.10 o posteriores (para la versión 3.2.6 programada para EOL, consulte [Programa de fin de vida útil de las versiones de Redis OSS](engine-versions.md#deprecated-engine-versions)).
+ El cifrado en reposo solo es compatible con los grupos de reproducción que se ejecutan en una Amazon VPC.
+ El cifrado en reposo solo se admite en los grupos de reproducción que ejecutan los siguientes tipos de nodos.
+ R7g, R6gd, R6g, R5, R4 y R3
+ M7g, M6g, M5, M4 y M3
+ T4g, T3, T2
+ C7gn
Para obtener más información, consulte [Tipos de nodos compatibles](CacheNodes.SupportedTypes.md)
+ El cifrado en reposo se habilita estableciendo explícitamente el parámetro `AtRestEncryptionEnabled` en `true`.
+ El cifrado en reposo solamente se puede habilitar en un grupo de reproducción en el momento de su creación. Por tanto, el cifrado en reposo no se puede habilitar y desactivar modificando un grupo de reproducción. Para obtener información acerca de la implementación del cifrado en reposo en un grupo de reproducción existente, consulte [Activación del cifrado en reposo](#at-rest-encryption-enable).
+ Si un clúster utiliza un tipo de nodo de la familia r6gd, los datos almacenados en SSD se cifran independientemente de si el cifrado en reposo está habilitado o no.
+ La opción de utilizar una clave gestionada por el cliente para el cifrado en reposo no está disponible en las AWS GovCloud regiones (us-gov-east-1 y us-gov-west -1).
+ Si un clúster utiliza un tipo de nodo de la familia r6gd, los datos almacenados en la SSD se cifran con la clave AWS KMS administrada por el cliente elegida (o con el cifrado administrado por el servicio en Regions).AWS GovCloud
+ Con Memcached, el cifrado en reposo solo se admite en las cachés sin servidor.
+ Cuando se usa Memcached, la opción de usar una clave administrada por el cliente para el cifrado en reposo no está disponible en AWS GovCloud las regiones (-1 y -1). us-gov-east us-gov-west
Implementar el cifrado en reposo puede reducir el rendimiento durante las operaciones de backup y sincronización de nodos. Compare sus datos con y sin cifrado en reposo para determinar el impacto en el rendimiento de la implementación.
## Uso de claves administradas por el cliente desde KMS AWS
ElastiCache admite claves AWS KMS simétricas administradas por el cliente (clave KMS) para el cifrado en reposo. Las claves KMS administradas por el cliente son claves de cifrado que usted crea, posee y administra en su cuenta.AWS Para obtener más información, consulte [Claves de AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) en la *Guía para desarrolladores de AWS Key Management Service*. Las claves se deben crear en AWS KMS para poder usarlas con ellas. ElastiCache
Para obtener información sobre cómo crear claves raíz de AWS KMS, consulte [Creación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía AWS para desarrolladores del Servicio de administración* de claves.
ElastiCache le permite integrarse con AWS KMS. Para obtener más información, consulte [Uso de concesiones](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) en la *Guía para desarrolladores de AWS Key Management Service*. No es necesaria ninguna acción por parte del cliente para habilitar ElastiCache la integración de Amazon con AWS KMS.
La `kms:ViaService` clave condicional limita el uso de una clave AWS KMS (clave KMS) a las solicitudes de AWS servicios específicos. Para usarla `kms:ViaService` con ElastiCache, incluye ambos ViaService nombres en el valor de la clave de condición: `elasticache.AWS_region.amazonaws.com` y`dax.AWS_region.amazonaws.com`. Para obtener más información, consulte [kms: ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service).
Puedes utilizarla [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)para hacer un seguimiento de las solicitudes que Amazon ElastiCache envía AWS Key Management Service en tu nombre. Todas las llamadas a la API AWS Key Management Service relacionadas con las claves gestionadas por el cliente tienen CloudTrail los registros correspondientes. También puede ver las concesiones que se ElastiCache crean al llamar a la API de [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html)KMS.
Una vez que se cifra un grupo de reproducción mediante la clave administrada por el cliente, todas las copias de seguridad para el grupo de reproducción se cifran de la siguiente manera:
+ Las copias de seguridad diarias automáticas se cifran mediante la clave administrada por el cliente asociada con el clúster.
+ La copia de seguridad final creada cuando se elimina el grupo de reproducción también se cifra mediante la clave administrada por el cliente asociada con el grupo de reproducción.
+ Las copias de seguridad creadas de forma manual se cifran de manera predeterminada para utilizar la clave de KMS asociada con el grupo de reproducción. Puede anular esto al elegir otra clave administrada por el cliente.
+ Al copiar una copia de seguridad se utiliza de forma predeterminada una clave administrada por el cliente asociada a la copia de seguridad de origen. Puede anular esto al elegir otra clave administrada por el cliente.
**nota**
Las claves administradas por el cliente no se pueden utilizar cuando se exportan copias de seguridad al bucket de Amazon S3 seleccionado. Sin embargo, todas las copias de seguridad exportadas a Amazon S3 se cifran mediante el [cifrado del lado del servidor.](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html) Puede optar por copiar el archivo de copia de seguridad en un objeto de S3 nuevo y cifrarlo mediante una clave de KMS administrada por el cliente, copiar el archivo a otro bucket de S3 que se ha configurado con el cifrado predeterminado mediante una clave de KMS o cambiar una opción de cifrado en el propio archivo.
También puede utilizar claves administradas por el cliente a fin de cifrar copias de seguridad creadas de forma manual para grupos de reproducción que no utilicen claves administradas por el cliente para el cifrado. Con esta opción, el archivo de copia de seguridad almacenado en Amazon S3 se cifra mediante una clave de KMS, aunque los datos no se cifren en el grupo de reproducción original.
La restauración desde una copia de seguridad le permite elegir entre las opciones de cifrado disponibles, similares a las opciones de cifrado disponibles cuando se crea un nuevo grupo de reproducción.
+ Si elimina la clave o [deshabilita](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) la clave y [revoca las concesiones](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) para la clave que utilizó para cifrar una caché, esta se vuelve irrecuperable. En otras palabras, no se puede modificar ni recuperar después de un fallo de hardware.AWS KMS elimina las claves raíz solo después de un período de espera de al menos siete días. Después de eliminar la clave, puede utilizar una clave administrada por el cliente diferente para crear una copia de seguridad con fines de archivo.
+ La rotación automática de claves preserva las propiedades de las claves raíz de AWS KMS, por lo que la rotación no afecta a su capacidad de acceder a sus ElastiCache datos. ElastiCache Las cachés cifradas de Amazon no admiten la rotación manual de claves, lo que implica crear una nueva clave raíz y actualizar cualquier referencia a la clave anterior. Para obtener más información, consulte [Rotación de claves AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) en la *Guía AWS para desarrolladores del servicio de administración de* claves.
+ El cifrado de una ElastiCache caché mediante una clave KMS requiere una concesión por caché. Esa concesión se utiliza durante toda la vida útil de la caché. Además, se utiliza una concesión por copia de seguridad durante la creación de la copia de seguridad. Dicha concesión se retira una vez que se crea la copia de seguridad.
+ Para obtener más información sobre las concesiones y los límites de AWS KMS, consulte [los límites](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) en la *Guía para desarrolladores del servicio de administración de AWS claves*.
## Activación del cifrado en reposo
Todas las cachés sin servidor tienen activado el cifrado en reposo.
Al crear un clúster basado en nodos, puede habilitar el cifrado en reposo configurando el parámetro `AtRestEncryptionEnabled` en `true`. No puede habilitar el cifrado en reposo en grupos de reproducción existentes.
Puede habilitar el cifrado en reposo al crear una ElastiCache memoria caché. Puede hacerlo mediante la Consola de administración de AWSAWS CLI, la o la ElastiCache API.
Cuando cree una caché, puede elegir una de las siguientes opciones:
+ **Default** (Predeterminado): esta opción utiliza el cifrado administrado por el servicio en reposo.
+ **Clave gestionada por el cliente**: esta opción le permite proporcionar la clave ID/ARN de AWS KMS para el cifrado en reposo.
Para obtener información sobre cómo crear claves raíz de AWS KMS, consulte [Crear claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía para desarrolladores del Servicio de administración de AWS claves*
**Contents**
+ [Habilitar el cifrado en reposo mediante el Consola de administración de AWS](#at-rest-encryption-enable-con)
+ [Habilitación del cifrado en reposo mediante el AWS CLI](#at-rest-encryption-enable-cli)
### Habilitación del cifrado en reposo en un clúster de Valkey o Redis OSS basado en nodos existente
El cifrado en reposo solamente se puede habilitar al crear un grupo de replicación de Valkey o Redis OSS. Si tiene un grupo de reproducción existente en el que desea habilitar el cifrado en reposo, haga lo siguiente.
**Para habilitar el cifrado en reposo en un grupo de reproducción existente**
1. Cree un backup manual del grupo de reproducción existente. Para obtener más información, consulte [Copias de seguridad manuales](backups-manual.md).
1. Cree un nuevo grupo de reproducción a partir de este backup. En el nuevo grupo de reproducción, habilite el cifrado en reposo. Para obtener más información, consulte [Restauración desde una copia de seguridad a una nueva caché](backups-restoring.md).
1. Actualice los puntos de enlace de la aplicación para que apunten al nuevo grupo de reproducción.
1. Elimine el grupo de reproducción antiguo. Para obtener más información, consulte [Eliminar un clúster en ElastiCache](Clusters.Delete.md) o [Eliminación de un grupo de reproducción](Replication.DeletingRepGroup.md).
### Habilitar el cifrado en reposo mediante el Consola de administración de AWS
#### Habilitación del cifrado en reposo en una caché sin servidor (consola)
Todas las cachés sin servidor tienen activado el cifrado en reposo. De forma predeterminada, se utiliza una AWS clave KMS propia para cifrar los datos. Para elegir su propia AWS KMS clave, realice las siguientes selecciones:
+ Amplíe la sección **Configuración predeterminada**.
+ Seleccione **Personalizar la configuración predeterminada** en la sección **Configuración predeterminada**.
+ Seleccione **Personalice su configuración de seguridad** en la sección **Seguridad**.
+ Elija **CMK administrada por el cliente** en **Configuración de clave de cifrado**.
+ Seleccione una clave en el ajuste **Clave de AWS KMS**.
#### Activación del cifrado en reposo en un clúster basado en nodos (consola)
Al diseñar su propia caché, las configuraciones de “desarrollo y prueba” y “producción” con el método “Creación sencilla” habilitan el cifrado en reposo mediante la clave **Predeterminada**. Al elegir la configuración, seleccione estas opciones:
+ Seleccione la versión 3.2.6, 4.0.10 o posterior como versión del motor.
+ Haga clic en la casilla de verificación situada junto a **Habilitar** en la opción **Cifrado en reposo**.
+ Elija una **Clave predeterminada** o una **CMK administrada por el cliente**.
Para conocer el step-by-step procedimiento, consulte lo siguiente:
+ [Creación de un clúster de Valkey (modo de clúster deshabilitado) (consola)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ [Creación de un clúster de Valkey o Redis OSS (modo de clúster habilitado) (consola)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
### Habilitación del cifrado en reposo mediante el AWS CLI
Para habilitar el cifrado en reposo al crear un clúster OSS de Valkey o Redis mediante el AWS CLI, utilice el at-rest-encryption-enabled parámetro *--* al crear un grupo de replicación.
#### Habilitación del cifrado en reposo en un clúster de Valkey o Redis OSS (modo de clúster deshabilitado) (CLI)
La siguiente operación crea el grupo de replicación de Valkey o Redis OSS (modo de clúster desactivado) `my-classic-rg` con tres nodos (*-- num-cache-clusters*), una réplica principal y dos réplicas de lectura. *El cifrado en reposo está habilitado para este grupo de replicación (--). at-rest-encryption-enabled*
Los siguientes parámetros y sus valores son necesarios para habilitar el cifrado de este grupo de reproducción:
**Parámetros clave**
+ **--engine**: debe ser `valkey` o `redis`.
+ **--engine-version**: si el motor es Redis OSS, debe ser la versión 3.2.6, 4.0.10 o posterior.
+ **--at-rest-encryption-enabled**: obligatorio para habilitar el cifrado en reposo.
**Example 1: clúster de Valkey o Redis OSS (modo de clúster deshabilitado) con réplicas**
Para Linux, macOS o 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
```
Para 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 ^
```
Para obtener más información, consulte los siguientes temas:
+ [Creación de un grupo de replicación de Valkey o Redis OSS (modo de clúster deshabilitado) desde cero (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)
#### Habilitación del cifrado en reposo en un clúster para Valkey o Redis OSS (modo de clúster habilitado) (CLI)
*La siguiente operación crea el grupo de replicación OSS (modo de clúster activado) de Valkey o Redis `my-clustered-rg` con tres grupos de nodos o fragmentos (--). num-node-groups* *Cada uno tiene tres nodos, una réplica principal y dos réplicas de lectura (--). replicas-per-node-group* El cifrado en reposo está habilitado para este grupo de replicación (*-- at-rest-encryption-enabled*).
Los siguientes parámetros y sus valores son necesarios para habilitar el cifrado de este grupo de reproducción:
**Parámetros clave**
+ **--engine**: debe ser `valkey` o `redis`.
+ **--engine-version**: si el motor es Redis OSS, debe ser la versión 4.0.10 o posterior.
+ **--at-rest-encryption-enabled**: obligatorio para habilitar el cifrado en reposo.
+ **--cache-parameter-group**: debe ser `default-redis4.0.cluster.on` o un valor derivado de este que lo convierta en un grupo de reproducción con el modo de clúster habilitado.
**Example 2: un clúster de Valkey o Redis OSS (modo de clúster habilitado)**
Para Linux, macOS o 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
```
Para 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
```
Para obtener más información, consulte los siguientes temas:
+ [Creación de un grupo de replicación de Valkey o Redis OSS (modo de clúster habilitado) desde cero (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)
## Véase también
+ [Amazon VPCs y la ElastiCache seguridad](VPCs.md)
+ [Identity and Access Management para Amazon ElastiCache](IAM.md)
# Autenticación y autorización
AWS Identity and Access Management (IAM) es un servicio web que lo ayuda a controlar de forma segura el acceso a los recursos de AWS. ElastiCache permite la autenticación de usuarios mediante IAM y el comando AUTH de Valkey y Redis OSS, así como la autorización de operaciones de usuarios mediante el control de acceso basado en roles (RBAC).
**Topics**
+ [Control de acceso basado en roles (RBAC)](Clusters.RBAC.md)
+ [Autenticación con el comando AUTH de Valkey o Redis OSS](auth.md)
+ [Deshabilitación del control de acceso en una caché de ElastiCache Valkey o Redis OSS](in-transit-encryption-disable.md)
# Control de acceso basado en roles (RBAC)
Con el comando AUTH de Valkey y Redis OSS, tal como se describe en [Autenticación con el comando AUTH de Valkey o Redis OSS](auth.md), puede utilizar el control de acceso basado en roles (RBAC). El RBAC también es la única forma de controlar el acceso a las cachés sin servidor. Está disponible para Valkey 7.2 en adelante y Redis OSS 6.0 a 7.2.
RBAC le permite:
+ Controlar el acceso a la caché a través de grupos de usuarios. Estos grupos de usuarios se han diseñado como una forma de organizar el acceso a las cachés.
+ Con *authN*, puede utilizar contraseñas por usuario en lugar de tokens de autenticación por clúster.
+ Con *authZ*, tiene permisos de usuario detallados.
+ Base su acceso al clúster en. ACLs
A diferencia de AUTH de Valkey y Redis OSS, donde todos los clientes autenticados tienen acceso completo a la caché si su token está autenticado, RBAC le permite asignar usuarios a conjuntos en función de los roles deseados de los usuarios. Estos conjuntos se han diseñado para organizar el acceso a las cachés.
Con el RBAC, puede crear usuarios y asignarles permisos específicos mediante una cadena de acceso, como se describe a continuación. Los usuarios se asignan a conjuntos alineados con una función específica (administradores, recursos humanos) que, a continuación, se despliegan en una o más ElastiCache cachés. Al hacerlo, puede establecer límites de seguridad entre clientes que utilicen las mismas cachés de Valkey o Redis OSS e impedir que los clientes accedan a los datos de los demás.
RBAC se ha diseñado para facilitar la introducción de [ACL](https://valkey.io/topics/acl/) en Redis OSS 6. Al utilizar RBAC con la caché de OSS de ElastiCache Valkey o Redis, existen algunas limitaciones:
+ Un grupo de usuarios configurado para el motor VALKEY solo puede contener usuarios que utilicen un mecanismo de autenticación (contraseña o IAM). Esto significa que todos los usuarios con el motor VALKEY y cualquier otro usuario con el motor Redis que tenga su configuración configurada para autenticarse con contraseña o IAM, pueden estar en este grupo de usuarios.
+ Cuando se utiliza RBAC con clústeres de Valkey, se pueden utilizar tanto los grupos de usuarios con el motor VALKEY como con el motor REDIS.
+ Cuando se utiliza RBAC con clústeres de Redis OSS, solo se pueden utilizar grupos de usuarios con el motor REDIS.
+ No puede especificar contraseñas en una cadena de acceso. Las contraseñas se configuran con nuestras llamadas. [CreateUser[ModifyUser](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyUser.html)](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateUser.html)
+ Para los derechos de usuarios, debe activar o desactivar usuarios con `on` y `off` como parte de la cadena de acceso. Si no se especifica ninguno en la cadena de acceso, se le asigna `off` al usuario y no tiene derechos de acceso a la caché.
+ No puede utilizar comandos prohibidos o renombrados en una cadena de acceso. Si especifica un comando prohibido o renombrado, se generará una excepción. Si desea utilizar listas de control de acceso (ACLs) para un comando cuyo nombre ha cambiado, especifique el nombre original del comando, es decir, el nombre del comando antes de cambiarle el nombre.
+ No puede utilizar el comando `reset` como parte de una cadena de acceso. Las contraseñas se especifican con parámetros de API y, en el caso ElastiCache de Valkey y Redis, OSS administra las contraseñas. Por lo tanto, no puede utilizar `reset` porque eliminará todas las contraseñas de un usuario.
+ Redis OSS 6 introduce el comando [ACL LIST](https://valkey.io/commands/acl-list). Este comando devuelve una lista de usuarios junto con las reglas de ACL aplicadas a cada usuario. ElastiCache admite el `ACL LIST` comando, pero no incluye soporte para hashes de contraseñas como lo hace Redis OSS. Con ElastiCache, puede utilizar la [DescribeUsers](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeUsers.html)operación para obtener información similar, incluidas las reglas contenidas en la cadena de acceso. Sin embargo, [DescribeUsers](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeUsers.html)no recupera la contraseña de un usuario.
+ [Otros comandos de solo lectura compatibles ElastiCache con Valkey y Redis OSS son [ACL WHOAMI, ACL USERS](https://valkey.io/commands/acl-whoami) y [ACL CAT](https://valkey.io/commands/acl-users).](https://valkey.io/commands/acl-cat) ElastiCache para Valkey y Redis, el OSS no admite ningún otro comando de ACL basado en la escritura.
+ Se aplican los siguientes límites:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonElastiCache/latest/dg/Clusters.RBAC.html)
**RBAC con Valkey**
Cuando se utiliza el control de acceso basado en roles con Valkey, los usuarios y los grupos de usuarios se crean con el tipo de motor VALKEY. Se recomienda esta opción, ya que, de forma predeterminada, Valkey con RBAC proporciona mayor seguridad en comparación con Redis OSS. Tanto los clústeres de Valkey aprovisionados como sin servidor admiten las asociaciones de usuarios y grupos de usuarios VALKEY.
Las principales características del control de acceso a Valkey son:
+ Los usuarios de Valkey están restringidos únicamente a las asociaciones de grupos de usuarios de Valkey.
+ Los grupos de usuarios de Valkey pueden incluir usuarios de Valkey y usuarios de Redis OSS protegidos con contraseña o habilitados para la autenticación de IAM.
+ Los usuarios de Valkey deben utilizar la protección por contraseña o la autenticación de IAM.
+ Los grupos de usuarios VALKEY solo se pueden asociar con los clústeres VALKEY.
+ No hay ningún requisito de usuario predeterminado. Cuando el grupo de usuarios de Valkey está asociado con clústeres, el requisito de usuario predeterminado se desactiva automáticamente. Los clientes verán que el usuario predeterminado está desactivado al usar el comando ACL LIST.
A continuación encontrará más información sobre el uso de RBAC con Valkey y Redis ElastiCache OSS.
**Topics**
+ [Especificación de permisos mediante una cadena de acceso](#Access-string)
+ [Aplicar RBAC a una caché para Valkey o Redis ElastiCache OSS](#rbac-using)
+ [Migración de AUTH a RBAC](#Migrate-From-RBAC-to-Auth)
+ [Migración de RBAC a AUTH](#Migrate-From-RBAC-to-AUTH-1)
+ [Rotación automática de contraseñas para usuarios](User-Secrets-Manager.md)
+ [Autenticación con IAM](auth-iam.md)
## Especificación de permisos mediante una cadena de acceso
Para especificar los permisos para una caché de OSS de ElastiCache Valkey o Redis, debe crear una cadena de acceso y asignarla a un usuario mediante la tecla o.AWS CLIConsola de administración de AWS
Las cadenas de acceso se definen como una lista de reglas delimitadas por espacios que se aplican al usuario. Definen qué comandos puede ejecutar un usuario y qué claves puede operar. Para ejecutar un comando, un usuario debe tener acceso al comando que se ejecuta y a todas las claves a las que accede el comando. Las reglas se aplican de izquierda a derecha de forma acumulativa y se puede utilizar una cadena más simple en lugar de la proporcionada si hay redundancias en la cadena proporcionada.
Para obtener más información sobre la sintaxis de las reglas de ACL, consulte [ACL](https://valkey.io/topics/acl/).
En el siguiente ejemplo, la cadena de acceso representa un usuario activo con acceso a todas las claves y comandos disponibles.
`on ~* +@all`
La sintaxis de la cadena de acceso se desglosa de la siguiente manera:
+ `on`: el usuario es un usuario activo.
+ `~*`: se brinda acceso a todas las claves disponibles.
+ `+@all`: se brinda acceso a todos los comandos disponibles.
La configuración anterior es la menos restrictiva. Puede modificar esta configuración para hacerla más segura.
En el siguiente ejemplo, la cadena de acceso representa a un usuario con acceso restringido al acceso de lectura en claves que comienzan por el espacio de claves “app::”
`on ~app::* -@all +@read`
Puede refinar aún más estos permisos al enumerar comandos a los que el usuario tiene acceso:
`+command1`: el acceso del usuario a los comandos se encuentra limitado a *`command1`*.
`+@category`: el acceso del usuario a los comandos se encuentra limitado a la categoría de comandos.
Para obtener información sobre cómo asignar una cadena de acceso a un usuario, consulte [Creación de usuarios y grupos de usuarios con la consola y la CLI](#Users-management).
Si va a migrar una carga de trabajo existente a ElastiCache, puede recuperar la cadena de acceso mediante una llamada`ACL LIST`, excluyendo los hashes de usuario y de contraseña.
Para la versión 6.2 y posteriores de Redis OSS, también se admite la siguiente sintaxis de cadena de acceso:
+ `&*`: se brinda acceso a todos los canales disponibles.
Para la versión 7.0 y posteriores de Redis OSS, también se admite la siguiente sintaxis de cadena de acceso:
+ `|`: se puede usar para bloquear subcomandos (por ejemplo, “-config\$1set”).
+ `%R~`: agregue el patrón de claves de lectura especificado. Esto se comporta de forma similar al patrón de claves normal, pero solo permite leer las claves que coinciden con el patrón dado. Consulte [key permissions](https://valkey.io/topics/acl/) (permisos de clave) para obtener más información.
+ `%W~`: agregue el patrón de claves de escritura especificado. Esto se comporta de forma similar al patrón de claves normal, pero solo concede permiso de escritura a las claves que coinciden con el patrón dado. Consulte [ACL key permissions](https://valkey.io/topics/acl/) para obtener más información.
+ `%RW~`: alias para `~`.
+ `()`: cree un nuevo selector con el que comparar las reglas. Los selectores se evalúan después de los permisos del usuario y según el orden en que se definen. Si un comando coincide con los permisos del usuario o con algún selector, está permitido. Consulte la página sobre [selectores de ACL](https://valkey.io/topics/acl/) para obtener más información.
+ `clearselectors`: elimine todos los selectores asociados al usuario.
## Aplicar RBAC a una caché para Valkey o Redis ElastiCache OSS
Para usarlo ElastiCache para Valkey o Redis OSS RBAC, siga los siguientes pasos:
1. Cree uno o más usuarios.
1. Cree un grupo de usuarios y agregue usuarios al grupo.
1. Asigne el grupo de usuarios a una caché que tenga el cifrado en tránsito habilitado.
Estos pasos se describen con detalle a continuación.
**Topics**
+ [Creación de usuarios y grupos de usuarios con la consola y la CLI](#Users-management)
+ [Administración de grupos de usuarios con la consola y la CLI](#User-Groups)
+ [Asignación de grupos de usuarios a cachés sin servidor](#Users-groups-to-serverless-caches)
+ [Asignación de grupos de usuarios a grupos de reproducción](#Users-groups-to-RGs)
### Creación de usuarios y grupos de usuarios con la consola y la CLI
La información de usuario para los usuarios de RBAC es un ID de usuario, nombre de usuario y, opcionalmente, una contraseña y una cadena de acceso. La cadena de acceso proporciona el nivel de permisos en las claves y comandos. El ID de usuario es exclusivo del usuario y el nombre de usuario es lo que se pasa al motor.
Asegúrese de que los permisos de usuario que proporcione tengan sentido con el propósito previsto del grupo de usuarios. Por ejemplo, si crea un grupo de usuarios denominado `Administrators`, cualquier usuario que agregue a ese grupo debe tener su cadena de acceso establecida en el acceso completo a las claves y comandos. Para los usuarios de un grupo de usuarios `e-commerce`, puede establecer las cadenas de acceso en acceso de solo lectura.
ElastiCache configura automáticamente un usuario predeterminado con un ID de usuario y un nombre de usuario y lo añade a todos `"default"` los grupos de usuarios. No puede modificar ni eliminar este usuario. Este usuario se ha diseñado para ser compatible con el comportamiento predeterminado de las versiones anteriores de Redis OSS y tiene una cadena de acceso que permite llamar a todos los comandos y acceder a todas las claves.
Para agregar un control de acceso adecuado a una caché, reemplace este usuario predeterminado por uno nuevo que no se encuentre habilitado o utilice una contraseña segura. Para cambiar el usuario predeterminado, cree un usuario nuevo con el nombre de usuario establecido en `default`. A continuación, puede intercambiarlo con el usuario predeterminado original.
En los siguientes procedimientos se muestra cómo intercambiar el usuario `default` original con otro usuario `default` que tiene una cadena de acceso modificada.
**Para modificar el usuario predeterminado de la consola**
1. Inicia sesión en la ElastiCache consola de Amazon Consola de administración de AWS y ábrela en [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Seleccione **Administración de grupos de usuarios** en el panel de navegación.
1. En **ID de grupo de usuarios**, elija el ID que desea modificar. Asegúrese de elegir el enlace y no la casilla de verificación.
1. Elija **Modificar**.
1. En la ventana **Modificar**, seleccione **Administrar**. En Seleccione el usuario que desee, elija el usuario con el **Nombre de usuario** predeterminado.
1. Seleccione **Elegir**.
1. Elija **Modificar**. Al hacerlo, se terminan todas las conexiones existentes que el usuario predeterminado tenga a una caché.
**Para modificar el usuario predeterminado con el AWS CLI**
1. Cree un usuario nuevo con el nombre de usuario `default` mediante los siguientes comandos.
Para Linux, macOS o 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*"
```
Para 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. Cree un grupo de usuarios y agregue el usuario que creó anteriormente.
Para Linux, macOS o Unix:
```
aws elasticache create-user-group \
--user-group-id "new-group-2" \
--engine "VALKEY" \
--user-ids "new-default-user"
```
Para Windows:
```
aws elasticache create-user-group ^
--user-group-id "new-group-2" ^
--engine "VALKEY" ^
--user-ids "new-default-user"
```
Al crear un usuario, puede configurar hasta dos contraseñas. Al modificar una contraseña, se mantienen todas las conexiones existentes a las cachés.
En concreto, tenga en cuenta estas restricciones de contraseña de usuario cuando utilice RBAC ElastiCache para Valkey y Redis OSS:
+ Las contraseñas deben tener entre 16 y 128 caracteres imprimibles.
+ No se admiten los siguientes caracteres no alfanuméricos: `,` `""` `/` `@`.
#### Administración de usuarios con la consola y la CLI
Utilice el siguiente procedimiento para administrar usuarios en la consola.
**Para administrar usuarios con la consola**
1. Inicia sesión en la ElastiCache consola de Amazon Consola de administración de AWS y ábrela en [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. En el ElastiCache panel de Amazon, selecciona **Gestión de usuarios**. Están disponibles las siguientes opciones:
+ **Crear usuario**: al crear un usuario, introduce un ID de usuario, un nombre de usuario, un modo de autenticación y una cadena de acceso. La cadena de acceso establece el nivel de permisos para qué claves y comandos se permite al usuario.
Al crear un usuario, puede configurar hasta dos contraseñas. Al modificar una contraseña, se mantienen todas las conexiones existentes a las cachés.
+ **Modificar usuario**: permite actualizar la configuración de autenticación de un usuario o cambiar su cadena de acceso.
+ **Eliminar usuario**: la cuenta se eliminará de cualquier grupo de usuarios al que pertenezca.
Utilice los siguientes procedimientos para administrar usuarios con la AWS CLI.
**Para modificar un usuario mediante la CLI**
+ Utilice el comando `modify-user` para actualizar la contraseña o contraseñas de un usuario o cambiar los permisos de acceso de un usuario.
Cuando se modifica un usuario, se actualizan los grupos de usuarios asociados al usuario, junto con las cachés asociadas al grupo de usuarios. Se mantienen todas las conexiones existentes. A continuación se muestran algunos ejemplos.
Para Linux, macOS o Unix:
```
aws elasticache modify-user \
--user-id user-id-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode Type=iam
```
Para Windows:
```
aws elasticache modify-user ^
--user-id user-id-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode Type=iam
```
**nota**
No recomendamos utilizar la opción `nopass`. Si lo hace, recomendamos que configure los permisos del usuario en solo lectura con acceso a un conjunto limitado de claves.
**Para eliminar un usuario mediante la CLI**
+ Ejecute el comando `delete-user` para eliminar un usuario. La cuenta se borra y elimina de todos los grupos de usuarios a los que pertenezca. A continuación se muestra un ejemplo.
Para Linux, macOS o Unix:
```
aws elasticache delete-user \
--user-id user-id-2
```
Para Windows:
```
aws elasticache delete-user ^
--user-id user-id-2
```
Para ver una lista de usuarios, llame a la operación [describe-users](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-users.html).
```
aws elasticache describe-users
```
### Administración de grupos de usuarios con la consola y la CLI
Puede crear grupos de usuarios para organizar y controlar el acceso de los usuarios a una o más cachés, como se muestra a continuación.
Utilice el siguiente procedimiento para administrar grupos de usuarios en la consola.
**Para administrar grupos de usuarios mediante la consola**
1. Inicia sesión en la ElastiCache consola de Amazon Consola de administración de AWS y ábrela en [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. En el ElastiCache panel de Amazon, selecciona **Administración de grupos de usuarios**.
A continuación, se muestran las operaciones disponibles para crear grupos de usuarios nuevos:
+ **Crear**: al crear un grupo de usuarios, se agregan usuarios y, a continuación, se asignan los grupos de usuarios a las cachés. Por ejemplo, puede crear un grupo de usuarios `Admin` para los usuarios que tienen roles administrativos en una caché.
**importante**
Si no utiliza ningún grupo de usuarios de Valkey o Redis OSS, debe incluir un usuario predeterminado al crear un grupo de usuarios.
+ **Agregar usuarios**: agregue usuarios al grupo de usuarios.
+ **Eliminar usuarios**: elimine usuarios del grupo de usuarios. Cuando se quitan usuarios de un grupo de usuarios, se terminan todas las conexiones existentes que tengan a una caché.
+ **Eliminar**: utilice esta opción para eliminar un grupo de usuarios. Tenga en cuenta que se eliminará el grupo de usuarios en sí, no los usuarios que pertenecen al grupo.
Para los grupos de usuarios existentes, puede realizar lo siguiente:
+ **Agregar usuarios**: agregue usuarios existentes al grupo de usuarios.
+ **Eliminar usuarios**: elimine los usuarios existentes del grupo de usuarios.
**nota**
Los usuarios se eliminan del grupo de usuarios, pero no se eliminan del sistema.
Utilice el siguiente procedimiento para administrar grupos de usuarios en la CLI.
**Para crear un grupo de usuarios nuevo y agregar un usuario mediante la CLI**
+ Utilice el comando `create-user-group`, tal y como se muestra a continuación:
Para Linux, macOS o Unix:
```
aws elasticache create-user-group \
--user-group-id "new-group-1" \
--engine "VALKEY" \
--user-ids user-id-1, user-id-2
```
Para Windows:
```
aws elasticache create-user-group ^
--user-group-id "new-group-1" ^
--engine "VALKEY" ^
--user-ids user-id-1, user-id-2
```
**Para modificar un grupo de usuarios al agregar usuarios nuevos o eliminar miembros actuales mediante la CLI**
+ Utilice el comando `modify-user-group`, tal y como se muestra a continuación:
Para Linux, macOS o 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
```
Para 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
```
**nota**
Cualquier conexión abierta que pertenezca a un usuario eliminado de un grupo de usuarios finaliza con este comando.
**Para eliminar un grupo de usuarios mediante la CLI**
+ Utilice el comando `delete-user-group`, tal y como se muestra a continuación: Se elimina el grupo de usuarios en sí, no los usuarios que pertenecen al grupo.
Para Linux, macOS o Unix:
```
aws elasticache delete-user-group /
--user-group-id
```
Para Windows:
```
aws elasticache delete-user-group ^
--user-group-id
```
Para ver una lista de grupos de usuarios, puedes llamar a la [describe-user-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-user-groups.html)operación.
```
aws elasticache describe-user-groups \
--user-group-id test-group
```
### Asignación de grupos de usuarios a cachés sin servidor
Después de crear un grupo de usuarios y agregar usuarios, el paso final para implementar el RBAC es asignar el grupo de usuarios a una caché sin servidor.
#### Asignación de grupos de usuarios a cachés sin servidor mediante la consola
Para añadir un grupo de usuarios a una caché sin servidor mediante el Consola de administración de AWS, haga lo siguiente:
+ Para el modo de clúster deshabilitado, consulte [Creación de un clúster de Valkey (modo de clúster deshabilitado) (consola)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ Para el modo de clúster habilitado, consulte [Creación de un clúster de Valkey o Redis OSS (modo de clúster habilitado) (consola)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
#### Asignación de grupos de usuarios a cachés sin servidor mediante el AWS CLI
La siguiente AWS CLI operación crea una caché sin servidor mediante el **user-group-id** parámetro con el valor. `my-user-group-id` Reemplace el grupo de subredes `sng-test` por otro existente.
**Parámetros clave**
+ **--engine**: debe ser `VALKEY` o `REDIS`.
+ **--user-group-id**: este valor proporciona el ID del grupo de usuarios, compuesto por usuarios con permisos de acceso especificados para la caché.
Para Linux, macOS o Unix:
```
aws elasticache create-serverless-cache \
--serverless-cache-name "new-serverless-cache" \
--description "new-serverless-cache" \
--engine "VALKEY" \
--user-group-id "new-group-1"
```
Para Windows:
```
aws elasticache create-serverless-cache ^
--serverless-cache-name "new-serverless-cache" ^
--description "new-serverless-cache" ^
--engine "VALKEY" ^
--user-group-id "new-group-1"
```
La siguiente AWS CLI operación modifica una caché sin servidor con el **user-group-id** parámetro con el valor. `my-user-group-id`
Para Linux, macOS o Unix:
```
aws elasticache modify-serverless-cache \
--serverless-cache-name serverless-cache-1 \
--user-group-id "new-group-2"
```
Para Windows:
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name serverless-cache-1 ^
--user-group-id "new-group-2"
```
Tenga en cuenta que cualquier modificación que se haga en una caché se actualizará de forma asíncrona. Puede monitorear el progreso al visualizar los eventos. Para obtener más información, consulte [Visualización de ElastiCache eventos](ECEvents.Viewing.md).
### Asignación de grupos de usuarios a grupos de reproducción
Después de crear un grupo de usuarios y agregar usuarios, el paso final para implementar el RBAC es asignar el grupo de usuarios a un grupo de reproducción.
#### Asignación de grupos de usuarios a grupos de reproducción mediante la consola
Para añadir un grupo de usuarios a una replicación mediante el Consola de administración de AWS, haga lo siguiente:
+ Para el modo de clúster deshabilitado, consulte [Creación de un clúster de Valkey (modo de clúster deshabilitado) (consola)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ Para el modo de clúster habilitado, consulte [Creación de un clúster de Valkey o Redis OSS (modo de clúster habilitado) (consola)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
#### Asignación de grupos de usuarios a grupos de replicación mediante el AWS CLI
La siguiente AWS CLI operación crea un grupo de replicación con el cifrado en tránsito (TLS) activado y el **user-group-ids** parámetro con el valor. `my-user-group-id` Reemplace el grupo de subredes `sng-test` por otro existente.
**Parámetros clave**
+ **--engine**: debe ser `valkey` o `redis`.
+ **--engine-version**: debe ser 6.0 o posterior.
+ **--transit-encryption-enabled**: obligatorio para la autenticación y a fin de asociar un grupo de usuarios.
+ **--user-group-ids**: este valor proporciona el ID del grupo de usuarios, compuesto por usuarios con permisos de acceso especificados para la caché.
+ **--cache-subnet-group**: obligatorio para asociar un grupo de usuarios.
Para Linux, macOS o 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"
```
Para 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"
```
La siguiente AWS CLI operación modifica un grupo de replicación con el cifrado en tránsito (TLS) habilitado y el **user-group-ids** parámetro con el valor. `my-user-group-id`
Para Linux, macOS o 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"
```
Para 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"
```
Tenga en cuenta los `PendingChanges` en la respuesta. Las modificaciones que se hagan en una caché se actualizarán de forma asíncrona. Puede monitorear el progreso al visualizar los eventos. Para obtener más información, consulte [Visualización de ElastiCache eventos](ECEvents.Viewing.md).
## Migración de AUTH a RBAC
Si se encuentra utilizando AUTH como se describe en [Autenticación con el comando AUTH de Valkey o Redis OSS](auth.md) y desea migrar a RBAC, utilice los siguientes procedimientos.
Utilice el siguiente procedimiento para migrar de AUTH a RBAC con la consola.
**Migración de AUTH de Valkey o Redis OSS a RBAC mediante la consola**
1. Inicie sesión en Consola de administración de AWS y abra la ElastiCache consola en. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. En la lista de la esquina superior derecha, selecciona la AWS región en la que se encuentra la memoria caché que deseas modificar.
1. En el panel de navegación, elija el motor que se ejecuta en la caché que desea modificar.
Aparecerá una lista de las cachés del motor elegido.
1. En la lista de cachés, elija el nombre de la caché que desea modificar.
1. Para **Actions (Acciones)**, elija **Modify (Modificar)**.
Aparecerá la ventana **Modificar**.
1. En **Opción de control de acceso**, elija **Lista de control de acceso de grupos de usuarios**.
1. En **Lista de control de acceso de grupos de usuarios**, elija un grupo de usuarios.
1. Seleccione **Vista previa de los cambios** y seleccione **Modificar** en la siguiente pantalla.
Utilice el siguiente procedimiento para migrar de AUTH de Valkey o Redis OSS a RBAC con la CLI.
**Migración de AUTH a RBAC mediante la CLI**
+ Utilice el comando `modify-replication-group`, tal y como se muestra a continuación:
Para Linux, macOS o Unix:
```
aws elasticache modify-replication-group --replication-group-id test \
--auth-token-update-strategy DELETE \
--user-group-ids-to-add user-group-1
```
Para Windows:
```
aws elasticache modify-replication-group --replication-group-id test ^
--auth-token-update-strategy DELETE ^
--user-group-ids-to-add user-group-1
```
## Migración de RBAC a AUTH
Si utiliza RBAC y desea migrar a AUTH de Redis OSS, consulte [Migración de RBAC a AUTH](auth.md#Migrate-From-RBAC-to-AUTH).
**nota**
Si necesitas deshabilitar el control de acceso a una ElastiCache caché, tendrás que hacerlo a través del.AWS CLI Para obtener más información, consulte [Deshabilitación del control de acceso en una caché de ElastiCache Valkey o Redis OSS](in-transit-encryption-disable.md).
# Rotación automática de contraseñas para usuarios
Con AWS Secrets Manager, puedes reemplazar las credenciales codificadas de tu código (incluidas las contraseñas) por una llamada a la API a Secrets Manager para recuperar el secreto mediante programación. Esto ayuda a garantizar la integridad del secreto si alguien examina el código, dado que el secreto sencillamente no está allí. Asimismo, puede configurar Secrets Manager para rotar el secreto automáticamente de acuerdo con la programación que especifique. Esto le permite reemplazar secretos a largo plazo con secretos a corto plazo, lo que contribuye a reducir significativamente el riesgo de peligro.
Con Secrets Manager, puede rotar automáticamente sus contraseñas de OSS ElastiCache para Redis (es decir, secretas) mediante una AWS Lambda función que proporciona Secrets Manager.
Para obtener más información al respecto AWS Secrets Manager, consulte [¿Qué es?AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)
## ¿Cómo ElastiCache usa los secretos
Valkey 7.2 y versiones posteriores tiene un conjunto de características equivalente al de Redis OSS 7.0. En Redis OSS 6, ElastiCache introducido [Control de acceso basado en roles (RBAC)](Clusters.RBAC.md) para proteger el clúster OSS de Valkey o Redis. Esta característica permite limitar determinadas conexiones en términos de los comandos que se pueden ejecutar y las claves a las que se puede acceder. Con RBAC, mientras el cliente crea un usuario con contraseñas, los valores de la contraseña se deben ingresar manualmente en texto no cifrado y estar visibles para el operador.
Con Secrets Manager, las aplicaciones obtienen la contraseña de Secrets Manager en lugar de ingresarla manualmente y almacenarla en la configuración de la aplicación. Para obtener información sobre cómo hacerlo, consulte [Cómo se asocian ElastiCache los usuarios al secreto](#How-User-Secrets-Manager-Associate).
El uso de secretos conlleva un coste. Para obtener información sobre precios, consulte [Precios de AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/).
## Cómo se asocian ElastiCache los usuarios al secreto
Secrets Manager guardará una referencia del usuario asociado en el campo `SecretString` del secreto. No habrá ninguna referencia al secreto desde ElastiCache un lado.
```
{
"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
}
```
## Función de rotación de Lambda
Para habilitar la rotación automática de contraseñas de Secrets Manager, se creará una función de Lambda que interactuará con la API [modificar-usuario](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-user.html) para actualizar las contraseñas del usuario.
Para obtener información sobre cómo funciona esto, consulte [Cómo funciona la rotación](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html#rotate-secrets_how).
**nota**
En el caso de algunos AWS servicios, para evitar el confuso escenario de los suplentes, se AWS recomienda utilizar tanto la `aws:SourceArn` clave de condición como la clave de condición `aws:SourceAccount` global. No obstante, si se incluye la condición `aws:SourceArn` en la política de la función de rotación, la función de rotación solo se puede utilizar para rotar el secreto especificado por ese ARN. Se recomienda incluir solo la clave de contexto `aws:SourceAccount`, para poder utilizar la función de rotación para varios secretos.
Para cualquier problema que puedas encontrar, consulta [Solucionar problemas de rotación de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/troubleshoot_rotation.html).
## Cómo crear un ElastiCache usuario y asociarlo a Secrets Manager
Los siguientes pasos muestran cómo crear un usuario y asociarlo con Secrets Manager:
1. **Crear un usuario inactivo**
Para Linux, macOS o 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
```
Para 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
```
Verá una respuesta similar a la siguiente:
```
{
"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. **Crear un secreto**
Para Linux, macOS o Unix:
```
aws secretsmanager create-secret \
--name production/ec/user1 \
--secret-string \
'{
"user_arn": "arn:aws:elasticache:us-east-1:123456xxxx:user:user1",
"username":"user1"
}'
```
Para Windows:
```
aws secretsmanager create-secret ^
--name production/ec/user1 ^
--secret-string ^
'{
"user_arn": "arn:aws:elasticache:us-east-1:123456xxxx:user:user1",
"username":"user1"
}'
```
Verá una respuesta similar a la siguiente:
```
{
"ARN": "arn:aws:secretsmanager:us-east-1:123456xxxx:secret:production/ec/user1-eaFois",
"Name": "production/ec/user1",
"VersionId": "aae5b963-1e6b-4250-91c6-ebd6c47d0d95"
}
```
1. **Configurar una función de Lambda para rotar la contraseña**
1. Inicie sesión en la consola Lambda Consola de administración de AWS y ábrala en [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/elasticache/)
1. Elija **Functions** (Funciones) en el panel de navegación y, a continuación, elija la función que ha creado. Elija el nombre de la función, no la casilla de verificación situada a la izquierda.
1. Elija la pestaña **Configuración**.
1. En **General configuration** (Configuración general), elija **Edit** (Editar) y, a continuación, establezca **Timeout** (Tiempo de espera) en al menos 12 minutos.
1. Seleccione **Save**.
1. Elija **Environment variables** (Variables de entorno) y, a continuación, establezca lo siguiente:
1. SECRETS\$1MANAGER\$1ENDPOINT: https://secretsmanager.**REGION**.amazonaws.com
1. SECRET\$1ARN: el nombre de recurso de Amazon (ARN) del secreto que creó en el paso 2.
1. USER\$1NAME: nombre de usuario del usuario, ElastiCache
1. Seleccione **Save**.
1. Elegir **Permissions** (Permisos)
1. En **Execution role** (Rol de ejecución), elija el nombre del rol de la función de Lambda para verla en la consola de IAM.
1. La función de Lambda necesitará el siguiente permiso para modificar los usuarios y establecer la contraseña:
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. Configurar la rotación de secretos de Secrets Manager
1. **Uso de Consola de administración de AWS, consulte [Configurar la rotación automática de los AWS secretos de Secrets Manager mediante la consola](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html)**
Para obtener más información sobre la configuración de un programa de rotación, consulte [Programación de expresiones en la rotación de Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_schedule.html).
1. **Con el AWS CLI, consulte [Configurar la rotación automática para AWS Secrets Manager usar el AWS Command Line Interface](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets-cli.html)**
# Autenticación con IAM
**Topics**
+ [Descripción general de](#auth-iam-overview)
+ [Limitaciones](#auth-iam-limits)
+ [Configuración](#auth-iam-setup)
+ [Conexión](#auth-iam-Connecting)
## Descripción general de
Con la autenticación de IAM, puede autenticar una conexión ElastiCache para Valkey o Redis OSS mediante identidades de AWS IAM, si su caché está configurada para usar Valkey o Redis OSS versión 7 o superior. Esto le permite reforzar el modelo de seguridad y simplificar muchas tareas de seguridad administrativa. También puede utilizar la autenticación de IAM para configurar un control de acceso detallado para cada caché y usuario individual, siguiendo los principios de permisos con privilegios mínimos. ElastiCache ElastiCache La autenticación de IAM ElastiCache funciona proporcionando un token de autenticación de IAM de corta duración en lugar de una contraseña de usuario de larga duración ElastiCache en el OSS o comando de Valkey o Redis. `AUTH` `HELLO` Para obtener más información sobre el token de autenticación de IAM, consulte el [proceso de firma de la versión 4](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) en la Guía de referencia AWS general y el ejemplo de código que aparece a continuación.
Puede utilizar las identidades de IAM y sus políticas asociadas para restringir aún más el acceso a Valkey o Redis OSS. También puede conceder acceso a los usuarios desde sus proveedores de identidades federados directamente a las cachés de Valkey o Redis OSS.
Para usar AWS IAM con ElastiCache, primero debe crear un ElastiCache usuario con el modo de autenticación configurado en IAM. A continuación, puede crear o reutilizar una identidad de IAM. La identidad de IAM necesita una política asociada para conceder la `elasticache:Connect` acción a la ElastiCache memoria caché y al usuario. ElastiCache Una vez configurado, puede crear un token de autenticación de IAM con AWS las credenciales del usuario o rol de IAM. Por último, debe proporcionar el token de autenticación de IAM de corta duración como contraseña en el cliente de Valkey o Redis OSS cuando se conecte a la caché. Un cliente OSS de Valkey o Redis con soporte para el proveedor de credenciales puede generar automáticamente las credenciales temporales para cada nueva conexión. ElastiCache realizará la autenticación de IAM para las solicitudes de conexión de los ElastiCache usuarios habilitados para IAM y validará las solicitudes de conexión con IAM.
## Limitaciones
Si utiliza la autenticación de IAM, se aplicarán las siguientes limitaciones:
+ La autenticación de IAM está disponible cuando se utiliza ElastiCache para Valkey 7.2 y versiones posteriores o para Redis OSS, versión 7.0 y versiones posteriores.
+ En el caso de ElastiCache los usuarios con IAM, las propiedades del nombre de usuario y el identificador de usuario deben ser idénticas.
+ El token de autenticación de IAM es válido durante 15 minutos. Para conexiones de larga duración, recomendamos utilizar un cliente de Valkey o Redis OSS que admita la interfaz de un proveedor de credenciales.
+ Una conexión autenticada ElastiCache por IAM a Valkey o Redis OSS se desconectará automáticamente después de 12 horas. La conexión se puede prolongar durante 12 horas enviando un comando `AUTH` o `HELLO` con un nuevo token de autenticación de IAM.
+ Los comandos `MULTI EXEC` no admiten la autenticación de IAM.
+ Actualmente, la autenticación de IAM admite las siguientes claves de contexto de condición global:
+ Cuando se utiliza la autenticación de IAM con cachés sin servidor, se admiten `aws:VpcSourceIp`, `aws:SourceVpc`, `aws:SourceVpce`, `aws:CurrentTime`, `aws:EpochTime` y `aws:ResourceTag/%s` (desde usuarios y cachés sin servidor asociados).
+ Cuando se utiliza la autenticación de IAM con grupos de réplica, se admiten `aws:SourceIp` y `aws:ResourceTag/%s` (desde los usuarios y grupos de réplica asociados).
Para obtener más información sobre las claves de contexto de condición globales, consulte [Claves de contexto de condición globales de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) en la Guía del usuario de IAM.
## Configuración
Para configurar la autenticación de IAM:
1. Creación de una caché
```
aws elasticache create-serverless-cache \
--serverless-cache-name cache-01 \
--description "ElastiCache IAM auth application" \
--engine redis
```
1. Cree un documento de política de confianza de IAM, como se muestra a continuación, para el rol que permita a la cuenta asumir el nuevo rol. Guarde la política en un archivo denominado *trust-policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. Cree un documento de política de IAM, como se muestra a continuación. Guarde la política en un archivo denominado *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. Crear un rol de IAM.
```
aws iam create-role \
--role-name "elasticache-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Creación de la política de IAM.
```
aws iam create-policy \
--policy-name "elasticache-allow-all" \
--policy-document file://policy.json
```
1. Adjunte la política de IAM al rol.
```
aws iam attach-role-policy \
--role-name "elasticache-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/elasticache-allow-all"
```
1. Cree un nuevo usuario habilitado para 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. Cree un grupo de usuarios y asocie al usuario.
```
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
```
## Conexión
**Conectar con el token como contraseña**
Primero debe generar el token de autenticación de IAM de corta duración mediante una [solicitud prefirmada SigV4 de AWS](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). A continuación, debe proporcionar el token de autenticación de IAM como contraseña al conectarse a una caché de Valkey o Redis OSS, como se muestra en el ejemplo siguiente.
```
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();
```
A continuación, se muestra la definición 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());
}
}
```
**Conectar con el proveedor de credenciales**
El siguiente código muestra cómo autenticarse con el proveedor de credenciales de autenticación de ElastiCache 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();
```
A continuación se muestra un ejemplo de un cliente OSS de Lettuce Redis que incluye un proveedor de credenciales para generar automáticamente credenciales temporales cuando sea necesario. IAMAuth TokenRequest
```
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());
}
}
```
# Autenticación con el comando AUTH de Valkey o Redis OSS
**nota**
**AUTH** se ha reemplazado por [Control de acceso basado en roles (RBAC)](Clusters.RBAC.md). Todas las cachés sin servidor deben usar RBAC para la autenticación.
Las contraseñas o tokens de autenticación de Valkey y Redis OSS permiten a Valkey y Redis OSS exigir una contraseña para que los clientes puedan ejecutar comandos, lo que mejora la seguridad de los datos. **AUTH** está disponible solo para clústeres basados en nodos.
**Topics**
+ [Descripción general de AUTH en Valkey y Redis ElastiCache OSS](#auth-overview)
+ [Aplicar la autenticación a un clúster de OSS ElastiCache para Valkey y Redis](#auth-using)
+ [Modificación del token de AUTH en un clúster existente](#auth-modifyng-token)
+ [Migración de RBAC a AUTH](#Migrate-From-RBAC-to-AUTH)
## Descripción general de AUTH en Valkey y Redis ElastiCache OSS
Cuando lo usa **AUTH** con su clúster OSS ElastiCache para Valkey y Redis, hay algunas mejoras.
En concreto, tenga en cuenta estas restricciones de los tokens o contraseñas de AUTH al utilizar AUTH:
+ Los tokens o contraseñas, deben tener entre 16 y 128 caracteres imprimibles.
+ Los caracteres no alfanuméricos están restringidos a (\$1, &, \$1, \$1, ^, <, >, -).
+ Solo se puede activar AUTH para los clústeres de Valkey o Redis OSS con el cifrado en tránsito activado.
Para configurar un token seguro, recomendamos que siga una política de contraseña estricta, como las que exigen las siguientes condiciones:
+ Los tokens o contraseñas deben incluir al menos tres de los siguientes tipos de caracteres:
+ Caracteres en mayúsculas
+ Caracteres en minúsculas
+ Dígitos
+ Caracteres no alfanuméricos (`!`, `&`, `#`, `$`, `^`, `<`, `>`, `-`)
+ Los tokens o contraseñas no deben contener una palabra del diccionario ni una palabra del diccionario modificada ligeramente.
+ Los tokens o contraseñas no deben ser iguales ni similares a un token que se haya utilizado recientemente.
## Aplicar la autenticación a un clúster de OSS ElastiCache para Valkey y Redis
Puede exigir a los usuarios que introduzcan un token (contraseña) en un servidor de Valkey o Redis OSS protegido mediante token. Para ello, incluya el parámetro `--auth-token` (API: `AuthToken`) con el token correcto al crear el clúster o grupo de reproducción. Inclúyalo también en todos los comandos posteriores para el clúster o grupo de reproducción.
La siguiente AWS CLI operación crea un grupo de replicación con el cifrado en tránsito (TLS) habilitado y el token. **AUTH** `This-is-a-sample-token` Reemplace el grupo de subredes `sng-test` por otro existente.
**Parámetros clave**
+ **--engine**: debe ser `valkey` o `redis`.
+ **--engine-version**: si el motor es Redis OSS, debe ser la versión 3.2.6, 4.0.10 o una posterior.
+ **--transit-encryption-enabled**: obligatorio para la autenticación y elegibilidad para la HIPAA.
+ **--auth-token**: obligatorio para la conformidad con la HIPAA. Este valor deber ser el token correcto de este servidor de Valkey o Redis OSS protegido mediante token.
+ **--cache-subnet-group**: obligatorio para la conformidad con la HIPAA.
Para Linux, macOS o 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
```
Para 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
```
## Modificación del token de AUTH en un clúster existente
Para facilitar la actualización de la autenticación, puede modificar el token de **AUTH** utilizado en un clúster. Puede realizar esta modificación si la versión del motor es Valkey 7.2 o superior o Redis 5.0.6 o superior. ElastiCache también debe tener activado el cifrado en tránsito.
La modificación del token de AUTH admite dos estrategias: ROTATE y SET. La estrategia ROTATE añade un token de AUTH adicional al servidor a la vez que se retiene el token anterior. La estrategia SET actualiza el servidor para que admita un único token de AUTH. Realice estas llamadas de modificación con el parámetro `--apply-immediately` para aplicar los cambios de inmediato.
### Rotación del token AUTH
Para actualizar un servidor de Valkey o Redis OSS con un nuevo **token de AUTH**, llame a la API de `ModifyReplicationGroup` con el parámetro `--auth-token` como nuevo token de **AUTH** y `--auth-token-update-strategy` con el valor ROTATE. Una vez que finaliza la modificación de ROTATE, el clúster admitirá el token de AUTH anterior además del especificado en el parámetro `auth-token`. Si no se configuró ningún token de AUTH en el grupo de replicación antes de la rotación del token de AUTH, el clúster admite el token de AUTH especificado en el parámetro `--auth-token`, además de la conexión sin autenticación. Consulte [Configuración del token AUTH](#auth-modifying-set) para actualizar el token de AUTH que se va a exigir mediante la estrategia de actualización SET.
**nota**
Si no configura el token AUTH antes, una vez completada la modificación, el clúster no admitirá ningún token AUTH además del especificado en el parámetro auth-token.
Si esta modificación se realiza en un servidor que ya admite dos tokens de AUTH, el token de AUTH más antiguo también se eliminará durante esta operación. Esto permite que un servidor admita hasta los dos token de AUTH más recientes en un momento determinado.
En este momento, puede continuar con la actualización del cliente para que utilice el último token de AUTH. Una vez que se actualizan los clientes, puede utilizar la estrategia SET para la rotación del token **AUTH** (que se explica en la sección siguiente) a fin de comenzar a utilizar en exclusiva el token nuevo.
La siguiente AWS CLI operación modifica un grupo de replicación para rotar el **AUTH** token`This-is-the-rotated-token`.
Para Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id authtestgroup \
--auth-token This-is-the-rotated-token \
--auth-token-update-strategy ROTATE \
--apply-immediately
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id authtestgroup ^
--auth-token This-is-the-rotated-token ^
--auth-token-update-strategy ROTATE ^
--apply-immediately
```
### Configuración del token AUTH
Para actualizar un servidor de Valkey o Redis OSS para que admita un único token de **AUTH** obligatorio, llame a la operación de la API `ModifyReplicationGroup` con el parámetro `--auth-token` con el mismo valor que el último token de AUTH y el parámetro `--auth-token-update-strategy` con el valor `SET`. La estrategia SET solo se puede usar con un clúster que tenga dos token de AUTH o un token de AUTH opcional debido al uso anterior de una estrategia ROTATE. Una vez finalizada la modificación, el servidor solo admite el token de AUTH especificado en el parámetro auth-token.
La siguiente AWS CLI operación modifica un grupo de replicación en el que se establece el token AUTH. `This-is-the-set-token`
Para Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id authtestgroup \
--auth-token This-is-the-set-token \
--auth-token-update-strategy SET \
--apply-immediately
```
Para Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id authtestgroup ^
--auth-token This-is-the-set-token ^
--auth-token-update-strategy SET ^
--apply-immediately
```
### Habilitación de la autenticación en un clúster existente
Para habilitar la autenticación en un servidor de Valkey o Redis OSS existente, llame a la operación de la API `ModifyReplicationGroup`. Llame a `ModifyReplicationGroup` con el parámetro `--auth-token` como el nuevo token y `--auth-token-update-strategy` con el valor ROTATE.
Tras finalizar la modificación de ROTATE, el clúster admite el token de **AUTH** especificado en el parámetro `--auth-token` además de la conexión sin autenticación. Una vez que todas las aplicaciones cliente estén actualizadas para autenticarse en Valkey o Redis OSS con el token de AUTH, utilice la estrategia SET para marcar el token de AUTH como obligatorio. La habilitación de la autenticación solo se admite en servidores de Valkey y Redis OSS con el cifrado en tránsito (TLS) habilitado.
## Migración de RBAC a AUTH
Si está autenticando usuarios con el control de acceso basado en roles (RBAC) de Valkey o Redis OSS, tal y como se describe en [Control de acceso basado en roles (RBAC)](Clusters.RBAC.md), y desea migrar a AUTH, utilice los siguientes procedimientos. Puede migrar mediante la consola o la CLI.
**Migración desde RBAC a AUTH mediante la consola**
1. Inicie sesión en Consola de administración de AWS y abra la ElastiCache consola en. [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. En la lista de la esquina superior derecha, elija la AWS región en la que se encuentra el clúster que desea modificar.
1. En el panel de navegación, elija el motor que se ejecuta en el clúster que desea modificar.
Se mostrará una lista de los clústeres del motor elegido.
1. En la lista de clústeres, para el clúster que desea modificar, elija su nombre.
1. Para **Actions (Acciones)**, elija **Modify (Modificar)**.
Aparecerá la ventana **Modificar**.
1. En **Control de acceso**, elija **Acceso de usuario predeterminado de AUTH de Valkey** o **Acceso de usuario predeterminado de AUTH de Redis OSS**.
1. En **Token de AUTH de Valkey** o **Token de AUTH de Redis OSS**, defina un nuevo token.
1. Seleccione **Vista previa de los cambios** y seleccione **Modificar** en la siguiente pantalla.
**Para migrar de RBAC a AUTH mediante el AWS CLI**
Utilice uno de los siguientes comandos para configurar un nuevo token de **AUTH** opcional para su grupo de replicación de Valkey o Redis OSS. Tenga en cuenta que un token de autenticación opcional permitirá el acceso no autenticado al grupo de replicación hasta que el token de autenticación se marque como obligatorio, de acuerdo con la estrategia de actualización `SET` que se describe en el siguiente paso.
Para Linux, macOS o 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
```
Para 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
```
Tras ejecutar el comando anterior, puede actualizar sus aplicaciones OSS de Valkey o Redis para que se autentiquen en el grupo de ElastiCache replicación mediante el token AUTH opcional recién configurado. Para completar la rotación del token de autenticación, utilice la estrategia de actualización `SET` en el siguiente comando. De esta forma, el token de AUTH opcional se marcará como obligatorio. Cuando se complete la actualización del token de autenticación, el estado del grupo de replicación aparecerá como `ACTIVE` y todas las conexiones a este grupo de replicación requerirán autenticación.
Para Linux, macOS o Unix:
```
aws elasticache modify-replication-group \
--replication-group-id test \
--auth-token This-is-a-sample-token \
--auth-token-update-strategy SET \
--apply-immediately
```
Para 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
```
Para obtener más información, consulte [Autenticación con el comando AUTH de Valkey o Redis OSS](#auth).
**nota**
Si necesita deshabilitar el control de acceso en un ElastiCache clúster, consulte. [Deshabilitación del control de acceso en una caché de ElastiCache Valkey o Redis OSS](in-transit-encryption-disable.md)
# Deshabilitación del control de acceso en una caché de ElastiCache Valkey o Redis OSS
Siga las instrucciones que se indican a continuación para deshabilitar el control de acceso en una caché de Valkey o Redis OSS habilitada para TLS. Su caché tendrá uno de los siguientes dos tipos de configuraciones: acceso de usuario predeterminado de AUTH o lista de control de acceso de grupos de usuarios (RBAC). Si la caché se creó con la configuración AUTH, debe cambiarla a la configuración RBAC antes de poder deshabilitar la caché mediante la eliminación de los grupos de usuarios. Si la caché se creó con la configuración RBAC, puede proceder directamente a deshabilitarla.
**Deshabilitación de una caché sin servidor de Valkey o Redis OSS configurada con RBAC**
1. Elimine los grupos de usuarios para deshabilitar el control de acceso.
```
aws elasticache modify-serverless-cache --serverless-cache-name --remove-user-group
```
1. (Opcional) Compruebe que no haya ningún grupo de usuarios asociado a la caché sin servidor.
```
aws elasticache describe-serverless-caches --serverless-cache-name
{
"..."
"UserGroupId": ""
"..."
}
```
**Deshabilitación de una caché de Valkey o Redis OSS configurada con un token de AUTH**
1. Cambie el token AUTH a RBAC y especifique un grupo de usuarios que agregar.
```
aws elasticache modify-replication-group --replication-group-id --auth-token-update-strategy DELETE --user-group-ids-to-add
```
1. Compruebe que el token AUTH se haya desactivado y que se haya agregado un grupo de usuarios.
```
aws elasticache describe-replication-groups --replication-group-id
{
"..."
"AuthTokenEnabled": false,
"UserGroupIds": [
""
]
"..."
}
```
1. Elimine los grupos de usuarios para deshabilitar el control de acceso.
```
aws elasticache modify-replication-group --replication-group-id --user-group-ids-to-remove
{
"..."
"PendingModifiedValues": {
"UserGroups": {
"UserGroupIdsToAdd": [],
"UserGroupIdsToRemove": [
""
]
}
"..."
}
```
1. (Opcional) Compruebe que no haya ningún grupo de usuarios asociado al clúster. Además, el campo `AuthTokenEnabled` debe decir false.
```
aws elasticache describe-replication-groups --replication-group-id
"AuthTokenEnabled": false
```
**Deshabilitación de un clúster de Valkey o Redis OSS configurado con RBAC**
1. Elimine los grupos de usuarios para deshabilitar el control de acceso.
```
aws elasticache modify-replication-group --replication-group-id --user-group-ids-to-remove
{
"..."
"PendingModifiedValues": {
"UserGroups": {
"UserGroupIdsToAdd": [],
"UserGroupIdsToRemove": [
""
]
}
"..."
}
```
1. (Opcional) Compruebe que no haya ningún grupo de usuarios asociado al clúster. Además, el campo `AuthTokenEnabled` debe decir false.
```
aws elasticache describe-replication-groups --replication-group-id
"AuthTokenEnabled": false
```