營運最佳做法

Last reviewed 2025-05-15 UTC

本節將介紹您在 Google Cloud 環境中部署及運作額外工作負載時，必須考量的作業。本節並非要詳盡列出雲端環境中的所有作業，而是要介紹與藍圖部署的架構建議和資源相關的決策。

更新基礎資源

雖然藍圖為基礎環境提供主觀的起點，但基礎需求可能會隨著時間增加。完成初始部署後，您可能會調整設定，或建構新的共用服務，供所有工作負載使用。

如要修改基礎資源，建議您透過基礎管道進行所有變更。如要瞭解如何編寫及合併程式碼，並觸發部署管道，請參閱分支策略簡介。

決定新工作負載專案的屬性

透過自動化管道的專案工廠模組建立新專案時，您必須設定各種屬性。設計及建立新工作負載專案的程序應包含下列決策：

  • 要啟用哪些 Google Cloud API
  • 要使用哪個共用虛擬私有雲，或是要建立新的虛擬私有雲網路
  • 要為管道建立的初始 project-service-account 建立哪些 IAM 角色
  • 要套用哪些專案標籤
  • 專案部署的資料夾
  • 要使用哪個帳單帳戶
  • 是否要將專案新增至 VPC Service Controls 服務範圍
  • 是否要為專案設定預算和帳單快訊門檻

如要完整瞭解每個專案可設定的屬性，請參閱自動化管道中專案 Factory 的輸入變數。

大規模管理權限

在基礎架構上部署工作負載專案時，您必須考量如何授予這些專案的目標開發人員和消費者存取權。建議您將使用者新增至現有身分識別供應商管理的群組，然後將群組與 Cloud Identity 同步處理，再將 IAM 角色套用至群組。請務必謹記最低權限原則。

此外，我們也建議您使用 IAM 建議工具，找出授予過多權限角色的允許政策。設計程序，定期檢查最佳化建議，或自動將最佳化建議套用至部署管道。

協調網路團隊和應用程式團隊之間的變更

藍圖部署的網路拓撲會假設您有一個團隊負責管理網路資源，以及另一個團隊負責部署工作負載基礎架構資源。工作負載團隊部署基礎架構時，必須建立防火牆規則，允許工作負載元件之間的預期存取路徑，但他們無權自行修改網路防火牆政策。

規劃團隊如何協作，以協調部署應用程式所需的集中式網路資源變更。舉例來說，您可能會設計一個程序，讓工作負載團隊為應用程式要求標記。網路團隊接著會建立標記，並在網路防火牆政策中新增規則，允許流量在帶有標記的資源之間流動，然後將使用標記的 IAM 角色委派給工作負載團隊。

透過 Active Assist 系列產品將環境調整至最佳狀態

除了 IAM 建議工具， Google Cloud 也提供 Active Assist 系列服務，針對如何將環境調整至最佳狀態提供建議。舉例來說，防火牆洞察或無人看管的專案建議工具提供實用建議，有助於強化安全防護機制。

設計程序，定期查看最佳化建議，或自動將最佳化建議套用至部署管道。決定哪些建議應由中央團隊管理，哪些應由工作負載擁有者負責，並套用 IAM 角色來存取建議。

授予機構政策例外狀況

藍圖會強制執行一組組織政策限制，這些限制適用於多數情況，且建議多數客戶採用。不過，您可能會有正當的用途，需要對廣泛執行的組織政策進行有限的例外處理。

舉例來說，藍圖會強制執行 iam.disableServiceAccountKeyCreation 限制。這項限制是重要的安全控管措施，因為服務帳戶金鑰一旦外洩，可能會造成重大負面影響，而且在大多數情況下，都應使用比服務帳戶金鑰更安全的替代方案進行驗證。不過，有些用途可能只能使用服務帳戶金鑰進行驗證，例如需要存取Google Cloud 服務但無法使用 Workload Identity Federation 的地端伺服器。在這種情況下，只要強制執行額外的補償控制措施 (例如管理服務帳戶金鑰的最佳做法)，您或許可以決定允許政策例外狀況。

因此，您應設計工作負載程序，要求政策例外狀況，並確保負責授予例外狀況的決策者具備技術知識，可驗證用途，並諮詢是否必須採取額外控管措施來補償。為工作負載授予例外狀況時，請盡可能縮小機構政策限制的範圍。您也可以有條件地將限制新增至組織政策，方法是定義標記，授予政策例外或強制執行權限，然後將標記套用至專案和資料夾。

