Cloud Armor

Cloud Armor 簡介

Google Cloud Armor 是 Google Cloud 提供的 Layer 3/4 DDoS 防護盾，同時也是 Layer 7 的 Web 應用程式防火牆 (WAF)。它附掛在 External Application Load Balancer、External Proxy Network Load Balancer 之前；自 2023 年起，也能透過 hybrid Network Endpoint Group (NEG) 保護位於地端或其他雲端的後端。Cloud Armor 跑在保護 Search、YouTube、Gmail 的同一張 Google 邊緣網路上，所以 DDoS 清洗發生在 Google 的 Points of Presence (PoP)，流量根本還沒進到你的 VPC 就先被擋下。

PCNE 考試中 Cloud Armor 題目集中在五個主軸：可以掛在哪些 LB 類型、backend security policy 與 edge security policy 的差別、Standard 與 Managed Protection Plus 怎麼選、Adaptive Protection 的貝氏 ML 模型怎麼運作，以及在指定情境下該選哪一種規則型態（預先配置 OWASP CRS、自訂 CEL、IP/Geo、threat intel feed）。本章節用具體的 gcloud 指令、API 欄位名稱與計費槓桿把這些情境串完整。

白話文解釋

在跳進 security policy JSON 之前，先把 Cloud Armor 想成三個不同的東西。每個比喻對應到一組功能——DDoS 清洗、WAF 檢查、調適型學習——因為 Cloud Armor 其實是三個產品用一個 policy 物件黏在一起。

類比 1：Cloud Armor 是夜店門口的保全

Global External Application Load Balancer 是夜店大門；Cloud Armor 是站在門口的保全。IP allow/deny 規則是夾在保全板夾上的 VIP 名單與黑名單。地理位置規則是「今晚不收這國家的客人」。預先配置 WAF 規則則是保全在門口搜身，檢查假證件 (SQL Injection)、噴漆罐 (XSS) 與開鎖工具 (Local File Inclusion)。這些東西保全完全不放進門，所以廚房（你的後端服務）根本看不到。Cloud Armor 是 PCNE 範圍內唯一完全在你的 VPC 之外運作的安全產品——保全站在人行道上，不是在建築物裡面。

類比 2：Adaptive Protection 是在這家飯店工作十年的門房

剛來上工的保全只能逐一判斷每個客人。在大廳看了十年的老門房則熟悉「正常」的節奏：晚上 8 點每分鐘三十人、凌晨 3 點每分鐘兩人，幾乎全部是西裝筆挺。當一台巴士在凌晨兩點停在門口、車上下來兩百個長相相似的人，他不等他們碰門就先通報警衛。Adaptive Protection 就是那個老門房：它用貝氏 (Bayesian) 模型對你的流量建立數小時到數天的基準線，當即時流量的指紋偏離基準（同樣的 User-Agent、同樣的 JA3、同樣的 URL 路徑、流量是平常的 10 倍），它會發出 attack event 並附上一份「建議規則」，讓你一鍵套用。

類比 3：Rate-Based Ban 是會把你踢下線的咖啡店 Wi-Fi

你家附近的咖啡店讓任何人連 Wi-Fi 90 分鐘，超過就踢下線 30 分鐘才能再連。rate-based ban 規則對 IP 也是這樣：當某個來源 IP 在時間視窗 M 內送出超過 N 個請求，就把它從這份 policy 上 ban 一段固定時間 D。和硬擋的 deny 不同，ban 會自動到期，所以一個臨時 burst-click 的合法 NAT 用戶之後還能正常進來。對付爬蟲、撞庫攻擊與意外重試風暴，這是正確的工具。

Cloud Armor 核心觀念

Cloud Armor 的資料模型小到可以塞在一頁紙上。考試考的是：你能不能把正確的物件掛到正確的 LB 上。

Security Policy、Rule 與 Priority

一個 security policy 是一個有名字的容器，最多可塞 200 條規則，每條規則有一個唯一的 priority 整數（0 是最優先，2,147,483,647 最低）。規則由 priority 由小到大評估，第一個 match 就生效。預設規則 priority 是 2147483647，會自動建立，你可以在 allow 與 deny(403) 之間切換——production 環境通常把預設設為 allow，再用上面的明確 deny 規則來擋（allow-list 型 policy 則反過來）。

