Application Gateway での相互認証の概要

相互認証 (クライアント認証) を使用すると、Application Gateway は要求を送信するクライアントを認証できます。 通常、クライアントのみが Application Gateway を認証します。 相互認証を使用すると、クライアントと Application Gateway の両方で相互認証を行えます。

相互認証

Application Gateway では、証明書ベースの相互認証がサポートされています。 信頼されたクライアント CA 証明書を Application Gateway にアップロードできます。ゲートウェイはこれらの証明書を使用して、要求を送信するクライアントを認証します。 IoT のユース ケースの増加と業界間のセキュリティ要件の増加に伴い、相互認証により、Application Gateway と通信できるクライアントを管理および制御できます。

Application Gateway には、クライアント証明書を検証するための次の 2 つのオプションがあります。

相互 TLS パススルー モード

相互 TLS (mTLS) パススルー モードでは、Application Gateway は TLS ハンドシェイク中にクライアント証明書を要求しますが、証明書が見つからないか無効な場合は接続を終了しません。 証明書の存在や有効性に関係なく、バックエンドへの接続が続行されます。 証明書が指定されている場合、Application Gateway は、アプリケーションで必要に応じてバックエンドに転送できます。 バックエンド サービスは、クライアント証明書の検証を担当します。

mTLS パススルー モードの利点

mTLS パススルー モードには、次の利点があります。

• ゲートウェイ構成の簡略化: ゲートウェイ レベルで CA 証明書のアップロードは必要ありません。
• 柔軟な認証: 一部のクライアントが証明書を使用し、他のクライアントがトークンベースの認証を使用する混合トラフィック シナリオをサポートします。
• バックエンド ポリシーの適用: バックエンド アプリケーションがカスタム証明書検証ロジックとポリシーを実装できるようにします。
• ゲートウェイのオーバーヘッドの削減: 証明書の検証をバックエンドにオフロードし、ゲートウェイでの処理を減らします。
• 段階的な移行のサポート: 既存のトラフィック パターンを中断することなく、mTLS の段階的なロールアウトを有効にします。

クライアント証明書をバックエンドに転送するには、サーバー変数を構成します。 詳細については、「 サーバー変数」を参照してください。

mTLS パススルー モードを構成する

mTLS パススルー モードは、Azure ポータルまたは ARM テンプレートを使用して構成できます。

双方向 TLS 厳密モード

相互 TLS 厳密モードでは、Application Gateway は、有効なクライアント証明書を要求することで、TLS ハンドシェイク中にクライアント証明書認証を適用します。 厳密モードを有効にするには、SSL プロファイルの一部としてルート CA と必要に応じて中間 CA を含む信頼されたクライアント CA 証明書をアップロードします。 この SSL プロファイルをリスナーに関連付けて、相互認証を適用します。

相互 TLS 厳格モードを構成する

相互認証の厳密モードを構成するには、SSL プロファイルのクライアント認証部分の一部として、信頼されたクライアント CA 証明書をアップロードします。 次に、SSL プロファイルをリスナーに関連付けて、構成を完了します。 アップロードするクライアント証明書には、常にルート CA 証明書が含まれている必要があります。 証明書チェーンはアップロードできますが、チェーンには中間 CA 証明書に加えてルート CA 証明書を含める必要があります。 アップロードされる各ファイルの最大サイズは 25 KB 以下である必要があります。

たとえば、クライアント証明書にルート CA 証明書、複数の中間 CA 証明書、リーフ証明書が含まれている場合は、ルート CA 証明書とすべての中間 CA 証明書を 1 つのファイルで Application Gateway にアップロードします。 信頼されたクライアント CA 証明書を抽出する方法の詳細については、「 信頼されたクライアント CA 証明書を抽出する」を参照してください。

ルート CA と中間 CA 証明書を含む証明書チェーンをアップロードする場合は、証明書チェーンを PEM または CER ファイルとしてゲートウェイにアップロードします。

各 SSL プロファイルでは、信頼されたクライアント CA 証明書チェーンを最大 100 つサポートできます。 1 つの Application Gateway で、合計 200 個の信頼されたクライアント CA 証明書チェーンをサポートできます。

相互 TLS 厳密モード認証でサポートされる証明書

Application Gateway は、パブリックおよびプライベートに確立された証明機関から発行された証明書をサポートしています。

• 既知の証明機関から発行された CA 証明書: 中間証明書とルート証明書は、一般的に信頼された証明書ストアに存在し、デバイスで追加の構成をほとんどまたはまったく使用せず、信頼された接続を有効にします。
• 組織が確立した証明機関から発行された CA 証明書: これらの証明書は通常、組織を通じてプライベートに発行され、他のエンティティによって信頼されません。 クライアントがチェーン信頼を確立するために、中間証明書とルート証明書を信頼された証明書ストアにインポートします。

