身分與存取管理（IAM）

什麼是身分識別與存取管理（IAM）？

身分識別與存取管理（Identity and Access Management，IAM） 是 Google Cloud 用來決定「誰能對哪個資源執行什麼操作」的服務。對於 Cloud Digital Leader（CDL）考試而言，IAM 是雲端安全的核心基石——它是保護組織中每個專案、每個 Cloud Storage 儲存桶、每個 BigQuery 資料集，以及每個 Compute Engine 虛擬機器的數位「門鎖與鑰匙」系統。沒有 IAM，Google Cloud 就像一個敞開大門的倉庫，任何人都可以隨意取用。有了 IAM，每扇門都有守衛，每位守衛都會核查身分證件，每張身分證件都對應一份精確的允許操作清單。

CDL 考試不要求您撰寫 gcloud 指令或 YAML 角色定義。考試測驗的是您是否能以業務領導者的視角理解 IAM 的三大支柱：主體（principal，「誰」）、角色（role，「做什麼」），以及資源（resource，「哪個」）。三大支柱合在一起，組成一個簡單的句子：「允許此主體對此資源執行此角色所涵蓋的操作。」這句話是 Google Cloud 中每條 IAM 政策的核心。

IAM 也實踐了一項核心安全哲學，稱為最小權限原則（principle of least privilege）。此原則規定，任何人員、應用程式或工作負載都應只被授予執行其工作所需的最低權限，不多給一分。將開發者的 Owner 角色授予生產環境專案「以備不時之需」，是違反最小權限原則的典型案例，也是導致資料外洩、意外刪除與稽核失敗的常見錯誤。IAM 旨在讓最小權限原則的實施與稽核都變得簡單易行。

三大支柱：誰、做什麼、哪個

Google Cloud 中的每個 IAM 決策，都可以歸結為回答三個問題。CDL 考生應熟記這個句子：「誰（Who） 能對 哪個（Which） 資源執行 什麼（What） 操作？」

「誰」— 主體（Principals）

主體（principal） 是請求存取 Google Cloud 資源的身分。主體有以下幾種形式：

• Google 帳號 — 個人使用者，以電子郵件地址識別，例如 [email protected]。
• Google 群組 — 使用者與其他群組的集合，以群組電子郵件識別，例如 [email protected]。群組是大規模管理存取權限的推薦方式。
• 服務帳號（Service Account） — 供應用程式、虛擬機器和自動化工作負載使用的非人類身分，以電子郵件格式識別，例如 [email protected]。
• Google Workspace 或 Cloud Identity 網域 — 代表整個公司的網域，授予其下所有帳號的存取權限。
• allAuthenticatedUsers / allUsers — 特殊主體，分別代表「所有登入 Google 的使用者」或「所有網際網路使用者」。這兩類主體具有危險性，很少適合使用。

「做什麼」— 角色與權限

角色（role） 是權限（permission） 的具名集合。權限是 IAM 存取控制的最小單位，例如 storage.objects.get 或 bigquery.tables.create，代表對特定資源類型執行單一操作。您永遠不會將個別權限直接授予主體；您授予的是角色，也就是相關權限的預先打包集合。

Google Cloud 提供三種角色類別：

1. 原始角色（Primitive roles） — Owner、Editor 與 Viewer。這些是細粒度 IAM 出現之前的舊版角色，涵蓋範圍極廣。
2. 預定義角色（Predefined roles） — 服務專屬角色，例如 roles/storage.objectViewer 或 roles/bigquery.dataEditor，由 Google 負責維護。
3. 自訂角色（Custom roles） — 由您自行挑選特定權限所定義的角色，適用於特殊或高度受管的工作流程。

「哪個」— 資源與階層架構

資源（resource） 是 Google Cloud 中任何可被操作的物件——專案、資料夾、Cloud Storage 儲存桶、虛擬機器、BigQuery 資料集、Pub/Sub 主題。資源依照**階層架構（hierarchy）**組織，從廣到細依序為：組織（Organization）→ 資料夾（Folder）→ 專案（Project）→ 資源（Resource）。您在哪個層級附加 IAM 政策，就決定了該政策的適用範圍。

白話文解釋

IAM 有時感覺很抽象，因為權限與政策都是看不見的——沒有實體鎖讓您觸碰。但 IAM 的運作邏輯其實非常類似我們日常生活中已在使用的門禁管理系統。以下三個類比分別呈現 IAM 的不同面向。

類比 1 — 辦公大樓門禁卡（主體、角色與資源）

