AWS Identity and Access Management
ユーザーガイド

AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity のアクセス権限

引き受けるロールのアクセス許可ポリシーによって、AssumeRoleAssumeRoleWithSAML、および AssumeRoleWithWebIdentity によって返る一時的なセキュリティ認証情報のアクセス許可が決まります。これらのアクセス権限は、ロールを作成または更新するときに定義します。

必要に応じて、AssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentity API オペレーションのパラメータとして JSON ポリシーを渡すことができます。このセッションポリシーでは、ロールの一時的な認証情報セッションに対応する範囲にアクセス許可を制限できます。ロールの一時的な認証情報を以降の AWS API コールで使用し、ロールを所有するアカウント内のリソースにアクセスできます。セッションポリシーを使用して、想定されているロールのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。AWS でロールの有効なアクセス許可を決定する方法の詳細については、「ポリシーの評価論理」を参照してください。


      PermissionsWhenPassingRoles_Diagram

AssumeRole を最初に呼び出した認証情報にアタッチされたポリシーは、「許可」または「拒否」承認の決定を行うときに AWS によって評価されません。ユーザーは引き受けたロールによって割り当てられたアクセス権限に従って、元のアクセス権限を一時的に放棄します。AssumeRoleWithSAML および AssumeRoleWithWebIdentity API オペレーションの場合、API の呼び出し元が AWS ID ではないため、評価するポリシーはありません。

例: AssumeRole を使用してアクセス権限を割り当てる

AssumeRole API オペレーションをさまざまなポリシーと共に使用できます。ここにいくつか例を挙げます。

ロールのアクセス許可ポリシー

この例では、オプションの Policy パラメータでセッションポリシーを指定せずに、AssumeRole API オペレーションを呼び出します。一時的な認証情報に割り当てられるアクセス許可は、引き受けるロールのアクセス許可ポリシーによって決まります。次のアクセス許可ポリシーの例では、productionapp という名前の S3 バケットに含まれるすべてのオブジェクトを一覧表示するアクセス許可をロールに付与します。また、このバケット内のオブジェクトを取得、格納、削除することもロールに許可します。

例 ロールのアクセス許可ポリシー

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] }

パラメータとして渡されたセッションポリシー

前の例と同じロールを引き受けることをユーザーに許可すると仮定します。ただし、この場合、オブジェクトを取得して productionapp S3 バケットに配置するためのアクセス許可のみをロールセッションに付与する必要があります。オブジェクトの削除は許可しません。これを実現する 1 つの方法が、新しいロールを作成し、そのロールのアクセス許可ポリシーで目的のアクセス許可を指定することです。もう 1 つの方法では、AssumeRole API を呼び出し、API オペレーションの一部としてオプションの Policy パラメータにセッションポリシーを含めます。結果として得られるセッションには、ロールのアイデンティティベースのポリシーおよびセッションポリシーの両方で付与されるアクセス許可のみが含まれます。このポリシーは、引き受けたロールのアクセス許可を超えて、アクセス許可を昇格することはできないことに注意してください。ロールセッションのアクセス許可の詳細については、「セッションポリシー」を参照してください。

たとえば、API 呼び出しのパラメータとして以下のポリシーを渡すとします。このセッションを使用するユーザーには、次のアクションのみを実行するアクセス許可が付与されています。

  • productionapp バケットのすべてのオブジェクトをリストします。

  • productionapp バケットのオブジェクトを取得し格納します。

次のセッションポリシーでは、s3:DeleteObject アクセス許可は除外され、引き受けたセッションに s3:DeleteObject アクセス許可は付与されません。このポリシーでは、ロールの既存のアクセス許可ポリシーが上書きされるように、ロールセッションのアクセス許可の上限を設定します。

AssumeRole API コールで渡すセッションポリシー

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] }

リソースベースのポリシー

一部の AWS リソースはリソースベースのポリシーをサポートし、このポリシーは一時的なセキュリティ認証情報に影響するアクセス許可を定義する別の仕組みとして利用できます。リソースベースのポリシーをサポートしているのは、Amazon S3 バケット、Amazon SNS トピック、Amazon SQS キューなど、一部のリソースのみです。以下の例では、前の例を拡張して、productionapp という名前の S3 バケットを使用します。以下に挙げるポリシーが、バケットにアタッチされます。

productionapp バケットに以下のリソースベースのポリシーをアタッチすると、すべてのユーザーに対して、バケットからオブジェクトを削除するアクセス許可は拒否されます (ポリシーの Principal 要素に注意)。ロールのアクセス許可ポリシーで DeleteObject アクセス許可が付与されていますが、これには引き受けたすべてのロールユーザーも含まれます。明示的な Deny ステートメントは Allow ステートメントより常に優先されます。

例 バケットポリシー

{ "Version": "2012-10-17", "Statement": { "Principal": {"AWS": "*"}, "Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::productionapp/*" } }

AWS による複数のポリシータイプの組み合わせと評価の詳細については、「ポリシーの評価論理」を参照してください。