決定 Google Cloud 登陸區的資源階層

資源階層架構可協助您整理 Google Cloud中的資源。 本文說明如何選擇資源階層，做為登陸區設計的一部分。這份指南適用於參與資源階層設計的雲端系統管理員、架構師和技術人員。本文是登陸區系列文章之一。其中包含範例階層，說明商家在Google Cloud中建構資源的常見方式。

資源階層的設計要素

在 Google Cloud中定義資源階層結構時，請務必考量貴機構目前的工作方式，以及雲端轉型的理想最終狀態。管理資源的最佳方式取決於貴機構在雲端中的預期工作方式。每個機構都不盡相同，因此沒有適用於所有機構的最佳資源階層做法。

不過，我們建議您避免將公司機構結構對應至資源階層。請改為專注於業務需求和營運 Google Cloud。

Google Cloud 資源階層結構

Google Cloud 的資源階層從根節點開始，也就是所謂的機構。除非是特定情況，否則建議商家只使用一個根節點。您可以使用「資料夾」和「專案」定義階層的較低層級，並在資料夾內建立資料夾，建構階層。您可以在階層的任何層級建立專案，以託管工作負載。

下圖顯示名為「Organization」的根節點，以及第一、第二和第三層的資料夾。專案和子資料夾會建立在第二層的資料夾下。

資源階層結構因素

決定資源階層結構時，請考量下列因素：

• 誰負責雲端資源？是您的部門、子公司、技術團隊或法人嗎？
• 您的法規遵循需求為何？
• 您是否有即將舉行的企業活動，例如合併、收購和分拆？

瞭解整個階層中的資源互動

資源階層中的子系會沿用組織政策，但較低層級定義的政策可以取代這些政策。詳情請參閱「瞭解階層評估」。您可以使用機構政策限制，為整個機構或重要部分設定規範，同時允許例外狀況。

允許政策 (舊稱 IAM 政策) 會由後代沿用，且較低層級的允許政策會累加。不過，允許政策可能會遭到拒絕政策取代，您可藉此限制專案、資料夾和機構層級的權限。拒絕政策的優先順序高於允許政策。

此外，您也需要考慮下列事項：

• Cloud Logging 包含匯總接收器，可用於匯總資料夾或機構層級的記錄。詳情請參閱「決定 Google Cloud 登陸區的安全性機制」。
• 帳單不會直接連結至資源階層，而是指派至專案層級。不過，如要取得資料夾層級的匯總資訊，您可以使用帳單報表依專案階層結構分析費用。
• 階層式防火牆政策可讓您在整個機構或特定資料夾中，實作一致的防火牆政策。繼承是隱含的，也就是說，您可以在任何層級允許或拒絕流量，也可以將決策權委派給較低的層級。

資源階層設計的決策點

下方的流程圖顯示您必須考量的事項，才能為機構選擇最合適的資源階層。

上圖概述了下列決策點：

1. 不同子公司、區域群組或業務單位是否有截然不同的政策規定？
   1. 如果是，請按照區域或子公司設計。
   2. 如果沒有，請前往下一個決策點。

2. 您的工作負載或產品團隊是否需要對政策有高度自主權？舉例來說，您沒有負責為所有工作負載或產品團隊制定政策的中央安全團隊。

   1. 如果是，請參閱根據問責架構設計的內容。

   2. 如果沒有，請參閱根據應用程式環境設計。

您的特定用途可能會引導您採用其他資源階層設計，而非決策圖表建議的設計。大多數機構會選擇混合式做法，並在資源階層的不同層級選取不同設計，從最影響政策和存取權的設計開始。

選項 1：根據應用程式環境建立階層

在許多機構中，您會為不同的應用程式環境 (例如開發、實際工作和測試) 定義不同的政策和存取控管機制。為每個環境制定標準化的個別政策，可簡化管理和設定作業。舉例來說，您在實際工作環境中採用的安全政策，可能比測試環境更嚴格。

如果符合下列條件，請使用以應用程式環境為準的階層：

