WAF for Azure Front Doorを理解するための前提
Front Door WAFはglobal edgeでincoming HTTP(S) requestをinspectionし、originへ到達する前にblockできる。 Front Door Premiumはmanaged rule setを含むfull WAF capabilities、Standardはcustom rules中心というtier差を確認する。
custom rulesはmanaged rulesより先に評価され、match ruleとrate limit ruleを作成できる。 managed DRSはXSS/SQLi/RCE等のcommon exploit categoryを検出し、DRS 2.0+はanomaly scoringを使用する。
WAF actionにはAllow/Block/Log/Redirect等があり、HTTP DDoS rulesetなど通常custom-rule orderと異なる例外もある。 false positive tuningではrule ID/matched variableをlogから特定し、broad Allowやruleset全disableを避ける。
Control plane / Data plane / Observability
攻撃sourceに近いFront Door POPでinspection。
custom + managed + bot/rate controlsをdomainへassociation。
WAFでblockされたrequestはorigin logに現れないことを利用して切り分ける。
Client-to-backend path
- requestがFront Door edgeへ到達する。
- WAF policyのcustom rulesをpriority順に評価する。
- Premiumではmanaged DRS/bot等を評価する。
- policy mode/actionに従いallow/block/log/redirect等を決定する。
- allow requestだけFront Door routing/cache/originへ進む。
- WAF/access logsでedge decisionを記録する。
仕組みを分解する
Front Door WAFとApplication Gateway WAFは同じ「WAF」という名称でも配置場所が異なります。Front Door WAFはglobal edge、AppGW WAFはregional VNet-side proxyです。multi-layer WAFを使う場合、どちらのruleがblockしたかをlog category/request ID/timeで判別できるようにします。
運用時は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は到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Tier | managed rules/bot/advanced featuresが必要ならPremiumを選定。 |
| Policy scope | domainごとにsecurity requirementが違うならpolicy associationを分離する。 |
| Rate limiting | API/login等でrate-limit ruleを使う場合、trusted proxy/client-IP semanticsを確認する。 |
| Layering | Front Door + AppGW WAFの二重inspectionは責任範囲とduplicate false positiveを設計する。 |
確認手順
Read-only verification
- Front Door domainにassociated WAF security policyを確認する。
- mode、custom rule priority/action、managed ruleset/versionをexportする。
- WAF logでclient IP、rule ID、action、URIを確認する。
- block testでorigin 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 front-door waf-policy show -g <rg> -n <policy> -o jsonc
az afd security-policy list -g <rg> --profile-name <profile> -o jsoncGet-AzFrontDoorWafPolicy -ResourceGroupName <rg> -Name <policy> | Format-List *障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| 正当request block | false positive | WAF log matched rule | exclusion/rule tuning |
| managed rule効かない | Standard tier/association | tier + policy config | Premium/association確認 |
| originにrequestなし | edge block | WAF/access log | rule action確認 |
| Allowで全部bypass | custom rule broad | custom priority/conditions | scope縮小 |
| bot traffic残る | bot ruleset未設定 | policy managed rules | Premium feature確認 |
変更時の確認と rollback
- WAF policyはversion controlし、ruleset/version changeをrelease扱いにする。
- PreventionからDetectionへ戻す場合もalertingを維持する。
- rate-limit threshold変更前後のrequest volumeを保存する。
- broad Allowをemergency rollbackとして残さず、期限付き最小条件にする。
Current notes — 2026-09-11
Front Door Premiumではmanaged rule setsが利用でき、Standardはcustom rule中心。DRS 2.0+はanomaly scoringを使う。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。