クロスアカウントポリシーの評価論理
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 つのアカウント内でリクエストが評価される方法の詳細については、「AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法」を参照してください。リクエストは、両方の評価が Allow
の決定を返す場合にのみ許可されます。
-
あるアカウントのプリンシパルが別のアカウントのリソースにアクセスするためのリクエストを行う場合のリクエストが、クロスアカウントリクエストです。
-
リクエスト元のプリンシパルは、信頼されたアカウント (
AccountA
) に存在します。AWS がこのアカウントを評価すると、ID ベースのポリシー、および ID ベースのポリシーを制限できるすべてのポリシーがチェックされます。詳細については、「アクセス許可の境界を使用したアイデンティティベースのポリシーの評価」を参照してください。 -
リクエストされたリソースは、信頼するアカウント (
AccountB
) に存在します。AWS は、このアカウントを評価するときに、リクエストされたリソースにアタッチされているリソースベースのポリシーと、リソースベースのポリシーを制限できるすべてのポリシーがチェックされます。詳細については、「リソースベースのポリシーを使用したアイデンティティベースのポリシーの評価」を参照してください。 -
AWS は、両方のアカウントポリシー評価でリクエストが許可されている場合にのみリクエストを許可します。
クロスアカウントポリシー評価の例
次の例は、あるアカウントのロールが、別のアカウントのリソースベースのポリシーによって許可が付与されるシナリオを示しています。
Carlos は、アカウント 111111111111 で Demo
という名前の IAM ロールを持つデベロッパーであるとします。アカウント 222222222222 の amzn-s3-demo-bucket-production-logs
Amazon S3 バケットにファイルを保存したいと考えています。
また、次のポリシーを IAM ロール Demo
にアタッチするとします。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "AllowS3ProductionObjectActions", "Effect": "Allow", "Action": "s3:*Object*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*log*", "arn:aws:s3:::*log*/*" ] } ] }
このポリシーの AllowS3ListRead
ステートメントでは、Amazon S3 内のすべてのバケットを一覧表示することを Carlos に許可します。この AllowS3ProductionObjectActions
ステートメントにより、Carlos に amzn-s3-demo-bucket-production
バケットへのフルアクセスが許可されます。
さらに、次のリソースベースのポリシー(バケットポリシー)を 222222222222 アカウントの amzn-s3-demo-bucket-production
バケットにアタッチします。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject*", "s3:ReplicateObject", "s3:RestoreObject" ], "Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" }, "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" } ] }
このポリシーにより、Demo
ロールは amzn-s3-demo-bucket-production
バケット内のオブジェクトにアクセスできます。このロールは、バケット内のオブジェクトを作成および編集することはできますが、削除することはできません。ロールはバケット自体を管理できません。
Carlos がファイルを amzn-s3-demo-bucket-production-logs
バケットに保存することをリクエストすると、AWS はこのリクエストに適用されるポリシーを決定します。この場合、アカウント 111111111111
に適用される唯一のポリシーは、Demo
ロールにアタッチされた ID ベースのポリシーです。アカウント 222222222222
には、amzn-s3-demo-bucket-production-logs
バケットにアタッチされたリソースベースのポリシーはありません。AWS がアカウント 111111111111
を評価するとき、Deny
の決定を返します。これは、ID ベースのポリシーの DenyS3Logs
ステートメントが、ログバケットへのアクセスを明示的に拒否するためです。1 つのアカウント内でリクエストが評価される方法の詳細については、「AWS エンフォースメントコードロジックがリクエストを評価してアクセスを許可または拒否する方法」を参照してください。
リクエストはいずれかのアカウントで明示的に拒否されるため、最終的な決定はリクエストを拒否することです。
Carlos は、その後、間違いに気付き、Production
バケットにファイルを保存しようとするとします。AWS は、最初にアカウント 111111111111
をチェックし、リクエストが許可されるかどうかを判断します。ID ベースのポリシーのみが適用され、リクエストが許可されます。次に、AWS はアカウント 222222222222
をチェックします。Production
バケットにアタッチされたリソースベースのポリシーのみが適用され、リクエストが許可されます。両方のアカウントがリクエストを許可するため、最終的な決定はリクエストを許可することです。