Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Sicurezza dei dati in Amazon ElastiCache
Per aiutarti a proteggere i tuoi dati, Amazon ElastiCache e Amazon EC2 forniscono meccanismi di protezione contro l'accesso non autorizzato ai tuoi dati sul server.
Amazon ElastiCache for Memcached fornisce funzionalità di crittografia per i dati nelle cache che eseguono le versioni 1.6.12 o successive di Memcached.
Amazon ElastiCache con Valkey e Redis OSS offre funzionalità di crittografia per i dati nelle cache che eseguono Valkey 7.2 o versioni successive e le versioni Redis OSS 3.2.6 (pianificata per EOL, consulta la pianificazione di [fine vita delle versioni Redis OSS), 4.0.10 o successive](engine-versions.md#deprecated-engine-versions). Amazon supporta ElastiCache anche l'autenticazione degli utenti con IAM o Valkey e Redis OSS AUTH e l'autorizzazione delle operazioni degli utenti tramite Role-Based Access Control (RBAC).
+ La crittografia dei dati in transito viene eseguita quando i dati si spostano da una posizione a un'altra, ad esempio tra i nodi del cluster o tra la cache e l'applicazione.
+ La crittografia dei dati inattivi esegue la crittografia su disco dei dati durante operazioni di sincronizzazione e backup.
ElastiCache supporta l'autenticazione degli utenti tramite IAM e il comando Valkey e Redis OSS AUTH e l'autorizzazione delle operazioni degli utenti tramite Role-Based Access Control (RBAC).
![\[Immagine: ElastiCache per Valkey e Redis OSS Security Diagram\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/images/ElastiCache-Redis-Secure-Compliant.png)
*ElastiCache per Valkey e Redis OSS Security Diagram*
**Topics**
+ [ElastiCache crittografia in transito (TLS)](in-transit-encryption.md)
+ [Crittografia At-Rest in ElastiCache](at-rest-encryption.md)
+ [Autenticazione e autorizzazione](auth-redis.md)
# ElastiCache crittografia in transito (TLS)
Per aiutarti a proteggere i tuoi dati, Amazon ElastiCache e Amazon EC2 forniscono meccanismi di protezione contro l'accesso non autorizzato ai tuoi dati sul server. Fornendo funzionalità di crittografia in transito, ti ElastiCache offre uno strumento che puoi utilizzare per proteggere i tuoi dati quando vengono spostati da una posizione all'altra.
Tutte le cache serverless Valkey o Redis OSS hanno la crittografia in transito abilitata. Per i cluster basati su nodi, è possibile abilitare la crittografia in transito su un gruppo di replica impostando il parametro su `TransitEncryptionEnabled` (`true`CLI:`--transit-encryption-enabled`) quando si crea il gruppo di replica. È possibile eseguire questa operazione indipendentemente dal fatto che si stia creando il gruppo di replica utilizzando l', l'o l'API.Console di gestione AWSAWS CLI ElastiCache
Tutte le cache serverless dispongono della crittografia dei dati in transito abilitata. Per i cluster basati su nodi, è possibile abilitare la crittografia in transito su un cluster impostando il parametro su `TransitEncryptionEnabled` (`true`CLI:`--transit-encryption-enabled`) quando si crea il cluster utilizzando l'operazione (`CreateCacheCluster`CLI:). `create-cache-cluster`
**Topics**
+ [Panoramica della crittografia dei dati in transito](#in-transit-encryption-overview)
+ [Condizioni di crittografia in transito (Valkey e Redis OSS)](#in-transit-encryption-constraints)
+ [Condizioni di crittografia in transito (Memcached)](#in-transit-encryption-constraints)
+ [Best practice per la crittografia in transito](#in-transit-encryption-best-practices)
+ [Altre opzioni Valkey e Redis OSS](#in-transit-encryption-see-also)
+ [Abilitazione della crittografia in transito per Memcached](#in-transit-encryption-enable-existing-mc)
+ [Abilitazione della crittografia dei dati in transito](in-transit-encryption-enable.md)
+ [Connessione a ElastiCache (Valkey) o Amazon ElastiCache for Redis OSS con crittografia in transito tramite valkey-cli](connect-tls.md)
+ [Abilitazione della crittografia in transito su un cluster Redis OSS basato su nodi utilizzando Python](in-transit-encryption-enable-python.md)
+ [Best practice per abilitare la crittografia dei dati in transito](enable-python-best-practices.md)
+ [Connessione a nodi abilitati con crittografia in transito tramite Openssl (Memcached)](#in-transit-encryption-connect-mc)
+ [Creazione di un client TLS Memcached utilizzando Java](#in-transit-encryption-connect-java)
+ [Creazione di un client TLS Memcached utilizzando PHP](#in-transit-encryption-connect-php-mc)
## Panoramica della crittografia dei dati in transito
La crittografia ElastiCache in transito di Amazon è una funzionalità che consente di aumentare la sicurezza dei dati nei punti più vulnerabili, quando sono in transito da una posizione all'altra. Poiché la crittografia e la decrittografia dei dati richiede l'elaborazione a livello di endpoint, l'abilitazione della crittografia dei dati in transito può in parte influire sulle prestazioni. È opportuno creare un riferimento per i dati con o senza crittografia dei dati in transito per determinare l'impatto sulle prestazioni per i propri casi d'uso.
ElastiCache la crittografia in transito implementa le seguenti funzionalità:
+ **Connessioni client crittografate**: le connessioni client ai nodi di cache sono crittografate con TLS.
+ **Connessioni server crittografate**: i dati che si spostano tra i nodi di un cluster sono crittografati.
+ **Autenticazione del server**: i client possono autenticare che si stanno connettendo al server giusto.
+ **Autenticazione client**: utilizzando le funzionalità Valkey e Redis OSS AUTH, il server può autenticare i client.
## Condizioni di crittografia in transito (Valkey e Redis OSS)
I seguenti vincoli sulla crittografia ElastiCache in transito di Amazon devono essere tenuti presenti quando pianifichi l'implementazione del cluster basato su nodi:
+ La crittografia in transito è supportata sui gruppi di replica che eseguono Valkey 7.2 e versioni successive e le versioni Redis OSS 3.2.6, 4.0.10 e successive.
+ La modifica dell'impostazione di crittografia in transito, per un cluster esistente, è supportata nei gruppi di replica che eseguono Valkey 7.2 e versioni successive e Redis OSS versione 7 e successive.
+ La crittografia dei dati in transito è supportata solo per gruppi di replica in esecuzione in un Amazon VPC.
+ La crittografia in transito non è supportata per i gruppi di replica che eseguono i seguenti tipi di nodi: M1, M2.
Per ulteriori informazioni, consulta [Tipi di nodi supportati](CacheNodes.SupportedTypes.md).
+ La crittografia dei dati in transito è abilitata impostando in maniera esplicata il parametro `TransitEncryptionEnabled` su `true`.
+ Assicurati che il client di cache supporti la connettività TLS e che sia abilitata nella configurazione del client.
+ A partire dal 26 gennaio 2026,AWS aggiornerà la versione TLS minima supportata alla 1.2 ElastiCache per Valkey versione 7.2 e successive e per Redis OSS versione 6 e ElastiCache successive. I clienti devono aggiornare il software client prima di tale data. Questo aggiornamento consente di soddisfare le esigenze di sicurezza, conformità e normative.
## Condizioni di crittografia in transito (Memcached)
I seguenti vincoli sulla crittografia ElastiCache in transito di Amazon devono essere tenuti presenti quando pianifichi l'implementazione del cluster basato su nodi:
+ La crittografia in transito è supportata su cluster che eseguono Memcached versione 1.6.12 e successive.
+ La crittografia dei dati in transito supporta Transport Layer Security (TLS) versioni 1.2 e 1.3.
+ La crittografia in transito è supportata solo per cluster in esecuzione in un VPC Amazon.
+ La crittografia in transito non è supportata per i gruppi di replica che eseguono i seguenti tipi di nodi: M1, M2, M3, R3, T2.
Per ulteriori informazioni, consulta [Tipi di nodi supportati](CacheNodes.SupportedTypes.md).
+ La crittografia dei dati in transito è abilitata impostando in maniera esplicata il parametro `TransitEncryptionEnabled` su `true`.
+ Puoi abilitare la crittografia in transito su un cluster solo durante la creazione del cluster. Non puoi attivare o disattivare la crittografia in transito modificando un cluster.
+ Assicurati che il client di cache supporti la connettività TLS e che sia abilitata nella configurazione del client.
## Best practice per la crittografia in transito
+ A causa dell'elaborazione richiesta per crittografare e decrittografare i dati a livello degli endpoint, l'implementazione della crittografia dei dati in transito può ridurre le prestazioni. Raffronta la crittografia dei dati in transito con l'assenza di crittografia sui dati per determinare il suo impatto sulle prestazioni per l'implementazione.
+ Siccome la creazione di nuove connessioni può richiedere molte risorse, puoi ridurre l'impatto della crittografia in transito sulle prestazioni mantenendo le connessioni SSL.
## Altre opzioni Valkey e Redis OSS
Per ulteriori informazioni sulle opzioni disponibili per Valkey e Redis OSS, consulta i seguenti link.
+ [Crittografia At-Rest in ElastiCache](at-rest-encryption.md)
+ [Autenticazione con il comando Valkey e Redis OSS AUTH](auth.md)
+ [Controllo accessi basato sui ruoli (RBAC)](Clusters.RBAC.md)
+ [Amazon VPCs e la ElastiCache sicurezza](VPCs.md)
+ [Identity and Access Management per Amazon ElastiCache](IAM.md)
## Abilitazione della crittografia in transito per Memcached
Per abilitare la crittografia in transito creando un cluster Memcached tramite AWS Management Console, effettua le selezioni seguenti:
+ Scegli Memcached come motore.
+ Scegli la versione del motore 1.6.12 o successiva.
+ In **Encryption in transit** (Crittografia in transito), scegli **Enable** (Abilita).
Per il step-by-step processo, vedi. [Creazione di un cluster per Valkey o Redis OSS](Clusters.Create.md)
# Abilitazione della crittografia dei dati in transito
Tutte le cache serverless dispongono della crittografia dei dati in transito abilitata. In un cluster basato su nodi, puoi abilitare la crittografia in transito utilizzando, la Console di gestione AWSAWS CLI o l'API. ElastiCache
## Abilitazione della crittografia in transito utilizzando Console di gestione AWS
### Abilitazione della crittografia in transito per un nuovo cluster basato su nodi utilizzando Console di gestione AWS
Quando si progetta il proprio cluster, le configurazioni "Sviluppo/Test" e "Produzione" con il metodo "Crea semplice" hanno la crittografia dei dati in transito abilitata. Quando scegli la configurazione, procedi come segue:
+ Scegli la versione motore 3.2.6, 4.0.10 o successiva.
+ Fai clic sulla casella di controllo **Abilita** accanto all'opzione **Crittografia dei dati in transito**.
Per il step-by-step processo, consulta quanto segue:
+ [Creazione di un cluster Valkey (modalità cluster disabilitata) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ [Creazione di un cluster Valkey o Redis OSS (modalità cluster abilitata) (Console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
### Abilitazione della crittografia in transito per un cluster esistente basato su nodi utilizzando il Console di gestione AWS
L'abilitazione della crittografia dei dati in transito è un processo in due fasi; imposta innanzitutto la modalità di crittografia dei dati in transito su `preferred`. Questa modalità consente ai client Valkey o Redis OSS di connettersi utilizzando connessioni crittografate e non crittografate. Dopo aver migrato tutti i client Valkey o Redis OSS per utilizzare connessioni crittografate, è possibile modificare la configurazione del cluster per impostare la modalità di crittografia di transito su. `required` L'impostazione della modalità di crittografia dei dati in transito su `required` rimuoverà tutte le connessioni non crittografate e consentirà solo le connessioni crittografate.
****Imposta la modalità di **crittografia Transit** su Preferred****
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Scegli le **cache Valkey o le** **cache Redis OSS** dalle ElastiCache **Risorse** elencate nel pannello di navigazione, presente a sinistra.
1. Scegli la cache che desideri aggiornare.
1. Scegli il menu a discesa **Actions** (Azioni), quindi **Modify** (Modifica).
1. Scegli **Enable** (Abilita) in **Encryption in transit** (Crittografia dei dati in transito) nella sezione **Security** (Sicurezza).
1. Scegli **Preferred** (Preferito) come **Transit encryption mode** (Modalità di crittografia dei dati in transito).
1. Scegli **Preview changes** (Anteprima modifiche) e salva le modifiche.
Dopo aver migrato tutti i client Valkey o Redis OSS per utilizzare connessioni crittografate:
****Imposta la modalità di **crittografia Transit** su Obbligatoria****
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Scegli le **cache Valkey o le** **cache Redis OSS** dalle ElastiCache **Risorse** elencate nel pannello di navigazione, presente a sinistra.
1. Scegli la cache che desideri aggiornare.
1. Scegli il menu a discesa **Actions** (Azioni), quindi **Modify** (Modifica).
1. Scegli **Required** (Richiesto) come **Transit encryption mode** (Modalità di crittografia dei dati in transito), nella sezione **Security** (Sicurezza).
1. Scegli **Preview changes** (Anteprima modifiche) e salva le modifiche.
## Abilitazione della crittografia in transito utilizzando il AWS CLI
Per abilitare la crittografia in transito durante la creazione di un gruppo di replica Valkey o Redis OSS utilizzando il, utilizzare il AWS CLI parametro. `transit-encryption-enabled`
### Abilitazione della crittografia in transito su un nuovo cluster basato su nodi per Valkey o Redis OSS (Cluster Mode Disabled) (CLI)
Utilizzate l'AWS CLI operazione `create-replication-group` e i seguenti parametri per creare un gruppo di replica Valkey o Redis OSS con repliche con crittografia in transito abilitata:
**Parametri chiave:**
+ **--engine**—Deve essere o. `valkey` `redis`
+ **--engine-version**—Se il motore è Redis OSS, deve essere 3.2.6, 4.0.10 o successivo.
+ **--transit-encryption-enabled**: obbligatorio. Se abiliti la crittografia dei dati in transito, devi anche fornire un valore per il parametro `--cache-subnet-group`.
+ **--num-cache-clusters**-deve essere almeno 1. Il valore massimo per questo parametro è sei.
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Disabled) ()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)
### Abilitazione della crittografia in transito su un nuovo cluster basato su nodi per Valkey o Redis OSS (Cluster Mode Enabled) (CLI)
Utilizzate l'AWS CLI operazione `create-replication-group` e i seguenti parametri per creare un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) con crittografia in transito abilitata:
**Parametri chiave:**
+ **--engine**—Deve essere o. `valkey` `redis`
+ **--engine-version**—Se il motore è Redis OSS, deve essere 3.2.6, 4.0.10 o successivo.
+ **--transit-encryption-enabled**: obbligatorio. Se abiliti la crittografia dei dati in transito, devi anche fornire un valore per il parametro `--cache-subnet-group`.
+ Utilizza uno dei seguenti set di parametri per specificare la configurazione dei gruppi di nodi del gruppo di replica:
+ **--num-node-groups**-specifica il numero di partizioni ( gruppi di nodi ) in questo gruppo di replica. Il valore massimo di questo parametro è 500.
**--replicas-per-node-group**–specifica il numero di nodi di replica in ogni gruppo di nodi. Il valore specificato qui viene applicato a tutti le partizioni in questo gruppo di replica. Il valore massimo di questo parametro è 5.
+ **--node-group-configuration**- Specifica la configurazione di ogni partizione in modo indipendente.
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Enabled) ()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)
### Abilitazione della crittografia dei dati in transito per un cluster esistente mediante la AWS CLI
L'abilitazione della crittografia dei dati in transito è un processo in due fasi; imposta innanzitutto la modalità di crittografia dei dati in transito su `preferred`. Questa modalità consente ai client Valkey o Redis OSS di connettersi utilizzando connessioni crittografate e non crittografate. Dopo aver migrato tutti i client Valkey o Redis OSS per utilizzare connessioni crittografate, è possibile modificare la configurazione del cluster per impostare la modalità di crittografia di transito su. `required` L'impostazione della modalità di crittografia dei dati in transito su `required` rimuoverà tutte le connessioni non crittografate e consentirà solo le connessioni crittografate.
Utilizzate l'AWS CLI operazione `modify-replication-group` e i seguenti parametri per aggiornare un gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) con la crittografia in transito disabilitata.
**Per abilitare la crittografia dei dati in transito**
1. Impostato su`preferred`, transit-encryption-mode utilizzando i seguenti parametri
+ **--transit-encryption-enabled**: obbligatorio.
+ **--transit-encryption-mode** – Deve essere impostato su `preferred`.
1. transit-encryption-modeImpostare su`required`, utilizzando i seguenti parametri:
+ **--transit-encryption-enabled**: obbligatorio.
+ **--transit-encryption-mode** – Deve essere impostato su `required`.
# Connessione a ElastiCache (Valkey) o Amazon ElastiCache for Redis OSS con crittografia in transito tramite valkey-cli
Per accedere ai dati dalle ElastiCache cache Redis OSS abilitate con crittografia in transito, si utilizzano client che funzionano con Secure Socket Layer (SSL). Puoi anche usare valkey-cli con Amazon Linux e TLS/SSL Amazon Linux 2. Se il client non supporta TLS, è possibile utilizzare il `stunnel` comando sull'host client per creare un tunnel SSL verso i nodi Redis OSS.
## Connessione crittografata con Linux
Per utilizzare valkey-cli per connettersi a un cluster Valkey o Redis OSS abilitato con crittografia in transito su Amazon Linux 2 o Amazon Linux, segui questi passaggi.
1. Scarica e compila l'utilità valkey-cli. Questa utilità è inclusa nella distribuzione del software Valkey.
1. Al prompt dei comandi dell' EC2 istanza, digita i comandi appropriati per la versione di Linux che stai utilizzando.
**Amazon Linux 2**
Se usi Amazon Linux 2, inserisci questo:
```
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**
Se usi Amazon Linux, inserisci questo:
```
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/
```
Su Amazon Linux, potrebbe essere necessario eseguire anche i seguenti passaggi aggiuntivi:
```
sudo yum install clang
CC=clang make
sudo make install
```
1. Dopo aver scaricato e installato l'utilità valkey-cli, si consiglia di eseguire il comando opzionale. `make-test`
1. Per connetterti a un cluster con crittografia e autenticazione abilitate, inserisci questo comando:
```
valkey-cli -h Primary or Configuration Endpoint --tls -a 'your-password' -p 6379
```
**Nota**
Se installi redis6 su Amazon Linux 2023, ora puoi usare `redis6-cli` il comando al posto di: `valkey-cli`
```
redis6-cli -h Primary or Configuration Endpoint --tls -p 6379
```
## Connessione crittografata con stunnel
Per utilizzare valkey-cli per connettersi a un cluster Redis OSS abilitato alla crittografia in transito tramite stunnel, segui questi passaggi.
1. Utilizza SSH per connettersi al client e installare `stunnel`.
```
sudo yum install stunnel
```
1. Esegui il comando seguente per creare e modificare il file `'/etc/stunnel/valkey-cli.conf'` contemporaneamente ElastiCache per aggiungere un endpoint del cluster Redis OSS a uno o più parametri di connessione, utilizzando l'output fornito di seguito come modello.
```
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
```
In questo esempio, il file di configurazione dispone di due connessioni, `valkey-cli` e `valkey-cli-replica`. I parametri sono impostati come riportato di seguito:
+ **client** è impostato su yes per specificare che questa istanza stunnel è un client.
+ **accept** è impostato sull'IP client. In questo esempio, il primario è impostato sull'impostazione predefinita di Redis OSS 127.0.0.1 sulla porta 6379. La replica deve chiamare una porta diversa e impostarla su 6380. Puoi usare porte effimere 1024–65535. Per ulteriori informazioni, consulta[Porte Effimere](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports)nella*guida per l'utente Amazon VPC.*
+ **connect** è impostato sull'endpoint del server Redis OSS. Per ulteriori informazioni, consulta [Ricerca degli endpoint di connessione in ElastiCache](Endpoints.md).
1. Avvia `stunnel`.
```
sudo stunnel /etc/stunnel/valkey-cli.conf
```
Utilizza il comando `netstat` per confermare che i tunnel sono stati avviati.
```
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. Connect al nodo Redis OSS crittografato utilizzando l'endpoint locale del tunnel.
+ Se non è stata utilizzata alcuna password AUTH durante la ElastiCache creazione del cluster Redis OSS, questo esempio utilizza valkey-cli per connettersi al server ElastiCache per Redis OSS utilizzando il percorso completo per valkey-cli, su Amazon Linux:
```
/home/ec2-user/redis-7.2.5/src/valkey-cli -h localhost -p 6379
```
Se la password AUTH è stata utilizzata durante la creazione del cluster Redis OSS, questo esempio utilizza valkey-cli per connettersi al server Redis OSS utilizzando il percorso completo per valkey-cli, su Amazon Linux:
```
/home/ec2-user/redis-7.2.5/src/valkey-cli -h localhost -p 6379 -a my-secret-password
```
O
+ Cambia la directory in redis-7.2.5 e procedi come segue:
Se non è stata utilizzata alcuna password AUTH durante la ElastiCache creazione del cluster Redis OSS, questo esempio utilizza valkey-cli per connettersi al server ElastiCache per Redis OSS utilizzando il percorso completo per valkey-cli, su Amazon Linux:
```
src/valkey-cli -h localhost -p 6379
```
Se la password AUTH è stata utilizzata durante la creazione del cluster Redis OSS, questo esempio utilizza valkey-cli per connettersi al server Valkey o Redis OSS utilizzando il percorso completo per valkey-cli, su Amazon Linux:
```
src/valkey-cli -h localhost -p 6379 -a my-secret-password
```
Questo esempio utilizza Telnet per connettersi al server Valkey Redis OSS.
```
telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
auth MySecretPassword
+OK
get foo
$3
bar
```
1. Per interrompere e chiudere i tunnel SSL, esegui il `pkill` del processo stunnel.
```
sudo pkill stunnel
```
# Abilitazione della crittografia in transito su un cluster Redis OSS basato su nodi utilizzando Python
La seguente guida mostrerà come abilitare la crittografia in transito su un cluster Redis OSS 7.0 originariamente creato con la crittografia in transito disabilitata. I client TCP e TLS continueranno a comunicare con il cluster durante questo processo senza tempi di inattività.
Boto3 otterrà le credenziali necessarie (`aws_access_key_id`, `aws_secret_access_key` e `aws_session_token`) dalle variabili di ambiente. Tali credenziali verranno incollate in anticipo nello stesso terminale bash in cui verrà eseguito `python3` per elaborare il codice Python mostrato in questa guida. Il codice nell'esempio seguente è stato elaborato da un' EC2 istanza lanciata nello stesso VPC che verrà utilizzato per creare il cluster ElastiCache Redis OSS al suo interno.
**Nota**
Gli esempi seguenti utilizzano l'SDK boto3 per le operazioni di ElastiCache gestione (creazione di cluster o utenti) e redis-py/ per la gestione dei dati. redis-py-cluster
È necessario utilizzare almeno la versione boto3 (=\$1) 1.26.39 per utilizzare la migrazione TLS online con l'API di modifica del cluster.
ElastiCache supporta la migrazione TLS online solo per i cluster con Valkey versione 7.2 e successive o Redis OSS versione 7.0 o successiva. Quindi, se hai un cluster che esegue una versione Redis OSS precedente alla 7.0, dovrai aggiornare la versione Redis OSS del tuo cluster. Per ulteriori informazioni sulle differenze di versione, consultare [Principali differenze di comportamento e compatibilità della versione del motore con Redis OSS](VersionManagementConsiderations.md).
**Topics**
+ [Definite le costanti di stringa che avvieranno il cluster ElastiCache Valkey o Redis OSS](#enable-python-define-constants)
+ [Definizione delle classi per la configurazione del cluster](#enable-python-define-classes)
+ [Definizione di una classe che rappresenterà il cluster stesso](#enable-python-define-classes-cluster)
+ [(Facoltativo) Crea una classe wrapper per la connessione del client dimostrativo al cluster Valkey o Redis OSS](#enable-python-create-wrapper)
+ [Creazione della funzione principale che illustra il processo di modifica della configurazione della crittografia dei dati in transito](#enable-python-main-function)
## Definite le costanti di stringa che avvieranno il cluster ElastiCache Valkey o Redis OSS
Per prima cosa, definiamo alcune semplici costanti di stringa Python che conterranno i nomi delle AWS entità necessarie per creare il ElastiCache cluster come `security-group``Cache Subnet group`, e a. `default parameter group` Tutte queste AWS entità devono essere create in anticipo nel tuo AWS account nella regione che intendi utilizzare.
```
#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"
```
## Definizione delle classi per la configurazione del cluster
Ora, definiamo alcune semplici classi Python che rappresenteranno una configurazione di un cluster, che conterranno i metadati sul cluster come la versione Valkey o Redis OSS, il tipo di istanza e se la crittografia in transito (TLS) è abilitata o disabilitata.
```
#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
```
## Definizione di una classe che rappresenterà il cluster stesso
Ora, definiamo alcune semplici classi Python che rappresenteranno lo stesso ElastiCache Valkey o Redis OSS Cluster. Questa classe avrà un campo client che conterrà un client boto3 per operazioni di ElastiCache gestione come la creazione del cluster e l'interrogazione dell'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()
```
## (Facoltativo) Crea una classe wrapper per la connessione del client dimostrativo al cluster Valkey o Redis OSS
Ora, creiamo una classe wrapper per il client `redis-py-cluster`. Questa classe wrapper supporta la precompilazione del cluster con alcune chiavi e l'esecuzione di comandi `get` ripetuti in modo casuale.
**Nota**
Questo è un passaggio facoltativo ma semplifica il codice della funzione principale che verrà fornito in un passaggio successivo.
```
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()
```
## Creazione della funzione principale che illustra il processo di modifica della configurazione della crittografia dei dati in transito
Ora, definiamo la funzione principale, che eseguirà le operazioni seguenti:
1. Crea il cluster utilizzando il client boto3. ElastiCache
1. Inizializzare il client `redis-py-cluster` che si connetterà al cluster con una connessione TCP chiara senza TLS.
1. Il client `redis-py-cluster` precompila il cluster con alcuni dati.
1. Il client boto3 attiverà la migrazione TLS da no-TLS a TLS preferred.
1. Durante la migrazione del cluster a TLS `Preferred`, il client TCP `redis-py-cluster` invierà operazioni `get` ripetute al cluster finché la migrazione non è terminata.
1. Al termine della migrazione a TLS `Preferred`, affermeremo che il cluster supporta la crittografia dei dati in transito. Successivamente, creeremo un client `redis-py-cluster` che si connetterà al cluster con TLS.
1. Invieremo alcuni comandi `get` utilizzando il nuovo client TLS e il vecchio client TCP.
1. Il client boto3 attiverà la migrazione TLS da TLS `Preferred` a TLS required.
1. Durante la migrazione del cluster a TLS richiesto, il client redis-py-cluster TLS invierà `get` operazioni ripetute al cluster fino al termine della migrazione.
```
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)
```
# Best practice per abilitare la crittografia dei dati in transito
## Prima di abilitare la crittografia dei dati in transito: accertarsi di disporre della gestione dei record DNS corretta
**Nota**
Stiamo modificando ed eliminando i vecchi endpoint durante questo processo. L'uso errato degli endpoint può far sì che il client Valkey o Redis OSS utilizzi endpoint vecchi ed eliminati che gli impediranno la connessione al cluster.
Durante la migrazione del cluster da No-TLS a TLS-Preferred, il vecchio record DNS dell'endpoint di configurazione del cluster viene mantenuto e i nuovi record DNS dell'endpoint di configurazione del cluster vengono generati in un formato diverso. I cluster abilitati per TLS utilizzano un formato di record DNS diverso rispetto ai cluster con funzionalità TLS. ElastiCache conserverà entrambi i record DNS quando un cluster è configurato in `encryption mode: Preferred` modo che Applications e altri client Valkey o Redis OSS possano passare da uno all'altro. Le seguenti modifiche nei record DNS vengono apportate durante il processo di migrazione TLS:
### Descrizione delle modifiche nei record DNS che vengono eseguite quando si abilita la crittografia dei dati in transito
**Per i cluster CME**
Quando un cluster è impostato sulla ‘modalità di crittografia dei dati in transito: preferred’:
+ L'endpoint di configurazione del cluster originale per il cluster No-TLS rimarrà attivo. Non ci saranno tempi di inattività quando il cluster viene riconfigurato dalla modalità di crittografia TLS ‘none’ a ‘preferred’.
+ I nuovi endpoint TLS Valkey o Redis OSS verranno generati quando il cluster è impostato sulla modalità TLS Preferred. Questi nuovi endpoint verranno risolti come quelli precedenti (non IPs TLS).
+ Il nuovo endpoint di configurazione TLS Valkey o Redis OSS verrà esposto nella ElastiCache console e nella risposta all'API. `describe-replication-group`
Quando un cluster è impostato sulla ‘modalità di crittografia dei dati in transito: required’:
+ I vecchi endpoint non abilitati per TLS verranno eliminati. Non ci saranno tempi di inattività degli endpoint del cluster TLS.
+ Puoi recuperarne uno nuovo `cluster-configuration-endpoint` dalla ElastiCache console o dall'API. `describe-replication-group`
**Per i cluster CMD con failover automatico abilitato o failover automatico disabilitato**
Quando il gruppo di replica è impostato sulla ‘modalità di crittografia dei dati in transito: preferred’:
+ L'endpoint primario e l'endpoint di lettura originali per i cluster non abilitati per TLS rimarranno attivi.
+ I nuovi endpoint primari e di lettura TLS verranno generati quando il cluster è impostato sulla modalità TLS `Preferred`. Questo nuovo endpoint verrà risolto nello stesso IP di quelli vecchi (non-TLS).
+ Il nuovo endpoint primario e l'endpoint di lettura verranno esposti nella ElastiCache Console e nella risposta all'API. `describe-replication-group`
Quando il gruppo di replica è impostato sulla ‘modalità di crittografia dei dati in transito: required’:
+ I vecchi endpoint primari e di lettura non TLS verranno eliminati. Non ci saranno tempi di inattività degli endpoint del cluster TLS.
+ Puoi recuperare nuovi endpoint primari e di lettura dalla ElastiCache Console o dall'API. `describe-replication-group`
### L'utilizzo suggerito dei record DNS
**Per i cluster CME **
+ Utilizza l'endpoint di configurazione del cluster anziché i record DNS per nodo nel codice dell'applicazione. L'uso diretto di nomi DNS per nodo non è consigliato perché durante la migrazione cambieranno e il codice dell'applicazione interromperà la connessione al cluster.
+ Non codificate un endpoint di configurazione del cluster nell'applicazione, poiché durante questo processo cambierà.
+ La codifica dell'endpoint di configurazione del cluster nell'applicazione è una pratica scorretta, in quanto può essere modificato durante questo processo. Una volta completata la crittografia in transito, interroga l'endpoint di configurazione del cluster con l'`describe-replication-group`API (come illustrato sopra (in grassetto)) e utilizza il DNS che ottieni in risposta da quel momento in poi.
**Per cluster CMD con failover automatico abilitato**
+ Utilizza l'endpoint primario e l'endpoint di lettura anziché i nomi DNS per nodo nel codice dell'applicazione poiché i vecchi nomi DNS per nodo vengono eliminati e nuovi vengono generati durante la migrazione del cluster da no-TLS a TLS-preferred. L'utilizzo diretto dei nomi DNS per nodo non è consigliato perché è possibile che vengano aggiunte repliche al cluster in futuro. Inoltre, quando il failover automatico è abilitato, i ruoli del cluster principale e delle repliche vengono modificati automaticamente dal ElastiCache servizio. Si consiglia di utilizzare l'endpoint primario e l'endpoint di lettura per tenere traccia di tali modifiche. Infine, l'utilizzo dell'endpoint di lettura consente di distribuire le letture dalle repliche equamente tra le repliche nel cluster.
+ Avere l'endpoint primario e l'endpoint di lettura codificati nell'applicazione è una bad practice poiché possono essere modificati durante il processo di migrazione TLS. Una volta completata la migrazione a TLS-Preferred, interroga l'endpoint primario e l'endpoint di lettura con l' describe-replication-groupAPI e utilizza il DNS che ottieni in risposta da questo momento in poi. In questo modo sarai in grado di tenere traccia delle modifiche negli endpoint in modo dinamico.
**Per cluster CMD con failover automatico disabilitato **
+ Usa l'endpoint primario e l'endpoint di lettura anziché i nomi DNS per nodo nel codice dell'applicazione. Quando il failover automatico è disabilitato, il ridimensionamento, l'applicazione di patch, il failover e altre procedure gestite automaticamente dal ElastiCache servizio quando il failover automatico è abilitato, vengono invece eseguite dall'utente. Ciò consente di tenere traccia dei diversi endpoint manualmente. Poiché i vecchi nomi DNS per nodo vengono eliminati e nuovi vengono generati durante la migrazione del cluster da no-TLS a TLS-preferred, non utilizzare direttamente i nomi DNS per nodo. Questo è obbligatorio per consentire ai client di connettersi al cluster durante la migrazione TLS. Inoltre, è possibile distribuire uniformemente le letture tra le repliche quando si utilizza l'endpoint di lettura e tenere traccia dei record DNS quando si aggiungono o si eliminano repliche dal cluster.
+ Avere l'endpoint di configurazione del cluster codificato nell'applicazione è una bad practice poiché può essere modificato durante il processo di migrazione TLS.
## Durante la crittografia dei dati in transito: prestare attenzione a quando il processo di migrazione termina
La modifica della modalità di crittografia dei dati in transito non è immediata e può richiedere tempo. Ciò vale soprattutto per cluster di grandi dimensioni. Solo al termine della migrazione del cluster a TLS-Preferred sarà in grado di accettare e servire connessioni TCP e TLS. Pertanto, si consiglia di non creare client che tenteranno di stabilire connessioni TLS al cluster finché la crittografia dei dati in transito non è terminata.
Esistono diversi modi per ricevere una notifica quando la crittografia dei dati in transito viene completata correttamente o non è riuscita: (non mostrato nell'esempio di codice precedente):
+ Utilizzo del servizio SNS per ricevere una notifica quando la crittografia è terminata
+ Utilizzo dell'API `describe-events` che genera un evento al termine della crittografia
+ Visualizzazione di un messaggio nella ElastiCache console che indica che la crittografia è stata completata
Puoi anche implementare logica nell'applicazione per sapere se la crittografia è terminata. Nell'esempio precedente, sono stati illustrati diversi modi per garantire che la migrazione del cluster venga completata:
+ Attendere l'avvio del processo di migrazione (lo stato del cluster diventa “in corso di modifica“) e attendere il completamento della modifica (lo stato del cluster torna a “disponibile“)
+ Affermando che nel cluster `transit_encryption_enabled` è impostato su True eseguendo query sull'API `describe-replication-group`.
### Dopo l'abilitazione della crittografia dei dati in transito: accertarsi che i client utilizzati siano configurati correttamente
Mentre il cluster è in modalità TLS-preferred, l'applicazione deve aprire connessioni TLS al cluster e utilizzare solo tali connessioni. In questo modo, nell'applicazione non si verificheranno tempi di inattività durante l'abilitazione della crittografia dei dati in transito. Puoi assicurarti che non ci siano connessioni TCP più chiare al motore Valkey o Redis OSS usando il comando info nella sezione 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
```
## Connessione a nodi abilitati con crittografia in transito tramite Openssl (Memcached)
Per accedere ai dati provenienti dai ElastiCache nodi Memcached abilitati con la crittografia in transito, è necessario utilizzare client che funzionano con Secure Socket Layer (SSL). Su Amazon linux e Amazon Linux 2, puoi utilizzare anche Openssl s\$1client.
Per utilizzare Openssl s\$1client per la connessione a un cluster Memcached con crittografia in transito abilitata su Amazon Linux 2 o Amazon Linux:
```
/usr/bin/openssl s_client -connect memcached-node-endpoint:memcached-port
```
## Creazione di un client TLS Memcached utilizzando Java
Per creare un client in modalità TLS, procedi come segue per inizializzare il client con il codice appropriato: 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");
}
}
```
## Creazione di un client TLS Memcached utilizzando PHP
Per creare un client in modalità TLS, effettuate le seguenti operazioni per inizializzare il client con la modalità appropriata: 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);
}
```
Per ulteriori informazioni sull’utilizzo del client PHP, consulta [Installazione del client ElastiCache cluster per PHP](Appendix.PHPAutoDiscoverySetup.md).
# Crittografia At-Rest in ElastiCache
Per proteggere i dati, Amazon ElastiCache e Amazon S3 offrono diversi modi per limitare l'accesso ai dati nella cache. Per ulteriori informazioni, consultare [Amazon VPCs e la ElastiCache sicurezza](VPCs.md) e [Identity and Access Management per Amazon ElastiCache](IAM.md).
ElastiCache la crittografia at-rest è una funzionalità che aumenta la sicurezza dei dati crittografando i dati su disco. È sempre abilitata su una cache serverless. Quando è abilitata, esegue la crittografia degli elementi seguenti:
+ Il disco durante la sincronizzazione, operazioni di backup e di swap.
+ I backup archiviati in Amazon S3
I dati archiviati su SSDs (unità a stato solido) in cluster abilitati al tiering dei dati sono sempre crittografati.
ElastiCache [offre la crittografia predefinita (gestita dal servizio) a riposo, oltre alla possibilità di utilizzare le proprie chiavi KMS simmetriche gestite dal cliente in AWS Key Management Service AWS(KMS).](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) Quando viene eseguito il backup della cache, nelle opzioni di crittografia scegli se utilizzare la chiave di crittografia predefinita o una chiave gestita dal cliente. Per ulteriori informazioni, consulta [Abilitazione della crittografia dei dati inattivi](#at-rest-encryption-enable).
**Importante**
**L'attivazione di At-Rest Encryption su un cluster Valkey o Redis OSS esistente basato su nodi comporta l'eliminazione del gruppo di replica esistente, dopo aver eseguito il backup e il ripristino sul gruppo di replica.**
La crittografia dei dati a riposo può essere abilitata su una cache solo quando viene creata. Poiché la crittografia e la decrittografia dei dati richiede l'elaborazione, l'abilitazione della crittografia dei dati inattivi può in parte influire sulle prestazioni durante queste operazioni. È opportuno creare un riferimento per i dati con o senza crittografia dei dati inattivi per determinare l'impatto sulle prestazioni per i propri casi d'uso.
**Topics**
+ [Condizioni di crittografia dei dati inattivi](#at-rest-encryption-constraints)
+ [Utilizzo delle chiavi gestite dal cliente di KMS AWS](#using-customer-managed-keys-for-elasticache-security)
+ [Abilitazione della crittografia dei dati inattivi](#at-rest-encryption-enable)
+ [Vedi anche](#at-rest-encryption-see-also)
## Condizioni di crittografia dei dati inattivi
I seguenti vincoli sulla crittografia a ElastiCache riposo devono essere tenuti presenti quando pianifichi l'implementazione della crittografia a riposo: ElastiCache
+ La crittografia a riposo è supportata nei gruppi di replica che eseguono Valkey 7.2 e versioni successive e nelle versioni Redis OSS (3.2.6 pianificata per EOL, consulta la pianificazione di fine del ciclo di vita delle versioni [Redis](engine-versions.md#deprecated-engine-versions) OSS), 4.0.10 o successive.
+ La crittografia dei dati inattivi è supportata solo per gruppi di replica in esecuzione in un Amazon VPC.
+ La crittografia dei dati inattivi è supportata solo per i gruppi di replica in esecuzione sui seguenti tipi di nodi.
+ R7g, R6gd, R6g, R5, R4, R3
+ M7g, 6g, M5, M4, M3
+ T4g, T3, T2
+ C7gn
Per ulteriori informazioni, consulta [Tipi di nodi supportati](CacheNodes.SupportedTypes.md)
+ La crittografia dei dati inattivi è abilitata impostando in maniera esplicita impostando il parametro `AtRestEncryptionEnabled` su `true`.
+ Puoi abilitare la crittografia dei dati inattivi su un gruppo di replica solo durante la creazione del gruppo di replica. Non puoi attivare/disattivare la crittografia dei dati inattivi modificando un gruppo di replica. Per informazioni sull'implementazione della crittografia dei dati inattivi su un gruppo di replica esistente, consulta [Abilitazione della crittografia dei dati inattivi](#at-rest-encryption-enable).
+ Se un cluster utilizza un tipo di nodo della famiglia r6gd, i dati archiviati su SSD vengono crittografati indipendentemente dal fatto che la crittografia a riposo sia abilitata o meno.
+ L'opzione di utilizzare la chiave gestita dal cliente per la crittografia a riposo non è disponibile nelle AWS GovCloud regioni (-1 e -1). us-gov-east us-gov-west
+ Se un cluster utilizza un tipo di nodo della famiglia r6gd, i dati archiviati su SSD vengono crittografati con la chiave AWS KMS gestita dal cliente selezionata (o la crittografia gestita dal servizio nelle regioni).AWS GovCloud
+ Con Memcached, la crittografia a riposo è supportata solo sulle cache serverless.
+ Quando si utilizza Memcached, l'opzione di utilizzare la chiave gestita dal cliente per la crittografia a riposo non è disponibile nelle AWS GovCloud regioni (-1 e -1). us-gov-east us-gov-west
L'implementazione della crittografia dei dati inattivi può ridurre le prestazioni durante le operazioni di backup e sincronizzazione. Raffronta la crittografia dei dati inattivi con l'assenza di crittografia sui dati per determinare il suo impatto sulle prestazioni per l'implementazione.
## Utilizzo delle chiavi gestite dal cliente di KMS AWS
ElastiCache supporta chiavi KMS simmetriche gestite dal cliente (chiave AWS KMS) per la crittografia a riposo. Le chiavi KMS gestite dal cliente sono chiavi di crittografia che crei, possiedi e gestisci nel tuo account.AWS Per ulteriori informazioni, consulta [AWS Chiavi KMS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) nella *AWS Key Management Service Developer Guide (Guida Sviluppatore del Servizio di Gestione Chiave*. Le chiavi devono essere create in AWS KMS prima di poter essere utilizzate con. ElastiCache
Per informazioni su come creare le chiavi principali di AWS KMS, consulta [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *AWS Key Management Service Developer Guide*.
ElastiCache ti consente di integrarti con AWS KMS. Per ulteriori informazioni, consulta [Utilizzo di concessioni](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) nella *AWS Guida per gli sviluppatori Key Management Service*. Non è necessaria alcuna azione da parte del cliente per abilitare ElastiCache l'integrazione di Amazon con AWS KMS.
La chiave `kms:ViaService` condizionale limita l'uso di una chiave AWS KMS (chiave KMS) alle richieste provenienti da servizi specifici.AWS Da utilizzare `kms:ViaService` con ElastiCache, includi entrambi i ViaService nomi nel valore della chiave di condizione: `elasticache.AWS_region.amazonaws.com` e. `dax.AWS_region.amazonaws.com` Per ulteriori informazioni, vedere [kms: ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service).
Puoi utilizzarlo [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)per tenere traccia delle richieste a cui Amazon ElastiCache invia per tuo AWS Key Management Service conto. Tutte le chiamate API AWS Key Management Service relative alle chiavi gestite dal cliente hanno CloudTrail i log corrispondenti. Puoi anche vedere le sovvenzioni generate chiamando ElastiCache la chiamata all'API [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html)KMS.
Dopo che un gruppo di replica viene crittografato mediante le chiavi gestite dal cliente, tutti i backup del gruppo di replica sono crittografati nel modo seguente:
+ I backup automatici giornalieri vengono crittografati utilizzando la chiave gestita dal cliente associata al cluster.
+ Anche il backup finale creato al momento dell'eliminazione del gruppo di replica viene crittografato utilizzando la chiave gestita da cliente associata a gruppo di replica.
+ I backup creati manualmente vengono crittografati per impostazione predefinita per utilizzare la chiave KMS associata al gruppo di replica. Puoi sostituirla scegliendo un'altra chiave gestita dal cliente.
+ La copia di un backup viene impostata in modo di default sull'uso della chiave gestita dal cliente associata a backup fonte. Puoi sostituirla scegliendo un'altra CMK gestita dal cliente.
**Nota**
Le chiavi gestite dal cliente non possono essere utilizzate durante l'esportazione dei backup sul bucket Amazon S3 selezionato. Tuttavia, tutti i backup esportati in Amazon S3 vengono crittografati utilizzando la [crittografia lato server](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). Puoi scegliere di copiare i file di backup su un nuovo oggetto S3 e crittografarli utilizzando una chiave gestita dal cliente, copiare i file in un altro bucket S3 configurato con la crittografia predefinita mediante una chiave KMS o modificare l'opzione di crittografia nel file stesso.
Puoi anche utilizzare le chiavi gestite dal cliente per crittografare i backup creati manualmente per i gruppi di replica che, per la crittografia, non utilizzano chiave gestite dal cliente. Con questa opzione, il file di backup archiviato in Amazon S3 viene crittografato utilizzando una chiave KMS, anche se i dati non sono crittografati sul gruppo di replica di fonte.
Il ripristino da un backup consente di scegliere tra le opzioni di crittografia disponibili, come si fa con le opzioni di crittografia disponibili quando si crea un nuovo gruppo di replica.
+ Se elimini o [disabiliti](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) la chiave e [revochi le assegnazioni](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) della chiave utilizzata per crittografare un gruppo di replica, la cache diventa irrecuperabile. In altre parole, non può essere modificato o ripristinato dopo un guasto hardware.AWS KMS elimina le chiavi principali solo dopo un periodo di attesa di almeno sette giorni. Una volta eliminata la chiave, puoi utilizzare una chiave gestita dal cliente differente per creare un backup per scopi di archiviazione.
+ La rotazione automatica delle chiavi preserva le proprietà delle chiavi principali del AWS KMS, quindi la rotazione non ha alcun effetto sulla capacità di accedere ai dati. ElastiCache ElastiCache Le cache Amazon crittografate non supportano la rotazione manuale delle chiavi, che comporta la creazione di una nuova chiave principale e l'aggiornamento di eventuali riferimenti alla vecchia chiave. Per ulteriori informazioni, consulta [Rotating AWS KMS keys nella AWS Key](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) *Management Service* Developer Guide.
+ La crittografia di una ElastiCache cache utilizzando la chiave KMS richiede una concessione per cache. Questa assegnazione viene utilizzata per tutta la durata della cache. Inoltre, durante la creazione del backup viene utilizzata una singola assegnazione per ogni backup. Questa assegnazione viene ritirata una volta creato il backup.
+ Per ulteriori informazioni su concessioni e limiti AWS KMS, consulta Limiti nella *AWS Key Management* [Service](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) Developer Guide.
## Abilitazione della crittografia dei dati inattivi
Tutte le cache serverless dispongono della crittografia dei dati a riposo abilitata.
Quando si crea un cluster basato su nodi, è possibile abilitare la crittografia a riposo impostando il parametro su. `AtRestEncryptionEnabled` `true` Non puoi abilitare la crittografia dei dati inattivi su gruppi di replica esistenti.
È possibile abilitare la crittografia a riposo quando si crea una cache. ElastiCache È possibile farlo utilizzando l'Console di gestione AWSAWS CLI, il o l' ElastiCache API.
Durante la creazione di una cache, puoi scegliere una delle opzioni seguenti:
+ **Predefinita** – Questa opzione utilizza la crittografia dei dati inattivi gestita dal servizio.
+ **Chiave gestita dal cliente**: questa opzione consente di fornire la chiave ID/ARN di AWS KMS per la crittografia a riposo.
Per informazioni su come creare le chiavi principali del AWS KMS, consulta [Create Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) nella *AWS Key Management Service* Developer Guide
**Contents**
+ [Abilitazione della crittografia At-Rest utilizzando il Console di gestione AWS](#at-rest-encryption-enable-con)
+ [Abilitazione della crittografia At-Rest utilizzando il AWS CLI](#at-rest-encryption-enable-cli)
### Abilitazione della crittografia At-Rest su un cluster Valkey o Redis OSS esistente basato su nodi
È possibile abilitare la crittografia at-rest solo quando si crea un gruppo di replica Valkey o Redis OSS. Se disponi di un gruppo di replica esistente su cui desideri abilitare la crittografia dei dati inattivi, procedi nel modo seguente.
**Per abilitare la crittografia dei dati inattivi su un gruppo di replica esistente**
1. Creare un backup manuale del gruppo di replica esistente. Per ulteriori informazioni, consulta [Esecuzione di backup manuali](backups-manual.md).
1. Creare un nuovo gruppo di replica eseguendo il ripristino dal backup. Sul nuovo gruppo di replica, abilitare la crittografia dei dati inattivi. Per ulteriori informazioni, consulta [Ripristino da un backup in una nuova cache](backups-restoring.md).
1. Aggiornare gli endpoint nell'applicazione affinché facciano riferimento al nuovo gruppo di replica.
1. Eliminare il vecchio gruppo di replica. Per ulteriori informazioni, consulta [Eliminazione di un cluster in ElastiCache](Clusters.Delete.md) o [Eliminazione di un gruppo di replica](Replication.DeletingRepGroup.md).
### Abilitazione della crittografia At-Rest utilizzando il Console di gestione AWS
#### Abilitazione della crittografia dei dati a riposo su una cache serverless (console)
Tutte le cache serverless dispongono della crittografia dei dati a riposo abilitata. Per impostazione predefinita, viene utilizzata una chiave KMS AWS di proprietà per crittografare i dati. Per scegliere la tua AWS KMS chiave, effettua le seguenti selezioni:
+ Espandi la sezione **Impostazioni predefinite**.
+ Scegli **Personalizza le impostazioni predefinite** nella sezione **Impostazioni predefinite**.
+ Scegli **Personalizza le impostazioni di sicurezza** nella sezione **Sicurezza**.
+ Scegli **CMK gestita dal cliente** per l'impostazione **Chiave di crittografia**.
+ Seleziona una chiave nell'impostazione **Chiave AWS KMS**.
#### Abilitazione della crittografia At-Rest su un cluster basato su nodi (console)
Quando si progetta la propria cache, le configurazioni "Sviluppo/Test" e "Produzione" con il metodo "Crea semplice" hanno la crittografia dei dati a riposo abilitata con la chiave **predefinita**. Quando scegli la configurazione, procedi come segue:
+ Scegliere la versione 3.2.6, 4.0.10 o successive come versione motore.
+ Fai clic sulla casella di controllo **Abilita** accanto all'opzione **Crittografia dei dati a riposo**.
+ Scegli una **chiave predefinita** o una **CMK gestita dal cliente**.
Per la step-by-step procedura, vedere quanto segue:
+ [Creazione di un cluster Valkey (modalità cluster disabilitata) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ [Creazione di un cluster Valkey o Redis OSS (modalità cluster abilitata) (Console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
### Abilitazione della crittografia At-Rest utilizzando il AWS CLI
Per abilitare la crittografia a riposo durante la creazione di un cluster Valkey o Redis OSS utilizzando il AWS CLI, utilizzare il parametro *-- at-rest-encryption-enabled* durante la creazione di un gruppo di replica.
#### Abilitazione della crittografia At-Rest su un cluster (CLI) Valkey o Redis OSS (modalità cluster disabilitata)
L'operazione seguente crea il gruppo di replica Valkey o Redis OSS (modalità cluster disabilitata) `my-classic-rg` con tre nodi (*-- num-cache-clusters*), una replica primaria e due di lettura. *La crittografia a riposo è abilitata per questo gruppo di replica (--). at-rest-encryption-enabled*
I seguenti parametri e i relativi valori sono necessari per abilitare la crittografia su questo gruppo di replica:
**Parametri chiave**
+ **--engine**—Deve essere o. `valkey` `redis`
+ **--engine-version**—Se il motore è Redis OSS, deve essere 3.2.6, 4.0.10 o successivo.
+ **--at-rest-encryption-enabled**- Richiesto per abilitare la crittografia inattiva.
**Example 1: Cluster Valkey o Redis OSS (modalità cluster disabilitata) con repliche**
Per 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
```
Per 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 ^
```
Per ulteriori informazioni, consulta la seguente documentazione:
+ [Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Disabled) ()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)
#### Abilitazione della crittografia At-Rest su un cluster per Valkey o Redis OSS (modalità cluster abilitata) (CLI)
*L'operazione seguente crea il gruppo di replica Valkey o Redis OSS (modalità cluster abilitata) `my-clustered-rg` con tre gruppi di nodi o shard (--). num-node-groups* *Ciascuno ha tre nodi, una replica principale e due repliche di lettura (--). replicas-per-node-group* La crittografia a riposo è abilitata per questo gruppo di replica (*--*). at-rest-encryption-enabled
I seguenti parametri e i relativi valori sono necessari per abilitare la crittografia su questo gruppo di replica:
**Parametri chiave**
+ **--engine**—Deve essere o. `valkey` `redis`
+ **--engine-version**—Se il motore è Redis OSS, deve essere 4.0.10 o successivo.
+ **--at-rest-encryption-enabled**- Richiesto per abilitare la crittografia inattiva.
+ **--cache-parameter-group**: deve essere `default-redis4.0.cluster.on` o uno derivato da esso per rendere questo un gruppo di replica abilitato in modalità cluster.
**Example 2: Un cluster Valkey o Redis OSS (Cluster Mode Enabled)**
Per 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
```
Per 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
```
Per ulteriori informazioni, consulta la seguente documentazione:
+ [Creazione da zero di un gruppo di replica Valkey o Redis OSS (Cluster Mode Enabled) ()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)
## Vedi anche
+ [Amazon VPCs e la ElastiCache sicurezza](VPCs.md)
+ [Identity and Access Management per Amazon ElastiCache](IAM.md)
# Autenticazione e autorizzazione
AWS Identity and Access Management (IAM) è un servizio web che consente di controllare in modo sicuro l'accesso alle AWS risorse. ElastiCache supporta l'autenticazione degli utenti tramite IAM e il comando Valkey e Redis OSS AUTH e l'autorizzazione delle operazioni degli utenti tramite Role-Based Access Control (RBAC).
**Topics**
+ [Controllo accessi basato sui ruoli (RBAC)](Clusters.RBAC.md)
+ [Autenticazione con il comando Valkey e Redis OSS AUTH](auth.md)
+ [Disabilitazione del controllo degli accessi su una cache ElastiCache Valkey o Redis OSS](in-transit-encryption-disable.md)
# Controllo accessi basato sui ruoli (RBAC)
Con il comando Valkey e Redis OSS AUTH come descritto in è [Autenticazione con il comando Valkey e Redis OSS AUTH](auth.md) possibile utilizzare Role-Based Access Control (RBAC). Il controllo degli accessi basato su ruoli è anche l'unico modo per controllare l'accesso alle cache serverless. È disponibile per Valkey 7.2 e versioni successive e Redis OSS da 6.0 a 7.2.
RBAC consente di:
+ Controllare l'accesso alla cache tramite gruppi di utenti. Questi gruppi di utenti sono progettati come un modo per organizzare l'accesso alle cache.
+ Con *AuthN*, disponi di password per utente anziché token di autenticazione per cluster.
+ Con *AuthZ*, disponi di autorizzazioni utente dettagliate.
+ Basa l'accesso al cluster su. ACLs
A differenza di Valkey e Redis OSS AUTH, in cui tutti i client autenticati hanno accesso completo alla cache se il loro token è autenticato, RBAC consente di assegnare gli utenti ai set in base ai ruoli desiderati dagli utenti. Questi set sono progettati per organizzare l'accesso alle cache.
Con RBAC, è possibile creare utenti e assegnare loro autorizzazioni specifiche utilizzando una stringa di accesso, come descritto di seguito. Gli utenti vengono assegnati a set allineati a un ruolo specifico (amministratori, risorse umane) che vengono quindi distribuiti in una o più cache. ElastiCache In questo modo, è possibile stabilire limiti di sicurezza tra i client che utilizzano la stessa cache o cache OSS Valkey o Redis e impedire ai client di accedere ai dati degli altri.
RBAC è progettato per supportare l'introduzione di [ACL](https://valkey.io/topics/acl/) in Redis OSS 6. Quando si utilizza RBAC con la cache ElastiCache Valkey o Redis OSS, esistono alcune limitazioni:
+ Un gruppo di utenti configurato per il motore «VALKEY» può contenere solo utenti che utilizzano un meccanismo di autenticazione (password o IAM). Ciò significa che tutti gli utenti con il motore «VALKEY» e tutti gli altri utenti con il motore «Redis» la cui configurazione è configurata per l'autenticazione con password o IAM, possono far parte di questo gruppo di utenti.
+ Quando si utilizza RBAC con cluster Valkey, è possibile utilizzare entrambi i gruppi di utenti con motore «VALKEY» e con motore «REDIS».
+ Quando si utilizza RBAC con cluster Redis OSS, è possibile utilizzare solo gruppi di utenti con il motore «REDIS».
+ Non è possibile specificare password in una stringa di accesso. Le password vengono impostate con o chiamate. [CreateUser[ModifyUser](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyUser.html)](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateUser.html)
+ Per quanto riguarda i diritti utente, abiliti o disabiliti gli utenti con `on` e `off` come parte della stringa di accesso. Se nessuno dei due è specificato nella stringa di accesso, all'utente viene assegnato `off` e non dispone dei diritti di accesso alla cache.
+ Non è possibile utilizzare comandi proibiti e rinominati come parte della stringa di accesso. Se si specifica un comando proibito o rinominato, verrà generata un'eccezione. Se desiderate utilizzare le liste di controllo degli accessi (ACLs) per un comando rinominato, specificate il nome originale del comando, in altre parole il nome del comando prima che fosse rinominato.
+ Non è possibile utilizzare la`reset`come parte di una stringa di accesso. Specificate le password con parametri API e ElastiCache per Valkey e Redis OSS gestisce le password. Pertanto, non è possibile utilizzare`reset`perché rimuoverebbe tutte le password per un utente.
+ [Redis OSS 6 introduce il comando ACL LIST.](https://valkey.io/commands/acl-list) Questo comando restituisce un elenco di utenti insieme alle regole ACL applicate a ciascun utente. ElastiCache supporta il `ACL LIST` comando, ma non include il supporto per gli hash delle password come fa Redis OSS. Con ElastiCache, è possibile utilizzare l'[DescribeUsers](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeUsers.html)operazione per ottenere informazioni simili, incluse le regole contenute nella stringa di accesso. Tuttavia, [DescribeUsers](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeUsers.html)non recupera una password utente.
+ [https://valkey.io/commands/acl-users](https://valkey.io/commands/acl-users) ElastiCache per Valkey e Redis OSS non supporta nessun altro comando ACL basato sulla scrittura.
+ Si applicano i seguenti limiti:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonElastiCache/latest/dg/Clusters.RBAC.html)
**RBAC con Valkey**
Quando si utilizza Role Based Access Control con Valkey, gli utenti e i gruppi di utenti vengono creati con il tipo di motore «VALKEY». Questo è consigliato, poiché per impostazione predefinita Valkey con RBAC offre una maggiore sicurezza rispetto a Redis OSS. Sia i cluster Valkey con provisioning che quelli serverless supportano le associazioni di utenti e gruppi di utenti VALKEY.
Le caratteristiche principali di Valkey Access Control includono:
+ Gli utenti Valkey sono limitati alle sole associazioni di gruppi di utenti Valkey.
+ I gruppi di utenti Valkey possono contenere utenti Valkey e utenti Redis OSS protetti da password o abilitati all'autenticazione IAM.
+ Gli utenti Valkey devono utilizzare la protezione tramite password o l'autenticazione IAM.
+ I gruppi di utenti VALKEY possono essere associati solo ai cluster VALKEY
+ Non esiste alcun requisito utente predefinito. Quando il gruppo di utenti Valkey è collegato ai cluster, i requisiti utente predefiniti vengono automaticamente disabilitati. I clienti vedranno che l'utente predefinito è disattivato quando utilizzano il comando ACL LIST.
Di seguito sono riportate ulteriori informazioni sull'utilizzo di RBAC con ElastiCache Valkey e Redis OSS.
**Topics**
+ [Specifica delle autorizzazioni mediante una stringa di accesso](#Access-string)
+ [Applicazione di RBAC a una cache ElastiCache per Valkey o Redis OSS](#rbac-using)
+ [Migrazione da AUTH a RBAC](#Migrate-From-RBAC-to-Auth)
+ [Migrazione da RBAC a AUTH](#Migrate-From-RBAC-to-AUTH-1)
+ [Rotazione automatica delle password per utenti](User-Secrets-Manager.md)
+ [Autenticazione con IAM](auth-iam.md)
## Specifica delle autorizzazioni mediante una stringa di accesso
Per specificare le autorizzazioni per una cache ElastiCache Valkey o Redis OSS, si crea una stringa di accesso e la si assegna a un utente tramite o.AWS CLIConsole di gestione AWS
Le stringhe di accesso sono definite come un elenco di regole delimitate da spazi che vengono applicate all'utente. Essi definiscono quali comandi un utente può eseguire e quali chiavi un utente può operare. Per eseguire un comando, un utente deve avere accesso al comando in esecuzione e tutte le chiavi sono accessibili dal comando. Le regole vengono applicate da sinistra a destra cumulativamente e una stringa più semplice può essere utilizzata al posto di quella fornita se ci sono ridondanze nella stringa fornita.
Per ulteriori informazioni sulla sintassi delle regole ACL, consulta [ACL](https://valkey.io/topics/acl/).
Nell'esempio seguente, la stringa di accesso rappresenta un utente attivo con accesso a tutti i tasti e i comandi disponibili.
`on ~* +@all`
La sintassi della stringa di accesso è suddivisa come segue:
+ `on`— L'utente è un utente attivo.
+ `~*`— L'accesso è dato a tutte le chiavi disponibili.
+ `+@all`— Accesso a tutti i comandi disponibili.
Le impostazioni precedenti sono le meno restrittive. È possibile modificare queste impostazioni per renderle più sicure.
Nell'esempio seguente, la stringa di accesso rappresenta un utente con accesso limitato all'accesso in lettura sulle chiavi che iniziano con lo spazio delle chiavi «app::»
`on ~app::* -@all +@read`
È possibile perfezionare ulteriormente queste autorizzazioni elencando i comandi a cui l'utente ha accesso:
`+command1`— L'accesso dell'utente ai comandi è limitato a*`command1`*.
`+@category`— L'accesso dell'utente è limitato a una categoria di comandi.
Per informazioni sull'assegnazione di una stringa di accesso a un utente, vedere[Creazione di utenti e gruppi di utenti con Console e CLI](#Users-management).
Se stai migrando un carico di lavoro esistente verso ElastiCache, puoi recuperare la stringa di accesso chiamando, escludendo l'utente e qualsiasi hash della `ACL LIST` password.
Per Redis OSS versione 6.2 e successive è supportata anche la seguente sintassi della stringa di accesso:
+ `&*` – L'accesso è consentito a tutti i canali disponibili.
Per Redis OSS versione 7.0 e successive è supportata anche la seguente sintassi della stringa di accesso:
+ `|` – Può essere usato per bloccare i sottocomandi (ad esempio, "-config\$1set").
+ `%R~` – Aggiunge il modello di chiave di lettura specificato. Il comportamento è simile al modello chiave normale, ma concede l'autorizzazione solo per leggere dalle chiavi che corrispondono al modello specificato. Per ulteriori informazioni, consulta [autorizzazioni della chiave](https://valkey.io/topics/acl/).
+ `%W~` – Aggiunge il modello di chiave di scrittura specificato. Il comportamento è simile al modello chiave normale, ma concede solo l'autorizzazione per scrivere nelle chiavi che corrispondono al modello specificato. Per ulteriori informazioni, consulta [Autorizzazioni delle chiavi ACL](https://valkey.io/topics/acl/).
+ `%RW~` – Alias per `~`.
+ `()` – Crea un nuovo selettore rispetto al quale abbinare le regole. I selettori vengono valutati dopo le autorizzazioni utente e in base all'ordine in cui sono definiti. Se un comando corrisponde alle autorizzazioni utente o a qualsiasi selettore, viene consentito. Per ulteriori informazioni, consulta [Selettori ACL](https://valkey.io/topics/acl/).
+ `clearselectors` – Elimina tutti i selettori collegati all'utente.
## Applicazione di RBAC a una cache ElastiCache per Valkey o Redis OSS
Per utilizzarlo ElastiCache per Valkey o Redis OSS RBAC, procedi nel seguente modo:
1. Crea uno o più utenti.
1. Crea un gruppo di utenti e aggiungi utenti al gruppo.
1. Assegna il gruppo di utenti a una cache in cui è abilitata la crittografia dei dati in transito.
Questi passaggi sono descritti in dettaglio come segue.
**Topics**
+ [Creazione di utenti e gruppi di utenti con Console e CLI](#Users-management)
+ [Gestione dei gruppi di utenti con Console e CLI](#User-Groups)
+ [Assegnazione di gruppi di utenti alle cache serverless](#Users-groups-to-serverless-caches)
+ [Assegnazione di gruppi di utenti ai gruppi di replica](#Users-groups-to-RGs)
### Creazione di utenti e gruppi di utenti con Console e CLI
Le informazioni utente per gli utenti RBAC sono un ID utente, un nome utente e facoltativamente una password e una stringa di accesso. La stringa di accesso fornisce il livello di autorizzazione per i tasti e i comandi. L'ID utente è univoco per l'utente e il nome utente è ciò che viene passato al motore.
Assicurarsi che le autorizzazioni utente fornite abbiano senso con lo scopo previsto del gruppo di utenti. Ad esempio, se si crea un gruppo di utenti denominato `Administrators`, qualsiasi utente aggiunto a quel gruppo deve avere la relativa stringa di accesso impostata per l'accesso completo a tasti e comandi. Per gli utenti in un`e-commerce`, è possibile impostare le relative stringhe di accesso su accesso di sola lettura.
ElastiCache configura automaticamente un utente predefinito con ID utente e nome `"default"` utente e lo aggiunge a tutti i gruppi di utenti. Non è possibile eliminare o modificare questo utente. Questo utente è progettato per garantire la compatibilità con il comportamento predefinito delle versioni precedenti di Redis OSS e dispone di una stringa di accesso che gli consente di chiamare tutti i comandi e accedere a tutte le chiavi.
Per aggiungere a una cache un controllo di accesso appropriato, sostituisci l'utente predefinito con uno nuovo che non è abilitato o utilizza una password complessa. Per modificare l'utente di default, creare un nuovo utente con il nome utente impostato su `default`. È quindi possibile scambiarlo con l'utente di default originale.
Di seguito viene illustrata la procedura per scambiare l'utente originale `default` con un altro `default` utente che dispone di una stringa di accesso modificata.
**Come modificare l'utente predefinito nella console**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nel riquadro di navigazione seleziona **Gestione gruppi di utenti**.
1. Per **ID gruppo di utenti** scegli l'ID che desideri modificare. Verificare di aver selezionato il collegamento e non la casella di controllo.
1. Scegli **Modifica**.
1. Nella finestra **Modifica**, scegli **Gestisci**. Per «seleziona l'utente che desideri», seleziona l'utente con il **nome utente** predefinito.
1. Scegliere **Choose (Scegli)**.
1. Scegli **Modifica**. Quando si esegue questa operazione vengono terminate tutte le connessioni esistenti a una cache disponibili per l'utente predefinito originale.
**Per modificare l'utente predefinito con AWS CLI**
1. Crea un nuovo utente con il nome utente`default`Utilizzando i seguenti comandi.
Per 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*"
```
Per 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. Creare un gruppo di utenti e aggiungere l'utente creato in precedenza.
Per Linux, macOS o Unix:
```
aws elasticache create-user-group \
--user-group-id "new-group-2" \
--engine "VALKEY" \
--user-ids "new-default-user"
```
Per Windows:
```
aws elasticache create-user-group ^
--user-group-id "new-group-2" ^
--engine "VALKEY" ^
--user-ids "new-default-user"
```
Quando si crea un utente, è possibile impostare fino a due password. Quando si modifica una password, vengono mantenute tutte le connessioni esistenti alle cache.
In particolare, tieni presente questi vincoli relativi alla password utente quando utilizzi RBAC ElastiCache for Valkey e Redis OSS:
+ Le password devono essere da 16 a 128 caratteri stampabili.
+ I seguenti caratteri non alfanumerici non sono consentiti:`,` `""` `/` `@`.
#### Gestione degli utenti con la console e la CLI
Utilizza la procedura seguente per gestire gli utenti sulla console.
**Per gestire gli utenti nella console**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nella ElastiCache dashboard di Amazon, scegli **Gestione utenti**. Sono disponibili le seguenti opzioni:
+ **Crea utente**: quando si crea un utente, si immette un ID utente, un nome utente, una modalità di autenticazione e una stringa di accesso. La stringa di accesso imposta il livello di autorizzazione per le chiavi e i comandi consentiti all'utente.
Quando si crea un utente, è possibile impostare fino a due password. Quando si modifica una password, vengono mantenute tutte le connessioni esistenti alle cache.
+ **Modifica utente**: consente di aggiornare le impostazioni di autenticazione di un utente o di modificarne la stringa di accesso.
+ **Elimina utente**: l'account viene rimosso da qualsiasi gruppo di utenti a cui appartiene.
Utilizza le procedure seguenti per gestire gli utenti con l'AWS CLI.
**Per modificare un utente utilizzando la CLI;**
+ Utilizzo dell'`modify-user`per aggiornare la password o le password di un utente o modificare le autorizzazioni di accesso di un utente.
Quando un utente viene modificato, vengono aggiornati i gruppi di utenti associati all'utente, insieme a tutte le cache associate ai gruppi di utenti. Tutte le connessioni esistenti vengono mantenute. Di seguito vengono mostrati gli esempi.
Per Linux, macOS o Unix:
```
aws elasticache modify-user \
--user-id user-id-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode Type=iam
```
Per Windows:
```
aws elasticache modify-user ^
--user-id user-id-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode Type=iam
```
**Nota**
Non è consigliabile utilizzare la`nopass`opzione. In tal caso, si consiglia di impostare le autorizzazioni dell'utente in sola lettura con accesso a un set limitato di chiavi.
**Per eliminare un utente utilizzando la CLI;**
+ Utilizza il comando `delete-user` per eliminare un utente. L'account viene eliminato e rimosso da tutti i gruppi di utenti a cui appartiene. Di seguito è riportato un esempio di :
Per Linux, macOS o Unix:
```
aws elasticache delete-user \
--user-id user-id-2
```
Per Windows:
```
aws elasticache delete-user ^
--user-id user-id-2
```
Per visualizzare un elenco di utenti, chiama l’operazione [describe-users](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-users.html).
```
aws elasticache describe-users
```
### Gestione dei gruppi di utenti con Console e CLI
È possibile creare gruppi di utenti per organizzare e controllare l'accesso degli utenti a una o più cache, come illustrato di seguito.
Utilizza la procedura seguente per gestire gruppi di utenti utilizzando la console.
**Gestione dei gruppi di utenti tramite la console;**
1. Accedi a Console di gestione AWS e apri la ElastiCache console Amazon all'indirizzo [https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/).
1. Nella ElastiCache dashboard di Amazon, scegli **Gestione dei gruppi di utenti**.
Di seguito sono elencate le operazioni disponibili per creare nuovi gruppi di utenti:
+ **Crea**: quando si crea un gruppo di utenti, si aggiungono gli utenti e quindi si assegnano i gruppi di utenti alle cache. Ad esempio, è possibile creare un gruppo di utenti `Admin` per gli utenti che dispongono di ruoli amministrativi per una cache.
**Importante**
Se non utilizzi un gruppo di utenti Valkey o Redis OSS, devi includere un utente predefinito durante la creazione di un gruppo di utenti.
+ **Aggiungi utenti**: aggiunge utenti al gruppo di utenti.
+ **Rimuovere gli utenti**— Rimuove gli utenti dal gruppo di utenti. Quando gli utenti vengono rimossi da un gruppo di utenti, vengono terminate tutte le connessioni esistenti alle cache.
+ **Elimina**: utilizza questa opzione per eliminare un gruppo di utenti. Si noti che il gruppo di utenti stesso, non gli utenti che appartengono al gruppo, verrà eliminato.
Per i gruppi di utenti esistenti, puoi effettuare le seguenti operazioni:
+ **Aggiungi utenti**— Aggiunge utenti esistenti al gruppo di utenti.
+ **Eliminazione di utenti**— Rimuove gli utenti esistenti dal gruppo di utenti.
**Nota**
Gli utenti vengono rimossi dal gruppo di utenti, ma non eliminati dal sistema.
Utilizza le procedure seguenti per gestire gruppi di utenti utilizzando la CLI.
**Per creare un nuovo gruppo di utenti e aggiungere un utente utilizzando la CLI**
+ Usa il comando `create-user-group` come mostrato nell'esempio seguente.
Per 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
```
Per Windows:
```
aws elasticache create-user-group ^
--user-group-id "new-group-1" ^
--engine "VALKEY" ^
--user-ids user-id-1, user-id-2
```
**Per modificare un gruppo di utenti aggiungendo nuovi utenti o rimuovendo membri correnti tramite la CLI**
+ Usa il comando `modify-user-group` come mostrato nell'esempio seguente.
Per 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
```
Per 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**
Tutte le connessioni aperte appartenenti a un utente rimosse da un gruppo di utenti vengono terminate con questo comando.
**Per eliminare un gruppo di utenti tramite la CLI;**
+ Usa il comando `delete-user-group` come mostrato nell'esempio seguente. Il gruppo di utenti stesso, non gli utenti che appartengono al gruppo, viene eliminato.
Per Linux, macOS o Unix:
```
aws elasticache delete-user-group /
--user-group-id
```
Per Windows:
```
aws elasticache delete-user-group ^
--user-group-id
```
Per visualizzare un elenco di gruppi di utenti, puoi chiamare l'[describe-user-groups](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-user-groups.html)operazione.
```
aws elasticache describe-user-groups \
--user-group-id test-group
```
### Assegnazione di gruppi di utenti alle cache serverless
Dopo aver creato un gruppo di utenti e aggiunto gli utenti, il passaggio finale dell'implementazione di RBAC consiste nell'assegnare il gruppo di utenti a una cache serverless.
#### Assegnazione di gruppi di utenti alle cache serverless mediante la console
Per aggiungere un gruppo di utenti a una cache serverless utilizzando il Console di gestione AWS, procedi come segue:
+ Per la modalità cluster disabilitata, vedere[Creazione di un cluster Valkey (modalità cluster disabilitata) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ Per la modalità cluster abilitata, consulta[Creazione di un cluster Valkey o Redis OSS (modalità cluster abilitata) (Console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
#### Assegnazione di gruppi di utenti alle cache serverless utilizzando AWS CLI
La seguente AWS CLI operazione crea una cache serverless utilizzando il **user-group-id** parametro con il valore. `my-user-group-id` Sostituisci il gruppo di sottoreti `sng-test` con uno esistente.
**Parametri chiave**
+ **--engine**— Deve essere `VALKEY` o`REDIS`.
+ **--user-group-id**: questo valore fornisce l'ID del gruppo di utenti composto da utenti con autorizzazioni di accesso specificate per la cache.
Per 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"
```
Per 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 seguente AWS CLI operazione modifica una cache serverless con il **user-group-id** parametro con il valore. `my-user-group-id`
Per Linux, macOS o Unix:
```
aws elasticache modify-serverless-cache \
--serverless-cache-name serverless-cache-1 \
--user-group-id "new-group-2"
```
Per Windows:
```
aws elasticache modify-serverless-cache ^
--serverless-cache-name serverless-cache-1 ^
--user-group-id "new-group-2"
```
Tieni presente che tutte le modifiche apportate a una cache vengono aggiornate in modo asincrono. Puoi monitorare l'avanzamento visualizzando gli eventi. Per ulteriori informazioni, consulta [Visualizzazione ElastiCache degli eventi](ECEvents.Viewing.md).
### Assegnazione di gruppi di utenti ai gruppi di replica
Dopo aver creato un gruppo di utenti e aggiunto utenti, il passaggio finale nell'implementazione di RBAC consiste nell'assegnare il gruppo di utenti a un gruppo di replica.
#### Assegnazione di gruppi di utenti ai gruppi di replica mediante la console
Per aggiungere un gruppo di utenti a una replica utilizzando il Console di gestione AWS, effettuate le seguenti operazioni:
+ Per la modalità cluster disabilitata, vedere[Creazione di un cluster Valkey (modalità cluster disabilitata) (console)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)
+ Per la modalità cluster abilitata, consulta[Creazione di un cluster Valkey o Redis OSS (modalità cluster abilitata) (Console)](Clusters.Create.md#Clusters.Create.CON.RedisCluster)
#### Assegnazione di gruppi di utenti a gruppi di replica utilizzando AWS CLI
La seguente AWS CLI operazione crea un gruppo di replica con la crittografia in transito (TLS) abilitata e il **user-group-ids** parametro con il valore. `my-user-group-id` Sostituisci il gruppo di sottoreti `sng-test` con uno esistente.
**Parametri chiave**
+ **--engine**— Deve essere `valkey` o. `redis`
+ **--engine-version** – Deve essere versione 6.0 o successiva.
+ **--transit-encryption-enabled**— Richiesto per l'autenticazione e per l'associazione di un gruppo di utenti.
+ **--user-group-ids**: questo valore fornisce l'ID del gruppo di utenti composto da utenti con autorizzazioni di accesso specificate per la cache.
+ **--cache-subnet-group**: obbligatorio per l'associazione di un gruppo di utenti.
Per 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"
```
Per 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 seguente AWS CLI operazione modifica un gruppo di replica con la crittografia in transito (TLS) abilitata e il **user-group-ids** parametro con il valore. `my-user-group-id`
Per 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"
```
Per 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"
```
Prendere nota dell'ID `PendingChanges` nella risposta. Tutte le modifiche apportate a una cache vengono aggiornate in modo asincrono. Puoi monitorare l'avanzamento visualizzando gli eventi. Per ulteriori informazioni, consulta [Visualizzazione ElastiCache degli eventi](ECEvents.Viewing.md).
## Migrazione da AUTH a RBAC
Se si utilizza AUTH come descritto in [Autenticazione con il comando Valkey e Redis OSS AUTH](auth.md) e si desidera migrare all'utilizzo di RBAC, utilizzare le seguenti procedure.
Utilizzare la procedura seguente per migrare da AUTH a RBAC utilizzando la console.
**Per migrare da Valkey o Redis OSS AUTH a RBAC utilizzando la console**
1. Accedi a e apri la console all'indirizzo.Console di gestione AWS ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dall'elenco nell'angolo in alto a destra, scegli la AWS regione in cui si trova la cache che desideri modificare.
1. Nel pannello di navigazione, scegli il motore che gira sulla cache che desideri modificare.
Viene visualizzato un elenco di cache che eseguono il motore scelto.
1. Nell'elenco delle cache, scegli il nome della cache che desideri modificare.
1. Per **Operazioni**, scegli **Modifica**.
Viene visualizzata la finestra **Modifica**.
1. Per **Controllo accessi** scegli **Lista di controllo accessi del gruppo di utenti**.
1. Per **Lista di controllo accessi del gruppo di utenti** scegli un gruppo di utenti.
1. Scegli **Visualizza l'anteprima delle modifiche** e quindi, nella schermata successiva, seleziona **Modifica**.
Utilizzare la seguente procedura per migrare da Valkey o Redis OSS AUTH a RBAC utilizzando la CLI.
**Per migrare da AUTH a RBAC utilizzando la CLI**
+ Usa il comando `modify-replication-group` come mostrato nell'esempio seguente.
Per 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
```
Per Windows:
```
aws elasticache modify-replication-group --replication-group-id test ^
--auth-token-update-strategy DELETE ^
--user-group-ids-to-add user-group-1
```
## Migrazione da RBAC a AUTH
Se utilizzi RBAC e desideri migrare a Redis OSS AUTH, consulta. [Migrazione da RBAC a AUTH](auth.md#Migrate-From-RBAC-to-AUTH)
**Nota**
Se devi disabilitare il controllo degli accessi su una ElastiCache cache, dovrai farlo tramite.AWS CLI Per ulteriori informazioni, consulta [Disabilitazione del controllo degli accessi su una cache ElastiCache Valkey o Redis OSS](in-transit-encryption-disable.md).
# Rotazione automatica delle password per utenti
Con Gestione dei segreti AWS, puoi sostituire le credenziali codificate nel codice (comprese le password) con una chiamata API a Secrets Manager per recuperare il segreto a livello di codice. Questo approccio aiuta a garantire che il segreto non venga compromesso da qualcuno che esamina il codice, perché semplicemente il segreto non è presente. Inoltre, puoi configurare Secrets Manager affinché ruoti automaticamente il segreto in base a una pianificazione specificata. In questo modo puoi sostituire i segreti a lungo termine con altri a breve termine, contribuendo a ridurre notevolmente il rischio di compromissione.
Utilizzando Secrets Manager, è possibile ruotare automaticamente le password ElastiCache per Redis OSS (ovvero segrete) utilizzando una AWS Lambda funzione fornita da Secrets Manager.
[Per ulteriori informazioni su Gestione dei segreti AWS, consulta What is?Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)
## Come ElastiCache utilizza i segreti
Valkey 7.2 e versioni successive hanno un set di funzionalità equivalente a Redis OSS 7.0. In Redis OSS 6, ElastiCache introdotto [Controllo accessi basato sui ruoli (RBAC)](Clusters.RBAC.md) per proteggere il cluster Valkey o Redis OSS. Questa funzionalità consente di limitare determinate connessioni in termini di comandi che è possibile eseguire e tasti a cui è possibile accedere. Con RBAC, mentre il cliente crea un utente con password, i valori delle password devono essere immessi manualmente in testo normale e sono visibili per l'operatore.
Con Secrets Manager, le applicazioni recuperano la password da Secrets Manager anziché inserirle manualmente e archiviarle nella configurazione dell'applicazione. Per informazioni su come fare, consulta [In che modo ElastiCache gli utenti vengono associati al segreto](#How-User-Secrets-Manager-Associate).
L'utilizzo di segreti comporta un costo. Per informazioni sui prezzi, consulta [Prezzi di AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing/).
## In che modo ElastiCache gli utenti vengono associati al segreto
Secrets Manager manterrà un riferimento per l'utente associato nel campo `SecretString` del segreto. Non ci sarà alcun riferimento al segreto da ElastiCache parte di Side.
```
{
"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
}
```
## Funzione di rotazione Lambda
Per abilitare la rotazione automatica delle password di Secrets Manager, creare una funzione Lambda che interagisce con l'API [modify-user](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-user.html) per aggiornare le password dell'utente.
Per informazioni sul funzionamento, consulta [Come funzione la rotazione](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html#rotate-secrets_how).
**Nota**
Per alcuni AWS servizi, per evitare il confuso scenario sostitutivo, si AWS consiglia di utilizzare sia i tasti di condizione `aws:SourceArn` sia i tasti di condizione `aws:SourceAccount` globale. Tuttavia, se includi la condizione `aws:SourceArn` nella tua policy della funzione di rotazione, la funzione di rotazione può essere utilizzata solo per ruotare il segreto specificato da tale ARN. Ti consigliamo di includere solo la chiave di contesto `aws:SourceAccount` in modo da poter utilizzare la funzione di rotazione per più segreti.
Per eventuali problemi, consulta [Risoluzione dei problemi relativi alla rotazione di AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/troubleshoot_rotation.html).
## Come creare un ElastiCache utente e associarlo a Secrets Manager
Nei passaggi seguenti viene illustrato come creare un utente e associarlo a Secrets Manager:
1. **Creazione di un utente non attivo**
Per 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
```
Per 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
```
Noterai una risposta simile alla seguente:
```
{
"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. **Creazione di un segreto**
Per 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"
}'
```
Per Windows:
```
aws secretsmanager create-secret ^
--name production/ec/user1 ^
--secret-string ^
'{
"user_arn": "arn:aws:elasticache:us-east-1:123456xxxx:user:user1",
"username":"user1"
}'
```
Noterai una risposta simile alla seguente:
```
{
"ARN": "arn:aws:secretsmanager:us-east-1:123456xxxx:secret:production/ec/user1-eaFois",
"Name": "production/ec/user1",
"VersionId": "aae5b963-1e6b-4250-91c6-ebd6c47d0d95"
}
```
1. **Configurazione di una funzione Lambda per ruotare la password **
1. Accedi Console di gestione AWS e apri la console Lambda all'indirizzo [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/elasticache/)
1. Nel riquadro di navigazione, seleziona **Functions** (Funzioni), quindi scegli la funzione da creare. Scegli il nome della funzione, non la casella di controllo alla sua sinistra.
1. Scegli la scheda **Configurazione**.
1. In **General configuration** (Configurazione generale), scegli **Edit** (Modifica), quindi imposta **Timeout** su almeno 12 minuti.
1. Scegli **Save** (Salva).
1. Scegli **Environmental variables** (Variabili di ambiente), quindi imposta le seguenti opzioni:
1. SECRETS\$1MANAGER\$1ENDPOINT – https://secretsmanager.**REGION**.amazonaws.com
1. SECRET\$1ARN – Il nome della risorsa Amazon (ARN) del segreto creato nella Fase 2.
1. USER\$1NAME — Nome utente dell'utente, ElastiCache
1. Scegli **Save** (Salva).
1. Seleziona **Permissions** (Autorizzazioni)
1. In **Execution role** (Ruolo di esecuzione), scegli il nome del ruolo della funzione Lambda da visualizzare sulla console IAM.
1. La funzione Lambda avrà bisogno della seguente autorizzazione per modificare gli utenti e impostare la password:
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. Impostazione della rotazione segreto di Secrets Manager
1. **Utilizzo di Console di gestione AWS, vedi [Impostare la rotazione automatica per AWS i segreti di Secrets Manager utilizzando la console](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_turn-on-for-other.html)**
Per ulteriori informazioni sulla configurazione di una pianificazione della rotazione, consulta la pagina relativa alle [espressioni di pianificazione nella rotazione Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_schedule.html).
1. **Utilizzando il AWS CLI, vedere [Impostare la rotazione automatica per Gestione dei segreti AWS l'utilizzo di AWS Command Line Interface](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets-cli.html)**
# Autenticazione con IAM
**Topics**
+ [Panoramica di](#auth-iam-overview)
+ [Limitazioni](#auth-iam-limits)
+ [Configurazione](#auth-iam-setup)
+ [Connessione](#auth-iam-Connecting)
## Panoramica di
Con IAM Authentication puoi autenticare una connessione a ElastiCache Valkey o Redis OSS utilizzando identitàAWS IAM, quando la cache è configurata per utilizzare Valkey o Redis OSS versione 7 o successiva. Ciò consente di consolidare il modello di sicurezza e semplificare molte attività di sicurezza amministrative. Puoi anche utilizzare l'autenticazione IAM per configurare un controllo granulare degli accessi per ogni singola ElastiCache cache e utente, seguendo i principi delle autorizzazioni con privilegi minimi. ElastiCache IAM Authentication for ElastiCache funziona fornendo un token di autenticazione IAM di breve durata anziché una password ElastiCache utente di lunga durata nell'OSS o nel comando Valkey o Redis. `AUTH` `HELLO` Per ulteriori informazioni sul token di autenticazione IAM, consulta il [processo di firma Signature Version 4](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) nella Guida di riferimento AWS generale e l'esempio di codice riportato di seguito.
Puoi utilizzare le identità IAM e le relative politiche associate per limitare ulteriormente l'accesso a Valkey o Redis OSS. Puoi anche concedere l'accesso agli utenti dei loro provider di identità federati direttamente alle cache Valkey o Redis OSS.
Per utilizzare AWS IAM con ElastiCache, devi prima creare un ElastiCache utente con la modalità di autenticazione impostata su IAM. Quindi puoi creare o riutilizzare un'identità IAM. L'identità IAM necessita di una policy associata per concedere l'`elasticache:Connect`azione alla ElastiCache cache e ElastiCache all'utente. Una volta configurato, puoi creare un token di autenticazione IAM utilizzando AWS le credenziali dell'utente o del ruolo IAM. Infine, è necessario fornire il token di autenticazione IAM di breve durata come password nel client Valkey o Redis OSS durante la connessione alla cache. Un client Valkey o Redis OSS con supporto per il provider di credenziali può generare automaticamente le credenziali temporanee per ogni nuova connessione. ElastiCache eseguirà l'autenticazione IAM per le richieste di connessione degli ElastiCache utenti abilitati a IAM e convaliderà le richieste di connessione con IAM.
## Limitazioni
Durante l'utilizzo dell'autenticazione IAM, valgono le seguenti limitazioni:
+ L'autenticazione IAM è disponibile quando si utilizza ElastiCache per Valkey 7.2 e versioni successive o Redis OSS versione 7.0 e successive.
+ Per gli ElastiCache utenti abilitati a IAM, le proprietà nome utente e id utente devono essere identiche.
+ Il token di autenticazione IAM è valido per 15 minuti. Per connessioni di lunga durata, consigliamo di utilizzare un client Valkey o Redis OSS che supporti un'interfaccia con un provider di credenziali.
+ Una connessione autenticata IAM a ElastiCache Valkey o Redis OSS verrà automaticamente disconnessa dopo 12 ore. La connessione può essere prolungata per 12 ore inviando un comando `AUTH` o `HELLO` con un nuovo token di autenticazione IAM.
+ L'autenticazione IAM non è supportata nei comandi `MULTI EXEC`.
+ Attualmente, l'autenticazione IAM supporta le seguenti chiavi di contesto della condizione globale:
+ Quando si utilizza l'autenticazione IAM con cache serverless, `aws:VpcSourceIp`, `aws:SourceVpc`, `aws:SourceVpce`, `aws:CurrentTime`, `aws:EpochTime` e `aws:ResourceTag/%s` (dalle cache serverless e dagli utenti associati) sono supportate.
+ Quando si utilizza l'autenticazione IAM con i gruppi di replica, `aws:SourceIp` e `aws:ResourceTag/%s` (dai gruppi di replica e dagli utenti associati) sono supportate.
Per ulteriori informazioni sulle chiavi di contesto delle condizioni globali, consultare [Chiavi di contesto delle condizioni globali AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) nella Guida per l'utente di IAM.
## Configurazione
Per impostare l'autenticazione IAM:
1. Crea una cache.
```
aws elasticache create-serverless-cache \
--serverless-cache-name cache-01 \
--description "ElastiCache IAM auth application" \
--engine redis
```
1. Crea un documento della policy di attendibilità IAM per il ruolo, come mostrato di seguito, che consenta all'account di assumere il nuovo ruolo. Salva la policy in un file denominato *trust-policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. Crea un documento della policy IAM, come mostrato di seguito. Salva la policy in un file denominato *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. Crea un ruolo IAM.
```
aws iam create-role \
--role-name "elasticache-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Creare la policy IAM.
```
aws iam create-policy \
--policy-name "elasticache-allow-all" \
--policy-document file://policy.json
```
1. Allega la policy IAM al ruolo.
```
aws iam attach-role-policy \
--role-name "elasticache-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/elasticache-allow-all"
```
1. Crea un nuovo utente attivato da 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. Crea un gruppo di utenti e collega l'utente.
```
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
```
## Connessione
**Connetti con token come password**
È innanzitutto necessario generare il token di autenticazione IAM di breve durata utilizzando una [richiesta prefirmata AWS SigV4](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). Dopodiché, fornisci il token di autenticazione IAM come password quando ti connetti a una cache OSS Valkey o Redis, come mostrato nell'esempio seguente.
```
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();
```
Di seguito è riportata la definizione per `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());
}
}
```
**Connetti con provider di credenziali**
Il codice seguente mostra come eseguire l'autenticazione ElastiCache utilizzando il provider di credenziali di autenticazione 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();
```
Di seguito è riportato un esempio di client Lettuce Redis OSS che include un provider di credenziali per generare IAMAuth TokenRequest automaticamente credenziali temporanee quando necessario.
```
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());
}
}
```
# Autenticazione con il comando Valkey e Redis OSS AUTH
**Nota**
**AUTH**È stato sostituito da. [Controllo accessi basato sui ruoli (RBAC)](Clusters.RBAC.md) Tutte le cache serverless devono utilizzare il controllo degli accessi basato su ruolo (RBAC) per l'autenticazione.
I token o le password di autenticazione Valkey e Redis OSS consentono a Valkey e Redis OSS di richiedere una password prima di consentire ai client di eseguire comandi, migliorando così la sicurezza dei dati. **AUTH**È disponibile solo per i cluster basati su nodi.
**Topics**
+ [Panoramica di AUTH in ElastiCache Valkey e Redis OSS](#auth-overview)
+ [Applicazione dell'autenticazione a un cluster ElastiCache for Valkey e Redis OSS](#auth-using)
+ [Modifica del token AUTH su un cluster esistente](#auth-modifyng-token)
+ [Migrazione da RBAC a AUTH](#Migrate-From-RBAC-to-AUTH)
## Panoramica di AUTH in ElastiCache Valkey e Redis OSS
Quando si utilizza il **AUTH** con il cluster ElastiCache for Valkey e Redis OSS, ci sono alcuni perfezionamenti.
In particolare, fai attenzione a questi vincoli relativi al token AUTH o alla password quando usi AUTH:
+ I token o password devono essere composti da 16–128 caratteri stampabili.
+ I caratteri non alfanumerici sono limitati a (\$1, &, \$1, \$1, ^, <, >, -).
+ L'AUTH può essere abilitato solo per i cluster Valkey o Redis OSS abilitati alla crittografia in transito.
Per configurare un token robusto, si consiglia di seguire una policy per password rigida che richieda, ad esempio, quanto segue:
+ I token o le password devono includere almeno tre dei seguenti tipi di caratteri:
+ Caratteri maiuscoli
+ Caratteri minuscoli
+ Numeri
+ Caratteri non alfanumerici (`!`, `&`, `#`, `$`, `^`, `<`, `>`, `-`)
+ I token o le password non devono contenere una parola del dizionario o una parola del dizionario leggermente modificata.
+ I token o le password non devono essere uguali o simili a quelli di un token usato di recente.
## Applicazione dell'autenticazione a un cluster ElastiCache for Valkey e Redis OSS
È possibile richiedere agli utenti di inserire un token (password) su un server Valkey o Redis OSS protetto da token. Per fare ciò, includi il parametro `--auth-token` (API: `AuthToken`) con il token corretto quando crei il gruppo di replica o il cluster. Includerlo anche in tutti i comandi successivi per il gruppo di replica o il cluster.
La seguente AWS CLI operazione crea un gruppo di replica con la crittografia in transito (TLS) abilitata e il token. **AUTH** `This-is-a-sample-token` Sostituisci il gruppo di sottoreti `sng-test` con uno esistente.
**Parametri chiave**
+ **--engine**— Deve essere `valkey` o. `redis`
+ **--engine-version**— Se il motore è Redis OSS, deve essere 3.2.6, 4.0.10 o successivo.
+ **--transit-encryption-enabled** : obbligatorio per l'autenticazione e la conformità HIPAA.
+ **--auth-token** : obbligatorio per la conformità HIPAA. Questo valore deve essere il token corretto per questo server Valkey o Redis OSS protetto da token.
+ **--cache-subnet-group** : obbligatorio per la conformità HIPAA.
Per 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
```
Per 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
```
## Modifica del token AUTH su un cluster esistente
Per semplificare l'aggiornamento dell'autenticazione, è possibile modificare il **AUTH** token utilizzato su un cluster. Puoi apportare questa modifica se la versione del motore è Valkey 7.2 o successiva o Redis 5.0.6 o successiva. ElastiCache deve inoltre avere la crittografia in transito abilitata.
La modifica del token di autorizzazione supporta due strategie: ROTATE e SET. La strategia ROTATE aggiunge un token AUTH aggiuntivo al server mantenendo il token precedente. La strategia SET aggiorna il server per supportare un solo token AUTH. Effettuare queste richieste di modifica con il parametro `--apply-immediately` per applicare immediatamente le modifiche.
### Rotazione del token AUTH
Per aggiornare un server Valkey o Redis OSS con un nuovo **token AUTH**, chiama l'`ModifyReplicationGroup`API con il `--auth-token` parametro come nuovo **AUTH** token e il `--auth-token-update-strategy` valore ROTATE. Una volta completata la modifica ROTATE, il cluster supporterà il token AUTH precedente oltre a quello specificato nel parametro. `auth-token` Se nessun token AUTH era configurato sul gruppo di replica prima della rotazione del token AUTH, il cluster supporta il token AUTH specificato nel `--auth-token` parametro oltre a supportare la connessione senza autenticazione. Vedi come [Impostazione del token AUTH](#auth-modifying-set) aggiornare il token AUTH da richiedere utilizzando la strategia di aggiornamento SET.
**Nota**
Se prima non si configura il token AUTH, una volta completata la modifica, il cluster non supporterà alcun token AUTH oltre a quello specificato nel parametro auth-token.
Se questa modifica viene eseguita su un server che supporta già due token AUTH, durante questa operazione verrà rimosso anche il token AUTH più vecchio. Ciò consente a un server di supportare fino a due token AUTH più recenti contemporaneamente.
A questo punto, puoi procedere aggiornando il client per utilizzare il token AUTH più recente. Una volta aggiornati i client, è possibile utilizzare la strategia SET in modo che la rotazione del token **AUTH** (spiegata nella sezione seguente) inizi esclusivamente utilizzando il nuovo token.
La seguente AWS CLI operazione modifica un gruppo di replica per ruotare il token. **AUTH** `This-is-the-rotated-token`
Per 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
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id authtestgroup ^
--auth-token This-is-the-rotated-token ^
--auth-token-update-strategy ROTATE ^
--apply-immediately
```
### Impostazione del token AUTH
Per aggiornare un server Valkey o Redis OSS in modo che supporti un singolo **AUTH** token richiesto, chiamate l'operazione `ModifyReplicationGroup` API con il `--auth-token` parametro con lo stesso valore dell'ultimo token AUTH e il parametro con il valore. `--auth-token-update-strategy` `SET` La strategia SET può essere utilizzata solo con un cluster con 2 token AUTH o 1 token AUTH opzionale che utilizzava in precedenza una strategia ROTATE. Una volta completata la modifica, il server supporta solo il token AUTH specificato nel parametro auth-token.
L'AWS CLI operazione seguente modifica un gruppo di replica su cui impostare il token AUTH. `This-is-the-set-token`
Per 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
```
Per Windows:
```
aws elasticache modify-replication-group ^
--replication-group-id authtestgroup ^
--auth-token This-is-the-set-token ^
--auth-token-update-strategy SET ^
--apply-immediately
```
### Abilitazione dell'autenticazione su un cluster esistente
Per abilitare l'autenticazione su un server Valkey o Redis OSS esistente, richiama l'operazione `ModifyReplicationGroup` API. Richiamare `ModifyReplicationGroup` con il parametro `--auth-token` come il nuovo token e `--auth-token-update-strategy` con il valore ROTATE.
Una volta completata la modifica ROTATE, il cluster supporta il **AUTH** token specificato nel `--auth-token` parametro oltre a supportare la connessione senza autenticazione. Una volta aggiornate tutte le applicazioni client per l'autenticazione su Valkey o Redis OSS con il token AUTH, utilizzate la strategia SET per contrassegnare il token AUTH come richiesto. L'abilitazione dell'autenticazione è supportata solo sui server Valkey e Redis OSS con crittografia in transito (TLS) abilitata.
## Migrazione da RBAC a AUTH
Se state autenticando gli utenti con Valkey o Redis OSS Role-Based Access Control (RBAC) come descritto in e desiderate migrare ad AUTH[Controllo accessi basato sui ruoli (RBAC)](Clusters.RBAC.md), utilizzate le seguenti procedure. È possibile eseguire la migrazione mediante console o CLI.
**Per migrare da RBAC a AUTH utilizzando la console**
1. Accedi a Console di gestione AWS e apri la console all'indirizzo. ElastiCache [ https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)
1. Dall'elenco nell'angolo in alto a destra, scegli la AWS regione in cui si trova il cluster che desideri modificare.
1. Nel riquadro di navigazione, scegliere il motore in esecuzione sul cluster da modificare.
Comparirà un elenco dei cluster che eseguono il motore selezionato.
1. Nell'elenco dei cluster, per il cluster che si desidera modificare, scegli il nome.
1. Per **Operazioni**, scegli **Modifica**.
Viene visualizzata la finestra **Modifica**.
1. Per il **controllo degli accessi**, scegli l'accesso utente predefinito **Valkey AUTH o l'accesso utente predefinito** **Redis** OSS AUTH.
1. In **Valkey AUTH token o **Redis OSS AUTH** token**, imposta un nuovo token.
1. Scegli **Visualizza l'anteprima delle modifiche** e quindi, nella schermata successiva, seleziona **Modifica**.
**Per migrare da RBAC a AUTH utilizzando il AWS CLI**
Utilizzate uno dei seguenti comandi per configurare un nuovo **AUTH** token opzionale per il gruppo di replica Valkey o Redis OSS. Tieni presente che un token di autenticazione opzionale consentirà l'accesso non autenticato al gruppo di replica finché il token di autenticazione non sarà contrassegnato come richiesto, utilizzando la strategia di aggiornamento nella fase successiva. `SET`
Per 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
```
Per 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
```
Dopo aver eseguito il comando precedente, è possibile aggiornare le applicazioni Valkey o Redis OSS per l'autenticazione al gruppo di ElastiCache replica utilizzando il token AUTH opzionale appena configurato. Per completare la rotazione del token di autenticazione, utilizzate la strategia `SET` di aggiornamento nel comando successivo di seguito. Questo contrassegnerà il token AUTH opzionale come richiesto. Al termine dell'aggiornamento del token di autenticazione, lo stato del gruppo di replica verrà visualizzato come `ACTIVE` e tutte le connessioni a questo gruppo di replica richiederanno l'autenticazione.
Per 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
```
Per 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
```
Per ulteriori informazioni, consulta [Autenticazione con il comando Valkey e Redis OSS AUTH](#auth).
**Nota**
Se è necessario disabilitare il controllo degli accessi su un ElastiCache cluster, vedere. [Disabilitazione del controllo degli accessi su una cache ElastiCache Valkey o Redis OSS](in-transit-encryption-disable.md)
# Disabilitazione del controllo degli accessi su una cache ElastiCache Valkey o Redis OSS
Segui le istruzioni seguenti per disabilitare il controllo degli accessi su una cache abilitata per Valkey o Redis OSS TLS. La cache avrà uno dei due diversi tipi di configurazioni: accesso utente predefinito AUTH o User group access control list (RBAC). Se la cache è stata creata con la configurazione AUTH, è necessario modificarla nella configurazione RBAC prima di poterla disabilitare rimuovendo i gruppi di utenti. Se la cache è stata creata con la configurazione RBAC, puoi procedere direttamente alla disabilitazione.
**Per disabilitare una cache serverless Valkey o Redis OSS configurata con RBAC**
1. Rimuovi i gruppi di utenti per disabilitare il controllo degli accessi.
```
aws elasticache modify-serverless-cache --serverless-cache-name --remove-user-group
```
1. (Facoltativo) Verifica che nessun gruppo di utenti sia associato alla cache serverless.
```
aws elasticache describe-serverless-caches --serverless-cache-name
{
"..."
"UserGroupId": ""
"..."
}
```
**Per disabilitare una cache Valkey o Redis OSS configurata con un token AUTH**
1. Cambia il token AUTH in RBAC e specifica un gruppo di utenti da aggiungere.
```
aws elasticache modify-replication-group --replication-group-id --auth-token-update-strategy DELETE --user-group-ids-to-add
```
1. Verifica che il token AUTH sia stato disabilitato e che sia stato aggiunto un gruppo di utenti.
```
aws elasticache describe-replication-groups --replication-group-id
{
"..."
"AuthTokenEnabled": false,
"UserGroupIds": [
""
]
"..."
}
```
1. Rimuovi i gruppi di utenti per disabilitare il controllo degli accessi.
```
aws elasticache modify-replication-group --replication-group-id --user-group-ids-to-remove
{
"..."
"PendingModifiedValues": {
"UserGroups": {
"UserGroupIdsToAdd": [],
"UserGroupIdsToRemove": [
""
]
}
"..."
}
```
1. (Facoltativo) Verifica che nessun gruppo di utenti sia associato al cluster. Il campo `AuthTokenEnabled` deve essere impostato su false.
```
aws elasticache describe-replication-groups --replication-group-id
"AuthTokenEnabled": false
```
**Per disabilitare un cluster Valkey o Redis OSS configurato con RBAC**
1. Rimuovi i gruppi di utenti per disabilitare il controllo degli accessi.
```
aws elasticache modify-replication-group --replication-group-id --user-group-ids-to-remove
{
"..."
"PendingModifiedValues": {
"UserGroups": {
"UserGroupIdsToAdd": [],
"UserGroupIdsToRemove": [
""
]
}
"..."
}
```
1. (Facoltativo) Verifica che nessun gruppo di utenti sia associato al cluster. Il campo `AuthTokenEnabled` deve essere impostato su false.
```
aws elasticache describe-replication-groups --replication-group-id
"AuthTokenEnabled": false
```