Netzwerk und mTLS für die Verwaltung externer Schlüssel in Managed HSM konfigurieren (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.

In diesem Artikel wird die Netzwerk- und Transportschichtsicherheitskonfiguration behandelt, die zum Herstellen einer Verbindung mit verwaltetem HSM mit Ihrem EKM-Proxy erforderlich ist. Sie richtet sich an Netzwerk- und Sicherheitsingenieure, die die Bereitstellung einer externen Schlüsselverwaltung einrichten oder warten.

Sie erfahren, wie Sie ein Konnektivitätsmodell auswählen, welchen ausgehenden Datenverkehr Managed HSM erzeugt und wie Sie die Zertifikate für gegenseitiges TLS (mTLS) bereitstellen und rotieren, mit denen beide Seiten der Verbindung authentifiziert werden.

Informationen zur End-to-End-Architektur und zum Anforderungsfluss finden Sie unter Managed HSM external key management architecture. Schritte zum Einrichten auf Befehlsebene finden Sie in der Schnellstartanleitung: Erstellen Des ersten externen Schlüssels mithilfe der Azure CLI.

Konnektivitätsmodell

Verwaltetes HSM initiiert eine ausgehende mTLS-Verbindung mit Ihrem EKM-Proxy. In der ersten Vorschauversion muss der EKM-Proxy über das öffentliche Internet in einem öffentlich aufgelösten FQDN erreichbar sein. Dies ist das einzige unterstützte Konnektivitätsmodell.

Die Sicherheit hängt nicht von Netzwerkebeneneinschränkungen ab. Die Verbindung ist durch gegenseitiges TLS (mTLS) geschützt: Beide Seiten präsentieren und überprüfen X.509-Zertifikate, bevor eine Nutzlast ausgetauscht wird. Verwaltete HSM-Quell-IPs sind nicht statisch und können nicht zugelassen werden, sodass Sie eingehenden Datenverkehr nicht auf verwaltetes HSM beschränken können. Zertifikatbasierte Identität ist der unterstützte Sicherheitsmechanismus.

Konfigurieren des öffentlichen Internetmodells

In diesem Modell ist der EKM-Proxy über das öffentliche Internet in einem öffentlich aufgelösten FQDN erreichbar.

  1. Stellen Sie den EKM-Proxy auf einem Host mit einer öffentlichen IP und einem DNS-Eintrag bereit.
  2. Beziehen Sie ein TLS-Serverzertifikat von einer Zertifizierungsstelle (CA), deren Stammzertifikat Sie bei der Verbindung zur externen Schlüsselverwaltung registrieren.
  3. Konfigurieren Sie den Proxy für das Überwachen von TCP-Port 443 , wobei TLS 1.3 aktiviert ist. Port 443 ist für die Vorschau erforderlich.
  4. Erstellen Sie eine Verbindung zur externen Schlüsselverwaltung, wobei --host auf den öffentlichen FQDN und --server-ca-certificate auf die Stammzertifizierungsstelle im PEM-Format festgelegt ist.

Den vollständigen az keyvault ekm-connection create Befehl finden Sie unter Schnellstart: Erstellen Des ersten externen Schlüssels mithilfe des Azure CLI.

Hinweis

Obwohl der Proxy öffentlich erreichbar ist, wird die Verbindung dennoch beidseitig authentifiziert. Ein Angreifer, der den Proxyendpunkt ohne ein gültiges verwaltetes HSM-Clientzertifikat erreicht, kann den Handshake nicht abschließen.

mTLS-Übersicht

Die Verbindung zwischen verwaltetem HSM und dem EKM-Proxy verwendet gegenseitiges TLS (mTLS). Beide Seiten präsentieren X.509-Zertifikate, und beide Seiten überprüfen das Zertifikat des Peers, bevor sie eine Nutzlast austauschen.

  • Serverzertifikat – der EKM-Proxy stellt dieses Zertifikat verwaltetem HSM vor. Das verwaltete HSM überprüft sie anhand der Root-CA, die Sie für die Verbindung zur externen Schlüsselverwaltung registriert haben.
  • Clientzertifikat – Verwaltetes HSM stellt dieses Zertifikat dem EKM-Proxy vor. Der Proxy muss es überprüfen und Verbindungen von unbekannten Ausstellern ablehnen.

Diese bidirektionale Authentifizierung stellt eine Identität her. Verwaltete HSM-Quell-IPs sind nicht stabil und können nicht vom Kunden festgelegt werden, sodass eine IP-basierte Zulassungsliste nicht ausreicht. Zertifikatbasierte Identität ist der einzige unterstützte Mechanismus.

TLS-Anforderungen:

  • Mindestversion: TLS 1.3.
  • Erforderliche Verschlüsselungssammlungen: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256.

Serverzertifikat (Proxy → verwaltetes HSM)

Das Serverzertifikat des Proxys ist ein PKIX-Standardzertifikat. Sie sind für die Bereitstellung, Verlängerung und Widerruf verantwortlich.

Was verwaltetes HSM überprüft:

  • Das Zertifikat lässt sich auf die Root-CA zurückführen, die im Feld --server-ca-certificate der externen Schlüsselverwaltungsverbindung registriert ist.
  • Das Zertifikat befindet sich innerhalb des Gültigkeitsfensters.
  • Der Subject Alternative Name (SAN) entspricht dem Proxy-Hostnamen, der für die externe Schlüsselverwaltungsverbindung konfiguriert ist.

Was --server-ca-certificate akzeptiert:

Ein Zertifikat der Stammzertifizierungsstelle im PEM- oder DER-Format. Geben Sie beim Ausführen von az keyvault ekm-connection create oder az keyvault ekm-connection update den Dateipfad zum Zertifikat an. Verwenden Sie im Azure Portaluploadfluss das PEM-Format mit einer .cer Erweiterung.

Erneuern des Serverzertifikats:

  • Wenn das neue Zertifikat auf die gleiche Stammzertifizierungsstelle zurückgeführt wird, die bereits für die Verbindung zur externen Schlüsselverwaltung registriert ist, stellen Sie das neue Zertifikat auf dem Proxy bereit. Es ist keine Änderung an der Externen Schlüsselverwaltungsverbindung erforderlich.

  • Wenn das neue Zertifikat eine andere Stammzertifizierungsstelle verwendet, aktualisieren Sie die Externe Schlüsselverwaltungsverbindung mit der neuen Zertifizierungsstelle, bevor Sie das neue Zertifikat bereitstellen:

    az keyvault ekm-connection update \
  --hsm-name <Managed HSM Name> \
  --server-ca-certificate oldandnewrootcas.pem

    Aktualisieren Sie die Verbindung zuerst, um ein Fenster zu vermeiden, in dem der Proxy ein Zertifikat darstellt, das verwaltetes HSM nicht überprüfen kann.

Clientzertifikat (Managed HSM → Proxy)

Managed HSM legt dem Proxy bei jeder Verbindung ein poolspezifisches X.509-Clientzertifikat vor. Microsoft stellt dieses Zertifikat aus und verwaltet es.

Informationen über das Clientzertifikat abrufen, das Managed HSM zur Authentifizierung beim EKM-Proxy verwendet:

az keyvault ekm-connection certificate show --hsm-name <Managed HSM Name>

Der Befehl gibt den Common Name (CN) des Antragstellers des Clientzertifikats sowie ein Array von X.509-Stammzertifikaten zurück, wobei jedes Zertifikat als Base64-kodiertes DER vorliegt.

Konfigurieren Sie den Proxy, um das Zertifikat zu akzeptieren:

Der Proxy muss beide auf die Zulassungsliste setzen:

  • Der allgemeine Antragstellername des Clientzertifikats (subjectCommonName).
  • Die vom Befehl zurückgegebenen Stammzertifikate (caCertificates).

Da die Zulassungsauflistung auf dem gemeinsamen Antragstellernamen und der Stammzertifizierungsstelle und nicht auf einem bestimmten Zertifikatfingerabdruck basiert, akzeptiert der Proxy weiterhin Verbindungen, nachdem verwaltetes HSM das Clientzertifikat gedreht hat, solange der gemeinsame Antragstellername und die Stammzertifizierungsstelle unverändert sind.

mTLS-Clientzertifikatsrotation

Microsoft rotiert das verwaltete HSM-Clientzertifikat planmäßig. Das neue Zertifikat wird ausgestellt, bevor das alte abläuft, und das verwaltete HSM verwendet nach der Rotation automatisch das neue Zertifikat.

Da der Proxy anhand des Common Name des Antragstellers und der Stammzertifikate und nicht anhand eines bestimmten Zertifikats ein Zertifikat auf die Zulassungsliste setzt, ist bei einer Zertifikatserneuerung keine Aktion erforderlich, solange der Common Name des Antragstellers und caCertificates unverändert bleiben.

Überwachungsstrategie:

  1. Führen Sie az keyvault ekm-connection certificate show --hsm-name <Managed HSM Name> nach einem Zeitplan aus (z. B. wöchentlich mithilfe eines Cron-Jobs oder eines Azure Automation-Runbooks).
  2. Achten Sie auf Änderungen am zurückgegebenen caCertificates Array.
  3. Wenn sich caCertificates ändert, rufen Sie das neue caCertificates-Array ab und fügen Sie es auf Ihrer EKM-Proxy-Seite der Zulassungsliste hinzu.

Firewall- und DNS-Anforderungen

Konfigurieren Sie firewallregeln und DNS im Netzwerk, in dem Ihr EKM-Proxy ausgeführt wird.

Firewallregeln

Konfigurieren Sie die Firewall in dem Netzwerksegment, in dem der Proxy läuft:

  • Eingehende TCP 443 aus dem öffentlichen Internet zulassen. Für die Vorschau ist Port 443 speziell erforderlich. Verwaltete HSM-Quell-IPs sind nicht statisch und können nicht zugelassen werden, sodass Sie eingehenden Datenverkehr nicht auf verwaltetes HSM beschränken können.
  • Eingehende TLS-1.3-Verbindungen mit den erforderlichen Verschlüsselungssuiten zulassen.

Hinweis

Für den ausgehenden Datenverkehr von Managed HSM EKM in der Vorschau sind keine Azure-Diensttags vorhanden. Da verwaltete HSM-Quell-IPs nicht statisch sind, wird die IP-basierte Zulassungsauflistung nicht unterstützt. Der Proxy muss TCP 443 aus einer beliebigen Quelle akzeptieren. Die mTLS-Clientzertifikatüberprüfung ist der einzige unterstützte Zugriffssteuerungsmechanismus.

Verlassen Sie sich nicht auf die IP-basierte Zulassungsauflistung als Sicherheitskontrolle. mTLS-Clientzertifikatüberprüfung ist der Authentifizierungsmechanismus, der den Proxy schützt.

DNS-Anforderungen

  • Der für die Verbindung zur externen Schlüsselverwaltung konfigurierte Proxy-FQDN muss aus Sicht des verwalteten HSM in eine öffentlich erreichbare Adresse aufgelöst werden.
  • Wenn Sie die Proxyadresse ändern, aktualisieren Sie die Externe Schlüsselverwaltungsverbindung, um den neuen FQDN oder die neue IP widerzuspiegeln. Die DNS-Auflösung erfolgt in Managed HSM bei jeder Verbindung.

Problembehandlung bei allgemeinen Netzwerkfehlern

Die vollständige Anleitung zur Problembehandlung finden Sie unter "Problembehandlung für die Verwaltung von verwalteten HSM-externen Schlüsseln". Die drei häufigsten netzwerkspezifischen Symptome sind:

Zertifikatskonflikt

Der mTLS-Handshake schlägt fehl, weil das Serverzertifikat des Proxys keine Zertifikatskette zu der Zertifizierungsstelle bildet, die für die Verbindung zur externen Schlüsselverwaltung registriert ist, oder weil der Antragstellername oder die Stammzertifizierungsstelle des Clientzertifikats des veralteten HSM nicht in der Zulassungsliste des Proxys enthalten ist. Prüfen Sie az keyvault ekm-connection certificate show und vergewissern Sie sich, dass die Proxy-Allowlist aktuell ist. Überprüfen Sie, ob --server-ca-certificate der Verbindung zur externen Schlüsselverwaltung mit der Stammzertifizierungsstelle übereinstimmt, die das aktuelle Proxy-Zertifikat ausgestellt hat.

Fehler bei der Namensauflösung

Verwaltetes HSM kann den Proxy-FQDN nicht auflösen. Dies geschieht, wenn der öffentliche DNS-Eintrag für den Proxy fehlt oder veraltet ist. Vergewissern Sie sich, dass der FQDN in der Verbindung zur externen Schlüsselverwaltung auf die richtige öffentliche IP aufgelöst wird.

Zeitüberschreibung beim Verbinden

Die TCP-Verbindung zum Proxy läuft in einen Timeout. Eine häufige Ursache ist eine Firewallregel, die eingehenden Datenverkehr am Proxy-Port blockiert. Überprüfen Sie die Firewall-Protokolle und vergewissern Sie sich, dass der Proxy auf dem erwarteten Port lauscht.

Verwandte Inhalte

  • Last updated on