IAM 設對了，資料還是可能走錯路

Week 2 把身份層的防線建好了：誰能用哪個 Service Account、金鑰怎麼管、憑證怎麼不落地。但身份層防線防的是「誰能呼叫」，防不了另一種風險——一個合法、有權限的身份，把資料從 Vertex AI 搬到一個不該去的地方，例如透過個人帳號的 Cloud Storage bucket 把訓練資料外傳、或是一個被入侵的合法憑證把推論結果导出到外部專案。IAM 管的是「誰」，VPC Service Controls（VPC-SC）管的是「資料能不能跨出這個邊界」——就算身份合法，邊界之外照樣進不去、出不來。

VPC-SC 的核心概念：服務邊界

VPC-SC 建立的是「服務邊界」（Service Perimeter），把一組 GCP 專案圈起來，邊界內的服務（例如 Vertex AI、Cloud Storage、BigQuery）只能彼此溝通，邊界外的請求即使帶著合法憑證，預設也會被阻擋——除非你明確設定了「Ingress/Egress Rule」允許特定的例外流量。

這跟 IAM 是互補而非取代關係：IAM 決定「這個身份有沒有權限呼叫這個 API」，VPC-SC 決定「這個呼叫是不是從邊界內部發起、資料是不是流向邊界內部」。兩者疊加，才能防住「合法身份 + 錯誤邊界」這種單靠 IAM 防不住的情境。

AI 專案適用的典型邊界設計

企業導入 Vertex AI 時，常見的邊界切法是把「訓練資料所在的專案」「Vertex AI 運算所在的專案」「模型產出結果的儲存專案」全部圈進同一個服務邊界，只開放邊界內部服務彼此溝通，並且明確限制哪些例外的 Ingress（進入邊界的流量，例如特定合作夥伴的資料上傳）與 Egress（離開邊界的流量，例如把去識別化後的分析結果匯出給業務單位）需要額外核准。

對金融、醫療這類需要證明「資料未曾離開受控環境」的產業，VPC-SC 提供的邊界證明是稽核時很有力的佐證。

設定概念示意

# 建立一個服務邊界，圈住指定專案，限制 Vertex AI 與 Cloud Storage 的存取範圍

gcloud access-context-manager perimeters create ai_workload_perimeter \

--title="AI Workload Perimeter" \

--resources=projects/PROJECT_NUMBER \

--restricted-services=aiplatform.googleapis.com,storage.googleapis.com \

--perimeter-type=regular

待實測提醒：VPC Service Controls 的設定語法、支援的服務清單（--restricted-services）會持續擴充，發布前請對照 VPC Service Controls 官方文件 確認目前版本，並務必先在 Dry-run 模式（--enforcement-mode=dry-run）測試邊界規則，避免上線後直接擋掉合法的生產流量。

這篇的檢查清單

• [ ] 是否已盤點 AI workload 涉及的所有專案，並評估是否該圈進同一個服務邊界？
• [ ] Ingress/Egress 的例外規則是否都有明確的業務理由與核准紀錄？
• [ ] 邊界規則上線前是否先用 Dry-run 模式驗證過，避免誤擋生產流量？