Azure Virtual Network Manager セキュリティ管理規則の機能と使いどころ
はじめに
1年ほどプレビューだったと思うのですが、下記の機能がGAされました。
Azure Virtual Network Manager セキュリティ管理規則が 30 リージョンで一般提供開始
NSG以外のネットワーク制限機能なのですが、NSGを含めてどこでどう制限を入れていくか、整理しておかないと使い所を間違えそうです。ということで、機能を確認しつつ使い道を考えてみたいと思います。
機能の前提知識
NSG
機能の概要
NSGはFirewallのような機能で、通信の接続元や先、プロトコル（ポート）ごとに許可・不許可を定義することができます。
適用対象
サブネットとNICにNSGを設定することができます。両方に割り当てたり、片方のみに割り当てたりすることも可能です。
制御の効き方
「Firewall」というとネットワークの境目のところで制御が効くようなイメージを持ってしまうので、誤解してしまいそうなのですが、ネットワークを跨がなくても効果があります。
以下のような構成を考えてみてください。
あるVNetの中に、サブネットが2つ。
それぞれVMが2台／1台含まれていて、
各NICやサブネットにNSGが適用されています。
この条件で、各VM間の通信に掛かるNSGの制御を考えます。
VM1→VM2の通信
サブネット内通信なので、サブネットに設定されたNSG-Aは効果がなさそうですが、実際には以下のルールが全て効きます。一度サブネットから外に出て、Azureの管理ネットワーク経由で、またサブネットに入ってくるようなイメージです。
- NSG-1のアウトバウンド
- NSG-Aのアウトバウンド
- NSG-Aのインバウンド
- NSG-2のインバウンド
この4つのルールで全てallowと判定されたときに、通信可能です。
NSG-Aは、インとアウト両方のルールが判定されることがかなり意外な感じです。
VM1→VM3の通信
サブネット間通信は、普通のイメージ通りだと思います。
- NSG-1のアウトバウンド
- NSG-Aのアウトバウンド
- NSG-Bのインバウンド
- NSG-3のインバウンド
この4つのルールで全てallowと判定されたときに、通信可能です。
TIPS
NSGで通信をallow/denyすると、NSGフローログにその記録が残されますが、そのログは最後に通信のallow/denyを判定したNSGに対してログが記録されます。
では、先ほどのVM１→VM３を例にとると、どの順番でNSGルールが判定されていくのでしょうか。
何となく先ほど記載した順番（NSG-1のアウトバウンド→NSG-Aのアウトバウンド→・・・→NSG2のインバウンド）で判定されそうですが、実はこれは確定ではありません。
以前、思ったNSGにてログが出なかったのでサポートに問い合わせたところ、実はこの判定は基本的には「サブネットのNSG」→「NICのNSG」という順番で処理されるものの、NSGを設定したデプロイ順で不定となるそうです。（5年ほど前の情報ですが…）
いずれにせよ、どこかのNSGでブロックされると通信不可、ということになりますので、同じブロックルールを複数の箇所に設定する多重防御（１ミスで通信が空いてしまうことを避ける）のと、構成管理のしやすさ（１要件は１箇所にしか設定しない）のバランスをとることが大事です。
VNet Manager セキュリティ管理規則
使い方
この辺りはドキュメントに書かれていることなのでサラリといきます。
「ネットワーク マネージャー」のデプロイ
機能「セキュリティ管理」を有効にして「ネットワーク マネージャー」をデプロイします。
※スコープには、サブスクリプションや管理グループを指定することができます。
ネットワークグループ
同じ設定を割り当てるVNetの集合である「グループ」を作成します。
このグループのメンバーとなる「VNet」は手動で追加することもできますし、Azure Policyを使って、特定の条件に一致する「VNet」を自動的に追加することもできます。
セキュリティ管理規則
構成＞セキュリティ管理規則、からルールを作成します。
設定例として記載したのは、分かりやすく「SSHの拒否」ルールです。
一般的に、インターネットから入ってくる「SSH」を許可する必要はなく、Bastion経由や内部ネットワーク・Express Route経由のオンプレミスなどからのみ許可すれば十分ですので、こういったルールを設定するパターンが考えられます。
ルールに記載する内容としては、NSGと一緒ですね。
セキュリティ管理規則のデプロイ
「ネットワークマネージャー」の「デプロイ」機能から、上記で作成したルールをリージョン指定してデプロイします。これを忘れると意味がないので気を付けましょう。。
適用対象
上の使い方に書いた通り、Virtual Networks、すなわち複数のVNetに共通するルールを定義していくことになります。NSGはサブネットやNIC単位で設定したところ、マルっと共通の設定を入れられるようになるので、組織全体で当たり前のルールを全体に適用する…といったことが容易になります。
制御の効き方
セキュリティ管理規則では、下記の3つのルールを記載することができます。（allow/denyだけのNSGよりも設定が増えます）
- 常に許可
- 拒否
- 許可
それぞれ効果は下記の通りです。大前提として優先順位が上位になるモノから評価されていきます。
常に許可
このルールに合致した場合、他のセキュリティ規則やNSGのルール等による評価が行われることなく、ターゲットへの通信が成功します。
拒否
このルールに合致した場合、他のセキュリティ規則やNSGのルール等による評価が行われることがなく、ターゲットへの通信が失敗します。
許可
このルールに合致した場合、NSGによるルール評価が行われます。通信が成功するかどうかは、NSG次第です。
この3ルールによる効果を図示すると下記のようになります。（公式ドキュメントの絵がちょっと難しかったので…）
なお、このような規則で制御がかかるため、先ほどの「設定例」で記載したSSH拒否ルールのみを作成すると、SSHでの通信が一切NGになってしまいますね。ちゃんと許可する範囲を、優先ルール上位でAllowルールで設定しましょう。
使いどころを考える
さて、ここまで書いてきた機能を使って、どのように「セキュリティ管理規則」を使うのが良いでしょうか。
これまで、「危険なNSGルール※」はAzureポリシーを使うなどして、環境内部の一律チェックを行うことが一般的でした。しかしセキュリティ管理規則を使うと、環境全体に対して一律のルールを強制することができます。
※インターネット（any）からの接続を許している、SSHやRDPなどの管理通信の許可ルール
ということで私の考える「セキュリティ管理規則の使いどころ」＝「NSGとの使い分け」は以下の通りです。
セキュリティ管理規則の使いどころ
組織全体で守りたいルール、いわゆるクラウド利用上のガードレールに相当するような「deny」となる通信や、あるいは監視ツールや社内共通基盤との「allways allow」設定が使いどころかと思います。
その他、各システムに通信設定を委ねる部分を「allow」にしておくことを忘れないようにしないといけないですね。
また、セキュリティ管理規則（VNet Manager）を操作する権限は、全体の管理を行う担当のみが握っておくことが肝心です。じゃないと、各システム担当が操作できちゃうことになりますからね。
NSG（サブネット）の使いどころ
これまで通り、「システム」で共通となる通信許可設定を入れていくことになると思います。なので基本的に今までの使い方と共通だと思いますが、全NSGの中に共通で書いていたような要件を「セキュリティ管理規則」にまとめられるようになりましたね…ということが最大のアップデートかと思います。
共通基盤であるXXXXとの通信を許可する…といったルールにおいて、その共通基盤の更改に伴って全NSGの更新が必要になりました。なんてことがざらにありましたので。
NSG（NIC）の使いどころ
基本的に「使わないべき」というのが私の考えです。
そもそもの設計思想として、「あるシステムの共通機能を持ったものがサブネット内にまとまっている」＝「共通のNSGやFW、LBなどの配下にできる」というのが基本だと思います。ですので、わざわざNIC単位で制御しないといけない…というのはごく一部の例外であるべきだ、という考え方です。
NIC単位でNSGを適用していくと管理対象がどんどん増え、テスト量や更新時の考慮漏れなど障害の原因になっていきます。NICにNSGを適用する前に、サブネット構成やサーバーの役割を見直した方が良いと思います。
おわりに
今回は「セキュリティの管理規則」の使い方について確認し、使いどころを考えて見ました。
特に難しい機能ではなく、積極的に使っていく機能だと思いますが、現時点では西日本リージョンがプレビューのようですね。
SLAが無いということはかけたつもりの制御が効かず通信がツーツーになってしまう可能性もあるわけで、本番サービスとして使いましょうと言える段階にはないわけですが、東日本はしっかりGAされていますので使いどころを絞って使っていきましょう！
Discussion