翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 継承の例
これらの例は、親タグポリシーと子タグポリシーがマージされてアカウントの有効なタグポリシーになるのを示すことにより、ポリシーの継承がどのように機能するかを示しています。
この例では、次の図に示す組織構造があることを前提としています。
![\[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"
]
}
}
}
```