Cloud Armor：WAF 與 DDoS 防護

Google Cloud Armor 簡介

對於 Professional Cloud Architect (專業雲端架構師) 而言，邊緣端的應用程式安全至關重要。Google Cloud Armor 是 Google 的企業級 Web 應用程式防火牆 (WAF) 與分散式阻斷服務 (DDoS) 防護服務。它利用保護 Google 自身服務（如 Search、Gmail、YouTube）的相同基礎架構來防禦您的應用程式。

白話文解釋 Google Cloud Armor

Cloud Armor 就像是高規格活動入口處的精銳保安團隊。

類比 1 — 夜店保全 (WAF)

想像一家受歡迎的夜店。Cloud Armor 就是門口的保全 (Bouncer)。保全不只是檢查您的身分證，還會觀察您的行為。如果您帶著隱藏的噴漆罐（SQL Injection）或試圖從通風口潛入（Cross-Site Scripting），保全會立即阻止您。他們有一份已知麻煩製造者的「黑名單」（IP Denylists）和一套「場地規則」（Security Policies）。

類比 2 — 防洪堤霸 (DDoS 防護)

DDoS 攻擊 就像是數百萬人突然湧入，試圖同時進入夜店，只為了堵住門口。Cloud Armor 是一個巨大的防洪堤霸。因為它建立在 Google 的全球網路上，它可以吸收足以淹沒普通伺服器的流量「洪水」，過濾掉虛假的「水」（攻擊流量），並讓真正的人進入。

類比 3 — 機器人狙擊手 (Bot Management)

有些訪客不是人，而是試圖買光所有票券再高價轉售的機器人。Bot Management 就像是一名狙擊手，能分辨出真正的真人脈搏與機器的點擊聲。它使用 reCAPTCHA 和行為分析來阻止機器人，而不影響真人的速度。

Cloud Armor 的關鍵功能

1. 具備預設規則的 WAF

Cloud Armor 提供基於 OWASP Top 10 漏洞的預建規則：

• SQL 資料隱碼攻擊 (SQL Injection, SQLi)
• 跨網站指令碼 (Cross-Site Scripting, XSS)
• 遠端檔案包含 (Remote File Inclusion, RFI)
• 本地檔案包含 (Local File Inclusion, LFI)

2. DDoS 防護

• Standard (標準版)： 包含在所有 GCP 客戶服務中。防禦常見的 Layer 3 與 Layer 4 攻擊。
• Managed Protection Plus： 一項訂閱服務，提供進階的 Layer 7 防護、自適應防護（基於機器學習）以及 DDoS 成本保護（針對攻擊期間產生的擴充費用提供抵免）。

3. 自適應防護 (Adaptive Protection)

Cloud Armor 使用機器學習分析您的正常流量模式。如果偵測到異常，它會自動建議新的安全規則，在攻擊影響您的服務之前將其封鎖。

4. 速率限制 (Rate Limiting)

透過 IP、Cookie 或 Header 限制使用者（或機器人）每秒/每分鐘可發送的請求數量，防止後端不堪重負。

5. Bot Management 與 reCAPTCHA Enterprise

與 reCAPTCHA 整合，過濾可疑流量並封鎖已知的惡意機器人，同時允許搜尋引擎爬蟲通過。

Cloud Armor 安全政策 (Security Policies)

政策是規則的集合，您將其附加到 HTTP(S) Load Balancer 的 Backend Service。

• 優先級 (Priority)： 規則按從低到高的數字進行評估（例如，優先級 1000 的規則會在 2000 之前評估）。
• 比對 (Matching)： 規則可以根據 IP 範圍、區域（地理區域封鎖）或複雜表達式（例如 request.headers['user-agent'].contains('BadBot')）進行比對。
• 動作 (Actions)： 允許 (Allow)、拒絕 (Deny，回傳 403、404 或 502)、速率限制 (Rate Limit) 或重導向至 reCAPTCHA。

