【東東老師 X 思想科技】Google Cloud IAM 的角色與權限控管介紹

當你開始使用 GCP 的專案，你就是這個這個專案的最高管理員，稱為「專案擁有者」(Project Owner)。 你可以管理這個專案中的所有資源，愛怎麼用就怎麼用。但如果你今天是在一家公司裡，一個專案可能會跟同事或其他部門的人一起使用， 如果企業夠大，有專業分工，甚至會有管理網路的、管理主機的、管理負載平衡的、還有專門管理帳單的人。 所以我們就必須切分成不同的權限，讓大家各司其職的同時，不影響其他人的操作，也能兼顧資訊安全，這就是為什麼我們要了解 Cloud IAM 。

Cloud IAM 是什麼？

Cloud IAM，全名 Cloud Identity and Access Management，直譯為身份和存取管理。就是 GCP 的角色和權限管理系統，管理「誰」可以進入「某個區域」做「什麼事情」。

由此可知它有三個元素：

1. 「誰」指的就是一個身份

又叫做「主體」(Principal)。

2. 「某個區域」就是「資源」

像是 VM、Disk 或 Cloud Storage Bucket 都是資源。

3. 「什麼事情」指的是具體的操作行為

也就是細分的權限，例如建立 VM、修改 VM 參數、讀取 VM、刪除 VM 等等。所以 Cloud IAM 就像是 GCP 的門禁系統，確保「對的人」可以存取「對的資源」，並且只能進行「被允許的操作」。

Cloud IAM 有什麼前提？

這裡指的是 Cloud IAM 可以管理的帳號，分成以下幾種狀況：

如果你本來就是使用 Gmail 或是 Google Workspace，當你啟用 GCP 的環境，你的帳號就可以直接用在 Cloud IAM。 但如果你使用的不是 Google 的帳號，例如你可能使用微軟的 M365，或是其他的郵件系統，你會看到像這樣的錯誤訊息：

代表這並不是一個 Google 帳號，你就必須要申請 Cloud Identity，讓你能夠建立 Google 的帳號， 這樣就可以使用 Cloud IAM 了。而可以被授權 Cloud IAM 角色的對象我們稱為主體 Pricipal，而這個主體並不是只有帳號，還包含了 Google Group (群組)，還有 Service Account (服務帳號) 跟網域，這些都是都是可以在 Cloud IAM 裡面，被賦予角色權限的對象。 

Cloud IAM 的角色與權限的關係

在 GCP 的專案環境中，每一個對資源的操作，有可能包含一個以上的權限，像是建立一台 VM，可能至少包含以下權限：

• compute.instances.create  (建立 VM)
• compute.disks.create (建立開機磁碟)
• compute.networks.use (讓 VM 連接到某個 VPC)
• compute.subnetworks.use (讓 VM 連接到某個 Subnet)
• compute.images.useReadOnly (使用一個作業系統的 Image，例如 Ubuntu)

而目前在一個 GCP 專案中，截止目前 (2024年11月21日)，已經有超過 10000 個細分權限，如果我們直接設定這 10000 個權限分配，應該會設定到懷疑人生。

而且這個權限數量，還隨著 GCP 新推出的服務持續增加當中。以專案擁有者，幾乎擁有全部的權限數量如下：

為了簡化管理，GCP 把相關的權限群組起來，依照使用的場景或是執行的操作， 劃分成不同的「角色」 ，這樣我們就能方便地管理大家的權限。 補充一下，GCP 的帳單角色，不直接屬於專案，而是和帳單帳戶 (Billing Account) 綁定的，運作方式有些不同，未來會再專文討論。

Cloud IAM 的角色類型

Cloud IAM 的角色有三大類，分述如下：

1. 基本角色 (Primitive Roles)

之所以叫「基本」，就是以簡單粗暴的方式來劃分權限，許多小公司或個人使用者都是用這類的權限，就是因為簡單，我們從權限由大到小說明如下：

(1) 擁有者 (Owner)

當你第一次進入 GCP 主控台，GCP 會用你的身份來建立一個專案，而你就是專案的擁有者。你擁有在這個專案裡全部的權限，看得到所有資源和資料，也可以任意更改，你也能夠管理任何帳號被分配的角色和權限。

(2) 編輯者 (Editor)

