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

Vor dem Aktivieren der Verschlüsselung während der Übertragung: sicherstellen, dass die DNS-Einträge ordnungsgemäß verarbeitet werden

Anmerkung

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

Während der Cluster von „no-TLS“ zu „TLS Preferred“ migriert wird, werden die alten DNS-Einträge pro Knoten beibehalten und die neuen DNS-Einträge pro Knoten werden in einem anderen Format generiert. TLS-fähige Cluster verwenden ein anderes Format von DNS-Einträgen als nicht TLS-fähige Cluster. ElastiCache behält beide DNS-Einträge bei, wenn ein Cluster im Verschlüsselungsmodus konfiguriert ist: Bevorzugt, damit Anwendungen und andere Redis OSS-Clients zwischen ihnen wechseln können. Die folgenden Änderungen in den DNS-Einträgen finden während des TLS-Migrationsprozesses statt:

Beschreibung der Änderungen an den DNS-Einträgen, die bei der Aktivierung der Verschlüsselung während der Übertragung vorgenommen werden

Für CME-Cluster

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

• Die ursprünglichen Cluster-Endpunkte für nicht TLS-fähige Cluster bleiben aktiv. Es wird keine Ausfallzeit geben, wenn der Cluster vom TLS-Verschlüsselungsmodus „none“ auf „preferred“ umkonfiguriert wird.

• Neue TLS Redis OSS-Endpunkte werden generiert, wenn der Cluster auf den TLS-Preferred-Modus gesetzt wird. Diese neuen Endpunkte werden auf dieselben IPs wie die alten (ohne TLS) aufgelöst.

• Der neue TLS Redis OSS-Konfigurationsendpunkt wird in der ElastiCache Konsole und in der Antwort auf die API verfügbar gemacht. describe-replication-group

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

• Alte Endpunkte, die nicht TLS-fähig sind, werden gelöscht. Es wird keine Ausfallzeiten der TLS-Cluster-Endpunkte geben.

• Sie können einen neuen 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 automatischen Failover

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

• Der ursprüngliche primäre Endpunkt und der Reader-Endpunkt für nicht TLS-fähige Cluster bleiben aktiv.

• Neue primäre und Reader-Endpunkte mit TLS werden generiert, wenn der Cluster auf den Modus „TLS Preferred“ eingestellt ist. Diese neuen Endpunkte werden auf dieselben IPs wie die alten (ohne TLS) aufgelöst.

• Der neue primäre Endpunkt und der Reader-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 primäre und Reader-Endpunkte ohne TLS werden gelöscht. Es wird keine Ausfallzeiten der TLS-Cluster-Endpunkte geben.

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

Die empfohlene Verwendung der DNS-Einträge

Für CME-Cluster

• Verwenden Sie den Endpunkt der Clusterkonfiguration anstelle von DNS-Einträgen pro Knoten in Ihrem Anwendungscode. Es wird nicht empfohlen, DNS-Namen pro Knoten direkt zu verwenden, da sie sich ändern können, wenn Shards hinzugefügt oder entfernt werden.

• 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. Nachdem die Verschlüsselung während der Übertragung abgeschlossen ist, fragen Sie den Endpunkt der Clusterkonfiguration mit der describe-replication-group-API ab (wie oben gezeigt (fett gedruckt)) und verwenden Sie das DNS, das Sie ab diesem Zeitpunkt als Antwort erhalten.

Für CMD-Cluster mit aktiviertem automatischen Failover

• Verwenden Sie in Ihrem Anwendungscode den primären Endpunkt und den Reader-Endpunkt anstelle der DNS-Namen pro Knoten, da die alten DNS-Namen pro Knoten gelöscht und neue generiert werden, wenn der Cluster von „no-TLS“ zu „TLS Preferred“ migriert wird. Es wird nicht empfohlen, DNS-Namen pro Knoten direkt zu verwenden, da Sie Ihrem Cluster später 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 Service 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 wird nicht empfohlen, den primären Endpunkt und den Reader-Endpunkt in Ihrer Anwendung fest zu kodieren, da diese 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 Endpunkt des Lesegeräts mit der describe-replication-group API ab und verwenden Sie ab diesem Zeitpunkt den DNS, den 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 Reader-Endpunkt anstelle der DNS-Namen pro Knoten in Ihrem Anwendungscode. 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 „no-TLS“ zu „TLS Preferred“ die alten DNS-Namen pro Knoten gelöscht und neue generiert werden, sollten Sie die DNS-Namen pro Knoten nicht direkt verwenden. Dies ist erforderlich, damit sich die Clients während der TLS-Migration mit dem Cluster verbinden können. Außerdem profitieren Sie von einer gleichmäßigen Verteilung der Lesevorgänge zwischen den Replikaten, wenn Sie den Reader-Endpunkt verwenden, und behalten den Überblick über die DNS-Einträge, wenn Sie dem Cluster Replikate hinzufügen oder löschen.

• Eine feste Kodierung des Endpunkts der Clusterkonfiguration in Ihrer Anwendung wird nicht empfohlen, da er während der TLS-Migration geändert werden kann.

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 sowohl TCP- als auch TLS-Verbindungen akzeptieren und bereitstellen. Daher sollten Sie keine Clients erstellen, die versuchen, TLS-Verbindungen mit dem 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 des SNS-Services, um benachrichtigt zu werden, wenn die Verschlüsselung abgeschlossen ist

• Verwenden der describe-events-API, die ein Ereignis ausgibt, 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“)

• Bestätigen Sie, dass für den Cluster transit_encryption_enabled auf „Wahr“ festgelegt ist, indem Sie die describe-replication-group-API abfragen.

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

Während sich der Cluster im Modus „TLS Preferred“ befindet, sollte Ihre Anwendung TLS-Verbindungen mit dem Cluster herstellen 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 Redis OSS info im Abschnitt SSL können Sie sicherstellen, dass keine klareren TCP-Verbindungen zur Redis OSS-Engine bestehen.

# 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