Google ACE: 資源階層、IAM 與帳務管理 — 學習指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

屬於 Google Associate Cloud Engineer — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

資源階層、身份與存取權管理 (IAM) 以及帳務管理，共同構成 Google Cloud 操作的控制平面。一個具備韌性的設計始於清晰的階層結構 (組織、資料夾、專案) 以界定政策與責任範圍；應用最小權限 IAM，搭配以群組為中心的管理方式，並為工作負載使用短期憑證；使用預算、匯出和標籤來進行成本歸因；並透過組織政策與全面的稽核日誌來強制執行治理。卓越的營運來自於標準化繼承、集中化帳務與日誌，以及使用服務帳號模擬 (impersonation) 而非長期金鑰。本節詳述了核心的建構元素、其預期用途，以及應避免的常見失敗模式。

資源階層與身份模型

資源階層
- Organization (組織)：根節點，透過 Cloud Identity 或 Google Workspace 建立。擁有全域政策 (IAM、組織政策、標籤)。
- Folders (資料夾)：選用的分組方式，可用於部門、環境 (例如 dev、prod) 或應用程式。有助於委派管理與政策範圍界定。
- Projects (專案)：資源、API、配額、IAM 及帳務關聯的管理邊界。大多數 Google Cloud 資源都是專案的子層。
- Inheritance (繼承)：IAM 政策與組織政策由上而下繼承。較高層級的拒絕 (Deny) 與限制 (Constraint) 優先。規劃資源放置位置 (組織 → 資料夾 → 專案) 時應盡量減少例外與緊急應變 (break-glass) 的需求。
Principals (主體)
- Google 帳號 (使用者)、Google 群組、服務帳號，以及透過 Workload Identity Federation 來的外部身份。
- 對於真人存取，應以 Google 群組作為主要的綁定目標，以簡化生命週期變更與審查。
- 服務帳號代表應用程式或服務；應優先使用 workload identity 而非金鑰。
Workload identities (工作負載身份)
- 在 Google Cloud 內部：GCE/GAE/Cloud Run/GKE 使用 metadata server 為其附加的服務帳號鑄造 (mint) 短期權杖 (token)。
- 在 Google Cloud 外部：Workload Identity Federation 可將外部身份 (OIDC/SAML/AWS) 對應至服務帳號，無需使用靜態金鑰。
設計權衡與失敗模式
- 缺乏資料夾結構而四處擴散的專案會導致政策重複與漂移。
- 直接將角色授予使用者會增加管理負擔；應優先採用基於群組的綁定。
- 使用具有過大權限的 Compute Engine 預設服務帳號會提高風險；應為每個工作負載建立最小權限的服務帳號。
- 將專案錯置於錯誤的資料夾下會繼承不正確的政策；應使用標籤或在變更管制的狀況下謹慎移動專案。

IAM 角色與政策設計

角色類型
- 基本角色 (Viewer、Editor、Owner)：權限範圍廣，為舊式角色。除非是用於嚴格管制的緊急應變 (break-glass)，否則應避免使用。
- 預先定義角色：針對各服務精心設計；大多數使用情境應優先選用。
- 自訂角色：在組織或專案層級，為滿足特定需求而彙總的權限集合。
- 條件式角色：IAM Conditions (CEL) 可加入情境脈絡，例如資源名稱、資料夾、標籤或時間；可用來限制權限過大的角色。
政策原則
- 最小權限：僅在最窄的範圍 (資源/專案/資料夾) 授予最小所需角色。
- 職責分離：切分職責 (例如，網路管理員 vs. 安全管理員 vs. 帳務管理員)。不要將部署與核准的操作耦合在單一主體上。
- 繼承意識：在組織/資料夾層級的綁定會影響所有後代；在套用前應記錄預期的影響範圍 (blast radius)。
Deny 政策
- IAM Deny 會明確地阻擋權限，即使該權限在別處已被授予；可用於建立防護圍欄 (guardrails) (例如，拒絕 iam.serviceAccountKeys.create)。
- Deny 具有優先權；需確保有文件化的緊急應變 (break-glass) 機制，並搭配有時限的例外處理流程。
範例
- 將自訂角色從 dev 複製到 prod：

undefined

透過 OS Login 授予基於群組的 SSH 管理員權限：

undefined

失敗模式
- 在組織或資料夾層級授予 Editor 角色，會無意中將權限級聯到所有專案。
- 條件過於嚴格的條件式角色可能會無聲地破壞自動化流程；在正式推出前應使用 Policy Troubleshooter 進行測試。
- 自訂角色可能會落後於新推出的權限；應定期審查。