Backend Security Policy 與 Edge Security Policy

兩種 policy 掛在不同層：

• Backend security policy — 掛在 backend service 或 backend bucket 上，能看到解密後的 HTTP 請求（包括 headers、body、解碼過的 URI）。WAF / OWASP CRS 規則與 CEL 表達式就住在這裡。
• Edge security policy — 掛在 backend bucket 或啟用 Cloud CDN 的 backend service 上，在 Google 邊緣 PoP 先於 cache lookup 評估，這意味著它可以阻擋流量連 cache 都打不到，更別提 origin。Edge policy 比較簡單——只支援 IP/CIDR、Geo 與 HTTP method 比對，不做 body 檢查。

Backend bucket 可以同時掛 edge policy 與 backend policy，edge policy 先跑。

Match 條件：Basic、Advanced 與 Preconfigured

每條規則有一個 match 區塊：

• Basic match — 最多 10 個 IP 範圍 (srcIpRanges)。
• Advanced match (CEL expression) — 一個 Common Expression Language 字串，上限 2048 字元，可引用 request.headers[...]、origin.region_code、request.path、request.query、request.method、inIpRange(origin.ip, '...') 等。
• Preconfigured expression set — 像 evaluatePreconfiguredExpr('sqli-v33-stable') 這樣的別名，展開後就是內建的 OWASP ModSecurity Core Rule Set。

預先配置 WAF 規則與 OWASP ModSecurity CRS

預先配置規則是 Cloud Armor 的 WAF 大腦。它是 Google 在邊緣規模下調校過、為了降低誤判的 OWASP ModSecurity Core Rule Set (CRS) 子集。

必背的規則家族

• sqli-v33-stable — SQL Injection（約 40 條子規則）。
• xss-v33-stable — Cross-Site Scripting。
• lfi-v33-stable — Local File Inclusion（../../etc/passwd）。
• rfi-v33-stable — Remote File Inclusion。
• rce-v33-stable — Remote Code Execution。
• methodenforcement-v33-stable — 攔截不尋常的 HTTP 動詞。
• scannerdetection-v33-stable — Nmap、Nikto、sqlmap 指紋。
• protocolattack-v33-stable — HTTP request smuggling、response splitting。
• sessionfixation-v33-stable — cookie / session 濫用。
• cve-canary — 針對野外正在被利用的 CVE（Log4Shell、Spring4Shell）的快速簽章。

Sensitivity Level 與 Opt-In 簽章

每條預先配置規則支援四個 sensitivity level（1–4）。Level 1 只有高信心匹配才觸發；level 4 是極度偏執，會擋下大量合法流量。預設是 1。也可以用 opt_in_rule_ids=['owasp-crs-v030301-id942110-sqli'] 從更高 level 中只加入特定簽章，不必把整個家族提升 level——這對於整體信任、只有一條子規則太敏感的情境很好用。

Preview 模式與調校

在規則上加 --preview，匹配時會記錄到 Cloud Logging，欄位是 enforcedAction: "allow" 與 previewedAction: "deny"，讓你在正式啟用前先量誤判率。考試最愛問的標準上線流程是：先 preview 部署，觀察 cloudaudit.googleapis.com 與 requests 一週，調整 opt_out_rule_ids 排除誤判過多的簽章，再把 --preview 拿掉。

使用 Common Expression Language (CEL) 寫自訂規則

當預先配置規則與 IP/Geo 攔截不夠時，CEL 提供一個迷你的查詢語言來寫自訂 matcher。

實用 CEL 樣式

• request.headers['user-agent'].contains('BadBot') — 用 header 子字串攔截。
• request.headers['user-agent'].matches('(?i)curl|wget|python-requests') — 不分大小寫的 regex 比對。
• origin.region_code == 'CN' || origin.region_code == 'RU' — 用 ISO 3166-1 alpha-2 做地理位置攔截。
• inIpRange(origin.ip, '203.0.113.0/24') — CIDR 成員判斷。
• request.path.startsWith('/admin/') && !inIpRange(origin.ip, '10.0.0.0/8') — 限定 admin 路徑只能從辦公室 IP 連。
• int(request.headers['content-length']) > 8192 — 攔截過大的 POST body。
• has(request.headers['x-forwarded-for']) — 檢查 header 是否存在。
• token.recaptcha_action.score < 0.5 — reCAPTCHA Enterprise 分數門檻。

