Network Security Group (NSG)を理解するための前提
custom ruleのpriorityは100–4096で、小さい数値ほど先に評価され、最初にmatchしたruleで評価を終了する。 NSGはstateful。許可されたconnectionのresponse trafficに逆方向の明示ruleは不要で、rule変更は原則として新規connectionへ効く。
NSGはsubnet、NIC、または両方へassociateできる。両方にある場合、対象flowは両方の評価を通過する必要がある。 inboundではpublic IPからprivate IPへの変換後、outboundではprivate IPからpublic IPへの変換前のaddressを基準にNSGが評価する。
既定ruleは削除できないが、より高いpriorityのcustom ruleで上書きできる。AllowInternetOutBoundはegress経路やSNATを作るruleではない。 接続障害ではconfigured NSGだけでなくNICのEffective security rules、NSG diagnostics、実際の5-tupleを組み合わせて判定する。
Control plane と data plane
仕組み
各方向で対象NSGのruleをpriority順に評価し、最初にmatchしたAllow/Denyを採用する。custom ruleがmatchしなければ65000以降のdefault rulesへ進む。
connectionが許可されるとflow recordにより戻りtrafficをstatefulに扱う。response用に機械的な逆向きruleを追加しない。
subnetとNICにNSGがある場合は両方がenforcement pointになる。片方のAllowだけを見て「許可済み」と判断しない。
Route、Firewall、guest OS firewall、application listen状態はNSGとは別。NSGがAllowでもend-to-end到達性は保証されない。
Packet / decision path
障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。
- 送信元applicationが新しいTCP/UDP flowを開始する。
- Azure SDNがdirectionと5-tupleを確定し、適用されるNSG/security admin rulesを評価する。
- NSGでAllowならrouting/次のsecurity controlへ進む。Denyならその時点でdropされる。
- destinationからのresponseはstateful flowとして戻るが、別経路や別security deviceのpolicyは独立に評価される。
- 障害時は同じ5-tupleでEffective security rules / NSG diagnostics / application testを揃える。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Association | 原則はsubnet単位のbaselineを中心にし、NIC NSGは例外や細粒度要件があるときに追加する。 | 二重associationは柔軟だが、障害時に両方のAllow/Denyを読む必要があり運用複雑性が増える。 |
| Rule identity | IP直書きよりservice tag / ASG /管理されたCIDRを優先する。 | workload scaleやPaaS prefix更新でrule maintenanceを減らせる。 |
| Change test | 既存sessionと新規sessionを分けて検証する。 | stateful flow recordによりrule削除後も既存connectionが残り得る。 |
| Evidence | configured rulesだけでなくeffective stateとflow-specific diagnosisを保存する。 | 「設定した」ではなく「そのpacketがどのruleで判定されたか」を受入条件にできる。 |
確認手順
Azure Portal / Network Watcher
- Network Security Groups → 対象NSG → Inbound/Outbound security rulesでpriorityとdefault rulesを確認。
- Subnet / NICのNetworkingからNSG associationを両側確認。
- Network Watcher → Effective security rules / NSG diagnosticsで代表VM/NICと5-tupleを固定して判定。
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 show -g <rg> -n <nsg> -o jsonc
az network nsg rule list -g <rg> --nsg-name <nsg> -o table
az network nic list-effective-nsg -g <rg> -n <nic> -o jsoncGet-AzNetworkSecurityGroup -ResourceGroupName <rg> -Name <nsg>
Get-AzEffectiveNetworkSecurityGroup -ResourceGroupName <rg> -NetworkInterfaceName <nic>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| Allow ruleがあるのに新規接続できない | より高priorityのDeny、もう一方のsubnet/NIC NSG、security admin rule | effective security rulesとNSG diagnosticsでdenying ruleを特定 | guest firewallやrouteを見る前にAzure側filter結果を固定する |
| rule削除後もSSHが切れない | 既存stateful flow | 同一sessionと新規sessionを別々に試験 | 既存接続継続を「ruleが効いていない」と誤認しない |
| Internetへ出られない | NSGだけでなくroute/SNAT/explicit outbound | AllowInternetOutBound有無、effective route、NAT/Firewall association | NSG Allowとegress pathの成立を分離して確認 |
| VNet内通信が意図せず通る | AllowVNetInBound / AllowVnetOutBoundとVirtualNetwork service tagの範囲 | default ruleとeffective prefix | 必要なsegmentationをcustom Deny/Allowで明示 |
変更時の確認と rollback
- 変更前にNSG JSON、association、effective security rulesを保存する。
- emergency rollbackは追加ruleの削除だけでなく、priority競合と既存flow残存を確認する。
- rollback後は新規connectionで再試験し、既存sessionだけで成功判定しない。
What changed recently
NSG flow logsは新規作成できず、2027-09-30にretire予定です。新しい可視化設計はVNet flow logsを前提にし、既存NSG flow logsは移行計画を持たせます。