Application Gateway での相互認証の概要

  • [アーティクル]

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

Note

TLS 1.2 は今後も必須となるため、相互認証で TLS 1.2 を使用することをお勧めします。

相互認証

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

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

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

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

重要

相互認証を使用する場合は、信頼されたクライアント CA 証明書チェーン全体を確実に Application Gateway にアップロードしてください。

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

Note

  • 相互認証は、Standard_v2 SKU と WAF_v2 SKU でのみ使用できます。
  • 現在、TLS プロトコル リスナー (プレビュー) の相互認証の構成は、REST API、PowerShell、CLI を使用して実行できます。 Azure Portal は近日中にサポートされるようになります。

相互認証でサポートされている証明書

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

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

Note

十分に確立された証明機関からクライアント証明書を発行する場合は、証明機関と協力して、意図しない組織間のクライアント証明書認証を防ぐため、組織用に中間証明書を発行できるかどうかの確認を検討してください。

追加のクライアント認証の検証

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

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

クライアント証明書の直接の発行者を確認するために Application Gateway を有効にする場合、アップロードされた証明書からクライアント証明書の発行者の DN を抽出する方法を次に示します。

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

重要

ファイルごとに証明書チェーンを 1 つだけアップロードすることをお勧めします。 これは、クライアント証明書の DN を確認する機能を有効にする場合に特に重要です。 1 つのファイルに複数の証明書チェーンをアップロードすると、シナリオ 4 または 5 で終了し、提示されたクライアント証明書が、Application Gateway がチェーンから抽出したクライアント証明書の発行者の DN と一致しない場合に、後で問題が発生する可能性があります。

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

サーバー変数

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

証明書の失効

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

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

Azure PowerShell を使用して既存の Application Gateway にクライアント失効確認を構成するには、次のコマンドを参照できます。

# 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

Application Gateway のクライアント認証構成に関するすべての Azure PowerShell 参照の一覧は、こちらを参照してください。

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

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

注: OCSP チェックは、前の OCSP 応答によって定義された nextUpdate 時間に基づいて、ローカル キャッシュを使用して検証されます。 OCSP キャッシュに前の要求からの情報が取り込まれていない場合、最初の応答が失敗する可能性があります。 クライアントの再試行時に、応答がキャッシュに存在している必要があり、その場合に要求が想定どおりに処理されます。

メモ

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

次のステップ

相互認証について学習した後は、「PowerShell で Application Gateway の認証を構成する」をご覧になり、相互認証を使用して Application Gateway を作成します。