サービスコントロールポリシーの継承 - AWS Organizations

サービスコントロールポリシーの継承

重要

このセクションの情報は、AI サービスのオプトアウトポリシー、バックアップポリシー、タグポリシーなどの管理ポリシータイプには適用されません。次のセクション「管理ポリシータイプのポリシー構文と継承」を参照してください。

サービスコントロールポリシー (SCPs)

サービスコントロールポリシーの継承は、以下のツリーのすべての部分にアクセス許可が流れるフィルターのように動作します。組織の逆ツリー構造が、ルートからすべての OU に接続し、アカウントで終わるブランチで構成されているとします。すべての AWS アクセス許可はツリーのルートに流れます。次に、これらのアクセス許可は、ルート、OU、およびアカウントにアタッチされた SCP を通過して、リクエストを行うプリンシパル (IAM ロールまたはユーザー) に到達する必要があります。各 SCP は、その下のレベルに渡されるアクセス許可をフィルタリングできます。アクションが Deny ステートメントによってブロックされた場合、その SCP の影響を受けるすべての OU およびアカウントは、そのアクションへのアクセスを拒否されます。下位レベルの SCP は、上位レベルの SCP によってブロックされたアクセス許可を追加できません。SCP はフィルタリングのみが可能で、アクセス許可を追加することはできません。

SCP は、ポリシーの要素が子 OU とアカウントによって継承される方法を変更する継承演算子をサポートしていません。

次の図では SCP の仕組みを示しています。

この図では、左側の楕円が、組織ルートにアタッチされている SCP を表していると仮定します。これにより、A、B、C のアクセスが許可されます。ルートには組織単位 (OU) が含まれ、右側の楕円が表す 2 番目の SCP がアタッチされています。2 番目の SCP は、C、D、E のアクセスを許可します。ルートにアタッチされている SCP は D または E を許可しないため、組織内の OU またはアカウントはそれらを使用できません。OU にアタッチされている SCP が D と E を明示的に許可しても、組織ルートにアタッチされた SCP によってよってブロックされるため、結果的にはブロックされます。OU の SCP が A と B を許可していないため、OU とその子 OU またはアカウントに対するこれらのアクセス許可はブロックされます。ただし、ルートの下にある他の OU は引き続き A や B を許可することができます。

OU の階層をアカウントまでトラバースすると、前の段落のプロセスが各 OU で繰り返され、最後にアカウントで繰り返されます。各レベルでは、親での評価結果が図の左側にあるポリシーとなり、子 OU にアタッチされた SCP と比較されます。

例えば、ツリーを下って X という子 OU に移動する場合、左側の楕円は、階層内で OU X の上位にあるすべての SCP によって許可されている、継承された有効なアクセス許可を表しているとします。右側の楕円は、OU に接続された SCP または OU X に含まれる AWS アカウント を表します。ここでも、これらのアクセス許可の交点は、右側のエンティティで使用できるものです。そのエンティティ がAWS アカウント の場合、交点がそのアカウントのユーザーとロールに付与できるアクセス許可セットとなります。エンティティが OU の場合、交点は OU の子が継承できるアクセス許可セットとなります。アカウントに到達するまで、OU 階層の下位レベルごとにこのプロセスを繰り返します。最終的に有効になったポリシーが、そのアカウントの上位にあるすべての SCP によって許可され、それにアタッチされたアクセス許可のリストに表示されます。

