VNet flow logsについて
先日VNet flow logsがパブリックプレビューになりました。
Azure仮想ネットワークの通信ログを記録するには、現在NSGフローログが提供されていますので、違いにフォーカスして挙動を確認したいと思います。
注意事項
ドキュメント記載の通りプレビューは申し込み制のものになります。
詳細は申し込みして確認いただければと思いますが、VNet flow logsを有効化するにはそのサブスクリプションのコンピューティングリソースの実行環境に制限がなされるとのことでした。
運用環境で許容できる制限ではありませんでしたので、プレビューを試される方は検証環境専用のサブスクリプションを用意することをお勧めします。
また、2023/9/1現在日本国内のリージョンでは提供されていません。
確認結果
先に結果だけまとめます。詳細や気になる動作は後述。
-
ログ出力
Type ログファイルフォーマット ログテーブル NSGフローログ json, flowLogVersion:2 AzureNetworkAnalytics_CL VNetフローログ json, flowLogVersion:4 NTANetAnalytics -
対応するログ
Type AVNMのセキュリティ管理ルール TCP/UDP以外 PaaSプライベートエンドポイン宛て VNet暗号化 NSGフローログ 非対応 非対応 非対応 非対応 VNetフローログ 対応 非対応 非対応 対応
NSGフローログのおさらい
VNet flow logsを試す前にNSGフローログのポイントをおさらいしておきます。
NSGフローログはNSGに対して設定できるログです。NSGはNICとサブネットに付与できますので、NICとサブネットの単位でログ出力が可能でした。
NSGフローログは設定すると指定したストレージアカウントにjsonファイルで出力されます。また、検索性を高めるためにTraffic Analyticsを利用してLog Analyticsワークスペースに出力することもできます。
NSGフローログの制限事項について
NSGフローログには運用上注意しなければならない事項がいくつかあります。
VNet flow logsで改善されているかの参考のため、いくつかをピックアップします。
制限事項の多くは以下のドキュメントに記載されていますので、NSGフローログを運用する前には確認しておきましょう。
Microsoftドキュメント NSGフローログに関する考慮事項
-
NSGフローログはNSGごとに設定しなければならない
これは単純に手間の問題ですが、設定漏れがあると次に示す仕様と合わさって正しく設定されていた箇所のNSGでもログの取得漏れを引き起こします。
Azure Policyを利用して設定漏れを抑止することはできますが、根本的な問題解決にはなりません。 -
1つの通信フローが複数のNSGを経由する場合、経由するすべてのNSGでNSGフローログを設定しなければならない
これはNSGフローログがその通信フローの中で最後に評価されたNSGのNSGフローログで記録される仕様と、サブネットのNSGとNICのNSGでNSGの評価順が固定されていない仕様によります。
概念的にVMからのアウトバウンド通信はNIC⇒サブネットの順に通過してNSGもその順に評価されるとイメージしますが、これは担保されていません。そのため、サブネットのNSGのみにフローログを設定していても最後にNICのNSGが評価される挙動を取るとログが記録されないことになります。 -
PaaSのプライベートエンドポイント宛てのトラフィックはNSGフローログに記録されない
PaaS宛ての通信のログ取得で問題になります。 -
TCP/UDPの通信のみしか記録されない
疎通確認にPingを使っていると記録されないため注意する必要があります。 -
Azure Virtual Network Manager (AVNM)のセキュリティ管理ルールが記録されない
NSGフローログという名前の通り当たり前ですがAVNMのルールで制御された通信の記録には対応していません。AVNMのセキュリティ管理ルールのログを保存する方法は現在提供されていません。
2023/9/1現在AVNMのセキュリティ管理ルール自体がプレビューなので問題になるケースは少ないですが考慮しておく必要があります。
VNet flow logsの機能確認（by Microsofotドキュメント）
公式ドキュメントの記載から特徴をピックアップすると以下の通りです。
- 仮想ネットワーク単位で有効化する
- ログはストレージアカウントとLog Analyticsワークスペースに保存可能 ※NSGフローログと同様
- ログはjsonファイルとして保存される ※NSGフローログと同様
- TCP/UDPにのみ対応している（OSIレイヤ4で動作する） ※NSGフローログと同様
- AVNMのセキュリティ管理ルールに対応している
- 仮想ネットワークの暗号化に対応している
ということで、名前の通り設定を仮想ネットワーク単位に管理できることはもちろん、AVNMのセキュリティ管理ルールに対応していることも明記されています。
一方で、ICMPへの対応は無いようです。
これらの動作や言及されていない点について実際に使用して確認したいと思います。
VNet flow logsの有効化
2023/9/1時点ではPowerShellもしくはAzure CLIで有効化する必要があります。こちらはドキュメントの通りに設定できます。
ちなみに、プレビューの申請が受理されていないとエラーが出ます。
なお、設定後はNSGフローログと同様にNetwork Watcherにて確認することができます。
設定変更もAzureポータルからおこなうことができました。
ログ出力
ログファイル
ドキュメント通りのフォーマットで出力されていることが確認できました。
ログの出力フォーマットの詳細はMicrosoftのドキュメント参照いただければと思いますが、細かい表記ルールが異なります(flowLogVersionが2→4に更新されています)。
例えば通信プロトコルを示す表記がNSGフローログではT (TCP) / U (UDP)で示されていましたが、VNetフローログではIANAのプロトコル番号(TCPなら6)で示されます。
また、VNetフローログでは通信の許可・拒否の項目がフローの状態の項目とマージされ、"Flow state"にB (Begin) / C (Continuing) / E (End) / D (Deny)で示されるようです。
加えてNSGフローログでは見えてこなかったログが記録されていました。
"aclID"が"00000000-0000・・・"という出力で、その中では"rule"が"Unspecified"という暗号化が原因で拒否されたトラフィックを示すログが記録されています。
送信元のIPアドレスを調べるとMicrosoft所有のグローバルIPでしたのでAzure内部の通信がキャプチャされたものと思われますが、詳細不明です。
Log Analyticsワークスペース
NSGフローログが出力されるAzureNetworkAnalytics_CLテーブルではなく、NTANetAnalyticsテーブルに出力されていました。
こちらもフォーマットの詳細はMicrosoftのドキュメント参照ですが、おおよそのつくりはNSGフローログと変わりありません。
ログ出力検証
NSGフローログの制限事項に関連するいくつかのログの出力有無を検証してみました。
AVNMのセキュリティ管理ルール
RDP（TCP/3389）の通信についてAVNMのセキュリティ管理ルールとNSGルールで許可・拒否設定してログ出力を確認しました。
No.5, 6のパターンではAVNMセキュリティ管理ルールの評価結果（許可）も記録されると思いましたが、NSGルールのみの記録でした。
複数のNSGを経由したときと同じく最後に評価されたルールのみ出力される挙動になるということのように見えます。
| No | AVNMセキュリティ管理ルール | NSGルール | ログ出力 |
|---|---|---|---|
| 1 | Always許可 | 許可 | AVNMセキュリティ管理ルールの許可として記録 |
| 2 | Always許可 | 拒否 | AVNMセキュリティ管理ルールの許可として記録 |
| 3 | 拒否 | 許可 | AVNMセキュリティ管理ルールの拒否として記録 |
| 4 | 拒否 | 拒否 | AVNMセキュリティ管理ルールの拒否として記録 |
| 5 | 許可 | 許可 | NSGルールの許可として記録、AVNMのセキュリティ管理ルールでの許可は記録なし |
| 6 | 許可 | 拒否 | NSGルールの拒否として記録、AVNMのセキュリティ管理ルールでの許可は記録なし |
PaaSのプライベートエンドポイント宛てのトラフィック
これは残念ながらNSGフローログと同様に記録されませんでした。
VNetピアリング時の挙動
VNet間の通信も問題なく記録されました。VNet flow logsの設定は送信元、送信先、いずれかのみ設定されている状態でも問題なく保存されていました。
NSGフローログのように経由するVNetすべてでログを有効化する必要があるといったことは無いようです。
まとめ
コンセプト通りVNet単位で通信ログの保存を設定、管理できるのは非常に便利です。
また、AVNMのセキュリティ管理ルールにも対応しているのも嬉しいですね。
ログのフォーマットも大きく変わりはしないので、これまでに近い形で管理・運用できると思われます。
一方で、PaaSのプライベートエンドポイント宛てのログが保存されないことやTCP/UDP以外のログが保存されないことはNSGフローログと同様です。
NSGフローログと同じ仕組みでキャプチャされているものと思うので、仕方が無いと思いますが今後の拡張に期待です。