Übersicht über die gegenseitige Authentifizierung in Application Gateway

Die gegenseitige Authentifizierung, auch bekannt als Clientauthentifizierung, ermöglicht es dem Anwendungs-Gateway, den Client zu authentifizieren, um Anforderungen senden zu können. Normalerweise authentifiziert nur der Client das Anwendungsgateway. Die gegenseitige Authentifizierung ermöglicht es dem Client und dem Anwendungsgateway, sich gegenseitig zu authentifizieren.

Hinweis

Wir empfehlen die Verwendung von TLS 1.2 mit gegenseitiger Authentifizierung, da TLS 1.2 in Zukunft vorgeschrieben wird.

Gegenseitige Authentifizierung

Das Anwendungsgateway unterstützt zertifikatbasierte gegenseitige Authentifizierung. Sie können vertrauenswürdige Client-CA-Zertifikate in das Application Gateway hochladen, und das Gateway verwendet diese Zertifikate, um Clients zu authentifizieren, die Anfragen senden. Mit dem Anstieg der IoT-Anwendungsfälle und der erhöhten Sicherheitsanforderungen in allen Branchen bietet die gegenseitige Authentifizierung eine Möglichkeit, zu verwalten und zu steuern, welche Clients mit Ihrem Anwendungsgateway kommunizieren können.

Das Anwendungsgateway bietet die folgenden beiden Optionen zum Überprüfen von Clientzertifikaten:

Wechselseitiger TLS-Passthroughmodus

Im mTLS-Passthroughmodus (Mutual TLS) fordert Application Gateway während des TLS-Handshakes ein Clientzertifikat an, beendet jedoch die Verbindung nicht, wenn das Zertifikat fehlt oder ungültig ist. Die Verbindung mit dem Back-End wird unabhängig von der Anwesenheit oder Gültigkeit des Zertifikats fortgesetzt. Wenn ein Zertifikat bereitgestellt wird, kann es vom Anwendungsgateway bei Bedarf an das Back-End weitergeleitet werden. Der Back-End-Dienst ist für die Überprüfung des Clientzertifikats verantwortlich.

Vorteile des mTLS-Passthroughmodus

Der mTLS-Passthroughmodus bietet die folgenden Vorteile:

  • Vereinfachte Gateway-Konfiguration: Auf Gateway-Ebene ist kein Hochladen von Zertifikaten der Zertifizierungsstelle erforderlich.
  • Flexible Authentifizierung: Unterstützt Szenarien für gemischten Datenverkehr, in denen einige Clients Zertifikate und andere tokenbasierte Authentifizierung verwenden.
  • Erzwingung von Back-End-Richtlinien: Ermöglicht Ihrer Back-End-Anwendung die Implementierung benutzerdefinierter Zertifikatüberprüfungslogik und -richtlinien.
  • Reduzierter Gatewayaufwand: Lädt die Zertifikatüberprüfung an das Back-End, wodurch die Verarbeitung auf dem Gateway reduziert wird.
  • Schrittweise Migrationsunterstützung: Ermöglicht phasenweises Rollout von mTLS, ohne vorhandene Datenverkehrsmuster zu unterbrechen.

Konfigurieren Sie Servervariablen, um Clientzertifikate an das Back-End weiterzuleiten. Weitere Informationen finden Sie unter Servervariablen.

Konfigurieren des mTLS-Passthroughmodus

Sie können den mTLS-Passthroughmodus mithilfe des Azure Portals oder arm-Vorlagen konfigurieren.

So konfigurieren Sie den mTLS-Passthroughmodus im Azure Portal:

  1. Navigieren Sie zu Ihrer Application Gateway-Ressource.

  2. Wählen Sie unter "Einstellungen"SSL-Profile aus.

  3. Wählen Sie +Hinzufügen aus, um ein neues SSL-Profil zu erstellen.

  4. Geben Sie einen Namen für Ihr SSL-Profil ein.

  5. Wählen Sie auf der Registerkarte "Clientauthentifizierung " die Option "Passthrough" aus.

    Im Passthrough-Modus ist das Clientzertifikat optional. Der Back-End-Server ist für die Clientauthentifizierung verantwortlich.

    Screenshot mit dem Dialogfeld

  6. Konfigurieren Sie die SSL-Richtlinieneinstellungen nach Bedarf.

  7. Wählen Sie "Hinzufügen" aus, um das SSL-Profil zu erstellen.

  8. Ordnen Sie das SSL-Profil Ihrem HTTPS-Listener zu.

