部署藍圖

Last reviewed 2025-05-15 UTC

本節說明部署藍圖的程序、命名慣例，以及藍圖建議的替代方案。

合併運用各種策略

如要根據本藍圖的最佳做法和建議，部署自己的企業基礎架構，請按照本節中歸納的高階工作操作。部署作業需要完成多項必要設定步驟，並透過 GitHub 上的 terraform-example-foundation 自動部署，以及在完成初始基礎部署後，手動設定其他步驟。

程序 步驟

部署基礎管道資源的事前準備

部署基礎管道前，請先完成下列步驟：

如要連線至現有的內部部署環境，請準備下列項目：

從 GitHub 部署 terraform-example-foundation 的步驟

請按照各階段的 README 指示，從 GitHub 部署 terraform-example-foundation：

部署 IaC 後的其他步驟

部署 Terraform 程式碼後，請完成下列步驟：

為機密工作負載客戶提供額外的管理控制項

Google Cloud 提供額外的管理控制項，協助您滿足安全性與法規遵循需求。不過，部分控制項會產生額外費用或作業上的取捨，可能不適合所有客戶。此外，這些控制項也需要根據您的特定需求自訂輸入內容，無法在藍圖中為所有客戶提供預設值，完全自動化。

本節介紹您集中套用至基礎架構的安全控管措施。本節並未詳盡列出可套用至特定工作負載的所有安全控管措施。如要進一步瞭解 Google 的安全產品和解決方案，請參閱Google Cloud 安全性最佳做法中心。

根據法規遵循規定、風險承受度和資料敏感度，評估下列控管措施是否適合您的基礎架構。

控制組 說明

使用 VPC Service Controls 保護資源

VPC Service Controls 可定義安全性政策，禁止從受信任 perimeter 外部存取 Google 代管服務、防止從不受信任的位置存取資料，還能降低資料竊取風險。不過，在您定義例外狀況以允許預期存取模式之前，VPC Service Controls 可能會導致現有服務中斷。

評估降低資料竊取風險的價值，是否足以抵銷採用 VPC Service Controls 後，複雜度增加和營運負擔加重的情況。藍圖會準備必要網路控制項和試營運的 VPC Service Controls 範圍，但您必須採取額外步驟，範圍才會強制執行。

限制資源位置

您可能受到法規限制，雲端資源只能部署在核准的地理位置。這項機構政策限制會強制規定，資源只能部署在您定義的位置清單中。

啟用 Assured Workloads

Assured Workloads 提供額外的法規遵循控管機制，協助您遵守特定監管體制。藍圖會在部署管道中提供選用變數，供您啟用這項功能。

啟用資料存取記錄

您可能需要記錄對特定私密資料或資源的所有存取行為。

評估工作負載處理需要資料存取記錄的機密資料位置，並為處理機密資料的每個服務和環境啟用記錄。

啟用存取權核准

Access Approval 可確保 Cloud Customer Care 和工程團隊必須明確取得您的核准，才能存取您的客戶內容。

評估審查 Access Approval 要求所需的作業程序，盡量避免支援事件處理延誤。

啟用金鑰存取依據

透過「金鑰存取理由」，您可以透過程式輔助方式控管 Google 是否能存取加密金鑰，包括自動化作業，以及客戶服務人員是否能存取客戶內容。

評估與金鑰存取依據相關的成本和作業負擔，以及金鑰存取依據對 Cloud External Key Manager (Cloud EKM) 的依附關係。

停用 Cloud Shell

Cloud Shell 是一個線上開發環境，這個殼層會託管在 Google 管理的伺服器上，位於您的環境之外，因此不受您在自有開發人員工作站上實作的控制項約束。

如要嚴格控管開發人員可存取雲端資源的工作站，請停用 Cloud Shell。您也可以評估 Cloud Workstations，在自己的環境中設定工作站。

限制 Google Cloud 控制台存取權

Google Cloud 可根據 Google Cloud 群組成員資格、受信任的 IP 位址範圍和裝置驗證等存取層級屬性，限制控制台存取權。部分屬性需要額外訂閱 Chrome Enterprise 進階版。