想像您在台北市中心一棟 30 層的辦公大樓上班。第一天報到時，警衛室發給您一張門禁卡。這張門禁卡就是您的身分識別，代表您這個主體。系統中記錄了這張卡的權限清單：「可進入 5、6、7 樓。可使用地下室健身房。不可進入 30 樓主管專區。」

這份權限清單就是您的角色。執行長的角色不同——她的卡能開每一扇門，包括頂樓停機坪。清潔人員又是另一個角色——他們的卡能開每層樓的清潔間，但無法進入安全伺服器室。角色是權限的集合包，就像 Google Cloud 的 roles/storage.objectViewer 打包了 storage.objects.get 與 storage.objects.list 一樣。

整棟大樓、各樓層與各個房間 就是資源。大廳就像組織節點——所有人都要經過。各樓層就像資料夾——您可以將 10 樓租給甲公司、12 樓租給乙公司。每層樓的各個房間就像專案，房間裡的每張辦公桌就像個別的 Cloud Storage 儲存桶和虛擬機器。

當一位外包顧問只來工作一週，警衛室不會給他執行長的萬能鑰匙「以備不時之需」，而是發給他一張只能進入指定會議室的臨時卡。這正是最小權限原則的實踐。若顧問的臨時卡之後遺失，損害只限於那間會議室，而非整棟大樓。

類比 2 — 公司組織圖與階層授權繼承

想像一家台灣半導體公司的組織圖。執行長在最頂端，下方是研發、業務和財務副總，各副總之下又有處長、經理與個人貢獻者。這就是 Google Cloud 資源階層架構的人性化版本。

現在想像執行長發出一份全公司公告：「全體員工皆可享有健身房會員福利。」因為執行長位居頂端，這項福利向下流動到每一位員工——副總、處長、經理、實習生，全部適用。不需要在每個層級重新發一次公告。這正是 IAM 政策繼承（policy inheritance） 的運作方式。在組織節點授予的角色，會自動套用至其下的每個資料夾、每個專案與每個資源。

再想像研發副總發出一份較窄範圍的公告：「研發部門所有人員皆可使用 7 樓實驗室。」這份公告只向下流動至研發部門——業務和財務人員不會獲得實驗室存取權限。這等同於在資料夾層級授予 roles/compute.viewer：只有該資料夾內的專案受到影響。

要特別留意的陷阱是：政策是加法式的（additive），採取聯集計算。如果執行長在組織層級授予您「健身房存取」，後來某位經理試圖在專案層級「收回」這項權限，那位經理無法移除在更高層級授予的權限——他只能新增更多權限。CDL 考試非常喜歡測驗這個概念，因為它與傳統檔案系統權限（較低層級可以覆蓋較高層級）的直覺相反。

類比 3 — 銀行金庫保全與裝甲車司機（服務帳號）

前兩個類比的主角都是人類員工。但在雲端環境中，大多數存取是機器對機器進行的，而非人類對機器。這就是服務帳號（service account） 的用武之地。

想像一家擁有金庫的銀行。客戶（人類）到大廳，用個人身分證件辦理存款。但銀行同時雇用了裝甲車司機在各分行之間運送黃金。裝甲車司機不是客戶——他是銀行內部建立的非人類身分，並被賦予一張特殊識別徽章。徽章上記載：「允許進入金庫、允許將黃金裝入裝甲車、允許在甲乙兩分行之間行駛。」不包含「允許開立客戶帳戶」或「允許解僱員工」。

在 Google Cloud 中，服務帳號就是那張裝甲車司機的識別徽章。當 Compute Engine 虛擬機器需要將日誌寫入 Cloud Logging 時，它不會以人類身分登入，而是使用服務帳號電子郵件，例如 [email protected]，並且這個服務帳號只被授予 roles/logging.logWriter——僅此而已。

服務帳號的風險，就像給裝甲車司機一把通行所有分行金庫的萬能鑰匙一樣危險。如果那張識別徽章被盜（服務帳號金鑰外洩到 GitHub），竊賊就能以機器的速度，悄無聲息地掏空每一個金庫。這正是為什麼最小權限原則對服務帳號比對人類更為重要：機器不會停頓、不會發問，而且可以二十四小時不間斷地運作。

資源階層架構詳解

Google Cloud 資源階層架構是一棵有四個層級的樹狀結構，理解它是通過 CDL 考試的必備知識。

第一層 — 組織（Organization）

組織節點位居頂端，代表您的公司。它會在您申請 Cloud Identity 或 Google Workspace 帳號時自動建立。所有資料夾、專案與資源都隸屬於組織。組織層級的 IAM 政策效力強大，因為它們套用至其下的所有資源。

