翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 管理ポリシーの継承を理解する
**重要**
このセクションの情報は、次の認可ポリシーには***適用されません***: サービスコントロールポリシー (SCP) およびリソースコントロールポリシー (RCP) SCPsRCPs「」を参照してください[RCP 評価](orgs_manage_policies_rcps_evaluation.md)。 AWS Organizations [SCP 評価](orgs_manage_policies_scps_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 の直下にあるアカウントがそのポリシーを継承します。組織内の複数のレベルにポリシーをアタッチできるため、アカウントは 1 つのポリシータイプに対して複数のポリシードキュメントを継承する場合があります。
**親ポリシー**
組織ツリーで下位のエンティティにアタッチされているポリシーよりも上位にアタッチされているポリシー。
例えば、管理ポリシー A を組織ルートにアタッチすると、それは単なるポリシーです。ここでポリシー B を そのルートの下にある OU にアタッチすると、ポリシー A はポリシー B の親ポリシーとなり、ポリシー B はポリシー A の子ポリシーとなります。ポリシー A とポリシー B がマージされ、OU のアカウントの有効なタグポリシーになります。
**子ポリシー**
組織ツリーで親ポリシーよりも下位レベルでアタッチされているポリシー。
**有効なポリシー**
アカウントに適用されるルールを指定する、最終的な 1 つのポリシードキュメント。有効なポリシーは、アカウントが継承するすべてのポリシーと、アカウントに直接アタッチされたポリシーが集約されたものです。詳細については、「[効果的な管理ポリシーの表示](orgs_manage_policies_effective.md)」を参照してください。
**継承演算子**
継承されたポリシーを 1 つの有効なポリシーにマージする方法を制御する演算子。これらの演算子は、アドバンスト機能とみなされます。経験豊富なポリシー作成者は、ポリシーを使用して、子ポリシーがどのような変更を行うことができるか、ポリシーの設定がどのようにマージされるかを制限できます。詳細については、「[継承演算子](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 Network Security Director ポリシー](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 とアカウントは、子ポリシーで指定された演算子のみを使用できます。この子制御演算子では、1 つ以上の値設定演算子を指定できます。
+ `"@@operators_allowed_for_child_policies"`: `["@@none"]` － 子 OU とアカウントは、ポリシーの演算子を使用できません。この演算子を使用して、子ポリシーがこれらの値を追加、付加、または削除できないように、親ポリシーで定義されている値で効果的にロックできます。
**注記**
継承された子制御演算子によって演算子の使用が制限されている場合、子ポリシーでそのルールを元に戻すことはできません。親ポリシーに子制御演算子を含めると、すべての子ポリシーの値設定演算子が制限されます。
# 継承の例
これらの例は、親タグポリシーと子タグポリシーがマージされてアカウントの有効なタグポリシーになるのを示すことにより、ポリシーの継承がどのように機能するかを示しています。
この例では、次の図に示す組織構造があることを前提としています。
![\[1 つのルート、2 つの OU、および複数のアカウントを持つ組織。\]](http://docs.aws.amazon.com/ja_jp/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` タグキーと 2 つの許容値 (`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"
]
}
}
}
}
```
タグの `@@assign` 演算子を指定すると、ポリシー A とポリシー B が統合されてアカウントの*有効なタグポリシー*が形成された場合に、以下のようになります。
+ ポリシー B は、親ポリシーであるポリシー A で指定された 2 つのタグ値を上書きします。その結果、`Sandbox` は、`CostCenter` タグキーの準拠値のみとなります。
+ `enforced_for` を追加することで、すべての Amazon Redshift リソースと Amazon DynamoDB テーブルで、指定されたタグ値として `CostCenter` タグを使用する*必要がある*ことが指定されます。
図に示すように、OU1 には 2 つのアカウント (111111111111 と 222222222222) が含まれています。
**アカウント 111111111111 および 222222222222 に対して有効な、結果として生じるタグポリシー**
**注記**
表示された有効なポリシーの内容を、新しいポリシーの内容として直接使用することはできません。構文には、他の子ポリシーと親ポリシーのマージを制御するために必要な演算子は含まれていません。有効なポリシーの表示は、マージの結果を把握することのみを目的としています。
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Sandbox"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## 例 2: 継承されたタグに新しい値を追加する
組織内のすべてのアカウントで、許容値の短いリストでタグキーを指定する必要がある場合が考えられます。1 つの 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"
]
}
}
}
}
```
ポリシー C を OU2 にアタッチすると、ポリシー A とポリシー C がマージしてアカウントの有効なタグポリシーを形成した時点で次のような効果があります。
+ ポリシー C には `@@append` 演算子が含まれているため、ポリシー A で指定されている許容タグ値のリストを上書きするのではなく、*追加*できます。
+ ポリシー B では、`enforced_for` を追加することにより、すべての Amazon Redshift リソースと Amazon DynamoDB テーブルで、指定されたタグ値として `CostCenter` タグを使用する必要があることが指定されます。上書き (`@@assign`) と追加 (`@@append`) は、子ポリシーが指定できるものを制限する子制御演算子が親ポリシーに含まれていない場合、同じ効果があります。
図に示すように、OU2 には 1 つのアカウント (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"
]
}
}
}
}
```
この例では、ポリシー D をアカウント 999999999999 にアタッチします。
**ポリシー D － 値を削除するためのアカウント 999999999999 のタグポリシー**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@remove": [
"Development",
"Marketing"
],
"enforced_for": {
"@@remove": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
}
```
ポリシー D をアカウント 999999999999 にアタッチすると、ポリシー A、ポリシー C、およびポリシー D をマージして有効なタグポリシーを形成した時点で、次の効果があります。
+ 前述の例をすべて実行した場合、ポリシー 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"]
}
}
}
}
```
この例では、組織ルートの 1 つのポリシーで、タグキーの値のみを追加できるということが定義されています。組織ルートにアタッチされたもう 1 つのポリシーは、子ポリシーが値の追加と削除の両方を行うことを許可します。これら 2 つのアクセス許可の共通部分が子ポリシーに使用されます。その結果、子ポリシーは値を追加できますが、値は削除できません。したがって、子ポリシーはタグ値のリストに値を追加できますが、`Maintenance` の値を削除することはできません。
## 例 6: 同じ階層レベルで値を追加した場合の競合
各組織エンティティに複数のタグポリシーをアタッチできます。これを行うと、同じ組織エンティティにアタッチされているタグポリシーに競合する情報が含まれる場合があります。ポリシーは、組織エンティティにアタッチされた順序に基づいて評価されます。最初に評価されるポリシーを変更するには、ポリシーをデタッチしてから再度アタッチします。
ポリシー J が最初に組織ルートにアタッチされ、その次にポリシー K が組織ルートにアタッチされると仮定します。
**ポリシー J － 組織ルートにアタッチされた最初のタグポリシー**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": ["Maintenance"]
}
}
}
}
```
**ポリシー K － 組織ルートにアタッチされた 2 番目のタグポリシー**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "project"
}
}
}
}
```
この例では、`PROJECT` タグキーを定義したポリシーが最初に組織ルートにアタッチされたため、このタグキーが有効なタグポリシーで使用されます。
**ポリシー JK － アカウントの有効なタグポリシー**
アカウントの有効なポリシーは次のようになります。
**注記**
表示された有効なポリシーの内容を、新しいポリシーの内容として直接使用することはできません。構文には、他の子ポリシーと親ポリシーのマージを制御するために必要な演算子は含まれていません。有効なポリシーの表示は、マージの結果を把握することのみを目的としています。
```
{
"tags": {
"project": {
"tag_key": "PROJECT",
"tag_value": [
"Maintenance"
]
}
}
}
```