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

SCP 評価

複数のサービスコントロールポリシー (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 ステートメントが に存在しない場合、アクセスは拒否されます。

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

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

Deny SCPs の操作方法

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

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

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

を使用するための戦略 SCPs

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

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

AWS Organizations は、作成時に FullAWSAccess SCPという名前の 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 で有効なポリシーを示しています。

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