營運最佳做法

本節將介紹在將其他工作負載部署至 Google Cloud 環境並進行操作時，必須考量的作業。本節並未詳述雲端環境中的所有作業，而是介紹與結構建議和藍圖部署的資源相關的決策。

更新基礎資源

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

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

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

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

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

如需各專案可設定屬性的完整參考資料，請參閱自動化管道中的專案工廠輸入變數。

大規模管理權限

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

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

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

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

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

使用 Active Assist 產品組合，將環境調整至最佳狀態

除了身分與存取權管理建議工具外， Google Cloud 也提供 Active Assist 服務組合，提供如何最佳化環境的最佳化建議。舉例來說，防火牆深入分析或閒置專案建議工具提供可行建議，有助於強化安全防護機制。

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

為機構政策授予例外狀況

藍圖會強制執行一組機構政策限制，這些限制適用於多數客戶的多數情況，但您可能有合法的用途，需要針對廣泛套用的機構政策設定有限例外狀況。

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

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

使用 VPC Service Controls 保護資源

藍圖會強制執行必要的設定 (例如受限制的 VIP)，協助您為 VPC Service Controls 準備環境。不過，由於切換至強制模式可能會造成中斷，因此需要為貴機構規劃專屬的計畫，因此範本一開始只會在模擬執行模式下部署 VPC Service Controls。

安全範圍會拒絕來自範圍外流量的存取權，包括主控台、開發人員工作站，以及用於部署資源的基礎管道。 Google Cloud 如果您使用 VPC Service Controls，必須在範圍中設計例外狀況，允許您指定的存取路徑。

VPC Service Controls 範圍適用於 Google Cloud 機構與外部來源之間的資料外洩控管機制。邊界並非用來取代或複製允許政策，以便精細控管個別專案或資源的存取權。設計和建構邊界時，建議您使用通用的統一邊界，以降低管理成本。

如果您必須設計多個邊界，以便精細控管貴 Google Cloud 機構內的服務流量，建議您明確定義較複雜的邊界結構可解決的威脅，以及邊界之間的存取路徑，以便執行所需的操作。

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

• 哪些用途需要 VPC Service Controls。
• 是否有必要的 Google Cloud 服務支援 VPC Service Controls。
• 如何設定緊急權限，以便在自動化管道中斷時修改邊界。
• 如何使用啟用 VPC Service Controls 的最佳做法來設計及實作範圍。

將範圍從模擬模式變更為強制模式後，建議您設計一個程序，以便持續將新專案新增至正確的範圍，並設計例外狀況程序，以便在開發人員有新用途但遭現有範圍設定拒絕時，將專案新增至該範圍。

在其他機構中測試全機構變更

建議您在未測試的情況下，絕對不要將變更部署至正式環境。針對工作負載資源，您可以透過開發、非實際工作環境和實際工作環境等不同的環境，實現這種做法。不過，該機構的部分資源並未提供獨立環境，無法方便進行測試。

如果要進行機構層級變更，或其他可能影響實際環境的變更 (例如識別資訊提供者和 Cloud Identity 之間的設定)，建議您建立單獨的機構進行測試。

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

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

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

無論在何種情況下，使用者透過 SSH 或 RDP 存取 VM 都可能會導致權限升級風險，因此您應在設計存取模型時考量這點。使用者可以在該 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中處理記錄和發現事項。

• 針對稽核記錄，請設計記錄檢視畫面，為個別團隊授予存取集中化記錄值區中記錄子集的權限，而不要將記錄複製到多個值區，因為這樣會增加記錄儲存空間成本。
• 針對安全性發現項目，請為 Security Command Center 授予資料夾層級和專案層級角色，讓團隊直接在控制台中查看及管理專案的安全性發現項目。

持續開發控制項程式庫

藍圖會先從偵測及防範威脅的控制項基本設定開始。建議您查看這些控制項，並根據需求新增其他控制項。下表概述了強制執行治理政策的機制，以及如何因應額外需求擴充這些機制：

隨著您對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 Secret Accessor IAM 角色授予需要存取密鑰的使用者或服務帳戶。建議您將 IAM 角色授予個別機密金鑰，而非專案中的所有機密金鑰。

請盡可能在 CI/CD 管道中自動產生正式版機密資料，並讓使用者無法存取 (除非是緊急情況)。在這種情況下，請務必確保您沒有將 IAM 角色授予任何使用者或群組，以便查看這些密鑰。

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

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

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

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

下表列出緊急帳戶的部分用途示例。

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

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

無論您採用哪種機制，請考慮如何在作業上解決下列問題：

• 您如何設計緊急存取權的範圍和精細程度？舉例來說，您可以為不同的業務單位設計不同的緊急機制，確保各單位不會互相干擾。
• 您的機制如何防止濫用行為？您是否需要核准？舉例來說，您可以將操作分開，讓一人持有憑證，另一人持有 MFA 權杖。
• 您如何稽核及發出破窗權限的警報？舉例來說，您可以設定自訂 Event Threat Detection 模組，在使用預先定義的緊急帳戶時建立安全性發現項目。
• 事件結束後，如何移除緊急存取權並恢復正常運作？

針對常見的權限提升工作和變更回復作業，建議您設計自動化工作流程，讓使用者不必為其使用者身分提升權限，即可執行操作。這種做法有助於減少人為錯誤並提高安全性。

對於需要定期介入的系統，自動修正可能是最佳解決方案。Google 鼓勵客戶採用零接觸正式版方法，透過自動化、安全 Proxy 或經過審查的 Breakglass 進行所有正式版變更。Google 為希望採用 Google SRE 做法的客戶提供 SRE 書籍。

後續步驟

• 請參閱「部署藍圖」(本系列的下一篇文件)。