はじめに
Azureを運用する際に「NSG(Network Security Group)」を設定することがよくあります。NSGとはAzureの仮想ネットワーク上のファイアウォールのようなもので、仮想ネットワークのサブネットや仮想マシンのNICに適用することができます。NSGは、送信元IP/ポート、宛先IP/ポート、プロトコルによってその通信の許可/拒否を定義することができます。みなさんは通信要件に合わせてこのNSGを設定していることでしょう。
そして、Azure上のシステムを運用していると、時々「Azure上の業務システムにアクセス出来なくなった」みたいな問い合わせを受けることがあります。複雑なネットワークを構成している場合、被疑部位を特定するのに苦労しますが、調査方法として、どこからどこへの通信が来ているのか確認するためにpingを打ったりアクセスログを調査することがありますね。
その中で欠かせないのが「NSGフローログ」です。今回はこの「NSGフローログ」について詳細を解説したいと思います。
NSGフローログとは
名前の通りですが、NSGフローログはNSGを通るトラフィックに関する情報を記録しているログです。先述した様なネットワーク関連の障害調査を行う際に、送信元から通信が来ているか？実はNSGルールでDropされていたりしないか？ということをこのログから確認することができます。NSGフローログの詳細や設定方法についてはMSサイトに詳しく載っていますのでここでは割愛いたします。
さて、実際にNSGフローログを見たことある方はその出力の仕方に違和感を覚えたことがあると思います。例えば、送信側にVMのNICのNSGフローログとサブネットのNSGフローログがあった場合、片方のNSGフローログには調査対象のトラフィック情報が記録されているが、もう片方には記録されてない、といったことが起こります。普通に考えれば、両方のNSGフローログにトラフィック情報が出力されていると思いますが、実際はそうなっていないのです。ではNSGフローログはどういうルールで記録されるのでしょうか。
NSGのルール評価について
NSGフローログの出力ルールを知るためには、NSGのルール評価がどのように行われるかということを知ることが重要です。まずこの点について解説していきます。
NSGルールの評価順序
例えば、下図のネットワーク構成において左のVMから右のVMに向けた通信を考える場合、NSGルールは①→②→③→④の順で評価されると思いますよね。それが普通の感覚なのですが、Microsoftサポートに問い合わせたところ、実はこの通りの順序で評価されていないということがわかりました。
実際は下記の順番になります。送信側、受信側ともに、サブネットのNSG→NICのNSGという順番になるそうです。(仕組みがよくわからず少々受け入れ難いのですが、そういうものだそうです・・・)
NSGルールの評価順序の入れ替え
さらに、必ずこの順序ということでもなく条件によっては評価ルールの順序が変わるケースがあるようです。
例えば、
- サブネットのNSGしかない状態で、後からNICにNSGを適用すると、「NICのNSG」→「サブネットのNSG」という評価順序に変わる
- さらにその状態でVMの再デプロイを行うと、元の順番（「サブネットのNSG」→「NICのNSG」）という評価順序になる
こんな動きになるようです。
NSGの仕様上、サブネットのNSGとNICのNSGの評価順序が変わっても、通信可否の制御には全く影響を与えないため、
どちらのNSGが先に評価されるかは担保されておらず、評価順序が変わりうることがある、ということが確認されています。
また、どちらの順番であっても拒否のルールの合致した場合はその時点でルール評価は終了 となることもNSGフローログの出力に大きな影響を与えます。
NSGフローログの出力ルールは？
NSGフローログに出力されるルールは、「最後に評価されたルール」 です。それぞれのNSGでどのような評価結果になったかによってフローログの出力先が変わります。通常条件においての出力パターンは下記の通りです。
| # | サブネットのNSG | NICのNSG | 出力先 |
|---|---|---|---|
| 1 | 拒否 | 拒否 | 最初にサブネットの NSG で拒否され評価が終了するため、 サブネットのNSGに拒否のルールが出力 |
| 2 | 拒否 | 許可 | 最初にサブネットの NSG で拒否され評価が終了するため、 サブネットのNSGに拒否のルールが出力 |
| 3 | 許可 | 拒否 | サブネットのNSGを通過しNICのNSG で拒否されるため、 NICのNSGに拒否のルールが出力 |
| 4 | 許可 | 許可 | サブネットのNSGを通過しNICのNSG でも許可されるため、 NICのNSGに許可のルールが出力 |
上記のルールについては、先述した「条件によっては順序が変わるケース」によっては評価順序が逆になるため、NSGフローログの出力ルールも逆の考え方になります。
実機検証
上記の通りとなるか実際に検証してみました。とりあえず#1のパタンをやってみました。
検証環境
検証環境は下記の構成でRDPの通信で試してみようと思います。
（はじめICMPで試そうとしたのですがNSGフローログが出力されず・・・確かにTCP/UDPしか出力フォーマットにないからICMPには対応してないのかな）
全てのNSGにはNSGフローログ出力の設定を入れています。構築時点ではsend-vmからreceive-vmへのRDPできる状態にしておきます。送信側も受信側も評価ルールの順序ですので、今回は送信側のNSGフローログ(感覚的に合わない方)を確認していきます。
subnet1-nsg:Deny
send-vm-nsg:Deny
先ほどの評価ルールの通りであれば、最初にサブネットのNSGに拒否のルールが出力されるはずです
では繋いでみましょう。キャプチャはありませんが当然接続は失敗します。さて、NSGフローログはどうなってるでしょうか？
なるほど、サブネットのNSGのフローログが出力されていますね。中身はこんな感じです。正しくブロックされていることがわかります。
当然ですがNSGフローログはサブネットのNSG分しか出力されていませんでした。
時間があれば他のパタンもやってみたいのですが、今回の実機検証はここまでとします。
ゴメンナサイ。。。
NSGフローログの実際の運用方法
これまで解説してきた通り、NSGフローログの出力はNSGルール評価順序が不定であるため、生ログを追うのはなかなか難しいです。実際の運用では、NSGフローログをLogAnalyticsに連携したりPowerBIから参照する方法などが公開されていますので、このようなツールを有効に活用しましょう。
おわりに
今回はNSGフローログの詳細について解説してみました。後半尻切れになってしまいましたが、NSGフローログの出力仕様について少しでも理解いただけたなら幸いです。NSGフローログはその有効性からたくさんの人が取り上げ記事にしてくれてますので、ぜひ色々なブログ・記事を読んでいただきご自身の知見としていただければと思います。それではまた。