次の方法で共有

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

Azure App Service
Azure Application Gateway
Azure SQL Database
Azure VPN Gateway
Azure Web Application Firewall

この記事では、 App Service Environment を使用したセキュリティで保護されたアプリケーションのデプロイの概要について説明します。 インターネットからのアプリケーション アクセスを制限するために、 Azure Application Gateway サービスと Azure Web アプリケーション ファイアウォール が使用されます。 この記事では、Azure DevOps を使用した App Service Environment の継続的な統合と継続的なデプロイ (CI/CD) に関するガイダンスも提供します。

このシナリオは、アプリケーション レベルのセキュリティに加えて、プラットフォーム レベルのセキュリティを顧客が意識している、銀行や保険などの業界でよくデプロイされます。 これらの概念を説明するために、ユーザーが経費報告書を送信できるアプリケーションを使用します。

考えられるユース ケース

次のユース ケースについて、このシナリオを検討してください。

  • 特別なセキュリティが必要な Azure Web アプリの構築。
  • 共有テナントの App Service プランではなく、専用のテナントの提供。
  • 内部負荷分散 (ILB) アプリケーション サービス環境で Azure DevOps を使用する。

アーキテクチャ

Secure ILB App Service Environment Deployment のサンプル シナリオ アーキテクチャを示す図。

このアーキテクチャの 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 は同じ仮想ネットワーク内のサブネットにデプロイされるため)。

コンポーネント

  • App Service Environment は、アプリケーションを高いスケールで安全に実行するための、完全に分離された専用の環境を提供します。 さらに、App Service Environment とその上で実行されるワークロードは仮想ネットワークの背後にあるため、追加のセキュリティ レイヤーと分離も提供されます。 高スケールと分離の要件により、ILB App Service Environment が選択されました。
  • このワークロードでは 分離された App Service 価格レベルが使用されるため、アプリケーションは、高速プロセッサ、ソリッド ステート ドライブ (SSD) ストレージを使用して Azure データセンター内のプライベート専用環境で実行され、Standard と比較してメモリとコアの比率が 2 倍になります。
  • Azure App Service Web アプリ と API アプリは 、Web アプリケーションと RESTful API をホストします。 これらのアプリと API は、自動スケーリング、カスタム ドメインなども (ただし専用レベルで) 提供する Isolated サービス プランでホストされています。
  • Azure Application Gateway は、レイヤー 7 で動作する Web トラフィック ロード バランサーであり、Web アプリケーションへのトラフィックを管理します。 Web アプリをホストする Web サーバーからトラフィックを再び復号化するための余分なオーバーヘッドをなくす SSL オフロードが提供されます。
  • Web アプリケーション ファイアウォール は、Application Gateway の機能です。 アプリケーション ゲートウェイで Web アプリケーション ファイアウォールを有効にすると、セキュリティがさらに強化されます。 Web アプリケーション ファイアウォールでは、Open Worldwide Application Security Project (OWASP) 規則を使用して、クロスサイト スクリプティング、セッション ハイジャック、SQL インジェクションなどの攻撃から Web アプリケーションが保護されます。
  • このアプリケーションのデータのほとんどはリレーショナル データであり、一部のデータはドキュメントや BLOB として使用されるため、Azure SQL Database が選択されました。
  • Azure Networking には Azure のさまざまなネットワーク機能が用意されており、ネットワークは Azure 内の他の仮想ネットワークとピアリングできます。 ExpressRoute またはサイト間によって、オンプレミスのデータセンターとの接続を確立することもできます。 この場合、Azure 仮想ネットワークと SQL Database インスタンスの間でのみデータが流れるように、仮想ネットワーク上で サービス エンドポイント が有効になります。
  • Azure DevOps は、スプリント中のチームの共同作業、アジャイル開発をサポートする機能の使用、ビルドパイプラインとリリース パイプラインの作成を支援するために使用されます。
  • インストールされたエージェントがそれぞれのビルドをプルダウンし、Web アプリを環境にデプロイできるように、Azure ビルド VM が作成されました。

代替

App Service Environment では、Windows 上で通常の Web アプリを実行できます。または、この例のように、環境内にデプロイされた、それぞれが Linux コンテナーとして実行される Web アプリを実行できます。 App Service Environment は、こうしたシングル インスタンスのコンテナー化アプリケーションをホストするために選択されました。 代替手段も存在します。ソリューションを設計するときは下に挙げる事項を考慮してください。

  • Azure Service Fabric: 環境が主に Windows ベースであり、ワークロードが主に .NET Framework ベースであり、.NET Core への再設計を検討していない場合は、Service Fabric を使用して Windows Server コンテナーをサポートおよびデプロイします。 さらに、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 データ、シンプルなテーブル ストレージなど、他のデータ モデルを実行するためのプラットフォームを提供します。

TLS と DNS の設計上の決定に対処する

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 証明書が機能するようにします。 ILB App Service Environment を内部で発行された SSL 証明書と連携させる方法と、信頼されたルート ストアに内部 CA を読み込む方法を検討するもう 1 つの ソリューション 。

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 プライベート ゾーンを使用することもできます。

考慮事項

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 Well-Architected Framework」を参照してください。

確実

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の 設計レビュー チェックリスト」を参照してください。

可用性

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティの 設計レビューチェックリスト」を参照してください。

  • 適切な App Service Web アプリケーション参照アーキテクチャのセキュリティに関する考慮事項を確認します。
  • 開発コストを削減しながら、開発者がより安全なソフトウェアを構築し、セキュリティ コンプライアンス要件に対処できるように、安全な開発 ライフサイクル プロセスに従ってください。
  • Azure PCI DSS コンプライアンスのブループリント アーキテクチャを確認します。
  • Azure DDoS Protection 、アプリケーション設計のベスト プラクティスと組み合わせることで、DDoS 攻撃に対する防御を強化するための強化された DDoS 軽減機能が提供されます。 任意の境界仮想ネットワークで Azure DDoS Protection を有効にする必要があります。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「 コストの最適化」のデザイン レビュー チェックリストを参照してください。

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

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

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

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、 パフォーマンス効率のデザイン レビュー チェックリストを参照してください。

共同作成者

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

プリンシパル作成者:

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

次のステップ