Best practice per abilitare la crittografia dei dati in transito - Amazon ElastiCache
Prima di abilitare la crittografia in transito: assicurati di avere una corretta gestione DNS dei recordDurante la crittografia dei dati in transito: prestare attenzione a quando il processo di migrazione termina

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 in transito: assicurati di avere una corretta gestione DNS dei record

Nota

Stiamo modificando ed eliminando i vecchi endpoint durante questo processo. L'uso scorretto degli endpoint può far sì che il OSS client Valkey o Redis utilizzi endpoint vecchi ed eliminati che ne impediranno la connessione al cluster.

Durante la migrazione del cluster da no- TLS a TLS -preferred, i vecchi record per nodo vengono conservati e i nuovi DNS record per nodo vengono generati in un formato diversoDNS. TLSi cluster abilitati utilizzano un formato di record diverso rispetto ai cluster. DNS non-TLS-enabled ElastiCache conserverà entrambi i DNS record quando un cluster è configurato in modalità di crittografia: preferibile in modo che Applications e altri OSS client Valkey o Redis possano passare da uno all'altro. Le seguenti modifiche nei DNS record avvengono durante il processo di migrazioneTLS:

Descrizione delle modifiche nei DNS record che avvengono quando si abilita la crittografia in transito

Per CME i cluster

Quando un cluster è impostato sulla ‘modalità di crittografia dei dati in transito: preferred’:

  • Gli endpoint del cluster originali per i cluster non TLS abilitati rimarranno attivi. Non si verificheranno tempi di inattività quando il cluster verrà riconfigurato dalla modalità di TLS crittografia da «nessuna» a «preferita».

  • I nuovi OSS endpoint TLS Valkey o Redis verranno generati quando il cluster è impostato sulla modalità -preferred. TLS Questi nuovi endpoint si risolveranno IPs come quelli precedenti (non-). TLS

  • Il nuovo endpoint di OSS configurazione TLS Valkey o Redis verrà esposto nella ElastiCache console e nella risposta a. describe-replication-group API

Quando un cluster è impostato sulla ‘modalità di crittografia dei dati in transito: required’:

  • I vecchi endpoint non TLS abilitati verranno eliminati. Non ci saranno tempi di inattività degli endpoint del TLS cluster.

  • È possibile recuperarne uno nuovo cluster-configuration-endpoint dalla ElastiCache console o dal. describe-replication-group API

Per CMD i cluster 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 cluster non TLS abilitati rimarranno attivi.

  • Quando il cluster viene impostato sulla modalità, verranno generati nuovi endpoint TLS primari e di lettura. TLS Preferred Questi nuovi endpoint verranno risolti sugli stessi IP di quelli precedenti (non-TLS).

  • Il nuovo endpoint primario e l'endpoint di lettura verranno esposti nella ElastiCache Console e nella risposta a. describe-replication-group API

Quando il gruppo di replica è impostato sulla ‘modalità di crittografia dei dati in transito: required’:

  • I vecchi endpoint non TLS primari e di lettura verranno eliminati. Non ci saranno tempi di inattività degli endpoint del TLS cluster.

  • È possibile recuperare nuovi endpoint primari e di lettura dalla ElastiCache Console o da. describe-replication-group API

L'utilizzo suggerito dei record DNS

Per i CME cluster

  • Utilizza l'endpoint di configurazione del cluster anziché i DNS record per nodo nel codice dell'applicazione. Non è consigliabile utilizzare direttamente DNS i nomi per nodo perché potrebbero cambiare quando si aggiungono o si rimuovono gli shard.

  • 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. Una volta completata la crittografia in transito, interroga l'endpoint di configurazione del cluster con describe-replication-group API (come illustrato sopra (in grassetto)) e utilizza la risposta DNS che otterrai da questo momento in poi.

Per i CMD cluster con failover automatico abilitato

  • Utilizzate l'endpoint primario e l'endpoint di lettura anziché i nomi per nodo nel codice dell'applicazione, poiché i vecchi DNS nomi per nodo vengono eliminati e ne vengono generati di nuovi durante la migrazione del cluster da no- a DNS -preferred. TLS TLS L'uso diretto di DNS nomi per nodo non è consigliato perché in futuro potresti aggiungere repliche al tuo cluster. 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 pratica scorretta, in quanto 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 di lettura con il comando che riceverai in risposta da questo momento in describe-replication-group API poi. DNS In questo modo sarai in grado di tenere traccia delle modifiche negli endpoint in modo dinamico.

Per CMD cluster con failover automatico disabilitato

  • Utilizza l'endpoint principale e l'endpoint di lettura anziché i DNS nomi 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 DNS nomi per nodo vengono eliminati e ne vengono generati di nuovi durante la migrazione del cluster da no- TLS a TLS -preferred, non utilizzare direttamente i nomi per nodo. DNS Questo è obbligatorio per consentire ai client di connettersi al cluster durante la migrazione. TLS Inoltre, trarrete vantaggio dalla distribuzione uniforme delle letture tra le repliche quando utilizzate l'endpoint reader e tenete traccia dei DNS record quando aggiungete o eliminate le repliche dal cluster.

  • Avere l'endpoint di configurazione del cluster codificato nell'applicazione è una pratica scorretta, in quanto 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 a TLS -preferred è in grado di accettare e servire entrambe le connessioni. TCP TLS Pertanto, non è necessario creare client che tenteranno di stabilire TLS connessioni al cluster fino al completamento della crittografia in transito.

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 SNS servizio per ricevere una notifica quando la crittografia è completata

  • L'utilizzo di describe-events API that emetterà 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“)

  • Affermare che il cluster è transit_encryption_enabled impostato su True interrogando il. describe-replication-group API

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 dovrebbe aprire TLS le connessioni 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 TCP connessioni più chiare al OSS motore Valkey o Redis 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