使用 VPC Service Controls 保護資源

藍圖會強制執行受限制 VIP 等必要設定，協助您準備 VPC Service Controls 環境。不過，藍圖一開始只會在模擬測試模式中部署 VPC Service Controls，因為切換至強制執行模式可能會造成中斷，且需要為貴機構規劃專屬的切換方式。

perimeter 會拒絕來自 perimeter 外部的流量存取受限 Google Cloud 服務，包括主控台、開發人員工作站，以及用於部署資源的基礎管道。如果您使用 VPC Service Controls，必須設計 perimeter 例外狀況，允許您預期的存取路徑。

VPC Service Controls perimeter 的用途是控管貴機構與外部來源之間的資料外洩。 Google Cloud 邊界並非要取代或複製個別專案或資源的精細存取控管允許政策。設計及建構周邊時，建議使用通用的統一週邊，以降低管理負擔。

如果您必須設計多個服務範圍，才能精細控管 Google Cloud 機構內的服務流量，建議您清楚定義更複雜的服務範圍結構所要防範的威脅，以及預期作業所需的服務範圍間存取路徑。

如要採用 VPC Service Controls，請評估下列事項：

將 perimeter 從模擬測試模式變更為強制執行模式後，建議您設計相關程序，確保新專案一律加入正確的 perimeter，並在開發人員遇到新用途但遭目前的 perimeter 設定拒絕時，設計例外狀況程序。

在獨立機構中測試全機構變更

建議您務必先測試變更，再部署至正式環境。對於工作負載資源，這種做法可透過開發、非正式和正式環境來簡化。不過，機構中的某些資源沒有獨立環境，無法進行測試。

如要進行機構層級的變更，或是其他可能影響生產環境的變更 (例如身分識別提供者與 Cloud Identity 之間的設定)，請考慮建立獨立的機構進行測試。

控管虛擬機器的遠端存取權

由於我們建議您透過基礎管道、基礎架構管道和應用程式管道部署不可變更的基礎架構，因此也建議您僅在有限或特殊用途的情況下，透過 SSH 或 RDP 授予開發人員虛擬機器的直接存取權。

如需遠端存取，建議您盡可能使用 OS 登入管理使用者存取權。這種做法會使用受管理 Google Cloud 服務，強制執行存取權控管、帳戶生命週期管理、兩步驟驗證和稽核記錄。或者，如果您必須透過中繼資料中的 SSH 金鑰或 RDP 憑證授予存取權，則您有責任管理憑證生命週期，並在 Google Cloud外部安全地儲存憑證。

在任何情況下，如果使用者擁有 VM 的 SSH 或 RDP 存取權，都可能造成權限提升風險，因此設計存取權模式時，請務必將這點納入考量。使用者可以在該 VM 上執行程式碼，並享有相關聯服務帳戶的權限，或查詢中繼資料伺服器，查看用於驗證 API 要求的存取權權杖。如果您並非有意讓使用者以服務帳戶的權限運作，這項存取權就可能成為權限提升。

規劃預算快訊，避免支出過度

藍圖會實作Google Cloud 架構完善的成本最佳化最佳做法，以管理成本，包括：

  • 在企業基礎的所有專案中使用單一帳單帳戶。

  • 為每個專案指派 billingcode 中繼資料標籤，用於在成本中心之間分配成本。

  • 設定預算和快訊門檻。

您有責任規劃預算及設定帳單快訊。如果預測支出即將達到預算的 120%，藍圖就會為工作負載專案建立預算快訊。這個方法可讓中央團隊找出並減輕重大超支事件。如果支出大幅增加，且沒有明確原因，可能表示發生安全事件，應從成本控管和安全性的角度進行調查。

視用途而定，您可能會根據整個環境資料夾的費用，或與特定成本中心相關的所有專案，設定預算，而不是為每個專案設定精細的預算。此外，我們也建議您將預算和快訊設定委派給工作負載擁有者，他們可能會為日常監控設定更精細的快訊門檻。

如需成本最佳化指南，請參閱 FinOps 中心：提高成本效益。

在內部成本中心之間分配費用

您可以在控制台中查看帳單報表，以多種維度查看及預估費用。除了預先建構的報表外，我們建議您將帳單資料匯出至 prj-c-billing-export 專案中的 BigQuery 資料集。匯出的帳單記錄可讓您根據專案標籤中繼資料 (例如 billingcode)，在自訂維度 (例如內部成本中心) 上分配費用。

