End-to-End-TLS mit Azure Front Door

  • Artikel

Transport Layer Security (TLS), zuvor bekannt als Secure Sockets Layer (SSL), ist die standardmäßige Sicherheitstechnologie, mit der eine verschlüsselte Verbindung zwischen einem Webserver und einem Client, beispielsweise einem Webbrowser, hergestellt wird. Diese Verbindung stellt sicher, dass alle Daten, die zwischen dem Server und dem Client übertragen werden, privat und verschlüsselt bleiben.

Um Ihre Sicherheits- oder Complianceanforderungen zu erfüllen, unterstützt Azure Front Door die End-to-End-TLS-Verschlüsselung. Die Front Door-TLS/SSL-Auslagerung beendet die TLS-Verbindung, entschlüsselt den Datenverkehr bei Azure Front Door, und verschlüsselt den Datenverkehr erneut, bevor er an den Ursprung weitergeleitet wird. Wenn Verbindungen mit dem Ursprung die öffentliche IP-Adresse des Ursprungs verwenden, ist es eine gute Sicherheitspraxis, HTTPS als Weiterleitungsprotokoll in Ihrer Azure Front Door zu konfigurieren. Wenn Sie HTTPS als Weiterleitungsprotokoll verwenden, können Sie die End-to-End-TLS-Verschlüsselung für die gesamte Verarbeitung der Anforderung vom Client bis zum Ursprung erzwingen. Die TLS/SSL-Auslagerung wird auch unterstützt, wenn Sie einen privaten Ursprung mit Azure Front Door Premium mithilfe des Private Link-Features bereitstellen.

In diesem Artikel wird erläutert, wie Azure Front Door mit TLS-Verbindungen funktioniert. Weitere Informationen zur Verwendung von TLS-Zertifikaten mit Ihren eigenen benutzerdefinierten Domänen finden Sie unter HTTPS für benutzerdefinierte Domänen. Informationen zum Konfigurieren eines TLS-Zertifikats in Ihrer eigenen benutzerdefinierten Domäne finden Sie unter Konfigurieren einer benutzerdefinierten Domäne in Azure Front Door mithilfe des Azure-Portals.

End-to-End-TLS-Verschlüsselung

Mit End-to-End-TLS können Sie vertrauliche Daten während der Übertragung an den Ursprung sichern und gleichzeitig von Azure Front Door-Features wie z. B. einem globalem Lastenausgleich und Zwischenspeichern profitieren. Weitere Features sind u. a. das URL-basierte Routing, die TCP-Aufteilung, das Zwischenspeichern an dem Edge-Standort, der den Clients am nächsten ist und das benutzerdefinierte Anpassen von HTTP-Anforderungen am Edge.

Azure Front Door lagert die TLS-Sitzungen am Edge aus und entschlüsselt Clientanforderungen. Anschließend werden die konfigurierten Routingregeln angewendet, um die Anforderungen an den entsprechenden Ursprung in der Ursprungsgruppe weiterzuleiten. Azure Front Door stellt dann eine neue TLS-Verbindung mit dem Ursprung her und verschlüsselt alle Daten mithilfe des Zertifikats des Ursprungs erneut, bevor die Anforderung an den Ursprung übertragen wird. Antworten des Ursprungs durchlaufen denselben Verschlüsselungsprozess zurück an den Endbenutzer. Sie können Azure Front Door so konfigurieren, dass HTTPS als Weiterleitungsprotokoll verwendet wird, um End-to-End-TLS zu aktivieren.

Unterstützte TLS-Versionen

Azure Front Door unterstützt vier Versionen des TLS-Protokolls: TLS-Versionen 1.0, 1.1, 1.2 und 1.3. Alle Azure Front Door-Profile, die nach September 2019 erstellt wurden, verwenden als Mindeststandard TLS 1.2 und haben TLS 1.3 aktiviert. TLS 1.0 und TLS 1.1 werden jedoch aus Gründen der Abwärtskompatibilität weiterhin unterstützt.

Obwohl Azure Front Door TLS 1.2 unterstützt, bei dem die Client-/gegenseitige Authentifizierung (mTLS) in RFC 5246 eingeführt wurde, unterstützt Azure Front Door diese Authentifizierungsart zurzeit nicht.

