SLA und geteilte Verantwortung für die Verwaltung externer Schlüssel für Managed HSM (Vorschau)

Wichtig

Die externe Schlüsselverwaltung des verwaltete HSM ist in der Vorschauversion. Vorschaufeatures werden Ihnen unter der Bedingung zur Verfügung gestellt, dass Sie den ergänzenden Nutzungsbedingungen zustimmen. Einige Aspekte dieses Features können sich vor der allgemeinen Verfügbarkeit ändern.

Die verwaltete Verwaltung externer HSM-Schlüssel erweitert Managed HSM, indem der Schlüsselverschlüsselungsschlüssel (KEK) in der vom Kunden gesteuerten Infrastruktur außerhalb von Azure beibehalten wird. Diese Anordnung verschiebt einen sinnvollen Teil der operativen Verantwortung von Microsoft zu Ihnen oder zu Ihrem HSM-Anbieter.

In diesem Artikel werden diese Grenzen explizit definiert, sodass Sie entscheiden können, ob die Verwaltung externer Schlüssel zu Ihrer Workload passt, bevor Sie sich für die Verwendung verpflichten.

Kompromiss bei der Überschrift

Wichtig

Externe Schlüssel, der EKM-Proxy und das externe HSM werden nicht von der verwalteten HSM-SLA abgedeckt. Microsoft gewährleistet die Verfügbarkeit von Managed HSM bis zu dem Punkt, an dem Microsoft Ihren EKM Proxy aufruft. Alles, was darüber hinaus liegt, liegt in Ihrer Verantwortung (oder den HSM-Lieferanten). Verwenden Sie für Workloads, die Microsofts SLA erfordern, stattdessen verwaltete HSM-Schlüssel.

Für was Microsoft verantwortlich ist

Microsoft betreibt die Dienstinfrastruktur innerhalb der Grenze des verwalteten HSM-Diensts. Dies deckt den Dienst selbst ab, nicht die Kontrolle über Ihr Schlüsselmaterial:

  • Verwaltete HSM-Dienstverfügbarkeit, die von der veröffentlichten managed HSM SLA abgedeckt wird.
  • Durchsetzen der Authentifizierung und Autorisierung, die Sie über Ihren Microsoft Entra-Mandanten und die lokale RBAC des Managed HSM definieren.
  • Ausgeben von Auditereignissen für Vorgänge der externen Schlüsselverwaltung auf der Seite von verwaltetem HSM (EkmProxyOperation).
  • Ausgehende mTLS-Verbindungsinitiierung von verwaltetem HSM zum EKM-Proxy.
  • Fehlertransparenz: Proxy- und Fehler externer HSMs für Sie und Support-Teams sichtbar machen, damit die Grundursache eindeutig erkennbar ist.
  • Dokumentation, Beispiele und die öffentliche EKM-Proxy-API-Spezifikation.

Wofür Sie (der Kunde) verantwortlich sind

Sie steuern den Zugriff auf Ihre Schlüssel, und Sie besitzen alles außerhalb der Grenze des verwalteten HSM-Diensts:

  • Authentifizierung und Autorisierung des Aufrufers – die Microsoft Entra-Identitäten und lokalen RBAC-Rollenzuweisungen für Managed HSM, die festlegen, wer Ihre Schlüssel verwenden kann und die alle in Ihrem Mandanten verwaltet werden.
  • Verwaltete HSM-Diagnoseprotokollierung – Aktivieren der verwalteten HSM-Protokollierung und Weiterleitung an Azure Monitor oder ein anderes von Ihnen ausgewähltes Ziel, einschließlich Aufbewahrung.
  • Betrieb und Sicherung des externen HSM – selbst oder über einen von Ihnen festgelegten Operator (z. B. Ihr HSM-Anbieter oder ein anderer Von Ihnen ausgewählter Dritter).
  • Betreiben und Sichern des EKM-Proxys – selbst oder über einen von Ihnen festgelegten Operator (z. B. Ihren HSM-Anbieter oder einen anderen von Ihnen ausgewählten Drittanbieter).
  • Netzwerkverfügbarkeit zwischen verwaltetem HSM und dem Proxy über seinen öffentlichen Endpunkt.
  • mTLS-Zertifikatbereitstellung, -verteilung und -rotation auf der Proxy-Seite.
  • Leistungs- und Kapazitätsplanung für den Proxy und das externe HSM unter Ihrem Payload.
  • Protokollierung und Überwachung am Proxy und HSM. Azure können diese Protokolle nicht sehen.
  • Sicherung, Wiederherstellung und Notfallwiederherstellung für externes Schlüsselmaterial.
  • Wählen Sie aus, ob Ihr KEK einzelne Region oder mehrere Regionen ist, einschließlich geografischer Redundanz des Proxys und des HSM.
  • Compliancenachweise für die vom Kunden betriebenen Teile des Systems.

