リバース プロキシ経由で Azure Spring Apps を公開する

Azure Spring Apps でアプリやマイクロサービスをホストする場合、インターネットに直接公開したくない場合があります。 代わりにリバース プロキシ経由で公開することができます。 この方法では、アプリの前にサービスを配置できます。 このサービスでは、アプリケーションをセキュリティで保護する Web アプリケーション ファイアウォール (WAF) 機能、負荷分散、ルーティング、要求フィルター処理、レート制限などの横断的な機能を定義できます。

Azure Application Gateway や Azure Front Door などの一般的なリバース プロキシ サービスを Azure Spring Apps の前にデプロイする場合、このリバース プロキシ経由でのみアプリケーションにアクセスできるようにする必要があります。 この安全策は、悪意のあるユーザーが WAF を迂回したり、スロットル制限を回避したりする試みを防ぐのに役立ちます。

Azure DDoS Protection では、アプリケーションの設計に関するベスト プラクティスと組み合わせることにより、DDoS 攻撃からの保護を向上させるための強化された DDoS 軽減機能が提供されます。 すべての境界仮想ネットワークで Azure DDOS Protection を有効にする必要があります。

この記事では、Azure Spring Apps でホストされているアプリケーションがリバース プロキシ サービス経由でのみアクセスできるように、アクセス制限を適用する方法について説明します。 これらの制限を適用するお勧めの方法は、Azure Spring Apps インスタンスのデプロイ方法と、使用しているリバース プロキシによって異なります。 これらの方法は、仮想ネットワークの内部と外部のどちらにデプロイするかによって考慮すべき点が異なります。 この記事では、"4 つのシナリオ" に関する情報を提供します。

• 仮想ネットワーク内に Azure Spring Apps をデプロイし、ネットワーク内からアプリにプライベートでアクセスする。

  • アプリを実行する仮想ネットワークを制御できます。 ネットワーク セキュリティ グループ (NSG) などの Azure ネットワークのネイティブ機能を使って、アクセスをロック ダウンし、リバース プロキシのみを許可できます。

  • Azure Application Gateway を使ってアプリケーションをインターネットに公開し、適切なアクセス制限を適用してロックダウンできます。 このアプローチについては、この記事後半の「シナリオ 1」で説明します。

  • プライベート仮想ネットワーク内の Azure Spring Apps インスタンスには到達できないので、Azure Front Door を直接使うことはできません。 Azure Front Door は、パブリック IP アドレスまたはプライベート エンドポイントを使うサービス経由でのみ、バックエンドに接続できます。 Azure Spring Apps の複数リージョン デプロイがあり、グローバル負荷分散が必要な場合でも、Application Gateway を介して Azure Spring Apps インスタンスを公開できます。 このシナリオを実現するには、Application Gateway の前に Azure Front Door を配置します。 このアプローチについては、この記事後半の「シナリオ 2」で説明します。

• 仮想ネットワーク外に Azure Spring Apps をデプロイし、エンドポイントを割り当てた場合にアプリをインターネットに直接公開する。

  • ネットワークを制御していないので、NSG を使ってアクセスを制限することはできません。 リバース プロキシのみがアプリにアクセスできるようにするには、Azure Spring Apps 内部でのアプローチが必要です。

  • アプリケーションが公開されているため、リバース プロキシとして Application Gateway または Azure Front Door を使用することができます。 Application Gateway のアプローチについては、この記事後半の「シナリオ 3」で説明します。 Azure Front Door のアプローチについては、この記事後半の「シナリオ 4」で説明します。

  • 必要に応じて、両方のアプローチを組み合わせて使用できます。 Application Gateway と Azure Front Door の両方を使う場合、2 つのリバース プロキシ間でシナリオ 2 で使うものと同じアクセス制限を使います。

シナリオの比較

次の表は、Azure Spring Apps のリバース プロキシ構成に関する 4 つのシナリオの簡単な比較を示しています。 各シナリオの詳細については、この記事の該当するセクションを参照してください。

