Notfallwiederherstellung für „Verwaltetes HSM“

  • Artikel

Sie müssen möglicherweise ein genaues Replikat Ihres HSM erstellen, wenn das Original aus einem der folgenden Gründe verloren gegangen oder nicht verfügbar ist:

  • Es wurde gelöscht und anschließend bereinigt.
  • Ein schwerwiegender Fehler in der Region hat dazu geführt, dass alle Mitgliedspartitionen zerstört wurden.

Sie können die HSM-Instanz in derselben oder einer anderen Region neu erstellen, wenn Sie über folgende Informationen/Daten verfügen:

  • Die Sicherheitsdomäne des Quell-HSM.
  • Die privaten Schlüssel (mindestens Quorumanzahl), mit denen die Sicherheitsdomäne verschlüsselt wird.
  • Die neueste vollständige HSM-Sicherung vom Quell-HSM.

Hier sind die Schritte des Verfahrens für die Notfallwiederherstellung angegeben:

  1. Erstellen einer neuen HSM-Instanz
  2. Aktivieren der „Sicherheitsdomänenwiederherstellung“ Ein neues RSA-Schlüsselpaar (Austauschschlüssel für Sicherheitsdomäne) wird für die Sicherheitsdomänenübertragung generiert und als Antwort gesendet. Diese wird als „SecurityDomainExchangeKey“ (öffentlicher Schlüssel) heruntergeladen.
  3. Erstellen Sie die „Datei für die Sicherheitsdomänenübertragung“, und laden Sie sie anschließend hoch. Sie benötigen die privaten Schlüssel, mit denen die Sicherheitsdomäne verschlüsselt wird. Die privaten Schlüssel werden lokal verwendet und bei diesem Prozess nie an einen anderen Ort übertragen.
  4. Erstellen Sie eine Sicherung des neuen HSM. Vor einer Wiederherstellung ist auch dann eine Sicherung erforderlich, wenn das HSM leer ist. Sicherungen ermöglichen einen einfachen Rollback.
  5. Stellen Sie die letzte HSM-Sicherung vom Quell-HSM wieder her.

Mit diesen Schritten können Sie den Inhalt des HSM manuell in einer anderen Region replizieren. Der HSM-Name (und der Dienstendpunkt-URI) lautet anders. Daher müssen Sie möglicherweise die Anwendungskonfiguration ändern, damit diese Schlüssel an einem anderen Speicherort verwendet werden können.

Erstellen eines neuen verwalteten HSM

Verwenden Sie den Befehl az keyvault create, um ein verwaltetes HSM zu erstellen. Das Skript verfügt über drei erforderliche Parameter: einen Ressourcengruppennamen, einen HSM-Namen und den geografischen Standort.

Zum Erstellen einer Ressource vom Typ „Verwaltetes HSM“ müssen Sie Folgendes eingeben:

  • Den Namen des HSM.
  • Die Ressourcengruppe, in die es unter Ihrem Abonnement eingefügt wird.
  • Den Azure-Standort.
  • Eine Liste mit den anfänglichen Administratoren.

Im folgenden Beispiel wird ein HSM mit dem Namen ContosoMHSM2 in der Ressourcengruppe ContosoResourceGroup am Standort USA, Westen 3 erstellt, mit dem aktuell angemeldeten Benutzer als einziger Administrator.

oid=$(az ad signed-in-user show --query objectId -o tsv)
az keyvault create --hsm-name "ContosoMHSM2" --resource-group "ContosoResourceGroup" --location "westus3" --administrators $oid

Hinweis

Die Ausführung des Befehls „Erstellen“ kann einige Minuten dauern. Nachdem der Vorgang erfolgreich abgeschlossen wurde und die Rückgabe erfolgt ist, können Sie Ihr HSM aktivieren.

Warnung

Verwaltete HSM-Instanzen werden als immer in Verwendung betrachtet. Wenn Sie den Bereinigungsschutz mithilfe des Flags --enable-purge-protection aktivieren, wird Ihnen der gesamte Aufbewahrungszeitraum in Rechnung gestellt.

