次の方法で共有

安全に管理された 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 Application Firewall を使用して、インターネットからのアプリケーション アクセスを制限します。 この記事では、Azure DevOps を使用して、継続的インテグレーションと継続的デプロイ (CI/CD) と App Service Environment を統合する方法についても説明します。

銀行や保険などの業界では、プラットフォーム レベルとアプリケーション レベルのセキュリティの両方を顧客が大切にしているため、このソリューションがよく使用されます。 これらの概念を示すために、次のサンプル アプリケーションでは、ユーザーが経費明細書を送信できます。

アーキテクチャ

セキュリティで保護された内部ロード バランサーの 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 エージェントが含まれています。 このエージェントにより、ビルド VM は Web アプリ成果物をプルし、それらを使用して Web アプリを App Service Environment にデプロイできます。 ビルド VM は、App Service Environment と同じ仮想ネットワーク内のサブネットに存在します。

コンポーネント

  • App Service Environment には、アプリケーションを大規模に安全に実行するための、完全に分離された専用の環境が用意されています。 App Service Environment とそのワークロードはどちらも仮想ネットワークの背後に存在するため、セットアップによってセキュリティと分離の層が追加されます。 このシナリオでは、ILB App Service Environment を使用して、高スケールと分離のニーズを満たします。

  • このワークロードでは、 App Service Isolated 価格レベルが使用されます。 アプリケーションは、高速プロセッサとソリッド ステート ドライブ (SSD) ストレージを使用する Azure データセンター内のプライベート専用環境で実行され、最大スケールアウト機能を提供します。

  • App Service の Web Apps と API Apps の機能は、Web アプリケーションと RESTful API をホストします。 これらのアプリと API は Isolated サービス プランでホストされます。これにより、自動スケール、カスタム ドメイン、専用レベルのその他の機能も提供されます。

  • Application Gateway は、Web アプリケーションへのトラフィックを管理するレイヤー 7 Web トラフィック ロード バランサーです。 Secure Sockets Layer (SSL) オフロードが提供されます。これにより、アプリケーションをホストする Web サーバーからのトラフィックの暗号化を解除するオーバーヘッドが排除されます。

  • Web アプリケーション ファイアウォール は、セキュリティを強化する Application Gateway の機能です。 Web アプリケーション ファイアウォールでは、Open Worldwide Application Security Project (OWASP) ルールを使用して、クロスサイト スクリプティング、セッション ハイジャック、SQL インジェクションなどの攻撃から Web アプリケーションを保護します。

  • SQL Database には 、アプリケーションのデータが格納されます。 ほとんどのデータはリレーショナルであり、一部のデータはドキュメントと BLOB として格納されます。

  • Azure Virtual Network には、Azure のさまざまなネットワーク機能が用意されています。 仮想ネットワークをピアリングし、ExpressRoute またはサイト間仮想プライベート ネットワーク (VPN) を介してオンプレミスのデータセンターとの接続を確立できます。 このシナリオでは、仮想ネットワーク上の サービス エンドポイント で、データが Azure 仮想ネットワークと SQL Database インスタンスの間でのみ流れるようにすることができます。

  • Azure DevOps では、 スプリント中にチームが共同作業を行い、ビルドパイプラインとリリース パイプラインを作成するためのツールを提供することで、アジャイル開発がサポートされます。

  • Azure ビルド VM を使用すると、インストールされたエージェントはそれぞれのビルドをプルダウンし、Web アプリを環境にデプロイできます。

代替

