瞭解允許政策

您可以透過 Google Cloud 允許政策 (又稱 Identity and Access Management (IAM) 政策) 授予資源的存取權，這些政策會附加至資源。每個資源只能附加一項允許政策。 允許政策會控管資源本身的存取權，以及繼承允許政策的任何資源後代。

這個頁面會以 JSON 格式顯示允許政策。您也可以使用 Google Cloud CLI，以 YAML 格式擷取允許政策。

政策結構

允許政策是一組角色繫結和中繼資料。角色繫結會指定應授予資源的存取權。將一或多個主體與單一 IAM 角色和任何特定環境的條件建立關聯或繫結，這些條件會變更角色授予方式和時間。中繼資料包含允許政策的其他資訊，例如 etag 和版本，方便管理政策。

每個角色繫結可包含下列欄位：

  • 一或多個主體，也稱為成員或身分。主體類型有很多種，包括單一使用者、使用者群組和服務帳戶。如需支援的主體類型完整清單，請參閱「主體類型」。
  • 「角色」：一組已命名的權限，可讓您對 Google Cloud資源執行動作。

  • 條件：選用的邏輯運算式，可根據要求屬性 (例如來源或目標資源) 進一步限制角色繫結。條件通常用於根據要求的內容，控管是否授予存取權。

    如果角色繫結包含條件，則稱為條件式角色繫結。

    部分 Google Cloud 服務不接受允許政策中的條件。 如要查看可接受條件的服務和資源類型清單，請參閱可接受條件式角色綁定的資源類型。

主體存取權的變更具有最終一致性。也就是說，存取權變更需要一段時間才會全面套用到系統。如要瞭解存取權變更平均需要多久才能生效，請參閱「存取權變更傳播」一文。

所有主體的限制

每項允許政策最多可包含 1,500 個主體。 為計算這項限制，身分與存取權管理會計算允許政策角色繫結中，每位主體的「所有」出現次數，以及允許政策「免除資料存取稽核記錄」的主體。但「不會」捨棄相同主體在不同角色繫結中重複出現的次數。舉例來說，假設允許政策只包含主體 user:my-user@example.com 的角色繫結，而這個主體出現在 50 個角色繫結中，那麼您可以在允許政策的角色繫結中再新增 1,450 個主體。

此外，就這項限制而言，無論網域或 Google 群組中有多少個別成員，每個網域或群組都會計為一個主體。

如果您使用 IAM 條件，或是授予許多主體角色，且這些主體的 ID 異常長，則 IAM 可能會在允許政策中允許較少主體。

群組和網域的限制

在允許政策中，最多可有 250 個主體是 Google 群組、Cloud Identity 網域或 Google Workspace 帳戶。

為計算這項限制，Cloud Identity 網域、Google Workspace 帳戶和 Google 群組的計數方式如下：

  • 如果是 Google 群組，無論群組在允許政策中出現幾次，每個不重複的群組只會計入一次。這與允許政策中主體總數的限制不同，後者會將群組的每次出現計入限制。
  • 如果是 Cloud Identity 網域或 Google Workspace 帳戶，IAM 會計算允許政策的角色繫結中，每個網域或帳戶出現的「所有」次數。但「不會」捨棄相同網域或帳戶在不同角色繫結中重複出現的次數。

舉例來說，如果允許政策只包含一個群組 (group:my-group@example.com)，且該群組在允許政策中出現 10 次，您最多可以再新增 249 個 Cloud Identity 網域、Google Workspace 帳戶或不重複群組，才會達到上限。

或者，如果允許政策只包含一個網域 (domain:example.com)，且該網域在允許政策中出現 10 次，您最多可以再新增 240 個 Cloud Identity 網域、Google Workspace 帳戶或不重複群組，才會達到上限。

政策中繼資料

允許政策的中繼資料包含下列欄位：

  • etag 欄位，用於並行控制，確保允許政策一致更新。詳情請參閱本頁面的「在政策中使用 etag」。
  • version 欄位，指定特定允許政策的結構定義版本。詳情請參閱本頁的「政策版本」一節。

