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 要素を含めることは一切できません。

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

例えば、 メンバーアカウントが組織を離れるのを禁止する を使用するポリシーをルートレベルで実装すると、組織内のすべてのアカウントに有効になります。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 を適用する方法を理解してください。

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

シナリオ	[ルート] における SCP	[サンドボックス] OU における SCP	[アカウント A] における SCP	[アカウント A] における適用されるポリシー	[アカウント B] と [アカウント C] における適用されるポリシー
1	フル AWS アクセス	フル AWS アクセス + S3 アクセス拒否	フル AWS アクセス + EC2 アクセス拒否	S3 も EC2 もアクセスなし	S3 アクセスなし
2	フル AWS アクセス	Amazon Elastic Compute Cloud (Amazon 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 アクセスを許可する	サービスへのアクセスなし	サービスへのアクセスなし