Procedimientos recomendados para habilitar el cifrado en tránsito - Amazon ElastiCache (RedisOSS)
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 OSS de 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 sin TLS a TLS preferido, se conservan los registros de DNS antiguos por nodo y los nuevos registros de DNS por nodo se generan en un formato diferente. Los clústeres habilitados para TLS utilizan un formato de registros DNS diferente al de los clústeres no habilitados para TLS. ElastiCache conservará ambos registros DNS cuando un clúster esté configurado en modo de cifrado: se prefiere para que Applications y otros clientes de Redis OSS puedan cambiar de uno a otro. Durante el proceso de migración de TLS se producen los siguientes cambios en los registros de DNS:

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 del clúster original para el clúster no habilitado 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”.

  • Se generarán nuevos puntos de conexión TLS Redis OSS cuando el clúster se configure en el modo TLS preferido. 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 Redis OSS se mostrará 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 describe-replication-group API.

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 de conexión 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 al agregar o eliminar particiones.

  • 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 de conexión de configuración del clúster con la API describe-replication-group (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 

  • 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, ya que los nombres de DNS antiguos por nodo se eliminan y se generan otros nuevos al migrar el clúster de sin TLS a TLS preferido. 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 poder 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. Cuando se complete el cambio de migración a TLS-Preferred, consulte el punto final principal y el punto final del lector con la describe-replication-group API y utilice el DNS que obtenga como respuesta 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 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 de DNS antiguos por nodo se eliminan y se generan otros nuevos al migrar el clúster de sin TLS a TLS preferido, no utilice los nombres de DNS por nodo directamente. Esto es obligatorio para que los clientes puedan conectarse al clúster durante la migración de TLS. Además, se beneficiará de distribuir las lecturas de manera uniforme entre las réplicas cuando utilice el punto de conexión del lector y de llevar un registro de los registros de DNS al agregar 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 a TLS preferido podrá aceptar y ofrecer conexiones de TCP y TLS. 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 el cifrado ha finalizado

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 el modo TLS preferido, la aplicación debe abrir conexiones de TLS al clúster y utilizar solo 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 TCP más claras al motor OSS de Redis mediante el comando Redis OSS info de 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