NGINX Plus を使用した Microsoft Azure App Service でのアプリケーションのセキュリティ保護

クラウド コンピューティング、特に Platform as a Service (PaaS) と Container as a Service (CaaS) サービスの普及により、企業がビジネス アプリケーションを展開および運用する方法が変化しています。 クラウド アプリケーションを設計する際の最も重要な課題の 1 つは、セキュリティを損なうことなくコストと時間のかかる運用タスクを削減する、完全に管理されたクラウド サービスを選択することです。

このブログ記事では、 Microsoft Azure App Serviceでアプリケーションをホストし、 NGINX Plusを使用して保護し、インターネットからの攻撃を防ぐ方法について説明します。

Microsoft Azure App Service の概要

Microsoft Azure App Service は、図 1 に示すように、組織が基盤となるインフラストラクチャを管理することなく、Microsoft Azure に Web、API、モバイル アプリを展開できる、エンタープライズ グレードの完全管理型プラットフォームです。 Azure App Service は、次の主な機能を提供します。

• Web アプリを使用すると、さまざまな言語やフレームワーク (ASP.NET、Node.js、Java、PHP、Python) で Web アプリをデプロイして実行できます。 また、包括的なアプリケーション管理機能 (監視、ステージングから運用への切り替え、デプロイされたアプリケーションの削除など) を備えたインターネット インフォメーション サービス (IIS) を使用して、スケーラブルで信頼性の高い Web アプリケーションを管理します。 また、コンテナを使用して Linux 上で Web アプリケーションを実行するための Docker ランタイムも提供します。
• API アプリは、CORS (クロスオリジン リソース共有) サポートを備えた REST API をデプロイするためのツールを提供します。 Azure API アプリは、コードを変更することなく、Azure Active Directory、ソーシャル ネットワーク シングル サインオン (SSO)、または OAuth を使用して簡単にセキュリティ保護できます。
• モバイル アプリは、認証、プッシュ通知、ユーザー管理、クラウド ストレージなどの重要な機能をサポートするモバイル バックエンド サービスを迅速に展開する方法を提供します。

Azure App Service により、Microsoft はクラウド上で Web アプリケーションを実行するための機能豊富で高速な方法を提供します。 実際、開発者は ASP.NET、Java、Node.js、PHP、Python を使用してアプリケーションをローカルで開発し、Microsoft Visual Studio または Azure CLI を使用して簡単に Azure App Service にデプロイできます。DevOps チームは、Azure App Service の継続的デプロイ機能を利用して、複数の環境にアプリケーション リリースを迅速かつ確実にデプロイすることもできます。

Azure App Service 上のアプリケーションは、Azure にデプロイされた他のリソースにアクセスしたり、オンプレミスの企業リソースへの VPN 経由で接続を確立したりできます。

Azure App Service 環境について

基本的に、Azure App Service で作成されたアプリケーションはインターネットに直接公開され、 azurewebsites.netのサブドメインに割り当てられます。 セキュリティを強化するために、SSL ターミネーション、または OAuth2 や OpenID Connect (OIDC) などの認証および承認プロトコルを使用してアプリを保護することができます。 ただし、きめ細かな送信および受信のセキュリティ ルールを使用してネットワークをカスタマイズしたり、Web アプリケーション ファイアウォール (WAF) などのミドルウェアを適用して、インターネットからの悪意のある攻撃や悪用を防いだりすることはできません。

Azure App Service で機密性の高いアプリケーションを実行し、それを保護したい場合は、Azure App Service Environment (ASE) を使用できます。 ASE は、仮想ネットワークに展開され、単一の顧客のアプリケーション専用の分離された環境です。 したがって、受信および送信のアプリケーション ネットワーク トラフィックをより詳細に制御できるようになります。

ASE を使用すると、図 2 に示すように、Web、API、モバイル、または関数アプリを、より安全な環境内に非常に大規模にデプロイできます。

新しい ASE v2 の作成

ASE には 2 つのバージョンがあります。 ASE v1 および ASE v2。 この投稿では、ASE v2 について説明します。

新しい ASE v2 は、Azure Portal を使用して手動で作成することも、Azure Resource Manager を使用して自動的に作成することもできます。

新しい ASE を作成するときは、次の 2 つのデプロイメント タイプから選択する必要があります。

• 外部 ASE は、ASE でホストされるアプリケーションをパブリック IP アドレスを通じて公開します。
• ILB ASE は、 Azure Virtual Network 内でのみアクセス可能なプライベート IP アドレス上で ASE ホスト アプリケーションを公開します。 内部エンドポイントは、Azure では内部ロード バランサー (ILB) と呼ばれます。