邊緣安全架構 (Edge Security Architecture)

為了實現穩健的架構，Cloud Armor 應該作為第一道防線：

1. Global HTTP(S) Load Balancer： 在 Google 邊緣節點接收流量。
2. Cloud Armor： 在流量進入您的 VPC 之前 進行檢查。
3. VPC 防火牆： 限制存取，使您的後端僅接受來自 Load Balancer IP 範圍的流量。
4. 後端 (GCE, GKE, Cloud Run)： 處理經過清洗、授權的流量。

自適應防護 (Adaptive Protection)：貝氏異常偵測對抗 L7 DDoS

Adaptive Protection 是 Managed Protection Plus 的旗艦級機器學習防禦能力。與比對已知特徵的靜態 WAF 規則不同，它會針對每個安全政策建立 流量基準模型（通常需要 1 小時以上的流量才能穩定），使用 貝氏分類器 (Bayesian classifier) 分析請求屬性 — URI 模式、來源 IP、地區、User-Agent、JA3/JA4 指紋、ASN 與 HTTP Header。

警報處理流程

1. 流量基準： 持續觀察建立每個 backend service 的「正常」機率分佈。
2. 異常分數： 當請求分佈偏離（例如某個 ASN 突然大量打 /login），Adaptive Protection 會發出帶有 信心分數 (0.0–1.0) 與 似然度 (likelihood) 的警報。
3. 建議規則： 警報附帶 預先格式化的 Cloud Armor 規則表達式（如 request.headers['user-agent'].contains('python-requests') && origin.region_code == 'XX'）以及 影響基準比率 (impacted baseline ratio)，顯示此規則會誤擋多少正常流量。
4. 維運動作： 在 Security Command Center 或 Cloud Logging（jsonPayload.enforcedSecurityPolicy.adaptiveProtection）中審查後，可選擇自動套用（透過 Cloud Functions 訂閱 Log Sink 觸發）或人工掛上規則。

調整選項

• 每個安全政策設定 adaptiveProtectionConfig.layer7DdosDefenseConfig.enable = true。
• ruleVisibility = STANDARD | PREMIUM — Premium 會揭露攻擊特徵與 impacted-baseline 細節。
• 警報門檻： 預設信心分數 ≥ 0.5 即觸發；偵測過於敏感可調高，要做高精度自動緩解可調低。

預設 WAF 規則：ModSecurity OWASP CRS 對應表

Cloud Armor 內建的預設 WAF 規則衍生自 OWASP ModSecurity Core Rule Set (CRS) 3.3。每個規則群組透過 evaluatePreconfiguredWaf() 表達式公開，並提供可調整的 敏感度等級 (sensitivity level 0–4)，以及選用的 opt_in_rule_ids / opt_out_rule_ids 進行細粒度控制。

規則群組目錄（節錄）

規則表達式範例

gcloud compute security-policies rules create 1000 \
  --security-policy=prod-armor \
  --expression="evaluatePreconfiguredWaf('sqli-v33-stable', {'sensitivity': 1})" \
  --action=deny-403

敏感度調整取捨

• Level 1（關閉偏執模式）： 誤報率最低 — 只有 ModSecurity paranoia-level-1 的規則會觸發。處理結構化 payload 的正式環境 API 預設用這層。
• Level 2–3： 加入啟發式規則（URL-encoded payload、異常字元類別）。建議用於靜態網站或行銷頁面。
• Level 4（開啟偏執模式）： 啟用完整 CRS paranoia level — 預期合法的 base64 上傳、GraphQL 查詢或富文字編輯器會誤報。先啟用 preview 模式 至少 7 天，再用 opt_out_rule_ids 調整。

rate-based-ban 規則：超越單純節流

Cloud Armor 將速率限制分成兩種動作：throttle（丟棄超量請求、放行合法請求）與 rate-based-ban（一旦超過門檻就將該違規 key 完全封禁一段時間）。

