AWS Organizations
ユーザーガイド

サービスコントロールポリシーについて

サービスコントロールポリシー (SCP) は、管理者が SCP が適用されるアカウントのユーザーとロールに、どのサービスとアクションを委譲できるかを決定します。SCP はいかなるアクセス権限も付与しません。代わりに、フィルタとして考えてください。SCP でサービスのアクションを許可した場合、アカウントの管理者はこれらのアクションのアクセス許可をアカウント内のユーザーおよびロールに付与することができます。管理者がそれらのアクセス許可を付与すると、ユーザーとロールはアクションを実行できるようになります。SCP がサービスのアクションを拒否した場合、アカウントの管理者は効率的にアクションのアクセス許可を付与することができません。また、管理者から付与された場合でもアカウント内のユーザーやロールがアクションを実行することはできません。たとえば、アカウント 111122223333 の管理者が Amazon Simple Storage Service (Amazon S3) と Amazon Elastic Compute Cloud (Amazon EC2) にのみアクセス権限を付与できるが、777788889999 の管理者は Amazon DynamoDB (DynamoDB) にのみアクセス権限を付与できる、と指定することができます。

重要

  • SCP は、アカウントがルート/OU の階層のどこにある場合も、マスターアカウントに影響しません

  • SCP は、影響を受けるアカウントのルートユーザーと、すべての IAM ユーザーおよび標準の IAM ロールに影響します

  • SCP は、アカウントのサービスにリンクされたロールには影響しません。これは他の AWS サービスとの統合をサポートするためのロールです。このロールを、SCP によって制限することはできません。

  • SCP は組織の一部であるアカウントが管理するプリンシパルのみに影響します。組織外のアカウントからのユーザーやロールには影響しません。組織内のアカウント A が所有する Amazon S3 バケットを例とします。その場合、このバケットポリシーは組織外のアカウントからのユーザーにアクセスを付与します。アカウント A には SCP がアタッチされています。この SCP は外部ユーザーに適用されません。組織内のアカウント「A」が管理するユーザーにのみ適用されます。

  • SCP は すべての機能を有効にする組織でのみ使用できます。組織が一括請求機能のみを有効にしている場合、SCP は使用できません。

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

この図では、ルートには、アクセス許可 A、B、C を付与する SCP がアタッチされています。ルートにある OU には、アクセス許可 C、D、E を付与する SCP があります。ルートの OU が D や E を許可していないため、親 OU を含め、ルートやその子のいずれも D や E を使用できません。親 OU が明示的に許可していても、ルートでブロックされるため、最終的にはブロックされることになります。また、OU の SCP が A や B を許可していないため、親 OU とその子に対するアクセス許可はブロックされます。ただし、ルートの下にある他の OU は親 OU のピアで、A や B を許可することができます。

この場合もユーザーとロールは、それらやグループにアタッチされている IAM アクセス権限ポリシーを使用してアクセス権限を付与される必要があります。SCP では、このようなポリシーによって付与されるアクセス許可はフィルタリングされるため、適用可能な SCP によって許可されていないアクションをユーザーが実行することはできません。1 つ以上の IAM アクセス権限ポリシーによりアクションがユーザーまたはロールに付与されている場合、SCP で許可されているアクションは使用できます。

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

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

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

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

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

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

SCP の構文の詳細については、このガイドの「Reference」セクションの サービス管理ポリシー構文 を参照してください 。

SCP を使用した戦略

組織内で、次のうちいずれかとして機能するよう、SCP を構成できます。

  • ブラックリスト – デフォルトでアクションは許可され、どのサービスとアクションを禁止するかを指定できます。

  • ホワイトリスト – デフォルトでアクションは禁止され、どのサービスとアクションを許可するかを指定できます。

SCP をブラックリストとして使用する

AWS Organizations のデフォルトの設定では、SCP をブラックリストとしてサポートしています。アカウント管理者は、特定のサービスや一連のアクションを拒否する (ブラックリスト化する) ポリシーを作成してアタッチするまで、すべてのサービスとアクションを委譲できます。

これをサポートするため、AWS Organizations は FullAWSAccess という名前の AWS 管理 SCP を作成時にすべてのルートと OU にアタッチします。このポリシーはすべてのサービスとアクションを許可します。ポリシーは AWS 管理 SCP であるため、修正や削除はできません。これはいつでもアタッチしたり、必要に応じて組織のエンティティからデタッチしたりできます。このポリシーは以下のとおりです。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }

これによりアカウント管理者は、特定のアカウントのユーザーおよびロールに実行してほしくないアクションを明示的に禁止する SCP を作成してアタッチするまで、あらゆるサービスやアクションのアクセス権限を移譲できます。

このようなポリシーは、以下の例のようになります。この例では、影響を受けるアカウントのユーザーが DynamoDB サービスのいかなるアクションも実行しないようにします。組織の管理者は、FullAWSAccess ポリシーをデタッチして、これを代わりにアタッチできます。この SCP は、引き続きすべての他のサービスとそのアクションを許可します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowsAllActions", "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Sid": "DenyDynamoDB", "Effect": "Deny", "Action": "dynamodb:*", "Resource": "*" } ] }

2 番目のステートメントにある明示的な Deny 要素が、最初の明示的な Allow よりも優先されるため、影響を受けるアカウントのユーザーは DynamoDB アクションを実行できません。また、FullAWSAccess ポリシーを残して、以下のように、Deny ステートメントのみを持つ 2 番目のポリシーをアタッチして設定することもできます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "dynamodb:*", "Resource": "*" } ] }

FullAWSAccess ポリシーと、ルートまたは OU に適用される前述の DynamoDB ポリシーにある Deny ステートメントの組み合わせには、両方のステートメントを含む単一のポリシーと全く同じ効果があります。特定のレベルに適用するすべてのポリシーはまとめられ、各ステートメントはどのポリシーから派生したものにかかわらず、先に述べたルールに基づいて評価されます (つまり、明示的Deny明示Allowに優先し、これはデフォルトの暗示Denyに優先します)。

SCP ホワイトリストとして使用する

SCP をホワイトリストとして使用するには、AWS 管理 FullAWSAccess SCP を、許可したいサービスやアクションのみを明示的に許可する SCP で置き換える必要があります。デフォルトの FullAWSAccess SCP を削除することで、すべてのサービスのすべてのアクションが暗黙的に拒否されるようになります。そうするとカスタム SCP は、許可したいアクションのみについて、暗示的 Deny を明示的 Allow で上書きします。指定のアカウント、アカウントへの直接パス内の各 OU を通じたルートからの各 SCP、アカウント自体にアタッチされた場合も、有効にするアクセス権限は、そのアクセス権限を許可する必要があります。

このようなホワイトリストポリシーは、以下の例のようになります。これにより、アカウントユーザーは Amazon EC2 および Amazon CloudWatch の操作を実行できるようになりますが、他のサービスは実行できません。親 OU とルート内のすべての SCP も、明示的にこれらのアクセス権限を許可する必要があります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*" ], "Resource": "*" } ] }

このページの内容: