服務定位

Cloudflare WAF 的核心定位是 把攻擊擋在 origin 之前的一站式 edge security。流量打到 Cloudflare anycast IP、經過 WAF / DDoS / Bot / Rate Limit / Page Shield 多層處理、再 proxy 到 origin。這跟 AWS WAF 跑在 AWS 內部 ALB / CloudFront / API Gateway 前是不同部署模型 — AWS WAF 流量 已經進到 AWS、Cloudflare WAF 流量 還沒到 origin。對 origin 是 任意雲 / on-prem 的客戶、Cloudflare 是天然選項；對 AWS-only 客戶、AWS WAF 整合更深但 edge 範圍小。

跟 Fastly Next-Gen WAF（前 Signal Sciences）相比、Cloudflare 走 signature + managed rule + ML 混合、Fastly NG-WAF 走 語意分析 + behavioral detection（不靠 regex signature）。Cloudflare managed rule 覆蓋廣但 false positive 較常見、需要 sensitivity tuning；Fastly NG-WAF 預設較低 FP 但需要 自己定義業務 anomaly。

關鍵張力：客戶信任的不只是 WAF rule 攔截能力、還包括 Cloudflare control plane 的安全性。Cloudflare 2023 control plane token 跟 Cloudflare 2026 route leak 兩個事件展示：vendor 自己被打進去 / 自動化配置失誤時、客戶側 直接修不了、只能等公告 + 客戶側 token rotation + emergency bypass。

本章目標

讀完本頁、讀者能判斷：

1. Cloudflare WAF 在 edge security stack 中承擔哪一段（DDoS / WAF / Bot / Page Shield / API Shield）、哪些要靠 origin 自己做
2. Managed Rule vs Custom Rule 的取捨、sensitivity tuning 跟 false positive curve
3. Cloudflare control plane 出事時的客戶側補強路徑（API token rotation、Origin Rules bypass、第二邊界 fallback）
4. 何時用 Cloudflare、何時走 AWS WAF / Fastly NG-WAF 的取捨

最短判讀路徑

判斷 Cloudflare WAF 配置是否健康、最少看四件事：

• 誰能改 WAF 規則：Cloudflare account 的 admin / member role 配置、API token scope（不要用 Global API Key、用 scoped API token + 限定 zone / 限定 permission）、Audit Log 是否同步到 SIEM
• 規則覆蓋面：Managed Ruleset（OWASP Core Ruleset + Cloudflare Managed Ruleset + Exposed Credentials Check）是否開、Sensitivity（Low / Medium / High）對應的 FP rate 是否監控、Custom Rule 是否進版控（Terraform provider）
• 入口暴露：origin IP 是否曝光（DNS 直查 / 歷史 SAN cert / 子域名）、Argo Tunnel / Authenticated Origin Pull 是否強制、繞過 Cloudflare 直連 origin 的路徑是否封住
• 證據可回查：Security Events Log 是否同步到 SIEM（Logpush 推到 R2 / S3 / Splunk）、Page Shield 偵測異常 script 是否 alert、API token 異常操作（特別 zone settings 變更）是否 alert

四件事任一缺失、就是 Audit Log 與 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

Managed Ruleset 分層：Cloudflare 提供三類 managed rule — OWASP Core Ruleset（OWASP CRS、寬覆蓋、FP 較多）、Cloudflare Managed Ruleset（Cloudflare 維護、針對熱門 CMS / framework）、Exposed Credentials Check（檢測登入流量中的已洩漏 credential）。production 通常開全部三套 + 各設適當 sensitivity。Sensitivity 不是「敏感度越高越好」— High sensitivity 攔截更多 borderline traffic、business-critical endpoint 可能誤殺合法請求。建議從 Log Mode 開始、觀察 1-2 週的 FP pattern、再切到 Block。

Custom Rule（Cloudflare Rules）：用 Rules language（類 SQL 表達式）定義條件 + 動作（Block / Challenge / Log / JS Challenge / Managed Challenge）。常見用法：geo block（特定國家）、known bad IP（threat intel feed）、URI path-based limit（admin endpoint 限定 IP）、header anomaly（缺 User-Agent / 異常 Referer）。所有 Custom Rule 走 Terraform provider 進版控、避免 console 直接改、變更走 PR review。

Rate Limiting：跟 WAF rule 是 獨立 product、配置是 threshold + window + action（例：1000 req/min per IP → challenge）。Rate Limiting 比 WAF 適合處理 legitimate-looking high volume（credential stuffing、scraping、API abuse）。注意 NAT pool IP 的問題 — 一個公司 / ISP NAT 出口可能合法產生高 QPS、簡單 per-IP rate limit 會誤殺、需要組合 cf.threat_score 或 cookie-based identification。

