主體存取邊界 (PAB) 政策可讓您定義主體可存取的資源。
其他存取權相關政策 (例如允許和拒絕政策) 會附加至資源。這些政策會定義哪些使用者可以存取所連結的資源。相較之下,主體存取邊界政策會附加至主體集,並控管主體集中的主體可執行的動作。
舉例來說,您可以使用主體存取邊界政策,禁止主體存取其他機構中的資源,以防範網路釣魚攻擊或資料竊取。
主體存取邊界政策的運作方式
根據預設,主體可以存取任何 Cloud de Confiance by S3NS 資源。也就是說,如果允許政策授予主體資源存取權,且沒有任何拒絕政策封鎖該存取權,主體就能存取資源。
您可以透過主體存取邊界政策,定義主體可存取的資源。如果主體無法存取資源,無論獲派哪些角色,都無法存取該資源。如要進一步瞭解如何使用主體存取邊界政策定義主體可存取的資源,請參閱「定義可存取的資源」。
主體存取邊界政策只會封鎖涉及支援權限的存取嘗試。如果主體存取邊界政策無法封鎖權限,主體就能使用該權限存取任何資源,不受所屬政策限制。詳情請參閱「主體存取邊界政策可封鎖的權限」。
用途
主體存取邊界政策適用於下列情況:
- 防止主體存取您不擁有的資源
- 將特定主體類型 (例如服務帳戶) 限制在特定專案中
如要查看在上述情況下使用主體存取邊界政策的詳細範例,請參閱「主體存取邊界政策的使用案例範例」。
主體存取邊界政策元件
主體存取邊界政策由個別規則組成。每項規則都會定義一組主體可存取的資源。每項政策最多可有 500 項規則。
政策也包含其他資訊,包括中繼資料和設定詳細資料。詳情請參閱「主體存取邊界政策結構」。
建立主體存取權範圍政策後,您可以建立政策繫結,將政策套用至主體組合。這些主體集中的所有主體隨後都會受到該主體存取邊界政策的約束,也就是說,他們有權存取政策中列出的資源。您可以將主體存取邊界政策繫結至任意數量的主要組合。
您最多可在機構中建立 1000 項主體存取邊界政策。
主體存取邊界政策封鎖的權限
主體存取邊界政策可以封鎖政策強制執行版本中包含的所有權限。如果主體存取邊界政策可以封鎖權限,就能防止不符合資格的主體使用該權限存取資源。
建立政策時,您需要指定政策的強制執行版本。更新強制執行版本會更新政策可封鎖的權限。如要查看各個強制執行版本封鎖的權限完整清單,請參閱強制執行版本參考資料。
如果主體存取邊界政策無法封鎖權限,則該政策不會影響主體是否能使用權限。換句話說,如果存取嘗試涉及該權限,IAM 就無法強制執行政策。
舉例來說,假設主體 Lee (lee@example.com) 獲派 Dataflow 開發人員角色 (roles/dataflow.developer)。這個角色包含 dataflow.googleapis.com/jobs.snapshot 權限,因此 Lee 可以為 Dataflow 工作建立快照。此外,Lee 也受到主體存取邊界政策限制,無法存取 example.com 以外的資源。不過,如果該主體存取權界線政策無法封鎖 dataflow.jobs.snapshot 權限,Lee 仍可擷取 example.com 以外機構的 Dataflow 工作快照。
管理違規處置版本
身分與存取權管理服務會定期新增強制執行版本,可封鎖其他權限。新版本也可以封鎖舊版本的所有權限。
如要在新的強制執行版本中封鎖權限,您必須更新主體存取邊界政策,才能使用新版本。
如要在新版本發布時自動更新政策的強制執行版本,您可以在建立政策時使用 latest 值。
不過,我們不建議使用這個值,因為這可能會導致主體意外失去資源存取權。
如果政策使用 latest 做為版本號碼,則會採用預設強制執行版本。預設強制執行版本通常是最新版本。
不過,新版本最多可能需要 4 週的時間,才會成為預設的強制執行版本。如要瞭解預設的強制執行版本,請參閱強制執行版本參考資料。
如果新的主體存取邊界政策未指定版本號碼,也會使用預設強制執行版本。
定義符合資格的資源
主體可能會受到任意數量的「主體存取權範圍」政策影響,或受其約束。這些政策會共同定義主體可存取的資源。
主體存取邊界政策是累加政策。也就是說,主體可存取的資源是主體適用的所有主體存取邊界政策中,所有資源的聯集。換句話說,如果單一主體存取邊界政策讓主體有權存取資源,那麼主體就有權存取資源,無論主體受其他主體存取邊界政策約束與否。
如果主體不受任何主體存取邊界政策限制,則可存取任何 Cloud de Confiance 資源。
以下各節說明如何自訂主體可存取的資源集。
新增符合資格的資源
如要讓主體有權存取原本無法存取的資源,可以採取下列幾種做法:
- 將資源新增至主體適用的主體存取邊界政策。
- 建立新的主體存取邊界政策,加入額外資源,然後將政策繫結至包含該主體的主體集。
- 移除或刪除主體適用的所有主體存取邊界政策。這項操作會讓主體有權存取「所有」 Cloud de Confiance 資源。
移除符合條件的資源
如果主體有權存取資源,您可以透過幾種方式取消這項權限。
首先,找出主體適用的所有主體存取邊界政策,包括資源。根據您找到的政策,您可以採取下列其中一項行動:
如果主體不受任何主體存取邊界政策限制,請建立新的主體存取邊界政策,只納入您希望主體可存取的資源。然後,將該政策繫結至含有主體的組合。
套用政策後,主體可存取的資源會從所有資源,變成政策中列出的資源。
如果主體已受一或多項主體存取邊界政策規範,請確保主體受規範的任何主體存取邊界政策都不包含該資源。如需逐步操作說明,請參閱減少主體可存取的資源。
在這個過程中,您必須確保主體一律受至少一項主體存取邊界政策約束。否則,主體可能會取得所有資源的存取權。
主體存取邊界政策和快取資源
部分 Cloud de Confiance by S3NS 服務會快取公開顯示的資源。舉例來說,Cloud Storage 會快取可公開讀取的物件。
主體存取邊界政策是否能禁止不符合資格的主體查看公開顯示的資源,取決於資源是否已快取:
- 如果資源已快取,主體存取邊界政策就無法禁止主體查看資源
- 如果資源未快取,主體存取邊界會禁止不符合資格的主體查看資源
在所有情況下,主體存取權範圍政策仍會禁止不符合資格的主體修改或刪除公開顯示的資源。
主體存取邊界政策評估
當主體嘗試存取資源時,IAM 會評估相關的主體存取邊界政策,判斷是否要封鎖存取嘗試。如果嘗試存取的主體適用於該政策,則該政策即為相關政策。
主體存取邊界政策只能封鎖或不封鎖存取權,無法授予存取權。只有允許政策才能實際授予主體資源存取權。如要瞭解不同政策類型對主體資源存取權的影響,請參閱「政策類型」。
如果符合下列任一條件,IAM 不會封鎖存取權:
- 主體不受任何主體存取邊界政策限制
- 相關主體存取邊界政策無法封鎖要求中的權限
- 主體存取邊界政策可讓主體存取資源
如果主體受至少一項主體存取邊界政策限制,但相關政策都未授予主體資源存取權,IAM 會封鎖存取權。
Fail-closed 評估
主體存取邊界政策會關閉失敗。也就是說,如果 IAM 在評估主體存取邊界政策時發生錯誤,IAM 會禁止主體存取資源。
IAM 在評估主體存取邊界政策時發生錯誤,最常見的原因是主體的詳細資料仍在系統中傳播。這類情況最有可能發生在剛建立的使用者身上。如要解決這個問題,請讓新主體稍候再試著存取資源。
將主體存取邊界政策套用至主體集
如要將主體存取邊界政策套用至主體集,請建立政策繫結,指定要套用的主體存取邊界政策,以及要套用政策的主體集。這項政策繫結會將政策繫結至主體組合。
將政策繫結至主體組合後,該主體組合中的主體只能存取主體存取邊界政策中列出的資源。
您可以將主體存取邊界政策繫結至任意數量的主要組合。每個主體組合最多可以繫結 10 項主體存取邊界政策。
您只能為現有的主體存取邊界政策建立繫結。嘗試為已刪除的主體存取邊界政策建立繫結時,系統會顯示錯誤訊息。如果您最近刪除了主體存取邊界政策,有時可以成功建立繫結,但繫結不會有任何作用。IAM 會自動清除這些繫結。
如要瞭解如何管理主體存取邊界政策,請參閱「建立及套用主體存取邊界政策」。
支援的主體組合
下表列出可繫結主體存取邊界政策的主體集類型。每個資料列包含下列項目:
- 主體組合類型
- 該類型主體集中的主體
- 該類型主體組合的 ID 格式
- Resource Manager 資源 (專案、資料夾或機構),會成為該類型主體組合的政策繫結上層
| 主體組合 | 詳細資料 | 政策繫結的父項資源 |
|---|---|---|
| 員工身分集區 |
包含指定工作團隊身分集區中的所有身分。
格式: |
包含工作團隊身分集區的機構 |
| Workload Identity 集區 |
包含指定工作負載身分集區中的所有身分。
格式: |
包含 workload identity pool 的專案 |
| Google Workspace 網域 |
包含指定 Google Workspace 網域中的所有身分。
格式: 您可以透過下列方法找出客戶 ID:
|
與 Google Workspace 網域相關聯的機構 |
| 專案主體組合 |
包含指定專案中的所有服務帳戶、工作負載身分集區和代理身分。
格式: |
專案 |
| 資料夾主體組合 |
包含指定資料夾中任何專案的所有服務帳戶、所有工作負載身分集區,以及所有代理程式身分。
格式: |
資料夾 |
| 機構主體組合 |
包含下列身分:
格式: |
機構簡介 |
| 代理身分 |
指定專案信任網域中的所有代理身分。根據預設,專案的信任網域包含專案中的所有代理身分。 格式:
|
專案 |
政策繼承和主體集
主體存取邊界政策會附加至主體組合,而非資源。因此,這些政策不會像允許和拒絕政策一樣,透過資源階層沿用上層設定。
不過,資料夾和機構的委託人集一律會包含後代委託人集中的所有委託人。舉例來說,如果專案的主體集包含某個主體,則任何上層資料夾或機構的主體集也會包含該主體。
舉例來說,假設某個機構是 example.com。這個機構與網域 example.com 相關聯,並擁有下列資源:
- 機構,
example.com - 專案「
project-1」(機構的子項) - 資料夾 (
folder-a),是機構的子項 - 兩個專案 (
project-2和project-3) 是folder-a的子項
這些資源的主體集包含下列身分:
| 主體組合 | example.com 網域中的 Google Workspace 身分 |
example.com 中的員工身分聯盟集區 |
project-1 中的服務帳戶、工作負載身分集區和代理程式身分 |
project-2 中的服務帳戶、工作負載身分集區和代理程式身分 |
project-3 中的服務帳戶、工作負載身分集區和代理程式身分 |
|---|---|---|---|---|---|
「example.com」的主體組合 |
|||||
「folder-a」的主體組合 |
|||||
「project-1」的主體組合 |
|||||
「project-2」的主體組合 |
|||||
「project-3」的主體組合 |
因此,下列主體會受到下列主體存取邊界政策影響:
example.com網域中的 Google Workspace 身分位於example.com的主體組合中,並會受到繫結至該主體組合的主體存取權範圍政策影響。project-1中的服務帳戶位於project-1和example.com的主體組合中,且會受到繫結至任一主體組合的主體存取權範圍政策影響。project-3中的代理身分位於project-3、folder-a和example.com的主體組合中,且會受到繫結至任何這些主體組合的主體存取邊界政策影響。
主體存取邊界政策的條件式政策繫結
您可以在主體存取邊界政策的政策繫結中使用條件運算式,進一步精確指定政策適用的主體。
政策繫結的條件運算式由一或多個陳述式組成,最多可使用 10 個邏輯運算子 (&&、|| 或 !) 連結。每個陳述式都代表適用於政策繫結的屬性控管規則,最終決定政策是否適用。
您可以在政策繫結的條件中使用 principal.type 和 principal.subject 屬性。系統不支援其他屬性。
principal.type屬性是指提出要求的主體類型,例如服務帳戶或代理程式身分。您可以使用這個屬性的條件,控管主體存取邊界政策適用的主體類型。舉例來說,如果您在主體存取邊界政策的繫結中新增下列條件運算式,則政策只會套用至服務帳戶:
principal.type == 'iam.googleapis.com/ServiceAccount'principal.subject屬性是指提出要求的主體身分,例如cruz@example.com。您可以搭配條件使用這項屬性,精確控管哪些主體適用於主體存取邊界政策。舉例來說,如果您將下列條件運算式新增至主體存取權範圍政策的繫結,則該政策不會套用至使用者
special-admin@example.com:principal.subject != 'special-admin@example.com'
如要進一步瞭解這些條件可使用的值,請參閱條件屬性參考資料。
如要瞭解如何在主體存取權界線政策中使用這些條件,請參閱「讓服務帳戶有權存取單一專案中的資源」一文。
跨機構政策繫結
您無法為主體存取權範圍政策建立跨機構政策繫結。跨機構政策繫結是指將一個機構的政策繫結至另一個機構的主體組合。
身分與存取權管理服務會定期刪除現有的跨機構政策繫結。如果您將專案從一個機構移至另一個機構,可能會發生跨機構政策繫結。舉例來說,請考慮以下情況:
- 您在機構
example.com中有一個專案example-project。 - 您希望
example-project中的主體有權存取example.com中的資源。如要這麼做,請在example.com中建立主體存取邊界政策,讓主體有權存取example.com中的資源,然後將該政策繫結至example-project的主體集。 - 將
example-project從example.com移至cymbalgroup.com。
在這種情況下,移動專案會建立跨機構政策繫結。這是因為 example.com 中的主體存取邊界政策會繫結至 cymbalgroup.com 中的主體集。如果您未手動刪除繫結,IAM 最終會自動刪除。刪除這項繫結可確保 cymbalgroup.com 管理員有權存取繫結至主體的所有主體存取邊界政策。
主體存取邊界政策的結構
主體存取邊界政策是中繼資料和主體存取邊界政策詳細資料的集合。中繼資料會提供政策名稱和政策建立時間等資訊。政策詳細資料會定義政策的作用,例如受影響主體可存取的資源。
舉例來說,下列主體存取邊界政策會讓受該政策約束的主體,有權存取 ID 為 0123456789012 的組織中的資源。
{
"name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
"uid": "puid_0123456789012345678",
"etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
"displayName": "Example policy",
"annotations": {
"example-key": "example-value"
},
"createTime": "2024-01-02T15:01:23Z",
"updateTime": "2024-01-02T15:01:23Z",
"details": {
"rules": [
{
"description": "Example principal access boundary policy rule",
"resources": [
"//cloudresourcemanager.googleapis.com/organizations/0123456789012"
],
"effect": "ALLOW"
}
],
"enforcementVersion": "4"
}
}
以下各節說明主體存取邊界政策中繼資料和詳細資料的欄位。
中繼資料
主體存取邊界政策包含下列中繼資料:
name:主體存取邊界政策的名稱。這個名稱的格式為organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID,其中ORGANIZATION_ID是建立主體存取權範圍政策的機構的數字 ID,PAB_POLICY_ID則是主體存取權範圍政策的英數 ID。uid:指派給主體存取邊界政策的專屬 ID。etag:政策目前狀態的 ID。更新政策時,這個值會隨之變更。為防止更新衝突,etag值必須與 IAM 中儲存的值相符。如果etag值不符,要求就會失敗。displayName:主體存取權範圍政策的人類可讀名稱。annotations:選用。使用者定義的鍵/值組合清單。您可以使用這些註解,為政策新增額外中繼資料,例如政策建立者,或是政策是否由自動化管道部署。如要進一步瞭解註解,請參閱「註解」一文。createTime:主體存取邊界政策的建立時間。updateTime:主體存取邊界政策上次更新的時間。
詳細資料
每項主體存取邊界政策都包含 details 欄位。這個欄位包含主體存取邊界規則和強制執行版本:
rules:主體存取邊界規則清單,定義受影響主體可存取的資源。每項規則都包含下列欄位:description:規則的易讀說明。resources:您希望主體有權存取的 Resource Manager 資源清單 (專案、資料夾和機構)。凡是受這項政策規範的主體,都有權存取這些資源。每項主體存取邊界政策最多可參照政策中所有規則的 500 項資源。
effect:主體與resources欄位所列資源的關係。您只能在主體存取邊界規則中指定"ALLOW"效果。這項關係可讓主體存取規則中列出的資源。
enforcementVersion:IAM 在強制執行政策時使用的強制執行版本。主體存取邊界政策版本會決定主體存取邊界政策可封鎖哪些權限。如要進一步瞭解如何設定及管理強制執行版本,請參閱本頁的「管理強制執行版本」。
政策繫結的結構
主體存取邊界政策的政策繫結包含政策名稱、要繫結政策的主體集名稱,以及說明政策繫結的中繼資料。也可以包含條件,用來修改政策適用的確切主體。
舉例來說,下列政策繫結會將政策 example-policy 繫結至 example.com 機構中的所有主體,該機構的 ID 為 0123456789012。政策繫結也包含一項條件,可防止系統對主體 super-admin@example.com 強制執行政策。
{
"name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
"uid": "buid_01234567890123456789",
"etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
"displayName": "Example policy binding",
"annotations": {
"example-key": "example-value"
},
"target": {
"principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
},
"policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
"policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
"policyUid": "puid_0123456789012345678",
"condition": {
"title": "Exempt principal",
"description": "Don't enforce the policy for super-admin@example.com",
"expression": "principal.subject != 'super-admin@example.com'"
},
"createTime": "2024-01-02T17:00:16Z",
"updateTime": "2024-01-02T17:00:16Z"
}
每個政策繫結都包含下列欄位:
name:政策繫結的名稱。這個名稱的格式為RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID,其中RESOURCE_TYPE/RESOURCE_ID是政策繫結父項資源的類型和 ID,BINDING_ID則是政策繫結的英數字元 ID。uid:指派給政策繫結的專屬 ID。etag:政策目前狀態的 ID。更新政策時,這個值會隨之變更。為防止更新衝突,etag值必須與 IAM 中儲存的值相符。如果etag值不符,要求就會失敗。displayName:政策繫結的人類可讀名稱。annotations:選用。使用者定義的鍵/值組合清單。您可以使用這些註解,在政策繫結中新增額外的中繼資料,例如政策繫結的建立者,或是政策繫結是否由自動化管道部署。如要進一步瞭解註解,請參閱「註解」一文。target:要繫結政策的主體組合。值的格式為{"principalSet": PRINCIPAL_SET},其中PRINCIPAL_SET是要將政策繫結至的主體集 ID。每個目標最多可繫結 10 項政策。
policyKind:政策繫結參照的政策類型。如果是主體存取邊界政策的政策繫結,這個值一律為PRINCIPAL_ACCESS_BOUNDARY。policy:要繫結至目標主體集的主體存取邊界政策。policyUid:指派給policy欄位所參照主體存取邊界政策的專屬 ID。condition:選用。這項邏輯運算式會影響身分與存取權管理系統對哪些主體強制執行政策。如果條件評估結果為 true 或無法評估,Identity and Access Management 會對提出要求的主體強制執行政策。如果條件評估結果為 false,Identity and Access Management 就不會對主體強制執行政策。詳情請參閱本頁的「主體存取邊界和條件」。createTime:建立政策繫結的時間。updateTime:政策繫結上次更新的時間。
後續步驟
- 進一步瞭解主體存取邊界政策的用途。
- 瞭解如何建立及套用主體存取邊界政策。
- 查看各個主體存取邊界政策強制執行版本封鎖的權限。