評估您信任的使用者存取模式，確保使用者能存取網頁型應用程式 (例如控制台)，這是零信任部署的一環。

命名慣例

建議您為Google Cloud 資源採用標準化命名慣例。下表說明藍圖中資源名稱的建議慣例。

資源 命名慣例

資料夾

fldr-environment

environment 是指機構內資料夾層級資源的說明。 Google Cloud例如：bootstrap、common、production、nonproduction、development 或 network。

例如：fldr-production

專案 ID

prj-environmentcode-description-randomid

  • environmentcode 是環境欄位的簡短形式 (b、c、p、n、d 或 net 其中之一)。共用虛擬私有雲主專案會使用相關聯環境的 environmentcode。跨環境共用的網路資源專案 (例如 interconnect 專案) 會使用 net 環境代碼。
  • description 是專案的其他資訊。您可以使用簡短且人類可讀的縮寫。
  • randomid 是隨機產生的後置字串，可避免全域不重複的資源名稱發生衝突，並防範攻擊者猜測資源名稱。藍圖會自動新增隨機四字元的英數 ID。

例如：prj-c-logging-a1b2

虛擬私有雲網路

vpc-environmentcode-vpctype

  • environmentcode 是環境欄位的簡短形式 (b、c、p、n、d 或 net 其中之一)。
  • vpctype 是 svpc、float 或 peer。

例如：vpc-p-svpc

子網路

sn-environmentcode-vpctype-region{-description}

  • environmentcode 是環境欄位的簡短形式 (b、c、p、n、d 或 net 其中之一)。
  • vpctype 是 svpc、float 或 peer。
  • region 是資源所在的任何有效Google Cloud 區域。建議移除連字號，並使用部分區域和方向的縮寫，以免超出字元限制。例如：au (澳洲)、na (北美洲)、sa (南美洲)、eu (歐洲)、se (東南亞) 或 ne (東北亞)。
  • description 是子網路的額外資訊。你可以使用簡短且人類可讀的縮寫。

例如：sn-p-svpc-uswest1

防火牆政策

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype 為 hierarchical 或 network。
  • scope 是 global 或資源所在的 Google Cloud地區。建議移除連字號，並使用部分區域和方向的縮寫，以免達到字元限制。例如：au (澳洲)、na (北美洲)、sa (南美洲)、eu (歐洲)、se (東南亞) 或 ne (東北亞)。
  • environmentcode 是環境欄位的簡短形式 (b、c、p、n、d 或 net 其中之一)，擁有政策資源。
  • description 是階層式防火牆政策的其他資訊。你可以使用簡短且人類可讀的縮寫。

例如：

fw-hierarchical-global-c-01

fw-network-uswest1-p-svpc

Cloud Router

cr-environmentcode-vpctype-region{-description}

  • environmentcode 是環境欄位的簡短形式 (b、c、p、n、d 或 net 其中之一)。
  • vpctype 是 svpc、float 或 peer。
  • region 是資源所在的任何有效 Google Cloud 區域。建議移除連字號，並使用部分區域和方向的縮寫，以免達到字元限制。例如：au (澳洲)、na (北美洲)、sa (南美洲)、eu (歐洲)、se (東南亞) 或 ne (東北亞)。
  • description 是 Cloud Router 的額外資訊。你可以使用簡短且人類可讀的縮寫。

例如：cr-p-svpc-useast1-cr1

Cloud Interconnect 連線

ic-dc-colo

  • dc 是資料中心的名稱，Cloud Interconnect 會連線至該資料中心。
  • colo 是與內部部署資料中心 Cloud Interconnect 對等互連的共置設施名稱。

例如：ic-mydatacenter-lgazone1

Cloud Interconnect VLAN 連結

vl-dc-colo-environmentcode-vpctype-region{-description}

  • dc 是資料中心的名稱，Cloud Interconnect 會連線至該資料中心。
  • colo 是 Cloud Interconnect 從內部部署資料中心對等互連的共置設施名稱。
  • environmentcode 是環境欄位的簡短形式 (b、c、p、n、d 或 net 其中之一)。
  • vpctype 是 svpc、float 或 peer。
  • region 是資源所在的任何有效 Google Cloud 區域。建議移除連字號，並使用部分區域和方向的縮寫，以免達到字元限制。例如：au (澳洲)、na (北美洲)、sa (南美洲)、eu (歐洲)、se (東南亞) 或 ne (東北亞)。
  • description 是 VLAN 的額外資訊。你可以使用簡短且人類可讀的縮寫。

