Mutual TLS authentication in Azure Front Door (preview)

Gilt für: ✔️ Front Door Premium

Die gegenseitige TLS-Authentifizierung (mTLS) oder Client-Authentifizierung stellt sicher, dass der Datenverkehr in beide Richtungen zwischen Client und Server sicher und vertrauenswürdig ist. Durch die Verwendung von mutual TLS können Sie Azure Front Door so konfigurieren, dass Sie die Client-Identität durch Vorlage eines gültigen Client-Zertifikats überprüfen. Die gegenseitige TLS-Authentifizierung ist nützlich für Situationen, in denen Sie die Kunden sicher identifizieren und verwalten müssen, um Ressourcen gezielt zu nutzen, wie z. B. Business-to-Business-Anwendungen (B2B), Internet der Dinge (IoT)-Anwendungen, Banking-Apps, VPNs, Unternehmensnetzwerke und mehr.

Sie können gegenseitiges TLS zusammen mit anderen Autorisierungen und Authentifizierungsmethoden verwenden, die von Azure Front Door unterstützt werden.

Gegenseitige TLS-Validierungsmodi

• Deaktiviere mTLS: Client-Zertifikat und Validierungen sind nicht erforderlich. Diese Option ist die Standardeinstellung.

• mTLS aktivieren:

  • Kundenzertifikat erforderlich und validiert: Das Kundenzertifikat ist verpflichtend. Azure Front Door führt die vollständige Validierung durch, einschließlich der Überprüfung der Anwesenheit und Gültigkeit von Client-Zertifikaten, Überprüfung gegen Widerruf und Root-CA-Kette sowie SAN/CN-Liste. Azure Front Door leitet die Anfrage mit Header X-Azure-ClientCertificate an den Ursprung weiter. Diese Option ist das Standardszenario, wenn mTLS aktiviert ist.

  • Kundenzertifikat erforderlich, aber nicht validiert: Das Kundenzertifikat ist verpflichtend. Azure Front Door führt keine weiteren Validierungen durch. Azure Front Door lässt Anfragen fallen, die keine Zertifikate enthalten. Der Ursprung muss alle Validierungen durchführen. Standardmäßig leitet Azure Front Door das Zertifikat in diesem Modus über Header an das Backend weiter.

    • Validierung des Client-Zertifikats, falls vorhanden: Ein Kundenzertifikat ist nicht verpflichtend. Azure Front Door führt eine vollständige Validierung durch, wenn ein Client-Zertifikat vorhanden ist, und leitet das Client-Zertifikat über X-Azure-ClientCertificate den Header an den Ursprung weiter. Wenn der Client kein Client-Zertifikat vorlegt, leitet Azure Front Door die Anfrage zur weiteren Validierung an den Ursprung weiter.

  • mTLS-Passthrough zum Ursprungs: Ein Kundenzertifikat ist nicht erforderlich. Azure Front Door führt keine Validierungen durch. Der Ursprung muss alle Validierungen durchführen.

Validierung der Client-Authentifizierung

Wenn Sie Azure Front Door konfigurieren, um das Client-Zertifikat zu validieren, überprüft es folgende Informationen:

• Das aktuelle Datum ist niedriger als das Zertifikatsdatum Not After .

• Das aktuelle Datum ist größer als oder gleich dem Zertifikatsdatum Not Before .

• Certificate Extended Key Usage ist nicht vorhanden oder, falls vorhanden, enthält es das Client-Authentifizierungs-OID.

• Gültigkeit und Integrität, dass das Zertifikat nicht verändert wurde, das Format des Zertifikats.

• Überprüfen Sie die Zertifikatskette: Wenn das Client-Zertifikat von einem vertrauenswürdigen Herausgeber für die angegebene Domäne ausgestellt wird, bildet CN (Zertifikatsname) der Zertifizierungen eine ununterbrochene Kette.

Sie können auch optionale Validierungen konfigurieren, wie zum Beispiel:

• Validiere die SAN/CN-Erweiterung des Client-Zertifikats anhand der Allowed SAN-Liste, die zu Azure Front Door hochgeladen wurde. Der benutzerdefinierte Domain-Hostname von Azure Front Door muss explizit in dieser Liste enthalten sein, um für die gegenseitige TLS-Validierung gültig zu sein. SAN wird zuerst validiert; wenn kein Match oder SAN leer ist, wird CN validiert. Wenn eines von SAN oder CN mit der erlaubten SAN-Liste übereinstimmt, die in Azure Front Door konfiguriert ist, gelingt die Validierung.

