一個 Service Account 幾乎能做完所有事的真實案例

Day2 提過一個場景：某企業的 Gemini API 客服機器人，串接用的 Service Account 掛的是專案層級的 roles/editor。這不是特例，是常態——大部分團隊在專案初期為了「先跑起來」，都會圖方便給一個寬鬆角色，等上線後才發現這個 SA 理論上不只能呼叫 Vertex AI，還能刪資料庫、改防火牆規則、建新的運算資源。一旦這組憑證外洩，攻擊面遠遠超出「AI 功能被濫用」。

最小權限設計的第一步：別再用 Basic Roles

GCP 的角色分三層：Basic Roles（Owner/Editor/Viewer，範圍極寬）、Predefined Roles（針對特定服務設計）、Custom Roles（自訂精細權限）。AI 專案的 Service Account 幾乎不該碰 Basic Roles，應該優先從 Vertex AI 的 Predefined Roles 裡挑選範圍夠窄的角色，例如聚焦在「呼叫既有模型端點做推論」而不是「管理整個 Vertex AI 環境」的角色。

待實測提醒：Vertex AI 的 Predefined Roles 清單與各角色包含的權限，會隨 GCP 版本更新調整，正式發布前請直接對照 Vertex AI IAM 官方文件 核對最新角色名稱與權限範圍，避免文章上線後角色名稱已經改版。

分層設計：一個專案不該只有一個 SA

實務上建議依「職能」拆分 Service Account，而不是一個 SA 打天下：

拆分的好處不只是降低單一 SA 外洩的衝擊範圍，也讓稽核時能直接從 Cloud Audit Logs 看出「是哪個職能的身份在做這件事」，而不用回頭猜測。

自訂角色：當 Predefined Role 還是太寬的時候

如果連最窄的 Predefined Role 都還包含用不到的權限，可以用 Custom Role 進一步收斂。例如一個只需要呼叫 aiplatform.endpoints.predict 的服務，不需要連 aiplatform.endpoints.list 或 aiplatform.models.get 都一併給。Custom Role 的維運成本較高（需要自己追蹤權限清單是否隨 API 版本變動），建議只在高敏感場景使用，一般場景先用範圍夠窄的 Predefined Role 即可。

這篇的檢查清單

• [ ] 專案內是否還有掛 roles/editor 或 roles/owner 的 AI 相關 Service Account？
• [ ] 是否依職能拆分了推論、訓練、部署、監控四種 SA？
• [ ] 每個 SA 的權限是否對照過 Vertex AI 官方最新角色文件？

明天處理另一半的問題：就算權限設對了，如果金鑰管理沒做好，一樣白費。