前兩天，我們先建立了 GCP 的基本環境，接著把第一份資料放進 Cloud Storage。到了今天，問題開始從「資料放在哪裡？」變成另一個更重要的問題：
到底誰可以存取這些資料？可以做什麼？

這也是雲端環境從「可以操作」走向「可以管理」的重要一步。
在 Google Cloud 中，負責處理這件事情的核心服務就是 IAM（Identity and Access Management）。簡單來說，IAM 要解決的就是：
Who can do What on Which Resource？

也就是「誰，可以對什麼資源，做什麼事情」。

這個概念看似簡單，但真正開始使用雲端後，會發現權限往往比建立資源本身更加複雜。尤其當 Project、Bucket、VM、Service Account、不同角色與繼承關係全部出現後，如果沒有建立正確的觀念，很容易遇到 403，也很容易為了解決問題而不斷「加權限」。

一、IAM 到底在解決什麼問題？

Google Cloud IAM 是用來管理資源存取權限的機制。Google 官方目前將它描述成一套細緻的授權系統，可以控制「誰可以對哪些資源做什麼」。一個基本的 IAM 授權關係，可以從 Principal、Role 與 Resource 三個元素理解。

這裡有一個很重要的觀念：
IAM 管理的不是「你是不是登入了 Google Cloud」，而是「你登入之後究竟被允許做什麼」。
所以「我可以進入 GCP Console」和「我可以刪除這個 Bucket」是兩件完全不同的事情。

二、不要一遇到問題就給 Owner

假設今天執行某個操作時出現：

403 Forbidden
Permission denied

第一個反應很容易是：
「是不是權限不夠？那我給他 Owner 試試看。」

這個做法短期可能有效，但從權限管理的角度來看，問題反而更大。
Google Cloud 官方目前仍然明確建議採用 Least Privilege（最小權限） 原則。基本角色例如 Owner、Editor、Viewer 所包含的權限範圍很廣，在正式環境中應優先使用符合實際需求的預先定義角色或自訂角色，而不是直接給過大的基本角色。Owner 更可以修改幾乎所有資源與 IAM 政策，因此應該非常謹慎使用。

三、權限不是只看「有沒有」，還要看「從哪裡來」

IAM 政策也會受到這種階層關係影響。
例如，你可能沒有直接在某個 Bucket 上授予某個使用者權限，但如果他的角色是在 Project 層級授予，那麼這個權限可能會往下繼承。
所以當你發現：
「奇怪，我明明沒有在這個 Bucket 給他權限，為什麼他還是可以存取？」

這時候不要急著認為系統出錯。
應該回頭檢查，看看是不是某一層已經授予了角色。

Google Cloud 目前的 IAM 文件也指出，要完整判斷一個 Principal 對資源有哪些有效權限，不能只看該資源自己的政策，而需要考慮祖先資源的 allow policies；這些政策合併後形成實際生效的權限。Google Cloud Documentation
這個觀念非常重要，因為它直接影響後面的權限排錯。

四、遇到 403，不要急著加權限

如果今天執行：
gcloud storage cp sample.csv gs://my-bucket/
結果得到：
403 Forbidden
比較好的處理方式不是 Owner
而是把 403 當成一個「排錯線索」。
可以依序問：

1. 權限是不是從其他層級繼承？
   可能 Project 已經授予某個角色，也可能存在其他 IAM 政策。
2. 是否還有 Deny Policy 或其他限制？
   Google Cloud 現代 IAM 不只有 allow policies，也包含 deny policies、Principal Access Boundary 等更進階的存取控制機制。Deny policy 可以禁止 Principal 使用特定 Permission，即使這個 Principal 原本透過角色取得了該 Permission。Google Cloud Documentation
   因此，403 並不等於「缺一個角色」。
   真正要做的是找出：
   哪一個身分，在什麼資源上，缺少哪一個能力？
   這樣解決問題後，留下來的權限才比較容易維護。

五、權限正確了，還要知道「誰做了什麼」

到這裡，我們已經知道：

但如果某一天 Bucket 被刪掉了，我們還會有另一個問題：
到底是誰刪的？什麼時間刪的？執行了什麼操作？

這就是 Cloud Audit Logs 的價值。
Google Cloud 目前提供四種主要 Audit Logs：

• Admin Activity
• Data Access
• System Event
• Policy Denied
  每一筆 Audit Log 都會包含資源、時間、服務與其他事件資訊；其中 protoPayload 會包含像 principalEmail、methodName 等重要欄位，可以協助我們判斷誰執行了什麼操作。

六、最後才是清理：權限與資源生命週期要一起管理

例如這次為了測試 IAM，我們可能暫時增加了一個角色。
如果只是「測試成功」就離開 Console，那些暫時增加的權限可能一直存在。
同樣地，Service Account 如果已經不再使用，也不應該永遠保留。
Google Cloud 目前建議對不再使用的 Service Account 先停用，再經過確認後刪除，避免直接刪除造成仍在使用的 IAM bindings 失效。

最後其實全部都指向同一件事情：
雲端資源必須有生命週期。

建立、使用、驗證、監控，最後還要清理。

Service Account 可以理解成「給程式或工作負載使用的身分」。
Google 官方目前將 Service Account 定義為 non-human user，也就是非人類使用者。它可以被授予 Cloud Storage、BigQuery 等資源的存取權限，也可以被其他 Principal 使用或模擬，因此它本身同時具有 Principal 與 Resource 的特性。

參考資料

1. Google Cloud — Use IAM securely
2. Google Cloud — IAM overview
3. Google Cloud — Best practices for using service accounts securely
4. Google Cloud — Best practices for managing service account keys
5. Google Cloud — Understanding audit logs
6. Google Cloud — Shared responsibility in Assured Workloads