Bonnes pratiques lors de l’activation du chiffrement en transit

Avant d'activer le chiffrement en transit : veillez à gérer correctement les enregistrements DNS

Note

Nous modifions et supprimons les anciens points de terminaison au cours de ce processus. Une utilisation incorrecte des points de terminaison peut amener le client Redis OSS à utiliser des points de terminaison anciens et supprimés, ce qui l'empêchera de se connecter au cluster.

Pendant la migration du cluster d'un protocole non compatible avec TLS vers un protocole TLS préféré, les anciens enregistrements DNS par nœud sont conservés et les nouveaux enregistrements DNS par nœud sont générés dans un format différent. Les clusters compatibles TLS utilisent un format d'enregistrement DNS différent de celui des clusters non compatibles TLS. ElastiCache conservera les deux enregistrements DNS lorsqu'un cluster est configuré en mode cryptage : préféré afin que les applications et les autres clients Redis OSS puissent passer de l'un à l'autre. Les modifications suivantes sont apportées aux enregistrements DNS au cours du processus de migration TLS :

Description des modifications apportées aux enregistrements DNS lors de l'activation du chiffrement en transit

Pour les clusters CME

Lorsqu'un cluster est réglé sur « mode de chiffrement en transit : préféré » :

• Les points de terminaison d'origine du cluster pour les clusters non compatibles avec TLS restent actifs. Il n'y a aucun temps d'arrêt lorsque le cluster est reconfiguré du mode de chiffrement TLS « sans » au mode « préféré ».

• De nouveaux points de terminaison TLS Redis OSS seront générés lorsque le cluster sera défini sur le mode TLS préféré. Ces nouveaux points de terminaison adoptent les mêmes adresses IP que les anciens (non TLS).

• Le nouveau point de terminaison de configuration TLS Redis OSS sera exposé dans la ElastiCache console et dans la réponse à describe-replication-group l'API.

Lorsqu'un cluster est réglé sur « mode de chiffrement en transit : obligatoire » :

• Les anciens points de terminaison non compatibles avec le protocole TLS sont supprimés. Les points de terminaison de cluster TLS ne sont pas interrompus.

• Vous pouvez en récupérer un nouveau cluster-configuration-endpoint depuis ElastiCache la console ou depuis l'describe-replication-groupAPI.

Pour les clusters CMD avec basculement automatique activé ou désactivé

Lorsqu'un groupe de réplication est réglé sur « mode de chiffrement en transit : préféré » :

• Le point de terminaison principal d'origine et le point de terminaison du lecteur pour un cluster non compatible avec TLS restent actifs.

• De nouveaux points de terminaison principaux et du lecteur TLS sont générés lorsque le cluster est réglé sur le mode TLS Preferred. Ces nouveaux points de terminaison adoptent la ou les mêmes adresses IP que les anciens (non TLS).

• Le nouveau point de terminaison principal et le nouveau point de terminaison du lecteur seront exposés dans la ElastiCache console et dans la réponse à l'describe-replication-groupAPI.

Lorsqu'un groupe de réplication est réglé sur « mode de chiffrement en transit : obligatoire » :

• Les anciens points de terminaison principaux et du lecteur non compatibles avec TLS sont supprimés. Les points de terminaison de cluster TLS ne sont pas interrompus.

• Vous pouvez récupérer les nouveaux points de terminaison principaux et lecteurs depuis ElastiCache la console ou depuis l'describe-replication-groupAPI.

L'utilisation suggérée des enregistrements DNS

Pour les clusters CME

• Utilisez le point de terminaison de configuration du cluster plutôt que les enregistrements DNS par nœud dans le code de votre application. L'utilisation directe de noms DNS par nœud n'est pas recommandée car ils peuvent changer lors de l'ajout ou de la suppression de partitions.

• Ne codez pas en dur le point de terminaison de configuration du cluster dans votre application car il va changer au cours de ce processus.

• Il est déconseillé de coder en dur le point de terminaison de configuration du cluster dans votre application car il peut être modifié au cours de ce processus. Une fois le chiffrement en transit terminé, interrogez le point de terminaison de configuration du cluster à l'aide de l'API describe-replication-group (comme indiqué ci-dessus (en gras)) et utilisez le DNS que vous obtenez en réponse à partir de ce moment.

Pour les clusters CMD avec basculement automatique activé