Sie können die TLS-Mindestversion in Azure Front Door in den HTTPS-Einstellungen der benutzerdefinierten Domäne über das Azure-Portal oder die Azure-REST-API konfigurieren. Derzeit können Sie zwischen 1.0 und 1.2 wählen. Wenn Sie TLS 1.2 als Mindestversion angeben, steuern Sie so die TLS-Mindestversion, die Azure Front Door von einem Client akzeptiert. Für die Mindestversion TLS 1.2 versucht die Aushandlung, TLS 1.3 und dann TLS 1.2 einzurichten, während für die Mindestversion TLS 1.0 alle vier Versionen versucht werden. Wenn Azure Front Door TLS-Datenverkehr an den Ursprung initiiert, versucht es, die beste TLS-Version auszuhandeln, die vom Ursprung zuverlässig und konsistent akzeptiert werden kann. Die unterstützten TLS-Versionen für Ursprungsverbindungen sind TLS 1.0, TLS 1.1, TLS 1.2 und TLS 1.3.

Hinweis

  • Um eine der Microsoft SDL-kompatiblen EC-Kurven zu unterstützen (einschließlich Secp384r1, Secp256r1 und Secp521) und um erfolgreich Anforderungen mit Azure Front Door über TLS 1.3 durchzuführen, sind Clients mit aktiviertem TLS 1.3 erforderlich.
  • Es wird empfohlen, dass Clients eine dieser Kurven als bevorzugte Kurve bei Anforderungen verwenden, um eine erhöhte TLS-Handshakelatenz zu vermeiden, die auftreten kann, wenn mehrere Roundtrips erforderlich sind, um die unterstützte EC-Kurve auszuhandeln.

Unterstützte Zertifikate

Wenn Sie Ihr TLS/SSL-Zertifikat erstellen, müssen Sie eine vollständige Zertifikatkette mit einer zulässigen Zertifizierungsstelle erstellen, die in der Microsoft-Liste der vertrauenswürdigen Zertifizierungsstellen enthalten ist. Bei Verwendung einer unzulässigen Zertifizierungsstelle wird Ihre Anforderung abgelehnt.

Zertifikate von internen Zertifizierungsstellen oder selbstsignierte Zertifikate sind nicht zulässig.

OCSP-Anheftung (Online Certificate Status Protocol)

Die OCSP-Anheftung wird in Azure Front Door standardmäßig unterstützt. Es ist keine Konfiguration erforderlich.

Ursprung-TLS-Verbindung (Azure Front Door zum Ursprung)

Bei HTTPS-Verbindungen erwartet Azure Front Door, dass Ihr Ursprung ein Zertifikat von einer gültigen Zertifizierungsstelle (ZS) vorlegt mit einem Antragstellernamen, der mit dem Hostnamen des Ursprungs übereinstimmt. Wenn beispielsweise der Ursprungshostname auf myapp-centralus.contosonews.net festgelegt ist und das Zertifikat, das Ihr Ursprung während des TLS-Handshakes vorlegt, weder myapp-centralus.contosonews.net noch *.contosonews.net im Antragstellernamen aufweist, dann verweigert Azure Front Door die Verbindung, und der Client wird einen Fehler erhalten.

Hinweis

Das Zertifikat muss über eine vollständige Zertifikatkette mit Blatt- und Zwischenzertifikaten verfügen. Die Stammzertifizierungsstelle muss in der Microsoft-Liste der vertrauenswürdigen Zertifizierungsstellen enthalten sein. Wenn ein Zertifikat ohne vollständige Kette präsentiert wird, funktionieren die Anforderungen, die dieses Zertifikat beinhalten, nicht wie erwartet.

In bestimmten Anwendungsfällen, etwa zum Testen, können Sie als Problemumgehung zum Beheben fehlerhafter HTTPS-Verbindungen die Überprüfung des Zertifikatantragstellernamens für Ihre Azure Front Door-Instanz deaktivieren. Beachten Sie, dass der Ursprung weiterhin ein Zertifikat mit einer gültigen vertrauenswürdigen Kette präsentieren, aber nicht mit dem Namen des Ursprungshosts übereinstimmen muss.

In Azure Front Door Standard und Premium können Sie einen Ursprung konfigurieren, um die Überprüfung des Zertifikatantragstellernamens zu deaktivieren.

In Azure Front Door (klassisch) können Sie die Überprüfung des Zertifikatantragstellernamens deaktivieren, indem Sie die Azure Front Door-Einstellungen im Azure-Portal ändern. Sie können die Überprüfung auch mithilfe der Einstellungen des Back-End-Pools in den Azure Front Door-APIs konfigurieren.

Hinweis

Aus Sicherheitsgründen empfiehlt Microsoft, die Überprüfung des Zertifikatantragstellernamens nicht zu deaktivieren.

Front-End-TLS-Verbindung (Client zu Azure Front Door)

