App Service 環境でネットワークセキュリティグループ (NSG) を利用する際の注意点
こんにちは
Azure CIE サポートの村山です。
今回は、最近様々なサービスの裏側で利用され始めている App Service Environment (以下 ASE) にてネットワークセキュリティ機能を利用する際の注意点についてご紹介します。
ASE は普段他社様と環境を共有している通常の App Service とは異なり、お客様専用のApp Service の環境を作成することができます。
加えて、ASE はご利用者様の仮想ネットワーク上の、サブネット内にデプロイするため、仮想ネットワークのセキュリティ機能を利用して受信と送信のネットワークを制御することも可能です。
また、内部ロードバランサーを含む ASE を利用することで、仮想ネットワーク内からプライベート接続を行うこともできるので、セキュリティ要件が厳しいシステムを構築する際に利用されることが度々ございます。
下記では、このネットワークのセキュリティ機能をご利用の際ので注意点について説明します。
2017/10/31 時点
現在では、ASE を新規作成すると、NSG が一緒に作成されます。
このため、手作業で全部作る必要がなくなり、より便利になっています。
ASE でネットワークのセキュリティ機能を利用する
ASE では、ASE リソースがデプロイされた仮想ネットワークに対し、ネットワークセキュリティグループ (以下 NSG) をバインドすることで、サブネット内にデプロイされた ASE のインスタンスに対して、受信と送信トラフィックの制御を行うことが可能です。
NSG については、以下のドキュメントに詳細が記載されています。
ネットワーク セキュリティ グループを使用したネットワーク トラフィック フローの制御
/ja-jp/azure/virtual-network/virtual-networks-nsg
NSG を作成後、Azure ポータルでは下記のような画面が表示され、受信/送信セキュリティ規則に、許可/拒否したいルールを利用者が追加します。
そして、作成した NSG を、ASE リソースがデプロイされた仮想ネットワークにバインドすると、NSG 内で設定された規則にもとづいて、ASE のインスタンスに対する通信が、許可・ブロックされます。
図1: ネットワークセキュリティグループの画面
ASE で NSG を設定する際の注意点
NSG を利用して不要なポートへの通信制御が可能ですが、その前提として、ASE が正常に動作するためにあらかじめ必要な通信を許可しておく必要があります。
これは、リソースの正常性確認 (ヘルスチェック) などを目的として、ASE が Azure データ センター、および ASE を構成する各インスタンス間で、定期的な通信を行っているためです。
下記ドキュメントにてそれぞれ詳細がございます。
App Service 環境への受信トラフィックを制御する方法
/ja-jp/azure/app-service-web/app-service-app-service-environment-control-inbound-traffic
ExpressRoute を使用した App Service 環境のネットワーク構成の詳細
/ja-jp/azure/app-service-web/app-service-app-service-environment-network-configuration-expressroute#required-network-connectivity
※ Express Route の記載がありますが、Express Route を利用しない場合でも同様です。
しばしば、システム構築上のセキュリティ要件から、上記のドキュメント内に記載された必要な通信以外の受信/送信トラフィックを可能な限り遮断したいとご要望いただくことがあります。
その要件を満たすために、例えば下記の画像のように必要なポート (454/455 ポート) 以外の既定の規則をすべて拒否するといったルールを設定してしまい、ASE が正常に動作をしなくなってしまったというお問い合わせを頂戴します。
※ NSG では、優先度の数値が小さい順にルールが実行されますので、高優先度のルールは数値が低くなるよう設定します。
図2: 過度に強力なセキュリティ規則を設定した場合
これは、既定の受信セキュリティ規則を拒否したために、ASE インスタンス間、また Azure データセンターからの正常性確認のための通信が途絶えてしまうことが原因です。
上記のドキュメントに明記はされておりませんが、記載されているポート番号以外にも、ASE が正常に動作するためには、併せて以下の 2 つの通信を許可しておく必要があります。
・ サブネット内のインバウンド・アウトバウンドの通信
・ Azure Load Balancer からのインバウンド通信
そのため、上記の “Deny_all” のルールを取り除く、もしくはそのルールより前に、サブネット内の通信および Azure Load Balancer からの通信を許可するルールを追加することで、ASE が正常に動作します。
例えば、"Deny_all" を利用して既定の規則を禁止するようなセキュリティ規則を追加する場合、受信セキュリティ規則を以下のように設定することで、ASE が正常に動作します。
※ あくまで例となりますので、送信セキュリティ規則も含め、ご要件に合わせて変更していただくようお願いします。
図3: NSG の設定例
ご参考までに、以下でそれぞれの通信の役割をご説明します。
サブネット内のインバウンド・アウトバウンドの通信の許可
ASE は、サブネット内でデプロイされたインスタンス間で通信を行っております。このため、ASE のインスタンス間の通信を許可する必要があります。
例として、サブネット内の通信を許可する設定例は下記画像の通りとなります。ご要件に合わせてこれらの規則を現在ご利用の NSG に追加してください。
※ 192.168.250.0/24 は手元の環境の ASE がデプロイされたサブネットのアドレス空間です。
Azure Load Balancer からのインバウンド通信の許可
Azure Load Balancer からの通信を遮断すると、Azure 基盤側で行っておりますサービスの正常性チェックや PaaS インスタンスのハートビートが行われず、ASE が正常に動作しなくなります。
IP アドレス 168.63.129.16 について
https://blogs.technet.microsoft.com/jpaztech/2016/04/01/about-168-63-129-16/
このため、ASE が正常に動作するためには、Azure Load Balancer からのインバウンド通信を許可する必要があります。
下記の資料では、NSG の詳細が説明されておりますので、ご利用をご検討のお客様はこちらの資料もご確認ください。
ネットワーク セキュリティ グループを使用したネットワーク トラフィック フローの制御
/ja-jp/azure/virtual-network/virtual-networks-nsg
今回は、ASE でネットワークセキュリティグループを利用する際の注意点に関してご紹介しましたが、いかがでしょうか。
お客様のセキュリティ要件によっては実は ASE があまり適していない場合も考えられますので、検証やご検討を十分行ってからご利用ください。
それでは、また！