對外的 AI API，等於多了一個新的攻擊面

當企業把 Gemini API 或自建的 Vertex AI Endpoint 包裝成對外服務（例如客服機器人、公開的 API 服務），這個端點就從「內部呼叫」變成「公開攻擊面」。前面幾篇談的 IAM、VPC-SC 管的是內部的存取邊界，但對外服務還需要另一層防線：擋住來自網際網路的掃描、DDoS、惡意流量。這正是 Cloud Armor 的角色。

Cloud Armor 能做什麼

Cloud Armor 是 GCP 的 WAF（Web Application Firewall）與 DDoS 防護服務，掛在 Global External Load Balancer 前面，對進入的流量做規則過濾。對 AI API 場景特別相關的能力包括：

速率限制（Rate Limiting）：防止單一來源在短時間內對 AI API 發送大量請求，這既是防 DDoS，也是防止有心人士用高頻請求對模型做探測式攻擊（例如試探 Prompt Injection 的各種變體）。

地理位置封鎖：如果服務只該對特定地區開放，可以直接在網路層擋掉其他地區的流量，減少不必要的攻擊面暴露。

已知攻擊特徵防護：Cloud Armor 內建的規則集可以防禦 SQL Injection、XSS 等常見 Web 攻擊模式，雖然這些不是針對 LLM 的攻擊，但如果你的 AI 服務前端還有傳統 Web 應用邏辯（例如儲存對話記錄的資料庫），這層防護依然必要。

自訂規則對應 AI 特定風險：可以針對「單一 IP 短時間內大量呼叫」「特定 payload 特徵」設計自訂規則，作為 Prompt Injection 高頻探測攻擊的第一道過濾，但要清楚這只是流量層的粗篩，真正的語意層防禦還是要靠 Model Armor（Week 4 會談）或 System Instruction 設計。

一個常見的誤解

不少團隊以為「Cloud Armor 擋掉了 Web 攻擊，AI API 就安全了」——但 Cloud Armor 是網路層/流量層的防護，它不理解 Prompt 的語意內容，擋不住一個「看起來正常」但語意上是注入攻擊的請求。Cloud Armor 跟 Model Armor（模型層過濾）是互補關係：一個管流量，一個管內容，缺一不可。

這篇的檢查清單

• [ ] 對外的 Vertex AI Endpoint / Gemini API 服務是否都掛了 Cloud Armor？
• [ ] 是否針對 AI API 特性設計了速率限制規則，而非只用預設規則集？
• [ ] 是否清楚 Cloud Armor 防的是流量層，語意層攻擊仍需 Week 4 的 Model Armor 補位？