相互 TLS 厳密モードのクライアント認証検証

クライアント証明書の DN を確認する

クライアント証明書の即時発行者を確認し、Application Gateway がその発行者を信頼することのみを許可できます。 このオプションは既定ではオフになっていますが、ポータル、PowerShell、またはAzure CLIを使用して有効にできます。

Application Gateway でクライアント証明書の即時発行者を確認できるようにする場合、次のシナリオでは、アップロードされた証明書からクライアント証明書発行者 DN を抽出する方法について説明します。

• シナリオ 1: 証明書チェーンには、ルート証明書、中間証明書、およびリーフ証明書が含まれます。
  • 中間証明書のサブジェクト名は、クライアント証明書発行者 DN として抽出されます。
• シナリオ 2: 証明書チェーンには、ルート証明書、中間 1 証明書、中間 2 証明書、およびリーフ証明書が含まれます。
  • intermediate2 証明書のサブジェクト名は、クライアント証明書発行者 DN として抽出されます。
• シナリオ 3: 証明書チェーンには、ルート証明書とリーフ証明書が含まれています。
  • ルート証明書のサブジェクト名は、クライアント証明書発行者 DN として抽出されます。
• シナリオ 4: 同じファイル内の同じ長さの複数の証明書チェーン。 チェーン 1 には、ルート証明書、中間 1 証明書、およびリーフ証明書が含まれます。 チェーン 2 には、ルート証明書、intermediate2 証明書、およびリーフ証明書が含まれます。
  • intermediate1 証明書のサブジェクト名は、クライアント証明書発行者 DN として抽出されます。
• シナリオ 5: 同じファイル内の長さが異なる複数の証明書チェーン。 チェーン 1 には、ルート証明書、中間 1 証明書、およびリーフ証明書が含まれます。 チェーン 2 には、ルート証明書、intermediate2 証明書、intermediate3 証明書、およびリーフ証明書が含まれます。
  • intermediate3 証明書のサブジェクト名は、クライアント証明書発行者 DN として抽出されます。

信頼されたクライアント CA 証明書チェーンを抽出する方法の詳細については、「 信頼されたクライアント CA 証明書チェーンを抽出する」を参照してください。

サーバー変数

相互 TLS 認証では、追加のサーバー変数を使用して、クライアント証明書に関する情報を Application Gateway の背後にあるバックエンド サーバーに渡すことができます。 使用可能なサーバー変数とその使用方法の詳細については、「 サーバー変数」を参照してください。

証明書の失効

クライアントが相互 TLS 認証で構成された Application Gateway への接続を開始すると、証明書チェーンと発行者の識別名を検証できます。 さらに、クライアント証明書の失効状態は OCSP (オンライン証明書ステータス プロトコル) で確認できます。 検証中、クライアントによって提示される証明書は、機関情報アクセス (AIA) 拡張機能で定義された OCSP レスポンダーを介して検索されます。 クライアント証明書が失効している場合、Application Gateway は HTTP 400 状態コードと理由でクライアントに応答します。 証明書が有効な場合、要求は引き続き Application Gateway によって処理され、定義されたバックエンド プールに転送されます。

REST API、ARM テンプレート、Bicep、CLI、または PowerShell を使用して、クライアント証明書の失効を有効にすることができます。

# 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

# Update existing gateway's SSL Profile
az network application-gateway update \
    --name ApplicationGateway01 \
    --resource-group ResourceGroup01 \
    --ssl-profiles [0].client-auth-configuration.verify-client-revocation=OCSP

クライアント要求に対して OCSP 失効状態が評価されたことを確認するために、 アクセス ログ には、OCSP 応答の状態を示す sslClientVerify というプロパティが含まれています。

OCSP レスポンダーの可用性が高く、Application Gateway とレスポンダー間のネットワーク接続が可能であることが重要です。 Application Gateway が定義されたレスポンダーの完全修飾ドメイン名 (FQDN) を解決できない場合、またはレスポンダーとの間のネットワーク接続がブロックされている場合、証明書失効状態は失敗し、Application Gateway は要求元のクライアントに 400 HTTP 応答を返します。

メモ

• CRL による失効チェックはサポートされていません。
• クライアント失効チェックは、API バージョン 2022-05-01 で導入されました。

関連するコンテンツ

相互認証について学習したら、 PowerShell で相互認証を使用して Application Gateway を構成 するに進み、相互認証を使用する Application Gateway を作成します。