簡介
VPC Service Controls (VPC SC) 是 Google Cloud 對「API 層資料外洩問題」的解答。IAM 回答「誰可以呼叫這個 API」，而 VPC SC 回答「在哪些網路情境下、可以對哪些特定資源呼叫這個 API」。它將 Cloud Storage、BigQuery、Pub/Sub、Cloud KMS、AI Platform 等代管服務包進一個稱為服務周邊 (service perimeter) 的邏輯邊界。任何跨越周邊的請求，只要沒有明確的 ingress 或 egress 規則允許，都會在 API 入口被拒絕，無論呼叫者的 IAM 權限有多強。
對 PCNE 考試而言，VPC SC 幾乎在每一道「混合雲 + 敏感資料 + 私有連線」的情境題都會出現。你會看到結合 restricted VIP (199.36.153.4/30)、地端的 Private Google Access、Cloud DNS forwarding zone、dry-run 與正式 enforced 周邊，以及搭配 Access Level 的 ingress 規則的題目。掌握規則語意、perimeter bridge 模型，以及排錯日誌欄位，是讓你在周邊題拿到 4/4 而不是 2/4 的關鍵差異。
VPC SC 是在 Google API 大門強制執行，而不是在你的 VPC 內部。即使請求來自全球外部 IP，只要周邊的 ingress 規則透過 Access Level 允許，仍可放行；反之，即使請求來自你的 VPC，只要來源專案不在周邊內，仍會被拒絕。請永遠在 API 層思考 VPC SC，而非在網路層。
服務周邊概念
周邊到底裝了什麼
服務周邊在 Organization 範圍內，透過 Access Context Manager 建立。每個周邊宣告三份清單：受保護的資源 (resources)（專案編號，現在也支援 VPC 網路）、被周邊包覆 API 介面的受限服務 (restricted services)，以及周邊內部 VM 被允許呼叫的VPC 可存取服務 (VPC accessible services)。一個典型的周邊路徑長這樣：accessPolicies/<policyId>/servicePerimeters/<name>，gcloud 用 gcloud access-context-manager perimeters describe <name> 查詢。
保護單位是專案，不是網路
對多數服務而言，保護單位是專案編號，例如 projects/1234567890。當請求打到 storage.googleapis.com 時，VPC SC 會查目的 bucket 所屬的專案，問該專案是否在某個周邊內。若是，請求必須來自同一周邊內部或被 ingress 規則允許。把專案加入周邊不需要修改任何應用程式碼，強制執行是在 API 層透明完成的。
Restricted services 清單
並非所有 Google API 都支援 VPC SC。restricted services 欄位列舉了哪些 API 會被周邊阻擋，例如 storage.googleapis.com、bigquery.googleapis.com、pubsub.googleapis.com、cloudkms.googleapis.com、aiplatform.googleapis.com。完整支援清單發布在 cloud.google.com 上，這是唯一可信來源——服務常在「supported / beta / GA」之間移動。不支援的服務（部分 Marketplace API、某些管理 API）無法被 VPC SC 保護，需要改用 Organization Policy 等其他控制。
服務周邊 (service perimeter) 是 Organization 範圍的邏輯邊界，包覆一份專案編號清單與一份受限服務 API 清單，任何跨邊界呼叫都會被拒絕，除非有 ingress/egress 規則、perimeter bridge 或 Access Level 明確允許。
Ingress 規則
Ingress 規則結構解剖
Ingress 規則讓周邊外的呼叫者進入周邊內的資源。每條 ingress 規則分兩半。ingressFrom 區塊宣告來源：identities（user:、serviceAccount:、group: 的清單）、identityType（ANY_IDENTITY、ANY_USER_ACCOUNT、ANY_SERVICE_ACCOUNT 三選一），以及 sources 欄位指向 accessLevel（例如 accessPolicies/123/accessLevels/corp_ip）或 resource（例如 projects/9876543210）。ingressTo 區塊宣告目的：operations（每個服務的 method selector 列表，例如 storage.googleapis.com 加上 methodSelectors 篩出 google.storage.objects.get），以及 resources（周邊內哪些專案可達，或 * 代表全部）。
具體範例
常見模式是「允許我們的 CI/CD 服務帳號從公司 IP 範圍讀取建置產物 bucket」。對應一條 ingress 規則：ingressFrom.identities = ["serviceAccount:[email protected]"]、ingressFrom.sources.accessLevel = corp_ip、ingressTo.operations 列出 storage.googleapis.com / google.storage.objects.get 與 google.storage.objects.list、ingressTo.resources = ["projects/1234567890"]。少了 access level 會拒絕；少了 operation selector 會拒絕；兩者同時存在才會放行。
為什麼 ingress 規則取代了「周邊上的 access levels」
舊版 VPC SC 周邊只支援一個平坦的 accessLevels 清單，作用於整個周邊。現代周邊使用精細的 ingress 規則，依 identity、source、目標 operation、目標 resource 分別限定——提供每個 API、每個專案層級的精準控制。新周邊請一律用 ingress 規則建模，而不要用舊版的全域 access level 清單，更不要以為單一個 Access Level 就能授權周邊內所有服務。
撰寫 ingress 規則時，先用白話寫出「誰、從哪、做什麼、對哪個資源」，再把每個子句對應到 identities、sources、operations、resources。大多數被拒絕的請求都是因為這四個欄位裡有一項漏寫。
Egress 規則
反方向流動
Egress 規則讓周邊內的呼叫者存取周邊外的資源。結構與 ingress 對稱：egressFrom 列出呼叫端身分與 identity type，egressTo 列出周邊外的 externalResources、operations 或 resources。典型用例是：跑在受保護分析專案內的 Dataflow worker，需要讀取另一個 Organization 公開分享的 BigQuery 資料集。
External resources 與 Service Directory
egressTo.externalResources 欄位是唯一能表達「這個地端端點透過 Private Service Connect 存取」或「這個第三方端點註冊在 Service Directory 裡」的方式。對於 Service Directory 撐起的 PSC 端點，要在 egress 規則中以 //servicedirectory.googleapis.com/projects/.../endpoints/... 列出端點；當流量從周邊內的 VPC egress 到周邊外的私有端點時必須如此。否則對你自己的 PSC 端點呼叫，可能會出現 NO_MATCHING_ACCESS_LEVEL 違規而被拒。
Egress + restricted VIP 合力鎖死對外流量
Egress 規則阻擋了像是「周邊內 VM 被入侵後上傳資料到攻擊者的 Cloud Storage bucket」這類外洩路徑。搭配下面要講的 restricted VIP，再加上 Cloud DNS response policy 讓 *.googleapis.com 解析到 restricted VIP，周邊內 VM 連上 Google API 的唯一路徑就是受限路徑，周邊規則因此生效。透過 public VIP 的「後門」完全不存在。
Egress 規則與 ingress 規則並非自動對稱，也不會自動產生反向路徑。若周邊 P 的專案 A 要呼叫周邊 Q 的 BigQuery 專案 B，你需要在 P 設 egress 規則且在 Q 設 ingress 規則。雙方都要同意，或改用 perimeter bridge。
Perimeter Bridge
設計上雙向且對稱
Perimeter bridge 是特殊類型的周邊，內含兩個以上的既有周邊，讓這些成員周邊裡的資源能自由互相呼叫受限服務。Bridge 是雙向（流量雙向流動）且對稱（橋裡所有成員彼此都能對話——不能只允許 A 呼叫 B 卻禁止 B 呼叫 A）。若需要不對稱流量，請改用 ingress/egress 規則。
10 個 bridge 的上限
一個專案最多能加入 10 個 perimeter bridge。這是硬性配額，常絆倒「每個跨團隊整合就開一條 bridge」的擴展方式。考試很愛考這個數字，也愛搭配「你有 12 個團隊，每個都要彼此分享資料怎麼辦」。答案通常是「整併成一個 regular perimeter 配 ingress/egress 規則」，而不是「開 N 條 bridge」。
何時用 bridge、何時用 ingress/egress
當兩個周邊需要廣泛、對稱的合作時 bridge 最合適——例如「資料工程」周邊與「資料分析」周邊，兩側多數專案都要互相呼叫 BigQuery 與 Cloud Storage。當只有特定身分或特定 operation 要跨越時，ingress/egress 規則更好——例如只有單一 CI 服務帳號要寫入建置產物。Bridge 用粒度換簡潔，規則用簡潔換粒度。
Perimeter bridge 不會擴展成員的受保護資源集合。它只允許跨周邊通訊。把專案 A、B 放進 bridge 不會保護它們——它們仍須各自是某個 regular perimeter 的資源。「只靠 bridge 來保護」是常見誤設，會讓專案毫無防護。
Dry-Run 模式
Spec 與 status 的差異
每個服務周邊都有兩個狀態：正式 enforced 設定（API 中稱為 status）與 dry-run 設定（API 中稱為 spec）。兩者都在同一個 perimeter 資源中宣告。Enforced 的 status 會真的拒絕流量；dry-run 的 spec 只會記錄「本來會被拒絕」而不會真的擋掉呼叫。這種雙狀態設計，讓你能在正式環境安全地灰度上線周邊變更。
Dry-run 灰度上線手冊
建議流程：（1）只先建立含 spec 區塊與 useExplicitDryRunSpec=true 的周邊；（2）讓它在 dry-run 待至少一個完整營運週期，通常 1–2 週；（3）收集所有 metadata.dryRun=true 的 vpcServiceControlsUniqueId 日誌，把每筆獨特的被拒呼叫轉成明確的 ingress 或 egress 規則；（4）dry-run 日誌乾淨後，用 gcloud access-context-manager perimeters dry-run enforce 把 spec 推升為 status。跳過 dry-run，是正式環境把斷線怪到 VPC SC 頭上的頭號原因。
Enforce 與 replace
dry-run enforce 會把 spec 複製進 status；dry-run drop 會丟棄 spec。也可以用 dry-run update 反覆迭代 spec 而不動到 enforced 狀態。考試很愛考這個區別：「我想測新的周邊規則卻不想弄壞正式環境」（用 spec），與「我想回滾到先前設定」（尚未 enforce 的話用 dry-run drop；已 enforce 則直接更新 status）。
Dry-run 模式 = spec 區塊 + useExplicitDryRunSpec=true。正式 enforced 模式 = status 區塊。Dry-run 日誌帶有 metadata.dryRun=true。用 gcloud access-context-manager perimeters dry-run enforce 推升正式。正式環境推升前先做 1–2 週的 dry-run 浸泡。
Restricted VIP
199.36.153.4/30 範圍
Restricted virtual IP 是 Google 管理的位址範圍 199.36.153.4/30，只暴露支援 VPC SC（受限）的服務。它的姊妹 private VIP 是 199.36.153.8/30，暴露所有 Google API 但不強制 VPC SC；要讓流量受周邊規則約束，請用 restricted VIP。兩者都能從 Google 網路內存取，並可透過 Cloud Interconnect 或 Cloud VPN 從地端網路存取，前提是設定好地端的 Private Google Access。
Cloud DNS 設定
要強制流量走 restricted VIP，請建立 googleapis.com 的 Cloud DNS private zone，裡面放一筆 CNAME *.googleapis.com → restricted.googleapis.com.，以及 restricted.googleapis.com. 的 A 紀錄指向 199.36.153.4、199.36.153.5、199.36.153.6、199.36.153.7 這四個位址。同樣的設定也可以用 Cloud DNS response policy 為需要覆蓋預設公開解析的 VPC 套用。地端則設定地端 DNS 把 googleapis.com 的查詢，透過 inbound forwarder 轉到 Cloud DNS。
為什麼這對 VPC SC 重要
如果受保護專案內的 VM 把 storage.googleapis.com 解析到 public VIP，呼叫雖然仍會打到受 VPC SC 保護的後端，但網路路徑是經由網際網路，可能破壞你的對外防火牆姿態。強制使用 restricted VIP 能把所有 Google API 流量留在 Google backbone，確保 VPC SC 強制執行一致，且可同時實施 0.0.0.0/0 預設拒絕的 egress 防火牆。「restricted VIP + 周邊 + 預設拒絕 egress」是安全資料分析的標準典範。
Restricted VIP 是 地端 Private Google Access 配合 VPC SC 的 GCP 端必備條件。沒有它，地端流量會打到公開端點，而你的地端網路也許根本連不到，會產生令人困惑的「Policy Denied」日誌。
Access Level 與 Access Context Manager
Access Level 代表什麼
Access Level 定義在 Access Context Manager (ACM) 中，是一個具名、可重複使用的條件集合，評估請求屬性，例如來源 IP CIDR、principal 身分、裝置政策（由 Endpoint Verification 驗證）、必要 signal 類型、區域、時段。BasicLevel 是屬性條件的 AND/OR 組合；CustomLevel 是 CEL 表達式，可存取 origin.ip、origin.region_code、device.is_corp_owned、levels 等欄位。
Access Level 接上 ingress 規則
在 ingress 規則裡，ingressFrom.sources.accessLevel = accessPolicies/<id>/accessLevels/<name> 引用一個 Access Level。Ingress 規則的判定邏輯：「請求符合 = 呼叫身分屬於 identities 且 請求屬性滿足 Access Level 且 目的符合 operations 與 resources」。Access Level 也可以從 IAM Condition 引用，用於單一資源的情境感知存取，但在 VPC SC 內，只有被 ingress 規則引用時才會起作用。
常見 Access Level 模式
三種模式反覆出現：（1）企業 IP access level 列出辦公室與 VPN CIDR，允許來自已知網路的管理存取；（2）裝置信任 access level 要求 device.is_corp_owned=true 與 device.encryption_status=ENCRYPTED，給通過 Endpoint Verification 的筆電；（3）區域 access level 只允許來自核可國家代碼的請求，以滿足資料主權政策。將三者合併在同一個 CustomLevel CEL 表達式裡，是敏感資料集常見的做法。
Policy Denied 日誌排錯
日誌住在哪裡
VPC SC 拒絕事件以 policy_denied 稽核日誌寫入 Cloud Logging。相關過濾條件為 protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog" AND protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"。每筆紀錄都帶一個 vpcServiceControlsUniqueId 欄位，這是整個系統裡最有用的識別碼——你把它交給 Google Cloud Support，他們就能跨服務追查拒絕事件，而不必你交出專案編號或 IAM 細節。
解讀 violationReason
稽核 metadata 的 violationReason 列舉了原因。常見值：NO_MATCHING_ACCESS_LEVEL（呼叫端沒對到任何 ingress 規則的 Access Level）、RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER（沒有 egress/ingress 配對或 bridge 的跨周邊呼叫）、NETWORK_NOT_IN_SAME_SERVICE_PERIMETER（使用了周邊外的 VPC）、SERVICE_NOT_ALLOWED_FROM_VPC（被呼叫的服務不在 VPC accessible services 內）、METHOD_NOT_ALLOWED_FROM_OUTSIDE（ingress 規則允許服務但不允許該特定 method）。這些字串可考性高，因為題目常常直接引用日誌行。
Dry-run 除錯循環
Dry-run 模式下同樣的欄位都會出現，但 metadata.dryRun=true 且呼叫不會真的被擋。標準工作流：用 metadata.dryRun=true AND severity=WARNING 過濾日誌，依 (servicePerimeterName, violationReason, principalEmail, resource) 分組，每一群決定要加 ingress 規則、egress 規則，還是修正呼叫端。Cloud Console 的 Troubleshooter 工具（Security → VPC Service Controls → Troubleshooter）能吃進 vpcServiceControlsUniqueId，把同樣的資料漂亮地顯示出來，附上建議的修補方式。
vpcServiceControlsUniqueId 是一條主線，串起使用者看到的 API 錯誤、Cloud Logging 紀錄、Troubleshooter UI 與 Google Support case。請永遠要求使用者在請求被意外拒絕時，先抓下這個 ID 再回報。
VPC Accessible Services
限制 VM 能呼叫哪些服務
在周邊內，VM 的 IAM 授權並不單獨決定它能打哪些 Google API。周邊的 vpcAccessibleServices 區塊可以限制 VPC 流量（周邊內）能呼叫的受限服務子集。設 enableRestriction=true 配 allowedServices=["storage.googleapis.com","bigquery.googleapis.com"] 後，即使 VM 有 Pub/Sub 的 IAM，也不能呼叫 pubsub.googleapis.com，因為來自該 VPC 的 API 呼叫會被 VPC SC 丟棄。
縱深防禦
vpcAccessibleServices 是 ingress 規則的反面。Ingress 限制能進來什麼；VPC accessible services 限制 VPC 來源能往外打什麼。兩者組合成「用不到的就連不到」的姿態：外部攻擊者沒辦法透過盜用憑證打到不該打的服務，被入侵的內部 VM 也無法橫向跳到原本工作負載不該觸及的服務。這正是 VPC SC 之所以是真正的縱深防禦控制，而不只是一份存取清單的原因。
常見 VPC SC 架構
分析周邊搭配地端注入
典型的分析部署用一個周邊包住 BigQuery 專案、Cloud Storage staging 專案、Dataflow runner 專案。地端注入使用「地端 Private Google Access + restricted VIP」。一條 ingress 規則允許地端 ETL 服務帳號從企業 IP Access Level 寫入 staging bucket 並啟動 Dataflow 工作。一條 egress 規則允許 Dataflow worker 服務帳號讀取核准過的外部預訓練模型 bucket。
Hub-and-spoke 與共享服務
當 hub VPC 提供共享服務（DNS、安全掃描、log），spoke VPC 跑業務工作負載時，每個 spoke 專案要嘛各自一個周邊，要嘛共用一個 regular perimeter。跨周邊呼叫 hub（例如呼叫掃描上傳檔案的 Cloud Function）可以用 hub 與每個 spoke 之間的 perimeter bridge，或在 hub 周邊上設個別 ingress 規則，引用 spoke 的專案編號。
白話文解釋（Plain English Explanation）
比喻一：密封的資料中心
想像你公司有一個極機密研究資料中心。IAM 是開門的識別證。但人進去後，員工仍可能把硬碟塞進口袋偷走。VPC Service Controls 就是每個出口都裝的金屬探測器與 X 光機：即使員工拿著合法識別證，沒有為這份檔案、這個目的地簽過「准予攜出」單（egress 規則），就帶不出去。金屬探測器不在乎識別證，它只在乎什麼東西要離開大樓。
比喻二：大使館簽證制度
每個服務周邊是一個邊境封閉的國家。Regular perimeter 是你的母國。Ingress 規則是簽證：誰（哪些身分、從哪個 IP）允許從外面進來、做什麼事（operations）、可以拜訪哪些城市（resources）。Egress 規則是出口許可：誰能離境、去哪、能帶什麼貨。Perimeter bridge 是兩國之間 Schengen 式的開放邊界。Restricted VIP 是唯一的官方機場——所有國際往來必須走它，這樣簽證的章才會真的蓋下去。
比喻三：雙重控管的銀行金庫
status 狀態是上線中的金庫：設錯就真的把客戶鎖在門外。spec 狀態（dry-run）是釘在牆上的建築藍圖：它顯示新的金庫規則「會」造成什麼後果，警衛把每筆「本來會被拒」的事件抄在筆記本（vpcServiceControlsUniqueId）裡，但真正的金庫仍用舊規則。藍圖經過一週審查、每筆被拒事件都被預期或解釋之後，銀行才依藍圖實際改建金庫（dry-run enforce）。
考試重點與陷阱
- 陷阱： 以為有 IAM 就夠了。IAM 阻擋未授權存取；VPC SC 阻擋已授權使用者透過 Google API 把資料偷出去。
- 陷阱： 以為 perimeter bridge 會保護專案。Bridge 只允許跨周邊呼叫，保護仍要靠 regular perimeter。
- 提示： 題目出現「防止資料外洩」、「限制哪些網路能呼叫 BigQuery」、「地端透過 Private Google Access 存取 Cloud Storage」這類字眼時，VPC SC 幾乎一定是答案。
- 提示： 題目引用日誌行帶有
violationReason: NO_MATCHING_ACCESS_LEVEL時，修法是新增或修改某條 ingress 規則所引用的 Access Level——不是改 IAM。 - 必背： Restricted VIP
199.36.153.4/30。Private VIP199.36.153.8/30。每個專案 bridge 上限 10 條。Dry-run =spec。正式 enforced =status。
常見問題 FAQ
Q1 — 可以把不同 Organization 的專案放進同一個周邊嗎？
不行。服務周邊範圍限於單一 Organization，並以該 Organization 內的專案編號引用專案。跨 Organization 的資料分享要在兩側各設 ingress 規則，或走 Analytics Hub 等共享外部路徑。
Q2 — VPC SC 需要額外付費嗎？
沒有每個 API 的附加費。維運成本來自設計周邊、撰寫 ingress/egress 規則、跑一段有意義的 dry-run 期間，以及在混合雲跨網段配置 Cloud DNS 與 restricted VIP。
Q3 — 周邊在 dry-run 待多久才能正式 enforce？
至少一個完整營運週期，通常 1–2 週。目標是抓到每月批次工作、週末備份、罕用的管理工具。dry-run 日誌乾淨後再用 gcloud access-context-manager perimeters dry-run enforce 推升。
Q4 — VPC SC 能保護 Cloud Run、Cloud Functions、App Engine 嗎？
Cloud Run、Cloud Functions 2nd gen 與多個 Serverless 服務都已是受限服務。請以 cloud.google.com 的官方支援清單為準，因為支援服務經常新增，beta 狀態的不要拿來跑正式環境。
Q5 — 在工作負載運行中把專案加入周邊會怎樣？
新的 API 呼叫立即依周邊評估，任何在途或新請求若未滿足 ingress/egress 規則，會以 policy_denied 被拒。請在維運窗口或 dry-run 驗證後再變更周邊成員資格。
Q6 — VPC SC 與 storage.publicAccessPrevention 之類的 Organization Policy 有何不同？
Organization Policy 限制資源如何被設定（例如 bucket 不可公開）；VPC SC 限制API 如何被呼叫（例如即使是私有 bucket，也不能被周邊外的呼叫者讀取）。兩者互補，最安全的部署同時使用。
Q7 — 可以用 VPC SC 依國家限制存取嗎？
可以，間接做到。在 Access Context Manager 建立一個帶 regions 條件、列出核可國碼的 Access Level，再從 ingress 規則的 sources.accessLevel 引用它即可。區域由呼叫端來源 IP 的地理位置推導。