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à.
# 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. TLS-enabled i cluster utilizzano un formato di record DNS diverso rispetto ai cluster. TLS-disabled 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. Durante il processo avvengono le seguenti modifiche nei record DNS: TLS-migration
### 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 negli stessi IP di quelli vecchi (non TLS).
+ Il nuovo endpoint di configurazione TLS Valkey o Redis OSS verrà esposto nella console e nella risposta all'ElastiCache 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à.
+ Avere l'endpoint di configurazione del cluster integrato nell'applicazione è una cattiva pratica, poiché 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 principale 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 ne vengono generati di nuovi 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 primario 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 modifica della migrazione a TLS-preferred , interroga l'endpoint primario e l'endpoint reader con l'API describe-replication-group 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 servizio quando il failover automatico è abilitato vengono invece eseguite dall'utente. ElastiCache Ciò consente di tenere traccia dei diversi endpoint manualmente. Poiché i vecchi nomi DNS per nodo vengono eliminati e ne vengono generati di nuovi durante la migrazione del cluster da No-TLS a, non utilizzare direttamente i nomi DNS per nodo. TLS-preferred Questo è obbligatorio in modo che i client possano connettersi al cluster durante il. TLS-migration Inoltre, potrai trarre vantaggio dalla distribuzione uniforme delle letture tra le repliche quando utilizzi l'endpoint di lettura e dalla possibilità di tenere traccia di DNS-records quando aggiungi o elimini le 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 quando il cluster termina la migrazione verso TLS-preferred è 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 TLS-preferred modalità, l'applicazione dovrebbe aprire le 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. È possibile assicurarsi che non vi siano connessioni TCP più chiare al motore Valkey o Redis OSS utilizzando 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
```