第二層 — 資料夾（Folder）

資料夾是介於組織與專案之間的選用性分組容器。典型的做法是建立 Production、Development、Sandbox 等資料夾，或依業務單位建立 Marketing、Engineering 等資料夾。資料夾最多可巢狀 10 層。

第三層 — 專案（Project）

專案是 Google Cloud 的主要組織單位。每個資源——每台虛擬機器、每個儲存桶、每個資料庫——都必須隸屬於一個專案。專案也是帳單、已啟用 API 與配額的管理邊界。

第四層 — 資源（Resource）

實際的資源——Compute Engine 執行個體、Cloud Storage 儲存桶、BigQuery 資料集、Pub/Sub 主題——位於最底層。部分服務支援將 IAM 政策直接附加至個別資源，以實現精細控制（例如，授予某使用者存取單一儲存桶的權限，而無需給予整個專案的存取權）。

角色類型：原始角色、預定義角色與自訂角色

CDL 考試要求您比較三種角色類別，並知道在各種業務情境下應推薦哪一種。

原始角色（Primitive Roles）

三種原始角色——Owner、Editor 與 Viewer——早於細粒度 IAM 存在，涵蓋範圍極廣：

• Viewer（roles/viewer） — 對專案中所有資源的唯讀存取。
• Editor（roles/editor） — 對大多數資源的讀寫存取，但無法管理 IAM 或帳單。
• Owner（roles/owner） — 完整控制權，包括授予他人角色以及刪除專案的能力。

這些角色使用方便，但存在風險。被授予 Editor 角色的人，可以修改該專案中的每個 Cloud SQL 資料庫、每個 BigQuery 資料集與每台 Compute Engine 執行個體——即便他實際上只需要存取一個儲存桶。

預定義角色（Predefined Roles）

預定義角色由 Google 針對特定服務與職務功能精心設計。範例如下：

• roles/storage.objectViewer — 只能讀取 Cloud Storage 儲存桶中的物件。
• roles/bigquery.dataEditor — 可讀寫 BigQuery 資料，但無法管理資料集或執行計費查詢。
• roles/compute.instanceAdmin — 可管理 Compute Engine 虛擬機器，但無法管理網路或防火牆。
• roles/pubsub.subscriber — 只能從 Pub/Sub 訂閱拉取訊息。

預定義角色是幾乎所有情境下的預設推薦選項，由 Google 隨服務演進持續測試與維護。

自訂角色（Custom Roles）

當原始角色與預定義角色都無法滿足需求時，您可以逐一挑選特定權限來建立自訂角色。自訂角色適用於特殊工作流程——例如，允許第三方稽核人員列出儲存桶但不能讀取其內容——但需要持續維護。若 Google 為某服務新增了一項權限，您的自訂角色不會自動納入。

服務帳號：非人類身分

服務帳號（service account） 是屬於您的應用程式或虛擬機器，而非人類使用者的特殊 Google 帳號。每當程式碼需要呼叫 Google Cloud API 時，都會用到服務帳號——例如 Cloud Run 服務寫入 Cloud Storage、Compute Engine 虛擬機器讀取 Cloud SQL 資料庫、Cloud Functions 發布訊息至 Pub/Sub。

服務帳號對 CDL 考試的重要性

服務帳號的能力與危險性同等強大。造成風險的原因有三點：

1. 可被授予廣泛角色。 開發者常因為「應用程式需要做很多事」而授予服務帳號 roles/editor。這是現實世界 Google Cloud 部署中最常見的 IAM 錯誤。
2. 憑證可能外洩。 被提交至公開 GitHub 儲存庫的服務帳號金鑰（JSON 檔案），可在數分鐘內讓攻擊者完全掌控您的專案。目前已有機器人程式持續掃描 GitHub 以尋找外洩的金鑰。
3. 以機器速度運作。 被入侵的人類帳號可能只會登入一次並竊取部分資料，而被入侵的服務帳號則可在數秒內刪除整個資料庫。

服務帳號最佳實踐

• 每個工作負載使用獨立的服務帳號。 不要讓不相關的應用程式共用同一個服務帳號。
• 避免下載服務帳號金鑰。 改用工作負載身分聯合（workload identity federation） 或附加服務帳號（attached service accounts）。
• 若必須使用金鑰，定期輪換，且絕對不要提交至版本控制系統。
• 稽核誰能模擬服務帳號。 roles/iam.serviceAccountUser 角色授予了「代理」服務帳號的能力，實質上是一條權限提升路徑。

最小權限原則

