進階 VPC Service Controls (VPC SC)
雖然單一服務周界提供了強大的保護，但現實中的企業架構往往需要在不同部門、組織或周界之間安全地移動資料。服務周界橋接 (Perimeter Bridges) 以及入站/出站規則 (Ingress/Egress Rules) 是在不損害安全性的情況下管理這些複雜互動的工具。
對於 專業雲端安全工程師 (PSE) 而言，精通這些概念對於設計可擴展的多周界架構至關重要，既能支持協作，又能有效防止資料外洩。
白話文解釋
VPC SC 的橋接與入站/出站規則聽起來抽象，但只要對應到日常生活的邊界，差異就會立刻清楚。以下三個比喻能幫助記憶其中的取捨。
比喻一：辦公大樓的門禁（服務周界橋接）
想像兩個用門禁卡管制的辦公樓層：3 樓是 HR、4 樓是 Finance，各自獨立鎖門。服務周界橋接 (Perimeter Bridge) 就像在兩個樓層之間加裝一道永久連通門：一旦打開，HR 的所有員工都能走進 Finance，Finance 的所有員工也都能走進 HR，沒有逐人檢查、沒有逐房間限制，而且雙向通行。這就是為什麼 GCP 文件強調橋接是雙向且對稱的，而且一個 regular perimeter 最多只能掛 10 條橋接——它是一句粗顆粒的信任宣告，不是外科手術等級的存取控制。
比喻二：機場海關（入站與出站規則）
接著想像國際機場。入站規則 (Ingress Rules) 就是 Perimeter_HR 入境大廳的證照查驗官：先查 from.identities（你拿的是哪本護照，例如某個 analytics-svc@…iam.gserviceaccount.com）、檢查 from.sources.accessLevel（你從哪個受信任的 Access Context Manager 層級飛來）、最後才在 to.operations（哪個航廈/API，例如 storage.googleapis.com 搭配 google.storage.objects.get）對應 to.resources（哪個特定的 GCS bucket）蓋章放行。出站規則 (Egress Rules) 則是 Perimeter_Finance 離境海關：負責檢查你的服務帳戶能不能把資料帶到 to.externalResources（例如 projects/hr-prod 或 Service Directory 端點）。兩邊必須各自同意，就像同時需要出境簽證和入境簽證。
比喻三：外交郵袋 vs 主權國家（Bridge 周界 vs Regular 周界）
Regular perimeter（一般周界） 就像一個主權國家：有完整的邊境、Access Levels、入站/出站政策、dry-run 模式以及受保護的服務清單。而 Bridge perimeter（橋接周界） 比較像兩個國家之間的外交郵袋通道——它本身不帶任何政策，只是宣告「這兩個 regular perimeter 整體互信」。你不能在橋接周界上掛 Access Level、不能在橋接上跑 dry-run、也不能把橋接限縮到單一 bucket。當稽核問你「到底是哪個身分動了哪個資源」時，橋接給不出答案——這正是 Google 官方建議新部署改用 ingress/egress 規則的原因。
設定服務周界橋接
服務周界橋接 (Perimeter Bridge) 允許位於不同服務周界中的專案進行通訊。
運作方式：
- 您透過建立橋接來「連結」兩個周界。
- 周界 A 內的專案現在可以呼叫周界 B 中的受限服務，反之亦然。
- 橋接是雙向的，且採取「全有或全無」的方式（A 中的所有專案都可以與 B 中的所有專案通訊）。
與入站/出站規則相比，服務周界橋接被視為「舊式」做法。雖然設定較簡單，但粒度較粗。如果您需要限制跨周界存取特定的儲存桶 (Bucket) 或服務帳戶，應改用入站/出站規則。
進階入站與出站規則
入站 (Ingress) 和 出站 (Egress) 規則針對進入或離開周界的流量提供了精細的控制。
入站規則 (誰可以進來？)
入站規則定義了：
- 來源 (From)： 來源（存取層級、特定專案或身分）。
- 目標 (To)： 目標（受保護的專案以及特定的服務/API）。
出站規則 (誰可以出去？)
出站規則定義了：
- 來源 (From)： 來源（周界內的身分或專案）。
- 目標 (To)： 目標（外部專案、服務或資源）。
入站/出站規則 (Ingress/Egress Rules) 是精細的政策，允許特定的身分跨越 VPC SC 周界邊界存取特定的資源。
入站規則的 from 區塊由 identities（或 identityType: ANY_SERVICE_ACCOUNT）與 sources（一個 Access Context Manager 的 accessLevel，或像 projects/123 這樣的 resource）組成；to 區塊則把 operations（例如 storage.googleapis.com 搭配 methodSelectors）與 resources 綁在一起。出站規則改以 to.externalResources 為目標——可以是 GCS bucket 路徑、專案編號，或用於私有連線的 Service Directory 端點。若任何一半缺漏（例如只給 identities 沒給 sources，或只給 operations 沒給 resources），規則會在政策驗證階段被拒絕。
熟記四項 VPC SC 周界考點：(1) 服務周界橋接 (Perimeter Bridge) 是雙向且對稱的，每個 regular perimeter 最多掛 10 條橋接；(2) Bridge 周界不能設定 Access Levels、入站/出站規則或受限服務清單，只有 Regular 周界可以；(3) 入站與出站規則必須雙邊都同意（來源周界的 egress 加上目標周界的 ingress 都要放行）；(4) 周界變更最長可能需要 30 分鐘才會完成傳播，所以正式啟用前一定要先用 dry-run 模式驗證。
在周界之間移動資源
將專案從周界 A 移至周界 B（或完全移除）是一項高風險操作。
- 依賴性檢查： 確保該專案對目前周界內的其他專案沒有現有的依賴關係。
- 測試模式 (Dry-run Mode)： 在實際移動之前，先使用測試模式查看會造成哪些中斷。
- 生效時間： 周界的變更可能需要長達 30 分鐘才能完成傳播。
共享 VPC 與 VPC SC 的情境
在共享 VPC (Shared VPC) 設定中，必須小心處理主機專案 (Host Project) 和服務專案 (Service Projects)。
- 規則： 主機專案及其所有的服務專案必須位於同一個服務周界內。
- 如果您將它們放在不同的周界中，透過 VPC 網路（如內部 IP）的通訊仍可運作，但對 Google API（如 GCS）的呼叫將被 VPC SC 封鎖，除非已設定橋接或規則。
受限服務的混合存取
專用 Google 存取通道 (Private Google Access, PGA) 允許地端系統透過 VPN 或專線存取 Google API。
- 當涉及 VPC SC 時，必須明確允許 PGA 流量。
- 您必須根據地端 IP 範圍建立 ACM 存取層級，並將其包含在周界的入站政策中。
根據身分與資源定義規則範圍
與橋接不同，入站/出站規則允許您精確指定哪個服務帳戶可以存取哪個特定的儲存桶。
- 範例： 僅允許
[email protected]讀取專案 B 中的gs://sensitive-data-bucket。
在入站/出站規則中，請務必使用儘可能嚴格的「目標 (To)」範圍，以最大限度地減少資料外洩的攻擊面。
多周界架構的最佳實踐
- 避免周界碎片化： 建立過多微小的周界會導致「規則疲勞」和管理複雜性。將具有相似資料敏感度的專案組合在一起。
- 使用資料夾層級政策： 在大型組織中，於資料夾層級管理周界會更易於行政管理。
- 規則標準化： 在整個組織中使用一致的存取層級命名慣例和邏輯。
在 CI/CD 流水線中管理 VPC SC
當首次啟用 VPC SC 時，自動化部署（如 Terraform 或 Jenkins）經常會失敗。
- 解決方案： 將 CI/CD 服務帳戶加入入站規則中。
- 基於身分的入站： 明確允許
[email protected]身分繞過周界執行管理任務。
複雜的資料分享模式
情境：資料潔淨室 (Data Clean Room)
兩家公司（公司 A 和公司 B）希望分享資料進行分析，但不希望任何一方看到原始資料。
- 建立一個資料潔淨室周界。
- 公司 A 建立一條出站規則，將資料推送到潔淨室。
- 公司 B 建立一條出站規則，將資料推送到潔淨室。
- 分析結果透過另一條單獨的規則傳出，但原始資料永遠不會離開資料潔淨室周界。
常見錯誤：忘記了即使目標專案有一條允許流量進入的入站規則，來源端也必須有對應的出站規則。兩個周界都必須「同意」這次傳輸。
PSE 考試情境
情境 1：精細的跨周界存取
「公司有兩個周界：Perimeter_HR 和 Perimeter_Finance。財務部的服務帳戶需要讀取 HR 儲存桶中的一個特定檔案。最安全的方法是什麼？」
解答： 在 Perimeter_HR 中建立一條入站規則，將財務部服務帳戶指定為「來源 (From)」，將該特定儲存桶指定為「目標 (To)」。在 Perimeter_Finance 中建立一條出站規則，允許該服務帳戶存取 HR 專案。
情境 2：共享 VPC 與 VPC SC
「您正將一個服務專案移入一個周界，但其主機專案位於另一個不同的周界。會發生什麼事？」 解答： 這次移動很可能會導致 API 呼叫失敗。根據 Google Cloud 的最佳實踐，主機和服務專案應位於同一個周界內。如果它們必須分開，則需要為每一次 API 互動設定複雜的入站/出站規則。
總結檢查表
- 比較服務周界橋接與入站/出站規則的優缺點。
- 列出入站規則的組件（來源/目標）。
- 解釋為什麼共享 VPC 的專案應位於同一個周界。
- 描述如何允許地端存取周界內的資源。
- 理解「資料潔淨室」分享模式。