SCP 評価 - AWS Organizations

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

SCP 評価

注記

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

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

SCP と Allow の連携の仕組み

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

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

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

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

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

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

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

SCP と Deny の連携の仕組み

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

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

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

SCP の使用戦略

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

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

ヒント

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

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

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

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

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

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

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

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

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

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