次の方法で共有

マルチテナント機能と Azure Private Link

  • [アーティクル]

Azure Private Link は、Azure プラットフォーム サービスや、Azure 仮想マシンでホストされた独自アプリケーションを対象に、プライベート IP アドレスを割り当てる役目を果たします。 Private Link を使用することで、テナントの Azure 環境からプライベートに接続できるようになります。 また、仮想プライベート ネットワーク ゲートウェイ (VPN Gateway) または ExpressRoute で接続されたオンプレミス環境から、Private Link を使用して目的のソリューションにアクセスすることもできます。

Azure Private Link は、 Snowflake、 Confluent Cloud、 MongoDB Atlasを含む多くの大規模な SaaS プロバイダーで使用されています。

この記事では、Azure でホストされるマルチテナント ソリューションを対象に Private Link を構成する方法について説明します。

重要な考慮事項

IP アドレス空間の重複

Private Link はマルチテナント型ソリューションのための強力な機能を提供するもので、テナントは、プライベート アドレス空間を介してサービスにアクセスできるようになります。

同じ (つまり重複する) プライベート IP アドレス空間が複数の異なるテナントによって使用されることは少なくありません。 たとえば、マルチテナント ソリューションに 10.1.0.0/16 という IP アドレス空間が使用されているとします。 同じ IP アドレス空間を持つ独自のオンプレミス ネットワークをテナント A が使用していて、偶然、テナント B も同じ IP アドレス空間を使用しているとしたらどうなるでしょうか。 IP アドレス範囲が重複するため、ネットワークどうしを直接接続したりピアリングしたりすることはできません。

Private Link を使用して各テナントからマルチテナント ソリューションに接続できるようにすると、各テナントのトラフィックにネットワーク アドレス変換 (NAT) が自動的に適用されます。 各テナントは、それぞれのネットワーク内でプライベート IP アドレスを使用でき、トラフィックは透過的にマルチテナント ソリューションに流れます。 テナントとサービス プロバイダーの使用 IP アドレス範囲が重複する場合でも、トラフィックには NAT が実行されます。

2 つのテナントとマルチテナント サービスとの間の接続を示す図。いずれも同じ IP アドレス空間が使用されています。

トラフィックは、マルチテナント ソリューションに到着した時点で既に変換されています。 つまり、マルチテナント サービスがある仮想ネットワーク IP アドレス空間内から送信されたように見えます。 Private Link は TCP プロキシ プロトコル v2 機能を備えており、それによってマルチテナント型サービスは、要求の送信元テナントを把握し、送信元ネットワークにおける元の IP アドレスまで把握することができるのです。

サービスの選択

Private Link を使用する際は、どのサービスへのインバウンド接続を許可するかを考慮することが大切です。

"Azure Private Link サービス" は、仮想マシンを Standard Load Balancer の背後に置いて使用されます。

Private Link を他の Azure サービスと併用することもできます。 そうしたサービスには、Azure App Service などのアプリケーション ホスティング プラットフォームが含まれます。 また、ネットワークと API のゲートウェイである Azure Application Gateway と Azure API Management も含まれます。

Private Link の構成に関わるさまざまな側面と適用される制限は、ご使用のアプリケーション プラットフォームによって決まります。 さらに、インバウンド トラフィックに Private Link がサポートされていないサービスもあります。 使用する Azure サービスのドキュメントで Private Link のサポート状況を確認してください。

制限

ソリューションのアーキテクチャに応じて、作成できるプライベート エンドポイントの数を慎重に考慮してください。 PaaS (サービスとしてのプラットフォーム) アプリケーション プラットフォームを使用する場合、1 つのリソースでサポートできるプライベート エンドポイント数の上限を知っておくことが大切です。 仮想マシンを実行する場合、Private Link サービスのインスタンスを Standard Load Balancer (SLB) にアタッチできます。 この構成では、通常、より多くのプライベート エンドポイントを接続できますが、それでも制限は適用されます。 Private Link を使用してリソースに接続できるテナントの数が、これらの制限によって決まってしまう場合があります。 エンドポイント数と接続数の上限については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。