編輯者能看到專案內所有資源的內容，也都能修改，像是開機器、關機器、建立負載平衡器，這些都做得到。編輯者和擁有者的權限很接近，就差在不能管權限，你沒有辦法授權別人進來這個專案，或者是把某個成員踢掉。

(3) 檢視者 (Viewer)

檢視者在這個專案裡面的東西，你全部都可以看，可是你不能改，但是全部都看得到，權限也是蠻大的。你可以看到專案內開了幾台機器、所有的 Cloud Storage Bucket 都能點進去看儲存了哪些檔案、 BigQuery 裡面有哪些表格和裡面的資料，全部都看得到，甚至可以下載到你的電腦上。

(4) 瀏覽者 (Browser)

瀏覽者的權限是最小的，它只能讓你知道，手上有一個專案叫做 dong-dong-gcp-4-cloud，並且能夠進入資訊主頁，看到這個專案的基本資訊，僅此而已，但裡面所有資源的內容都完全看不到。

2. 預先定義的角色 (Predefined Roles)

由於基本角色的權限劃分比較簡單粗暴，方便好用，但這種方式給出的權限都有一點太大了。

對於公司規模較大，在部門專業分工的情境下，就可以使用預先定義的角色。 這種角色就是依照使用者在公司賦予的任務之下，授權相對應的權限。 

例如：

(1) 只管虛擬機器的人，就可以給他執行個體管理員 (Compute Instance Admin)；

(2) 管理 VPC 和 Subnet 的人，可以授予 Compute Network 管理員；

(3) 管理防火牆的人可以授予 Compute Security 管理員； 

(4) 管理上述全部的人，可以直接授予 Compute 管理員；

(5) 而管理整個專案資訊安全的人，卻又不管理虛擬機器和網路的人，可以授予 Security 管理員。 

這樣感覺很複雜，我們整理如下表：

你可以看出，每個權限都可以縱向擴充 (網路相關權限包含資安)，或是橫向擴充 (資安相關權限包含網路)。而且不是只有管理員，GCP 的每一個服務也都能再細分成編輯者和檢視者。

而且上述只針對虛擬機器和網路，GCP 還有各種服務如 Cloud Storage、Cloud SQL 和 BigQuery，各自又區分出不同的角色。由此可見，角色區分地非常細。 只要公司有對於權限或資安有較高的標準和規劃， 都可以依照分工和職責去給予不同的角色。 但反過來說，也會需要專人來負責管理權限劃分，以免造成授權混亂的情形。

3. 自訂角色 (Custom Roles)

因為預先定義的角色是用服務或屬性來劃分每個角色擁有的權限， 但是如果一個人的職責橫跨不同的服務，例如他同時管理虛擬機器和 Cloud SQL 資料庫，你就必須同時給予兩種角色，或是使用一個自訂角色配上相關的權限。 

這種方式可以對每個人的權限做最細緻的管理，做到「剛好必要」的權限分配。但這就需要一個專門的人員，除了了解 GCP 的每一項操作產生的結果，也要知道該行為涉及哪些權限。因為當這個制定角色開通並且授權出去之後 ，使用者可能會在過程中會發現提出某個功能的操作權限不足，然後再回報給自訂角色管理人員， 來來回回重複確認和測試，並且調整權限，過程會很耗時。 

而且這個過程很有可能是會持續發生的，隨著使用者對於 GCP 的操作越來越深入或廣泛， 所以會持續提出增加權限的需求。 同時  GCP 的服務也會持續的成長，每個服務的功能也會越切越細，導致新的權限不斷產生，然後再持續調整授權。 如果沒有專屬的角色管理人員來處理的話， 很容易讓權限管理變得混亂。 因此通常建議使用預先定義的角色就好，除非公司專業分工到了極致，再考慮使用自訂角色。

Cloud IAM 的基本授權操作

主選單有一個 IAM 與管理，進去後會直接顯示「身分與存取權管理」的頁面，它會列出在一個 GCP 專案內，所有帳號授權的角色有哪些，如果要授權給新的帳號，就點擊「授予存取權」。接著在「新增主體」欄位輸入要授權的帳號，選擇要指派的角色，因為角色非常多，要慢慢找，或著是先去「角色」頁面看好要授權的角色，把名字複製起來，貼在角色的搜尋欄位裡面。