對於機構、資料夾、專案和帳單帳戶，允許政策也可以包含 auditConfig 欄位，指定會為各項服務產生稽核記錄的活動類型。如要瞭解如何設定允許政策的這部分，請參閱「設定資料存取稽核記錄」。

在政策中使用 etag

如果多個系統嘗試同時寫入相同的允許政策，這些系統可能會覆寫彼此的變更。這是因為允許政策是使用讀取 - 修改 - 寫入模式更新，其中涉及多項作業：

  1. 讀取現有的允許政策
  2. 修改允許政策
  3. 撰寫完整的允許政策

如果系統 A 讀取允許政策，而系統 B 立即寫入該允許政策的更新版本，則系統 A 不會知道系統 B 的變更。當系統 A 將自己的變更寫入允許政策時，系統 B 的變更可能會遺失。

為避免發生這個問題，Identity and Access Management (IAM) 支援透過允許政策中的 etag 欄位控管並行作業。每個允許政策都包含 etag 欄位，且每次更新允許政策時，這個欄位的值都會變更。如果允許政策包含 etag 欄位，但沒有任何角色繫結，則允許政策不會授予任何 IAM 角色。

etag 欄位包含 BwUjMhCsNvY= 等值。更新允許政策時，請務必在更新後的允許政策中加入 etag 欄位。如果擷取允許政策後，政策有所變更，etag 值就不會相符，更新也會失敗。如果是 REST API，您會收到 HTTP 狀態碼 409 Conflict，且回應主體類似於下列內容：

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

如果收到這項錯誤，請重試整套作業：再次讀取允許政策、視需要修改，然後寫入更新後的允許政策。您應在用於管理允許政策的任何工具中，自動重試，並採用指數輪詢策略。

範例：簡單政策

請參考下列允許政策，將主體繫結至角色：

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

在上例中，系統會無條件授予 Jie Owner 基本角色。這個角色幾乎授予 Jie 無限制的存取權。

範例：具有多個角色繫結的政策

請參考下列允許政策，其中包含多個角色繫結。 每個角色繫結都會授予不同的角色：

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:raha@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

在上述範例中，第一個角色繫結會授予 Jie 機構管理員預先定義角色 (roles/resourcemanager.organizationAdmin)。這個角色包含機構、資料夾和有限專案作業的權限。在第二個角色繫結中，Jie 和 Raha 都透過專案建立者角色 (roles/resourcemanager.projectCreator) 獲得專案建立權。這些角色繫結共同授予 Jie 和 Raha 細微的存取權，且 Jie 獲得的存取權比 Raha 多。

範例：含有條件式角色繫結的政策

請參考下列允許政策，該政策會將主體繫結至預先定義的角色，並使用條件運算式限制角色繫結：

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

在本例中，version 欄位設為 3，因為允許政策包含條件運算式。允許政策中的角色繫結是有條件的，會將角色授予 prod-dev 群組和服務帳戶 prod-dev-example@appspot.gserviceaccount.com，但只到 2022 年 7 月 1 日為止。

如要瞭解各個允許政策版本支援的功能，請參閱這個頁面的「政策版本」一節。

範例：具有條件式和無條件角色繫結的政策

請參考下列允許政策，其中包含同一個角色的條件和無條件角色繫結：

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

在本範例中，服務帳戶 serviceAccount:prod-dev-example@appspot.gserviceaccount.com 包含在相同角色的兩個角色繫結中。第一個角色繫結沒有條件。第二個角色繫結設有條件，只授予角色到 2022 年 7 月 1 日。

實際上，這項允許政策一律會將角色授予服務帳戶。在 IAM 中，條件式角色繫結不會覆寫沒有條件的角色繫結。如果主體繫結至角色，且角色繫結沒有條件，則主體一律具有該角色。將主體新增至相同角色的條件角色繫結，不會有任何效果。

相較之下，prod-dev 群組只會納入條件式角色繫結。因此，該使用者只會在 2022 年 7 月 1 日前擁有該角色。

範例：將角色繫結至已刪除主體的政策