加えて、Private Link を使用するために特殊なネットワーク構成が必要になるサービスもあります。 たとえば、Private Link と Azure Application Gateway を併用する場合は、Application Gateway リソース用の Standard サブネットのほかに 専用サブネットをプロビジョニングする必要があります。

デプロイと診断の構成を含むソリューションのテストを、Private Link の構成を有効にした状態で慎重に行ってください。 一部の Azure サービスでプライベート エンドポイントが有効になっていると、パブリック インターネット トラフィックがブロックされます。 この動作により、デプロイと管理のプロセスの変更が必要になる場合があります。

ソリューションをインターネットに公開したうえで、さらにプライベート エンドポイント経由で公開するようなデプロイも考えられます。 たとえば、一部のテナントはプライベート接続を必要とし、他のテナントはパブリック インターネット接続に依存している場合があります。 全体的なネットワーク トポロジと、各テナントのトラフィックが辿るパスを考慮してください。

Standard Load Balancer の背後にある仮想マシンに依拠したソリューションであっても、Private Link サービス経由でエンドポイントを公開できます。 この場合、仮想マシン ベースのワークロードには、たいてい Web アプリケーション ファイアウォールとアプリケーション ルーティングが既に含まれています。

Azure PaaS サービスの多くは、インバウンド接続に Private Link をサポートしています。Azure サブスクリプションや Microsoft Entra テナントの垣根を越えたインバウンド接続もサポートされます。 そのサービスの Private Link 機能を使用してエンドポイントを公開することができます。

インターネットに接続する他のサービス、たとえば Azure Front Door を使用する際は、インバウンド トラフィックに Private Link がサポートされているかどうかを考慮することが大切です。 されていない場合は、ソリューションに至る各パスをトラフィックがどのように辿るかを考慮してください。

たとえば、インターネットに接続するアプリケーションを構築して、仮想マシン スケール セット上で実行するとします。 セキュリティとトラフィック アクセラレーションに Azure Front Door を使用し、 そのトラフィックをプライベート エンドポイント経由でバックエンド (提供元) サービスに送信するよう Front Door を構成します。Azure Front Door には、その Web Application Firewall (WAF) が含まれています。 ソリューションへの接続に、テナント A はパブリック エンドポイントを、テナント B はプライベート エンドポイントを使用します。 Front Door は受信接続に Private Link をサポートしないため、テナント B のトラフィックは Front Door とその WAF をバイパスすることになります。

Azure Front Door 経由および (Front Door をバイパスする) プライベート エンドポイント経由で要求を受信するようすを示した図。

分離モデル

Private Link はその設計上、1 つのアプリケーション層を複数の分離したクライアント (テナントなど) で使用するシナリオをサポートします。 Private Link の分離を検討する際、主な懸念事項は、要件をサポートするためにデプロイする必要があるリソースの数です。 Private Link に使用できるテナント分離モデルは、使用するサービスによって異なります。

Standard Load Balancer の背後にある仮想マシンに対して Private Link サービスを使用する場合、検討できる分離モデルはいくつかあります。

考慮事項 共有 Private Link サービスと共有ロード バランサー 専用 Private Link サービスと専用ロード バランサー 専用 Private Link サービスと共有ロード バランサー
デプロイの複雑性 低 中から高 (テナント数による) 中から高 (テナント数による)
操作の複雑さ 低 中から高 (リソース数による) 中から高 (リソース数による)
考慮すべき制限 同じ Private Link サービスでのプライベート エンドポイントの数 サブスクリプションあたりの Private Link サービスの数 Standard Load Balancer あたりの Private Link サービスの数
シナリオ例 共有アプリケーション層を備えた大規模なマルチテナント ソリューション テナントごとに分離されたデプロイ スタンプ 1 つのスタンプに多数のテナントが存在する共有アプリケーション層

3 ついずれのモデルも、データの分離とパフォーマンスのレベルは、ソリューションの他の要素に依存し、Private Link サービスのデプロイがこれらの要素に重大な影響を与えることはありません。

