AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity のアクセス権限 - AWS Identity and Access Management
例: AssumeRole を使用してアクセス権限を割り当てる

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

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

必要に応じて、インラインまたはマネージド セッションポリシー をAssumeRole、AssumeRoleWithSAML、または AssumeRoleWithWebIdentity API オペレーションのパラメータとして渡すことができます。セッションポリシーは、ロールの一時的な認証情報セッションのアクセス許可を制限します。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。ロールの一時的な認証情報を以降の 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 パラメータにセッションポリシーを含めます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーを使用して、委任されているロールのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。ロールセッションのアクセス許可の詳細については、「セッションポリシー」を参照してください。

新しいセッションの一時的な認証情報を取得した後、それらのアクセス許可を付与するユーザーに取得した認証情報を渡すことができます。

たとえば、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 による複数のポリシータイプの組み合わせと評価の詳細については、「ポリシーの評価論理」を参照してください。