NSG Rule Processingを理解するための前提
NSG ruleはdirectionごとにpriority昇順で評価され、最初のmatchでterminatingする。 評価条件はsource/destination address、source/destination port、protocolを中心とする5-tuple。
flow recordによるstateful動作のため、response trafficは開始方向の許可状態を利用する。 既存connectionに対してrule追加/変更/削除の効果が即時に見えないことがある。必ずnew connectionを作る。
subnet NSGとNIC NSGの両方があると、どちらか一方でDenyならend-to-end flowは成立しない。 Azure Virtual Network Manager security admin rulesがある環境ではNSGより先に評価されるため、NSGだけを見て結論を出さない。
Control plane と data plane
仕組み
inbound packetはAzure側で必要なaddress translation後のdestination contextでNSG評価される。outboundはpublic SNAT前のprivate source contextで評価される。
各enforcement pointでcustom rules→default rulesの順にmatchを探す。priority番号が同じdirection内の順序を決める。
Allowされたconnectionにはstateが作られ、return trafficは対応flowとして扱われる。
policy変更後の既存flowは継続し得る。security validationでは新しいsocket/sessionを生成する。
IP Flow Verify/NSG diagnosticsはflow-specificなAllow/Denyとruleを示すが、routeやapplication healthの証明には別ツールを使う。
Packet / decision path
障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。
- 新規flowの5-tupleを記録する。
- security admin ruleがある場合は先にそのactionを確認する。
- source/destinationに関係するsubnet/NIC NSGを列挙する。
- 各NSGでdirection/priority/match条件を順番に照合する。
- 判定後、route・Firewall・guest OS・applicationへpacket walkを継続する。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Priority spacing | 100,200,300のように将来挿入余地を残す。 | 緊急ruleを既存rule全再採番なしで挿入しやすい。 |
| Deny strategy | 広いDenyの前に必要なspecific Allowを配置し、例外理由を記録する。 | first matchなので順序誤りが直ちに障害になる。 |
| Stateful test | 変更前後とも新規connectionを用いる。 | existing flowの継続をrule評価と混同しない。 |
| Dual NSG | subnet+NICを採用する場合は責務を分ける。 | 同じ意図のruleを二重管理するとdrift/診断コストが増える。 |
確認手順
Azure Portal / Network Watcher
- Network Watcher → NSG diagnosticsでsource/destination/port/protocolを指定。
- VM/NIC → Effective security rulesでsubnet/NIC/admin ruleの集約結果を確認。
- 対象NSG rule一覧でpriorityとsource/destination objectの展開を確認。
Verification discipline
- subscription / resource group / resource ID / NIC / direction / 5-tupleを記録する。
- 同じ条件でbefore/afterを比較し、既存sessionとnew connectionを区別する。
- configuration、effective state、logs、application resultを別々の証拠として残す。
- 変更成功はcontrol-plane Succeededではなくobservable data-plane behaviorで判定する。
az network nsg rule list -g <rg> --nsg-name <nsg> -o table
az network nic list-effective-nsg -g <rg> -n <nic> -o jsonc
az network watcher test-ip-flow --direction <Inbound|Outbound> --protocol <TCP|UDP> --local <ip:port> --remote <ip:port> --vm <vm-resource-id>Get-AzEffectiveNetworkSecurityGroup -ResourceGroupName <rg> -NetworkInterfaceName <nic>
Test-AzNetworkWatcherIPFlow -NetworkWatcher <watcher> -Direction <Inbound|Outbound> -Protocol TCP -LocalIPAddress <ip> -LocalPort <port> -RemoteIPAddress <ip> -RemotePort <port> -TargetVirtualMachineId <id>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 同じruleなのに結果が違う | 既存flowか新規flowか、source ephemeral port、direction | connection再生成と5-tuple採取 | test条件を完全一致させる |
| NIC NSGではAllow | subnet NSGまたはsecurity admin ruleでDeny | effective rulesの全enforcement point | 片方だけのrule listで結論を出さない |
| IP Flow VerifyはAllowだが通信不可 | routing/NVA/guest firewall/listen状態 | Next hop、Connection troubleshoot、OS socket | NSG以外へpacket walkを進める |
| ruleがmatchしない | ASG membership/service tag/prefix/port/protocolの認識違い | effective rule detailと実IP | objectが何に展開されるかを確認 |
変更時の確認と rollback
- 変更したrule/priorityを元へ戻す前に、現在のeffective判定とnew-flow結果を保存する。
- rollback後にnew-flowと既存flow双方を観測し、state expiration待ちが必要か判断する。
What changed recently
NSG flow logsは新規作成できず、2027-09-30にretire予定です。新しい可視化設計はVNet flow logsを前提にし、既存NSG flow logsは移行計画を持たせます。