管理ポリシータイプのポリシー構文と継承 - AWS Organizations

管理ポリシータイプのポリシー構文と継承

重要

このセクションの情報は、SCP には適用されません。前のセクション「サービスコントロールポリシーの継承」を参照してください。

管理ポリシーには、次のタイプがあります。

継承の動作は、管理ポリシータイプの場合とサービスコントロールポリシーの場合とで異なります。この管理ポリシータイプの構文には、継承演算子が含まれています。継承演算子を使用すると、適用する親ポリシーの要素や、子 OU とアカウントが継承する際に上書きまたは変更できる要素を細かく指定できます。

有効なポリシーは、組織ルートと OU から継承されるルールのセットと、アカウントに直接アタッチされたルールのセットです。有効なポリシーは、アカウントに適用される最終的なルールセットを指定します。適用されたポリシー内のすべての継承演算子の効果を含む、アカウントの有効なポリシーを表示できます。詳細については、 有効なタグポリシーの表示を参照してください。

このセクションでは、親ポリシーと子ポリシーがアカウントの有効なポリシーにどのように処理されるかを説明します。

用語

このトピックでは、ポリシーの継承について説明するときに、次の用語を使用します。

ポリシーの継承

組織の最上位ルートから、組織単位 (OU) 階層、個々のアカウントへと移行する、組織のさまざまなレベルでのポリシーの相互作用です。

ポリシーは、組織ルート、OU、個々のアカウント、およびこれらの組織エンティティの任意の組み合わせにアタッチできます。ポリシーの継承とは、組織ルートまたは OU にアタッチされたポリシーを指します。ポリシーがアタッチされている組織ルートまたは OU のメンバーであるすべてのアカウントは、そのポリシーを継承します。

例えば、ポリシーを組織ルートにアタッチすると、組織内のすべてのアカウントがそのポリシーを継承します。これは、組織内のすべてのアカウントが常に組織ルートの下にあるためです。特定の OU にポリシーをアタッチすると、その OU または子 OU の直下にあるアカウントがそのポリシーを継承します。組織内の複数のレベルにポリシーをアタッチできるため、アカウントは 1 つのポリシータイプに対して複数のポリシードキュメントを継承する場合があります。

親ポリシー

組織ツリーで下位のエンティティにアタッチされているポリシーよりも上位にアタッチされているポリシー。

例えば、ポリシー A を組織ルートにアタッチすると、それは単なるポリシーです。ここでポリシー B を そのルートの下にある OU にアタッチすると、ポリシー A はポリシー B の親ポリシーとなり、ポリシー B はポリシー A の子ポリシーとなります。ポリシー A とポリシー B がマージされ、OU のアカウントの有効なタグポリシーになります。

子ポリシー

組織ツリーで親ポリシーよりも下位レベルでアタッチされているポリシー。

有効なポリシー

アカウントに適用されるルールを指定する、最終的な 1 つのポリシードキュメント。有効なポリシーは、アカウントが継承するすべてのポリシーと、アカウントに直接アタッチされたポリシーが集約されたものです。例えば、タグポリシーを使用すると、アカウントに適用される有効なタグポリシーを表示できます。詳細については、 有効なタグポリシーの表示を参照してください。

継承演算子

継承されたポリシーを 1 つの有効なポリシーにマージする方法を制御する演算子。これらの演算子は、アドバンスト機能とみなされます。経験豊富なポリシー作成者は、ポリシーを使用して、子ポリシーがどのような変更を行うことができるか、ポリシーの設定がどのようにマージされるかを制限できます。

継承演算子

継承演算子は、アカウントの有効なポリシーが作成される際に、継承されたポリシーとアカウントポリシーがどのようにマージされるかを制御します。これらの演算子には、値設定演算子と子制御演算子が含まれます。

AWS Organizations コンソールでビジュアルエディタを使用する場合は、@@assign 演算子のみを使用できます。他の演算子は、アドバンスト機能とみなされます。他の演算子を使用するには、JSON ポリシーを手動で作成する必要があります。経験豊富なポリシーの作成者は、継承演算子を使用して、有効なポリシーに適用するタグ値を制御し、子ポリシーがどのような変更を行うことができるかを制限できます。

値設定演算子

次の値設定演算子を使用して、ポリシーと親ポリシーとの相互作用を制御できます。

  • @@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、および複数のアカウントを持つ組織。

例 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" ] } } }