IAM でのクロスアカウントのリソースへのアクセス
一部の AWS サービスでは、IAM を使用してリソースへのクロスアカウントアクセスを許可できます。これを行うには、共有するリソースにポリシーを直接アタッチするか、ロールをプロキシとして使用します。
リソースを直接共有するには、共有するリソースでリソースベースのポリシーがサポートされている必要があります。ロールの ID ベースのポリシーとは異なり、リソースベースのポリシーは、そのリソースにアクセスできるユーザー (プリンシパル) を指定します。
リソースベースのポリシーがサポートされていない別のアカウントのリソースにアクセスする場合は、ロールをプロキシとして使用します。
これらのポリシータイプの違いの詳細については、「アイデンティティベースおよびリソースベースのポリシー」を参照してください。
注記
IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。例えば、標準 aws パーティションの米国西部 (北カリフォルニア) にアカウントがあるとします。aws-cn パーティションの中国にもアカウントがあります。中国のアカウントのリソースベースのポリシーを使用して、標準 AWS アカウントのユーザーにアクセスを許可することはできません。
ロールを使用したクロスアカウントアクセス
すべての AWS のサービスがリソースベースのポリシーをサポートしているわけではありません。これらのサービスでは、複数のサービスへのクロスアカウントアクセスを提供する際に、クロスアカウント IAM ロールを使用して許可管理を一元化できます。クロスアカウント IAM ロールとは、別の AWS アカウントの IAM プリンシパルがそのロールを引き受けることを許可する信頼ポリシーを含む IAM ロールです。簡単に言えば、ある AWS アカウントで、特定のアクセス許可を別の AWS アカウントに委任するロールを作成できます。
ポリシーを IAM ID にアタッチする方法については、「IAM ポリシーを管理する」を参照してください。
注記
プリンシパルがロールのアクセス許可の一時的な使用のためにそのロールに切り替えた場合、プリンシパルは元のアクセス許可を放棄して、引き受けたロールに割り当てられたアクセス許可を引き継ぎます。
では、ユーザーアカウントにアクセスする必要がある APN パートナーソフトウェアに適用されるプロセス全体を見ていきましょう。
-
ユーザーは、APN パートナーが必要とする、Amazon S3 リソースへのアクセスを許可するポリシーを含む IAM ロールを、自分のアカウントに作成します。この例では、ロール名は
APNPartnerです。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucket-name" ] } ] } -
次に、ユーザーは、
APNPartnerロールの信頼ポリシーに APN パートナーの AWS アカウント ID を提供して、パートナーの AWS アカウントがそのロールを引き受けることができるように指定します。{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::APN-account-ID:role/APN-user-name" }, "Action": "sts:AssumeRole" } ] } -
ユーザーはロールの Amazon リソースネーム (ARN) を APN パートナーに渡します。ARN はロールの完全修飾名です。
arn:aws:iam::APN-ACCOUNT-ID:role/APNPartner注記
マルチテナントの状況では、外部 ID を使用することをお勧めします。詳細については、「AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法」を参照してください。
-
APN パートナーのソフトウェアがユーザーのアカウントにアクセスする必要がある場合、ソフトウェアはユーザーのアカウント内のロールの ARN を指定して AWS Security Token Service の AssumeRole API を呼び出します。STS は、ソフトウェアが処理を実行できるようにする一時的な AWS 認証情報を返します。
ロールを使用してクロスアカウントアクセスを付与する別の例については、「所有している別の AWS アカウント へのアクセス権を IAM ユーザーに提供」を参照してください。「IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任」の手順に従うこともできます。
リソースベースのポリシーを使用したクロスアカウントアクセス
あるアカウントがリソースベースのポリシーを使用して別のアカウント経由でリソースにアクセスする場合、プリンシパルは引き続き信頼されたアカウントで動作するため、ロールのアクセス許可を受け取るためにプリンシパル自体のアクセス許可を放棄する必要はありません。つまり、プリンシパルは信頼されたアカウントのリソースに引き続きアクセスできるだけでなく、信頼されたアカウントのリソースにもアクセスできます。これは、他のアカウントに属する共有リソースから、また共有リソースへと情報をコピーするといったタスクにおいて便利です。
リソースベースのポリシーで指定できるプリンシパルには、アカウント、IAM ユーザー、フェデレーティッドユーザー、IAM ロール、引き受けたロールセッション、AWS サービスなどがあります。詳細については、「プリンシパルの指定」を参照してください。
信頼ゾーン (信頼された組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「外部エンティティと共有されているリソースを識別する」を参照してください。
リソースベースのポリシーをサポートする AWS サービスの一部を以下に示します。プリンシパルではなくリソースへのアクセス許可ポリシーのアタッチをサポートする AWS サービスの数が増えている完全なリストについては、IAM と連携する AWS のサービス をご参照の上、[リソースベース] 列で [はい] のあるサービスをお探しください。
-
Amazon S3 バケット – ポリシーはバケットにアタッチされますが、ポリシーによってバケットとバケット内のオブジェクトの両方へのアクセスが制御されます。Amazon S3 アクセス許可に関する詳細は、Amazon Simple Storage Service ユーザーガイドの「Access Control」を参照してください。状況によっては、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 にアタッチします。リソース所有アカウントによって許可される最大数のアクセス許可を付与できます。
重要
クロスアカウントアクセスでは、プリンシパルは ID ポリシーおよびリソースベースのポリシー内に Allow を必要とします。
リソースベースのポリシーにより、アカウント内のすべてのプリンシパルがリソースへの完全な管理アクセスを許可するとします。すると、AWS アカウントで、プリンシパルへの完全アクセス、読み取り専用アクセス、またはその他の部分的なアクセスを委任できます。また、リソースベースのポリシーでリストアクセス許可のみが許可される場合は、リストアクセスのみを委任できます。アカウントが保持しているものよりも多くのアクセス許可を委任しようとしても、プリンシパルが保持できるのは一覧表示アクセスのみになります。
これらの決定方法の詳細については、「アカウント内でのリクエストの許可または拒否の決定」を参照してください。
注記
IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。たとえば、標準 aws パーティションのアカウントと aws-cn パーティションのアカウントの間にクロスアカウントアクセスを追加することはできません。
たとえば、AccountA と AccountB を管理するとします。AccountA には、BucketA という名前の Amazon S3 バケットがあります。
-
AccountB のすべてのプリンシパルにバケット内のオブジェクトへのフルアクセスを許可するリソースベースのポリシーを
BucketAにアタッチします。プリンシパルは、そのバケット内の任意のオブジェクトを作成、読み取り、または削除できます。{ "Version": "2012-10-17", "Statement": [ { "Sid": "PrincipalAccess", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::AccountB:root"}, "Action": "s3:*", "Resource": "arn:aws:s3:::BucketA/*" } ] }AccountA は、リソースベースのポリシーで AccountB をプリンシパルとして指定することにより、AccountB に BucketA へのフルアクセスを許可します。その結果、AccountB は BucketA に対してあらゆるアクションを実行する権限が与えられるため、AccountB の管理者は AccountB のユーザーにアクセスを委任できるようになります。
AccountB ルートユーザーは、アカウントに付与されるすべてのアクセス許可を保持しています。したがって、ルートユーザーは BucketA へのフルアクセスを保持しています。
-
AccountB で、User2 という名前の IAM ユーザーにポリシーをアタッチします。このポリシーにより、ユーザーは BucketA 内のオブジェクトへの読み取り専用アクセスが許可されます。つまり、User2 はオブジェクトを表示できますが、オブジェクトの作成、編集、または削除を行うことはできません。
{ "Version": "2012-10-17", "Statement": [ { "Effect" : "Allow", "Action" : [ "s3:Get*", "s3:List*" ], "Resource" : "arn:aws:s3:::BucketA/*" } ] }AccountB が委任できるアクセスの最大レベルは、アカウントに付与されるアクセスレベルです。この場合、リソースベースのポリシーにより AccountB へのフルアクセスが付与されますが、User2 は読み取り専用アクセスのみが付与されます。
AccountB の管理者は、User1 にはアクセス権を付与しません。デフォルトでは、ユーザーは明示的に付与されたアクセス許可以外のアクセス許可を保持していないため、User1 は BucketA にアクセスできません。
IAM では、プリンシパルがリクエストを行った時点でプリンシパルのアクセス許可が評価されます。ワイルドカード (*) を使用してリソースへのフルアクセスをユーザーに付与すると、プリンシパルは AWS アカウントがアクセスできるすべてのリソースにアクセスできます。これは、ユーザーのポリシーの作成後に追加またはアクセスを得るリソースに対しても当てはまります。
前の例では、AccountB がすべてのアカウントのすべてのリソースへのフルアクセスを許可するポリシーを User2 にアタッチしていた場合、User2 は AccountB がアクセスできるすべてのリソースに自動的にアクセスできるようになります。これには、BucketA へのアクセスと AccountA のリソースベースのポリシーによって付与されたその他のリソースへのアクセスが含まれます。
アプリケーションやサービスへのアクセス権の付与など、ロールの複雑な使用方法の詳細については、「ロールの一般的なシナリオ: ユーザー、アプリケーション、およびサービス」を参照してください。
重要
信頼できるエンティティにだけアクセスを許可し、必要最少レベルのアクセスを提供します。信頼されたエンティティが別の AWS アカウントである場合は常に、任意の IAM プリンシパルにリソースへのアクセスを許可できます。信頼された AWS アカウントは、アクセス権を付与された範囲でのみアクセス権を委任できますが、アカウント自身に付与された範囲を超えるアクセス権を委任することはできません。
権限、ポリシー、ポリシーを作成するのに使用するアクセス許可ポリシー言語の詳細については、「AWS リソースの アクセス管理」を参照してください。
