End-to-End-TLS mit Azure Front Door
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 Browser hergestellt wird. Über diese Verbindung wird sichergestellt, dass alle Daten privat und verschlüsselt zwischen dem Webserver und dem Webbrowser übertragen werden.
Um Ihre Sicherheits- oder Complianceanforderungen zu erfüllen, unterstützt Azure Front Door (AFD) die End-to-End-TLS-Verschlüsselung. Die Front Door-TLS/SSL-Auslagerung beendet die TLS-Verbindung, entschlüsselt den Datenverkehr in Azure Front Door und verschlüsselt den Datenverkehr erneut, bevor er an das Back-End weitergeleitet wird. Da Verbindungen mit dem Back-End über die öffentliche IP-Adresse erfolgen, wird dringend empfohlen, dass Sie HTTPS als Weiterleitungsprotokoll in Azure Front Door konfigurieren, um die End-to-End-TLS-Verschlüsselung vom Client zum Back-End zu erzwingen. TLS/SSL-Offload wird auch unterstützt, wenn Sie ein privates Back-End mit Azure Front Door Premium mithilfe des PrivateLink-Features bereitstellen.
End-to-End-TLS-Verschlüsselung
Mit End-to-End-TLS können Sie vertrauliche Daten während der Übertragung an das Back-End 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 das entsprechende Back-End im Back-End-Pool weiterzuleiten. Azure Front Door stellt dann eine neue TLS-Verbindung mit dem Back-End her und verschlüsselt alle Daten mithilfe des Back-End-Zertifikats erneut, bevor die Anforderung an das Back-End übertragen wird. Antworten vom Back-End 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 drei Versionen des TLS-Protokolls: TLS-Versionen 1.0, 1.1 und 1.2. Alle Azure Front Door-Profile, die nach September 2019 erstellt wurden, verwenden TLS 1.2 als Mindeststandard, TLS 1.0 und TLS 1.1 werden jedoch aus Gründen der Abwärtskompatibilität auch weiterhin unterstützt.
Obwohl Azure Front Door TLS 1.2 unterstützt, bei dem die Clientauthentizierung/gegenseitige Authentifizierung 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. Wenn Azure Front Door TLS-Datenverkehr an das Back-End initiiert, versucht es, die beste TLS-Version auszuhandeln, die vom Back-End zuverlässig und konsistent akzeptiert wird.
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.
Back-End-TLS-Verbindung (Azure Front Door zum Back-End)
Bei HTTPS-Verbindungen erwartet Azure Front Door, dass Ihr Back-End ein Zertifikat von einer gültigen Zertifizierungsstelle vorlegt, und dass die Antragstellernamen mit dem Back-End-Hostnamen übereinstimmen. Wenn beispielsweise der Back-End-Hostname auf myapp-centralus.contosonews.net festgelegt ist und das Zertifikat, das Ihr Back-End während des TLS-Handshakes vorlegt, weder myapp-centralus.contosonews.net noch *.contosonews.net im Antragstellernamen aufweist, verweigert Azure Front Door die Verbindung, und ein Fehler tritt auf.
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.
Aus Sicherheitsgründen wird es nicht empfohlen, die Überprüfung des Zertifikatsubjektnamens zu deaktivieren. In bestimmten Anwendungsfällen, etwa zum Testen, können Sie als Problemumgehung zum Beheben fehlerhafter HTTPS-Verbindungen die Überprüfung des Namens des Zertifikatantragstellers 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. Die Option zum Deaktivieren dieses Features ist für jede Azure Front Door-Ebene unterschiedlich:
- Azure Front Door Standard und Premium: Sie finden die Option in den Ursprungseinstellungen.
- Azure Front Door (klassisch): Sie finden die Option in den Azure Front Door-Einstellungen im Azure-Portal und unter „BackendPoolsSettings“ in der Azure Front Door-API.
Front-End-TLS-Verbindung (Client zu 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.
Ein von Azure Front Door verwaltetes Zertifikat stellt über Digicert ein TLS/SSL-Standardzertifikat zur Verfügung und wird im Schlüsseltresor 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:
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 1 bis 2 Tagen unabhängig von der Ablauffrist automatisch zu einer neueren Version des Zertifikats rotiert.
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.
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 (SAN) für das Zertifikat nicht ändert.
Unterstützte Verschlüsselungssammlungen:
Bei TLS1.2 werden folgende Verschlüsselungssammlungen unterstützt:
- 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-Verschlüsselungsverfahren zu aktivieren, um die Sicherheit zu erhöhen. CBC-Verschlüsselungsverfahren unterstützen die Betriebssysteme Windows 8.1, 8 und 7. Die DHE-Verschlüsselungssammlungen werden zukünftig deaktiviert sein.
Wenn Sie benutzerdefinierte Domänen mit TLS 1.0/1.1 verwenden, werden die folgenden Verschlüsselungssammlungen unterstützt:
- 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 Konfigurieren bestimmter Chiffrensammlungen (Cipher Suites) nicht.