クロスアカウントポリシーの評価論理 - AWS Identity and Access Management
クロスアカウントリクエストが許可されているかどうかを確認クロスアカウントポリシー評価の例

クロスアカウントポリシーの評価論理

1 つのアカウントのプリンシパルが別のアカウントのリソースにアクセスすることを許可できます。これはクロスアカウントアクセスと呼ばれます。クロスアカウントアクセスを許可する場合、プリンシパルが存在するアカウントを信頼されたアカウントと呼びます。リソースが存在するアカウントは、信頼するアカウントです。

クロスアカウントアクセスを許可するには、共有するリソースにリソースベースのポリシーをアタッチします。また、リクエストのプリンシパルとして機能する ID に ID ベースポリシーをアタッチする必要があります。信頼するアカウントのリソースベースのポリシーは、リソースにアクセスできる信頼されるアカウントのプリンシパルを指定する必要があります。アカウント全体を指定することも、その IAM ユーザー、フェデレーティッドユーザー、IAM ロール、または引き受けたロールセッションを指定することもできます。AWS サービスをプリンシパルとして指定することもできます。詳細については、「プリンシパルの指定」を参照してください。

プリンシパルの ID ベースのポリシーは、信頼するサービスにあるリソースへのリクエストされたアクセスを許可する必要があります。これを行うには、リソースの ARN を指定するか、すべてのリソースへのアクセスを許可します (*)。

IAM では、リソースベースのポリシーをロールにアタッチして、他のアカウントのプリンシパルがその IAM ロールを引き受けることを許可できます。ロールのリソースベースのポリシーは、ロールの信頼ポリシーと呼ばれます。そのロールを引き受けると、許可されたプリンシパルは結果として生じる一時的な認証情報を使用して、アカウント内の複数のリソースにアクセスできます。このアクセスは、ロールの ID ベースのアクセス許可ポリシーで定義されます。ロールを使用したクロスアカウントアクセスの許可と、他のリソースベースのポリシーを使用したクロスアカウントアクセスの許可の違いについては、「IAM でのクロスアカウントのリソースへのアクセス」を参照してください。

重要

ポリシー評価ロジックに影響を与えるサービスもあります。たとえば、AWS Organizations は、1 つ以上のアカウントのプリンシパルに適用できるサービスコントロールポリシーをサポートします。AWS Resource Access Manager は、プリンシパルが共有されるリソースに対して実行できるアクションを制御するポリシーフラグメントをサポートします。

クロスアカウントリクエストが許可されているかどうかを確認

クロスアカウントリクエストの場合、信頼済み AccountA のリクエスタには ID ベースのポリシーが必要です。このポリシーでは、信頼する AccountB のリソースへのリクエストを許可する必要があります。また、AccountB のリソースベースのポリシーを使用して、AccountA のリクエスタによるリソースへのアクセスを許可する必要があります。

クロスアカウントリクエストを行うと、AWS は 2 つの評価を実行します。AWS は、信頼するアカウントのリクエストと信頼されるアカウントを評価します。1 つのアカウント内でリクエストが評価される方法の詳細については、「アカウント内でのリクエストの許可または拒否の決定」を参照してください。リクエストは、両方の評価が Allow の決定を返す場合にのみ許可されます。

クロスアカウント評価

  1. あるアカウントのプリンシパルが別のアカウントのリソースにアクセスするためのリクエストを行う場合のリクエストが、クロスアカウントリクエストです。

  2. リクエスト元のプリンシパルは、信頼されたアカウント (AccountA) に存在します。AWS がこのアカウントを評価すると、ID ベースのポリシー、および ID ベースのポリシーを制限できるすべてのポリシーがチェックされます。詳細については、「単一アカウント内のポリシーを評価する」を参照してください。

  3. リクエストされたリソースは、信頼するアカウント (AccountB) に存在します。AWS は、このアカウントを評価するときに、リクエストされたリソースにアタッチされているリソースベースのポリシーと、リソースベースのポリシーを制限できるすべてのポリシーがチェックされます。詳細については、「単一アカウント内のポリシーを評価する」を参照してください。

  4. AWS は、両方のアカウントポリシー評価でリクエストが許可されている場合にのみリクエストを許可します。

クロスアカウントポリシー評価の例

次の例は、あるアカウントのユーザーが、別のアカウントのリソースベースのポリシーによってアクセス許可が付与されるシナリオを示しています。

Carlos は、アカウント 111111111111 で carlossalazar という名前の IAM ユーザーを持つ開発者であるとします。アカウント 222222222222 の Production-logs Amazon S3 バケットにファイルを保存したいと考えています。

また、次のポリシーを IAM ユーザー carlossalazar にアタッチするとします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        },
        {
            "Sid": "AllowS3ProductionObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object*",
            "Resource": "arn:aws:s3:::Production/*"
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::*log*",
                "arn:aws:s3:::*log*/*"
            ]
        }
    ]
}

このポリシーの AllowS3ListRead ステートメントでは、Amazon S3 内のすべてのバケットを一覧表示することを Carlos に許可します。この AllowS3ProductionObjectActions ステートメントにより、Carlos に Production バケットへのフルアクセスが許可されます。DenyS3Logs ステートメントでは、名前に log が含まれている S3 バケットへのアクセスを Carlos に拒否します。また、これらのバケット内のすべてのオブジェクトへのアクセスを拒否します。

さらに、次のリソースベースのポリシー（バケットポリシー）を 222222222222 アカウントの Production バケットにアタッチします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject*",
                "s3:PutObject*",
                "s3:ReplicateObject",
                "s3:RestoreObject"
            ],
            "Principal": { "AWS": "arn:aws:iam::111111111111:user/carlossalazar" },
            "Resource": "arn:aws:s3:::Production/*"
        }
    ]
}

このポリシーにより、carlossalazar ユーザーは Production バケット内のオブジェクトにアクセスできます。バケット内のオブジェクトを作成および編集することはできますが、削除することはできません。バケット自体を管理することはできません。

Carlos がファイルを Production-logs バケットに保存することをリクエストすると、AWS はこのリクエストに適用されるポリシーを決定します。この場合、アカウント 111111111111 に適用される唯一のポリシーは、carlossalazar ユーザーにアタッチされた ID ベースのポリシーです。アカウント 222222222222 には、Production-logs バケットにアタッチされたリソースベースのポリシーはありません。AWS がアカウント 111111111111 を評価するとき、Deny の決定を返します。これは、ID ベースのポリシーの DenyS3Logs ステートメントが、ログバケットへのアクセスを明示的に拒否するためです。1 つのアカウント内でリクエストが評価される方法の詳細については、「アカウント内でのリクエストの許可または拒否の決定」を参照してください。

リクエストはいずれかのアカウントで明示的に拒否されるため、最終的な決定はリクエストを拒否することです。

本稼働ログバケットへのリクエスト

Carlos は、その後、間違いに気付き、Production バケットにファイルを保存しようとするとします。AWS は、最初にアカウント 111111111111 をチェックし、リクエストが許可されるかどうかを判断します。ID ベースのポリシーのみが適用され、リクエストが許可されます。次に、AWS はアカウント 222222222222 をチェックします。Production バケットにアタッチされたリソースベースのポリシーのみが適用され、リクエストが許可されます。両方のアカウントがリクエストを許可するため、最終的な決定はリクエストを許可することです。

本稼働バケットへのリクエスト