Wofür der Proxy und der HSM-Operator verantwortlich sind

Sie können den EKM-Proxy und das externe HSM selbst betreiben oder einen Operator (z. B. Ihren HSM-Anbieter oder einen anderen Drittanbieter) festlegen. Wer diese Komponenten betreibt, ist für Folgendes verantwortlich:

  • Die ordnungsgemäße Implementierung des EKM-Proxys gemäß der EKM-Proxy-API-Spezifikation.
  • Einhaltung des ≤ 250 ms Latenzbudgets pro Anfrage.
  • Unterstützung der erforderlichen kryptografischen Algorithmen (A256KW, A256KWP, RSA-OAEP, RSA-OAEP-256) und Schlüsseltypen (AES-256, RSA 2048 / 3072 / 4096).
  • Strikte Einhaltung der Kodierungsregeln: rohe vorzeichenlose Bytes im Big-Endian-Format, base64url — niemals PEM, JWK, Hexadezimal- oder Dezimalzeichenfolgen.
  • Bereitstellung von Support und Reaktion auf Vorfälle für den Proxy und das externe HSM, die sie betreiben.

Zusammenfassung der gemeinsamen Verantwortung

Area Microsoft Customer Benannter Operator
Verfügbarkeit des verwalteten HSM-Diensts ✅ Besitztümer
Authentifizierung und Autorisierung des Aufrufers (Entra-Identitäten, lokales RBAC) Erzwingung ✅ Besitzt
Verwahrung von externem KEK-Material ✅ Besitztümer
EKM-Proxyimplementierung ✅ Besitzt Bei Delegierung
EKM-Proxyvorgang (Bereitstellen, Skalieren, Patch) ✅ Besitzt Bei Delegierung
mTLS-Zertifikatlebenszyklus (Verwaltetes HSM-Clientzertifikat) ✅ Besitztümer
mTLS-Zertifikatlebenszyklus (Proxyserverzertifikat und vertrauenswürdige Stammzertifizierungsstelle) ✅ Besitzt Bei Delegierung
Netzwerkpfad zwischen verwaltetem HSM und Proxy ✅ Besitzt
Externe HSM-Verfügbarkeit ✅ Besitztümer Bei Delegierung
Verpacken und Entpacken – Latenz ✅ Besitztümer Bei Delegierung
Verwaltete HSM-seitige Protokollierung Gibt Überwachungsereignisse aus ✅ Konfiguriert und speichert
Protokolle (auf Proxy- und HSM-Seite) ✅ Besitztümer Bei Delegierung
Sicherung und Wiederherstellung externer Schlüssel ✅ Besitzt
Geografische Redundanz von externen Schlüsseln ✅ Besitzt
Compliancenachweise ✅Azure-Geltungsbereich ✅ Kundenumfang ✅ Geltungsbereich des Operators
Reaktion auf Vorfälle ✅ Geltungsbereich des verwalteten HSM ✅ Proxy- und HSM-Bereich Bei Delegierung

SLA-Auswirkungen

Die Managed HSM SLA gilt weiterhin für Schlüsselvorgänge in Managed HSM sowie für die Rolle von Managed HSM bei externen Schlüsselverwaltungsvorgängen.

Für externe Schlüssel, den EKM-Proxy oder das externe HSM gibt es keine SLA. Dies ist beabsichtigt und spiegelt wider, dass diese Komponenten außerhalb der Kontrolle Microsoft betrieben werden.

