VPC Service Controls

VPC Service Controls 簡介

對於 Professional Cloud Architect 而言，僅靠 IAM 不足以防止數據外洩。雖然 IAM 控制了「誰」可以存取數據，但它無法防止惡意的內部人員或受損的身分將數據移動到外部、未經授權的 GCP 專案。

VPC Service Controls (VPC SC) 為你的 Google 代管服務（如 BigQuery、GCS 和 Cloud SQL）提供了一個「安全週邊 (Security Perimeter)」，將你的數據保留在受信任的環境中。

白話文解釋 VPC Service Controls

VPC Service Controls 就像是軍事基地的高牆和檢查哨。

類比 1 — 軍事基地（服務週邊 - Service Perimeter）

IAM 就像擁有「基地識別證」（身分），讓你可以進入「研究實驗室」（服務）。然而，沒有什麼能阻止你將秘密文件放進口袋，然後開車出大門前往競爭對手的家中。VPC SC 就是圍繞整個基地的 高大混凝土牆。即使你有識別證可以查看文件，牆壁也會阻止你將文件帶到基地 之外。

類比 2 — 安全隧道（橋接週邊 - Bridge Perimeter）

想像兩個獨立的軍事基地（專案 A 和專案 B）需要共享秘密。你不想拆除這兩個基地的牆。相反，你在它們之間建立了一個 安全隧道（橋接週邊 - Bridge Perimeter）。這允許獲得授權的人員在基地 A 和基地 B 之間攜帶文件，但他們仍然無法將文件帶到其他任何地方。

類比 3 — 大門哨兵（存取層級 - Access Levels）

Access Context Manager 就是 大門哨兵。哨兵不僅僅查看你的識別證；他們還會檢查：「你是否駕駛基地授權的車輛？」或「你是否來自受信任的 GPS 位置？」如果你嘗試從可疑位置進入，即使你的識別證有效，哨兵也會封鎖你。

VPC SC 的核心組成部分

1. 服務週邊 (Service Perimeter)

一個邏輯邊界，包圍了一組專案和 Google 代管服務。

• 受限服務： 你可以選擇哪些服務（例如 BigQuery、GCS）受週邊保護。
• 效果： 受保護的服務與週邊之外的任何事物之間的通訊預設會被封鎖。

2. 存取層級 (Access Levels - Access Context Manager)

定義從週邊外部存取資源的條件。

• 準則： IP 地址、裝置類型（例如必須加密）、使用者身分等。
• 使用情境： 允許使用公司 VPN 的員工存取 BigQuery，即使他們技術上處於週邊「外部」。

3. 週邊橋接 (Perimeter Bridge)

連接兩個或多個週邊。

• 要求： 兩個週邊中的專案必須相互信任。
• 使用情境： 允許一個週邊中的生產專案讀取另一個週邊中的數據湖 (Data Lake) 專案。

進站 (Ingress) 與出站 (Egress) 規則深度解析

Access Levels 處理基於身分與裝置的例外，而 ingress / egress 規則 則提供對哪些 API 呼叫可穿越週邊的屬性層級控制。每條規則是 from {sources, identities, identityType} 與 to {operations, resources} 的組合。

Ingress 規則 — 讓外部呼叫者進入

• from.identities： 特定 service account（例如非週邊專案的 Dataflow worker SA），允許呼叫週邊內部的服務。
• from.sources.accessLevel： 將 Access Level（公司 IP / 裝置）與規則結合，呼叫者必須同時符合身分與情境條件才能進入。
• to.operations： 限縮到特定方法，如 storage.googleapis.com / google.storage.objects.get — 允許讀取，但不允許 list 或 write。

Egress 規則 — 讓週邊工作負載對外存取

• to.resources： 鎖定特定外部專案編號（projects/123456789），而不只是某個服務。這是允許週邊內 BigQuery 作業匯出到 gs://partner-bucket 而不必開放整個 storage.googleapis.com API 的方法。
• to.externalResources： 允許服務 egress 到透過 Service Directory 或 PSC consumer endpoint 暴露的非 Google 端點。
• 身分縮限： 將 egressFrom.identities 與 egressTo.operations 結合，可只允許單一 Composer SA 寫入一個外部 GCS bucket — 將影響範圍最小化。

VPC SC 測試模式 (Dry-run Mode)

VPC SC 非常強大，如果配置不當，很容易導致應用程式中斷。所有新的週邊或規則變更都應從 dry-run 開始。

Dry-run 的運作方式