共有 Private Link サービスをデプロイして、Standard Load Balancer に接続する方法があります。 各テナントはプライベート エンドポイントを作成し、それを使用してソリューションに接続できます。

Private Link サービスの 1 つのインスタンスで多数のプライベート エンドポイントがサポーされます。 制限に達した場合は、Private Link サービスのインスタンスを追加デプロイできますが、1 つのロード バランサーにデプロイできる Private Link サービスの数にも制限があります。 これらの制限に近づくことが予想される場合は、デプロイ スタンプ ベースのアプローチを使用し、共有ロード バランサーと Private Link サービス インスタンスを各スタンプにデプロイすることを検討してください。

テナントごとに専用 Private Link サービスと専用ロード バランサーをデプロイできます。 テナントに厳しいコンプライアンス要件がある場合など、テナントごとに専用の一連の仮想マシンがある場合は、このアプローチが有効です。

Private Link サービスのインスタンスを各テナント専用にデプロイしたうえで、共有 Standard Load Balancer をデプロイすることもできます。 ただし、このモデルから大きなメリットが得られる可能性はあまりありません。 また、1 つの Standard Load Balancer にデプロイできる Private Link サービスの数には上限があるので、小規模なマルチテナント ソリューションの枠を超えたスケーリングは困難です。

共有 Private Link サービスを複数デプロイする方が一般的です。 この方法であれば、1 つの共有ロード バランサーでサポートできるプライベート エンドポイントの数を拡張することができます。

プライベート エンドポイントを使用した Azure PaaS サービスの分離モデル

Azure の Platform as a Service (PaaS) サービスをデプロイし、テナントがプライベート エンドポイントでそれらのサービスにアクセスできるようにする場合は、特定のサービスの機能と制約を考慮してください。 さらに、アプリケーション層のリソースが特定のテナント専用なのか、テナント間で共有されているのかを考慮してください。

テナントごとに専用の一連のアプリケーション層リソースをデプロイする場合、リソースへのアクセスに使用するプライベート エンドポイントをテナントごとに 1 つデプロイすることになるでしょう。 各テナントには専用のリソースがあるため、Private Link に関連したサービスの上限まで使い切ることはまずありません。

アプリケーション層のリソースをテナント間で共有する場合、テナントごとにプライベート エンドポイントをデプロイすることを検討するかもしれません。 1 つのリソースにアタッチできるプライベート エンドポイントの数には制限があり、これらの制限はサービスごとに異なります。

Private Link には、マルチテナント環境で役立ついくつかの機能があります。 ただし、具体的に利用できる機能は、使用するサービスによって異なります。 仮想マシンとロード バランサーの基本的な Azure Private Link サービスでは、以下に説明するすべての機能がサポートされています。 Private Link をサポートするその他のサービスでは、これらの機能のサブセットに利用が限定される場合があります。

サービス エイリアス

テナントは、Private Link を使用してサービスへのアクセスを構成する際、Azure が接続を確立できるよう、サービスを識別できなければなりません。

Private Link サービス、そして Private Link に対応している他の特定の Azure サービスでは、テナントに提供する エイリアスを構成 できます。 エイリアスを使用すれば、Azure サブスクリプション ID やリソース グループ名は開示せずに済みます。

サービスの可視性

Private Link サービスを通じて、 プライベート エンドポイントの可視性を制御することができます。 たとえば、エイリアスまたはリソース ID を知っているすべての Azure 顧客にサービスへの接続を許可することができます。 または、一連の既知の Azure 顧客のみにアクセスを制限することもできます。

また、プライベート エンドポイントに接続できる事前承認済みの Azure サブスクリプション ID のセットを指定することもできます。 この方法を使用する場合は、サブスクリプション ID をどのように収集して承認するかを検討してください。 たとえば、テナントのサブスクリプション ID を収集するための管理ユーザー インターフェイスをアプリケーションに用意することが考えられます。 そのうえで、Private Link サービス インスタンスを動的に再構成して、該当サブスクリプション ID の接続を事前承認することができます。

