Bonnes pratiques lors de l’activation du chiffrement en transit - Amazon ElastiCache
Avant d'activer le chiffrement en transit : assurez-vous que les DNS enregistrements sont correctement gérésPendant le chiffrement en transit : faites attention à la fin du processus de migration

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques lors de l’activation du chiffrement en transit

Avant d'activer le chiffrement en transit : assurez-vous que les DNS enregistrements sont correctement gérés

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 OSS client Valkey ou Redis à utiliser des points de terminaison anciens et supprimés, ce qui l'empêchera de se connecter au cluster.

Pendant la migration du cluster de « no » TLS à « TLS préféré », les anciens DNS enregistrements par nœud sont conservés et les nouveaux DNS enregistrements par nœud sont générés dans un format différent. TLSLes clusters activés utilisent un format d'DNSenregistrement différent de celui des non-TLS-enabled clusters. ElastiCache conservera les deux DNS enregistrements lorsqu'un cluster est configuré en mode chiffrement : préféré afin que les applications et les autres OSS clients Valkey ou Redis puissent passer de l'un à l'autre. Les modifications suivantes sont apportées aux DNS enregistrements au cours du processus de TLS migration :

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

Pour les CME clusters

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

  • Les points de terminaison du cluster d'origine pour le cluster non TLS activé resteront actifs. Il n'y aura aucun temps d'arrêt lorsque le cluster passe du mode de TLS chiffrement « aucun » au mode « préféré » à « préféré ».

  • De nouveaux OSS points de terminaison TLS Valkey ou Redis seront générés lorsque le cluster est défini sur le mode -preferred. TLS Ces nouveaux points de terminaison seront résolus de la même manière IPs que les anciens (non-TLS).

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

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

  • Les anciens points de terminaison non TLS activés seront supprimés. Il n'y aura aucune interruption de service des points de terminaison du TLS cluster.

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

Pour les CMD clusters sur lesquels le basculement automatique est activé ou le basculement automatique est 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 et le point de terminaison du lecteur d'origine pour le cluster non TLS activé resteront actifs.

  • De nouveaux points de terminaison TLS principaux et lecteurs seront générés lorsque le cluster sera réglé en TLS Preferred mode. Ces nouveaux points de terminaison utiliseront 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 au describe-replication-groupAPI.

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

  • Les anciens points de terminaison non TLS principaux et de lecture seront supprimés. Il n'y aura aucune interruption de service des points de terminaison du TLS cluster.

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

L'utilisation suggérée des DNS enregistrements

Pour les CME clusters

  • Utilisez le point de terminaison de configuration du cluster plutôt que DNS les enregistrements par nœud dans le code de votre application. Il n'est pas recommandé d'utiliser directement les DNS noms par nœud, 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 avec le describe-replication-group API (comme illustré ci-dessus (en gras)) et utilisez la réponse DNS que vous obtiendrez à partir de maintenant.

Pour les CMD clusters sur lesquels le basculement automatique est activé

  • Utilisez le point de terminaison principal et le point de terminaison du lecteur plutôt que les DNS noms par nœud dans le code de votre application, car les anciens DNS noms par nœud sont supprimés et de nouveaux sont générés lors de la migration du cluster de no- TLS à -preferred. TLS L'utilisation directe de DNS noms par nœud n'est pas recommandée car vous pourriez ajouter des répliques à 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 lecteur dans votre application, car ils peuvent être modifiés au cours du processus de TLS migration. Une fois le changement de migration vers TLS -preferred terminé, interrogez le point de terminaison principal et le point de terminaison du lecteur avec le 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 CMD clusters dont le basculement automatique est désactivé

  • Utilisez le point de terminaison principal et le point de terminaison du lecteur plutôt que les DNS noms 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. Étant donné que les anciens DNS noms par nœud sont supprimés et que de nouveaux sont générés lors de la migration du cluster de no- TLS à TLS -preferred, n'utilisez pas directement les noms par DNS nœud. Ceci est obligatoire pour que les clients puissent se connecter au cluster pendant la TLS migration. Vous aurez également avantage à répartir uniformément les lectures entre les répliques lorsque vous utilisez le point de terminaison du lecteur et à suivre les DNS enregistrements lors de l'ajout ou de la suppression de répliques 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 TLS migration.

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 a terminé la migration vers TLS -preferred qu'il est en mesure d'accepter et de servir à la fois les TCP TLS connexions. Par conséquent, vous ne devez pas créer de clients qui essaieront d'établir des TLS connexions au 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 SNS service pour recevoir une notification lorsque le chiffrement est terminé

  • L'utilisation du describe-events API qui émettra un événement lorsque le chiffrement sera 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 est transit_encryption_enabled défini sur True en interrogeant le. describe-replication-group API

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 TLS connexions au cluster et n'utiliser que 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'y a pas de TCP connexions plus claires avec le OSS moteur Valkey ou Redis en utilisant la commande info dans la SSL section.

# 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