本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 理解管理政策繼承
**重要**
本節中的資訊***不適用於***授權政策：服務控制政策 (SCPs) 和資源控制政策 RCPs)。如需 SCPs和 RCPs如何在 AWS Organizations 階層中運作的詳細資訊，請參閱 [SCP 評估](orgs_manage_policies_scps_evaluation.md)和 [RCP 評估](orgs_manage_policies_rcps_evaluation.md)。
您可以在組織中將這些管理政策連接至組織實體 (組織根、組織單位 (OU) 或帳戶)：
+ 當您將管理政策連接至組織根時，組織中的所有 OU 和帳戶都會繼承該政策。
+ 當您將管理政策連接至特定 OU 時，直屬於該 OU 或任何子 OU 的帳戶會繼承此政策。
+ 當您將管理政策連接至特定帳戶時，它只會影響該帳戶。
因為您可以將管理政策連接至組織中的多個層級，所以帳戶可以繼承多個政策。
下列主題說明如何將父政策和子政策處理為 帳戶的有效政策。
**Topics**
+ [術語](inheritance-terminology.md)
+ [管理政策類型](syntax-inheritance.md)
+ [繼承運算子](policy-operators.md)
+ [繼承範例](inheritance-examples.md)
# 继承術語
本主題在討論管理政策繼承時會使用下列術語。
**政策繼承**
組織不同層級的政策互動，從組織的頂層根下移至組織單位 (OU) 階層，再到個別帳戶。
您可以將政策連接至組織根、OU、個別帳戶，以及這些組織實體的任何組合。政策繼承是指連接至組織根或 OU 的管理政策。在連接管理政策的組織根目錄或 OU 中，所有成員帳戶都*繼承*該政策。
例如，當管理政策連接至組織根時，組織中的所有帳戶都會繼承該政策。這是因為組織中的所有帳戶永遠都在組織根下。當您將標籤政策連接至特定 OU 時，直屬於該 OU 或任何子 OU 的帳戶會繼承該政策。因為您可以將政策連接至組織中的多個層級，所以帳戶可能會繼承單一政策類型的多個政策文件。
**父政策**
在組織樹狀結構中較上方連接的政策，高於樹狀結構中連接至較低實體的政策。
例如，如果您將管理政策 A 連接至組織根，就只是政策而已。如果您也將政策 B 連接至該根下的 OU，而政策 A 是政策 B 的父政策。政策 B 是政策 A 的子政策。政策 A 和政策 B 合併，為 OU 中的帳戶建立有效的標籤政策。
**子政策**
在組織樹狀結構中比父政策更低的層級上連接的政策。
**有效政策**
指定規則以套用至帳戶的最終單一政策文件。帳戶繼承的任何政策，加上直接連接至帳戶的任何政策，聚集而成有效政策。如需詳細資訊，請參閱[檢視有效的管理政策](orgs_manage_policies_effective.md)。
**繼承運算子**
控制繼承的政策如何合併成為單一有效政策的運算子。這些運算子視為進階功能。經驗豐富的政策作者可以使用這些運算子，限制子政策可以進行哪些變更和政策中的設定如何合併。如需詳細資訊，請參閱[繼承運算子](policy-operators.md)。
# 政策語法與管理政策類型的繼承
政策究竟如何影響繼承它們的 OU 和帳戶，取決於所選管理政策的類型。管理政策類型包括：
+ [宣告式政策](orgs_manage_policies_declarative.md)
+ [備份政策](orgs_manage_policies_backup.md)
+ [標籤政策](orgs_manage_policies_tag-policies.md)
+ [聊天應用程式政策](orgs_manage_policies_chatbot.md)
+ [AI 服務選擇退出政策](orgs_manage_policies_ai-opt-out.md)
+ [Security Hub 政策](orgs_manage_policies_security_hub.md)
+ [Bedrock 政策](orgs_manage_policies_bedrock.md)
+ [Inspector 政策](orgs_manage_policies_inspector.md)
+ [升級推展政策](orgs_manage_policies_upgrade_rollout.md)
+ [S3 政策](orgs_manage_policies_s3.md)
+ [AWS Shield 網路安全總監政策](orgs_manage_policies_network_security_director.md)
管理政策類型的語法包含*[繼承運算子](policy-operators.md)*，可讓您精細地指定要套用父政策中的哪些元素，以及哪些元素在被子 OU 和帳戶繼承時可以被覆寫或修改。
*有效政策*是從組織根和 OU 繼承的一組規則，以及直接連接到帳戶的規則。有效政策會指定套用至帳戶的最終規則集。您可以檢視帳戶的有效政策，其中包含所套用政策中所有繼承運算子的效果。如需詳細資訊，請參閱[檢視有效的管理政策](orgs_manage_policies_effective.md)。
# 繼承運算子
繼承運算子可控制繼承的政策和帳戶政策如何合併成為帳戶的有效政策。這些運算子包括值-設定運算子和子控制運算子。
當您在 AWS Organizations 主控台中使用視覺化編輯器時，您只能使用 `@@assign`運算子。其他運算子視為進階功能。若要使用其他運算子，您必須手動撰寫 JSON 政策。經驗豐富的政策作者可以使用繼承運算子，控制哪些值套用至有效的政策，並限制子政策可以進行哪些變更。
如需政策繼承如何在組織中運作的詳細資訊，請參閱 [繼承範例](inheritance-examples.md)。
## 值-設定運算子
您可以使用下列值-設定運算子來控制政策與其父政策的互動方式。
+ `@@assign` – 使用指定的設定**覆寫**任何繼承的政策設定。如果未繼承指定的設定，此運算子會將其新增至有效政策。此運算子可套用至任何類型的任何政策設定。
+ 對於單值設定，此運算子會以指定的值取代繼承的值。
+ 對於多值設定 (JSON 陣列)，此運算子會移除任何繼承的值，並取代為此政策指定的值。
+ `@@append` – 將指定的設定 (不刪除任何項目) **新增**至繼承的設定。如果未繼承指定的設定，此運算子會將其新增至有效政策。此運算子只能與多值設定一起使用。
+ 此運算子會將指定的值新增至繼承陣列中的任何值。
+ `@@remove` – 從有效政策中**移除**指定的繼承設定 (如果存在)。此運算子只能與多值設定一起使用。
+ 此運算子會從繼承自父政策的值陣列中，只移除指定的值。其他值可以繼續存在於陣列中，而且可以由子政策繼承。
## 子控制運算子
可自行決定是否使用子控制運算子。您可以使用 `@@operators_allowed_for_child_policies` 運算子來控制子政策可以使用哪些值-設定運算子。您可以允許所有運算子、某些特定運算子或不允許運算子。根據預設，允許所有運算子 (`@@all`)。
+ `"@@operators_allowed_for_child_policies"`:`["@@all"]` – 子 OU 和帳戶可以在政策中使用任何運算子。根據預設，子政策中允許所有運算子。
+ `"@@operators_allowed_for_child_policies"`:`["@@assign", "@@append", "@@remove"]` – 子 OU 和帳戶在子政策中只能使用指定的運算子。您可以在此子控制運算子中指定一或多個值-設定運算子。
+ `"@@operators_allowed_for_child_policies"`:`["@@none"]` – 子 OU 和帳戶在政策中無法使用運算子。您可以使用此運算子，有效封鎖父政策中定義的值，讓子政策無法新增、附加或移除這些值。
**注意**
如果繼承的子控制運算子禁止使用某個運算子，則您無法在子政策中反轉該規則。如果您將子控制運算子包含在父政策中，則會限制所有子政策中的值-設定運算子。
# 繼承範例
這些範例顯示父標籤和子標籤政策如何合併成為帳戶的有效標籤政策，以示範政策繼承的運作方式。
這些範例假設您有如下圖所示的組織結構。
![\[具有一個根、兩個 OU 和數個帳戶的組織。\]](http://docs.aws.amazon.com/zh_tw/organizations/latest/userguide/images/org-structure-inheritance.png)
**Topics**
+ [範例 1：允許子政策*只*覆寫標籤值](#example-assign-operator)
+ [範例 2：將新值附加到繼承的標籤](#example-append-operator)
+ [範例 3：從繼承的標籤中移除值](#example-remove-operator)
+ [範例 4：限制對子政策的變更](#example-restrict-child)
+ [範例 5：與子控制運算子衝突](#multiple-same-node-operators)
+ [範例 6：與相同階層層級上附加的值衝突](#multiple-same-node-values)
## 範例 1：允許子政策*只*覆寫標籤值
下列標籤政策定義 `CostCenter` 標籤鍵和兩個可接受的值 (`Development` 和 `Support`)。如果您將此政策連接至組織根，則會對組織中的所有帳戶產生效果。
**政策 A – 組織根標籤政策**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
假設您希望 OU1 中的使用者對某個索引鍵使用不同的標籤值，而且想要針對特定的資源類型強制執行標籤政策。因為政策 A 未指定允許哪些子控制運算子，所以允許所有運算子。您可以使用 `@@assign` 運算子，並建立如下的標籤政策以連接至 OU1。
**政策 B – OU1 標籤政策**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Sandbox"
]
},
"enforced_for": {
"@@assign": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
當政策 A 和政策 B 合併以形成帳戶的*有效標籤政策*時，為標籤指定 `@@assign` 運算子會執行以下操作：
+ 政策 B 覆寫父政策 (政策 A) 中指定的兩個標籤值。結果是 `Sandbox` 是 `CostCenter` 標籤鍵的唯一合規值。
+ 新增的 `enforced_for` 指定在所有 Amazon Redshift 資源和 Amazon DynamoDB 資料表上，`CostCenter` 標籤*必須*使用指定的標籤值。
如圖所示，OU1 包含兩個帳戶：111111111111 和 222222222222。
**帳戶 111111111111 和 222222222222 所產生的有效標籤政策**
**注意**
您無法直接使用顯示的有效政策的內容作為新政策的內容。語法不包括控制與其他子政策和父政策合併所需的運算子。顯示有效政策僅用於了解合併的結果。
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Sandbox"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## 範例 2：將新值附加到繼承的標籤
在某些情況下，您希望組織中的所有帳戶以簡短的可接受值清單來指定標籤鍵。對於一個 OU 中的帳戶，在建立資源時，您可能想要允許只有這些帳戶才可以指定的額外值。此範例指出如何利用 `@@append` 運算子來這樣做。`@@append` 運算子是進階功能。
與範例 1 一樣，此範例一開始也以政策 A 當作組織根標籤政策。
**政策 A – 組織根標籤政策**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
在此範例中，將政策 C 連接至 OU2。此範例的差異在於，在政策 C 中使用 `@@append` 運算子會*新增至* (而非覆寫) 可接受的值清單和 `enforced_for` 規則。
**政策 C – OU2 標籤政策，用於附加值**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@append": [
"Marketing"
]
},
"enforced_for": {
"@@append": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
當政策 A 和政策 C 合併形成帳戶的有效標籤政策時，將政策 C 連接至 OU2 會產生下列效果：
+ 因為政策 C 包含 `@@append` 運算子，所以允許*新增至* (而非覆寫) 政策 A 中指定的可接受標籤值清單。
+ 與政策 B 一樣，新增的 `enforced_for` 指定在所有 Amazon Redshift 資源和 Amazon DynamoDB 資料表上，`CostCenter` 標籤必須做為指定的標籤值。如果父政策不含子控制運算子來限制子政策可指定的內容，則覆寫 (`@@assign`) 和新增 (`@@append`) 有相同的效果。
如圖所示，OU2 包含一個帳戶：999999999999。政策 A 和政策 C 合併，為帳戶 999999999999 建立有效的標籤政策。
**帳戶 999999999999 的有效標籤政策**
**注意**
您無法直接使用顯示的有效政策的內容作為新政策的內容。語法不包括控制與其他子政策和父政策合併所需的運算子。顯示有效政策僅用於了解合併的結果。
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Development",
"Support",
"Marketing"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## 範例 3：從繼承的標籤中移除值
在某些情況下，連接至組織的標籤政策所定義的標籤值，可能超過您希望帳戶使用的數量。此範例說明如何使用 `@@remove` 運算子修訂標籤政策。`@@remove` 是進階功能。
與其他範例一樣，此範例一開始也以政策 A 當作組織根標籤政策。
**政策 A – 組織根標籤政策**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
在此範例中，將政策 C 連接至帳戶 999999999999。
**政策 D – 帳戶 999999999999 標籤政策，用於移除值**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@remove": [
"Development",
"Marketing"
],
"enforced_for": {
"@@remove": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
}
```
當政策 A、政策 C 和政策 D 合併形成有效的標籤政策時，將政策 D 連接至帳戶 999999999999 會產生下列效果：
+ 假設您已執行所有先前的範例，則政策 B、C 和 C 是 A 的子政策。政策 B 只連接至 OU1，因此不影響帳戶 9999999999999。
+ 對於帳戶 9999999999999，`CostCenter` 標籤鍵唯一可接受的值是 `Support`。
+ 不強制 `CostCenter` 標籤鍵合規。
**帳戶 999999999999 新的有效標籤政策**
**注意**
您無法直接使用顯示的有效政策的內容作為新政策的內容。語法不包括控制與其他子政策和父政策合併所需的運算子。顯示有效政策僅用於了解合併的結果。
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Support"
]
}
}
}
```
如果您稍後將更多帳戶新增至 OU2，其有效的標籤政策將與帳戶 999999999999 有所不同。這是因為更嚴格的政策 D 只在帳戶層級連接，而不是連接至 OU。
## 範例 4：限制對子政策的變更
在某些情況下，您可能想要限制子政策中的變更。此範例說明如何利用子控制運算子來這樣做。
此範例從新的組織根標籤政策開始，並假設標籤政策尚未連接至組織實體。
**政策 E – 組織根標籤政策，用於限制子政策中的變更**
```
{
"tags": {
"project": {
"tag_key": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "Project"
},
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance",
"Escalations"
]
}
}
}
}
```
當您將政策 E 連接至組織根時，政策即可防止子政策變更 `Project` 標籤鍵。不過，子政策可以覆寫或附加標籤值。
假設您接著將下列政策 F 連接至 OU。
**政策 F – OU 標記政策**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": [
"Escalations - research"
]
}
}
}
}
```
合併政策 E 和政策 F 會對 OU 的帳戶產生下列效果：
+ 政策 F 是政策 E 的子政策。
+ 政策 F 試圖變更大小寫處理，但無法這樣做。這是因為政策 E 在標籤鍵中包含 `"@@operators_allowed_for_child_policies": ["@@none"]` 運算子。
+ 不過，政策 F 可以為索引鍵附加標籤值。這是因為政策 E 在標籤值中包含 `"@@operators_allowed_for_child_policies": ["@@append"]`。
**OU 中帳戶的有效政策**
**注意**
您無法直接使用顯示的有效政策的內容作為新政策的內容。語法不包括控制與其他子政策和父政策合併所需的運算子。顯示有效政策僅用於了解合併的結果。
```
{
"tags": {
"project": {
"tag_key": "Project",
"tag_value": [
"Maintenance",
"Escalations",
"Escalations - research"
]
}
}
}
```
## 範例 5：與子控制運算子衝突
子控制運算子可以存在於組織階層中相同層級上連接的標籤政策中。在此情況下，政策合併形成帳戶的有效政策時會使用允許運算子的交集。
假設政策 G 和政策 H 連接至組織根。
**政策 G – 組織根標籤政策 1**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance"
]
}
}
}
}
```
**政策 H – 組織根標籤政策 2**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
}
}
}
}
```
在此範例中，組織根上的一個政策定義只能附加標籤鍵的值。連接至組織根的其他政策允許子政策附加和移除值。這兩個許可的交集用於子政策。結果是子政策可以附加值，但不能移除值。因此，子政策可以將值附加至標籤值清單，但無法移除 `Maintenance` 值。
## 範例 6：與相同階層層級上附加的值衝突
您可以將多個標籤政策連接至每個組織實體。當您這麼做時，連接至相同組織實體的標籤政策可能包含衝突的資訊。這些政策是根據連接至組織實體時的順序來評估。若要變更先評估哪個政策，您可以分離政策，再重新連接。
假設政策 J 最先連接至組織根，然後政策 K 才連接至組織根。
**政策 J – 連接至組織根的第一個標籤政策**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": ["Maintenance"]
}
}
}
}
```
**政策 K – 連接至組織根的第二個標籤政策**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "project"
}
}
}
}
```
在此範例中，有效的標籤政策中會使用標籤鍵 `PROJECT`，因為定義此標籤鍵的政策最先連接至組織根。
**政策 JK – 帳戶的有效標籤政策**
帳戶的有效政策如下。
**注意**
您無法直接使用顯示的有效政策的內容作為新政策的內容。語法不包括控制與其他子政策和父政策合併所需的運算子。顯示有效政策僅用於了解合併的結果。
```
{
"tags": {
"project": {
"tag_key": "PROJECT",
"tag_value": [
"Maintenance"
]
}
}
}
```