• Überprüfen Sie den Widerrufsstatus des Client-Zertifikats mit OCSP (Online Certificate Status Protocol).

Überprüfung des Zertifikatswiderrufs

Azure Front Door unterstützt die Validierung gegen den Status des Zertifikatswiderrufs. Standardmäßig ist sie aktiviert. Während der Validierung sucht Azure Front Door das vom Client präsentierte Zertifikat mithilfe des definierten OCSP-Responders in seiner Authority Information Access (AIA)-Erweiterung nach. Wenn das Client-Zertifikat widerrufen wird, antwortet Azure Front Door dem Client mit einem HTTP-403-Statuscode und Begründung. Wenn das Zertifikat gültig ist, bearbeitet Azure Front Door die Anfrage weiter.

Unterstützt mTLS öffentliche und private Zertifikate?

Azure Front Door unterstützt derzeit Zertifikate, die sowohl von bekannten öffentlichen Zertifikatsstellen als auch von privat etablierten Zertifizierungsstellen ausgestellt werden.

• CA-Zertifikate, die von bekannten Zertifikatsstellen ausgestellt wurden: Trusted certificate stores umfassen häufig Zwischen- und Root-Zertifikate, die vertrauenswürdige Verbindungen mit wenig bis gar keiner zusätzlichen Konfiguration auf dem Gerät ermöglichen.

• CA-Zertifikate, die von der Organisation etablierten Zertifizierungsstellen ausgestellt werden: Ihre Organisation stellt diese Zertifikate in der Regel privat aus, und andere Einrichtungen vertrauen ihnen nicht. Sie müssen Zwischen- und Root-Zertifikate in vertrauenswürdige Zertifikatsspeicher importieren, damit Kunden Chain Trust aufbauen können.

Azure Front Door führt jedoch Extended Key Usage (EKU)-Prüfungen bei Client-Zertifikaten durch, um sicherzustellen, dass sie für die Client-Authentifizierung gedacht sind. Aufgrund von Veränderungen in der Branche stellen öffentliche Zertifizierungsstellen (CAs) bald auf, Kunden-Authentifizierungszertifikate mit dem erforderlichen EKU auszustellen.

Wechsel zu privaten CAs, die weiterhin Zertifikate mit der richtigen EKU ausstellen können, für mTLS-Szenarien auf Azure Front Door. Dieser Übergang gewährleistet eine unterbrechungsfreie und sichere Client-Authentifizierung.

Wichtige Designüberlegungen vor der Implementierung von mTLS auf Front Door-Domänen

• Aktivieren Sie mTLS auf neuen Domains und neuen Endpunkten, um unnötige Ausfallzeiten zu vermeiden.

• Wenn du mTLS aktivierst, kannst du kein Caching auf Routen oder Routenüberschreibungen in der Regel-Engine mit Caching aktivieren. Diese Einschränkung verhindert, dass zwischengespeicherte Inhalte an nicht authentifizierte Clients zurückgegeben werden.

• mTLS funktioniert funktional auf der Domäne. Um jedoch Sicherheit zu gewährleisten, wo böswillige Nutzer mTLS nicht umgehen können, um Ihren Ursprung zu erreichen, gibt es eine mTLS-Kontrolle am Azure Front Door-Endpunkt. Bevor Sie mTLS auf einer benutzerdefinierten Domain aktivieren, aktivieren Sie zunächst mTLS am Azure Front Door-Endpunkt, mit dem die benutzerdefinierte Domain verknüpft ist. Alle Domänen mit mTLS können nur mit Routen unter solchen Endpunkten verknüpft werden. Man kann Domains mit gemischtem Zustand der gegenseitigen Authentifizierung nicht mit demselben Endpunkt verknüpfen.

• Man kann die Azure Front Door-Endpunktdomäne nicht mit Routen verknüpfen, wenn mTLS am Front Door-Endpunkt aktiviert ist. Umgekehrt müssen Sie die Endpunktdomäne von allen Routen unter dem Endpunkt trennen, bevor Sie mTLS am Endpunkt aktivieren.

