Google PCA: 組織設計、IAM 與雲端治理 — 學習指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

總覽

組織設計、IAM 與治理為所有 Google Cloud 架構運作的基礎。良好的設計能建立清晰的管理邊界、最小化影響範圍、實現最小權限原則、控制成本，並在多個團隊和環境中實現營運擴展。治理應強調護欄而非閘門：自動化設定安全、可衡量且可回復的預設值，同時將日常控制權委派給最接近工作負載的團隊。

資源階層與身分識別基礎

Google Cloud 資源形成一個嚴格的樹狀結構：Organization → Folders → Projects → Resources (例如 Compute Engine 執行個體、值區)。IAM 政策和 Organization Policy 限制會沿著樹狀結構向下繼承。

主要設計原則：

• 使用單一 Organization 來集中化治理。為主要的管理邊界 (例如，業務單位、地區，或受監管 vs. 非受監管) 建立頂層 Folders。
• 在每個邊界內，建立環境 Folders (prod、nonprod) 以應用差異化的政策。盡可能讓專案以工作負載為範疇且具備臨時性，以減少影響範圍並簡化費用分攤。
• 繼承：允許的授權會累加 (上層節點與當前節點的允許繫結聯集)。若使用 IAM Deny 政策，其優先權較高，即使存在允許授權也能阻擋存取。避免將寬鬆的角色置於樹狀結構的高層；其影響範圍廣大且難以撤銷。

身分識別來源：

• Cloud Identity 是員工的身分識別平台。與您的企業 IdP (SAML/OIDC) 整合，以集中化驗證和生命週期管理 (員工的加入、異動與離職)。若有需要，可使用 Google Cloud Directory Sync 進行屬性和群組同步。
• Groups 是主要的 IAM 主體。基於群組的存取方式能實現可擴展的變更和可稽核的所有權。採用群組中的群組模式 (例如，net-admins、sec-admins、app-team-A)，並限制誰可以管理群組成員。
• Service accounts 代表工作負載。優先選擇使用短期憑證的 service account impersonation，而非儲存金鑰。避免使用使用者管理的服務帳號金鑰；將其視為特例，並實施嚴格的審批和輪替。
• 工作負載身分識別模式：
  • GKE Workload Identity 將 Kubernetes service accounts 繫結至 Google service accounts；從而消除了節點層級的憑證。
  • Workload Identity Federation 讓外部身分 (地端、其他雲端、GitHub Actions) 無需金鑰即可取得短期的 Google 存取權。使用 pool/provider 範圍和屬性條件來限制存取。

常見的失敗模式與緩解措施：

• 在 Folder 或 Organization 層級授予基本角色 (Owner/Editor/Viewer) 會導致普遍的權限過高問題。僅在範圍嚴格限定的緊急應變專案中使用。
• 所有權不明的群組氾濫會破壞最小權限原則。強制執行群組的命名、用途標籤和擁有者元資料。
• 孤立的服務帳號和過時的繫結會累積風險。安排定期的存取權審查，並使用 IAM Recommender 來減少未使用的權限。

IAM 模型、角色與存取操作

角色與繫結：

• Predefined roles 是為特定服務精心設計的，應作為預設選擇。
• 當 Predefined roles 的權限過於粗略時，可使用 Custom roles 來填補缺口。從觀察到的最小必要權限集開始建立；並對其進行版本控制和測試。
• Basic roles (Viewer/Editor/Owner) 是舊版角色，權限過於寬鬆。避免在 Organization 和 Folder 範圍使用。不要將 Owner 用於日常操作；應保留給平台緊急應變使用，並搭配強力的補償性控制措施。
• 條件式角色繫結 (IAM Conditions) 使用諸如 resource.name、resource.matchTag、request.time 或 request.auth.audiences 等屬性，來限制繫結生效的時間和地點。可將條件用於有時間限制的存取、對正式環境的標籤範圍存取，或限制地點的操作。

最小權限與權限提升：

• 將「讀取」、「操作」和「管理」的職責分開。例如，網路、安全和應用程式團隊在不同的範圍內獲得不同的角色。
• 使用 Access Approval 工作流程或由工單驅動的自動化來實現即時權限提升，透過條件繫結有時間限制的角色。

拒絕政策與風險：

• IAM Deny 可以集中阻擋高風險權限 (例如，resourcemanager.projects.delete)。Deny 會覆寫 allow，並適用於整個子樹。務必徹底驗證；設定錯誤的 deny 可能會鎖住自動化程序或導致部署中斷。

可稽核性與審查：

• 在 Organization 層級啟用 Admin Activity logs；預設會保留 400 天。對於敏感服務，啟用 Data Access logs 並將其路由到 BigQuery 以進行長期保留和稽核。
• 實施定期的存取權審查：使用 Cloud Asset Inventory 列舉所有繫結，與所有權登記冊進行比較，移除 IAM Recommender 建議的未使用角色，並驗證特例的到期日。