Bot Management（單獨 SKU）：免費版 WAF 不含 Bot Management、需要 Pro / Business / Enterprise 才有。Bot Management 用 ML + behavioral fingerprint 區分 human / good bot（搜尋引擎）/ likely bot / verified bot、給 bot score（1-99）。客戶在 Custom Rule 用 cf.bot_management.score < 30 之類條件挑出 likely bot 處理。簡單 user-agent 過濾擋不住現代 headless browser、必須走 Bot Management。

Page Shield（JS supply chain 防護）：Page Shield 監測客戶網頁載入的 JS / connect 來源、發現 新出現的腳本 或 已洩漏的 script（CT log + threat intel）就 alert。意義是 防 third-party script 被供應鏈攻擊（類 Magecart）— WAF 攔不住、因為攻擊發生在 browser 端 而非 origin 流量。需要在 Page 載入 Page Shield 的 monitoring script。

API Shield：用 OpenAPI schema validation、auto-discovery API endpoint、mTLS 驗證、JWT validation。對於有 schema 的 API、可以擋掉 schema 不符的請求（多餘欄位、型別錯誤、缺必要欄位）— 比 generic WAF rule 精準。

Origin 暴露面收緊：Cloudflare 唯一有效的前提是 流量必須經過 Cloudflare。如果攻擊者拿到 origin 真實 IP（DNS 歷史記錄、漏洞披露網站、SSL cert SAN）、可以繞過 Cloudflare 直打 origin。控制方法：origin firewall 只允許 Cloudflare IP range 入站、Argo Tunnel（origin 主動建 outbound 連線到 Cloudflare、不開任何入站 port）、Authenticated Origin Pull（origin 用 cert 驗證請求來自 Cloudflare）三選一或組合。

API token 治理：避免 Global API Key（全帳號 root token）、改用 scoped API token（限 zone + 限 permission + 限 IP + 限 TTL）。token 進 Secret Management / Vault、定期 rotate。對應 Cloudflare control plane token 2023 揭示的 lesson：Cloudflare 自己也踩過 token 治理不足、客戶側不能假設 vendor 完美。

核心取捨表

選 Cloudflare WAF 的核心訴求：多雲 / on-prem origin + 需要 整套 edge security suite（DDoS + WAF + Bot + Page Shield + API Shield） + 接受 Cloudflare 控制面風險、且有預算做 Enterprise tier 才能拿到完整功能。純 AWS-internal app + ALB origin 用 AWS WAF 整合更直接。

進階主題

Workers + Workers AI 作為 custom logic：當 managed rule + custom rule 表達力不夠（例：根據 user account tier 決定 challenge 強度、整合內部 risk score API）、可以用 Cloudflare Workers 寫 JavaScript / TypeScript / Rust 在 edge 執行。Workers AI 提供 edge ML inference、可以做 inline content moderation 或 anomaly detection。代價是 Workers code 進 Cloudflare 控制面、變更要走部署流程、debug 跟 origin 是兩條 trace。

Logpush 跟 SIEM 整合：Cloudflare Security Events 量大、free / Pro 在 dashboard 看、Business / Enterprise 走 Logpush 到 R2 / S3 / Splunk / Datadog / Sumo Logic。production 必須走 Logpush、不能只在 dashboard — 事件 30 天保留期是 Cloudflare 端、SIEM 留更久。Logpush 也是 SIEM 上做 跨來源 correlation 的前提（WAF event + origin app log + IdP log）。

Multi-account / Tenant：大企業有多個 Cloudflare account（不同 BU / 不同產品線）、要走 Cloudflare for SaaS 或 Account-level access、API token scope 要限定 account。Single account 多 zone 是常見小組織配置、但跨組織 / 跨產品線必須拆 account 隔離 admin compromise blast radius。

Magic Transit / Zero Trust integration：Magic Transit 是 L3 DDoS（不只 HTTP、TCP / UDP 也 anycast）、Zero Trust 是 employee access（取代 VPN）。跟 WAF 是不同產品、但常一起部署 — Magic Transit 防 L3/L4 attack、WAF 防 L7、Zero Trust 防內部 east-west。

排錯與失敗快速判讀