帳務與成本管理

帳務帳號與關聯
- 一個專案必須且只能連結到一個帳務帳號，才能使用需付費的服務。
- 角色：Billing Account Administrator 管理帳號與付款方式；Billing Account User 負責連結專案；Project Billing Manager 管理專案的帳務連結。
- 集中至一個公司帳務帳號；透過更新專案的帳務關聯來遷移專案。
預算、警示與歸因
- 預算會產生警示，但不會中止消費。若需要強制執行，可使用 Pub/Sub 搭配 Cloud Functions/Cloud Run 進行程式化修復。
- 將帳務資料匯出至 BigQuery 以進行每日/每月的成本分析與預測；結合資源標籤 (label) 與標記 (tag) 進行歸因。
- 標籤 (Labels) 與標記 (Tags)：標準化鍵值 (key) (例如 cost_center、env、app)。缺少標籤會降低歸因的準確性。
成本分析
- 使用 BigQuery 匯出的資料，透過 SQL 按 SKU/服務計算滾動預測。與資源元數據 (例如 GCE 標籤) 進行 JOIN 以獲得更精細的報告。
- 對於跨專案分析，可以匯總所有專案的匯出資料，或將資料匯出到單一的中央資料集。
常見陷阱
- 新專案未設定預算；應建立一個政策，在專案建立時自動創建預算。
- 沒有 BigQuery 匯出意味著歷史洞察有限；應及早啟用以建立歷史記錄。
- 在專案上使用個人信用卡會使責任歸屬碎片化；應整合到公司的帳務帳號下，並設定適當的 IAM 與付款設定檔。
- 共享服務專案中的成本異常需要透過標記與內部計費 (cross-charging) 政策來處理。

安全的工作負載驗證與存取模式

服務帳號模擬 (impersonation)
- 優先使用模擬，而非金鑰。將 roles/iam.serviceAccountTokenCreator 角色授予呼叫者身分；呼叫者會取得短期有效的權杖，以服務帳號的身分執行操作。
- 範例： gcloud auth print-access-token
  –impersonate-service-account sa-deployer@PROJECT_ID.iam.gserviceaccount.com
金鑰與輪替
- 避免使用使用者管理的金鑰。若有必要，請將其儲存在 Secret Manager 中，至少每 90 天輪替一次，監控其使用情況，並透過 VPC Service Controls 和 CMEK 加以限制。
- 強制執行限制條件以禁止建立金鑰： constraints/iam.disableServiceAccountKeyCreation = true
OS Login 與 SSH
- 使用 OS Login 搭配基於群組的 IAM 角色 (compute.osLogin, compute.osAdminLogin)。每個使用者將自己的公開 SSH 金鑰上傳至其 Google 帳戶，以實現可追溯的存取。透過管理員活動 (Admin Activity) 和資料存取 (Data Access) 稽核日誌進行稽核。
- 避免將共用的 SSH 金鑰內建 (bake) 在映像檔中。
Workload Identity Federation
- 對於地端或其他雲端環境，請設定身分聯合，以在不建立金鑰的情況下授予 Google Cloud 的存取權限，從而降低資料外洩的風險。
失敗模式與緩解措施
- 將金鑰儲存在版本庫 (repos) 或 CI/CD 變數中會導致洩露；應改用模擬 (impersonation) 或身分聯合 (federation)。
- 具有寬鬆角色的預設服務帳號風險很高；應使用 constraints/iam.allowedPolicyMemberDomains 進行限制，並移除原始角色 (primitive roles)。
- 舊版 GCE 執行個體上若缺少存取範圍 (scope)，可能會阻擋 API 存取；建議改用每個 API 的 IAM 權限搭配應用程式預設憑證 (default application credentials)。

治理、機構政策、稽核與疑難排解

機構政策與限制條件
- 使用限制條件強制執行防護機制：不允許 VM 使用外部 IP、限制區域、防止金鑰建立、限制允許的服務、要求統一的值區層級存取權、限制網域共用。
- 依資源階層指定目標，並使用標籤針對特定環境的例外情況進行微調。
Cloud Identity 與生命週期
- Cloud Identity 提供使用者目錄、SSO 和管理角色。進行小範圍的委派（例如，群組管理員、使用者管理管理員），並自動化到職、異動、離職 (JML) 的工作流程，以更新群組成員資格和存取權。
- 對於敏感環境，使用 Access Approvals 和 Access Transparency。
稽核記錄
- 「管理員活動」和「系統事件」記錄永遠開啟；「資料存取」記錄必須明確啟用，且可能會產生費用。
- 透過將來自資料夾/機構的彙總接收器路由到一個安全專案中，來進行集中管理。使用 CMEK 和受限的存取權來保護。
- 監控「政策拒絕」記錄，以偵測機構政策衝突。
多專案疑難排解工具組
- Policy Troubleshooter：根據有效的 IAM 和拒絕政策，診斷存取被允許或拒絕的原因。
- Cloud Asset Inventory：查詢跨機構/資料夾/專案的 IAM 繫結和政策歷史記錄。範例：