rate-based-ban 結構

gcloud compute security-policies rules create 2000 \
  --security-policy=prod-armor \
  --expression="true" \
  --action=rate-based-ban \
  --rate-limit-threshold-count=100 \
  --rate-limit-threshold-interval-sec=60 \
  --ban-duration-sec=600 \
  --ban-threshold-count=10000 \
  --ban-threshold-interval-sec=600 \
  --conform-action=allow \
  --exceed-action=deny-429 \
  --enforce-on-key=IP

enforce-on-key 選項

• IP — 預設值；多數情境用這個。
• ALL — 單一全域計數器；幾乎不會用，除了「事故期間全面熔斷」。
• HTTP_HEADER + key 名稱 — 依 X-API-Key 封禁（IP 被 NAT 共用的已驗證 API 最適合）。
• XFF_IP — 信任最左側的 X-Forwarded-For（僅限您自己掌控的 CDN/proxy 終結時）。
• HTTP_COOKIE — 以 session 為單位封禁。
• HTTP_PATH — Path-aware burst（讓 /login 與 /health 分開計量）。
• SNI — 萬用憑證下依 hostname 封禁。
• REGION_CODE — 以國家為範圍封禁（少用）。

雙層保護模式

穩健的登入端點會 疊加多條規則：

1. 優先級 1000 — throttle 每 IP 每分鐘 10 次打 /login（平緩突發）。
2. 優先級 1100 — rate-based-ban 每 IP 每 10 分鐘超過 100 次則封禁 1 小時（擋暴力破解）。
3. 優先級 1200 — rate-based-ban 依 HTTP_HEADER:X-API-Key 每小時 500 次（攔截跨 IP 的 credential stuffing）。

throttle 處理合法的重試風暴（使用者連點兩下）；ban 處理持續性攻擊者。

Edge Security Policies 與 Cloud CDN 整合

Cloud Armor 提供兩種安全政策 類型：

• CLOUD_ARMOR（後端安全政策）— 掛在 backend service 上。在 LB 完成 URL map 路由與內容選擇 之後 評估。
• CLOUD_ARMOR_EDGE（邊緣安全政策）— 掛在前端為 Cloud CDN 的 backend service 或 backend bucket 上。在 Google 邊緣於 CDN 快取查找 之前 評估。

為何 edge security policies 對 CDN 很重要

當 Cloud CDN 從邊緣快取回應時，請求根本不會到達源站 — 傳統的後端安全政策只在 cache miss 時觸發。攻擊者持續打一個已快取的 /popular-asset.jpg 會吃掉邊緣頻寬卻完全不會踩到您的 WAF。邊緣安全政策在快取層本身就攔下請求，補上這個缺口。

邊緣政策支援的能力

• IP allow/deny（CIDR、IP lists、Address Groups）。
• 地理位置封鎖 (origin.region_code)。
• ASN 封鎖 (origin.asn)。
• Request method 過濾。
• 邊緣不支援： 預設 WAF 規則、Adaptive Protection、rate limiting（這些都只能用後端政策 — 因為它們需要邊緣快取層為了效能會略過的完整 L7 檢查）。

分層架構

Client → Edge Security Policy (IP/geo 封鎖) → Cloud CDN cache
                                                     ↓ (miss)
                                        Backend Security Policy (WAF、rate limit、Adaptive)
                                                     ↓
                                                 Backend Service

被封禁 ASN 的爬蟲在邊緣就被丟掉，CDN 完全不會產生費用。合法的 cache miss 則會經過完整 WAF 再進到 origin。設定方式：gcloud compute security-policies create my-edge --type=CLOUD_ARMOR_EDGE，再用 --security-policy=my-edge --edge-security-policy=my-edge 掛到 backend bucket/service。

IAP 與 Cloud Armor：內部應用程式的縱深防禦