In der Ausgabe dieses Befehls werden die Eigenschaften des verwalteten HSM angezeigt, das Sie erstellt haben. Die zwei wichtigsten Eigenschaften sind diese:

  • name: Im Beispiel lautet der Name „ContosoMHSM“. Sie verwenden diesen Namen für andere Key Vault-Befehle.
  • hsmUri: In diesem Beispiel lautet der URI „https://contosomhsm2.managedhsm.azure.net.“. Von Anwendungen, die Ihr HSM über die zugehörige REST-API nutzen, muss dieser URI verwendet werden.

Ihr Azure-Konto verfügt nun über die Berechtigung zum Durchführen von Vorgängen für dieses verwaltete HSM. Derzeit ist noch keine andere Person autorisiert.

Aktivieren des Wiederherstellungsmodus für die Sicherheitsdomäne

An diesem Punkt des üblichen Erstellungsprozesses wird die Sicherheitsdomäne des neuen HSM initialisiert und heruntergeladen. Da wir jedoch ein Notfallwiederherstellungsverfahren durchführen, weisen wir das HSM stattdessen an, den Wiederherstellungsmodus für Sicherheitsdomänen zu aktivieren und einen Austauschschlüssel für die Sicherheitsdomäne herunterzuladen. Der Austauschschlüssel für die Sicherheitsdomäne ist ein öffentlicher RSA-Schlüssel, der zum Verschlüsseln der Sicherheitsdomäne vor dem Hochladen in das HSM verwendet wird. Der entsprechende private Schlüssel ist innerhalb des HSM geschützt, damit der Inhalt Ihrer Sicherheitsdomäne während der Übertragung sicher ist.

az keyvault security-domain init-recovery --hsm-name ContosoMHSM2 --sd-exchange-key ContosoMHSM2-SDE.cer

Erstellen eines Sicherheitsdomänenupload-Blobs der HSM-Quelle

Für diesen Schritt benötigen Sie:

  • Den Austauschschlüssel für die Sicherheitsdomäne, den Sie im vorherigen Schritt heruntergeladen haben.
  • Die Sicherheitsdomäne des Quell-HSM.
  • Die privaten Schlüssel (mindestens Quorumanzahl), die zum Verschlüsseln der Sicherheitsdomäne verwendet wurden.

Mit dem Befehl az keyvault security-domain restore-blob wird Folgendes durchgeführt:

  • Entschlüsseln der Sicherheitsdomäne des Quell-HSM mit den von Ihnen bereitgestellten privaten Schlüsseln
  • Erstellen eines Sicherheitsdomänenupload-Blobs, das mit dem heruntergeladenen Sicherheitsdomänen-Austauschschlüssel aus dem vorherigen Schritt verschlüsselt ist

Dieser Schritt kann offline ausgeführt werden.

Im folgenden Beispiel verwenden wir die Sicherheitsdomäne aus dem ContosoMHSM-, die drei zugehörigen privaten Schlüssel und den Exchange-Schlüssel der Sicherheitsdomäne, um ein verschlüsseltes Blob zu erstellen und herunterzuladen, das wir zum Hochladen auf ContosoMHSM2 verwenden, das auf eine Sicherheitsdomäne wartet.

az keyvault security-domain restore-blob --sd-exchange-key ContosoMHSM2-SDE.cer --sd-file ContosoMHSM-SD.json --sd-wrapping-keys cert_0.key cert_1.key cert_2.key --sd-file-restore-blob restore_blob.json

Hochladen des Sicherheitsdomänenupload-Blobs auf das Ziel-HSM

Wir verwenden nun das im vorherigen Schritt erstellte Blob für den Sicherheitsdomänenupload und laden es in das Ziel-HSM hoch, um die Wiederherstellung der Sicherheitsdomäne abzuschließen. Das --restore-blob-Flag wird verwendet, um das Verfügbarmachen von Schlüsseln in einer Onlineumgebung zu verhindern.