有一點要注意的是，如果你今天是授權專案擁有者給別人，系統會發信通知對方，但是其他角色的授權不會發信通知。

所以當你授權其他角色之後，你就把專案的網址直接傳給對方，讓對方方便進入你的專案操作。 

Cloud IAM 角色和權限的繼承機制

上述只提到專案和資源的範圍，而在整個 GCP 的組織架構裡，總共分成 機構 (Organization)、資料夾 (Folder)、專案 (Project) 和資源 (Resource) 四個層級。

權限會從上而下繼承，代表在機構層級授予的角色，會應用到所有資料夾、專案和專案內的資源。

如上圖，如果你在 Team B 資料夾層級授權 Viewer 給同事，他就可以看到 Project 1 和 Product 2 底下所有的專案，以及專案之下所有的資源。如果你在 Production Project 又授權 Editor 給同事，因為 Editor 角色涵蓋的權限比 Viewer 多，所以會覆蓋原本 Viewer 的權限，同事在專案就擁有 Editor 角色的所有權限。在專案層級，如果你是在 Test 專案授權 Compute Instance Admin 給同事，他就可以連到 Test 專案裡所有的虛擬機器。

那假如只想給同事連到其中一台機器怎麼辦？

在 IAM 授權的介面中，還有一個條件 (Conditions)，這裡可以設定到最細的資源對象，甚至連授權的時間都可以規範，不過要注意目前還是 Preview 階段，建議多反覆測試再使用，詳細的說明可以參考這份文件。

Cloud IAM 設定中常見的注意事項

(一) 遵守最小權限原則 (Principle of Least Privilege)

1. 最小權限原則主要三個基本原則

(1) 使用者只能擁有完成其工作所需的最小權限，也就是剛好必要的權限。

(2) 如果可以的話，權限的範圍和時間都應該最小化。

(3) 預設拒絕所有權限，只開放必要的存取

2. 最小權限原則的比喻

可以想像成一個飯店的房卡系統：

(1) 住客的房卡只能開啟自己的房間。

(2) 清潔人員的房卡有時效性限制，例如從退房期限開始 (中午 12:00) 到新客入住之前 (下午 15:00)。

(3) 經理雖然是主管，但是他也只能進入辦公室區域，不能進入住客的房間。

3. 最小權限原則在 GCP 的正式做法

(1) 優先使用預先定義的角色或自訂角色

(2) 除非真的別無選擇，否則盡量不要用基本角色

(3) 可以使用 GCP 的「角色建議」和「政策模擬」來找出最適合的角色

角色建議 (Role Recommendations) 功能，它是由 IAM Recommender 所產生的，它會主動提示目前授予的角色，是否包含太多權限，確保你能夠遵守最小權限原則，詳細說明可以參考這份文件。

我們在 IAM 的主畫面就可以看到，它提示了某個授權設定包含 9003 個超額權限。

當我們點擊它所提示的超額權限之後，它會秀出建議替換的角色，並且分析權限數量的變化。

政策模擬器 (Policy Simulator) 功能則是讓你在變更某個帳號的角色時，讓你預先確認變更前後的差異。如下圖我把一個帳號從 Secret Manager 密鑰存取者改成Secret Manager 密鑰管理員：

若我們按下測試變更，會看到它模擬變更後會有什麼結果：

要注意它列出來的存取權變更，是根據前面 90 天的操作記錄來分析，如果你像我一樣，90 內曾經刪除過某些資源的話，它就會顯示「狀態不明或發生錯誤的存取權」，所以如果可以的話，最好能夠逐條確認變更後的影響。

(二) 個人帳號務必啟用兩步驟驗證

如果駭客今天不是駭入你的主機或程式，而是直接破解你的密碼，那它就有可能做出任何毀滅性的事情，例如瘋狂開你的機器來挖礦，或開啟殭化電腦去攻擊其他系統，所以這是根本且必要的步驟。

如果可以的話，最高管理員請使用 Security Key，長得有點像隨身碟，以後兩步驟驗證的第二步驟，就可以插入金鑰來驗證。

(三) 設置兩個最高管理員

如果你目前只有專案層級，那就是設定兩位擁有者，為什麼呢？

曾經發生過一家中小企業，老闆要工程師使用 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。

文章轉載自《東東GCP 教學》網站