Azure にデプロイされるすべてのソリューションには、何らかの形式のネットワークが必要です。 Azure ネットワーク サービスを操作する方法は、ソリューションの設計とワークロードによって異なります。 この記事では、Azure 上のマルチテナント ソリューションのネットワークの側面に関する考慮事項とガイダンスを提供します。 これには、仮想ネットワークなどの下位レベルのネットワーク コンポーネントに関する情報が含まれており、上位レベルおよびアプリケーション層のアプローチまで拡張されます。
注
Azure は、ネットワーク コンポーネントの多くと同様に、マルチテナント環境です。 独自のソリューションを設計するために詳細を理解する必要はありませんが、 Azure が仮想ネットワーク トラフィックを他の顧客のトラフィックから分離する方法について詳しく学習できます。
主な考慮事項と要件
インフラストラクチャとプラットフォームのサービス
ネットワーク コンポーネントの考慮事項は、使用するサービスのカテゴリによって異なります。
インフラストラクチャ サービス
仮想マシン (VM) や Azure Kubernetes Service (AKS) などのインフラストラクチャ サービスを使用する場合は、サービスの接続を支える仮想ネットワークを検討し、設計します。 また、設計に組み込む必要があるセキュリティと分離の他のレイヤーも検討してください。 ネットワーク レイヤー コントロールだけに依存することを回避してください。
プラットフォーム サービス
Azure App Service、Azure Cosmos DB、Azure SQL Database などの Azure プラットフォーム サービスを使用する場合、アーキテクチャによって必要なネットワーク サービスが決まります。
プラットフォーム サービスをインターネットから分離するには、仮想ネットワークを使用します。 使用するサービスによっては、 プライベート エンドポイント または Azure Application Gateway などの仮想ネットワーク統合リソースを操作できます。 また、パブリック IP アドレスを介してプラットフォーム サービスを利用できるようにし、ファイアウォールや ID 制御などのサービス独自の保護を使用することもできます。 このような状況では、独自の仮想ネットワークをデプロイして構成する必要がない場合があります。
次の要因に基づいて、プラットフォーム サービスに仮想ネットワークを使用するかどうかを決定します。
コンプライアンス要件: 特定のコンプライアンス標準を満たすことが必要になる場合があります。 一部の標準では、特定のネットワーク制御の使用など、特定の方法で Azure 環境を構成する必要があります。 詳細については、 マルチテナント ソリューションでのガバナンスとコンプライアンスのアーキテクチャ アプローチに関する記事を参照してください。
テナントの要件: 組織でネットワーク層の分離または制御の要件が定義されていない場合でも、テナントが存在する可能性があります。 テナントがソリューションにアクセスする方法と、テナントがネットワーク設計に関する前提条件を持っているかどうかを明確に理解します。
複雑さ： 仮想ネットワークでは複雑さが発生します。 セキュリティで保護されていない環境のデプロイを回避するために必要な原則をチームが明確に理解していることを確認します。
プライベート ネットワークを使用する場合の影響を理解していることを確認してください。
サブネットのサイズを設定する
仮想ネットワークをデプロイする必要がある場合は、サブネットを含む仮想ネットワーク全体のサイズとアドレス空間を慎重に検討してください。
Azure リソースを仮想ネットワークにデプロイする方法と、各リソースが使用する IP アドレスの数について説明します。 テナント固有のコンピューティング ノード、データベース サーバー、またはその他のリソースをデプロイする場合は、予想されるテナントの増加と リソースの水平方向の自動スケーリングに十分な大きさのサブネットを作成します。
同様に、マネージド サービスを使用する場合は、それらがどのように IP アドレスを使用するかを理解します。 たとえば、 Azure Container Networking Interface (CNI) で AKS を使用する場合、サブネットから使用される IP アドレスの数は、ノードの数、水平方向のスケーリング方法、サービスのデプロイ プロセスなどの要因に基づきます。 仮想ネットワーク統合で App Service と Azure Functions を使用する場合、 使用される IP アドレスの数はプラン インスタンスの数に基づいています。
サブネットを計画するときは、サブネットのセグメント化のガイダンスを確認 します。
パブリックまたはプライベート アクセス
テナントがインターネットまたはプライベート IP アドレスを介してサービスにアクセスする必要があるかどうかを検討します。
インターネット ベース (パブリック) アクセス用にサービスをセキュリティで保護するには、ファイアウォール規則、IP アドレスの許可リストと拒否リスト、共有シークレットとキー、ID ベースの制御を使用します。
テナントがプライベート IP アドレスを使用してサービスに接続できるようにするには、 Azure Private Link サービス または テナント間仮想ネットワーク ピアリングの使用を検討してください。 一部の限られたシナリオでは、Azure ExpressRoute または Azure VPN Gateway を使用してソリューションへのプライベート アクセスを有効にすることも検討してください。 通常、この方法は、テナントが少ない場合や、テナントごとに専用の仮想ネットワークをデプロイする場合にのみ有効です。
テナントのエンドポイントへのアクセス
Azure の内部または外部のテナントのネットワーク内のエンドポイントにデータを送信する必要があるかどうかを検討します。 たとえば、顧客が提供する Webhook を呼び出したり、テナントのシステムにリアルタイム メッセージを送信したりできます。
テナントのエンドポイントにデータを送信する必要がある場合は、次の一般的な方法を検討してください。
インターネット経由でソリューションからテナントのエンドポイントへの接続を開始します。 接続が 静的 IP アドレスから発信される必要があるかどうかを検討します。 使用する Azure サービスによっては、Azure NAT ゲートウェイ、ファイアウォール、またはロード バランサーをデプロイして、ネットワーク アドレス変換 (NAT) を使用することが必要になる場合があります。
場所に関係なく、Azure でホストされるサービスと顧客のネットワーク間の接続を有効にする エージェント をデプロイします。
一方向メッセージングには、イベント ドメインを使用する可能性がある Azure Event Grid などのサービスを使用することを検討してください。
考慮すべきアプローチとパターン
このセクションでは、マルチテナント ソリューションで考慮すべき主要なネットワーク アプローチについて説明します。 まず、コア ネットワーク コンポーネントの下位レベルのアプローチから始めて、HTTP やその他のアプリケーション層の問題に対するアプローチについて説明します。
サービス プロバイダーが選択した IP アドレスを持つテナント固有の仮想ネットワーク
一部のシナリオでは、テナントの代わりに Azure で専用の仮想ネットワーク接続リソースを実行する必要があります。 たとえば、テナントごとに VM を実行したり、プライベート エンドポイントを使用してテナント固有のデータベースにアクセスしたりする必要がある場合があります。
制御する IP アドレス空間を使用して、テナントごとに仮想ネットワークをデプロイすることを検討してください。 この方法では、トラフィックのイングレスとエグレスを一元的に制御する ハブ アンド スポーク トポロジ の確立など、独自の目的で仮想ネットワークをピアリングできます。
仮想ネットワーク ピアリングを使用するなどして、作成した仮想ネットワークにテナントが直接接続する必要がある場合は、サービス プロバイダーが選択した IP アドレスを使用しないでください。 選択したアドレス空間は、既存のアドレス空間と競合している可能性があります。
テナントが選択された IP アドレスを持つテナント固有の仮想ネットワーク
テナントに代わって管理する仮想ネットワークと独自の仮想ネットワークをピアリングする必要がある場合は、テナントが選択した IP アドレス空間を使用してテナント固有の仮想ネットワークをデプロイすることを検討してください。 このセットアップにより、各テナントは、システムの仮想ネットワーク内の IP アドレス範囲が独自の仮想ネットワークと重複しないようにし、ピアリングの互換性を実現できます。
ただし、この方法では、テナントの仮想ネットワークをピアリングしたり、 ハブアンドスポーク トポロジを採用したりすることができなくなる可能性があります。 ピアリングされた仮想ネットワークでは、重複する IP アドレス範囲を使用できません。テナントが独自の IP アドレス範囲を選択すると、互いに重複する範囲が選択される可能性があります。
ハブアンドスポーク トポロジ
ハブアンドスポーク仮想ネットワーク トポロジを使用すると、一元化されたハブ仮想ネットワークを複数のスポーク仮想ネットワークとピアリングできます。 仮想ネットワークのトラフィックのイングレスとエグレスを一元的に制御し、各スポークの仮想ネットワーク内のリソースが相互に通信できるかどうかを制御できます。 各スポーク仮想ネットワークは、Azure Firewall などの共有コンポーネントにもアクセスでき、Azure DDoS Protection などのサービスを使用する場合があります。
ハブアンドスポーク トポロジを使用する場合は、 ピアリングされた仮想ネットワークの最大数などの制限を計画します。 各テナントの仮想ネットワークに重複するアドレス空間を使用しないでください。
選択した IP アドレスを使用するテナント固有の仮想ネットワークをデプロイするときは、ハブアンドスポーク トポロジの使用を検討してください。 各テナントの仮想ネットワークはスポークになり、ハブ仮想ネットワーク内の共通リソースを共有できます。 ハブアンドスポーク トポロジは、複数の仮想ネットワーク間で共有リソースをスケーリングする場合や 、デプロイ スタンプ パターンを使用する場合にも使用できます。
ヒント
ソリューションが複数の地理的リージョンにまたがる場合は、トラフィックが複数の Azure リージョンを通過しないように、リージョンごとに個別のハブとハブ リソースをデプロイします。 この方法では、リソース コストが高くなりますが、要求の待機時間が短縮され、グローバル ピアリングの料金が削減されます。
静的 IP アドレス
受信トラフィック、送信トラフィック、またはその両方に対して、テナントで静的パブリック IP アドレスを使用するためのサービスが必要かどうかを検討します。 さまざまな Azure サービスによって、静的 IP アドレスがさまざまな方法で有効になります。
VM やその他のインフラストラクチャ コンポーネントを使用する場合は、受信と送信の両方の静的 IP アドレス指定にロード バランサーまたはファイアウォールを使用することを検討してください。 Azure NAT ゲートウェイを使用して、送信トラフィックの IP アドレスを制御することを検討してください。 詳細については、マルチテナント
プラットフォーム サービスを使用する場合、使用する特定のサービスによって、IP アドレスを制御する方法が決まります。 VM などのリソースを仮想ネットワークにデプロイし、NAT ゲートウェイまたはファイアウォールを使用するなど、特定の方法でリソースを構成する必要がある場合があります。 または、サービスが送信トラフィックに使用する IP アドレスの現在のセットを要求することもできます。 たとえば、 App Service は、アプリケーションの現在の送信 IP アドレスを取得するための API と Web インターフェイスを提供します。
エージェント
テナントがソリューションによって開始されたメッセージを受信したり、テナントのネットワーク内のデータにアクセスしたりできるようにするには、ネットワーク内にデプロイするエージェント ( オンプレミス ゲートウェイとも呼ばれる) を提供することを検討してください。 このアプローチは、テナントのネットワークが Azure 内にあるか、別のクラウド プロバイダーにあるか、オンプレミスにあるかに関係なく機能します。
エージェントは、指定して制御するエンドポイントへの送信接続を開始します。 実行時間の長い接続を維持するか、断続的にポーリングします。 Azure Relay を使用して、エージェントからサービスへの接続を確立し管理することを検討してください。 エージェントは接続を確立すると、サービスが正しいテナントに接続をマップできるように、テナント識別子に関する情報を認証して含めます。
通常、エージェントはテナントのセキュリティ構成を簡略化します。 特にオンプレミスの環境では、受信ポートを開くことは複雑でリスクが高い場合があります。 エージェントを使用すると、テナントがこのリスクを取る必要がなくなります。
テナントのネットワークに接続するためのエージェントを提供する Microsoft サービスには、次の例があります。
- Azure Data Factory セルフホステッド統合ランタイム
- App Service ハイブリッド接続
- Azure Logic Apps、Power BI、およびその他のサービスに使用される Microsoft オンプレミス データ ゲートウェイ
Private Link サービス
Private Link サービス は、テナントの Azure 環境からソリューションへのプライベート接続を提供します。 テナントは、独自の仮想ネットワークで Private Link サービスを使用して、オンプレミス環境からサービスにアクセスすることもできます。 Azure は、プライベート IP アドレスを使用してサービスにトラフィックを安全にルーティングします。
詳細については、「 マルチテナントとプライベート リンク」を参照してください。
ドメイン名、サブドメイン、および TLS
マルチテナント ソリューションでドメイン名とトランスポート層セキュリティ (TLS) を使用する場合は、 主な考慮事項を確認してください。
ゲートウェイ ルーティングとゲートウェイ オフロード パターン
ゲートウェイ ルーティング パターンとゲートウェイ オフロード パターンには、レイヤー 7 リバース プロキシまたはゲートウェイのデプロイが含まれます。 ゲートウェイは、次の機能を含むマルチテナント アプリケーションのコア サービスを提供します。
- テナント固有のバックエンドまたはデプロイ スタンプへの要求のルーティング
- テナント固有のドメイン名と TLS 証明書の処理
- Web アプリケーション ファイアウォール (WAF) を使用してセキュリティ上の脅威の要求を検査する
- パフォーマンスを向上させるために応答をキャッシュする
Azure には、Azure Front Door、Application Gateway、Azure API Management など、これらの目標の一部またはすべてを達成できるいくつかのサービスが用意されています。 NGINX や HAProxy などのソフトウェアを使用して、独自のカスタム ソリューションをデプロイすることもできます。
ソリューションのゲートウェイをデプロイする場合は、最初に完全なプロトタイプを構築することをお勧めします。 必要なすべての機能を含め、アプリケーション コンポーネントが期待どおりに機能することを確認します。 また、トラフィックとテナントの増加をサポートするためにゲートウェイ コンポーネントがどのようにスケーリングされるかも理解する必要があります。
静的コンテンツ ホスティング パターン
静的コンテンツ ホスティング パターンは、クラウドネイティブ ストレージ サービスの Web コンテンツを提供し、コンテンツ配信ネットワークを使用してコンテンツをキャッシュします。
シングルページ JavaScript アプリケーションなどのソリューションの静的コンポーネントや、イメージ ファイルやドキュメントなどの静的コンテンツには、 Azure Front Door または別のコンテンツ配信ネットワークを使用できます。
ソリューションの設計によっては、JSON 形式の API 応答など、テナント固有のファイルやデータをコンテンツ配信ネットワーク内にキャッシュできる場合もあります。 このプラクティスは、ソリューションのパフォーマンスとスケーラビリティの向上に役立ちます。 テナント間でのデータ漏洩を防ぐために、テナント固有のデータが十分に分離されていることを確認します。 データが更新された場合や新しいアプリケーション バージョンがデプロイされた場合など、テナント固有のコンテンツをキャッシュから消去する方法を検討してください。 URL パスにテナント識別子を含めることで、特定のファイル、特定のテナントに関連するすべてのファイル、またはすべてのテナントのすべてのファイルを消去するかどうかを制御できます。
回避すべきアンチパターン
仮想ネットワーク接続の計画に失敗する
仮想ネットワークにリソースをデプロイすると、トラフィックがソリューションのコンポーネントを通過する方法を大幅に制御できます。 ただし、仮想ネットワーク統合では、特にサービスとしてのプラットフォーム (PaaS) コンポーネントに対して、より複雑さ、コスト、その他の要因も考慮する必要があります。
運用環境に実装する前に、ネットワーク戦略をテストして計画し、問題を特定します。
制限を計画しない
Azure では、ネットワーク リソースに影響する多くの制限が適用されます。 これらの制限には、 Azure リソースの制限 と、基本的なプロトコルとプラットフォームの制限が含まれます。 たとえば、App Service や Azure Functions などのプラットフォーム サービスで大規模なマルチテナント ソリューションを構築する場合は、 伝送制御プロトコル (TCP) 接続と送信元ネットワーク アドレス変換 (SNAT) ポートの数を考慮する必要があります。 VM とロード バランサーを使用する場合は、 送信規則 と SNAT ポートの制限も考慮する必要があります。
小さなサブネット
デプロイする予定のリソースまたはインスタンスの数をサポートするように各サブネットのサイズを設定します (特にスケーリング時)。 PaaS リソースを使用する場合は、リソースの構成とスケールが、そのサブネットで必要な IP アドレスの数にどのように影響するかを理解します。
ネットワークの不適切なセグメント化
ソリューションに仮想ネットワークが必要な場合は、受信トラフィックと送信トラフィック (南北トラフィックと呼ばれます) とソリューション内のトラフィック (東西トラフィックと呼ばれます) を制御するようにネットワークセグメント化を構成する方法を検討してください。 テナントが独自の仮想ネットワークを持つ必要があるか、共有仮想ネットワークに共有リソースをデプロイする必要があるかを決定します。 アプローチの変更は困難な場合があるため、将来の成長目標に適したアプローチを選択する前に、すべての要件を慎重に検討してください。
ネットワーク レイヤー セキュリティ コントロールにのみ依存する
最新のソリューションでは、ネットワーク層セキュリティを他のセキュリティコントロールと組み合わせる必要があります。 ファイアウォールやネットワークのセグメント化だけに依存しないでください。 このアプローチは、 ゼロ トラスト ネットワークと呼ばれることもあります。 ID ベースのコントロールを使用して、ソリューションのすべてのレイヤーでクライアント、呼び出し元、またはユーザーを確認します。 保護のレイヤーを追加できるサービスの使用を検討してください。 オプションは、使用する Azure サービスによって異なります。 AKS では、相互 TLS 認証にサービス メッシュを使用することを検討し、 ネットワーク ポリシーを 適用して東西トラフィックを制御します。 この App Service では、 認証と承認の組み込みのサポート と アクセスの制限を使用することを検討してください。
テストなしでホスト ヘッダーを書き換える
ゲートウェイ オフロード パターンを使用する場合は、HTTP 要求の Host ヘッダーの書き換えを検討してください。 この方法では、カスタム ドメインと TLS 管理をゲートウェイにオフロードすることで、バックエンド Web アプリケーション サービスの構成を簡略化できます。
ただし、 Host ヘッダーの書き換えは、一部のバックエンド サービスで問題を引き起こす可能性があります。 アプリケーションが HTTP リダイレクトまたは Cookie を発行すると、ホスト名の不一致によってアプリケーションの機能が破損する可能性があります。 特に、この問題は、App Service や Azure Functions などのマルチテナント インフラストラクチャで実行されるバックエンド サービスを使用する場合に発生する可能性があります。 詳細については、「 ホスト名の保持のベスト プラクティス」を参照してください。
使用する予定のゲートウェイ構成を使用して、アプリケーションの動作をテストします。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
プリンシパル作成者:
- ジョン・ダウンズ |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
その他の共同作成者:
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
- Joshua Waddell | FastTrack for Azure のシニア カスタマー エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
関連リソース
- マルチテナント ソリューションでのドメイン名に関する考慮事項。
- ご使用のネットワーク サービスに関するサービス固有のガイダンスを確認します。