こ記事では、Azure App Service Environment を使用した、セキュリティで保護されたアプリケーションのデプロイの概要を説明します。 インターネットからのアプリケーション アクセスを制限するために、Azure Application Gateway サービスと Azure Web Application Firewall を使用します。 この記事では、Azure DevOps を使用した App Service Environment の継続的な統合と継続的なデプロイ (CI/CD) に関するガイダンスも提供します。
このシナリオは、アプリケーション レベルのセキュリティに加えて、プラットフォーム レベルのセキュリティを顧客が意識している、銀行や保険などの業界でよくデプロイされます。 これらの概念を説明するために、ユーザーが経費報告書を送信できるアプリケーションを使用します。
考えられるユース ケース
次のユース ケースについて、このシナリオを検討してください。
- 特別なセキュリティが必要な Azure Web アプリの構築。
- 共有テナントの App Service プランではなく、専用のテナントの提供。
- 内部負荷分散型 (ILB) Application Service Environmen と Azure DevOps の併用。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
データフロー
- まず HTTP/HTTPS 要求が Application Gateway に到達します。
- 必要に応じて (図には示されていません)、Web アプリに対して Microsoft Entra 認証を有効にすることができます。 トラフィックが最初に Application Gateway に到達すると、ユーザーはアプリケーションの認証を行うための資格情報を入力するよう求められます。
- ユーザーの要求が環境の内部ロード バランサー (ILB) を通過すると、トラフィックが経費 Web アプリにルーティングされます。
- その後、ユーザーは経費報告書の作成に進みます。
- 経費報告書作成の一環として、デプロイされた API アプリが呼び出されて、ユーザーの上司の名前とメール アドレスを取得します。
- 作成された経費報告書は Azure SQL Database に保存されます。
- 継続的なデプロイを容易にするために、コードは Azure DevOps インスタンスにチェックインされます。
- ビルド VM には Azure DevOps Agent がインストールされているため、ビルド VM は App Service Environment にデプロイする Web アプリ用のビットをプルできます (ビルド VM は同じ仮想ネットワーク内のサブネットにデプロイされるため)。
Components
- App Service Environment では、高スケールで安全にアプリケーションを実行するための、完全に分離された専用の環境が提供されます。 さらに、App Service Environment とその上で実行されるワークロードは仮想ネットワークの背後にあるため、追加のセキュリティ レイヤーと分離も提供されます。 高スケールと分離の要件により、ILB App Service Environment が選択されました。
- このワークロードでは分離型の App Service 価格レベルが使用されているため、アプリケーションは Azure データセンターのプライベートな専用環境で、より高速なプロセッサ、SSD ストレージ、および Standard と比べて 2 倍のメモリ対コア比を使用して実行されます。
- Azure App Services の Web アプリと API アプリは、Web アプリケーションと RESTful API をホストします。 これらのアプリと API は、自動スケーリング、カスタム ドメインなども (ただし専用レベルで) 提供する Isolated サービス プランでホストされています。
- Azure Application Gateway は、レイヤー 7 で動作し、Web アプリケーションへのトラフィックを管理する Web トラフィック ロード バランサーです。 Web アプリをホストする Web サーバーからトラフィックを再び復号化するための余分なオーバーヘッドをなくす SSL オフロードが提供されます。
- Web アプリケーション ファイアウォール (WAF) は Application Gateway の機能です。 Application Gateway で WAF を有効にすると、セキュリティが強化されます。 WAF では、OWASP 規則を使用して、クロスサイト スクリプティング、セッション ハイジャック、SQL インジェクションなどの攻撃から Web アプリケーションが保護されます。
- Azure SQL Database が選択された理由は、このアプリケーションのデータの大部分がリレーショナル データであり、一部のデータがドキュメントおよび BLOB であることです。
- Azure ネットワークは、Azure の各種ネットワーキング機能を提供します。このネットワークは、Azure の別の仮想ネットワークとピアリングできます。 ExpressRoute またはサイト間によって、オンプレミスのデータセンターとの接続を確立することもできます。 この場合、Azure 仮想ネットワークと SQL Database インスタンスの間だけでデータが流れることを保証するために、仮想ネットワーク上でサービス エンドポイントが有効になります。
- Azure DevOps は、アジャイル開発をサポートする機能を使用して、スプリント中のチームの共同作業を支援し、ビルドとリリースのパイプラインを作成するために使用されます。
- Azure ビルド VM は、インストールされたエージェントがそれぞれのビルドをプル ダウンして、環境に Web アプリをデプロイできるようにするために作成されました。
代替
App Service Environment では、Windows 上で通常の Web アプリを実行できます。または、この例のように、環境内にデプロイされた、それぞれが Linux コンテナーとして実行される Web アプリを実行できます。 App Service Environment は、こうしたシングル インスタンスのコンテナー化アプリケーションをホストするために選択されました。 代替手段も存在します。ソリューションを設計するときは下に挙げる事項を考慮してください。
- Azure Service Fabric: 環境の大部分が Windows ベースであり、ワークロードが主に .NET Framework ベースであり、.NET Core への再設計をまだ検討していない場合は、Windows Server コンテナーをサポートおよびデプロイするために Service Fabric を使用します。 さらに、Service Fabric では C# または Java プログラミングの API がサポートされており、ネイティブ マイクロサービスの開発のために、Windows または Linux にクラスターをプロビジョニングできます。
- Azure Kubernetes Service (AKS) はオープンソース プロジェクトであり、通常はマイクロサービス ベースのアーキテクチャを使用する複雑なマルチコンテナー アプリケーションをホストするのにいっそう適しているオーケストレーション プラットフォームです。 AKS はマネージド Azure サービスであり、Kubernetes クラスターのプロビジョニングと構成の複雑さが抽象化されます。 ただし、Kubernetes プラットフォームのサポートと保守には、このプラットフォームに関する相当の知識が必要になるため、少数のシングル インスタンスのコンテナー化 Web アプリケーションをホストすることは最善の選択肢ではない場合があります。
データ層の他のオプションを次に示します。
- Azure Cosmos DB: データのほとんどが非リレーショナル形式である場合、Azure Cosmos DB は適切な代替手段です。 このサービスは、MongoDB、Cassandra、Graph データ、シンプルなテーブル ストレージなど、他のデータ モデルを実行するためのプラットフォームを提供します。
考慮事項
ILB App Service Environment で証明書を扱うときには、いくつかの考慮事項があります。 証明書が最終的に格納されるサーバーによって生成される証明書署名要求を必要としない、信頼されたルートにチェーンされた証明書を生成する必要があります。 たとえば、インターネット インフォメーション サービス (IIS) の場合は、最初の手順で IIS サーバーから CSR を生成し、それを SSL 証明書発行機関に送信します。
App Service Environment の内部ロード バランサー (ILB) から CSR を発行することはできません。 この制限を処理する方法として、ワイルドカード プロシージャを使用します。
ワイルドカード プロシージャを使用すると、DNS 名の所有権の証明を CSR の代わりに使用できます。 DNS 名前空間を所有している場合は、特別な DNS TXT レコードを入力できます。ワイルドカード プロシージャは、このレコードの存在をチェックし、見つかった場合は、正しいレコードを所持しているため DNS サーバーの所有者であると認識します。 その情報に基づいて、信頼されたルートにサインアップされた証明書が発行されるので、それを ILB にアップロードできます。 信頼されたルート SSL 証明書が ILB にあるので、Web アプリ上の個々の証明書ストアについては何もする必要はありません。
ILB App Service Environment で実行中のサービス間で安全な呼び出しを行う場合は、自己署名または内部発行の SSL 証明書が機能するようにします。 内部的に発行された SSL 証明書が ILB App Service Environment で機能するようにする方法と、信頼されたルート ストアに内部 CA を読み込む方法については、別の考慮対象のソリューションです。
App Service Environment のプロビジョニング中に、環境のドメイン名を選択するときは次の制限事項について考慮してください。 ドメイン名は、次の名前にはできません。
- net
- azurewebsites.net
- p.azurewebsites.net
- nameofthease.p.azurewebsites.net
さらに、アプリに使用されるカスタム ドメイン名と、ILB App Service Environment によって使用されるドメイン名を重複させることはできません。 ドメイン名が contoso.com である ILB App Service Environment では、次のようなカスタム ドメイン名はアプリに使用できません。
- www.contoso.com
- abcd.def.contoso.com
- abcd.contoso.com
ILB App Service Environment のドメインには、このようなカスタム ドメイン名と競合しないものを選択します。 この例では、環境のドメインに contoso-internal.com などを使用できます。これは、末尾が .contoso.com のカスタム ドメイン名と競合しないためです。
もう 1 つの考慮事項は DNS です。 App Service Environment 内のアプリケーションが相互に通信できるようにするには、たとえば、Web アプリケーションが API と通信するには、環境を保持する仮想ネットワーク用に DNS を構成する必要があります。 独自の DNS を用意することも、Azure DNS プライベート ゾーンを使用することもできます。
可用性
- クラウド アプリケーションを構築する際には、可用性のために標準的な設計パターンを適用することを検討してください。
- 適切な App Service Web アプリケーションのリファレンス アーキテクチャで可用性に関する考慮事項を確認します。
- その他の可用性に関する考慮事項については、Azure アーキテクチャ センターの可用性のチェックリストを参照してください。
スケーラビリティ
- App Service Environment におけるスケールのしくみについて説明します。
- クラウド アプリの自動スケーリングのベスト プラクティスを確認します。
- クラウド アプリケーションを構築するときは、スケーラビリティのための標準的な設計パターンに注意してください。
- 適切な App Service Web アプリケーションのリファレンス アーキテクチャでスケーラビリティに関する考慮事項を確認します。
- その他のスケーラビリティに関する記事については、Azure アーキテクチャ センターの「パフォーマンス効率のチェックリスト」を参照してください。
セキュリティ
- セキュリティの重要な要素の概要について確認します。
- 適切な App Service Web アプリケーションのリファレンス アーキテクチャでセキュリティに関する考慮事項を確認します。
- セキュリティで保護された開発ライフサイクル プロセスに従って、開発コストを削減しながら、開発者がより安全なソフトウェアを構築し、セキュリティ コンプライアンス要件に対応できるようにします。
- Azure PCI DSS コンプライアンスを実現するためのブループリント アーキテクチャを確認してください。
- Azure DDoS Protection では、アプリケーションの設計に関するベスト プラクティスと組み合わせることにより、DDoS 攻撃からの保護を向上させるための強化された DDoS 軽減機能が提供されます。 すべての境界仮想ネットワークで Azure DDOS Protection を有効にする必要があります。
回復性
- 回復性とスケーラビリティの向上のために、App Service Environment による Geo 分散スケールの使用を検討してください。
- 回復性のための標準的な設計パターンを確認し、必要に応じて、これらを実装することを検討します。
- Azure アーキテクチャ センターでは、複数のApp Service に関する推奨プラクティスを確認できます。
- データ層にはアクティブ geo レプリケーションを、イメージおよびキューには geo 冗長ストレージを使用することを検討します。
- 回復性の詳細については、Azure アーキテクチャ センターの関連記事を参照してください。
このシナリオのデプロイ
このシナリオをデプロイするには、こちらのステップ バイ ステップのチュートリアルを実行してください。このチュートリアルでは、各コンポーネントを手動でデプロイする方法を示しています。 このチュートリアルを実行するときには、v2 ではなく App Service Environment v3 を選択してください。 また、このチュートリアルでは、シンプルな Contoso 経費報告アプリケーションを実行する .NET サンプル アプリケーションも提供します。
価格
このシナリオの実行時のコストについて調べます。 すべてのサービスがコスト計算ツールで事前構成されています。 特定のユース ケースに応じた価格の変化を確認するには、予想されるトラフィックと一致するように該当する変数を変更します。
予測されるトラフィックの量に基づいて、次の 3 つのサンプル コスト プロファイルを用意しました。
- Small: この価格例は、1 か月に数千人のユーザーにサービスを提供する最小運用レベルのインスタンスに必要なコンポーネントを表しています。 アプリでは標準の Web アプリの単一インスタンスが使用されており、自動スケーリングを有効にするにはこれで十分です。 その他の各コンポーネントは、最小限のコストでありながら SLA のサポートおよび運用レベルのワークロードを十分に処理できる容量が確保される、標準サービス レベルにスケーリングされています。
- Medium: この価格例は、中規模サイズのデプロイに必要なコンポーネントを表しています。 1 か月間に約 100,000 人のユーザーを推定しています。 予想されるトラフィックは、中程度の Standard レベルによって単一アプリ サービス インスタンスで処理されます。 また、中レベルのコグニティブおよび検索サービスが計算ツールに追加されています。
- Large: この価格例は、高スケールを想定したアプリケーションを表します。このアプリケーションでは、1 か月あたり数百万人のユーザーが数テラバイトのデータをやり取りします。 この使用のレベルでは、トラフィック マネージャーが前面にある複数のリージョンにデプロイされたハイ パフォーマンスの Premium レベル Web アプリが必要です。 データは、ストレージ、データベース、CDN の各コンポーネントで構成され、そのすべてがテラバイト データ用に構成されています。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Faisal Mustafa |シニア カスタマー エンジニア
次のステップ
- ステップバイステップのデプロイ チュートリアル
- ILB App Service Environment を Azure Application Gateway と統合する
- Web アプリを Azure Application Gateway と統合する
- App Service Environment を使用した geo 分散スケール