CEL 的限制

每條規則一個 CEL 表達式，最多 2048 字元。沒有迴圈、沒有遞迴、不能呼叫外部 API。Body 檢查要另外啟用 JSON 解析規則 (jsonParsing: STANDARD) 且會增加延遲——熱路徑上請關閉。

CEL 與預先配置規則組合

production 常見組合：priority 1000 = evaluatePreconfiguredExpr('sqli-v33-stable') action=deny(403)；priority 1100 = 自訂 CEL inIpRange(origin.ip, 'corp-cidr') action=allow，把公司 IP 在 WAF 之上開白名單以便測試。因為規則是 first-match，公司 IP 會在 WAF 規則被評估前就 allow。

Rate-Based Ban 與 Throttle Action

除了 allow/deny，Cloud Armor 還有兩個 rate-aware 的 action 用於 Layer 7 洪水流量緩解。

Throttle (rate_based_throttle)

當某把 key 超過每時間視窗 N 個請求，後續請求會收到 deny(429) 直到速率降回門檻以下。Key 可以是 IP、header 值、/24 regional IP、HTTP 路徑或 X-Forwarded-For 第一個 IP，用 enforceOnKey 設定。Throttle 是 reactive、逐請求的：一超量就立刻 429。

Rate-Based Ban (rate_based_ban)

觸發條件一樣，但超過門檻後該 key 會被 ban 一段固定 banDurationSec（典型 600 秒）。在 ban 期間，該 key 的每個請求都直接 drop，不再重新評估速率。在邊緣規模下這比較高效，對於數小時內慢慢攀升的爬蟲也更有效。

怎麼選 Key

enforceOnKey: ALL（單一全域計數器）幾乎不會是你要的——一個流氓 IP 就會污染所有人的計數。IP 是預設值。XFF_IP 在 Cloud Armor 前面再掛一層 CDN（會注入 X-Forwarded-For）時是正解。HTTP_HEADER 鎖在 session cookie 上，則是「限制每個登入使用者每秒 5 個請求」的正確答案。

Adaptive Protection（貝氏 ML）

Adaptive Protection 是針對每個 backend service 的 ML 系統，會學習「正常」流量形狀並對 Layer 7 DDoS 異常打標。它在 security policy 層級用 --enable-layer7-ddos-defense 開啟，且需要該專案啟用 Managed Protection Plus 才能實際送出 suggested rule。

貝氏模型怎麼運作

對每個受保護的 backend service，模型持續取樣請求特徵（URL 路徑、User-Agent、JA3 TLS 指紋、來源 ASN、Accept-Language、地理位置、header 數量），並建立正常流量的機率分佈。當即時流量偏離超過門檻，Adaptive Protection 會發出 attack event 到 Cloud Logging，內容包含：

• 0.0–1.0 之間的 confidence score（Google 建議 ≥ 0.7 才採取行動）。
• 一段「attack signature」——一條 CEL 形狀的表達式，描述惡意流量的特徵。
• 一個「impacted baseline」——此 signature 會誤擋多少比例的合法流量。
• 一鍵「套用 suggested rule」按鈕。

該 signature 預設以 preview 規則進到你的 security policy，方便你在強制執行前先驗證。

遙測與調校

Adaptive event 會出現在 networksecurity.googleapis.com/dos_attack_mitigations，並可透過 Security Command Center 串到 Pub/Sub。訓練視窗是數小時到數天，所以全新 backend 在資料量還沒累積前 signature 會比較弱。模型是 per-backend-service，不是 per-policy——把同一份 policy 掛到 10 個 backend service，會有 10 條獨立 baseline。

Managed Protection 等級：Standard vs Plus

Cloud Armor 有兩個等級，差異是 PCNE 每場必考。

Standard（免費、按量計費）