• Es gibt Ausfallzeiten, wenn du mTLS auf einer bestehenden Azure Front Door-Domain aktivierst, da du die folgenden Änderungen vornehmen musst. Aktivieren Sie mTLS für neue benutzerdefinierte Domains.

1. Erstellen Sie einen neuen Endpunkt mit aktiviertem mTLS oder verwenden Sie einen bestehenden Azure Front Door-Endpunkt mit aktiviertem mTLS.

2. Trenne die benutzerdefinierte Domain von den bestehenden Routen und dem Endpunkt, die mTLS nicht aktiviert haben.

3. Dann ordne die benutzerdefinierte Domain wieder dem Endpunkt zu.

• Sobald die gegenseitige Authentifizierung auf einer Domain aktiviert ist, führt das Deaktivieren auch zu Ausfallzeiten.

  1. Trennen Sie die benutzerdefinierte Domain von allen Routen unter dem bestehenden mTLS-fähigen Endpunkt.

  2. Deaktiviere mTLS auf der Domain.

  3. Verbinde die Domain wieder mit einem anderen Endpunkt ohne aktiviertes mTLS.

• Füge Zugangskontrolle zu deinem Ursprung hinzu, um zu bestätigen, dass die Anfrage von einer gültigen Front Door kommt. Weitere Informationen finden Sie unter Sicherer Datenverkehr zu Azure Front Door-Herkünften.

• CA Certificate Management: Laden Sie eine Root und bis zu drei Intermediates (PEM, <25 KB) über Azure Key Vault hoch. Keine Autorotation, aber Dual-CA-Unterstützung ermöglicht nahtloses Rollover.

• Azure Front Door führt Extended Key Usage (EKU)-Prüfungen bei Client-Zertifikaten durch, um sicherzustellen, dass sie für die Client-Authentifizierung gedacht sind, was eine wichtige Sicherheitsmaßnahme ist. Aufgrund von Veränderungen in der Branche werden öffentliche Zertifizierungsstellen (CAs) jedoch bald aufhören, Kundenauthentifizierungszertifikate mit dem erforderlichen EKU auszustellen. Wechsel zu privaten CAs, die weiterhin Zertifikate mit der richtigen EKU für mTLS-Szenarien auf Azure Front Door ausstellen können, um eine unterbrechungsfreie und sichere Client-Authentifizierung sicherzustellen.

• Kunden entfernen sich von OCSP. Während der Überprüfung der Zertifikatswiderrufsprüfung von Front Door überprüft Azure Front Door derzeit nur OCSP.

• Wenn der Client Anfragen mit den folgenden Headern sendet, entfernt Azure Front Door die Header und leitet die Anfrage an den Ursprung weiter.

  • X-Azure-ClientCertEndDate
  • X-Azure-ClientCertFingerprint
  • X-Azure-ClientCertIssuer
  • X-Azure-ClientCertSerial
  • X-Azure-ClientCertStartDate
  • X-Azure-ClientCertSubject
  • X-Azure-ClientCertVerify
  • X-Azure-ClientCertificate

Welche Metriken und Logfelder stellt die Lösung frei?

Die Lösung stellt folgende Metriken offen:

• Anzahl der mTLS-Anfragen.

• MTLS-Anfragen fehlgeschlagen.

• mTLS-Fehleranfragen, unterteilt nach Fehlertypen, SNI-Hostnamen und TLS-Protokollen.

Konfigurationsquoten-Limit

• Die Zertifikatskette der Client-CA kann eine Wurzel und bis zu drei Intermediates umfassen.

• CA-Zertifikate müssen PEM-codiert und unter 25 KB sein.

• Auto-Rotation wird nicht unterstützt.

• Sie können zwei CA-Zertifikate anhängen, um eine nahtlose Übertragung während Ablauf oder Widerruf zu gewährleisten. Azure Front Door verwendet das gültige CA-Zertifikat zur Validierung während der Laufzeit.

Konfigurationsschritte

1. Um mehr über die Einschränkungen zu erfahren, siehe den Abschnitt zu wichtigen Designüberlegungen . Es wird empfohlen, mTLS auf neuen Endpunkten und Domänen zu aktivieren.

2. Melden Sie sich im Azure-Portal an und suchen Sie nach Ihrem Front Door-Profil.