• Utilisez le point de terminaison principal et le point de terminaison du lecteur plutôt que les noms DNS par nœud dans le code de votre application, car les anciens noms DNS par nœud sont supprimés et de nouveaux sont générés lors de la migration du cluster d'un protocole non compatible avec TLS vers TLS préféré. L'utilisation directe de noms DNS par nœud n'est pas recommandée si vous choisissez d'ajouter des réplicas à votre cluster à l'avenir. De plus, lorsque le basculement automatique est activé, les rôles du cluster principal et des répliques sont modifiés automatiquement par le ElastiCache service. Il est suggéré d'utiliser le point de terminaison principal et le point de terminaison du lecteur pour vous aider à suivre ces modifications. Enfin, l'utilisation du point de terminaison du lecteur vous permet de répartir vos lectures provenant des réplicas de manière égale entre les réplicas du cluster.

• Il est déconseillé de coder en dur le point de terminaison principal et le point de terminaison du lecteur dans votre application, car cela peut être modifié au cours du processus de migration TLS. Une fois le changement de migration vers TLS-Preferred terminé, interrogez le point de terminaison principal et le point de terminaison du lecteur avec l' describe-replication-group API et utilisez le DNS que vous obtenez en réponse à partir de ce moment. De cette façon, vous pouvez suivre l'évolution des points de terminaison de manière dynamique.

Pour les clusters CMD avec basculement automatique désactivé

• Utilisez le point de terminaison principal et le point de terminaison du lecteur plutôt que les noms DNS par nœud dans le code de votre application. Lorsque le basculement automatique est désactivé, c'est vous qui effectuez le dimensionnement, les correctifs, le basculement et les autres procédures gérées automatiquement par le ElastiCache service lorsque le basculement automatique est activé. Vous pouvez ainsi plus facilement effectuer un suivi manuel des différents points de terminaison. Puisque les anciens noms DNS par nœud sont supprimés et que de nouveaux sont générés lors de la migration du cluster du mode non compatible avec TLS vers TLS préféré, n'utilisez pas directement les noms DNS par nœud. Cela est obligatoire pour que les clients puissent se connecter au cluster pendant la migration vers TLS. Vous bénéficiez également de la répartition uniforme des lectures entre les réplicas lorsque vous utilisez le point de terminaison du lecteur et du suivi des enregistrements DNS lors de l'ajout ou de la suppression de réplicas dans le cluster.

• Il est déconseillé de coder en dur le point de terminaison de configuration du cluster dans votre application car il peut être modifié au cours du processus de migration TLS.

Pendant le chiffrement en transit : faites attention à la fin du processus de migration

Le passage au mode de chiffrement en transit n'est pas immédiat et peut prendre un certain temps. Cela est particulièrement vrai pour les grands clusters. Ce n'est que lorsque le cluster termine la migration vers TLS préféré qu'il est en mesure d'accepter et de gérer à la fois les connexions TCP et TLS. Par conséquent, vous ne devez pas créer de clients qui essaient d'établir des connexions TLS avec le cluster tant que le chiffrement en transit n'est pas terminé.

Il existe plusieurs manières d'être averti lorsque le chiffrement en transit est terminé avec succès ou a échoué : (non illustré dans l'exemple de code ci-dessus) :

• Utilisation du service SNS pour recevoir une notification lorsque le chiffrement est terminé

• Utilisation de l'API describe-events qui émet un événement lorsque le chiffrement est terminé

• Affichage d'un message dans la ElastiCache console indiquant que le chiffrement est terminé

Vous pouvez également implémenter une logique dans votre application pour savoir si le chiffrement est terminé. Dans l'exemple ci-dessus, nous avons vu plusieurs manières de nous assurer que le cluster termine la migration :

• Attendre le début du processus de migration (le statut du cluster passe à « en cours de modification ») et attendre que la modification soit terminée (le statut du cluster redevient « disponible »)

• Affirmer que le cluster a transit_encryption_enabled défini sur True en interrogeant l'API describe-replication-group.

Après avoir activé le chiffrement en transit : veillez à ce que les clients que vous utilisez soient correctement configurés

Lorsque le cluster est en mode TLS préféré, votre application doit ouvrir des connexions TLS vers le cluster et utiliser uniquement ces connexions. Ainsi, votre application ne connaît pas d'interruption lors de l'activation du chiffrement en transit. Vous pouvez vous assurer qu'il n'existe pas de connexions TCP plus claires avec le moteur Redis OSS à l'aide de la commande Redis OSS info dans la section 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