任何 External Application Load Balancer 都自動包含。提供始終開啟的邊緣 Layer 3/4 DDoS 防護。每份 policy 每月 $0.75 USD、每百萬次請求評估 $0.75 USD。WAF 預先配置規則與自訂 CEL 可以用，但每次評估都計費。沒有 Adaptive Protection、沒有 DDoS 帳單保護。

Managed Protection Plus（訂閱制）

年度訂閱，前 100 個受保護資源（backend service + backend bucket）每月 $3,000 USD，已含 WAF 與 Adaptive Protection。加值內容：

• Adaptive Protection — 貝氏 L7 模型。
• DDoS 帳單保護 — 經 Google 確認的 DDoS 攻擊若導致 egress / LB 費用暴增，Google 會退回超出部分。
• DDoS Response Team 在活躍攻擊期間可諮詢。
• WAF 規則與 Adaptive Protection 不再按請求計費（已含在訂閱裡）。
• 經 Google 策劃的 威脅情報資料源 (Tor exit node、公有雲 egress IP、已知惡意 ASN、搜尋引擎爬蟲)。

何時建議 Plus

當受保護資源超過 10 個、跑受規管工作負載（PCI、HIPAA）、或面臨可信的 DDoS 風險時，Plus 就划算。考題情境「客戶擔心 DDoS 導致非預期的帳單暴衝」永遠是 Plus + 帳單保護。

Cloud CDN 整合

Cloud CDN 位於 load balancer 與後端之間。Cloud Armor 與 Cloud CDN 組合時的順序很重要。

流量順序

對啟用 CDN 的 backend service，每個請求的流程是：

1. Edge security policy（若有）—— 在 PoP 做 IP/Geo deny。
2. Cloud CDN cache lookup —— 若 HIT，直接從 cache 回應；cache hit 時 backend security policy 的 WAF 被略過。
3. Backend security policy —— 只有在 cache MISS（回源）時才會跑。

考試陷阱：考生以為 Cloud Armor 會檢查每一個請求。啟用 Cloud CDN 後，WAF 只檢查 cache miss，通常只占 5–20%。這對效能有利但意味著：要做全面 IP/Geo 攔截，一定要用 edge policy，否則一個被污染的 cache 項目可能會被回應給來自錯誤國家的攻擊者。

快取已認證內容

啟用 signedRequestMode: REQUIRE_SIGNATURES 時，URL 簽章在 Cloud Armor 評估 之前 就被 LB 驗證。沒有有效簽章的攻擊者會被 signer 擋下回 403，不是 Cloud Armor。

IAP 分層與縱深防禦

Cloud Armor 是其中一層；PCNE 藍圖期望你能把它跟 Identity-Aware Proxy (IAP) 與 VPC Service Controls 串起來。

Cloud Armor + IAP

兩者可掛在同一個 External Application LB 上。順序：Cloud Armor 先（邊緣），IAP 後（在 backend 前）。被 ban 的 IP 連 IAP 都打不到，省下驗證延遲。通過 Armor 但沒有 Google 身分的請求會被 IAP 帶到登入挑戰。Armor 處理「形狀型」過濾（速率、地理位置、bot），IAP 處理「身分型」過濾（誰能存取 /admin）。

Cloud Armor + reCAPTCHA Enterprise

Cloud Armor 可以透過 token.recaptcha_session.score 與 token.recaptcha_action.score 這兩個 CEL 變數吃 reCAPTCHA Enterprise token。常見組合：頁面發出 reCAPTCHA token；用戶端把它放在 header；Cloud Armor 規則 token.recaptcha_action.score < 0.4 action=deny(403)。這能抓到會解圖片謎題、但行為分數失格的 bot。

Cloud Armor + VPC Service Controls

Cloud Armor 保護對外的 LB。VPC-SC 在 BigQuery、Cloud Storage 等服務外建立 service perimeter，即使 VPC 內部 workload 被攻陷，也無法把資料 exfiltrate 到 perimeter 外。兩者解決不同問題，受規管工作負載通常一起部署。

Hybrid NEG 與多雲後端支援

2023 年起 PCNE 開始考的新能力：Cloud Armor 可以保護 不在 Google Cloud 上的後端。

Hybrid Connectivity NEG

