Procedimientos recomendados para habilitar el cifrado en tránsito

Antes de habilitar el cifrado en tránsito: asegúrese de gestionar los DNS registros de forma adecuada

nota

Durante este proceso, cambiaremos y eliminaremos los puntos de conexión antiguos. El uso incorrecto de los puntos de conexión puede provocar que el OSS cliente de Valkey o Redis utilice puntos de conexión antiguos y eliminados, lo que impedirá que se conecte al clúster.

Mientras se migra el clúster de no preferente TLS a TLS preferencial, se conservan los registros antiguos por nodo y los nuevos DNS registros por nodo se generan en un formato DNS diferente. TLSLos clústeres habilitados para -utilizan un formato de registro diferente al de los DNS clústeres. non-TLS-enabled ElastiCache conservará ambos DNS registros cuando un clúster esté configurado en modo de cifrado: se prefiere para que Applications y otros OSS clientes de Valkey o Redis puedan cambiar de uno a otro. Los siguientes cambios en los DNS registros se producen durante el proceso TLS de migración:

Descripción de los cambios en los DNS registros que se producen al habilitar el cifrado en tránsito

Para CME clústeres

Cuando un clúster está configurado en “modo de cifrado de tránsito: preferido”:

• Los puntos finales del clúster original del clúster no TLS habilitado permanecerán activos. No habrá tiempo de inactividad cuando el clúster se vuelva a configurar del modo de TLS cifrado «ninguno» al «preferido».

• Cuando el clúster se configure en el modo preferido, se generarán nuevos OSS puntos finales de TLS Valkey o Redis. TLS Estos nuevos puntos finales se resolverán IPs igual que los anteriores (no). TLS

• El nuevo punto final de OSS configuración de TLS Valkey o Redis aparecerá en la ElastiCache consola y en la respuesta a. describe-replication-group API

Cuando un clúster está configurado en “modo de cifrado de tránsito: requerido”:

• Se eliminarán los puntos finales antiguos no TLS habilitados. No habrá tiempo de inactividad en los puntos finales del TLS clúster.

• Puede recuperar uno nuevo cluster-configuration-endpoint desde la ElastiCache consola o desde el describe-replication-groupAPI.

Para CMD clústeres con la conmutación por error automática habilitada o desactivada

Cuando el grupo de replicación está establecido en “modo de cifrado de tránsito: preferido”:

• El punto final principal y el punto final del lector originales del clúster no TLS activado permanecerán activos.

• Cuando el clúster se ponga en TLS Preferred modo, se generarán nuevos puntos finales TLS principales y de lectura. Estos nuevos puntos finales se resolverán con las mismas IP que los anteriores (no). TLS

• El nuevo punto final principal y el punto final del lector aparecerán en la ElastiCache consola y en la respuesta a la describe-replication-groupAPI.

Cuando el grupo de replicación está establecido en “modo de cifrado de tránsito: requerido”:

• Se eliminarán los puntos finales antiguos que no sean TLS principales y los de lectura. No habrá tiempo de inactividad en los puntos finales del TLS clúster.

• Puede recuperar los nuevos puntos finales principales y de lectura desde la ElastiCache consola o desde el. describe-replication-group API

El uso sugerido de los registros DNS

Para CME clústeres

• Utilice el punto final de configuración del clúster en lugar de los DNS registros por nodo en el código de la aplicación. No se recomienda usar directamente DNS los nombres de cada nodo, ya que pueden cambiar al agregar o quitar fragmentos.

• No codifique el punto de conexión de configuración del clúster en la aplicación, ya que cambiará durante este proceso.

• Tener el punto de conexión de configuración del clúster codificado en la aplicación no es conveniente, ya que se puede cambiar durante este proceso. Una vez completado el cifrado en tránsito, consulte el punto final de configuración del clúster con el símbolo describe-replication-group API (como se ha demostrado anteriormente (en negrita)) y utilice la respuesta DNS que obtenga a partir de ahora.

Para CMD clústeres con la conmutación por error automática habilitada

