View a markdown version of this page

Procedimientos recomendados para habilitar el cifrado en tránsito - Amazon ElastiCache
Antes de habilitar el cifrado en tránsito: asegúrese de gestionar correctamente los registros de DNSDurante el cifrado en tránsito: preste atención a cuándo finaliza el proceso de migración

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Procedimientos recomendados para habilitar el cifrado en tránsito

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

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 cliente de Valkey o Redis OSS utilice puntos de conexión antiguos y eliminados, lo que impedirá que se conecte al clúster.

Mientras se migra el clúster de modo sin TLS a uno sin TLS TLS-preferred, se conserva el registro DNS del punto final de configuración del clúster anterior y los nuevos registros DNS del punto final de configuración del clúster se generan en un formato diferente. TLS-enabled los clústeres utilizan un formato de registros DNS diferente al de los clústeres. TLS-disabled ElastiCache conservará ambos registros DNS cuando se configure un clúster para encryption mode: Preferred que Applications y otros clientes OSS de Valkey o Redis puedan cambiar de uno a otro. Durante el proceso se producen los siguientes cambios en los registros DNS: TLS-migration

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

Para clústeres de CME

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

  • Los puntos de conexión de configuración del clúster original para el clúster no activado para TLS permanecerán activos. No habrá tiempo de inactividad cuando el clúster se vuelva a configurar del modo de cifrado TLS “ninguno” a “preferido”.

  • Cuando el clúster se ponga en modo, se generarán nuevos puntos de conexión TLS Valkey o Redis OSS. TLS-preferred Estos nuevos puntos de conexión se resolverán con las mismas IP que los anteriores (no TLS).

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

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

  • Se eliminarán los puntos de conexión antiguos que no estén habilitados para TLS. No habrá tiempo de inactividad en los puntos de conexión del clúster de TLS.

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

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

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

  • El punto de conexión principal y el punto de conexión del lector originales del clúster que no admite TLS permanecerán activos.

  • Se generarán nuevos puntos de conexión principales y del lector de TLS cuando el clúster se establezca en el modo Preferred de TLS. Estos nuevos puntos de conexión se resolverán con las mismas IP que los anteriores (sin TLS).

  • El nuevo punto final principal y el punto final del lector se mostrarán en la ElastiCache consola y en la respuesta a la describe-replication-group API.

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

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

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

El uso sugerido de los registros de DNS

Para clústeres de CME 

  • Utilice el punto de conexión de configuración del clúster en lugar de los registros de DNS por nodo en el código de la aplicación. No se recomienda utilizar nombres de DNS por nodo directamente, ya que es posible que cambien y el código de la aplicación interrumpa la conexión con el clúster.

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

  • No se recomienda tener el punto de conexión de configuración del clúster codificado en la aplicación, ya que se puede cambiar durante este proceso. Una vez completado el cifrado en tránsito, consulte el punto de conexión de configuración del clúster con la API describe-replication-group (tal como se ha demostrado anteriormente [en negrita]) y utilice el DNS que obtendrá como respuesta a partir de ese momento.

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

  • Usa el punto final principal y el punto final del lector en lugar de los nombres DNS de cada nodo en el código de la aplicación, ya que los nombres DNS antiguos por nodo se eliminan y se generan otros nuevos al migrar el clúster de una versión sin TLS a otra. TLS-preferred No se recomienda utilizar nombres de DNS por nodo directamente, ya que es posible que agregue réplicas al 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 de 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 de conexión principal y el punto de conexión del lector codificados en la aplicación no es conveniente, ya que se pueden cambiar durante el proceso de migración de TLS. Una vez finalizada la migración a TLS-preferred , consulte el punto final principal y el punto final del lector con la API describe-replication-group y, a partir de ese momento, utilice el DNS que obtenga como respuesta. De esta forma, podrá realizar un seguimiento de los cambios en los puntos de conexión de forma dinámica.

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

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

  • 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 el proceso de migración de 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, podrá aceptar y atender las conexiones TCP y TLS. TLS-preferred Por lo tanto, no debe crear clientes que intenten establecer conexiones de TLS 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):

  • Uso del servicio de SNS para recibir una notificación cuando se complete el cifrado

  • Uso de la API describe-events que emitirá un evento cuando se complete el cifrado

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

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”)

  • Afirmar que el clúster ha establecido transit_encryption_enabled en Verdadero mediante una consulta a la API describe-replication-group.

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 TLS-preferred modo, la aplicación debería abrir las conexiones TLS 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 conexiones de TCP más claras al motor de Valkey o Redis OSS mediante el comando info en la sección de 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