az keyvault security-domain upload --hsm-name ContosoMHSM2 --sd-file restore_blob.json --restore-blob

Nun verfügen das Quell-HSM (ContosoMHSM) und das Ziel-HSM (ContosoMHSM2) über die gleiche Sicherheitsdomäne. Wir können jetzt eine vollständige Sicherung vom Quell-HSM auf das Ziel-HSM durchführen.

Sichern und Wiederherstellen

Es ist immer ratsam, vor dem Durchführen einer vollständigen HSM-Wiederherstellung eine vollständige Sicherung durchzuführen. Sie verfügen dann über einen Wiederherstellungspunkt, falls es bei der Wiederherstellung zu einem Fehler kommt. Dazu können Sie eine von zwei Methoden verwenden: vom Benutzer zugewiesene verwaltete Identität oder SAS-Token.

Erstellen einer Sicherung (als Wiederherstellungspunkt) Ihres neuen HSM

Zum Erstellen einer HSM-Sicherung benötigen Sie:

  • Ein Speicherkonto, unter dem die Sicherung gespeichert wird.
  • Einen Blobspeichercontainer in diesem Speicherkonto, in dem vom Sicherungsprozess ein neuer Ordner zum Speichern der verschlüsselten Sicherung erstellt wird.
  • Eine vom Benutzer zugewiesene verwaltete Identität, die die Rolle „Storage Blob Data Contributor“ im SAS-Token des Speicherkontos ODER des Speichercontainers mit den Berechtigungen „crdw“ aufweist

Wir verwenden den Befehl az keyvault backup für die HSM-Sicherung im Speichercontainer mhsmbackupcontainer, der sich in den folgenden Beispielen im Speicherkonto mhsmdemobackup befindet.

Bei Verwendung der vom Benutzer zugewiesenen Methode für verwaltete Identität geben wir die vom Benutzer zugewiesene verwaltete Identität mit dem --mi-user-assigned Parameter an, und ordnen sie dem verwalteten HSM zu, bevor sie die Sicherung im folgenden Beispiel schreiben.

az keyvault update-hsm --hsm-name ContosoMHSM2 --mi-user-assigned "/subscriptions/subid/resourcegroups/mhsmrgname/providers/Microsoft.ManagedIdentity/userAssignedIdentities/userassignedidentityname"
az keyvault backup start --use-managed-identity true --hsm-name ContosoMHSM2 --storage-account-name mhsmdemobackup --blob-container-name mhsmbackupcontainer

Wiederherstellen einer Sicherung vom Quell-HSM

Für diesen Schritt benötigen Sie:

  • Das Speicherkonto und den Blobcontainer, in dem die Sicherungen des Quell-HSM gespeichert werden.
  • Den Namen des Ordners, aus dem Sie die Sicherung wiederherstellen möchten. Wenn Sie reguläre Sicherungen erstellen, enthält dieser Container viele Ordner.

Wir verwenden den Befehl az keyvault restore für das neue HSM ContosoMHSM2, wobei wir die Sicherung der Quell-MHSM verwenden, die wir wiederherstellen möchten. Diese befindet sich im folgenden Beispiel im Ordner mhsm-ContosoMHSM-2020083120161860 im Speichercontainer mhsmdemobackupcontainer des Speicherkontos ContosoBackup.

Bei Verwendung der vom Benutzer zugewiesenen verwalteten Identitätsmethode legen wir den --use-managed-identity Pramater auf "true" fest.

az keyvault restore start --hsm-name ContosoMHSM2 --storage-account-name ContosoBackup --blob-container-name mhsmdemobackupcontainer --backup-folder mhsm-ContosoMHSM-2020083120161860 --use-managed-identity true

Sie haben nun einen vollständigen Prozess für die Notfallwiederherstellung erstellt. Der Inhalt des Quell-HSM bei Erstellung der Sicherung wird auf das Ziel-HSM kopiert, einschließlich aller Schlüssel, Versionen, Attribute, Tags und Rollenzuweisungen.

Nächste Schritte