Hybrid NEG 指向地端或其他雲的端點（IP:port，透過 Cloud Interconnect、Cloud VPN 或公網可達）。把它掛在 Global External Application LB 的 backend service，再掛 Cloud Armor，你就能在不重構應用程式的前提下，把 Google 規模的 WAF + DDoS 放到你的 AWS 或地端應用前面。

Internet NEG

概念類似，但 endpoint 是公網上任意 FQDN（例如 legacy.example.com）。Cloud Armor 看請求、套 WAF、再用 HTTPS 代理到該 FQDN。適合做為你無法控制的 SaaS 端點前的安全墊片。

注意事項

Hybrid NEG 的流量離開 Google 網路時仍要付 egress。後端的 TLS 憑證必須有效（或加 --insecure，考試不建議）。Adaptive Protection 可以正常運作——它學的是請求形狀，跟 origin 在哪裡無關。

IP Allow/Deny 清單與威脅情報資料源

最單純的規則型態，但考試還是會問配額與資料源名稱。

IP/CIDR 清單

每條規則的 srcIpRanges 最多 10 個項目。要更多就拆多條規則，或升級到 Managed Protection Plus 取得 named IP list，每條清單支援多達 10,000 個項目。Named list 用名稱引用，與 policy 規則獨立更新——很適合 SOC 維運的封鎖清單。

Geo Match

origin.region_code 回傳 ISO 3166-1 alpha-2。也可以用 origin.asn 做基於 ASN 的攔截。注意：Cloud Armor 用 MaxMind 的 GeoIP 資料，準確度約 95–98%——VPN 與行動電信 IP 偶爾會誤判位置。

威脅情報資料源（僅 Plus）

Google 維護、用 evaluateThreatIntelligence('FEED_NAME') 引用的策劃清單：

• iplist-tor-exit-nodes — Tor exit node。
• iplist-known-malicious-ips — Google 策劃的惡意 IP。
• iplist-public-clouds — AWS、Azure、OCI 等（攔截從 compute 發起的爬蟲）。
• iplist-vpn-providers — 已知 VPN 服務商。
• iplist-search-engines — 用來允許爬蟲。

這些清單持續更新，省下自己維護封鎖清單的負擔。

日誌、遙測與疑難排解

當合法使用者被擋下時，Cloud Logging 是你唯一的朋友。

Log 落地點

Cloud Armor 日誌是 Load Balancer 請求日誌 loadbalancing.googleapis.com/requests 的一部分。每筆 log 包含 enforcedSecurityPolicy.name、enforcedSecurityPolicy.outcome（ACCEPT/DENY）、enforcedSecurityPolicy.priority（命中的規則），以及在 preview 模式下的 previewedSecurityPolicy。要記錄到每個 match（不只是擋下），要在 backend service 啟用 verbose logging。

Cloud Audit Log

Policy 變更（建立、更新、刪除規則）會記錄到 cloudaudit.googleapis.com/activity。SOC 2 / ISO 27001 稽核需要這些證據。

常用 gcloud 指令

# 建立 backend security policy
gcloud compute security-policies create prod-waf \
  --description="Prod WAF for App LB"

# 加入預先配置 SQLi 規則，以 preview 模式上線
gcloud compute security-policies rules create 1000 \
  --security-policy=prod-waf \
  --expression="evaluatePreconfiguredExpr('sqli-v33-stable')" \
  --action=deny-403 \
  --preview

# 掛到 backend service 上
gcloud compute backend-services update prod-bes \
  --security-policy=prod-waf --global

# 啟用 Adaptive Protection
gcloud compute security-policies update prod-waf \
  --enable-layer7-ddos-defense

常見陷阱與權衡

考試最愛邊邊角角，以下是高頻陷阱：

• Cache hit 不過 WAF。 對 Cloud CDN backend 要 edge policy + backend policy 雙層才完整。
• Priority 留間距很重要。 用 1000、2000、3000……才能事後插隊不必整批重編號。
• CEL 上限 2048 字元。 過長的表達式在 policy 更新時才會被拒絕，不是建立規則當下——先 preview 測試。
• enforceOnKey: ALL 的 rate-based ban 會把一個流氓 IP 變成自殘 DDoS。一定要選 IP 或 XFF_IP。
• Adaptive Protection 延遲。 建議需要數小時的 baseline；不要期望第一天就能保護。
• Plus 等級的最低承諾是年度的。 在攻擊當下從 Standard 切到 Plus 不會回溯給你帳單保護。

