SCP 評価 - AWS Organizations

SCP 評価

注記

このセクションの情報は、バックアップポリシー、タグポリシー、チャットボットポリシー、または AI サービスオプトアウトポリシーなどの管理ポリシータイプには適用されません。詳細については、「管理ポリシーの継承を理解する」を参照してください。

AWS Organizations ではさまざまなレベルで複数のサービスコントロールポリシー (SCP) を関連付けることができるため、SCP の評価方法を理解しておくと、正しい結果をもたらす SCP を作成するのに役立ちます。

SCP と Allow の連携の仕組み

特定のアカウントに対してアクセス許可を許可するには、アカウント (ターゲット アカウント自体を含む) への直接パスのルートから各 OU までのすべてのレベルで明示的な Allow ステートメントが必要です。そのため、SCP を有効にすると、AWS Organizations がすべてのサービスとアクションを許可する FullAWSAccess という名前の AWS 管理 SCP ポリシーがアタッチします。このポリシーが組織のどのレベルでも削除され、置き換えられない場合、そのレベルのすべての OU とアカウントはいかなるアクションも実行できなくなります。

例えば、図 1 と図 2 のシナリオを見ていきましょう。アカウント B でアクセス権限またはサービスを許可するには、そのアクセス権限またはサービスを許可する SCP を Production OU であるルート、およびアカウント B 自体にアタッチする必要があります。

SCP の評価はデフォルトで拒否されるモデルに従います。つまり、SCP で明示的に許可されていないアクセス権限はすべて拒否されます。ルート、Production OU、アカウント B などのどのレベルでも SCP に許可ステートメントが存在しない場合、アクセスは拒否されます。

メモ
  • SCP 内の Allow ステートメントにより、Resource 要素に "*" エントリのみを含めることが許可されます。

  • SCP 内の Allow ステートメントには、Condition 要素を含めることは一切できません。

Organizational structure diagram showing Root, OU, and Member accounts with SCP permissions.

図 1: ルート、Production OU、アカウント B に Allow ステートメントがアタッチされた組織構造の例

Organizational structure with Root, OUs, and member accounts showing SCP allow and deny actions.

図 2: Production OU で Allow ステートメントが欠落している組織構造の例と、アカウント B への影響

SCP と Deny の連携の仕組み

特定のアカウントに対するアクセス許可が拒否される場合、ルートからアカウント (ターゲット アカウント自体を含む) への直接パス内の各 OU を経由するすべての SCPがそのアクセス許可を拒否できます。

例えば、Production OU にアタッチされている SCP に、特定のサービスに対して明示的な Deny ステートメントが指定されているとします。また、図 3 に示すように、同じサービスへのアクセスを明示的に許可する別の SCP がルートとアカウント B にアタッチされている場合もあります。その結果、組織内のどのレベルにも適用された拒否ポリシーが、その下にあるすべての OU とメンバーアカウントに対して評価されるため、アカウント A とアカウント B の両方がサービスへのアクセスを拒否されます。

Organizational structure showing Root, OUs, and member accounts with SCP permissions.

図 3: Production OU で Deny ステートメントがアタッチされた組織構造の例と、アカウント B への影響

SCP の使用戦略

SCP を作成する際、AllowDeny ステートメントを組み合わせて使用することで、組織内で意図したアクションやサービスを実現できます。Deny ステートメントは、ルートレベルまたは OU レベルで適用されると、その下にあるすべてのアカウントに影響するため、組織や OU のより広い範囲に適用すべき制限を実装する強力な方法です。

例えば、Deny ステートメントを使用して メンバーアカウントが組織を離れるのを禁止する にルートレベルでポリシーを実装すると、組織内のすべてのアカウントに有効になります。Deny ステートメントは、例外の作成に役立つ条件要素もサポートしています。

ヒント

IAMサービスの最終アクセス時間データを使用して SCP を更新し、必要な AWS のサービスのみへのアクセスを制限できます。詳細については、IAM ユーザーガイドの「組織の Organizations サービスの最終アクセス時間データを表示する」を参照してください。

AWS Organizations は [FullAWSAccess] という名前の AWS 管理の SCP を、すべてのルート、OU とアカウントの作成時にアタッチします。このポリシーはすべてのサービスとアクションを許可します。[FullAWSAccess] をサービスのセットのみを許可するポリシーに置き換えることができます。これにより、SCP の更新によって明示的に許可されない限り、新しい AWS のサービスは許可されません。例えば、組織内で一部のサービスの使用のみを許可したい場合は、Allow ステートメントを使用して特定のサービスのみを許可できます。

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

この 2 つのステートメントを組み合わせたポリシーは、次の例のようになります。このポリシーでは、メンバーアカウントが組織から退出することを防ぎ、必要な AWS サービスの使用を許可します。組織の管理者は、[FullAWSAccess] ポリシーをデタッチして、これを代わりにアタッチできます。

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

次に、以下のサンプル組織構造を検討して、組織内のさまざまなレベルで複数の SCP を適用する方法を理解してください。

Organizational structure diagram showing Root, OUs, and member accounts in a hierarchical layout.

次の表は、サンドボックス OU で有効なポリシーを示しています。

シナリオ [ルート] における SCP [サンドボックス] OU における SCP [アカウント A] における SCP [アカウント A] における適用されるポリシー [アカウント B][アカウント C] における適用されるポリシー
1 フル AWS アクセス フル AWS アクセス + S3 アクセス拒否 フル AWS アクセス + EC2 アクセス拒否 S3 も EC2 もアクセスなし S3 アクセスなし
2 フル AWS アクセス EC2 アクセスを許可する EC2 アクセスを許可する EC2 アクセスを許可する EC2 アクセスを許可する
3 S3 アクセスを拒否する S3 アクセスを許可する フル AWS アクセス サービスへのアクセスなし サービスへのアクセスなし

次の表は、ワークロード OU で有効なポリシーを示しています。

シナリオ [ルート] における SCP [ワークロード] OU における SCP [テスト] OU における SCP [アカウント D] における適用されるポリシー [Production] OU、[アカウント E][アカウント F] における適用されるポリシー
1 フル AWS アクセス フル AWS アクセス フル AWS アクセス + EC2 アクセス拒否 EC2 アクセスなし フル AWS アクセス
2 フル AWS アクセス フル AWS アクセス EC2 アクセスを許可する EC2 アクセスを許可する フル AWS アクセス
3 S3 アクセスを拒否する フル AWS アクセス S3 アクセスを許可する サービスへのアクセスなし サービスへのアクセスなし