3. Wählen Sie unter SicherheitMutual TLS CA-Zertifikate aus. Du siehst eine Liste deiner bestehenden mTLS-Zertifikatsketten, falls du in der Vergangenheit welche hochgeladen hast.

4. Klicken Sie auf + Hinzufügen. Du siehst Key Vault und geheime Objekte, auf die du Zugriff hast. Wählen Sie die Exemplare aus, die Sie als öffentlichen Schlüsselteil von mTLS Handshake verwenden möchten.

5. Unter Einstellungen wählen Sie Front Door Manager. Du siehst die Liste deiner Endpunkte.

6. Wählen Sie + Fügen Sie einen Endpunkt hinzu und aktivieren Sie Enforce mutual TLS.

   Note

   Du kannst die Standarddomäne von Azure Front Door (zum Beispiel .z01.azurefd.net) nicht als Domain zu den Routen auf diesem Endpunkt hinzufügen, wenn Enforce mutual TLS aktiviert ist. Gehe zum nächsten Schritt, um benutzerdefinierte Domains mit aktiviertem mTLS zu erstellen, bevor du Routen erstellst.

7. Wählen Sie unter Einstellungen die Option Domänen. Du siehst die Liste deiner bestehenden benutzerdefinierten Domains.

8. Klicken Sie auf + Hinzufügen.

9. Konfigurieren Sie auf der Seite "Hinzufügen einer Domäne " Ihre Domäne und scrollen Sie dann zu den erweiterten Einstellungen nach unten und wählen Sie "Enable mutual TLS", um das gemeinsame TLS für die Domain zu konfigurieren.

10. Wählen Sie Hinzufügen , um die Domain zu erstellen.

    1. Gegenseitiger TLS-Modus: Wählen Sie aus den vier Optionen

       • Kundenzertifikat erforderlich und validiert
       • Kundenzertifikat erforderlich, aber nicht validiert
       • Validierung des Client-Zertifikats, falls vorhanden
       • mTLS-Passthrough zum Ursprung

    2. Wählen Sie CA-Zertifikat aus, wenn es für Azure Front Door ausgefüllt ist, um das Client-Zertifikat zu validieren.

    3. Aktivieren Sie die Überprüfung des Zertifikatswiderrufs.

    4. Füge die SAN/CN-Liste hinzu, die abgeglichen werden soll. Der benutzerdefinierte Domain-Hostname von Azure Front Door muss explizit in dieser Liste enthalten sein, um für die gegenseitige TLS-Validierung gültig zu sein.

11. Nach erfolgreicher Domain-Erstellung gehen Sie zum zuvor erstellten Endpunkt unter Front Door Manager und fügen Sie eine Route hinzu, um diese Domain mit der richtigen Ursprungsgruppe zu verknüpfen.

12. Überprüfe, ob mTLS wie erwartet funktioniert. Sie können diese Bedingung überprüfen, indem Sie die lokale Host-IP an eine der Azure Front Door-IPs binden.

13. Nach erfolgreicher Validierung aktualisieren Sie den benutzerdefinierten CNMAE-Datensatz in DNS, sodass er auf den Azure Front Door-Endpunkt verweist.

    Beschränke den Backend-/Ursprungszugriff darauf, nur Verkehr von Azure Front Door zu akzeptieren, was verhindert, dass mTLS durch direkten Zugriff auf den Ursprung umgangen wird. Weitere Informationen finden Sie unter Sicherer Datenverkehr zu Azure Front Door-Herkünften.

Um die bestehende mTLS-Konfiguration einer Domain zu bearbeiten, wählen Sie auf der Seite Domains den Domainnamen aus. Die Seite "Domain bearbeiten" erscheint mit der aktuellen mTLS-Konfiguration.

Unexpected 403 (Forbidden) from Azure Front Door for mTLS request

Für weitere diagnostische Informationen geben Sie den Header X-Azure-DebugInfo:1 mit der Anfrage an Azure Front Door. Für die Antwort gibt Front Door den Debug-Header X-Azure-Externalerror, , mit einem Wert zurück, der andeutet, worum der Fehler liegen könnte. Die folgende Tabelle listet die Fehlerwerte und deren Bedeutungen auf.

Verwandte Inhalte

• TLS encryption with Azure Front Door
• TLS-Richtlinie für Azure Front Door