• Managed Rule 誤殺合法請求：High sensitivity 開後 business endpoint 變慢 / 報錯 — 看 Security Events 找 rule_id、用 Custom Rule skip 該 rule 在特定 path / 特定 user-agent、不要全 zone 關 rule
• Bot Management 太嚴 / 太鬆：bot score threshold 設不對、合法 API client 被當 bot、或攻擊者拿到 verified bot 假冒 — 用 Bot Analytics 看分數分布、調整 threshold 同時加白名單（API key + IP CIDR）
• Rate Limit 誤殺 NAT 用戶：per-IP rate limit 在 NAT 出口 IP 上炸 — 改 per-session（cookie-based）或 cf.threat_score 條件
• Origin IP 外洩：DNS 歷史 + 漏洞披露 + cert SAN 揭露真實 origin、攻擊繞 Cloudflare 直打 — 換 IP + 開 origin firewall（只允許 Cloudflare CIDR）+ Argo Tunnel
• API token over-scoped：CI / 第三方 SaaS 拿到 Global API Key、整 account 都被改 — 改 scoped token、限 zone + permission + IP、進 Vault
• Security Events 沒進 SIEM：事件只在 dashboard、跨來源 correlation 沒法做 — 配 Logpush + alert 規則
• Page Shield 沒裝：客戶端 JS 被植入、伺服器端日誌看不到攻擊、第三方 script CDN 被打 — 啟用 Page Shield + CSP report-uri 雙軌
• 第二邊界沒設：完全依賴 Cloudflare、Cloudflare 出事流量全停（2023 / 2026 自家事件）— 高 SLA 服務應該設 fallback origin / secondary DNS（如 Route53 health check failover 到 Fastly 或直連 origin）

何時改走其他服務

不在本頁內的主題

• Cloudflare 完整 product line（Workers / Pages / R2 / D1 / Magic Transit / Zero Trust 各自細節）
• WAF Rules language 完整語法 reference
• Page Shield / API Shield Enterprise tier 完整功能對照
• 各 PCI DSS / SOC 2 / FedRAMP 合規矩陣
• Cloudflare 在中國的部署模式（JD Cloud Union 合作）

案例回寫

Cloudflare WAF 在 07 案例庫有 兩個直接 vendor-level 事件 + 多個 edge-exposure 對照：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：AWS WAF、Fastly Next-Gen WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：HashiCorp Vault（Cloudflare API token 存放）、Okta（Cloudflare admin 走 SSO）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件 / Cloudflare 自家事件如何 routing 進 IR）
• 官方：Cloudflare WAF Documentation

服務定位

AWS WAF 的核心定位是 跟 AWS 服務深度耦合的 L7 防護層。Web ACL 直接掛 AWS resource、規則用 IAM policy 管理、log 進 Kinesis Firehose / CloudWatch Logs / S3、跟 AWS Shield Standard（內含、L3/L4 DDoS）自動整合。這跟 Cloudflare WAF 在 origin 之前的 edge 攔截不同 — AWS WAF 流量 已經進到 AWS 邊界、不是擋在外部。對 origin 跑在 ALB / CloudFront / API Gateway 後的客戶、AWS WAF 是天然選項；origin 在其他雲或地端、AWS WAF 觸不到。

跟 Fastly Next-Gen WAF 相比、AWS WAF 走 signature + managed rule group 偵測模型、不像 Fastly NG-WAF 走語意 / behavioral；AWS WAF 的 Managed Rule Group 來自 AWS Managed 與 AWS Marketplace 第三方（Fortinet、F5、Imperva 等）、客戶端 看不到 rule logic、debug 時要靠 sampled request 反推。

計費模型也是關鍵差異：AWS WAF 按 per-Web-ACL + per-rule + per-request 計費（單 ACL $5/月、單 rule $1/月、$0.60 per 1M request），Managed Rule Group 算多 rule、開太多套 ruleset 與流量大時帳單會明顯漲。Cloudflare 是 plan-tier 計費（Pro / Business / Enterprise）、不會因為多開 rule 線性漲價。

本章目標

讀完本頁、讀者能判斷：

1. AWS WAF 在 AWS-internal 防護 stack 中承擔哪一段、哪些要靠 AWS Shield / VPC / CloudFront 補位
2. Web ACL scope（Regional vs CloudFront）的選擇與跨 region 部署成本
3. Managed Rule Group / Custom Rule / Rate-based Rule 的取捨、Bot Control add-on 是否值得開
4. 何時用 AWS WAF、何時走 Cloudflare WAF / Fastly NG-WAF 的判準

最短判讀路徑

判斷 AWS WAF 配置是否健康、最少看四件事：

• Web ACL scope 對不對：CloudFront distribution 必須掛 CloudFront scope（強制在 us-east-1 建立 ACL）、ALB / API Gateway 必須掛 Regional scope（每個 region 各一份）；scope 配錯掛不上去、跨 region 部署是否用 IaC（Terraform / CloudFormation）同步複製 ACL
• Managed Rule Group 與 sensitivity：是否啟用 AWSManagedRulesCommonRuleSet（CRS）、AmazonIpReputationList（已知惡意 IP）、AnonymousIpList（VPN / proxy / Tor）、KnownBadInputsRuleSet（已知 exploit pattern）、Marketplace rule 是否在 Count mode 觀察 1-2 週 FP 再切 Block
• Logging 有沒有開：Web ACL log 預設關閉、必須手動配 Kinesis Firehose / CloudWatch Logs / S3 destination；event 是否進 SIEM（見 7.13 偵測覆蓋率與訊號治理）、是否能對 sampled request 反推 rule 行為
• IAM 邊界：誰能 update Web ACL（wafv2:UpdateWebACL、wafv2:UpdateRuleGroup）、是否限定 admin role 才能改、CI 是否只有 wafv2:Get* / List* 用來 verify、敏感變更是否走 Change Management / Audit Log