つまり、メンバーアカウントレベルで AWS サービス API を許可するには、メンバーアカウントと組織ルートの間のすべてのレベルで、その API を許可する必要があります。組織ルートから、指定された AWS サービス API を許可するメンバーアカウント (ec2:RunInstances など) まで、すべてのレベルに SCP をアタッチする必要があります。これには、次の戦略のいずれかを使用できます。

  • 拒否リスト戦略は、デフォルトですべての OU とアカウントにアタッチされている FullAWSAccess SCP を使用します。この SCP は、デフォルトの暗黙の拒否を上書きし、追加の SCP を作成し、適切な OU またはアカウントにアタッチしてアクセス許可を明示的に拒否しない限り、すべてのアクセス許可がルートからすべてのアカウントに流れることを明示的に許可します。この戦略が有効なのは、ポリシー内の明示的な deny があらゆる種類の allow を常に上書きするためです。拒否ポリシーのある OU のレベルの下のアカウントでは、拒否された API は使用できません。また、アクセス許可を階層の下位に追加する方法はありません。詳細については、「SCP を拒否リストとして使用する」を参照してください。

  • 許可リスト戦略では、すべての OU とアカウントにデフォルトで接続されている FullAWSAccess SCP を削除します。つまり、明示的に許可しない限り、API はどこでも許可されないということです。サービス API を AWS アカウント で動作させるには、独自の SCP を作成し、アカウントとその上にあるルートまでのすべての OU にアタッチする必要があります。ルートから始まる階層内のすべての SCP は、OU とその下のアカウントで使用できるようにする API を明示的に許可する必要があります。この戦略が有効なのは、SCP 内の明示的な allow が暗黙的な deny を上書きするためです。詳細については、「SCP を許可リストと使用する」を参照してください。

暗黙的な許可と、明示的な許可および拒否の観点でポリシーがどのように評価されるか、また、上書きし、上書きされる許可および拒否を確認するには、「アカウント内でのリクエストの許可または拒否を決定する」を参照してください。

アカウント内のユーザーとロールは、それらやグループにアタッチされている AWS Identity and Access Management (IAM) アクセス許可ポリシーを使用してアクセス許可を付与される必要があります。SCP は、それらのポリシーによって付与するために使用できるアクセス許可を決定するだけです。ユーザーは、該当する SCP で許可されていないアクションを実行することはできません。1 つ以上の IAM アクセス許可ポリシーによりアクションがユーザーまたはロールに付与されている場合、SCP で許可されているアクションを使用できます。

SCP を組織ルートや OU に、またアカウントに直接アタッチする際、所定のアカウントに影響するすべてのポリシーは、IAM アクセス許可ポリシーを規定するものと同じルールを使用してまとめて評価されます。

  • 影響を受けるアカウントのユーザーとロールは、SCP の Deny ステートメントにリストされているアクションを実行できません。明示的な Deny ステートメントは、他の SCP により付与されるどの Allow よりも優先されます。

  • 明示的に Allow を SCP に持つ (例えば、デフォルトの "*" SCP や、特定のサービスやアクションを呼び出すその他の SCP) 任意のアクションは、影響を受けるアカウントのユーザーおよびロールに移譲できます。

  • SCP により明示的に許可されていない任意のアクションは、暗示的に拒否され、影響を受けるアカウントのユーザーまたはロールに委任できません。

デフォルトでは、FullAWSAccess と名付けられた SCP が各組織ルート、OU、アカウントにアタッチされています。このデフォルト SCP はすべてのアクションとすべてのサービスを許可します。したがって新しい組織では、SCP の作成と操作を開始するまで、既存のすべての IAM アクセス許可が継続して機能します。新しい、または修正された SCP をアカウントを含む組織ルートや OU に適用するとすぐに、ユーザーがアカウントで持つアクセス権限は SCP によりフィルタリングされます。指定のアカウントの階層の各レベルで SCP により許可されなくなると、以前は機能していたアクセス権限は拒否されるようになります。

組織ルートで SCP ポリシータイプを無効にすると、すべての SCP が組織ルート内のすべてのエンティティから自動的にデタッチされます。組織ルートで SCP を再度有効にすると、元のすべてのアタッチメントは失われ、すべてのエンティティが、デフォルトの FullAWSAccess SCP のみがアタッチされた状態にリセットされます。

SCP の構文の詳細については、「SCP 構文」を参照してください。

アカウントに適用されているすべてのポリシーと、そのポリシーの取得元の一覧を表示できます。これを行うには、AWS Organizations コンソールでアカウントを選択します。アカウントの詳細ページで、[ポリシー] を選択し、右側の詳細ペインで [サービスコントロールポリシー] を選択します。アカウントの任意のコンテナまたはすべての親コンテナにポリシーをアタッチできるため、同じポリシーが複数回アカウントに適用される場合があります。アカウントに適用される効果的なポリシーは、適用可能なすべてのポリシーの許可されたアクセス許可の交点です。

SCP の使用方法の詳細については、「サービスコントロールポリシー (SCPs)」を参照してください。