瞭解允許政策

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

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

政策結構

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

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

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

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

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

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

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

所有主體的限制

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

此外，就這項限制而言，無論主體集合中有多少個別成員，每個主體集合都會計為單一主體。

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

政策中繼資料

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

  • 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": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

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

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

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

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com",
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/prod-dev",
        "serviceAccount:prod-dev-example@appspot.s3ns-system.iam.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.s3ns-system.iam.gserviceaccount.com，但只到 2022 年 7 月 1 日為止。

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

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

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

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/prod-dev",
        "serviceAccount:prod-dev-example@appspot.s3ns-system.iam.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.s3ns-system.iam.gserviceaccount.com 包含在相同角色的兩個角色繫結中。第一個角色繫結沒有條件。第二個角色繫結設有條件，只授予角色到 2022 年 7 月 1 日。

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

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

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

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

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@my-project.s3ns-system.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.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901 識別碼，而非 serviceAccount:serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com。

預設政策

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

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

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

政策繼承和資源階層

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

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

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

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

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

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

範例：政策繼承

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

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

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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.s3nsapis.fr/v1/projects/project-id:getIamPolicy

要求主體包含下列文字：

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

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

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/tal@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

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

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

POST https://cloudresourcemanager.s3nsapis.fr/v1/projects/project-id:getIamPolicy

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

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

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/tal@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

設定政策時指定政策版本

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

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

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

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

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/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": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

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

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

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

已刪除主體的政策

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

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

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

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

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

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

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

政策最佳做法

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

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

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

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

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

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

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

後續步驟