部署藍圖

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 可讓您定義安全性政策，禁止存取受信任範圍外的 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 Premium。

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

命名慣例

建議您為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

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

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

自訂角色

rl-description

如要查看角色的其他資訊，請按一下「Where」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 是儲存空間值區的額外資訊。 你可以使用簡短且人類可讀的縮寫。

例如：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 範圍：藍圖建議使用單一範圍，其中包含 Shared VPC 拓撲的所有服務專案。

您可能需要為機構建立多個安全防護範圍，或者決定完全不使用 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 等工具，或是由團隊使用主控台查看及管理安全發現項目。您可能會為不同團隊設定多個匯出作業，並使用專屬篩選器，這些團隊的範圍和職責各不相同。

後續步驟