接続の承認

Private Link では、クライアント (テナントなど) とプライベート エンドポイントとの間の接続が要求された後、接続が "承認" されなければなりません。 接続が承認されるまで、トラフィックはプライベート エンドポイント接続を通過できません。

Private Link サービスでは、いくつかの種類の承認フローがサポートされています。以下はその例です。

  • 手動承認。すべての接続をチームが明示的に承認します。 Private Link を介してサービスを使用するテナントがごく少数である場合は現実的な方法です。
  • API ベースの承認。Private Link サービスは手動での接続の承認を要求し、アプリケーションは Update Private Endpoint Connection API、Azure CLI、Azure PowerShell のいずれかを使用して接続を承認します。 プライベート エンドポイントの使用が承認されているテナントの一覧がある場合に適した方法です。
  • 自動承認。接続が自動的に承認されるべきサブスクリプション ID の一覧を Private Link サービス自体が保持します。

詳細については、「サービス アクセスを制御する」を参照してください。

プロキシ プロトコル v2

Private Link サービスの使用時、皆さんのアプリケーションから見えるのは、既定ではネットワーク アドレス変換 (NAT) 後の IP アドレスだけです。 つまり、それ自体の仮想ネットワーク内からトラフィックが流れてきているように見えるということです。

Private Link では、元の、つまりテナントの仮想ネットワークにおけるクライアント IP アドレスにアクセスできます。 この機能には TCP プロキシ プロトコル v2 が使用されています。

たとえば、"特定のサービスに対し、ホスト 10.0.0.10 からはアクセスできるが、ホスト 10.0.0.20 からはアクセスできない" など、IP アドレス ベースのアクセス制限を追加するという要件がテナントの管理者にあるとします。 プロキシ プロトコル v2 が使用されていれば、アプリケーションに対するこのようなアクセス制限をテナントが構成できます。 ただし、アプリケーション コードでクライアントの元の IP アドレスを検査し、制限を適用する必要があります。

  • Azure Private Link サービスのプロバイダー (SaaS ISV) とコンシューマーの視点からの説明とデモ: マルチテナント サービス プロバイダー (独立系ソフトウェア ベンダーが SaaS 製品を構築するなど) を可能にするAzure Private Link サービス機能を見るビデオ。 このソリューションを使用すると、コンシューマーは、コンシューマー自身の Azure 仮想ネットワークからプライベート IP アドレスを使用してプロバイダーのサービスにアクセスできます。
  • Azure Private Link サービスを使用した TCP プロキシ プロトコル v2 - 詳細情報: Azure Private Link サービスの高度な機能である TCP プロキシ プロトコル v2 の詳細を示すビデオ。 マルチテナントや SaaS のシナリオで役立ちます。 ビデオでは、Azure Private Link サービスでプロキシ プロトコル v2 を有効にする方法を説明します。 また、NGINX サービスを構成して、NAT IP ではなく元のクライアントのソース プライベート IP アドレスを読み取り、プライベート エンドポイント経由でサービスにアクセスする方法についても説明します。
  • NGINX Plus を使用して、Azure Private Link サービスからプロキシ プロトコル TLV をデコード linkIdentifier する: NGINX Plus を使用して、Azure Private Link サービスから TCP プロキシ プロトコル v2 TLV を取得する方法を説明する動画。 この動画では、プライベート エンドポイント接続の数値 linkIdentifier (LINKID とも呼ばれます) を抽出してデコードする方法が紹介されています。 このソリューションは、接続元となる特定のコンシューマー テナントを識別する必要があるマルチテナント プロバイダーに役立ちます。
  • SaaS プライベート接続パターン: Azure Managed Applications を使用してプライベート エンドポイント接続の承認を自動化するための 1 つのアプローチを紹介するサンプル ソリューション。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • John Downs | プリンシパル ソフトウェア エンジニア
  • Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

その他の共同作成者:

  • Sumeet Mittal | Azure Private Link のプリンシパル製品マネージャー

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

マルチテナントでのネットワークのアプローチを確認します。