Bewährte Methoden für die Aktivierung der Verschlüsselung während der Übertragung - Amazon ElastiCache
Bevor Sie die Verschlüsselung bei der Übertragung aktivieren: Stellen Sie sicher, dass Sie über die richtige Verarbeitung von DNS Datensätzen verfügenBei der Verschlüsselung während der Übertragung: darauf achten, wann der Migrationsprozess abgeschlossen ist

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden für die Aktivierung der Verschlüsselung während der Übertragung

Bevor Sie die Verschlüsselung bei der Übertragung aktivieren: Stellen Sie sicher, dass Sie über die richtige Verarbeitung von DNS Datensätzen verfügen

Anmerkung

Während dieses Prozesses ändern und löschen wir alte Endpunkte. Eine falsche Verwendung der Endpunkte kann dazu führen, dass der Valkey- oder OSS Redis-Client alte und gelöschte Endpunkte verwendet, sodass keine Verbindung zum Cluster hergestellt werden kann.

Während der Migration des Clusters von „Nein“ TLS zu „TLSbevorzugt“ werden die alten Einträge pro Knoten beibehalten und die neuen DNS Datensätze pro Knoten werden in einem anderen Format generiertDNS. TLS-aktivierte Cluster verwenden ein anderes Datensatzformat als Cluster. DNS non-TLS-enabled ElastiCache behält beide DNS Datensätze bei, wenn ein Cluster im Verschlüsselungsmodus konfiguriert ist: Vorgezogen, damit Anwendungen und andere Valkey- oder OSS Redis-Clients zwischen ihnen wechseln können. Die folgenden Änderungen in den DNS Datensätzen finden während des TLS -Migrationsprozesses statt:

Beschreibung der Änderungen in den DNS Datensätzen, die bei der Aktivierung der Verschlüsselung während der Übertragung vorgenommen werden

Für Cluster CME

Wenn ein Cluster auf „Übertragungs-Verschlüsselungsmodus: bevorzugt“ eingestellt ist:

  • Die ursprünglichen Cluster-Endpunkte für nicht TLS aktivierte Cluster bleiben aktiv. Es gibt keine Ausfallzeiten, wenn der Cluster vom TLS Verschlüsselungsmodus „ohne“ auf „bevorzugt“ umkonfiguriert wird.

  • Neue TLS Valkey- oder OSS Redis-Endpunkte werden generiert, wenn der Cluster auf den Modus -preferred gesetzt wird. TLS Diese neuen Endpunkte werden genauso aufgelöst IPs wie die alten (nicht-). TLS

  • Der neue TLS Valkey- oder OSS Redis-Konfigurationsendpunkt wird in der ElastiCache Konsole und in der Antwort auf angezeigt. describe-replication-group API

Wenn ein Cluster auf „Übertragungs-Verschlüsselungsmodus: erforderlich“ eingestellt ist:

  • Alte, nicht TLS aktivierte Endpunkte werden gelöscht. Es wird keine Ausfallzeit von TLS Cluster-Endpunkten geben.

  • Sie können ein neues cluster-configuration-endpoint von der ElastiCache Konsole oder von der describe-replication-group API abrufen.

Für CMD Cluster mit aktiviertem automatischem Failover oder deaktiviertem automatischem Failover

Wenn die Replikationsgruppe auf „Übertragungs-Verschlüsselungsmodus: bevorzugt“ eingestellt ist:

  • Der ursprüngliche primäre Endpunkt und der Leser-Endpunkt für den Cluster ohne TLS Aktivierung bleiben aktiv.

  • Neue TLS primäre Endpunkte und Leser-Endpunkte werden generiert, wenn der Cluster auf TLS Preferred Modus gesetzt wird. Diese neuen Endpunkte werden auf dieselben IP-Adressen wie die alten (nicht-TLS) aufgelöst.

  • Der neue primäre Endpunkt und der Leser-Endpunkt werden in der ElastiCache Konsole und in der Antwort auf die describe-replication-group API angezeigt.

Wenn die Replikationsgruppe auf „Übertragungs-Verschlüsselungsmodus: erforderlich“ eingestellt ist:

  • Alte Endpunkte (nicht TLS primär) und Lesegeräte werden gelöscht. Es wird keine Ausfallzeit der TLS Cluster-Endpunkte geben.

  • Sie können neue Primär- und Leser-Endpunkte von der ElastiCache Konsole oder von der abrufen. describe-replication-group API

Die empfohlene Verwendung der Datensätze DNS

Für CME Cluster

  • Verwenden Sie den Endpunkt der Cluster-Konfiguration anstelle von DNS Datensätzen pro Knoten im Code Ihrer Anwendung. Die direkte Verwendung von DNS Namen pro Knoten wird nicht empfohlen, da sie sich beim Hinzufügen oder Entfernen von Shards ändern können.

  • Kodieren Sie den Endpunkt der Clusterkonfiguration in Ihrer Anwendung nicht fest, da er sich während dieses Vorgangs ändern wird.

  • Eine feste Kodierung des Endpunkts der Clusterkonfiguration in Ihrer Anwendung wird nicht empfohlen, da er während dieses Vorgangs geändert werden kann. Wenn die Verschlüsselung während der Übertragung abgeschlossen ist, fragen Sie den Endpunkt der Cluster-Konfiguration mit dem ab describe-replication-group API (wie oben dargestellt (fett gedruckt)) ab und verwenden Sie ab diesem Zeitpunkt die Antwort, die DNS Sie als Antwort erhalten.

