Azure Firewall Network Rules

運用前提: Portal上のresource stateだけでなく、対象5-tupleのeffective state・route・security logs・new connectionを組み合わせてdata planeを確認します。SKU/limit/preview statusは変更されるため、導入時は末尾のcurrent Microsoft Learnも再確認してください。

Azure Firewall Network Rulesを理解するための前提

Network ruleはsource、destination、protocol、destination portなどL3/L4条件でtrafficをfilterする。 Firewall PolicyではDNATの後、Application rulesより前にNetwork rulesが処理され、matchすると後続Application ruleは評価されない。

任意TCP/UDP protocolでFQDN filteringを使えるが、network ruleのFQDN利用にはDNS proxyが必要。 HTTP/SやMSSQLのFQDN filteringではApplication ruleがSNI等を使えるため、Microsoftは可能な場合Application ruleを推奨している。

network-rule trafficのSNATはdestinationがpublic/privateか、PolicyのPrivate IP ranges設定、forced tunneling等で変わる。 FQDN network ruleはDNS resolutionからIP集合へ変換して評価するため、wildcard/SNI-based filteringと同一ではない。

通信や判断の流れを追う

SourceRouteNSG / PolicyWorkloadResponse

Control plane と data plane

Control planecontrol planeではNetwork rule collection action (Allow/Deny)、priority、source/destination object、protocol/port、Policy DNS/SNAT settingsを定義する。

Data planedata planeではpacketのIP/port/protocolとresolved FQDN IP集合を比較し、Network rule matchがApplication ruleより先にterminatingする。

仕組み

DNAT ruleにmatchしなかったoutbound/east-west flowがNetwork rule passへ入る。

RCG/RC priority順にNetwork rulesを評価する。

FQDN destinationの場合はFirewallがDNS proxy/upstream DNSで保持したIP mappingと照合する。

matchしたAllow/Denyで評価終了。Allowなら必要なSNATを適用してforward。

matchがなくHTTP/S/MSSQL等の対象trafficならApplication ruleへ進む。

Packet / decision path

障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。

IP/port protocol filteringが本質のtrafficにNetwork ruleを使う。
HTTP/S/MSSQLのdomain intentは原則Application ruleへ寄せる。
FQDN network rule利用時はclientとFirewallのDNS pathを統一する。
SNAT private rangesはon-prem registered public range等を考慮して明示する。
Network ruleが広すぎてApplication layer policyをshadowしないかreviewする。

設計判断

判断点	推奨	理由
Rule type	L3/L4 requirementはNetwork、Web/domain policyはApplication。	処理順とmatching semanticsが異なる。
FQDN	DNS proxyを前提にexact FQDNを使う。	client/FirewallのDNS差でunexpected dropを防ぐ。
SNAT	private/registered rangeの定義をnetwork architectureと合わせる。	source IP preservationとreturn pathに影響する。
Observability	structured Network Rule logsをLog Analyticsへ送る。	rule hitとdeny reasonをsource/destinationで検索できる。

確認手順

Azure Portal / Network Watcher

Firewall Policy → RCG → Network rule collectionsを確認。
DNS proxy/FQDNを使う場合はPolicy DNS settingsとclient DNS serverを確認。
LogsでAZFWNetworkRule等のstructured tableを使い、代表5-tupleのaction/ruleを確認。

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で判定する。

Azure CLI — read-only first

az network firewall policy rule-collection-group list -g <rg> --policy-name <policy> -o jsonc
az network firewall policy show -g <rg> -n <policy> -o jsonc
az monitor diagnostic-settings list --resource <firewall-resource-id> -o jsonc

PowerShell — read-only first

Get-AzFirewallPolicy -ResourceGroupName <rg> -Name <policy>

障害切り分け

症状	疑う点	証拠	次の確認
Application ruleがhitしない	先行Network ruleでterminating	Network/Application logsとprocessing order	広いNetwork Allowを狭める
FQDN Network ruleが不安定	clientとFirewallのDNS結果差	DNS proxy設定/upstream DNS	clientをFirewall DNS proxyへ向ける
on-prem宛sourceがFirewall IPに変わる	private range設定にregistered prefix不足	SNAT private rangesとlogs	internal prefixを適切に定義
Allowだがreturn失敗	asymmetric route/SNAT mismatch	両方向route + source NAT	return pathをstate domainへ戻す

変更時の確認と rollback

rule collection/Policy/SNAT/DNS設定をセットでexportする。
rollbackはNetwork ruleだけでなくDNS proxy/private ranges変更も戻し、source IPとnew-flow logを確認する。

Azure Firewall Network Rules