• 每個週邊都有 enforced config 和 dry-run config，兩者會對每個請求並行評估。
• Dry-run config 會將模擬的拒絕事件寫入 policyDenied 日誌，並帶有 dryRun: true 標記，但請求仍會被 enforced config 放行。
• 在 Log Explorer 中用 protoPayload.metadata.dryRun="true" 過濾，並依 resource.labels.service 分組，可以找出所有會被中斷的合法工作流程。

推送流程

1. 透過 gcloud access-context-manager perimeters dry-run create / update 套用新配置為 dry-run。
2. 執行 7-30 天，涵蓋每月批次與每季結算週期。
3. Dry-run 日誌乾淨後，再用 gcloud access-context-manager perimeters dry-run enforce <perimeter> 推送上線。

私有 Google 存取 (Private Google Access) 與 Restricted VIP

為了在不使用公共 IP 的情況下從 VPC 內部呼叫 Google API，需要使用 Private Google Access (PGA)。在 VPC SC 場景中，PGA 有兩種對考試很重要的型態。

private.googleapis.com — 199.36.153.8/30

• 預設的 PGA VIP，可解析到 所有 Google API，包含 VPC SC 不支援的服務（例如 compute.googleapis.com 操作、oslogin）。
• 適用於 VM 在非週邊專案、需要無公網 egress 的廣泛 Google API 存取。

restricted.googleapis.com — 199.36.153.4/30

• 配合 VPC SC 使用的 restricted VIP。只解析到 VPC SC 支援的服務（BigQuery、GCS、Pub/Sub、Spanner 等）。
• 標準作法：VPC 內建立一個 DNS managed zone，將 *.googleapis.com 以 CNAME 指向 restricted.googleapis.com，再加一條 199.36.153.4/30 → default-internet-gateway 的路由。
• 再搭配一條 deny-all egress 防火牆規則（0.0.0.0/0），可確保週邊內的 VM 物理上無法 到達任何非 VPC SC 的 Google 服務或公網。

排除被拒絕請求 (Policy Denied Logs)

VPC SC 封鎖請求時，client 會收到一個 HTTP 403，錯誤類型為 vpcServiceControlsUniqueIdentifier（unique ID）。該拒絕事件也會寫入兩條日誌串流。

查詢位置

• Cloud Audit Logs → policyDenied： 在 protoPayload.status.details 下找 violations[].type（例如 VPC_SERVICE_CONTROLS）以及 vpcServiceControlsUniqueId 欄位，這個 ID 是主要的關聯鍵。
• VPC SC Troubleshooter（Console）： 把 unique ID 貼上去，即可反向解析出被封鎖的 principal、目標服務、目標資源，以及觸發的週邊和規則。

常見違規類型

• NO_MATCHING_ACCESS_LEVEL — 呼叫者在週邊外部，且沒有任何 ingress 規則或 Access Level 符合。
• RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER — 跨週邊讀取，但既沒有 bridge 也沒有對應的 ingress/egress 規則。
• SERVICE_NOT_ALLOWED_FROM_VPC — 工作負載呼叫了週邊根本不允許的受限服務。

調查查詢

resource.type="audited_resource"
protoPayload.status.code=7
protoPayload.metadata.violationReason="RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER"

依 protoPayload.authenticationInfo.principalEmail 分組，即可找到肇事的工作負載。

透過 Bridge 進行跨週邊共享

Bridge 解決的是「兩個強週邊需要互相交換數據」但又不想削弱任一邊安全性的問題。

Bridge 機制

• Bridge perimeter 是一個專案清單，這些專案受 VPC SC 保護的服務可以互相存取。它 不是 你放工作負載的週邊。
• 專案必須已經屬於某個 regular perimeter；bridge 是疊加在其上。
• Bridge 是 雙向且對稱的 — 每個成員都能讀寫其他任何成員。

Bridge 還是 Ingress/Egress？

• Bridge： 一群緊密合作的專案（資料湖 + 多個分析專案），希望所有對所有都能互通。
• Ingress/egress 規則： 不對稱或更窄的存取（例如分析週邊讀取資料湖週邊，但資料湖不能反向讀取）。現代最佳實踐傾向使用 ingress/egress，因為粒度更細。

必記限制

• 一個專案最多只能加入 10 個 bridge。
• Bridge 成員身分 不會 繞過 Access Levels — 若週邊 A 對外部呼叫者要求 corporate_vpn access level，那麼經由 bridge 從週邊 B 過來的呼叫，依然要滿足任何引用該條件的 ingress 規則。

BigQuery、GCS 與 Pub/Sub 的 VPC SC 行為

PCA 考題裡這三個服務佔了大半，但它們在週邊內的行為各有細節。

BigQuery