四件事任一缺失、就是 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

Web ACL 與 scope：Web ACL 是 AWS WAF 的 規則容器、必須 attach 到 AWS resource。Scope 兩種：Regional（給 ALB / API Gateway / App Runner / AppSync / Cognito User Pool、每 region 獨立）與 CloudFront（給 CloudFront distribution、必須在 us-east-1 建立、全球生效）。同一個 ACL 不能跨 scope 共用；跨 region 部署同一套規則必須複製 ACL、用 Terraform / CloudFormation 管理避免 drift。

Rule action 五種：每個 rule 觸發時可以做 Block（直接 403）、Allow（跳過後續 rule、放行）、Count（不擋、只記錄、用於 dry-run 觀察 FP）、CAPTCHA（出題給人類解、bot 過不去）、Challenge（silent JS challenge、無感驗證）。新 rule 上線標準動作是先 Count 1-2 週看 sample、確認 FP 在容忍範圍才切 Block。CAPTCHA / Challenge 是 Bot Control add-on 配套、要額外計費。

Managed Rule Group（managed by AWS / Marketplace）：AWS Managed（免費含在 WAF）涵蓋 Common Rule Set（OWASP top10 對應）、Known Bad Inputs、SQL Database、Linux、Unix、Windows、Anonymous IP List、Amazon IP Reputation List、Account Takeover Prevention (ATP)、Account Creation Fraud Prevention (ACFP)。AWS Marketplace（付費）來自 Fortinet / F5 / Imperva / Cyber Security Cloud 等。Marketplace 規則 不公開 rule logic、攔錯時只能用 sampled request 反推、debug 比 AWS Managed 困難。

Custom Rule（statement + 條件）：Custom Rule 用 statement（match condition + transformation）組合：IP Set match、Geo match、Regex Pattern Set、Size constraint、SQL injection match、XSS match、String match（含 header / body / URI / query 各部位）。複雜條件用 AND / OR / NOT 組合、上限是每 Web ACL 5,000 Web ACL Capacity Units（WCU）— 規則越複雜 WCU 越高、Marketplace 大型 rule group 可能直接吃掉一半 budget。

IP Set / Regex Pattern Set：IP Set 存 IPv4 / IPv6 CIDR 清單、Regex Pattern Set 存正則表達式集合。兩者都是 獨立資源、可在多個 Web ACL 引用、單獨更新（不必動 Web ACL 結構）。實務上 threat intel feed 應該 push 到 IP Set、用 Lambda 自動 sync、不用手動加。

Rate-based Rule：限制 單一 aggregate key 在滾動 5 分鐘窗口內的請求數、超過 threshold 觸發 action。aggregate key 可選 IP、Forwarded-IP（看 X-Forwarded-For）、HTTP method、URI path、Header、Cookie 或組合。關鍵陷阱：CloudFront 後 origin ALB 必須用 Forwarded-IP、否則 Rate-based Rule 看到的全是 CloudFront 邊緣節點 IP、所有真實使用者被合併計算、要嘛全擋要嘛全放。

Logging 必須手動開：Web ACL log 預設關閉、destination 三選一：Kinesis Data Firehose（推到 S3 / Splunk / Datadog）、CloudWatch Logs（簡單但貴）、S3（直寫、需自己處理 partition）。production 通常走 Kinesis Firehose → S3 + Athena query、配合 SIEM 拉 alert。沒開 log 等於 攻擊發生時沒證據、事後無法回查。

跟 AWS Shield 整合：所有 AWS WAF 客戶自動含 Shield Standard（L3/L4 DDoS、免費、SYN flood / UDP reflection 等基礎防護）。Shield Advanced 是付費 add-on（$3,000/month per organization + per-resource fee + data transfer out fee）、提供 24/7 DRT（DDoS Response Team）、cost protection（DDoS 期間 AWS service scaling fee 補貼）、進階分析。一般客戶 Shield Standard 已足夠；金融 / 政府 / 高知名度品牌需要 Shield Advanced 的 DRT 與 cost protection。