請參考下列允許政策。這項允許政策會將角色繫結至已刪除的服務帳戶 serviceAccount:my-service-account@my-project.iam.gserviceaccount.com。因此，服務帳戶的 ID 現在會加上 deleted: 前置字串：

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

如果您建立同名的新服務帳戶，允許政策中已刪除服務帳戶的角色繫結，就不會套用至新服務帳戶。這項行為適用於所有類型的已刪除主體。

這樣一來，新主體就不會繼承已刪除主體獲得的角色。如要將角色授予新主體，請將新主體新增至允許政策的角色繫結，如本頁的「已刪除主體的政策」所示。

所有已刪除的主體都會加上 deleted: 前置字元。部分已刪除主體類型 (例如服務帳戶) 也會加上 ?uid=numeric-id 後置字串，其中 numeric-id 是已刪除主體的唯一數字 ID。在本例中，允許政策會顯示 deleted:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com?uid=123456789012345678901 識別碼，而非 serviceAccount:serviceAccount:my-service-account@my-project.iam.gserviceaccount.com。

預設政策

所有接受允許政策的資源都會使用預設允許政策建立。大多數資源的預設允許政策都是空白。 不過，部分資源的預設允許政策會自動包含特定角色繫結。舉例來說，當您建立新專案時，專案的允許政策會自動建立角色繫結，授予您專案的擁有者角色 (roles/owner)。

這些角色繫結是由系統建立，因此使用者不需要資源的 getIamPolicy 或 setIamPolicy 權限，即可建立角色繫結。

如要瞭解資源是否是透過允許政策建立，請參閱資源的說明文件。

政策繼承和資源階層

Google Cloud 資源有階層分明的組織架構，以機構節點做為階層的根節點，然後是資料夾 (選用)，最後是專案。大多數其他資源都是在專案下建立及管理。 除了機構之外，每項資源都只有一個父項。機構是階層結構中的根節點，因此沒有父項。詳情請參閱「資源階層」主題。

設定允許政策時，請務必考量資源階層。在階層中較高的層級 (例如機構、資料夾或專案層級) 設定允許政策時，授予的存取權範圍包括附加這項允許政策的資源層級，以及該層級下的所有資源。舉例來說，在機構層級設定的允許政策會套用至機構和機構下的所有資源。同樣地，在專案層級設定的允許政策會套用至專案和專案中的所有資源。

政策繼承是指允許政策如何套用至資源階層中該層級以下的資源。「有效政策」是指資源在資源階層中，如何沿用所有父項允許政策。這是下列項目的聯集：

  • 資源上設定的允許政策
  • 在階層中，針對資源的所有祖先資源層級設定的允許政策

系統會分別評估每個影響資源有效允許政策的新角色繫結 (從父項資源繼承)。如果任何較高層級的角色繫結授予要求存取權，系統就會授予資源的特定存取要求。

如果資源的任何層級導入新的角色繫結，資源的繼承許可政策就會擴大存取權授予範圍。

範例：政策繼承

如要瞭解允許政策的繼承行為，請考量以下情境：您在資源階層的兩個不同層級，將兩個不同的 IAM 角色授予使用者 Raha。

如要授予 Raha 機構層級角色，請在機構中設定下列允許政策：

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

這項允許政策會授予 Raha「Storage 物件檢視者」角色 (roles/storage.objectViewer)，其中包含專案和 Cloud Storage 物件的 get 和 list 權限。由於您在機構中設定了允許政策，Raha 可以對機構中的所有專案和 Cloud Storage 物件使用這些權限。

如要在專案層級授予 Raha 角色，請在專案 myproject-123 中設定下列允許政策：

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

這項允許政策會授予 Raha「Storage 物件建立者」角色 (roles/storage.objectCreator)，讓她建立 Cloud Storage 物件。由於您在 myproject-123 上設定了允許政策，Raha 只能在 myproject-123 中建立 Cloud Storage 物件。

現在有兩個角色繫結授予 Raha 存取 myproject-123 下目標 Cloud Storage 物件的權限，因此適用下列允許政策：

  • 組織層級的允許政策會授予列出及取得此組織下所有 Cloud Storage 物件的權限。
  • 專案 myproject-123 層級的允許政策會授予在該專案中建立物件的權限。