以下 SQL 查詢是範例查詢，可瞭解依billingcode專案標籤分組的所有專案費用。

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

如要設定這項匯出功能，請參閱將 Cloud Billing 資料匯出至 BigQuery。

如果您需要內部會計或成本中心之間的交易退單，請務必將從這項查詢取得的資料納入內部程序。

將偵測性控制措施的調查結果匯入現有 SIEM

雖然基礎資源可協助您設定稽核記錄和安全發現項目的匯總目的地，但您有責任決定如何使用這些信號。

如果您需要將所有雲端和地端環境的記錄檔匯總至現有 SIEM，請決定如何將 prj-c-logging 專案的記錄檔和 Security Command Center 的發現項目，擷取至現有工具和程序。如果單一團隊負責監控整個環境的安全性，您可能會為所有記錄和發現事項建立單一匯出項目；如果多個團隊各司其職，您可能會建立多個匯出項目，並根據各團隊的需求篩選記錄和發現事項。

或者，如果記錄檔量和費用過高，您可以只在Google Cloud中保留 Google Cloud 記錄檔和結果，避免重複。在這種情況下，請確保現有團隊具備適當的存取權和訓練，可直接在Google Cloud中處理記錄和調查結果。

  • 如果是稽核記錄，請設計記錄檢視畫面，將集中式記錄 bucket 中的部分記錄存取權授予個別團隊，而不是將記錄複製到多個 bucket，這樣會增加記錄儲存空間費用。
  • 如要查看安全性發現項目，請為 Security Command Center 授予資料夾層級和專案層級的角色，讓團隊直接在控制台中，查看及管理負責專案的安全性發現項目。

持續開發控制項程式庫

藍圖一開始會提供偵測及防範威脅的控制項基準。建議您查看這些控制選項，並根據需求新增其他控制選項。下表摘要說明強制執行控管政策的機制，以及如何根據額外需求擴充這些政策：

藍圖強制執行的政策控制項 如何擴大這些控制項的適用範圍

Security Command Center 會偵測多個安全來源的安全漏洞和威脅。

定義 Security Health Analytics 的自訂模組和 Event Threat Detection 的自訂模組。

機構政策服務會對Google Cloud 服務強制執行建議的機構政策限制。

從可用限制的預先建立清單中，強制執行其他限制，或建立自訂限制。

Open Policy Agent (OPA) 政策會在部署前，驗證基礎管道中的程式碼是否符合可接受的設定。

根據 GoogleCloudPlatform/policy-library 的指引，開發其他限制。

根據記錄指標和效能指標發出快訊：設定記錄指標，以便在 IAM 政策和部分敏感資源的設定發生變化時發出快訊。

針對您認為不應在環境中發生的記錄事件，設計其他記錄指標和警告政策。

自動記錄分析自訂解決方案會定期查詢記錄檔中的可疑活動，並建立 Security Command Center 發現項目。

使用安全記錄分析做為參考，撰寫其他查詢，為您要監控的安全事件建立發現項目。

自訂資產變更因應解決方案會建立 Security Command Center 發現項目，並可自動執行修正動作。

建立額外的 Cloud Asset Inventory 資訊提供，監控特定資產類型的變更，並編寫額外的 Cloud Run 函式，運用自訂邏輯回應政策違規事項。

這些控制選項可能會隨著您的需求和成熟度而有所變化。Google Cloud

使用 Cloud Key Management Service 管理加密金鑰

Google Cloud 為所有客戶內容提供靜態預設加密，同時提供 Cloud Key Management Service (Cloud KMS)，讓您進一步控管靜態資料的加密金鑰。建議您評估預設加密機制是否足夠，或是您是否有法規遵循需求，必須使用 Cloud KMS 自行管理金鑰。詳情請參閱「決定如何遵守靜態資料加密適用的法規」。

藍圖會在通用資料夾中提供 prj-c-kms 專案，並在每個環境資料夾中提供 prj-{env}-kms 專案，集中管理加密金鑰。這個方法可讓中央團隊稽核及管理工作負載專案中資源使用的加密金鑰，以符合法規和法規遵循要求。

視作業模式而定，您可能會偏好由單一團隊控管的 Cloud KMS 單一集中式專案執行個體，也可能偏好在每個環境中分別管理加密金鑰，或是偏好使用多個分散式執行個體，以便將加密金鑰的責任委派給適當的團隊。視需要修改 Terraform 程式碼範例，以符合您的作業模式。