Lambda@Edge / CloudFront Functions 補位：當 WAF rule statement 表達不出複雜業務邏輯（geofencing + business hour + user tier 組合、JWT claim 解析後判斷 routing）、用 Lambda@Edge（Node.js / Python、跑在 CloudFront 邊緣節點、4 個 phase：viewer-request / origin-request / origin-response / viewer-response）或 CloudFront Functions（純 JS、輕量、低延遲、只在 viewer-request / viewer-response）補位。Lambda@Edge 適合複雜邏輯、CloudFront Functions 適合 header rewrite / 簡單 routing；兩者都不能取代 WAF managed rule、但補位 WAF 表達力上限。

跟 AWS IAM 整合：誰能改 Web ACL 是 IAM policy 決定（wafv2:CreateWebACL、wafv2:UpdateWebACL、wafv2:AssociateWebACL、wafv2:UpdateRuleGroup 等 action）。production 標準配置：admin role 才能 update、CI / 開發者只有 wafv2:Get* / List* 用來 verify、敏感變更走 Change Management + CloudTrail audit log。

核心取捨表

選 AWS WAF 的核心訴求：AWS-internal app + origin 跑在 ALB / CloudFront / API Gateway / App Runner 後 + 想跟 IAM / CloudTrail / Shield 同套 control plane 治理。Origin 不在 AWS、或要 把攻擊擋在抵達雲之前、應該走 Cloudflare WAF 或 Fastly NG-WAF。

進階主題

AWS WAF Bot Control（add-on）：付費 add-on、用 AWS 自家 bot fingerprinting 區分 verified bot（搜尋引擎）/ signal: automated browser（headless Chrome 等）/ signal: known bot（已標記 IoT / scraper），給每個請求 bot category label。Custom Rule 在 label 上做條件、決定 Block / Challenge / CAPTCHA。比 user-agent 過濾準很多、但要額外計費（per-request）。Bot Control 有兩個 inspection level：common（便宜、基礎指紋）與 targeted（貴、含 JavaScript challenge、CAPTCHA、token-based）。

Fraud Control（ATP / ACFP）：Account Takeover Prevention（ATP）跟 Account Creation Fraud Prevention（ACFP）是 Managed Rule Group 的特殊類別、需付費啟用。ATP 看登入端點的 credential stuffing、ACFP 看註冊端點的 bot signup。兩者都用 AWS 自家 threat intel（被竊憑證 list、行為模型）打 label、客戶側用 Custom Rule 處理。對有 login / signup 端點的 SaaS / 電商有價值、純內部後台不必開。

CAPTCHA / Challenge：AWS WAF 內建 CAPTCHA puzzle 與 silent JS Challenge、可在 rule action 直接呼叫。Challenge 在客戶端執行 proof-of-work、合法瀏覽器無感、headless 工具卡住；CAPTCHA 是視覺題、人類解、bot 不會。Production 標準做法：Bot Control 給 label → Custom Rule 看 label → likely bot 走 Challenge、known bad 走 Block、人類流量直接 Allow。

ACM Private CA + WAF 對 mTLS：AWS WAF 本身不做 mTLS 驗證、mTLS 是 ALB / API Gateway / CloudFront 自己的功能（搭配 AWS ACM Private CA 簽發 client cert）。WAF 在 mTLS 完成後才看 L7 流量、可以用 HTTP header match（mTLS 後 ALB 注入 client cert 資訊到 header）做進一步 rule。Internal API 用 mTLS + WAF 是常見組合。

Lambda@Edge 補 inline business logic：複雜判斷（user tier × geo × business hour × A/B test）WAF rule statement 表達不出來、用 Lambda@Edge 在 viewer-request phase 解析 JWT、查 internal risk API、回 response header 給 WAF 後續判斷。代價：Lambda@Edge 部署只能在 us-east-1、code 更新傳播到全球 edge 要幾分鐘、debug 是分散式 CloudWatch Logs。

排錯與失敗快速判讀

