編集

次の方法で共有

安全に管理された Web アプリケーション

Azure App Service
Azure Application Gateway
Azure SQL データベース
Azure VPN Gateway
Azure Web アプリケーション ファイアウォール

こ記事では、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 の併用。

アーキテクチャ

セキュリティで保護された ILB App Service Environment デプロイのためのシナリオ例のアーキテクチャを示す図。

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

データフロー

  1. まず HTTP/HTTPS 要求がアプリケーション ゲートウェイに到達します。
  2. 必要に応じて (図には示されていません)、Web アプリに対して Microsoft Entra 認証を有効にすることができます。 トラフィックが最初にアプリケーション ゲートウェイに到達すると、ユーザーはアプリケーションの認証を行うための資格情報を入力するよう求められます。
  3. ユーザーの要求が環境の内部ロード バランサー (ILB) を通過すると、トラフィックが経費 Web アプリにルーティングされます。
  4. その後、ユーザーは経費報告書の作成に進みます。
  5. 経費報告書作成の一環として、デプロイされた API アプリが呼び出されて、ユーザーの上司の名前とメール アドレスを取得します。
  6. 作成された経費報告書は Azure SQL Database に保存されます。
  7. 継続的なデプロイを容易にするために、コードは Azure DevOps インスタンスにチェックインされます。
  8. ビルド 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 Service Web Apps と API Apps は、Web アプリケーションと RESTful API をホストします。 これらのアプリと API は、自動スケーリング、カスタム ドメインなども (ただし専用レベルで) 提供する Isolated サービス プランでホストされています。
  • Azure Application Gateway は、レイヤー 7 で動作し、Web アプリケーションへのトラフィックを管理する Web トラフィック ロード バランサーです。 Web アプリをホストする Web サーバーからトラフィックを再び復号化するための余分なオーバーヘッドをなくす SSL オフロードが提供されます。
  • Web Application Firewall (WAF) は Application Gateway の機能です。 アプリケーション ゲートウェイで Web アプリケーション ファイアウォールを有効にすると、セキュリティがさらに強化されます。 Web アプリケーション ファイアウォールでは、Open Worldwide Application Security Project (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 プライベート ゾーンを使用することもできます。

可用性

スケーラビリティ

セキュリティ

回復性

このシナリオのデプロイ

このシナリオをデプロイするには、こちらの ステップ バイ ステップのチュートリアル を実行してください。このチュートリアルでは、各コンポーネントを手動でデプロイする方法を示しています。 このチュートリアルを実行するときには、v2 ではなく App Service Environment v3 を選択してください。 また、このチュートリアルでは、シンプルな Contoso 経費報告アプリケーションを実行する .NET サンプル アプリケーションも提供します。

価格

このシナリオの実行時のコストについて調べます。 すべてのサービスがコスト計算ツールで事前構成されています。 特定のユース ケースに応じた価格の変化を確認するには、予想されるトラフィックと一致するように該当する変数を変更します。

予測されるトラフィックの量に基づいて、次の 3 つのサンプル コスト プロファイルを用意しました。

  • Small: この価格例は、1 か月に数千人のユーザーにサービスを提供する最小運用レベルのインスタンスに必要なコンポーネントを表しています。 アプリでは標準の Web アプリの単一インスタンスが使用されており、自動スケーリングを有効にするにはこれで十分です。 その他の各コンポーネントは、最小限のコストでありながらサービスレベル アグリーメント (SLA) のサポートおよび運用レベルのワークロードを十分に処理できる容量が確保される、Basic レベルにスケーリングされています。
  • Medium: この価格例は、中規模サイズのデプロイに必要なコンポーネントを表しています。 1 か月間に約 100,000 人のユーザーを推定しています。 中程度の Standard レベルで予想されるトラフィックは、単一の App Service インスタンスで処理されます。 また、中レベルのコグニティブおよび検索サービスが計算ツールに追加されています。
  • Large: この価格例は、高スケールを想定したアプリケーションを表します。このアプリケーションでは、1 か月あたり数百万人のユーザーが数テラバイトのデータをやり取りします。 この使用レベルでは、Traffic Manager を介して複数のリージョンに展開された、ハイ パフォーマンスの Premium レベル Web アプリが必要です。 データは、ストレージ、データベース、CDN の各コンポーネントで構成され、そのすべてがテラバイト データ用に構成されています。

共同作成者

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

プリンシパル作成者:

  • Faisal Mustafa |シニア カスタマー エンジニア

次のステップ