Azure 上の SaaS ワークロードのネットワーク
ネットワークは、顧客が SaaS アプリケーションにアクセスする上でのバックボーンを提供し、ソリューションのコンポーネント間の通信を可能にします。 ネットワークの設計方法は、ソリューションのセキュリティ、運用、コスト、パフォーマンス、信頼性に直接影響します。 ネットワーク戦略に対する構造化されたアプローチは、クラウド環境が成長するにつれて、よりいっそう重要になります。
ネットワークのデプロイ戦略とトポロジを決定する
SaaS ソリューションにはそれぞれ、固有のネットワーク要件があります。 より多くの顧客をオンボードさせ、顧客による使用量が増加すると、ネットワーク要件が変化します。 IP アドレス範囲などのリソースは限られているため、成長への対応は困難なものになる可能性があります。 ネットワーク設計は、セキュリティと顧客の分離に影響を与えます。 ネットワーク戦略の計画は、成長の管理、セキュリティの向上、運用の複雑さの軽減に役立ちます。
設計上の考慮事項
テナント モデルに基づいてネットワーク デプロイ戦略を計画します。 ネットワーク リソースが顧客間で共有されるのか、1 人の顧客専用のものになるのか、それらの組み合わせになるのかを決定します。 この選択は、アプリケーションの機能、セキュリティ、顧客の分離に影響します。
仮想ネットワークや Azure Front Door プロファイルなどのネットワーク リソースは、複数の顧客間で共有するのが一般的です。 このアプローチにより、コストと運用上のオーバーヘッドが削減されます。 また、接続も簡略化されます。 顧客のリソースを共有ストレージ アカウントやコントロール プレーンなどの共有リソースと簡単に接続することができます。
ただし、高いセキュリティとコンプライアンスを確立するには、顧客ごとに専用のネットワーク リソースが必要になる場合があります。 たとえば、顧客間の高度なネットワークのセグメント化をサポートするには、境界として仮想ネットワークを使用します。 専用リソースが必要になるのは、すべての顧客のネットワーク リソースの数が単一共有ネットワークの容量を超える場合です。
現在と将来の要件を考慮して、各顧客が必要とするネットワーク リソースの数を計画します。 顧客の要件と Azure リソースの制限によって、特定の結果が強制される場合があります。 リソースが異なると、顧客所有の Azure 仮想ネットワークとの仮想ネットワーク ピアリングに個別のネットワークを使用するなど、異なるデプロイ戦略が必要になる場合があります。
SaaS ソリューション内でのリソースの共有の詳細については、「SaaS ワークロードのリソース編成」を参照してください。
ネットワーク トポロジについて理解します。 ネットワーク トポロジは通常、以下の 3 つのカテゴリに分類されます。
フラット ネットワーク: セグメント化用のサブネットを含む単一の分離されたネットワーク。 単純なネットワーク レイアウトを持つ単一マルチテナント アプリケーションに最適です。 フラット ネットワークでは、スケーリングによってオーバーヘッドとコストが増加するにつれて、リソースの限界に到達し、追加のネットワークが必要になる可能性があります。 複数のアプリケーションをホストしたり、同じ仮想ネットワーク内で専用のデプロイ スタンプを使用することを計画している場合は、複雑なネットワーク レイアウトが必要になる場合があります。
ハブ アンド スポーク: 分離されたスポーク ネットワークへのピアリングを備えた中央に位置するハブ ネットワーク。 各顧客またはアプリケーションが独自のスポークを所有し、ハブとしか通信を行わないため、高いスケーラビリティと顧客の分離が必要な場合に最適です。 ハブ内のリソースをすべてのスポークで使用できるようにしながら、必要に応じて追加のスポークをすばやくデプロイできます。 ハブ経由の "推移的な" またはスポーク対スポークの通信は既定で無効になっており、これは SaaS ソリューション内の顧客の分離を維持するのに役立ちます。
ネットワークなし: 仮想ネットワークをデプロイせずに複雑なワークロードをホストできる Azure PaaS サービスで使用されます。 たとえば、Azure App Service では、Azure バックボーン ネットワーク経由での他の PaaS サービスとの直接統合が可能です。 このアプローチでは管理が簡素化されますが、セキュリティ制御のデプロイの柔軟性とパフォーマンスを最適化する能力が制限されます。 このアプローチが上手く機能するのは、クラウド ネイティブ アプリケーションにおいてです。 ソリューションが進化するにつれて、やがてはハブ アンド スポーク トポロジに移行することが予想されます。
トレードオフ: 複雑性とセキュリティ。 はじめはネットワーク境界を定義しないことで、セキュリティ グループ、IP アドレス空間、ファイアウォールなどのネットワーク コンポーネントを管理する運用上の負担を軽減できます。 ただし、ネットワーク境界は、ほとんどのワークロードで不可欠です。 ネットワーク セキュリティ制御がない場合は、強力な ID およびアクセス管理を利用して、悪意のあるトラフィックからワークロードを保護します。
マルチリージョン アーキテクチャがどのようにネットワーク トポロジに影響を与えるかを理解します。 仮想ネットワークを使用するマルチリージョン アーキテクチャでは、ファイアウォール、仮想ネットワーク ゲートウェイ、ネットワーク セキュリティ グループをリージョン間で共有できないため、ほとんどのネットワーク リソースはリージョンごとに個別にデプロイされます。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| どのネットワーク コンポーネントが共有され、どのコンポーネントが顧客専用のものとなるかを決定します。 Azure Firewall、Azure Bastion、Azure Front Door などのインスタンスごとに課金されるリソースを共有します。 |
セキュリティと分離に関する要件の間でバランスの取れたサポートを実現すると同時に、コストと運用上の負担を軽減します。 |
| フラット トポロジかネットワークを使用しないアプローチから開始します。 これらのアプローチで提供される分離とトラフィック制御には限界があるため、必ず最初にセキュリティ要件を確認してください。 |
より単純なネットワーク トポロジを使用することで、ソリューションの複雑性とコストを削減できます。 |
| ニーズが複雑な場合や、顧客ごとに専用の仮想ネットワークをデプロイする場合は、ハブ アンド スポーク トポロジを検討してください。 ハブを使用して、複数の顧客ネットワークにわたる共有ネットワーク リソースをホストします。 | ハブ ネットワークを通してリソースを共有することで、スケーリングをより簡単に行い、コスト効率を向上させることができます。 |
安全なネットワーク境界を設計する
ネットワーク境界は、アプリケーションと (インターネットを含む) 他のネットワークとの間にセキュリティ境界を確立します。 ネットワーク境界を文書化することで、以下に示すさまざまな種類のトラフィック フローを区別できるようになります。
- イングレス トラフィック。これは外部ソースからネットワーク内に到着します。
- 内部トラフィック。これはネットワーク内のコンポーネント間を行き来します。
- エグレス トラフィック。これはネットワークから出ていきます。
各フローには、異なるリスクと制御が含まれます。 たとえば、イングレス トラフィックを検査して処理するには、複数のセキュリティ制御が必要です。
重要
一般的なベスト プラクティスとして、必ずゼロ トラストのアプローチに従うようにしてください。 内部トラフィックを含め、すべてのトラフィックが制御かつ検査されるようにしてください。
顧客がアーキテクチャに影響を与える特殊なコンプライアンス要件を持っている場合も考えられます。 たとえば、顧客が SOC 2 コンプライアンスを必要としている場合、顧客はセキュリティ要件を満たすために、ファイアウォール、Web アプリケーション ファイアウォール、ネットワーク セキュリティ グループを含むさまざまなネットワーク制御を実装する必要があります。 すぐに準拠する必要がない場合でも、アーキテクチャの設計時には、これらの拡張性に関係する要因を検討してください。
「SE:06 ネットワークと接続に関する推奨事項」を参照してください
設計上の考慮事項
イングレス トラフィックを保護して管理します。 外からの脅威がないかこのトラフィックを検査します。
ファイアウォールを使用すると、悪意のある IP をブロックし、高度な分析を実行して、侵入の試みからの保護を提供することができます。 しかし、ファイアウォールにはコストがかかる可能性があります。 セキュリティ要件を評価して、ファイアウォールが必要かどうかを判断します。
Web アプリケーションは、SQL インジェクション、クロス サイト スクリプティング、その他の OWASP Top 10 の脆弱性などの一般的な攻撃に対して脆弱です。 Azure Web Application Firewall は、これらの攻撃に対する保護を提供するもので、Application Gateway と Azure Front Door と統合されています。 これらのサービスのレベルを確認して、どの WAF 機能がどの製品に含まれているかを把握します。
DDoS 攻撃は、インターネットに接続しているアプリケーションにとってのリスクです。 Azure は、基本レベルの保護を無償で提供しています。 Azure DDoS Protection は、トラフィック パターンを学習し、それに応じて保護を調整することで高度な保護を提供しますが、コストがかかります。 Front Door を使用している場合は、組み込みの DDoS 機能を利用します。
セキュリティ以外にも、キャッシュと負荷分散を使用することで、イングレス トラフィックを操作して、アプリケーションのパフォーマンスを向上させることもできます。
グローバル HTTP(S) トラフィック管理には、Azure Front Door などのリバース プロキシ サービスを使用することを検討します。 または、受信トラフィック制御に Application Gateway やその他の Azure サービスを使用します。 Azure での負荷分散の選択肢の詳細については、「負荷分散の選択肢」を参照してください。
内部トラフィックを保護します。 悪意のあるアクセスを防ぐために、アプリケーションとそのコンポーネント間のトラフィックがセキュリティで保護されていることを確認します。 インターネット経由のルーティングの代わりに内部トラフィックを使用することで、これらのリソースを保護し、パフォーマンスを向上させます。 Azure Private Link は、ネットワーク内の内部 IP アドレスを介して Azure リソースに接続するために一般的に使用されます。 リソースの種類によっては、サービス エンドポイントの方がコスト効率の高い代替手段になる場合があります。 リソースのパブリック インターネット接続を有効にする場合は、IP アドレスやアプリケーション ID (マネージド ID など) を使用してトラフィックを制限する方法を理解してください。
エグレス トラフィックを保護します。 一部のソリューションでは、送信トラフィックを検査してデータ流出を防ぎます。これは特に規制コンプライアンスや企業顧客のために重要です。 ファイアウォールを使用してエグレス トラフィックを管理して確認し、承認されていない場所への接続をブロックします。
送信接続と SNAT をスケーリングする方法を計画します。 ソース ネットワーク アドレス変換 (SNAT) ポートの枯渇は、マルチテナント アプリケーションに影響する可能性があります。 多くの場合、これらのアプリケーションではテナントごとに個別のネットワーク接続が必要であり、顧客間でリソースを共有すると、顧客ベースの拡大に伴う SNAT 枯渇のリスクが高まります。 Azure NAT Gateway、Azure Firewall などのファイアウォール、またはこれら 2 つのアプローチの組み合わせを使用することで、SNAT の枯渇を軽減できます。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| インターネットに公開されているネットワーク エンドポイントのカタログを保守します。 IP アドレス (静的な場合)、ホスト名、ポート、使用されているプロトコル、接続の理由などの詳細をキャプチャします。 各エンドポイントを保護する方法を文書化します。 |
このリストは境界定義の基礎となり、ソリューションを通したトラフィックの管理に関する明示的な決定を行うことを可能にします。 |
| アクセスを制限し、保護を強化するための Azure サービス機能を把握します。 たとえば、ストレージ アカウント エンドポイントを顧客に公開するには、Shared Access Signature、ストレージ アカウント ファイアウォール、内部使用と外部使用用の個別のストレージ アカウントの使用などの追加の制御が必要になります。 |
自身のセキュリティ、コスト、パフォーマンスのニーズに合った制御を選択できます。 |
| HTTP (S) ベースのアプリケーションでは、Azure Front Door や Application Gateway などのリバース プロキシを使用します。 | リバース プロキシは、パフォーマンスの向上、回復性、セキュリティを実現し、運用の複雑さを軽減するための幅広い機能を提供します。 |
| Web アプリケーション ファイアウォールを使用してイングレス トラフィックを検査します。 App Service や Azure Kubernetes Service (AKS) などの Web ベースのリソースをインターネットに直接公開することを避けます。 |
Web アプリケーションを一般的な脅威からより効果的に保護し、ソリューションの全体的な露出を減らすことができます。 |
| DDoS 攻撃からアプリケーションを保護します。 パブリック エンドポイントで使用されているプロトコルに応じて、Azure Front Door や Azure DDoS Protection を使用します。 |
一般的な種類の攻撃からソリューションを保護します。 |
| アプリケーションで大規模なエグレス接続が必要な場合は、NAT Gateway またはファイアウォールを使用して、追加の SNAT ポートを提供します。 | より高いレベルのスケールをサポートできます。 |
ネットワーク間接続
一部のシナリオでは、顧客のプライベート ネットワーク内のデータや、マルチクラウド セットアップにおける別のクラウド プロバイダー上の資産など、Azure の外部のリソースに接続する必要がある場合があります。 これらのニーズにより、ネットワーク設計が複雑化し、具体的な要件に基づいてクロスネットワーク接続を実装するためのさまざまなアプローチが必要になる可能性があります。
設計上の考慮事項
アプリケーションが接続を必要とするエンドポイントを特定します。 アプリケーションは、ストレージ サービスやデータベースなどの他のサービスと通信する必要がある場合があります。 それらの所有者、場所、接続の種類を文書化します。 その後、適切な方法を選択することで、これらのエンドポイントに接続することができます。 一般的なアプローチには以下が存在します。
リソースの場所 Owner 考慮するべき接続の選択肢 Azure カスタマー - (複数の Microsoft Entra ID テナントにわたる) プライベート エンドポイント
- (複数の Microsoft Entra ID テナントにわたる) 仮想ネットワーク ピアリング
- (複数の Microsoft Entra ID テナントにわたる) サービス エンドポイント
その他のクラウド プロバイダー ISV または顧客 - サイト間 VPN
- ExpressRoute
- インターネット
オンプレミス ISV または顧客 - サイト間 VPN
- ExpressRoute
- インターネット
プライベート リンクとプライベート エンドポイント。 仮想マシンの内部ロード バランサーなど、さまざまな Azure リソースへの安全な接続を提供します。 これらによって、SaaS ソリューションへの顧客のプライベート アクセスが実現できますが、コストに関する考慮が伴います。
トレードオフ: セキュリティとコスト。プライベート リンクは、トラフィックがプライベート ネットワーク内に留まることを保証し、Microsoft Entra テナント間のネットワーク接続に推奨されます。 ただし、各プライベート エンドポイントにはコストが発生し、これはセキュリティのニーズによって増加する可能性があります。 サービス エンドポイントはコスト効率に優れた代替手段になる可能性があり、トラフィックを Microsoft バックボーン ネットワーク上に留めながら、一定レベルのプライベート接続を提供します。サービス エンドポイント。 Microsoft のバックボーン ネットワーク経由で PaaS リソースにトラフィックをルーティングし、サービス間通信をセキュリティで保護します。 これは、高帯域幅アプリケーションではコスト効率が高くなる可能性がありますが、セキュリティのためにアクセス制御リストを構成して保守する必要があります。 複数の Microsoft Entra ID テナントにわたるサービス エンドポイントのサポートは、Azure サービスによって異なります。 使用する各サービスの製品ドキュメントを確認してください。
仮想ネットワーク ピアリングは、2 つの仮想ネットワークを接続し、一方のネットワーク内のリソースが他方のネットワーク内の IP アドレスにアクセスできるようにします。 これは、Azure 仮想ネットワーク内のプライベート リソースへの接続を容易にします。 アクセスは、ネットワーク セキュリティ グループを使用して管理できますが、分離の実現は困難な可能性があります。 そのため、具体的な顧客のニーズに基づいてネットワーク トポロジを計画することが重要です。
仮想プライベート ネットワーク (VPN) は、クラウド プロバイダーとオンプレミスの場所を含む 2 つのネットワーク間に、インターネットを経由する安全なトンネルを作成します。 サイト間 VPN は、構成に各ネットワーク内のネットワーク アプライアンスを使用します。 これは、低コストの接続の選択肢を提供しますが、セットアップが必要で、予測可能なスループットは保証されません。
ExpressRoute は、Azure と他のクラウド プロバイダーまたはオンプレミス ネットワーク間の専用かつ高パフォーマンスのプライベート接続を提供します。 これは、予測可能なパフォーマンスを保証し、インターネット トラフィックを回避しますが、コストが高く、より複雑な構成が必要になります。
宛先に基づいた計画を行います。 特にターゲット リソースが顧客の Azure サブスクリプション内にある場合など、異なる Microsoft Entra ID テナント内のリソースに接続することが必要になる場合があります。 プライベート エンドポイント、サイト間 VPN、または仮想ネットワークのピアリングを使用することを検討してください。 詳細については、「複数 Microsoft Entra ID テナントでの仮想ネットワークのピアリング」を参照してください。
別のクラウド プロバイダー内でホストされているリソースに接続するには、パブリック インターネット アクセス、サイト間 VPN、または ExpressRoute を使用するのが一般的です。 詳細については、「他のクラウド プロバイダーへの接続」を参照してください。
ネットワーク トポロジに対する接続の影響を理解します。 Azure 仮想ネットワークが持つことができる仮想ネットワーク ゲートウェイは 1 つだけで、これはサイト間 VPN または ExpressRoute 経由で複数の場所に接続できます。 ただし、ゲートウェイ経由の接続数には制限があり、顧客トラフィックの分離は困難な可能性があります。 異なる場所に対する複数の接続を実現するには、適切にネットワーク トポロジを計画します。おそらくは、顧客ごとに個別の仮想ネットワークをデプロイすることになります。
IP アドレス計画の影響を理解します。 接続に関する一部のアプローチでは、ネットワーク アドレス変換 (NAT) を自動的に提供し、IP アドレスの重複に関する問題を防ぎます。 ただし、仮想ネットワーク ピアリングと ExpressRoute は NAT を実行しません。 これらの方法を使用する場合は、IP アドレス範囲が重複しないようにネットワーク リソースと IP アドレスの割り当てを慎重に計画し、将来の成長を可能にします。 IP アドレスの計画は複雑になる可能性があります。これは、顧客などのサードパーティに接続する場合に顕著です。そのため、サードパーティーの IP 範囲との競合の可能性を考慮してください。
ネットワーク エグレスの課金を理解します。 Azure は通常、送信ネットワーク トラフィックに対する課金を、トラフィックが Microsoft ネットワークを離れるか、Azure リージョン間を移動するタイミングで行います。 マルチリージョンまたはマルチクラウド ソリューションを設計する場合は、コストの影響を理解することが重要です。 Azure Front Door や ExpressRoute の使用などのアーキテクチャに関する選択は、ネットワーク トラフィックに対する課金がどのように行われるかに影響する可能性があります。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| セキュリティを優先するために、ネットワークをまたぐ接続に対してはプライベート ネットワークのアプローチを優先します。 インターネット経由でのルーティングを検討するのは、必ず関連するセキュリティとパフォーマンス上の影響を評価した後にします。 |
プライベート トラフィックは安全なネットワーク パスを通過するため、さまざまな種類のセキュリティ リスクの軽減に役立ちます。 |
| 顧客の Azure 環境でホストされている顧客リソースに接続するときは、Private Link、サービス エンドポイント、または仮想ネットワーク ピアリングを使用します。 | トラフィックを Microsoft ネットワーク上に留めることができるため、その他のアプローチと比較してコストと運用上の複雑性を軽減できます。 |
| クラウド プロバイダーをまたぐ、またはオンプレミス ネットワークへの接続を行う場合は、サイト間 VPN または ExpressRoute を使用します。 | これらのテクノロジは、プロバイダー間の安全な接続を提供します。 |
顧客が所有する環境にデプロイする
ビジネス モデルによっては、顧客の Azure 環境内でアプリケーションまたはそのコンポーネントをホストすることが必要になる場合があります。 顧客は自身の Azure サブスクリプションを管理し、アプリケーションの実行に必要なリソースのコストを直接支払います。 あなたは、ソリューション プロバイダーとして、初期デプロイ、構成の適用、アプリケーションへの更新プログラムのデプロイなどのソリューションの管理を担当します。
このような状況では、多くの場合、顧客は独自のネットワークを利用して、自身が定義したネットワーク空間にアプリケーションをデプロイします。 Azure Managed Applications には、このプロセスを容易にする機能が用意されています。 詳細については、「Azure Managed Applications での既存の仮想ネットワークの使用」を参照してください。
設計上の考慮事項
IP アドレスの範囲と競合。 顧客が仮想ネットワークをデプロイして管理する場合、顧客はネットワークの競合とスケーリングを処理する責任を負います。 ただし、顧客による使用のさまざまなシナリオを予測する必要があります。 IP アドレスを効率的に使用することで、最小限の IP アドレス空間を使用した環境でのデプロイを計画し、顧客の範囲との重複を防ぐために IP アドレス範囲のハードコーディングを避けます。
または、ソリューション専用の仮想ネットワークをデプロイします。 Private Link または仮想ネットワーク ピアリングを使用して、顧客がリソースに接続できるようにすることができます。 これらのアプローチについては、「クロスネットワーク接続」で説明されています。 イングレス ポイントとエグレス ポイントの定義を完了している場合は、IP アドレスの重複によって発生する問題を排除するためのアプローチとして NAT を評価します。
管理目的のネットワーク アクセスを提供します。 顧客環境にデプロイするリソースを確認し、どのようにして監視、管理、再構成のためにそれらにアクセスするかを計画します。 リソースがプライベート IP アドレスを使用して顧客所有の環境にデプロイされる場合は、自身のネットワークからそれらにアクセスするためのネットワーク パスがあることを確認します。 アプリケーションの新しいバージョンのプッシュや Azure リソース構成の更新など、アプリケーションとリソースの両方の変更を容易にする方法を検討してください。
一部のソリューションでは、Just-In-Time アクセスやアプリケーションへの更新プログラムのデプロイなど、Azure Managed Applications によって提供される機能を使用できます。 より詳細な制御が必要な場合は、自分のコントロール プレーンが接続できるエンドポイントを顧客のネットワーク内でホストし、リソースへのアクセスを提供できます。 この方法では、セキュリティ、運用、およびパフォーマンスに関する要件を満たすために、追加の Azure リソースと開発が必要になります。 このアプローチを実装する方法の例については、「Azure Managed Applications の更新のサンプル」を参照してください。
設計の推奨事項
| 推奨 | 特長 |
|---|---|
| Azure Managed Applications を使用して、顧客がデプロイしたリソースをデプロイして管理します。 | Azure Managed Applications には、顧客の Azure サブスクリプション内にリソースをデプロイして管理することを可能にするさまざまな機能が用意されています。 |
| 自分が顧客の仮想ネットワーク空間内で使用する IP アドレスの数を最小限に抑えます。 | 多くの場合、顧客が利用できる IP アドレスには制限があります。 フットプリントを最小限に抑え、自分のスケーリングを顧客の IP アドレスの使用から切り離すことで、自分のソリューションを使用できる顧客の数を増やし、より高いレベルの成長を実現できます。 |
| 顧客の環境内でリソースを管理するためのネットワーク アクセスを取得する方法を計画し、監視、リソース構成の変更、アプリケーションの更新について検討します。 | 自分が管理するリソースを直接構成できます。 |
| 専用の仮想ネットワークをデプロイするか、顧客の既存の仮想ネットワークと統合するかを決定します。 | 事前に計画を行うことで、分離、セキュリティ、および顧客のその他のシステムとの統合に関する顧客の要件を満たすことができます。 |
| Azure リソース上のパブリック アクセスを既定で無効にします。 可能な場合はプライベート イングレスを優先します。 | 自分と顧客が保護する必要があるネットワーク リソースの範囲を減らします。 |
その他のリソース
マルチテナント機能は、SaaS ワークロードを設計するための主要なビジネス手法です。 以下の記事は、ネットワーク設計に関連する詳細情報を提供します。
- マルチテナント ソリューションでのネットワークのアーキテクチャに関するアプローチ
- テナント モデル
- ハブ アンド スポークのネットワーク トポロジ
- マルチテナント機能に関する Azure NAT Gateway の考慮事項
- テナント統合とデータ アクセスに関するアーキテクチャ上のアプローチ
次のステップ
Azure 上の SaaS ワークロードのデータ整合性とパフォーマンスに関するデータ プラットフォーム上の考慮事項について学習します。