資源階層與 IAM 簡介
對於 GCP 專業雲端安全工程師 (PSE) 來說，資源階層是掛載所有安全性政策的骨架。IAM (身分與存取管理) 是控制存取權限的神經系統。瞭解它們如何相互作用——特別是關於繼承、覆蓋和優先順序——是設計安全且可擴展的雲端環境的基礎。
在本主題中，我們將超越基本的「使用者/角色/資源」概念，深入探討大型組織結構的複雜性、拒絕政策 (Deny Policies) 的策略性運用，以及如何利用政策智慧 (Policy Intelligence) 自動化「最小權限原則」。
白話文解釋
1. 俄羅斯娃娃 (資源階層)
想像一組俄羅斯娃娃。最大的是組織 (Organization)。裡面是資料夾 (Folders)，資料夾裡面是專案 (Projects)，專案裡面則是資源 (Resources) (如虛擬機器、儲存桶)。如果你在最大的娃娃上點一個點，裡面的每個娃娃都會被有效地「標記」。這就是 IAM 繼承。如果標記是應用在外層娃娃上，你無法在內層娃娃上「擦掉」它。
2. 最高法院 (拒絕政策)
將標準的 IAM 角色想像成地方法律。它們告訴你你「可以」做什麼。拒絕政策 (Deny Policies) 就像是憲法修正案或最高法院的裁決。無論地方法律 (IAM 角色) 怎麼說，憲法修正案 (拒絕政策) 都會覆蓋它。如果憲法規定「學校內禁止攜帶武器」，那麼即使地方法律授予「所有人攜帶武器的權限」，在該特定情境下也是無效的。
3. 私人教練 (IAM 推薦工具)
想像你有一串包含 100 把鑰匙的鑰匙圈，但你實際只用到其中 3 把。私人教練 (IAM Recommender) 會觀察你 90 天，發現你只用了那 3 把鑰匙，並建議你把笨重的鑰匙圈換成一個只裝那 3 把鑰匙的小鑰匙圈。這減少了你的「安全性負重」(爆炸半徑)。
組織、資料夾與專案結構
資源階層的結構旨在同時實現集中控制與分散自治。
組織節點 (Organization Node)
階層的根節點。它代表你的公司，並與 Cloud Identity 或 Google Workspace 網域連結。
- 安全性優勢： 允許設定組織政策限制 (例如：「禁用所有虛擬機器的外部 IP 地址」)。
資料夾 (Folders)
用於根據部門 (如「財務部」、「工程部」) 或環境 (如「正式環境」、「開發環境」) 對專案進行分組。
- 嵌套： 資料夾最多可嵌套 10 層。
專案 (Projects)
啟用服務與計費的基本單位。每個資源都必須屬於一個專案。
資源階層 (Resource Hierarchy) 是 Google Cloud 資源的邏輯組織結構。它使你能夠透過繼承機制大規模地管理存取權限與設定。
繼承與直接 IAM 繫結 (Inherited vs. Direct IAM Bindings)
IAM 的累加性質
IAM 政策是累加的。使用者的有效權限是組織、資料夾、專案和資源級別授予權限的聯集。
繼承流
- 直接繫結： 在特定的儲存桶上授予
roles/storage.admin。 - 繼承繫結： 在專案級別授予
roles/storage.admin，這會自動應用於該專案中的每個儲存桶。
你無法「減去」繼承的權限。如果使用者在資料夾級別是「所有者 (Owner)」，你無法在專案級別將其改為「檢視者 (Viewer)」來限制其權限。他們仍將擁有「所有者」權限。
基礎角色、預定義角色與自訂角色
基礎角色 (Primitive Roles)
- 所有者 (Owner)、編輯者 (Editor)、檢視者 (Viewer)。
- PSE 警告： 在正式環境中應避免使用這些角色。它們的權限過於廣泛，違反了最小權限原則。
預定義角色 (Predefined Roles)
由 Google 建立與維護。它們提供對特定服務操作的精細存取 (例如 roles/compute.instanceAdmin)。
- 優點： 當 Google 在服務中新增權限時，這些角色會自動更新。
自訂角色 (Custom Roles)
由使用者建立，用於捆綁特定權限。
- 使用場景： 當沒有預定義角色符合高度特定的職能需求時。
- 維護： 如果底層服務引入了新的必要權限，你必須手動更新自訂角色。
自訂角色無法在資料夾或組織級別授予。它們僅限於專案或資源級別。
使用 IAM Recommender 達成最小權限
IAM Recommender 是政策智慧 (Policy Intelligence) 套件的一部分。它使用機器學習來分析存取模式。
- 回顧期： 分析過去 90 天的活動。
- 建議： 如果使用者擁有
roles/editor但僅使用儲存權限，它會建議切換至roles/storage.objectAdmin。
拒絕政策 (Deny Policies) 及其優先順序
拒絕政策的引入是為了在累加的 IAM 世界中提供明確的「拒絕」。
- 優先順序： 拒絕政策在允許政策「之前」進行評估。如果匹配到拒絕政策，存取將被阻止，無論是否存在任何允許政策。
- 範圍： 可應用於組織、資料夾或專案級別。
- 例外： 你無法拒絕專案「所有者」管理專案本身的權限 (以防止鎖定)，但可以拒絕他們存取專案內的資料。
拒絕政策不支援自訂角色；它們針對特定的權限 (例如 iam.googleapis.com/roles.setIamPolicy)。
資源級別的 IAM
某些服務允許將 IAM 政策直接附加到單個資源，提供最高級別的精細度。
- Cloud Storage： 個別儲存桶上的 IAM。
- BigQuery： 個別資料集甚至資料表/檢視表上的 IAM。
- KMS： 個別加密金鑰上的 IAM。
管理政策繼承與覆蓋
階層式保護措施
- 組織政策 (Organization Policies)： 設定 IAM 無法覆蓋的限制 (例如：「限制 VPC 對等互連」)。
- 資源管理員留置權 (Resource Manager Liens)： 防止專案或資源被意外刪除。
IAM 政策故障排除與稽核
Cloud Audit Logs (雲端稽核記錄)
- 管理活動 (Admin Activity)： 記錄所有元資料變更 (誰更改了 IAM 政策)。
- 資料存取 (Data Access)： 記錄誰存取了資料 (對於大多數服務，必須明確啟用)。
政策疑難排解工具 (Policy Troubleshooter)
回答以下問題的工具：「為什麼這個使用者擁有/不擁有這個權限？」它會分析整個階層和拒絕政策。
基於角色的存取控制 (RBAC) 設計
RBAC 最佳實務
- 以職能為中心： 根據工作職責建立群組 (如 "Network-Admins", "DB-Admins")。
- 避免個別分配： 始終將角色繫結至群組。
- 命名規範： 使用清晰的名稱，如
[email protected]。
自訂角色建立的最佳實務
- 不要過度設計： 先檢查預定義角色的組合是否可行。
- 權限對應： 使用
gcloud iam roles copy指令從預定義角色開始，然後刪除不需要的部分。 - 命名： 在自訂角色 ID 中包含專案 ID，以避免衝突。
與其從零手刻自訂角色，不如針對 roles/compute.instanceAdmin 這類預定義角色執行 gcloud iam roles copy，再削減多餘權限——並搭配 IAM Recommender 的 90 天分析，找出 roles/editor 中實際未被使用的權限。請務必把產生的角色繫結到 Cloud Identity 群組 (例如 [email protected])，不要直接綁定個別使用者或服務帳戶，這樣成員異動時就不需要動到 IAM 政策。
資源階層與 IAM 的 CLI 指令
檢視專案政策
gcloud projects get-iam-policy PROJECT_ID
在資料夾級別新增繫結
gcloud resource-manager folders add-iam-policy-binding FOLDER_ID \
--member="group:[email protected]" \
--role="roles/resourcemanager.folderAdmin"
建立自訂角色
gcloud iam roles create myCustomRole --project=my-project \
--file=role-definition.yaml
有效的 IAM 政策是所有「允許政策」的聯集減去任何匹配的**「拒絕政策」**。
PSE 安全性最佳實務
- 每月稽核： 使用政策分析工具 (Policy Analyzer) 尋找「幽靈」權限。
- 使用資料夾進行環境隔離： 如果正式環境和開發環境需要不同的安全性護欄，請不要將它們混在同一個資料夾中。
- 限制「所有者」角色： 對於只需要管理權限的人，使用
roles/resourcemanager.projectIamAdmin而非roles/owner。
故障排除場景
場景：使用者擁有「儲存管理員」權限，但無法刪除儲存桶。
診斷： 資料夾或組織級別可能存在一個明確禁止 storage.buckets.delete 的拒絕政策。
修正： 使用 gcloud iam deny-policies list 檢查拒絕政策。
場景：自訂角色缺少新功能的權限。
診斷： 自訂角色不會自動繼承 Google 新增的權限。 修正： 手動識別新權限 (例如透過 API 文件) 並將其新增至自訂角色定義中。
PSE 考試場景
場景 1：最小權限自動化
「安全性稽核員希望確保所有開發人員都擁有所需的最小權限，而無需手動審查。你應該使用什麼？」 答案： 實施 IAM Recommender，並使用 Cloud Function 或第三方工具自動應用其建議。
場景 2：防止資料外洩
「如何確保包括專案所有者在內的所有人都無法將 GCS 儲存桶設為公開？」
答案： 在組織級別應用組織政策限制 (storage.publicAccessPrevention)。
常見問題 (FAQ)
Q1：我可以在資料夾之間移動專案嗎？
A1：可以，使用 gcloud projects move 指令。請注意，專案將失去舊資料夾繼承的權限，並獲得新資料夾的繼承權限。
Q2：資料夾階層的最大深度是多少？ A2：10 層。
Q3：拒絕政策會影響服務帳戶嗎？ A3：會。拒絕政策適用於所有主體，包括使用者、群組和服務帳戶。
總結檢查清單
- 繪製標準企業資源階層圖。
- 解釋累加 IAM 與拒絕政策之間的區別。
- 列出自訂角色的限制 (資料夾/組織級別限制)。
- 描述 IAM Recommender 如何計算其建議。
- 瞭解組織政策與 IAM 的不同之處。