下表摘要說明 Raha 的有效政策：

機構的 Storage 物件檢視者角色權限 `myproject-123` 的 Storage 物件建立者角色權限 Raha 在 `myproject-123` 上的有效權限
resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
 resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.create
 resourcemanager.projects.get
resourcemanager.projects.list
storage.objects.get
storage.objects.list
storage.objects.create

政策版本

隨著時間推移，身分與存取權管理服務可能會新增功能，大幅新增或變更允許政策架構中的欄位。為避免中斷現有整合項目 (這些項目依賴允許政策結構的一致性)，我們會在新的允許政策結構定義版本中導入這類變更。

如果您是第一次整合 IAM，建議使用當時可用的最新允許政策結構定義版本。下一節將討論可用的不同版本，以及如何使用各版本。同時也會說明如何指定政策版本，並討論一些疑難排解情境。

每個現有的允許政策都會指定 version 欄位，做為允許政策中繼資料的一部分。請參考以下範例中醒目顯示的部分：

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

這個欄位會指定允許政策的語法結構定義版本。每個允許政策版本都包含特定語法結構定義，可供角色繫結使用。新版可能包含採用新版語法結構定義的角色繫結，而舊版不支援這類繫結。這個欄位僅用於控管允許政策的語法結構定義，不得用於其他用途。

有效政策版本

允許政策可使用下列允許政策版本：

版本 說明
1 政策適用的 IAM 語法結構定義第一個版本。支援將一個角色繫結至一或多個主體。不支援條件式角色繫結。
2 保留供內部使用。
3 介紹角色繫結中的 condition 欄位，該欄位會使用以內容和屬性為依據的規則，限制角色繫結。詳情請參閱 IAM 條件總覽。

在取得政策時指定政策版本

對於 REST API 和用戶端程式庫，當您取得允許政策時，建議在要求中指定允許政策版本。如果要求指定允許政策版本，IAM 會假設呼叫端瞭解該允許政策版本中的功能，並能正確處理這些功能。

如果要求未指定允許政策版本，IAM 會假設呼叫端需要 1 版允許政策。

取得允許政策時，IAM 會檢查要求中的允許政策版本，如果要求未指定版本，則會檢查預設版本。IAM 也會檢查允許政策中不支援的欄位 (適用於 1 允許政策)。系統會根據這項資訊決定要傳送的回覆類型：

  • 如果允許政策不含任何條件，無論要求中的版本號碼為何，IAM 一律會傳回版本 1 允許政策。
  • 如果允許政策包含條件，且呼叫端要求允許政策版本 3，則 IAM 會傳回包含條件的允許政策版本 3。如需範例，請參閱本頁的情境 1。

  • 如果允許政策包含條件，且呼叫端要求版本 1 的允許政策，或未指定版本，則 IAM 會傳回版本 1 的允許政策。

    如果角色繫結包含條件，IAM 會在角色名稱後方附加字串 _withcond_，然後加上雜湊值，例如 roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8。條件本身不存在。如需範例，請參閱本頁的情境 2。

情境 1：完全支援 IAM 條件的政策版本

假設您呼叫下列 REST API 方法，取得專案的允許政策：

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

要求主體包含下列文字：

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

回應會包含專案的允許政策。如果允許政策包含至少一個有條件的角色繫結，則其 version 欄位會設為 3：