• Web ACL 掛不上 CloudFront：scope 配成 Regional、CloudFront 拒絕 attach — Web ACL 必須在 us-east-1 + CloudFront scope 才能掛 CloudFront；ALB / API Gateway 反過來只能掛 Regional scope
• Rate-based Rule 全擋 / 全放：CloudFront 後 origin 看到全部都是 CloudFront IP、aggregate key 沒換 Forwarded-IP — 改用 Forwarded-IP（X-Forwarded-For）作 aggregate key，並設 Fallback behavior
• Managed Rule Group 誤殺合法請求：CRS High sensitivity 開後 file upload / rich text editor 端點被 Block — 找 sampled request 看 rule_id、用 Scope-down statement 限定該 rule 在某 path 不執行、或開該 rule 為 Count、不要關整個 group
• Marketplace Rule 攔不明流量：Marketplace rule logic 不公開、sampled request 看到 rule label 但不知為何 — 切該 rule 到 Count mode 觀察、若無 attack 跡象換 AWS Managed 同類 rule
• WCU 超限：Web ACL 上限 5,000 WCU、加 Marketplace + 多個 AWS Managed 就會爆 — 看 Capacity Used、移除重疊 rule、把 Custom Rule 表達式簡化（少用 transformation chain）
• Logging 沒設 / 設錯：事件發生後沒有完整 log 可查、只有 sampled request（保留 3 小時、機率抽樣） — 必開 Logging configuration 到 Kinesis Firehose / S3 / CloudWatch Logs、確認 IAM role 有 firehose:PutRecord 權限
• IAM 權限過寬：CI account 拿到 wafv2:* 整 zone 都能改 — 收斂到 wafv2:Get* / List* 唯讀、敏感寫入限 admin role + MFA + Change Management
• 跨 region 部署 drift：手動在 console 改 us-east-1 ACL、其他 region 沒同步 — 用 Terraform / CloudFormation IaC 管理、PR review、CI plan 檢查 drift
• Shield Standard 不夠擋大型 L7 DDoS：Standard 只防 L3/L4、L7 attack 靠 WAF Rate-based Rule + Bot Control — 若反覆遭遇大型 L7 DDoS、評估 Shield Advanced 的 DRT + cost protection 是否值得

何時改走其他服務

不在本頁內的主題

• AWS WAF Classic（v1）的遷移細節 — 本頁全以 WAFv2 為準
• 完整 WCU 計算規則與每個 statement 的 WCU cost reference
• Marketplace 第三方 rule group 各家功能矩陣
• AWS WAF 在 GovCloud / China region 的差異
• Bot Control / ATP / ACFP 完整 label schema reference

案例回寫

AWS WAF 在 07 案例庫無直接 vendor-level case、但多個 case 對應 WAF 作為 修補窗口期臨時控制 與 entry point 治理 的角色：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：Cloudflare WAF、Fastly Next-Gen WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：AWS IAM（誰能改 Web ACL）、AWS ACM（mTLS client cert）、AWS Secrets Manager（rule update 用的 API key）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件如何 routing 進 IR）
• 官方：AWS WAF Documentation

服務定位

Fastly NG-WAF 設計的第一順位是 production 可直接走 Block 模式。Signature WAF 的成本不在 rule 本身、在 false positive — 一條 SQLi pattern 可能誤判合法 SQL-like 字串（搜尋查詢、CSV 上傳）、production 開 Block 立刻炸合法流量、所以多數 signature WAF 跑在 Detect / Log Only 模式、攔不下真正攻擊。Fastly NG-WAF 走 Signal 模型：每個請求被解析後標記若干 Signal（SQLi、XSS、CMDI、Traversal、Anomaly 等）、再依 threshold-based rule（N 個 Signal 在 M 秒內聚集）才動作 — false positive 自然降低、Block 模式可開。

跟 Cloudflare WAF 的對照：Cloudflare 走 signature + managed rule + ML 三層、覆蓋廣但需要 sensitivity tuning；Fastly NG-WAF 預設低 FP 但需要 客戶自己定義業務語意（哪些 path 是 admin、哪些 header 不該出現、哪些 anomaly 對自家業務代表攻擊）— 用 Tag + Match Conditions 表達。跟 AWS WAF 的對照：AWS WAF 跟 ALB / CloudFront / API Gateway 整合深、跨雲弱；Fastly NG-WAF 部署模型多樣（Edge / Agent / Cloud）、跨 AWS / GCP / on-prem / K8s 一致。

關鍵張力：低 FP 的 代價 是要花時間理解自家業務語意。Signature WAF 是「裝上就有保護」、Fastly NG-WAF 是「裝上有 baseline、業務 anomaly 要自己標」。沒有人定義 Tag + Power Rules、就只用到產品 30% 能力。

本章目標

讀完本頁、讀者能判斷：

1. Fastly NG-WAF 的 Signal / Tag / Rule / Mode 四個核心 first-class concept 各承擔什麼責任
2. Edge / Agent + Module / Cloud Proxy 三種部署模型的選擇條件
3. Account Takeover Protection、Bot Protection、API discovery 三個進階 module 的適用情境
4. 何時用 Fastly NG-WAF、何時走 Cloudflare WAF / AWS WAF 的取捨

最短判讀路徑

判斷 Fastly NG-WAF 配置是否健康、最少看四件事：