Cloud Armor 部署最佳實踐

PCNE 對齊的 production 級 Cloud Armor 上線範本：

Policy 配置

• 每個 backend service 一份 backend security policy（不要共用大政策）。
• 每個對外 Cloud CDN backend bucket 一份 edge security policy。
• 保留 priority 區段：0–999 白名單（公司 IP、健康檢查）、1000–1999 預先配置 WAF、2000–2999 自訂 CEL、3000–3999 rate-based ban、9000–9999 geo 與 threat feed，預設規則 allow。

上線紀律

• 每條新規則先以 --preview 模式上線。
• 觀察日誌至少 7 天。
• 對誤判過多的簽章調整 opt_out_rule_ids。
• 拿掉 --preview，再觀察 24 小時，然後處理下一條規則。

可觀測性

• 把 LB 請求日誌串到 BigQuery，用 SQL 做事件回溯。
• Adaptive Protection 警報串到 Pub/Sub → PagerDuty。
• 把 loadbalancing.googleapis.com/https/request_count 指標、按 enforcedSecurityPolicy.outcome=DENY 過濾做成儀表板。

實戰案例：Black Friday DDoS 防禦

一家零售客戶在 Black Friday 同時面臨撞庫攻擊與 Layer 7 HTTP 洪水流量。PCNE 正解的架構：