仮想ネットワーク内でのデプロイ

Azure Spring Apps が仮想ネットワークにデプロイされると、次の 2 つのサブネットが使用されます。

• 関連するネットワーク リソースを含むサービス ランタイム サブネット
• コードをホストするアプリ サブネット

サービス ランタイム サブネットには、アプリ接続用のロード バランサーが含まれているため、このサービス ランタイム サブネット上に NSG を定義して、リバース プロキシからのトラフィックのみを許可できます。 他のすべてのトラフィックをブロックすると、仮想ネットワーク内の誰も、リバース プロキシを経由せずにアプリにアクセスできなくなります。

リバース プロキシ経由で公開する各アプリにエンドポイントを割り当て、リバース プロキシから仮想ネットワーク内に到達できるようにすることをお勧めします。 また、各アプリについて、使うカスタム ドメインをマップすることで、リバース プロキシ内で HTTP Host ヘッダーがオーバーライドされないように防ぎ、元のホスト名をそのまま維持することもできます。 この方法を使用することで、Cookie の破損や正しく動作しないリダイレクト URL などの問題を回避できます。 詳細については、「ホスト名の保存」を参照してください。

シナリオ 1: リバース プロキシとして Application Gateway を使う

シナリオ 1 では、Application Gateway を使ってアプリケーションをインターネットに公開し、適切なアクセス制限を適用してロックダウンする方法について説明します。

次の図は、シナリオ 1 のアーキテクチャを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

Application Gateway を Azure Spring Apps インスタンスの前に配置する場合、Spring Cloud Gateway アプリの割り当てられたエンドポイントをバックエンド プールとして使います。 エンドポイントの例は myspringcloudservice-myapp.private.azuremicroservices.io です。 このエンドポイントにより、サービス ランタイム サブネット内のプライベート IP アドレスに解決されます。 そのため、アクセスを制限するには、サービス ランタイム サブネットに NSG を配置し、次の受信セキュリティ規則を設定します (拒否規則を最も低い優先度に設定します)。

シナリオ 1 の構成では、サービス ランタイム サブネットで次のソースからのトラフィックのみが許可されます。

• 専用 Application Gateway サブネット。
• アプリ サブネット (2 つの Azure Spring Apps サブネット間の双方向通信が必要です)。
• Azure ロード バランサー (これは一般的な Azure プラットフォームの要件です)

その他のトラフィックはすべてブロックされます。

シナリオ 2: Azure Front Door と Application Gateway の両方をリバース プロキシとして使う

前述のとおり、Azure Spring Apps の前に Azure Front Door を直接配置することはできません。プライベート仮想ネットワークに到達できないからです。 (Azure Front Door Standard または Premium は、仮想ネットワーク内のプライベート エンドポイントに接続できますが、現在、Azure Spring Apps はプライベート エンドポイントのサポートを提供していません)。それでも、異なる Azure リージョンにある Azure Spring Apps の複数のインスタンス間でグローバルな負荷分散が必要などの理由で、Azure Front Door を使う場合は、Application Gateway 経由でアプリを引き続き公開することができます。 このシナリオを実現するには、Application Gateway の前に Azure Front Door を配置します。

次の図は、シナリオ 2 のアーキテクチャを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

シナリオ 2 の構成では、シナリオ 1 と同じ方法で、Application Gateway と Azure Spring Apps の間にアクセス制限が実装されます。 適切な規則を使用して、サービス ランタイム サブネットに NSG を配置します。

また、シナリオ 2 でも、Application Gateway が Azure Front Door インスタンスからのトラフィックのみを受け入れるようにする必要があります。 Azure Front Door のドキュメントには、バックエンドへのアクセスをロックダウンして Azure Front Door のトラフィックのみを許可する方法が説明されています。 バックエンドが Application Gateway の場合、この制限を次のように実装できます。