次の例では、インターネットからのアクセスを防ぐために ILB ASE を選択しています。 したがって、ASE にデプロイされたアプリケーションには、同じネットワークで実行されている仮想マシン (VM) からのみアクセスできます。 次の 2 つのコマンドは、Azure Resource Manager と Azure CLI を使用して新しいILB ASE v2 をプロビジョニングします。

$ azure config mode arm $ azure group デプロイメント作成 my-resource-group my-deployment-name --template-uri https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/201-web-app-asev2-ilb-create/azuredeploy.json

パブリックアクセス可能な ASE 内のアプリへのアクセスのセキュリティ保護

一方、インターネットからアプリにアクセスできるようにする場合は、アプリケーションに保存されている機密情報を盗もうとする悪意のある攻撃者からアプリを保護する必要があります。

ASE のレイヤー 7 でアプリケーションを保護するには、主に次の 2 つの選択肢があります。

• Azure アプリケーション ゲートウェイ
• NGINX ModSecurity WAFモジュールを搭載した NGINX Plus

(WAF 機能を備えたカスタム アプリケーション配信コントローラー [ADC] を代用することもできますが、ここではその使用例については説明しません。)

ソリューションの選択は、セキュリティ制約によって異なります。 一方、Azure Application Gateway は、セキュリティ強化のためのターンキー ソリューションを提供するため、基盤となるインフラストラクチャを維持する必要がありません。 一方、NGINX Plus を VM に導入すると、セキュリティ ルールを微調整するための制御性と柔軟性が強化された強力なスタックが得られます。

ASE 内で作成されたアプリケーションの負荷分散とセキュリティ保護のために Azure Application Gateway と NGINX Plus のどちらを選択するかは、各ソリューションが提供する機能を十分に理解している必要があります。 Azure Application Gateway は単純なユースケースでは機能しますが、複雑なユースケースでは、NGINX Plus に標準で付属する多くの機能は提供されません。

次の表は、Azure Application Gateway と NGINX Plus の負荷分散とセキュリティ機能のサポートを比較したものです。 NGINX Plus の機能の詳細については、表の下に表示されます。

ご覧のとおり、NGINX Plus と Azure Application Gateway はどちらも、レイヤー 7 の負荷分散機能と WAF を備えた ADC として機能し、一般的な Web の脆弱性やエクスプロイトに対する強力な保護を実現します。

NGINX Plus は、Azure Application Gateway にはないいくつかの追加機能を提供します。

• URL の書き換えとリダイレクト – NGINX Plus を使用すると、リクエストの URL をバックエンド サーバーに渡す前に書き換えることができます。 つまり、クライアントにアドバタイズされる URL を変更することなく、ファイルの場所やリクエスト パスを変更できます。 リクエストをリダイレクトすることもできます。 たとえば、すべての HTTP リクエストを HTTPS サーバーにリダイレクトできます。
• 接続とレートの制限 – NGINX Plus インスタンスとの間のトラフィックを制御するために複数の制限を設定できます。 これには、受信接続数、受信リクエストのレート、バックエンド ノードへの接続、NGINX Plus からクライアントへのデータ転送レートの制限が含まれます。
• HTTP/2 および WebSocket のサポート – NGINX Plus は、アプリケーション層 (レイヤー 7) でHTTP/2およびWebSocket をサポートします。 Azure Application Gateway ではサポートされませんが、代わりに Azure Load Balancer が、TCP と UDP が動作するネットワーク層 (レイヤー 4) でそれらをサポートします。

セキュリティを強化するために、 Azure DDoS Protection をデプロイして、レイヤー 3 および 4での脅威を軽減し、Azure Application Gateway または NGINX Plus によって提供されるレイヤー 7 の脅威軽減機能を補完することができます。

NGINX Plus を Azure App Service と組み合わせて使用してアプリケーションを保護する

図 3 は、NGINX Plus と Azure App Service を組み合わせて、運用環境でビジネス アプリケーションを実行するための安全な環境を提供する方法を示しています。 このデプロイメント戦略では、負荷分散と WAF 機能に NGINX Plus を使用します。

このデプロイメントでは、次のコンポーネントが組み合わされます。

• Azure 仮想ネットワーク (VNet) – 組織専用の Azure クラウド内の仮想ネットワークを表します。 論理的な分離を提供し、Azure リソースが仮想ネットワーク内で安全に相互通信できるようにします。 ここでは、2 つのサブネットを定義しました。 内部 インターネットに直接公開されていないウェブアプリケーションの場合、 ワフ NGINX Plus とその基盤となるインフラストラクチャ向けです。