最小權限原則（Principle of Least Privilege，PoLP） 規定，每個主體——每位使用者、每個群組、每個服務帳號——都應只擁有執行其特定工作所需的權限，不多也不少。這不是 Google Cloud 的發明，而是一項可追溯至 1970 年代的基礎安全原則。但 IAM 提供了真正實踐這項原則的工具。

為何最小權限原則如此重要

• 縮小爆炸半徑。 若開發者的憑證遭竊，攻擊者只能存取開發者原本能存取的範圍。
• 防止意外。 初階工程師若沒有生產資料庫的刪除權限，就不可能意外刪除它。
• 簡化稽核。 當權限範圍嚴格限定後，稽核人員可以輕鬆確認「此人不可能執行該操作」。
• 滿足合規要求。 SOC 2、ISO 27001 和 HIPAA 等標準都要求提供存取控制規範的證明。

Cloud Identity 與 Google Workspace

IAM 中的人類身分從何而來？來源有兩個：

Cloud Identity

Cloud Identity 是 Google 的獨立身分識別即服務（Identity-as-a-Service）解決方案，為不使用 Google Workspace 的組織提供使用者帳號、群組管理與單一登入（SSO）功能。免費版支援有限數量的使用者；付費版（Cloud Identity Premium）新增了進階裝置管理與安全調查工具等安全功能。

Google Workspace

Google Workspace（前稱 G Suite）將 Cloud Identity 與生產力應用程式——Gmail、Google Drive、Google Docs、Google Meet、Google Calendar——整合在一起。若公司已使用 Google Workspace，每個 Workspace 帳號都自動是有效的 Google Cloud 身分。

對於 CDL 考試，請記住以下幾點：

• Cloud Identity 與 Google Workspace 都提供資源階層架構中的組織節點。
• 兩者都管理出現在 IAM 政策中作為主體的使用者和群組。
• 兩者之間的選擇是業務決策：若需要電子郵件與生產力應用程式，選擇 Workspace；若只需要 Google Cloud 的身分識別功能，選擇 Cloud Identity。

與外部身分識別提供者的聯合

許多企業已使用 Active Directory、Okta 或 Microsoft Entra ID 作為身分識別來源。Google Cloud 支援單一登入（SSO） 與工作負載身分聯合（workload identity federation），使用者無需另建 Google 密碼——他們以企業身分登入，IAM 仍能正常運作，因為該身分已被對應至 Google 帳號。

稽核日誌與責任歸屬

IAM 授予存取權限，而 Cloud Audit Logs 則記錄實際執行了哪些操作。每個 Google Cloud 服務的 API 呼叫都會被記錄，包含發出呼叫的主體、被操作的資源，以及操作結果。

稽核日誌分為四個類別：

• Admin Activity（管理活動） — 建立或刪除資源等管理操作。永遠啟用、無法關閉、免費提供。
• Data Access（資料存取） — 對資源資料的讀寫操作。大多數服務預設停用，因為日誌量龐大。
• System Event（系統事件） — Google Cloud 自動執行的操作，例如維護事件。
• Policy Denied（政策拒絕） — 被拒絕的存取嘗試，有助於偵測攻擊行為。

對於 CDL 考試，您不需要記憶日誌保留期限或篩選語法。您只需了解：IAM 定義誰能執行什麼操作，Cloud Audit Logs 證明實際發生了什麼。兩者共同構成 Google Cloud 責任歸屬的基礎。有關合規的深入探討，請參閱合規性與隱私保護。

IAM 與其他 CDL 章節的關聯

IAM 並非孤立存在，它是支撐幾乎所有 Google Cloud 安全相關章節的存取控制層。

• 資料加密 — IAM 控制誰能讀取加密資料以及誰持有金鑰。請參閱資料加密與保護，了解客戶自管加密金鑰（CMEK）如何與 Cloud KMS 的 IAM 權限連結。
• 合規性 — IAM 提供存取受控的證明，這對 SOC 2、HIPAA、GDPR 與 ISO 27001 至關重要。請參閱合規性與隱私保護。
• 成本管理 — IAM 同樣控制帳單存取。只有擁有 roles/billing.admin 的使用者才能變更付款方式或關閉帳單帳號。
• 雲端價值主張 — 強健的 IAM 是 Google Cloud 雲端價值主張對注重安全的企業而言具有說服力的重要原因之一。

常見 IAM 錯誤與規避

在考試情境中出現以下反模式時，請務必辨識出來：

