身分管理是安全架構的第一道防線
在雲端世界，網路邊界不再是唯一的安全屏障。「誰可以存取什麼」比「流量從哪裡來」更為關鍵。GCP 的 IAM 體系是整個安全架構的基石——從單一專案的權限控管到跨組織的身分聯邦，每一層設計都直接影響你的安全態勢。作為架構師，你必須能設計出兼顧安全性與可操作性的身分管理方案。
IAM 核心概念
GCP IAM 的授權模型可以用一句話概括：誰（Principal） 對 什麼資源（Resource） 擁有 什麼權限（Role）。
主體類型（Principals）
- Google Account — 個人使用者，以 email 識別
- Google Group — 一組使用者的集合，是管理權限的最佳實踐單位
- Service Account — 應用程式或工作負載的身分，既是主體也是資源
- Google Workspace / Cloud Identity Domain — 代表組織內所有使用者
- allAuthenticatedUsers / allUsers — 特殊主體，生產環境中極度危險，應搭配 Organization Policy 限制
角色層級
| 類型 | 說明 | 適用場景 |
|---|---|---|
| Basic Roles | Owner、Editor、Viewer，權限過於寬泛 | 僅限快速原型，生產環境禁用 |
| Predefined Roles | Google 預先定義的細粒度角色（如 roles/storage.objectViewer） | 大多數場景的首選 |
| Custom Roles | 自行組合權限，精確控制 | 預定義角色仍無法滿足最小權限需求時 |
Deny Policies 與 IAM Conditions
Deny Policies 是 IAM 的新利器——在 allow policy 之前評估，明確拒絕特定操作，即使使用者擁有 allow 權限也會被阻擋。典型用途：禁止任何人刪除生產資料庫、禁止在特定區域外建立資源。
IAM Conditions 允許你為角色綁定添加條件邏輯，例如：「僅在工作時間」「僅對特定資源名稱前綴」「僅從特定 IP 範圍」才授予權限。Conditions 搭配 Deny Policies 可以實現非常精細的存取控制。
💡 考試小提示：題目出現「即使擁有 Owner 角色也不能執行特定操作」，答案指向 Deny Policies。看到「根據時間或 IP 限制存取」則是 IAM Conditions。
最小權限原則實踐
最小權限（Least Privilege）不是口號——它需要具體的工具和流程來落實。
- IAM Recommender — 分析過去 90 天的權限使用紀錄，主動建議移除未使用的權限或降級過寬的角色。架構師應建立定期審查 Recommender 建議的流程
- Service Account Key 管理 — 盡可能避免產生 SA key。優先使用 Workload Identity（GKE）、Workload Identity Federation（外部工作負載）或 attached service account
- 短期憑證（Short-lived Credentials） — 透過
generateAccessTokenAPI 產生臨時 token，預設最長 1 小時；若設定constraints/iam.allowServiceAccountCredentialLifetimeExtensionOrg Policy 約束，可延長至最長 12 小時，取代長期有效的 SA key
原則很簡單：如果可以不用 key，就不要用 key。如果必須用，設定自動輪替和到期日。
Organization Policy
Organization Policy Service 讓你在組織層級定義護欄（Guardrails），防止即使擁有 IAM 權限的使用者做出不合規的操作。
約束類型
- Boolean Constraints — 啟用/停用特定行為（例：
constraints/compute.disableSerialPortAccess） - List Constraints — 允許/拒絕特定值的清單（例：
constraints/gcp.resourceLocations限制資源只能建在特定區域） - Custom Constraints — 針對 Google Cloud 資源的特定欄位撰寫自訂條件（例：「Cloud SQL 實例必須啟用自動備份」）
策略繼承
Organization Policy 沿著 Resource Manager 階層由上往下繼承：Organization → Folders → Projects。子層級可以合併或覆寫父層級的策略，但最佳實踐是在最高層級定義基線，僅在必要時於子層級放寬。
💡 考試小提示：題目描述「需要強制所有專案遵守某項策略，即使專案 Owner 也不能繞過」，答案是 Organization Policy（不是 IAM）。IAM 控制「誰能做什麼」，Org Policy 控制「什麼能被做」。
Workload Identity Federation
Workload Identity Federation（WIF） 解決了一個長久的痛點：外部工作負載（跑在 AWS、Azure、地端或 CI/CD 系統上的應用）如何安全存取 GCP 資源？
傳統做法是匯出 Service Account key，存放在外部系統——這帶來 key 洩漏、缺乏自動輪替、難以稽核等風險。WIF 的架構徹底消除了 key 的需求：
- 在 GCP 建立 Workload Identity Pool，定義信任的外部身分提供者（AWS、Azure AD、任何 OIDC/SAML 提供者）
- 外部工作負載使用其原生身分取得 token（例如 AWS 的 instance metadata、GitHub Actions 的 OIDC token）
- 將外部 token 交換為 GCP 的 短期 STS token
- 使用 STS token impersonate 指定的 Service Account，存取 GCP 資源
整個過程無需產生或管理任何 key，外部 token 的生命週期由來源系統控制，GCP 端只需管理信任關係。
💡 考試小提示：看到「外部工作負載存取 GCP」「消除 service account key」「跨雲身分認證」，答案幾乎必然是 Workload Identity Federation。如果是 GKE 的 Pod 存取 GCP API，則是 Workload Identity（GKE 版本，原理類似但機制不同）。
IAP（Identity-Aware Proxy）
Identity-Aware Proxy（IAP） 實現了零信任架構的核心理念——存取控制從網路層移至應用層。IAP 在使用者和應用之間建立一個認證代理，每次存取都需要驗證身分和權限。
核心功能
- Web 應用防護 — 為部署在 GCE、GKE 或 App Engine 上的 Web 應用提供身分驗證，無需修改應用程式碼
- TCP Tunneling — 透過
gcloud compute ssh --tunnel-through-iap安全連線至沒有外部 IP 的 VM，取代傳統 VPN 或 bastion host - Context-Aware Access — 整合裝置狀態、IP 位址、時間等情境資訊，做出動態的存取決策
BeyondCorp 整合
IAP 是 Google BeyondCorp 零信任模型的關鍵元件。在 BeyondCorp 架構中，不存在「受信任的內部網路」——每個請求都必須經過身分驗證和授權，無論來自公司辦公室還是咖啡廳。
💡 考試小提示：題目出現「不使用 VPN 存取內部應用」「零信任」「BeyondCorp」，答案指向 IAP。題目提到「安全連線至沒有外部 IP 的 VM」，答案是 IAP TCP Tunneling。
Chrome Enterprise Premium
Chrome Enterprise Premium（前身為 BeyondCorp Enterprise）將零信任擴展到終端裝置和瀏覽器層級：
- Endpoint Verification — 驗證裝置的安全狀態（OS 版本、磁碟加密、螢幕鎖定），作為 context-aware access 的信號
- Device Trust — 根據裝置信任等級動態調整存取權限，例如未加密的裝置只能存取低敏感度資源
- DLP for Browser — 在 Chrome 瀏覽器層級實施資料外洩防護，防止複製、列印或下載敏感資料
- Threat Protection — 即時偵測惡意軟體和釣魚攻擊
Chrome Enterprise Premium 搭配 IAP 形成完整的零信任存取鏈：裝置信任 → 身分驗證 → 情境評估 → 授權存取。
服務帳戶最佳實踐
Service Account 的管理是企業安全中最容易出問題的環節。以下是架構師必須推動的最佳實踐：
| 原則 | 做法 |
|---|---|
| 專用帳戶 | 每個服務/應用使用獨立的 SA，禁止多服務共用 |
| 避免預設 SA | 不使用 Compute Engine 和 App Engine 的 default SA，它們通常擁有過寬的 Editor 權限 |
| 禁用 key 匯出 | 透過 Org Policy constraints/iam.disableServiceAccountKeyCreation 禁止產生 key |
| 使用 Impersonation | 人員透過 --impersonate-service-account 臨時取得 SA 權限，而非直接綁定角色 |
| 短期 Token | 使用 generateAccessToken 或 generateIdToken 產生有時效的憑證 |
Resource Manager 階層
GCP 的資源階層是所有安全策略的骨架，理解繼承關係是設計 IAM 架構的前提：
Organization → Folders → Projects → Resources
- Organization — 最頂層，綁定 Google Workspace 或 Cloud Identity domain，是 Org Policy 和 IAM 的全域起點
- Folders — 用來映射部門、團隊或環境（dev/staging/prod），最多 10 層巢狀
- Projects — 資源的容器，也是計費和 API 啟用的邊界
- Resources — 實際的 GCP 服務實例（VM、bucket、database 等）
IAM Policy 沿階層向下繼承——在 Organization 層級授予的角色，會自動套用到所有 Folders、Projects 和 Resources。因此，在越高層級授權，影響範圍越大，需要越謹慎。最佳實踐是在高層級授予寬泛的唯讀權限（如 Viewer），在低層級授予精確的操作權限。
實戰情境
情境一：多團隊企業 IAM 設計
背景：一家軟體公司有 4 個產品團隊和 1 個平台團隊，需要設計 IAM 架構，確保職責分離且易於管理。
架構決策：
- 建立 Organization 綁定公司的 Cloud Identity domain，啟用所有安全相關的 Organization Policies（禁止 SA key 產生、限制資源區域、禁用 Serial Port）
- 以 Folders 映射組織結構：頂層分為
Production和Non-Production，下層按團隊再分子資料夾 - 每個團隊使用 Google Group 管理成員，權限綁定到 Group 而非個人——人員異動只需修改 Group 成員
- 平台團隊在 Organization 層級擁有
roles/resourcemanager.organizationViewer，在 Shared VPC 宿主專案擁有網路管理角色 - 產品團隊在各自的 Folder 層級擁有
roles/editor，但透過 Deny Policy 明確禁止刪除生產環境的關鍵資源 - 使用 IAM Recommender 每月審查權限，持續精簡不必要的角色
情境二：第三方廠商透過 WIF 安全存取
背景：公司委託外部 AI 廠商在其 AWS 環境中訓練模型，模型需要讀取存放在 GCS bucket 的訓練資料。
架構決策：
- 建立 Workload Identity Pool，設定 AWS 為信任的身分提供者，限制特定 AWS Account ID
- 建立專用的 Service Account，僅授予
roles/storage.objectViewer於特定 bucket - 廠商的 AWS workload 使用 AWS IAM Role 取得 token，透過 WIF 交換 GCP STS token，再 impersonate 專用 SA 讀取資料
- 無需產生任何 SA key——廠商不持有任何 GCP 長期憑證
- 搭配 IAM Conditions 限制存取時段（僅工作日 08:00-20:00）和來源 IP 範圍
- 透過 VPC Service Controls（進階安全層）建立 perimeter，確保資料只能在指定 project 內被存取
重點整理
- IAM 授權模型：Principal + Role + Resource，搭配 Conditions 和 Deny Policies 實現精細控制
- 最小權限不是口號——用 IAM Recommender 持續審查，用短期憑證取代長期 key
- Organization Policy 控制「什麼能被做」，與 IAM 的「誰能做什麼」互補，是企業治理的核心
- Workload Identity Federation 消除 SA key 的需求，是跨雲和外部工作負載存取 GCP 的標準方案
- IAP 實現零信任的應用層存取控制，TCP Tunneling 取代傳統 VPN/bastion
- Chrome Enterprise Premium 將零信任延伸至裝置和瀏覽器，搭配 IAP 形成完整的存取鏈
- Resource Manager 階層決定策略繼承方向——在越高層級授權，影響範圍越大
下一步
在下一課中，我們將深入 GCP 的資料保護與加密架構，涵蓋 Cloud KMS 金鑰管理、CMEK/CSEK 加密策略、VPC Service Controls 資料邊界，以及 Data Loss Prevention（DLP）——這些是建構企業級安全架構不可或缺的另一半拼圖。