• Utilice el punto de conexión principal y el punto final del lector en lugar de los DNS nombres de cada nodo en el código de la aplicación, ya que los DNS nombres antiguos de cada nodo se eliminan y se generan otros nuevos al migrar el clúster de no a preferente. TLS TLS No se recomienda usar DNS nombres por nodo directamente, ya que podría agregar réplicas a su clúster en el futuro. Además, cuando la conmutación por error automática está habilitada, el ElastiCache servicio cambia automáticamente las funciones del clúster principal y las réplicas, por lo que se recomienda utilizar el punto final principal y el punto final del lector para ayudarle a realizar un seguimiento de esos cambios. Por último, utilizar el punto de conexión del lector le ayudará a distribuir las lecturas de las réplicas de manera equitativa entre las réplicas del clúster.

• Tener el punto final principal y el punto final del lector codificados en la aplicación es una mala práctica, ya que se pueden cambiar durante el TLS proceso de migración. Una vez que se haya completado el cambio de migración a TLS -preferred, consulte el punto final principal y el punto final del lector con el comando describe-replication-group API -preferred y utilice la respuesta DNS que obtenga a partir de ese momento. De esta forma, podrá realizar un seguimiento de los cambios en los puntos de conexión de forma dinámica.

Para un CMD clúster con la conmutación por error automática desactivada

• Utilice el punto final principal y el punto final del lector en lugar de los DNS nombres de cada nodo en el código de la aplicación. Si la conmutación por error automática está desactivada, usted se encarga de realizar el escalado, los parches, la conmutación por error y otros procedimientos que el ElastiCache servicio gestiona automáticamente cuando la conmutación por error automática está habilitada. Esto le facilita la realización manual del seguimiento de los distintos puntos de conexión. Dado que los DNS nombres antiguos de cada nodo se eliminan y se generan otros nuevos al migrar el clúster de «no» TLS a «TLSpreferido», no utilice directamente los nombres por nodo. DNS Esto es obligatorio para que los clientes puedan conectarse al clúster durante la migración. TLS Además, te beneficiarás de distribuir uniformemente las lecturas entre las réplicas cuando utilices el terminal del lector y de llevar un registro de los DNS registros al añadir o eliminar réplicas del clúster.

• Tener el punto final de configuración del clúster codificado en la aplicación es una mala práctica, ya que se puede cambiar durante el proceso de migración. TLS

Durante el cifrado en tránsito: preste atención a cuándo finaliza el proceso de migración

El cambio del modo de cifrado de tránsito no es inmediato y puede llevar algún tiempo. Esto es especialmente cierto en el caso de los clústeres grandes. Solo cuando el clúster finalice la migración a TLS -preferred, podrá aceptar y atender tanto TCP las conexiones como las demás. TLS Por lo tanto, no debe crear clientes que intenten establecer TLS conexiones con el clúster hasta que se complete el cifrado en tránsito.

Hay varias formas de recibir notificaciones cuando el cifrado en tránsito se completa correctamente o no funciona: (No se muestra en el ejemplo de código anterior):

• Utilizar el SNS servicio para recibir una notificación cuando se complete el cifrado

• Usar el describe-events API que emitirá un evento cuando se complete el cifrado

• Ver un mensaje en la ElastiCache consola que indica que el cifrado se ha completado

También puede implementar la lógica en la aplicación para saber si se ha completado el cifrado. En el ejemplo anterior, vimos varias formas de garantizar que el clúster finalice la migración:

• Esperar a que comience el proceso de migración (el estado del clúster cambia a “modificándose”) y esperar a que finalice la modificación (el estado del clúster vuelve a ser “disponible”)

• Para confirmar que el clúster se ha transit_encryption_enabled establecido en True, consulte el. describe-replication-group API

Después de habilitar el cifrado en tránsito: asegúrese de que los clientes que utiliza estén configurados correctamente

Mientras el clúster esté en el modo TLS preferido, la aplicación debería abrir TLS las conexiones al clúster y utilizar únicamente esas conexiones. De esta forma, la aplicación no sufrirá tiempo de inactividad al habilitar el cifrado en tránsito. Puede asegurarse de que no haya TCP conexiones más claras con el OSS motor Valkey o Redis mediante el comando info que aparece en la sección. 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