服務範圍支援資料夾

VPC Service Controls 的資料夾成員資格功能可讓您定義 service perimeter，並以資料夾做為成員。 Google Cloud 這項功能可讓您透過單一週邊設定保護整個資料夾階層，減少大規模管理週邊的行政負擔。

本文說明安全防護範圍的資料夾支援功能運作方式，並涵蓋下列主題：

  • 使用安全防護範圍中的資料夾時，需要瞭解的核心概念、行為和優點。

  • 資料夾成員資格、巢狀資源和資源階層規則 (例如繼承和評估優先順序) 之間的互動。

  • 如何查詢專案和資料夾的已設定安全防護範圍。

  • 使用這項功能的最佳做法和已知限制。

關於安全防護範圍中的資料夾成員

Google Cloud 資料夾可包含多個專案、其他資料夾，或是兩者兼具。雖然您可以將資料夾中的個別專案新增至服務安全防護範圍，但建議您改為新增上層資料夾。建立 perimeter 時，如果指定資料夾做為受保護的資源，VPC Service Controls 會納入該資料夾中的所有資源，例如專案和巢狀資料夾。

如果您將專案新增至已在 perimeter 中設定的資料夾，VPC Service Controls 會自動將這些專案新增至相同 perimeter。您不需要更新安全範圍設定，即可納入這些專案。 同樣地，從資料夾移除專案時，VPC Service Controls 會自動從 perimeter 移除這些專案。

巢狀資料夾和沿用機制

VPC Service Controls 會限制您在範圍內設定的資料夾中的所有資源，例如巢狀資料夾及其資源。將資料夾新增至 perimeter 時，VPC Service Controls 會自動限制該資料夾及其子資料夾中的所有專案。

資源成員資格評估優先順序

Google Cloud 資源只能受一個強制執行模式的正規服務 perimeter 保護，以及一個模擬測試模式的正規服務 perimeter 保護。如果資源或其上層資料夾與多個安全防護範圍相關聯，資源階層中的最低層級關聯會決定有效安全防護範圍。

VPC Service Controls 會分別評估強制執行模式和模擬測試模式的優先順序：

  • 強制執行模式優先順序：系統會根據階層中最低的資源 (專案本身或最接近的祖先資料夾)，判斷有效的強制執行邊界，並明確指派給強制執行邊界。
  • 模擬測試模式優先順序：系統會根據階層中明確指派給模擬測試範圍的最低資源，或從明確指派的強制執行資源隱含繼承的資源，判斷有效的模擬測試範圍。

為專案或子資料夾設定 dry run perimeter，不會停用或覆寫在祖系資料夾上設定的 enforced perimeter。

優先順序範例

  • 範例 1 (強制執行模式下的直接專案覆寫)：如果您在強制執行的 perimeter (sp1) 中設定父項資料夾 (folders/1)，並在另一個強制執行的 perimeter (sp2) 中明確設定該資料夾內的專案 (projects/1)，則 projects/1 會受到 sp2 保護。直接專案指派的優先順序高於資料夾繼承。folders/1 中的所有其他專案 (例如 projects/2) 仍會透過資料夾繼承機制受到 sp1 保護。

  • 範例 2 (模擬測試模式中的資料夾繼承)：在模擬測試模式中設定 service perimeter 的資料夾 (folders/1) 時，該資料夾中的所有專案 (projects/1 和 projects/2) 都會繼承模擬測試 perimeter 設定 (sp1)，除非明確停用。模擬測試模式的繼承行為與強制執行模式的繼承行為相同，除非巢狀資源明確設定了不同的模擬測試 perimeter。

  • 範例 3 (獨立評估強制執行和模擬測試 perimeter)： VPC Service Controls 會獨立評估強制執行和模擬測試關聯。如果您在強制執行的 perimeter (sp1) 中設定上層資料夾 (folders/1)，並明確將該資料夾中的專案 (projects/1) 指派給 dry run perimeter (sp2)，則 projects/1 會繼續受到強制執行模式下的 sp1 保護，同時由 sp2 在模擬測試模式下進行評估。將專案指派給試營運 Perimeter 時，不會覆寫或停用上層資料夾的強制執行 Perimeter。

  • 範例 4 (多層資料夾階層和子資料夾優先順序)：在多層資料夾階層中，VPC Service Controls 會評估階層中每個層級的優先順序。如果祖系資料夾 (folders/2) 已在強制執行的 perimeter (sp1) 中設定，所有內含專案 (projects/1 和 projects/2) 都會繼承 sp1 強制執行設定。在不同層級指派模擬測試範圍時 (例如將祖系 folders/2 指派給 dry run perimeter sp2，並將專案 projects/2 (位於子資料夾 folders/1 中) 指派給 dry run perimeter sp1)，每個專案都會從最接近的祖系繼承模擬測試設定。因此，projects/1會在 sp2 模擬測試中評估，但 projects/2 會在 sp1 模擬測試中評估。