• Azure App Service 環境– このサンプル デプロイメントでは、2 つのサンプル Web アプリケーション ( Web App 1とWeb App 2 ) を使用して、NGINX Plus でさまざまな Web アプリケーションを保護し、負荷分散する方法を示します。 NGINX Plus では、個別のアップストリームブロックを構成することで、さまざまな Web アプリケーションにリクエストを分散し、ロケーションブロックを含む URI に基づいてコンテンツ ルーティングを実行します。 以下は、この目標を満たす最小限の NGINX Plus 構成を示しています (ここでは、すべてのリクエストが同じアップストリーム グループに送信されます)。

  アップストリーム バックエンド { サーバーASE-ILB の IP アドレス; } サーバー { 場所 / { proxy_set_header Host $host; proxy_pass http://backend; } }
  

• NGINX Plus – 複数の Web アプリケーション間で HTTP(S) 接続の負荷を分散します。 NGINX Plus を VM にデプロイすると、他の Azure サービスよりもインフラストラクチャをより細かく制御できるようになります。 たとえば、VM では、分離された仮想ネットワーク内で実行されるオペレーティング システム (Linux または Windows) を選択できます。 実際、Azure VM は、NGINX Plus がサポートするすべての Linux ディストリビューションで利用できます (明らかな理由により、Amazon Linux は除く)。
• Azure VM スケール セット– VM スケール セットは、同一の VM のセットをデプロイおよび管理するために使用できる Azure コンピューティング リソースです。VM のサイズを構成し、VM を適切な VNet に割り当てることができます。 スケール セット内で実行されるすべての VM は、VM インスタンス間の TCP 接続を提供する Azure Load Balancer によって負荷分散されます。 ここで、スケール セット内の各 VM は、Azure Marketplace から入手できる NGINX Plus イメージに基づいています。 スケール セットは、真の自動スケーリングを提供するように設計されています。

Azure では、アプリケーションの Azure リソースを論理的にグループ化する簡単な方法として、リソース グループもサポートされています。 リソース グループの使用はインフラストラクチャの設計とトポロジに影響を及ぼさないため、ここでは示しません。

NGINX Plus の高可用性と Azure VM スケール セットによる自動スケーリング

Azure VM スケール セットを使用すると、スケーリングをサポートする物理ハードウェアを購入して維持することなく、いつでもスケーリングできる仮想化のパワーが得られます。 ただし、VM の構成、パッチ適用、セキュリティ更新、VM 上で実行されるソフトウェアのインストールなどのタスクを実行して VM を保守する責任は依然としてあります。

図 4 に示すアーキテクチャでは、NGINX Plus インスタンスが Azure VM スケール セット内にアクティブ/アクティブの高可用性のためにデプロイされています。 アクティブ アクティブ設定は、すべての NGINX Plus VM が Azure Load Balancer によってルーティングされた受信要求を処理できるため、コスト効率の高い容量を提供できるため優れています。

Azure VM スケール セットを使用すると、平均 CPU 使用率に基づいて NGINX Plus インスタンスの自動スケーリングを簡単に設定することもできます。 この場合、NGINX Plus 設定ファイルを同期するように注意する必要があります。 この目的には、 NGINX Plus 管理者ガイドで説明されているように、NGINX Plus 構成共有機能を使用できます。

まとめ

クラウド アプリケーションに Azure App Service を使用し、Web アプリ、API、モバイル バックエンドの前に NGINX Plus を使用することで、これらのアプリケーションの負荷をグローバル規模で分散し、セキュリティを確保できます。 NGINX Plus を Azure App Service と組み合わせて使用することで、Web からのエクスプロイトや攻撃に対する高度な保護を備えた、完全に負荷分散されたインフラストラクチャを実現できます。 これにより、重要なアプリケーションを本番環境で安全に実行するための堅牢な設計が保証されます。

リソース

Web アプリの概要(Microsoft)
App Service 環境の概要(Microsoft)
Azure ポータルを使用して Web アプリケーション ファイアウォールを備えたアプリケーション ゲートウェイを作成する(Microsoft)
NGINX オープンソースと NGINX Plus (NGINX) の機能を比較する
HTTP ロードバランシング(NGINX)

ゲスト共著者の Cedric Derue 氏は、Altran のソリューション アーキテクト兼 Microsoft MVP です。 ゲスト共著者の Vincent Thavonekham は、VISEO の Microsoft 地域ディレクター兼 Azure MVP です。