您可以選擇強制執行客戶自行管理的加密金鑰 (CMEK) 機構政策，確保特定資源類型一律需要 CMEK 金鑰，且只能使用允許清單中受信任專案的 CMEK 金鑰。

使用 Secret Manager 儲存及稽核應用程式憑證

建議您切勿將機密密鑰 (例如 API 金鑰、密碼和私密憑證) 提交至原始碼存放區。請改為將密鑰提交至 Secret Manager，並將 Secret Manager 密鑰存取者 IAM 角色授予需要存取密鑰的使用者或服務帳戶。建議您將 IAM 角色授予個別密鑰，而非專案中的所有密鑰。

請盡可能在 CI/CD 管道中自動產生正式環境密鑰，並禁止使用者存取，除非是緊急情況。在這種情況下，請務必不要將檢視這些密鑰的 IAM 角色授予任何使用者或群組。

藍圖會在通用資料夾中提供單一 prj-c-secrets 專案，並在每個環境資料夾中提供 prj-{env}-secrets 專案，集中管理密鑰。這個方法可讓中央團隊稽核及管理應用程式使用的密鑰，以符合法規和法規遵循要求。

視作業模式而定，您可能會偏好由單一團隊控管的集中式 Secret Manager 執行個體，也可能偏好在每個環境中分別管理密鑰，或是偏好使用多個分散式 Secret Manager 執行個體，讓每個工作負載團隊都能管理自己的密鑰。視需要修改 Terraform 程式碼範例，以符合您的作業模式。

規劃高權限帳戶的緊急存取權

雖然我們建議透過基礎管道部署的版本控管 IaC 管理基礎資源的變更，但您可能遇到特殊或緊急情況，需要具備特殊權限才能直接修改環境。建議您規劃緊急存取帳戶 (有時稱為緊急呼叫或緊急帳戶)，以便在發生緊急狀況或自動化程序故障時，取得環境的高權限存取權。

下表說明緊急存取帳戶的部分用途範例。

急用權限用途 說明

超級管理員

緊急存取 Cloud Identity 使用的超級管理員角色，例如修正與身分聯盟或多重驗證 (MFA) 相關的問題。

機構管理員

緊急存取機構管理員角色，然後授予機構中任何其他 IAM 角色的存取權。

基礎管道管理員

如果基礎管道的自動化作業中斷，您可緊急存取Google Cloud 上的 CICD 專案和外部 Git 存放區，修改其中的資源。

營運或 SRE

作業或 SRE 團隊需要具備特殊權限，才能回應中斷或事件。包括重新啟動 VM 或還原資料等工作。

允許緊急存取的機制取決於您現有的工具和程序，但以下列出幾個範例機制：

  • 使用現有的特殊存取權管理工具，暫時將使用者新增至預先定義的群組，並授予高權限 IAM 角色，或使用高權限帳戶的憑證。
  • 預先佈建帳戶，僅供管理員使用。舉例來說，開發人員 Dana 可能會使用 dana@example.com 身分進行日常作業，並使用 admin-dana@example.com 身分進行緊急存取。
  • 使用即時權限提升存取權等應用程式，讓開發人員自行提升至權限較高的角色。

無論使用哪種機制，請考慮如何從作業層面解決下列問題：

  • 如何設計緊急存取權的範圍和細微程度？舉例來說，您可以為不同業務部門設計不同的緊急存取機制，確保彼此不會互相干擾。
  • How does your mechanism prevent abuse? 您是否需要核准？舉例來說，您可能已分割作業，由一人持有憑證，一人持有 MFA 權杖。
  • 您如何稽核及產生緊急存取快訊？舉例來說，您可以設定自訂 Event Threat Detection 模組，在系統使用預先定義的緊急存取帳戶時建立安全性發現項目。
  • 事件結束後，如何移除緊急存取權並恢復正常運作？

對於常見的權限提升工作和復原變更，我們建議設計自動化工作流程，讓使用者執行作業時，不需要提升使用者身分的權限。這種方法有助於減少人為錯誤並提升安全性。

如果系統需要定期介入，自動修正可能是最佳解決方案。Google 鼓勵客戶採用零接觸式生產方法，透過自動化、安全 Proxy 或經過稽核的緊急存取權，進行所有生產變更。Google 為有意採用 Google SRE 方法的客戶提供 SRE 書籍。

後續步驟