IAM ロールとリソースベースのポリシーとの相違点
一部の AWS サービスでは、リソースに対するクロスアカウントアクセス許可を付与できます。これを行うには、プロキシとしてロールを使用する代わりに、共有するリソースに直接ポリシーをアタッチします。共有するリソースは、リソースベースのポリシーをサポートしている必要があります。ID ベースのポリシーとは異なり、リソースベースのポリシーは、そのリソースにアクセスできるユーザー(プリンシパル)を指定します。
IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。たとえば、標準 aws
パーティションの米国西部 (北カリフォルニア) にアカウントがあるとします。aws-cn
パーティションの 中国 (北京) にもアカウントがあります。標準 aws
アカウントで、中国 (北京) のアカウントの Amazon S3 リソースベースのポリシーを使用して、ユーザーにアクセスを許可することはできません。
リソースベースのポリシーを使用したクロスアカウントアクセスには、ロールを使用したクロスアカウントアクセスに比べて、いくつかの利点があります。リソースベースのポリシーによってリソースにアクセスする場合、プリンシパルは引き続き信頼されたアカウントで作業を行い、ロールのアクセス許可を受け取るために自身のアクセス許可を放棄する必要はありません。つまり、プリンシパルは信頼されたアカウントのリソースに引き続きアクセス可能である一方で、信頼するアカウントのリソースにもアクセスできます。これは、他のアカウントに属する共有リソースから、また共有リソースへと情報をコピーするといったタスクにおいて便利です。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を参照してください。
リソースベースのポリシーで指定できるプリンシパルには、アカウント、IAM ユーザー、フェデレーティッドユーザー、IAM ロール、引き受けたロールセッション、AWS サービスなどがあります。詳細については、「プリンシパルの指定」を参照してください。
リソースベースのポリシーをサポートする AWS サービスの一部を以下に示します。プリンシパルではなくリソースへのアクセス許可ポリシーのアタッチをサポートする AWS サービスの数が増えている完全なリストについては、AWSIAM と連携する{ut}サービス をご参照の上、[リソースベース] 列で [はい] のあるサービスをお探しください。
-
Amazon S3 バケット – ポリシーはバケットにアタッチされますが、ポリシーによってバケットとバケット内のオブジェクトの両方へのアクセスがコントロールされます。詳細については、Amazon Simple Storage Service ユーザーガイドの「アクセスコントロールリスト (ACL) の概要」を参照してください。
状況によっては、Amazon S3 へのクロスアカウントアクセスにロールを使うのが最適な場合もあります。詳細については、Amazon Simple Storage Service ユーザーガイドの「チュートリアル例」を参照してください。
-
Amazon Simple Notification Service (Amazon SNS) のトピック — 詳細については、Amazon Simple Notification Service デベロッパーガイドの「Amazon SNS トピックへのアクセスの管理」を参照してください。
-
Amazon Simple Queue Service (Amazon SQS) キュー — 詳細については、Amazon Simple Queue Service 開発者ガイドの「付録:アクセスポリシー言語」を参照してください。
リソースベースのポリシーにおける AWS アクセス権限の委任について
リソースがアカウントのプリンシパルにアクセス許可を付与する場合は、そのアクセス許可を特定の IAM ID に委任できます。ID とは、ユーザー、ユーザーのグループ、またはアカウント内のロールです。アクセス許可を委任するには、ポリシーを ID にアタッチします。リソース所有アカウントによって許可される最大数のアクセス許可を付与できます。
リソースベースのポリシーにより、アカウント内のすべてのプリンシパルがリソースへの完全な管理アクセスを許可するとします。すると、AWS アカウントで、プリンシパルへの完全アクセス、読み取り専用アクセス、またはその他の部分的なアクセスを委任できます。また、リソースベースのポリシーでリストアクセス許可のみが許可される場合は、リストアクセスのみを委任できます。アカウントが保持しているものよりも多くのアクセス許可を委任しようとしても、プリンシパルが保持できるのは一覧表示アクセスのみになります。ポリシーを IAM ID にアタッチする方法については、「IAM ポリシーを管理する」を参照してください。
IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。たとえば、標準 aws
パーティションのアカウントと aws-cn
パーティションのアカウントの間にクロスアカウントアクセスを追加することはできません。
たとえば、AccountA
と AccountB
を管理するとします。AccountA
には、BucketA
という名前の Amazon S3 バケットがあります。BucketA
のすべてのプリンシパルにバケット内のオブジェクトへのフルアクセスを許可するリソースベースのポリシーを AccountB
にアタッチします。プリンシパルは、そのバケット内の任意のオブジェクトを作成、読み取り、または削除できます。AccountB
では、User2
という名前の IAM ユーザーにポリシーをアタッチします。このポリシーにより、ユーザーは BucketA
内のオブジェクトへの読み取り専用アクセスを許可します。つまり、User2
はオブジェクトを表示できますが、作成、編集、削除はできません。

-
AccountA
は、リソースベースのポリシーでAccountB
をプリンシパルとして命名することにより、BucketA
へのフルアクセスをAccountB
許可します。その結果、AccountB
はBucketA
で任意のアクションを実行する権限を与えられ、AccountB
管理者はAccountB
のユーザーにアクセス権を委任できます。 -
AccountB
ルートユーザーには、アカウントに付与されるすべてのアクセス許可があります。したがって、ルートユーザーにはBucketA
へのフルアクセス権があります。 -
AccountB
管理者はUser1
へのアクセス権を付与しません。デフォルトでは、ユーザーには明示的に付与されている以外のアクセス許可はありません。したがって、User1
はBucketA
にアクセスできません。 -
AccountB
管理者は、User2
へのBucketA
読み取り専用アクセスを許可 します。User2
はバケット内のオブジェクトを表示できます。AccountB
が委任できるアクセスの最大レベルは、アカウントに付与されるアクセスレベルです。この場合、リソースベースのポリシーではAccountB
への完全アクセス権が付与されますが、User2
は読み取り専用アクセス権のみが付与されます。
IAM では、プリンシパルがリクエストを行った時点でプリンシパルのアクセス許可が評価されます。したがって、ワイルドカード (*) を使用してリソースへのフルアクセスをユーザーに付与すると、プリンシパルは AWS アカウントがアクセスできるすべてのリソースにアクセスできます。これは、ユーザーのポリシーの作成後に追加またはアクセスを得るリソースに対しても当てはまります。
前の例では、AccountB
がすべてのアカウントのすべてのリソースへのフルアクセスを許可する User2
にポリシーをアタッチした場合、User2
は AccountB
にアクセスできるすべてのリソースに自動的にアクセスできます。これには、BucketA
アクセスと AccountA
のリソースベースのポリシーによって付与されたその他のリソースへのアクセスが含まれます。
信頼できるエンティティにだけアクセスを付与し、必要最少レベルのアクセスを提供します。信頼されたエンティティが他の AWS アカウントである場合、そのアカウントは属しているすべての IAM ユーザーにアクセス許可を委任できます。信頼された AWS アカウントは、アクセス権を付与された範囲でのみアクセス権を委任できますが、アカウント自身に付与された範囲を超えるアクセス権を委任することはできません。
権限、ポリシー、ポリシーを作成するのに使用するアクセス許可ポリシー言語の詳細については、「AWS リソースの アクセス管理」を参照してください。