Hinweis

PowerShell- und CLI-Unterstützung für die Passthroughkonfiguration sind derzeit nicht verfügbar.

Strenger Modus für wechselseitiges TLS

Im gegenseitigen TLS-strikten Modus erzwingt das Anwendungsgateway die Clientzertifikatauthentifizierung, indem während des TLS-Handshakes ein gültiges Clientzertifikat erforderlich ist. Um den strikten Modus zu aktivieren, laden Sie ein CA-Zertifikat einer vertrauenswürdigen Clientzertifizierungsstelle hoch, das eine Stammzertifizierungsstelle und optional Zwischenzertifizierungsstellen als Teil des SSL-Profils enthält. Ordnen Sie dieses SSL-Profil einem Listener zu, um die gegenseitige Authentifizierung zu erzwingen.

Konfigurieren des strikten Modus für gegenseitiges TLS

Um den strikten Modus für die gegenseitige Authentifizierung zu konfigurieren, laden Sie ein zertifikat der vertrauenswürdigen Clientzertifizierungsstelle als Teil des Clientauthentifizierungsteils eines SSL-Profils hoch. Ordnen Sie dann das SSL-Profil einem Listener zu, um die Konfiguration abzuschließen. Das hochzuladende Clientzertifikat muss immer ein Stamm-CA-Zertifikat enthalten. Sie können eine Zertifikatkette hochladen, aber die Kette muss zusätzlich zu allen Zwischenzertifizierungsstellenzertifikaten ein Stammzertifizierungsstellenzertifikat enthalten. Die maximale Größe jeder hochgeladenen Datei darf maximal 25 KB betragen.

Wenn Ihr Clientzertifikat z.B. ein Wurzelzertifikats, mehrere Zwischenzertifikats und ein Blattzertifikat enthält, laden Sie sowohl das Wurzelzertifikats als auch alle Zwischenzertifikats in einer einzigen Datei zum Application Gateway hoch. Weitere Informationen zum Extrahieren eines CA-Zertifikats des vertrauenswürdigen Clients finden Sie unter Extrahieren von CA-Zertifikaten für vertrauenswürdige Clients.

Wenn Sie eine Zertifikatkette mit Zertifikaten der Stammzertifizierungsstelle und Zwischenzertifizierungsstellen hochladen, laden Sie die Zertifikatkette als PEM- oder CER-Datei in das Gateway hoch.

Wichtig

Laden Sie die gesamte Zertifikatkette der vertrauenswürdigen Clientzertifizierungsstelle zum Anwendungsgateway hoch, wenn Sie die wechselseitige Authentifizierung verwenden.

Jedes SSL-Profil kann bis zu 100 Zertifikatketten für vertrauenswürdige Clientzertifizierungsstellen unterstützen. Ein einzelnes Application Gateway kann insgesamt 200 vertrauenswürdige Client-Zertifizierungsstellen-Zertifikatketten unterstützen.

Hinweis

  • Die gegenseitige Authentifizierung ist nur für Standard_v2 und WAF_v2 SKUs verfügbar.
  • Die Konfiguration der gegenseitigen Authentifizierung für TLS-Protokolllistener ist derzeit über REST-API, PowerShell und CLI verfügbar.

Zertifikate, die für die gegenseitige TLS Strict Mode-Authentifizierung unterstützt werden

