(三) 設置兩個最高管理員
如果你目前只有專案層級，那就是設定兩位擁有者，為什麼呢？
曾經發生過一家中小企業，老闆要工程師使用 GCP，但工程師用自己的 Gmail 來申請 GCP，而且沒有授權給老闆。有一天工程師離職了，沒有交接 GCP 的專案，直接人間蒸發，老闆從頭到尾都沒有被授權 GCP 專案，等於員工直接帶走公司的重要系統和資料。
如果為此向 Google 提交技術支援申請，Google 基於本身的條款，不會介入任何 GCP 的操作，就是不可能直接把那個專案還給老闆並且把工程師踢掉。
所以第一個方法就是至少要有兩位擁有者，第二個方法則是，不要用 Gmail，而是使用 Cloud Identity 來創建一個機構，如果工程師在專案是擁有者，老闆是機構管理員，還可能把專案的權限拿回來。
同理，如果你是已經有 GCP 的機構層級，那也要設定兩位機構管理員，一方面防止上述情形發生，另一方面則是防止帳號被駭客盜走，至少另一個帳號還有機會阻止駭客。
(四) 善用稽核記錄 (Audit Logs)
GCP 預設會自動記錄每個使用者的操作，如果有人做了什麼異常的行為，都會被記錄起來，但有些 Data Access Logs 預設沒有開啟，你可以評估有哪些重要服務要開啟記錄功能。
要注意額外開啟的 Log 會佔用 Cloud Logging 的儲存空間，如果想要節省費用，可以匯出到其他地方保存。
(五) 在機構層級管理跨專案存取的 IAM 政策
如果你有多個專案，在機構層級設定 IAM 的話，你只要設定一次就好，而不用每個專案都設定一次，如果公司常常新增或刪除 GCP 專案，這樣可以避免有哪一個專案沒設定到。
另外，可以針對部門成員建立群組 (Google Group)，這樣就可以透過群組統一授權，也能避免人員異動，而沒有被授權到相關權限。
最好的方式就是，各個部門都有各自的資料夾，資料夾底下就是部門自己擁有的 GCP 專案，然後資料夾直接分配授權給部門群組，或是主管，這樣就能更方便地管理全公司的 IAM。
四、 Service Account (服務帳戶) 簡介
Service Account 是一種特殊的 Google 帳戶，設計用來代表應用程式或服務，而不是人類使用者。它能夠執行指定的任務並存取必要的資源。
和人類使用的帳號比起來，Service Account 的使用頻率更高，像我們人類平日會上下班，假日會休息，而 Service Account 是和程式綁在一起，全年無休 24小時運作的，因此它更顯得重要，本文特別拉出來單獨說明。
(一) Service Account 的功能和特色
1. 提供應用程式授權，以操作 GCP 資源
Service Account 的主要任務之一是提供授權給應用程式，允許它們存取和操作 GCP 資源。
無論是存取 Cloud Storage 中的檔案，還是對 BigQuery 的表格查詢，Service Account 都能做為應用程式的「身份」，確保只有經授權的應用程式能與資源互動，避免未經允許的存取行為。
2. 基於身份和角色的存取控制
Service Account 在 Cloud IAM 中也是被授權的「主體」，你可以授予任何需要的角色來取得權限，讓 Service Account 能操作 GCP 的資源。
例如，某個 Service Account 可以被授權僅限讀取 Cloud Storage 資料，而另一個 Service Account 能被授權操作 Compute Engine 資源 (例如給 VM 開機或關機)，這種細微的權限控制提高了整體的安全性。
另一方面，上述提到的自訂角色，設定給一般使用者，由於使用者操作 GCP 所需的權限較多，實際執行起來有點麻煩。
但是如果是給 Service Account 使用自訂角色，反而是好的，因為你可以真的只給 1~2 條必要的權限，真正符合最小權限原則的精神。
3. 提供安全的 API 呼叫和資源操作方式
我們人類在 GCP 的任何操作，背後都是 AP 在運作的。而應用程式需要透過 API 與 GCP 服務互動時，Service Account 會以它的身份進行授權並簽署 API 請求。這樣能確保通訊的安全性，避免敏感資料在傳輸過程中被駭客攔截。
而且，Service Account 的 Key 還能進一步加密對 API 的呼叫，提供額外的保護。
(二) Service Account 的運作流程
如下圖所示，Service Account 的運作流程可分為以下四個步驟：
1. 應用程式保存著 Service Account Key 的 Json 格式金鑰檔案，裡面包含 GCP Project ID、Service Account ID 和 Key 的內容。
2. 當需要存取 GCP 服務時，應用程式使用這個 Json Key 來呼叫 GCP 的 API 進行身份驗證。
3. GCP 驗證金鑰的有效性，並確認對應的 Service Account。
4. 驗證成功後，應用程式可以使用該 Service Account 被賦予的角色和權限存取 GCP 服務。
(二) Service Account 的常見使用情境
1. 自動化工作流程
GCP 提供的 CI/CD 工具如 Cloud Build 和 Cloud Run，能幫助開發人員簡化軟體的編譯、測試與部署流程。
這些工具在運作過程中，通常需要訪問其他 GCP 資源，例如讀取 Cloud Storage 中的設定檔，或寫入結果至 BigQuery，此時就必須要使用 Service Account。
Service Account 為這些工具提供授權，確保它們能安全地訪問資源，同時避免人為操作的繁瑣與潛在錯誤。這不僅提高了工作效率，也降低了安全風險。
2. 跨系統間的安全通訊
應用程式通常需要在各個服務之間通訊或傳輸資料，例如從 Cloud Storage 中讀取資料，並透過 BigQuery 分析處理。而通訊必須以安全為首要考量，否則可能導致敏感資料洩露出去。
Service Account 可以充當服務之間的信任橋樑，透過授權的 API 呼叫，Service Account 確保只有經過允許的服務才能執行特定操作。
此外，它還能限制操作範圍，避免過多的權限導致潛在風險，這點非常重要。這樣的安全機制，不僅保護了資料的完整性，也簡化了跨服務整合的流程。
3. 第三方應用整合
在許多情境下，企業需要將 GCP 資源與第三方應用程式串接。例如，某些外部程式需要訪問您的 Cloud Storage 或監控你的虛擬機器的效能指標。為了保障安全，為這些第三方應用創建專屬門的 Service Account 是最好的方法。
專門的 Service Account 能夠以最小權限原則給予角色，只讓它存取必要的資源。同時，這種設計方式也能確保第三方應用與內部服務之間的存取控制是清晰且可管理的。
一旦某個第三方應用不再需要訪問資源，刪除其對應的 Service Account 就可以立即撤銷其權限，提升整體安全性。
(三) 如何建立和管理 GCP Service Account
1. 建立 Service Account
主選單「IAM 與管理」的「服務帳戶」，點擊「建立服務帳戶」。
接下來給 Service Account 命名，建議取一個容易了解的名字，或是設定一個命名原則，在說明欄也寫清楚這個 Service Account 的用途，讓其他人都看得懂。接下來按「建立並繼續」。
接者設定要授予 Service Account 的角色，這個動作在 IAM 的主畫面也可以設定，GCP 在這裡是給你方便一起設定，如果還不確定要授予什麼角色，也可以先跳過。
如果你按「繼續」，下一步驟是把 Service Account 的存取權給使用者，這一步請跳過！！直接按下完成。
你可能會覺得奇怪，這個步驟在做什麼？為什麼要跳過？
因為這個動作是把 Service Account 的使用權給使用者，使用者會取得這個 Service Account 的所有權限，例如使用者原本只有 Compute Instance Admin 角色，只能管理虛擬機器，結果他拿到一個 Service Account 的存取權限，而這個 Service Account 可以存取 BigQuery 所有的資料，等於這個使用者也能看到 BigQuery 的資料。
所以這個動作會讓使用者的權限範圍擴大，違反最小權限原則。
除此之外，使用者透過 Service Account 存取資料，會繞過正常的權限管理機制。因為系統日誌只會記錄 Service Account 存取資料的記錄，追蹤不到實際的操作者是誰，如果發生資安事件，也會阻礙調查。
就像你是大樓的管理員，Service Account 就像是公司的門禁卡，使用者小明是員工，GCP 的服務就像是大樓裡的不同房間。
小明只能進入一樓茶水間和三樓的辦公室，結果你把你的門禁卡給了小明，小明突然可以進入所有樓層，包括機密檔案室！
而大樓的監視器只會拍到「有人用公司門禁卡進出」，但不會知道用門禁卡的人是誰。如果小明把資料帶出大樓，或是銷毀，沒有人會知道是小明做的。
所以這個動作，除非你熟悉會有什麼後果，如果不懂最好不要授權給使用者。
按下完成之後，你可以點擊 Service Account 的名稱，進入它的詳細資訊頁面。
在這裡你會看到專屬 ID，如果你再展開下方進階設定，還會看到用戶端 ID，這些都是機密資訊，不要隨便分享。
尤其是「網域層級委派」，這是一個在 Google Workspace 中的「超級無敵大權限」，它可以看到公司內所有人的雲端硬碟檔案，如果不懂絕對不要設定。
2. 建立 Service Account Key
如果你的 Service Account 是要讓外部的應用程式存取 GCP，就要再建立 Service Account Key。這時我們再點擊「金鑰」頁籤。
下方會看到「新增鍵」，這是 Google 翻譯得不好，其實就是「新增金鑰」，然後再「建立新的金鑰」。
點擊之後會彈出一個視窗，問你 Service Account Key 的檔案要下載成什麼格式，通常我們都用 Json 格式。
按下「建立」之後，會自動下載金鑰檔案到你的本機電腦。
所以當你擁有這個金鑰檔案，你就有能力存取 Service Account 能存取的各項資源了。
這也代表你必須好好保管這個檔案，要注意「非常非常多用戶」因為沒保管好金鑰檔案，導致檔案被駭客拿走，在 GCP 的專案裡大肆破壞你的環境，或是開一堆機器在挖礦， 一天之內造成上百萬元的 GCP 帳單，是由你幫駭客買單，不可不慎！
(四) 什麼時候要使用 Service Account？
Google 在官網有提供一個決定是否要用 Service Account 的決策過程如下：
我將問題標上號碼，逐一解析如下，方便你能對照著看：
1. 你是否在單一使用者開發環境 (如個人電腦、Cloud Shell、個人用的虛擬機器、虛擬桌面)？
像這樣的環境通常已經有使用者登入，你可以直接使用個人的憑證，例如你可能就是專案擁有者，權限也夠大，所以在開發或測試時較為彈性，不會動不動就因為權限不足而卡住。
・是，往問題 4，因為可能有更簡單的驗證方式。
・否，往問題 2，可能是生產環境或共享環境，會影響到這些環境的正常運作，所以可能要使用 Service Account，能確保它的權限不會太大，影響到其他部分的運作。
2. 你是否在 GCP 中運作程式？
因為 GCP 有特殊的驗證機制，可以直接使用內建的身份驗證，不一定真的要用 Service Account。
・是，往問題 3，確認是否使用容器服務，如果是，遇有其他方法可以使用。
・否，往問題 5，程式可能在本機或其他雲端的外部環境，可能真的要用 Service Account。
3. 是否在 GKE 或 Anthos 中執行容器 (Container) 應用程式？
GKE (Google Kubernetes Engine) 是 GCP 的容器管理服務，它把原生的 Kubernetes 直接做在 GCP 上，底層交由 GCP 直接來管理維護，並做出各種加值應用，比原生的 Kubernetes 更為方便強大。Anthos 則是讓地端也能夠執行 GKE。
・是，使用 Workload Identity Federation for GKE，這是 GKE 專門的身份驗證機制，比 Service Account 更安全。
・否，直接使用 Service Account。
4. 你的情境是否真的需要 Service Account？
它是問你是否需要在所有環境中統一驗證的方式，需要特殊的權限組合，或是自動化的操作。
・是：使用使用者憑證 (User Credentials) 模擬 (Impersonate) Service Account，因為這個動作必須要先做使用者身份驗證，事後可以追蹤到是誰在使用，而且它會產生短期憑證，會自動過期，比較安全。詳細內容可以參考這份文件。
・否：使用使用者憑證，就是使用者本人親自驗證。
5. 你的工作負載 (Workload；就是你在運作的程式) 是否支援 (Workload Identity Federation)？
它指的是 Workload Identity Federation 可以支援像是 AWS IAM 或 Azure AD 所提供的身份，這樣的話就不用額外建立和管理 Service Account 和金鑰，更安全也更方便。
・是：是：設定 Workload Identity Federation。
・否：建立 Service Account Key，已經沒有其他更好的方式了。
(五) 預設的 Service Account
1. 為什麼會有預設的 Service Account？
你可能會發現，在 Cloud IAM 的畫面中，經常看到兩個預設的 Service Account： Compute Engine default service account 和 App Engine default service account。
這些 Service Account 是 GCP 自動創建的，主要用於特定服務的運行授權。當 Compute Engine VM 或 App Engine 應用程式運行時，GCP 會自動為它們提供一個安全的「內部身份驗證代碼 」(Identity Token)，這些代碼用來代表預設的 Service Account 進行身份驗證和授權。
2. 預設的 Service Account 的特點如下
・無需手動管理密鑰檔案：不需要產生、下載 Service Account 金鑰檔案。
・安全性更高：避免了因金鑰洩露導致的資安風險。
・簡化操作：應用程式可以直接使用 Google 提供的函式庫 (例如 Google Cloud SDK 或 Cloud Client Libraries) 進行授權，這些程式庫會自動檢測並使用預設的身份。
以下分述兩個預設的 Service Account：
(1) Compute Engine Default Service Account
Compute Engine Default Service Account 是當您在專案中啟用 Compute Engine API 時自動生成的 Service Account，它的格式會長這個樣子：
[project-number]-compute@developer.gserviceaccount.com
你可能會想，你什麼時候啟用這個 API？其實當你建立好一個新的專案，接著要準備建立你第一台虛擬機器時，它就會自動啟用 Compute Engine API 了。
由於虛擬機器在 GCP 裡面也可能要呼叫其他服務，所以這個 Service Account 會授權虛擬機器存取 GCP 資源，例如讀取 Cloud Storage 中的資料或與 Cloud SQL 進行互動。
預設情況下，此 Service Account 通常具有 Editor 角色 (Role)，即允許對專案中的所有資源進行讀寫操作。然而，這種設置在安全性上存在潛在風險，詳細內容可以參考這份文件。
你可能會很緊張，擔心如果機器被駭客入侵，那駭客不就拿到 Editor 角色的權限了？
其實當我們在建立機器時，雖然 GCP 預設使用 Compute Engine Default Service Account，但是它受到「存取權範圍」的控制。如果你當時切換到「針對各個 API 設定存取權」，可以看到它原始的設定如下圖：
它的預設設定包含：Storage 和 Service Management 的唯讀存取權、Stackdriver Logging 和 Monitoring 的寫入權限，以及 Service Control 的讀取/寫入權限。所以它的權限是比較小的，不用太過擔心。
假如你對這一點有充份了解，那就建議你以後建立虛擬機器時，不要使用 Compute Engine Default Service Account，而是用你自訂的 Service Account，然後採用最小權限原則，根據 VM 的具體需求調整其角色。
例如，只賦予存取必要資源的權限，而非整個 GCP 專案所有服務的讀寫權限。還要注意要設定 Logs Writer 和Monitoring Metric Writer，這樣虛擬機器才能夠把 Log 和效能指標寫入 GCP 喔！
(2) App Engine Default Service Account
這是當您啟用 App Engine 應用程式時，GCP 自動創建的 Service Account，它的格式會長這個樣子：
[project-id]@appspot.gserviceaccount.com
它會授權 App Engine 的應用程式存取 GCP 資源，例如呼叫其他 GCP 服務的 API 或存取資料庫。
這個 Service Account 也有 Editor 角色，允許應用程式對專案內的資源進行各種讀寫操作。它和 Compute Engine default service account 一樣，預設權限過高可能導致安全性問題。
建議你手動把它的 Editor 角色改成更小權限的角色，等到它存取其他服務，卡住的時候再逐步開放也不遲。
如果你的機構 (Organization) 是在 2024 年 5 月 3 日以後建立的，它有一個機構政策「停用自動為預設服務帳戶授予 IAM 的功能」，是預設會強制執行的，那就不用擔心。(注意你要切換到機構角度，不是專案角度)
像我是的機構是之前就建立的，該政策並沒有強制執行，就請務必透過「管理政策」來改成「強制執行」。
(五) Service Account 注意事項
在 GCP 官方文件提供的 Service Account 注意事項非常多，這裡整理幾個最簡單也最重要的要點給大家：
1. 將 Service Account 視為資源管理
因為它的使用方式，跟一般的使用者帳號差很多，所以要定期觀查每個 Service Account 的使用情形，如果有程式不再運作，就要跟著停用對應的 Service Account 和金鑰。
2. 建立單一用途的 Service Account
遵守最小權限原則，Service Account 只做一件事，使用最小剛好用到的權限，不要使用預設的 Service Account。
3. 建立並遵守命名原則
讓大家一看就知道 Service Account 用在什麼地方，甚至在說明欄位記錄聯絡人和文件連結，以後如果要異動，能夠找到對應的負責人員聯絡，避免誤刪造成系統無法運作。
4. 識別並停用未使用的 Service Account
你可以使用 Activity Analyzer 檢查使用情況，查看最近 Servcie Account 和金鑰的驗證記錄，具體操作可以查看這份文件。
5. 在刪除前先停用
先停用一段時間再決定是否刪除 Service Account，或先刪除金鑰，觀查是否有影響到某個程式的運作，避免太快誤刪造成系統維護的麻煩。
6. 不要用預設的 Service Account
如上述所談，權限太大了。虛擬機器也不要用預設的 Service Account，盡量用專屬的 Service Account 配上專屬的角色。
7. 不要使用網域授權 (Domain-wide Delegation)
這個權限太大了，會讓 Service Account 模擬組織中的任何使用者，也容易被駭客拿來破壞。或是必須設定權限到期日，不要讓它的權限一直存在。
8. 不要讓任何人可以直接存取 Service Account
如果一個使用者可以存取 Service Account，他就有可能用 Service Account 的權限做更多事情，甚至利用 Servcie Account 的權限 (像是 iam.serviceAccounts.setIamPolicy)，再間接取得更多權限。
9. 在沒有其他選擇時才使用 Service Account 金鑰
使用金鑰做所份驗證時，你沒有辦法追蹤誰使用了金鑰。此外也不要把金鑰檔案儲存在公開的程式碼儲存庫 (如 GitHub)。還有定期輪替金鑰，防止過期或洩露帶來的風險。
10. 善用稽核記錄 (Audit Logs)
某些 GCP 服務 (例如 Compute Engine) 在Audit Logs 中會包含 serviceAccountDelegationInfo 欄位，這個欄位會顯示Service Account 是否被模擬使用，以及是誰在模擬這個 Service Account。
但不是所有服務都會記錄模擬的詳細資訊，需要額外啟用某些 API 的資料存取記錄，否則可能會遺漏重要的追蹤資訊。因此還要再啟用 Data Access Logs：
(1) Identity and Access Management (IAM) API，能夠追蹤 Service Account 的詳細使用情況。
(2) Security Token Service API，會記錄 Token 的請求和發放，追蹤身份驗證的過程。
還有很多更細節的注意事情，有需要再參考這份文件。
五、結論
你會發現，本文前半部在開始介紹 IAM 還蠻簡單的，後面隨著牽涉到的範圍越廣也越深。因為整個 GCP 環境內的所有動作，沒有一個和權限無關，就算是 GCP 本身例行性的維護和運作，雖然沒有經過你的操作，你也都能夠查到相關的記錄和使用的權限，而不會直接隱藏不讓你知道。
所以 Cloud IAM 就是 GCP 運作的底層邏輯之一，如果這部分能夠充分了解，對你以後操作 GCP 和故障排除時會很有幫助，也能夠確保整個環境的資訊安全，避免內部人員越權或駭客入侵造成嚴重的後果。
來源文章：
