メニュー
AWS Identity and Access Management
ユーザーガイド

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

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

必要に応じて、AssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentity API 呼び出しのパラメータとして個別のポリシーを渡すことができます。渡したポリシーを使用して、一時的なセキュリティ認証情報に割り当てたアクセス権限の範囲を制限します。つまり、ロールのアクセス権限ポリシーによって許可されたアクセス権限の一部のみを許可するようにします。渡したポリシーを使用して、ロールのアクセス権限ポリシーによって許可されている以上のアクセス権限を付与することはできません(絞り込むことのみ可能です)。AssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentity API 呼び出しのパラメータとしてポリシーを渡さない場合、一時的なセキュリティ認証情報にアタッチされるアクセス権限は、引き受けるロールのアクセス権限ポリシーで定義されたアクセス権限と同じです。

AssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentity によって返される一時的なセキュリティ認証情報を使用して AWS リクエストを行うと、AWS は以下のポリシーをすべて評価して、アクセスを許可するか拒否するかを判断します。

  • 先ほど説明したように、引き受けたロールのアクセス権限ポリシーと、API へのパラメータとして渡されたポリシーの組み合わせ。

  • 一時的なセキュリティ認証情報がアクセスするリソースにアタッチされたリソースベースのポリシー(Amazon S3 バケットポリシーなど)。

AWS は、これらのポリシーをすべて使用し、IAM ポリシー評価ロジックに基づいて、"許可" または "拒否" を決定します。

重要なのは、AssumeRole を最初に呼び出した IAM ユーザーまたは認証情報にアタッチされたポリシーは、"許可" または "拒否" を決定するときに AWS によって評価されないことを理解することです。ユーザーは引き受けたロールによって割り当てられたアクセス権限に従って、元のアクセス権限を一時的に放棄します。AssumeRoleWithSAML および AssumeRoleWithWebIdentity API の場合、API の呼び出し元が AWS アイデンティティではないため、評価するポリシーはありません。

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

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

ロールのアクセス権限ポリシー

この例では、AssumeRole API を呼び出し、オプションの Policy パラメータは指定しません。AssumeRole の呼び出しによって返される一時的なセキュリティ認証情報に割り当てられるアクセス権限、つまり、引き受けたロールユーザーに割り当てられるアクセス権限は、引き受けるロールのアクセス権限ポリシーによって決まります。以下の例は、引き受けたロールユーザーが productionapp という名前の S3 バケットに含まれるすべてのオブジェクトを一覧表示し、そのバケット内のオブジェクトを取得、格納、削除するアクセス権限を付与するロールのアクセス権限ポリシーです。

例 ロールのアクセス権限ポリシー

Copy
{ "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 呼び出しのパラメータとしてポリシーを渡すと、引き受けたロールユーザーに有効なアクセス権限は、ロールのアクセス権限ポリシーおよび渡されたポリシーで付与されたアクセス権限のみです。

AssumeRole API 呼び出しで渡すポリシー

Copy
{ "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 ステートメントより常に優先されます。

例 バケットポリシー

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

AWS によって複数のポリシーがどのように組み合わされて評価されているかの詳細については、「IAM ポリシーの評価論理」を参照してください。