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 リソースの アクセス管理」を参照してください。