• 跨專案查詢（例如 project-A.dataset.table 讀取 project-B 的表）要求兩個專案在同一週邊，或 project B 的週邊上有一條 ingress 規則列出 project A 的 service account。
• Authorized views / authorized datasets 仍然受 VPC SC 規範：dataset 所在的專案必須能從呼叫者的週邊到達。
• bq load 從週邊外的 GCS bucket 載入，需要對 storage.googleapis.com 加一條 egress 規則，scope 到該 bucket 所在專案。

Cloud Storage

• 即使 IAM 完全開放，從週邊 VM 用 gsutil cp 複製到外部 bucket 仍會被擋下 — VPC SC 凌駕於 IAM 之上。
• 在週邊內產生的 signed URL，若 bucket 受限，仍然要遵守 VPC SC；簽章可以放行 IAM，但實際的 API 呼叫仍必須從允許的來源發出。
• storage.googleapis.com 與 storage.cloud.google.com 兩個 endpoint 都受週邊保護 — 考題的干擾項常宣稱只有 API hostname 被涵蓋，這是錯的。

Pub/Sub

• Publisher 與 subscriber 跨不同週邊的訂閱，需要對應的 ingress 規則，引用 pubsub.googleapis.com / google.pubsub.v1.Subscriber.Pull。
• 推送（push）訂閱到 Google 以外的 HTTPS 端點會被擋，除非該目的地透過 egress 規則放行 — 多數團隊改用 pull 訂閱，或週邊內部的 Cloud Run 目標。

PSC 與 VPC SC 的疊加

Private Service Connect (PSC) 與 VPC SC 是互補關係，不是取代關係。

各自負責什麼

• PSC for Google APIs： 在你的 VPC 內建立一個帶私有 IP 的 consumer endpoint，鎖定 all-apis 或特定 API 套件。可解決「無法使用 199.36.153.4/30，因為與地端 IP 衝突」的問題。
• VPC SC： API 層的邊界，無論網路路徑為何，都防止數據流向週邊以外的專案。

組合模式

1. 建立 target 為 all-apis（或 vpc-sc bundle）的 PSC endpoint，配一個 VPC 內的私有 IP。
2. 將 endpoint 所在的專案放入 service perimeter。
3. 透過 DNS 將 *.googleapis.com 轉到 PSC endpoint，而不是 restricted VIP。
4. Endpoint 仍會把請求轉送到 GFE，由 GFE 對週邊重新評估 — 因此即便工作負載被入侵，雖有私有連通性，仍無法將數據外洩到週邊以外的專案。

PSC 服務後端

PSC 也讓週邊內的專案可透過私有 IP 消費 producer 服務（例如第三方 SaaS 或其他租戶的內部服務）。Producer 的 consumer-accept 清單限制哪些專案可連線，而 VPC SC 確保數據去向受邊界約束。

常見問題 — VPC Service Controls

Q1. VPC SC 與 VPC 防火牆有什麼不同？

VPC 防火牆控制 VM 之間的流量（第 3/4 層）。VPC SC 控制對 Google 代管服務 (API)（如 BigQuery 和 GCS）的存取。它們作用於技術堆疊的不同層級。

Q2. 一個專案可以屬於多個服務週邊嗎？

不可以。一個專案一次只能屬於 一個 服務週邊。要在不同週邊的專案之間共享數據，必須使用 橋接 (Bridge) 或 進站/出站規則。

Q3. VPC SC 會影響效能嗎？

不會。VPC SC 是在 Google API 前端 (GFE) 實施的，不會為你的請求增加可測量的延遲。

Q4. 啟用 VPC SC 時，現有數據會發生什麼？

數據本身不會發生任何變化，但根據週邊規則，對該數據的存取將立即受到限制。這就是為什麼 測試模式 (Dry-run mode) 至關重要的原因。

Q5. VPC SC 能防止透過網際網路發生的數據外洩嗎？

可以。透過限制哪些 IP 地址（存取層級）可以觸及你的數據，並封鎖所有導向外部專案的出站流量，VPC SC 可有效防止數據洩漏到公共網際網路或未經授權的帳戶。

最後的架構師提示

在 PCA 考試中，請將 VPC SC 視為「外洩殺手」。如果情境提到「惡意內部人員」、「專案間的數據洩漏」或「保護 SaaS/API 服務」，VPC SC 就是預期的答案。請準備好解釋 基於身分的 (IAM) 與 基於邊界的 (VPC SC) 安全性之間的區別。此外，請記住 Access Context Manager 是用於為週邊定義特定「存取層級」(IP, 裝置等) 的工具。