例如：vl-mydatacenter-lgazone1-p-svpc-useast1-cr1

群組

grp-gcp-description@example.com

其中 description 是群組的其他資訊。您可以使用簡短且容易解讀的縮寫。

例如：grp-gcp-billingadmin@example.com

自訂角色

rl-description

其中 description 是角色的額外資訊。您可以使用簡短且人類可讀的縮寫。

例如：rl-customcomputeadmin

服務帳戶

sa-description@projectid.iam.gserviceaccount.com

其中：

  • description是服務帳戶的額外資訊。你可以使用簡短且人類可讀的縮寫。
  • projectid 是全域專屬專案 ID。

例如：sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

Storage bucket

bkt-projectid-description

其中：

  • projectid 是全域專屬專案 ID。
  • description 是儲存空間 bucket 的額外資訊。 你可以使用簡短且人類可讀的縮寫。

例如：bkt-prj-c-infra-pipeline-a1b2-app-artifacts

預設最佳化建議的替代方案

藍圖中建議的最佳做法可能不適用於所有客戶。您可以根據特定需求自訂任何建議。下表列出一些常見的變化，您可能會根據現有的技術堆疊和工作方式，需要這些變化。

決策領域 可能的替代方案

機構：藍圖會使用單一機構做為所有資源的根節點。

決定登陸區的資源階層 Google Cloud 一文介紹了您可能偏好使用多個機構的幾種情境，例如：

  • 貴機構包含可能在未來出售或以完全獨立實體形式經營的子公司。
  • 您想在沙箱環境中進行實驗，但不想連線至現有機構。

資料夾結構：藍圖的資料夾結構會將工作負載劃分為頂層的 production, non-production 和 development 資料夾。

決定 Google Cloud 登陸區的資源階層介紹了其他資料夾結構方法，可根據您管理資源和沿用政策的方式選擇，例如：

  • 依應用程式環境分類的資料夾
  • 根據區域實體或子公司建立資料夾
  • 根據當責架構建立資料夾

機構政策：藍圖會在機構節點強制執行所有機構政策限制。

您可能為業務的不同部分制定不同的安全政策或工作方式。在這個情境中，請在資源階層的較低節點強制執行組織政策限制。查看組織政策限制的完整清單，瞭解如何滿足您的需求。

部署管道工具：藍圖使用 Cloud Build 執行自動化管道。

您可能偏好使用其他產品來建立部署管道，例如 Terraform Enterprise、GitLab Runners、GitHub Actions 或 Jenkins。藍圖包含各項產品的替代方向。

部署的程式碼存放區：藍圖使用 Cloud Source Repositories 做為代管的私人 Git 存放區。

使用偏好的版本管控系統管理程式碼存放區，例如 GitLab、GitHub 或 Bitbucket。

如果您使用在內部部署環境中代管的私人存放區，請設定從存放區到 Google Cloud環境的私人網路路徑。

身分識別提供者：藍圖假設您使用內部部署的 Active Directory，並透過 Google Cloud Directory Sync 將身分連結至 Cloud Identity。

如果您已使用 Google Workspace，可以沿用 Google Workspace 中已管理的 Google 身分。

如果沒有現有的身分提供者，您可以直接在 Cloud Identity 中建立及管理使用者身分。

如果您有現有的身分識別提供者，例如 Okta、Ping 或 Azure Entra ID，您可以在現有的身分識別提供者中管理使用者帳戶，並同步處理至 Cloud Identity。

如果您有資料主權或法規遵循方面的需求，而無法使用 Cloud Identity，且不需要其他 Google 服務 (例如 Google Ads 或 Google Marketing Platform) 的受管理 Google 使用者身分，則可能偏好員工身分同盟。在這種情況下，請注意支援服務的限制。