Application Gateway unterstützt sowohl von öffentlichen als auch von privaten Zertifizierungsstellen ausgestellte Zertifikate.

  • Zertifizierungsstellenzertifikate, die von bekannten Zertifizierungsstellen ausgestellt wurden: Zwischen- und Stammzertifikate werden häufig in vertrauenswürdigen Zertifikatspeichern gefunden und ermöglichen vertrauenswürdige Verbindungen mit wenig bis ohne zusätzliche Konfiguration auf dem Gerät.
  • CA-Zertifikate, die von der Organisation eingerichteten Zertifizierungsstellen ausgestellt werden: Diese Zertifikate werden in der Regel privat über Ihre Organisation ausgestellt und werden von anderen Entitäten nicht als vertrauenswürdig eingestuft. Um eine Vertrauenskette zu etablieren, importieren Sie Zwischen- und Stammzertifikate in vertrauenswürdige Zertifikatspeicher für Clients.

Hinweis

Wenn Sie Clientzertifikate von etablierten Zertifizierungsstellen ausstellen, sollten Sie mit der Zertifizierungsstelle zusammenarbeiten, um festzustellen, ob ein Zwischenzertifikat für Ihre Organisation ausgestellt werden kann. Dieser Ansatz verhindert versehentlich die organisationsübergreifende Clientzertifikatauthentifizierung.

Überprüfung der Client-Authentifizierung für den strengen Mutual-TLS-Modus

Clientzertifikat-DN überprüfen

Sie können den unmittelbaren Aussteller des Clientzertifikats überprüfen und nur zulassen, dass das Anwendungsgateway diesem Aussteller vertraut. Diese Option ist standardmäßig deaktiviert, Sie können sie aber über das Portal, PowerShell oder Azure CLI aktivieren.

Wenn Sie das Anwendungsgateway aktivieren, um den unmittelbaren Aussteller des Clientzertifikats zu überprüfen, beschreiben die folgenden Szenarien, wie der Clientzertifikatherausgeber DN aus den hochgeladenen Zertifikaten extrahiert wird:

  • Szenario 1: Die Zertifikatkette umfasst Stammzertifikate, Zwischenzertifikate und Blattzertifikate.
    • Der Betreffname des Zwischenzertifikats wird als Issuer-DN des Clientzertifikats extrahiert.
  • Szenario 2: Die Zertifikatskette umfasst Stammzertifikat, Zwischenzertifikat1, Zwischenzertifikat2 und Blattzertifikat.
    • Der Betreffname des Intermediate2-Zertifikats wird als Aussteller-DN des Clientzertifikats extrahiert.
  • Szenario 3: Zertifikatkette umfasst Stammzertifikate und Blattzertifikate.
    • Der Betreffname des Stammzertifikats wird als Aussteller-DN des Clientzertifikats extrahiert.
  • Szenario 4: Mehrere Zertifikatketten derselben Länge in derselben Datei. Die Kette 1 enthält Stammzertifikate, Zwischenzertifikate und Blattzertifikate. Die Kette 2 umfasst Stammzertifikate, Zwischenzertifikate2 und Blattzertifikate.
    • Der Antragstellername des Intermediate1-Zertifikats wird als DN des Clientzertifikatsausstellers extrahiert.
  • Szenario 5: Mehrere Zertifikatketten unterschiedlicher Längen in derselben Datei. Die Kette 1 enthält Stammzertifikate, Zwischenzertifikate und Blattzertifikate. Die Kette 2 umfasst Stammzertifikate, Zwischenzertifikate2, Zwischenzertifikate3 und Blattzertifikate.
    • Der Betreffname des Intermediate3-Zertifikats wird als Aussteller-DN des Clientzertifikats extrahiert.

Wichtig

Es wird empfohlen, nur eine Zertifikatkette pro Datei hochzuladen. Diese Empfehlung ist besonders wichtig, wenn Sie die Option "Clientzertifikat-DN überprüfen" aktivieren. Das Hochladen mehrerer Zertifikatketten in einer Datei führt zu Szenario vier oder fünf, was später zu Problemen führen kann, wenn das angezeigte Clientzertifikat nicht mit dem Clientzertifikatherausgeber DN übereinstimmt, den das Anwendungsgateway aus den Ketten extrahiert hat.