Um das HTTPS-Protokoll für die sichere Bereitstellung von Inhalten in einer benutzerdefinierten Azure Front Door-Domäne zu aktivieren, können Sie ein von Azure Front Door verwaltetes oder Ihr eigenes Zertifikat verwenden.

Weitere Informationen finden Sie unter HTTPS für benutzerdefinierte Domänen.

Ein von Azure Front Door verwaltetes Zertifikat stellt über DigiCert ein TLS/SSL-Standardzertifikat zur Verfügung und wird im Key Vault von Azure Front Door gespeichert.

Wenn Sie ein eigenes Zertifikat verwenden möchten, können Sie ein Zertifikat einer unterstützten Zertifizierungsstelle integrieren. Hierbei kann es sich um ein Standard-TLS-, ein erweitertes Validierungs- oder sogar um ein Platzhalterzertifikat handeln. Selbstsignierte Zertifikate werden nicht unterstützt. Weitere Informationen zu Aktivieren von HTTPS für eine benutzerdefinierte Domäne.

Automatische Zertifikatrotation

Von Azure Front Door verwaltete Zertifikate werden innerhalb von 90 Tagen vor dem Ende der Ablaufzeit automatisch von Azure Front Door zur neuesten Version rotiert. Von Azure Front Door verwaltete Standard-/Premium-Zertifikate werden innerhalb von 45 Tagen vor dem Ende der Ablaufzeit automatisch von Azure Front Door zur neuesten Version rotiert. Wenn Sie ein von Azure Front Door verwaltetes Zertifikat verwenden und feststellen, dass das Ablaufdatum des Zertifikats weniger als 60 Tage oder, was die Standard-/Premium-SKU angeht, weniger als 30 Tage entfernt ist, sollten Sie ein Supportticket erstellen.

Für Ihr eigenes benutzerdefiniertes TLS/SSL-Zertifikat:

  1. Legen Sie die Geheimnisversion auf „Neueste“ fest, damit das Zertifikat automatisch zur neuesten Version rotiert wird, wenn eine neuere Version des Zertifikats in Ihrem Schlüsseltresor verfügbar ist. Bei benutzerdefinierten Zertifikaten wird das Zertifikat innerhalb von 3 bis 4 Tagen unabhängig von der Ablauffrist automatisch zu einer neueren Version des Zertifikats rotiert.

  2. Bei der Auswahl einer bestimmten Version wird die automatische Rotation nicht unterstützt. Sie müssen die neue Version manuell auswählen, um das Zertifikat zu rotieren. Es dauert bis zu 24 Stunden, bis die neue Version des Zertifikats/Geheimnisses bereitgestellt wird.

    Hinweis

    Verwaltete Azure Front Door-Zertifikate (Standard und Premium) werden automatisch rotiert, wenn der CNAME-Domäneneintrag direkt auf einen Front Door-Endpunkt oder indirekt auf einen Traffic Manager-Endpunkt verweist. Andernfalls müssen Sie das Domäneneigentum erneut überprüfen, um die Zertifikate zu rotieren.

    Sie müssen sicherstellen, dass der Dienstprinzipal für Front Door Zugriff auf den Schlüsseltresor hat. Informationen finden Sie unter „Gewähren des Zugriffs auf Ihren Schlüsseltresor“. Der aktualisierte Zertifikatrolloutvorgang von Azure Front Door verursacht keine Downtime in der Produktion, sofern sich der Antragstellername oder der alternative Antragstellername (Subject Alternate Name, SAN) für das Zertifikat nicht geändert haben.

Unterstützte Verschlüsselungssammlungen:

Für TLS 1.2/1.3 werden folgende Verschlüsselungssammlungen unterstützt:

  • TLS_AES_256_GCM_SHA384 (nur TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (nur TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Hinweis

Für Windows 10 und höhere Versionen wird empfohlen, eine oder beide Suites mit ECDHE_GCM-Verschlüsselungsverfahren zu aktivieren, um die Sicherheit zu erhöhen. Windows 8.1, 8 und 7 sind nicht mit diesen Suites mit ECDHE_GCM-Verschlüsselungsverfahren kompatibel. Die Suites mit ECDHE_GCM- und DHE-Verschlüsselungsverfahren wurden aus Gründen der Kompatibilität mit diesen Betriebssystemen bereitgestellt.

Wenn Sie benutzerdefinierte Domänen mit TLS1.1.0 und 1.1 verwenden, werden folgende Suites mit Verschlüsselungsverfahren unterstützt:

  • TLS_AES_256_GCM_SHA384 (nur TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (nur TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Azure Front Door unterstützt das Deaktivieren oder Konfigurieren bestimmter Suites mit Verschlüsselungsverfahren für Ihr Profil nicht.

Nächste Schritte