拒絕政策

身分與存取權管理 (IAM) 拒絕政策可讓您設定Google Cloud 資源存取權的防護措施。您可以透過拒絕政策定義拒絕規則，防止特定主體使用特定權限，無論主體具備何種角色均適用。

本頁提供拒絕政策和拒絕規則的總覽。如要瞭解如何建立及更新拒絕政策，請參閱「拒絕存取資源」。

拒絕政策的運作方式

拒絕政策由拒絕規則組成。每項拒絕規則都會指定下列內容：

• 權限遭拒的一組主體
• 主體遭拒或無法使用的權限
• 選用：權限遭拒時必須為 true 的條件

如果主體遭到拒絕授權，無論獲派哪些 IAM 角色，都無法再進行與該權限相關的操作。這是因為 IAM 一律會先檢查相關的拒絕政策，再查看相關的允許政策。詳情請參閱政策評估。

如要指定拒絕政策的適用範圍，請將政策附加至專案、資料夾或機構。拒絕政策附加至其中一個資源後，政策中的主體就無法使用指定權限存取該資源或任何子系。如要進一步瞭解拒絕政策的附加位置，請參閱本頁面的「附加點」。

您可以將多項拒絕政策附加至單一資源。這樣一來，您就能為不同類型的拒絕規則建立個別的拒絕政策。舉例來說，您可以將與法規遵循相關的拒絕規則放在一個政策中，然後使用另一個政策處理其他拒絕規則。系統會分別評估各項拒絕政策。

每項資源最多可有 500 項拒絕政策。 這些拒絕政策合計最多可包含 500 條拒絕規則。

附件點

每項拒絕政策都會附加至機構、資料夾或專案。附加至其中一項資源後，該專案、資料夾或機構中的所有低層級資源都會沿用拒絕政策。如要使用拒絕政策，您需要拒絕政策所附加資源的 ID，也就是「附加點」。這個 ID 採用下表中的其中一種格式：

拒絕政策沿用

拒絕政策與允許政策一樣，都是沿用上層資源階層的設定。將拒絕政策附加至專案、資料夾或機構後，該政策也會對專案、資料夾或機構內的所有資源生效。

舉例來說，如果機構的拒絕政策規定主體不得使用特定權限，則主體無法在機構內的任何資源使用該權限。即使該機構內的資料夾和專案採用較寬鬆的拒絕政策，仍適用這項規則。

同樣地，如果專案的拒絕政策規定主體不得使用特定權限，則主體不得在專案中對任何資源使用該權限。即使上層機構和資料夾的拒絕政策較寬鬆，仍適用這項規則。

拒絕條件

拒絕條件會指定套用拒絕規則須符合哪些條件。如果條件評估結果為 true 或無法評估，系統會套用拒絕規則，主體就無法使用指定權限。如果條件評估結果為 false，拒絕規則就不會套用，主體只要具備指定權限，就能使用這些權限。

拒絕條件的結構與 IAM 條件相同。不過，拒絕條件只會辨識資源標記函式。

如要瞭解如何撰寫條件，請參閱 IAM 條件總覽。

權限群組

部分服務可讓您拒絕權限群組。權限群組是一組符合指定模式的權限。您可以使用權限群組拒絕相關權限組合，例如拒絕單一服務或資源的所有權限。

支援的權限群組列於「拒絕政策支援的權限」。支援的權限群組 ID 會以萬用字元 (*) 取代一或多個權限名稱部分。每個群組包含的權限取決於萬用字元的位置：