undefined

Logs Explorer：依主體、方法和資源進行篩選，以追蹤跨專案的操作。
用於操作人員情境切換的 gcloud 設定：

undefined

常見的失敗模式：機構政策衝突導致部署受阻、缺少資料存取記錄妨礙調查，以及在錯誤的範圍授予 IAM 權限。建立 Runbook 和變更前預覽，以降低事件的平均解決時間 (MTTR)。

實務問題情境

Aurelia Retail 在一次收購後，整合了多個團隊和專案。他們必須集中管理帳務、對數百個 Compute Engine VM 強制執行一致的 IAM 和 SSH 管理，並在最小干擾下建立治理機制。

建立公司帳務帳戶並連結專案

理由：單一帳務帳戶可集中管理付款方式、抵用金和預算。將 Billing Account User 權限授予專案遷移群組，並將 Project Billing Manager 權限授予團隊負責人，以便在不授予過多權限的情況下重新連結專案。
執行步驟：在主控台中建立帳務帳戶。為每個專案更新其帳務關聯。立即在一個中央分析專案中，啟用將帳務資料匯出至 BigQuery 的功能。

使用資料夾和標籤標準化資源階層

理由：將專案放置在環境資料夾（prod、nonprod）下，支援防護機制的繼承和針對性的例外。標籤允許細粒度的機構政策目標設定，而無需複製資料夾樹狀結構。
執行步驟：為 prod 和 nonprod 建立資料夾；相應地移動專案。定義標籤 env=prod|nonprod 和應用程式識別碼。

實作基於群組的 IAM，並遵循最低權限和職責分離原則

理由：群組簡化了生命週期管理和稽核。在部署人員、安全人員和網路管理員之間劃分角色，可減少影響範圍。
執行步驟：為 app-operators、net-admins、sec-admins 和 billing-managers 建立 Google 群組。根據需要在資料夾/專案範圍繫結預先定義的角色；避免使用基本角色。

強制執行基於 OS Login 的 SSH 管理

理由：附加到使用者帳戶的個別 SSH 金鑰提供了可歸因、可撤銷的存取權。OS Login 角色透過 IAM 管理 Linux 帳戶，從而消除了共用金鑰。
執行步驟：在每個專案中，啟用 OS Login 中繼資料。將 compute.osAdminLogin 權限授予 ops-admins 群組。範例：

undefined

用模擬 (impersonation) 取代服務帳戶金鑰

理由：短期有效的憑證可降低金鑰外洩的風險，並簡化輪替。稽核記錄會捕捉到誰模擬了誰，從而提高可追溯性。
執行步驟：將 roles/iam.serviceAccountTokenCreator 權限授予 CI/CD 執行器身分，使其能操作工作負載服務帳戶。移除使用者管理的金鑰，並應用機構政策來阻止新金鑰的建立。

應用機構政策以建立防護機制

理由：限制條件可防止所有專案中出現具風險的設定，同時在有正當理由的情況下，允許加上標籤的例外。
執行步驟：強制執行限制條件，以不允許在 prod 環境中使用外部 IP、將區域限制在核准的地點，並停用服務帳戶金鑰的建立。使用標籤來允許有文件化核准的特定專案的例外情況。

建立成本治理

理由：預算會在超支前提醒擁有者；匯出至 BigQuery 有助於成本歸屬和預測。標籤可將資源支出對應到成本中心。
執行步驟：為每個資料夾和主要應用程式建立預算，並設定 Pub/Sub 通知。透過部署範本和 CI 中的政策驗證來強制執行標籤政策。

集中稽核並加速疑難排解

理由：跨機構的彙總記錄和資產清查可加速調查和合規報告的產出。
執行步驟：建立彙總接收器，將資料傳送到一個有 CMEK 保護值區的安全專案。為關鍵服務（Cloud Storage、BigQuery）啟用資料存取記錄。使用 Cloud Asset Inventory 定期掃描 IAM 繫結。訓練操作人員在存取失敗時使用 Policy Troubleshooter，並使用 Logs Explorer 追蹤管理員活動/資料存取。