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

SCP 評価

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

SCP と Allow の連携の仕組み

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

例えば、図 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 の使用戦略

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

AWS Organizations は、作成時にすべてのルート、OU、アカウントに FullAWSAccess という名前の AWS マネージド SCP をアタッチします。このポリシーはすべてのサービスとアクションを許可します。FullAWSAccess を一連のサービスのみを許可するポリシーに置き換えて、SCPs を更新することで明示的に許可されない限り、新しい AWS のサービス は許可されません。例えば、組織内で一部のサービスの使用のみを許可したい場合は、Allow ステートメントを使用して特定のサービスのみを許可できます。FullAWSAccess は、ルートレベルまたはすべてのレベルで置き換えることができます。ルートにサービス固有の許可リスト SCP をアタッチすると、その下にあるすべての OUs とアカウントに自動的に適用されます。つまり、シナリオ 7 に示すように、単一のルートレベルのポリシーによって組織全体で有効なサービス許可リストが決定されます。または、各 OU とアカウントで FullAWSAccess を削除して置き換えることもできます。これにより、組織単位または個々のアカウント間で異なるより詳細なサービス許可リストを実装できます。

注: allow ステートメントと暗黙的な deny-by-default モデルのみに依存すると、より広範囲または重複する Allow ステートメントがより制限の厳しいステートメントを上書きできるため、意図しないアクセスにつながる可能性があります。

JSON

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

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

JSON

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

AWS Organization で複数のサービスコントロールポリシー (SCP) を適用する方法を示すために、以下の組織構造とシナリオについて考えてみましょう。

シナリオ 1: 拒否ポリシーの影響

このシナリオは、組織内の上位レベルに拒否ポリシーを設定することが、以下のすべてのアカウントにどのように影響するかを示しています。サンドボックス OU に「フル AWS アクセス」ポリシーとS3 アクセスの拒否」ポリシーの両方があり、アカウント B にEC2 アクセスの拒否」ポリシーがある場合、その結果、アカウント B は S3 (OU レベルの拒否) と EC2 (アカウントレベルの拒否) にアクセスできません。アカウント A は S3 にアクセスできません (OU レベルの拒否により)。

シナリオ 2: 許可ポリシーをすべてのレベルに存在させる必要性

このシナリオは、SCP で許可ポリシーがどのように機能するかを示しています。サービスにアクセスできるようにするには、ルートからアカウントまで、すべてのレベルで明示的な許可が存在する必要があります。ここでは、サンドボックス OU には「EC2 アクセスの許可」ポリシーがあり、これにより EC2 サービスへのアクセスのみが明示的に許可されているため、アカウント A と B は EC2 にのみアクセスできます。

シナリオ 3: ルートレベルで Allow ステートメントが欠落した場合の影響

SCP のルートレベルで「許可」ステートメントが欠落していることは、組織内のすべてのメンバーアカウントの AWS サービスとアクションへのすべてのアクセスを効果的にブロックする重大な設定ミスです。

シナリオ 4: 階層になった Deny ステートメントとその結果発生するアクセス許可

このシナリオは、2 階層にわたる OU 構造を示しています。ルートとワークロードの両方の OU には「フル AWS アクセス」があり、テスト OU には「EC2 AWS アクセスを拒否」がある「フルアクセス」があり、本番稼働用 OU には「フル AWS アクセス」があります。その結果、アカウント D は EC2 を除くすべてのサービスにアクセスすることができ、アカウント E と F はすべてのサービスにアクセスできます。

シナリオ 5: OU レベルのポリシーに許可ポリシーを設けてサービスへのアクセスを制限

このシナリオでは、許可ポリシーを使用して特定のサービスへのアクセスを制限する方法を示しています。Test OU には「EC2 アクセスを許可」ポリシーが設定されています。つまり、EC2 サービスのみがアカウント D に対して許可されています。Production OU は「フル AWS アクセス」に設定されているため、アカウント E と F はすべてのサービスにアクセスできます。これは、ルートレベルでより広範な許可を維持しながら、OU レベルでより厳格な制限の許可ポリシーを実装する方法を示しています。

シナリオ 6: ルートレベルの拒否は、下位レベルの許可に関係なくすべてのアカウントに影響

このシナリオは、ルートレベルに拒否ポリシーがあると、より低いレベルに許可ポリシーがあるかないかに関係なく、組織内のすべてのアカウントに影響することを示しています。ルートには、「フル AWS アクセス」ポリシーとS3 アクセスを拒否」ポリシーの両方があります。Test OU には「S3 アクセスを許可」ポリシーがありますが、この場合、ルートレベルの S3 拒否が優先されます。アカウント D はサービスにアクセスできません。これは、Test OU では S3 へのアクセスのみ許可されているものの、S3 がルートレベルで拒否されているからです。アカウント E と F は S3 を除く他のサービスにアクセスできます。これは、ルートレベルで明示的に拒否されいるからです。

シナリオ 7: ルートレベルのカスタム許可ポリシーが OU レベルのアクセスを制限する

このシナリオでは、明示的なサービス許可リストを持つ SCPs が、 内のルートレベルで適用されるとどのように機能するかを示します AWS Organizations。組織のルートレベルでは、限定された AWS 一連のサービスへのアクセスを明示的に許可する 2 つのカスタムSCPs がアタッチされます。SCP_1 は IAM と Amazon EC2 を許可し、SCP_2 は Amazon S3 と Amazon CloudWatch を許可します。組織単位 (OU) レベルでは、デフォルトの FullAWSAccess ポリシーはアタッチされたままです。ただし、交差動作のため、これらの OUs のアカウント A と B は、ルートレベルの SCP によって明示的に許可されているサービスにのみアクセスできます。より制限の厳しいルートポリシーが優先され、組織レベルで付与されるより広範なアクセス許可に関係なく、IAM、EC2, S3、CloudWatch サービスのみへのアクセスが効果的に制限されます。