• SERVICE_FQDN/RESOURCE.*：拒絕指定資源的所有權限。
• SERVICE_FQDN/*.*：拒絕指定服務的所有權限。
• SERVICE_FQDN/*.VERB：拒絕以指定動詞結尾的服務的所有權限。

權限群組包含符合指定模式的所有現有和未來權限。舉例來說，假設您使用權限群組 example.googleapis.com/exampleResource.*，拒絕使用者對 exampleResource 資源類型擁有所有權限。如果 example.googleapis.com 為 exampleResource 資源類型新增權限 (例如 example.googleapis.com/exampleResource.newPermission)，系統會自動拒絕授予使用者這項新權限。

您只能在支援的權限群組中使用萬用字元。系統不支援在其他權限名稱中使用萬用字元。

拒絕政策的結構

拒絕政策是中繼資料和拒絕規則的集合。拒絕規則會將一組主體與一組權限建立關聯，這些主體遭拒或無法使用這些權限。每項規則也可以指定條件，決定何時拒絕授權。

舉例來說，下列拒絕政策會禁止所有主體刪除專案，但如果主體是 project-admins 群組的成員，或是要刪除的專案含有值為 test 的標記，則不在此限。

{
  "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
  "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
  "kind": "DenyPolicy",
  "displayName": "Only project admins can delete projects.",
  "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
  "createTime": "2021-09-07T23:15:35.258319Z",
  "updateTime": "2021-09-07T23:15:35.258319Z",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete",
          "cloudresourcemanager.googleapis.com/folders.*"
        ],
        "exceptionPermissions": [
          "cloudresourcemanager.googleapis.com/folders.list",
          "cloudresourcemanager.googelapis.com/folders.get"
        ],
        "denialCondition": {
          "title":  "Only for non-test projects",
          "expression": "!resource.matchTag('12345678/env', 'test')"
        }
      }
    }
  ]
}

以下各節說明拒絕政策中繼資料和拒絕規則的欄位。

中繼資料

拒絕政策包含下列中繼資料：

• name：拒絕政策的名稱。這個名稱的格式為「policies/ATTACHMENT_POINT/denypolicies/POLICY_ID」，其中 ATTACHMENT_POINT 是拒絕政策所附加的專案、資料夾或機構，而 POLICY_ID 是拒絕政策的英數字元 ID。
• uid：Google 指派給拒絕政策的專屬 ID。
• kind：政策類型。拒絕政策的 kind 一律為 DenyPolicy。
• displayName：選用。使用者可解讀的拒絕政策名稱。
• etag：政策版本的 ID。為避免更新衝突，etag 值必須與 IAM 中儲存的值相符。如果 etag 值不相符，要求就會失敗。
• createTime：拒絕政策的建立時間。
• updateTime：上次更新拒絕政策的時間。

拒絕規則

每項拒絕規則可包含下列欄位：

• deniedPrincipals：遭拒絕權限的主體。您可以列出個別主體和主體集。個別主體類型包括使用者帳戶、服務帳戶，以及員工或工作負載身分集區中的單一身分。主體集包括 Google 群組、Cloud Identity 網域、工作團隊或工作負載身分集，以及網路上所有使用者。

  如需有效主體類型和 ID 的清單，請參閱「拒絕政策的主體 ID」。

• exceptionPrincipals：選用。不受拒絕規則限制的主體。即使這些主體列於 deniedPrincipals 中，或屬於 deniedPrincipals 中列出的群組，也不會遭到拒絕指定權限。

  您可以列出個別主體和主體集。個別主體類型包括使用者帳戶、服務帳戶，以及工作團隊或工作負載身分集區中的單一身分。主體集包括 Google 群組、Cloud Identity 網域、員工或工作負載身分集，以及網路上所有使用者。

  如需有效主體類型和 ID 的清單，請參閱「拒絕政策的主體 ID」。

• deniedPermissions：指定主體無法使用或遭拒的權限。這些權限使用 IAM v2 權限格式，並以完整網域名稱 (FQDN) 識別服務。格式為 SERVICE_FQDN/RESOURCE.ACTION。Google API 使用 *.googleapis.com 網域。例如：iam.googleapis.com/roles.delete。

  只有部分權限可以拒絕。如需可拒絕的權限完整清單，請參閱「拒絕政策支援的權限」。

  在某些情況下，您也可以使用權限群組拒絕一組權限。詳情請參閱「權限群組」。

• exceptionPermissions：選用。指定主體可使用的權限清單，即使這些權限包含在 deniedPermissions 中也一樣。舉例來說，您可以使用這個欄位，為權限群組中的特定權限設定例外狀況。

• denialConditions：選用。影響拒絕規則適用時間的邏輯運算式。如果條件評估結果為 true 或無法評估，系統會拒絕授權。如果條件評估結果為 false，系統不會拒絕授權。詳情請參閱本頁的「拒絕條件」。

常見用途

以下列舉幾種常見情況，您可能會想使用拒絕政策，以及在每種情況下可能建立的拒絕規則範例。如要瞭解如何建立及更新拒絕政策，請參閱「拒絕存取資源」。

集中管理員權限

您可以使用拒絕政策，將特定類型的管理活動限制在特定主體範圍內。

舉例來說，假設您想將機構的自訂角色管理權限，限制在單一中央團隊。如要這麼做，請建立拒絕規則，拒絕所有使用者 (管理群組中的使用者除外) 進行自訂角色管理所需的權限 (custom-role-admins)：

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/custom-role-admins@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

接著，將拒絕政策附加至機構。

現在只有 custom-role-admins 群組的成員可以管理自訂角色，即使其他使用者具備必要權限也一樣。

舉例來說，假設 Yuri 和 Tal 都具備機構管理員角色 (roles/iam.organizationRoleAdmin)，但 Yuri 是 custom-role-admins 的成員，Tal 則不是。有了這項拒絕政策，只有 Yuri 可以建立、刪除及更新角色。

建立授予存取權的例外狀況

您可以使用拒絕政策拒絕繼承的權限。這項功能可讓您在資源階層的較高層級授予角色，然後視需要拒絕個別較低層級資源的角色權限。

舉例來說，假設您有一個名為 Engineering 的資料夾，其中包含多個專案。您想在資料夾中幾乎所有專案的服務帳戶金鑰管理員角色 (roles/iam.serviceAccountKeyAdmin) 中，授予群組「eng」權限。不過，您不希望群組在資料夾中的特定專案 example-prod 內，獲得建立及刪除服務帳戶金鑰的權限。

您不需要在每個專案中授予服務帳戶金鑰管理員角色，只要建立下列拒絕規則，即可拒絕 eng 群組中的主體在服務帳戶金鑰管理員角色中建立及刪除權限：

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

接著，將這項拒絕規則新增至拒絕政策，並將政策附加至專案 example-prod。

將拒絕政策附加至專案後，您可以在 Engineering 資料夾中將服務帳戶金鑰管理員角色授予 eng 群組，但禁止該群組在 example-prod 中建立或刪除服務帳戶金鑰。

eng 群組的成員現在可以在 example-prod 以外的所有專案中建立及刪除服務帳戶金鑰。舉例來說，如果 Izumi 是 eng 群組的成員，他可以為 example-dev 和 example-test 中的服務帳戶建立及刪除金鑰，但無法為 example-prod 中的服務帳戶執行這類操作。

不過，假設您實際上希望 eng 群組的子集能夠在 example-prod 中建立及刪除服務帳戶金鑰。這個子集以群組 eng-prod 表示。如要允許群組成員在 example-prod 中建立及刪除服務帳戶金鑰，可以將該群組排除在拒絕規則之外：eng-prod

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/eng-prod@example.com"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

採用這項修訂後的拒絕政策後，eng-prod 群組的成員就能在所有專案 (包括 example-prod) 中建立及刪除服務帳戶金鑰。舉例來說，如果 Charlie 是 eng-prod 群組的成員，即使他也是 eng 群組的成員，仍可在 example-dev、example-test 和 example-prod 中建立及刪除金鑰。

根據標記封鎖存取權

標記是鍵/值組合，可附加至機構、資料夾或專案。您可以使用拒絕政策，根據標記拒絕權限，而不必為每個角色授權新增 IAM 條件。

舉例來說，假設您將所有專案標記為 dev、test 或 prod。您希望只有 project-admins 群組的成員可以刪除標記為 prod 的專案。

為解決這個問題，您建立拒絕規則，拒絕所有人的 cloudresourcemanager.googleapis.com/projects.delete 權限，但標記為 prod 的資源除外，project-admins 群組則不受影響：

{
  "displayName": "Only project admins can delete production projects.",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://goog/group/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "denialCondition": {
          "title":  "Only for prod projects",
          "expression": "resource.matchTag('12345678/env', 'prod')"
        }
      }
    }
  ]
}

接著，將這項拒絕規則新增至拒絕政策，並將政策附加至機構。

有了這項拒絕規則，您就能限制主體的存取權，不必為角色授權新增條件。您可以改為授予主體具備 cloudresourcemanager.googleapis.com/projects.delete 權限的角色，並依據拒絕規則，防止 project-admins 群組以外的主體刪除任何標記 prod 的專案。

舉例來說，假設有兩位使用者 Bola 和 Kiran。兩位使用者都具有專案刪除者角色 (roles/resourcemanager.projectDeleter)。此外，Kiran 是 project-admins 群組的成員。有了這項拒絕政策，Bola 只能刪除含有 dev 或 test 標記的專案。Kiran 可以刪除所有專案，無論專案標記為何。

後續步驟

• 瞭解如何建立、更新及刪除拒絕政策。
• 瞭解如何排解拒絕政策造成的存取問題。
• 查看可拒絕的權限。
• 請參閱主體類型，瞭解可納入拒絕政策的主體。