• 您有不同的應用程式環境，且政策和管理規定各不相同。
• 您有集中式安全或稽核需求，中央安全團隊必須能夠對所有正式工作負載和資料，持續強制執行這些需求。
• 您需要不同的 Identity and Access Management (IAM) 角色，才能存取不同環境中的Google Cloud 資源。

如果符合下列情況，請避免使用這個階層：

• 您不會執行多個應用程式環境。
• 您在不同環境中沒有不同的應用程式依附元件和業務程序。
• 不同地區、團隊或應用程式的政策差異很大。

下圖顯示 example.com 的階層，這是一間虛構的金融科技公司。

如上圖所示，example.com 有三個應用程式環境，分別具有不同的政策、存取控管、法規要求和程序。環境如下：

• 開發和 QA 環境：這個環境由內部員工和顧問開發人員管理。他們會持續推送程式碼，並負責確保品質。這項環境絕不會開放給貴商家的消費者使用。與正式環境相比，開發環境的整合和驗證要求較不嚴格，且開發人員會獲派適當權限的核准角色。開發與 QA 環境僅適用於 example.com 的標準應用程式。

• 測試環境：這個環境用於迴歸和應用程式測試，並支援使用 example.com API 的 example.com 客戶的企業對企業 (B2B) 產品。為此，example.com 會建立兩種類型的專案：

  • 完成內部測試專案，以進行 B2B 產品的內部迴歸、效能和設定測試。
  • 支援多租戶的客戶 UAT 專案，方便 B2B 客戶驗證設定，並配合 example.com 的使用者體驗、品牌、工作流程、報表等規定。

• 正式環境：這個環境會代管所有經過驗證、接受及發布的產品。這個環境須遵守付款卡產業資料安全標準 (PCI DSS) 法規，並使用硬體安全模組 (HSM)，且與第三方處理器整合，以處理驗證和付款結算等項目。稽核和法規遵循團隊是這個環境的重要利害關係人。這個環境的存取權受到嚴格控管，且大多僅限於自動部署程序。

如要進一步瞭解如何根據應用程式環境設計階層，請參閱企業基礎藍圖中的「機構結構」。

選項 2：依據區域或子公司建立階層

有些機構的業務遍及多個區域，子公司在不同地區經營業務，或是機構本身是合併和收購的結果。這些機構需要使用 Google Cloud的資源階層，並維持區域或子公司之間不同程序和政策的獨立性，以確保可擴充性及管理選項。這個階層會將子公司或區域做為資源階層中的最高資料夾層級。部署程序通常以區域為中心。

如果符合下列條件，請使用這個階層：

• 不同地區或子公司各自獨立運作。
• 不同地區或子公司有不同的營運主幹、數位平台產品和程序。
• 您的商家在不同區域或子公司有不同的法規和法規遵循標準。

下圖顯示全球機構的階層範例，其中包含兩個子公司和一個具有區域化結構的控股集團。

上圖的階層結構如下：

• 第一層的資料夾如下：
  • Subsidiary 1 和 Subsidiary 2 資料夾代表公司的兩個子公司，這些子公司與機構的其他部分有不同的存取權和政策。各子公司會使用 IAM 限制專案和 Google Cloud 資源的存取權。
  • Holding group 資料夾代表在各區域具有高層級通用政策的群組。
  • 如企業基礎藍圖所述，Bootstrap資料夾代表部署基礎架構所需的常見資源 Google Cloud 。
• 在第二層的「Group Holding」資料夾中，有下列資料夾：
  • APAC、EMEA 和 Americas 資料夾代表群組內的不同區域，這些區域具有不同的控管、存取權限和政策。
  • Shared infrastructure 資料夾代表所有區域都會使用的全域資源。
• 每個資料夾內都有各種專案，其中包含這些子公司或區域負責的資源。

您可以新增更多資料夾，區隔公司內的不同法律實體、部門和團隊。

方法 3：根據問責架構建立階層

