NSG Default Rulesを理解するための前提
Inbound既定はAllowVNetInBound(65000)、AllowAzureLoadBalancerInBound(65001)、DenyAllInbound(65500)。 Outbound既定はAllowVnetOutBound(65000)、AllowInternetOutBound(65001)、DenyAllOutBound(65500)。
default rulesは削除できないが、100–4096のcustom ruleで先にmatchさせることで実質的にoverrideする。 VirtualNetwork / AzureLoadBalancer / Internetは固定CIDRではなくservice tag。特にVirtualNetworkを「そのVNetのCIDRだけ」と決めつけない。
AllowInternetOutBoundはfilter許可であり、public IP、NAT Gateway、Firewall、routeなどのoutbound connectivityを生成しない。 default ruleをbaselineとして使う場合も、workload trust boundaryを明示し、必要ならVNet内east-westをcustom ruleで細分化する。
Control plane と data plane
仕組み
custom inbound/outbound rulesをpriority順に評価する。
matchがなければ65000/65001/65500のdefault chainへ進む。
AllowVNet系はVirtualNetwork service tag同士を許可するため、VNet内segmentationを要件にするなら追加policyが必要。
Internet outboundはNSG上Allowでも、effective routeとSNAT/explicit outboundがなければInternet到達は成立しない。
Packet / decision path
障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。
- flowがcustom ruleにmatchするか確認する。
- matchしなければ該当directionのdefault ruleへ進む。
- service tagが現在どのprefix集合を表すかを確認する。
- route/NAT/firewallとNSGを分けて判定する。
- east-west trustが広すぎないか設計レビューする。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| East-West | tier間通信はASG/CIDRで必要serviceだけ明示し、AllowVNetに丸投げしない。 | VNetはtrust boundaryそのものではない。 |
| Load balancer | AzureLoadBalancer service tagを理解してhealth probeを不要に遮断しない。 | probe失敗をbackend/application障害と誤認しやすい。 |
| Outbound | NSG allowとegress connectivityを別契約にする。 | security ruleとrouting/SNATは別レイヤー。 |
| Override | default Denyを変更したいのではなく、上位priorityのspecific ruleで意図を表現する。 | Azure管理default ruleを直接変更できない。 |
確認手順
Azure Portal / Network Watcher
- NSG → Default security rulesをInbound/Outbound両方確認。
- Effective security rulesでdefault ruleが実際にどのprefixへ展開されるか確認。
- Network Watcher NSG diagnosticsでcustom→defaultのどこが判定したか確認。
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 nic list-effective-nsg -g <rg> -n <nic> -o jsoncGet-AzNetworkSecurityGroup -ResourceGroupName <rg> -Name <nsg>
Get-AzEffectiveNetworkSecurityGroup -ResourceGroupName <rg> -NetworkInterfaceName <nic>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| VNet内通信が広く通る | AllowVNetInBound/OutBound | default ruleとVirtualNetwork tag展開 | tier別custom Deny/Allowを設計 |
| LB probeだけ失敗 | AzureLoadBalancer probe許可をoverrideしたcustom Deny | NSG diagnosticsでprobe source | health probe要件をspecificに許可 |
| Internet outbound Allowなのに不達 | egress route/SNAT欠落 | effective route/NAT/Firewall | explicit outboundを確認 |
| 想定外prefixがVirtualNetwork扱い | service tag semantics | effective rule prefixes | connected network/UDR等を含む現在のtag範囲を確認 |
変更時の確認と rollback
- 追加したoverride ruleを削除/restoreし、default behaviorに戻した後も新規flowで確認する。
- VNet内segmentationをrollbackする場合はblast radiusを明示し、広いAllowへ戻す前に関係者合意を取る。
What changed recently
NSG flow logsは新規作成できず、2027-09-30にretire予定です。新しい可視化設計はVNet flow logsを前提にし、既存NSG flow logsは移行計画を持たせます。