• Application Gateway サブネットで、AzureFrontDoor.Backend サービス タグを持つトラフィックのみを許可する NSG を作成します (Azure Front Door 以外は Application Gateway に到達できません)。 Application Gateway の NSG 制限に関する記事で説明されているように、他の必要なサービス タグも含めてください。
• Application Gateway でカスタム WAF 規則を作成し、X-Azure-FDID HTTP ヘッダーに特定の Azure Front Door インスタンス ID が設定されていることを確認します。 この方法を使用すると、自分の Application Gateway インスタンスに対して、同じ IP 範囲を使う他の組織の Azure Front Door インスタンスから到達できないようになります。

仮想ネットワーク外でのデプロイ

Azure Spring Apps を仮想ネットワークの外部にデプロイする場合、ネットワークを制御できないため、ネイティブの Azure ネットワーク機能を使用できません。 代わりに、必要なアクセス制限をアプリ自体に適用し、リバース プロキシからのトラフィックのみを許可する必要があります。 アプリが多数ある場合、このアプローチではさらに複雑になる可能性があります。また、すべてのアプリが適切に構成されるとは限らないというリスクがあります。

Spring Cloud Gateway を使ってアプリを公開し、セキュリティで保護する

このアクセス制御の責任を個々のアプリケーションの開発者が負わないように、Spring Cloud Gateway を使って横断的な制限を適用することができます。 Spring Cloud Gateway はよく使われる Spring プロジェクトです。他のアプリと同じように Azure Spring Apps にデプロイできます。 Spring Cloud Gateway を使うことで、Azure Spring Apps インスタンス内で自分のアプリケーションを非公開にし、共有された Spring Cloud Gateway アプリ経由でのみアクセスできるようにすることができます。 そして、Spring Cloud Gateway の組み込み機能であるルート述語を使って、このアプリに必要なアクセス制限を構成します。 ルート述語に受信 HTTP 要求のさまざまな属性を使って、要求をバックエンド アプリケーションに転送するか拒否するかを決定することができます。 この述語では、クライアント IP アドレス、要求メソッドまたはパス、HTTP ヘッダーなどの属性を使用できます。

このパターンは一般的に使用されます。 この記事の目的では、Spring Cloud Gateway を介してアプリケーションを公開することを前提としています。 ルート述語は、リバース プロキシからのリクエストのみが許可されるように、必要なアクセス制限を設定する際に使用されると考えています。 Spring Cloud Gateway を使わない場合でも、同じ一般原則が適用されます。 ただし、この記事で後述するものと同じ X-Forwarded-For HTTP ヘッダーに基づいて、アプリに独自の要求フィルター処理機能を組み込む必要があります。

Spring Cloud Gateway のしくみについては、この記事では取り上げません。 これは、コードや構成を使ってカスタマイズできる非常に柔軟なサービスです。 説明を簡単にするために、この記事では、コードの変更を必要としない純粋な構成に基づくアプローチのみを取り上げます。 このアプローチを実装するには、デプロイされた Spring Cloud Gateway アプリに従来の application.properties または application.yml ファイルを含めます。 また、構成ファイルを Git リポジトリに外部化する Azure Spring Apps 内で Config Server を使ってこのアプローチを実装することもできます。 次の例では、YAML 構文を使用して application.yml アプローチを実装していますが、同等の application.properties 構文も機能します。

アプリケーションへの要求をルーティングする

既定では、Azure Spring Apps のアプリにエンドポイントが割り当てられていない場合、またはカスタム ドメインが構成されていない場合、外部から到達することはできません。 アプリが自身を Spring Cloud Service Registry に登録すると、Spring Cloud Gateway からそのアプリを検出し、ルーティング規則を使って正しい宛先アプリにトラフィックを転送できるようになります。

その結果、Azure Spring Apps でエンドポイントを割り当てる必要があるアプリは、Spring Cloud Gateway アプリのみです。 このエンドポイントにより、外部から到達可能になります。 他のアプリにエンドポイントを割り当てないでください。 そうしないと、アプリは、Spring Cloud Gateway を経由せずに直接到達可能になり、結果としてリバース プロキシがバイパスされます。

