WAF for Application Gatewayを理解するための前提
Application Gateway WAF_v2ではWAF Policyにcustom rules、managed rules、exclusions等をまとめ、gateway/listener/pathへassociationできる。 policyはglobal、per-site(listener)、per-URI(path-based rule)のscopeで分離できる。
custom ruleはmanaged ruleより先に評価されるため、Allow等の例外がmanaged protectionをbypassし得る。 Detection modeは観測・tuning、Prevention modeはblockを伴う。production切替前にfalse positiveをWAF logで確認する。
managed rule disableを第一手にせず、request attribute exclusionやnarrow custom ruleなど最小scopeで調整する。 WAF blockはbackend application 403と区別し、WAF logのrule ID/action/matched variableを証拠にする。
Control plane / Data plane / Observability
gateway / listener / pathで適用範囲を定義。
custom rule→managed ruleの順序を理解。
Detectionで観測し、最小exclusion後にPreventionへ。
Client-to-backend path
- client requestがWAF_v2 listenerへ到達する。
- 適用WAF Policyとcustom rulesをpriority順に評価する。
- managed rule setがrequest componentをinspection/anomaly scoringする。
- Detectionならlog、Preventionならpolicy/actionに従ってblock等を実行する。
- 許可requestだけrouting rule/backendへ進む。
- WAF/access/backend logを同じrequest contextで相関する。
仕組みを分解する
WAF tuningは「rule 949110がblockしたから949110をdisable」では不十分です。anomaly scoringでは個別match rulesの合計でblocking thresholdに達します。実際にmatchedしたrule IDとvariableを確認し、正当requestの特定fieldだけをexclusionする方がblast radiusを小さくできます。
運用時はresource configurationだけで完了判定せず、実clientからの名前解決、TCP/TLS handshake、HTTP status、backend側のsource IP/Host/header、health telemetryを同じtimestampで揃えます。load balancer/proxyがhealthyでもapplication dependencyが壊れている場合があり、逆にbackend applicationが正常でもhealth probe条件やrouting ruleが不整合ならtrafficは到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Policy granularity | 複数siteを1 gatewayに載せる場合、security profileが違えばlistener/path policyへ分ける。 |
| Mode rollout | Detection→log review→exclusion/custom tuning→Preventionの段階移行を基本にする。 |
| Managed rules | version変更はreleaseとして扱い、before/after false positive/coverageを比較する。 |
| Logging | WAF logsをLog Analytics等へ常時送信し、block理由を再現できるようにする。 |
確認手順
Read-only verification
- WAF policy association scopeをgateway/listener/pathごとに確認する。
- mode、managed rule set/version、custom rule priority/action、exclusionをexportする。
- known benign/malicious test requestでDetection/Prevention behaviorを確認する。
- WAF logのruleId/message/detailsとapplication access logを相関する。
Evidence to keep
- resource ID / subscription / region / frontend / backend targetを保存し、同名resource取り違えを防ぐ。
- DNS answer、source IP、destination IP/port、Host/SNI、health status、timestampを同じincident recordへ残す。
- 変更前後で同じclient journeyをnew connectionとして再実行する。
- Portal表示だけでなくCLI/PowerShell/APIまたはlogsを併用し、観測面の一時差を識別する。
az network application-gateway waf-policy show -g <rg> -n <policy> -o jsonc
az network application-gateway show -g <rg> -n <appgw> --query "firewallPolicy.id" -o tsvGet-AzApplicationGatewayFirewallPolicy -ResourceGroupName <rg> -Name <policy> | Format-List *障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| 正当request 403 | false positive | WAF log rule ID/variable | narrow exclusion |
| 悪性requestが通る | Detection/Allow rule | policy mode/custom priority | Prevention + rule order |
| siteごと挙動違う | policy association scope | listener/path policy IDs | effective policy確認 |
| 大量block | ruleset update/app change | time-series rule ID | change correlation |
| backend logなし | edgeでWAF block | WAF access log | backend前blockと判定 |
変更時の確認と rollback
- WAF Policy JSONをversion controlする。
- managed ruleset upgradeは旧versionへ戻せるrelease単位にする。
- exclusionはowner/reason/expiryを記録する。
- Prevention→Detection rollback後もalertingを維持し、単なる無防備化にしない。
Current notes — 2026-09-11
WAF_v2ではpolicyをgateway/listener/pathにassociationでき、custom rulesとmanaged rules/exclusionsをscope別に運用できる。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。