查詢已設定的有效 perimeter

由於資源可以從祖系資料夾繼承 perimeter 保護機制，因此您可以使用 LookupConfiguredServicePerimeter 方法，找出保護專案或資料夾的 service perimeter。

API 會傳回下列內容：

  • servicePerimeter：有效強制執行的邊界完整名稱。
  • servicePerimeterDryRun：有效試營運服務安全防護範圍的完整名稱。
  • restrictedResource：強制執行的安全防護範圍直接附加的特定資源 (專案或資料夾)。
  • restrictedResourceDryRun：直接附加模擬測試範圍的特定資源。

詳情請參閱「查詢已設定的周邊範圍」。

從安全範圍排除專案

如要從資料夾層級的 perimeter 排除專案，請明確將該專案指派給另一個不限制任何服務，且允許所有輸入和輸出流量的 perimeter。由於明確的專案設定優先於資料夾層級的 perimeter，因此專案會從資料夾 perimeter 中排除。

如要瞭解如何更新 perimeter，請參閱「更新 service perimeter」。

範圍政策

範圍政策中的服務範圍只會限制該政策範圍內的資源。如要將資料夾納入範圍周邊，存取權政策必須以該資料夾或其祖系 (例如上層資料夾或機構) 為範圍。

最佳做法

管理以資料夾為準的邊界時，請參閱下列最佳做法。

將專案安全地遷移至資料夾邊界

從明確的專案成員資格轉換為以資料夾為準的成員資格時，請按照下列步驟操作，避免無意間中斷周邊防護強制執行：

  1. 將目標上層資料夾新增至 service perimeter。
  2. 在資源階層中，將專案移至該上層資料夾。
  3. 等待至少 48 小時：在周邊設定中保留明確的專案項目至少 48 小時。這段等待期可讓資源階層傳播作業在所有系統中完成。
  4. 從 perimeter 中移除明確的專案設定。專案仍會透過資料夾繼承機制受到保護。

階層異動

移動資料夾或專案會變更其有效的 perimeter 保護措施。為避免存取遭拒，請與 Resource Manager 管理員協調所有階層異動。

如果您將已在安全防護範圍中設定的專案移至其他資料夾，並將該資料夾新增至同一個安全防護範圍，則必須在安全防護範圍中保留現有的明確專案成員資格設定至少 48 小時。這段等待期可讓資源階層傳播，並避免從 perimeter 移除明確的專案設定時，發生非預期的 perimeter 強制執行問題。

限制

  • 周邊橋接器不支援以資料夾為準的成員資格。perimeter bridge 只接受專案資源。

  • VPC Service Controls 不支援資料夾層級的 API 資源。

  • 由於已知問題，在模擬執行 perimeter 中將虛擬私有雲網路專案設為受保護資源時，系統會覆寫以資料夾為準的強制執行設定。如果網路專案明確新增至模擬測試 perimeter，就會失去從上層資料夾繼承的強制執行 perimeter 保護措施。

  • 非Google Cloud API 和以 allowed_service_patterns 設定的周邊範圍不支援資料夾成員資格。如要允許存取這些服務模式，必須將來源專案或虛擬私有雲網路明確新增至範圍，而非透過資料夾繼承。

後續步驟