Fehler, die auf den Proxy oder externen HSM zurückzuführen sind – Timeouts, Authentifizierungsfehler, Drosselung – werden mit proxybasierten Fehlercodes gemeldet und zählen nicht für die verwaltete HSM-SLA.

Wenn Ihre Workload SLA-gesicherte Schlüsselverfügbarkeit erfordert, verwenden Sie verwaltete HSM-Schlüssel.

Leistungserwartungen

Das Latenzbudget pro Anforderung über den Proxy beträgt ≤ 250 ms. Beim Verwalteten HSM kommt es zu einer Zeitüberschreitung, wenn der Proxy nicht innerhalb dieses Zeitfensters antwortet.

Microsoft maskiert, glättet oder gleicht Proxy- oder HSM-Latenz nicht aus. Ihre End-to-End-Leistung spiegelt die langsamste Verbindung in der Kette wider.

Es gibt keine dedizierten Wiederholungsstrategien zum Ausblenden von Proxy- oder HSM-Nichtverfügbarkeit. Fehler werden an Aufrufer weitergegeben.

Fehlertransparenz

Fehler, die im Proxy oder in einem externen HSM entstehen, werden zusammen mit ihrem HTTP-Statuscode und ihrer Meldung an Managed HSM zurückgegeben und in Azure-Diagnoseprotokollen erfasst.

Das macht die Triage eindeutig: Supporttechniker auf beiden Seiten der Grenze können auf einen Blick erkennen, ob ein Problem auf der Seite von Microsoft oder auf Ihrer liegt. In der Previewphase gibt es keine gemeinsame Korrelations-ID zwischen Managed HSM und Proxyprotokollen – korrelieren Sie daher manuell, indem Sie den externen Schlüsselbezeichner, den Algorithmus und den Zeitstempel über beide Quellen hinweg innerhalb eines Zeitfensters von ±1 Sekunde abgleichen.

Pricing

Standardmäßig verwaltete HSM-Preise gelten wie gewohnt.

Es gibt keinen zusätzlichen Microsoft Aufpreis für die Verwendung der externen Schlüsselverwaltung.

Sie tragen separat die Kosten des EKM-Proxy-Computes und des externen HSM, in der Regel von Ihrem HSM-Anbieter berechnet.

Supportgrenzen

Microsoft unterstützt verwaltetes HSM und die veröffentlichte EKM-Proxy-API-Spezifikation.

Microsoft stellt keine Referenzproxyimplementierung als unterstütztes Produkt bereit. Beispielcode in dieser Dokumentation ist nur illustrativ.

Melden Sie Probleme, die auf den Proxy oder ein externes HSM zurückzuführen sind, Ihrem HSM-Anbieter oder Ihrem Betriebsteam.

Der Microsoft-Support kann dabei helfen, Symptome über die Grenze hinweg anhand von Überwachungsprotokollen, der externen Schlüssel-ID und dem Abgleich der Zeitstempel in Zusammenhang zu bringen.

Wann stattdessen verwaltete HSM-Schlüssel ausgewählt werden sollen

Externes Schlüsselmanagement ist nicht für jede Arbeitslast die richtige Wahl. Erwägen Sie verwaltete HSM-Schlüssel, wenn:

  • Sie haben keine behördliche oder Souveränitätsanforderung, die die physische Kontrolle von Schlüsselmaterial außerhalb der Microsoft Infrastruktur vorschreibt.
  • Sie möchten, dass die verwaltete HSM-SLA auf Ihre Schlüssel angewendet werden soll.
  • Sie verfügen nicht über die operativen Kapazitäten, um ein externes HSM und einen Proxy hochverfügbar zu betreiben.
  • Sie benötigen kryptografische Vorgänge, die über das Verpacken und Entpacken von Schlüsseln hinausgehen, z. B. Signieren, Verifizieren, Verschlüsseln oder Entschlüsseln.
  • Sie möchten Secure Key Release (SKR) verwenden.

Verwandte Inhalte

  • Last updated on