如果產品是獨立運作，或是組織單位有明確定義的團隊負責產品生命週期，那麼根據問責架構建立的階層就最適合。在這些機構中，產品負責人負責整個產品生命週期，包括程序、支援、政策、安全性及存取權。你的產品彼此獨立，且通常沒有全機構適用的規範和控制項。

符合下列條件時，請使用這個階層：

• 您經營的機構對每項產品都有明確的擁有權和責任。
• 工作負載彼此獨立，且不會共用許多常見政策。
• 您的程序和外部開發人員平台會以服務或產品的形式提供。

下圖顯示電子商務平台供應商的階層範例。

上圖的階層結構如下：

• 第一層的資料夾如下：
  • 名為 Ecommerce Modules 和 Logistics and Warehousing Modules 的資料夾代表平台產品中的模組，在產品生命週期內需要相同的存取權和政策。
  • Reconciliation and Billing 資料夾代表產品團隊，負責平台產品中特定業務元件的端對端模組。
  • 如企業基礎藍圖所述，Bootstrap資料夾代表部署基礎架構所需的常見資源 Google Cloud 。
• 每個資料夾內都有各種專案，其中包含不同產品團隊負責的獨立模組。

詳情請參閱「Fabric FAST VPC Service Controls」。

資源階層結構最佳做法

下列各節將說明設計資源階層的最佳做法，無論您選擇哪種資源階層，都建議遵循這些做法。

如要進一步瞭解如何設定 Cloud Identity 和 Google Workspace 帳戶與機構的最佳做法，請參閱「規劃帳戶和機構的最佳做法」。

使用單一機構節點

為避免管理負擔過重，請盡可能使用單一機構節點。 不過，建議使用多個機構節點來處理下列用途：

• 您想測試 IAM 層級或資源階層的重大變更。
• 您想在沙箱環境中進行實驗，但該環境沒有相同的機構政策。
• 您的機構包含可能在未來出售或以完全獨立實體形式經營的子公司。

使用標準化命名慣例

在整個機構中採用標準化命名慣例。安全基礎藍圖提供命名慣例範例，您可以根據需求調整。

將啟動程序資源和常見服務分開

請為使用基礎架構即程式碼 (IaC) 啟動環境，以及在環境或應用程式之間共用的通用服務，分別建立資料夾。 Google Cloud 將啟動程序資料夾放在資源階層的機構節點下方。

根據您選擇的結構，將常見服務的資料夾放在階層的不同層級。

如果符合下列條件，請將通用服務的資料夾放在機構節點下方：

• 您的階層會在最高層級使用應用程式環境，第二層則使用團隊或應用程式。
• 您有環境之間共用的服務，例如監控。

如果符合下列條件，請將通用服務的資料夾放在較低的層級，也就是應用程式資料夾下方：

• 您有應用程式共用的服務，且為每個部署環境部署個別執行個體。

• 應用程式共用微服務，因此每個部署環境都需要開發和測試。

下圖顯示階層範例，其中包含所有環境使用的共用基礎架構資料夾，以及階層中較低層級的每個應用程式環境共用服務資料夾：

上圖的階層結構如下：

• 第一層的資料夾如下：
  • Development environment 和 Production environment 資料夾包含應用程式環境。
  • Shared infrastructure 資料夾包含跨環境共用的常見資源，例如監控。
  • Bootstrap 資料夾包含部署 Google Cloud 基礎架構所需的常見資源，如企業基礎藍圖所述。
• 第二層有下列資料夾：
  • 每個應用程式在每個環境中都有一個資料夾 (App 1 和 App 2)，其中包含這些應用程式的資源。
  • 兩個應用程式環境的 Shared 資料夾，內含應用程式共用但各自獨立的服務。舉例來說，您可能會有資料夾層級的祕密專案，以便對正式環境和非正式環境的祕密套用不同的允許政策。
• 每個應用程式資料夾內都有各種專案，其中包含屬於各個應用程式的獨立模組。

後續步驟

• 設計登陸區的網路 (本系列文件的下一篇)。
• 查看企業基礎藍圖。
• 請參閱Google Cloud 安全最佳做法中心提供的藍圖和白皮書。