多個區域：藍圖會將區域資源部署到兩個不同的 Google Cloud 區域，協助您設計工作負載，同時兼顧高可用性和災難復原需求。

如果您的使用者遍布多個地理位置，不妨設定更多 Google Cloud 區域，在更靠近使用者的位置建立資源，減少延遲時間。

如果您有資料主權限制，或單一Google Cloud 區域就能滿足可用性需求，則可能只會設定一個區域。

IP 位址分配：藍圖提供一組 IP 位址範圍。

您可能需要根據現有混合式環境中的 IP 位址可用性，變更所用的特定 IP 位址範圍。如果您修改 IP 位址範圍，請參考藍圖，瞭解所需的範圍數量和大小，並查看Google Cloud的有效 IP 位址範圍。

混合式網路：藍圖會跨多個實體網站和Google Cloud 區域使用專屬互連，以盡可能提升頻寬和可用性。

視成本、頻寬和可靠性需求而定，您可能會改為設定合作夥伴互連網路或 Cloud VPN。

如果您需要在專屬互連網路完成前，開始部署具有私人連線的資源，可以先使用 Cloud VPN，之後再改用專屬互連網路。

如果沒有現有的內部部署環境，您可能完全不需要混合式網路。

VPC Service Controls perimeter：藍圖建議使用單一 perimeter，其中包含 Shared VPC 拓撲的所有服務專案。

您可能需要為組織建立多個 perimeter，也可能決定完全不使用 VPC Service Controls。

如需相關資訊，請參閱「決定如何透過 Google API 減少資料外洩風險」。

Secret Manager：藍圖會部署專案，以便在 common 資料夾中使用 Secret Manager，管理機構層級的密鑰，並在每個環境資料夾中部署專案，管理環境專屬的密鑰。

如果貴機構只有一個團隊負責管理及稽核機密密鑰，您可能只想使用單一專案來管理密鑰存取權。

如果允許工作負載團隊管理自己的密鑰，您可能不會使用集中式專案管理密鑰存取權，而是讓團隊在工作負載專案中使用自己的 Secret Manager 執行個體。

Cloud KMS：藍圖會部署專案，以便在 common 資料夾中使用 Cloud KMS，管理整個機構的金鑰，並為每個環境資料夾部署專案，管理各環境的金鑰。

如果貴機構只有一個團隊負責管理及稽核加密金鑰，您可能只想使用單一專案來管理金鑰存取權。集中式方法有助於滿足法規遵循要求，例如 PCI 金鑰管理員。

如果您允許工作負載團隊管理自己的金鑰，可能就不會使用集中式專案管理金鑰存取權，而是允許團隊在工作負載專案中使用自己的 Cloud KMS 執行個體。

匯總記錄接收器：藍圖會在機構節點設定一組記錄接收器，讓中央安全團隊可以查看整個機構的稽核記錄。

您可能有不同團隊負責稽核業務的不同部分，而這些團隊可能需要不同的記錄才能完成工作。在這種情況下，請在適當的資料夾和專案中設計多個匯總接收器，並建立篩選器，確保每個團隊只會收到必要的記錄，或是設計記錄檢視畫面，以便對共用記錄值區進行精細的存取權控管。

基礎架構管道的精細程度：藍圖採用一種模型，每個業務單位都有各自的基礎架構管道，可管理工作負載專案。

如果您有負責部署所有專案和基礎架構的中央團隊，或許會偏好由中央團隊管理單一基礎架構管線。這個中央團隊可以接受工作負載團隊的提取要求，以便在建立專案前審查並核准，也可以自行建立提取要求，回應已開立工單的系統。

如果個別工作負載團隊可以自訂管道，且您想為管道設計更精細的特殊權限服務帳戶，則可能偏好更精細的管道。

SIEM 匯出：藍圖會管理 Security Command Center 中的所有安全性發現項目。

決定是否要將 Security Command Center 的安全發現項目匯出至 Google Security Operations 或現有 SIEM 等工具，或是由團隊使用主控台查看及管理安全發現項目。您可能會為不同團隊設定多個匯出作業，並為這些團隊設定不同的範圍和職責，以及專屬篩選條件。

後續步驟