翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
SCP 評価
注記
このセクションの情報は、バックアップポリシー、タグポリシー、チャットアプリケーションポリシー、AI サービスのオプトアウトポリシーなどの管理ポリシータイプには適用されません。詳細については、「管理ポリシーの継承を理解する」を参照してください。
AWS Organizationsではさまざまなレベルで複数のサービスコントロールポリシー (SCP) を関連付けることができるため、SCP の評価方法を理解しておくと、正しい結果をもたらす SCP を作成するのに役立ちます。
SCP と Allow の連携の仕組み
特定のアカウントに対してアクセス許可を許可するには、アカウント (ターゲット アカウント自体を含む) への直接パスのルートから各 OU までのすべてのレベルで明示的な Allow ステートメントが必要です。そのため、SCPs を有効にすると、 は FullAWSAccess
例えば、図 1 と図 2 のシナリオを見ていきましょう。アカウント B でアクセス権限またはサービスを許可するには、そのアクセス権限またはサービスを許可する SCP を Production OU であるルート、およびアカウント B 自体にアタッチする必要があります。
SCP の評価はデフォルトで拒否されるモデルに従います。つまり、SCP で明示的に許可されていないアクセス権限はすべて拒否されます。ルート、Production OU、アカウント B などのどのレベルでも SCP に許可ステートメントが存在しない場合、アクセスは拒否されます。
図 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 の使用戦略
SCPs記述するときは、 Allowステートメントと Denyステートメントを組み合わせて使用して、組織内の意図したアクションとサービスを許可できます。 Denyステートメントは、ルートレベルまたは OUsため、組織または OU のより広範な部分に当てはまる制限を実装する強力な方法です。
たとえば、 メンバーアカウントが組織を離れるのを禁止するルートレベルで へのDenyステートメントを使用してポリシーを実装できます。これは、組織内のすべてのアカウントに対して有効です。Deny ステートメントは、例外の作成に役立つ条件要素もサポートしています。
ヒント
IAM でサービスの最終アクセス時間データを使用して SCP を更新し、必要な AWS のサービス のみへのアクセスを制限できます。詳細については、IAM ユーザーガイドの「組織の Organizations サービスの最終アクセス時間データを表示する」を参照してください。
AWS Organizations は、作成時にすべてのルート、OU、アカウントに FullAWSAccessAllow ステートメントを使用して特定のサービスのみを許可できます。
この 2 つのステートメントを組み合わせたポリシーは、次の例のようになります。このポリシーでは、メンバーアカウントが組織から退出することを防ぎ、必要な AWS サービスの使用を許可します。組織の管理者は、[FullAWSAccess] ポリシーをデタッチして、これを代わりにアタッチできます。
組織で複数のサービスコントロールポリシー (SCPs) AWS を適用する方法を示すには、次の組織構造とシナリオを検討してください。
シナリオ 1: 拒否ポリシーの影響
このシナリオは、組織内の上位レベルの拒否ポリシーが、以下のすべてのアカウントにどのように影響するかを示しています。サンドボックス OU に「フル AWS アクセス」ポリシーとS3 アクセスの拒否」ポリシーの両方があり、アカウント B にEC2 アクセスの拒否」ポリシーがある場合、その結果、アカウント B は S3 (OU レベルの拒否から) と EC2 (アカウントレベルの拒否から) にアクセスできなくなります。アカウント A には S3 アクセスがありません (OU レベルの拒否から）。
シナリオ 2: 許可ポリシーはすべてのレベルに存在する必要があります
このシナリオは、許可ポリシーSCPs でどのように機能するかを示しています。サービスにアクセスするには、ルートからアカウントまで、すべてのレベルで明示的な許可が必要です。ここでは、サンドボックス OU にはEC2 アクセスを許可する」ポリシーがあり、EC2 サービスアクセスを明示的にのみ許可するため、アカウント A と B は EC2 アクセスのみを持ちます。
シナリオ 3: ルートレベルで許可ステートメントが欠落した場合の影響
SCP のルートレベルで「許可」ステートメントが欠落していることは、組織内のすべてのメンバーアカウントの AWS サービスとアクションへのすべてのアクセスを効果的にブロックする重大な設定ミスです。
シナリオ 4: Layered Deny ステートメントとその結果のアクセス許可
このシナリオは、2 レベルのディープ OU 構造を示しています。ルートとワークロードの両方の OU には「フル AWS アクセス」があり、テスト OU にはEC2 AWS アクセスを拒否」がある「フルアクセス」があり、本番稼働用 OU には「フル AWS アクセス」があります。その結果、アカウント D には EC2 を除くすべてのサービスアクセスがあり、アカウント E と F にはすべてのサービスアクセスがあります。
シナリオ 5: OU レベルのポリシーにサービスアクセスの制限を許可する
このシナリオでは、許可ポリシーを使用して特定のサービスへのアクセスを制限する方法を示します。テスト OU にはEC2 アクセスを許可する」ポリシーがあります。つまり、EC2 サービスのみがアカウント D に対して許可されます。本番稼働用 OU は「フル AWS アクセス」を保持するため、アカウント E と F はすべてのサービスにアクセスできます。これは、ルートレベルでより広範な許可を維持しながら、OU レベルでより制限の厳しい許可ポリシーを実装する方法を示しています。
シナリオ 6: ルートレベルの拒否は、下位レベルの許可に関係なくすべてのアカウントに影響します
このシナリオは、ルートレベルの拒否ポリシーが、より低いレベルの許可ポリシーに関係なく、組織内のすべてのアカウントに影響することを示しています。ルートには、「フル AWS アクセス」ポリシーとS3 アクセスを拒否」ポリシーの両方があります。Test OU にはS3 アクセスを許可する」ポリシーがありますが、ルートレベルの S3 拒否が優先されます。テスト OU は S3 アクセスのみを許可するため、アカウント D にはサービスアクセスがありませんが、S3 はルートレベルで拒否されます。アカウント E と F は、ルートレベルで明示的に拒否されるため、S3 を除く他のサービスにアクセスできます。