• 部署模型對齊架構：Fastly Edge inline（流量本來就過 Fastly CDN）/ Agent + Module（自管 Nginx / Apache / IIS / Envoy / .NET 加 sigsci-agent local process）/ Cloud Proxy（Fastly 接 origin proxy）三選一或混用、是否覆蓋所有入口（含 admin、internal API、staging）
• Signal 與 Tag 設計：預設 Signal（SQLi / XSS / CMDI / Traversal / Backdoor / Anomaly）是否全開、業務語意 Tag（admin-path、internal-only、payment-flow）是否定義並掛上 Match Conditions、Power Rules 是否組合多 Signal / Tag 走 threshold-based action
• Rule mode 與 threshold：Site-level 跟 Corp-level Rule 是 Block 還是 Off、threshold（連續幾個 Signal / 多久窗口）是否依 endpoint 業務調整、Template Rule（ATO、Bot）是否啟用
• Logging 與 sigsci-agent token 治理：Syslog / HTTP webhook / S3 / SIEM（Splunk / Datadog / Sumo Logic）整合是否 production-grade、sigsci-agent 連回控制面的 token 是否進 HashiCorp Vault、跨環境 token 是否分離

四件事任一缺失、就是 Audit Log 與 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

部署模型選擇：Fastly Edge inline 是最簡部署、流量已過 Fastly CDN 就 inline 加 NG-WAF、沒有額外 agent 要管；Agent + Module 是 self-managed Nginx / Apache / IIS / Envoy / HAProxy / .NET / Java（Tomcat）等加裝 sigsci-module（process 內 module 攔請求）+ sigsci-agent（本機 daemon、跟 Fastly 控制面 sync rule、collect event）— 適合 origin 不過 Fastly CDN、或 internal API；Cloud Proxy 是 Fastly 提供 reverse proxy 端點、客戶 DNS 指過去、origin 在後面 — 適合不想改 origin、又沒用 Fastly CDN。三種混用常見、大企業 edge 用 Fastly Edge、internal service 用 Agent + Module。

Signal 是已知攻擊指標：Fastly NG-WAF 預定義 Signal 包含 SQLi / XSS / CMDI（command injection）/ Traversal（路徑穿越）/ Backdoor / RCE / Anomaly 等。Signal 是 語意解析結果 — request body 被 parser 拆解（JSON / form / multipart）、每個欄位看「這像不像某類攻擊」、不是 regex 比對。意義是 encoding 變化攔不住（base64 / URL encode / Unicode normalize 都會被解開）、跟 signature WAF 的脆性對比明顯。

