IAM ロールとリソースベースのポリシーとの相違点

一部の AWS サービスでは、リソースに対するクロスアカウントアクセス許可を付与できます。これを行うには、プロキシとしてロールを使用する代わりに、共有するリソースに直接ポリシーをアタッチします。共有するリソースは、リソースベースのポリシーをサポートしている必要があります。ID ベースのポリシーとは異なり、リソースベースのポリシーは、そのリソースにアクセスできるユーザー（プリンシパル）を指定します。

注記

IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。たとえば、標準 aws パーティションの 米国西部 (北カリフォルニア) にアカウントがあるとします。aws-cn パーティションの 中国 (北京) にもアカウントがあります。標準 aws アカウントで、中国 (北京) のアカウントの Amazon S3 リソースベースのポリシーを使用して、ユーザーにアクセスを許可することはできません。

リソースベースのポリシーを使用したクロスアカウントアクセスには、ロールを使用したクロスアカウントアクセスに比べて、いくつかの利点があります。リソースベースのポリシーによってリソースにアクセスする場合、プリンシパルは引き続き信頼されたアカウントで作業を行い、ロールのアクセス許可を受け取るために自身のアクセス許可を放棄する必要はありません。つまり、プリンシパルは信頼されたアカウントのリソースに引き続きアクセス可能である一方で、信頼するアカウントのリソースにもアクセスできます。これは、他のアカウントに属する共有リソースから、また共有リソースへと情報をコピーするといったタスクにおいて便利です。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を参照してください。

リソースベースのポリシーで指定できるプリンシパルには、アカウント、IAM ユーザー、フェデレーティッドユーザー、IAM ロール、引き受けたロールセッション、AWS サービスなどがあります。詳細については、「プリンシパルの指定」を参照してください。

リソースベースのポリシーをサポートする AWS サービスの一部を以下に示します。プリンシパルではなくリソースへのアクセス許可ポリシーのアタッチをサポートする、AWS の増え続けるサービスの全一覧については、「IAM と連携する AWS のサービス」を参照してください。これらのサービスでは、「リソースベース」列が「はい」になっています。

• Amazon S3 バケット – ポリシーはバケットにアタッチされますが、ポリシーによってバケットとバケット内のオブジェクトの両方へのアクセスがコントロールされます。詳細については、『Amazon Simple Storage Service 開発者ガイド』の「アクセスコントロール」を参照してください。

  状況によっては、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 バケットがあります。AccountB のすべてのプリンシパルにバケット内のオブジェクトへのフルアクセスを許可するリソースベースのポリシーを BucketA にアタッチします。プリンシパルは、そのバケット内の任意のオブジェクトを作成、読み取り、または削除できます。AccountB では、User2 という名前の IAM ユーザーにポリシーをアタッチします。このポリシーにより、ユーザーは BucketA 内のオブジェクトへの読み取り専用アクセスを許可します。つまり、User2 はオブジェクトを表示できますが、作成、編集、削除はできません。

1. AccountA は、リソースベースのポリシーで AccountB をプリンシパルとして命名することにより、BucketA へのフルアクセスを AccountB 許可します。その結果、AccountB は BucketA で任意のアクションを実行する権限を与えられ、AccountB 管理者は AccountB のユーザーにアクセス権を委任できます。

2. AccountB ルートユーザー には、アカウントに付与されるすべてのアクセス許可があります。したがって、ルートユーザー には BucketA へのフルアクセス権があります。

3. AccountB 管理者は User1 へのアクセス権を付与しません。デフォルトでは、ユーザーには明示的に付与されている以外のアクセス許可はありません。したがって、User1 は BucketA にアクセスできません。

4. AccountB 管理者は、BucketA への User2 読み取り専用アクセスを許可 します。User2 はバケット内のオブジェクトを表示できます。AccountB が委任できるアクセスの最大レベルは、アカウントに付与されるアクセスレベルです。この場合、リソースベースのポリシーでは AccountB への完全アクセス権が付与されますが、User2 は読み取り専用アクセス権のみが付与されます。

IAM では、プリンシパルがリクエストを行った時点でプリンシパルのアクセス許可が評価されます。したがって、ワイルドカード (*) を使用してリソースへのフルアクセスをユーザーに付与すると、プリンシパルは AWS アカウントがアクセスできるすべてのリソースにアクセスできます。これは、ユーザーのポリシーの作成後に追加またはアクセスを得るリソースに対しても当てはまります。

前の例では、AccountB がすべてのアカウントのすべてのリソースへのフルアクセスを許可する User2 にポリシーをアタッチした場合、User2 は AccountB にアクセスできるすべてのリソースに自動的にアクセスできます。これには、BucketA アクセスと AccountA のリソースベースのポリシーによって付与されたその他のリソースへのアクセスが含まれます。

重要

信頼できるエンティティにだけアクセスを付与し、必要最少レベルのアクセスを提供します。信頼されたエンティティが他の AWS アカウントである場合、そのアカウントは属しているすべての IAM ユーザーにアクセス許可を委任できます。信頼された AWS アカウントは、アクセス権を付与された範囲でのみアクセス権を委任できますが、アカウント自身に付与された範囲を超えるアクセス権を委任することはできません。

権限、ポリシー、ポリシーを作成するのに使用するアクセス許可ポリシー言語の詳細については、「AWS リソースのアクセス管理」を参照してください。