Weitere Informationen zum Extrahieren von Zertifikatketten vertrauenswürdiger Clientzertifizierungsstellen finden Sie unter Extrahieren von Zertifikatketten für vertrauenswürdige Clientzertifizierungsstellen.

Servervariablen

Mit der gegenseitigen TLS-Authentifizierung können Sie zusätzliche Servervariablen verwenden, um Informationen über das Clientzertifikat an die Back-End-Server hinter dem Anwendungsgateway zu übergeben. Weitere Informationen zu den verfügbaren Servervariablen und deren Verwendung finden Sie unter Servervariablen.

Zertifikatswiderruf

Wenn ein Client eine Verbindung mit einem Anwendungsgateway initiiert, das mit gegenseitiger TLS-Authentifizierung konfiguriert ist, kann die Zertifikatkette und der distinguished Name des Ausstellers überprüft werden. Darüber hinaus kann der Sperrstatus des Clientzertifikats mit OCSP (Online Certificate Status Protocol) überprüft werden. Während der Validierung wird das vom Client vorgelegte Zertifikat über den definierten OCSP-Responder in der AIA-Erweiterung (Authority Information Access) abgerufen. Wenn das Clientzertifikat widerrufen wurde, antwortet das Anwendungsgateway mit einem HTTP 400-Statuscode und grund auf den Client. Wenn das Zertifikat gültig ist, wird die Anforderung weiterhin vom Anwendungsgateway verarbeitet und an den definierten Back-End-Pool weitergeleitet.

Sie können die Clientzertifikatsperrung über REST-API, ARM-Vorlage, Bicep, CLI oder PowerShell aktivieren.

Verwenden Sie die folgenden Befehle, um die Clientsperrüberprüfung für ein vorhandenes Anwendungsgateway mithilfe von Azure PowerShell zu konfigurieren:

# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

# Create new SSL Profile
$profile  = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw

# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP

# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw

Eine Liste aller Azure PowerShell Verweise auf die Clientauthentifizierungskonfiguration auf dem Anwendungsgateway finden Sie in den folgenden Artikeln:

Um zu überprüfen, ob der OCSP-Sperrstatus für die Clientanforderung ausgewertet wurde, enthalten Zugriffsprotokolle eine Eigenschaft sslClientVerify , die den Status der OCSP-Antwort anzeigt.

Es ist wichtig, dass der OCSP-Responder hoch verfügbar ist und dass die Netzwerkkonnektivität zwischen Dem Anwendungsgateway und dem Responder möglich ist. Wenn das Anwendungsgateway den vollqualifizierten Domänennamen (FQDN) des definierten Antwortenden nicht auflösen kann oder wenn die Netzwerkkonnektivität mit oder vom Antwortenden blockiert wird, schlägt der Zertifikatsperrstatus fehl, und das Anwendungsgateway gibt eine 400 HTTP-Antwort an den anfordernden Client zurück.

Hinweis

OCSP-Überprüfungen werden über den lokalen Cache basierend auf der von einer vorherigen OCSP-Antwort definierten nextUpdate Zeit validiert. Wenn der OCSP-Cache nicht aus einer vorherigen Anforderung aufgefüllt wurde, schlägt die erste Antwort möglicherweise fehl. Beim Wiederholen des Clients sollte die Antwort im Cache gefunden werden, und die Anforderung wird erwartungsgemäß verarbeitet.

Notizen

  • Die Sperrüberprüfung über CRL wird nicht unterstützt.
  • Die Clientsperrüberprüfung wurde in API Version 2022-05-01 eingeführt.

Verwandte Inhalte

Wechseln Sie, nachdem Sie sich über die gegenseitige Authentifizierung informiert haben, zu Konfigurieren eines Anwendungsgateways mit gegenseitiger Authentifizierung in PowerShell, um ein Anwendungsgateway zu erstellen, das die gegenseitige Authentifizierung verwendet.

  • Last updated on