Identity-Aware Proxy (IAP) 在 LB 層用 Google 身分驗證使用者，而 Cloud Armor 在驗證之前過濾流量。兩者結合可為內部 / 員工應用程式建立 雙層邊界。

評估順序

對於同時啟用兩者的外部 HTTPS LB：

1. 請求到達 Google 邊緣。
2. Cloud Armor 邊緣政策（如有掛載）評估 IP / 地理位置。
3. Cloud Armor 後端政策 評估 WAF、rate limit、Adaptive Protection。
4. IAP 介入：檢查有效的 _iap cookie，或啟動 OAuth2 流程。
5. 通過 IAP 驗證的請求會被注入 x-goog-iap-jwt-assertion Header。
6. Backend service 收到帶有 IAP 簽章 JWT 的請求。

為何兩者都需要？

• IAP 假設使用者已能到達 LB。沒有 Cloud Armor，攻擊者依然能對 IAP 的 OAuth callback 發動 DDoS、credential stuffing，或掃描設定錯誤的後端。
• Cloud Armor 不知道使用者身分。它無法執行「只允許 Engineering 群組的員工打 /admin」這種規則 — 那是 IAP + Cloud Identity groups 的工作。

內部管理後台模式

• Cloud Armor： 地理位置限制為公司所在區域、對 /login 做 rate limit、封禁已知惡意 ASN。
• IAP： 限制存取對象為 group:[email protected]。
• 後端： 驗證 x-goog-iap-jwt-assertion 簽章；拒絕沒有此 Header 的請求（避免攻擊者繞過 IAP 直接打後端 — 這也是前述 VPC 防火牆鎖定的必要性）。

這套架構讓外部攻擊者必須穿透三道獨立控制：邊緣 IP 過濾、WAF / rate limit、以及帶群組強制的 Google OAuth。

Hybrid NEG + Anycast：保護地端與多雲源站

Cloud Armor 的保護不限於 GCP 託管的後端。透過 Hybrid Connectivity Network Endpoint Group (Hybrid NEG)，外部 HTTPS LB 可前綴：

• 地端機房（透過 Cloud Interconnect / Cloud VPN 連通）。
• AWS / Azure 工作負載（透過網際網路端點或 interconnect）。
• 想放到自家 WAF 後面的第三方 SaaS。

架構流程

Anycast IP (Google Global LB) → Cloud Armor → Hybrid NEG (FQDN 或 IP:port)
                                                     ↓
                                       Cloud Interconnect / 網際網路
                                                     ↓
                                          地端 F5 / AWS ALB / Azure App GW

Google Frontend (GFE) 終結公開的 Anycast IP，吸收 L3/L4 流量洪水。Cloud Armor 對 L7 payload 跑 Adaptive Protection 與 WAF 規則。只有經過清洗的流量會透過您的 Interconnect 出向到地端源站 — 意思是您的地端網路完全不會看到原始 DDoS，私網頻寬也不會被打爆。

Anycast 優勢

Google 的 Anycast IP 從 全球 180+ 個 PoP 廣播。1 Tbps 的容量型攻擊會自動被切散到各個 PoP — 沒有單一入口會被打滿。這也是為什麼即使是極小的地端源站（一條 1 Gbps Interconnect）也能撐過數百 Gbps 的攻擊：攻擊在邊緣就被過濾，只有合法流量會經過 Interconnect。

注意事項

• Hybrid NEG 後端需要在地端防火牆放行 Google LB 健康檢查範圍 (130.211.0.0/22、35.191.0.0/16) 才能讓健康探測通過。
• 延遲下限 = client → 最近的 GFE PoP + GFE → 地端源站。第二段受您的 Interconnect 拓樸限制，所以要挑離 DC 近的 PoP。
• Cloud CDN 預設不會快取 Hybrid NEG 的回應；如果內容可快取，需在 backend service 上明確啟用。

Managed Protection Plus vs Standard：方案比較

Cloud Armor 提供兩種方案。選錯不是讓靜態網站超額付費，就是讓金融 API 暴露不足。

