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 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 de DNS diferente al de los clústeres no habilitados para TLS. ElastiCache conservará ambos registros de DNS cuando un clúster esté configurado en modo de cifrado: se prefiere para que las aplicaciones y otros clientes de Valkey o 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 de TLS de Valkey o Redis OSS cuando el clúster se establezca en el modo preferido de TLS. Estos nuevos puntos de conexión se resolverán con las mismas IP que los anteriores (no TLS).

• El nuevo punto de conexión de configuración de TLS de Valkey o Redis OSS se mostrará en la consola de ElastiCache 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 un nuevo cluster-configuration-endpoint desde la consola de ElastiCache 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 punto de conexión principal y el punto de conexión del lector nuevos se mostrarán en la consola de ElastiCache y en la respuesta a la API describe-replication-group.

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 nuevos puntos de conexión principales y del lector desde la consola de ElastiCache o desde la API describe-replication-group.

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 servicio de ElastiCache cambia automáticamente los roles del clúster principal y las réplicas. Se recomienda utilizar el punto de conexión principal y el punto de conexión del lector para ayudarlo 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 finalizado el cambio de migración a TLS preferido, consulte el punto de conexión principal y el punto de conexión del lector con la API describe-replication-group y utilice el DNS que obtendrá como respuesta a partir de ahora. 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. Cuando la conmutación por error automática está desactivada, usted se encarga de escalar, aplicar parches, conmutación por error y otros procedimientos que el servicio de ElastiCache administra 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 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 consola de ElastiCache 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 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 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