App Service Environment は、Windows 上で通常の Web アプリを実行することも、この例のように、環境内にデプロイされた Linux コンテナーとして実行される Web アプリを実行することもできます。 このシナリオでは、App Service Environment を使用して、これらの単一インスタンスのコンテナー化されたアプリケーションをホストします。 ソリューションを設計するときは、次の代替手段を検討してください。

  • Azure Container Apps は、コンテナー化されたアプリケーションの実行中にインフラストラクチャのオーバーヘッドを削減し、コストを節約するサーバーレス プラットフォームです。 これにより、サーバー構成、コンテナー オーケストレーション、デプロイの詳細を管理する必要がなくなります。 Container Apps には、アプリケーションを安定してセキュリティで保護するために必要なすべての up-to-date サーバー リソースが用意されています。

  • Azure Kubernetes Service (AKS) は、オープンソース プロジェクトであり、通常はマイクロサービス ベースのアーキテクチャを使用する複雑なマルチコンテナー アプリケーションをホストするように設計されたオーケストレーション プラットフォームです。 AKS は、Kubernetes クラスターのプロビジョニングと構成を簡略化するマネージド Azure サービスです。 Kubernetes プラットフォームをサポートおよび維持するには、Kubernetes プラットフォームに関する重要な知識が必要です。そのため、少数の単一インスタンスのコンテナー化された Web アプリケーションをホストするのが最適なオプションではない可能性があります。

データ層には、次の代替手段を使用します。

  • Azure Cosmos DB は、ほとんどのデータが非リレーショナル形式の場合に適したオプションです。

考えられるユース ケース

次のユース ケースでは、このソリューションを検討してください。

  • 追加のセキュリティを必要とする Azure Web アプリを構築します。
  • 共有テナント App Service プランではなく、専用テナントを提供します。
  • 内部的に負荷分散された App Service Environment で Azure DevOps を使用します。

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

App Service Environment の既定のドメイン サフィックスのドメイン ネーム システム (DNS) 設定では、アプリケーションの到達可能性はそれらの名前に制限されません。 ILB App Service Environment のカスタム ドメイン サフィックス機能を使用すると、独自のドメイン サフィックスを使用して、App Service Environment でホストされているアプリケーションにアクセスできます。

カスタム ドメイン サフィックスは、App Service Environment で使用されるルート ドメインを定義します。 ILB App Service Environment の場合、既定のルート ドメインは appserviceenvironment.net。 ILB App Service Environment は顧客の仮想ネットワークの内部であるため、お客様は、仮想ネットワーク環境に合った既定のドメインに加えてルート ドメインを使用できます。 たとえば、Contoso Corporation は、解決可能で Contoso の仮想ネットワーク内でのみ到達可能であることを意図したアプリに対して、 internal.contoso.com の既定のルート ドメインを使用する場合があります。 この仮想ネットワーク内のアプリには、 APP-NAME.internal.contoso.comにアクセスすることでアクセスできます。

カスタム ドメイン サフィックスは、App Service Environment に適用されます。 この機能は、個々の App Service インスタンスのカスタム ドメイン バインドとは異なります。

カスタム ドメイン サフィックスに使用される証明書に、 *.scm.CUSTOM-DOMAINのサブジェクト代替名 (SAN) エントリが含まれている場合、ソース管理マネージャー (SCM) サイトは APP-NAME.scm.CUSTOM-DOMAINから到達可能になります。 SCM には、基本認証を使用してカスタム ドメイン経由でのみアクセスできます。 シングル サインオンは、既定のルート ドメインを使用する場合にのみ使用できます。

ILB App Service Environment で証明書を管理する場合は、次の要因を考慮してください。

  • 有効な SSL またはトランスポート層セキュリティ (TLS) 証明書を Azure キー コンテナーに格納します。PFX 形式。

  • 証明書が 20 KB 未満であることを確認します。

  • 選択したカスタム ドメイン名にワイルドカード証明書を使用します。

  • App Service Environment のシステム割り当てマネージド ID またはユーザー割り当てマネージド ID を構成します。 マネージド ID は、SSL または TLS 証明書が存在する Azure キー コンテナーに対して認証します。

  • App Service Environment は、キー コンテナーのローテーション後 24 時間以内に証明書の変更を適用することを想定しています。