Spring Cloud Gateway 経由で登録されたすべてのアプリを公開する簡単な方法の 1 つとして、次のように DiscoveryClient ルート定義ロケーターを使う方法があります。

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true
          predicates:
          - Path="/"+serviceId+"/**" # Include the Path predicate to retain default behavior
          - (...)

また、アプリ固有のルートを定義することで、特定のアプリを Spring Cloud Gateway で選択的に公開することもできます。

spring:
  cloud:
    gateway:
      routes:
      - id: my_app1_route
        uri: lb://MY-APP1
        filters:
        - RewritePath=/myapp1(?<segment>/?.*), $\{segment}
        predicates:
        - (...)

探索ロケーター アプローチと明示的なルート定義の両方にルート述語を使って、無効な要求を拒否することができます。 このケースでは、その機能を使って、Azure Spring Apps の前にあると想定されるリバース プロキシが送信元ではない要求をブロックします。

X-Forwarded-For HTTP ヘッダーを使用してアクセスを制限する

Azure Spring Apps にアプリをデプロイすると、HTTP クライアントまたはリバース プロキシからは直接そのアプリに接続されません。 ネットワーク トラフィックは、まず内部のイングレス コントローラーを経由します。

追加のサービスにより、ダイレクト ネットワーク クライアントの IP アドレスは常に Azure Spring Apps の内部コンポーネントとなります。 IP アドレスは、アプリを呼び出すリバース プロキシのような "論理" クライアントではありません。 クライアントの IP アドレスをアクセス制限に使うことはできません。 また、Spring Cloud Gateway の組み込みの RemoteAddr ルート述語は、既定でクライアント IP アドレスを使うので、要求フィルター処理には使用できません。

幸い、Azure Spring Apps では、アプリへの要求で、論理クライアントの IP アドレスを常に X-Forwarded-For HTTP ヘッダーに追加しています。 X-Forwarded-For ヘッダーの最後 (1 番右) の値には、常に論理クライアントの IP アドレスが含まれています。

X-Forwarded-For ヘッダーに基づいて要求をフィルター処理するには、組み込みの XForwarded Remote Addr ルート述語を使います。 この述語を使うことで、1 番右の値として許可されるリバース プロキシの IP アドレスまたは IP 範囲の一覧を構成できます。

正しいホスト名と要求 URL が表示されるようにアプリを構成する

Spring Cloud Gateway を使用する場合に考慮すべき重要な要素があります。 Spring Cloud Gateway では、送信要求の HTTP Host ヘッダーにアプリ インスタンスの内部 IP アドレス (たとえば Host: 10.2.1.15:1025) を設定します。 アプリケーション コードから見える要求のホスト名は、ブラウザーから送信された要求の元のホスト名 (contoso.com など) ではなくなります。 場合によっては、この結果により Cookie が破損したり、リダイレクト URL が正しく動作しないなどの問題が発生する可能性があります。 このような問題と、それを回避するための Application Gateway や Azure Front Door などのリバース プロキシ サービスの構成方法については、「ホスト名の保存」を参照してください。

Spring Cloud Gateway では、Forwarded ヘッダーに元のホスト名が指定されます。 また、X-Forwarded-Port、X-Forwarded-Proto、X-Forwarded-Prefix などの他のヘッダーも設定されるため、アプリケーションで使用して元の要求 URL を再構築することもできます。 Spring Framework アプリケーションでは、アプリケーションのプロパティで server.forward-headers-strategy 設定を FRAMEWORK に設定することで、この構成を自動的に実現できます。 (この値は NATIVE に設定しないでください。設定した場合、他のヘッダーが使用され、必要な X-Forwarded-Prefix ヘッダーが考慮されません)。詳細については、「フロントエンド プロキシ サーバーの背後での実行」を参照してください。 この構成の場合、HttpServletRequest.getRequestURL メソッドではこれらのヘッダーをすべて考慮し、ブラウザーから送信されたとおりの要求 URL を返します。