{
  "bindings": [
    {
      "members": [
        "user:tal@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

如果允許政策不含條件式角色繫結，即使要求指定版本 3，其 version 欄位也會設為 1：

{
  "bindings": [
    {
      "members": [
        "user:tal@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

情境 2：政策版本僅支援部分 IAM 條件

假設您呼叫下列 REST API 方法，取得專案的允許政策：

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

要求主體為空白，未指定版本號碼。因此，IAM 會使用預設允許政策版本 1。

允許政策包含條件角色繫結。由於允許政策版本為 1，因此回應中不會顯示條件。如要指出角色繫結使用條件，IAM 會在角色名稱後方附加 _withcond_ 字串，然後是雜湊值：

{
  "bindings": [
    {
      "members": [
        "user:tal@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

設定政策時指定政策版本

設定允許政策時，建議您在要求中指定允許政策版本。如果要求指定允許政策版本，IAM 會假設呼叫端瞭解該允許政策版本中的功能，並能正確處理這些功能。

如果要求未指定允許政策版本，IAM 只會接受可出現在 1 允許政策版本中的欄位。最佳做法是不要在版本 1 允許政策中變更條件式角色繫結，因為允許政策不會顯示每個角色繫結的條件，您無法得知角色繫結實際授予的時間或位置。請改為取得允許政策的 3 版本表示法，其中會顯示每個角色繫結的條件，並使用該表示法更新角色繫結。

情境：要求和回應中的政策版本

假設您使用 REST API 取得允許政策，並在要求中指定版本 3。回應包含下列允許政策，其中使用版本 3：

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

您決定讓 Raha 擔任儲存空間管理員角色 (roles/storage.admin)，不只是在平日，而是整週都擔任這個角色。從角色繫結中移除條件，然後傳送 REST API 要求來設定允許政策。同樣地，您會在要求中指定版本 3：

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

回覆包含更新後的允許政策：

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

即使要求指定版本 3，回應中的允許政策仍會使用版本 1，因為允許政策只會使用版本 1 允許政策支援的欄位。

已刪除主體的政策

如果允許政策中的角色繫結包含已刪除的主體，且您為同名的新主體新增角色繫結，角色繫結一律會套用至新主體。

舉例來說，假設這項允許政策包含已刪除服務帳戶 (my-service-account@project-id.iam.gserviceaccount.com) 的角色繫結。因此，每個服務帳戶的 ID 都會加上 deleted: 前置字元：

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

假設您建立的新服務帳戶也命名為 my-service-account@project-id.iam.gserviceaccount.com，並想授予專案建立者角色 (roles/resourcemanager.projectCreator)。如要將角色授予新服務帳戶，請更新允許政策，如下列範例所示：

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "serviceAccount:my-service-account@project-id.iam.gserviceaccount.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

為方便稽核 IAM 允許政策，您也可以從「擁有者」角色的角色繫結中移除已刪除的使用者：

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

政策最佳做法

如果機構有大量使用者，請參考下列最佳做法： Google Cloud

  • 如要管理多個具有相同存取權設定的主體，請改用群組。將每個主體放入群組，並將預期角色授予群組，而非個別使用者帳戶主體。

  • 在機構層級授予的角色：請仔細考慮要在機構層級授予哪些主體角色。對大多數機構而言，只有少數特定團隊 (例如安全和網路團隊) 應獲准存取這個層級的資源階層。

  • 在資料夾層級授予角色：考慮使用資料夾層級來反映貴機構的營運架構，每個資料夾可設定不同的存取權授予組合，以符合業務和營運需求。舉例來說，父項資料夾可能代表某個部門，其中一個子項資料夾可能代表某個群組的資源存取權和作業，另一個子項資料夾則可能代表某個小型團隊。這兩個資料夾可能都包含團隊運作所需的專案。以這種方式使用資料夾，可確保適當的存取權分離，同時遵守從父項資料夾和機構繼承的允許政策。建立及管理資源時，這項做法可減少許可政策的維護作業。 Google Cloud

  • 在專案層級授予角色：必要時，請在專案層級授予角色繫結，以遵循最低權限原則。舉例來說，如果主體需要存取資料夾中的 10 個專案，您應分別授予這 3 個專案的存取權；反之，如果您在資料夾中授予角色，主體將獲得另外 7 個專案的存取權，但他們並不需要這些存取權。

    或者，您也可以使用 IAM 條件，在機構或資料夾層級授予角色，但僅限於部分資料夾或專案。

  • 僅授予網域內的主體存取權：為提升貴機構的安全性，請勿將角色授予網域外的主體。您可以強制執行iam.allowedPolicyMemberDomains機構政策限制，落實這項最佳做法。

後續步驟