Azure Key Vault へのネットワーク アクセス

  • キー コンテナーには、パブリックにアクセスすることも、App Service Environment がデプロイされているサブネットから到達可能なプライベート エンドポイントを介してアクセスすることもできます。

  • パブリック アクセスを使用する場合は、App Service Environment の送信 IP アドレスからのトラフィックのみを受け入れるように、キー コンテナーをセキュリティで保護できます。

  • App Service Environment は、キー コンテナーにアクセスするときに、プラットフォームの送信 IP アドレスをソース アドレスとして使用します。 この IP アドレスは、Azure portal の [IP アドレス] ページで確認できます。

DNS 構成

カスタム ドメイン サフィックスを使用して App Service Environment 内のアプリケーションにアクセスするには、独自の DNS サーバーを構成するか、カスタム ドメインの Azure プライベート DNS ゾーンで DNS を構成します。 詳細については、「 DNS の構成」を参照してください。

一意の既定のホスト名をセキュリティで保護する

セキュリティで保護された一意の既定のホスト名機能は、未解決の DNS エントリとサブドメインの引き継ぎからリソースを保護するための長期的なソリューションを提供します。 App Service リソースに対してこの機能を有効にした場合、組織外のユーザーは、同じ既定のホスト名を持つリソースを再作成できません。 この保護により、悪意のあるアクターが未解決の DNS エントリを悪用してサブドメインを引き継ぐのを防ぐことができます。 詳細については、「 一意の既定のホスト名をセキュリティで保護する」を参照してください。

考慮事項

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

確実

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

可用性

セキュリティ

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

  • 適切な App Service Web アプリケーション参照アーキテクチャのセキュリティに関する考慮事項を確認します。

  • 開発コストを削減しながら、開発者がより安全なソフトウェアを構築し、セキュリティ コンプライアンス要件に対処できるように、セキュリティ 開発ライフサイクル プロセスに従ってください。

  • Azure DDoS Protection とアプリケーション設計のベスト プラクティスを使用して、分散型サービス拒否 (DDoS) 攻撃に対する保護を強化します。 境界仮想ネットワークで DDoS Protection を有効にします。

コストの最適化

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

このシナリオの実行時のコストについて調べます。 次のサンプル コスト プロファイルは、予想されるトラフィックに基づいています。 すべてのサービスは、コスト計算ツールで事前に構成されています。

  • 小規模デプロイ: この価格の例は、毎月数千人のユーザーにサービスを提供する最小限の運用レベルのインスタンスのコンポーネントを表します。 このアプリは、分離された Web アプリの単一の小さなインスタンスを使用します。 追加の各コンポーネントは Basic レベルにスケーリングされ、コストを最小限に抑えながら、サービス レベル アグリーメント (SLA) のサポートと、運用レベルのワークロードを処理するための十分な容量が確保されます。

  • 中のデプロイ: この価格の例は、毎月約 100,000 人のユーザーにサービスを提供する中程度のサイズのデプロイのコンポーネントを表します。 中程度のサイズの単一の分離された App Service インスタンスがトラフィックを管理します。 追加されたワークロードをサポートするために、Application Gateway と SQL Database の容量が増加します。

  • 大規模なデプロイ: この価格の例は、毎月数百万人のユーザーにサービスを提供し、数テラバイトのデータを移動する大規模なアプリケーションのコンポーネントを表します。 このレベルの使用には、複数のリージョンにデプロイされ、Azure Traffic Manager によって前面に配置された、高パフォーマンスの分離層 Web アプリが必要です。 見積もりには、Traffic Manager と追加の Application Gateway インスタンスと Virtual Network インスタンスが含まれます。 追加されたワークロードをサポートするために、SQL Database の容量が増えます。

特定のユース ケースの価格を確認するには、予想されるトラフィックに合わせて適切な変数を変更します。

パフォーマンス効率

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

共同作成者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパル作成者:

  • Nicholas McCollum |プリンシパル カスタマー エンジニア

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