實用範例 (有時間限制、標籤範圍的繫結)：

• gcloud projects add-iam-policy-binding PROJECT_ID –member=“group:prod-ops@example.com” –role=“roles/compute.instanceAdmin.v1” –condition=‘title=ProdOnlyTemp,expression=resource.matchTag(“organizations/1234567890/env”,“prod”) && request.time < timestamp(“2026-01-01T00:00:00Z”)’

財務治理與組織政策護欄

帳務架構：

• 將一或多個帳務帳戶集中管理，並由財務部門持有。僅在法律或營運上有要求時（例如，獨立的法人實體或經銷商模式）才使用多個帳務帳戶。
• 透過自動化將專案連結至帳務帳戶；不允許在已核准的工作流程之外手動進行連結。

費用分攤與成本可視性：

• 一致地使用標籤 (labels) 與成本分配標記 (cost allocation tags)。標籤是自由格式的中繼資料，用於篩選和報告；標記具階層性，可用於 IAM 條件與政策中。為選定的標記啟用成本分配，使其顯示在帳務匯出資料中。
• 將帳務資料匯出至 BigQuery 進行分析；依據負責人、成本中心和環境建立儀表板。要求每個專案都必須有權責負責人與預算。

預算與異常偵測：

• 在資料夾和專案層級建立帶有警示的預算。加入程式化的應對措施（例如，通知輪值人員、開立工單，或停用新的配額增加）以抑制失控的支出。
• 根據預期用量使用配額 (Quotas) 與承諾用量 (CUDs)；並監控其使用率。

組織政策限制條件 (預設安全)：

• 在組織或資料夾層級強制實施護欄，僅在有正當理由時才放寬。常見的限制條件：
  • constraints/iam.disableServiceAccountKeyCreation = true
  • constraints/compute.requireOsLogin = true
  • constraints/compute.trustedImageProjects 限制 VM 映像檔
  • constraints/sql.restrictPublicIp = true
  • constraints/storage.uniformBucketLevelAccess = true
  • constraints/compute.disableSerialPortAccess = true
• 使用 VPC Service Controls 來降低敏感邊界內受支援服務的資料外洩風險。

政策例外處理：

• 例外情況必須是可申請、經核准、有時效性且可稽核的。偏好使用 IAM 條件，透過標記/時間來限定例外範圍。定期核對例外情況，並透過 policy-as-code 管道讓它們自動到期。

停用服務帳戶金鑰的組織政策 (YAML) 範例：

• name: organizations/1234567890/policies/iam.disableServiceAccountKeyCreation spec: rules:
  • enforce: true 接著套用：gcloud org-policies set-policy policy.yaml

Landing Zone、共享服務、自動化與營運模型

Landing zone (落地帶)：

• 提供預先強化的基準線：組織政策、日誌接收器、CMEK 策略、Shared VPC、私有 DNS、Cloud NAT、Private Service Connect、稽核與安全專案，以及受限制的映像檔目錄。
• 為 Shared VPC 的每個環境分離主機專案。網路管理員控制主機專案；應用程式團隊則在附加到正確主機的服務專案中進行部署。

專案工廠：

• 使用基礎設施即程式碼 (infrastructure-as-code) 自動化專案建立。批量建立具有以下特性的專案：
  • 正確的資料夾位置與帳務連結
  • 預先綁定的群組與角色
  • 預設服務帳號被停用或受限制
  • 將日誌接收器指向中央專案與具備保留政策的儲存桶
  • 預先定義的預算、標籤 (label) 與標記 (tag)
• 使用 Terraform 模組或 Cloud Config Controller 將工廠程式碼化。在套用變更前，於 CI 中強制執行政策驗證。

共享服務與隔離：

• 將身份、網路、CI/CD、Artifact 登錄檔與安全工具集中在專屬專案中。透過資料夾與 VPC 隔離環境；使用防火牆政策、獨立的服務邊界，以及每個環境不同的 Cloud KMS 金鑰環來阻擋橫向移動。
• 使用 Private Service Connect 與生產者專案向消費者發布共享服務，而無需暴露公開端點。

稽核日誌與治理自動化：

• 將管理員活動與資料存取日誌路由到一個稽核專案。設定日誌儲存桶使用 CMEK，並配置符合法規的保留政策。
• 使用 Cloud Asset Inventory 的資訊流饋送到 Pub/Sub，再結合 Cloud Functions/Cloud Run 來偵測配置偏差（例如，公開的儲存桶），並自動修復或開啟工單。
• 政策即程式碼 (Policy-as-code) 技術棧：
  • 將組織政策與 IAM 以程式碼形式儲存在版本庫中
  • 使用 Config Validator/Policy Controller 管理 KRM 資源
  • 在 CI/CD 中進行部署前政策檢查
  • 排程的和解作業 (reconciler jobs) 以重新套用期望的狀態

