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 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, i vecchi record DNS per nodo vengono conservati e i nuovi record DNS per nodo vengono generati in un formato diverso. I cluster abilitati per TLS utilizzano un formato di record DNS diverso rispetto ai cluster non abilitati per TLS. ElastiCache conserverà entrambi i record DNS quando un cluster è configurato in modalità di crittografia: preferibile in modo che Applications e altri client 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’:

• Gli endpoint del cluster originali per cluster non abilitati per TLS rimarranno attivi. Non ci saranno tempi di inattività quando il cluster viene riconfigurato dalla modalità di crittografia TLS ‘none’ a ‘preferred’.

• I nuovi endpoint TLS 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 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'utilizzo diretto dei nomi DNS per nodo non è consigliato perché potrebbero cambiare quando si aggiungono o si rimuovono partizioni.

• Non codificare l'endpoint di configurazione del cluster nell'applicazione, poiché questo cambierà durante questo processo.

• Avere l'endpoint di configurazione del cluster codificato nell'applicazione è una bad practice poiché può essere modificato durante questo processo. Al termine della crittografia dei dati in transito, esegui query sull'endpoint di configurazione del cluster con l'API describe-replication-group (come illustrato sopra in grassetto) e utilizza il DNS che ricevi in risposta da questo punto in avanti.

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 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 migrazione a TLS-Preferred, interroga l'endpoint primario e l'endpoint di lettura con l' describe-replication-group API 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 vi siano connessioni TCP più chiare al motore Redis OSS utilizzando il comando Redis OSS 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