1. Global External Application LB，/static/* 啟用 Cloud CDN，origin 部署在 us-central1 與 europe-west1。
2. Edge security policy 掛在 CDN backend bucket：擋下 origin.region_code 不在出貨國家清單內的流量。
3. Backend security policy 搭配 Managed Protection Plus：
   • Priority 1000：evaluatePreconfiguredExpr('sqli-v33-stable') deny。
   • Priority 1100：evaluatePreconfiguredExpr('xss-v33-stable') deny。
   • Priority 2000：/login 上的 rate-based ban（300 req / 60 秒，ban 600 秒），key 為 XFF_IP。
   • Priority 3000：evaluateThreatIntelligence('iplist-tor-exit-nodes') deny。
   • Priority 9000：Adaptive Protection 自動建議（preview → 核准後 enforce）。
4. IAP 放在 /admin 路徑前，提供 SSO + 2FA。
5. reCAPTCHA Enterprise 放在 /checkout，CEL 在分數 < 0.4 時擋下。

攻擊開始時，Adaptive Protection 在數分鐘內標出 0.92 confidence 的 signature；on-call 把它從 preview 切到 enforce；Cloud Logging 顯示 deny 比例飆升；帳單保護吸收 LB 大量回應 429 造成的合法 egress 超額。

Cloud Armor 考試重點

PCNE Cloud Armor 題目反覆出現的點：

• Cloud Armor 只附掛在 External Application LB 與 External Proxy Network LB。Internal LB 與 Passthrough LB 是錯誤答案。
• 預先配置 WAF 規則基於 OWASP ModSecurity CRS v3.3，不是 OWASP Top 10（Top 10 是 分類 清單，CRS 才是實際簽章包）。
• Edge security policy 只支援 IP、Geo 與 HTTP method，沒有 body 檢查。
• Adaptive Protection 需要 Managed Protection Plus 與 backend policy。
• DDoS 帳單保護 是 Plus 等級獨有；Standard 等級仍有 DDoS 清洗但沒有費用保證。
• Cloud CDN cache hit 略過 backend security policy；要做全域攔截請用 edge policy。
• Rate-based ban 預設 key 是 IP；若 client 在另一層 CDN 後面，要切換到 XFF_IP。
• Hybrid NEG 讓 Cloud Armor 能保護地端與其他雲（包括 AWS）的後端。

常見問題 (FAQ)

Backend security policy 與 edge security policy 有什麼差別？

Backend policy 掛在 backend service 或 backend bucket 上，在 Cloud CDN cache lookup 之後 跑，支援完整的 WAF、CEL 與 rate-based ban。Edge policy 掛在 backend bucket 或啟用 CDN 的 backend service 上，在 Google PoP 先於 cache 跑，只支援 IP、Geo 與 HTTP method 比對。當你需要同時擋下被污染 cache hit 的全域 geo block，就要用 edge；OWASP 簽章則用 backend。

什麼時候該升級到 Managed Protection Plus？

下列任一條件成立時就升級：面臨可信的 DDoS 風險且需要帳單保護、受保護 backend service 超過 ~10 個（訂閱基數攤平後划算）、需要 Adaptive Protection 的貝氏 ML、需要超過 10 筆項目的 named IP list、需要 Google 策劃的威脅情報資料源（Tor exit node、公有雲、已知惡意 IP）。

Cloud Armor 會檢查 request body 嗎？

只有在 policy 啟用 jsonParsing: STANDARD 後，且僅針對 JSON 請求 body、預設上限 8 KB（可調）才會檢查。檢查會增加延遲，建議只在接受 JSON POST/PUT 的路徑（例如 /api/）開啟，靜態資源路徑不要開。

Cloud Armor 可以保護位於 AWS 或地端的後端嗎？

可以，透過 hybrid NEG（走 Cloud Interconnect 或 Cloud VPN）或 Internet NEG（公網 FQDN）。把 NEG 掛在 Global External Application LB 的 backend service 上、再掛 Cloud Armor，同樣的 WAF + DDoS 防護就會生效。Adaptive Protection 也能正常運作，因為它學的是請求形狀、與 origin 位置無關。

Cloud Armor 與 Cloud CDN 怎麼組合？

Edge security policy 在 PoP 先跑。若請求命中 cache，Cloud CDN 直接回應——backend security policy 對 cache hit 完全看不到。Cache miss 時，請求才會流到 LB，backend security policy 才會跑（WAF、CEL、rate-based ban），然後才回源。意味著快取內容站台的 WAF 只保護到 5–20% 的請求；全域攔截一定要用 edge policy。

/login 的撞庫防護用哪一組 rate-based ban 設定？

production 常見：每 60 秒每個 XFF_IP 上限 300 個請求、ban 600 秒，並用 CEL 限定範圍 request.path == '/login' && request.method == 'POST'。這只會在登入端點 ban 違規 IP、用 X-Forwarded-For IP（前面再掛一層 CDN 時正解）、且自動到期，被 NAT 共享的使用者之後可以恢復。

為什麼 Adaptive Protection 第一天沒抓到我的攻擊？

Adaptive Protection 的貝氏模型需要每個 backend service 累積數小時到數天的 baseline 才能建立可用的正常分佈。全新 backend 的 baseline 很弱，會 under-fire 或 over-fire。建議新服務上線後先讓 Adaptive Protection 跑 preview 幾天，調好門檻再切到 enforce。

合法使用者被 Cloud Armor 擋下時要怎麼排查？

到 Cloud Logging 查 loadbalancing.googleapis.com/requests、用該使用者的 IP 過濾。Log 會包含 enforcedSecurityPolicy.name、enforcedSecurityPolicy.priority（命中哪條規則）、enforcedSecurityPolicy.outcome=DENY。用 priority 回查 policy 找到誤擋規則。如果是預先配置 WAF 規則，用 opt_out_rule_ids 排除具體簽章；如果是自訂 CEL 規則，調整 match 表達式。

相關章節

• pcne-cloud-cdn — 快取策略與和 Cloud Armor 的組合。
• pcne-cloud-load-balancing — 哪些 LB 類型支援 Cloud Armor、哪些不支援。
• pcne-network-security-best-practices — 跨 VPC、IAP、Cloud Armor 的縱深防禦。

延伸閱讀

• Cloud Armor 總覽：https://cloud.google.com/armor/docs/cloud-armor-overview
• Security policy 參考：https://cloud.google.com/armor/docs/security-policy-overview
• Adaptive Protection：https://cloud.google.com/armor/docs/adaptive-protection-overview
• 預先配置 WAF 規則：https://cloud.google.com/armor/docs/waf-rules
• 速率限制：https://cloud.google.com/armor/docs/rate-limiting-overview
• Managed Protection 等級：https://cloud.google.com/armor/docs/managed-protection-overview