本文說明使用 Google 群組透過 Identity and Access Management (IAM) 管理 Google Cloud 資源存取權的最佳做法。
群組類型
這裡列出的群組類型，是思考、使用及管理 Google 群組的一種方式。這些群組類型並非由任何 Google 群組屬性設定。不過，在整體 Google 群組管理方法中採用這些群組類型，有助於避免一些常見的安全陷阱。
本文件使用下列類型的群組：
機構群組
機構群組代表機構結構的子集，通常來自人力資源資料。這些群組可能以部門、匯報結構、地理位置或其他組織分組為依據。
員工加入機構、調往其他部門或離開機構時，機構群組的成員也會隨之變更。
當商家重組時，組織群組的整體結構可能會變更。重組可能會導致建立新群組，或停用現有群組。
機構群組的例子包括
org.marketing-fte、org.finance-all、org.msmith-reports、org.apac-all和org.summer-interns。機構群組通常用於電子郵件通訊。
協作群組
協作群組代表工作群組、專案成員，或想要協作處理專案或討論特定主題的使用者。
協作群組的架構與任何機構架構無關。通常是根據臨時需求，以自助式方式建立。
協作群組的成員資格不受限制，機構中的任何人都能加入。或者，協作群組可以自我管理，也就是由特定成員決定要將誰納入群組。
協作群組的範例包括
collab.security-discuss和collab.website-relaunch。協作群組通常用於電子郵件通訊。
存取群組
存取權群組的唯一用途是提供存取權。這些群組代表工作職能，可簡化指派執行這些工作職能所需角色的程序。您不必將角色授予個別主體，而是將角色授予群組，然後管理群組成員資格。
存取權群組的結構會受到貴機構資源或工作負載結構的影響。部署新資源或工作負載時，可能需要建立新的存取群組。
存取權群組的成員資格通常由一或多位群組擁有者控管，他們會邀請使用者加入群組，或核准使用者加入群組的要求。
存取群組的範例包括
access.prod-firewall-admins、access.finance-datamart-viewers和access.billing-dashboard-users。存取權群組僅用於提供存取權。不會用於通訊。
違規處置群組
強制執行群組與存取群組類似，但強制執行群組是用於強制執行存取限制政策，而非提供存取權。
執行群組的結構通常會受到法規遵循需求和組織結構的影響。
通常會根據一組預先定義的規則，判斷使用者是否屬於強制執行群組，這些規則會考量使用者的安全等級、位置或在機構中的角色。
強制執行群組的範例包括
enforcement.users-in-restricted-locations、enforcement.fedramp-low和enforcement.sso-users。強制執行群組僅用於強制執行存取限制政策。不會用於通訊。
為群組命名，以反映群組類型
為協助您遵循本文件其餘部分的最佳做法，請使用可從名稱判斷群組類型的群組名稱。您可以使用命名慣例或次要網域。
命名慣例
以下是其中一種命名慣例，可讓群組類型一目瞭然：
機構群組：
org.GROUP_NAME@example.com。 例如：org.finance-all@example.com。協作群組：
collab.TEAM_NAME@example.com。 例如：collab.msmiths-team@example.com。存取權群組：
access.JOB_FUNCTION@example.com。例如：access.billing-dashboard-users@example.com。違規處置群組：
enforcement.GROUP_DESCRIPTION@example.com。例如：enforcement.sso-users@example.com。
採用貴機構適用的慣例，並確保群組管理軟體支援該慣例。使用前置字串可依功能將群組依字母順序排序，但部分群組管理系統 (例如 Google 網路論壇企業版) 僅支援後置字串。如果無法使用前置字元，可以改用後置字元或次要網域。
次要網域
除了命名慣例，您也可以使用次要網域將群組類型嵌入名稱中，例如 access.example.com。如果次要網域是已驗證網域的子網域，則不需驗證，也不必存在於 DNS 中。此外，如果沒有為次要網域建立 DNS 郵件交換 (MX) 記錄，就能禁止非預期通訊對象的群組接收內送電子郵件。
巢狀規則
不同類型的群組有不同的規則，決定是否允許巢狀結構 (接受群組做為成員)。
機構群組的巢狀結構規則
建議您巢狀組織群組，反映組織結構圖。也就是說，每位員工都會加入一個群組，而這些群組會彼此包含。舉例來說，org.finance-all 群組可能包含 org.finance-us、org.finance-germany 和 org.finance-australia 群組做為成員。
您可以將組織群組新增至任何其他類型的群組做為成員。相較於必須將機構群組的每位成員新增至其他群組，這種做法簡單許多。
請勿將任何其他群組類型新增為機構群組的成員。請勿將存取權、執法或協作群組做為機構階層的一部分。
協作群組的巢狀規則
每個協作群組都應有一套明確的政策，決定如何新增成員。如果兩個協作群組遵循相同的成員政策，即可巢狀化。不過，如果巢狀協作群組的成員資格政策不同，不符合群組成員資格政策的成員也可能加入。請先詳閱成員政策，再巢狀嵌入協作群組。
協作群組可以將機構群組設為成員。
存取權群組的巢狀規則
一般來說，您不應巢狀存取群組。巢狀存取權群組可能會導致難以判斷誰有權存取哪些資源。此外，如果存取群組巢狀結構包含不同存取政策，主體可能會規避嚴格的存取群組成員政策。
存取權群組可以將機構群組設為成員。
強制執行群組的巢狀規則
請勿以巢狀結構編排強制執行群組。巢狀強制執行群組會導致難以判斷主體存取遭拒的原因。此外，如果巢狀強制執行群組的成員資格政策不同，部分主體可能會受到非預期的限制。
強制執行群組可以將機構群組設為成員。
管理機構群組
請按照下列最佳做法管理機構群組。
從單一事實來源佈建
由於機構群組是以人力資源資料為依據，因此最好只從人力資源資訊系統或外部可靠來源 (例如外部身分識別提供者 (IdP) 或身分識別治理系統，如 Sailpoint、Okta 或 Entra ID) 佈建這些群組。
不允許修改群組
請勿手動在組織群組中新增或移除使用者，也不要讓使用者自行從組織群組中移除。
避免使用組織群組提供資源存取權
機構群組中的所有使用者很少需要相同層級的資源存取權。因此，授予機構群組存取權時，群組中部分成員的存取權可能會超出實際需求。
此外，根據外部 IdP 與 Cloud Identity 的同步頻率，外部 IdP 變更傳播至 Cloud Identity 時可能會延遲。這類延遲可能會導致超額權限擴散。舉例來說，即使現有群組包含不需要存取資源的使用者，資源擁有者也可能會授予現有群組存取權，而不是建立新群組。
如果必須使用機構群組提供存取權，請將機構群組新增為存取群組的成員，而非直接授予存取權，並只授予權限有限的角色，例如機構檢視者。否則，請使用存取權群組提供資源存取權。
禁止機構群組中的服務帳戶和外部使用者
請勿在機構群組中加入服務帳戶，因為服務帳戶不代表使用者。
外部使用者 (來自其他 Google Workspace 或 Cloud Identity 帳戶的使用者) 通常不屬於貴機構，因此沒有理由成為機構群組的成員。如果將外部工作者加入自己的 Google Workspace 或 Cloud Identity 帳戶，他們就會視為內部使用者，並可加入貴機構的群組。
使用 Cloud Identity 安全群組和群組限制強制執行這些規則。
管理協作群組
請按照下列最佳做法管理協作群組。
使用網路論壇企業版管理協作群組
如果您使用 Google Workspace，可以透過網路論壇企業版管理協作群組。使用者可透過 Google 網路論壇建立、瀏覽及加入群組。您必須設定網路論壇企業版，才能讓使用者建立新的協作群組。
停用網路論壇企業版 (如果未使用)
如果您使用 Cloud Identity 但沒有 Google Workspace，Cloud Identity 中就不需要任何協作群組，因此最好停用網路論壇企業版，防止使用者在 Cloud Identity 中建立群組。
強制為協作群組加上後置字串
如果您使用網路論壇企業版，請設定強制執行後置字串。如果您允許所有人建立新的網路論壇企業版群組，這點就特別重要。
強制執行後置字串可防止使用者建立群組時，刻意與即將從外部來源佈建的存取權群組或機構群組發生名稱衝突。在這種情況下，錯誤命名的協作群組建立者可能會提高自己的權限。
請勿使用協作群組控管存取權
協作群組的存取控管較為寬鬆，通常不會遵循明確的生命週期。因此很適合協作，但不適合存取控管。
如果您嚴格遵守協作群組的命名慣例，可以建立自訂組織政策限制，防止協作群組獲得 IAM 角色。同樣地，如果您在外部佈建及管理協作群組，請勿將這些群組佈建至 Cloud Identity，以免遭人濫用來控管存取權。
管理存取權群組
請按照下列最佳做法管理存取群組。
選取合適的工具來管理存取群組
由於存取權群組是由工作負載擁有者管理，因此請使用適合自助式服務的工具。工具應允許使用者尋找現有的存取群組，並強制執行安全防護措施，套用下列控管措施：
- 哪些機構群組的成員有資格加入存取權群組
使用者必須符合哪些條件才能加入群組
舉例來說，使用者是否需要提供理由？
群組成員資格的生命週期上限
是否需要核准成員資格，以及核准者
支援稽核追蹤記錄
JIT 群組就是符合這些需求的工具。
使用存取權群組建立職務模型，並授予資源存取權
為每個職務建立存取權群組，並授予該群組存取權，讓該職務的使用者能存取所有必要資源。接著，您可以將該職務的使用者新增至群組，授予他們所需存取權，不必為每位使用者指派相同角色。
您可以使用單一存取群組，提供多項資源的存取權，甚至是多個專案的存取權。不過，請務必確認每位群組成員都需要您授予群組的存取權。如果部分使用者不需要額外存取權，請建立新的存取群組，並將額外存取權授予該群組。
為特定工作負載使用存取群組
為多個工作負載重複使用存取群組，會導致權限過多和管理複雜。
為工作負載擁有者建立存取群組，消除相關障礙
為減少重複使用現有存取權群組的誘因，請讓存取權群組的建立和維護作業簡單明瞭。工作負載擁有者應能以自助服務方式建立存取群組，並支援適當的命名方式。
讓使用者尋找及加入存取權群組
如果使用者可以探索現有的存取群組，並加入所需的群組，就不太可能累積不需要的權限。如有需要，你可以使用邀請或核准程序，控管可加入群組的使用者。
預設讓會員方案自動到期
要求使用者在一段時間後重新加入存取權群組或延長會員資格。這項做法會刻意增加成為存取群組成員的難度，並鼓勵使用者讓不需要的成員資格失效。這項最佳做法對於達成「零常駐權限」(ZSP) 的目標至關重要，對外部使用者來說更是如此。
不過，請勿將這項規則套用至服務帳戶，因為從存取群組移除服務帳戶可能會導致服務中斷。
為每個群組指派擁有者
每個存取權群組都應有一或多位指定擁有者。這有助於培養群組成員的責任感。擁有者可以是與群組相關聯工作負載的同一人或團隊。
限制存取權群組的瀏覽權限
不要在群組目錄中顯示存取權群組。(他們應該會在存取權群組管理工具中顯示。)此外，請只允許群組成員查看其他成員。這些做法可防止惡意人士取得寶貴資訊。
限制外部成員
由於網域限制共用 (DRS) 政策限制適用於群組，但不適用於群組成員，因此允許外部成員的存取群組可能會建立漏洞，破壞 DRS。
使用 Cloud Identity 安全性群組和群組限制，允許或禁止外部成員加入存取權群組。此外，建議您為允許外部成員加入的存取權群組，採用特殊命名慣例，例如 external.access.GROUP_NAME@example.com。
管理違規處置群組
請按照下列最佳做法管理違規處置群組。
選取合適的工具來管理違規處置群組
由於強制執行群組的成員資格是根據機構規則而定，且用於套用安全性限制，因此請勿允許成員選擇退出或自行從強制執行群組中移除。
使用動態群組，即可自動佈建強制執行群組。如果您使用外部 IdP，請使用 IdP 提供的動態群組，然後將這些群組佈建至 Cloud Identity。請注意，使用外部 IdP 可能會導致政策更新延遲。
如果無法使用動態群組，建議使用 Terraform 或其他基礎架構即程式碼 (IaC) 工具佈建強制執行群組。如果您使用 IaC 建立強制執行群組，請確保您不會為管道提供不必要的廣泛存取權。
使用強制執行群組，強制執行存取控管和驗證控管
使用強制執行群組來強制執行強制存取控管。Google Cloud 支援強制存取控管，並提供多種服務和工具，包括：
強制執行群組也可用於套用驗證控制項，例如 SAML 設定檔指派或兩步驟驗證 (2SV)。
由於這些控制項都會限制功能或移除存取權，因此強制執行群組是正確的選擇。
禁止使用者退出強制執行群組
允許使用者離開強制執行群組，違反了強制存取控制原則。如要禁止使用者退出群組，請使用 Groups Settings API 將 whoCanLeaveGroup 屬性設為 NONE_CAN_LEAVE。
外部 IdP 的最佳做法
如果您使用外部 IdP 進行驗證，也可以使用該 IdP 佈建機構群組和強制執行群組。
避免使用外部來源做為存取群組
您可以在外部 IdP 中管理存取群組，並將這些群組佈建至 Cloud Identity，但這種做法有幾個缺點：
佈建延遲
外部 IdP 所做的變更，最多可能需要數小時才會反映在存取群組中。
可能出現差異
部分 IdP 不會對群組進行授權控制。舉例來說，外部刪除群組後，他們可能不會在 Cloud Identity 中刪除群組，或是主動刪除 Cloud Identity 中存在但 IdP 中沒有的群組成員。
如果出現差異，使用者可能會保留不需要的存取權，並取得存取權擁有者的錯誤資訊。這也可能增加建立存取群組的難度。
為避免這些問題，請使用外部 IdP 僅佈建機構和強制執行群組，並使用 JIT 群組等工具直接在 Cloud Identity 中管理存取群組。
如果依名稱對應群組，請使用次要網域
Cloud Identity 會依據電子郵件地址識別群組，但外部 IdP 中的群組可能沒有電子郵件地址。
許多 IdP 允許您從群組名稱衍生虛擬電子郵件地址，例如使用 my-group@example.com，藉此解決這個問題。這樣做雖然可行，但如果其他群組或使用者已使用這個電子郵件地址，可能會導致衝突。在最糟的情況下，惡意行為人可能會利用這個命名衝突，建立偽裝成其他較少受到審查的群組類型的安全群組。
為避免發生衝突，請為從外部來源佈建的群組使用專屬的次要網域，例如 groups.example.com。
避免將群組管理員角色授予部署管道
如果您使用 IaC 管理群組 (例如 Terraform)，部署管道必須具備完成工作所需的權限。「群組管理員」角色授權建立群組，但擁有該角色的任何主體，也能管理 Cloud Identity 帳戶中的所有群組。
如要限制管道的存取權，請建立只有一項權限 (建立群組的權限) 的服務帳戶，然後將管道設為其建立的所有群組擁有者。這樣一來，該管道就能管理自己建立的任何群組，以及建立更多群組，但無權管理自己未建立的群組。
以下步驟說明這個做法：
建立自訂管理員角色，並只授予 Admin API 群組建立權限。
為這個角色取個好記易懂的名稱，例如「群組建立者」。
建立服務帳戶，並指派「群組建立者」角色。
使用管道的服務帳戶，並在建立群組時傳遞
WITH_INITIAL_OWNER旗標。
使用 Cloud Logging 稽核及監控群組。
記錄功能可讓您收集、監控及分析群組活動。
稽核會員變更
新增或移除機構群組、存取群組或強制執行群組的成員，可能會影響成員可存取的資源，因此請務必保留稽核追蹤記錄，追蹤這些變更。
要求提供加入存取群組的事由
如要讓監控資料更有用，請要求使用者在加入群組或要求加入群組時提供理由，並記錄這些理由。如果需要經過核准程序，請記錄核准要求者的詳細資料。
這項額外中繼資料日後可協助您分析使用者加入群組的原因，以及他們獲得特定資源存取權的原因。
啟用 Cloud Identity 稽核記錄共用功能
設定 Cloud Identity 將記錄檔傳送至 Cloud Logging，以便您以處理其他 Google Cloud 記錄檔的方式處理這些稽核記錄檔，包括設定快訊或使用外部安全性資訊和事件管理 (SIEM) 系統。