Tag 是客戶自定 Signal：用 Match Conditions（path / method / IP / header / body content / query 參數）定義「什麼樣的請求叫某 tag」、例：Path: /admin/* AND Source IP NOT IN internal_cidr → tag: admin-external-access。Tag 之後可以走 Rule 處理（看到 admin-external-access 就 alert / block）。Tag 是 Fastly NG-WAF 表達 業務語意 的主要工具、不是用來補強 Signal。

Rule 三層：Site-level Rule（單一 site / property）/ Corp-level Rule（整個 organization 共用、用於 corp-wide block list、跨 BU 統一 policy）/ Template Rule（Fastly 提供的預設複合 rule、如 ATO template、Bot template）。Rule 表達式組合 Signal / Tag / Source IP / Path / Method、走 Block / Off。Power Rules 是進階版 — 支援 threshold + 時間窗口 + 多條件 AND/OR、例：「同 IP 在 60 秒內觸發 5 個 SQLi Signal 就 Block 10 分鐘」。

Mode 兩種：Block（攔截、回 406 / 自訂 status）/ Off（不動作、純 log）。沒有 Cloudflare 的 Sensitivity 滑桿 — 因為 Signal 本身已是語意判讀結果、不需要敏感度調整、調整在 threshold（多少 Signal 才動作）。

Account Takeover Protection（ATO）：偵測 credential stuffing pattern — 同 IP 多 login fail、跨 IP 同 account 多 login、impossible travel、unusual UA。Fastly NG-WAF 內建 login endpoint detection（自動 / 手動標記 /login、/auth/signin 等）、配合 ATO Template Rule 直接 inline 處理（rate limit、challenge、block）。對應 Identity Boundary 的 ATO 對策、但是在 WAF 層直接攔、不等 IdP 內 ATO 邏輯。

Bot Protection：跟 Cloudflare Bot Management 同類、走 behavioral + browser fingerprint + JS challenge、區分 verified bot / likely bot / human。比 user-agent 過濾穩、headless browser 攔得住。

API discovery：Fastly NG-WAF 自動學習 site 的 API endpoint 與 schema、偵測 schema drift（突然出現的多餘欄位、缺欄位、type mismatch）— 比手動維護 OpenAPI schema 輕量、適合內部 API 多但沒寫完整 OpenAPI 的團隊。

Logging 與 sigsci-agent 治理：所有 event 走 Fastly NG-WAF 控制面 + 客戶端 Syslog / HTTP webhook / S3 / SIEM（Splunk / Datadog / Sumo Logic）。sigsci-agent 連回控制面用 Site API key — 該 key 進 HashiCorp Vault、跨環境 prod / staging 分離、rotation 走標準 secret rotation 流程、不能寫死在 agent 配置檔。

核心取捨表

選 Fastly NG-WAF 的核心訴求：production 直接 Block + API / schema-rich 業務 + 自管伺服器需要 inline agent + 跨雲 / on-prem mix、且有預算支付 Enterprise tier。純 AWS-internal 簡單 web app 用 AWS WAF 整合更直接；要整套 edge security suite 用 Cloudflare。

進階主題

VCL + Edge custom rule：Fastly Edge 部署模式下、NG-WAF 跟 Fastly CDN 的 VCL（Varnish Configuration Language）共存、複雜邏輯可寫 VCL 在 NG-WAF 處理前後攔截 — 例：geo block 在 VCL 做、NG-WAF 處理通過的請求。Compute@Edge（Fastly 的 edge serverless、類 Cloudflare Workers）也可以接 NG-WAF 結果做進一步處理。代價是 VCL / Compute@Edge code 變另一條 ops trace、要有版控與 staging。

ATO 進階 — credential stuffing 場景：login endpoint 接 ATO Template Rule 後、可進一步整合 已洩漏 credential check（類 Have I Been Pwned 整合）、failed login burst → progressive challenge（先 CAPTCHA、再 block）。對應 Identity Boundary 的 IdP ATO 邏輯、Fastly 在 WAF 層攔的好處是 攻擊不會打到 IdP、減少 IdP 端 rate limit 壓力。

Bot Protection 進階：browser fingerprint + behavioral pattern + JS challenge 三層、可掛 bot score threshold 在 Power Rules 內、配合 ATO 做 high-risk login flow（bot score 高 + login endpoint → 強 challenge）。

Agent + Module 在 K8s / VM：K8s 場景 sigsci-agent 走 sidecar 或 DaemonSet、sigsci-module 在 ingress controller（Nginx Ingress Controller 加 sigsci-nginx module）；VM 場景 sigsci-agent 走 systemd service、module 隨 web server 啟動。跨環境 token 隔離（prod / staging / dev）走 Vault dynamic secret 或環境變數注入、不寫死配置檔。

Corp-level Rule 共用：多 BU / 多產品線在同一 Corp（Fastly NG-WAF 的 organization 概念）下、Corp Rule 跨所有 Site 生效 — 適合表達「全公司禁 IP X」「全公司 ATO Template 都開」、避免每個 Site 重複配置。

排錯與失敗快速判讀

• Signal 沒觸發、攻擊穿過：Encoding 異常 / parser 沒解析該 content-type — 確認 Content-Type 正確、body 大小沒超過 sigsci-module 限制（預設 100KB）、Signal scope 是否包含該 endpoint
• Tag 沒掛上：Match Conditions 寫錯（path 大小寫、trailing slash、wildcard 語意）— 在 Fastly NG-WAF console 用 Rule Evaluation 工具測試 request 是否命中
• Block 模式誤殺：Power Rules threshold 太低、單一合法請求觸發多 Signal — 調 threshold 或加 Site Rule exception 排除特定 path / source
• sigsci-agent 跟控制面失聯：Site API key 過期 / firewall block out-bound / agent 版本太舊 — agent log 看 connection status、輪換 token 走 Vault、保持 agent 在 supported version range
• sigsci-module load 失敗：web server 啟動報 module 載入錯 — 確認 module 版本跟 web server major version 對齊（Nginx 1.20 對 sigsci-nginx 對應版本）
• ATO Template 沒攔到：login endpoint detection 沒標到自家 path — 手動在 console 標記 login endpoint 路徑
• Logging gap：Syslog / webhook 送失敗、SIEM 沒收到 — 確認 destination accept、TLS cert 沒過期、retry policy
• 跨環境 token 漏氣：staging token 流到 prod、改 staging 影響 prod rule — Vault 環境分離、token 加標籤、定期 audit token usage

何時改走其他服務

不在本頁內的主題

• Signal Sciences 收購前的 product line 演進細節
• 完整 Signal 清單與每個 Signal 的內部解析邏輯
• VCL / Compute@Edge 完整語法 reference
• Fastly CDN 本身的 caching / TLS / origin shielding 細節
• Enterprise 合約細節、各國資料駐留選項

案例回寫

Fastly NG-WAF 沒有直接 vendor-level 公開事件、案例庫對照引用以「behavioral detection 在 zero-day / supply chain 場景的 inline mitigation 角色」為主：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：Cloudflare WAF、AWS WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：HashiCorp Vault（sigsci-agent Site API key 存放）、Okta（Fastly admin 走 SSO）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件 routing 進 IR）
• 官方：Fastly Next-Gen WAF Documentation