1. 將 roles/owner 授予服務帳號。 服務帳號幾乎不應被設為 Owner；應持有窄範圍的預定義角色。
2. 在 Cloud Storage 儲存桶上使用 allUsers。 這會將儲存桶完全公開至網際網路。對公開網站或許可行，但對客戶資料庫而言是災難性的。
3. 將存取權限授予個別使用者而非群組。 當使用者換部門或離職時，您必須記得更新數十條政策。使用群組可解決這個問題。
4. 將服務帳號金鑰儲存於版本控制系統。 應改用工作負載身分聯合或附加服務帳號。
5. 忽略 IAM Recommender。 Google 會告知您哪些權限未被使用，請善用這些資料來優化角色範圍。

常見問題

IAM 中的驗證（authentication）與授權（authorization）有何不同？

驗證（authentication） 回答「您是誰？」——這是確認主體身分的過程，通常透過密碼、安全金鑰或權杖完成。授權（authorization） 回答「您被允許做什麼？」——這是驗證通過後，IAM 檢查主體角色是否允許所請求操作的過程。IAM 主要是一套授權系統；驗證則由 Cloud Identity、Google Workspace 或聯合身分識別提供者負責處理。

既然原始角色（如 Owner 和 Editor）不建議使用，為何仍然存在？

原始角色的存在是為了與細粒度 IAM 出現之前所建立的 Google Cloud 專案向下相容。它們對小型沙箱或學習專案也很方便，在這些場景中便利性大於安全風險。對於任何生產工作負載，Google 建議將原始角色替換為預定義角色，並限定於實際使用的特定服務。CDL 考試直接測驗這個偏好。

若使用者從更高層級繼承了某權限，是否可以拒絕他使用？

可以，但需透過 IAM Deny 政策（IAM Deny policies），這是相對較新的獨立功能。標準的 IAM 允許政策（allow policies） 是加法式的——您無法減去在更高層級授予的權限。Deny 政策讓您能明確封鎖特定主體的特定權限，無論繼承的允許政策為何。對於 CDL 考試，重要結論是：允許政策採聯集計算，Deny 政策是例外處理機制，而非主要工具。

員工離職後會發生什麼事？

當員工離職時，其身分通常會在 Cloud Identity 或 Google Workspace 中被停用或刪除。一旦身分不存在，所有參照該身分的 IAM 繫結（binding）都會失效——即便 IAM 政策條目仍然存在。最佳實踐是同時將該員工從其所屬的群組中移除，並清理所有孤立繫結。這也是為什麼建議將角色授予群組而非個人：只需將人員從群組中移除，即可一次撤銷其所有存取權限。

IAM 如何處理來自組織外部的使用者？

外部使用者——例如擁有 Gmail 地址的外包廠商，或來自合作夥伴公司網域的人員——可以直接將其電子郵件新增為主體，從而被授予 IAM 角色。但這存在風險，因為您無法控制其驗證方式或裝置安全性。Cloud Identity Premium 與 Access Context Manager 允許您設定條件（例如要求使用受管裝置或位於特定地點），外部使用者必須滿足這些條件才能使用已授予的權限，從而對第三方存取提供更嚴密的控制。

服務帳號金鑰是否有安全使用的情境？

服務帳號金鑰（JSON 檔案）在功能上等同於預設永不過期的使用者名稱與密碼組合。只有在儲存於密鑰管理服務中、定期輪換，且絕不提交至版本控制系統的前提下，才算是安全的用法。對於大多數工作負載，Google 現在建議採用無金鑰驗證機制，例如工作負載身分聯合（workload identity federation）（適用於 Google Cloud 外部的工作負載）與附加服務帳號（attached service accounts）（適用於 Compute Engine 和 Cloud Run 等 Google Cloud 內部的工作負載）。這些機制可完全消除長效金鑰的使用。

總結：IAM 作為雲端安全的基礎

對於 Cloud Digital Leader 考試，IAM 是將所有安全主題串連在一起的核心議題。請記住三大支柱——主體（principal，誰）、角色（role，做什麼）、資源（resource，哪個）——以及四層階層架構——組織 → 資料夾 → 專案 → 資源——並記住政策向下繼承。優先選擇預定義角色而非原始角色，對人類身分與服務帳號身分都嚴格落實最小權限原則，並始終搭配 Cloud Audit Logs 以在事後提供責任歸屬的證明。

能以業務語言闡述這些概念的 CDL——「我們在資料夾層級為行銷團隊的群組授予 roles/bigquery.dataViewer，使其能讀取所有行銷專案的廣告活動資料，同時無法修改任何內容」——就具備了為利害關係人提供安全雲端採用建議的能力。IAM 不僅是一項技術工具，更是讓 Google Cloud 在大規模環境下安全運作的組織規範。