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 erweiterte 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

Architekturdiagramm eines verwalteten HSM mit Replikation in mehreren Regionen.

Wenn die Replikation in mehreren Regionen für verwaltetes HSM aktiviert ist, wird in einer erweiterten 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 Traffic Manager sicher, dass Anforderungen weiterhin vom Pool verwalteter HSMs in der erweiterten Region 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
Erweiterte Region Ja Ja
Primäre Region Ja Vielleicht

Wenn eine erweiterte 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 erweiterte 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üden-Mitte“, „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 erweiterte Region verwendet werden. Andere Regionen sind aufgrund von Kapazitätsbeschränkungen in der Region möglicherweise nicht verfügbar.

Abrechnung

Replikation in mehreren Regionen in einer erweiterten Region verursacht zusätzliche Kosten (x2), da ein neuer HSM-Pool in der erweiterten 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 eine erweiterte Region aus dem primären HSM entfernt wird, wird das HSM in der entfernten Region gelöscht, anstatt in den Zustand des vorläufigen Löschens versetzt zu werden, und die Abrechnung für das gelöschte HSM endet sofort. Sie können bei Bedarf immer aus der primären Region auf eine neue erweiterte Region erweitern.

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 einer erweiterten Region wird empfohlen, einen weiteren privaten Endpunkt und eine private DNS-Zone zu erstellen, sobald das verwaltete HSM in der primären Region in das verwaltete HSM in einer erweiterten 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 erweiterten Region („USA, Westen-Mitte“).

  • Wenn die beiden verwalteten HSMs in der primären und erweiterten Region mit aktiviertem privatem 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.

    Diagramm zur Illustration des ersten Szenarios mit verwaltetem HSM in mehreren Regionen.

  • 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.

    Diagramm zur Illustration des zweiten Szenarios mit verwaltetem HSM in mehreren Regionen.

  • Verwaltete HSMs in primären und erweiterten Regionen, aber nur ein privater Endpunkt, der entweder in der primären oder der erweiterten 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.

    Diagramm zur Illustration des dritten Szenarios mit verwaltetem HSM in mehreren Regionen.

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.

Diagramm zur Illustration des vierten Szenarios mit verwaltetem HSM in mehreren Regionen.

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.

Diagramm zur Illustration des fünften Szenarios mit verwaltetem HSM in mehreren Regionen.

Azure CLI-Befehle

Wenn Sie einen neuen Pool verwalteter HSMs erstellen und dann auf eine erweiterte Region erweitern, lesen Sie vor der Erweiterung diese Anweisungen. Wenn Sie einen bereits vorhandenen Pool verwalteter HSMs erweitern, verwenden Sie die folgenden Anweisungen, um den HSM-Pool in einer erweiterten Region zu erweitern.

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.

Erweitern eines primären HSM in eine erweiterte Region

Um einen Pool verwalteter HSMs auf eine andere Region zu erweitern, führen Sie den folgenden Befehl aus, der automatisch ein neues HSM in einer erweiterten Region 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 erweiterte Region, in die Sie diesen erweitern.

Entfernen einer erweiterten Region aus dem primären HSM

Nachdem Sie ein erweitertes 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

Nächste Schritte