Aktivieren der Replikation in mehreren Regionen auf einem verwalteten Azure HSM
Mit der Replikation in mehreren Regionen können Sie einen verwalteten HSM-Pool von einer Azure-Region (als primäre Region bezeichnet) auf eine andere Azure-Region (als sekundäre Region bezeichnet) erweitern. Nach der Konfiguration sind beide Regionen aktiv, können Anforderungen verarbeiten und bei automatisierter Replikation dasselbe Schlüsselmaterial, dieselben Rollen und Berechtigungen gemeinsam nutzen. Die der Anwendung am nächsten gelegene verfügbare Region empfängt und erfüllt die Anforderung, wodurch der Lesedurchsatz maximiert und die Wartezeiten minimiert werden. Während regionale Ausfälle selten sind, verbessert die Replikation in mehreren Regionen die Verfügbarkeit unternehmenskritischer kryptografischer Schlüssel, falls eine Region nicht verfügbar werden sollte. Weitere Informationen zur SLA finden Sie unter SLA für verwaltetes HSM in Azure Key Vault.
Aufbau
Wenn die Replikation in mehreren Regionen für ein verwaltetes HSM aktiviert ist, wird in der sekundären Region ein zweiter verwalteter HSM-Pool mit drei HSM-Partitionen mit Lastenausgleich erstellt. Wenn Anforderungen an den globalen DNS-Endpunkt <hsm-name>.managedhsm.azure.net von Traffic Manager gesendet werden, empfängt und erfüllt die nächstgelegene verfügbare Region die Anforderung. Während jede Region einzeln aufgrund der Verteilung von HSMs in der Region regionale Hochverfügbarkeit aufrechterhält, stellt der Traffic Manager sicher, dass Anforderungen weiterhin vom sekundär verwalteten HSM-Pool verarbeitet werden können, selbst wenn alle Partitionen eines verwalteten HSM in einer Region aufgrund einer Katastrophe nicht verfügbar sind.
Replication latency
Jeder Schreibvorgang auf das verwaltete HSM, z. B. das Erstellen oder Aktualisieren eines Schlüssels, das Erstellen oder Aktualisieren einer Rollendefinition oder das Erstellen oder Aktualisieren einer Rollenzuweisung, kann bis zu 6 Minuten dauern, bis beide Regionen vollständig repliziert sind. Innerhalb dieses Fensters ist nicht garantiert, dass das geschriebene Material zwischen den Regionen repliziert wurde. Daher ist es am besten, sechs Minuten zwischen dem Erstellen oder Aktualisieren des Schlüssels und seiner Verwendung zu warten, um sicherzustellen, dass das Schlüsselmaterial vollständig zwischen Regionen repliziert wurde. Gleiches gilt für Rollenzuweisungen und Rollendefinitionen.
Failoververhalten
Ein Failover tritt auf, wenn eine der Regionen in einem verwalteten HSM mit mehreren Regionen aufgrund eines Ausfalls nicht mehr verfügbar ist und die andere Region beginnt, alle Anforderungen zu verarbeiten. Der Ausfall kann nur auf Ihren HSM-Pool, den gesamten verwalteten HSM-Dienst oder die gesamte Azure-Region beschränkt sein. Während des Failovers können Sie abhängig von der betroffenen Region eine Verhaltensänderung feststellen.
| Betroffene Region | Lesevorgänge zulässig | Schreibvorgänge zulässig |
|---|---|---|
| Secondary | Ja | Ja |
| Primär | Ja | Vielleicht |
Wenn die sekundäre Region nicht mehr verfügbar ist, sind Lesevorgänge (Abrufen von Schlüsseln, Auflisten von Schlüsseln, alle Kryptografievorgänge, Auflisten von Rollenzuweisungen) verfügbar, wenn die primäre Region aktiv ist. Schreibvorgänge (Erstellen und Aktualisieren von Schlüsseln, Erstellen und Aktualisieren von Rollenzuweisungen, Erstellen und Aktualisieren von Rollendefinitionen) sind ebenfalls verfügbar.
Wenn die primäre Region nicht verfügbar ist, sind Lesevorgänge verfügbar, Schreibvorgänge aber möglicherweise nicht, je nach Umfang des Ausfalls.
Zeit bis zum Failover
Im Hintergrund verarbeitet die DNS-Auflösung die Umleitung von Anforderungen an die primäre oder sekundäre Region.
Wenn beide Regionen aktiv sind, löst Traffic Manager eingehende Anforderungen an den geografisch nächstgelegenen Standort oder den Standort mit der niedrigsten Netzwerklatenz zum Ursprung der Anforderung auf. DNS-Einträge werden mit einer Standard-TTL von 5 Sekunden konfiguriert.
Wenn eine Region einen fehlerhaften Status an Traffic Manager meldet, werden zukünftige Anforderungen an die andere Region aufgelöst, sofern verfügbar. Für Clients, die DNS-Lookups zwischenspeichern, kann sich die Failoverzeit verlängern. Sobald jedoch alle clientseitigen Caches abgelaufen sind, sollten zukünftige Anforderungen an die verfügbare Region weitergeleitet werden.
Unterstützte Azure-Regionen
Die folgenden Regionen werden als primäre Regionen unterstützt (Regionen, aus denen Sie einen verwalteten HSM-Pool replizieren können):
- USA, Osten
- USA (Ost 2)
- Vereinigtes Königreich, Norden
- Europa, Westen
- USA, Westen
- Kanada, Osten
- Katar, Mitte
- Asien, Osten
- Asien, Südosten
- UK, Süden
- USA, Mitte
- Japan, Osten
- Schweiz, Norden
- Brasilien Süd
- Australien, Mitte
- Indien, Mitte
- USA, Westen 3
- Kanada, Mitte
- Australien (Osten)
- Indien, Süden
- Schweden, Mitte
- Südafrika, Norden
- Korea, Mitte
- Europa, Norden
- Frankreich, Mitte
- Japan, Westen
- USA, Süden-Mitte
- Polen, Mitte
- Schweiz, Westen
- Australien, Südosten
- Indien, Westen
- VAE, Mitte
- Vereinigte Arabische Emirate, Norden
- USA, Westen 2
- USA, Westen-Mitte
Hinweis
„USA, Mitte“, „USA, Osten“, „USA, Süd-Zentral“, „USA, Westen 2“, „Schweiz, Norden“, „Europa, Westen“, „Indien, Mitte“, „Kanada, Mitte“, „Kanada, Osten“, „Japan, Westen“, „Katar, Mitte“, „Polen, Mitte“ und „USA, Westen-Mitte“ können derzeit nicht als sekundäre Region erweitert werden. Andere Regionen sind aufgrund von Kapazitätsbeschränkungen in der Region möglicherweise nicht verfügbar.
Abrechnung
Replikation in mehreren Regionen in eine sekundäre Region verursacht zusätzliche Kosten (x2), da ein neuer HSM-Pool in der sekundären Region genutzt wird. Weitere Informationen finden Sie unter Verwaltetes Azure HSM – Preise.
Verhalten des vorläufigen Löschens
Das Feature „Vorläufiges Löschen von verwalteten HSMs“ ermöglicht die Wiederherstellung gelöschter HSMs und Schlüssel. In einem Szenario mit aktivierter Replikation in mehreren Regionen gibt es jedoch feine Unterschiede, bei denen das sekundäre HSM gelöscht werden muss, bevor das vorläufige Löschen auf dem primären HSM ausgeführt werden kann. Wenn ein sekundäres HSM gelöscht wird, wird es außerdem sofort endgültig gelöscht und wechselt nicht in einen vorläufigen Löschzustand, wodurch jegliche weitere Abrechnung für das sekundäre HSM beendet wird. Sie können bei Bedarf immer aus der primären Region auf eine neue Region als sekundäre Region erweitern.
Verhalten privater Verbindungen bei Replikation in mehreren Regionen
Das Feature „Azure Private Link“ erlaubt es Ihnen, über einen privaten Endpunkt in Ihrem virtuellen Netzwerk auf den verwalteten HSM-Dienst zugreifen. Sie würden den privaten Endpunkt auf dem verwalteten HSM in der primären Region genau so konfigurieren, als ob Sie das Feature „Replikation in mehreren Regionen“ nicht verwenden würden. Für das verwaltete HSM in der sekundären Region wird empfohlen, einen weiteren privaten Endpunkt zu erstellen, sobald das verwaltete HSM in der primären Region auf das verwaltete HSM in der sekundären Region repliziert wurde. Dadurch werden Clientanforderungen an das verwaltete HSM umgeleitet, das dem Clientstandort am nächsten ist.
Im Folgenden finden Sie ein paar Szenarien mit Beispielen: Verwaltetes HSM in einer primären Region („Vereinigtes Königreich, Süden“) und ein anderes verwaltetes HSM in einer sekundären Region („USA, Westen-Mitte“).
Wenn die beiden verwalteten HSMs in der primären und sekundären Region mit aktiviertem privaten Endpunkt ausgeführt werden, werden Clientanforderungen an das verwaltete HSM umgeleitet, das dem Clientstandort am nächsten ist. Clientanforderungen werden an den privaten Endpunkt der nächstgelegenen Region gesendet und dann vom Traffic Manager an das verwaltete HSM derselben Region weitergeleitet.
Wenn eins der verwalteten HSMs (z. B. „Vereinigtes Königreich, Süden“) in einem Szenario mit Replikation in mehreren Regionen bei aktivierten privaten Endpunkten nicht verfügbar ist, werden Clientanforderungen an das verfügbare verwaltete HSM („USA, Westen-Mitte“) umgeleitet. Clientanforderungen aus der Region „Vereinigtes Königreich, Süden“, werden zuerst an den privaten Endpunkt von „Vereinigtes Königreich, Süden“ gesendet und dann von Traffic Manager an das verwaltete HSM in „USA, Westen-Mitte“ weitergeleitet.
Verwaltete HSMs in primären und sekundären Regionen, aber nur ein privater Endpunkt, der entweder in der primären oder sekundären Region konfiguriert ist. Damit ein Client aus einem anderen VNet (VNET1) über einen privaten Endpunkt in einem anderen VNet (VNET2) eine Verbindung mit einem verwalteten HSM herstellen kann, ist VNet-Peering zwischen den beiden VNets erforderlich. Sie können einen VNet-Link für die private DNS-Zone hinzufügen, die während der Erstellung des privaten Endpunkts erstellt wird.
Im folgenden Diagramm wird ein privater Endpunkt nur in der Region „Vereinigtes Königreich, Süden“ erstellt, während zwei aktive verwaltete HSMs vorhanden sind, von denen das eine in „Vereinigtes Königreich, Süden“ und das andere in „USA, Westen-Mitte“ ausgeführt wird. Anforderungen von beiden Clients werden an das HSM in „Vereinigtes Königreich, Süden“ gesendet, da Anforderungen über den privaten Endpunkt weitergeleitet werden, dessen Standort sich in diesem Fall in „Vereinigtes Königreich, Süden“ befindet.
Im folgenden Diagramm wird ein privater Endpunkt nur in der Region „Vereinigtes Königreich, Süden“ erstellt, wobei nur das verwaltete HSM in „USA, Westen-Mitte“ verfügbar ist, und das verwaltete HSM in „Vereinigtes Königreich, Süden“ nicht verfügbar ist. In diesem Fall werden Anforderungen über den privaten Endpunkt in „Vereinigtes Königreich, Süden“ an das verwaltete HSM in „USA, Westen-Mitte“ umgeleitet, da Traffic Manager erkennt, dass das verwaltete HSM in „Vereinigtes Königreich, Süden“ nicht verfügbar ist.
Azure CLI-Befehle
Wenn Sie einen neuen verwalteten HSM-Pool erstellen und dann auf einen sekundären erweitern, lesen Sie vor der Erweiterung diese Anweisungen. Wenn Sie einen bereits vorhandenen verwalteten HSM-Pool erweitern, verwenden Sie die folgenden Anweisungen, um ein sekundäres HSM in einer anderen Region zu erstellen.
Hinweis
Für diese Befehle ist mindestens Version 2.48.1 der Azure CLI erforderlich. Informationen zum Installieren der neuesten Version finden Sie unter Installieren der Azure CLI.
Hinzufügen eines sekundären HSM in einer anderen Region
Um einen verwalteten HSM-Pool auf eine andere Region zu erweitern, führen Sie den folgenden Befehl aus, der automatisch ein zweites HSM erstellt.
az keyvault region add --hsm-name "ContosoMHSM" --region "australiaeast"
Hinweis
„ContosoMHSM“ in diesem Beispiel ist der Name des primären HSM-Pools. „australiaeast“ ist die sekundäre Region, in die Sie diesen erweitern.
Entfernen eines sekundären HSM in einer anderen Region
Nachdem Sie ein sekundäres HSM entfernt haben, werden die HSM-Partitionen in der anderen Region endgültig gelöscht. Alle sekundären Partitionen müssen gelöscht werden, bevor ein primäres verwaltetes HSM vorläufig gelöscht oder endgültig gelöscht werden kann. Nur sekundäre Partitionen können mit diesem Befehl gelöscht werden. Die primäre Partition kann nur mit den Befehlen soft-delete (vorläufig löschen) und purge (endgültig löschen) gelöscht werden.
az keyvault region remove --hsm-name ContosoMHSM --region australiaeast
Auflisten aller Regionen
az keyvault region list --hsm-name ContosoMHSM