資源命名與標籤：

• 強制執行簡短、易讀的命名模式，其中包含環境、應用程式、區域和序號等資訊（例如，appA-prd-usw2-web-01）。保留標記 (tag) 用於治理（env=prod, pii=true, owner=team-x）。在建立專案時驗證必要標籤 (label)/標記 (tag) 是否存在。

多團隊營運與委派管理：

• 建立平台、安全與網路團隊，並明確定義其範疇與角色。將專案層級的管理權限委派給應用程式團隊，限制在其資料夾邊界內。透過目錄與範本，在護欄內提供自助服務。
• 透過將爆炸半徑小的決策權下放給團隊，並集中化影響多個專案或共享基礎設施的決策，來平衡自主性與風險。

實務問題情境

Contoso 零售計畫在三個月內將八個產品團隊導入 Google Cloud。每個團隊都需要生產 (prod) 和非生產 (nonprod) 環境、隔離的網路、集中的安全日誌，以及成本歸責。平台團隊必須防止服務帳號金鑰擴散、限制 VM 映像檔，並為事件回應啟用有時限的提升權限存取。

方法：

1. 建立層級結構與資料夾

• 為部門建立頂層資料夾，並為生產與非生產環境建立巢狀資料夾。理由：清晰的管理邊界允許設定目標性的護欄與預算，同時能夠將管理權委派給產品團隊，而無需授予組織層級的權力。

2. 部署帶有 Shared VPC 的 Landing Zone

• 為生產與非生產網路建立由網路團隊管理的主機專案。透過 Shared VPC 附加團隊的服務專案。理由：集中化路由、NAT 與防火牆政策，同時按專案隔離工作負載；防止導致擴散和安全不一致的臨時性網路設定。

3. 實作組織政策護欄

• 強制執行約束條件：停用服務帳號金鑰建立、要求使用 OS Login、限制 Cloud SQL 的公開 IP、將 VM 映像檔限制於受信任的專案，以及啟用統一的儲存桶層級存取。理由：「預設安全」可減少高頻率的設定錯誤；必要時，例外情況可以是有時限的。

4. 建立身份與群組

• 將 Cloud Identity 與企業 IdP 整合；為每個團隊的開發、維運和管理角色建立群組，並為網路管理員和安全管理員建立平台層級的群組。理由：基於群組的 IAM 具有擴展性，並符合職責分離原則；其生命週期會跟隨人事異動。

5. 以最小權限和條件式權限提升來定義 IAM

• 在資料夾或專案範疇將預先定義的角色綁定到群組；透過條件式綁定啟用事件回應的權限提升，該綁定僅限於帶有 prod 標記的資源，並在 24 小時後到期。理由：日常操作採用最小權限，並在需要時提供安全、可稽核的權限提升機制。

6. 建立專案工廠的交付管線

• 使用 Terraform 模組來建立專案，包含必要的標籤/標記 (env, owner, cost-center)、連結帳務、附加到正確的 Shared VPC、建立指向中央稽核專案的日誌接收器，並設定預算。理由：大規模、一致且合規的資源配置消除了手動造成的偏差，並加快了導入速度。

7. 集中化稽核日誌與存取審查

• 將管理員活動與資料存取日誌路由到使用 CMEK 的 BigQuery；排程每月查詢以列舉 IAM 綁定，並與群組所有權及來自 IAM Recommender 的最後存取資料進行比較。理由：持久的稽核軌跡和持續的存取權限適當調整可降低風險與成本。

8. 成本治理與警示

• 啟用成本分配標記與標籤、將帳務資料匯出到 BigQuery，並設定每個資料夾和每個專案的預算，附帶通知給財務和團隊負責人。理由：透明的成本分攤可推動責任歸屬；早期警示可抑制失控的支出。

9. 工作負載身份與無金鑰自動化

• 對於 GKE，啟用 Workload Identity；對於外部 CI (GitHub)，設定 Workload Identity Federation，並將其範疇限定於特定的儲存庫與條件。理由：消除長期有效的金鑰，並將使用限制在預期的工作負載上。

10. 例外處理流程與自動化

• 實作一個請求工作流程，該流程透過 CI 建立有條件的 IAM 綁定或暫時性的政策放寬，並具備自動到期功能。理由：在不犧牲控制權的情況下賦予團隊權力；每個例外都是有時限且可稽核的。

技術成果：

• 團隊可以在 15 分鐘內自助服務建立新專案，並具備合規的預設值。
• 不允許使用者管理的服務帳號金鑰；事件回應的權限提升是有時限且依標記範疇限定的。
• 成本按團隊和環境進行匯總，並具備自動化預算和異常警示。
• 稽核日誌和存取審查持續驗證權限與政策符合預期。

所有領域 · 運算、應用程式平台與工作負載架構 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →