Azure Firewall Application Rulesを理解するための前提
Application rulesは主にHTTP、HTTPS、MSSQL trafficをFQDNベースでfilterするapplication-level policy。 HTTPSではtransparent proxyとSNI等を利用して、同じIPにresolveする複数FQDNをNetwork ruleより識別しやすい。
Network ruleが先にmatchするとApplication ruleは評価されないため、広いL3/L4 AllowがL7 policyをshadowし得る。 Application ruleはinbound publishing用ではない。inbound HTTP/SにL7 protectionが必要ならWAF等を組み合わせる。
Application ruleで処理されるtrafficはtransparent proxyによりSNATされるため、backend側のsource visibility設計に注意する。 PremiumではTLS inspection、URL filtering、Web Categories、IDPSを組み合わせてencrypted Web trafficの検査を強化できる。
Control plane と data plane
仕組み
Network rule passでmatchしなかったHTTP/S/MSSQL flowがApplication ruleへ進む。
proxyがrequested FQDN/SNI/protocolを検証する。
rule collectionをpriority順に評価し、Allow/Denyを決定する。
Premium TLS inspection対象ならdecrypt→policy/IDPS inspection→re-encryptする。
Allowされたflowはproxy/SNAT経由でdestinationへ接続し、Application Rule logへ記録する。
Packet / decision path
障害時はresource一覧ではなく、同じsource/destination/port/protocolで各enforcement pointを順に追います。
- Web/domain intentはNetwork ruleよりApplication ruleへ寄せる。
- HTTPSではSNI/証明書/target FQDNが一致する実client journeyで検証する。
- Wildcardは必要最小限にし、CDN/shared-domainを過大許可しない。
- TLS inspection導入時はcertificate trustとexception policyを別途設計する。
- Application rule logsをrule owner/expiry reviewへ使う。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| FQDN vs IP | Web許可はFQDNで表現する。 | dynamic endpoint変更をIP allowlistへ追随させる負担を下げる。 |
| Shadowing | 先行Network rulesを最小化する。 | Network matchはApplication evaluationを終了させる。 |
| TLS | Premium inspectionが必要なtraffic/除外trafficを分類する。 | certificate pinning等でbreakするapplicationがある。 |
| Inbound | public web ingressはApp Gateway/Front Door WAF等と役割分担する。 | Application rulesはinbound HTTP/S reverse proxy securityではない。 |
確認手順
Azure Portal / Network Watcher
- Policy → Application rule collectionsでprotocol/target FQDN/actionを確認。
- Firewall logsでApplication Ruleのhit/denyとtarget FQDNを確認。
- Premium使用時はTLS inspection/IDPS statusとcertificate chainを確認。
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 firewall policy rule-collection-group list -g <rg> --policy-name <policy> -o jsonc
az monitor diagnostic-settings list --resource <firewall-resource-id> -o jsoncGet-AzFirewallPolicy -ResourceGroupName <rg> -Name <policy>障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| FQDN Allowなのにdeny | 先行Network rule、SNI/Host mismatch、certificate/DNS | Network+Application logs、client SNI | rule typeとactual hostnameを確認 |
| 接続先でsource IPが変わる | Application rule SNAT/proxy | destination access log | source-preservation要件ならrule type/architectureを再評価 |
| TLS inspection後だけ失敗 | client CA trust/certificate pinning | TLS errorとPolicy certificate | trust deployment/exceptionを設計 |
| shared CDNを広く許可 | wildcard/domain scope過大 | actual FQDN/URL logs | URL filtering/Premiumまたはspecific targetへ狭める |
変更時の確認と rollback
- 変更前にApplication rule collectionとTLS settingsをexport。
- rollback後、DNS cacheだけでなく新規TLS sessionを生成し、target FQDNとFirewall logを確認する。