本節說明可用來部署藍圖的程序、命名慣例,以及藍圖建議的替代方案。
整合所有資訊
如要按照本藍圖的最佳做法和建議,部署自己的企業基礎架構,請按照本節概略說明的各項工作進行。部署作業需要結合必要的設定步驟、透過 GitHub 上的 terraform-example-foundation 進行自動部署,以及在完成初始基礎部署後必須手動設定的額外步驟。
程序 | 步驟 |
---|---|
部署基礎管道資源前的必要條件 |
請先完成下列步驟,再部署基礎管道:
如要連線至現有的內部部署環境,請準備下列項目: |
從 GitHub 部署 terraform-example-foundation 的步驟 |
請按照各階段的 README 指示,從 GitHub 部署 terraform-example-foundation:
|
IaC 部署後的其他步驟 |
部署 Terraform 程式碼後,請完成下列操作:
|
針對機密工作負載的客戶提供額外的管理控管機制
Google Cloud 提供其他管理控管機制,有助於滿足安全性和法規遵循要求。不過,某些控制項會涉及額外成本或營運權衡,可能不利於每位客戶。這些控制項也需要自訂輸入內容,以滿足您的特定需求,這些需求無法在設計圖中以預設值全自動化。
本節將介紹您可集中套用至基礎架構的安全控制項。本節並未詳述所有可套用至特定工作負載的安全控管機制。如要進一步瞭解 Google 的安全性產品和解決方案,請參閱Google Cloud 安全性最佳做法中心。
根據法規遵循要求、風險偏好度和資料敏感度,評估下列控管措施是否適合您的基礎架構。
控制項 | 說明 |
---|---|
您可以使用 VPC Service Controls 定義安全性政策,禁止存取受信任範圍外的 Google 代管服務、禁止透過不受信任的位置存取資料,以及降低資料竊取的風險。不過,除非您定義例外狀況,允許預期的存取模式,否則 VPC Service Controls 可能會導致現有服務中斷。 評估減少資料竊取風險的價值是否值得採用 VPC Service Controls 所帶來的複雜性和營運開銷。範本會準備必要的網路控制項和 VPC Service Controls 範圍模擬資料,但您必須採取額外步驟,系統才會強制執行範圍。 |
|
您可能必須遵守法規要求,僅在核准的地理位置部署雲端資源。這項機構政策限制會強制規定資源只能部署在您定義的位置清單中。 |
|
Assured Workloads 提供額外法規遵循控管機制,協助您遵守特定法規體制。藍圖會在部署管道中提供啟用選用的變數。 |
|
您可能需要記錄所有對特定敏感資料或資源的存取行為。 評估工作負載處理需要資料存取記錄的敏感資料,並為處理敏感資料的每項服務和環境啟用記錄。 |
|
使用 Access Approval 後,Cloud Customer Care 和工程團隊必須明確取得您的核准,才能存取您的客戶內容。 評估審查 Access Approval 要求所需的作業流程,以減少解決支援事件的延遲時間。 |
|
透過「金鑰存取理由」功能,您可以透過程式碼控制 Google 是否能存取您的加密金鑰,包括自動操作和客戶服務團隊存取客戶內容。 評估與金鑰存取依據相關的成本和營運額外負擔,以及對 Cloud External Key Manager (Cloud EKM) 的依附性。 |
|
Cloud Shell 是線上開發環境,這個殼層會在您環境之外由 Google 管理的伺服器上代管,因此不會受到您可能在自己的開發人員工作站上實作的控制項影響。 如果您想嚴格控管開發人員可用來存取雲端資源的工作站,請停用 Cloud Shell。您也可以評估Cloud Workstations,在自己的環境中使用可設定的工作站選項。 |
|
Google Cloud 可讓您根據存取層級屬性 (例如群組成員資格、信任的 IP 位址範圍和裝置驗證) 限制控制台 Google Cloud 的存取權。部分屬性需要額外訂閱 Chrome Enterprise 進階版。 評估您信任的存取模式,以便使用者存取網頁版應用程式 (例如控制台),做為更大規模的零信任部署的一部分。 |
命名慣例
建議您為Google Cloud 資源採用標準化的命名慣例。下表說明藍圖中資源名稱的建議慣例。
資源 | 命名慣例 |
---|---|
資料夾 |
例如: |
專案 ID |
例如: |
虛擬私有雲網路 |
例如: |
子網路 |
例如: |
防火牆政策 |
例如:
|
Cloud Router |
例如: |
Cloud Interconnect 連線 |
例如: |
Cloud Interconnect VLAN 連結 |
例如: |
群組 |
其中 例如: |
自訂角色 |
其中 例如: |
服務帳戶 |
其中:
例如: |
儲存空間值區 |
其中:
例如: |
替代預設最佳化建議
藍圖中建議的最佳做法可能不適用於每位客戶。您可以根據特定需求自訂任何最佳化建議。下表列出您可能需要的常見變化,這些變化會根據您現有的技術堆疊和工作方式而定。
決策區域 | 可能的替代方案 |
---|---|
機構:模板會使用單一機構做為所有資源的根節點。 |
「為 Google Cloud 目標網域決定資源階層」一文介紹了您可能會偏好多個機構的情況,例如:
|
資料夾結構:藍圖具有資料夾結構,可將工作負載劃分為頂層的 |
為 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:範本會在 | 如果您有一個團隊負責管理及稽核貴機構中的敏感機密金鑰,建議您只使用單一專案管理機密金鑰的存取權。 如果您讓工作負載團隊自行管理機密資料,可能就不需要使用集中式專案來管理機密資料存取權,而是讓團隊在工作負載專案中使用自己的 Secret Manager 執行個體。 |
Cloud KMS:此範本會在 |
如果您有一個團隊負責管理及稽核整個機構的加密金鑰,建議您只使用單一專案來管理金鑰存取權。集中式方法有助於滿足 PCI 值管鑰保管人等法規遵循要求。 如果您讓工作負載團隊自行管理金鑰,可能就不需要使用集中式專案來管理金鑰存取權,而是讓團隊在工作負載專案中使用自己的 Cloud KMS 例項。 |
匯總記錄接收器:此範本會在機構節點中設定一組記錄接收器,讓集中式安全性團隊能夠查看整個機構的稽核記錄。 | 您可能會有不同的團隊負責稽核業務的不同部分,而這些團隊可能需要不同的記錄來執行工作。在這種情況下,請在適當的資料夾和專案中設計多個匯出集結點,並建立篩選器,讓每個團隊只收到必要的記錄,或是設計記錄檢視畫面,針對常見記錄值區進行精細的存取權控管。 |
基礎架構管道的精細程度:此藍圖採用的模型為,每個業務單位都有獨立的基礎架構管道,用於管理各自的工作負載專案。 | 如果您有負責部署所有專案和基礎架構的中央團隊,可能會偏好由中央團隊管理的單一基礎架構管道。這個中央團隊可以接受工作負載團隊提交的提取要求,在專案建立前進行審查及核准,或是在收到支援單系統的回應時,自行建立提取要求。 如果個別工作負載團隊能夠自訂自己的管道,且您想為管道設計更精細的特權服務帳戶,那麼您可能會偏好更精細的管道。 |
SIEM 匯出:此範本可管理 Security Command Center 中的所有安全發現項目。 | 決定是否要將 Security Command Center 中的安全性發現項目匯出至 Google Security Operations 或現有的 SIEM 等工具,或是要讓團隊使用主控台查看及管理安全性發現項目。您可以為不同團隊設定多個匯出作業,每個團隊的範圍和職責各不相同,並為這些團隊設定專屬的篩選器。 |
後續步驟
- 使用 GitHub 上的 Terraform 範例基礎導入藍圖。
- 進一步瞭解最佳做法設計原則,請參閱 Google Cloud Well-Architected Framework。
請查看藍圖程式庫,協助您加快設計及建構常見的企業工作負載,包括:
請參閱相關解決方案,瞭解如何在基礎環境中部署。