Google Cloud IAM 簡介
對於 Professional Cloud Architect 而言，IAM 是最關鍵的安全邊界。它回答了最根本的問題：「誰 (Who) 可以對哪個資源 (Resource) 執行什麼操作 (What)？」 一個架構良好的 IAM 策略遵循 最低權限原則 (Principle of Least Privilege)，確保每個身分都只擁有其所需的確切權限，不多也不少。
一種政策和技術框架，用於確保正確的使用者擁有適當的技術資源存取權限。在 GCP 上，它定義了「誰」（身分 - Identity）、「做什麼」（角色/權限 - Role/Permissions）以及「針對哪個」（資源 - Resource）。參考資料：https://cloud.google.com/iam/docs/overview
白話文解釋 IAM
IAM 就像是一個高安全性研究設施的安全系統。
類比 1 — 安全識別證（身分 - Identity）
在設施中，每個人都有一個 安全識別證。這張識別證不只是寫著你的名字；它還告訴系統你是誰——是研究員、清潔工還是訪客。在 GCP 中，你的 身分 (Identity) 就是你的電子郵件地址（Google Workspace、Cloud Identity 或 Service Account）。
類比 2 — 職稱（角色 - Role）
「保安人員」這個角色附帶了一組鑰匙。你不會分別給保安員「前門」、「後門」和「倉庫」的鑰匙。你只需給他們 保安人員角色 (Security Guard Role)，該角色會自動包含所有這些鑰匙。在 GCP 中，角色 (Roles) 是權限的集合。你將角色分配給身分，而不是分配單個權限。
類比 3 — 讀卡機（政策 - Policy）
IAM 政策 (IAM Policy) 就像是門上 讀卡機 內部的邏輯。當你感應識別證時，讀卡機會詢問：「這個特定的識別證 (身分) 是否擁有這個特定門 (資源) 的『科學實驗室存取權』(角色)？」如果答案是肯定的，門就會打開。
IAM 模型：誰、能做什麼、針對哪個
IAM 政策是在特定 資源 (Resource) 層級將 成員 (Members) 映射到 角色 (Roles) 的過程。
1. 「誰」（身分 - Identities）
- Google 帳戶： 個人使用者（例如
[email protected]）。 - Service Accounts (服務帳戶)： 應用程式和工作負載的身分（例如
[email protected]）。 - Google Groups (Google 群組)： 管理使用者的推薦方式。將角色分配給群組，然後在該群組中添加/移除使用者。
- Google Workspace/Cloud Identity 網域： 組織中的所有使用者。
2. 「能做什麼」（角色 - Roles）
- 基本角色 (Primitive Roles)： (Owner, Editor, Viewer)。避免在生產環境中使用，因為它們的權限過於寬泛。
- 預定義角色 (Predefined Roles)： 由 Google 管理（例如
roles/storage.objectViewer）。權限精細且會自動更新。 - 自訂角色 (Custom Roles)： 由你根據特定需求創建。當預定義角色仍然過於寬泛時使用。
3. 「針對哪個」（資源 - Resources）
IAM 角色可以應用於 資源階層 (Resource Hierarchy) 的不同層級：
- Organization (組織)（最高層級）
- Folder (資料夾)
- Project (專案)
- Resource (資源)（例如特定的 GCS 儲存桶或 Cloud SQL 執行個體）
繼承 (Inheritance)： 權限是向下繼承的。如果使用者是「專案檢視者 (Project Viewer)」，他們會自動成為該專案內每個儲存桶和 VM 的檢視者。參考資料：https://cloud.google.com/iam/docs/resource-hierarchy-access-control
Service Accounts (應用程式身分)
Service accounts 是工作負載 GCP 安全性的支柱。
- 無需密碼： 它們使用加密金鑰（由 Google 管理或手動管理）。
- Service Account ActAs： 使用者必須擁有
roles/iam.serviceAccountUser角色才能「冒充」或使用服務帳戶。 - 短期憑證： 盡可能使用短期憑證代替靜態 JSON 金鑰，以降低金鑰洩漏的風險。
Workload Identity (GKE 與多雲)
Workload Identity 是運行在 Kubernetes (GKE) 或其他雲端上的應用程式存取 GCP 服務的安全方式。
- 舊方法： 匯出 JSON 金鑰並將其掛載為 Secret（非常危險！）。
- 新方法： 將 Kubernetes Service Account (KSA) 連結到 Google Service Account (GSA)。GKE 會自動處理權杖交換。無需管理金鑰！
Conditional IAM (條件式 IAM)
你可以為 IAM 綁定添加 條件 (Conditions)，使其更加精細。
- 基於時間： 「僅允許在上午 9 點到下午 5 點之間存取。」
- 基於資源： 「僅允許存取以
public-為前綴的儲存桶。」 - 基於 IP： 「僅允許從公司 VPN IP 地址存取。」
架構師的 IAM 最佳實踐
- 使用群組 (Groups)： 永遠不要將角色分配給個人使用者。這會造成管理噩夢。
- 最低權限原則： 使用盡可能精細的角色。使用 IAM Recommender 來查找並移除未使用的權限。
- 審計一切： 啟用 Cloud Audit Logs（數據存取日誌）以查看誰做了什麼。
- 輪換金鑰： 如果必須使用服務帳戶金鑰，請每 90 天輪換一次。
- 使用 Workload Identity Federation： 用於 Google Cloud 之外的資源（例如 AWS、Azure 或地端）在不使用服務帳戶金鑰的情況下存取 GCP。
常見問題 — Identity and Access Management
Q1. 預定義角色 (Predefined Role) 和自訂角色 (Custom Role) 有什麼區別？
預定義角色由 Google 管理，並在添加新功能時自動更新。自訂角色由你管理，提供最精細的控制，但如果服務的底層權限發生變化，你負責更新它們。
Q2. 我應該使用 Service Account Key 嗎？
盡可能避免使用。 服務帳戶金鑰是「長效型」的，且可能洩漏。建議優先使用 Workload Identity、Identity Federation 或 Service Account Impersonation。
Q3. 我可以在 IAM 中拒絕權限嗎？
IAM 僅具有 疊加性 (Additive)。你授予權限，而不是「拒絕」權限。如果使用者在專案層級擁有「編輯者 (Editor)」角色，你無法「拒絕」他們存取該專案中的特定儲存桶。但是，可以使用 Organization Policies (組織政策) 來限制操作。
Q4. "IAM Recommender" 的作用是什麼？
它使用機器學習來分析你的 IAM 日誌，並建議移除過去 90 天內未使用的權限，幫助你實現最低權限原則。
Q5. 如何管理第三方承包商的存取權限？
將他們添加到組織中特定的 Google Group (Google 群組)，並將必要的角色分配給該群組。當他們的合約結束時，只需將他們從群組中移除即可。
最後的架構師提示
在 PCA 考試中，關於「如何保護應用程式？」的答案幾乎總是 Workload Identity（針對 GKE）或 具備最低權限的 Service Account。請記住，Groups 是給人用的，而 Service Accounts 是給機器用的。如果題目提到「減少管理開銷」，答案是 Google Groups。如果提到「用於審計的合規性」，答案是 Cloud Audit Logs。