Application Gateway での TLS 終端とエンド ツー エンド TLS の概要
トランスポート層セキュリティ (TLS) (以前の Secure Sockets Layer (SSL)) は、Web サーバーとブラウザー間に暗号化されたリンクを確立するための標準的なセキュリティ テクノロジです。 このリンクにより、Web サーバーとブラウザー間で渡されるすべてのデータがプライベートで暗号化されたままになります。 Application Gateway では、ゲートウェイでの TLS 終端とエンド ツー エンド TLS 暗号化の両方がサポートされています。
TLS 終了
Application Gateway では、ゲートウェイの TLS 終端がサポートされています。その後、通常、トラフィックは、暗号化されないままバックエンド サーバーに渡されます。 アプリケーション ゲートウェイでの TLS 終端には多くの利点があります。
- パフォーマンスの向上 – TLS 解読を行っているときの最大のパフォーマンスへの影響は、初期ハンドシェイクです。 パフォーマンスを向上させるには、解読を行うサーバーで TLS セッション ID をキャッシュし、TLS セッション チケットを管理します。 これをアプリケーション ゲートウェイで行う場合は、同じクライアントからのすべての要求でキャッシュされた値を使用できます。 バックエンド サーバーで行う場合は、クライアントの要求が別のサーバーに渡されるたびに、クライアントを再認証する必要があります。 TLS チケットの使用はこの問題の軽減に役立ちますが、すべてのクライアントでサポートされているわけではなく、構成と管理は難しい場合があります。
- バックエンド サーバーの使用率の向上 – SSL/TLS 処理では CPU に非常に多くの負荷がかかり、キー サイズが大きくなるほど多くの負荷がかかります。 バックエンド サーバーからこの作業を取り除けば、最も効率的な作業に集中してコンテンツを配信することができます。
- インテリジェントなルーティング – トラフィックの暗号化を解除することで、アプリケーション ゲートウェイはヘッダー、URIなど、要求のコンテンツにアクセスでき、このデータを使用して要求をルーティングすることができます。
- 証明書の管理 – 証明書は、購入して、すべてのバックエンド サーバーではなくアプリケーション ゲートウェイにインストールするだけで済みます。 これにより時間もコストも節約できます。
TLS 終端を構成するには、TLS/SSL 証明書をリスナーに追加する必要があります。 これにより、Application Gateway で受信トラフィックを復号化し、クライアントへの応答トラフィックを暗号化することができます。 Application Gateway に提供される証明書は、プライベートおよび公開キーの両方を含む Personal Information Exchange (PFX) 形式である必要があります。 サポートされている PFX アルゴリズムの一覧は、「PFXImportCertStore 関数」を参照してください。
重要
リスナーの証明書では、信頼のチェーンを確立するため、証明書チェーン全体をアップロードする必要があります (CA からのルート証明書、中間、リーフ証明書)。
Note
アプリケーション ゲートウェイには、新しい証明書を作成したり証明機関に証明書要求を送信したりする機能はありません。
TLS 接続を機能させるには、TLS/SSL 証明書が次の条件を確実に満たすようにする必要があります。
- 現在の日付と時刻が、証明書の "有効期間の開始日" と"有効期間の終了日" の日付範囲内である。
- 証明書の "共通名" (CN) が、要求のホスト ヘッダーと一致する。 たとえば、クライアントが
https://www.contoso.com/に要求を送信する場合、CN はwww.contoso.comである必要があります。
バックエンド証明書の共通名 (CN) でエラーが発生した場合は、トラブルシューティング ガイドを参照してください。
TLS 終端でサポートされる証明書
Application Gateway では、次の種類の証明書がサポートされています。
- CA (証明機関) 証明書: CA 証明書は、証明機関 (CA) によって発行されたデジタル証明書です
- EV (拡張された検証) 証明書: EV 証明書は、業界標準の証明書ガイドラインに準拠する証明書です。 これにより、ブラウザーのロケーター バーが緑色になり、会社名も公開されます。
- ワイルドカード証明書: この証明書は、*site.com に基づく任意の数のサブドメインをサポートしています。* は、指定したサブドメインに置き換えられます。 ただし、ユーザーが先頭の "www" を入力せずに Web サイトにアクセスしている場合、ワイルドカード証明書はそれに対応していないため、site.com はサポートされません。
- 自己署名証明書: クライアントのブラウザーではこれらの証明書が信頼されておらず、仮想サービスの証明書が信頼チェーンに含まれていないことがユーザーに警告されます。 自己署名証明書は、テストや、管理者がクライアントを制御していて、ブラウザーのセキュリティの警告を安全にバイパスできる環境に適しています。 運用環境のワークロードでは、自己署名証明書を使用しないでください。
詳細については、アプリケーション ゲートウェイでの TLS 終端の構成に関するページを参照してください。
証明書のサイズ
サポートされる TLS/SSL 証明書の最大サイズを把握するには、「Application Gateway の制限」セクションを確認してください。
エンド ツー エンド TLS 暗号化
バックエンド サーバーに対する非暗号化通信を回避したい場合があります。 セキュリティ要件、コンプライアンス要件がある場合や、セキュリティで保護された接続以外がアプリケーションでは受け入れられない場合があります。 Azure Application Gateway には、これらの要件をサポートするためのエンド ツー エンドの TLS 暗号化が用意されています。
エンド ツー エンド TLS を使用すると、機密データを暗号化してバックエンドに安全に送信することができます。その間にも、Application Gateway のレイヤー 7 負荷分散機能を使用できます。 これらの機能には、cookie ベースのセッション アフィニティ、URL ベースのルーティング、サイトに基づくルーティングのサポート、X-Forwarded-* ヘッダーの書き換えまたは挿入機能などが含まれます。
エンド ツー エンド TLS 通信モードが構成されている場合、Application Gateway によって TLS セッションがゲートウェイで終了され、ユーザー トラフィックの暗号化が解除されます。 次に、構成済みのルールが適用され、トラフィックのルーティング先になる適切なバックエンド プール インスタンスが選択されます。 バックエンドに要求を送信する前に、Application Gateway によってバックエンド サーバーへの新しい TLS 接続が開始され、バックエンド サーバーの公開キー証明書を使用してデータが再暗号化されます。 Web サーバーからの応答は、同じ手順でエンドユーザーに移動します。 エンド ツー エンド TLS は、バックエンドの HTTP 設定でのプロトコル設定を HTTPS に設定することによって有効になり、その後、バックエンド プールに適用されます。
Application Gateway v1 SKU ゲートウェイでは、TLS ポリシーは、TLS バージョンをフロントエンド トラフィックにのみ適用し、定義された暗号をフロントエンドとバックエンドの両方のターゲットに適用します。 Application Gateway v2 SKU ゲートウェイでは、TLS ポリシーはフロントエンド トラフィックにのみ適用され、バックエンドの TLS 接続は常に TLS 1.0 から TLS 1.2 のバージョンでネゴシエートされます。
Application Gateway は、証明書がアプリケーション ゲートウェイの許可リストに登録されているバックエンド サーバーか、証明書が既知の CA 機関によって署名されていて、かつ、その証明書の CN が HTTP バックエンド設定のホスト名と一致しているバックエンド サーバーとしか通信しません。 これらには、Azure App Service/Web Apps や Azure API Management などの信頼済みの Azure サービスが含まれます。
バックエンド プール内のメンバーの証明書が既知の CA 機関によって署名されていない場合、エンド ツー エンド TLS が有効になっているバックエンド プール内の各インスタンスは、セキュリティで保護された通信を許可する証明書を使って構成される必要があります。 証明書を追加することにより、Application Gateway は、既知のバックエンド インスタンスのみと通信するため、 エンド ツー エンド通信のセキュリティが強化されます。
Note
バックエンド サーバーを認証するためにバックエンドの HTTP 設定に追加する証明書は、アプリケーション ゲートウェイで TLS 終端のリスナーに追加する証明書と同じものにすることも、セキュリティの強化のために別のものにすることもできます。
この例では、TLS1.2 を使用する要求が、エンド ツー エンド TLS を使用して Pool1 のバックエンド サーバーにルーティングされます。
エンド ツー エンド TLS と証明書の許可リスト
Application Gateway は、証明書がアプリケーション ゲートウェイの許可リストに登録されているバックエンド サーバーか、証明書が既知の CA 機関によって署名されていて、かつ、その証明書の CN が HTTP バックエンド設定のホスト名と一致しているバックエンド サーバーとしか通信しません。 エンド ツー エンド TLS のセットアップ プロセスには、使用されている Application Gateway のバージョンに関する違いがいくつかあります。 次のセクションでは、各バージョンについて個別に説明します。
v1 SKU を利用するエンド ツー エンド TLS
バックエンド サーバーでエンド ツー エンド TLS を有効にし、それらに対して Application Gateway から要求をルーティングするには、正常性プローブが成功して、正常な応答が返される必要があります。
HTTPS の正常性プローブに対しては、Application Gateway v1 SKU では、HTTP 設定にアップロードされる認証証明書と完全に一致する証明書 (バックエンド サーバー証明書の公開キーであり、ルート証明書ではありません) が使用されます。
許可リストに登録された既知の許可されたバックエンドへの接続のみが許可されます。 残りのバックエンドは、正常性プローブによって異常と見なされます。 自己署名証明書はテストのみを目的とするため、運用環境のワークロードで使用することはお勧めできません。 このような証明書は、使用する前に、上記の手順で説明したとおりに、アプリケーション ゲートウェイの許可リストに登録する必要があります。
Note
認証および信頼されたルート証明書の設定は、Azure App Service などの信頼済みの Azure サービスでは必要ありません。 それらは既定で、信頼済みと見なされます。
v2 SKU を利用するエンド ツー エンド TLS
認証証明書は廃止され、Application Gateway v2 SKU の信頼されたルート証明書に置き換えられました。 これは認証証明書と同様の働きをしますが、いくつかの重要な違いがあります。
既知の CA 機関によって署名され、バックエンドの HTTP 設定のホスト名と一致する CN を持つ証明書は、エンド ツー エンド TLS が機能するために追加の手順は必要ありません。
たとえば、バックエンド証明書が既知の CA により発行されて、その CN が contoso.com であり、バックエンドの http 設定の [ホスト] フィールドも contoso.com に設定されている場合、追加の手順は必要ありません。 バックエンドの HTTP 設定のプロトコルとして HTTPS を設定すると、正常性プローブとデータ パスの両方が TLS で有効になります。 バックエンドとして Azure App Service または他の Azure の Web サービスを使用している場合は、それらも暗黙で信頼されており、エンド ツー エンド TLS にはこれ以上の手順は必要ありません。
Note
TLS/SSL 証明書が信頼されるためには、バックエンド サーバーのその証明書が、既知の CA によって発行されている必要があります。 証明書が信頼されている CA によって発行されていなかった場合は、アプリケーション ゲートウェイでは、その発行元 CA の証明書が信頼されている CA によって発行されたかどうかがチェックされます。信頼されている CA が見つかる (この時点で信頼できる安全な接続が確立されます) か、信頼されている CA が見つからない (この時点で、アプリケーション ゲートウェイによってバックエンドが正常でないとマークされます) まで、この操作が続行されます。 そのため、バックエンド サーバーの証明書には、ルート CA と中間 CA の両方を含めることをお勧めします。
バックエンド サーバーの証明書が自己署名されている場合、または未知の CA/ 中継局によって署名されている場合、Application Gateway v2 でエンドツーエンドの TLS を有効にするには、信頼できるルート証明書をアップロードする必要があります。 Application Gateway は、サーバー証明書のルート証明書が、プールに関連付けられたバックエンド http 設定の信頼できるルート証明書のリストの 1 つと一致するバックエンドとのみ通信します。
また、Application Gateway v2 では、ルート証明書の一致に加えて、バックエンドの HTTP 設定に指定されているホスト設定が、バックエンド サーバーの TLS/SSL 証明書によって提示されている共通名 (CN) のホスト設定と一致するかどうかも検証されます。 バックエンドとの TLS 接続を確立しようとする場合、Application Gateway v2 では、Server Name Indication (SNI) 拡張機能がバックエンドの HTTP 設定で指定されているホストに設定されます。
バックエンドの HTTP 設定で [ホスト] フィールドではなく、[バックエンド ターゲットからホスト名を取得する] が選択されている場合、SNI ヘッダーには常にバックエンド プールの FQDN が設定されます。バックエンド サーバーの TLS/SSL 証明書の CN は、その FQDN と一致している必要があります。 このシナリオでは、IP アドレスを持つバックエンド プール メンバーはサポートされません。
ルート証明書は､バックエンド サーバーの証明書からの base64 でエンコードされたルート証明書になります｡
v1 SKU と v2 SKU における SNI の違い
前述したように、Application Gateway では、Application Gateway リスナーでクライアントからの TLS トラフィックが終了され (これをフロントエンド接続と呼ぶことにします)、トラフィックの暗号化が解除され、要求の転送先となるバックエンド サーバーを決定するために必要な規則が適用されて、バックエンド サーバーとの新しい TLS セッションが確立されます (これをバックエンド接続と呼ぶことにします)。
次の表に、フロントエンドとバックエンドの接続の観点から、v1 と v2 の SKU 間での SNI の違いをまとめています。
フロントエンド TLS 接続 (クライアントからアプリケーション ゲートウェイへ)
| シナリオ | v1 | v2 |
|---|---|---|
| クライアントで SNI ヘッダーが指定されており、すべてのマルチサイト リスナーでの "SNI を必要とする" フラグが有効になっている場合 | 適切な証明書が返されます。(server_name に従った) サイトが存在しない場合は、接続がリセットされます。 | 使用可能な場合は、適切な証明書が返されます。それ以外の場合は、HTTPS リスナーに関連付けられている要求ルーティング規則で指定された順序に従って、最初の HTTPS リスナーの証明書が返されます |
| クライアントで SNI ヘッダーが指定されておらず、すべてのマルチサイト ヘッダーでの "SNI を必要とする" が有効になっている場合 | 接続がリセットされます | HTTPS リスナーに関連付けられている要求ルーティング規則で指定された順序に従って、最初の HTTPS リスナーの証明書が返されます |
| クライアントで SNI ヘッダーが指定されておらず、証明書を使用して構成された基本リスナーがある場合 | 基本リスナーで構成されている証明書がクライアントに返されます (既定またはフォールバック証明書) | 基本リスナーで構成されている証明書が返されます |
ヒント
SNI フラグは、PowerShell または ARM テンプレートを使用して構成できます。 詳細については、「RequireServerNameIndication」および「クイック スタート: Azure Application Gateway を使用して Web トラフィックを転送する - ARM テンプレート」を参照してください。.
バックエンド TLS 接続 (アプリケーション ゲートウェイからバックエンド サーバーへ)
プローブ トラフィックの場合
| シナリオ | v1 | v2 |
|---|---|---|
| TLS ハンドシェイク中の FQDN としての SNI (server_name) ヘッダー | バックエンド プールから FQDN として設定されます。 RFC 6066 に従い、リテラルな IPv4 および IPv6 アドレスは、SNI ホスト名では許可されていません。 注: バックエンド プールでの FQDN は、バックエンド サーバーの IP アドレス (パブリックまたはプライベート) に DNS 解決される必要があります |
SNI ヘッダー (server_name) は、HTTP 設定に関連付けられたカスタム プローブ (構成されている場合) からホスト名として設定されます。そうでない場合は、HTTP 設定で指定されているホスト名から、さらに、それ以外の場合には、バックエンド プールに指定されている FQDN から設定されます。 優先順位は、カスタム プローブ > HTTP 設定 > バックエンド プールです。 注: HTTP 設定とカスタム プローブに構成されているホスト名が異なる場合、優先順位に従って、SNI はカスタム プローブからホスト名として設定されます。 |
| バックエンド プール アドレスが IP アドレスである場合 (v1)、またはカスタム プローブのホスト名が IP アドレスとして構成されている場合 (v2) | SNI (server_name) は設定されません。 注: この場合、バックエンド サーバーでは、既定またはフォールバックの証明書を返せる必要があります。また、それは認証証明書の HTTP 設定で許可リストに登録されている必要があります。 バックエンド サーバーに既定/フォールバックの証明書が構成されていない状態で、SNI が想定されている場合、サーバーでは接続がリセットされる可能性があり、プローブ障害を引き起こします |
前述の優先順位で、IP アドレスがホスト名として指定されている場合、RFC 6066 に従って SNI は設定されません。 注: カスタム プローブが構成されておらず、ホスト名が HTTP 設定またはバックエンド プールに設定されていない場合、v2 のプローブでも SNI は設定されません |
Note
カスタム プローブが構成されない場合、Application Gateway では、<プロトコル>://127.0.0.1:<ポート>/ の形式で既定のプローブを送信します。 たとえば、既定の HTTPS プローブの場合、https://127.0.0.1:443/ として送信されます。 ここで示されている 127.0.0.1 は、HTTP ホスト ヘッダーとしてのみ使用され、RFC 6066 に従い、SNI ヘッダーとしては使用されないことに注意してください。 正常性プローブのエラーに関する詳細については、バックエンドの正常性に関するトラブルシューティング ガイドのページを参照してください。
ライブ トラフィックの場合
| シナリオ | v1 | v2 |
|---|---|---|
| TLS ハンドシェイク中の FQDN としての SNI (server_name) ヘッダー | バックエンド プールから FQDN として設定されます。 RFC 6066 に従い、リテラルな IPv4 および IPv6 アドレスは、SNI ホスト名では許可されていません。 注: バックエンド プールでの FQDN は、バックエンド サーバーの IP アドレス (パブリックまたはプライベート) に DNS 解決される必要があります |
SNI ヘッダー (server_name) は、HTTP 設定からホスト名として設定されます。そうでない場合は、PickHostnameFromBackendAddress オプションが選択されているか、ホスト名が指定されていないと、バックエンド プールの構成に FQDN として設定されます |
| バックエンド プール アドレスが IP アドレスであるか、またはホスト名が HTTP 設定に設定されていない場合 | バックエンド プール エントリが FQDN でない場合、RFC 6066 に従って SNI は設定されません | SNI はクライアントによって入力された FQDN からホスト名として設定されます。また、バックエンド証明書の CN が、このホスト名と一致している必要があります。 |
| ホスト名は HTTP サーバー設定で指定されていないが、FQDN がバックエンド プール メンバーのターゲットとして指定されている場合 | SNI はクライアントによって入力された FQDN からホスト名として設定されます。また、バックエンド証明書の CN が、このホスト名と一致している必要があります。 | SNI はクライアントによって入力された FQDN からホスト名として設定されます。また、バックエンド証明書の CN が、このホスト名と一致している必要があります。 |
次のステップ
エンド ツー エンド TLS について学習したら、「Application Gateway での PowerShell を使用したエンド ツー エンド TLS の構成」に進んで、エンド ツー エンド TLS を使用するアプリケーション ゲートウェイを作成します。