シナリオ 3: Spring Cloud Gateway と共に Application Gateway を使用する

シナリオ 3 では、Spring Cloud Gateway エンドポイントを介してパブリックに到達可能なアプリのリバース プロキシとして Application Gateway を使用する方法について説明します。

次の図は、シナリオ 3 のアーキテクチャを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

Application Gateway を Azure Spring Apps インスタンスの前に配置する場合、Spring Cloud Gateway アプリの割り当てられたエンドポイントをバックエンド プールとして使います。 エンドポイントの例は myspringcloudservice-mygateway.azuremicroservices.io です。 Azure Spring Apps は仮想ネットワークの外部にデプロイされているため、この URL はパブリック IP アドレスに解決されます。 バックエンド プールがパブリック エンドポイントの場合、Application Gateway はそのフロントエンドのパブリック IP アドレスを使ってバックエンド サービスに到達します。

Application Gateway インスタンスからの要求のみが Spring Cloud Gateway に到達できるようにするには、XForwarded Remote Addr ルート述語を構成します。 次の例に示すように、Application Gateway の専用パブリック IP アドレスからの要求のみを許可するように述語を構成します。

(...)
predicates:
- XForwardedRemoteAddr="20.103.252.85"

シナリオ 4: Spring Cloud Gateway と共に Azure Front Door を使用する

シナリオ 4 では、Spring Cloud Gateway エンドポイントを介してパブリックに到達可能なアプリのリバース プロキシとして Azure Front Door を使用する方法について説明します。

次の図は、シナリオ 4 のアーキテクチャを示しています。

このアーキテクチャの Visio ファイルをダウンロードします。

シナリオ 3 と同様に、この構成では Spring Cloud Gateway アプリのパブリック URL を Azure Front Door のバックエンド プールまたは送信元として使います。 エンドポイントの例は https://myspringcloudservice-mygateway.azuremicroservices.io です。

Azure Front Door は多くのエッジ ロケーションを持つグローバルなサービスなので、バックエンド プールとの通信に多くの IP アドレスを使います。 Azure Front Door のドキュメントには、バックエンドへのアクセスをロックダウンして Azure Front Door のトラフィックのみを許可する方法が説明されています。 ただし、このシナリオでは、アプリがデプロイされている Azure ネットワークを制御しません。 残念ながら AzureFrontDoor.Backend サービス タグを使って、現在の状態であることが保証されている送信 Azure Front Door IP アドレスの完全な一覧を取得できません。 代わりに、Azure IP 範囲とサービス タグをダウンロードし、AzureFrontDoor.Backend セクションを見つけ、addressPrefixes 配列からすべての IP 範囲を XForwarded Remote Addr ルート述語構成にコピーする必要があります。

Azure Front Door の IP 範囲は他の組織と共有されるため、お客様固有の一意の Front Door ID を含む X-Azure-FDID HTTP ヘッダーに基づいて、特定の Azure Front Door インスタンスのみにアクセスをロックダウンすることも必要です。 Header ルート述語を使うことで、アクセスを制限できます。これにより、指定した HTTP ヘッダーに特定の値がない限り、要求は拒否されます。

このシナリオでは、Spring Cloud Gateway のルート述語の構成は、次の例のようになります。

(...)
predicates:
- XForwardedRemoteAddr="13.73.248.16/29","20.21.37.40/29","20.36.120.104/29","20.37.64.104/29", ...(and many more)...
- Header="X-Azure-FDID", "00112233-4455-6677-8899-aabbccddeeff"

共同作成者

Microsoft では、このコンテンツを保持しています。 元のコンテンツは次の共同作成者によって開発されました。

プリンシパル作成者:

• Jelle Druyts | プリンシパル カスタマー エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次の手順

• Azure Spring Apps の参照アーキテクチャ
• Azure Virtual Network での Azure Spring Apps の実行に関するお客様の責任

関連リソース

• ホスト名の保存
• 負荷分散のオプション
• マイクロサービス アーキテクチャ スタイル