Standard（HTTPS LB 內建）

• L3/L4 DDoS 防護： 容量型攻擊（UDP flood、SYN flood、reflection）在 GFE 吸收 — 永遠啟用、無需設定。
• 人工安全政策： IP/CIDR allow-deny、地理位置封鎖、自訂 CEL 表達式。
• 預設 WAF 規則： OWASP CRS 3.3 規則群組（SQLi、XSS 等）— 需人工掛上。
• rate limit： throttle 與 rate-based-ban 動作。
• 邊緣安全政策： 支援。
• 費用： 平台 $0；每政策 $1/月 + 每規則 $0.75/月 + 每百萬請求 $0.75 評估費。

Managed Protection Plus（訂閱方案）

• 包含 Standard 全部功能，再加上：
• Adaptive Protection（L7 ML 防禦） — 貝氏異常偵測與自動產生的規則建議。
• Curated detections： Google SRE 維護的新 CVE 規則（Log4Shell 等級）會在揭露後數小時內部署。
• Premium 規則可視度： Security Command Center 中提供完整特徵分析。
• Threat Intelligence： Tor exit node、已知惡意 IP、公有雲、搜尋引擎等具名 IP 清單。
• DDoS 帳單保護： 對 Cloud Armor 確認的攻擊期間因自動擴充與出向所產生的費用提供 服務抵免 — 為您把「DDoS 變成天價帳單」的風險封頂。
• 24/7 DDoS Response Team (DRT) 支援 處理實時事件。
• 費用： 每月 $3,000 底價 + 每受保護資源每月 $30（通常 1 年合約）。

決策對照表

考試速記

PCA 情境只要出現以下任一關鍵字：「machine learning detection」、「DDoS 攻擊期間的成本」、「curated threat intel」、「24/7 應變團隊」、「zero-day 緩解」 — 答案就是 Managed Protection Plus。如果只提到 OWASP、SQLi、地理封鎖或 rate limit，Standard 方案 才是便宜的正解。

常見問題 — Cloud Armor WAF 與 DDoS 防護

Q1. 如果我已經有 VPC 防火牆，還需要 Cloud Armor 嗎？

需要。 VPC 防火牆僅檢查 IP 地址和連接埠（Layer 3/4）。它們無法查看 HTTP 請求「內部」以阻止 SQL Injection 或 XSS 等行為。您需要 Cloud Armor 來提供 Layer 7 防護。

Q2. Cloud Armor 可以封鎖來自特定國家的流量嗎？

可以。您可以使用地理位置封鎖 (Geo-blocking) 規則，根據 IP 地址的地理來源允許或拒絕流量。

Q3. Cloud Armor 可以與 Cloud Storage (GCS) 搭配使用嗎？

可以。如果 GCS 存儲桶被配置為 HTTP(S) Load Balancer 的後端，則可以使用 Cloud Armor。這常用於保護靜態網站或私有資產。

Q4. 什麼是「自適應防護 (Adaptive Protection)」？

這是一項由機器學習驅動的功能，透過學習應用程式的正常行為並在偏離時發出警報，來偵測「零日漏洞」或複雜的攻擊。

Q5. 我如何查看 Cloud Armor 封鎖了什麼？

所有的比對和封鎖紀錄都會儲存在 Cloud Logging 中。您可以在 Cloud Monitoring 中建立資訊主頁，以追蹤攻擊趨勢和規則成效。

架構師最終提示

在 PCA 考試中，Cloud Armor 是您的**「邊緣防禦 (Edge Defense)」解決方案。如果場景提到「OWASP」、「Layer 7 攻擊」、「SQL Injection」或「Load Balancer 端的 DDoS」，Cloud Armor 就是答案。請記住，它需要 HTTP(S) Load Balancer**（標準版或全球版）。如果問題涉及「緩解 DDoS 攻擊期間的成本」，答案則是 Managed Protection Plus。