SCP 評価

注記

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

のさまざまなレベルで複数のサービスコントロールポリシー (SCPs) をアタッチできるため AWS Organizations、 の評価方法を理解することSCPsで、適切な結果が得られるSCPsように記述できます。

Allow のSCPs仕組み

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

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

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

メモ

• の Allowステートメントは、 Resource要素に"*"エントリのみを持つことSCPを許可します。

• の AllowステートメントSCPには、 Condition要素を一切使用できません。

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

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

拒否のSCPs仕組み

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

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

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

を使用するための戦略 SCPs

記述SCPs中に、 Allowステートメントと Denyステートメントを組み合わせて使用して、組織内の意図したアクションとサービスを許可できます。 Denyステートメントは、組織のより広い部分、またはルートレベルまたは OU レベルで適用されると、その下にあるすべてのアカウントに影響するOUsため、 ステートメントは、適用されるべき制限を実装する強力な方法です。

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

ヒント

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

AWS Organizations は、作成時に FullAWSAccessSCPという名前 AWS のマネージド をすべてのルート、OU、アカウントにアタッチします。このポリシーはすべてのサービスとアクションを許可します。FullAWSAccess を一連のサービスのみを許可するポリシーに置き換えて、 を更新することで明示的に許可されない限り AWS のサービス 、新しい は許可されませんSCPs。例えば、組織内で一部のサービスの使用のみを許可したい場合は、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": "*" 
        }
    ]
}

次に、次の組織構造の例を考え、組織内のSCPs異なるレベルで複数の を適用する方法を理解します。

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

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

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

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