Für CMD Cluster mit aktiviertem automatischem Failover

  • Verwenden Sie den primären Endpunkt und den Leser-Endpunkt anstelle der DNS Namen pro Knoten im Code Ihrer Anwendung, da die alten DNS Namen pro Knoten gelöscht und neue generiert werden, wenn der Cluster von „Nein“ auf „bevorzugt“ migriert wird. TLS TLS Die direkte Verwendung von DNS Namen pro Knoten wird nicht empfohlen, da Sie Ihrem Cluster in future möglicherweise Replikate hinzufügen. Wenn Automatic Failover aktiviert ist, werden außerdem die Rollen des primären Clusters und der Replikate automatisch vom ElastiCache Dienst geändert. Es wird empfohlen, den primären Endpunkt und den Leser-Endpunkt zu verwenden, um den Überblick über diese Änderungen zu behalten. Schließlich hilft Ihnen die Verwendung des Reader-Endpunkts dabei, Ihre Lesevorgänge aus den Replikaten gleichmäßig auf die Replikate im Cluster zu verteilen.

  • Es ist eine schlechte Praxis, den primären Endpunkt und den Leser-Endpunkt in Ihrer Anwendung fest zu codieren, da sie während des TLS Migrationsprozesses geändert werden können. Nachdem die Umstellung auf TLS -preferred abgeschlossen ist, fragen Sie den primären Endpunkt und den Reader-Endpunkt mit dem ab describe-replication-group API und verwenden Sie ab diesem Zeitpunkt die Antwort, die DNS Sie als Antwort erhalten. Auf diese Weise können Sie Änderungen an Endpunkten dynamisch verfolgen.

Für CMD Cluster mit deaktiviertem automatischen Failover

  • Verwenden Sie den primären Endpunkt und den Leser-Endpunkt anstelle der DNS Namen pro Knoten im Code Ihrer Anwendung. Wenn Automatic Failover deaktiviert ist, werden Skalierung, Patching, Failover und andere Verfahren, die automatisch vom ElastiCache Dienst verwaltet werden, wenn Automatic Failover aktiviert ist, stattdessen von Ihnen durchgeführt. Das erleichtert es Ihnen, den Überblick über die verschiedenen Endpunkte zu behalten. Da bei der Migration des Clusters von „Nein“ auf „TLSBevorzugt“ die alten DNS Namen pro Knoten gelöscht werden und neue generiert werden, sollten Sie die Namen pro Knoten nicht direkt verwenden. TLS DNS Dies ist obligatorisch, damit die Clients während der -Migration eine Verbindung zum Cluster herstellen können. TLS Außerdem profitieren Sie von der gleichmäßigen Verteilung der Lesevorgänge zwischen den Replikaten, wenn Sie den Reader-Endpunkt verwenden, und Sie behalten den Überblick über die DNS -records, wenn Sie Repliken zum Cluster hinzufügen oder daraus löschen.

  • Es ist eine schlechte Praxis, den Endpunkt der Clusterkonfiguration in Ihrer Anwendung fest zu codieren, da er während des Migrationsprozesses geändert werden kann. TLS

Bei der Verschlüsselung während der Übertragung: darauf achten, wann der Migrationsprozess abgeschlossen ist

Die Änderung des Verschlüsselungsmodus während der Übertragung erfolgt nicht sofort und kann einige Zeit in Anspruch nehmen. Dies gilt insbesondere für große Cluster. Erst wenn der Cluster die Migration zu TLS -preferred abgeschlossen hat, kann er Verbindungen TCP sowohl TLS akzeptieren als auch bereitstellen. Daher sollten Sie keine Clients erstellen, die versuchen, TLS Verbindungen zum Cluster herzustellen, bis die Verschlüsselung während der Übertragung abgeschlossen ist.

Es gibt mehrere Möglichkeiten, sich benachrichtigen zu lassen, wenn die Verschlüsselung während der Übertragung erfolgreich abgeschlossen wurde oder fehlschlägt (im obigen Codebeispiel nicht dargestellt):

  • Verwenden Sie den SNS Dienst, um eine Benachrichtigung zu erhalten, wenn die Verschlüsselung abgeschlossen ist

  • Wenn Sie den verwenden describe-eventsAPI, wird ein Ereignis ausgelöst, wenn die Verschlüsselung abgeschlossen ist

  • In der ElastiCache Konsole wird eine Meldung angezeigt, dass die Verschlüsselung abgeschlossen ist

Sie können in Ihrer Anwendung auch Logik implementieren, um festzustellen, ob die Verschlüsselung abgeschlossen ist. Im obigen Beispiel haben wir mehrere Möglichkeiten kennengelernt, wie wir sicherstellen können, dass der Cluster die Migration abschließt:

  • Warten, bis der Migrationsprozess beginnt (der Clusterstatus wechselt zu „Wird geändert“) und warten, bis die Änderung abgeschlossen ist (der Clusterstatus wechselt wieder zu „Verfügbar“)

  • Es wird bestätigt, dass der Cluster auf True transit_encryption_enabled gesetzt wurde, indem die abgefragt wird. describe-replication-group API

Nach dem Aktivieren der Verschlüsselung während der Übertragung: sicherstellen, dass die von Ihnen verwendeten Clients ordnungsgemäß konfiguriert sind

Solange sich der Cluster im Modus TLS -preferred befindet, sollte Ihre Anwendung TLS Verbindungen zum Cluster öffnen und nur diese Verbindungen verwenden. Auf diese Weise kommt es bei Ihrer Anwendung nicht zu Ausfallzeiten, wenn die Verschlüsselung während der Übertragung aktiviert wird. Mit dem Befehl info im Abschnitt können Sie sicherstellen, dass keine klareren TCP Verbindungen zur Valkey- oder OSS Redis-Engine bestehen. 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