

# IAM アイデンティティ
<a name="id"></a>

IAM アイデンティティは 1 つ以上のポリシーに関連付けることができます。これにより、アイデンティティによる実行が承認されるアクション、実行対象の AWS リソース、実行される条件が決まります。IAM アイデンティティには、IAM ユーザー、IAM グループ、IAM ロールが含まれます。IAM アイデンティティは人間のユーザーまたはプログラムによるワークロードを表すアイデンティティの種類であり、認証して AWS アカウント でアクションを実行するように承認できます。IAM アイデンティティには、IAM ユーザーおよび IAM ロールが含まれます。一般的に使用される用語の定義については、「[用語](introduction_identity-management.md#intro-structure-terms)」を参照してください。

外部 ID プロバイダーから既存の ID をフェデレーションできます。これらの ID は、AWS リソースにアクセスするための IAM ロールを引き受けます。詳細については、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。

AWS IAM アイデンティティセンター を使用して、アイデンティティと AWS リソースへのアクセスを作成および管理することもできます。IAM Identity Center アクセス許可セットは、リソースへのアクセスを提供するために必要な IAM ロールを自動的に作成します。詳細については、「[IAM Identity Center とは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。

AWS アカウントのルートユーザー は、AWS アカウント の確立時に作成される AWS アカウント プリンシパルです。ルートユーザーは、アカウントのすべての AWS サービスとリソースにアクセスできます。詳細については、「[IAM ルートユーザー](#id_root)」を参照してください。

**注記**  
IAM ID を使用する際は、「[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices-use-cases.html)」に従ってください。
ルートユーザーを操作するときは、[AWS アカウント のルートユーザーのベストプラクティス](root-user-best-practices.md)に従ってください。
サインインできない場合は、「[AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)」を参照してください。

## IAM ルートユーザー
<a name="id_root"></a>

AWS アカウント を最初に作成する場合は、アカウントのすべての AWS のサービス とリソースに対して完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。この ID は、AWS アカウント の *root ユーザー*と呼ばれます。詳細については、「[AWS アカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)」を参照してください。

## IAM ユーザー
<a name="id_iam-users"></a>

*IAM ユーザー*は、1 人のユーザーまたは 1 つのアプリケーションに対して特定の許可を持つ AWS アカウント 内のアイデンティティです。詳細については、「[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)」を参照してください。

## IAM ユーザーグループ
<a name="id_iam-groups"></a>

IAM グループは、IAM ユーザーのコレクションを指定するアイデンティティです。詳細については、「[ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)」を参照してください。

## IAM ロール
<a name="id_iam-roles"></a>

*IAM ロール*は、特定の許可を持つ、AWS アカウント内のアイデンティティです。これは IAM ユーザーに似ていますが、詳細のユーザーに関連付けられていません。詳細については、「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」を参照してください。

# AWS アカウントのルートユーザー
<a name="id_root-user"></a>

Amazon Web Services (AWS) アカウントを初めて作成する場合は、このアカウントのすべての AWS サービスとリソースに対して完全なアクセス権限を持つシングルサインインアイデンティティで始めます。このアイデンティティは、AWS アカウントの*ルートユーザー*と呼ばれます。AWS アカウント を作成するために使用したメールアドレスとパスワードは、ルートユーザーとしてサインインするために使用する認証情報です。
+ ルートレベルのアクセス許可を必要とするタスクを実行する場合にのみ、ルートユーザーを使用してください。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、「[ルートユーザー認証情報が必要なタスク](#root-user-tasks)」を参照してください。
+ [AWS アカウント のルートユーザーのベストプラクティス](root-user-best-practices.md)に従ってください。
+ サインインできない場合は、「[AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)」を参照してください。

**重要**  
日常的なタスクにはルートユーザーを使用せず、[AWS アカウントのルートユーザーのベストプラクティス](root-user-best-practices.md)に従うことを強くお勧めします。ルートユーザー資格情報は保護し、ルートユーザーでしか実行できないタスクを実行するときに使用します。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、「[ルートユーザー認証情報が必要なタスク](#root-user-tasks)」を参照してください。

ルートユーザーにはデフォルトで MFA が適用されますが、最初のアカウント作成時またはサインイン時にプロンプトに従って MFA を追加するためには、お客様のアクションが必要です。ルートユーザーを保護するための MFA の使用の詳細については、「[AWS アカウントのルートユーザー の多要素認証](enable-mfa-for-root.md)」を参照してください。

## メンバーアカウントのルートアクセスを一元管理
<a name="id_root-user-access-management"></a>

認証情報を大規模に管理するのに役立つよう、AWS Organizations のメンバーアカウントのルートユーザー認証情報に対するアクセスを一元的に保護できます。AWS Organizations を有効にすると、すべての AWS アカウントを組織に統合して一元管理を実現できます。ルートアクセスを一元化すると、ルートユーザー認証情報を削除し、メンバーアカウントで次の特権タスクを実行できます。

**メンバーアカウントのルートユーザー認証情報を削除する**  
[メンバーアカウントのルートアクセスを一元化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html)したら、Organizations のメンバーアカウントからルートユーザー認証情報を削除することを選択できます。ルートユーザーのパスワード、アクセスキー、署名証明書を削除し、多要素認証 (MFA) を非アクティブ化できます。Organizations で作成した新しいアカウントには、デフォルトでルートユーザー認証情報はありません。メンバーアカウントは、アカウントリカバリが有効になっていない限り、ルートユーザーにサインインしたり、ルートユーザーのパスワードリカバリを実行したりすることはできません。

**ルートユーザー認証情報を必要とする特権タスクを実行する**  
一部のタスクは、アカウントのルートユーザーとしてサインインした場合にのみ実行できます。これらの [ルートユーザー認証情報が必要なタスク](#root-user-tasks) の一部は、管理アカウントまたは IAM の委任された管理者によって実行できます。メンバーアカウントで特権アクションを実行する方法の詳細については、「[特権タスクを実行する](id_root-user-privileged-task.md)」を参照してください。

**ルートユーザーのアカウントリカバリを有効にする**  
メンバーアカウントのルートユーザー認証情報をリカバリする必要がある場合、Organizations 管理アカウントまたは委任された管理者は、**[パスワードリカバリ許可]** 特権タスクを実行できます。メンバーアカウントのルートユーザーの E メール受信トレイにアクセスできるユーザーは、[ルートユーザーのパスワードをリセット](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html)して、ルートユーザー認証情報をリカバリできます。ルートユーザーに対するアクセスを必要とするタスクが完了したら、ルートユーザー認証情報を削除することをお勧めします。

# メンバーアカウントのルートアクセスを一元化する
<a name="id_root-enable-root-access"></a>

ルートユーザー認証情報は、アカウント内のすべての AWS サービスとリソースに完全にアクセスできる各 AWS アカウント に割り当てられた最初の認証情報です。AWS Organizations を有効にすると、すべての AWS アカウントを組織に統合して一元管理を実現できます。各メンバーアカウントには、メンバーアカウントでアクションを実行するためのデフォルトの許可を持つ独自のルートユーザーがあります。ルートユーザー認証情報のリカバリとアクセスを大規模に防ぐために、AWS Organizations を使用して管理される AWS アカウント のルートユーザー認証情報を一元的に保護することをお勧めします。

ルートアクセスを一元化したら、組織内のメンバーアカウントからルートユーザー認証情報を削除できます。ルートユーザーのパスワード、アクセスキー、署名証明書を削除し、多要素認証 (MFA) を非アクティブ化できます。AWS Organizations で作成した新しいアカウントには、デフォルトでルートユーザー認証情報はありません。メンバーアカウントは、ルートユーザーにサインインしたり、ルートユーザーのパスワードリカバリを実行したりできません。

**注記**  
一部の [ルートユーザー認証情報が必要なタスク](id_root-user.md#root-user-tasks) は IAM の管理アカウントまたは委任された管理者が実行できるタスクもありますが、一部のタスクはアカウントのルートユーザーとしてサインインした場合にのみ実行できます。  
これらのタスクのいずれかを実行するためにメンバーアカウントのルートユーザー認証情報を復元する必要がある場合は、[特権タスクを実行する](id_root-user-privileged-task.md) のステップに従って、**[パスワード回復を許可]**を選択します。メンバーアカウントのルートユーザーの E メール受信トレイにアクセスできるユーザーは、[ルートユーザーのパスワードをリセット](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html)し、メンバーアカウントのルートユーザーにサインインする手順を実行できます。  
 ルートユーザーに対するアクセスを必要とするタスクが完了したら、ルートユーザー認証情報を削除することをお勧めします。

## 前提条件
<a name="enable-root-access-management_prerequisite"></a>

ルートアクセスを一元化する前に、次の設定でアカウントを設定する必要があります:
+ IAM アクセス許可を持っている必要があります。
  + `iam:GetAccessKeyLastUsed`
  + `iam:GetAccountSummary`
  + `iam:GetLoginProfile`
  + `iam:GetUser`
  + `iam:ListAccessKeys`
  + `iam:ListMFADevices`
  + `iam:ListSigningCertificates`
  + `sts:AssumeRoot`
**注記**  
メンバーアカウントのルートユーザー認証情報ステータスを監査するには、AWS Organizations メンバーアカウントで特権タスクを実行する際に許可の範囲を狭めるために [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials) AWS マネージドポリシーを使用するか、または `iam:GetAccountSummary` へのアクセス権を持つ任意のポリシーを使用できます。  
ルートユーザーの認証情報レポートを生成するには、他のポリシーで同じ出力を生成する `iam:GetAccountSummary` アクションのみが必要です。次のような個々のルートユーザーの認証情報を一覧表示または取得することも可能です。  
ルートユーザーのパスワードが存在するかどうか
ルートユーザーのアクセスキーが存在するかどうか、および最後に使用された日時
ルートユーザーが署名証明書に関連付けられているかどうか
ルートユーザーに関連付けられた MFA デバイス
統合ルートユーザーの認証情報ステータスのリスト
+ [AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_introduction.html) で AWS アカウント を管理する必要があります。
+ 組織内でこの機能を有効にするには、次の許可が必要です:
  + `iam:EnableOrganizationsRootCredentialsManagement`
  + `iam:EnableOrganizationsRootSessions`
  + `iam:ListOrganizationsFeatures`
  + `organizations:EnableAwsServiceAccess`
  + `organizations:ListAccountsForParent`
  + `organizations:RegisterDelegatedAdministrator` 
+ 最適なコンソール機能を確保するために、次の追加のアクセス許可を有効にすることをお勧めします。
  + `organizations:DescribeAccount`
  + `organizations:DescribeOrganization`
  + `organizations:ListAWSServiceAccessForOrganization`
  + `organizations:ListDelegatedAdministrators`
  + `organizations:ListOrganizationalUnitsForParent`
  + `organizations:ListParents`
  + `organizations:ListTagsForResource`

## 一元化されたルートアクセスの有効化 (コンソール)
<a name="enable-root-access-console"></a>

**AWS マネジメントコンソール のメンバーアカウントでこの機能を有効にするには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. コンソールのナビゲーションペインで、**[ルートアクセス管理]** を選択し、**[有効にする]** を選択します。
**注記**  
**ルートアクセス管理が無効になっている**場合は、AWS Organizations で AWS Identity and Access Management のために信頼されたアクセスを有効にします。詳細については、「*AWS Organizations ユーザーガイド*」の「[AWS IAM と AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-iam.html)」を参照してください。

1. [有効にする機能] セクションで、有効にする機能を選択します。
   + 管理アカウントと IAM の委任された管理者がメンバーアカウントのルートユーザー認証情報の削除することを許可するには、**[ルート認証情報の管理]** を選択します。メンバーアカウントがルートユーザー認証情報を削除した後にその認証情報をリカバリできるようにするには、メンバーアカウントで特権ルートアクションを有効にする必要があります。
   + 管理アカウントと IAM の委任された管理者がルートユーザー認証情報を必要とする特定のタスクを実行することを許可するには、**[メンバーアカウントでの特権ルートアクション]** を選択します。

1. (オプション) ルートユーザーアクセスを管理し、メンバーアカウントで特権アクションを実行するための許可を持つ **[委任された管理者]** のアカウント ID を入力します。セキュリティまたは管理用のアカウントをお勧めします。

1. **[有効化]** を選択します。

## 一元化されたルートアクセスの有効化 (AWS CLI)
<a name="enable-root-access-cli"></a>

**AWS Command Line Interface (AWS CLI) からの一元的なルートアクセスを有効にするには**

1. AWS Organizations で AWS Identity and Access Management のために信頼されたアクセスをまだ有効にしていない場合は、次のコマンドを使用します: [aws organizations enable-aws-service-access](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/organizations/enable-aws-service-access.html)。

1. 管理アカウントと委任された管理者がメンバーアカウントのルートユーザー認証情報を削除することを許可するには、次のコマンドを使用します: [aws iam enable-organizations-root-credentials-management](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-organizations-root-credentials-management.html)。

1. 管理アカウントと委任された管理者がルートユーザー認証情報を必要とする特定のタスクを実行することを許可するには、次のコマンドを使用します: [aws iam enable-organizations-root-sessions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-organizations-root-sessions.html)。

1. (オプション) 委任された管理者を登録するには、次のコマンドを使用します: [aws organizations register-delegated-administrator](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/organizations/register-delegated-administrator.html)。

   次の例では、アカウント 111111111111 を、IAM サービスの委任された管理者として割り当てます。

   ```
   aws organizations register-delegated-administrator 
   --service-principal iam.amazonaws.com
   --account-id 111111111111
   ```

## 一元化されたルートアクセスの有効化 (AWS API)
<a name="enable-root-access-api"></a>

**AWS API からの一元的なルートアクセスを有効にするには**

1. AWS Organizations で AWS Identity and Access Management のために信頼されたアクセスをまだ有効にしていない場合は、次のコマンドを使用します: [EnableAWSServiceAccess](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html)。

1. 管理アカウントと委任された管理者がメンバーアカウントのルートユーザー認証情報を削除することを許可するには、次のコマンドを使用します: [EnableOrganizationsRootCredentialsManagement](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOrganizationsRootCredentialsManagement.html)。

1. 管理アカウントと委任された管理者がルートユーザー認証情報を必要とする特定のタスクを実行することを許可するには、次のコマンドを使用します: [EnableOrganizationsRootSessions](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOrganizationsRootSessions.html)。

1. (オプション) 委任された管理者を登録するには、次のコマンドを使用します: [RegisterDelegatedAdministrator](https://docs.aws.amazon.com/organizations/latest/APIReference/API_RegisterDelegatedAdministrator.html)。

## 次のステップ
<a name="enable-root-access_next-steps"></a>

組織内のメンバーアカウントの特権認証情報を一元的に保護したら、[特権タスクを実行する](id_root-user-privileged-task.md) を参照して、メンバーアカウントで特権アクションを実行します。

# AWS Organizations メンバーアカウントで特権タスクを実行する
<a name="id_root-user-privileged-task"></a>

AWS Organizations 管理アカウントと IAM の委任された管理者アカウントは、メンバーアカウントで、それ以外の場合にはルートユーザー認証情報を必要とする特権タスクを実行できます。一元化されたルートアクセスでは、これらのタスクは短期特権セッションを通じて実行されます。これらのセッションは、メンバーアカウントでルートユーザーのサインインを必要とせずに、特定の特権アクションを対象とする一時的な認証情報を提供します。

特権セッションを立ち上げると、誤って設定された Amazon S3 バケットポリシーの削除、誤って設定された Amazon SQS キューポリシーの削除、メンバーアカウントのルートユーザー認証情報の削除、メンバーアカウントのルートユーザー認証情報の再有効化を行うことができます。

**注記**  
一元化されたルートアクセスを使用するには、管理アカウントまたは委任された管理者アカウントを通じて、`sts:AssumeRoot` アクセス許可を明示的に付与されたIAM ユーザーまたはロールとしてサインインする必要があります。ルートユーザーの認証情報を使用して `sts:AssumeRoot` を呼び出すことはできません。

## 前提条件
<a name="root-user-privileged-task_prerequisite"></a>

特権セッションを立ち上げる前に、次の設定が必要です:
+ 組織内で一元的なルートアクセスを有効にしたこと。この機能を有効にするステップについては、「[メンバーアカウントのルートアクセスを一元化する](id_root-enable-root-access.md)」を参照してください。
+ 管理アカウントまたは委任された管理者アカウントに、次の許可があること: `sts:AssumeRoot`

## メンバーアカウントでの特権アクションの実行 (コンソール)
<a name="root-user-privileged-task_action-console"></a>

**AWS マネジメントコンソール のメンバーアカウントで特権アクションのセッションを立ち上げるには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. コンソールのナビゲーションペインで、**[ルートアクセス管理]** を選択します。

1. メンバーアカウントのリストから名前を選択し、**[特権アクションを実行]** を選択します。

1. メンバーアカウントで実行する特権アクションを選択します。
   + **[Amazon S3 バケットポリシーを削除]** を選択して、すべてのプリンシパルが Amazon S3 バケットにアクセスすることを拒否する、誤って設定されているバケットポリシーを削除します。

     1. **[S3 を参照]** を選択して、メンバーアカウントが所有するバケットから名前を選択し、**[選択]** を選択します。

     1. **[バケットポリシーを削除]** を選択します。

     1. 誤って設定されたポリシーを削除した後に、Amazon S3 コンソールを使用してバケットポリシーを修正します。詳細については、「*Amazon S3 ユーザーガイド*」の「[Amazon S3 コンソールを使用したバケットポリシーの追加](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)」を参照してください。
   + すべてのプリンシパルによる Amazon SQS キューへのアクセスを拒否する Amazon Simple Queue Service リソースベースのポリシーを削除するには、**[Amazon SQS ポリシーを削除]** を選択します。

     1. **[SQS キュー名]** にキュー名を入力し、**[SQS ポリシーを削除]** を選択します。

     1. 誤って設定されたポリシーを削除した後に、Amazon SQS コンソールを使用してキューポリシーを修正します。詳細については、「*Amazon SQS デベロッパーガイド*」の「[Configuring an access policy in Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-add-permissions.html)」を参照してください。
   + メンバーアカウントからルートアクセスを削除するには、**[ルート認証情報を削除]** を選択します。ルートユーザー認証情報を削除すると、ルートユーザーのパスワード、アクセスキー、署名証明書が削除され、該当のメンバーアカウントの多要素認証 (MFA) が非アクティブ化されます。

     1. **[ルート認証情報を削除]** を選択します。
   + メンバーアカウントのルートユーザー認証情報をリカバリするには、**[パスワードのリカバリを許可]** を選択します。

     このオプションは、メンバーアカウントにルートユーザー認証情報がない場合にのみ使用できます。

     1. **[パスワードのリカバリを許可]** を選択します。

     1. この特権アクションを実行すると、メンバーアカウントのルートユーザーの E メール受信トレイにアクセスできるユーザーは、[ルートユーザーのパスワードをリセット](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html)し、メンバーアカウントのルートユーザーにサインインできます。

## メンバーアカウントでの特権アクションの実行 (AWS CLI)
<a name="root-user-privileged-task_action-cli"></a>

**AWS Command Line Interface からメンバーアカウントで特権アクションのセッションを立ち上げるには**

1. ルートユーザーセッションを引き受けるには、次のコマンドを使用します: [aws sts assume-root](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-root.html)。
**注記**  
グローバルエンドポイントは `sts:AssumeRoot` ではサポートされていません。このリクエストはリージョンレベルの AWS STS エンドポイントに送信する必要があります。詳細については、「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」を参照してください。

   メンバーアカウントのために特権ルートユーザーセッションを立ち上げる際には、セッションの範囲が、セッション中に実行される特権アクションに設定されるよう、`task-policy-arn` を定義する必要があります。次のいずれかの AWS マネージドポリシーを使用して、特権セッションのアクションの範囲を設定できます。
   + [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials)
   + [IAMCreateRootUserPassword](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMCreateRootUserPassword)
   + [IAMDeleteRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMDeleteRootUserCredentials)
   + [S3UnlockBucketPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-S3UnlockBucketPolicy)
   + [SQSUnlockQueuePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-SQSUnlockQueuePolicy)

   管理アカウントまたは委任された管理者が特権ルートユーザーセッション中に実行できるアクションを制限するには、AWS STS 条件キー [sts:TaskPolicyArn](reference_policies_iam-condition-keys.md#ck_taskpolicyarn) を使用できます。

    次の例では、委任された管理者がルートを引き受けて、メンバーアカウント ID *111122223333* のルートユーザー認証情報を削除します。

   ```
   aws sts assume-root \
     --target-principal 111122223333 \
     --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials \
     --duration-seconds 900
   ```

1. レスポンスの `SessionToken`、`AccessKeyId`、`SecretAccessKey` を使用し、メンバーアカウントで特権アクションを実行します。リクエストのユーザー名とパスワードを省略して、メンバーアカウントにデフォルト設定できます。
   + **ルートユーザー認証情報のステータスを確認します**。メンバーアカウントのルートユーザー認証情報のステータスを確認するには、次のコマンドを使用します。
     + [get-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-user.html)
     + [get-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-login-profile.html)
     + [list-access-keys](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-access-keys.html)
     + [list-signing-certificates](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-signing-certificates.html)
     + [list-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-mfa-devices.html)
     + [get-access-key-last-used](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-access-key-last-used.html)
   + **ルートユーザー認証情報を削除します**。ルートアクセスを削除するには、次のコマンドを使用します。ルートユーザーのパスワード、アクセスキー、署名証明書を削除し、多要素認証 (MFA) を非アクティブ化して、ルートユーザーに対するすべてのアクセスとルートユーザーのすべてのリカバリを削除できます。
     + [delete-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-login-profile.html)
     + [delete-access-key](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-access-key.html)
     + [delete-signing-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-signing-certificate.html)
     + [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html)
   + **Amazon S3 バケットポリシーを削除します**。すべてのプリンシパルが Amazon S3 バケットにアクセスすることを拒否する、誤って設定されているバケットポリシーを読み取り、編集し、削除するには、次のコマンドを使用します。
     + [list-buckets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/list-buckets.html)
     + [get-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/get-bucket-policy.html)
     + [put-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-policy.html)
     + [delete-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/delete-bucket-policy.html)
   + **Amazon SQS ポリシーを削除します**。すべてのプリンシパルが Amazon SQS キューにアクセスすることを拒否する、Amazon Simple Queue Service のリソースベースのポリシーを表示および削除するには、次のコマンドを使用します。
     + [list-queues](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/list-queues.html)
     + [get-queue-url](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-url.html)
     + [get-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-attributes.html)
     + [set-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/set-queue-attributes.html)
   + **パスワードのリカバリを許可します**。メンバーアカウントのユーザー名を表示し、ルートユーザー認証情報をリカバリするには、次のコマンドを使用します。
     + [get-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-login-profile.html)
     + [create-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-login-profile.html)

## メンバーアカウントでの特権アクションの実行 (AWS API)
<a name="root-user-privileged-task_action-api"></a>

**AWS API からメンバーアカウントで特権アクションのセッションを立ち上げるには**

1. ルートユーザーセッションを引き受けるには、次のコマンドを使用します: [AssumeRoot](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html)。
**注記**  
グローバルエンドポイントは AssumeRoot ではサポートされていません。このリクエストはリージョンレベルの AWS STS エンドポイントに送信する必要があります。詳細については、「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」を参照してください。

   メンバーアカウントのために特権ルートユーザーセッションを立ち上げる際には、セッションの範囲が、セッション中に実行される特権アクションに設定されるよう、`TaskPolicyArn` を定義する必要があります。次のいずれかの AWS マネージドポリシーを使用して、特権セッションのアクションの範囲を設定できます。
   + [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials)
   + [IAMCreateRootUserPassword](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMCreateRootUserPassword)
   + [IAMDeleteRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMDeleteRootUserCredentials)
   + [S3UnlockBucketPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-S3UnlockBucketPolicy)
   + [SQSUnlockQueuePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-SQSUnlockQueuePolicy)

   管理アカウントまたは委任された管理者が特権ルートユーザーセッション中に実行できるアクションを制限するには、AWS STS 条件キー [sts:TaskPolicyArn](reference_policies_iam-condition-keys.md#ck_taskpolicyarn) を使用できます。

   次の例では、委任された管理者は、メンバーアカウント ID *111122223333* の Amazon S3 バケットについて誤って設定されたリソースベースのポリシーを読み取り、編集し、削除するルートを引き受けます。

   ```
   https://sts.us-east-2.amazonaws.com/
     ?Version=2011-06-15
     &Action=AssumeRoot
     &TargetPrincipal=111122223333
     &PolicyArns.arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy 
     &DurationSeconds 900
   ```

1. レスポンスの `SessionToken`、`AccessKeyId`、`SecretAccessKey` を使用し、メンバーアカウントで特権アクションを実行します。リクエストのユーザー名とパスワードを省略して、メンバーアカウントにデフォルト設定できます。
   + **ルートユーザー認証情報のステータスを確認します**。メンバーアカウントのルートユーザー認証情報のステータスを確認するには、次のコマンドを使用します。
     + [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)
     + [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)
     + [ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html)
     + [ListSigningCertificates](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSigningCertificates.html)
     + [ListMFADevices](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADevices.html)
     + [GetAccessKeyLastUsed](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)
   + **ルートユーザー認証情報を削除します**。ルートアクセスを削除するには、次のコマンドを使用します。ルートユーザーのパスワード、アクセスキー、署名証明書を削除し、多要素認証 (MFA) を非アクティブ化して、ルートユーザーに対するすべてのアクセスとルートユーザーのすべてのリカバリを削除できます。
     + [DeleteLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteLoginProfile.html)
     + [DeleteAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html)
     + [DeleteSigningCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSigningCertificate.html)
     + [DeactivateMfaDevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)
   + **Amazon S3 バケットポリシーを削除します**。すべてのプリンシパルが Amazon S3 バケットにアクセスすることを拒否する、誤って設定されているバケットポリシーを読み取り、編集し、削除するには、次のコマンドを使用します。
     + [ListBuckets](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListBuckets.html)
     + [GetBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketPolicy.html)
     + [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html)
     + [DeleteBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketPolicy.html)
   + **Amazon SQS ポリシーを削除します**。すべてのプリンシパルが Amazon SQS キューにアクセスすることを拒否する、Amazon Simple Queue Service のリソースベースのポリシーを表示および削除するには、次のコマンドを使用します。
     + [ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)
     + [GetQueueUrl](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueUrl.html)
     + [GetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html)
     + [SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)
   + **パスワードのリカバリを許可します**。メンバーアカウントのユーザー名を表示し、ルートユーザー認証情報をリカバリするには、次のコマンドを使用します。
     + [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)
     + [CreateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html)

# AWS アカウントのルートユーザー の多要素認証
<a name="enable-mfa-for-root"></a>

**重要**  
AWS では、AWS への MFA で可能な限りパスキーまたはセキュリティキーを使用することをお勧めします。これらはフィッシングなどの攻撃に対する耐性が高いためです。詳細については、「[パスキーとセキュリティキー](#passkeys-security-keys-for-root)」を参照してください。

多要素認証 (MFA) は、セキュリティを強化するためのシンプルで効果的なメカニズムです。1 つ目の要因であるパスワードは、ユーザーが記憶する秘密であり、知識要因とも呼ばれます。その他の要因としては、所有要因 (セキュリティキーなど、ユーザーが持っているもの) や継承要因 (生体認証スキャンなど、ユーザー自身のもの) があります。セキュリティを向上させるには、多要素認証 (MFA) を設定して AWS リソースを保護することを強くお勧めします。

**注記**  
すべての AWS アカウントタイプ (スタンドアロン、管理、メンバーアカウント) では、ルートユーザーに MFA を設定する必要があります。MFA がまだ有効になっていない場合、ユーザーは AWS マネジメントコンソールにアクセスする最初のサインイン試行から 35 日以内に MFA を登録する必要があります。

AWS アカウントのルートユーザー および IAM ユーザーでは、MFA を使用することができます。ルートユーザーの MFA を有効化すると、ルートユーザーの認証情報のみが影響を受けます。IAM ユーザーに対して MFA を有効にする方法の詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。

**注記**  
AWS Organizations を使用して管理される AWS アカウントには、認証情報の復旧と大規模なアクセスを防ぐために、メンバーアカウントの[ルートアクセスを一元管理](id_root-user.md#id_root-user-access-management)するためのオプションがある場合があります。このオプションを有効にすると、パスワードや MFA などのルートユーザー認証情報をメンバーアカウントから削除して、ルートユーザーとしてのサインイン、パスワードの回復、または MFA の設定を効果的に防止できます。または、パスワードベースのサインイン方法を維持する場合は、MFA を登録してアカウントを保護し、アカウントの保護を強化します。

ルートユーザーの MFA を有効にする前に、[アカウント設定と連絡先情報を確認および更新](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-root-user.html)して、E メールと電話番号にアクセスできることを確認してください。MFA デバイスが紛失したり、盗難にあったり、機能しなくなったりしても、そのメールアドレスと電話番号を使用してアイデンティティを確認することで、ルートユーザーとしてサインインできます。代替の認証要素を使用してログインする方法については、「[IAM 内で MFA で保護された ID を復元する](id_credentials_mfa_lost-or-broken.md)」を参照してください｡ この機能を無効にするには、「[AWS サポート](https://console.aws.amazon.com/support/home#/)」にお問い合わせください。

AWS はルートユーザーに対して次の MFA タイプをサポートします。
+ [パスキーとセキュリティキー](#passkeys-security-keys-for-root)
+ [仮想認証アプリケーション](#virtual-auth-apps-for-root)
+ [ハードウェア TOTP トークン](#hardware-totp-token-for-root)

## パスキーとセキュリティキー
<a name="passkeys-security-keys-for-root"></a>

AWS Identity and Access Management は MFA のパスキーとセキュリティキーをサポートします。FIDO 標準に基づいて、パスキーではパブリックキー暗号化が使用され、パスワードよりも安全性の高い、強力でフィッシング耐性のある認証が提供されます。AWS は、デバイスバインドパスキー (セキュリティキー) と同期パスキーの 2 種類のパスキーをサポートしています。
+ **セキュリティキー**: これらは YubiKey などの物理デバイスで、認証の 2 番目の要素として使用されます。1 つのセキュリティキーで、複数のルートユーザーアカウントと IAM ユーザーをサポートできます。
+ **同期パスキー**: これらは、Google、Apple、Microsoft アカウントなどのプロバイダーの認証情報マネージャー、および 1Password、Dashlane、Bitwarden などのサードパーティーサービスを 2 番目の要素として使用します。

Apple MacBook の Touch ID などの組み込みの生体認証機能を使用して、認証情報マネージャーのロックを解除し、AWS にサインインできます。パスキーは、指紋、顔、またはデバイス PIN を使用して、選択したプロバイダーで作成されます。モバイルデバイスやハードウェアセキュリティキーといったデバイスからクロスデバイス認証 (CDA) パスキーを使用して、ラップトップなどの別のデバイスにサインインすることもできます。詳細については、[「Cross-Device Authentication](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda) (CDA)」を参照してください。

デバイス間でパスキーを同期することで、AWS へのサインインが容易になり、使いやすさと回復性が向上します。パスキーとセキュリティキーの有効化の詳細については、「[ルートユーザーのパスキーまたはセキュリティキーを有効にする (コンソール）](enable-fido-mfa-for-root.md)」を参照してください。

FIDO 仕様と互換性のあるすべての [FIDO 認定製品](https://fidoalliance.org/certification/fido-certified-products/)のリストが、FIDO アライアンスから提供されています。

## 仮想認証アプリケーション
<a name="virtual-auth-apps-for-root"></a>

仮想認証アプリケーションは、電話やその他のデバイスで実行され、物理デバイスをエミュレートします。仮想認証アプリは、[タイムベースドワンタイムパスワード (TOTP)](https://datatracker.ietf.org/doc/html/rfc6238) アルゴリズムを実装しており、単一デバイスで複数のトークンをサポートします。ユーザーは、サインイン中にプロンプトが表示されたら、デバイスから有効なコードを入力する必要があります。ユーザーに割り当てられた各トークンは一意であることが必要です。ユーザーは、別のユーザーのトークンからコードを入力して認証を受けることはできません。

ハードウェアの購入承認の待機中、またはハードウェアの到着を待つ間に、仮想 MFA デバイスを使用することをお勧めします。仮想 MFA デバイスとして使用可能なサポートされているアプリケーションのリストについては、「[多要素認証 (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1)」を参照してください。AWS で仮想 MFA デバイスを設定する手順については、「[ルートユーザーの仮想 MFA デバイスを有効にする (コンソール)](enable-virt-mfa-for-root.md)」を参照してください。

## ハードウェア TOTP トークン
<a name="hardware-totp-token-for-root"></a>

ハードウェアデバイスでは、[タイムベースドワンタイムパスワード (TOTP) アルゴリズム](https://datatracker.ietf.org/doc/html/rfc6238)に基づいて 6 桁の数値コードが生成されます。サインイン時に、ユーザーはデバイスから取得した有効なコードを 2 番目のウェブページに入力する必要があります。ユーザーに割り当てられた各 MFA デバイスは一意であることが必要です。ユーザーは、別のユーザーのデバイスからコードを入力して認証することはできません。サポートされているハードウェア MFA デバイスの詳細については、「[多要素認証 (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1)」を参照してください。AWS でハードウェア TOTP デバイスを設定する手順については、「[のルートユーザー (コンソール) 用にハードウェア TOTP トークンを有効にします](enable-hw-mfa-for-root.md)」を参照してください。

物理的な MFA デバイスを使用する場合は、ハードウェア TOTP デバイスの代わりに FIDO セキュリティキーを使用することをお勧めします。FIDO セキュリティキーのメリットは、バッテリーが不要でフィッシング耐性があるという点です。さらには、セキュリティを強化するために、1 台のデバイスで複数のルートユーザーと IAM ユーザーをサポートしています。

**Topics**
+ [

## パスキーとセキュリティキー
](#passkeys-security-keys-for-root)
+ [

## 仮想認証アプリケーション
](#virtual-auth-apps-for-root)
+ [

## ハードウェア TOTP トークン
](#hardware-totp-token-for-root)
+ [

# ルートユーザーのパスキーまたはセキュリティキーを有効にする (コンソール）
](enable-fido-mfa-for-root.md)
+ [

# ルートユーザーの仮想 MFA デバイスを有効にする (コンソール)
](enable-virt-mfa-for-root.md)
+ [

# のルートユーザー (コンソール) 用にハードウェア TOTP トークンを有効にします
](enable-hw-mfa-for-root.md)

# ルートユーザーのパスキーまたはセキュリティキーを有効にする (コンソール）
<a name="enable-fido-mfa-for-root"></a>

ルートユーザーのパスキーは、AWS CLI API や AWS API からではなく、AWS マネジメントコンソール からのみ設定して有効にできます。<a name="enable_fido_root"></a>

**ルートユーザーのパスキーまたはセキュリティキーを有効にするには (コンソール)**

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)を開き、ルートユーザーの認証情報を使用してサインインします。

   手順については、「AWS サインイン ユーザーガイ」の「[ルートユーザーとして AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)」を参照してください。

1. ナビゲーションバーの右側で、使用するアカウント名を選択してから、**[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[ナビゲーションメニューのセキュリティ認証情報\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. ルートユーザーの **[セキュリティ認証情報]** ページの **[多要素認証 (MFA)]** で、**[MFA デバイスの割り当て]** を選択します。

1. **[MFA デバイス名]** ページで、**[デバイス名]** を入力し、**[パスキーまたはセキュリティキー]** を選択し、**[次へ]** を選択します。

1. **[デバイスの設定]** で、パスキーを設定します。顔や指紋などの生体認証データを使用、デバイス PIN を使用、またはコンピュータの USB ポートに FIDO セキュリティキーを挿入してタップすることで、パスキーを作成します。

1. ブラウザの指示に従って、パスキープロバイダーを選択するか、デバイス全体で使用するパスキーを保存する場所を選択します。

1. [**続行**] をクリックしてください。

これで、AWS で使用するパスキーが登録されました。次回にルートユーザーの認証情報を使用してサインインするときは、パスキーで認証してサインインプロセスを完了する必要があります。

FIDO セキュリティキーに関する問題のトラブルシューティングについては、「[FIDO セキュリティキーをトラブルシューティングする](troubleshoot_mfa-fido.md)」を参照してください。

# ルートユーザーの仮想 MFA デバイスを有効にする (コンソール)
<a name="enable-virt-mfa-for-root"></a>

AWS マネジメントコンソール を使用して、仮想 MFA デバイスをルートユーザーが使用できるように設定して有効化することができます。AWS アカウント の MFA デバイスを有効にするには、ルートユーザー認証情報を使用して AWS にサインインしている必要があります。

**仮想 MFA デバイスを設定および有効化してルートユーザーで使用するには (コンソール)**

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)を開き、ルートユーザーの認証情報を使用してサインインします。

   手順については、「AWS サインイン ユーザーガイ」の「[ルートユーザーとして AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)」を参照してください。

1. ナビゲーションバーの右側で、使用するアカウント名を選択してから、**[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[ナビゲーションメニューのセキュリティ認証情報\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. **[Multi-Factor Authentication(MFA)]** (多要素認証 (MFA)) セクションで、**[Assign MFA device]** (MFA デバイスの割り当て) を選択します。

1. ウィザードで **[デバイス名]** を入力し、**[認証アプリ]**、**[次へ]** の順に選択します。

   IAM が QR コードを含む仮想 MFA デバイスの設定情報を生成して表示します。図は、QR コードに対応していないデバイスでの手動入力に利用できるシークレット設定キーを示しています。

1. デバイスで仮想 MFA アプリを開きます。

   仮想 MFA アプリが複数の仮想 MFA デバイスまたはアカウントをサポートしている場合は、新しい仮想 MFA デバイスまたはアカウントを作成するオプションを選択します。

1. QR コードをスキャンするアプリを使用してアプリを設定するのが最も簡単な方法です。QR コードに対応していない場合には、設定情報を手入力します。IAM によって生成された QR コードやシークレット設定キーはお客様の AWS アカウント に紐付けられており、別のアカウントでは使用できません。ただし、元の MFA デバイスが利用できなくなった場合に、これらの情報を再利用してアカウントの新しい MFA デバイスを設定できます。
   + QR コードを使用して仮想 MFA デバイスを設定するには、ウィザードで [**Show QR code (QR コードの表示)**] を選択します。その後、アプリの指示に従ってコードをスキャンします。例えば、カメラアイコンや [**Scan account barcode**] のようなコマンドを選択し、デバイスのカメラを使用してコードを QR スキャンする場合があります。
   + **[Set up device]** (デバイスの設定) ウィザードで、**[Show secret key]** (シークレットキーの表示) を選択し、その後、MFA アプリにシークレットキーを入力します。
**重要**  
QR コードまたはシークレット設定キーの安全なバックアップを作成するか、アカウント用に複数の MFA デバイスを有効にしていることを確認します。AWS アカウントのルートユーザー および IAM ユーザーに対し、「[現在サポートされている MFA タイプ](https://aws.amazon.com/iam/features/mfa/)」の任意の組み合わせで、最大 **8** 台の MFA デバイスを登録できます。例えば、仮想 MFA デバイスがホストされているスマートフォンを紛失した場合などは、仮想 MFA デバイスが使用できなくなる可能性があります。そのような場合で、ユーザーにアタッチされた他の MFA デバイスや、[ルートユーザー MFA デバイスの回復](id_credentials_mfa_lost-or-broken.md#root-mfa-lost-or-broken) を使用してもアカウントにサインインできない場合は、アカウントへのサインインが不能になるので、[カスタマー サービスに連絡](https://support.aws.amazon.com/#/contacts/aws-mfa-support)して MFA によるアカウントの保護を解除する必要があります。

   デバイスは 6 桁の数字の生成を開始します。

1. ウィザードの **[MFA Code 1]** (MFA コード 1) ボックスに、仮想 MFA デバイスに現在表示されているワンタイムパスワードを入力します。デバイスが新しいワンタイムパススワードを生成するまで待ちます (最長 30 秒)。生成されたら [**MFA code 2 (MFA コード 2)**] ボックスに 2 つ目のワンタイムパススワードを入力します。**[Add MFA]** (MFA を追加) を選択します。
**重要**  
コードを生成したら、即時にリクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーとは正常に関連付けられますが、その MFA デバイスは同期されません。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。その場合は、[デバイスの再同期](id_credentials_mfa_sync.md)ができます。

デバイスを AWS で使用する準備が整いました。AWS マネジメントコンソールでの MFA 利用の詳細については、「[MFA 対応のサインイン](console_sign-in-mfa.md)」を参照してください。

# のルートユーザー (コンソール) 用にハードウェア TOTP トークンを有効にします
<a name="enable-hw-mfa-for-root"></a>

ルートユーザーの物理的な MFA デバイスは、AWS CLI または AWS API からではなく、AWS マネジメントコンソール からのみ設定して有効にすることができます。

**注記**  
他のテキスト (例: **MFA を使用してサインイン** や **認証デバイスのトラブルシューティング**) が表示される場合があります。ただし、提供されている機能は同じです。いずれの場合も、認証の代替要因を使用してアカウントの E メールアドレスと電話番号を確認できない場合は、MFA 設定の削除について [AWS サポート](https://aws.amazon.com/forms/aws-mfa-support) にお問い合わせください。<a name="enable_physical_root"></a>

**ルートユーザーのハードウェア TOTP トークンを有効にするには (コンソール)**

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)を開き、ルートユーザーの認証情報を使用してサインインします。

   手順については、「AWS サインイン ユーザーガイ」の「[ルートユーザーとして AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)」を参照してください。

1. ナビゲーションバーの右側で、使用するアカウント名を選択してから、**[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[ナビゲーションメニューのセキュリティ認証情報\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. [**Multi-factor authentication (MFA)**] セクションを展開します。

1. **[Assign MFA device]** (MFA デバイスの割り当て) を選択します。

1. ウィザード内で **[Device name]** (デバイス名) に入力した後、**[Hardware TOTP token]** (ハードウェア TOTP トークン)、**[Next]** (次へ) の順に選択します。

1. [**シリアル番号**] ボックスに MFA デバイス背面に表示されているシリアル番号を入力します。

1. MFA デバイスに表示されている 6 桁の数字を [**MFA code 1 (MFA コード 1)**] に入力します。デバイス前面のボタンを押して数字を表示する場合があります。  
![\[IAM ダッシュボード、MFA デバイス\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/MFADevice.png)

1. デバイスがコードを更新するまで 30 秒ほど待ち、更新後に表示された 6 桁の数字を [**MFA code 2 (MFA コード 2)**] に入力します。デバイス前面のボタンを再度押して新しい数字を表示する場合があります。

1. **[Add MFA]** (MFA を追加) を選択します。これで、MFA デバイスと AWS アカウント の関連付けが完了しました。
**重要**  
認証コードを生成した後すぐに、リクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーとは正常に関連付けられますが、その MFA デバイスは同期されなくなります。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。その場合は、[デバイスの再同期](id_credentials_mfa_sync.md)ができます。

   次回、ルートユーザー認証情報を使ってサインインするときに、MFA デバイスのコードを入力する必要があります。

# AWS アカウントのルートユーザー のパスワードを変更する
<a name="root-user-password"></a>

[[セキュリティ認証情報]](https://console.aws.amazon.com/iam/home?#security_credential) または **[アカウント]** ページにアクセスすると、メールアドレスとパスワードを変更できます。AWS サインインページで **[Forgot password]?** (パスワードを忘れた場合) を選択して、パスワードをリセットすることもできます。

ルートユーザーのパスワードを変更するには、IAM ユーザーではなく、AWS アカウントのルートユーザー としてサインインする必要があります。ルートユーザーパスワードを*忘れた*場合にそれをリセットする方法については、「[紛失または忘れたルートユーザーのパスワードをリセットする](reset-root-password.md)」を参照してください。

パスワードを保護するには、次のベストプラクティスに従う必要があります。
+ パスワードを定期的に変更します。
+ パスワードを知っているユーザーがアカウントにアクセスできるので、パスワードはプライベートに保ちます。
+ AWS では、他のサイトで使用しているものとは異なるパスワードを使用します。
+ 安易に想像できるパスワードは使用しないでください。例えば、`secret`、`password`、`amazon`、`123456` などのパスワードです。また、辞書に載っている単語や氏名、メールアドレスまたはその他の簡単に入手できる個人情報なども含みます。

**重要**  
AWS Organizations を使用した AWS アカウント の管理により、メンバーアカウントのために[一元的なルートアクセス](id_root-user.md#id_root-user-access-management)が有効になる場合があります。これらのメンバーアカウントはルートユーザー認証情報を持っておらず、ルートユーザーとしてサインインできず、ルートユーザーのパスワードをリカバリできません。ルートユーザー認証情報を必要とするタスクを実行する必要がある場合は、管理者に問い合わせてください。

------
#### [ AWS マネジメントコンソール ]

**ルートユーザーのパスワードを変更するには**
**最小アクセス許可**  
以下の手順を実行するには、少なくとも次の IAM アクセス許可が必要です。  
追加の AWS アカウント (IAM) アクセス許可を必要としない AWS Identity and Access Management ルートユーザーとしてサインインする必要があります。IAM ユーザーまたはロールとしてこれらの手順を実行することはできません。

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)を開き、ルートユーザーの認証情報を使用してサインインします。

   手順については、「AWS サインイン ユーザーガイ」の「[ルートユーザーとして AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)」を参照してください。

1. コンソールの右上隅で、アカウント名またはアカウント番号を選択し、続いて **[セキュリティ認証情報]** を選択します。

1. **[アカウント]** ページで、**[アカウント設定]** の横の **[編集]** を選択します。セキュリティ上の理由から、再認証を求められます。
**注記**  
**[編集]** オプションが表示されない場合は、アカウントのルートユーザーとしてログインしていない可能性があります。IAM ユーザーまたはロールとしてサインインしている間は、アカウント設定を変更できません。

1. **[アカウント設定の更新]** ページで、**[パスワード]**、**[編集]** の順に選択します。

1. **[パスワードの更新]** ページで、**[現在のパスワード]**、**[新しいパスワード]**、**[新しいパスワードの確認]** の各フィールドに入力します。
**重要**  
必ず強力なパスワードを選択してください。IAM ユーザー用のアカウントパスワードポリシーを設定することはできますが、このポリシーはルートユーザーには適用されません。

   AWS ではパスワードが以下の条件を満たす必要があります：
   + 8～128 文字で構成されていること。
   + 英字の大文字、英字の小文字、数字、記号 (\$1 @ \$1 \$1 % ^ & \$1 () <> [] \$1\$1 \$1 \$1\$1-=) のうち、少なくとも 3 つの文字タイプを使用する必要があります。
   + AWS アカウント アカウント名またはメールアドレスと同じでないこと。

1. **[Save changes]** (変更の保存) をクリックします。

------
#### [ AWS CLI or AWS SDK ]

このタスクは AWS CLI 内でも AWS SDK のいずれかによる API 操作でもサポートされません。このタスクは、AWS マネジメントコンソール を使用してのみ実行できます。

------

# 紛失または忘れたルートユーザーのパスワードをリセットする
<a name="reset-root-password"></a>

AWS アカウント を初めて作成したときに、E メールアドレスとパスワードを指定しました。これらは、AWS アカウントのルートユーザー 認証情報です。 パスワード ルートユーザーパスワードを忘れた場合は、AWS マネジメントコンソール からパスワードをリセットできます。

AWS Organizations を使用した AWS アカウント の管理により、メンバーアカウントのために[一元的なルートアクセス](id_root-user.md#id_root-user-access-management)が有効になる場合があります。これらのメンバーアカウントはルートユーザー認証情報を持っておらず、ルートユーザーとしてサインインできず、ルートユーザーのパスワードをリカバリできません。ルートユーザー認証情報を必要とするタスクを実行する必要がある場合は、管理者に問い合わせてください。

**重要**  
**AWS へのサインインに問題がある場合** ユーザーのタイプに応じて正しい [AWS サインインページ](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)が表示されていることを確認します。AWS アカウントのルートユーザー (アカウント所有者) の場合は、AWS アカウント の作成時に設定した認証情報を使用して AWS にサインインできます。IAM ユーザーの場合、アカウント管理者から AWS へのサインインに使用可能な認証情報をもらうことができます。サポートをリクエストする必要がある場合、このページのフィードバックリンクは使用しないでください。このフォームは AWS サポートではなく、サポート ドキュメントチームに送信されます。代わりに、「[お問い合わせ](https://aws.amazon.com/contact-us/)」ページで **[AWS アカウントにまだログインできない]** を選択してから、表示されているサポートオプションのいずれかを選択します。

**ルートユーザーパスワードをリセットするには**

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)を開き、ルートユーザーの認証情報を使用してサインインします。

   手順については、「AWS サインイン ユーザーガイ」の「[ルートユーザーとして AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)」を参照してください。
**注記**  
 *IAM ユーザー*認証情報を使用して [AWS マネジメントコンソール](https://console.aws.amazon.com/) にサインインしている場合、ルートユーザーパスワードをリセットするには、まずサインアウトする必要があります。アカウント固有の IAM ユーザーのサインインページが表示された場合は、ページの下部付近にある ** ルートアカウントの認証情報を使用してサインインする** を選択します。必要に応じて、アカウントの E メールアドレスを指定し、[**次へ**] を選択して [**ルートuser sign in (ルートユーザーサインイン)**] ページにアクセスします。

1. [**パスワードを忘れた場合**] を選択します。
**注記**  
IAM ユーザーの場合、このオプションは使用できません。**[パスワードを忘れた場合]** オプションは、ルートユーザーアカウントでのみ使用できます。IAM ユーザーの場合、忘れたパスワードをリセットするには管理者に依頼必要があります。詳細については、「[AWS アカウント のIAMユーザーパスワードを忘れてしまいました](https://docs.aws.amazon.com/signin/latest/userguide/troubleshooting-sign-in-issues.html#troubleshoot-forgot-iam-password)」を参照してください。AWS アクセスポータルからサインインする場合は、「[IAM アイデンティティセンターのユーザーパスワードのリセット](https://docs.aws.amazon.com/singlesignon/latest/userguide/resetpassword-accessportal.html)」を参照してください。

1. アカウントに関連付けられている E メールアドレスを入力します。次に、CAPTCHA のテキストを入力し、**[続行]** を選択します。

1. AWS アカウント に関連付けられている E メールを Amazon Web Services からのメッセージで確認します。メールは `@verify.signin.aws` で終わるアドレスから届きます。E メールの指示にしたがって操作します。アカウントに E メールが表示されない場合は、スパムフォルダを確認してください。メールにアクセスできなくなった場合は、AWS サインイン ユーザーガイドの「[自分の AWS アカウントのメールにアクセスできない](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-troubleshooting.html#credentials-not-working-console)」を参照してください。

# ルートユーザーのアクセスキーを作成する
<a name="id_root-user_manage_add-key"></a>

**警告**  
ルートユーザーのアクセスキーペアを**作成しない**ことを強くお勧めします。[ルートユーザーが必要とするタスクはごくわずか](id_root-user.md#root-user-tasks)であり、これらのタスクは通常、頻繁に実行されないため、AWS マネジメントコンソール にサインインしてルートユーザーのタスクを実行することをお勧めします。アクセスキーを作成する前に、[長期的なアクセスキーの代替案](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys)を確認してください。

お勧めしませんが、AWS Command Line Interface (AWS CLI) または、ルートユーザーの認証情報を使用した AWS SDK のいずれかの API 操作を使用してコマンドを実行できるように、ルートユーザーのアクセスキーを作成できます。アクセスキーを作成するときは、アクセスキー ID とシークレットアクセスキーをセットとして作成します。アクセスキーの作成時に、AWS では、アクセスキーのシークレットアクセスキーの部分を表示およびダウンロードする機会が 1 回限り与えられます。これをダウンロードしない場合や紛失した場合は、アクセスキーを削除して新しいアクセスキーを作成できます。ルートユーザーアクセスキーは、コンソール、AWS CLI、または AWS API で作成できます。

新しく作成したアクセスキーのステータスは *active* になります。これは、CLI および API コール用にこのアクセスキーを使用できる状態です。ルートユーザー に最大 2 つのアクセスキーを割り当てることができます。

使用していないアクセスキーは非アクティブ化する必要があります。アクセスキーが非アクティブになると、そのアクセスキーを API 呼び出しに使用することはできなくなります。非アクティブになったキーも、引き続き制限に対してカウントされます。アクセスキーはいつでも作成したり削除したりすることができます。ただし、一度アクセスキーを削除した場合、永久に削除されて、回復することはできません。

------
#### [ AWS マネジメントコンソール ]

**AWS アカウントのルートユーザー のアクセスキーを作成するには**
**最小アクセス許可**  
以下の手順を実行するには、少なくとも次の IAM アクセス許可が必要です。  
追加の AWS アカウント (IAM) アクセス許可を必要としない AWS Identity and Access Management ルートユーザーとしてサインインする必要があります。IAM ユーザーまたはロールとしてこれらの手順を実行することはできません。

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)を開き、ルートユーザーの認証情報を使用してサインインします。

   手順については、「AWS サインイン ユーザーガイ」の「[ルートユーザーとして AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)」を参照してください。

1. コンソールの右上隅で、アカウント名またはアカウント番号を選択し、続いて **[セキュリティ認証情報]** を選択します。

1. [**Access keys (アクセスキー)**] セクションで、[**Create access key (アクセスキーを作成)**] を選択します。このオプションを使用できない場合は、既に最大数のアクセスキーがあります。新しいキーを作成する前に、既存のアクセスキーのいずれかを削除する必要があります。詳細については、「[IAM オブジェクトクォータ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities)」を参照してください。

1. **[ルートユーザーアクセスキーの代替方法]** ページで、セキュリティに関する推奨事項を確認してください。続行するには、チェックボックスをオンにし、**[アクセスキーの作成]** を選択します。

1. **[アクセスキーの取得]** ページに、**[アクセスキー]** の ID が表示されます。

1. **[シークレットアクセスキー]** で **[表示]** を選択し、ブラウザのウィンドウからアクセス キー ID とシークレットキーをコピーし、どこか別の安全な場所に貼り付けます。また、**[.csv ファイルをダウンロード]** を選択して、アクセスキー ID とシークレットキーが含まれる `rootkey.csv` という名前のファイルをダウンロードすることもできます。そのファイルをどこか安全な場所に保管します。

1. **[完了]** をクリックします。アクセスキーが不要になったら、悪用されることを防ぐために、[そのキーを削除するか](id_root-user_manage_delete-key.md)、少なくとも無効化することを検討してください。

------
#### [ AWS CLI & SDKs ]

**ルートユーザーのアクセスキーを作成するには**
**注記**  
ルートユーザーとして次のコマンドまたは API 操作を実行するには、アクティブなアクセスキーペアが 1 つ必要です。アクセスキーがない場合は、AWS マネジメントコンソール を使用して最初のアクセスキーを作成します。次いで、AWS CLI でその 1 つ目のアクセスキーから得た認証情報を使用して、2 つ目のアクセスキーを作成するか、アクセスキーを削除します。
+ AWS CLI: [aws iam create-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)  
**Example**  

  ```
  $ aws iam create-access-key
  {
      "AccessKey": {
          "UserName": "MyUserName",
          "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
          "Status": "Active",
          "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
          "CreateDate": "2021-04-08T19:30:16+00:00"
      }
  }
  ```
+ AWS API: IAM API リファレンスの [CreateAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html)。

------

# ルートユーザーのアクセスキーを削除する
<a name="id_root-user_manage_delete-key"></a>

AWS マネジメントコンソール、AWS CLI または AWS API を使用して、ルートユーザーアクセスキーを削除できます。

------
#### [ AWS マネジメントコンソール ]

**ルートユーザーのアクセスキーを削除するには**
**最小アクセス許可**  
以下の手順を実行するには、少なくとも次の IAM アクセス許可が必要です。  
追加の AWS アカウント (IAM) アクセス許可を必要としない AWS Identity and Access Management ルートユーザーとしてサインインする必要があります。IAM ユーザーまたはロールとしてこれらの手順を実行することはできません。

1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)を開き、ルートユーザーの認証情報を使用してサインインします。

   手順については、「AWS サインイン ユーザーガイ」の「[ルートユーザーとして AWS マネジメントコンソール にサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)」を参照してください。

1. コンソールの右上隅で、アカウント名またはアカウント番号を選択し、続いて **[セキュリティ認証情報]** を選択します。

1. **[アクセスキー]** セクションで、削除するアクセスキーを選択して、**[アクション]**、**[削除]** の順に選択します。
**注記**  
または、アクセスキーを完全に削除する代わりに **[非アクティブ化]** することもできます。これにより、キー ID またはシークレットキーを変更することなく、後でそのキーの使用を再開できます。非アクティブになっているアクセスキーを AWS API へのリクエストで使用しようとしても、その試みはすべて失敗して、アクセス拒否の状態になります。

1. **[<access key ID> を削除]** ダイアログボックスで、**[非アクティブ化]** を選択し、アクセスキー ID を入力して削除を確認したら、**[削除]** を選択します。

------
#### [ AWS CLI & SDKs ]

**ルートユーザーのアクセスキーを削除するには**
**最小アクセス許可**  
以下の手順を実行するには、少なくとも次の IAM アクセス許可が必要です。  
追加の AWS アカウント (IAM) アクセス許可を必要としない AWS Identity and Access Management ルートユーザーとしてサインインする必要があります。IAM ユーザーまたはロールとしてこれらのステップを実行することはできません。
+ AWS CLI: [aws iam delete-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)  
**Example**  

  ```
  $ aws iam delete-access-key \
      --access-key-id AKIAIOSFODNN7EXAMPLE
  ```

  このコマンドが成功した場合、出力は生成されません。
+ AWS API: [DeleteAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html) 

------

## ルートユーザー認証情報が必要なタスク
<a name="root-user-tasks"></a>

日常的なタスクを実行したり、AWS リソースにアクセスしたりするには、[AWS IAM アイデンティティセンター で管理者ユーザーを設定](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)することをお勧めします。ただし、アカウントのルートユーザーとしてサインインする場合にのみ、以下に示すタスクを実行できます。

AWS Organizations のメンバーアカウント全体で特権ルートユーザー認証情報の管理を簡素化するには、AWS アカウント に対する高度な特権アクセスを一元的に保護するのに役立つよう、一元化されたルートアクセスを有効にできます。[メンバーアカウントのルートアクセスを一元管理](#id_root-user-access-management) を使用すると、長期的なルートユーザー認証情報のリカバリを一元的に削除して防止し、組織内のアカウントセキュリティを改善できます。この機能を有効にすると、メンバーアカウントで次の特権タスクを実行できます。
+ ルートユーザーのアカウントリカバリを防ぐには、メンバーアカウントのルートユーザー認証情報を削除します。また、メンバーアカウントのルートユーザー認証情報をリカバリするためのパスワードのリカバリを許可することもできます。
+ すべてのプリンシパルが Amazon S3 バケットにアクセスすることを拒否する、誤って設定されたバケットポリシーを削除します。
+ すべてのプリンシパルによる Amazon SQS キューへのアクセスを拒否する Amazon Simple Queue Service リソースベースのポリシーを削除します。

**アカウント管理タスク**
+ [AWS アカウント設定を変更する。](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-root-user.html)AWS Organizations に属さないスタンドアロンの AWS アカウントが E メールアドレス、ルートユーザーパスワード、ルートユーザーアクセスキーを更新するには、ルート認証情報が必要です。アカウント名、連絡先情報、代替連絡先情報、支払い通貨設定、AWS リージョンなどのその他のアカウント設定については、ルートユーザー認証情報は不要です。
**注記**  
AWS Organizations (すべての機能が有効化されている場合) は、管理アカウントと委任された管理者アカウントからメンバーアカウント設定を一元的に管理するために使用できます。管理アカウントと委任された管理者アカウントの両方で承認された IAM ユーザーまたは IAM ロールは、メンバーアカウントの閉鎖や、ルート E メールアドレス、アカウント名、連絡先情報、代替連絡先情報、およびメンバーアカウントの AWS リージョンの更新を実行できます。
+ [AWS アカウントを閉鎖する。](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html)AWS Organizations に属さないスタンドアロンの AWS アカウントがアカウントを閉鎖するには、ルート認証情報が必要です。AWS Organizations では、管理アカウントと委任された管理者アカウントからメンバーアカウントを一元的に閉鎖することができます。
+ [IAM ユーザーアクセス許可を更新します。](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)唯一の IAM 管理者が自身のアクセス許可を誤って取り消した場合は、ルートユーザーとしてサインインしてポリシーを編集し、アクセス許可を復元できます。

**請求タスク**
+ [請求情報とコスト管理コンソールへの IAM アクセスをアクティブにする](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html#ControllingAccessWebsite-Activate)
+ 一部の請求タスクはルートユーザーに限定されます。詳細については、AWS Billingユーザーガイドの「[AWS アカウントの管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html)」を参照してください。
+ 特定の税金請求書を表示します。[aws-portal:ViewBilling](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-permissions-ref.html#user-permissions) 許可を持つ IAM ユーザーは、AWS Europe から VAT 請求書を表示およびダウンロードすることができますが、AWS Inc または Amazon Internet Services Private Limited (AISPL) からはできません。

**AWS GovCloud (US) タスク**
+ [AWS GovCloud (US) にサインアップします](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/getting-started-sign-up.html)。
+ AWS GovCloud (US) アカウントに AWS サポート からのルートユーザーアクセスキーを要求します。

**Amazon EC2 タスク**
+ リザーブドインスタンスマーケットプレイスに[出品者として登録します](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-general.html)。

**AWS KMS タスク**
+ AWS Key Management Service キーが管理不能になった場合、管理者は サポート に連絡して再び管理可能にできます。ただし、サポート はルートユーザーのプライマリ電話番号に応答して、チケット OTP の確認による認可をします。

**Amazon Mechanical Turk タスク**
+  [AWS アカウントを MTurk リクエスタアカウントにリンクします](https://docs.aws.amazon.com/AWSMechTurk/latest/AWSMechanicalTurkGettingStartedGuide/SetUp.html#accountlinking)。

**Amazon Simple Storage Service Tasks**
+ [MFA (多要素認証)に対応するように Amazon S3 バケットを設定します](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html)。
+ [すべてのプリンシパルを拒否する Amazon S3 バケットを編集または削除します](https://aws.amazon.com/premiumsupport/knowledge-center/change-vpc-endpoint-s3-bucket-policy/)。

  特権アクションを使用すると、設定ミスのあるバケットポリシーを持つ Amazon S3 バケットのロックを解除できます。詳細については、「[AWS Organizations メンバーアカウントで特権タスクを実行する](id_root-user-privileged-task.md)」を参照してください。

**Amazon Simple Queue Service Task**
+ [すべてのプリンシパルを拒否する Amazon SQS リソースベースのポリシーを編集または削除します](https://aws.amazon.com/premiumsupport/knowledge-center/sqs-queue-access-issues-deny-policy)。

  特権アクションを使用すると、設定ミスのあるリソースベースのポリシーを持つ Amazon SQS キューのロックを解除できます。詳細については、「[AWS Organizations メンバーアカウントで特権タスクを実行する](id_root-user-privileged-task.md)」を参照してください。

## その他のリソース
<a name="id_root-user-resources"></a>

AWS ルートユーザーの詳細については、次のリソースを参照してください:
+ ルートユーザーの問題については、「[ルートユーザーに関する問題をトラブルシューティングする](troubleshooting_root-user.md)」を参照してください。
+ AWS Organizations のルートユーザーの E メールアドレスを一元的に管理するには、「*AWS Organizations ユーザーガイド*」の「[メンバーアカウントのルートユーザーの E メールアドレスを更新する](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_primary_email.html)」を参照してください。

以下の記事では、ルートユーザーの操作に関するさらに詳細な情報を提供しています。
+ [AWS アカウント とそのリソースを保護するためのベストプラクティスにはどのようなものがありますか?](https://repost.aws/knowledge-center/security-best-practices)
+ [ルートユーザーが使用されたことを通知する EventBridge イベントルールを作成する方法とは?](https://repost.aws/knowledge-center/root-user-account-eventbridge-rule)
+ [AWS アカウントのルートユーザー アクティビティを監視して通知する](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/) 
+ [IAM ルートユーザーのアクティビティを監視する](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-iam-root-user-activity.html) 

# IAM ユーザー
<a name="id_users"></a>

**重要**  
 IAM [ベストプラクティス](best-practices.md)では、長期的な認証情報を持つIAMユーザーを使用するのではなく、一時的な認証情報を使用して AWS にアクセスするために、IDプロバイダーとのフェデレーションを使用することを人間ユーザーに求めることを推奨します。IAM ユーザーは、フェデレーションユーザーでサポートされていない[特定のユースケース](gs-identities-iam-users.md)にのみ使用することをお勧めします。

IAM ユーザーは、AWS アカウント で作成したエンティティです。IAM ユーザーは、IAM ユーザーを使用して AWS リソースとやりとりする人間のユーザーまたはワークロードを表します。IAM ユーザーは名前と認証情報で構成されます。

管理者アクセス許可を持つ IAM ユーザーが AWS アカウントのルートユーザー ということではありません。ルートユーザー の詳細については、「[AWS アカウントのルートユーザー](id_root-user.md)」を参照してください。

## AWS が IAM ユーザーを識別する方法
<a name="id_users_create_aws-identifiers"></a>

IAM ユーザーを作成すると、IAM はそのユーザーを識別するための以下の手段を作成します。
+ IAM ユーザーの「フレンドリ名」。IAM ユーザーを作成したときに指定した名前です (`Richard`、`Anaya` など)。これは、AWS マネジメントコンソール に表示される名前です。IAM ユーザー名は Amazon リソースネーム (ARN) に表示されるため、IAM 名に個人識別情報を含めることはお勧めしません。IAM 名の要件と制限については、「[IAM 名前の要件](reference_iam-quotas.md#reference_iam-quotas-names)」 を参照してください。
+ IAM ユーザーの Amazon リソースネーム (ARN)。AWS 全体で IAM ユーザーを一意に識別する必要がある場合は、ARN を使用します。例えば、ARN を使用して、Amazon S3 バケットの IAM ポリシーの `Principal` として IAM ユーザーを指定できます。IAM ユーザーの ARN は次の例のように表示されます。

  `arn:aws:iam::account-ID-without-hyphens:user/Richard`
+ IAM ユーザー用の一意の識別子。この ID が返されるのは、API、Tools for Windows PowerShell または AWS CLI を使用して IAM ユーザーを作成した場合だけです。この ID はコンソールには表示されません。

これらの ID の詳細については[IAM ID](reference_identifiers.md)を参照してください。

## IAM ユーザーと認証情報
<a name="id_users_creds"></a>

AWS には、IAM ユーザーの認証情報に応じてさまざまな方法でアクセスできます。
+ [**コンソールパスワード**](id_credentials_passwords.md): AWS マネジメントコンソール などのインタラクティブセッションにサインインするときに IAM ユーザーが入力するパスワード。IAM ユーザーのパスワード (コンソールアクセス) を無効化すると、サインイン認証情報を使用して AWS マネジメントコンソール にサインインできなくなります。アクセス許可を変更したり、想定されたロールを使用してコンソールにアクセスすることを妨げたりすることはありません。コンソールアクセスが有効になっている IAM ユーザーは、これらの同じ認証情報を使用して、AWS CLI および SDK アクセスを `aws login` AWS CLI コマンドを使用して認証することもできます。これらのユーザーには [SignInLocalDevelopmentAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SignInLocalDevelopmentAccess.html) アクセス許可が必要です。詳細については、「*AWS Command Line Interfaceユーザーガイド*」の「[AWS CLI に対する認証とアクセスコントロール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html)」を参照してください。
+ [**アクセスキー**](id_credentials_access-keys.md): AWS へのプログラムによる呼び出しに使用されます。ただし、IAM ユーザーのアクセスキーを作成する前に検討すべきより安全な代替手段があります。詳細については、「AWS 全般のリファレンス」の「[長期的なアクセスキーの考慮事項と代替方法](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#alternatives-to-long-term-access-keys)」を参照してください。IAM ユーザーがアクティブなアクセスキーを持っている場合、それらのキーは引き続き機能し、AWS CLI、Tools for Windows PowerShell、AWS API、または AWS Console Mobile Application 用のツールを介したアクセスを許可します。
+ [**CodeCommit で使用する SSH キー**](id_credentials_ssh-keys.md): CodeCommit での認証に使用可能な OpenSSH 形式の SSH パブリックキー。
+ [**サーバー証明書**](id_credentials_server-certs.md): AWS の一部のサービスでの認証に使用可能な SSL/TLS 証明書。AWS Certificate Manager (ACM) を使用してサーバー証明書のプロビジョニング、管理、デプロイを行うことをお勧めします。ACM でサポートされていないリージョンで HTTPS 接続をサポートする必要があるときにのみ、IAM を使用してください。ACM をサポートするリージョンについては、「AWS 全般のリファレンス」の「[AWS Certificate Manager エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/acm.html)」を参照してください。

IAM ユーザーに適した認証情報を選択できます。AWS マネジメントコンソール を使用して IAM ユーザーを作成するときは、少なくともコンソールパスワードまたはアクセスキーを含める選択をする必要があります。デフォルトでは、AWS CLI または AWS API を使用して作成された新しい IAM ユーザーには、どのような種類の認証情報も提供されていません。ユースケースに基づいて、IAM ユーザーに合った種類の認証情報を作成する必要があります。

パスワード、アクセスキー、および多要素認証 (MFA) デバイスの管理には、以下のオプションがあります。
+ **[IAM ユーザーのパスワードを管理します](id_credentials_passwords.md)。**AWS マネジメントコンソール へのアクセスを許可するパスワードを作成および変更します。最低限のパスワードの複雑さを強制するパスワードポリシーを設定します。IAM ユーザーが自分のパスワードを変更できるようにします。
+ **[IAM ユーザーのアクセスキーを管理します](id_credentials_access-keys.md)。**アカウントのリソースにプログラムでアクセスするためのアクセスキーを作成および更新します。
+ **[IAM ユーザーの多要素認証 (MFA) を有効化する](id_credentials_mfa.md)。**[ベストプラクティス](best-practices.md)として、アカウントのすべての IAM ユーザーに対して、多要素認証を要求することをお勧めします。MFA を使用する場合、IAM ユーザーは 2 つの形式の ID を指定する必要があります。まず、ユーザー ID の一部である認証情報 (パスワードまたはアクセスキー) を指定します。さらに、一時的な数値コードを指定します。この数値コードは、ハードウェアデバイスか、スマートフォンまたはタブレットのアプリケーションで生成されます。
+ **[使用されていないパスワードおよびアクセスキーを見つけます](id_credentials_finding-unused.md)。**アカウントのパスワードまたはアクセスキーを持つユーザー、またはアカウント内の IAM ユーザーであれば、だれでも AWS リソースにアクセスできます。セキュリティ保護のための[ベストプラクティス](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html)は、IAM ユーザーがパスワードやアクセスキーを使用しなくなったら、それらを削除することです。
+ **[アカウントの認証情報レポートをダウンローします](id_credentials_getting-report.md)。**アカウント内のすべての IAM ユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成し、ダウンロードできます。パスワードおよびアクセスキーについては、パスワードやアクセスキーが最近いつ使用されたかが、認証情報レポートに表示されます。

## IAM ユーザーおよびアクセス許可
<a name="id_users_perms"></a>

デフォルトでは、新しい IAM ユーザーには、何かを実施するための[アクセス許可](access.md)がありません。AWS オペレーションの実行や AWS リソースへのアクセスを認可されていません。個々の IAM ユーザーを持つ利点は、アクセス許可を各ユーザーに個別に割り当てることができることです。管理アクセス許可を複数のユーザーに割り当てることができます。これらのユーザーは、AWS リソースを管理するだけでなく、他の IAM ユーザーを作成して管理することもできます。ただし、通常、ユーザーのアクセス許可はユーザーの作業に必要なタスク (AWS アクションまたはオペレーション) とリソースだけに制限します。

Diego というユーザーを想定します。IAM ユーザー `Diego` を作成する際には、そのパスワードを作成し、特定の Amazon EC2 インスタンスの開始と Amazon RDS データベース内のテーブルの情報の読み取り (`GET`) を行うことができるアクセス許可をアタッチします。IAM ユーザーを作成して初期認証情報とアクセス許可を付与する手順については、「[AWS アカウント で IAM ユーザーを作成する](id_users_create.md)」を参照してください。既存のユーザーのアクセス許可を変更する手順については、「[IAM ユーザーのアクセス許可を変更する](id_users_change-permissions.md)」を参照してください。ユーザーのパスワードやアクセスキーを変更する手順については、「[AWS のユーザーパスワード](id_credentials_passwords.md)」と「[IAM ユーザーのアクセスキーを管理します。](id_credentials_access-keys.md)」を参照してください。

IAM ユーザーにアクセス許可の境界を追加することもできます。アクセス許可の境界は、AWS 管理ポリシーを使用してアイデンティティベースのポリシーで IAM ユーザーまたはロールに付与できるアクセス許可の上限を設定できる高度な機能です。ポリシーのタイプと用途の詳細については、「[AWS Identity and Access Management でのポリシーとアクセス許可](access_policies.md)」を参照してください。

## IAM ユーザーとアカウント
<a name="id_users_accounts"></a>

各 IAM ユーザーが関連付けられる AWS アカウント は 1 つだけです。IAM ユーザーは AWS アカウント 内で定義されているため、AWS のファイルに対する支払方法を持つ必要はありません。アカウント内の IAM ユーザーユーザーが実行したすべての AWS アクティビティは、お客様のアカウントに請求されます。

AWS アカウントの IAM リソースの数とサイズには制限があります。詳細については、「[IAM と AWS STSクォータ](reference_iam-quotas.md)」を参照してください。

## IAM ユーザーとサービスアカウント
<a name="id_users_service_accounts"></a>

IAM ユーザーは、関連付けられた認証情報とアクセス権限を持つ、IAM のリソースです。IAM ユーザーは、認証情報を使用して AWS リクエストを行う人物またはアプリケーションを表すことができます。これは通常、*サービスアカウント*と呼ばれます。IAM ユーザーの長期的な認証情報を使用することを選択した場合は、**アプリケーションコードに直接アクセスキーを埋め込まないでください。**AWS SDK と AWS Command Line Interface では、既知のロケーションにアクセスキーを置くことができるため、コードで保持する必要はありません。詳細については、 「AWS 全般のリファレンス」の「[IAM ユーザーアクセスキーを適切に管理する](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#iam-user-access-keys)」を参照してください。または、ベストプラクティスとして、[長期的なアクセスキーの代わりに一時的なセキュリティ認証情報 (IAM ロール) を使用できます](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#use-roles)。

# IAM ユーザーが AWS にサインインする方法
<a name="id_users_sign-in"></a>

IAM ユーザーとして AWS マネジメントコンソール にサインインするには、ユーザー ID またはアカウントエイリアスを入力する必要があります。管理者がコンソールで IAM ユーザーを作成しましたにサインインすると、ユーザー名とアカウント ID またはアカウントエイリアスを含むアカウントサインインページの URL など、サインイン認証情報が送信されたはずです。

```
https://My_AWS_Account_ID.signin.aws.amazon.com/console/
```

**ヒント**  
ウェブブラウザでアカウントのサインインページのブックマークを作成するには、アカウントのサインイン URL を手動でブックマークエントリに入力する必要があります。ウェブブラウザのブックマーク機能は使用しないでください。リダイレクトによってサインイン URL が不明確になるからです。

また、次の一般サインインエンドポイントでサインインして、アカウント ID またはアカウントエイリアスを手動で入力することもできます。

```
[https://console.aws.amazon.com/](https://console.aws.amazon.com/)
```

利便性のため、AWS サインインページはブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。次回、ユーザーが任意のページに移動したとき、AWS マネジメントコンソール コンソールは Cookie を使用して、ユーザーをアカウントのサインインページにリダイレクトします。

管理者が IAM ユーザーIDに関連付けられているポリシーで指定した AWS リソースにのみアクセスできます。ユーザーがコンソールで操作するには、AWS リソースのリスト表示や作成など、コンソールが実行するアクションの実行権限が必要です。詳細については、[AWS リソースの アクセス管理](access.md)および[IAM アイデンティティベースのポリシーの例](access_policies_examples.md)を参照してください。

**注記**  
組織に既存のアイデンティティシステムがある場合は、Single Sign-On (SSO) オプションを作成することができます。SSO を使用すると、ユーザーは IAM ユーザーアイデンティティを持たなくてもアカウントの AWS マネジメントコンソール にアクセスできます。SSO では、ユーザーが組織のサイトにサインインしたり、AWS に個別にサインインする必要もなくなります。詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。

**CloudTrail でのログ記録サインインの詳細**  
CloudTrail を有効化してログにサインインイベントを記録する場合、CloudTrail がイベントを記録する場所を選択するしくみを認識しておく必要があります。
+ ユーザーがコンソールに直接サインインすると、選択されたサービスのコンソールがリージョンをサポートするかどうかによって、グローバルまたはリージョンのサインインエンドポイントにリダイレクトされます。例えば、メインコンソールのホームページはリージョンをサポートするため、次の URL にサインインした場合:

  ```
  https://alias.signin.aws.amazon.com/console
  ```

  `https://us-east-2.signin.aws.amazon.com` などののリージョンのサインインエンドポイントにリダイレクトされ、そのリージョンのログでリージョンの CloudTrail ログエントリとなります。

  一方、Amazon S3 コンソールはリージョンをサポートしないため、次の URL にサインインした場合:

  ```
  https://alias.signin.aws.amazon.com/console/s3
  ```

  AWS により `https://signin.aws.amazon.com` にあるグローバルのサインインエンドポイントにリダイレクトされ、グローバルの CloudTrail ログエントリとなります。
+ リージョン対応のメインコンソールのホームページで次のような URL 構文を使ってサインインすることにより、手動で特定のリージョンのサインインエンドポイントをリクエストすることができます。

  ```
  https://alias.signin.aws.amazon.com/console?region=ap-southeast-1
  ```

  AWS により `ap-southeast-1` リージョンサインインエンドポイントにリダイレクトされ、そのリージョンの CloudTrail ログイベントとなります。

CloudTrail と IAM の詳細については、「[CloudTrail による IAM イベントのログ記録](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html)」を参照してください。

ユーザーが、アカウントの操作のためにプログラムによるアクセスが必要な場合は、各ユーザーにアクセスキーペア (アクセスキー ID とシークレットアクセスキー) を作成できます。ただし、ユーザーのアクセスキーを作成する前に検討すべきより安全な代替手段があります。詳細については、「AWS 全般のリファレンス」の「[長期的なアクセスキーの考慮事項と代替方法](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#alternatives-to-long-term-access-keys)」を参照してください。

## 追加リソース
<a name="id_users_sign-in-additional-resources"></a>

AWS サインインの詳細については、次のリソースを参照してください。
+ この[AWS サインインユーザーガイド](https://docs.aws.amazon.com/signin/latest/userguide/what-is-sign-in.html)は、ユーザーのタイプに応じて、Amazon Web Services (AWS) にサインインするさまざまな方法を理解するのに役立ちます。
+ AWS マネジメントコンソール では、1 つのウェブブラウザで最大 5 つの異なる ID を同時にサインインできます。詳細については、「*AWS マネジメントコンソール 入門ガイド*」の「[複数の入門ガイドアカウントへのサインイン](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html)」を参照してください。

# MFA 対応のサインイン
<a name="console_sign-in-mfa"></a>

[多要素認証 (MFA)](id_credentials_mfa.md) デバイスで構成されているユーザーは、MFA デバイスを使用して AWS マネジメントコンソール にサインインする必要があります。ユーザーがサインイン認証情報を入力した後、AWS はそのユーザーのアカウントを調べ、そのユーザーに MFA が必要かどうかを確認します。

**重要**  
AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API コールでの AWS マネジメントコンソールへの直接アクセスにアクセスキーとシークレットキーの認証情報を使用する場合、MFA は必要ありません。詳細については、「[コンソールアクセスでのアクセスキーとシークレットキー認証情報の使用](securing_access-keys.md#console-access-security-keys)」を参照してください。

以下のトピックでは、MFA が必要なときにユーザーがサインインを完了する方法について説明します。

**Topics**
+ [

## 複数の MFA デバイスが有効になっている
](#console_sign-in-multiple-mfa)
+ [

## FIDO セキュリティキー
](#console_sign-in-mfa-fido)
+ [

## 仮想 MFA デバイス
](#console_sign-in-mfa-virtual)
+ [

## ハードウェア TOTP トークン
](#console_sign-in-mfa-hardware)

## 複数の MFA デバイスが有効になっている
<a name="console_sign-in-multiple-mfa"></a>

ユーザーが AWS アカウント で複数の MFA デバイスを有効にした状態で、そのアカウントのルートユーザーまたは IAM ユーザーとして AWS マネジメントコンソール にログインする場合でも、サインインに必要な MFA デバイスは 1 台のみです。パスワードによる認証を行ったユーザーは、使用する MFA デバイスタイプを選択し認証を完了します。その後、ユーザーは、選択したタイプのデバイスを使用した認証を求められます。

## FIDO セキュリティキー
<a name="console_sign-in-mfa-fido"></a>

MFA がユーザーに必要な場合は、2 番目のサインインページが表示されます。ユーザーは FIDO セキュリティキーをタップする必要があります。

**注記**  
Google Chrome をお使いの方は、**[Verify your identity with amazon.com]** (amazon.comで本人確認をしてください) と要求するポップアップが表示されますが、いずれのオプションも選択しないようにしてください。セキュリティキーをタップするだけでよいのです。

他の MFA デバイスとは異なり、FIDO のセキュリティキーは同期しなくなります。管理者は、FIDO セキュリティキーを紛失したり壊れたりした場合、そのキーを無効にすることができます。詳細については、「[MFA デバイスの無効化 (コンソール)](id_credentials_mfa_disable.md#deactive-mfa-console)」を参照してください。

WebAuthn をサポートするブラウザーおよび、AWS がサポートする FIDO 対応デバイスについては、「[パスキーとセキュリティキーを使用するためのサポートされる設定](id_credentials_mfa_fido_supported_configurations.md)」を参照してください。

## 仮想 MFA デバイス
<a name="console_sign-in-mfa-virtual"></a>

MFA がユーザーに必要な場合は、2 番目のサインインページが表示されます。[**MFA code (MFA コード)**] ボックスに、ユーザーは MFA アプリケーションから提供される数値コードを入力する必要があります。

MFA コードが正しい場合、ユーザーは AWS マネジメントコンソール にアクセスできます。このコードが間違っていると、ユーザーは別のコードで再試行できます。

仮想 MFA デバイスが同期しなくなることがあります。ユーザーが AWS マネジメントコンソール へのサインインを何度か試みて失敗した場合、仮想 MFA デバイスを同期するよう求められます。ユーザーは画面の指示に従って仮想 MFA デバイスを同期できます。お客様の AWS アカウント のユーザーに代わってデバイスを同期する方法については、「[仮想 MFA デバイスとハードウェア MFA デバイスを再同期する](id_credentials_mfa_sync.md)」を参照してください。

## ハードウェア TOTP トークン
<a name="console_sign-in-mfa-hardware"></a>

MFA がユーザーに必要な場合は、2 番目のサインインページが表示されます。ユーザーは、**[MFA code]** (MFA コード) ボックスに、ハードウェア TOTP トークンから提供される数値コードを入力する必要があります。

MFA コードが正しい場合、ユーザーは AWS マネジメントコンソール にアクセスできます。このコードが間違っていると、ユーザーは別のコードで再試行できます。

ハードウェア TOTP トークンは、同期から外れることはありません。AWS マネジメントコンソール へのサインインが、複数回連続して失敗したユーザーに対しては、MFA トークンデバイスと同期するように求められます。ユーザーは画面の指示に従って MFA トークンデバイスを同期できます。お客様の AWS アカウント のユーザーに代わってデバイスを同期する方法については、「[仮想 MFA デバイスとハードウェア MFA デバイスを再同期する](id_credentials_mfa_sync.md)」を参照してください。

# AWS アカウント で IAM ユーザーを作成する
<a name="id_users_create"></a>

**重要**  
 IAM [ベストプラクティス](best-practices.md)では、長期的な認証情報を持つIAMユーザーを使用するのではなく、一時的な認証情報を使用して AWS にアクセスするために、IDプロバイダーとのフェデレーションを使用することを人間ユーザーに求めることを推奨します。IAM ユーザーは、フェデレーションユーザーでサポートされていない[特定のユースケース](gs-identities-iam-users.md)にのみ使用することをお勧めします。

IAM ユーザーを作成して、このユーザーにタスクの実行を許可するステップは次のとおりです。

1. [ユーザーを AWS マネジメントコンソール、AWS CLI](getting-started-workloads.md)、Tools for Windows PowerShell で、または AWS API オペレーションを使用して作成します。AWS マネジメントコンソール でユーザーを作成する場合は、選択内容に基づいてステップ 1 ～ 4 が自動的に処理されます。IAM ユーザーをプログラムにより作成した場合、各ステップを別個に実行する必要があります。

1. ユーザーに必要なアクセスのタイプに応じてユーザーの認証情報を作成します。
   + **[コンソールアクセスを有効にする - オプション]**: ユーザーが AWS マネジメントコンソール にアクセスする必要がある場合は、[該当ユーザーのパスワードを作成します](id_credentials_passwords_admin-change-user.md)。ユーザーのコンソールアクセスを無効にすると、ユーザー名とパスワードを使用して AWS マネジメントコンソール にサインインできなくなります。アクセス許可を変更したり、想定されたロールを使用してコンソールにアクセスすることを妨げたりすることはありません。
**ヒント**  
ユーザーが必要とする認証情報のみを作成します。例えば、AWS マネジメントコンソール を介したアクセスのみ必要なユーザーには、アクセスキーを作成しないでください。

1. 必要なタスクを実行するためのアクセス許可をユーザーに付与します。IAM ユーザーをグループに配置し、アクセス許可の管理は、グループにアタッチされているポリシーを通して行うことをお勧めします。ただし、アクセス許可ポリシーをユーザーに直接アタッチして、アクセス許可を付与することもできます。コンソールを使用してユーザーを追加する場合は、既存のユーザーから新しいユーザーにアクセス許可をコピーできます。

   ユーザーが持つことのできる最大アクセス許可を定義するポリシーを指定することで、[アクセス許可の境界](access_policies_boundaries.md)を追加してユーザーのアクセス許可を制限することもできます。アクセス許可の境界は、アクセス許可を付与しません。

   アクセス許可の付与またはアクセス許可の境界の設定に使用するカスタムアクセス許可ポリシーを作成する手順については、「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](access_policies_create.md)」を参照してください。

1. (オプション) タグをアタッチして、メタデータをユーザーに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。

1. 必要なサインイン情報をユーザーに提供します。この情報には、ユーザーがアカウントのサインインページで認証情報として入力するパスワードやコンソールの URL が含まれます。詳細については、「[IAM ユーザーが AWS にサインインする方法](id_users_sign-in.md)」を参照してください。

1. (オプション) ユーザーの [多要素認証 (MFA)](id_credentials_mfa.md) を設定します。MFA では、ユーザーが AWS マネジメントコンソール にサインインするたびに 1 回限り使用のコードを入力することが求められます。

1. (オプション) IAM ユーザーに自分の認証情報を管理する権限を与えることができます。(デフォルト設定では、自身の認証情報を管理する権限は、IAM ユーザーにはありません。) 詳細については、「[IAM ユーザーに自分のパスワード変更を許可する](id_credentials_passwords_enable-user-change.md)」を参照してください。
**注記**  
コンソールを使用してユーザーを作成し、**[ユーザーは次回サインイン時に新しいパスワードを作成する必要があります (推奨)]** を選択した場合、ユーザーには必要なアクセス許可が付与されます。

ユーザーの作成に必要なアクセス許可の詳細については、「[他の IAM リソースにアクセスするのに必要なアクセス許可](access_permissions-required.md)」を参照してください。

特定のユースケースのために IAM ユーザーを作成する手順については、次のトピックを参照してください。
+ [緊急アクセス用の IAM ユーザーを作成する](getting-started-emergency-iam-user.md)
+ [IAM ロールを使用できないワークロード用の IAM ユーザーを作成する](getting-started-workloads.md)

# IAM ユーザーを表示する
<a name="id_users_list"></a>

IAM ユーザーを一覧表示するには、AWS アカウント または特定の IAM グループで、ユーザーが属するすべてのユーザーグループを一覧表示します。ユーザーの一覧表示に必要な権限の詳細については、「[他の IAM リソースにアクセスするのに必要なアクセス許可](access_permissions-required.md)」を参照してください。

## アカウント内のすべての IAM ユーザーを一覧表示するには
<a name="id_users_manage_list-users"></a>

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

コンソールには、AWS アカウント 内の IAM ユーザーが表示されます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ `[aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)`

------
#### [ API ]

次のオペレーションを呼び出します。
+ `[ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)` 

------

## IAM グループ内の IAM ユーザーを一覧表示するには
<a name="id_users_manage_list-users-group"></a>

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで、**[ユーザーグループ]** を選択します。

1. ユーザーグループの名前を選択します。

グループのメンバーである IAM ユーザーが **[ユーザー]** タブに一覧表示されます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ `[aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html)`

------
#### [ API ]

次のオペレーションを呼び出します。
+ `[GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)` 

------

## ユーザーが所属しているすべての IAM グループを一覧表示するには
<a name="id_users_manage_list-groups-users"></a>

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. **[Users]** (ユーザー) のリストで、IAM ユーザー名を選択します。

1. **[グループ]** タブを選択すると、現在のユーザーを含めるグループのリストが表示されます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ `[aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)`

------
#### [ API ]

次のオペレーションを呼び出します。
+ `[ListGroupsForUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupsForUser.html)` 

------

## 次のステップ
<a name="id_users_list-next-steps"></a>

IAM ユーザーのリストを取得したら、次の手順で IAM ユーザー名を変更、削除、または非アクティブ化できます。
+ [IAM ユーザー名を変更する](id_users_rename.md)
+ [IAM ユーザーを削除または非アクティブ化する](id_users_remove.md)

# IAM ユーザー名を変更する
<a name="id_users_rename"></a>

**注記**  
[ベストプラクティス](best-practices.md)として、一時的な認証情報の使用により AWS にアクセスするには、人間のユーザーに対して ID プロバイダーとのフェデレーションの使用を必須とすることをお勧めします。ベストプラクティスに従えば、IAM ユーザーやグループを管理することにはなりません。管理するのではなく、ユーザーとグループは AWS の外部で管理され、フェデレーション ID として AWS リソースにアクセスできます。フェデレーション ID は、エンタープライズユーザーディレクトリ、ウェブ ID プロバイダー、AWS Directory Service、Identity Center ディレクトリのユーザー、または ID ソースから提供された認証情報を使用して AWS のサービスにアクセスするユーザーです。フェデレーション ID は、ID プロバイダーが定義したグループを使用します。AWS IAM アイデンティティセンター を使用している場合は、IAM Identity Center でのユーザーとグループの作成に関する情報について、AWS IAM アイデンティティセンター ユーザーガイドの「[Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)」(IAM Identity Center での ID の管理) を参照してください。

Amazon Web Services には、AWS アカウント の IAM ユーザーを管理するための複数のツールが用意されています。アカウントまたは特定のグループの IAM ユーザーを一覧表示したり、ユーザーが属するすべての IAM グループを一覧表示したりできます。また、IAM ユーザーの名前変更やパスの変更をしたりできます。IAM ユーザーではなくフェデレーション ID の使用に移行している場合は、AWS アカウントから IAM ユーザーを削除したり、ユーザーを非アクティブ化したりできます。

IAM ユーザーの管理ポリシーの追加、変更、または削除の詳細については、「[IAM ユーザーのアクセス許可を変更する](id_users_change-permissions.md)」を参照してください。IAM ユーザーのインラインポリシーの管理の詳細については、「[IAM ID のアクセス許可の追加および削除](access_policies_manage-attach-detach.md)」、「[IAM ポリシーを編集する](access_policies_manage-edit.md)」、および「[IAM ポリシーを削除する](access_policies_manage-delete.md)」を参照してください。ベストプラクティスとして、インラインポリシーではなく管理ポリシーを使用します。AWS 管理ポリシーでは、多くの一般的ユースケースでアクセス許可を付与します。AWS 管理ポリシーは、すべての AWS のユーザーが使用できるため、特定のユースケースに対して最小特権のアクセス許可が付与されない場合があることに留意してください。そのため、ユースケースに応じた[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、「[AWS マネージドポリシー](access_policies_managed-vs-inline.md#aws-managed-policies)」を参照してください。特定のジョブ機能用に設計された AWS 管理ポリシーの詳細については、[AWSジョブ機能の 管理ポリシー](access_policies_job-functions.md) を参照してください。

IAM ポリシーの検証の詳細については、「[IAM ポリシーの検証](access_policies_policy-validator.md)」を参照してください。

**ヒント**  
[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) では、IAM ロールが使用するサービスとアクションを分析し、使用可能なきめ細かなポリシーを生成できます。生成された各ポリシーをテストしたら、ポリシーを本番環境にデプロイできます。これにより、ワークロードに必要なアクセス許可のみが付与されます。ポリシー生成の詳細については、「[IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)」を参照してください。

IAM ユーザーパスワードの管理に関する詳細については、「[IAM ユーザーのパスワードを管理する](id_credentials_passwords_admin-change-user.md)」を参照してください。

## IAM ユーザーの名前の変更
<a name="id_users_renaming"></a>

ユーザーの名前またはパスを変更するには、AWS CLI、Tools for Windows PowerShell または AWS API を使用する必要があります。コンソールに、ユーザーの名前を変更するためのオプションはありません。ユーザーの名前の変更に必要なアクセス許可の詳細については、「[他の IAM リソースにアクセスするのに必要なアクセス許可](access_permissions-required.md)」を参照してください。

ユーザーの名前またはパスを変更すると、以下のことが起こります。
+ ユーザーにアタッチされているポリシーは、新しい名前のユーザーにそのままアタッチされています。
+ ユーザーは名前が変わるだけで、所属する IAM グループは変わりません。
+ ユーザーの一意の ID は変更されません。一意の ID の詳細については、「[一意の識別子](reference_identifiers.md#identifiers-unique-ids)」を参照してください。
+ ユーザーを*プリンシパル* (このユーザーにはアクセスが許可されます) として参照しているリソースやロールのポリシーは、新しい名前またはパスを使用するように自動的に更新されます。例えば、Amazon S3 内のキューベースのポリシー、または Amazon SQS 内のリソースベースのポリシーは、新しい名前またはパスを使用するように自動的に更新されます。

IAM は、ユーザーを*リソースとして*参照しているポリシーを、自動的に更新しません。新しい名前またはパスを使用するには、手動で更新する必要があります。例えば、`Richard` というユーザーに自身の認証情報の管理を許可するポリシーがアタッチされているとします。名前を `Richard` から `Rich` に変更する場合、管理者はそのポリシーを更新して、次のリソースを

```
arn:aws:iam::111122223333:user/division_abc/subdivision_xyz/Richard
```

次のように変更する必要があります。

```
arn:aws:iam::111122223333:user/division_abc/subdivision_xyz/Rich
```

パスを変更する場合も同様です。管理者は、ユーザーの新しいパスを反映するようにポリシーを更新する必要があります。

### ユーザーの名前を変更するには
<a name="id_users_manage_list-users-rename"></a>
+ AWS CLI: [aws iam update-user](https://docs.aws.amazon.com/cli/latest/reference/iam/update-user.html)
+ AWS API: [UpdateUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateUser.html) 

# IAM ユーザーを削除または非アクティブ化する
<a name="id_users_remove"></a>

[ベストプラクティス](best-practices.md#remove-credentials)では、AWS アカウント から未使用の IAM ユーザーを削除することが推奨されています。IAM ユーザーの認証情報を将来使用するために保持する場合は、アカウントから削除する代わりに、ユーザーのアクセス許可を非アクティブ化できます。詳細については、「[IAM ユーザーの非アクティブ化](#id_users_deactivating)」を参照してください。

**警告**  
削除したIAM ユーザーとアクセスキーは復元または復旧できません。

## 前提条件 — IAM ユーザーアクセスを表示する
<a name="users-manage_prerequisites"></a>

ユーザーを削除する前に、そのユーザーが最近行ったサービスレベルのアクティビティを確認してください。これにより、それを使用しているプリンシパル (ユーザーまたはアプリケーション) からアクセスを削除することを防止できます。最後にアクセスした情報を表示する方法の詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](access_policies_last-accessed.md)」を参照してください。

## IAM ユーザーを削除する (コンソール)
<a name="id_users_deleting_console"></a>

AWS マネジメントコンソールを使用して IAM ユーザーを削除すると、関連付けられている以下の情報が IAM によって自動的に削除されます。
+ IAM ユーザー識別子
+ すべてのグループメンバシップ (つまり、IAM ユーザーは、メンバーとして所属していたすべてのグループから削除されます)
+ IAM ユーザーのパスワード 
+ IAM ユーザーに組み込まれていたすべてのインラインポリシー (ユーザーグループのアクセス許可を使用して IAM ユーザーに適用されているポリシーは影響を受けません) 
**注記**  
IAM は、ユーザーを削除すると、IAM ユーザーにアタッチされた管理ポリシーをすべて削除しますが、管理ポリシーは削除しません。
+ 関連する MFA デバイス

### IAM ユーザーを削除するには (コンソール)
<a name="id_users_remove-section-1"></a>

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで、**[ユーザー]** を選択し、削除する IAM ユーザー名の横にあるチェックボックスをオンにします。

1. ページの上部で、[**削除**] を選択します。
**注記**  
いずれかのユーザーにアクティブなアクセスキーがある場合は、ユーザーを削除する前にアクセスキーを非アクティブ化する必要があります。詳細については、「[IAM ユーザーのためにアクセスキーを非アクティブ化するには](access-keys-admin-managed.md#admin-deactivate-access-key)」を参照してください。

1. 確認ダイアログボックスで、テキスト入力フィールドにユーザー名を入力し、ユーザーの削除を確認します。**[削除]** を選択します。

コンソールには、IAM ユーザーが削除されたというステータス通知が表示されます。

------

## IAM ユーザーの削除 (AWS CLI)
<a name="id_users_deleting_cli"></a>

AWS CLI を使用して IAM ユーザーを削除する場合、AWS マネジメントコンソールの場合とは異なり、IAM ユーザーにアタッチされている項目を削除する必要があります。この手順では、そのプロセスについて説明します。

**AWS アカウント から IAM ユーザーを削除するには (AWS CLI)**

1. ユーザーのパスワード（使用していた場合）を削除します。

   `[aws iam delete-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-login-profile.html)`

1. ユーザーのアクセスキーを削除します (使用していた場合)。

   `[aws iam list-access-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)` (ユーザーのアクセスキーを一覧表示するには) および `[aws iam delete-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)`

1. ユーザーの署名証明書を削除します。認証情報を削除すると、完全に削除され、復元できないことに注意してください。

   `[aws iam list-signing-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-signing-certificates.html)` (ユーザーの署名証明書を一覧表示するには) および `[aws iam delete-signing-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-signing-certificate.html)`

1. ユーザーの SSH パブリックキーを削除します (使用していた場合)。

   `[aws iam list-ssh-public-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-ssh-public-keys.html)` (ユーザーの SSH パブリックキーを一覧表示するには) および `[aws iam delete-ssh-public-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-ssh-public-key.html)`

1. ユーザーの Git 認証情報を削除します。

   `[aws iam list-service-specific-credentials](https://docs.aws.amazon.com/cli/latest/reference/iam/list-service-specific-credentials.html)` (ユーザーの Git 認証情報を一覧表示するには) および `[aws iam delete-service-specific-credential](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-specific-credential.html)`

1. ユーザーの 多要素認証 (MFA) デバイスを無効にします (使用していた場合)。

   `[aws iam list-mfa-devices](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-devices.html)` (ユーザーの MFA デバイスを一覧表示するには)、`[aws iam deactivate-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html)` (デバイスを無効にするには)、`[aws iam delete-virtual-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html)` (仮想 MFA デバイスを完全に削除するには) 

1. ユーザーのインラインポリシーを削除します。

   `[aws iam list-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-policies.html)` (ユーザーのインラインポリシーを一覧表示するには) および [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user-policy.html) (ポリシーをさくじょするには) 

1. ユーザーにアタッチされているすべての管理ポリシーをデタッチします。

   `[aws iam list-attached-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-user-policies.html)` (ユーザーにアタッチされているポリシーを一覧表示するには) および [https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html) (ポリシーをデタッチするには) 

1. すべての IAM グループからユーザーを削除します。

   `[aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)` (ユーザーが属する IAM グループを一覧表示するには) および `[aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html)` 

1. ユーザーを削除します。

   `[aws iam delete-user](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user.html)` 

## IAM ユーザーの非アクティブ化
<a name="id_users_deactivating"></a>

IAM ユーザーが一時的に会社から離れるときは、そのユーザーを非アクティブ化する必要がある場合があります。IAM ユーザー認証情報を現状のままにしておき、AWS のアクセスをブロックすることができます。

ユーザーを非アクティブ化するには、AWS へのユーザーアクセスを拒否するポリシーを作成してアタッチします。ユーザーアクセスは後で復元できます。

ユーザーにアタッチしてアクセスを拒否できるポリシーを 2 例紹介します。

次のポリシーには期限を設けていません。ユーザーのアクセスを復元するには、ポリシーを削除する必要があります。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [ 
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*"
      } 
   ]
}
```

------

次のポリシーには、2024 年 12 月 24 日午後 11 時 59 分 (UTC) にポリシーを開始し、2025 年 2 月 28 日午後 11 時 59 分 (UTC) にポリシーを終了するという条件があります。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
          "DateGreaterThan": {"aws:CurrentTime": "2024-12-24T23:59:59Z"},
          "DateLessThan": {"aws:CurrentTime": "2025-02-28T23:59:59Z"}
          }
       }
   ]
}
```

------

# AWS マネジメントコンソール への IAM ユーザーアクセスを制御する
<a name="console_controlling-access"></a>

AWS マネジメントコンソール を使用して AWS アカウント にサインインするアクセス許可を持つ IAM ユーザーは、AWS リソースにアクセスできます。以下の一覧は、AWS マネジメントコンソール を通じて AWS アカウント リソースへのアクセス権限を IAM ユーザーに付与する方法を示しています。また、AWS ウェブサイトを通じて、AWS アカウントの他の機能に IAM ユーザーがアクセスする方法も示しています。

**注記**  
IAM の使用は無料です。

**AWS マネジメントコンソール**  
AWS マネジメントコンソール にアクセスする必要がある各 IAM ユーザーのパスワードを作成します。ユーザーは、IAM 対応の AWS アカウント サインインページから、コンソールにアクセスします。サインインページへのサインインについての詳細は、「AWS サインイン ユーザーガイド」の「[AWS にサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。パスワード作成の詳細については、[AWS のユーザーパスワード](id_credentials_passwords.md)を参照してください。  
パスワードを削除することで、AWS マネジメントコンソール への IAM ユーザーアクセスを無効にできます。これにより、サインイン認証情報を使用して AWS マネジメントコンソール にサインインすることができなくなります。権限を変更したり、引き受けたロールを使用してコンソールにアクセスできないようにしたりすることはありません。ユーザーがアクティブなアクセスキーを持っている場合、それらのキーは引き続き機能し、AWS CLI、Tools for Windows PowerShell、AWS API、またはAWS Console Mobile Application 用のツールを介したアクセスを許可します。

**Amazon EC2 インスタンス、Amazon S3 バケットなどの AWS リソース**  
IAM ユーザーがパスワードを持っている場合も、AWS リソースにアクセスするにはアクセス許可が必要です。お客様が IAM ユーザーを作成した際、デフォルトではそのユーザーにアクセス許可はありません。必要なアクセス許可を IAM ユーザーに付与するには、ユーザーにポリシーをアタッチします。多数の IAM ユーザーが同じリソースで同じタスクを実行する場合、これらの IAM ユーザーをグループに割り当てることができます。次に、そのグループにアクセス許可を割り当てることができます。IAM ユーザーおよびグループの作成の詳細については、「[IAM アイデンティティ](id.md)」を参照してください。ポリシーを使用するアクセス許可設定の詳細については、[AWS リソースの アクセス管理](access.md)を参照してください。

**AWS ディスカッションフォーラム**  
[AWS ディスカッションフォーラム](https://forums.aws.amazon.com/)への投稿は、どなたでもお読みいただけます。ユーザーが質問やコメントを AWS ディスカッションフォーラムに投稿する場合は、自分のユーザーネームを使用することができます。ユーザーが初めて AWS ディスカッションフォーラムに投稿する場合、ユーザーはニックネームおよび E メールアドレスを入力するように求められます。AWS ディスカッションフォーラムでそのニックネームを使用できるのは、そのユーザーのみです。

**AWS アカウント の請求および使用情報**  
ユーザーに、AWS アカウント の請求および使用情報へのアクセスを許可することができます。詳細については、[AWS Billing ユーザーガイド](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html) の「*請求情報へのアクセスのコントロール*」を参照してください。

**AWS アカウント プロファイル情報**  
ユーザーが AWS アカウント のプロファイル情報にアクセスすることはできません。

**AWS アカウント セキュリティ認証情報**  
ユーザーが AWS アカウント のセキュリティ認証情報にアクセスすることはできません。

**注記**  
IAM ポリシーによるアクセスコントロールは、インターフェイスとは関係ありません。たとえば、AWS マネジメントコンソール にアクセスするパスワードをユーザーに提供できます。AWS マネジメントコンソール 内におけるユーザーのアクションを、ユーザー (またはユーザーが属するグループ) のポリシーで制御することができます。または、AWS への API コールを実行するための AWS アクセスキーをユーザーに提供することもできます。これらのアクセスキーを認証に使用するライブラリまたはクライアントを通じてユーザーが呼び出すことのできるアクションをポリシーで制御することもできます。

# IAM ユーザーのアクセス許可を変更する
<a name="id_users_change-permissions"></a>

AWS アカウント 内の IAM ユーザーのアクセス許可を変更するには、グループメンバーシップを変更するか、既存のユーザーからアクセス許可をコピーするか、ユーザーに直接ポリシーをアタッチするか、または[アクセス許可の境界](access_policies_boundaries.md)を設定することができます。アクセス許可の境界では、ユーザーに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。

ユーザーのアクセス権限の変更に必要なアクセス権限の詳細については、「[他の IAM リソースにアクセスするのに必要なアクセス許可](access_permissions-required.md)」を参照してください。

**Topics**
+ [

## ユーザーアクセスの表示
](#users-modify_prerequisites)
+ [

## ユーザーのアクセスアクティビティに基づくポリシーの生成
](#users_change_permissions-gen-policy)
+ [

## ユーザーへのアクセス許可の追加 (コンソール)
](#users_change_permissions-add-console)
+ [

## ユーザーのアクセス許可の変更 (コンソール)
](#users_change_permissions-change-console)
+ [

## ユーザーからのアクセス許可ポリシーを削除するには (コンソール)
](#users_change_permissions-remove-policy-console)
+ [

## ユーザーからアクセス許可の境界を削除するには (コンソール)
](#users_change_permissions-remove-boundary-console)
+ [

## ユーザーのアクセス許可の追加と削除 (AWS CLI または AWS API)
](#users_change_permissions-add-programmatic)

## ユーザーアクセスの表示
<a name="users-modify_prerequisites"></a>

ユーザーのアクセス許可を変更する前に、サービスレベルの最近のアクティビティを確認する必要があります。これは、アクセス権を使用しているプリンシパル (ユーザーまたはアプリケーション) から削除しないようにするために重要です。最後にアクセスした情報を表示する方法の詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](access_policies_last-accessed.md)」を参照してください。

## ユーザーのアクセスアクティビティに基づくポリシーの生成
<a name="users_change_permissions-gen-policy"></a>

IAM エンティティ (ユーザーまたはロール) に必要な権限を超えるアクセス許可を付与することがあります。付与するアクセス権限を調整するために、エンティティのアクセスアクティビティに基づく IAM ポリシーを生成できます。IAM Access Analyzer は AWS CloudTrail ログを確認し、指定した日付範囲内のロールが使用したアクセス許可を含むポリシーテンプレートを生成します。テンプレートを使用して、きめ細かなアクセス権限で管理ポリシーを作成し、それを IAM エンティティにアタッチできます。これにより、特定のユースケースでロールが AWS リソースとインタラクションするために必要なアクセス権限のみを付与します。詳細については、「[IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)」を参照してください。

## ユーザーへのアクセス許可の追加 (コンソール)
<a name="users_change_permissions-add-console"></a>

IAM では 3 つの方法でユーザーにアクセス許可ポリシーを追加できます。
+ **IAM ユーザーを IAM グループに追加する** – IAM ユーザーをグループのメンバーにします。グループのポリシーがユーザーにアタッチされます。
+ **既存の IAM ユーザーからアクセス許可をコピーする** – すべてのグループメンバーシップ、アタッチされた管理ポリシー、インラインポリシー、および既存のアクセス許可の境界をソースユーザーからコピーします。
+ **ポリシーを IAM ユーザーに直接アタッチする** – 管理ポリシーをユーザーに直接アタッチします。アクセス許可の管理を簡単にするために、ポリシーをグループにアタッチしてから、IAM ユーザーを適切なグループのメンバーにします。

**重要**  
ユーザーにアクセス許可の境界が設定されている場合は、アクセス許可の境界で許可されている以上のアクセス許可をユーザーに追加することはできません。

### IAM ユーザーをグループに追加することによってアクセス許可を追加するには
<a name="users_change_permissions-add-group-console"></a>

IAM ユーザーを IAM グループに追加すると、ユーザーのアクセス許可が、そのグループに対して定義されたアクセス許可に更新されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. **[Users]** (ユーザー) のリストで、IAM ユーザー名を選択します。

1. **[グループ]** タブを選択すると、現在のユーザーを含めるグループのリストが表示されます。

1. **グループにユーザーを追加** を選択します。

1. ユーザーが参加する各グループのチェックボックスをオンにします。リストには、各グループの名前と、そのグループのメンバーとなった場合にユーザーが受け取るポリシーが表示されます。

1. (オプション) **[グループを作成]** を選択して、新しいグループを定義できます。これは、既存のグループとは異なるポリシーがアタッチされているグループにユーザーを追加する場合に便利です。

   1. 新しいタブで、**[ユーザーグループ名]** に新しいグループの名前を入力します。
**注記**  
AWS アカウントの IAM リソースの数とサイズには制限があります。詳細については、「[IAM と AWS STSクォータ](reference_iam-quotas.md)」を参照してください。グループ名は、最大 128 文字の英数字、プラス記号 (\$1)、等号 (=)、カンマ (,)、ピリオド (.)、アットマーク (@)、ハイフン (-) を組み合わせて指定します。名前はアカウント内で一意である必要があります。大文字と小文字は区別されません。例えば、*TESTGROUP* というグループと *testgroup* というグループを作成することはできません。

   1. グループにアタッチする管理ポリシーのチェックボックスを 1 つ以上オンにします。[**ポリシーの作成**] を選択して、新しい管理ポリシーを作成することもできます。その場合は、新しいポリシーが完成したらこのブラウザタブまたはウィンドウに戻り、[**Refresh (更新)**] を選択した後、グループにアタッチする新しいポリシーを選択します。詳細については、「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](access_policies_create.md)」を参照してください。

   1. **[ユーザーグループの作成]** を選択します。

   1. 元のタブに戻り、グループのリストを更新します。次に、新しいグループのチェックボックスをオンにします。

1. **[グループにユーザーを追加]** を選択します。

コンソールには、指定したグループにユーザーが追加されたことを示すステータスメッセージが表示されます。

------

### 別の IAM ユーザーにコピーすることによってアクセス許可を追加するには
<a name="users_change_permissions-add-copy-console"></a>

アクセス許可をコピーして IAM ユーザーにアクセス許可を追加すると、IAM は、指定されたユーザーからすべてのグループメンバーシップ、アタッチされた管理ポリシー、インラインポリシー、および既存のアクセス許可の境界をコピーして、現在選択されているユーザーにすぐに適用します。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. **[Users]** (ユーザー) のリストで、IAM ユーザー名を選択します。

1. **[アクセス許可]** タブで、**[アクセス許可を追加]** を選択します。

1. **[アクセス許可を追加]** ページで、**[アクセス許可をコピー]** を選択します。リストには、使用可能な IAM ユーザーと、そのグループメンバーシップ、アタッチされたポリシーが表示されます。

1. コピーするアクセス権限を持つユーザーの横のラジオボタンをオンにします。

1. **[次へ]** を選択して、ユーザーに加える変更のリストを表示します。次に、[**アクセス許可の追加**] を選択します。

コンソールには、指定した IAM ユーザーからアクセス許可がコピーされたことを示すステータスメッセージが表示されます。

------

### ポリシーを IAM ユーザーに直接アタッチすることによってアクセス権限を追加するには
<a name="users_change_permissions-add-directly-console"></a>

管理ポリシーは IAM ユーザーに直接アタッチできます。更新されたアクセス許可はすぐに適用されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. **[Users]** (ユーザー) のリストで、IAM ユーザー名を選択します。

1. **[アクセス許可]** タブで、**[アクセス許可を追加]** を選択します。

1. **[アクセス許可を追加]** ページで、**[ポリシーを直接アタッチ]** を選択します。**[アクセス許可ポリシー]** リストには、使用可能なポリシーとそのポリシータイプ、アタッチされたエンティティが表示されます。

1. アタッチする **[ポリシー名]** の横にあるラジオボタンを選択します。

1. **[次へ]** を選択して、ユーザーに加える変更のリストを表示します。次に、[**アクセス許可の追加**] を選択します。

コンソールには、指定した IAM ユーザーにポリシーが追加されたことを示すステータスメッセージが表示されます。

------

### IAM ユーザーのアクセス許可の境界を設定するには
<a name="users_change_permissions-set-boundary-console"></a>

アクセス許可の境界は、AWS のアクセス許可を管理するための高度な機能であり、IAM ユーザーが持つことができるアクセス許可の上限を設定するために使用されます。アクセス許可の境界を設定すると、付与された他のアクセス許可に関係なく、IAM ユーザーのアクセス許可が直ちに境界に制限されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. **[ユーザー]** リストで、アクセス許可の境界を変更する対象の IAM ユーザーの名前を選択します。

1. **[アクセス許可]** タブを選択します。必要に応じて、**[アクセス許可の境界]** セクションを開き、**[境界の設定]** を選択します。

1. **[アクセス許可の境界を設定]** ページの **[アクセス許可ポリシー]** で、アクセス許可の境界に使用するポリシーを選択します。

1. [**Set boundary (境界の設定)**] を選択します。

コンソールには、アクセス許可の境界が追加されたことを示すステータスメッセージが表示されます。

------

## ユーザーのアクセス許可の変更 (コンソール)
<a name="users_change_permissions-change-console"></a>

IAM では、次の方法でユーザーに関連付けられているアクセス許可を変更できます。
+ **アクセス許可ポリシーの編集** – ユーザーのインラインポリシーまたはユーザーのグループのインラインポリシーを編集するか、ユーザーにアタッチされている管理ポリシーを直接またはグループを介して編集します。ユーザーにアクセス許可の境界が設定されている場合は、アクセス許可の境界で使用されているポリシーで許可される以上のアクセス許可をユーザーに付与することはできません。
+ **アクセス許可の境界の変更** – ユーザーのアクセス許可の境界として使用されているポリシーを変更します。この変更に伴って、ユーザーに許可されるアクセス許可の上限が拡張または縮小される場合があります。

### ユーザーにアタッチされているアクセス許可ポリシーの編集
<a name="users_change_permissions-edit-policy-console"></a>

アクセス許可を変更すると、ユーザーのアクセス許可がすぐに更新されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. **[ユーザー]** リストで、アクセス許可の境界を変更する対象の IAM ユーザーの名前を選択します。

1. **[アクセス許可]** タブを選択します。必要に応じて、**[アクセス許可の境界]** セクションを開きます。

1. ポリシーの詳細を表示するために編集するポリシーの名前を選択します。**[アタッチされたエンティティ]** タブを選択すると、ポリシーを編集した場合に影響を受ける可能性のある他のエンティティ (IAM ユーザー、グループ、ロール) が表示されます。

1. [**Permissions (アクセス許可)**] タブを選択し、ポリシーで付与されるアクセス許可を確認します。アクセス許可を変更するには、**[編集]** を選択します。

1. ポリシーを編集し、[ポリシー検証](access_policies_policy-validator.md)に関する推奨事項を解決します。詳細については、「[IAM ポリシーを編集する](access_policies_manage-edit.md)」を参照してください。

1. **[次へ]** を選択し、ポリシーの概要を確認してから、**[変更を保存]** を選択します。

コンソールには、ポリシーが更新されたことを通知するステータスメッセージが表示されます。

------

### ユーザーのアクセス許可の境界を変更するには
<a name="users_change_permissions-change-boundary-console"></a>

アクセス許可の境界を変更すると、ユーザーのアクセス許可がすぐに更新されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. **[ユーザー]** リストで、アクセス許可の境界を変更する対象の IAM ユーザーの名前を選択します。

1. **[アクセス許可]** タブを選択します。必要に応じて、[**Permissions boundary (アクセス許可の境界)**] セクションを開き、[**Change boundary (境界の変更)**] を選択します。

1. アクセス許可の境界として使用するポリシーを選択します。

1. [**Set boundary (境界の設定)**] を選択します。

コンソールには、アクセス許可の境界が変更されたことを示すステータスメッセージが表示されます。

------

## ユーザーからのアクセス許可ポリシーを削除するには (コンソール)
<a name="users_change_permissions-remove-policy-console"></a>

アクセス許可ポリシーを削除すると、ユーザーのアクセス許可がすぐに更新されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. アクセス許可ポリシーを削除する対象のユーザーの名前を選択します。

1. **[アクセス許可]** タブを選択します。

1. 既存のポリシーを削除してアクセス許可を取り消す場合は、**[アタッチ方法]** 列を表示して、ユーザーがそのポリシーを取得する方法を把握してから、**[削除]** を選択してポリシーを削除します。
   + グループメンバーシップのためにポリシーが適用されている場合、**[削除]** を選択して、ユーザーをそのグループから削除します。1 つのグループには複数のポリシーがアタッチされている場合があります。グループからユーザーを削除すると、そのユーザーは、グループメンバーシップを通じて受け取った*すべての*ポリシーへのアクセスを失います。
   + ポリシーがユーザーに直接アタッチされた管理ポリシーの場合、**[削除]** を選択して、ユーザーへのポリシーのアタッチを解除します。これは、そのポリシー自体やそのポリシーがアタッチされている他のエンティティに影響を与えません。
   + ポリシーがインライン埋め込みポリシーである場合は、**[削除]** を選択すると、IAM からポリシーが削除されます。ユーザーに直接アタッチされたインラインポリシーは、そのユーザーにのみ存在します。

ポリシーがグループメンバーシップを通じてユーザーに付与された場合、コンソールには、IAM ユーザーが IAM グループから削除されたことを示すステータスメッセージが表示されます。ポリシーが直接アタッチされた場合やインラインの場合、ポリシーが削除されたことがステータスメッセージで通知されます。

------

## ユーザーからアクセス許可の境界を削除するには (コンソール)
<a name="users_change_permissions-remove-boundary-console"></a>

アクセス許可の境界を削除すると、ユーザーのアクセス許可がすぐに更新されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. **[ユーザー]** リストで、アクセス許可の境界を削除する対象の IAM ユーザーの名前を選択します。

1. **[アクセス許可]** タブを選択します。必要に応じて、**[アクセス許可の境界]** セクションを開きます。

1.  [**Change boundary (境界の変更)**] を選択します。アクセス許可の境界を削除することを確定するには、確認ダイアログで **[境界を削除]** を選択します。

コンソールには、アクセス許可の境界が削除されたことを示すステータスメッセージが表示されます。

------

## ユーザーのアクセス許可の追加と削除 (AWS CLI または AWS API)
<a name="users_change_permissions-add-programmatic"></a>

アクセス許可をプログラムにより追加または削除するには、グループメンバーシップの追加または削除、管理ポリシーのアタッチまたはデタッチ、インラインポリシーの追加または削除のいずれかを行う必要があります。詳細については、以下の各トピックを参照してください。
+ [IAM グループのユーザーを編集する](id_groups_manage_add-remove-users.md)
+ [IAM ID のアクセス許可の追加および削除](access_policies_manage-attach-detach.md)

# AWS のユーザーパスワード
<a name="id_credentials_passwords"></a>

アカウント内の IAM ユーザーのパスワードを管理できます。IAM ユーザーが AWS マネジメントコンソール にアクセスするには、パスワードが必要です。ユーザーが、AWS Tools for Windows PowerShell、AWS CLI SDK または API を使用してプログラムで AWS リソースにアクセスする場合、パスワードは必要ありません。このような環境では、IAM ユーザーに[アクセスキー](id_credentials_access-keys.md)を割り当てることができます。ただし、アクセスキーに代わるより安全な代替手段が他にもあり、最初に検討することをお勧めします。詳細については、「[AWS セキュリティ認証情報](security-creds.md)」を参照してください。

**注記**  
いずれかの IAM ユーザーがパスワードを紛失したり、忘れたりした場合は、IAM からパスワードを取得*することはできません*。設定に応じて、ユーザーまたは管理者のいずれかが新しいパスワードを作成する必要があります。

**Topics**
+ [

# IAM ユーザー用のアカウントパスワードポリシーを設定する
](id_credentials_passwords_account-policy.md)
+ [

# IAM ユーザーのパスワードを管理する
](id_credentials_passwords_admin-change-user.md)
+ [

# IAM ユーザーに自分のパスワード変更を許可する
](id_credentials_passwords_enable-user-change.md)
+ [

# IAM ユーザーが自分のパスワードを変更する方法
](id_credentials_passwords_user-change-own.md)

# IAM ユーザー用のアカウントパスワードポリシーを設定する
<a name="id_credentials_passwords_account-policy"></a>

IAM ユーザーのパスワードの複雑度の要件や必須のローテーション期間を指定するためのカスタムパスワードポリシーを AWS アカウント に設定できます。カスタムパスワードポリシーを設定しない場合、IAM ユーザーのパスワードはデフォルトの AWS パスワードポリシーの要件を満たす必要があります。詳細については、「[カスタムパスワードポリシーのオプション](#password-policy-details)」を参照してください。

**Topics**
+ [

## パスワードポリシーの設定に関するルール
](#password-policy-rules)
+ [

## パスワードポリシーを設定するために必要なアクセス許可
](#default-policy-permissions-required)
+ [

## デフォルトのパスワードポリシー
](#default-policy-details)
+ [

## カスタムパスワードポリシーのオプション
](#password-policy-details)
+ [

## パスワードポリシーを設定するには (コンソール)
](#IAMPasswordPolicy)
+ [

## パスワードポリシーを変更するには (コンソール)
](#id_credentials_passwords_account-policy-section-1)
+ [

## カスタムパスワードポリシーを削除するには (コンソール)
](#id_credentials_passwords_account-policy-section-2)
+ [

## パスワードポリシーの設定 (AWS CLI)
](#PasswordPolicy_CLI)
+ [

## パスワードポリシーの設定 (AWS API)
](#PasswordPolicy_API)

## パスワードポリシーの設定に関するルール
<a name="password-policy-rules"></a>

IAM パスワードポリシーは、AWS アカウントのルートユーザー パスワードまたは IAM ユーザー アクセスキーには適用されません。パスワードの有効期限が切れた場合、IAM ユーザーは AWS マネジメントコンソール にサインインできなくなりますが、引き続きアクセスキーを使用できます。

パスワードポリシーを作成または変更する場合、パスワードポリシーの設定の多くは、ユーザーが次回パスワードを変更するときに適用されます。ただし、一部の設定はすぐに適用されます。例: 
+ 最小文字数と文字タイプの要件が変更されると、これらの設定はユーザーが次回パスワードを変更するときに適用されます。既存のパスワードが更新されたパスワードポリシーに従っていない場合でも、ユーザーは既存のパスワードの変更を強制されません。
+ パスワードの有効期限を設定した場合、有効期限は直ちに適用されます。例えば、パスワードの有効期限を 90 日に設定したとします。この場合、既存のパスワードが作成されてから 90 日を超える期間が経過しているすべての IAM ユーザーのパスワードが失効します。これらのユーザーは、次回サインインするときにパスワードを変更する必要があります。

サインインが指定された回数失敗したユーザーをアカウントからロックアウトするために、「ロックアウトポリシー」を作成することはできません。セキュリティを強化するために、強力なパスワードポリシーと Multi-Factor Authentication (MFA) を組み合わせることをお勧めします。MFA の詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。

## パスワードポリシーを設定するために必要なアクセス許可
<a name="default-policy-permissions-required"></a>

IAM エンティティ (ユーザーまたはロール) がアカウントのパスワードポリシーを表示または編集することを許可するには、アクセス許可を設定する必要があります。ポリシーには、IAM ポリシーに次のパスワードポリシーアクションを含めることができます。
+ `iam:GetAccountPasswordPolicy` – エンティティが各自のアカウントのパスワードポリシーを表示することを許可します
+ `iam:DeleteAccountPasswordPolicy` – エンティティが各自のアカウントのカスタムパスワードポリシーを削除し、デフォルトのパスワードポリシーに戻すことを許可します
+ `iam:UpdateAccountPasswordPolicy` – エンティティが各自のアカウントのカスタムパスワードポリシーを作成または変更することを許可します

次のポリシーは、アカウントのパスワードポリシーを表示および編集するためのフルアクセスを許可します。この例の JSON ポリシードキュメントを使用して IAM ポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "FullAccessPasswordPolicy",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:DeleteAccountPasswordPolicy",
                "iam:UpdateAccountPasswordPolicy"
            ],
            "Resource": "*"
        }
    ]
}
```

------

IAM ユーザーが各自のパスワードを変更するために必要なアクセス許可の詳細については、「[IAM ユーザーに自分のパスワード変更を許可する](id_credentials_passwords_enable-user-change.md)」をご参照ください。

## デフォルトのパスワードポリシー
<a name="default-policy-details"></a>

管理者がカスタムパスワードポリシーを設定しない場合、IAM ユーザーパスワードはデフォルトの AWS パスワードポリシーの要件を満たす必要があります。

デフォルトのパスワードポリシーでは、次の条件が適用されます。
+ パスワードの文字数制限: 8～128 文字
+ 大文字、小文字、数字、英数字以外の文字 (`! @ # $ % ^ & * ( ) _ + - = [ ] { } | '`) のうち、最低 3 つの文字タイプの組み合わせ
+ AWS アカウント 名または E メールアドレスと同じでないこと
+ 有効期限のないパスワード

## カスタムパスワードポリシーのオプション
<a name="password-policy-details"></a>

アカウントのカスタムパスワードポリシーを設定する場合、次の条件を指定できます。
+ **パスワードの最小文字数** – 6～128 文字の間で指定できます。
+ **パスワードの強度** – 次のいずれかのチェックボックスをオンにして、IAM ユーザーパスワードの強度を定義できます。
  + ラテンアルファベットの大文字 (A–Z) が少なくとも 1 つ必要
  + ラテンアルファベットの小文字 (a–z) が少なくとも 1 つ必要
  + 少なくとも 1 つの数字が必要
  + 少なくとも 1 つの英数字以外の文字 `! @ # $ % ^ & * ( ) _ + - = [ ] { } | '` が必要 
+ **パスワードの有効期限をオンにする** – IAM ユーザーのパスワードが設定されてから有効な期間を 1～1,095 日の間で選択して指定できます。例えば、90 日間の有効期限を指定すると、すぐにすべてのユーザーに影響します。変更後、90 日を超える古いパスワードのユーザーがコンソールにログインする場合は、新しいパスワードを設定する必要があります。75 日から 89 日が経過したパスワードのユーザーは、パスワードの有効期限について AWS マネジメントコンソール から警告を受け取ります。IAM ユーザーは、アクセス許可があれば、いつでもパスワードを変更できます。新しいパスワードを設定すると、そのパスワードの有効期間が始まります。IAM ユーザーは一度に 1 つだけ有効なパスワードを持つことができます。
+ **[パスワードの失効に管理者のリセットを必要とする]** – パスワードが失効した後に IAM ユーザーが AWS マネジメントコンソール を使用して各自のパスワードを更新できないようにするには、このオプションを選択します。このオプションを選択する前に、AWS アカウント で複数のユーザーが IAM ユーザーパスワードをリセットするための管理アクセス許可を持っていることを確認します。管理者ユーザーの `iam:UpdateLoginProfile` 権限は IAM ユーザーパスワードをリセットできます。IAM ユーザーの `iam:ChangePassword` 権限キーとアクティブアクセスキーは、IAM ユーザーコンソールのパスワードをプログラムでリセットできます。このチェックボックスをオフにした場合、パスワードが失効している IAM ユーザーは、AWS マネジメントコンソール にアクセスする前に新しいパスワードを設定する必要があります。
+ **[ユーザーが各自のパスワードを変更することを許可]** – お客様のアカウント内のすべての IAM ユーザーが各自のパスワードを変更することを許可できます。これにより、そのユーザーだけに対する `iam:ChangePassword` アクションと `iam:GetAccountPasswordPolicy` アクションへのアクセスがユーザーに付与されます。このオプションでは、各ユーザーにアクセス許可ポリシーがアタッチされません。あるいは、IAM ではすべてのユーザーにアカウントレベルでアクセス許可が適用されます。あるいは、一部のユーザーのみが、自分自身のパスワードを管理できるように許可できます。これを行うには、このチェックボックスをオフにします。パスワードを管理できるユーザーを限定するポリシーの使用方法については、「[IAM ユーザーに自分のパスワード変更を許可する](id_credentials_passwords_enable-user-change.md)」を参照してください。
+ **パスワードの再利用を禁止** – 指定した数の以前のパスワードを IAM ユーザーが再利用することを禁止できます。再利用できない以前のパスワードの数を 1～24 個の間で指定できます。

## パスワードポリシーを設定するには (コンソール)
<a name="IAMPasswordPolicy"></a>

AWS マネジメントコンソール を使用して、カスタムパスワードポリシーを作成、変更、および削除できます。パスワードポリシーの変更は、このポリシーの変更後に作成された新しい IAM ユーザーに適用され、既存の IAM ユーザーにはパスワードを変更するときに適用されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[アカウント設定]** を選択します。

1. **[パスワードポリシー]** セクションで、**[編集]** を選択します。

1. カスタムパスワードポリシーを使用するには、**[カスタム]** を選択します。

1. パスワードポリシーに適用するオプションを選択し、**[変更の保存]** を選択します。

1. **[カスタムを設定]** を選択して、カスタムパスワードポリシーを設定することを確認します。

コンソールには、IAM ユーザーのパスワード要件が更新されたことを通知するステータスメッセージが表示されます。

------

## パスワードポリシーを変更するには (コンソール)
<a name="id_credentials_passwords_account-policy-section-1"></a>

AWS マネジメントコンソール を使用して、カスタムパスワードポリシーを作成、変更、および削除できます。パスワードポリシーの変更は、このポリシーの変更後に作成された新しい IAM ユーザーに適用され、既存の IAM ユーザーにはパスワードを変更するときに適用されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[アカウント設定]** を選択します。

1. **[パスワードポリシー]** セクションで、**[編集]** を選択します。

1. パスワードポリシーに適用するオプションを選択し、**[変更の保存]** を選択します。

1. **[カスタムを設定]** を選択して、カスタムパスワードポリシーを設定することを確認します。

コンソールには、IAM ユーザーのパスワード要件が更新されたことを通知するステータスメッセージが表示されます。

------

## カスタムパスワードポリシーを削除するには (コンソール)
<a name="id_credentials_passwords_account-policy-section-2"></a>

AWS マネジメントコンソール を使用して、カスタムパスワードポリシーを作成、変更、および削除できます。パスワードポリシーの変更は、このポリシーの変更後に作成された新しい IAM ユーザーに適用され、既存の IAM ユーザーにはパスワードを変更するときに適用されます。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[アカウント設定]** を選択します。

1. **[パスワードポリシー]** セクションで、**[編集]** を選択します。

1. **[IAM のデフォルト]** を選択してカスタムパスワードポリシーを削除し、**[変更を保存]** を選択します。

1. **[デフォルトを設定]** を選択して、IAM デフォルトパスワードポリシーを設定することを確認します。

コンソールには、パスワードポリシーが IAM のデフォルトに設定されていることを通知するステータスメッセージが表示されます。

------

## パスワードポリシーの設定 (AWS CLI)
<a name="PasswordPolicy_CLI"></a>

AWS Command Line Interface を使用して、パスワードポリシーを設定できます。

**AWS CLI からアカウントのカスタムパスワードポリシーを管理するには**  
以下の コマンドを実行します。
+ カスタムパスワードポリシーを作成または変更するには: [https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html)
+ パスワードポリシーを表示するには: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-account-password-policy.html) 
+ カスタムパスワードポリシーを削除するには: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-account-password-policy.html) 

## パスワードポリシーの設定 (AWS API)
<a name="PasswordPolicy_API"></a>

AWS API オペレーションを使用して、パスワードポリシーを設定できます。

**AWS API からアカウントのカスタムパスワードポリシーを管理するには**  
以下のオペレーションを呼び出します。
+ カスタムパスワードポリシーを作成または変更するには: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html)
+ パスワードポリシーを表示するには: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html) 
+ カスタムパスワードポリシーを削除するには: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html) 

# IAM ユーザーのパスワードを管理する
<a name="id_credentials_passwords_admin-change-user"></a>

AWS マネジメントコンソール を使用して AWS リソースを操作する IAM ユーザーには、サインインのためのパスワードが必要です。AWS アカウントの IAM ユーザーのパスワードを作成、変更、削除できます。

ユーザーにパスワードを割り当てると、ユーザーは、以下のような、アカウント用のサインイン URL を使用して AWS マネジメントコンソール にサインインできます。

```
https://12-digit-AWS-account-ID or alias.signin.aws.amazon.com/console
```

IAM ユーザーの AWS マネジメントコンソール へのサインインの詳細については、AWS サインイン ユーザーガイドの「[AWS にサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。

ユーザーは、パスワードが割り当てられている場合でも、AWS リソースへのアクセスにはやはりアクセス許可が必要です。デフォルトでは、ユーザーには何も権限が与えられていません。ユーザーに必要な権限を与えるには、ユーザーまたはユーザーが属しているグループにポリシーを割り当てます。ユーザーおよびグループの作成の詳細については、[IAM アイデンティティ](id.md)を参照してください。ポリシーを使用するアクセス許可設定の詳細については、[IAM ユーザーのアクセス許可を変更する](id_users_change-permissions.md)を参照してください。

ユーザーに自分のパスワードを変更する権限を付与できます。詳細については、「[IAM ユーザーに自分のパスワード変更を許可する](id_credentials_passwords_enable-user-change.md)」を参照してください。ユーザーがアカウントのサインインページにアクセスする方法の詳細については、AWS サインイン ユーザーガイドの「[AWS へサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。

**Topics**
+ [

## IAM ユーザーパスワードの作成、変更、削除 (コンソール)
](#id_credentials_passwords_admin-change-user_console)

## IAM ユーザーパスワードの作成、変更、削除 (コンソール)
<a name="id_credentials_passwords_admin-change-user_console"></a>

AWS マネジメントコンソール を使用して IAM ユーザーのパスワードを管理できます。

ユーザーのアクセスニーズは、時間の経過とともに変化する可能性があります。CLI アクセスを想定していたユーザーがコンソールにアクセスできるようにしたり、認証情報を含む E メールを受信してユーザーのパスワードを変更できるようにしたり、組織を離れたユーザーや AWS にアクセスする必要がなくなったユーザーを削除できるようにしたりすることが必要になる場合があります。

### IAM ユーザーのパスワードを作成するには (コンソール)
<a name="id_credentials_passwords_admin-change-user-section-1"></a>

この手順を使用して、ユーザー名に関連付けられたパスワードを作成し、ユーザーコンソールへのアクセスを許可します。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. パスワードを作成するユーザーの名前を選択します。

1. **[セキュリティ認証情報]** タブを選択し、**[コンソールサインイン]** で **[コンソールアクセスを有効にする]** を選択します。

1. **[コンソールアクセスを有効にする]** ダイアログボックスで **[パスワードのリセット]** を選択し、IAM によってパスワードを生成するか、カスタムパスワードを作成するかを選択します。
   + IAM によって自動的にパスワードを生成するには、[**Autogenerated password (自動生成パスワード)**] を選択します。
   + カスタムパスワードを作成するには、[**Custom password (カスタムパスワード)**] を選択し、パスワードを入力します。
**注記**  
作成するパスワードは、アカウントの[パスワードポリシー](id_credentials_passwords_account-policy.md)の要件を満たす必要があります。

1. サインイン時に新しいパスワードを作成するようにユーザーに要求する場合は、**[ユーザーは次回のサインインで新しいパスワードを作成する必要があります]** を選択します。

1. ユーザーに新しいパスワードをすぐに使用するように要求するには、**[アクティブなコンソールセッションを取り消す]** を選択します。これにより、インラインポリシーが IAM ユーザーにアタッチされ、そのユーザーの認証情報がポリシーで指定された時間よりも古い場合はリソースへのユーザーアクセスを拒否します。

1. **[パスワードのリセット]** を選択します。

1. **[コンソールパスワード]** ダイアログで、ユーザーの新しいパスワードを有効にしたことが通知されます。パスワードを表示してユーザーと共有するには、**[コンソールパスワード]** ダイアログボックスで **[表示]** を選択します。**[.csv ファイルのダウンロード]** を選択して、ユーザーの認証情報を含むファイルをダウンロードします。
**重要**  
セキュリティ上の理由で、この手順を完了するとパスワードにアクセスできなくなりますが、いつでも新しいパスワードを作成できます。

コンソールには、コンソールアクセスが有効になったことを示すステータスメッセージが表示されます。

------

### IAM ユーザーのパスワードを変更するには (コンソール)
<a name="id_credentials_passwords_admin-change-user-section-2"></a>

この手順を使用して、ユーザー名に関連付けられているパスワードを更新します。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. パスワードを変更するユーザーの名前を選択します。

1. **[セキュリティ認証情報]** タブを選択し、**[コンソールサインイン]** で **[コンソールアクセスの管理]** を選択します。

1. **[コンソールアクセスを管理]** ダイアログボックスで、**[パスワードのリセット]** を選択し、IAM によってパスワードを自動的に生成するか、カスタムパスワードを作成するかを選択します。
   + IAM によって自動的にパスワードを生成するには、[**Autogenerated password (自動生成パスワード)**] を選択します。
   + カスタムパスワードを作成するには、[**Custom password (カスタムパスワード)**] を選択し、パスワードを入力します。
**注記**  
作成するパスワードは、アカウントの[パスワードポリシー](id_credentials_passwords_account-policy.md)の要件を満たす必要があります。

1. サインイン時に新しいパスワードを作成するようにユーザーに要求する場合は、**[ユーザーは次回のサインインで新しいパスワードを作成する必要があります]** を選択します。

1. ユーザーに新しいパスワードをすぐに使用するように要求するには、**[アクティブなコンソールセッションを取り消す]** を選択します。これにより、インラインポリシーが IAM ユーザーにアタッチされ、そのユーザーの認証情報がポリシーで指定された時間よりも古い場合はリソースへのユーザーアクセスを拒否します。

1. **[パスワードのリセット]** を選択します。

1. **[コンソールパスワード]** ダイアログで、ユーザーの新しいパスワードを有効にしたことが通知されます。パスワードを表示してユーザーと共有するには、**[コンソールパスワード]** ダイアログボックスで **[表示]** を選択します。**[.csv ファイルのダウンロード]** を選択して、ユーザーの認証情報を含むファイルをダウンロードします。
**重要**  
セキュリティ上の理由で、この手順を完了するとパスワードにアクセスできなくなりますが、いつでも新しいパスワードを作成できます。

コンソールには、コンソールアクセスが更新されたことを示すステータスメッセージが表示されます。

------

### IAM ユーザーのパスワードを削除 (無効化) するには (コンソール)
<a name="id_credentials_passwords_admin-change-user-section-3"></a>

この手順を使用して、ユーザー名に関連付けられているパスワードを削除し、ユーザーのコンソールアクセスを取り消します。

**重要**  
パスワードを削除することで、AWS マネジメントコンソール への IAM ユーザーアクセスを無効にできます。これにより、サインイン認証情報を使用して AWS マネジメントコンソール にサインインすることができなくなります。権限を変更したり、引き受けたロールを使用してコンソールにアクセスできないようにしたりすることはありません。ユーザーがアクティブなアクセスキーを持っている場合、それらのキーは引き続き機能し、AWS CLI、Tools for Windows PowerShell、AWS API、またはAWS Console Mobile Application 用のツールを介したアクセスを許可します。

------
#### [ Console ]

1. *AWSサインインユーザーガイド*の「[AWS へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. **[IAM コンソールのホーム]** ページの左側のナビゲーションペインで、**[検索の IAM]** テキストボックスにクエリを入力します。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. パスワードを削除するユーザーの名前を選択します。

1. **[セキュリティ認証情報]** タブを選択し、**[コンソールサインイン]** で **[コンソールアクセスの管理]** を選択します。

1. ユーザーにコンソールの使用をすぐに止めるように要求するには、**[アクティブなコンソールセッションを取り消す]** を選択します。これにより、インラインポリシーが IAM ユーザーにアタッチされ、そのユーザーの認証情報がポリシーで指定された時間よりも古い場合はリソースへのユーザーアクセスを拒否します。

1. **[アクセスの無効化]** を選択します。

コンソールには、コンソールアクセスが無効になったことを示すステータスメッセージが表示されます。

------

### IAM ユーザーパスワードの作成、変更、削除 (AWS CLI)
<a name="Using_ManagingPasswordsCLIAPI"></a>

AWS CLI API を使用して IAM ユーザーのパスワードを管理できます。

**パスワードを作成するには (AWS CLI)**

1. (オプション) ユーザーがパスワードを持っているかどうかを確認するには、[aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html) コマンドを実行します。

1. パスワードを作成するには、[aws iam create-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-login-profile.html) コマンドを実行します。

**ユーザーのパスワードを変更するには (AWS CLI)**

1. (オプション) ユーザーがパスワードを持っているかどうかを確認するには、[aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html) コマンドを実行します。

1. パスワードを変更するには、[aws iam update-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/update-login-profile.html) コマンドを実行します。

**ユーザーのパスワードを削除 (無効化) するには (AWS CLI)**

1. (オプション) ユーザーがパスワードを持っているかどうかを確認するには、[aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html) コマンドを実行します。

1. (オプション) パスワードを前回使用した日付を確認するには、[aws iam get-user](https://docs.aws.amazon.com/cli/latest/reference/iam/get-user.html) コマンドを実行します。

1. パスワードを削除するには、[aws iam delete-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-login-profile.html) コマンドを実行します。

**重要**  
ユーザーのパスワードを削除すると、ユーザーは AWS マネジメントコンソール にサインインできなくなります。ユーザーがアクティブなアクセスキーを持っている場合、それらのキーは引き続き有効で、AWS CLI、Tools for Windows PowerShell、または AWS API 関数呼び出しで使用できます。AWS CLI、Tools for Windows PowerShell、または AWS API を使用してユーザーを AWS アカウント から削除する場合、まずこのオペレーションを使用してパスワードを削除する必要があります。詳細については、「[IAM ユーザーの削除 (AWS CLI)](id_users_remove.md#id_users_deleting_cli)」を参照してください。

**指定した時間より前にユーザーのアクティブなコンソールセッションを取り消すには (AWS CLI)**

1. 指定した時間より前に IAM ユーザーのアクティブなコンソールセッションを取り消すインラインポリシーを埋め込むには、以下のインラインポリシーを使用して次のコマンドを実行します: [aws iam put-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-user-policy.html)

   このインラインポリシーはすべてのアクセス許可を拒否し、`aws:TokenIssueTime` 条件キーを含みます。インラインポリシーの `Condition` 要素で指定された時間より前に、ユーザーのアクティブなコンソールセッションを取り消します。`aws:TokenIssueTime` 条件キーの値は、独自の値に置き換えてください。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Deny",
       "Action": "*",
       "Resource": "*",
       "Condition": {
         "DateLessThan": {
           "aws:TokenIssueTime": "2014-05-07T23:47:00Z"
         }
       }
     }
   }
   ```

------

1. (オプション) IAM ユーザーに埋め込まれているインラインポリシーの名前をリストするには、次のコマンドを実行します: [aws iam list-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-policies.html)

1. (オプション) IAM ユーザーに埋め込まれている名前付きのインラインポリシーを表示するには、次のコマンドを実行します: [aws iam get-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/get-user-policy.html)

### IAM ユーザーパスワードの作成、変更、削除 (AWS API)
<a name="Using_ManagingPasswordsAPI"></a>

AWS API を使用して IAM ユーザーのパスワードを管理できます。

**パスワードを作成するには (AWS API)**

1. (オプション) ユーザーがパスワードを持っているかどうかを確認するには、[GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html) オペレーションを呼び出します。

1. パスワードを作成するには、[CreateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html) オペレーションを呼び出します。

**ユーザーのパスワードを変更するには (AWS API)**

1. (オプション) ユーザーがパスワードを持っているかどうかを確認するには、[GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html) オペレーションを呼び出します。

1. パスワードを変更するには、[UpdateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateLoginProfile.html) オペレーションを呼び出します。

**ユーザーのパスワードを削除 (無効化) するには (AWS API)**

1. (オプション) ユーザーがパスワードを持っているかどうかを確認するには、[GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html) コマンドを実行します。

1. (オプション) パスワードを前回使用した日付を確認するには、[GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html) コマンドを実行します。

1. パスワードを削除するには、[DeleteLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteLoginProfile.html) コマンドを実行します。

**重要**  
ユーザーのパスワードを削除すると、ユーザーは AWS マネジメントコンソール にサインインできなくなります。ユーザーがアクティブなアクセスキーを持っている場合、それらのキーは引き続き有効で、AWS CLI、Tools for Windows PowerShell、または AWS API 関数呼び出しで使用できます。AWS CLI、Tools for Windows PowerShell、または AWS API を使用してユーザーを AWS アカウント から削除する場合、まずこのオペレーションを使用してパスワードを削除する必要があります。詳細については、「[IAM ユーザーの削除 (AWS CLI)](id_users_remove.md#id_users_deleting_cli)」を参照してください。

**指定した時間より前にユーザーのアクティブなコンソールセッションを取り消すには (AWS API)**

1. 指定した時間より前に IAM ユーザーのアクティブなコンソールセッションを取り消すインラインポリシーを埋め込むには、以下のインラインポリシーを使用して次のコマンドを実行します: [PutUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html)

   このインラインポリシーはすべてのアクセス許可を拒否し、`aws:TokenIssueTime` 条件キーを含みます。インラインポリシーの `Condition` 要素で指定された時間より前に、ユーザーのアクティブなコンソールセッションを取り消します。`aws:TokenIssueTime` 条件キーの値は、独自の値に置き換えてください。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Deny",
       "Action": "*",
       "Resource": "*",
       "Condition": {
         "DateLessThan": {
           "aws:TokenIssueTime": "2014-05-07T23:47:00Z"
         }
       }
     }
   }
   ```

------

1. (オプション) IAM ユーザーに埋め込まれているインラインポリシーの名前をリストするには、次のコマンドを実行します: [ListUserPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUserPolicies.html)

1. (オプション) IAM ユーザーに埋め込まれている名前付きインラインポリシーを表示するには、次のコマンドを実行します: [GetUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUserPolicy.html)

# IAM ユーザーに自分のパスワード変更を許可する
<a name="id_credentials_passwords_enable-user-change"></a>

**注記**  
フェデレーション ID を持つユーザーは、ID プロバイダーが定義したプロセスを使用してパスワードを変更します。[ベストプラクティス](best-practices.md)として、人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには、ID プロバイダーとのフェデレーションの使用を必須とします。

IAM ユーザーに、AWS マネジメントコンソール にサインインするためのパスワードを変更するアクセス許可を付与できます。これには以下の 2 つの方法があります。
+ [アカウントのすべての IAM ユーザーが自分のパスワードを変更できるようにします](#proc_letalluserschangepassword)。
+ [選択した IAM ユーザーだけが自分のパスワードを変更できるようにします](#proc_letselectuserschangepassword)。このシナリオでは、すべてのユーザーが各自のパスワードを変更するオプションを無効にし、一部のユーザーにのみアクセス許可を付与する IAM ポリシーを使用します。この方法では、ユーザーは各自のパスワードと、必要に応じて各自のアクセスキーなどの他の認証情報を変更できます。

**重要**  
IAM ユーザーが強力なパスワードを作成することを求める[カスタムパスワードポリシーを設定](id_credentials_passwords_account-policy.md)することをお勧めします。

## すべての IAM ユーザーが自分のパスワードを変更できるようにします。
<a name="proc_letalluserschangepassword"></a>

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで [**アカウント設定**] をクリックします。

1. **[パスワードポリシー]** セクションで、**[編集]** を選択します。

1. カスタムパスワードポリシーを使用するには、**[カスタム]** を選択します。

1. **[ユーザーにパスワードの変更を許可]** を選択し、**[変更の保存]** をクリックします。これにより、アカウントのすべてのユーザーに、そのユーザーだけに対する `iam:ChangePassword` アクションと `iam:GetAccountPasswordPolicy` アクションへのアクセスが付与されます。

1. パスワードを変更するための次の手順をユーザーに提供します: [IAM ユーザーが自分のパスワードを変更する方法](id_credentials_passwords_user-change-own.md)。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ `[aws iam update-account-password-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html)`

------
#### [ API ]

AWS マネジメントコンソール のサインインページの URL のエイリアスを作成するには、以下のオペレーションを呼び出します。
+ `[UpdateAccountPasswordPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html)` 

------

## 選択された IAM ユーザーが自分のパスワードを変更可能にするには
<a name="proc_letselectuserschangepassword"></a>

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで **[アカウント設定]** をクリックします。

1. **[パスワードポリシー]** セクションで、**[ユーザーにパスワードの変更を許可]** が選択されていないことを確認します。このチェックボックスがオンになっている場合、すべてのユーザーが自分のパスワードを変更できます。（前の手順を参照）。

1. パスワードの変更が許可されている必要があるユーザーを作成します (まだ存在していない場合)。詳細については、「[AWS アカウント で IAM ユーザーを作成する](id_users_create.md)」を参照してください。

1. (オプション) 自分のパスワードの変更を許可するユーザーに対して IAM グループを作成し、そのグループに前のステップのユーザーを追加します。詳細については、「[IAM ユーザーグループ](id_groups.md)」を参照してください。

1. 以下のポリシーをグループに割り当てます 詳細については、「[IAM ポリシーを管理する](access_policies_manage.md)」を参照してください。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "iam:GetAccountPasswordPolicy",
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": "iam:ChangePassword",
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       }
     ]
   }
   ```

------

   このポリシーでは、ユーザーに [ChangePassword (パスワードの変更)](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html) アクションへのアクセスを許可して、コンソール、AWS CLI、Tools for Windows PowerShell、または API から自分のパスワードのみを変更できるようにします。また、[GetAccountPasswordPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html) アクションへのアクセス権も付与します。これにより、ユーザーは現在のパスワードポリシーを表示できます。このアクセス許可は、ユーザーが **[パスワードの変更]** ページでアカウントパスワードポリシーを表示できるようにするために必要です。変更されたパスワードがポリシーの要件を確実に満たしているようにするために、ユーザーは現在のパスワードポリシーの読み取りが許可されている必要があります。

1. パスワードを変更するための次の手順をユーザーに提供します: [IAM ユーザーが自分のパスワードを変更する方法](id_credentials_passwords_user-change-own.md)。

------

### 詳細情報
<a name="HowToPwdIAMUser-moreinfo"></a>

認証情報の管理の詳細については、次のトピックを参照してください。
+ [IAM ユーザーに自分のパスワード変更を許可する](#id_credentials_passwords_enable-user-change) 
+ [AWS のユーザーパスワード](id_credentials_passwords.md)
+ [IAM ユーザー用のアカウントパスワードポリシーを設定する](id_credentials_passwords_account-policy.md)
+ [IAM ポリシーを管理する](access_policies_manage.md)
+ [IAM ユーザーが自分のパスワードを変更する方法](id_credentials_passwords_user-change-own.md)

# IAM ユーザーが自分のパスワードを変更する方法
<a name="id_credentials_passwords_user-change-own"></a>

IAM ユーザーに自分のパスワードを変更するアクセス許可が付与されている場合、ユーザーは AWS マネジメントコンソール の特別なページを使用してこれを行うことができます。AWS CLI または AWS API を使用することもできます。

**Topics**
+ [

## 必要なアクセス許可
](#change-own-passwords-permissions-required)
+ [

## IAM ユーザー自身によるパスワードの変更方法 (コンソール)
](#ManagingUserPwdSelf-Console)
+ [

## IAM ユーザー自身によるパスワードの変更方法 (AWS CLI または AWS API)
](#ManagingUserPwdSelf-CLIAPI)

## 必要なアクセス許可
<a name="change-own-passwords-permissions-required"></a>

IAM ユーザーのパスワードを変更するには、次のポリシーからのアクセス許可が必要です: [AWS: IAM ユーザーが [セキュリティ認証情報] ページで自分のコンソールパスワードを変更できるようにします](reference_policies_examples_aws_my-sec-creds-self-manage-password-only.md)。

## IAM ユーザー自身によるパスワードの変更方法 (コンソール)
<a name="ManagingUserPwdSelf-Console"></a>

以下の手順では、IAM ユーザーが AWS マネジメントコンソール を使用して自分のパスワードを変更する方法について説明します。

**IAM ユーザー自身のパスワードを変更するには (コンソール)**

1. AWS アカウント ID またはアカウントエイリアス、IAM ユーザー名、およびパスワードを使用して [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
**注記**  
利便性のため、AWS サインインページは、ブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。以前に別のユーザーとしてサインインしたことがある場合は、ページの下部にある**[別のアカウントにサインイン]**を選択し、メインのサインインページに戻ります。そこから、AWS アカウント ID またはアカウントエイリアスを入力して、アカウントの IAM ユーザーサインインページにリダイレクトされるようにすることができます。

   AWS アカウント アカウント ID の取得については、管理者にお問い合わせください。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[AWS マネジメントコンソールのセキュリティ認証情報へのリンク\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **[AWS IAM 認証情報]** タブで、**[パスワードを変更]** を選択します。

1. [**Current password (現在のパスワード)**] に現在のパスワードを入力します。[**New password (新しいパスワード)**] ボックスおよび [**Confirm new password (新しいパスワードの確認)**] ボックスに新しいパスワードを入力します。その後、**[パスワードを更新]** を選択します。
**注記**  
新しいパスワードは、アカウントのパスワードポリシーの要件を満たしている必要があります。詳細については、「[IAM ユーザー用のアカウントパスワードポリシーを設定する](id_credentials_passwords_account-policy.md)」を参照してください。

## IAM ユーザー自身によるパスワードの変更方法 (AWS CLI または AWS API)
<a name="ManagingUserPwdSelf-CLIAPI"></a>

以下の手順では、IAM ユーザーが AWS CLI または AWS API を使用して自身のパスワードを変更する方法について説明します。

**自身の IAM パスワードを変更するには、以下を使用します。**
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html](https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html)
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html)

# IAM ユーザーのアクセスキーを管理します。
<a name="id_credentials_access-keys"></a>

**重要**  
[ベストプラクティス](best-practices.md)は、アクセスキーのような長期的認証情報を作成するのではなく、IAM ロールなどの一時的なセキュリティ認証情報を使用することです。アクセスキーを作成する前に、[長期的なアクセスキーの代替案](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys)を確認してください。

アクセスキーは、IAM ユーザーまたは AWS アカウントのルートユーザー の長期的な認証情報です。アクセスキーを使用して、AWS CLI または AWS API (直接または AWS SDK を使用) にプログラムでリクエストに署名することができます。詳細については、「[AWS セキュリティ認証情報を使用してプログラムでアクセスする](security-creds-programmatic-access.md)」を参照してください。

アクセスキーは、アクセスキー ID (例: `AKIAIOSFODNN7EXAMPLE`) とシークレットアクセスキー (例: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`) の 2 つで構成されています。リクエストを認証するために、アクセスキー ID とシークレットアクセスキーの両方を使用する必要があります。



アクセスキーペアを作成する場合は、アクセスキー ID とシークレットアクセスキーを安全な場所に保存します。シークレットアクセスキーは、キー作成時にのみ取得できます。シークレットアクセスキーを紛失した場合は、そのアクセスキーを削除し、新しく作成する必要があります。詳細な手順については、「[アクセスキーを更新する](id-credentials-access-keys-update.md)」を参照してください。

アクセスキーはユーザーごとに最大 2 つまで持つことができます。

**重要**  
アクセスキーを持つ IAM ユーザーは、アカウントのセキュリティリスクとなります。アクセスキーを安全に管理します。[アカウント識別子を確認する](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html)ためであっても、アクセスキーを認可されていない当事者に提供しないでください。提供すると、第三者がアカウントへの永続的なアクセスを取得する場合があります。  
アクセス キーを使用する場合は、次の点に注意してください。  
アクセス キーを作成する際に、アカウントのルート認証情報を使用**しないでください**。
アプリケーションファイルにアクセスキーや認証情報を保存**しないでください**。
プロジェクト領域にアクセス キーや認証情報を含むファイルを**含めないでください**。
共有 AWS 認証情報ファイルに保存されているアクセスキーまたは認証情報は、プレーンテキストで保存されます。

## モニタリングの推奨事項
<a name="monitor-access-keys"></a>

アクセスキーを作成した後:
+ AWS CloudTrail を使用してアクセスキーの使用状況をモニタリングし、不正なアクセス試行を検出します。詳細については、「[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)」を参照してください。
+ アクセスの拒否を管理者に通知する CloudWatch アラームを設定し、悪意のあるアクティビティを検出できるようにします。詳細については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)」を参照してください。
+ 必要に応じて、アクセスキーを定期的に確認、更新、削除します。

以下のトピックでは、アクセスキーに関連する管理タスクについて詳しく説明します。

**Topics**
+ [

## モニタリングの推奨事項
](#monitor-access-keys)
+ [

# インラインポリシーを IAM ユーザーにアタッチしてアクセスキーの使用を制御する
](access-keys_inline-policy.md)
+ [

# アクセスキーを管理するために必要なアクセス許可
](access-keys_required-permissions.md)
+ [

# IAM ユーザーが独自のアクセスキーを管理する方法
](access-key-self-managed.md)
+ [

# IAM 管理者が IAM ユーザーアクセスキーを管理する方法
](access-keys-admin-managed.md)
+ [

# アクセスキーを更新する
](id-credentials-access-keys-update.md)
+ [

# アクセスキーを保護する
](securing_access-keys.md)

# インラインポリシーを IAM ユーザーにアタッチしてアクセスキーの使用を制御する
<a name="access-keys_inline-policy"></a>

ベストプラクティスとして、[ワークロードはIAMロールを持つ一時的な認証情報](best-practices.md#bp-workloads-use-roles)を使用して AWS にアクセスすることをお勧めします。アクセスキーを持つ IAM ユーザーには、最小特権アクセスを割り当て、[多要素認証 (MFA)](id_credentials_mfa.md) を有効にする必要があります。IAM ロールの引き受けに関する詳細については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。

ただし、サービスの自動化やその他の短期的なユースケースの概念実証テストを作成し、アクセスキーを持つ IAM ユーザーを使用してワークロードを実行する場合は、[ポリシー条件を使用して IAM ユーザー認証情報へのアクセスをさらに制限](best-practices.md#use-policy-conditions)することをお勧めします。

このような状況では、指定した時刻以降に認証情報を期限切れにする期限付きポリシーを作成するか、安全なネットワークからワークロードを実行している場合は、IP 制限ポリシーを使用できます。

これらのユースケースの両方で、アクセスキーを持つ IAM ユーザーにアタッチされたインラインポリシーを使用できます。

**IAM ユーザーの期限付きポリシーを設定するには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ユーザー]** を選択し、短期ユースケースのユーザーを選択します。ユーザーをまだ作成していない場合は、ここで[ユーザーの作成](getting-started-workloads.md)ができます。

1. ユーザーの **[詳細]** ページが開くので、**[アクセス許可]** タブを選択します。

1. **[アクセス許可の追加]**、**[インラインポリシーの作成]** の順に選択します。

1. **[ポリシーエディタ]** セクションで、**[JSON]** を選択して JSON エディタを表示します。

1. JSON エディタで、次のポリシーを入力し、`aws:CurrentTime` タイムスタンプの値を目的の有効期限切れの日時に置き換えます。

------
#### [ JSON ]

****  

   ```
   {
   "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
         "DateGreaterThan": {
         "aws:CurrentTime": "2025-03-01T00:12:00Z"
           }
         }
       }
     ]
   }
   ```

------

   このポリシーは、 `Deny` 効果を使用して、指定された日付以降のすべてのリソースに対するすべてのアクションを制限します。`DateGreaterThan` 条件は、現在の時刻と設定したタイムスタンプを比較します。

1. **[次へ]** を選択して **[確認と作成]** ページに進みます。**ポリシー**の詳細で、**[ポリシー名]** にポリシーの名前を入力し、**[ポリシーの作成]** を選択します。

ポリシーが作成されると、ユーザーの **[アクセス許可]** タブに表示されます。現在の時刻がポリシーで指定された時刻以上になると、ユーザーは AWS リソースにアクセスできなくなります。これらのアクセスキーに指定した有効期限をワークロード開発者に必ず通知してください。

**IAM ユーザーの IP 制限ポリシーを設定するには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ユーザー]** を選択し、安全なネットワークからワークロードを実行するユーザーを選択します。ユーザーをまだ作成していない場合は、ここで[ユーザーの作成](getting-started-workloads.md)ができます。

1. ユーザーの **[詳細]** ページが開くので、**[アクセス許可]** タブを選択します。

1. **[アクセス許可の追加]**、**[インラインポリシーの作成]** の順に選択します。

1. **[ポリシーエディタ]** セクションで、**[JSON]** を選択して JSON エディタを表示します。

1. 次の IAM ポリシーを JSON エディタにコピーし、パブリック IPv4 または IPv6 アドレス、または範囲を必要に応じて変更します。現在のパブリック IP アドレスを確認するには、[https://checkip.amazonaws.com](https://checkip.amazonaws.com/) を使用できます。スラッシュ表記を使用して、個々の IP アドレスまたは IP アドレスの範囲を指定できます。詳細については、「[aws:SourceIp](reference_policies_condition-keys.md#condition-keys-sourceip)」を参照してください。
**注記**  
IP アドレスは VPN またはプロキシサーバーによって難読化されてはなりません。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Sid":"IpRestrictionIAMPolicyForIAMUser",
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
           "NotIpAddress": {
             "aws:SourceIp": [
               "203.0.113.0/24",
               "2001:DB8:1234:5678::/64",
               "203.0.114.1"
             ]
           },
           "BoolIfExists": {
             "aws:ViaAWSService": "false"
           }
         }
       }
     ]
   }
   ```

------

   このポリシーの例では、リクエストが (CIDR 表記で指定された) ネットワーク「203.0.113.0/24」、「2001:DB8:1234:5678::/64」、または特定の IP アドレス「203.0.114.1」から発生した場合を除き、このポリシーが適用された IAM ユーザーのアクセスキーの使用を拒否します。

1. **[次へ]** を選択して **[確認と作成]** ページに進みます。**ポリシー**の詳細で、**[ポリシー名]** にポリシーの名前を入力し、**[ポリシーの作成]** を選択します。

ポリシーが作成されると、ユーザーの **[アクセス許可]** タブに表示されます。

このポリシーを AWS Organizations の複数の AWS アカウントでサービスコントロールポリシー (SCP) として適用することもできますが、このポリシーステートメントをこの SCP の対象となる AWS アカウント内の IAM ユーザーにのみ適用されるようにするための追加条件 `aws:PrincipalArn` を使用することをお勧めします。次のポリシーには、その更新が含まれています。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "IpRestrictionServiceControlPolicyForIAMUsers",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "2001:DB8:1234:5678::/64",
            "203.0.114.1"
          ]
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        },
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:user/*"
        }
      }
    }
  ]
}
```

------

# アクセスキーを管理するために必要なアクセス許可
<a name="access-keys_required-permissions"></a>

**注記**  
`iam:TagUser` は、アクセスキーの説明を追加および編集するためのオプションのアクセス許可です。詳細については、[IAM ユーザーにタグ付けする](id_tags_users.md)を参照してください。

IAM ユーザーのアクセスキーを作成するには、次のポリシーのアクセス許可が必要です。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CreateOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:TagUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}
```

------

IAM ユーザーのアクセスキーを更新するには、次のポリシーのアクセス許可が必要です。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ManageOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
                "iam:GetAccessKeyLastUsed",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:UpdateAccessKey",
                "iam:TagUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}
```

------

# IAM ユーザーが独自のアクセスキーを管理する方法
<a name="access-key-self-managed"></a>

IAM 管理者は、「[アクセスキーを管理するために必要なアクセス許可](access-keys_required-permissions.md)」で説明されているポリシーをアタッチすることで、アクセスキーを自己管理するためのアクセス許可を IAM ユーザーに付与できます。

これらのアクセス許可により、IAM ユーザーは次の手順を使用して、ユーザー名に関連付けられたアクセスキーを作成、アクティブ化、非アクティブ化、削除できます。

**Topics**
+ [

## 自分のアクセスキーを作成する (コンソール)
](#Using_CreateAccessKey)
+ [

## アクセスキーを非アクティブ化する (コンソール)
](#deactivate-access-key-seccreds)
+ [

## アクセスキーをアクティブ化する (コンソール)
](#activate-access-key-seccreds)
+ [

## アクセスキーを削除する (コンソール)
](#delete-access-key-seccreds)

## 自分のアクセスキーを作成する (コンソール)
<a name="Using_CreateAccessKey"></a>

適切なアクセス許可が付与されている場合は、AWS マネジメントコンソールを使用して自分のアクセスキーを作成できます。

**自分のアクセスキーを作成するには (コンソール)**

1. AWS アカウント ID またはアカウントエイリアス、IAM ユーザー名、およびパスワードを使用して [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
**注記**  
利便性のため、AWS サインインページは、ブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。以前に別のユーザーとしてサインインしたことがある場合は、ページの下部にある**[別のアカウントにサインイン]**を選択し、メインのサインインページに戻ります。そこから、AWS アカウント ID またはアカウントエイリアスを入力して、アカウントの IAM ユーザーサインインページにリダイレクトされるようにすることができます。

   AWS アカウント アカウント ID の取得については、管理者にお問い合わせください。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[AWS マネジメントコンソールのセキュリティ認証情報へのリンク\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. [**Access keys (アクセスキー)**] セクションで、[**Create access key (アクセスキーを作成)**] を選択します。既に 2 つのアクセスキーがある場合、このボタンは無効になるため、新しいアクセスキーを作成する前に、前のアクセスキーを削除する必要があります。

1. **[Access key best practices & alternatives]** (アクセスキーのベストプラクティスと代替方法) ページで、対象のユースケースを選択し、長期的なアクセスキーの作成を避けるのに役立つその他のオプションを確認します。依然としてユースケースにアクセスキーが必要だと考えられる場合は、**[Other]** (その他)、**[Next]** (次へ) の順に選択します。

1. (オプション) アクセスキーの説明タグに値を設定します。これにより、タグのキーと値のペアが IAM ユーザーに対し追加されます。後で、アクセスキーを識別し、更新する際にこの設定が役立ちます。タグキーには、アクセスキー ID が設定されます。タグ値には、入力したアクセスキーの説明が設定されます。完了したら、**[Create access key]** (アクセスキーを作成) を選択します。

1. **[Retrieve access keys]** (アクセスキーの取得) ページで、**[Show]** (表示) を選択してユーザーのシークレットアクセスキーの値を表示するか、**[Download .csv file]** (.csv ファイルをダウンロード) を選択します。これはシークレットアクセスキーを保存する唯一の機会です。シークレットアクセスキーを安全な場所に保存したら、**[Done]** (完了) を選択します。

## アクセスキーを非アクティブ化する (コンソール)
<a name="deactivate-access-key-seccreds"></a>

適切なアクセス許可が付与されている場合は、AWS マネジメントコンソールを使用して自分のアクセスキーを非アクティブ化できます。

**アクセスキーを無効にするには**

1. AWS アカウント ID またはアカウントエイリアス、IAM ユーザー名、およびパスワードを使用して [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
**注記**  
利便性のため、AWS サインインページは、ブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。以前に別のユーザーとしてサインインしたことがある場合は、ページの下部にある**[別のアカウントにサインイン]**を選択し、メインのサインインページに戻ります。そこから、AWS アカウント ID またはアカウントエイリアスを入力して、アカウントの IAM ユーザーサインインページにリダイレクトされるようにすることができます。

   AWS アカウント アカウント ID の取得については、管理者にお問い合わせください。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[AWS マネジメントコンソールのセキュリティ認証情報へのリンク\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **[Access keys]**アクセスキーセクションで、無効にするキーを選択し、**[Actions]** (アクション)、**[Deactivate]** (無効化) の順に選択します。確認を求めるメッセージが表示されたら、[**Deactivate (無効化)**] を選択します。非アクティブ化されたアクセスキーは、2 つのアクセスキーの制限にカウントされます。

## アクセスキーをアクティブ化する (コンソール)
<a name="activate-access-key-seccreds"></a>

適切なアクセス許可が付与されている場合は、AWS マネジメントコンソールを使用して自分のアクセスキーをアクティブ化できます。

**アクセスキーを有効にするには**

1. AWS アカウント ID またはアカウントエイリアス、IAM ユーザー名、およびパスワードを使用して [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
**注記**  
利便性のため、AWS サインインページは、ブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。以前に別のユーザーとしてサインインしたことがある場合は、ページの下部にある**[別のアカウントにサインイン]**を選択し、メインのサインインページに戻ります。そこから、AWS アカウント ID またはアカウントエイリアスを入力して、アカウントの IAM ユーザーサインインページにリダイレクトされるようにすることができます。

   AWS アカウント アカウント ID の取得については、管理者にお問い合わせください。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[AWS マネジメントコンソールのセキュリティ認証情報へのリンク\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **[Access keys]** (アクセスキー) セクションで、有効にするキーを選択し、**[Actions]** (アクション)、**[Activate]** (有効化) の順に選択します。

## アクセスキーを削除する (コンソール)
<a name="delete-access-key-seccreds"></a>

適切なアクセス許可が付与されている場合は、AWS マネジメントコンソールを使用して自分のアクセスキーを削除できます。

**不要になったアクセスキーを削除するには**

1. AWS アカウント ID またはアカウントエイリアス、IAM ユーザー名、およびパスワードを使用して [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
**注記**  
利便性のため、AWS サインインページは、ブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。以前に別のユーザーとしてサインインしたことがある場合は、ページの下部にある**[別のアカウントにサインイン]**を選択し、メインのサインインページに戻ります。そこから、AWS アカウント ID またはアカウントエイリアスを入力して、アカウントの IAM ユーザーサインインページにリダイレクトされるようにすることができます。

   AWS アカウント アカウント ID の取得については、管理者にお問い合わせください。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[AWS マネジメントコンソールのセキュリティ認証情報へのリンク\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **[Access keys]** (アクセスキー) セクションで、削除するキーを選択し、**[Actions]** (アクション)、**[Delete]** (削除)の順に選択します。ダイアログの指示に従って、まず **[Deactivate]** (無効化) をしてから、削除することを確認します。アクセスキーを完全に削除する前に、アクセスキーが使用されていないことを確認することをお勧めします。

# IAM 管理者が IAM ユーザーアクセスキーを管理する方法
<a name="access-keys-admin-managed"></a>

IAM 管理者は、個々の IAM ユーザーに関連付けられたアクセスキーを作成、アクティブ化、非アクティブ化、削除できます。また、アクセスキーを持つアカウントの IAM ユーザーを一覧表示し、特定のアクセスキーを持つ IAM ユーザーを見つけることもできます。

**Topics**
+ [

## IAM ユーザーのアクセスキーを作成するには
](#admin-create-access-key)
+ [

## IAM ユーザーのためにアクセスキーを非アクティブ化するには
](#admin-deactivate-access-key)
+ [

## IAM ユーザーのためにアクセスキーをアクティブ化するには
](#admin-activate-access-key)
+ [

## IAM ユーザーのためにアクセスキーを削除するには
](#admin-delete-access-key)
+ [

## IAM ユーザーのアクセスキーを一覧表示するには
](#admin-list-access-key)
+ [

## IAM ユーザーのアクセスキーを一覧表示するには
](#admin-list-access-key)
+ [

## アカウント内のユーザーのすべてのアクセスキー ID を表示するには
](#admin-list-all-access-keys)
+ [

## アクセスキー ID を使用してユーザーを検索するには
](#admin-find-user-access-keys)
+ [

## アクセスキー ID の最新の使用状況を確認するには
](#admin-find-most-recent-use-access-keys)

## IAM ユーザーのアクセスキーを作成するには
<a name="admin-create-access-key"></a>

------
#### [ Console ]

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. ユーザー詳細ページを開くには、ユーザー名を選択します。

1. **[セキュリティ認証情報]** タブの **[アクセスキー]** セクションで、**[アクセスキーの作成]** を選択します。

   このボタンが無効化されている場合は、新しいキーを作成する前に、既存のキーのいずれかを削除する必要があります。

1. **[Access key best practices & alternatives]** (アクセスキーのベストプラクティスと代替案) ページで、ベストプラクティスと代替案を確認します。ユースケースを選択して、長期的なアクセスキーの作成を避けるのに役立つ他のオプションを確認します。

1. 依然としてユースケースにアクセスキーが必要だと考えられる場合は、**[Other]** (その他)、**[Next]** (次へ) の順に選択します。

1. **(オプション)** **[説明タグの設定]** ページで、アクセスキーに説明タグを追加して、アクセスキーの追跡に役立てることができます。**[アクセスキーを作成]** を選択します。

1. **[Retrieve access key]** (アクセスキーの取得) ページで、**[Show]** (表示) を選択し、ユーザーのシークレットアクセスキーの値を表示します。

1. アクセスキー ID とシークレットアクセスキーを、ご使用のコンピュータの安全な場所に `.csv` ファイルとして保存するには、**[Download .csv file]** (.csv ファイルをダウンロード) を選択します。
**重要**  
新しく作成したアクセスキーを表示またはダウンロードできるのはこのときだけであり、復元することはできません。アクセスキーを安全に保持してください。

ユーザー用のアクセスキー作成後、キーペアはデフォルトで有効状態になっているので、対象のユーザーはすぐにキーペアを使用できます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html) 

------

## IAM ユーザーのためにアクセスキーを非アクティブ化するには
<a name="admin-deactivate-access-key"></a>

------
#### [ Console ]

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. ユーザー詳細ページを開くには、ユーザー名を選択します。

1. **[セキュリティ認証情報]** タブの **[アクセスキー]** セクションで、**[アクション]** ドロップダウンメニューを選択し、**[非アクティブ化]** を選択します。

1. **[非アクティブ化]** ダイアログボックスで **[非アクティブ化]** を選択して、アクセスキーを非アクティブ化することを確定します。

アクセスキーを非アクティブ化すると、API コールで使用できなくなります。必要に応じて、再度アクティブ化できます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html) 

------

## IAM ユーザーのためにアクセスキーをアクティブ化するには
<a name="admin-activate-access-key"></a>

------
#### [ Console ]

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. ユーザー詳細ページを開くには、ユーザー名を選択します。

1. **[セキュリティ認証情報]** タブの **[アクセスキー]** セクションで、**[アクション]** ドロップダウンメニューを選択し、**[アクティブ化]** を選択します。

アクセスキーをアクティブ化すると、API コールで使用できるようになります。必要に応じて、再度非アクティブ化できます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html) 

------

## IAM ユーザーのためにアクセスキーを削除するには
<a name="admin-delete-access-key"></a>

アクセスキーが非アクティブ化した後、不要になったら削除します。

------
#### [ Console ]

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. ユーザー詳細ページを開くには、ユーザー名を選択します。

1. **[セキュリティ認証情報]** タブの **[アクセスキー]** セクションで、アクセスキーを非アクティブ化するための **[アクション]** ドロップダウンメニューを選択し、**[削除]** を選択します。

1. **[削除]** ダイアログボックスで、テキスト入力フィールドにアクセスキー ID を入力し、**[削除]** を選択して、アクセスキーを削除することを確定します。

アクセスキーを削除すると、復元できません。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html) 

------

## IAM ユーザーのアクセスキーを一覧表示するには
<a name="admin-list-access-key"></a>

IAM ユーザーに関連付けられたアクセスキー ID のリストを表示できます。

------
#### [ Console ]

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. ユーザー詳細ページを開くには、ユーザー名を選択します。

1. **[セキュリティ認証情報]** タブの **[アクセスキー]** セクションに、ユーザーのアクセスキーが一覧表示されます。

各 IAM ユーザーは、2 つのアクセスキーを持つことができます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) 

------

## IAM ユーザーのアクセスキーを一覧表示するには
<a name="admin-list-access-key"></a>

IAM ユーザーに関連付けられたアクセスキー ID のリストを表示できます。

------
#### [ Console ]

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. ユーザー詳細ページを開くには、ユーザー名を選択します。

1. **[セキュリティ認証情報]** タブの **[アクセスキー]** セクションに、表示される各キーのステータスを含む、ユーザーのアクセス キー ID が一覧表示されます。
**注記**  
ユーザーのアクセスキー ID のみが表示されます。シークレットアクセスキーは、キー作成時にのみ取得できます。

各 IAM ユーザーは、2 つのアクセスキーを持つことができます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) 

------

## アカウント内のユーザーのすべてのアクセスキー ID を表示するには
<a name="admin-list-all-access-keys"></a>

AWS アカウント内のユーザーのアクセスキー ID のリストを表示できます。

------
#### [ Console ]

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. ユーザー詳細ページを開くには、ユーザー名を選択します。

1. 必要に応じて、以下の手順を行い、[**アクセスキー ID**] 列をユーザーテーブルに追加します。

   1. 右端のテーブルの上で、**[設定]** アイコン (![\[Preferences icon\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/console-settings-icon.console.png)) を選択します。

   1. **[設定]** ダイアログボックスの **[表示可能な列を選択]** で、**[アクセスキー ID]** を有効にします。

   1. **[確認]** を選択して、ユーザーのリストに戻ります。リストが更新され、アクセスキー ID が含まれるようになります。

1. **[アクセスキー ID]** 列には、各アクセスキーの状態と、その後に ID が表示されます (**`Active - AKIAIOSFODNN7EXAMPLE`**、**`Inactive - AKIAI44QH8DHBEXAMPLE`** など)。

   この情報を使用して、1 つ以上のアクセスキーを持つユーザーのアクセスキー ID を表示およびコピーできます。この列のアクセスキーのないユーザーに、**[`-`]** と表示されます。
**注記**  
シークレットアクセスキーは、キー作成時にのみ取得できます。

各 IAM ユーザーは、2 つのアクセスキーを持つことができます。

------

## アクセスキー ID を使用してユーザーを検索するには
<a name="admin-find-user-access-keys"></a>

アクセスキー ID を使用して、AWS アカウント内のユーザーを検索できます。

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインの検索ボックスに、AKIAI44QH8DHBEXAMPLE などの **[アクセスキー ID]** を入力します。

1. アクセスキー ID が関連付けられている IAM ユーザーがナビゲーションペインに表示されます。ユーザー詳細ページを開くには、ユーザー名を選択します。

------

## アクセスキー ID の最新の使用状況を確認するには
<a name="admin-find-most-recent-use-access-keys"></a>

アクセスキーの最新の使用状況は、IAM ユーザーページのユーザーリスト、ユーザーの詳細ページ、認証情報レポートに表示されます。

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ユーザーリストで、**[最後に使用したアクセスキー]** 列を確認します。

   この列が表示されない場合は、**[設定]** アイコン (![\[Preferences icon\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/console-settings-icon.console.png)) を選択し、**[表示可能な列を選択]** で **[最後に使用したアクセスキー]** を有効にして、列が表示されるようにします。

1. (オプション) ナビゲーションペインの **[アクセスレポート]** で **[認証情報レポート]** を選択して、アカウント内のすべての IAM ユーザーについて最後に使用したアクセスキーの情報を含むレポートをダウンロードします。

1. (オプション) ユーザーの詳細を表示する IAM ユーザーを選択します。**[概要]** セクションには、アクセスキー ID、そのステータス、および最後に使用した日時が含まれます。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html) 

------

# アクセスキーを更新する
<a name="id-credentials-access-keys-update"></a>

セキュリティの[ベストプラクティス](best-practices.md#update-access-keys)として、IAM ユーザーのアクセスキーは、従業員が退職するときなど、必要に応じて更新することをお勧めします。IAM ユーザーは、必要な権限が付与されている場合、自分のアクセスキーを更新できます。

自身のアクセスキーを更新するために管理者からユーザーに IAM ユーザーアクセス許可を付与する方法については、「[AWS: IAM ユーザーが [セキュリティ認証情報] ページで自分のパスワード、アクセスキー、および SSH パブリックキーを管理できるようにします](reference_policies_examples_aws_my-sec-creds-self-manage-pass-accesskeys-ssh.md)」を参照してください。また、アカウントにパスワードポリシーを適用して、すべての IAM ユーザーにパスワードの更新を要求し、その頻度を決めることもできます。詳細については、「[IAM ユーザー用のアカウントパスワードポリシーを設定する](id_credentials_passwords_account-policy.md)」を参照してください。

**注記**  
シークレットアクセスキーを紛失した場合は、そのアクセスキーを削除し、新しく作成する必要があります。シークレットアクセスキーは、キー作成時にのみ取得できます。この手順を実行して、紛失したアクセスキーを非アクティブ化し、新しい認証情報に置き換えることができます。

**Topics**
+ [

## IAM ユーザーアクセスキーの更新 (コンソール)
](#rotating_access_keys_console)
+ [

## アクセスキーの更新 (AWS CLI)
](#rotating_access_keys_cli)
+ [

## アクセスキーの更新 (AWS API)
](#rotating_access_keys_api)

## IAM ユーザーアクセスキーの更新 (コンソール)
<a name="rotating_access_keys_console"></a>

AWS マネジメントコンソール からアクセスキーを更新できます。

**IAM ユーザーのアプリケーションを中断せずにアクセスキーを更新するには (コンソール)**

1. 最初のアクセスキーがアクティブな間に、2 番目のアクセスキーを作成します。

   1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

   1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

   1. 対象のユーザー名を選択し、[**セキュリティ認証情報**] タブを選択します。

   1. [**Access keys (アクセスキー)**] セクションで、[**Create access key (アクセスキーを作成)**] を選択します。**[Access key best practices & alternatives]** (アクセスキーのベストプラクティスと代替案) ページで、**[Other]** (その他)、**[Next]** (次へ) の順に選択します。

   1. (オプション) アクセスキーの説明タグに値を設定して、この IAM ユーザーにタグキーと値のペアを追加します。後で、アクセスキーを識別し、更新する際にこの設定が役立ちます。タグキーには、アクセスキー ID が設定されます。タグ値には、入力したアクセスキーの説明が設定されます。完了したら、**[Create access key]** (アクセスキーを作成) を選択します。

   1. **[Retrieve access keys]** (アクセスキーの取得) ページで、**[Show]** (表示) を選択してユーザーのシークレットアクセスキーの値を表示するか、**[Download .csv file]** (.csv ファイルをダウンロード) を選択します。これはシークレットアクセスキーを保存する唯一の機会です。シークレットアクセスキーを安全な場所に保存したら、**[Done]** (完了) を選択します。

      ユーザー用のアクセスキー作成後、キーペアはデフォルトで有効状態になっているので、対象のユーザーはすぐにキーペアを使用できます。この時点で、ユーザーには 2 つのアクティブなアクセスキーがあります。

1. すべてのアプリケーションとツールを更新して新しいアクセスキーを使用します。

1. <a name="id_credentials_access-keys-key-still-in-use"></a>最も古いアクセスキーの **[Last used]** (前回使用) を確認して、最初のアクセスキーが使用中かどうかを確認します。先に進む前に、数日間待ってから古いアクセスキーが使用されているかどうかを確認するという方法があります。

1. **[Last used]** (前回使用) の情報で、古いキーが使用された形跡がないことを示していても、最初のアクセスキーをすぐには削除しないことをお勧めします。代わりに、**[Actions]** (アクション)、**[Deactivate]** (無効化) の順に選択し、最初のアクセスキーを無効化します。

1. 新しいアクセスキーのみを使用して、アプリケーションが機能しているかどうかを確認してください。この時点で、元のアクセスキーをまだ使用しているツールやアプリケーションは AWS リソースへアクセスできなくなるので、機能が停止されます。そのようなアプリケーションやツールを見つけた場合は、最初のアクセスキーを再度有効にすることができます。次に、「[Step 3](#id_credentials_access-keys-key-still-in-use)」に戻り、新しいキーを使用するためにこのアプリケーションを更新します。

1. 一定期間待機して、すべてのアプリケーションとツールが更新されていることを確認した後、最初のアクセスキーを削除できます。

   1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

   1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

   1. 対象のユーザー名を選択し、[**セキュリティ認証情報**] タブを選択します。

   1. 削除するアクセスキーの **[Access keys]** (アクセスキー) セクションで、**[Actions]** (アクション) を選択し、次に **[Delete]** (削除) を選択します。ダイアログの指示に従って、まず **[Deactivate]** (無効化) を行ってから、削除することを確認します。

**更新または削除する必要があるアクセスキーを判断する方法 (コンソール)**

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. 必要に応じて、以下の手順を実行して [**Access key age (アクセスキーの古さ)**] 列をユーザーテーブルに追加します。

   1. 右端のテーブルの上で、設定アイコン (![\[Settings icon\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/console-settings-icon.console.png)) を選択します。

   1. [**Manage Columns (列の管理)**] で、[**Access key age (アクセスキーの古さ)**] を選択します。

   1. [**Close (閉じる)**] を選択して、ユーザーのリストに戻ります。

1. [**Access key age (アクセスキーの古さ)**] 列には、最も古いアクティブアクセスキーが作成されてから経過した日数が表示されます。この情報を使用して、更新または削除の必要があるアクセスキーを持つユーザーを検索できます。アクセスキーのないユーザーは、この列に [**None (なし)**] と表示されます。

## アクセスキーの更新 (AWS CLI)
<a name="rotating_access_keys_cli"></a>

AWS Command Line Interface からアクセスキーを更新できます。

**アプリケーションを中断せずにアクセスキーを更新するには (AWS CLI)**

1. 最初のアクセスキーがアクティブな間に、2 番目のアクセスキーを作成します。このキーは、デフォルトでアクティブになります。次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)

     この時点で、ユーザーには 2 つのアクティブなアクセスキーがあります。

1. <a name="step-update-apps"></a>すべてのアプリケーションとツールを更新して新しいアクセスキーを使用します。

1. <a name="step-determine-use"></a>次のコマンドを使用して最初のアクセスキーがまだ使用されているかどうかを確認します。
   +  [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)

   先に進む前に、数日間待ってから古いアクセスキーが使用されているかどうかを確認するという方法があります。

1. ステップ [Step 3](#step-determine-use) で古いキーが使用されていないことがわかっても、最初のアクセスキーはすぐに削除しないことをお勧めします。代わりに、次のコマンドを使用して最初のアクセスキーの状態を `Inactive` に変更します。
   +  [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

1. 新しいアクセスキーのみを使用して、アプリケーションが機能しているかどうかを確認してください。この時点で、元のアクセスキーをまだ使用しているツールやアプリケーションは AWS リソースへアクセスできなくなるので、機能が停止されます。このようなアプリケーションまたはツールは、その状態を `Active` に戻すことで、最初のアクセスキーを再度有効にすることができます。次にステップ [Step 2](#step-update-apps) に戻り、新しいキーを使用するようにこのアプリケーションを更新します。

1. 一定期間待機して、すべてのアプリケーションとツールが更新されたことを確認したら、次のコマンドを使用して最初のアクセスキーを削除できます。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)

## アクセスキーの更新 (AWS API)
<a name="rotating_access_keys_api"></a>

AWS API を使用してアクセスキーを更新できます。

**アプリケーションを中断せずにアクセスキーを更新するには (AWS API)**

1. 最初のアクセスキーがアクティブな間に、2 番目のアクセスキーを作成します。このキーは、デフォルトでアクティブになります。次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html)

     この時点で、ユーザーには 2 つのアクティブなアクセスキーがあります。

1. <a name="step-update-apps-2"></a>すべてのアプリケーションとツールを更新して新しいアクセスキーを使用します。

1. <a name="step-determine-use-2"></a>次のオペレーションを呼び出して最初のアクセスキーがまだ使用されているかどうかを確認します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)

   先に進む前に、数日間待ってから古いアクセスキーが使用されているかどうかを確認するという方法があります。

1. ステップ [Step 3](#step-determine-use-2) で古いキーが使用されていないことがわかっても、最初のアクセスキーはすぐに削除しないことをお勧めします。代わりに、次のオペレーションを呼び出して最初のアクセスキーの状態を `Inactive` に変更します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html)

1. 新しいアクセスキーのみを使用して、アプリケーションが機能しているかどうかを確認してください。この時点で、元のアクセスキーをまだ使用しているツールやアプリケーションは AWS リソースへアクセスできなくなるので、機能が停止されます。このようなアプリケーションまたはツールは、その状態を `Active` に戻すことで、最初のアクセスキーを再度有効にすることができます。次にステップ [Step 2](#step-update-apps-2) に戻り、新しいキーを使用するようにこのアプリケーションを更新します。

1. 一定期間待機して、すべてのアプリケーションとツールが更新されたことを確認したら、次のオペレーションを呼び出して最初のアクセスキーを削除できます。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html)

# アクセスキーを保護する
<a name="securing_access-keys"></a>

アクセスキーを持っているユーザーなら誰でも、AWS リソースに対して同じレベルのアクセス権を持ちます。したがって、AWS でのアクセスキーの保護は非常に困難で、しかも[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)に沿って行う必要があります。

アクセスキーを保護するのに役立つガイダンスについては、以下のセクションを参照してください。

**注記**  
組織によっては、セキュリティ要件とポリシーがこのトピックに記載されているものとは異なる可能性があります。ここで示すのは、一般的なガイドラインとしての提案です。

## AWS アカウントのルートユーザー アクセスキーを削除する (または生成しない)
<a name="root-password"></a>

**アカウントを保護する最善の方法の 1 つは、AWS アカウントのルートユーザー のアクセスキーを持たないことです。**ルートユーザーのアクセスキーを持つ必要がある場合 (まれに) を除いて、キーを生成しないことをお勧めします。代わりに、日常の管理タスクのために AWS IAM アイデンティティセンター で管理ユーザーを作成してください。IAM Identity Center で管理ユーザーを作成する方法については、IAM Identity Center ユーザーガイドの「[はじめに](https://docs.aws.amazon.com//singlesignon/latest/userguide/getting-started.html)」を参照してください。

アカウントのルートユーザーアクセスキーが既にある場合は、そのキーを現在使用しているアプリケーション (ある場合) の場所を見つけ、ルートユーザーアクセスキーを IAM ユーザーアクセスキーに置き換えることをお勧めします。次いで、ルートユーザーアクセスキーを無効にして削除します。アクセスキーを更新する方法の詳細については、「[アクセスキーを更新する](id-credentials-access-keys-update.md)」を参照してください。



## 長期アクセスキーの代わりに一時的なセキュリティ認証情報 (IAM ロール) を使用する
<a name="use-roles"></a>

多くの場合、期限のない長期のアクセスキー (IAM ユーザーのアクセスキーなど) は必要ありません。その代わり、IAM ロールを作成し、一時的なセキュリティ認証情報を生成できます。一時的なセキュリティ認証情報は、アクセスキー ID とシークレットアクセスキーで構成されていますが、認証情報がいつ無効になるかを示すセキュリティトークンも含んでいます。

IAM ユーザーやルートユーザーに関連付けられているものなどの長期的なアクセスキーは、それらを手動で取り消すまで有効です。ただし、IAM ロールや AWS Security Token Service の他の機能を使用して取得した一時的なセキュリティ認証情報は、短期間で期限が切れます。認証情報が誤って開示された場合のリスクに備えて、一時的なセキュリティ認証情報を使用することができます。

以下のシナリオでは、IAM ロールと一時的なセキュリティ認証情報を使用します。
+ **Amazon EC2 インスタンスで実行されているアプリケーションまたは AWS CLI スクリプトがある場合。**アプリケーション内で直接アクセスキーを使用しないでください。アクセスキーをアプリケーションに渡したり、アプリケーションに埋め込んだり、ソースからアクセスキーを読み取ったりしないでください。代わりに、アプリケーションに適したアクセス許可を持つ IAM ロールを定義し、[EC2 のロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)を使用して Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動します。これにより、IAM ロールが Amazon EC2 インスタンスに関連付けられます。この方法により、アプリケーションは AWS へのプログラムされた呼び出しに使用することもできる、一時的なセキュリティ認証情報を取得します。AWS SDK および AWS Command Line Interface (AWS CLI)は、そのロールから一時的なセキュリティ認証情報を自動的に取得できます。
+ **クロスアカウントアクセス許可を付与する必要がある場合。**IAM ロールを使用してアカウント間の信頼を確立し、信頼できるアカウントへ制限されたアクセス許可を 1 つのアカウントのユーザーに付与します。詳細については、「[IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](tutorial_cross-account-with-roles.md)」を参照してください。
+ **モバイルアプリを持っている場合。**暗号化ストレージ内であっても、アクセスキーをアプリに埋め込まないでください。代わりに、[Amazon Cognito](https://aws.amazon.com/cognito/) を使用して、アプリでユーザー ID を管理してください。このサービスでは、Login with Amazon、Facebook、Google、または OpenID Connect (OIDC) に対応している任意の ID プロバイダを使用してユーザーを認証できます。さらに、Amazon Cognito 認証情報プロバイダを使用して、AWS にリクエストを送信するためにアプリが使用する認証情報を管理できます。
+ **AWS に連携しようとしており、組織が SAML 2.0 をサポートしている場合。**SAML 2.0 をサポートする ID プロバイダーを持つ組織で作業する場合は、SAML を使用するようにプロバイダーを設定します。SAML を使用して、AWS と認証情報を交換し、一連の一時的なセキュリティ認証情報を取り戻すことができます。詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。
+ **AWS に連携しようとしており、組織にオンプレミスのアイデンティティストアがある場合。**ユーザーが組織内で認証できる場合、AWS リソースにアクセスするための一時的なセキュリティ認証情報を発行できるアプリケーションを記述することができます。詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。
+ **IAM ポリシーの条件を使用して、予想されるネットワークからのアクセスのみを許可します。**パブリック IP アドレスや仮想プライベートクラウド (VPC) など、予想されるネットワークのみを指定して許可する[条件つきの IAM ポリシー](reference_policies_elements_condition_operators.md)を実装することで、アクセスキーの使用場所と方法を制限できます。これにより、アクセスキーは想定された許容可能なネットワークからのみ使用できることがわかります。

**注記**  
AWS リソースへのプログラムによるアクセスを必要とするアプリケーションで Amazon EC2 インスタンスを使用していますか? その場合には、[EC2 の IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) を使用します。

## IAM ユーザーのアクセスキーを適切に管理する
<a name="iam-user-access-keys"></a>

プログラムによる AWS へのアクセスを設定したい場合、IAM ユーザー用にアクセスキーを作成して、必要なアクセス許可のみをユーザーに付与します。

IAM ユーザーアクセスキーを保護するために、以下の注意事項を守ってください。
+ **アクセスキーを直接コードに埋め込まないでください。**[AWS SDK](https://aws.amazon.com/tools/#sdk) と [AWS コマンドラインツール](https://aws.amazon.com/tools/#cli) では、既知の場所にアクセスキーを置くことができるため、それらをコードで保持する必要がありません。

  次のいずれかの場所にアクセスキーを置きます。
  + **AWS 認証情報ファイル。**AWS SDK と AWS CLI では、AWS 認証情報ファイルに保存した認証情報が自動的に使用されます。

    AWS 認証情報ファイルの使用については、SDK のドキュメントを参照してください。例としては、*AWS SDK for Javaデベロッパーガイド*の「[AWS 認証情報とリージョンを設定する](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup-credentials.html)」および *AWS Command Line Interface ユーザーガイド*の「[設定と認証情報ファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)」などがあります。

    AWS SDK for .NET と AWS Tools for Windows PowerShell の認証情報を保存するには、SDK ストアの使用をお勧めします。詳細については、*AWS SDK for .NET デベロッパーガイド*の「[SDK Store の使用](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/sdk-store.html)」を参照してください。
  + **環境変数。**マルチテナントシステムでは、システム環境変数ではなくユーザー環境変数を選択します。

    環境変数を使用した認証情報の保存の詳細については、*AWS Command Line Interface ユーザーガイド*の「[環境変数](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html)」を参照してください。
+ **異なるアプリケーションには、異なるアクセスキーを使用します**。こうすることで、アクセスキーが公開された場合に、アクセス許可を分離して、個々のアプリケーションに対するアクセスキーを無効化できます。アプリケーションごとに別々のアクセスキーを持つと、[AWS CloudTrail](https://aws.amazon.com/cloudtrail/) ログファイルに個別のエントリが生成されます。この設定により、特定のアクションを実行したアプリケーションを簡単に判別できます。
+ **必要に応じてアクセスキーを更新してください。**アクセスキーが危険にさらされる可能性がある場合は、アクセスキーを更新し、以前のアクセスキーを削除してください。詳細については、「[アクセスキーを更新する](id-credentials-access-keys-update.md)」を参照してください。
+ **使用していないアクセスキーを削除します。**ユーザーが退職したら、そのユーザーがリソースにアクセスできないようにするため、対応する IAM ユーザーを削除します。アクセスキーが最後に使用された日時を調べるには、[https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html) API (AWS CLI コマンド: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)) を使用します。
+ **一時的な認証情報を使用し、最も機密性の高い API 操作ができるよう、多要素認証を設定します。**IAM ポリシーを使用して、ユーザーが呼び出すことができる API オペレーションを指定できます。場合によっては、ユーザーが特に機密性の高いアクションを実行することを許可する前に、このユーザーに AWS MFA で認証することを求める追加のセキュリティが必要となることもあります。たとえば、ユーザーにAmazon EC2 `RunInstances`、`DescribeInstances`、および `StopInstances` アクションの実行を許可するポリシーがすでに存在する可能性があります。ただし `TerminateInstances` のような有害なアクションを制限し、AWS MFA デバイスによって認証される場合に限り、ユーザーがそのアクションを実行できるように管理することもできます。詳細については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。

## AWS アクセスキーを使用してモバイルアプリにアクセスする
<a name="access-keys-mobile-app"></a>

AWS モバイルアプリを使用して、限定された AWS サービスと機能にアクセスできます。モバイルアプリは、外出先でもインシデント対応をサポートするのに役立ちます。詳細およびアプリのダウンロードについては、「[AWS コンソールモバイルアプリケーション](https://aws.amazon.com/console/mobile/)」を参照してください。

コンソールのパスワードまたはアクセスキーを使用して、モバイルアプリにサインインできます。ベストプラクティスとして、ルートユーザーアクセスキーは使用しないでください。その代わりに、モバイルデバイスでパスワードまたは生体認証ロックを使用することに加えて、モバイルアプリを使用して AWS リソースを管理するための IAM ユーザーを作成することを強くお勧めします。モバイルデバイスを紛失した場合は、その IAM ユーザーのアクセス権を削除します。

**アクセスキーを使用してサインインするには (モバイルアプリ)**

1. モバイルデバイスでアプリを開きます。

1. デバイスに ID を初めて追加する場合は、[**Add an identity (ID を追加)**]、[**Access keys (アクセスキー)**] の順に選択します。

   別の ID を使用して既にサインインしている場合は、メニューアイコンを選択し、[**Switch identity** (ID を切り替える)] を選択します。次に、[**Sign in as a different identity (別の ID としてサインイン)**]、[ **Access keys (アクセスキー)**] の順に選択します。

1. [**Access keys (アクセスキー)**] ページで、情報を入力します。
   + **Access key ID (アクセスキー ID)** – アクセスキー ID を入力します。
   + **Secret access key (シークレットアクセスキー)** – シークレットアクセスキーを入力します。
   + **Identity name (ID 名)** – モバイルアプリに表示される ID の名前を入力します。これは、IAM ユーザー名と一致する必要はありません。
   + **Identity PIN (ID PIN)** – 今後のサインイン時に使用する個人識別番号 (PIN) を作成します。
**注記**  
AWS モバイルアプリで生体認証を有効にすると、作成した PIN ではなく、指紋認証または顔認識を使用して検証するように求められます。生体認証に失敗した場合は、代わりに PIN の入力を求められることがあります。

1. [**Verify and add keys**] (確認してキーを追加) を選択します。

   モバイルアプリを使用して、一部のリソースにアクセスできるようになりました。

## 関連情報
<a name="more-resources"></a>

以下のトピックでは、アクセスキーを使用するために AWS SDK および AWS CLI を設定するためのガイダンスを示しています。
+ *AWS SDK for Java デベロッパーガイド*の「[AWS 認証情報とリージョンの設定](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup-credentials.html)」。
+ *AWS SDK for .NET デベロッパーガイド*の「[SDK Store の使用](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/sdk-store.html)」。
+ *AWS SDK for PHP デベロッパーガイド*の「[SDK への認証情報の提供](https://docs.aws.amazon.com/aws-sdk-php/v2/guide/credentials.html)」。
+ Boto 3 (AWS SDK for Python) ドキュメントの「[設定](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html#configuration)」。
+ *AWS Tools for Windows PowerShellユーザーガイド*の「[AWS 認証情報の使用](https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html)」。
+ *AWS Command Line Interface ユーザーガイド*の「[設定と認証情報ファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)」。
+ AWS SDK for .NET デベロッパーガイドの「[IAM ロールを使用したアクセス権の付与](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html)」
+ AWS SDK for Java 2.x で [Amazon EC2 用の IAM ロールを設定します](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html)

## コンソールアクセスでのアクセスキーとシークレットキー認証情報の使用
<a name="console-access-security-keys"></a>

AWS CLI だけでなく、AWS マネジメントコンソールへの直接アクセスにアクセスキーとシークレットキーの認証情報を使用できます。これは AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API コールを使用して実現できます。IAM プリンシパルは、`GetFederationToken` によって提供される一時的な認証情報とトークンを使用してコンソール URL を構築することでコンソールにアクセスできます。詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。

MFA が有効化されている状態で IAM またはルートユーザーの認証情報を使用してコンソールに直接サインインする場合は、MFA が必要です。ただし、(`GetFederationToken` で一時的な認証情報を使用する) 上記の方法を使用する場合、MFA は必要ありません。



## アクセスキーの監査
<a name="Using_access-keys-audit"></a>

コード内の AWS アクセスキーを確認して、キーが所有するアカウントのものであるかどうかを判断できます。アクセスキー ID は、[https://docs.aws.amazon.com/cli/latest/reference/sts/get-access-key-info.html](https://docs.aws.amazon.com/cli/latest/reference/sts/get-access-key-info.html) AWS CLI コマンドまたは [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html) AWS API オペレーションを使用して渡すことができます。

AWS CLI および AWS API オペレーションは、AWS アカウント アクセスキーが属するアカウントの ID を返します。`AKIA` で始まるアクセスキー ID は、IAM ユーザーまたは AWS アカウントのルートユーザー の長期的な認証情報です。`ASIA` で始まるアクセスキー ID は、AWS STS オペレーションを使用して作成される一時的な認証情報です。レスポンスのアカウントがユーザーに属している場合、ルートユーザーとしてサインインしてルートユーザーのアクセスキーを確認できます。次に、[認証情報レポート](id_credentials_getting-report.md)を取得して、キーを所有している IAM ユーザーを確認できます。`ASIA` アクセスキーの一時認証情報をリクエストしたユーザーを確認するには、CloudTrail ログで AWS STS イベントを表示します。

セキュリティ上の理由から、[AWS CloudTrail ログを確認](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)して、AWS でアクションを実行したユーザーを調べることができます。ロール信頼ポリシーで `sts:SourceIdentity` 条件キーを使用すると、ユーザーがロールを引き受けるときに ID を指定するように要求できます。例えば、IAM ユーザーがセッション名として自分のユーザー名を指定するように要求できます。これにより、AWS の特定のアクションを実行したユーザーを特定できます。詳細については、「[`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity)」を参照してください。

このオペレーションは、アクセスキーの状態を示しません。キーは、アクティブ、非アクティブ、または削除済みのいずれかです。アクティブなキーにオペレーションを実行するアクセス許可がない場合があります。削除済みアクセスキーを指定すると、キーが存在しないというエラーが返されることがあります。

# IAM の AWS 多要素認証
<a name="id_credentials_mfa"></a>

セキュリティを向上させるには、多要素認証 (MFA) を設定して AWS リソースを保護することを推奨します。スタンドアロンアカウント、管理アカウント、メンバーアカウントを含むすべての AWS アカウント の AWS アカウントのルートユーザー と、IAM ユーザーに対して MFA を有効にできます。可能な限り、パスキーやセキュリティキーなどのフィッシング耐性のある MFA を使用することをお勧めします。これらの FIDO ベースの認証はパブリックキー暗号化を使用し、フィッシング、中間者攻撃、リプレイ攻撃に耐性があり、TOTP ベースのオプションよりも強力なレベルのセキュリティを提供します。

MFA は、ルートユーザーのすべてのアカウントタイプに適用されます。詳細については、「[AWS Organizations アカウントのルートユーザーの認証情報です。](root-user-best-practices.md#ru-bp-organizations)」を参照してください。

ルートユーザーの MFA を有効化すると、ルートユーザーの認証情報のみが影響を受けます。アカウントの IAM ユーザーは固有の認証情報を持つ独立した ID であり、各 ID には固有の MFA 設定があります。ルートユーザーを保護するための MFA の使用の詳細については、「[AWS アカウントのルートユーザー の多要素認証](enable-mfa-for-root.md)」を参照してください。

AWS アカウントのルートユーザー と IAM ユーザーは、任意のタイプの MFA デバイスを最大 8 台登録できます。複数の MFA デバイスを登録すると、柔軟性をもたせることができ、1 つのデバイスが紛失または損傷した場合にアクセスが中断するリスクを軽減できるようになります。AWS マネジメントコンソールにログインしたり、AWS CLI を使用してセッションを確立したりするには、MFA デバイスが 1 台あれば十分です。

**注記**  
人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用を必須とすることをお勧めします。AWS IAM アイデンティティセンター の使用を検討したことのある場合 IAM Identity Center を使用すると、複数の AWS アカウント へのアクセスを一元的に管理できます。ユーザーには、割り当てられたすべてのアカウントに対する MFA で保護された Single Sign-On によるアクセスを、1 つの場所から提供することができます。IAM Identity Center では、 その内部でユーザー ID の作成および管理を行います。あるいは、既存の SAML 2.0 互換 ID プロバイダーにも簡単に接続することができます。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」(IAM Identity Center とは?) を参照してください。

MFA は、ユーザーが AWS のウェブサイトやサービスにアクセスするときに、サインイン認証情報に加えて、AWS でサポートされている MFA メカニズムからの一意の認証情報を要求することでセキュリティを強化します。

## MFA タイプ
<a name="id_credentials_mfa-types"></a>

AWS は、次の MFA タイプをサポートしています。

**Contents**
+ [

### パスキーとセキュリティキー
](#passkeys-security-keys-for-iam-users)
+ [

### 仮想認証アプリケーション
](#virtual-auth-apps-for-iam-users)
+ [

### ハードウェア TOTP トークン
](#hardware-totp-token-for-iam-users)

### パスキーとセキュリティキー
<a name="passkeys-security-keys-for-iam-users"></a>

AWS Identity and Access Management は MFA のパスキーとセキュリティキーをサポートします。FIDO 標準に基づいて、パスキーではパブリックキー暗号化が使用され、パスワードよりも安全性の高い、強力でフィッシング耐性のある認証が提供されます。AWS は、デバイスバインドパスキー (セキュリティキー) と同期パスキーの 2 種類のパスキーをサポートしています。
+ **セキュリティキー**: これらは YubiKey などの物理デバイスで、認証の 2 番目の要素として使用されます。1 つのセキュリティキーで、複数のルートユーザーアカウントと IAM ユーザーをサポートできます。
+ **同期パスキー**: これらは、Google、Apple、Microsoft アカウントなどのプロバイダーの認証情報マネージャー、および 1Password、Dashlane、Bitwarden などのサードパーティーサービスを 2 番目の要素として使用します。

Apple MacBook の Touch ID などの組み込みの生体認証機能を使用して、認証情報マネージャーのロックを解除し、AWS にサインインできます。パスキーは、指紋、顔、またはデバイス PIN を使用して、選択したプロバイダーで作成されます。モバイルデバイスやハードウェアセキュリティキーといったデバイスからクロスデバイス認証 (CDA) パスキーを使用して、ラップトップなどの別のデバイスにサインインすることもできます。詳細については、[「Cross-Device Authentication](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda) (CDA)」を参照してください。

デバイス間でパスキーを同期することで、AWS へのサインインが容易になり、使いやすさと回復性が向上します。パスキーとセキュリティキーの有効化の詳細については、「[ルートユーザーのパスキーまたはセキュリティキーを有効にする (コンソール）](enable-fido-mfa-for-root.md)」を参照してください。

FIDO 仕様と互換性のあるすべての [FIDO 認定製品](https://fidoalliance.org/certification/fido-certified-products/)のリストが、FIDO アライアンスから提供されています。

### 仮想認証アプリケーション
<a name="virtual-auth-apps-for-iam-users"></a>

仮想認証アプリケーションは、電話やその他のデバイスで実行され、物理デバイスをエミュレートします。仮想認証アプリは、[タイムベースドワンタイムパスワード (TOTP)](https://datatracker.ietf.org/doc/html/rfc6238) アルゴリズムを実装しており、単一デバイスで複数のトークンをサポートします。ユーザーは、サインイン中にプロンプトが表示されたら、デバイスから有効なコードを入力する必要があります。ユーザーに割り当てられた各トークンは一意であることが必要です。ユーザーは、別のユーザーのトークンからコードを入力して認証を受けることはできません。

最も強力な保護を実現するために、[パスキーやセキュリティキー](#passkeys-security-keys-for-iam-users)などのフィッシング耐性のある MFA を使用することをお勧めします。パスキーまたはセキュリティキーをまだ使用できない場合は、ハードウェアの購入承認の待機中、またはハードウェアの到着を待つ間の暫定措置として、仮想 MFA デバイスを使用することをお勧めします。仮想 MFA デバイスとして使用可能なサポートされているアプリケーションのリストについては、「[多要素認証 (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1)」を参照してください。

IAM ユーザーの仮想 MFA デバイスを設定する手順については、「[AWS マネジメントコンソールで仮想 MFA デバイスを割り当てる](id_credentials_mfa_enable_virtual.md)」を参照してください。

**注記**  
AWS アカウント で割り当てられていない仮想 MFA デバイスは、AWS マネジメントコンソール 経由で、またはサインインプロセス中に新しい仮想 MFA デバイスを追加すると削除されます。未割り当ての仮想 MFA デバイスとは、お客様のアカウントにあるデバイスですが、アカウントのルートユーザーまたは IAM ユーザーがサインインプロセスで使用されません。これらは削除されるため、新しい仮想 MFA デバイスをアカウントに追加できます。また、デバイス名を再利用することもできます。  
アカウント内の未割り当ての仮想 MFA デバイスを表示するには、[list-virtual-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-virtual-mfa-devices.html) AWS CLI コマンドまたは [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) コールを使用できます。
仮想 MFA デバイスを非アクティブ化するには、[deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html) AWS CLI コマンドまたは [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) コールを使用できます。このデバイスは未割り当てになります。
未割り当ての仮想 MFA デバイスを AWS アカウント ルートユーザーまたは IAM ユーザーにアタッチするには、[enable-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-mfa-device.html) AWS CLI コマンドまたは [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) コールとともに、デバイスが生成した認証コードが必要となります。

### ハードウェア TOTP トークン
<a name="hardware-totp-token-for-iam-users"></a>

ハードウェアデバイスでは、[タイムベースドワンタイムパスワード (TOTP) アルゴリズム](https://datatracker.ietf.org/doc/html/rfc6238)に基づいて 6 桁の数値コードが生成されます。サインイン時に、ユーザーはデバイスから取得した有効なコードを 2 番目のウェブページに入力する必要があります。

これらのトークンは AWS アカウント でのみ使用されます。AWS とセキュアに共有された一意のトークンシードを持つトークンのみを使用できます。トークンシードは、トークンの生成時に生成されるシークレットキーです。他のソースから購入したトークンは、IAM では機能しません。互換性を確保するには、[OTP トークン](https://www.amazon.com/SafeNet-IDProve-Time-based-6-Digit-Services/dp/B002CRN5X8)または [OTP ディスプレイカード](https://www.amazon.com/SafeNet-IDProve-Card-Amazon-Services/dp/B00J4NGUO4)のいずれかのリンクからハードウェア MFA デバイスを購入する必要があります。
+ ユーザーに割り当てられた各 MFA デバイスは一意であることが必要です。ユーザーは、別のユーザーのデバイスからコードを入力して認証することはできません。サポートされているハードウェア MFA デバイスの詳細については、「[多要素認証 (MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1)」を参照してください。
+ 物理 MFA デバイスを使用する場合は、ハードウェア TOTP デバイスの代わりにセキュリティキーを使用することをお勧めします。セキュリティキーは、バッテリー要件がなく、フィッシングへの耐性があり、1 つのデバイスで複数のユーザーをサポートします。

パスキーまたはセキュリティ キーは、AWS CLI または AWS API からではなく、AWS マネジメントコンソール からのみ有効にできます。セキュリティキーを有効にするには、そのデバイスに物理的にアクセスできる必要があります。

IAM ユーザーのハードウェア TOTP トークンを設定する手順については、「[AWS マネジメントコンソールでハードウェア TOTP トークンを割り当てる](id_credentials_mfa_enable_physical.md)」を参照してください。

**注記**  
**SMS テキストメッセージベース MFA** – AWS では、SMS 多要素認証 (MFA) の有効化のサポートを終了しました。SMS テキストメッセージベースの MFA を使用する IAM ユーザーを抱えているお客様は、別のいずれかの方法 ([パスキーまたはセキュリティキー](id_credentials_mfa_enable_fido.md)、[仮想 (ソフトウェアベースの) MFA デバイス](id_credentials_mfa_enable_virtual.md)、または[ハードウェア MFA デバイス](id_credentials_mfa_enable_physical.md)) に切り替えることをお勧めします。割り当てられた SMS MFA デバイスを使用して、アカウントのユーザーを識別することができます。これを行うには、IAM コンソールに移動して、ナビゲーションペインの [**ユーザー**] を選択し、テーブルの [**MFA**] 列の [**SMS**] を使用してユーザーを探します。

## MFA 奨励事項
<a name="id_credentials_mfa-recommendations"></a>

AWS ID を保護するには、MFA 認証に関する以下の推奨事項に従ってください。
+ [パスキーやセキュリティキー](#passkeys-security-keys-for-iam-users)などのフィッシング耐性のある MFA を MFA デバイスとして使用することをお勧めします。これらの FIDO ベースの認証機能は、フィッシングなどの攻撃に対して最も強力な保護を提供します。
+ AWS アカウント 内の AWS アカウントのルートユーザー と IAM ユーザーに対しては、複数の MFA デバイスを有効にすることをお勧めします。これにより、AWS アカウント のセキュリティレベルを引き上げ、AWS アカウントのルートユーザー などの権限の高いユーザーに対するアクセスの管理を簡素化できます。
+ AWS アカウントのルートユーザー および IAM ユーザーに対し、「[現在サポートされている MFA タイプ](https://aws.amazon.com/iam/features/mfa/)」の任意の組み合わせで、最大 **8** 台の MFA デバイスを登録できます。MFA デバイスが複数ある場合でも、そのユーザとして AWS マネジメントコンソール にログインしたり、AWS CLI を使用してセッションを作成したりするのに必要なのは、1 台の MFA デバイスだけです。IAM ユーザーは既存の MFA デバイスで認証して、追加の MFA デバイスを有効または無効にする必要があります。
+ MFA デバイスが紛失、盗難、またはアクセス不能になった場合は、残りの MFA デバイスのいずれかを使用して、AWS アカウント での回復手順を実行することなく AWS アカウント にアクセスできます。MFA デバイスが紛失または盗難に遭った場合は、関連付けられている IAM プリンシパルからそのデバイスを切り離してください。
+ 複数の MFA を使用すると、地理的に離れた場所にいる従業員やリモートで作業している従業員は、ハードウェアベースの MFA 使用して AWS にアクセスできます。ハードウェアデバイスを 1 台送付したり、1 台のハードウェアデバイスを従業員間で物理的に交換したりする必要はありません。
+ IAM プリンシパルに追加の MFA デバイスを使用すると、1 つ以上の MFA を日常的に使用できると同時に、物理 MFA デバイスをボールドなどの安全な物理的な場所に保存したり、バックアップや冗長性を確保したりできます。

**注意事項**  
セキュリティキーまたはパスキーの MFA 情報を AWS STS API オペレーションに渡して一時的認証情報をリクエストすることはできません。セキュリティキーまたはパスキーを使用する場合は、 `aws login` コマンドを実行して、AWS CLI および AWS SDK で使用する認証情報を取得できます。
AWS CLI コマンドまたは AWS API 操作を使用して [FIDO セキュリティキー](id_credentials_mfa_enable_fido.md)を有効にすることはできません。
複数のルートユーザーまたは IAM MFA デバイスに同じ名前を使用することはできません。

## その他のリソース
<a name="id_credentials_mfa-resources"></a>

MFA の詳細については、次のリソースを参照してください。
+ MFA を使用して AWS にアクセスする方法の詳細については、「[MFA 対応のサインイン](console_sign-in-mfa.md)」を参照してください。
+  IAM アイデンティティセンターを活用して、AWS アクセスポータル、IAM アイデンティティセンター統合アプリケーション、AWS CLI への安全な MFA アクセスを有効にすることができます。詳細については、「[IAM アイデンティティセンターで MFA を有効化する](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-getting-started.html)」を参照してください。

# AWS マネジメントコンソールでパスキーやセキュリティキーを割り当てる
<a name="id_credentials_mfa_enable_fido"></a>

パスキーは、AWS リソースを保護するために使用できる[多要素認証 (MFA) デバイス](id_credentials_mfa.md)の一種です。AWS は、同期パスキーと、セキュリティキーとも呼ばれるデバイスにバインドされたパスキーをサポートします。

同期パスキーを使用すると、IAM ユーザーは、多くのデバイスで (新しいデバイスであっても)、FIDO サインイン認証情報にアクセスできます。すべてのアカウントですべてのデバイスを再登録する必要はありません。同期パスキーには、Google、Apple、Microsoft などのファーストパーティ認証情報マネージャーと、1Password 、Dashlane、Bitwarden などのサードパーティー認証情報マネージャーが 2 番目の要素として含まれます。デバイス上の生体認証 (TouchID、FaceID など) を使用して、選択した認証情報マネージャーのロックを解除してパスキーを使用することもできます。

または、デバイスにバインドされたパスキーは、コンピュータの USB ポートに接続する FIDO セキュリティキーにバインドされます。プロンプトが表示されたらタップしてサインインプロセスを安全に完了します。すでに他のサービスで FIDO セキュリティキーを使用していて、[AWS でサポートされている構成](id_credentials_mfa_fido_supported_configurations.md) (Yubico の YubiKey 5 シリーズなど) がある場合は、そのキーも AWS で使用できます。それ以外の場合、AWS で MFA 用に WebAuthn を使用するには、FIDO セキュリティキーを購入する必要があります。さらに、FIDO セキュリティキーは、同じデバイスで複数の IAM ユーザーまたはルートユーザーをサポートできるため、アカウントセキュリティのユーティリティが強化されます。両方のデバイスタイプの仕様と購入情報については、「[多要素認証](https://aws.amazon.com/iam/details/mfa/)」を参照してください。

AWS アカウントのルートユーザー および IAM ユーザーに対し、[[現在サポートされている MFA タイプ]](https://aws.amazon.com/iam/features/mfa/)の任意の組み合わせで、最大 **8** 台の MFA デバイスを登録できます。MFA デバイスが複数ある場合でも、そのユーザとして AWS マネジメントコンソール にログインしたり、AWS CLI を使用してセッションを作成したりするのに必要なのは、1 台の MFA デバイスだけです。複数の MFA デバイスを登録することをお勧めします。例えば、組み込みの認証アプリを登録し、物理的に安全な場所に保管するセキュリティキーも登録することができます。組み込みの認証アプリを使用できない場合は、登録済みのセキュリティキーを使用できます。認証アプリについては、認証アプリが搭載されたデバイスを紛失したり破損したりした場合に、アカウントにアクセスできなくなるのを防ぐため、それらのアプリのクラウドバックアップまたは同期機能を有効にすることもお勧めします。

**注記**  
人間のユーザーが AWS にアクセスする場合には、一時的な認証情報の使用を推奨します。ユーザーは、ID プロバイダーを使用して AWS にフェデレーションし、会社の認証情報と MFA 設定で認証できます。AWS へのアクセスとビジネスアプリケーションを管理する場合は、IAM Identity Center の使用をお勧めします。詳細については、「[IAM Identity Center ユーザーガイド](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。

**Topics**
+ [

## 必要なアクセス許可
](#enable-fido-mfa-for-iam-user-permissions-required)
+ [

## 自身の IAM ユーザーのパスキーまたはセキュリティキーを有効にする (コンソール)
](#enable-fido-mfa-for-own-iam-user)
+ [

## 別の IAM ユーザーのパスキーまたはセキュリティキーを有効にする (コンソール)
](#enable-fido-mfa-for-iam-user)
+ [

## パスキーまたはセキュリティキーを置き換える
](#replace-fido-mfa)
+ [

# パスキーとセキュリティキーを使用するためのサポートされる設定
](id_credentials_mfa_fido_supported_configurations.md)

## 必要なアクセス許可
<a name="enable-fido-mfa-for-iam-user-permissions-required"></a>

重要な MFA 関連のアクションを保護しながら、独自の IAM ユーザー用に FIDO パスキーを管理するには、次のポリシーのアクセス許可が必要です。

**注記**  
ARN は静的な値であり、認証機能を登録するためにどのプロトコルが使用されたかを示すものではありません。U2F は廃止されたため、新しい実装はすべて WebAuthn を使用しています。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## 自身の IAM ユーザーのパスキーまたはセキュリティキーを有効にする (コンソール)
<a name="enable-fido-mfa-for-own-iam-user"></a>

自身の IAM ユーザーのパスキーまたはセキュリティキーは、AWS CLI API や AWS API からではなく、AWS マネジメントコンソール からのみ有効にできます。セキュリティキーを有効にするには、そのデバイスに物理的にアクセスできる必要があります。

**自身の IAM ユーザーのパスキーまたはセキュリティキーを有効にするには (コンソール)**

1. AWS アカウント ID またはアカウントエイリアス、IAM ユーザー名、およびパスワードを使用して [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
**注記**  
利便性のため、AWS サインインページは、ブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。以前に別のユーザーとしてサインインしたことがある場合は、ページの下部にある**[別のアカウントにサインイン]**を選択し、メインのサインインページに戻ります。そこから、AWS アカウント ID またはアカウントエイリアスを入力して、アカウントの IAM ユーザーサインインページにリダイレクトされるようにすることができます。

   AWS アカウント アカウント ID の取得については、管理者にお問い合わせください。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[AWS マネジメントコンソール のセキュリティ認証情報へのリンク\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. 選択した IAM ユーザーのページで、**[セキュリティ認証情報]** タブを選択します。

1. **[Multi-factor authentication (MFA)** (多要素認証 (MFA)) で、**[Assign MFA device]** (MFA デバイスの割り当て) を選択します。

1. **[MFA デバイス名]** ページで、**[デバイス名]** を入力し、**[パスキーまたはセキュリティキー]** を選択し、**[次へ]** を選択します。

1. **[デバイスの設定]** で、パスキーを設定します。顔や指紋などの生体認証データを使用、デバイス PIN を使用、またはコンピュータの USB ポートに FIDO セキュリティキーを挿入してタップすることで、パスキーを作成します。

1. ブラウザの指示に従って、**[続行]** を選択します。

これで、AWS で使用するパスキーまたはセキュリティキーが登録されました。AWS マネジメントコンソールでの MFA 利用の詳細については、「[MFA 対応のサインイン](console_sign-in-mfa.md)」を参照してください。

## 別の IAM ユーザーのパスキーまたはセキュリティキーを有効にする (コンソール)
<a name="enable-fido-mfa-for-iam-user"></a>

別の IAM ユーザーのパスキーまたはセキュリティキーは、AWS CLI API や AWS API からではなく、AWS マネジメントコンソール からのみ有効にすることができます。

**別の IAM ユーザーのパスキーまたはセキュリティキーを有効にするには (コンソール)**

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. **[ユーザー]** で、MFA を有効化するユーザーの名前を選択します。

1. 選択した IAM ユーザーのページで、**[セキュリティ認証情報]** タブを選択します。

1. **[Multi-factor authentication (MFA)** (多要素認証 (MFA)) で、**[Assign MFA device]** (MFA デバイスの割り当て) を選択します。

1. **[MFA デバイス名]** ページで、**[デバイス名]** を入力し、**[パスキーまたはセキュリティキー]** を選択し、**[次へ]** を選択します。

1. **[デバイスの設定]** で、パスキーを設定します。顔や指紋などの生体認証データを使用、デバイス PIN を使用、またはコンピュータの USB ポートに FIDO セキュリティキーを挿入してタップすることで、パスキーを作成します。

1. ブラウザの指示に従って、**[続行]** を選択します。

これで、別の IAM ユーザーが AWS で使用するパスキーまたはセキュリティキーが登録されました。AWS マネジメントコンソールでの MFA 利用の詳細については、「[MFA 対応のサインイン](console_sign-in-mfa.md)」を参照してください。

## パスキーまたはセキュリティキーを置き換える
<a name="replace-fido-mfa"></a>

[現在サポートされている MFA タイプ](https://aws.amazon.com/iam/features/mfa/)の任意の組み合わせで、一度に最大 8 台の MFA デバイスを、AWS アカウントのルートユーザー および IAM ユーザーに割り当てることができます。ユーザーが FIDO の認証装置を紛失した場合や、何らかの理由で交換する必要がある場合、最初に古い FIDO 認証装置を無効化する必要があります。その後、そのユーザー用に新しい MFA デバイスを追加できます。
+ IAM ユーザーに関連付けられているデバイスを非アクティブ化するには、「[MFA デバイスを無効にする](id_credentials_mfa_disable.md)」を参照してください。
+ IAM ユーザー用に新しい FIDO セキュリティキーを追加するには、「[自身の IAM ユーザーのパスキーまたはセキュリティキーを有効にする (コンソール)](#enable-fido-mfa-for-own-iam-user)」を参照してください。

新しいパスキーまたはセキュリティキーにアクセスできない場合は、新しい仮想 MFA デバイスまたはハードウェア TOTP トークンを有効化します。手順については、以下のいずれかを参照してください。
+ [AWS マネジメントコンソールで仮想 MFA デバイスを割り当てる](id_credentials_mfa_enable_virtual.md) 
+ [AWS マネジメントコンソールでハードウェア TOTP トークンを割り当てる](id_credentials_mfa_enable_physical.md) 

# パスキーとセキュリティキーを使用するためのサポートされる設定
<a name="id_credentials_mfa_fido_supported_configurations"></a>

現在サポートされている設定を使用して、IAM での 多要素認証 (MFA) メソッドとして、FIDO2 のデバイスにバインドされたパスキー (セキュリティキーとも呼ばれます) を使用できます。これには、IAM でサポートされている FIDO2 デバイスや、FIDO2 をサポートしているブラウザなどが含まれます。FIDO2 デバイスを登録する前に、お使いのブラウザとオペレーティングシステム (OS) のバージョンが最新であることを確認してください。機能の動作は、ブラウザ、認証システム、および OS クライアントによって異なる場合があります。あるブラウザでデバイスの登録に失敗した場合は、別のブラウザで登録を試みることができます。

FIDO2 はオープンな認証標準の FIDO U2F の拡張であり、公開鍵暗号に基づくセキュリティと同等の高レベルのセキュリティを提供します。FIDO2 は、W3C Web 認証仕様 (WebAuthn API) と、アプリケーション層プロトコルである FIDO アライアンスの Client-to-Authenticator Protocol (CTAP) で構成されています。CTAP は、ブラウザやオペレーティングシステムなどのクライアントまたはプラットフォームと外部認証システムとの間の通信を可能にします。AWS で FIDO 認定の認証機能を有効にすると、セキュリティキーにより、AWS でのみ使用するための新しいキーペアが作成されます。まず、認証情報を入力します。プロンプトが表示されたら、AWS によって発行された認証チャレンジに応答するセキュリティキーをタップします。FIDO2 標準の詳細については、「[FIDO2 プロジェクト](https://en.wikipedia.org/wiki/FIDO2_Project)」を参照してください。

## AWS でサポートされている FIDO2 デバイス
<a name="id_credentials_mfa_fido_supported_devices"></a>

IAM では、USB、Bluetooth、または NFC 経由でデバイスに接続する FIDO2 セキュリティデバイスをサポートしています。IAM は、TouchID や FaceID などのプラットフォーム認証機能もサポートしています。IAM は Windows Hello のローカルパスキー登録をサポートしていません。パスキーを作成して使用するには、Windows ユーザーは、モバイルデバイスやハードウェアセキュリティキーなどのデバイスのパスキーを使用して別のデバイス (ラップトップなど) にサインインする[クロスデバイス認証](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda)を使用する必要があります。

**注記**  
AWS は、FIDO2 デバイスを検証するためにコンピュータの物理的 USB ポートにアクセスする必要があります。セキュリティキーは、仮想マシン、リモート接続、またはブラウザのシークレットモードでは機能しません。

FIDO アライアンスでは、FIDO 仕様と互換性のあるすべての [FIDO2 製品](https://fidoalliance.org/certification/fido-certified-products/)のリストを公開しています。

## FIDO2 をサポートするブラウザ
<a name="id_credentials_mfa_fido_browsers"></a>

ウェブブラウザで実行される FIDO2 セキュリティデバイスの可用性は、ブラウザとオペレーティングシステムの組み合わせによって異なります。現在、以下のブラウザでセキュリティキーの使用がサポートされています。


****  

| ウェブブラウザ | macOS 10.15\$1 | Windows 10 | Linux | IOS 14.5 以降 | Android 7 以降 | 
| --- | --- | --- | --- | --- | --- | 
| Chrome | あり | はい | はい | あり | なし | 
| Safari | はい | なし | なし | あり | なし | 
| Edge | はい | あり | なし | あり | なし | 
| Firefox | あり | あり | なし | あり | なし | 

**注記**  
現在、FIDO2 をサポートしている Firefox のほとんどのバージョンでは、デフォルト状態で、そのサポートが有効になっていません。Firefox で FIDO2 のサポートを有効にする手順については、「[FIDO セキュリティキーをトラブルシューティングする](troubleshoot_mfa-fido.md)」を参照してください。  
macOS の Firefox は、パスキーのクロスデバイス認証ワークフローを完全にはサポートしていない場合があります。クロスデバイス認証に進む代わりに、セキュリティキーをタッチするように求めるプロンプトが表示される場合があります。macOS でパスキーを使用してサインインするには、Chrome や Safari などの別のブラウザを使用することをお勧めします。

YubiKey など、FIDO2 認定デバイスのブラウザのサポートについては、「[FIDO2 および U2F のオペレーティングシステムとウェブブラウザのサポート](https://support.yubico.com/hc/en-us/articles/360016615020-Operating-system-and-web-browser-support-for-FIDO2-and-U2F)」を参照してください。

### ブラウザプラグイン
<a name="id_credentials_mfa_fido_plugins"></a>

AWS は、FIDO2 をネイティブにサポートするブラウザのみをサポートしています。AWS は FIDO2 ブラウザのサポートを追加するためのプラグインの使用をサポートしていません。一部のブラウザプラグインは FIDO と互換性がなく、FIDO2 セキュリティキーで予期しない結果が生じることがあります。

ブラウザプラグインの無効化やその他のトラブルシューティングのヒントについては、「[FIDO セキュリティキーを有効にできない](troubleshoot_mfa-fido.md#troubleshoot_mfa-fido-cant-enable)」を参照してください。

## デバイス証明書
<a name="id_credentials_mfa_fido_certifications"></a>

FIPS 検証や FIDO 証明書レベルなど、デバイス関連の証明書を取得して割り当てるのは、セキュリティキーの登録時だけです。デバイス証明書は [FIDO Alliance Metadata Service (MDS)](https://fidoalliance.org/metadata/) から取得できます。セキュリティキーの証明書ステータスまたはレベルが変更されても、デバイスタグに自動的に反映されることはありません。デバイスの証明書情報を更新するには、デバイスを登録し直して、更新された証明書情報を取得します。

AWS では、FIDO MDS から取得したデバイス登録時の条件キーとして、FIPS-140-2、FIPS-140-3、および FIDO 証明書レベルの証明書タイプが用意されています。希望する証明書タイプとレベルに基づいて、IAM ポリシーに特定の認証者の登録を指定できます。詳細については、以下のポリシーを参照してください。

### デバイス証明書のポリシーの例
<a name="id_credentials_mfa_fido_certifications_policies"></a>

以下のユースケースは、FIPS 証明書を持つ MFA デバイスを登録できるようにするサンプルポリシーを示しています。

**Topics**
+ [

#### ユースケース 1: FIPS-140-2 L2 証明書を持つデバイスのみの登録を許可する
](#id_credentials_mfa_fido_certifications_policies_use_case_1)
+ [

#### ユースケース 2: FIPS-140-2 L2 および FIDO L1 証明書を持つデバイスの登録を許可する
](#id_credentials_mfa_fido_certifications_policies_use_case_2)
+ [

#### ユースケース 3: FIPS-140-2 L2 または FIPS-140-3 L2 証明書を持つデバイスの登録を許可する
](#id_credentials_mfa_fido_certifications_policies_use_case_3)
+ [

#### ユースケース 4: FIPS-140-2 L2 認証を持ち、仮想認証システムやハードウェア TOTP などのその他の種類の MFA をサポートするデバイスの登録を許可する
](#id_credentials_mfa_fido_certifications_policies_use_case_4)

#### ユースケース 1: FIPS-140-2 L2 証明書を持つデバイスのみの登録を許可する
<a name="id_credentials_mfa_fido_certifications_policies_use_case_1"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        }
    ]
}
```

------

#### ユースケース 2: FIPS-140-2 L2 および FIDO L1 証明書を持つデバイスの登録を許可する
<a name="id_credentials_mfa_fido_certifications_policies_use_case_2"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2",
                    "iam:FIDO-certification": "L1"
                }
            }
        }
    ]
}
```

------

#### ユースケース 3: FIPS-140-2 L2 または FIPS-140-3 L2 証明書を持つデバイスの登録を許可する
<a name="id_credentials_mfa_fido_certifications_policies_use_case_3"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-3-certification": "L2"
                }
            }
        }
    ]
}
```

------

#### ユースケース 4: FIPS-140-2 L2 認証を持ち、仮想認証システムやハードウェア TOTP などのその他の種類の MFA をサポートするデバイスの登録を許可する
<a name="id_credentials_mfa_fido_certifications_policies_use_case_4"></a>

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:RegisterSecurityKey": "Create"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:RegisterSecurityKey": "Activate",
          "iam:FIDO-FIPS-140-2-certification": "L2"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "Null": {
          "iam:RegisterSecurityKey": "true"
        }
      }
    }
  ]
}
```

------

## AWS CLI および AWS API
<a name="id_credentials_mfa_fido_cliapi"></a>

AWS は、パスキーとセキュリティキーの使用を AWS マネジメントコンソール でのみサポートしています。MFA に対するパスキーとセキュリティキーの使用は [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/) と [AWS API](https://aws.amazon.com/tools/) ではサポートされていません。また、[MFA 保護 API オペレーション](id_credentials_mfa_configure-api-require.md)へのアクセスでもサポートされていません。

## その他のリソース
<a name="id_credentials_mfa_fido_additional_resources"></a>
+ AWS でのパスキーとセキュリティキーの使用の詳細については、「[AWS マネジメントコンソールでパスキーやセキュリティキーを割り当てる](id_credentials_mfa_enable_fido.md)」を参照してください。
+ AWS でのパスキーとセキュリティキーのトラブルシューティングについては、「[FIDO セキュリティキーをトラブルシューティングする](troubleshoot_mfa-fido.md)」を参照してください。
+ FIDO2 サポートに関する一般的な業界情報については、「[FIDO2 プロジェクト](https://en.wikipedia.org/wiki/FIDO2_Project)」を参照してください。

# AWS マネジメントコンソールで仮想 MFA デバイスを割り当てる
<a name="id_credentials_mfa_enable_virtual"></a>

**重要**  
AWS では、AWS への MFA に可能な限りパスキーまたはセキュリティキーを使用することをお勧めします。詳細については、「[AWS マネジメントコンソールでパスキーやセキュリティキーを割り当てる](id_credentials_mfa_enable_fido.md)」を参照してください。

電話や他のデバイスを仮想多要素認証 (MFA) デバイスとして使用できます。これを行うには、[標準ベースの TOTP (時刻ベースのワンタイムパスワード) アルゴリズムである RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238) に準拠するモバイルアプリをインストールします。これらのアプリは、6 桁の認証コードを生成します。認証はセキュリティで保護されていないモバイルデバイスで実行することができ、コードはアクセス許可のない当事者と共有される可能性があるため、TOTP ベースの MFA は [FIDO2](https://en.wikipedia.org/wiki/FIDO_Alliance#FIDO2) セキュリティキーやパスキーなどのフィッシング耐性オプションと同等のセキュリティを提供しません。フィッシングなどの攻撃に対して最も強力な保護を実現するには、MFA にパスキーまたはセキュリティキーを使用することをお勧めします。

パスキーまたはセキュリティキーをまだ使用できない場合は、ハードウェア購入の承認またはハードウェアの到着を待つ間、暫定措置として仮想 MFA デバイスを使用することをお勧めします。

一般的な仮想 MFA アプリでは、複数の仮想デバイスの作成がサポートされているため、複数の AWS アカウント またはユーザーに対しても同じアプリを使用できます。[MFA タイプ](https://aws.amazon.com/iam/features/mfa/)を任意に組み合わせた最大 **8** 台の MFA デバイスを AWS アカウントのルートユーザーおよび IAM ユーザーと共に登録できます。AWS マネジメントコンソールにログインしたり、AWS CLI を使用してセッションを確立したりするには、MFA デバイスが 1 台あれば十分です。複数の MFA デバイスを登録することをお勧めします。また、認証アプリ搭載のデバイスを紛失または損傷した場合にアカウントにアクセスできなくなるのを防ぐため、クラウドバックアップや同期機能を有効にすることをお勧めします。

AWS では、6 桁の OTP を生成する仮想 MFA アプリが必要です。使用できる仮想 MFA アプリケーションのリストについては、「[多要素認証](https://aws.amazon.com/iam/features/mfa/?audit=2019q1)」を参照してください。

**Topics**
+ [

## 必要なアクセス許可
](#mfa_enable_virtual_permissions-required)
+ [

## IAM ユーザーの仮想 MFA デバイスの有効化 (コンソール)
](#enable-virt-mfa-for-iam-user)
+ [

## 仮想 MFA デバイスの交換
](#replace-virt-mfa)

## 必要なアクセス許可
<a name="mfa_enable_virtual_permissions-required"></a>

IAM ユーザーの仮想 MFA デバイスを更新するには、次のポリシーのアクセス許可が必要です: [AWS: MFA で認証された IAM ユーザーが [セキュリティ認証情報] ページで自分の MFA デバイスを管理できるようにします](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md)。

## IAM ユーザーの仮想 MFA デバイスの有効化 (コンソール)
<a name="enable-virt-mfa-for-iam-user"></a>

AWS マネジメントコンソール で IAM を使用して、アカウントの IAM ユーザーの仮想 MFA デバイスを有効化および管理することができます。IAM リソース (仮想 MFA デバイスを含む) にタグをアタッチして、タグへのアクセスを特定、整理、制御することができます。仮想 MFA デバイスにタグを付けることができるのは、AWS CLI または AWS API を使用する場合のみです。AWS CLI または AWS API を使用して、MFA デバイスを有効化および管理するには、「[AWS CLI または AWS API で MFA デバイスを割り当てる](id_credentials_mfa_enable_cliapi.md)」を参照してください。IAM リソースのタグ付けの詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください 

**注記**  
MFA を設定するには、ユーザーの仮想 MFA デバイスをホストするハードウェアに物理的にアクセスできる必要があります。例えば、スマートフォンで実行される仮想 MFA デバイスを使用するユーザー用に MFA を設定するとします。その場合、ウィザードを完了するには、そのスマートフォンを利用できる必要があります。このため、ユーザーが自分の仮想 MFA デバイスを設定して管理できるようにすることをお勧めします。この場合、必要な IAM アクションを実行する権限をユーザーに付与する必要があります。このアクセス許可を付与する IAM ポリシーの詳細および例については、「[IAM チュートリアル: ユーザーに自分の認証情報および MFA 設定を許可する](tutorial_users-self-manage-mfa-and-creds.md)」およびポリシーの例「[AWS: MFA で認証された IAM ユーザーが [セキュリティ認証情報] ページで自分の MFA デバイスを管理できるようにします](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md)」を参照してください。

**IAM ユーザーの仮想 MFA デバイスを有効にするには (コンソール)**

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. **[Users]** (ユーザー) のリストで、IAM ユーザー名を選択します。

1. [**Security Credentials**] タブを選択します。**[Multi-factor authentication (MFA)** (多要素認証 (MFA)) で、**[Assign MFA device]** (MFA デバイスの割り当て) を選択します。

1. ウィザードで **[デバイス名]** を入力し、**[認証アプリ]**、**[次へ]** の順に選択します。

   IAM が QR コードを含む仮想 MFA デバイスの設定情報を生成して表示します。図は、QR コードに対応していないデバイスでの手動入力に利用できる「シークレット設定キー」を示しています。

1. 仮想 MFA アプリを開きます。仮想 MFA デバイスをホストするために使用できるアプリケーションのリストについては、「[多要素認証](https://aws.amazon.com/iam/details/mfa/)」を参照してください。

   仮想 MFA アプリが複数の仮想 MFA デバイスまたはアカウントをサポートしている場合は、新しい仮想 MFA デバイスまたはアカウントを作成するオプションを選択します。

1. MFA アプリが QR コードをサポートしているかどうかを確認してから、次のいずれかを実行します。
   + ウィザードから **[Show QR code]** (QR コードの表示) を選択し、アプリを使用して QR コードをスキャンします。そのための選択肢には、デバイスのカメラを使用してコードをスキャンするカメラアイコンや**スキャンコード**などがあります。
   + 同じウィザードで **[Show secret key]** (シークレットキーを表示) を選択した後、MFA アプリにシークレットキーを入力します。

   これで仮想 MFA デバイスはワンタイムパスワードの生成を開始します。

1. **[デバイスの設定]** ページで、**[MFA コード 1]** ボックスに、現在仮想 MFA デバイスに表示されているワンタイムパスワードを入力します。デバイスが新しいワンタイムパススワードを生成するまで待ちます (最長 30 秒)。生成されたら [**MFA code 2 (MFA コード 2)**] ボックスに 2 つ目のワンタイムパススワードを入力します。**[Add MFA]** (MFA を追加) を選択します。
**重要**  
コードを生成したら、即時にリクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーとは正常に関連付けられますが、その MFA デバイスは同期されません。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。その場合は、[デバイスの再同期](id_credentials_mfa_sync.md)ができます。

これで仮想 MFA デバイスを AWS で使用できます。AWS マネジメントコンソールでの MFA 利用の詳細については、「[MFA 対応のサインイン](console_sign-in-mfa.md)」を参照してください。

**注記**  
AWS アカウント で割り当てられていない仮想 MFA デバイスは、AWS マネジメントコンソール 経由で、またはサインインプロセス中に新しい仮想 MFA デバイスを追加すると削除されます。未割り当ての仮想 MFA デバイスとは、お客様のアカウントにあるデバイスですが、アカウントのルートユーザーまたは IAM ユーザーがサインインプロセスで使用されません。これらは削除されるため、新しい仮想 MFA デバイスをアカウントに追加できます。また、デバイス名を再利用することもできます。  
アカウント内の未割り当ての仮想 MFA デバイスを表示するには、[list-virtual-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-virtual-mfa-devices.html) AWS CLI コマンドまたは [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) コールを使用できます。
仮想 MFA デバイスを非アクティブ化するには、[deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html) AWS CLI コマンドまたは [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) コールを使用できます。このデバイスは未割り当てになります。
未割り当ての仮想 MFA デバイスを AWS アカウント ルートユーザーまたは IAM ユーザーにアタッチするには、[enable-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-mfa-device.html) AWS CLI コマンドまたは [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) コールとともに、デバイスが生成した認証コードが必要となります。

## 仮想 MFA デバイスの交換
<a name="replace-virt-mfa"></a>

AWS アカウントのルートユーザーと IAM ユーザーは、MFA タイプを任意に組み合わせた最大 **8** 台の MFA デバイスを登録できます。ユーザーがデバイスを紛失したか、何らかの理由で交換する必要がある場合は、古いデバイスを非アクティブ化します。その後、新しいデバイスをユーザーに追加できます。
+ 別の IAM ユーザーに関連付けられているデバイスを非アクティブ化するには、「[MFA デバイスを無効にする](id_credentials_mfa_disable.md)」を参照してください。
+ 別の IAM ユーザーの交換用の仮想 MFA デバイスを追加するには、上記の「[IAM ユーザーの仮想 MFA デバイスの有効化 (コンソール)](#enable-virt-mfa-for-iam-user)」の手順に従います。
+ AWS アカウントのルートユーザー ユーザーの交換用の仮想 MFA デバイスを追加するには、[ルートユーザーの仮想 MFA デバイスを有効にする (コンソール)](enable-virt-mfa-for-root.md) の手順に従います。

# AWS マネジメントコンソールでハードウェア TOTP トークンを割り当てる
<a name="id_credentials_mfa_enable_physical"></a>

**重要**  
AWS では、AWS への MFA に可能な限りパスキーまたはセキュリティキーを使用することをお勧めします。詳細については、「[AWS マネジメントコンソールでパスキーやセキュリティキーを割り当てる](id_credentials_mfa_enable_fido.md)」を参照してください。

ハードウェア TOTP トークンは、タイムベースドワンタイムパスワード (TOTP) アルゴリズムに基づいて、6 桁の数値コードを生成します。ユーザーは、サインインプロセス中に求められたら、デバイスから有効なコードを入力する必要があります。ユーザーに割り当てられる各 MFA デバイスは一意であり、他のユーザーのデバイス向けのコードでは認証されません。MFA デバイスをアカウント間またはユーザー間で共有することはできません。

ハードウェア TOTP トークンと [FIDO セキュリティキー](id_credentials_mfa_enable_fido.md)は、いずれもお客様が購入する物理デバイスです。ハードウェア MFA デバイスは、ユーザーが AWS にサインインすると認証用の TOTP コードを生成します。バッテリーに依存しているため、時間の経過とともにバッテリーの交換と AWS との再同期が必要になる場合があります。パブリックキー暗号化を利用した FIDO セキュリティキーは、バッテリーを必要とせず、シームレスな認証プロセスを提供します。フィッシング耐性を高めるためには、FIDO セキュリティキーを使用することをお勧めします。FIDO セキュリティキーは、TOTP デバイスの代わりに使用できる、よりセキュアな手段です。さらに、FIDO セキュリティキーは、同じデバイスで複数の IAM ユーザーまたはルートユーザーをサポートできるため、アカウントセキュリティのユーティリティが強化されます。両方のデバイスタイプの仕様と購入情報については、「[多要素認証](https://aws.amazon.com/iam/details/mfa/)」を参照してください。



IAM ユーザーのハードウェア TOTP デバイスは、AWS マネジメントコンソール、コマンドライン、または IAM API を使用して有効にすることができます。AWS アカウントのルートユーザー の MFA デバイス設定を有効にするには、「[のルートユーザー (コンソール) 用にハードウェア TOTP トークンを有効にします](enable-hw-mfa-for-root.md)」を参照してください。

AWS アカウントのルートユーザー および IAM ユーザーに対し、「[現在サポートされている MFA タイプ](https://aws.amazon.com/iam/features/mfa/)」の任意の組み合わせで、最大 **8** 台の MFA デバイスを登録できます。MFA デバイスが複数ある場合でも、そのユーザとして AWS マネジメントコンソール にログインしたり、AWS CLI を使用してセッションを作成したりするのに必要なのは、1 台の MFA デバイスだけです。

**重要**  
MFA デバイスを紛失したりアクセスできなくなったりした場合に、ユーザーが引き続きアカウントにアクセスできるようにするため、複数の MFA デバイスを利用可能にしておくことをお勧めします。

**注記**  
コマンドラインから MFA デバイスを有効化する場合には、[https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html) を使用します。IAM API で MFA デバイスを有効化する場合には、[https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) オペレーションを使用します。

**Topics**
+ [

## 必要なアクセス許可
](#enable-hw-mfa-for-iam-user-permissions-required)
+ [

## 自身の IAM ユーザーでハードウェア TOTP トークンを有効にする (コンソール)
](#enable-hw-mfa-for-own-iam-user)
+ [

## 別の IAM ユーザーのハードウェア TOTP トークンを有効にする (コンソール)
](#enable-hw-mfa-for-iam-user)
+ [

## 物理的な MFA デバイスの交換
](#replace-phys-mfa)

## 必要なアクセス許可
<a name="enable-hw-mfa-for-iam-user-permissions-required"></a>

重要な MFA 関連のアクションを保護しながら、IAM ユーザー用にハードウェア TOTP トークンを管理するには、以下のポリシーによるアクセス許可が必要です。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## 自身の IAM ユーザーでハードウェア TOTP トークンを有効にする (コンソール)
<a name="enable-hw-mfa-for-own-iam-user"></a>

 自分のハードウェア TOTP トークンは、AWS マネジメントコンソール から有効化できます。

**注記**  
ハードウェア TOTP トークンを有効にする前に、そのデバイスに対し物理的なアクセス権限を持つ必要があります。

**自身の IAM ユーザーのハードウェア TOTP トークンを有効にするには (コンソール)**

1. AWS アカウント ID またはアカウントエイリアス、IAM ユーザー名、およびパスワードを使用して [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
**注記**  
利便性のため、AWS サインインページは、ブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。以前に別のユーザーとしてサインインしたことがある場合は、ページの下部にある**[別のアカウントにサインイン]**を選択し、メインのサインインページに戻ります。そこから、AWS アカウント ID またはアカウントエイリアスを入力して、アカウントの IAM ユーザーサインインページにリダイレクトされるようにすることができます。

   AWS アカウント アカウント ID の取得については、管理者にお問い合わせください。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[AWS マネジメントコンソール のセキュリティ認証情報へのリンク\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **[AWS IAM 認証情報]** タブの **[多要素認証 (MFA)]** セクションで、**[MFA デバイスの割り当て]** を選択します。

1. ウィザード内で **[Device name]** (デバイス名) に入力した後、**[Hardware TOTP token]** (ハードウェア TOTP トークン)、**[Next]** (次へ) の順に選択します。

1. 対象デバイスのシリアルナンバーを入力します。シリアルナンバーは、通常、デバイスの背面にあります。

1. MFA デバイスに表示されている 6 桁の数字を [**MFA code 1 (MFA コード 1)**] に入力します。デバイス前面のボタンを押して数字を表示する場合があります。  
![\[IAM ダッシュボード、MFA デバイス\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/MFADevice.png)

1. デバイスがコードを更新するまで 30 秒ほど待ち、更新後に表示された 6 桁の数字を [**MFA code 2 (MFA コード 2)**] に入力します。デバイス前面のボタンを再度押して新しい数字を表示する場合があります。

1. **[Add MFA]** (MFA を追加) を選択します。
**重要**  
認証コードを生成した後すぐに、リクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーとは正常に関連付けられますが、その MFA デバイスは同期されなくなります。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。その場合は、[デバイスの再同期](id_credentials_mfa_sync.md)ができます。

デバイスを AWS で使用する準備が整いました。AWS マネジメントコンソールでの MFA 利用の詳細については、「[MFA 対応のサインイン](console_sign-in-mfa.md)」を参照してください。

## 別の IAM ユーザーのハードウェア TOTP トークンを有効にする (コンソール)
<a name="enable-hw-mfa-for-iam-user"></a>

 AWS マネジメントコンソール から別の IAM ユーザーのハードウェア TOTP トークンを有効にできます。

**別の IAM ユーザーのハードウェア TOTP トークンを有効にするには (コンソール)**

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. MFA を有効化するユーザーの名前を選択します。

1. [**Security Credentials**] タブを選択します。**[Multi-factor authentication (MFA)** (多要素認証 (MFA)) で、**[Assign MFA device]** (MFA デバイスの割り当て) を選択します。

1. ウィザード内で **[Device name]** (デバイス名) に入力した後、**[Hardware TOTP token]** (ハードウェア TOTP トークン)、**[Next]** (次へ) の順に選択します。

1. 対象デバイスのシリアルナンバーを入力します。シリアルナンバーは、通常、デバイスの背面にあります。

1. MFA デバイスに表示されている 6 桁の数字を [**MFA code 1 (MFA コード 1)**] に入力します。デバイス前面のボタンを押して数字を表示する場合があります。  
![\[IAM ダッシュボード、MFA デバイス\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/MFADevice.png)

1. デバイスがコードを更新するまで 30 秒ほど待ち、更新後に表示された 6 桁の数字を [**MFA code 2 (MFA コード 2)**] に入力します。デバイス前面のボタンを再度押して新しい数字を表示する場合があります。

1. **[Add MFA]** (MFA を追加) を選択します。
**重要**  
認証コードを生成した後すぐに、リクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーとは正常に関連付けられますが、その MFA デバイスは同期されなくなります。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。その場合は、[デバイスの再同期](id_credentials_mfa_sync.md)ができます。

デバイスを AWS で使用する準備が整いました。AWS マネジメントコンソールでの MFA 利用の詳細については、「[MFA 対応のサインイン](console_sign-in-mfa.md)」を参照してください。

## 物理的な MFA デバイスの交換
<a name="replace-phys-mfa"></a>

「[現在サポートされている MFA タイプ](https://aws.amazon.com/iam/features/mfa/)」の任意の組み合わせで、一度に最大 8 台の MFA デバイスを、AWS アカウントのルートユーザー および IAM ユーザーに割り当てることができます。ユーザーがデバイスを紛失したか、何らかの理由で交換する必要がある場合、最初に古いデバイスを非アクティブ化する必要があります。その後、新しいデバイスをユーザーに追加できます。
+ 現在ユーザーに関連付けられているデバイスを非アクティブ化するには、「[MFA デバイスを無効にする](id_credentials_mfa_disable.md)」を参照してください。
+ IAM ユーザーに対し、交換用ハードウェア TOTP トークンを追加するには、このトピックの前半にある手順「[別の IAM ユーザーのハードウェア TOTP トークンを有効にする (コンソール)](#enable-hw-mfa-for-iam-user)」の各ステップに従います。
+ AWS アカウントのルートユーザー に対し、交換用ハードウェア TOTP トークンを追加するには、このトピックの上記手順「[のルートユーザー (コンソール) 用にハードウェア TOTP トークンを有効にします](enable-hw-mfa-for-root.md)」の各ステップに従います。

# AWS CLI または AWS API で MFA デバイスを割り当てる
<a name="id_credentials_mfa_enable_cliapi"></a>

IAM ユーザーの仮想 MFA デバイスを有効にするには、AWS CLI コマンドまたは AWS API オペレーションを使用します。AWS CLI、AWS API、Tools for Windows PowerShell、またはその他のコマンドラインツールを使用して AWS アカウントのルートユーザー の MFA デバイスを有効にすることはできません。ただし、AWS マネジメントコンソール を使用して、ルートユーザーの MFA デバイスを有効化することができます。

AWS マネジメントコンソール から MFA デバイスを有効にすると、コンソールがお客様に代わって複数のステップを実行します。代わりに AWS CLI、Tools for Windows PowerShell、または AWS API を使用して仮想デバイスを作成する場合は、それらのステップを適切な順序で自分で実行する必要があります。たとえば、仮想 MFA デバイスを作成するには、IAM オブジェクトを作成し、文字列または QR コードグラフィックとしてコードを抽出する必要があります。次に、デバイスを IAM ユーザーと同期させて関連付ける必要があります。詳細については、[New-IAMVirtualMFADevice](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=New-IAMVirtualMFADevice.html&tocid=New-IAMVirtualMFADevice) の **[Examples]** (例) セクションを参照してください。物理デバイスの場合は作成ステップを飛ばし、デバイスを同期してユーザーに関連付ける手順へ直接進んでください。

IAM リソース (仮想 MFA デバイスを含む) にタグをアタッチして、タグへのアクセスを特定、整理、制御することができます。仮想 MFA デバイスにタグを付けることができるのは、AWS CLI または AWS API を使用する場合のみです。

SDK または CLI を使用する IAM ユーザーは、[https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) を呼び出して追加の MFA デバイスを有効にするか、[https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) を呼び出して既存の MFA デバイスを無効にできます。これを正常に行うには、まず [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) を呼び出し、既存の MFA デバイスで MFA コードを送信する必要があります。この呼び出しで、一時的なセキュリティ認証情報を返されます。この認証情報を使用して、MFA 認証を必要とする API オペレーションに署名できます。リクエストとレスポンスの例については、「[`GetSessionToken`—信頼されていない環境にあるユーザー向けの一時的認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_getsessiontoken)」を参照してください。

**IAM で仮想デバイスのエンティティを作成し、仮想 MFA デバイスを表すには**  
これらのコマンドは、次のコマンドの多くでシリアルナンバーの代わりに使用されるデバイスの ARN を提供します。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateVirtualMFADevice.html) 

**AWS を使用するように MFA デバイスを有効にするには**  
これらのコマンドでは、デバイスを AWS と同期させて、ユーザーと関連付けます。デバイスが仮想デバイスの場合、仮想デバイスの ARN をシリアルナンバーとして使用します。

**重要**  
認証コードを生成した後すぐに、リクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーとは正常に関連付けられますが、その MFA デバイスは同期されなくなります。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。この場合は、次のコマンドを使用してデバイスを再同期できます。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) 

**デバイスを無効にするには**  
以下のコマンドでは、デバイスとユーザーの関連付けを解除し、デバイスを無効化します。デバイスが仮想デバイスの場合、仮想デバイスの ARN をシリアルナンバーとして使用します。別途、仮想デバイスのエンティティも削除する必要があります。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)

**仮想 MFA デバイスエンティティを一覧表示するには**  
以下のコマンドでは、仮想 MFA デバイスのエンティティを一覧表示します。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) 

**仮想 MFA デバイスにタグを付けるには**  
仮想 MFA デバイスにタグを付けるには、次のコマンドを使用します。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html) 

**仮想 MFA デバイスのタグを一覧表示するには**  
仮想 MFA デバイスにアタッチされたタグを一覧表示するには、次のコマンドを使用します。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html) 

**仮想 MFA デバイスのタグを解除するには**  
仮想 MFA デバイスにアタッチされたタグを削除するには、次のコマンドを使用します。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html) 

**MFA デバイスを再同期するには**  
AWS が受け入れられないコードをデバイスが生成している場合は、以下のコマンドを使用します。デバイスが仮想デバイスの場合、仮想デバイスの ARN をシリアルナンバーとして使用します。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html) 

**IAM で仮想 MFA デバイスのエンティティを削除するには**  
デバイスのユーザーへの関連付けを解除した後、そのデバイスのエンティティを削除できます。
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html) 
+ AWS API:[https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html) 

**紛失または故障中の仮想 MFA デバイスを復旧するには**  
仮想化 MFA アプリをホストするユーザーのデバイスが紛失、交換、または機能しなくなることがあります。この場合、ユーザーが自分で復旧することはできません。ユーザーは、デバイスを無効にするために管理者に連絡する必要があります。詳細については、「[IAM 内で MFA で保護された ID を復元する](id_credentials_mfa_lost-or-broken.md)」を参照してください。

# MFA ステータスをチェックする
<a name="id_credentials_mfa_checking-status"></a>

IAM コンソールで、AWS アカウントのルートユーザー または IAM ユーザーで有効な MFA デバイスが有効化されているかどうかを確認します。

**ルートユーザーの MFA ステータスを確認するには**

1. ルートユーザー認証情報を使用して AWS マネジメントコンソール にサインインし、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[セキュリティ認証情報]** を選択します。

1. **[Multi-factor Authentication (MFA)]** で、MFA が有効か無効かを確認します。MFA がアクティブ化されていない場合は、アラート記号 (![\[Alert icon\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/console-alert-icon.console.png)) が表示されます。

アカウントに対して MFA を有効化する場合は、以下のいずれかを参照してください。
+ [ルートユーザーの仮想 MFA デバイスを有効にする (コンソール)](enable-virt-mfa-for-root.md)
+ [ルートユーザーのパスキーまたはセキュリティキーを有効にする (コンソール）](enable-fido-mfa-for-root.md)
+ [のルートユーザー (コンソール) 用にハードウェア TOTP トークンを有効にします](enable-hw-mfa-for-root.md)

**IAM ユーザーの MFA ステータスを確認するには**

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで **[ユーザー]** を選択します。

1. 必要に応じて、以下の手順を実行して、[**MFA**] 列を USERS テーブルに追加します。

   1. 右端のテーブルの上で、設定アイコン (![\[Settings icon\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/console-settings-icon.console.png)) を選択します。

   1. [**Manage Columns (列の管理)**] で、[**MFA**] を選択します。

   1. (オプション) ユーザーテーブルに表示しない列見出しのチェックボックスをオフにします。

   1. [**Close (閉じる)**] を選択して、ユーザーのリストに戻ります。

1. [**MFA**] 列に、有効になっている MFA デバイスが表示されます。そのユーザーにアクティブな MFA デバイスがない場合は、コンソールに **[None]** (なし) と表示されます。ユーザーの MFA デバイスが有効になっている場合は、**MFA** 列に、そのデバイスのタイプを示す値 (**[Virtual]** (仮想)、**[Security Key]** (セキュリティキー)、**[Hardware]** (ハードウェア)、または **SMS**) が表示されます。
**注記**  
AWS は、間もなく SMS 多要素認証 (MFA) のサポートを終了します。SMS テキストメッセージベース MFA を使用する IAM ユーザーのお客様は、以下の別のいずれかの方法 ([仮想 (ソフトウェアベースの) MFA デバイス](id_credentials_mfa_enable_virtual.md)、[FIDO セキュリティキー](id_credentials_mfa_enable_fido.md)、または[ハードウェア MFA デバイス](id_credentials_mfa_enable_physical.md)) に切り替えることをお勧めします。割り当てられた SMS MFA デバイスを使用して、アカウントのユーザーを識別することができます。これを行うには、IAM コンソールに移動して、ナビゲーションペインの [**ユーザー**] を選択し、テーブルの [**MFA**] 列の [**SMS**] を使用してユーザーを探します。

1. ユーザーの MFA デバイスに関する追加情報を表示するには、確認する MFA ステータスのユーザー名を選択します。次に、[**認証情報**] タブを選択します。

1. そのユーザーにアクティブな MFA デバイスがない場合は、コンソールに **[MFA デバイスなし] と表示されます。**[多要素認証 (MFA)]** セクションで [MFA デバイスを割り当てて AWS 環境のセキュリティを強化します]**。ユーザーの MFA デバイスが有効化されている場合、**[Multi-factor authentication (MFA)]** (多要素認証 (MFA)) セクションには、対象のデバイスに関する詳細が表示されます。
   + デバイス名
   + デバイスのタイプ
   + デバイスのID (物理デバイスのシリアル番号、または AWS での仮想デバイスの ARN)
   + デバイスの作成日時

デバイスを削除または再同期するには、そのデバイスの横にあるラジオボタンをオンにし、**[Remove]** (削除) または **[Resync]** (再同期) を選択します。

MFA の有効化の詳細については、以下を参照してください。
+ [AWS マネジメントコンソールで仮想 MFA デバイスを割り当てる](id_credentials_mfa_enable_virtual.md)
+ [AWS マネジメントコンソールでパスキーやセキュリティキーを割り当てる](id_credentials_mfa_enable_fido.md)
+ [AWS マネジメントコンソールでハードウェア TOTP トークンを割り当てる](id_credentials_mfa_enable_physical.md)

# 仮想 MFA デバイスとハードウェア MFA デバイスを再同期する
<a name="id_credentials_mfa_sync"></a>

AWS コンソールを使用して、仮想およびハードウェア Multi-Factor Authentication (MFA) デバイスを再同期できます。ユーザーのデバイスが使用しようとしたときに同期されていない場合、ユーザーのサインインは失敗し、IAM はユーザーにデバイスの再同期を促します。

**注記**  
FIDO セキュリティキーは同期しなくなることはありません。FIDO セキュリティキーが紛失または破損した場合は、それを非アクティブにすることができます。MFA デバイスタイプを無効にする方法については、「[別の IAM ユーザーの MFA デバイスを無効化するには (コンソール)](id_credentials_mfa_disable.md#deactivate-mfa-for-user)」を参照してください。

AWS 管理者は、IAM ユーザーの仮想およびハードウェア MFA デバイスがシステムと同期されていない場合、それらのデバイスを再同期できます。

AWS アカウントのルートユーザー MFA デバイスが動作していない場合は、IAM コンソールを使用してデバイスを再同期することができます。デバイスを正常に再同期できない場合は、デバイスの関連付けを解除して再関連付けする必要がある場合があります。方法の詳細については、「[MFA デバイスを無効にする](id_credentials_mfa_disable.md)」および「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。

**Topics**
+ [

## 必要なアクセス許可
](#id_credentials_mfa_sync_console-permissions-required)
+ [

## 仮想およびハードウェア MFA デバイスの再同期 (IAM コンソール)
](#id_credentials_mfa_sync_console)
+ [

## 仮想およびハードウェア MFA デバイスの再同期 (AWS CLI)
](#id_credentials_mfa_sync_cli)
+ [

## 仮想およびハードウェア MFA デバイスの再同期 (AWS API)
](#id_credentials_mfa_sync_api)

## 必要なアクセス許可
<a name="id_credentials_mfa_sync_console-permissions-required"></a>

独自の IAM ユーザーの仮想またはハードウェア MFA デバイスを再同期するには、次のポリシーのアクセス許可が必要です。このポリシーでは、デバイスを作成することや非アクティブ化することはできません。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowListActions",
            "Effect": "Allow",
            "Action": [
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowUserToViewAndManageTheirOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "BlockAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## 仮想およびハードウェア MFA デバイスの再同期 (IAM コンソール)
<a name="id_credentials_mfa_sync_console"></a>

IAM コンソールを使用して、仮想およびハードウェア MFA デバイスを再同期できます。

**独自の IAM ユーザーの仮想またはハードウェア MFA デバイスを再同期するには (コンソール)**

1. AWS アカウント ID またはアカウントエイリアス、IAM ユーザー名、およびパスワードを使用して [IAM コンソール](https://console.aws.amazon.com/iam)にサインインします。
**注記**  
利便性のため、AWS サインインページは、ブラウザ cookie を使用して IAM ユーザー名とアカウント情報を記憶します。以前に別のユーザーとしてサインインしたことがある場合は、ページの下部にある**[別のアカウントにサインイン]**を選択し、メインのサインインページに戻ります。そこから、AWS アカウント ID またはアカウントエイリアスを入力して、アカウントの IAM ユーザーサインインページにリダイレクトされるようにすることができます。

   AWS アカウント アカウント ID の取得については、管理者にお問い合わせください。

1. 右上のナビゲーションバーで自分のユーザー名を選択し、続いて **[Security credentials]** (セキュリティ認証情報) を選択します。  
![\[AWS マネジメントコンソールのセキュリティ認証情報へのリンク\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **[AWS IAM 認証情報]** タブの **[多要素認証 (MFA)]** セクションで、MFA デバイスの横にあるラジオボタンを選択し、**[再同期]** を選択します。

1. デバイスで連続して生成された次の 2 つのコードを [**MFA コード 1**] および [**MFA コード 2**] に入力します。次に、**[Resync]** (再同期) を選択します。
**重要**  
コードを生成したら、即時にリクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、リクエスト処理中に見えますが、デバイスは同期されていません。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。

**別の IAM ユーザーの仮想またはハードウェア MFA デバイスを再同期するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで [**ユーザー**] を選択してから、MFA デバイスを再同期する必要があるユーザーの名前を選択します。

1. ［**Security credentials**］タブを選択します。**[多要素認証 (MFA)]** セクションで、MFA デバイスの横にあるラジオボタンを選択し、**[再同期]** を選択します。

1. デバイスで連続して生成された次の 2 つのコードを [**MFA コード 1**] および [**MFA コード 2**] に入力します。次に、**[Resync]** (再同期) を選択します。
**重要**  
コードを生成したら、即時にリクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、リクエスト処理中に見えますが、デバイスは同期されていません。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。

**サインインする前に ルートユーザーMFA を再同期するには (コンソール)**

1. [**Amazon Web Services Sign In With Authentication Device (認証デバイスによる Amazon Web Services へのサインイン)**] ページで、[**認証デバイスに問題がありますか?] を選択します。[Click here]** (ここをクリックしてください)｡
**注記**  
他のテキスト (例: **MFA を使用してサインイン** や **認証デバイスのトラブルシューティング**) が表示される場合があります。ただし、提供されている機能は同じです。

1. [**Re-Sync With Our Servers (サーバーとの再同期)**] セクションで、デバイスで連続して生成された次の 2 つのコードを [**MFA code 1 (MFA コード 1)**] および [**MFA code 2 (MFA コード 2)**] に入力します。次に、[**Re-sync authentication device (認証デバイスの再同期)**] を選択します。

1. 必要に応じて、パスワードをもう一度入力し、[**サインイン**] を選択します。次に、MFA デバイスを使用してサインインを完了します。

**サインインした後に ルートユーザーMFA デバイスを再同期するには (コンソール)**

1. **[Root user]** (ルートユーザー) を選択して AWS アカウント の E メールアドレスを入力し、アカウント所有者として [IAM コンソール](https://console.aws.amazon.com/iam/)にサインインします。次のページでパスワードを入力します。
**注記**  
ルートユーザーでは、「**IAM ユーザーとしてサインイン**」ページにサインインすることはできません。**[IAM ユーザーのサインイン]** ページが表示された場合、ページ下部付近で **[ルートユーザーの電子メールを使用してサインインする]** を選択します。ルートユーザーを使用してサインインする方法については、AWS サインイン ユーザーガイドの「[ルートユーザーとして AWS マネジメントコンソール へサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-          root-user-sign-in-tutorial.html)」を参照してください。

1. ナビゲーションバーの右側で、使用するアカウント名を選択し、次に **[Security Credentials]** (セキュリティ認証情報) を選択します。必要に応じて、**[Continue to Security credentials]** (セキュリティ認証情報に進む) を選択します。  
![\[ナビゲーションメニューの [Security credentials] (セキュリティ認証情報)\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. ページの [**Multi-Factor Authentication (MFA)**] セクションを展開します。

1. デバイスの横にあるラジオボタンを選択して、**[Resync]** (再同期) を選択します。

1. **[Resync MFA device]** (MFA デバイスを再同期) ダイアログボックスで、デバイスで連続して生成された次の 2 つのコードを **[MFA code 1]** (MFA コード 1) および **[MFA code 2]** (MFA コード 2) に入力します。次に、**[Resync]** (再同期) を選択します。
**重要**  
コードを生成したら、即時にリクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーとは正常に関連付けられますが、その MFA デバイスは同期しません。これは、タイムベースドワンタイムパスワード (TOTP) の有効期間が短いために起こります。

## 仮想およびハードウェア MFA デバイスの再同期 (AWS CLI)
<a name="id_credentials_mfa_sync_cli"></a>

AWS CLI から仮想およびハードウェア MFA デバイスを再同期できます。

**IAM ユーザーの仮想 MFA デバイスまたはハードウェア MFA デバイスを再同期するには (AWS CLI)**  
コマンドプロンプトで、[aws iam resync-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html)コマンドを発行します。
+ 仮想 MFA デバイス: デバイスの Amazon リソースネーム（ARN）をシリアル番号として入力します。

  ```
  aws iam resync-mfa-device --user-name Richard --serial-number arn:aws:iam::123456789012:mfa/RichardsMFA --authentication-code1 123456 --authentication-code2 987654
  ```
+ ハードウェア MFA デバイス: ハードウェアデバイスのシリアル番号をシリアル番号として指定します。形式はベンダー固有です。例えば、Amazon から gemalto トークンを購入できます。シリアル番号は通常、4 つの文字の後に 4 つの数字が続きます。

  ```
  aws iam resync-mfa-device --user-name Richard --serial-number ABCD12345678 --authentication-code1 123456 --authentication-code2 987654
  ```

**重要**  
コードを生成したら、即時にリクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合は、コードの有効期間が短いためリクエストは送信されません。

## 仮想およびハードウェア MFA デバイスの再同期 (AWS API)
<a name="id_credentials_mfa_sync_api"></a>

IAM には同期を実行する API コールがあります。この場合、仮想およびハードウェア MFA デバイスユーザーにこの API コールに対するアクセス許可を付与することをお勧めします。API コールに基づいてツールを構築して、ユーザーが必要に応じてデバイスを再同期できるようにします。

**IAM ユーザーの仮想またはハードウェア MFA デバイスを再同期するには (AWS API)**
+ [ResyncMFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html) リクエストを送信します。

# MFA デバイスを無効にする
<a name="id_credentials_mfa_disable"></a>

IAM ユーザーとして多要素認証 (MFA) デバイスにサインインできない場合は、管理者に連絡してください。

管理者として、他の IAM ユーザー用に端末を無効にすることができます。これにより、ユーザーは MFA を使用しないでサインインできます。MFA デバイスが置き換えられる際、またはデバイスが一時的に使用できない時に、一時的な対処方法としてれを行う場合があります。ただし、ユーザーの新しいデバイスを可能な限り速やかに有効にすることをお勧めします。MFA デバイスを有効化する方法については [IAM の AWS 多要素認証](id_credentials_mfa.md) を参照してください。

**注記**  
API または AWS CLI を使用して AWS アカウント からユーザーを削除する場合は、ユーザーの MFA デバイスを無効化または削除する必要があります。この変更は、ユーザーを削除するプロセスの一環として行います。ユーザーの削除の詳細については、「[IAM ユーザーを削除または非アクティブ化する](id_users_remove.md)」を参照してください。

**Topics**
+ [

## MFA デバイスの無効化 (コンソール)
](#deactive-mfa-console)
+ [

## MFA デバイスの無効化 (AWS CLI)
](#deactivate-mfa-cli)
+ [

## MFA デバイスの無効化 (AWS API)
](#deactivate-mfa-api)

## MFA デバイスの無効化 (コンソール)
<a name="deactive-mfa-console"></a><a name="deactivate-mfa-for-user"></a>

**別の IAM ユーザーの MFA デバイスを無効化するには (コンソール)**

1. AWS マネジメントコンソールにサインインして、IAM コンソールを開きます [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. ユーザーの MFA デバイスを非アクティブ化するには、削除する MFA を持つユーザーの名前を選択します。

1. ［**Security credentials**］タブを選択します。

1. **[多要素認証 (MFA)]** で MFA デバイスの横にあるラジオボタンを選択し、**[削除]** を選択し、さらにまた **[削除]** を選択します。

   デバイスは AWS から削除されます。このデバイスは、再び有効化されて AWS ユーザーや AWS アカウントのルートユーザー に関連付けられるまで、サインインやリクエストの認証に使用できなくなります。<a name="deactivate-mfa-for-root"></a>

**AWS アカウントのルートユーザー の MFA デバイスを無効にするには (コンソール)**

1. **[Root user]** (ルートユーザー) を選択して AWS アカウント の E メールアドレスを入力し、アカウント所有者として [IAM コンソール](https://console.aws.amazon.com/iam/)にサインインします。次のページでパスワードを入力します。
**注記**  
ルートユーザーでは、「**IAM ユーザーとしてサインイン**」ページにサインインすることはできません。**[IAM ユーザーのサインイン]** ページが表示された場合、ページ下部付近で **[ルートユーザーの電子メールを使用してサインインする]** を選択します。ルートユーザーを使用してサインインする方法については、AWS サインイン ユーザーガイドの「[ルートユーザーとして AWS マネジメントコンソール へサインインする](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-          root-user-sign-in-tutorial.html)」を参照してください。

1. ナビゲーションバーの右側で、使用するアカウント名を選択し、次に **[Security Credentials]** (セキュリティ認証情報) を選択します。必要に応じて、**[Continue to Security credentials]** (セキュリティ認証情報に進む) を選択します。  
![\[ナビゲーションメニューのセキュリティ認証情報\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. **[Multi-factor authentication (MFA)]** (多要素認証 (MFA))セクションで、無効化する MFA デバイスの横にあるラジオボタンをオンにし、**[Remove]** (削除) を選択します。

1. **[**を削除] を選択します。

   AWS アカウント 向けの MFA デバイスの無効化が完了しました。AWS アカウント に関連付けられている E メールを Amazon Web Services からの確認メッセージで確認します。この E メールでは、Amazon Web Services の Multi-Factor Authentication (MFA) が無効化されたことを通知します。メッセージは `@amazon.com` または `@aws.amazon.com` から送信されます。

**注記**  
AWS アカウント で割り当てられていない仮想 MFA デバイスは、AWS マネジメントコンソール 経由で、またはサインインプロセス中に新しい仮想 MFA デバイスを追加すると削除されます。未割り当ての仮想 MFA デバイスとは、お客様のアカウントにあるデバイスですが、アカウントのルートユーザーまたは IAM ユーザーがサインインプロセスで使用されません。これらは削除されるため、新しい仮想 MFA デバイスをアカウントに追加できます。また、デバイス名を再利用することもできます。

## MFA デバイスの無効化 (AWS CLI)
<a name="deactivate-mfa-cli"></a>

**IAM ユーザーの MFA デバイスを無効化するには (AWS CLI)**
+ 次のコマンドを実行します。[https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html)

## MFA デバイスの無効化 (AWS API)
<a name="deactivate-mfa-api"></a>

**IAM ユーザーの MFA デバイスを無効化するには (AWS API)**
+ 呼び出すオペレーション: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)

# IAM 内で MFA で保護された ID を復元する
<a name="id_credentials_mfa_lost-or-broken"></a>

[仮想 MFA デバイス](id_credentials_mfa_enable_virtual.md)または[ハードウェア TOTP トークン](id_credentials_mfa_enable_physical.md)が正常に機能しているようでも、AWS リソースへのアクセスに使用できない場合は、AWS と同期していない可能性があります。仮想またはハードウェア MFA デバイスの同期については、「[仮想 MFA デバイスとハードウェア MFA デバイスを再同期する](id_credentials_mfa_sync.md)」を参照してください。[FIDO セキュリティキー](id_credentials_mfa_enable_fido.md)は同期しなくなることはありません。

AWS アカウントのルートユーザーの [MFA デバイス](id_credentials_mfa.md)で紛失、破損、動作不能といった問題が起きても、アカウントへのアクセスを回復できます。IAM ユーザーは、デバイスを無効にするために管理者に連絡する必要があります。

**重要**  
複数の MFA デバイスをアクティブ化することをお勧めします。複数の MFA デバイスを登録すると、1 つのデバイスが紛失または損傷しても、継続的なアクセスを確保できるようになります。AWS アカウントのルートユーザー と IAM ユーザーは、任意のタイプの MFA デバイスを最大 8 台登録できます。

## 前提条件 — 別の MFA デバイスを使用する
<a name="mfa-lost-or-broken-prerequisites"></a>

[多要素認証 (MFA) デバイス](id_credentials_mfa.md)を紛失または破損したり、MFA デバイスが機能しなかったりする場合は、同じルートユーザーまたは IAM ユーザーに登録された別の MFA デバイスを使用してサインインできます。

**別の MFA デバイスを使用してサインインするには**

1. AWS アカウント ID またはアカウントのエイリアスおよびパスワードを使用して [AWS マネジメントコンソール](url-comsole-domain;iam) にサインインします。

1. **[追加の検証が必要]** ページまたは **[多要素認証]** ページで、**[別の MFA 方法を試す]** を選択します。

1. 選択した MFA デバイスのタイプで認証します。

1. 次のステップは、代替 MFA デバイスで正常にサインインしたかどうかによって異なります。
   + 正常にサインインできたら、[仮想 MFA デバイスとハードウェア MFA デバイスを再同期する](id_credentials_mfa_sync.md) を実行できます。これにより、問題が解決する可能性があります。MFA デバイスが紛失または破損した場合は、非アクティブ化できます。MFA デバイスタイプを無効にする方法については、「[MFA デバイスを無効にする](id_credentials_mfa_disable.md)」を参照してください。
   + MFA でサインインできない場合は、「[ルートユーザー MFA デバイスの回復](#root-mfa-lost-or-broken)」または「[IAM ユーザー MFA デバイスの回復](#iam-user-mfa-lost-or-broken)」のステップを実行して、MFA で保護された ID を復旧します。



## ルートユーザー MFA デバイスの回復
<a name="root-mfa-lost-or-broken"></a>

MFA を使用してサインインできない場合は、アカウントに登録されているメールアドレスと主な連絡先電話番号を使用して本人確認を行うことで、別の認証方法を使用してサインインできます。

代替認証要素を使用してルートユーザーとしてサインインする前に、アカウントに関連付けられている E メールと主要連絡先の電話番号にアクセスできることを確認します。主要連絡先の電話番号を更新する必要がある場合は、ルートユーザーではなく、管理者アクセス権を持つ IAM ユーザーとしてサインインします。アカウント連絡先情報の更新に関するその他の手順については、AWS Billing ユーザーガイドの「[連絡先情報の編集](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html)」を参照してください。E メールと主要連絡先の電話番号にアクセスできない場合は、[AWS サポート](https://support.aws.amazon.com/#/contacts/aws-mfa-support) に連絡する必要があります。

**重要**  
アカウントを正常に回復するために、ルートユーザーにリンクされている E メールアドレスと連絡先電話番号を最新の状態に保つことをお勧めします。詳細については、「AWS アカウント管理リファレンスガイド」の「[AWS アカウントの主要連絡先の更新](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html)」を参照してください。

**認証の代替要因を AWS アカウントのルートユーザー として使用してログインするには**

1.  **[ルートユーザー]** を選択し、AWS アカウント のメールアドレスを入力して、アカウント所有者として [AWS マネジメントコンソール](https://console.aws.amazon.com/) にサインインします。次のページでパスワードを入力します。

1. 「**追加の検証が必要**」ページで、認証に使用する MFA メソッドを選択し、**[次へ]** を選択します。
**注記**  
次のような代替テキストが表示される場合があります。**MFA を使用してサインイン**、**認証デバイスのトラブルシューティング**、または **MFA のトラブルシューティング**ですが、機能は同じです。代替認証要素を使用してアカウントの E メールアドレスと主要連絡先の電話番号を確認できない場合は、MFA デバイスを非アクティブ化するように [AWS サポート](https://support.aws.amazon.com/#/contacts/aws-mfa-support) に連絡する必要があります。

1. 使用している MFA の種類に応じて表示されるページは異なりますが、**[MFA のトラブルシューティング]** オプションの機能は同じです。**[追加の検証が必要]** ページまたは「[**多要素認証]** ページで、**[MFA のトラブルシューティング]** を選択します。

1. 必要に応じて、パスワードをもう一度入力し、[**サインイン**] を選択します。

1. **[認証デバイスのトラブルシューティング]** ページの **[別の認証要素を使用してサインイン]** セクションで **[別の要素を使用してサインイン]** を選択します。

1. 「**別の認証要素を使用してサインイン**」ページで、E メールアドレスの確認を行ってアカウントを認証します。**[確認 E メールを送信]** を選択します。

1. AWS アカウント に関連付けられているメールで、Amazon ウェブサービス (recover-mfa-no-reply@verify.signin.aws) からのメッセージを確認します。E メールの指示にしたがって操作します。

   アカウントに E メールが表示されない場合は、迷惑メールフォルダを確認するか、ブラウザに戻り、[**Resend the email (E メールの再送信)**] を選択します。

1. E メールアドレスを確認した後も、アカウントの認証を続けることができます。主要連絡先の電話番号を確認するには、**[Call me now]** (すぐに連絡を受ける) を選択します。

1. AWS からの呼び出しに応答し、プロンプトが表示されたら、AWS ウェブサイトの電話番号の 6 桁の番号を入力します。

   AWS からの呼び出しを受けない場合は、[**サインイン**] を選択してコンソールに再度サインインし、やり直してください。または、「[Lost or unusable Multi-Factor Authentication (MFA) device](https://support.aws.amazon.com/#/contacts/aws-mfa-support)」(多要素認証 (MFA) の紛失または使用不可) を参照して、サポートにお問い合わせください。

1. 電話番号を確認した後、[**Sign in to the console (コンソールにサインイン)**] を選択してアカウントにサインインすることができます。

1. 次の手順は、使用している MFA のタイプによって異なります。
   + 仮想 MFA デバイスの場合は、デバイスからアカウントを削除します。次に、[AWS セキュリティ認証情報](https://console.aws.amazon.com/iam/home?#security_credential)ページにアクセスし、古い仮想 MFA デバイスのエンティティを削除してから、新しいキーペアを作成することができます。
   + FIDO セキュリティキーの場合は、[[AWS Security Credentials]](https://console.aws.amazon.com/iam/home?#security_credential) ページに移動し、新しい FIDO セキュリティキーを有効にする前に古い FIDO セキュリティキーを非アクティブにします。
   + ハードウェア TOTP トークンの場合は、デバイスの修理または交換についてサードパーティープロバイダーにお問い合わせください。新しいデバイスを受け取るまで、認証の代替要因を使用してサインインを続けることができます。新しいハードウェア MFA デバイスを入手したら、[AWS セキュリティ認証情報](https://console.aws.amazon.com/iam/home?#security_credential)ページに移動し、古い MFA デバイスを削除します。
**注記**  
紛失または盗難された MFA デバイスを同じタイプのデバイスで置き換える必要はありません。例えば、FIDO セキュリティキーが損傷し、新しいものを注文した場合は、その新しい FIDO キーが届くまで、仮想 MFA またはハードウェア TOTP トークンを使用できます。

**重要**  
MFA デバイスが紛失または盗まれた場合は、代替の MFA デバイスにサインインして確立してから、ルートユーザーパスワードを変更します。攻撃者が認証デバイスを盗み、現在のパスワードも保持している可能性があるからです。詳細については、「[AWS アカウントのルートユーザー のパスワードを変更する](root-user-password.md)」を参照してください。

## IAM ユーザー MFA デバイスの回復
<a name="iam-user-mfa-lost-or-broken"></a>

MFA でサインインできない IAM ユーザーは、自ら MFA デバイスを復旧することはできません。管理者に連絡して、デバイスを非アクティブ化するように依頼する必要があります。その後、新しいデバイスを有効にすることができます。

**IAM ユーザーとしての MFA デバイスに関するヘルプ情報を入手するには**

1. お使いの IAM ユーザーのユーザー名やパスワードの設定を行った AWS システム管理者あるいは別の担当者にご連絡ください。管理者は､サインインできるように「[MFA デバイスを無効にする](id_credentials_mfa_disable.md)」の説明に従って、MFA デバイスを非アクティブ化する必要があります。

1. 次の手順は、使用している MFA のタイプによって異なります。
   + 仮想 MFA デバイスの場合は、デバイスからアカウントを削除します。次に、「[AWS マネジメントコンソールで仮想 MFA デバイスを割り当てる](id_credentials_mfa_enable_virtual.md)」の説明に従って､仮想デバイスを有効にします。
   + FIDO セキュリティキーの場合、デバイスの交換についてサードパーティープロバイダーにお問い合わせください。新しい FIDO セキュリティキーを受け取ったら、「[AWS マネジメントコンソールでパスキーやセキュリティキーを割り当てる](id_credentials_mfa_enable_fido.md)」で説明されているとおりに有効にします。
   + ハードウェア TOTP トークンの場合は、デバイスの修理または交換についてサードパーティープロバイダーにお問い合わせください。新しい物理 MFA デバイスを入手したら、「[AWS マネジメントコンソールでハードウェア TOTP トークンを割り当てる](id_credentials_mfa_enable_physical.md)」の説明に従ってデバイスを有効にします。
**注記**  
紛失または盗難された MFA デバイスを同じタイプのデバイスで置き換える必要はありません。任意の組み合わせの MFA デバイスを最大で 8 台用意できます。例えば、FIDO セキュリティキーが損傷し、新しいものを注文した場合は、その新しい FIDO キーが届くまで、仮想 MFA またはハードウェア TOTP トークンを使用できます。

1. MFA デバイスを紛失または盗難にあった場合は、アタッカーがその認証デバイスから現在のパスワードを入手している可能性があるため、パスワードを変更してください。詳細については、[IAM ユーザーのパスワードを管理する](id_credentials_passwords_admin-change-user.md) を参照してください。

# MFA を使用した安全な API アクセス
<a name="id_credentials_mfa_configure-api-require"></a>

IAM ポリシーを使用して、ユーザーが呼び出すことができる API オペレーションを指定できます。特に重要なアクションの実行をユーザーに許可する前に、多要素認証 (MFA) で認証するように求めることで、セキュリティを強化できます。

たとえば、ユーザーにAmazon EC2 `RunInstances`、`DescribeInstances`、および `StopInstances` アクションの実行を許可するポリシーがすでに存在する可能性があります。ただし `TerminateInstances` のような有害なアクションを制限し、AWS MFA デバイスによって認証される場合に限り、ユーザーがそのアクションを実行できるように管理することもできます。

**Topics**
+ [

## 概要:
](#MFAProtectedAPI-overview)
+ [

## シナリオ: クロスアカウントの委任の MFA 保護
](#MFAProtectedAPI-cross-account-delegation)
+ [

## シナリオ: 現在のアカウントの API オペレーションへのアクセスに対する MFA 保護
](#MFAProtectedAPI-user-mfa)
+ [

## シナリオ: リソースベースのポリシーを持つリソースの MFA 保護
](#MFAProtectedAPI-resource-policies)

## 概要:
<a name="MFAProtectedAPI-overview"></a>

API オペレーションに MFA 保護を追加する場合、次のタスクが関連します:

1. 管理者は、MFA 認証が求められる API リクエストを行うユーザーごとに AWS MFA デバイスを設定します。詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。

1. 管理者はユーザーに対し、ユーザーが AWS MFA デバイスで認証されているかどうかを確認する `Condition` 要素を含むポリシーを作成します。

1. ユーザーは、MFA パラメータをサポートする AWS STS API オペレーションである [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) または [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) のいずれかを呼び出します。この呼び出しの一部としてユーザーは、このユーザーに関連付けられるデバイスのデバイス識別子を含めます。また、ユーザーは、デバイスが生成する時間ベースのワンタイムパスワード (TOTP) も含めます。そのつど、ユーザーは一時的な認証情報を取り戻し、その情報を使用して AWS に追加リクエストを行うことができます。
**注記**  
サービスの API オペレーションの MFA 保護は、サービスが一時的なセキュリティ認証情報をサポートする場合にのみ使用できます。サポートするサービスの一覧については、「[一時的セキュリティ認証情報を使用して AWS にアクセスする](https://docs.aws.amazon.com/STS/latest/UsingSTS/UsingTokens.html)」を参照してください。

承認が失敗した場合、AWS は他の承認されていないアクセスと同様に "Access Denied" というエラーメッセージを返します。MFA 保護 API ポリシーが存在する場合、ユーザーが有効な MFA 認証なしで API オペレーションを呼び出す場合に、AWS はポリシーで指定される API オペレーションへのアクセスを拒否します。また、API オペレーションへのリクエストのタイムスタンプがポリシーで指定される許可範囲外である場合にも、そのオペレーションは拒否されます。ユーザーは、MFA コードとデバイスのシリアルナンバーを使って新しい一時的な認証情報をリクエストすることで、再度、MFA の認証を受ける必要があります。

### MFA 条件を指定した IAM ポリシー
<a name="MFAProtectedAPI-policies"></a>

MFA 条件を指定したポリシーは、次にアタッチすることができます:
+ IAM ユーザーまたはグループ
+ Amazon S3 バケット、Amazon SQS キュー、または Amazon SNS トピックなどのリソース
+ ユーザーが引き受けることのできる IAM ロールの信頼ポリシー

ポリシーの MFA 条件を使用して、次のプロパティを確認することができます。
+ 存在 — ユーザーが MFA を使って認証されたことを単に確認するには、`Bool` 条件で `aws:MultiFactorAuthPresent` キーが `True` であることを確認します。ユーザーが短期的な認証情報で認証した場合に限りキーが表示されます。アクセスキーのような長期的な認証情報に、このキーは含まれません。
+ 期間 - MFA 認証後、指定された期間内のみアクセス権を与える場合、数値条件タイプを使用して `aws:MultiFactorAuthAge` キーの有効期間を値 (3600 秒など) と比較します。MFA が使用されなかった場合、`aws:MultiFactorAuthAge` キーは存在しません。

以下の例は、MFA 認証の存在をテストする MFA 条件が含まれる、IAM ロールの信頼ポリシーを示します。このポリシーにより、`Principal` 要素 (`ACCOUNT-B-ID` を有効な AWS アカウント ID に置き換えます) で指定された AWS アカウント のユーザーは、このポリシーがアタッチされたロールを引き受けることができます。ただし、このようなユーザーは、MFA を使用して認証されたユーザーの場合のみ、ロールを引き受けることができます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}
```

------

MFA の条件種別の詳細については、「[AWS グローバル条件コンテキストキー](reference_policies_condition-keys.md)」、「[数値条件演算子](reference_policies_elements_condition_operators.md#Conditions_Numeric)」、および「[条件キーの有無をチェックする条件演算子](reference_policies_elements_condition_operators.md#Conditions_Null)」を参照してください。

### GetSessionToken または AssumeRole を選択する
<a name="scenarios"></a>

AWS STS には、ユーザーが MFA 情報を渡す際に使用できる 2 つの API オペレーションである `GetSessionToken` と `AssumeRole` があります。ユーザーが一時的な認証情報を取得するために呼び出す API オペレーションは、以下のどのシナリオがあてはまるかによって異なります。

**以下のシナリオでは、`GetSessionToken` を使用します。**
+ リクエストを作成する IAM ユーザーと同じ AWS アカウント のリソースにアクセスする API オペレーションの呼び出し。 `GetSessionToken`リクエストによる一時的な認証情報で IAM および AWS STS API にアクセスできるのは、認証情報のリクエストに MFA 情報を含めた場合*のみ*である点に注意してください。`GetSessionToken` によって返される一時的な認証情報には MFA 情報が含まれているので、認証情報によって実行される各 API オペレーションで MFA を確認できます。
+ リソースに基づくポリシー (MFA 条件を含む) で保護されているリソースへのアクセス。

`GetSessionToken` オペレーションの目的は、MFA を使用してユーザーを認証することです。認証オペレーションを制御するためにポリシーを使用することはできません。

**以下のシナリオでは、`AssumeRole` を使用します。**
+ 同じまたは異なる AWS アカウント のリソースにアクセスする API オペレーションの呼び出し。API コールには、任意の IAM または AWS STS API を含めることができます。アクセスを保護するには、ユーザーがロールを引き受けた時点で MFA を強制する必要があります。`AssumeRole` によって返される一時的な認証情報のコンテキストには MFA 情報が含まれていないので、MFA に対する個別の API オペレーションを確認できません。このため、リソースベースのポリシーで保護されたリソースへのアクセスを制限するために、`GetSessionToken` を使用する必要があります。

**注記**  
IAM ユーザーが MFA でサインインするとき、AWS CloudTrail ログには MFA 情報が含まれます。IAM ユーザーが IAM ロールを引き受けると、CloudTrail は引き受けたロールを使用して実行されたアクションの `sessionContext` 属性も `mfaAuthenticated: true` をログに記録します。ただし、CloudTrail ログ記録は、引き受けたロールの認証情報を使用して API コールが行われたときに IAM で必要になるものとは異なります。詳細については、「[CloudTrail userIdentity 要素](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)」を参照してください。

これらのシナリオの実行方法に関する詳細は、本書で後から提供されます。

### MFA 保護された API アクセスについて重要な点
<a name="MFAProtectedAPI-important-points"></a>

API オペレーションの MFA 保護の次の点に注意してください:
+ MFA 保護は、一時的なセキュリティ認証情報を使用した場合のみ利用できます。この認証情報は、`AssumeRole` または `GetSessionToken` を使用して取得する必要があります。
+ AWS アカウントのルートユーザー 認証情報で MFA 保護 API アクセスを使用することはできません。
+ U2F セキュリティキーで MFA 保護 API アクセスを使用することはできません。
+ フェデレーションユーザーに AWS サービス利用のために MFA デバイスを割り当てることはできませんので、そのようなユーザーは MFA が管理する AWS リソースへアクセスできません。(次のポイントを参照してください。) 
+ 一時的な認証情報を返す他の AWS STS API オペレーションは、MFA をサポートしていません。`AssumeRoleWithWebIdentity` と `AssumeRoleWithSAML` の場合、ユーザーは外部プロバイダーによって認証されており、プロバイダーが MFA を要求したかどうかを AWS が判断することはできません。`GetFederationToken` については、MFA は必ずしも特定のユーザーに関連付けられていません。
+ 同様に、長期的な認証情報 (IAM ユーザーアクセスキーと ルートユーザーアクセスキー) は失効しないため、MFA 保護 API アクセスでは使用できません。
+ `AssumeRole` と `GetSessionToken` は、MFA 情報がない状態でも呼び出すことができます。この場合、発信者は一時的な認証情報を取り戻しますが、その一時的認証情報のセッション情報では、ユーザーが MFA を使用して認証されたことが示されません。
+ API オペレーションに対する MFA 保護を確立するには、ポリシーに MFA 条件を追加します。MFA の使用を適用するには、ポリシーに `aws:MultiFactorAuthPresent` 条件キーが含まれている必要があります。クロスアカウントの委任では、ロールの信頼ポリシーに条件キーが含まれている必要があります。
+ 別の AWS アカウント に自分のアカウントのリソースへのアクセスを許可する場合、リソースのセキュリティは、信頼されたアカウント (つまりお客様のアカウントではない他のアカウント) の設定によって決まります。これは、多要素認証を要求する場合にも当てはまります。仮想 MFA デバイスを作成するアクセス許可がある、信頼されるアカウント内のアイデンティティは、ロールの信頼ポリシーのその部分を満たすために MFA クレームを作成できます。他のアカウントのメンバーに多要素認証を必要とする自身の AWS リソースへのアクセスを許可する前に、信頼されるアカウントの所有者がセキュリティのベストプラクティスを取り入れていることを確認する必要があります。たとえば、信頼されるアカウントは、MFA デバイス管理 API オペレーションなどの機密性の高い API オペレーションへのアクセスを指定する信頼できるアイデンティティに制限する必要があります。
+ ポリシーに MFA の条件が含まれている場合、ユーザーが MFA 認証済みでないか、無効な MFA デバイス識別子または無効な TOTP を入力すると、リクエストは拒否されます。

## シナリオ: クロスアカウントの委任の MFA 保護
<a name="MFAProtectedAPI-cross-account-delegation"></a>

このシナリオでは、ユーザーが AWS MFA デバイスを使用して認証された場合にのみ、別のアカウントの IAM ユーザーにアクセスを委任します。クロスアカウントの委任に関する詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」を参照してください。

アカウント A (アクセス対象のリソースを所有している信頼するアカウント) があり、このアカウントに管理者権限を持つ IAM ユーザー Anaya がいると仮定します。Anaya は、アカウント B (信頼されたアカウント) のユーザー Richard にアクセス許可を付与するつもりですが、Richard がロールを引き受ける前に、MFA によって認証されていることを確認する必要があります。

1. 信頼するアカウント A で、Anaya は `CrossAccountRole` という IAM ロールを作成し、ロールの信頼ポリシーのプリンシパルをアカウント B のアカウント ID に設定します。この信頼ポリシーは、AWS STS `AssumeRole` アクションに対するアクセス許可を付与します。Anaya は、次の例に示すように、信頼ポリシーに MFA の条件も追加します。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Allow",
       "Principal": {"AWS": "ACCOUNT-B-ID"},
       "Action": "sts:AssumeRole",
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }
   }
   ```

------

1. Anaya は、ロールが実行できることを指定するアクセス許可ポリシーを、ロールに追加します。MFA 保護を使用するロールのアクセス許可ポリシーは、他のロールアクセス許可ポリシーと同じです。次の例では、Anaya がこのロールに追加するポリシーを示しています。これによって、引き受けるユーザーがアカウント A のテーブル `Books` で任意の Amazon DynamoDB アクションを実行することを許可します。また、このポリシーは、コンソールでアクションを実行するときに必要となる `dynamodb:ListTables` アクションも許可します。
**注記**  
アクセス許可ポリシーに MFA 条件は含まれません。ユーザーがロールを引き受けることができるかどうかを決定するためにのみ MFA 認証が使用されていることに注意してください。ユーザーがロールを引き受けた場合、それ以上の MFA の確認は行われません。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "TableActions",
               "Effect": "Allow",
               "Action": "dynamodb:*",
               "Resource": "arn:aws:dynamodb:*:111122223333:table/Books"
           },
           {
               "Sid": "ListTables",
               "Effect": "Allow",
               "Action": "dynamodb:ListTables",
               "Resource": "*"
           }
       ]
   }
   ```

------

1. 信頼されたアカウント B で管理者は、IAM ユーザー Richard が AWS MFA デバイスを使用して設定されていること、および Richard がデバイスの ID を知っていることを確認します。ハードウェア MFA デバイスの場合には、デバイス ID はシリアル番号であり、仮想 MFA デバイスの場合には、デバイス ID はデバイスの ARN です。

1. アカウント B で、管理者は、`AssumeRole` アクションを呼び出すことを許可する次のポリシーを、ユーザー Richard (または彼が属するグループ) にアタッチします。リソースは、Anaya がステップ 1 で作成したロールの ARN に設定されます。このポリシーに MFA 条件が含まれないことに注意してください。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "sts:AssumeRole"
               ],
               "Resource": [
                   "arn:aws:iam::111122223333:role/CrossAccountRole"
               ]
           }
       ]
   }
   ```

------

1. アカウント B で、Richard (または Richard が実行中のアプリケーション) が `AssumeRole` を呼び出します。API コールには、引き受けるロールの ARN (`arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole`)、MFA デバイスの ID、Richard がデバイスから取得した現在の TOTP が含まれます。

   Richard が `AssumeRole` を呼び出すと、AWS は Richard に有効な認証情報 (MFA の要件など) があるかどうかを確認します。その場合、Richard は正常にロールを引き受け、ロールの一時的な認証情報を使用して、アカウント A の `Books` という名前のテーブルで DynamoDB アクションを実行できます。

   `AssumeRole` を呼び出すプログラムの例については、「[MFA 認証での AssumeRole の呼び出し](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-assumerole)」を参照してください。

## シナリオ: 現在のアカウントの API オペレーションへのアクセスに対する MFA 保護
<a name="MFAProtectedAPI-user-mfa"></a>

このシナリオでは、使用する AWS アカウント でユーザーが AWS MFA デバイスを使用して認証された場合のみ、機密性の高い API オペレーションにアクセスできるようにする必要があります。

アカウント A があり、そこに EC2 インスタンスの作業を必要としている開発者グループが存在すると仮定します。通常の開発者は、インスタンスの作業を実行できますが、`ec2:StopInstances` または `ec2:TerminateInstances` アクションへのアクセス許可を付与されていません。このようなの「有害な」特権的アクションをいくつかの信頼されたユーザーに制限するために、これらの機密性の高い Amazon EC2 アクションを許可するポリシーに MFA 保護を追加します。

このシナリオでは、信頼されたユーザーの 1 人がユーザー Sofía です。ユーザー Anaya は、アカウント A の管理者です。

1. Anaya は、Sofía が AWS MFA デバイスで設定されていること、および Sofía がこのデバイスの ID を知っていることを確認します。ハードウェア MFA デバイスの場合には、デバイス ID はシリアル番号であり、仮想 MFA デバイスの場合には、デバイス ID はデバイスの ARN です。

1. Anaya は `EC2-Admins` という名のグループを作成し、ユーザー Sofía をグループに追加します。

1. Anaya は、次のポリシーを `EC2-Admins` グループにアタッチします。このポリシーは、ユーザーが MFA を使用して認証された場合にのみ、ユーザーに Amazon EC2 `StopInstances` アクションと `TerminateInstances` アクションを呼び出すアクセス許可を与えます。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [{
       "Effect": "Allow",
       "Action": [
         "ec2:StopInstances",
         "ec2:TerminateInstances"
       ],
       "Resource": ["*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }
   ```

------

1. 
**注記**  
このポリシーを有効にするために、ユーザーはまずサインアウトして、再度サインインする必要があります。

   ユーザー Sofía が Amazon EC2 インスタンスを停止または終了する必要がある場合、Sofía (または Sofía が実行しているアプリケーション) は `GetSessionToken` を呼び出します。この API オペレーションは、MFA デバイスの ID と Sofía がデバイスから取得した現在の TOTP を渡します。

1. ユーザー Sofía (または Sofía が使用しているアプリケーション) は、`GetSessionToken` から提供される一時的な認証情報を使用して Amazon EC2 の `StopInstances` または `TerminateInstances` アクションを呼び出します。

   `GetSessionToken` を呼び出すプログラムの例については、本書で後から説明する「[MFA 認証での GetSessionToken の呼び出し](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-getsessiontoken)」を参照してください。

## シナリオ: リソースベースのポリシーを持つリソースの MFA 保護
<a name="MFAProtectedAPI-resource-policies"></a>

このシナリオでは、S3 バケット、SQS キュー、または SNS トピックの所有者であるとします。リソースにアクセスする任意の AWS アカウント の任意のユーザーが AWS MFA デバイスによって認証されていることを確認する必要があります。

このシナリオは、最初にユーザーにロールを引き受けることを要求せずに、クロスアカウント MFA 保護を提供する方法を説明します。この場合、ユーザーは次の 3 つの条件を満たしている場合にリソースにアクセスできます。これは、ユーザーが MFA によって認証される必要があること、`GetSessionToken` から一時的なセキュリティ認証情報を取得できること、および、リソースのポリシーによって信頼されているアカウントにいることです。

アカウント A に存在し、S3 バケットを作成すると仮定します。さまざまな AWS アカウント に存在するユーザーが、MFA を使って認証されている場合にのみ、このバケットへのアクセスを許可します。

このシナリオでは、ユーザー Anaya はアカウント A の管理者です。ユーザー Nikhil は、アカウント C の IAM ユーザーです。

1. アカウント A で、Anaya が `Account-A-bucket` という名前のバケットを作成します。

1. Anaya はバケットにバケットポリシーを追加します。このポリシーは、アカウント A、アカウント B、またはアカウント C のユーザーに、バケット内の Amazon S3 `PutObject` および `DeleteObject` アクションの実行を許可します。ポリシーは、MFA 条件を含みます。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [{
       "Effect": "Allow",
       "Principal": {"AWS": [
         "ACCOUNT-A-ID",
         "ACCOUNT-B-ID",
         "ACCOUNT-C-ID"
       ]},
       "Action": [
         "s3:PutObject",
         "s3:DeleteObject"
       ],
       "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }
   ```

------
**注記**  
Amazon S3 により MFA 削除機能が *ルート*アカウントアクセス (のみ)に提供されています。バケットのバージョニング状態を設定する際に、Amazon S3 MFA 削除機能を有効にできます。IAM ユーザーでは Amazon S3 MFA 削除機能を使うことはできず、また MFA 保護 API とは別のアクセス管理となっています。バケットの削除権限を持つ IAM ユーザーであっても、Amazon S3 MFA 削除機能を使用してバケットの削除を行うことはできません。Amazon S3 MFA 削除機能の詳細については、[MFA Delete](https://docs.aws.amazon.com/AmazonS3/latest/dev/MultiFactorAuthenticationDelete.html) を参照してください。

1. アカウント C で管理者は、ユーザー Nikhil が AWS MFA デバイスを使用して設定されていること、および Nikhil がデバイスの ID を知っていることを確認します。ハードウェア MFA デバイスの場合には、デバイス ID はシリアル番号であり、仮想 MFA デバイスの場合には、デバイス ID はデバイスの ARN です。

1. アカウント C で、Nikhil (または Nikhil が実行中のアプリケーション) が `GetSessionToken` を呼び出します。呼び出しには、MFA デバイスの ID または ARN、および Nikhil がデバイスから取得する現在の TOTP が含まれます。

1. Nikhil (または Nikhil が使用中のアプリケーション) は、`GetSessionToken` から返された一時的な認証情報を使用して Amazon S3 の `PutObject` アクションを呼び出し、ファイルを `Account-A-bucket` にアップロードします。

   `GetSessionToken` を呼び出すプログラムの例については、本書で後から説明する「[MFA 認証での GetSessionToken の呼び出し](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-getsessiontoken)」を参照してください。
**注記**  
この場合、`AssumeRole` が返す一時的認証情報は機能しません。ユーザーはロールを引き受けるために MFA 情報を提供できますが、`AssumeRole` が返す一時的認証情報には MFA 情報は含まれません。この情報は、このポリシーの MFA 条件を満たすために必要です。

# サンプルコード: 多要素認証での認証情報のリクエスト
<a name="id_credentials_mfa_sample-code"></a>

以下の例では、`GetSessionToken` と `AssumeRole` オペレーションを呼び出し、MFA 認証パラメータを渡す方法を示しています。`GetSessionToken` の呼び出しにはアクセス権限は必要ありませんが、`AssumeRole` を呼び出すポリシーがあることが必要です。返される認証情報は、アカウントのすべての S3 バケットを一覧表示するために使用されます。

## MFA 認証での GetSessionToken の呼び出し
<a name="MFAProtectedAPI-example-getsessiontoken"></a>

以下の例は、`GetSessionToken` を呼び出し、MFA 認証情報を渡す方法を示しています。`GetSessionToken` オペレーションによって返される一時的な認証情報は、アカウントのすべての S3 バケットを一覧表示するために使用されます。

このコードを実行するユーザー (あるいはこのユーザーが含まれるグループ) にアタッチされるポリシーは、返された一時的な認証情報へのアクセス権限を提供します。このコード例のポリシーでは、Amazon S3 `ListBuckets` オペレーションをリクエストするアクセス許可をユーザーに付与しています。

次のサンプルコードは、`GetSessionToken` を使用する方法を説明しています。

------
#### [ CLI ]

**AWS CLI**  
**IAM ID のために短期間有効な認証情報のセットを取得するには**  
次の `get-session-token` コマンドは、呼び出しを実行する IAM ID のために短期間有効な認証情報のセットを取得します。結果として得られる認証情報は、ポリシーによって多要素認証 (MFA) が必要とされるリクエストのために使用できます。認証情報は生成されてから 15 分後に失効します。  

```
aws sts get-session-token \
    --duration-seconds 900 \
    --serial-number "YourMFADeviceSerialNumber" \
    --token-code 123456
```
出力:  

```
{
    "Credentials": {
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY",
        "SessionToken": "AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2020-05-19T18:06:10+00:00"
    }
}
```
詳細については、「*AWS IAM ユーザーガイド*」の「[一時的なセキュリティ認証情報のリクエスト](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_getsessiontoken)」を参照してください。  
+  API の詳細については、「*AWS CLI コマンドリファレンス*」の「[GetSessionToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-session-token.html)」を参照してください。

------
#### [ PowerShell ]

**Tools for PowerShell V4**  
**例 1: 一定期間有効な一時的な認証情報を含む `Amazon.RuntimeAWSCredentials` インスタンスを返します。一時的な認証情報をリクエストするために使用される認証情報は、現在のシェルのデフォルトから推測されます。他の認証情報を指定するには、-ProfileName または-AccessKey/-SecretKey パラメータを使用します。**  

```
Get-STSSessionToken
```
**出力:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**例 2: 1 時間有効な一時的な認証情報を含む `Amazon.RuntimeAWSCredentials` インスタンスを返します。リクエストを行うために使用される認証情報は、指定されたプロファイルから取得されます。**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile
```
**出力:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**例 3: プロファイル「myprofilename」で認証情報が指定されているアカウントに関連付けられた MFA デバイスの識別番号とデバイスから提供された値を使用して、1 時間有効な一時的な認証情報を含む `Amazon.RuntimeAWSCredentials` インスタンスを返します。**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile -SerialNumber YourMFADeviceSerialNumber -TokenCode 123456
```
**出力:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
+  API の詳細については、*AWS Tools for PowerShell コマンドレットリファレンス (V4)* の「[GetSessionToken](https://docs.aws.amazon.com/powershell/v4/reference)」を参照してください。

**Tools for PowerShell V5**  
**例 1: 一定期間有効な一時的な認証情報を含む `Amazon.RuntimeAWSCredentials` インスタンスを返します。一時的な認証情報をリクエストするために使用される認証情報は、現在のシェルのデフォルトから推測されます。他の認証情報を指定するには、-ProfileName または-AccessKey/-SecretKey パラメータを使用します。**  

```
Get-STSSessionToken
```
**出力:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**例 2: 1 時間有効な一時的な認証情報を含む `Amazon.RuntimeAWSCredentials` インスタンスを返します。リクエストを行うために使用される認証情報は、指定されたプロファイルから取得されます。**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile
```
**出力:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**例 3: プロファイル「myprofilename」で認証情報が指定されているアカウントに関連付けられた MFA デバイスの識別番号とデバイスから提供された値を使用して、1 時間有効な一時的な認証情報を含む `Amazon.RuntimeAWSCredentials` インスタンスを返します。**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile -SerialNumber YourMFADeviceSerialNumber -TokenCode 123456
```
**出力:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
+  API の詳細については、「*AWS Tools for PowerShell Cmdlet リファレンス (V5)*」の「[GetSessionToken](https://docs.aws.amazon.com/powershell/v5/reference)」を参照してください。

------
#### [ Python ]

**SDK for Python (Boto3)**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/sts#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。
MFA トークンを渡してセッショントークンを取得し、それを使用してアカウントの Amazon S3 バケットを一覧表示します。  

```
def list_buckets_with_session_token_with_mfa(mfa_serial_number, mfa_totp, sts_client):
    """
    Gets a session token with MFA credentials and uses the temporary session
    credentials to list Amazon S3 buckets.

    Requires an MFA device serial number and token.

    :param mfa_serial_number: The serial number of the MFA device. For a virtual MFA
                              device, this is an Amazon Resource Name (ARN).
    :param mfa_totp: A time-based, one-time password issued by the MFA device.
    :param sts_client: A Boto3 STS instance that has permission to assume the role.
    """
    if mfa_serial_number is not None:
        response = sts_client.get_session_token(
            SerialNumber=mfa_serial_number, TokenCode=mfa_totp
        )
    else:
        response = sts_client.get_session_token()
    temp_credentials = response["Credentials"]

    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )

    print(f"Buckets for the account:")
    for bucket in s3_resource.buckets.all():
        print(bucket.name)
```
+  API の詳細については、「AWS SDK for Python (Boto3) API リファレンス」の「[GetSessionToken](https://docs.aws.amazon.com/goto/boto3/sts-2011-06-15/GetSessionToken)」を参照してください。

------

## MFA 認証での AssumeRole の呼び出し
<a name="MFAProtectedAPI-example-assumerole"></a>

以下の例は、`AssumeRole` を呼び出し、MFA 認証情報を渡す方法を示しています。`AssumeRole` によって返される一時的セキュリティ認証情報は、アカウントのすべての Amazon S3 バケットを一覧表示するために使用されます。

このシナリオの詳細については、「[シナリオ: クロスアカウントの委任の MFA 保護](id_credentials_mfa_configure-api-require.md#MFAProtectedAPI-cross-account-delegation)」を参照してください。

次のサンプルコードは、`AssumeRole` を使用する方法を説明しています。

------
#### [ .NET ]

**SDK for .NET**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/STS#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
using System;
using System.Threading.Tasks;
using Amazon;
using Amazon.SecurityToken;
using Amazon.SecurityToken.Model;

namespace AssumeRoleExample
{
    class AssumeRole
    {
        /// <summary>
        /// This example shows how to use the AWS Security Token
        /// Service (AWS STS) to assume an IAM role.
        ///
        /// NOTE: It is important that the role that will be assumed has a
        /// trust relationship with the account that will assume the role.
        ///
        /// Before you run the example, you need to create the role you want to
        /// assume and have it trust the IAM account that will assume that role.
        ///
        /// See https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html
        /// for help in working with roles.
        /// </summary>

        // A region property may be used if the profile or credentials loaded do not specify a region,
        // or to use a specific region.
        private static readonly RegionEndpoint REGION = RegionEndpoint.USWest2;

        static async Task Main()
        {
            // Create the SecurityToken client and then display the identity of the
            // default user.
            var roleArnToAssume = "arn:aws:iam::123456789012:role/testAssumeRole";

            var client = new Amazon.SecurityToken.AmazonSecurityTokenServiceClient(REGION);

            // Get and display the information about the identity of the default user.
            var callerIdRequest = new GetCallerIdentityRequest();
            var caller = await client.GetCallerIdentityAsync(callerIdRequest);
            Console.WriteLine($"Original Caller: {caller.Arn}");

            // Create the request to use with the AssumeRoleAsync call.
            var assumeRoleReq = new AssumeRoleRequest()
            {
                DurationSeconds = 1600,
                RoleSessionName = "Session1",
                RoleArn = roleArnToAssume
            };

            var assumeRoleRes = await client.AssumeRoleAsync(assumeRoleReq);

            // Now create a new client based on the credentials of the caller assuming the role.
            var client2 = new AmazonSecurityTokenServiceClient(credentials: assumeRoleRes.Credentials, REGION);

            // Get and display information about the caller that has assumed the defined role.
            var caller2 = await client2.GetCallerIdentityAsync(callerIdRequest);
            Console.WriteLine($"AssumedRole Caller: {caller2.Arn}");
        }
    }
}
```
+  API の詳細については、AWS SDK for .NET API リファレンスの「[AssumeRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/sts-2011-06-15/AssumeRole)」を参照してください。**

------
#### [ Bash ]

**Bash スクリプトを使用した AWS CLI**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/aws-cli/bash-linux/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
###############################################################################
# function iecho
#
# This function enables the script to display the specified text only if
# the global variable $VERBOSE is set to true.
###############################################################################
function iecho() {
  if [[ $VERBOSE == true ]]; then
    echo "$@"
  fi
}

###############################################################################
# function errecho
#
# This function outputs everything sent to it to STDERR (standard error output).
###############################################################################
function errecho() {
  printf "%s\n" "$*" 1>&2
}

###############################################################################
# function sts_assume_role
#
# This function assumes a role in the AWS account and returns the temporary
#  credentials.
#
# Parameters:
#       -n role_session_name -- The name of the session.
#       -r role_arn -- The ARN of the role to assume.
#
# Returns:
#       [access_key_id, secret_access_key, session_token]
#     And:
#       0 - If successful.
#       1 - If an error occurred.
###############################################################################
function sts_assume_role() {
  local role_session_name role_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function sts_assume_role"
    echo "Assumes a role in the AWS account and returns the temporary credentials:"
    echo "  -n role_session_name -- The name of the session."
    echo "  -r role_arn -- The ARN of the role to assume."
    echo ""
  }

  while getopts n:r:h option; do
    case "${option}" in
      n) role_session_name=${OPTARG} ;;
      r) role_arn=${OPTARG} ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done

  response=$(aws sts assume-role \
    --role-session-name "$role_session_name" \
    --role-arn "$role_arn" \
    --output text \
    --query "Credentials.[AccessKeyId, SecretAccessKey, SessionToken]")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-role operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}
```
+  API の詳細については、「AWS CLI コマンドリファレンス」の「[AssumeRole](https://docs.aws.amazon.com/goto/aws-cli/sts-2011-06-15/AssumeRole)」を参照してください。

------
#### [ C\$1\$1 ]

**SDK for C\$1\$1**  
 GitHub には、その他のリソースもあります。用例一覧を検索し、[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp/example_code/sts#code-examples)での設定と実行の方法を確認してください。

```
bool AwsDoc::STS::assumeRole(const Aws::String &roleArn,
                             const Aws::String &roleSessionName,
                             const Aws::String &externalId,
                             Aws::Auth::AWSCredentials &credentials,
                             const Aws::Client::ClientConfiguration &clientConfig) {
    Aws::STS::STSClient sts(clientConfig);
    Aws::STS::Model::AssumeRoleRequest sts_req;

    sts_req.SetRoleArn(roleArn);
    sts_req.SetRoleSessionName(roleSessionName);
    sts_req.SetExternalId(externalId);

    const Aws::STS::Model::AssumeRoleOutcome outcome = sts.AssumeRole(sts_req);

    if (!outcome.IsSuccess()) {
        std::cerr << "Error assuming IAM role. " <<
                  outcome.GetError().GetMessage() << std::endl;
    }
    else {
        std::cout << "Credentials successfully retrieved." << std::endl;
        const Aws::STS::Model::AssumeRoleResult result = outcome.GetResult();
        const Aws::STS::Model::Credentials &temp_credentials = result.GetCredentials();

        // Store temporary credentials in return argument.
        // Note: The credentials object returned by assumeRole differs
        // from the AWSCredentials object used in most situations.
        credentials.SetAWSAccessKeyId(temp_credentials.GetAccessKeyId());
        credentials.SetAWSSecretKey(temp_credentials.GetSecretAccessKey());
        credentials.SetSessionToken(temp_credentials.GetSessionToken());
    }

    return outcome.IsSuccess();
}
```
+  API の詳細については、AWS SDK for C\$1\$1 API リファレンスの「[AssumeRole](https://docs.aws.amazon.com/goto/SdkForCpp/sts-2011-06-15/AssumeRole)」を参照してください。**

------
#### [ CLI ]

**AWS CLI**  
**ロールを引き受けるには**  
次の `assume-role` コマンドは、IAM ロール `s3-access-example` のために短期間有効な認証情報のセットを取得します。  

```
aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/xaccounts3access \
    --role-session-name s3-access-example
```
出力:  

```
{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:s3-access-example",
        "Arn": "arn:aws:sts::123456789012:assumed-role/xaccounts3access/s3-access-example"
    },
    "Credentials": {
        "SecretAccessKey": "9drTJvcXLB89EXAMPLELB8923FB892xMFI",
        "SessionToken": "AQoXdzELDDY//////////wEaoAK1wvxJY12r2IrDFT2IvAzTCn3zHoZ7YNtpiQLF0MqZye/qwjzP2iEXAMPLEbw/m3hsj8VBTkPORGvr9jM5sgP+w9IZWZnU+LWhmg+a5fDi2oTGUYcdg9uexQ4mtCHIHfi4citgqZTgco40Yqr4lIlo4V2b2Dyauk0eYFNebHtYlFVgAUj+7Indz3LU0aTWk1WKIjHmmMCIoTkyYp/k7kUG7moeEYKSitwQIi6Gjn+nyzM+PtoA3685ixzv0R7i5rjQi0YE0lf1oeie3bDiNHncmzosRM6SFiPzSvp6h/32xQuZsjcypmwsPSDtTPYcs0+YN/8BRi2/IcrxSpnWEXAMPLEXSDFTAQAM6Dl9zR0tXoybnlrZIwMLlMi1Kcgo5OytwU=",
        "Expiration": "2016-03-15T00:05:07Z",
        "AccessKeyId": "ASIAJEXAMPLEXEG2JICEA"
    }
}
```
コマンドの出力には、AWS に対する認証に使用できるアクセスキー、シークレットキー、およびセッショントークンが含まれています。  
AWS CLI を使用する場合は、ロールに関連付けられた名前付きプロファイルを設定できます。プロファイルを使用すると、AWS CLI は assume-role を呼び出し、ユーザーのために認証情報を管理します。詳細については、「*AWS CLI ユーザーガイド*」の「[AWS CLI で IAM ロールを使用する](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)」を参照してください。  
+  API の詳細については、「*AWS CLI コマンドリファレンス*」の「[AssumeRole](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)」を参照してください。

------
#### [ Java ]

**SDK for Java 2.x**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/sts#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.sts.StsClient;
import software.amazon.awssdk.services.sts.model.AssumeRoleRequest;
import software.amazon.awssdk.services.sts.model.StsException;
import software.amazon.awssdk.services.sts.model.AssumeRoleResponse;
import software.amazon.awssdk.services.sts.model.Credentials;
import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;
import java.util.Locale;

/**
 * To make this code example work, create a Role that you want to assume.
 * Then define a Trust Relationship in the AWS Console. You can use this as an
 * example:
 *
 * {
 * "Version":"2012-10-17",		 	 	 
 * "Statement": [
 * {
 * "Effect": "Allow",
 * "Principal": {
 * "AWS": "<Specify the ARN of your IAM user you are using in this code example>"
 * },
 * "Action": "sts:AssumeRole"
 * }
 * ]
 * }
 *
 * For more information, see "Editing the Trust Relationship for an Existing
 * Role" in the AWS Directory Service guide.
 *
 * Also, set up your development environment, including your credentials.
 *
 * For information, see this documentation topic:
 *
 * https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
 */
public class AssumeRole {
    public static void main(String[] args) {
        final String usage = """

                Usage:
                    <roleArn> <roleSessionName>\s

                Where:
                    roleArn - The Amazon Resource Name (ARN) of the role to assume (for example, arn:aws:iam::000008047983:role/s3role).\s
                    roleSessionName - An identifier for the assumed role session (for example, mysession).\s
                """;

        if (args.length != 2) {
            System.out.println(usage);
            System.exit(1);
        }

        String roleArn = args[0];
        String roleSessionName = args[1];
        Region region = Region.US_EAST_1;
        StsClient stsClient = StsClient.builder()
                .region(region)
                .build();

        assumeGivenRole(stsClient, roleArn, roleSessionName);
        stsClient.close();
    }

    public static void assumeGivenRole(StsClient stsClient, String roleArn, String roleSessionName) {
        try {
            AssumeRoleRequest roleRequest = AssumeRoleRequest.builder()
                    .roleArn(roleArn)
                    .roleSessionName(roleSessionName)
                    .build();

            AssumeRoleResponse roleResponse = stsClient.assumeRole(roleRequest);
            Credentials myCreds = roleResponse.credentials();

            // Display the time when the temp creds expire.
            Instant exTime = myCreds.expiration();
            String tokenInfo = myCreds.sessionToken();

            // Convert the Instant to readable date.
            DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.SHORT)
                    .withLocale(Locale.US)
                    .withZone(ZoneId.systemDefault());

            formatter.format(exTime);
            System.out.println("The token " + tokenInfo + "  expires on " + exTime);

        } catch (StsException e) {
            System.err.println(e.getMessage());
            System.exit(1);
        }
    }
}
```
+  API の詳細については、AWS SDK for Java 2.x API リファレンスの「[AssumeRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/sts-2011-06-15/AssumeRole)」を参照してください。**

------
#### [ JavaScript ]

**SDK for JavaScript (v3)**  
 GitHub には、その他のリソースもあります。用例一覧を検索し、[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3/example_code/sts#code-examples)での設定と実行の方法を確認してください。
クライアントを作成します。  

```
import { STSClient } from "@aws-sdk/client-sts";
// Set the AWS Region.
const REGION = "us-east-1";
// Create an AWS STS service client object.
export const client = new STSClient({ region: REGION });
```
IAM ロールを割り当てます。  

```
import { AssumeRoleCommand } from "@aws-sdk/client-sts";

import { client } from "../libs/client.js";

export const main = async () => {
  try {
    // Returns a set of temporary security credentials that you can use to
    // access Amazon Web Services resources that you might not normally
    // have access to.
    const command = new AssumeRoleCommand({
      // The Amazon Resource Name (ARN) of the role to assume.
      RoleArn: "ROLE_ARN",
      // An identifier for the assumed role session.
      RoleSessionName: "session1",
      // The duration, in seconds, of the role session. The value specified
      // can range from 900 seconds (15 minutes) up to the maximum session
      // duration set for the role.
      DurationSeconds: 900,
    });
    const response = await client.send(command);
    console.log(response);
  } catch (err) {
    console.error(err);
  }
};
```
+  API の詳細については、「*AWS SDK for JavaScript API リファレンス*」の「[AssumeRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/sts/command/AssumeRoleCommand)」を参照してください。

**SDK for JavaScript (v2)**  
 GitHub には、その他のリソースもあります。用例一覧を検索し、[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascript/example_code/sts#code-examples)での設定と実行の方法を確認してください。

```
// Load the AWS SDK for Node.js
const AWS = require("aws-sdk");
// Set the region
AWS.config.update({ region: "REGION" });

var roleToAssume = {
  RoleArn: "arn:aws:iam::123456789012:role/RoleName",
  RoleSessionName: "session1",
  DurationSeconds: 900,
};
var roleCreds;

// Create the STS service object
var sts = new AWS.STS({ apiVersion: "2011-06-15" });

//Assume Role
sts.assumeRole(roleToAssume, function (err, data) {
  if (err) console.log(err, err.stack);
  else {
    roleCreds = {
      accessKeyId: data.Credentials.AccessKeyId,
      secretAccessKey: data.Credentials.SecretAccessKey,
      sessionToken: data.Credentials.SessionToken,
    };
    stsGetCallerIdentity(roleCreds);
  }
});

//Get Arn of current identity
function stsGetCallerIdentity(creds) {
  var stsParams = { credentials: creds };
  // Create STS service object
  var sts = new AWS.STS(stsParams);

  sts.getCallerIdentity({}, function (err, data) {
    if (err) {
      console.log(err, err.stack);
    } else {
      console.log(data.Arn);
    }
  });
}
```
+  API の詳細については、AWS SDK for JavaScript API リファレンスの「[AssumeRole](https://docs.aws.amazon.com/goto/AWSJavaScriptSDK/sts-2011-06-15/AssumeRole)」を参照してください。**

------
#### [ PowerShell ]

**Tools for PowerShell V4**  
**例 1: 一時的な認証情報一式 (アクセスキー、シークレットキー、セッショントークン) を返します。この認証情報は、リクエストしたユーザーが通常はアクセスできない AWS リソースに 1 時間アクセスするために使用できます。返される認証情報には、引き受けているロールのアクセスポリシーと提供されたポリシーで許可されている権限があります (提供されたポリシーを使用して、引き受けているロールのアクセスポリシーで定義されている権限を超える権限を付与することはできません)。**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -Policy "...JSON policy..." -DurationInSeconds 3600
```
**例 2: 引き受けているロールのアクセスポリシーで定義されているのと同じ権限を持つ、1 時間有効の一時的な認証情報を返します。**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600
```
**例 3: コマンドレットの実行に使用されるユーザー認証情報に関連付けられている MFA からシリアル番号と生成されたトークンを提供する一時的な認証情報一式を返します。**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -SerialNumber "GAHT12345678" -TokenCode "123456"
```
**例 4: 顧客アカウントで定義されているロールを引き受けた一時的な認証情報一式を返します。第三者が引き受けることができるロールごとに、顧客アカウントは、ロールを引き受けるたび、-ExternalId パラメータで渡す必要がある識別子を使用してロールを作成する必要があります。**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -ExternalId "ABC123"
```
+  API の詳細については、*AWS Tools for PowerShell コマンドレットリファレンス (V4)* の「[AssumeRole](https://docs.aws.amazon.com/powershell/v4/reference)」を参照してください。

**Tools for PowerShell V5**  
**例 1: 一時的な認証情報一式 (アクセスキー、シークレットキー、セッショントークン) を返します。この認証情報は、リクエストしたユーザーが通常はアクセスできない AWS リソースに 1 時間アクセスするために使用できます。返される認証情報には、引き受けているロールのアクセスポリシーと提供されたポリシーで許可されている権限があります (提供されたポリシーを使用して、引き受けているロールのアクセスポリシーで定義されている権限を超える権限を付与することはできません)。**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -Policy "...JSON policy..." -DurationInSeconds 3600
```
**例 2: 引き受けているロールのアクセスポリシーで定義されているのと同じ権限を持つ、1 時間有効の一時的な認証情報を返します。**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600
```
**例 3: コマンドレットの実行に使用されるユーザー認証情報に関連付けられている MFA からシリアル番号と生成されたトークンを提供する一時的な認証情報一式を返します。**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -SerialNumber "GAHT12345678" -TokenCode "123456"
```
**例 4: 顧客アカウントで定義されているロールを引き受けた一時的な認証情報一式を返します。第三者が引き受けることができるロールごとに、顧客アカウントは、ロールを引き受けるたび、-ExternalId パラメータで渡す必要がある識別子を使用してロールを作成する必要があります。**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -ExternalId "ABC123"
```
+  API の詳細については、「*AWS Tools for PowerShell Cmdlet リファレンス (V5)*」の「[AssumeRole](https://docs.aws.amazon.com/powershell/v5/reference)」を参照してください。

------
#### [ Python ]

**SDK for Python (Boto3)**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/sts#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。
MFA トークンを必要とする IAM ロールを想定し、一時的な認証情報を使用してアカウントの Amazon S3 バケットを一覧表示します。  

```
def list_buckets_from_assumed_role_with_mfa(
    assume_role_arn, session_name, mfa_serial_number, mfa_totp, sts_client
):
    """
    Assumes a role from another account and uses the temporary credentials from
    that role to list the Amazon S3 buckets that are owned by the other account.
    Requires an MFA device serial number and token.

    The assumed role must grant permission to list the buckets in the other account.

    :param assume_role_arn: The Amazon Resource Name (ARN) of the role that
                            grants access to list the other account's buckets.
    :param session_name: The name of the STS session.
    :param mfa_serial_number: The serial number of the MFA device. For a virtual MFA
                              device, this is an ARN.
    :param mfa_totp: A time-based, one-time password issued by the MFA device.
    :param sts_client: A Boto3 STS instance that has permission to assume the role.
    """
    response = sts_client.assume_role(
        RoleArn=assume_role_arn,
        RoleSessionName=session_name,
        SerialNumber=mfa_serial_number,
        TokenCode=mfa_totp,
    )
    temp_credentials = response["Credentials"]
    print(f"Assumed role {assume_role_arn} and got temporary credentials.")

    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )

    print(f"Listing buckets for the assumed role's account:")
    for bucket in s3_resource.buckets.all():
        print(bucket.name)
```
+  API の詳細については、「*AWS SDK for Python (Boto3) API リファレンス*」の「[AssumeRole](https://docs.aws.amazon.com/goto/boto3/sts-2011-06-15/AssumeRole)」を参照してください。

------
#### [ Ruby ]

**SDK for Ruby**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby/example_code/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
  # Creates an AWS Security Token Service (AWS STS) client with specified credentials.
  # This is separated into a factory function so that it can be mocked for unit testing.
  #
  # @param key_id [String] The ID of the access key used by the STS client.
  # @param key_secret [String] The secret part of the access key used by the STS client.
  def create_sts_client(key_id, key_secret)
    Aws::STS::Client.new(access_key_id: key_id, secret_access_key: key_secret)
  end

  # Gets temporary credentials that can be used to assume a role.
  #
  # @param role_arn [String] The ARN of the role that is assumed when these credentials
  #                          are used.
  # @param sts_client [AWS::STS::Client] An AWS STS client.
  # @return [Aws::AssumeRoleCredentials] The credentials that can be used to assume the role.
  def assume_role(role_arn, sts_client)
    credentials = Aws::AssumeRoleCredentials.new(
      client: sts_client,
      role_arn: role_arn,
      role_session_name: 'create-use-assume-role-scenario'
    )
    @logger.info("Assumed role '#{role_arn}', got temporary credentials.")
    credentials
  end
```
+  API の詳細については、AWS SDK for Ruby API リファレンスの「[AssumeRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/sts-2011-06-15/AssumeRole)」を参照してください。**

------
#### [ Rust ]

**SDK for Rust**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/sts/#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
async fn assume_role(config: &SdkConfig, role_name: String, session_name: Option<String>) {
    let provider = aws_config::sts::AssumeRoleProvider::builder(role_name)
        .session_name(session_name.unwrap_or("rust_sdk_example_session".into()))
        .configure(config)
        .build()
        .await;

    let local_config = aws_config::from_env()
        .credentials_provider(provider)
        .load()
        .await;
    let client = Client::new(&local_config);
    let req = client.get_caller_identity();
    let resp = req.send().await;
    match resp {
        Ok(e) => {
            println!("UserID :               {}", e.user_id().unwrap_or_default());
            println!("Account:               {}", e.account().unwrap_or_default());
            println!("Arn    :               {}", e.arn().unwrap_or_default());
        }
        Err(e) => println!("{:?}", e),
    }
}
```
+  API の詳細については、「AWS SDK for Rust API リファレンス」の「[AssumeRole](https://docs.rs/aws-sdk-sts/latest/aws_sdk_sts/client/struct.Client.html#method.assume_role)」を参照してください。

------
#### [ Swift ]

**SDK for Swift**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift/example_code/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
import AWSSTS

    public func assumeRole(role: IAMClientTypes.Role, sessionName: String)
        async throws -> STSClientTypes.Credentials
    {
        let input = AssumeRoleInput(
            roleArn: role.arn,
            roleSessionName: sessionName
        )
        do {
            let output = try await stsClient.assumeRole(input: input)

            guard let credentials = output.credentials else {
                throw ServiceHandlerError.authError
            }

            return credentials
        } catch {
            print("Error assuming role: ", dump(error))
            throw error
        }
    }
```
+  API の詳細については、「AWS SDK for Swift API リファレンス」の「[AssumeRole](https://sdk.amazonaws.com/swift/api/awssts/latest/documentation/awssts/stsclient/assumerole(input:))」を参照してください。

------

# IAM ユーザーのサービス固有の認証情報
<a name="id_credentials_service-specific-creds"></a>

サービス固有の認証情報は、特定のAWS サービス用に設計された特殊な認証メカニズムです。これらの認証情報は、標準のAWS 認証情報と比較して認証が簡素化されており、個々のAWS サービスの認証要件に合わせて調整されます。複数のAWS サービスで使用できるアクセスキーとは異なり、サービス固有の認証情報は、作成されたサービスでのみ使用するように設計されています。このターゲットを絞ったアプローチにより、認証情報の適用範囲を制限することでセキュリティを強化します。

サービス固有の認証情報は通常、特定のサービスの要件に従ってフォーマットされたユーザー名とパスワードのペアまたは特殊な API キーで構成されます。サービス固有の認証情報を作成すると、デフォルトでアクティブになるため直ぐに使用できます。サポート対象の各サービスでは、IAM ユーザーごとにサービス固有の認証情報を最大 2 セット設定できます。この制限により、必要に応じて新しいセットにローテーションしながら、1 つのアクティブなセットを維持できます。 AWS は現在、次のサービスのサービス固有の認証情報をサポートしています。

## サービス固有の認証情報を使用するタイミング
<a name="id_credentials_service-specific-creds-usecase"></a>

サービス固有の認証情報は、AWS 認証情報、AWS SDK、または AWS API とネイティブに互換性のないサードパーティーのライブラリ、SDK、ツール、またはアプリケーションとの互換性を目的としています。このようなユースケースには、セルフホストインフラストラクチャまたは他のプロバイダーがホストするサービスからの AWS サービスへの移行が含まれます。

一から始める場合、および可能な限り、IAM ロールによって提供される認証情報などの AWS 一時的認証情報を使用し、AWS SDK または一時的認証情報をサポートする AWS ライブラリを使用して AWS サービスで認証することをお勧めします。

## サービス固有の認証情報のローテーション
<a name="id_credentials_service-specific-creds-rotation"></a>

セキュリティのベストプラクティスとして、サービス固有の認証情報を定期的にローテーションします。アプリケーションを中断せずに認証情報を更新するには：

1. 同じサービスと IAM ユーザーに対して、サービス固有の認証情報の 2 番目のセットを作成する

1. すべてのアプリケーションを更新して、新しい認証情報で正しく動作することを確認します。

1. 元の認証情報の状態を「非アクティブ」に変更します。

1. すべてのアプリケーションが正常に機能していることを確認します。

1. 非アクティブなサービス固有の認証情報を、不要であることを確認したら削除します。

## サービス固有の認証情報のモニタリング
<a name="id_credentials_service-specific-creds-monitoring"></a>

AWS CloudTrail を使用して、AWS アカウント内のサービス固有の認証情報の使用をモニタリングできます。サービス固有の認証情報の使用に関連する CloudTrail イベントを表示するには、認証情報が使用されるサービスからのイベントの CloudTrail ログを確認します。詳細については、「[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)」を参照してください。

セキュリティを強化するには、不正アクセスやその他のセキュリティ上の懸念を示す可能性のある特定の認証情報の使用パターンを通知するように CloudWatch アラームを設定することを検討してください。詳細については、「*AWS CloudTrail ユーザーガイド*」の「[Amazon CloudWatch Logs による CloudTrail ログファイルのモニタリング](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)」を参照してください。

以下のトピックでは、サービス固有の認証情報について説明します。

**Topics**
+ [

## サービス固有の認証情報を使用するタイミング
](#id_credentials_service-specific-creds-usecase)
+ [

## サービス固有の認証情報のローテーション
](#id_credentials_service-specific-creds-rotation)
+ [

## サービス固有の認証情報のモニタリング
](#id_credentials_service-specific-creds-monitoring)
+ [

# Amazon Bedrock と Amazon CloudWatch Logs の API キー
](id_credentials_bedrock_cloudwatchlogs.md)
+ [

# Amazon Keyspaces で IAM を使用する（Apache Cassandra の場合）
](id_credentials_keyspaces.md)

# Amazon Bedrock と Amazon CloudWatch Logs の API キー
<a name="id_credentials_bedrock_cloudwatchlogs"></a>

**注記**  
Amazon CloudWatch Logs API キーは現在プレビューで提供されていて、今後数週間で一般公開される予定です。Amazon CloudWatch Logs API キーは、このページで説明されている Amazon Bedrock 長期 API キーとよく似ています。Amazon CloudWatch Logs 長期 API キーの詳細については、「[Sending logs to Amazon CloudWatch Logs using HLC endpoint](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_HLC_Endpoint.html)」を参照してください。

Amazon Bedrock は、主要な AI 企業と Amazon の基盤モデルを提供するフルマネージドサービスです。Amazon Bedrock には、AWS マネジメントコンソール を通じてアクセスできるほか、AWS CLI や AWS APIを使えばプログラムからもアクセスできます。Amazon Bedrock にプログラムからリクエストする場合は、[一時的なセキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html)または Amazon Bedrock の API キーを使用して認証できます。Amazon Bedrock は、次の 2 種類の API キーをサポートしています。
+ **短期 API キー** – 短期 API キーは、AWS 署名バージョン 4 を使用する署名付き URL です。短期 API キーは、API キーを生成する ID の認証情報と同じアクセス許可と有効期限を共有し、最大 12 時間またはコンソールセッションの残り時間の短い方の時間まで有効です。Amazon Bedrock コンソール、Python パッケージ `aws-bedrock-token-generator`、および他のプログラミング言語用のパッケージを使用して、短期 API キーを生成できます。詳細については、「*Amazon Bedrock ユーザーガイド*」の「[Generate Amazon Bedrock API keys for easy access to the Amazon Bedrock API](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html)」を参照してください。
+ **長期 API キー** – 長期 API キーは IAM ユーザーに関連付けられ、IAM [サービス固有の認証情報](id_credentials_service-specific-creds.md)を使用して生成されます。これらの認証情報は Amazon Bedrock でのみ使用するように設計されており、認証情報の適用範囲を制限することでセキュリティを強化しています。長期 API キーの有効期限を設定できます。IAM または Amazon Bedrock コンソール、AWS CLI、AWS API を使用して、長期 API キーを生成できます。

IAM ユーザーは、Amazon Bedrock 用に最大 2 つの長期 API キーを持つことができ、安全なキーローテーションプラクティスを実装するのに役立ちます。

長期 API キーを生成すると、AWS 管理ポリシー [AmazonBedrockLimitedAccess](https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonBedrockLimitedAccess) が IAM ユーザーに自動的にアタッチされます。このポリシーは、コア Amazon Bedrock API オペレーションへのアクセスを許可します。追加の Amazon Bedrock アクセスが必要な場合は、IAM ユーザーのアクセス許可を変更できます。許可の変更については、「[IAM ID のアクセス許可の追加および削除](access_policies_manage-attach-detach.md)」を参照してください。Amazon Bedrock キーの使用方法の詳細については、「Amazon Bedrock ユーザーガイド」の「[Amazon Bedrock API キーを使用する](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-use.html)」を参照してください。

**注記**  
長期 API キーは、短期 API キーと比較してセキュリティリスクが高くなります。可能であれば、短期 API キーまたは一時的なセキュリティ認証情報を使用することをお勧めします。長期 API キーを使用する場合は、定期的なキーローテーションプラクティスを実施することをお勧めします。

## 前提条件
<a name="id_credentials_bedrock_prerequisites"></a>

IAM コンソールで Amazon Bedrock 長期 API キーを生成する前に、次の前提条件を満たす必要があります。
+ 長期 API キーに関連付ける IAM ユーザー。IAM ユーザーの作成手順については、「[AWS アカウント で IAM ユーザーを作成する](id_users_create.md)」を参照してください。
+ IAM ユーザーのサービス固有の認証情報を管理するには、次の IAM ポリシーのアクセス許可があることを確認してください。このポリシー例では、サービス固有の認証情報を作成、一覧表示、更新、削除、およびリセットするアクセス許可を付与します。Resource の要素の `username` 値を、Amazon Bedrock API キーを生成する IAM ユーザーの名前に置き換えます。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "ManageBedrockServiceSpecificCredentials",
              "Effect": "Allow",
              "Action": [
                  "iam:CreateServiceSpecificCredential",
                  "iam:ListServiceSpecificCredentials",
                  "iam:UpdateServiceSpecificCredential",
                  "iam:DeleteServiceSpecificCredential",
                  "iam:ResetServiceSpecificCredential"
              ],
              "Resource": "arn:aws:iam::*:user/username"
          }
      ]
  }
  ```

------

## Amazon Bedrock の長期 API キーの生成 (コンソール)
<a name="id_credentials_bedrock_console_create"></a>

**Amazon Bedrock 長期 API キーを生成するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. IAM コンソールのナビゲーションペインで **[ユーザー]** を選択します。

1. IAM ユーザーを選択して、Amazon Bedrock の長期 API キーを生成します。

1. **[セキュリティ認証情報]** タブを選択します。

1. **[Amazon Bedrock の API キー]** セクションで、**[API キーの生成]** を選択します。

1. **API キーの有効期限**について、以下のいずれかを実行します。
   + API キーの有効期限として **1**、**5**、**30**、**90**、または **365** 日を選択します。
   + **カスタム期間**を選択して、カスタム API キーの有効期限を指定します。
   + **[有効期限なし]** (非推奨) を選択します。

1. **[API キーの生成]** を選択します。

1. API キーをコピーまたはダウンロードします。API キー値を表示できるのは今回だけです。
**重要**  
API キーを安全に保存してください。ダイアログボックスを閉じた後は、API キーを再度取得することはできません。シークレットアクセスキーがわからないまたは忘れた場合、取得することはできません。代わりに、新しいアクセスキーを作成し、古いキーを非アクティブにします。

## Amazon Bedrock の長期 API キーの生成 (AWS CLI）
<a name="id_credentials_bedrock_cli_create"></a>

AWS CLI を使用して Amazon Bedrock 長期 API キーを生成するには、次の手順を実行します。

1. [create-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-user.html) コマンドを使用して、Amazon Bedrock を使用するために必要な IAM ユーザーを作成します。

   ```
   aws iam create-user \
       --user-name BedrockAPIKey_1
   ```

1. [ attach-user-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-user-policy.html) コマンドを使用して、AWS 管理ポリシー `AmazonBedrockLimitedAccess` を Amazon Bedrock IAM ユーザーにアタッチします。

   ```
   aws iam attach-user-policy --user-name BedrockAPIKey_1 \
       --policy-arn arn:aws:iam::aws:policy/AmazonBedrockLimitedAccess
   ```

1. [ create-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-service-specific-credential.html) コマンドを使用して、Amazon Bedrock の長期 API キーを生成します。認証情報の有効期間には、1～36600 日の値を指定できます。認証情報の有効期間を指定しないと、API キーは期限切れになりません。

   有効期限が 30 日の長期 API キーを生成するには:

   ```
   aws iam create-service-specific-credential \
       --user-name BedrockAPIKey_1 \
       --service-name bedrock.amazonaws.com \
       --credential-age-days 30
   ```

レスポンスで返される `ServiceApiKeyValue` が、Amazon Bedrock の 長期 API キーです。`ServiceApiKeyValue` 値は後で取得できないため、安全に保管してください。

### 長期 API キーを一覧表示する (AWS CLI）
<a name="id_credentials_bedrock_cli_list"></a>

特定のユーザーの Amazon Bedrock 長期 API キーメタデータを一覧表示するには、[list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html) コマンドと `--user-name` パラメータを使用します。

```
aws iam list-service-specific-credentials \
    --service-name bedrock.amazonaws.com \
    --user-name BedrockAPIKey_1
```

アカウント内のすべての Amazon Bedrock 長期 API キーメタデータを一覧表示するには、[list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html) コマンドと `--all-users`パラメータを使用します。

```
aws iam list-service-specific-credentials \
    --service-name bedrock.amazonaws.com \
    --all-users
```

### 長期 API キーステータスを更新する (AWS CLI）
<a name="id_credentials_bedrock_cli_update"></a>

Amazon Bedrock の長期 API キーのステータスを更新するには、[update-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/update-service-specific-credential.html) コマンドを使用します。

```
aws iam update-service-specific-credential \
    --user-name "BedrockAPIKey_1" \
    --service-specific-credential-id "ACCA1234EXAMPLE1234" \
    --status Inactive|Active
```

## Amazon Bedrock の長期 API キーの生成 (AWS API)
<a name="id_credentials_bedrock_api"></a>

次の API オペレーションを使用して、Amazon Bedrock の長期 API キーを生成および管理できます。
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html) 

# Amazon Keyspaces で IAM を使用する（Apache Cassandra の場合）
<a name="id_credentials_keyspaces"></a>

Amazon Keyspaces (Apache Cassandra 用) は、スケーラブルで可用性の高い、Apache Cassandra 互換のマネージドデータベースサービスです。AWS マネジメントコンソール を通じてかプログラムにより、Amazon Keyspaces にアクセスできます。サービス固有の認証情報を使用して Amazon Keyspaces にプログラムでアクセスするには、`cqlsh` またはオープンソースの Cassandra ドライバーを使用できます。サービス固有の認証情報は、Cassandra が認証とアクセス管理に使用するようなユーザー名とパスワードを含みます。サポート対象の各サービスでは、ユーザーごとにサービス固有の認証情報を最大 2 セット設定できます。

AWS アクセスキーを使用して Amazon Keyspaces にプログラムでアクセスするには、AWS SDK や AWS Command Line Interface (AWS CLI) またはオープンソースの Cassandra ドライバーと SigV4 プラグインを使用できます。詳細については、「Amazon Keyspaces (Apache Cassandra 向け) 開発者ガイド」の「[Amazon Keyspaces の AWS の認証情報の作成と設定](https://docs.aws.amazon.com//keyspaces/latest/devguide/access.credentials.html)」を参照してください。

**注記**  
コンソール経由で Amazon Keyspaces とやり取りする予定がある場合、サービス固有の認証情報を生成する必要はありません。詳細については、「Amazon Keyspaces (Apache Cassandra 向け) 開発者ガイド」の「[コンソールを使用した Amazon Keyspaces へのアクセス](https://docs.aws.amazon.com/keyspaces/latest/devguide/console_keyspaces.html)」を参照してください。

Amazon Keyspaces にアクセスするために必要な権限の詳細については、 『[Amazon Keyspaces (Apache Cassandra 用）開発者ガイド](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-console)』の「*Amazon キースペース (Apache Cassandraの場合) ID ベースのポリシーの例*」を参照してください。

## Amazon Keyspaces 認証情報の生成 (コンソール)
<a name="keyspaces_credentials_console"></a>

AWS マネジメントコンソール を使用して、IAM ユーザー用の Amazon Keyspaces (Apache Cassandra 用) 認証情報を生成できます。

**Amazon Keyspaces サービス固有の認証情報を生成するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで、[**ユーザー**] を選択し、認証情報を必要とするユーザーの名前を選択します。

1. [**セキュリティ認証情報**] タブにある [**Amazon Keyspaces (Apache Cassandra 用) の認証情報**] で、[**認証情報を生成する**] を選択します。

1. これで、サービス固有の認証情報が利用可能になりました。パスワードを表示またはダウンロードできるのはこのときだけです。後で回復することはできません。ただし、パスワードはいつでもリセットできます。ユーザーおよびパスワードは後で必要になるため、安全な場所に保存します。

## Amazon Keyspaces 認証情報の生成（AWS CLI)
<a name="keyspaces_credentials_cli"></a>

AWS CLI を使用して、IAM ユーザー用の Amazon Keyspaces (Apache Cassandra 用) 認証情報を生成できます。

**Amazon Keyspaces サービス固有の認証情報を生成するには (AWS CLI)**
+ 以下のコマンドを使用します。
  + [aws iam create-service-specific-credential](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-specific-credential.html)

## Amazon Keyspaces 認証情報の生成（AWS API)
<a name="keyspaces_credentials_api"></a>

AWS API を使用して、IAM ユーザー用の Amazon Keyspaces (Apache Cassandra 用) 認証情報を生成できます。

**Amazon Keyspaces サービス固有の認証情報を生成するには (AWS API)**
+ 以下のオペレーションを実行します。
  + [CreateServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html) 

# 使用していない AWS 認証情報の検索
<a name="id_credentials_finding-unused"></a>

AWS アカウント のセキュリティを高めるには、不要な IAM ユーザー認証 (パスワードおよびアクセスキー) を削除します。たとえば、ユーザーが組織を離れる際、または今後 AWS へのアクセスが不要な場合には、使用されていた認証情報を検索し、それらが無効になっていることを確認する必要があります。必要のなくなった認証情報は削除することが理想的です。それらは必要に応じて、後日いつでも再作成できます。少なくとも、パスワードを変更するか、アクセスキーを無効にして、以前のユーザーがアクセスできないようにする必要があります。

もちろん、*使用していない*の定義は異なる可能性がありますが、通常は特定の期間内に使用されなかった認証情報を指します。

## 使用していないパスワードの検索
<a name="finding-unused-passwords"></a>

AWS マネジメントコンソール を使用して、ユーザーのパスワード使用状況情報を表示できます。多数のユーザーがいる場合は、コンソールを使用して、ユーザーごとのコンソールパスワードの最終使用日時に関する情報を含む認証情報レポートをダウンロードできます。また、AWS CLI または IAM API から情報にアクセスすることも可能です。

**未使用のパスワードを検索するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. 必要に応じて、[**Console last sign-in (コンソールへの前回サインイン)**] 列を USERS テーブルに追加します。

   1. 右端のテーブルの上で、設定アイコン (![\[Settings icon\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/console-settings-icon.console.png)) を選択します。

   1. **[表示する列の選択]** で、**[コンソールの最終サインイン]** を選択します。

   1. **[確認]** を選択して、ユーザーのリストに戻ります。

1. [**Console last sign-in**] (コンソールへの最終サインイン) 列に、ユーザーがコンソールを通じて AWS に最後にサインインした日付が表示されます。この情報を使用して、特定の期間以上サインインしていないユーザーとパスワードを検索できます。この列には、一度もサインインしていないユーザーとパスワードに、[**なし**] と表示されます。[**なし**] は、パスワードが設定されていないユーザーを表します。最近使用されていないパスワードは削除の対象となります。
**重要**  
サービス上の問題により、前回使用したパスワードに関するデータには、2018 年 5 月 3 日 22 時 50 分 (太平洋夏時間) から 2018 年 5 月 23 日 14 時 08 分 (太平洋夏時間) までのパスワードの使用は含まれません。これは、IAM コンソールに表示される[前回サインイン](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html)した日付および [IAM 認証情報レポート](https://docs.aws.amazon.com/IAM/latest/UserGuide/SupportedTypes.xmlid_credentials_getting-report.html)でパスワードを前回使用した日付として [GetUser API オペレーション](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)から返される日付に影響を与えます。該当する期間中にユーザーがサインインした場合、パスワードを前回使用した日付として返される日付は、2018 年 5 月 3 日より前にユーザーが最後にサインインした日付になります。2018 年 5 月 23 日 14 時 08 分 (太平洋夏時間) より後にサインインしたユーザーの場合、パスワードを前回使用した日付として返される日付は正確です。  
前回使用したパスワードに関する情報を使用して未使用の認証情報を特定して削除する (例: 過去 90 日間に AWS にサインインしなかったユーザーを削除する) 場合は、2018 年 5 月 23 日より後の日付を含めるように評価ウィンドウを調整してください。または、ユーザーがアクセスキーを使用して AWS にプログラムでアクセスする場合は、前回使用したアクセスキーの情報を参照できます。これはすべての日付について正確であるためです。

**コンソールで認証情報レポートをダウンロードして、使用されていないパスワードを検索するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで、[**認証情報レポート**] を選択します。

1. [**レポートをダウンロード**] を選択して、`status_reports_<date>T<time>.csv` という名前のカンマ区切り値 (CSV) のファイルをダウンロードします。5 番目の列には、日付または以下のいずれか 1 つを含む `password_last_used` 列が表示されます。
   + **該当なし** – 割り当てられているパスワードが 1 つもないユーザー。
   + [**no\$1information (情報なし)**] – IAM パスワードの有効期間の追跡を開始した 2014 年 10 月 20 日以降にパスワードを使用していないユーザー。

**未使用のパスワードを見つけるには (AWS CLI)**  
未使用のパスワードを見つけるには、次のコマンドを実行します。
+ `[aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)` は、ユーザーのリストを返します。各ユーザーには、`PasswordLastUsed` 値が設定されています。値がない場合は、ユーザーがパスワードを持っていないか、IAM がパスワードの有効期限の追跡を開始した 2014 年 10 月 20 日以降にパスワードが使用されていないことを示します。

**未使用のパスワードを見つけるには (AWS API)**  
未使用のパスワードを見つけるには、次のオペレーションを呼び出します。
+  ` [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)` は、ユーザーのコレクションを返します。各ユーザーには、`<PasswordLastUsed>` 値が設定されています。値がない場合は、ユーザーがパスワードを持っていないか、IAM がパスワードの古さの追跡を開始した 2014 年 10 月 20 日以降にパスワードが使用されていないことを示します。

認証情報レポートをダウンロードするためのコマンドについては、「[認証情報レポートの取得 (AWS CLI)](id_credentials_getting-report.md#getting-credential-reports-cliapi)」を参照してください。

## 使用していないアクセスキーの検索
<a name="finding-unused-access-keys"></a>

AWS マネジメントコンソール を使用して、ユーザーのアクセスキーの使用状況に関する情報を表示できます。多数のユーザーがいる場合は、コンソールを使用して認証情報レポートをダウンロードし、ユーザーごとのアクセスキーの最終使用日時を検索できます。また、AWS CLI または IAM API から情報にアクセスすることも可能です。

**使用していないアクセスキーを検索するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで [**Users (ユーザー)**] を選択します。

1. 必要に応じて、[**Access key last used (アクセスキー前回使用)**] 列をユーザーテーブルに追加します。

   1. 右端のテーブルの上で、設定アイコン (![\[Settings icon\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/console-settings-icon.console.png)) を選択します。

   1. **[表示する列の選択]** で、**[最後に使用したアクセスキー]** を選択します。

   1. **[確認]** を選択して、ユーザーのリストに戻ります。

1. [**Access key last used (アクセスキー前回使用)**] 列には、ユーザーがプログラムで最後に AWS にアクセスしてから経過した日数が表示されます。この情報を使用して、指定の期間以上使用されていないアクセスキーを持つユーザーを検索できます。この列のアクセスキーのないユーザーに、**[–]** と表示されます。最近使用されていないアクセスキーは削除の対象となります。

**認証情報レポートをダウンロードして、使用していないアクセスキーを検索するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで、[**認証情報レポート**] を選択します。

1. [**レポートをダウンロード**] を選択して、`status_reports_<date>T<time>.csv` という名前のカンマ区切り値 (CSV) のファイルをダウンロードします。列 11 ～ 13 にはアクセスキー 1 を最後に使用した日付、アクセスキーのリージョン、およびサービス情報が含まれます。列 16 ～ 18 にはアクセスキー 2 の同様の情報が含まれます。ユーザーがアクセスキーを持っていないか、IAM がアクセスキーの有効期限の追跡を開始した 2015 年 4 月 22 日以降にアクセスキーが使用されていない場合、値 [**該当なし**] が表示されます。

**未使用のアクセスキーを見つけるには (AWS CLI)**  
以下のコマンドを使用して、未使用のアクセスキーを見つけることができます。
+ `[aws iam list-access-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)` は `AccessKeyID` を含む、ユーザーのアクセスキーに関する情報を返します。
+ `[aws iam get-access-key-last-used](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)` はアクセスキー ID を使用して、`LastUsedDate`、アクセスキーを最後に使用した `Region`、最後に要求されたサービスの `ServiceName` を含む出力を返します。`LastUsedDate` が見つからない場合、IAM がアクセスキーの有効期限の追跡を開始した 2015 年 4 月 22 日以降にアクセスキーは使用されていません。

**未使用のアクセスキーを見つけるには (AWS API)**  
未使用のアクセスキーを見つけるには、以下のオペレーションを呼び出します。
+ `[ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html)` は指定したユーザーに関連付けられたアクセスキーの `AccessKeyID` 値のリストを返します。
+ `[GetAccessKeyLastUsed](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)` はアクセスキー ID を使用して、値のコレクションを返します。これには、`LastUsedDate`、アクセスキーを最後に使用した `Region`、最後に要求されたサービスの `ServiceName` が含まれています。値が見つからない場合、ユーザーがアクセスキーを持っていないか、IAM がアクセスキーの古さの追跡を開始した 2015 年 4 月 22 日以降にアクセスキーが使用されていないことを示します。

認証情報レポートをダウンロードするためのコマンドについては、「[認証情報レポートの取得 (AWS CLI)](id_credentials_getting-report.md#getting-credential-reports-cliapi)」を参照してください。

# AWS アカウント の認証情報レポートを生成します。
<a name="id_credentials_getting-report"></a>

アカウントのすべてのユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された*認証情報レポート*を生成し、ダウンロードできます。認証情報レポートは、AWS マネジメントコンソール、[AWS SDK](https://aws.amazon.com/tools)、[コマンドラインツール](https://aws.amazon.com/tools/#Command_Line_Tools)、または IAM API から取得できます。

**注記**  
IAM 認証情報レポートには IAM が管理する次の認証情報のみが含まれます。パスワード、ユーザーごとに最初の 2 つのアクセスキー、MFA デバイス、X.509 署名証明書。このレポートには、サービス固有の認証情報 (CodeCommit パスワード、Amazon Bedrock の長期 API キー、Amazon CloudWatch Logs の長期 API キーなど) や、最初の 2 つ以外のユーザーアクセスキーは含まれません。認証情報をすべて表示するには、[ListServiceSpecificCredentials](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html) API と [ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) API を使用します。

認証情報レポートを使用して、監査やコンプライアンスの作業を支援することができます。このレポートを使用して、パスワードやアクセスキーの更新など、認証情報ライフサイクルの要件の効果を監査できます。外部の監査人にこのレポートを提供することも、監査人が直接このレポートをダウンロードできるようにアクセス権限を付与することもできます。

認証情報レポートは、4 時間ごとに 1 回生成できます。レポートをリクエストすると、IAM はまず AWS アカウント について過去 4 時間以内にレポートが生成されたかどうかを確認します。レポートが生成されている場合は、最新のレポートがダウンロードされます。アカウントの最新のレポートが 4 時間以上前のものであるか、アカウントに以前のレポートがない場合、IAM は新しいレポートを生成してダウンロードします。

**Topics**
+ [

## 必要なアクセス許可
](#id_credentials_required_permissions)
+ [

## レポートフォーマットの理解
](#id_credentials_understanding_the_report_format)
+ [

## 認証情報レポートの取得 (コンソール)
](#getting-credential-reports-console)
+ [

## 認証情報レポートの取得 (AWS CLI)
](#getting-credential-reports-cliapi)
+ [

## 認証情報レポートの取得 (AWS API)
](#getting-credential-reports-api)

## 必要なアクセス許可
<a name="id_credentials_required_permissions"></a>

レポートを作成してダウンロードするには、以下のアクセス許可が必要です。
+ 認証情報レポートを作成生成するには: `iam:GenerateCredentialReport` 
+ レポートをダウンロードするには: `iam:GetCredentialReport`

## レポートフォーマットの理解
<a name="id_credentials_understanding_the_report_format"></a>

認証情報レポートは、カンマ区切り値（CSV）ファイルとしてフォーマットされます。CSV ファイルを一般的なスプレッドシートソフトウェアで開いて分析を実行できます。また、CSV ファイルをプログラム的に利用するアプリケーションを作成して、カスタム分析を実行することもできます。

CSV ファイルには、次の列が含まれます。

**ユーザー**  
ユーザーのわかりやすい名前。

**arn**  
ユーザーの Amazon リソースネーム（ARN）。ARN の詳細については、[IAM ARN](reference_identifiers.md#identifiers-arns)を参照してください。

**user\$1creation\$1time**  
ユーザーが作成された日時 ([ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601))。

**password\$1enabled**  
ユーザーがパスワードを持っている場合、この値は `TRUE` です。それ以外の場合は、`FALSE` です。組織の一部として作成された新規メンバーアカウントは、デフォルトでルートユーザー認証情報を持たないため、この値は `FALSE` になります。

**password\$1last\$1used**  
AWS アカウントのルートユーザー またはユーザーのパスワードを使用して最後に AWS ウェブサイトにサインインした日時「[(ISO 8601 日付/時刻形式)](http://www.iso.org/iso/iso8601)」。AWS ユーザーの最終サインイン時刻をキャプチャするウェブサイトには、AWS マネジメントコンソール、AWS ディスカッションフォーラム、および AWS Marketplace があります。5 分以内にパスワードが複数回使用された場合、最初の使用のみがこのフィールドに記録されます。  
+ 次のような場合、このフィールドの値は `no_information` になります。
  + ユーザーのパスワードが使用されたことがない場合。
  + IAM が 2014 年 10 月 20 日にこの情報の追跡を開始してから、ユーザーのパスワードが使用されていないなど、パスワードに関連付けられたサインインデータがない場合。
+ ユーザーがパスワードを所有していない場合、このフィールドの値は `N/A` (該当なし) です。

**重要**  
サービス上の問題により、前回使用したパスワードに関するデータには、2018 年 5 月 3 日 22 時 50 分 (太平洋夏時間) から 2018 年 5 月 23 日 14 時 08 分 (太平洋夏時間) までのパスワードの使用は含まれません。これは、IAM コンソールに表示される[前回サインイン](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html)した日付および [IAM 認証情報レポート](https://docs.aws.amazon.com/IAM/latest/UserGuide/SupportedTypes.xmlid_credentials_getting-report.html)でパスワードを前回使用した日付として [GetUser API オペレーション](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)から返される日付に影響を与えます。該当する期間中にユーザーがサインインした場合、パスワードを前回使用した日付として返される日付は、2018 年 5 月 3 日より前にユーザーが最後にサインインした日付になります。2018 年 5 月 23 日 14 時 08 分 (太平洋夏時間) より後にサインインしたユーザーの場合、パスワードを前回使用した日付として返される日付は正確です。  
前回使用したパスワードに関する情報を使用して未使用の認証情報を特定して削除する (例: 過去 90 日間に AWS にサインインしなかったユーザーを削除する) 場合は、2018 年 5 月 23 日より後の日付を含めるように評価ウィンドウを調整してください。または、ユーザーがアクセスキーを使用して AWS にプログラムでアクセスする場合は、前回使用したアクセスキーの情報を参照できます。これはすべての日付について正確であるためです。

**password\$1last\$1changed**  
ユーザーのパスワードが最後に設定された日時 ([ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601))。ユーザーがパスワードを所有していない場合、このフィールドの値は `N/A` (該当なし) です。

**password\$1next\$1rotation**  
アカウントにパスワードの更新を必要とする[パスワードポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingPasswordPolicies.html)がある場合、このフィールドには、新しいパスワードを設定するようユーザーに求める日時 ([ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601)) が保存されます。AWS アカウント (ルート) の値は常に `not_supported` です。

**mfa\$1active**  
ユーザーに対して[多要素認証](id_credentials_mfa.md) (MFA) デバイスが有効になっていた場合、この値は `TRUE` です。それ以外の場合は、`FALSE` です。

**access\$1key\$11\$1active**  
ユーザーがアクセスキーを所有し、そのアクセスキーのステータスが `Active` である場合、この値は `TRUE` です。それ以外の場合は、`FALSE` です。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。

**access\$1key\$11\$1last\$1rotated**  
ユーザーのアクセスキーが作成または最後に変更された日時 ([ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601))。ユーザーがアクティブなアクセスキーを所有していない場合、このフィールドの値は `N/A` (該当なし) です。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。

**access\$1key\$11\$1last\$1used\$1date**  
AWS API リクエストの署名にユーザーのアクセスキーが直近に使用されたときの [ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601)の日付と時刻。15 分以内にアクセスキーが複数回使用された場合、最初の使用のみがこのフィールドに記録されます。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。  
次のような場合、このフィールドの値は `N/A`（該当なし）になります。  
+ ユーザーにアクセスキーがない場合。
+ アクセスキーが一度も使用されていない場合。
+ IAM が 2015 年 4 月 22 日にこの情報の追跡を開始してから、アクセスキーが使用されていない場合。

**access\$1key\$11\$1last\$1used\$1region**  
アクセスキーが直近に使用された [AWS リージョン](https://docs.aws.amazon.com/general/latest/gr/rande.html)。15 分以内にアクセスキーが複数回使用された場合、最初の使用のみがこのフィールドに記録されます。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。  
次のような場合、このフィールドの値は `N/A`（該当なし）になります。  
+ ユーザーにアクセスキーがない場合。
+ アクセスキーが一度も使用されていない場合。
+ アクセスキーが最後に使用されたのが、IAM が 2015 年 4 月 22 日にこの情報の追跡を開始するより前の場合。
+ 最後に使用したサービスは、Amazon S3 など、リージョン固有ではありません。

**access\$1key\$11\$1last\$1used\$1service**  
アクセスキーを使用して最近アクセスされた AWS サービス。このフィールドの値として、サービスの`s3`名前空間 (Amazon S3 の 、Amazon EC2 の `ec2` など) が使用されます。15 分以内にアクセスキーが複数回使用された場合、最初の使用のみがこのフィールドに記録されます。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。  
次のような場合、このフィールドの値は `N/A`（該当なし）になります。  
+ ユーザーにアクセスキーがない場合。
+ アクセスキーが一度も使用されていない場合。
+ アクセスキーが最後に使用されたのが、IAM が 2015 年 4 月 22 日にこの情報の追跡を開始するより前の場合。

**access\$1key\$12\$1active**  
ユーザーが 2 つ目のアクセスキーを所有し、その 2 つ目のキーのステータスが `Active` である場合、この値は `TRUE` です。それ以外の場合は、`FALSE` です。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。  
ユーザーはアクセスキーを 2 つまで持つことができ、最初にキーを更新してから前のキーを削除すると、ローテーションが簡単になります。アクセスキーの更新の詳細については、「[アクセスキーを更新する](id-credentials-access-keys-update.md)」を参照してください。

**access\$1key\$12\$1last\$1rotated**  
ユーザーの 2 つ目のアクセスキーが作成された、または最後に更新された日時 ([ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601))。ユーザーが 2 つ目のアクティブなアクセスキーを所有していない場合、このフィールドの値は `N/A` (該当なし) です。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。

**access\$1key\$12\$1last\$1used\$1date**  
AWS API リクエストの署名にユーザーの 2 つ目のアクセスキーが直近に使用されたときの [ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601)の日付と時刻。15 分以内にアクセスキーが複数回使用された場合、最初の使用のみがこのフィールドに記録されます。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。  
次のような場合、このフィールドの値は `N/A`（該当なし）になります。  
+ ユーザーに 2 つ目のアクセスキーがない場合。
+ ユーザーの 2 つ目のアクセスキーが一度も使用されていない場合。
+ ユーザーの 2 つ目のアクセスキーが最後に使用されたのが、IAM が 2015 年 4 月 22 日にこの情報の追跡を開始するより前の場合。

**access\$1key\$12\$1last\$1used\$1region**  
ユーザーの 2 つ目のアクセスキーが直近に使用された [AWS リージョン](https://docs.aws.amazon.com/general/latest/gr/rande.html)。15 分以内にアクセスキーが複数回使用された場合、最初の使用のみがこのフィールドに記録されます。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。次のような場合、このフィールドの値は `N/A`（該当なし）になります。  
+ ユーザーに 2 つ目のアクセスキーがない場合。
+ ユーザーの 2 つ目のアクセスキーが一度も使用されていない場合。
+ ユーザーの 2 つ目のアクセスキーが最後に使用されたのが、IAM が 2015 年 4 月 22 日にこの情報の追跡を開始するより前の場合。
+ 最後に使用したサービスは、Amazon S3 など、リージョン固有ではありません。

**access\$1key\$12\$1last\$1used\$1service**  
ユーザーの 2 つ目のアクセスキーを使用して最近アクセスされた AWS サービス。このフィールドの値として、サービスの`s3`名前空間 (Amazon S3 の 、Amazon EC2 の `ec2` など) が使用されます。15 分以内にアクセスキーが複数回使用された場合、最初の使用のみがこのフィールドに記録されます。アカウントのルートユーザーと IAM ユーザーの両方に適用されます。次のような場合、このフィールドの値は `N/A`（該当なし）になります。  
+ ユーザーに 2 つ目のアクセスキーがない場合。
+ ユーザーの 2 つ目のアクセスキーが一度も使用されていない場合。
+ ユーザーの 2 つ目のアクセスキーが最後に使用されたのが、IAM が 2015 年 4 月 22 日にこの情報の追跡を開始するより前の場合。

**cert\$11\$1active**  
ユーザーが X.509 署名証明書を所有し、その証明書のステータスが `Active` である場合、この値は `TRUE` です。それ以外の場合は、`FALSE` です。

**cert\$11\$1last\$1rotated**  
ユーザーの署名証明書が作成または最後に変更された日時 ([ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601))。ユーザーがアクティブな署名証明書を所有していない場合、このフィールドの値は `N/A` (該当なし) です。

**cert\$12\$1active**  
ユーザーが 2 つ目の X.509 署名証明書を所有し、その証明書のステータスが `Active` である場合、この値は `TRUE` です。それ以外の場合は、`FALSE` です。  
証明書のローテーションを容易にするために、ユーザーは最大で 2 個の X.509 署名証明書を持つことができます。

**cert\$12\$1last\$1rotated**  
ユーザーの 2 つ目の署名証明書が作成または最後に変更された日時 ([ISO 8601 日付/時刻形式](https://en.wikipedia.org/wiki/ISO_8601))。ユーザーが 2 つ目のアクティブな署名証明書を所有していない場合、このフィールドの値は `N/A` (該当なし) です。

**additional\$1credentials\$1info**  
ユーザーが 3 つ以上のアクセスキーまたは証明書を持っている場合、この値は追加のアクセスキーまたは証明書、およびユーザーに関連付けられたアクセスキーまたは証明書を一覧表示するために使用できるアクションの数になります。

## 認証情報レポートの取得 (コンソール)
<a name="getting-credential-reports-console"></a>

AWS マネジメントコンソールを使用して、認証情報レポートをカンマ区切り値 (CSV) ファイルとしてダウンロードできます。

**認証情報レポートをダウンロードするには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、[**認証情報レポート**] を選択します。

1. [**レポートをダウンロード**] を選択します。

## 認証情報レポートの取得 (AWS CLI)
<a name="getting-credential-reports-cliapi"></a>

**認証情報レポートをダウンロードするには (AWS CLI)**

1. 認証情報レポートを生成します。AWS には、単一のレポートが格納されます。レポートが存在する場合、認証情報レポートを生成すると、以前のレポートが上書きされます。[https://docs.aws.amazon.com/cli/latest/reference/iam/generate-credential-report.html](https://docs.aws.amazon.com/cli/latest/reference/iam/generate-credential-report.html)

1. 最後に生成されたレポートを表示します: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-credential-report.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-credential-report.html)

## 認証情報レポートの取得 (AWS API)
<a name="getting-credential-reports-api"></a>

**認証情報レポートをダウンロードするには (AWS API)**

1. 認証情報レポートを生成します。AWS には、単一のレポートが格納されます。レポートが存在する場合、認証情報レポートを生成すると、以前のレポートが上書きされます。[https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html)

1. 最後に生成されたレポートを表示します: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html)

# CodeCommit の IAM 認証情報: Git 認証情報、SSH キー、および AWS アクセス キー
<a name="id_credentials_ssh-keys"></a>

CodeCommit はマネージド型バージョン管理サービスであり、AWS クラウド内のプライベート Git リポジトリをホストします。CodeCommit を使用するには、Git クライアントを CodeCommit リポジトリと通信できるように設定します。この設定の一環として、CodeCommit がユーザーの認証に使用できる IAM 認証情報を指定します。IAM は、次の 3 種類の認証情報で CodeCommit をサポートしています。
+ Git 認証情報。HTTPS 経由の CodeCommit リポジトリとの通信に使用できる、IAM によって生成されたユーザー名とパスワードのペアです。
+ SSH キー。IAM ユーザーに関連付けて SSH 経由で CodeCommit リポジトリと通信できる、ローカルで生成されたパブリックキーとプライベートキーのペアです。
+  [AWS アクセスキー](id_credentials_access-keys.md)。AWS CLI に含まれる認証情報ヘルパーで使用して、HTTPS 経由で CodeCommit リポジトリと通信できます。

**注記**  
別の AWS アカウントのリポジトリにアクセスするには、SSH キーまたは Git 認証情報を使用できません。別の IAM ユーザーおよびグループに対して、CodeCommit リポジトリへのアクセスを設定する方法を学ぶには AWS アカウント の詳細については、「AWS CodeCommit ユーザーガイド」の「[ロールを使用した AWS CodeCommit リポジトリへのクロスアカウントアクセスを設定する](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html)」を参照してください。

以下のセクションに各オプションの詳細を示します。

## CodeCommitで Git 認証情報および HTTPS を使用する (推奨)
<a name="git-credentials-code-commit"></a>

Git 認証情報では、IAM ユーザーの静的ユーザー名とパスワードのペアを生成し、その認証情報を HTTPS 接続に使用します。また、静的 Git 認証情報をサポートするサードパーティー製ツールや統合開発環境 (IDE) でもこの認証情報を使用できます。

これらの認証情報はサポートされているすべてのオペレーティングシステムで共通であり、ほとんどの認証情報管理システム、開発環境、その他のソフトウェア開発ツールと互換性があるため、推奨される方法です。Git 認証情報のパスワードはいつでもリセットできます。また、認証情報が不要になった場合は、非アクティブ化または削除できます。

**注記**  
Git 認証情報用のユーザー名やパスワードは選択できません。IAMは、これらのクレデンシャルを生成して、AWS のセキュリティ標準と CodeCommit の安全なリポジトリを確実に満たすようにします。認証情報は、生成時に 1 回のみダウンロードできます。必ず、認証情報を安全な場所に保存してください。必要に応じて、パスワードをいつでもリセットできますが、そうすると古いパスワードを使用した接続が無効になります。接続するには、新しいパスワードを使用するように接続を再構成する必要があります。

詳細については、以下のトピックを参照してください。
+ IAM ユーザーを作成するには、「[AWS アカウント で IAM ユーザーを作成する](id_users_create.md)」を参照してください。
+ CodeCommit で Git 認証情報を生成して使用するには、[AWS CodeCommit ユーザーガイド](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html)の「*Git 認証情報を使用する HTTPS ユーザーの場合*」を参照してください。

**注記**  
Git 認証情報を生成した後で IAM ユーザーの名前を変更しても、Git 認証情報のユーザー名は変更されません。ユーザー名とパスワードは変わらず、有効のままです。

**サービス固有の認証情報を更新するには**

1. 現在使用されているセットに加えて、2 つ目のサービス固有の認証情報セットを作成します。

1. 新しい認証情報のセットを使用するようにすべてのアプリケーションを更新して、アプリケーションが動作することを確認します。

1. 元の認証情報の状態を「非アクティブ」に変更します。

1. すべてのアプリケーションが動作していることを確認します。

1. 非アクティブ化したサービス固有の認証情報を削除します。

## CodeCommit で SSH キーと SSH を使用する
<a name="ssh-keys-code-commit"></a>

SSH 接続では、SSH 認証用に Git および CodeCommit が使用するパブリックキーとプライベートキーのファイルをローカルマシンで作成します。パブリックキーは IAM ユーザーに関連付け、プライベートキーはローカルマシンに保存します。詳細については、以下のトピックを参照してください。
+ IAM ユーザーを作成するには、「[AWS アカウント で IAM ユーザーを作成する](id_users_create.md)」を参照してください。
+ SSH 公開キーを作成して IAM ユーザーに関連付けるには、[AWS CodeCommit ユーザーガイド](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-unixes.html)の「[Linux、macOS、または Unix での SSH 接続について](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-windows.html)」または「*Windows での SSH 接続について*」を参照してください。

**注記**  
パブリックキーは ssh-rsa 形式または PEM 形式でエンコードされます。パブリックキーの最小のビットの長さは 2048 ビットですが、パブリックキーの最大長は 16384 ビットです。これはアップロードするファイルのサイズとは異なります。たとえば 2048 ビットキーを生成した場合、作成された PEM ファイルの長さは 1679 バイトになります。パブリックキーを別の形式またはサイズで提供すると、キーの形式が無効であることを知らせるエラーメッセージが表示されます。

## AWS CLI 認証情報ヘルパーおよび CodeCommit で HTTPS を使用する
<a name="access-keys-code-commit"></a>

Git が CodeCommit リポジトリとの通信で AWS に対する認証を必要とする場合は、Git 認証情報を使用した HTTPS 接続の代わりに、暗号化された署名済みバージョンの IAM ユーザー認証情報または Amazon EC2 インスタンスロールを Git で使用できます。これは、IAM ユーザーを必要としない CodeCommit リポジトリと接続する唯一の方法です。また、フェデレーションアクセスおよび一時的な認証情報を使用できる唯一の方法でもあります。詳細については、以下のトピックを参照してください。
+ フェデレーションアクセスの詳細については、[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)および[外部で認証されたユーザーへのアクセス (ID フェデレーション)](id_roles_common-scenarios_federated-users.md)を参照してください。
+ 一時的な認証情報の詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」および「[CodeCommit リポジトリへの一時アクセス](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html)」を参照してください。

AWS CLI 認証情報ヘルパーには、Keychain Access や Windows Credential Management などの他の認証情報ヘルパーシステムとの互換性はありません。認証情報ヘルパーを使用して HTTPS 接続を設定する際は、追加の設定考慮事項があります。詳細については、[AWS CLI ユーザーガイド](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-unixes.html)の「[AWS CLI 資格情報ヘルパーを使用したLinux、macOS、または Unix での HTTPS 接続](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-windows.html)」または「*AWS CodeCommit 資格情報ヘルパーを使用した Windows での HTTPS 接続について*」を参照してください。

# IAM でサーバー証明書を管理する
<a name="id_credentials_server-certs"></a>

ウェブサイトまたは AWS のアプリケーションへの HTTPS 接続を有効にするには、SSL/TLS *サーバー証明書*が必要です。AWS Certificate Manager (ACM) によってサポートされているリージョンの証明書では、ACM を使用して、サーバー証明書をプロビジョン、管理、およびデプロイすることをお勧めします。サポートされていないリージョンでは、IAM を Certificate Manager として使用する必要があります。ACM がサポートするリージョンについては、「AWS 全般のリファレンス」の「[AWS Certificate Manager エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/acm.html)」を参照してください。

**重要**  
ACM は、サーバー証明書をプロビジョン、管理、デプロイするための推奨ツールです。ACM を使用すると、証明書をリクエストしたり、既存の ACM または外部証明書を AWS リソースにデプロイしたりできます。ACM で提供された証明書は無料で自動的に更新されます。[サポートされているリージョン](https://docs.aws.amazon.com/general/latest/gr/acm.html)では、ACM を使用して、コンソールまたはプログラムでサーバー証明書を管理できます。ACM の使用の詳細については、[https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)を参照してください。ACM 証明書のリクエストの詳細については、*AWS Certificate Manager ユーザーガイド*の「[パブリック証明書のリクエスト](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html)」または「[プライベート証明書のリクエスト](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html)」を参照してください。ACM へのサードパーティー証明書のインポートの詳細については、*AWS Certificate Manager ユーザーガイド*の「[証明書のインポート](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)」を参照してください。

[ACM でサポート](https://docs.aws.amazon.com/general/latest/gr/acm.html)されていないリージョンで HTTPS 接続をサポートする必要があるときにのみ、Certificate Manager として IAM を使用してください。IAM はプライベートキーを安全に暗号化し、暗号化されたバージョンを IAM SSL 証明書ストレージに保存します。IAM はすべてのリージョンでのサーバー証明書のデプロイをサポートしますが、AWS で使用するには、外部プロバイダーから証明書を取得する必要があります。ACM 証明書を IAM にアップロードすることはできません。また、IAM コンソールから証明書を管理することはできません。

IAM へのサードパーティー証明書のアップロードの詳細については、以下のトピックを参照してください。

**Topics**
+ [

## サーバー証明書をアップロードする (AWS API)
](#upload-server-certificate)
+ [

## サーバー証明書の AWS API オペレーション
](#id_credentials_server-certs-api)
+ [

## サーバー証明書のトラブルシューティング
](#server-certificate-troubleshooting)

## サーバー証明書をアップロードする (AWS API)
<a name="upload-server-certificate"></a>

IAM にサーバー証明書をアップロードするには、証明書と対応するプライベートキーを提供する必要があります。証明書が自己署名されていない場合、証明書チェーンも提供する必要があります (自己署名証明書をアップロードするときに証明書チェーンは必要ありません)。証明書をアップロードする前に、これらの項目がすべてあり、以下の条件を満たしていることを確認します。
+ 証明書はアップロード時に有効である必要があります。有効期間の開始 (証明書の `NotBefore` 日付) 前、または有効期間の終了 (証明書の `NotAfter` 日) 後に証明書をアップロードすることはできません。
+ プライベートキーは非暗号化される必要があります。パスワードやパスフレーズで保護されたプライベートキーをアップロードすることはできません。暗号化されたプライベートキーの復号のヘルプについては、「[サーバー証明書のトラブルシューティング](#server-certificate-troubleshooting)」を参照してください。
+ 証明書、プライベートキー、および証明書チェーンはすべて PEM エンコードされる必要があります。これらの項目の PEM 形式への変換のヘルプについては、「[サーバー証明書のトラブルシューティング](#server-certificate-troubleshooting)」を参照してください。

[IAM API](https://docs.aws.amazon.com/IAM/latest/APIReference/) を使用して証明書をアップロードするには、[UploadServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UploadServerCertificate.html) リクエストを送信します。次の例では、[AWS Command Line Interface (AWS CLI) ](https://aws.amazon.com/cli/) を使用してこのオペレーションを行う方法を示します。例では、次のように想定しています。
+ PEM エンコードされた証明書は、`Certificate.pem` というファイルに保存されます。
+ PEM エンコードされた証明書チェーンは、`CertificateChain.pem` というファイルに保存されます。
+ PEM エンコードされ、非暗号化されたプライベートキーは、`PrivateKey.pem` というファイルに保存されます。
+ (オプション) キーバリューペアを使ってサーバー証明書にタグを付けるとします。例えば、証明書の特定と整理を行うために、タグキー `Department` と タグ値 `Engineering` を追加することが可能です。

次のコマンドの例を使用するには、これらのファイル名を独自のファイル名に置き換えます。*ExampleCertificate* をアップロードした証明書の名前に置き換えます。証明書にタグを付ける場合は、*ExampleKey* と *ExampleValue* タグのキーバリューのペアを独自の値に置き換えます。1 つの連続した行にコマンドを入力します。次の例では、読みやすくするために改行とスペースを追加しています。

```
aws iam upload-server-certificate --server-certificate-name ExampleCertificate
                                    --certificate-body file://Certificate.pem
                                    --certificate-chain file://CertificateChain.pem
                                    --private-key file://PrivateKey.pem
                                    --tags '{"Key": "ExampleKey", "Value": "ExampleValue"}'
```

前のコマンドが成功すると、[Amazon リソースネーム (ARN)](reference_identifiers.md#identifiers-arns)、わかりやすい名前、識別子 (ID)、有効期限日、タグなど、アップロードされた証明書に関するメタデータを返します。

**注記**  
Amazon CloudFront で使用することを目的としてサーバー証明書をアップロードする場合、`--path` オプションを使用してパスを指定する必要があります。パスの先頭に `/cloudfront` を含め、末尾にスラッシュを含める必要があります（例: `/cloudfront/test/`）。

AWS Tools for Windows PowerShell を使用して証明書をアップロードするには、[Publish-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Publish-IAMServerCertificate.html&tocid=Publish-IAMServerCertificate) を使用します。

## サーバー証明書の AWS API オペレーション
<a name="id_credentials_server-certs-api"></a>

次のコマンドを使用して、サーバー証明書を表示、タグ付け、名前変更、削除します。
+ [GetServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServerCertificate.html) を使用して証明書を取得します。このリクエストは、証明書、証明書チェーン (アップロードされた場合)、および証明書に関するメタデータを返します。
**注記**  
アップロード後に IAM からプライベートキーをダウンロードまたは取得することはできません。
+ [Get-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Get-IAMServerCertificate.html&tocid=Get-IAMServerCertificate) を使用して証明書を取得します。
+ アップロードされたサーバー証明書を一覧表示するには、[ListServerCertificates](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServerCertificates.html) を使用します。リクエストは、各証明書に関するメタデータを含むリストを返します。
+ アップロードしたサーバー証明書を一覧表示するには、[Get-IAMServerCertificates](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Get-IAMServerCertificates.html&tocid=Get-IAMServerCertificates) を使用します。
+ 既存のサーバー証明書にタグを付けするには、[TagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagServerCertificate.html) を使用します。
+ Iサーバー証明書のタグを除するには、[UntagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagServerCertificate.html) を使用します。
+ サーバー証明書の名前を変更するか、そのパスを更新するには、[UpdateServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServerCertificate.html) を使用します。

   次の例では、AWS CLI を使用してこのオペレーションを行う方法を示します

  以下のサンプルコマンドを使用するには、古い証明書の名前、新しい証明書の名前、および証明書のパスを置き換え、1 つの連続した行にコマンドを入力します。次の例では、読みやすくするために改行とスペースを追加しています。

  ```
  aws iam update-server-certificate --server-certificate-name ExampleCertificate
                                      --new-server-certificate-name CloudFrontCertificate
                                      --new-path /cloudfront/
  ```

  AWS Tools for Windows PowerShell を使用してサーバー証明書の名前を変更するか、パスを更新するには、[Update-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Update-IAMServerCertificate.html&tocid=Update-IAMServerCertificate) を使用します。
+ サーバー証明書を削除するには、[delete\$1server\$1certificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServerCertificate.html) を使用します。

  AWS Tools for Windows PowerShell を使用してサーバー証明書を削除するには、[Remove-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Remove-IAMServerCertificate.html&tocid=Remove-IAMServerCertificate) を使用します。

## サーバー証明書のトラブルシューティング
<a name="server-certificate-troubleshooting"></a>

証明書を IAM にアップロードする前に、証明書、プライベートキー、および証明書チェーンがすべて PEM エンコードされていることを確認する必要があります。また、プライベートキーは非暗号化されていることも確認する必要があります。次の 例を参照してください。

**Example PEM エンコードされた証明書の例**  

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
```

**Example PEM エンコードされ、暗号化されていないプライベートキーの例**  

```
-----BEGIN RSA PRIVATE KEY-----
Base64-encoded private key
-----END RSA PRIVATE KEY-----
```

**Example PEM エンコードされた証明書チェーンの例**  
証明書チェーンには 1 つまたは複数の証明書が含まれます。テキストエディタ、Windows のコピーコマンド、または Linux の cat コマンドを使用して、ファイルをチェーンに連結します。複数の証明書を含めるときは、各証明書が、前述の証明書を認証する必要があります。そのため、証明書を連結して最後にルート CA 証明書を含めます。  
次の例には 3 つの証明書が含まれていますが、証明書チェーンに含まれている証明書はそれ以上またはそれ以下である可能性があります。  

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
```

これらの項目が IAM へのアップロードに適切な形式でない場合は、[OpenSSL](https://openssl.org/) を使用して適切な形式に変換できます。

**DER から PEM に証明書または証明書チェーンを変換するには**  
以下の例のように、[OpenSSL **x509** コマンド](https://openssl.org/docs/manmaster/man1/x509.html)を使用します。次のサンプルコマンドで、`Certificate.der` を、DER エンコードされた証明書を含むファイルの名前に置き換えます。`Certificate.pem` を、希望する出力ファイル名に置き換え、PEM エンコードされた証明書を含めます。  

```
openssl x509 -inform DER -in Certificate.der -outform PEM -out Certificate.pem
```
 

**DER から PEM にプライベートキーを変換するには**  
以下の例のように、[OpenSSL **rsa** コマンド](https://openssl.org/docs/manmaster/man1/rsa.html)を使用します。次のサンプルコマンドで、`PrivateKey.der` を、DER エンコードされたプライベートキーを含むファイルの名前に置き換えます。`PrivateKey.pem` を、希望する出力ファイル名に置き換え、PEM エンコードされたプライベートキーを含めます。  

```
openssl rsa -inform DER -in PrivateKey.der -outform PEM -out PrivateKey.pem
```
 

**暗号化されたプライベートキーを復号するには (パスワードやパスフレーズを削除)**  
以下の例のように、[OpenSSL **rsa** コマンド](https://openssl.org/docs/manmaster/man1/rsa.html)を使用します。次のサンプルコマンドを使用するには、`EncryptedPrivateKey.pem` を、暗号化されたプライベートキーを含むファイルの名前に置き換えます。`PrivateKey.pem` を、希望する出力ファイル名に置き換え、PEM エンコードおよび非暗号化されたプライベートキーを含めます。  

```
openssl rsa -in EncryptedPrivateKey.pem -out PrivateKey.pem
```
 

**証明書バンドルを PKCS\$112 (PFX) から PEM に変換するには**  
以下の例のように、[OpenSSL **pkcs12** コマンド](https://openssl.org/docs/manmaster/man1/pkcs12.html)を使用します。次のサンプルコマンドで、`CertificateBundle.p12` を、PKCS\$112 エンコードされた証明書バンドルを含むファイルの名前に置き換えます。`CertificateBundle.pem` を、希望する出力ファイル名に置き換え、PEM エンコードされた証明書バンドルを含めます。  

```
openssl pkcs12 -in CertificateBundle.p12 -out CertificateBundle.pem -nodes
```
 

**証明書バンドルを PKCS\$17 から PEM に変換するには**  
以下の例のように、[OpenSSL **pkcs7** コマンド](https://openssl.org/docs/manmaster/man1/pkcs7.html)を使用します。次のサンプルコマンドで、`CertificateBundle.p7b` を、PKCS\$17 エンコードされた証明書バンドルを含むファイルの名前に置き換えます。`CertificateBundle.pem` を、希望する出力ファイル名に置き換え、PEM エンコードされた証明書バンドルを含めます。  

```
openssl pkcs7 -in CertificateBundle.p7b -print_certs -out CertificateBundle.pem
```

# IAM ユーザーグループ
<a name="id_groups"></a>

IAM [* ユーザーグループ*](#id_groups)とは、IAM ユーザーの集合です。ユーザーグループを使用すると、複数のユーザーに対してアクセス許可を指定でき、それらのユーザーのアクセス許可を容易に管理することができます。たとえば、Admins というユーザーグループを作成し、管理者が一般的に必要とするようなアクセス許可をそのユーザーグループに付与できます。そのグループのすべてのユーザーグループは、Admins グループのアクセス許可を自動的に付与されます。管理者権限を必要とする新しいユーザーが組織に参加した場合、そのユーザーを Admins ユーザーグループに追加することで、適切な権限を割り当てることができます。組織内で職務を変更したユーザーがいる場合は、そのユーザーのアクセス許可を編集する代わりに、ユーザーを古い IAM グループから削除して適切な新しい IAM グループに追加することができます。

グループ内のすべてのユーザーがそのポリシーのアクセス許可を受け取れるように、ID ベースのポリシーをグループにアタッチすることができます。ポリシー (リソースベースのポリシーなど) では、ユーザーグループを `Principal` として識別することはできません。これは、グループが認証ではなくアクセス許可に関連しており、プリンシパルが認証済みの IAM エンティティであるためです ポリシーの詳細については、「[アイデンティティベースおよびリソースベースのポリシー](access_policies_identity-vs-resource.md)」を参照してください。

次に IAM グループの重要な特徴を示します。
+ ユーザーグループは多くのユーザーを持つことができ、ユーザーは複数のグループに属することができます。
+ ユーザーグループを入れ子形式にすることはできません。ユーザーグループにはユーザーのみを含めることができ、他の IAM グループを含めることはできません。
+ AWS アカウント 内のユーザーすべてを自動的に含むデフォルトのユーザーグループはありません。このようなユーザーグループが必要な場合は、そのユーザーグループを作成し、新たなユーザーを 1 人 1 人割り当てる必要があります。
+ AWS アカウント の IAM リソースの数とサイズは、グループの数や、ユーザーがメンバーになることができるグループの数などには制限があります。詳細については、「[IAM と AWS STSクォータ](reference_iam-quotas.md)」を参照してください。

以下の図は、小企業の簡単なサンプルを示しています。企業の所有者は、企業の成長に伴い、他のユーザーを作成して管理するための `Admins` ユーザーグループを作成します。`Admins` ユーザーグループは、`Developers` ユーザーグループと`Test` ユーザーグループを作成します。これらの IAM グループはそれぞれ、AWS (ジム、ブラッド、DevApp1 など) とやりとりするユーザー (人員とアプリケーション) で構成されます。各ユーザーは、それぞれ一連の認証情報をもっています。この例では、各ユーザーは 1 つのユーザーグループに属しています。しかし、ユーザーは複数の IAM グループに属することができます。

![\[AWS アカウント、ユーザー、および IAM グループ間の関係性の例\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/Relationship_Between_Entities_Example.diagram.png)


# IAM グループを作成する
<a name="id_groups_create"></a>

**注記**  
[ベストプラクティス](best-practices.md)として、一時的な認証情報の使用により AWS にアクセスするには、人間のユーザーに対して ID プロバイダーとのフェデレーションの使用を必須とすることをお勧めします。ベストプラクティスに従えば、IAM ユーザーやグループを管理することにはなりません。管理するのではなく、ユーザーとグループは AWS の外部で管理され、フェデレーション ID として AWS リソースにアクセスできます。フェデレーション ID は、エンタープライズユーザーディレクトリ、ウェブ ID プロバイダー、AWS Directory Service、Identity Center ディレクトリのユーザー、または ID ソースから提供された認証情報を使用して AWS のサービスにアクセスするユーザーです。フェデレーション ID は、ID プロバイダーが定義したグループを使用します。AWS IAM アイデンティティセンター を使用している場合は、IAM Identity Center でのユーザーとグループの作成に関する情報について、AWS IAM アイデンティティセンター ユーザーガイドの「[Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)」(IAM Identity Center での ID の管理) を参照してください。

IAM グループを作成して、類似するロールまたは責任を持つ複数のユーザーのアクセス許可を管理します。これらのグループにポリシーをアタッチすることで、ユーザーのグループ全体に対するアクセス許可を付与または取り消すことができます。これにより、グループのアクセス許可に加えた変更がそのグループのすべてのメンバーに自動的に適用されるため、セキュリティポリシーのメンテナンスが簡素化され、一貫したアクセス制御が可能になります。グループを作成後、グループ内の IAM ユーザーに期待される作業のタイプに基づいてグループアクセス許可を付与し、IAM ユーザーをグループに追加します。

IAM グループ作成に必要なアクセス許可については、「[他の IAM リソースにアクセスするのに必要なアクセス許可](access_permissions-required.md)」を参照してください。

## IAMグループを作成し、ポリシーをアタッチするには
<a name="id_groups_create-section-1"></a>

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ユーザーグループ]**、**[グループの作成]** の順に選択します。

1. **[ユーザーグループ名]** に、グループ名を入力します。
**注記**  
AWS アカウントの IAM リソースの数とサイズには制限があります。詳細については、「[IAM と AWS STSクォータ](reference_iam-quotas.md)」を参照してください。グループ名は、最大 128 文字の英数字、プラス記号 (\$1)、等号 (=)、カンマ (,)、ピリオド (.)、アットマーク (@)、アンダースコア (\$1)、ハイフン (-) を組み合わせて指定します。名前はアカウント内で一意である必要があります。大文字と小文字は区別されません。例えば、**ADMINS** と **admins** というロール名を両方作成することはできません。

1. ユーザーのリストで、グループに追加する各ユーザーのチェックボックスをオンにします。

1. ポリシーのリストで、グループのすべてのメンバーに適用する各ポリシーのチェックボックスをオンにします。

1. **[グループの作成]** を選択してください。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [aws iam create-group](https://docs.aws.amazon.com/cli/latest/reference/iam/create-group.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [CreateGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html)

------

# IAM グループの表示
<a name="id_groups_manage_list"></a>

アカウント内のすべての IAM グループのリスト、グループ内のユーザーのリスト、およびユーザーが属する IAM グループを一覧表示したりできます。CLI または API を使用すると、特定のパスのプレフィックスが付いたすべての IAM グループを一覧表示できます。

------
#### [ Console ]

アカウントの全 IAM グループを一覧表示するには:
+ ナビゲーションペインで、**[ユーザーグループ]** を選択します。

特定の IAM グループ内の IAM ユーザーを一覧表示するには:
+ ナビゲーションペインで、**[ユーザーグループ]** を選択します。次に、グループの名前を選択して、グループの詳細ページを開きます。**[ユーザー]** タブでグループメンバーシップを確認します。

ユーザーが所属しているすべての IAM グループを一覧表示するには:
+ ナビゲーションペインで **[ユーザー]** を選択します。次に、ユーザー名を選択して、ユーザーの詳細ページを開きます。**[グループ]** タブを選択すると、ユーザーが属するグループのリストが表示されます。

------
#### [ AWS CLI ]

アカウントの全 IAM グループを一覧表示するには:
+ [aws iam list-groups](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups.html)

特定の IAM グループのユーザーを一覧表示するには:
+ [aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html)

ユーザーが所属しているすべての IAM グループを一覧表示するには:
+ [aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)

------
#### [ API ]

アカウントの全 IAM グループを一覧表示するには:
+ [ListGroups](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroups.html)

特定の IAM グループのユーザーを一覧表示するには:
+ [GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)

ユーザーが所属しているすべての IAM グループを一覧表示するには:
+ [ListGroupsForUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupsForUser.html)

------

# IAM グループのユーザーを編集する
<a name="id_groups_manage_add-remove-users"></a>

IAM グループを使用して、同じアクセス許可ポリシーを複数のユーザーに一度に適用します。適用後、IAM グループにユーザーを追加したり、IAM グループからユーザーを削除したりできます。これは、組織で従業員の異動があるときに便利です。

## ポリシーアクセスを確認する
<a name="groups-remove_prerequisites"></a>

グループを削除する前に、グループの詳細ページを使用してグループのメンバー (IAM ユーザー）、**[アクセス許可]** タブでグループにアタッチされたポリシーを確認し、**[最終アクセス時間]** タブを使用して最近のサービスレベルのアクティビティを確認します。これにより、それを使用しているプリンシパル (ユーザーまたはアプリケーション) から意図せずアクセスが削除されるのを防ぐことができます。最後にアクセスした情報を表示する方法の詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](access_policies_last-accessed.md)」を参照してください。

## IAM グループに IAM ユーザーを追加する
<a name="groups-add-remove-console"></a>

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ユーザーグループ]** を選択してから、グループ名を選択します。

1. [**Users (ユーザー)**] タブを選択し、[**Add users (ユーザーの追加)**] を選択します。追加するユーザーの横のチェックボックスをオンにします。

1. [**ユーザーの追加**] を選択します。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ `[aws iam add-user-to-group](https://docs.aws.amazon.com/cli/latest/reference/iam/add-user-to-group.html)`

------
#### [ API ]

次のオペレーションを呼び出します。
+ `[AddUserToGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)`

------

## IAM グループから IAM ユーザーを削除する
<a name="id_groups_manage_add-remove-users-section-1"></a>

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ユーザーグループ]** を選択してから、グループ名を選択します。

1. **[ユーザー]** タブを選択します。削除するユーザーの横にあるチェックボックスをオンにし、[**ユーザーの削除**]を選択します。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ `[aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html)`

------
#### [ API ]

次のオペレーションを呼び出します。
+ `[RemoveUserFromGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveUserFromGroup.html)`

------

# IAM ユーザーグループにポリシーをアタッチする
<a name="id_groups_manage_attach-policy"></a>

[AWS 管理ポリシー](access_policies_managed-vs-inline.md#aws-managed-policies)をアタッチできます — つまり、次の手順で説明するように、AWS によって提供される事前記述されたポリシーをユーザーグループにアタッチできます。カスタマー管理ポリシー (独自に作成したカスタムのアクセス権限を使用するポリシー) をアタッチするには、まずポリシーを作成する必要があります。カスタマー管理ポリシーの作成方法については、「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](access_policies_create.md)」を参照してください。

アクセス許可とポリシーの詳細については、「[AWS リソースの アクセス管理](access.md)」を参照してください。

## IAM グループにポリシーをアタッチするには
<a name="id_groups_manage_attach-policy-section-1"></a>

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ユーザーグループ]** を選択してから、グループ名を選択します。

1. **[アクセス許可]** タブを選択します。

1. **[アクセス許可を追加]**、**[ポリシーをアタッチ]** の順に選択します。

1. ユーザーグループにアタッチされている現在のポリシーは、**現在のアクセス権限ポリシー**のリストに表示されます。**その他のアクセス権限ポリシー**のリストで、アタッチするポリシーの名前の横にあるチェックボックスをオンにします。検索ボックスを使用して、ポリシーのリストをタイプとポリシー名でフィルタリングできます。

1. IAM グループにアタッチするポリシーを選択して、**[ポリシーをアタッチ]** を選択します。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ `[aws iam attach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html)`

------
#### [ API ]

次のオペレーションを呼び出します。
+ `[AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html)`

------

# IAM ユーザーグループの名前を変更する
<a name="id_groups_manage_rename"></a>

ユーザーグループ名またはパスを変更すると、以下のことが起こります。
+ ユーザーグループにアタッチされているポリシーは、新しい名前のグループにそのままアタッチされています。
+ ユーザーグループは名前が変わるだけで、保持するユーザーは一切変わりません。
+ ユーザーグループの一意の ID は変更されません。一意の ID の詳細については、「[一意の識別子](reference_identifiers.md#identifiers-unique-ids)」を参照してください。

IAM は、新しい名前を使用するためのリソースとしてユーザーグループを参照するポリシーを自動的に更新しません。したがって、ユーザーグループの名前を変更するときには注意が必要です。ユーザーグループの名前を変更する前に、すべてのポリシーを手動でチェックし、このユーザーグループの名前を参照しているポリシーを見つける必要があります。たとえば、Bob は組織のテスト部門のマネージャーであるとします。Bob の IAM ユーザーエンティティにアタッチされたポリシーにより、Bob はテストユーザーグループに対してユーザーを追加および削除できます。管理者は、ユーザーグループの名前 (またはグループのパス) を変更する場合、Bob にアタッチされているポリシーも更新して新しい名前またはパスを反映する必要があります。この更新を行わないと、Bob はユーザーグループに対してユーザーを追加および削除できるようになりません。

**IAM グループをリソースとして参照しているポリシーを見つけるには:**

1. IAM コンソールのナビゲーションペインから、**[ポリシー]** を選択します。

1. [**タイプ**]列で並べ替えて、**カスタマー管理**するカスタムポリシーを見つけます。

1. [ポリシーの編集] を選択して、ポリシー内のユーザーグループの名前を変更します。

1. [**アクセス許可**] タブを選択し、[**概要**] を選択します。

1. サービスのリストに **[IAM]** があれば、それを選択します。

1. **[リソース]** 列でユーザーグループの名前を見つけます。

1. [**編集**] を選択して、ポリシー内のユーザーグループの名前を変更します。

## IAM ユーザーグループの名前を変更するには
<a name="id_groups_manage_rename-section-1"></a>

------
#### [ Console ]

1. ナビゲーションペインで **[ユーザーグループ]** を選択し、グループ名を選択します。

1. **[編集]** を選択します。新しいユーザーグループ名を入力し、[**変更の保存**] を選択します。。

------
#### [ AWS CLI ]

次のコマンドを実行します。
+ [aws iam update-group](https://docs.aws.amazon.com/cli/latest/reference/iam/update-group.html)

------
#### [ API ]

次のオペレーションを呼び出します。
+ [UpdateGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateGroup.html)

------

# IAM グループを削除する
<a name="id_groups_manage_delete"></a>

コンソールで IAM グループを削除すると、自動的にすべてのグループメンバーが削除され、アタッチされていた管理ポリシーはすべてデタッチされ、すべてのインラインポリシーが削除されます。ただし、IAM は、IAM グループをリソースとして参照するポリシーを自動的には削除されません。IAM グループを削除する際は注意してください。IAM グループを削除する前に、すべてのポリシーを手動で確認して、このグループの名前を参照しているポリシーを見つける必要があります。例えば、テストチームマネージャーの John は、IAM ユーザーエンティティにアタッチされたポリシーの権限を持ち、テストユーザーグループに対してユーザーを追加および削除できます。管理者は、ユーザーグループを削除する場合に、John にアタッチされているポリシーも削除する必要があります。それ以外の場合、管理者が削除したグループを再作成して同じ名前を付けると、テストチームを辞めても John の権限はそのまま残ります。

一方、CLI、SDK、または API を使用してユーザー グループを削除する場合は、まずグループ内のユーザーを削除する必要があります。次に、IAM グループに埋め込まれたインラインポリシーを削除します。さらに、グループにアタッチされているすべての管理ポリシーをデタッチします。その後に、IAM グループ自体を削除できます。

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ユーザーグループ]** を選択します。

1. IAM グループのリストで、削除する IAM グループの名前の横にあるチェックボックスをオンにします。検索ボックスを使用して、IAM グループのリストをタイプ、パーミッション、およびグループ名でフィルタリングできます。

1. **[削除]** を選択します。

1. １ つのグループを削除する場合は、確認ボックスにグループ名を入力し、**[削除]** を選択します。複数のグループを削除する場合は、削除する IAM グループの数と **user groups** を入力し、**[削除]** を選択します。例えば、3 つのグループを削除する場合は、**3 **user groups**** を入力します。

------
#### [ AWS CLI ]

1. IAM グループからすべてのユーザーを削除します。
   + [aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html) (IAM グループ内のユーザーリストの取得)、および [aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html) (IAM グループからのユーザーの削除)

1. IAM グループに組み込まれたインラインポリシーをすべて削除します。
   + [aws iam list-group-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-group-policies.html) (IAM グループのインラインポリシーのリストの取得) および [aws iam delete-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-group-policy.html) (グループのインラインポリシーの削除)

1. IAM グループにアタッチされた管理ポリシーをすべてデタッチします。
   + [aws iam list-attached-group-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-group-policies.html) (IAM グループにアタッチされている管理ポリシーのリストの取得)、および [aws iam detach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-group-policy.html) (IAM グループからの管理ポリシーのデタッチ)

1. IAM グループを削除します。
   + [aws iam delete-group](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-group.html)

------
#### [ API ]

1. IAM グループからすべてのユーザーを削除します。
   + [GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html) (IAM グループ内のユーザーリストの取得) および [RemoveUserFromGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveUserFromGroup.html) (IAM グループからのユーザーの削除)

1. IAM グループに組み込まれたインラインポリシーをすべて削除します。
   + [ListGroupPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupPolicies.html) (IAM グループのインラインポリシーのリストの取得) および [DeleteGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroupPolicy.html) (IAM グループからのインラインポリシーの削除)

1. IAM グループにアタッチされた管理ポリシーをすべてデタッチします。
   + [ListAttachedGroupPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedGroupPolicies.html) (IAM グループにアタッチされている管理ポリシーのリストの取得) および [DetachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachGroupPolicy.html) (IAM グループからの管理ポリシーのデタッチ)

1. IAM グループを削除します。
   + [DeleteGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.html)

------

# IAM ロール
<a name="id_roles"></a>

IAM *ロール*は、特定の許可があり、アカウントで作成できるもう 1 つの IAM アイデンティティです。IAM ロールは、アイデンティティが AWS で実行できることとできないことを決定するアクセス許可ポリシーを持つ AWS アイデンティティであるという点で IAM ユーザーと似ています。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。また、ロールには標準の長期認証情報 (パスワードやアクセスキーなど) も関連付けられません。代わりに、ロールを引き受けると、ロールセッション用の一時的なセキュリティ認証情報が提供されます。

ロールを使用して、通常は AWS リソースへのアクセス権のないユーザー、アプリケーション、サービスにそのアクセス権を委任できます。例えば、AWS アカウントのユーザーに、通常はないリソースに対するアクセス許可を付与したり、ある AWS アカウント のユーザーに、別のアカウントのリソースに対するアクセス許可を付与したりできます。または、モバイルアプリに AWS リソースの使用を許可しても、(キーの更新が困難であり、ユーザーがキーの抽出を行える可能性がある) アプリへの AWS キーの埋め込みは禁止すべきである場合があります。AWS の外部 (社内ディレクトリなど) に ID をすでに持っているユーザーに AWS へのアクセスを許可することが必要になる場合があります。または、リソースを監査できるように、アカウントへのアクセス権を第三者に付与することが必要になる場合もあります。

これらのシナリオでは、*IAM ロール*を使用して AWS リソースにアクセスを委任できます。このセクションでは、ロールの概要とさまざまな使用方法、適切なアプローチを選択するタイミングと方法、ロールの作成、管理、切り替え（または引き受け）、削除を行う方法について説明します。

**注記**  
AWS アカウント を初めて作成するとき、デフォルトではロールは作成されません。アカウントにサービスを追加すると、そのユースケースをサポートするためにサービスにリンクされたロールが追加される場合があります。  
 サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。  
サービスにリンクされたロールを削除する前に、最初に関連するリソースを削除する必要があります。これにより、リソースにアクセスするための許可を意図せず削除することが防止され、 リソースが保護されます。  
サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[サービスにリンクされたロール]** 列が **[はい]** になっているサービスを検索してください。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。

**Topics**
+ [

## IAM ユーザーの作成が適している場合 (ロールではなく)
](#id_which-to-choose)
+ [

## ロールに関する用語と概念
](#id_roles_terms-and-concepts)
+ [

## その他のリソース
](#id_roles_additional-resources)
+ [

# 混乱する代理問題
](confused-deputy.md)
+ [

# IAM ロールによく見られるシナリオ
](id_roles_common-scenarios.md)
+ [

# IAM ロールの作成
](id_roles_create.md)
+ [

# IAM ロールの管理
](id_roles_manage.md)
+ [

# ロールを引き受けるための各種方法
](id_roles_manage-assume.md)

## IAM ユーザーの作成が適している場合 (ロールではなく)
<a name="id_which-to-choose"></a>

IAM ユーザーは、ID フェデレーションによってサポートされていないユースケースにのみ使用することをお勧めします。ユースケースには次のようなものがあります。
+ **IAM ロールを使用できないワークロード** – AWS へのアクセスが必要な場所から、ワークロードを実行する場合があります。状況によっては、IAM ロールを使用して WordPress プラグインなどに対して一時的な認証情報を提供することができない場合もあります。このような状況では、そのワークロードに対して IAM ユーザーの長期的なアクセスキーを使用して、AWS への認証を行います。
+ **サードパーティー AWS クライアント** – IAM Identity Center を使用したアクセスがサポートされていないツール (AWS でホストされていないサードパーティー AWS クライアントまたはベンダーなど) を使用している場合 は、IAM ユーザーの長期的なアクセスキーを使用します。
+ **AWS CodeCommit アクセス** — CodeCommit を使用してコードを保存している場合、CodeCommit の SSH キーまたはサービス固有の認証情報を持つ IAM ユーザーを使用して、リポジトリへの認証を行うことができます。通常の認証に IAM Identity Center のユーザーを使用することに加えて、これを行うことをお勧めします。IAM Identity Center のユーザーとは、お客様の AWS アカウント またはクラウドアプリケーションにアクセスする必要がある従業員のことです。IAM ユーザーを設定せずに CodeCommit リポジトリへのアクセス許可をユーザーに付与するには、**git-remote-codecommit** ユーティリティを設定します。IAM および CodeCommit の詳細については、「[CodeCommit の IAM 認証情報: Git 認証情報、SSH キー、および AWS アクセス キー](id_credentials_ssh-keys.md)」を参照してください。**git-remote-codecommit** ユーティリティの設定についての詳細は、*AWS CodeCommit ユーザーガイド*の「[認証情報のローテーションを使用した AWS CodeCommit リポジトリへの接続](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials)」を参照してください。
+ **Amazon Keyspaces (Apache Cassandra 向け) へのアクセス** – IAM Identity Center 内のユーザーを使用できない状況 (Cassandra との互換性をテストする場合など) では、サービス専用の認証情報を持つ IAM ユーザーを使用して Amazon Keyspaces で認証できます。IAM Identity Center のユーザーとは、お客様の AWS アカウント またはクラウドアプリケーションにアクセスする必要がある従業員のことです。一時的な認証情報を使用して Amazon Keyspaces に接続することもできます。詳細については、「*Amazon Keyspaces (Apache Cassandra 向け) デベロッパーガイド*」の「[一時的な認証情報を使用して IAM ロールと SigV4 プラグインを使用して Amazon Keyspaces に接続する](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM)」を参照してください。
+ **緊急アクセス** — ID プロバイダーにアクセスできない状況で、AWS アカウント のアクションを実行する必要がある場合。緊急アクセスの IAM ユーザーを設定することは、レジリエンス計画の一部となります。緊急時のユーザー認証情報は、多要素認証 (MFA) を使用して厳重に管理し、安全性を確保することをお勧めします。

## ロールに関する用語と概念
<a name="id_roles_terms-and-concepts"></a>

ロールの操作に役立つ基本的な用語を紹介します。

****ロール** **  
特定のアクセス権限を持ち、アカウントで作成できる IAM アイデンティティです。IAM ロールは、IAM ユーザーといくつかの類似点を持っています。ロールとユーザーは、両方とも、ID が AWS でできることとできないことを決定するアクセス許可ポリシーを持つ AWS ID です。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。また、ロールには標準の長期認証情報 (パスワードやアクセスキーなど) も関連付けられません。代わりに、ロールを引き受けると、ロールセッション用の一時的なセキュリティ認証情報が提供されます。  
ロールを割り当てできるのは、以下のものです。  
+ 同じ AWS アカウント または別の AWS アカウント 内の IAM ユーザー
+ 同じアカウント内の IAM ロール
+ サービスプリンシパル。AWS のサービスおよび機能で使用します。
  + Amazon EC2 や AWS Lambda などのコンピューティングサービスでコードを実行できるようにするサービス
  + Amazon S3 オブジェクトのレプリケーションなど、ユーザーに代わってリソースに対してアクションを実行する機能
  + IAM Roles Anywhere や Amazon ECS Anywhere など、AWS の外部で実行されるアプリケーションに一時的なセキュリティ認証情報を提供するサービス
+ SAML 2.0 または OpenID Connect と互換性のある外部 ID プロバイダー (IdP) サービスによって認証される外部ユーザー

****AWS サービス ** ロール**  
 サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「*IAM ユーザーガイド*」の「[AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。

****AWS サービスにリンクされたロール****  
 サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。  
サービスにリンクされたロールのサポートを開始する時点ですでにサービスを使用している場合は、アカウントの新しいロールに関する E メールが送信されることがあります。この場合、サービスにリンクされたロールは、サービスによって自動的にアカウントに作成されています。このロールをサポートするために必要な操作はありません。また、手動でロールを削除しないでください。詳細については、「[AWS アカウントに新しいロールが表示される](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared)」を参照してください。
サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[Service-Linked Role]** (サービスにリンクされたロール) 列が **[Yes]** (はい) になっているサービスを検索してください。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。詳細については、「[サービスにリンクされたロールの作成](id_roles_create-service-linked-role.md)」を参照してください。

****ロールの連鎖****  
ロールの連鎖は、 ロールを使用して 2 つ目のロールを引き受ける場合に発生します。ロール、AWS CLI、または API を切り替えることで、AWS マネジメントコンソール を介してロールの連鎖を実行できます。たとえば、`RoleA` には `RoleB` を引き受けるアクセス権があります。User1 は AssumeRole API オペレーションの長期的なユーザー認証情報を使用して `RoleA` を引き受けることができます。このオペレーションを用いて `RoleA` の短期的な認証情報を返します。ロールが連鎖していれば、User1 によって `RoleB` が引き受けられるよう `RoleA` の短期的な認証情報を使用できます。  
ロールを引き受けるときは、セッションタグを渡して、タグを推移的に設定できます。推移的なセッションタグは、ロールの連鎖内の後続のすべてのセッションに渡されます。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。  
ロールの連鎖では、AWS マネジメントコンソール、AWS CLI、 または AWS API ロールセッションが最長 1 時間に制限されます。これは、個々のロールに対して設定されている最大セッション期間に関係なく適用されます。[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーションを使用してロールを引き受ける場合は、`DurationSeconds` パラメータを使用してロールセッションの期間を指定できます。パラメータの値は、[ロールの最大セッション期間設定](id_roles_update-role-settings.md#id_roles_update-session-duration)によって、最大 43200 秒 (12 時間) まで指定できます。ただし、ロールの連鎖を使用してロールを引き受ける場合、`DurationSeconds` パラメータ値で 1 時間を超える値を指定すると、オペレーションは失敗します。  
AWS マネジメントコンソール でのロールの切り替えの詳細については、「[ユーザーから IAM ロールに切り替える (コンソール)](id_roles_use_switch-role-console.md)」を参照してください。

****委任****  
委任により、制御するリソースへのアクセスを許可するユーザーにアクセス許可を付与できます。委任には、2 つのアカウント間の信頼を設定することが含まれます。1 つ目は、リソースを所有するアカウント（信頼するアカウント）です。2 つ目は、リソース（信頼されたアカウント）にアクセスする必要があるユーザーを含むアカウントです。信頼するアカウントと信頼されたアカウントには、以下のいずれかを指定できます。  
+ 同じアカウント。
+ 組織の制御下にある別々のアカウント。
+ 異なる組織によって所有される 2 つのアカウント。
リソースにアクセスする権限を委任するには、2 つのポリシーがアタッチされた信頼されるアカウントの [IAM ロールを作成します](id_roles_create_for-user.md)。*アクセス許可ポリシー*は、リソースに対して目的のタスクを実行するために必要なアクセス許可をロールのユーザーに付与します。*信頼ポリシー*は、信頼されたアカウントのどのメンバーにロールを割り当てることができるかを指定します。  
信頼ポリシーを作成する際、プリンシパル要素およびプリンシパル要素内の ARN の一部としてワイルドカード (\$1) を指定することはできません。信頼ポリシーは、信頼するアカウントのロールにアタッチされ、アクセス許可の半分です。残りの半分は、[ユーザーがロールを切り替えることができる、またはロールを引き受けることができる](id_roles_use_permissions-to-switch.md)信頼されたアカウントのユーザーにアタッチされたアクセス許可ポリシーです。ロールを引き受けるユーザーの各自のアクセス権限は一時的に無効になりますが、その代わりにロールのアクセス権限を取得します。ユーザーがロールの使用を終了または停止すると、元のユーザーアクセス権限に戻ります。[外部 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) という追加パラメータは、同じ組織がコントロールしていないアカウント間でロールを安全に利用するのに役立ちます。

****信頼ポリシー****  
[JSON ポリシードキュメント](reference_policies_grammar.md)では、ロールを引き受けるために*信頼する*プリンシパルを定義します。ロール信頼ポリシーは、IAMのロールに関連付けられている必須の[リソースベースのポリシー](access_policies.md#policies_resource-based)です。信頼ポリシーで指定できる[プリンシパル](reference_policies_elements_principal.md)には、ユーザー、ロール、アカウント、およびサービスが含まれます。詳細については、「*AWS セキュリティブログ*」の「[IAM ロールで信頼ポリシーを使用する方法](https://aws.amazon.com/blogs//security/how-to-use-trust-policies-with-iam-roles/)」を参照してください。

****クロスアカウントアクセスのロール****  
あるアカウントのリソースに対するアクセス権限を、別のアカウントの信頼されるプリンシパルに付与するロール。クロスアカウントアクセスを許可する主な方法は、ロールを使用することです。ただし、一部の AWS サービスでは、リソースにポリシーを直接アタッチすることができます (ロールをプロキシとして使用する代わりに)。これらはリソースベースのポリシーと呼ばれ、別の AWS アカウント のプリンシパルにリソースへのアクセスを許可するために使用できます。これらのリソースには、Amazon Simple Storage Service (S3) バケット、Amazon Glacier ボールト、Amazon Simple Notification Service (SNS) トピック、Amazon Simple Queue Service (SQS) キューなどがあります。リソースベースのポリシーをサポートするサービスを確認するには､「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください｡ リソースベースのポリシーの詳細については、「[IAM でのクロスアカウントのリソースへのアクセス](access_policies-cross-account-resource-access.md)」を参照してください。

## その他のリソース
<a name="id_roles_additional-resources"></a>

以下のリソースは、IAM ロールに関連する IAM 用語の詳細を理解するのに役立ちます。
+ **プリンシパル**は、アクションを実行してリソースにアクセスできる AWS のエンティティです。プリンシパルは、AWS アカウントのルートユーザー、IAM ユーザー、またはロールをにすることができます。AWS サービスのアイデンティティを表すプリンシパルは、[サービスプリンシパル](reference_policies_elements_principal.md#principal-services)です。ロール信頼ポリシーのプリンシパル要素を使用して、ロールを引き受けると信頼するプリンシパルを定義します。

   ロールの引き受けを許可できるプリンシパルの詳細と例については、「[AWS JSON ポリシーの要素: Principal](reference_policies_elements_principal.md)」を参照してください。
+ **ID フェデレーション**は、外部 ID プロバイダーと AWS の間に信頼関係を作成します。既存の OpenID Connect (OIDC) または Security Assertion Markup Language (SAML) 2.0 プロバイダーを使用して、 AWS リソースにアクセスできるユーザーを管理できます。OIDC および SAML 2.0 を使用して、これらの外部 ID プロバイダーと AWS との信頼関係を設定する場合、ユーザーは IAM ロールに割り当てられます。ユーザーは一時的な認証情報を受け取り、これを使用して AWS リソースにアクセスすることもできます。

  フェデレーティッドプリンシパルの詳細については、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。
+ **フェデレーティッドプリンシパル**は、企業のユーザーディレクトリ、Directory Service からのOIDC プロバイダーの既存 ID です。[ID プロバイダー](id_roles_providers.md)を通じてアクセスがリクエストされると、AWS はフェデレーティッドプリンシパルにロールを割り当てます。

  SAML および OIDC のフェデレーティッドプリンシパルの詳細については、「[フェデレーションユーザーのセッションとロール](introduction_access-management.md#intro-access-roles)」を参照してください。
+ **アクセス許可ポリシー**は、ロールが使用できるアクションとリソースを定義するアイデンティティベースのポリシーです。ドキュメントは IAM ポリシー言語のルールに従って記述されます。

  詳細については、「[IAM JSON ポリシーリファレンス](reference_policies.md)」を参照してください。
+ **アクセス許可の境界**は、ポリシーを使用して、アイデンティティベースのポリシーがロールに付与できるアクセス許可の上限を設定する高度な機能です。アクセス許可の境界をサービスにリンクされたロールに適用することはできません。

  詳細については、「[IAM エンティティのアクセス許可境界](access_policies_boundaries.md)」を参照してください。

# 混乱する代理問題
<a name="confused-deputy"></a>

混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。これを防ぐために、サードパーティー (*クロスアカウント*) や 他の AWS サービス (*クロスサービス*)に対して、お客様のアカウント内のリソースへのアクセス権を提供してしまった場合に、お客様のアカウントの保護に役立つツールを AWS が提供します。

お客様の AWS リソースへのアクセス権をサードパーティーに付与 (委任) することが必要になる場合があります。例えば、Example Corp という第三者企業を雇って、コストを最適化するためにお客様の AWS アカウント をモニタリングする業務を依頼することにします。Example Corp がお客様の毎日の支出を追跡するには、お客様の AWS リソースにアクセスする必要があります。また、Example Corp は他の顧客について他の多くの AWS アカウント をモニタリングしています。IAM ロールを使用して AWS アカウント と Example Corp アカウントと間の信頼関係を確立できます。このシナリオで重要なのは、オプションの識別子としての*外部 ID* です。この ID を IAM ロールの信頼ポリシーで使用することで、ロールを引き受けることができるユーザーを指定できます。外部 ID の最も重要な機能は、混乱した代理問題の防止と対処です。

一部の AWS サービス (呼び出し元サービス) は、AWS サービスプリンシパルを使用して、他の AWS サービス (呼び出し先サービス) から AWS リソースにアクセスします。これらのサービスインタラクションの一部では、別の AWS アカウント で呼び出し先サービスからリソースと通信するように呼び出し元サービスを設定できます。これの例としては、別の AWS アカウント にある中央 Amazon S3 バケットに書き込むように AWS CloudTrail を設定することが挙げられます。呼び出し元のサービスである CloudTrail には、`cloudtrail.amazonaws.com` の allow ステートメントを追加することで、S3 バケットのポリシーを使用する S3 バケットへのアクセスが付与されます。

呼び出し元のサービスの AWS サービスプリンシパルが呼び出し先のサービスからリソースにアクセスしている場合、呼び出し先のサービスのリソースポリシーは、呼び出し元のサービスを設定したアクターではなく、AWS サービスプリンシパルのみを承認します。例えば、条件なしで CloudTrail サービスプリンシパルを信頼する S3 バケットは、信頼された管理者が設定した AWS アカウント から CloudTrail ログを受信できますが、Amazon S3 バケットの名前がわかっている場合は、AWS アカウント 内の不正なアクターから CloudTrail ログを受信することもできます。

混乱した代理問題は、アクターが AWS サービスのサービスプリンシパルの信頼を使用して、アクセスすることを意図していないリソースにアクセスする場合に発生します。

## クロスアカウントでの混乱した代理
<a name="mitigate-confused-deputy"></a>

次の図は、クロスアカウントでの「混乱した代理」問題を示しています。

![\[「混乱した代理」問題の説明\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/confuseddeputyproblem2.png)


このシナリオでは、次のことを前提としています。
+ **AWS1** はあなたの AWS アカウント。
+ **AWS1:ExampleRole** は、お客様のアカウントのロールである。このロールの信頼ポリシーは、Example Corp の AWS アカウントを、ロールを引き受けることができるアカウントとして指定することによって、Example Corp を信頼しています。

次の状況が発生します。

1. お客様は、Example Corp のサービスの使用を開始するとき、**AWS1:ExampleRole** の ARN を Example Corp に提供します。

1. Example Corp はそのロールの ARN を使用して、お客様の AWS アカウント のリソースにアクセスするために必要な一時的なセキュリティ認証情報を入手します。この方法では、お客様に代わって操作を実行できる "代理" として Example Corp を信頼します。

1. 別の AWS ユーザーも Example Corp のサービスを利用し始め、このユーザーも **AWS1:ExampleRole** の ARN を Example Corp が使用できるように提供するとします。この別のユーザーは、秘密ではない **AWS1:ExampleRole** を知った、または推測した可能性があります。

1. その別のユーザーが Example Corp に自分のアカウントの AWS リソース (そう自称しているリソース) へのアクセスを依頼すると、Example Corp は **AWS1:ExampleRole** を使用してお客様のアカウントのリソースにアクセスします。

このようにして、その別のユーザーはお客様のリソースに不正にアクセスできます。Example Corp は、この別のユーザーによって操られ、無意識にお客様のリソースにアクセスしたため、"混乱した代理" になります。

Example Corp は、ロールの信頼ポリシーに `ExternalId` の条件の確認を含めることを必須とすることで、「混乱した代理」問題に対応できます。Example Corp は、顧客ごとに一意の `ExternalId` 値を生成して、ロールを引き受けるリクエストでその値を使用します。`ExternalId` 値は、Example Corp の顧客の間で一意でなければならず、Example Corp の顧客ではなく、Example Corp によって管理されます。そのため、外部 ID は Example Corp から取得するものであり、自分では用意できません。これにより、Example Corp が混乱した代理人になることを防ぎ、別のアカウントの AWS リソースへのアクセスを許可してしまうことを防ぎます。

このシナリオでは、Example Corp がお客様に割り当てた一意の ID は 12345 であり、もう一方のお客様に割り当てた ID は 67890 であるとします。これらの ID は、このシナリオで使用することのみを目的としているため、簡略化されています。通常、これらの ID は GUID です。これらの ID が Example Corp の顧客の間で一意であることを考慮すると、これらの値を外部 ID として使用することは賢明です。

Example Corp はお客様に 12345 という外部 ID 値を提供します。お客様は、`Condition` 値が 12345 であることを必須とする以下のような [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-sts](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-sts) 要素をロールの信頼ポリシーに追加する必要があります。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}
```

------

このポリシーの Condition 要素により、AssumeRole API 呼び出しに 12345 という外部 ID 値が含まれている場合にのみ Example Corp はロールを引き受けることができます。Example Corp は、顧客に代わってロールを引き受けるたびに、その顧客の外部 ID 値を AssumeRole 呼び出しに含めます。別の顧客がお客様の ARN を Example Corp に提供した場合でも、Example Corp が AWS へのリクエストに含める外部 ID を顧客がコントロールすることはできません。これにより、権限のない顧客がお客様のリソースにアクセスすることを防止できます。

次の図は、このプロセスを示したものです。

![\[「混乱した代理」問題を解消する方法\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/confuseddeputymitigation2.png)


1. 前述と同様に、お客様は、Example Corp のサービスを利用し始めるとき、**AWS1:ExampleRole** の ARN を Example Corp に提供します。

1.  Example Corp がそのロールの ARN を使用して **AWS1:ExampleRole** ロールを引き受けるとき、Example Corp は AssumeRole API コールにお客様の外部 ID (12345) を含めます。この外部 ID はロールの信頼ポリシーと一致するため、AssumeRole API 呼び出しは正常に実行され、Example Corp はお客様の AWS アカウント のリソースにアクセスするための一時的なセキュリティ認証情報を取得します。

1. 別の AWS ユーザーも Example Corp のサービスを利用し始め、先ほどと同様、このユーザーも **AWS1:ExampleRole** の ARN を Example Corp が使用できるように提供するとします。

1. しかし、今回は、Example Corp が **AWS1:ExampleRole** ロールを引き受けるとき、もう一方のお客様に関連付けられている外部 ID (67890) が提供されます。その別の顧客がこの ID を変更することはできません。Example Corp がこれを行うのは、ロールを使用するリクエストがもう一方のお客様から来たからであり、67890 は Example Corp が業務を遂行する環境を示すからです。お客様は自身の外部 ID (12345) を使用する条件を **AWS1:ExampleRole** の信頼ポリシーに追加したため、AssumeRole API コールは失敗します。別の顧客がお客様のアカウントのリソースに不正にアクセスすることが防止されます (図の赤色の「X」で示しています)。

外部 ID により、Example Corp が他の顧客によって操られ、無意識にお客様のリソースにアクセスすることを防止します。

## サービス間の混乱した代理の防止
<a name="cross-service-confused-deputy-prevention"></a>

次の図は、CloudTrail と Amazon S3 のインタラクションの例を使用して、サービス間の混乱した代理問題を示しています。ここでは、権限のないアクターが、アクセス権が付与されていない Amazon S3 バケットに CloudTrail ログを書き込みます。

![\[権限のないアクターには、CloudTrail サービスプリンシパルを使用して、別のアカウントの Amazon S3 バケットへのアクセス権が付与されます。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/cross-service-confused-deputy1.png)


権限のないアクターが AWS プリンシパルの信頼を使用してリソースにアクセスできないように保護するために、AWS サービスプリンシパルには、代理で動作する AWS リソース、AWS アカウント、AWS 組織に関する情報があります。

この情報は、リソースポリシーで使用できるグローバル条件キー値、または AWS サービスプリンシパルによって行われたリクエストのリソースコントロールポリシーで使用できます。AWS サービスプリンシパルにリソースの 1 つにアクセスするためのアクセス許可が付与されている場合は、リソースポリシーで [aws:SourceArn](reference_policies_condition-keys.md#condition-keys-sourcearn)、[aws:SourceAccount](reference_policies_condition-keys.md#condition-keys-sourceaccount)、[aws:SourceOrgID](reference_policies_condition-keys.md#condition-keys-sourceorgid)、または [aws:SourceOrgPaths](reference_policies_condition-keys.md#condition-keys-sourceorgpaths) を使用することをお勧めします。これらの条件キーを使用すると、リソースポリシー、または リソースにアクセスする AWS サービスプリンシパルが、AWS リソース、AWS アカウント、または想定する AWS Organizations の代理で実行しているリソースコントロールポリシーでテストできます。
+ `aws:SourceArn` を使用して、AWS サービスプリンシパルが、特定の AWS CloudTrail 証跡や AppStream フリートなどの特定のリソースの代理としてリソースにアクセスできるようにします。
+ `aws:SourceAccount` を使用して、AWS サービスプリンシパルが特定の AWS アカウント の代理としてリソースにアクセスできるようにします。
+ `aws:SourceOrgID` を使用して、AWS サービスプリンシパルが特定の AWS Organizations の代理としてリソースにアクセスできるようにします。
+ `aws:SourceOrgPaths` を使用して、AWS サービスプリンシパルが特定の AWS Organizations パスの代理としてリソースにアクセスできるようにします。

次の図は、リソースが `aws:SourceAccount` グローバル条件コンテキストキーで設定されていて、別のアカウントの不正なアクターがアクセスすることを意図していない AWS リソースにアクセスしようとする、サービス間の混乱した代理シナリオを示しています。

![\[不正なアクターは、CloudTrail サービスプリンシパルを使用して、別のアカウントの Amazon S3 バケットへのアクセスを拒否されます。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/cross-service-confused-deputy2.png)


ポリシーで `aws:SourceArn`、`aws:SourceAccount`、`aws:SourceOrgID`、および `aws:SourceOrgPaths` グローバル条件キーを使用すると、サービスプリンシパルがユーザーの代理としてリソースにアクセスしていることを確認できます。これらの条件キーは、いずれかのリソースへのアクセスが AWS サービスプリンシパルに付与されるたびに使用することをお勧めします。

**注記**  
一部の AWS のサービス インタラクションには、ユーザーによるリソースへのアクセスをテストするサービス間の混乱した代理問題から保護するのに役立つ追加のコントロールがあります。例えば、KMS キー付与が AWS のサービス に発行されると、AWS KMS はリソースに関連付けられた暗号化コンテキストとキーのグラントを使用して、サービス間の混乱した代理問題から保護します。  
サービス間の混乱した代理リスクを回避するのに役立つサービス固有のメカニズム、および `aws:SourceArn`、`aws:SourceAccount`、`aws:SourceOrgID`、`aws:SourceOrgPaths` がサポートされるかどうかの詳細については、使用するサービスのドキュメントを参照してください。

## リソースベースのポリシーによるサービス間の混乱した代理保護
<a name="cross-service-confused-deputy-prevention-resource"></a>

次のポリシー例では、サービスプリンシパル AWS アカウント が 111122223333 に代わって動作している場合にのみ、サービスプリンシパル `cloudtrail.amazonaws.com` に Amazon S3 バケット arn:aws:s3:::amzn-s3-demo-bucket1 へのアクセスを許可します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CloudTrailAclCheck",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        },
        {
            "Sid": "AWSCloudTrailWrite",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/[optionalPrefix]/Logs/myAccountID/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        }
    ]
}
```

------

このバケットポリシーの例では、`aws:SourceArn` でフリート ARN を指定することで、指定された Amazon AppStream フリートに代わって動作している場合にのみ、s3://amzn-s3-demo-bucket2 内の powershell スクリプト examplefile.psh へのアクセスをサービスプリンシパル `appstream.amazonaws.com` に許可します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket2/examplefile.psh",
            "Condition": {
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/ExampleFleetName"
                } 
            }
        }
    ]
}
```

------

## リソースコントロールポリシーによるサービス間の混乱した代理保護
<a name="cross-service-confused-deputy-prevention-resource-control"></a>

リソースコントロールポリシー (RCP) を使用して、サポートされている AWS のサービス のリソースにサービス間の混乱した代理コントロールを適用できます。RCP を使用すると、サービス間の混乱した代理コントロールをリソースに一元的に適用できます。特定のリソースベースポリシーにステートメントを追加しなくても、組織内の AWS Organizations、組織単位 (OU)、または AWS アカウント にアタッチされた RCP で、`aws:SourceOrgId` や `aws:SourceOrgPaths` のような条件キーを使用できます。RPC とサポートされているサービスに関する詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。

次の RCP の例では、`aws:SourceOrgID` が o-ExampleOrg に相当する場合、メンバーアカウントの Amazon S3 バケットへの AWS サービスプリンシパルアクセスを拒否します。`SourceOrgID` が o-ExampleOrg に等しい AWS のサービス プリンシパルを許可するには、対応する許可が S3 バケットのリソースベースのポリシーに存在する必要があります

このポリシーは、`aws:SourceAccount` キーが存在するサービスプリンシパル (`"Bool": {"aws:PrincipalIsAWSService": "true"}`) によるリクエストに対してのみ、コントロールを適用します (`"Null": {"aws:SourceAccount": "false"}`)。これにより、この条件キーの使用を必要としないサービス統合とプリンシパルによる呼び出しは影響を受けません。`aws:SourceAccount` 条件キーがリクエストコンテキストに存在する場合、Null 条件は true に評価され、`aws:SourceOrgID` が強制適用されます。リクエストが組織に属さないアカウントからのものである場合でもコントロールが適用されるように、Null 条件演算子では `aws:SourceOrgID` ではなく `aws:SourceAccount` が使用されます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "RCPEnforceConfusedDeputyProtectionForS3",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:SourceOrgID": "o-ExampleOrg"
        },
        "Null": {
          "aws:SourceAccount": "false"
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "true"
        }
      }
    }
  ]
}
```

------

# IAM ロールによく見られるシナリオ
<a name="id_roles_common-scenarios"></a>

多くの AWS 機能と同様に、通常ロールを使用する方法には、IAM コンソールでインタラクティブに使用する方法と、AWS CLI、Tools for Windows PowerShell、API のいずれかを使用してプログラムで使用する方法の 2 つがあります。
+ IAM コンソールを使用するアカウントの IAM ユーザーは、別のロールに*切り替えて*、コンソールでそのロールのアクセス許可を一時的に使用できます。ユーザーは、元のアクセス権限を返却し、そのロールに割り当てられたアクセス権限を取得します。ユーザーがそのロールを終了すると、元のアクセス権限に戻ります。
+ アプリケーションまたは AWS によって提供されるサービス (Amazon EC2 など) は、AWS にプログラムによるリクエストを行うためのロールの一時的セキュリティ認証情報をリクエストすることで、ロールを*引き受ける*ことができます。ロールをこのように使用することで、リソースへのアクセスが必要なエンティティごとに長期的なセキュリティ認証情報を共有または保持する (IAM ユーザーを作成するなどして) 必要がなくなります。

**注記**  
このガイドでは、*ロールの切り替え*および*ロールの引き受け*という言葉を、ほとんど同じ意味で使用しています。

ロールを使用する最もシンプルな方法は、自分のアカウントまたは別の AWS アカウント 内に作成したロールに切り替えるアクセス許可を IAM ユーザーに付与する方法です。IAM ユーザーは、 コンソールを使用して簡単にロールを切り替え、通常は必要ないアクセス許可を使用することができます。その後、ロールを終了して、それらのアクセス許可を返却できます。これは、機密性の高いリソースに*誤って*アクセスしたり変更したりすることを回避するのに役立ちます。

アプリケーションとサービスへのアクセスを許可する (つまり、外部フェデレーションユーザー) など、ロールを複雑な方法で使用するには、`AssumeRole` API を呼び出します。この API 呼び出しは、アプリケーションが後続の API 呼び出しで使用できる一時的な認証情報のセットを返します。一時的な認証情報を使用して試行されたアクションは、関連付けられたロールによって付与されたアクセス権限のみを使用します。アプリケーションは、ユーザーがコンソールで行った方法でロールを "終了" する必要はありません。アプリケーションは一時的な認証情報を使用して停止し、元の認証情報で呼び出しを再開するだけです。

フェデレーティッドユーザーは、ID プロバイダー (IdP) から提供される認証情報を使用してサインインします。その後、AWS は一時的な認証情報を信頼された IdP に提供し、後続の AWS リソースリクエストに含めることができるようにユーザーに渡します。これらの認証情報は、割り当てられたロールに付与されたアクセス権限を提供します。

このセクションは、次のシナリオの概要を提供します。
+ [ユーザーが所有する別のアカウントのリソースにアクセスできるように、ユーザーが所有する 1 つの AWS アカウント の IAM ユーザーにアクセスを許可する](id_roles_common-scenarios_aws-accounts.md)
+ [AWS ワークロード以外へのアクセスを提供する](id_roles_common-scenarios_non-aws.md)
+ [サードパーティーが所有する AWS アカウント の IAM ユーザーへのアクセスを許可する](id_roles_common-scenarios_third-party.md)
+ [AWS が提供するサービスに AWS リソースへのアクセスを許可する](id_roles_common-scenarios_services.md)
+ [外部で認証された (ID フェデレーション) ユーザーにアクセスを許可する](id_roles_common-scenarios_federated-users.md)

# 所有している別の AWS アカウント内の IAM ユーザーに対するアクセス
<a name="id_roles_common-scenarios_aws-accounts"></a>

IAM ユーザーには、AWS アカウント 内のロール、または所有する他の AWS アカウント で定義されたロールに切り替えるアクセス許可を付与することができます。

**注記**  
お客様が所有または制御していないアカウントへのアクセス権を付与する場合は、このトピックの「[第三者が所有する AWS アカウント へのアクセス](id_roles_common-scenarios_third-party.md)」を参照してください。

組織の業務に不可欠な Amazon EC2 インスタンスがあるとします。このインスタンスを終了するためのアクセス許可をユーザーに直接付与する代わりに、これらの権限を持つロールを作成できます。次に、インスタンスを終了する必要があるときに、このロールに切り替えることを管理者に許可します。これにより、インスタンスに次の保護レイヤーが追加されます。
+ ユーザーにロールを引き受けるアクセス権限を明示的に付与する必要があります。
+ ユーザーは、アクティブに AWS マネジメントコンソール を使用してロールに切り替えるか、AWS CLI または AWS API を使用してロールを引き受ける必要があります。
+ MFA デバイスでサインインしているユーザーのみがロールを引き受けることができるように、ロールに多要素認証 (MFA) 保護を追加できます。ロールを引き受けるユーザーが最初に多要素認証 (MFA) を使用して認証されるようにロールを設定する方法については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。

このアプローチを使用して*最小権限の原則*を強制することをお勧めします。つまり、昇格されたアクセス許可の使用は、特定のタスクに必要なときのみに制限されます。ロールを使用すると、機密性の高い環境が誤って変更されるのを防ぐことができます (特に、ロールが必要なときだけ使用されるように[監査](cloudtrail-integration.md)と組み合わせている場合)。

この目的でロールを作成する場合、ユーザーがロールの信頼ポリシーの `Principal` 要素にアクセスする必要のあるアカウントを ID で指定します。その後、その他のアカウントの特定のユーザーに、そのロールに切り替えるためのアクセス権限を付与できます。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。

あるアカウントのユーザーは、同じアカウントまたは別のアカウントのロールに切り替えることができます。そのロールを使用している間、ユーザーはアクションだけを実行して、ロールによって許可されているリソースのみにアクセスできますが、元のユーザーアクセス権限は停止されます。ユーザーがそのロールを終了すると、元のユーザーのアクセス権限に戻ります。

## 個別の開発用アカウントと本稼働用アカウントを使用したシナリオ例
<a name="id_roles_common-scenarios_aws-accounts-example"></a>

本稼働環境から開発環境を分離するための複数の AWS アカウント が組織に存在するとします。開発アカウントのユーザーは、本番稼働用アカウントでリソースにアクセスすることが必要になる場合があります。たとえば、開発環境から本番稼働環境に更新を昇格させる場合、クロスアカウントアクセスが必要になることがあります。両方のアカウントで作業するユーザーにそれぞれの ID（およびパスワード）を作成することも可能ですが、複数のアカウントに対する複数の認証情報を管理する必要があり、ID 管理が困難になります。以下の図では、すべてのユーザーは開発用アカウントで管理されていますが、数名の開発者は本稼働用アカウントに制限付きでアクセスする必要があります。開発用アカウントにはテスターと開発者の 2 つのグループがあり、それぞれ個別のポリシーがあります。

![\[ロールを使用して別のアカウントのユーザーにアクセス権限を委任する\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)


1. 管理者は、本番稼働用アカウントで IAM を使用し、このアカウントで `UpdateApp` ロールを作成します。ロールでは、管理者は開発用アカウントを `Principal` として指定する信頼ポリシーを定義します。これは、開発用アカウントの認証されたユーザーが `UpdateApp` ロールを使用できることを意味します。また、管理者は、`productionapp` という Amazon S3 バケットに対する読み取りと書き込みを指定するロールについてのアクセス許可ポリシーを定義します。

   次に、管理者は、このロールを引き受ける必要がある任意のユーザーと該当情報を共有します。この情報は、ロールのアカウント番号と名前 (AWS コンソールユーザーの場合)、または Amazon リソースネーム (ARN) (AWS CLI または AWS API アクセスの場合) です。ロールの ARN は `arn:aws:iam::123456789012:role/UpdateApp` のようになります。これは、ロールの名前が `UpdateApp` で、ロールがアカウント番号 123456789012 に作成されたことを意味します。
**注記**  
管理者は、ロールを引き受けるユーザーが最初に多要素認証 (MFA) を使用して認証されるように、オプションでロールを設定できます。詳細については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。

1. 開発アカウントでは、管理者は開発者グループのメンバーに対して、このロールに切り替えるアクセス許可を付与します。これは、Developers グループに AWS Security Token Service（AWS STS）`UpdateApp` ロールの `AssumeRole` API を呼び出すアクセス権限を付与することで行われます。これにより、開発用アカウントの Developers グループに所属する IAM ユーザーは、本稼働用アカウントの `UpdateApp` ロールに切り替えることができます。Developers グループに所属しないの他のユーザーには、そのロールに切り替えるアクセス許可がないため、本番稼働用アカウントの S3 バケットにはアクセスできません。

1. ユーザーは、ロールへの切り替えをリクエストします。
   + AWS コンソール: ユーザーはナビゲーションバーのアカウント名を選択してから、[**ロールの切り替え**] を選択します。ユーザーは、アカウント ID（またはエイリアス）とロール名を指定します。または、管理者からメールで送信されたリンクをクリックすることもできます。リンクをクリックすると、詳細がすでに入力された [**ロールの切り替え**] ページに移動します。
   + AWS API/AWS CLI: 開発用アカウントの Developers グループに所属するユーザーが `AssumeRole` 関数を呼び出し、`UpdateApp` ロールの認証情報を取得します。呼び出しの一部として、ユーザーが `UpdateApp` ロールの ARN を指定します。Testers グループのユーザーが同じ要求をしても、テスターは `UpdateApp` ロールの ARN に対して `AssumeRole` を呼び出すことは許可されていないため、その要求は拒否されます。

1. AWS STS が一時的な認証情報を返します。
   + AWS コンソール: AWS STS はリクエストをロールの信頼ポリシーと照合し、そのリクエストが信頼されたエンティティ (開発用アカウント) からであることを確認します。照合の後、AWS STS は AWS コンソールに[一時的セキュリティ認証情報](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)を返します。
   + API/CLI: AWS STS は、リクエストをロールの信頼ポリシーと照合し、信頼されたエンティティ (Development アカウント) からであることを確認します。照合の後、AWS STS はアプリケーションに[一時的セキュリティ認証情報](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)を返します。

1. 一時的な認証情報により、AWS リソースにアクセスすることができます。
   + AWS コンソール: AWS コンソールは、後続のすべてのコンソールアクション (この場合は、`productionapp` バケットの読み書き) でユーザーの代わりに一時的な認証情報を使用します。コンソールは、本稼働用アカウントにある他のリソースにはアクセスできません。ユーザーがロールを終了すると、ユーザーのアクセス権限がロールに切り替える前に持っていた元のアクセス権限に戻ります。
   + API/CLI: アプリケーションは、その一時的な認証情報を使用して `productionapp` バケットを更新します。一時的な認証情報を使用し、アプリケーションは `productionapp` バケットでのみ読み書きを行うことができますが、本番稼働用アカウントにあるその他のリソースにはアクセスできません。アプリケーションは、ロールを終了する必要はありませんが、その代わりに一時的な認証情報の使用を停止し、後続の API 呼び出しで元の認証情報の使用する必要があります。

## その他のリソース
<a name="id_roles_common-scenarios_more-info"></a>

詳細については次を参照してください:
+ [IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](tutorial_cross-account-with-roles.md)

# AWS 以外のワークロードに対するアクセス
<a name="id_roles_common-scenarios_non-aws"></a>

[IAM ロール](id_roles.md)は、[アクセス許可](access_policies.md)が割り当てられている AWS Identity and Access Management IAM 内のオブジェクトです。IAMの ID または AWS 外部からの ID を使用して[そのロールを引き受ける](id_roles_manage-assume.md)と、ロールセッションのための一時的なセキュリティ認証情報が提供されます。データセンターや AWS 以外のインフラストラクチャで実行されるワークロードが、AWS リソースにアクセスしなければならない場合があります。長期的なアクセスキーを作成、配布、管理する代わりに、AWS Identity and Access Management Roles Anywhere (IAM Roles Anywhere) を使用して AWS 以外のワークロードを認証することができます。IAM Roles Anywhere は、認証局 (CA) から発行された X.509 証明書を使用して ID を認証し、IAM ロールによって提供される一時的な認証情報を使用した AWS のサービス への安全なアクセスを提供します。

**IAM Roles Anywhere を使用するには**

1. [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) を使用して CA を設定するか、独自の PKI インフラストラクチャの CA を使用します。

1. CA を設定したら、IAM Roles Anywhere にトラストアンカーと呼ばれるオブジェクトを作成します。このアンカーは、IAM Roles Anywhere と CA との間に認証目的で信頼を確立します。

1. その後、既存の IAM ロールを設定するか、IAM Roles Anywhere サービスを信頼する新しいロールを作成できます。

1. トラストアンカーを使用して IAM Roles Anywhere で AWS 以外のワークロードを認証します。AWS は AWS リソースへのアクセスが許可された IAM ロールに対し、AWS 以外のワークロードの一時的な認証情報を付与します。

## 追加リソース
<a name="id_roles_non-aws_additional_resources"></a>

AWS 以外のワークロードへのアクセスを提供する方法について詳しく知りたい場合は、以下のリソースを参考にすると便利です。
+ IAM Roles Anywhere の設定の詳細については、「*IAM Roles Anywhere User Guide*」(IAM Roles Anywhere ユーザーガイド) の「[What is AWS Identity and Access Management Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)」( Roles Anywhere とは) を参照してください。
+ IAM Roles Anywhere のパブリックキーインフラストラクチャ (PKI) を設定する方法については、「AWS セキュリティブログ」の「[IAM Roles Anywhere with an external certificate authority](https://aws.amazon.com/blogs/)」を参照してください。

# 第三者が所有する AWS アカウント へのアクセス
<a name="id_roles_common-scenarios_third-party"></a>

組織内の AWS リソースへ組織外の第三者がアクセスする必要がある場合には、ロールを使用することでアクセス許可を委任することができます。たとえば、組織内の AWS リソースの管理を第三者へ委託しているような場合が相当します。IAM ロールを使用することで、AWS セキュリティ認証情報を共有することなく第三者に AWS リソースへのアクセスを許可することができます。第三者は代わりに、AWS アカウント に作成したロールを引き受けることで、AWS リソースにアクセスできます。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。

第三者は、以下の情報を提供する必要があります。これらの情報は、第三者が引き受けることのできるロールの作成に必要です。
+ **第三者の AWS アカウント ID**。ロールの信頼ポリシーを定義するときは、その AWS アカウント ID をプリンシパルとして指定します。
+ **ロールを一意に関連付けるための外部 ID**。外部 ID は、ユーザーと第三者によってのみ識別される識別子です。たとえば、ユーザーとサードパーティーの間の請求書 ID は使用できますが、サードパーティーの名前や電話番号などの推測できるものは使用しないでください。ロールの信頼ポリシーを定義するときは、この ID を指定する必要があります。サードパーティーは、ロールを引き受けるときに、この ID を指定する必要があります。
+ **第三者が AWS リソースでの作業を行うのに必要なアクセス許可**。ロールのアクセス許可ポリシーを定義する際に、権限を指定する必要があります。このポリシーには、第三者はどのアクションができるのか、およびどのリソースにアクセスできるのかが定義されています。

ロールの作成が完了したら、そのロールの Amazon リソースネーム（ARN）を対象の第三者に提供します。第三者がロールを担当するにあたり、このロールの ARN を必要とします。

**重要**  
お客様の AWS リソースへのアクセスを第三者に許可すると、第三者はポリシーで指定したすべてのリソースにアクセスできます。サードパーティーによるリソースの使用は、ユーザーに請求されます。したがって、第三者によるリソースの使用については適切な制限を設けるようにしてください。

## 第三者によるアクセスのための外部 ID
<a name="id_roles_third-party_external-id"></a>

外部 ID を使用すると、ロールを引き受けるユーザーは、業務を遂行する環境へのアクセスをリクエストできます。また、アカウント所有者が、特定の環境においてのみロールを引き受けることができるようにする方法の 1 つでもあります。外部 ID の最も重要な機能は、[混乱する代理問題](confused-deputy.md) の防止と対処です。

**重要**  
AWS は、外部 ID を機密情報として扱いません。アクセスキーペアやパスワードなどの機密情報を AWS で作成した場合、それらを再び表示することはできません。ロールの外部 ID は、ロールを表示する権限を持つすべてのユーザーが表示できます。

## 外部 ID が適している状況
<a name="external-id-use"></a>

外部 ID は以下の状況で使用します。
+ お客様は AWS アカウント の所有者で、それ以外の AWS アカウント アカウントにアクセスするロールを第三者のために設定しました。第三者がお客様のロールを引き受けるときに含める外部 ID は、第三者に問い合わせる必要があります。その後、ロールの信頼ポリシーでその外部 ID を確認します。これにより、外部の第三者は、お客様に代わって操作を行う場合にのみ、お客様のロールを引き受けることができます。
+ お客様は、前のシナリオの Example Corp のように、さまざまな顧客に代わってロールを引き受ける立場にあります。各顧客に一意の外部 ID を割り当て、ロールの信頼ポリシーに外部 ID を追加するように指示します。ロールを引き受けるには、リクエストに正しい外部 ID が常に含まれていることを確認する必要があります。

  既にそれぞれの顧客に一意の ID を割り当てている場合は、この一意の ID を外部 ID として使用できます。外部 ID は、この目的のためだけに明示的に作成したり個別に追跡したりする必要のある特別な値ではありません。

  外部 ID は常に `AssumeRole` API 呼び出しで指定する必要があります。さらに、顧客からロールの ARN を受け取ったら、正しい外部 ID と正しくない外部 ID の両方を使用して、そのロールを引き受けることができるかどうかをテストします。正しい外部 ID がなくてもロールを引き受けることのできる場合は、システムに顧客のロール ARN を保存しないでください。顧客がロール信頼ポリシーを更新し、正しい外部 ID を要求するまで待ちます。こうすることにより、顧客による不正を防止し、"混乱した代理" 問題からお客様と顧客の両方を守ることができます。

## 外部 ID を使用したシナリオの例
<a name="id_roles_third-party_example"></a>

例えば、Example Corp という第三者企業を雇って、コストを最適化するためにお客様の AWS アカウント をモニタリングする業務を依頼するとします。Example Corp がお客様の毎日の支出を追跡するには、お客様の AWS リソースにアクセスする必要があります。また、Example Corp は他の顧客について他の多くの AWS アカウントをモニタリングしています。

Example Corp に AWS アカウントの IAM ユーザーとのその長期的認証情報へのアクセスを許可しないでください。代わりに、IAM ロールとその一時的なセキュリティ認証情報を使用します。IAM ロールは、第三者が長期的認証情報 (IAM ユーザーアクセスキーなど) を共有することなくお客様の AWS リソースにアクセスできるようにするメカニズムです。

IAM ロールを使用して AWS アカウント と Example Corp アカウントと間の信頼関係を確立できます。この関係が確立されると、Example Corp アカウントのメンバーは、AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API を呼び出して、一時的セキュリティ認証情報を取得できます。次に、Example Corp のメンバーは、この認証情報を使用してアカウントの AWS リソースにアクセスできます。

**注記**  
一時的セキュリティ認証情報を取得するために呼び出すことのできる AssumeRole とその他の AWS API オペレーションの詳細については、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。

このシナリオの詳細は以下のとおりです。

1. お客様は Example Corp を雇うとします。Example Corp はお客様の一意の顧客 ID を作成します。Example Corp はその一意の顧客 ID と Example Corp の AWS アカウント 番号をお客様に提供します。この情報は次の手順でお客様が IAM ロールを作成するために必要になります。
**注記**  
Example Corp は、顧客ごとに一意である限り、任意の文字列値を ExternalId に使用できます。顧客のアカウント番号を使用することもできますし、ランダムな文字列でもかまいません。ただし、2 つの顧客に同じ値を使用することはできません。「シークレット」することを意図したものではありません。Example Corp は、顧客ごとに ExternalId 値を指定する必要があります。重要なのは、各外部IDがユニークであることを確認するために、お客様**によってではなく**、Example Corp によって生成される必要があるということです。

1. お客様は AWS にサインインし、お客様のリソースへのアクセス権を Example Corp に付与する IAM ロールを作成します。他の IAM ロールと同様に、このロールにも 2 つのポリシー (アクセス許可ポリシーと信頼ポリシー) があります。ロールの信頼ポリシーでは、だれがこのロールを引き受けることができるかを指定します。このサンプルシナリオでは、ポリシーで `Principal` として Example Corp の AWS アカウント 番号を指定します。これにより、そのアカウントの ID はロールを引き受けることができるようになります。さらに、信頼ポリシーに `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` 要素を追加します。この `Condition` は `ExternalId` コンテキストキーをテストして、その要素が Example Corp の一意の顧客 ID に一致するようにします。その例を示します。

   ```
       "Principal": {"AWS": "Example Corp's AWS アカウント ID"},
       "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
   ```

1. ロールのアクセス許可ポリシーでは、ロールがだれに何を許可するかを指定します。たとえば、お客様の Amazon EC2 と Amazon RDS のリソースのみを管理でき、お客様の IAM ユーザーまたはグループは管理できないようにロールを指定できます。サンプルシナリオでは、アクセス許可ポリシーを使用して、お客様のアカウントのすべてのリソースに対する読み取り専用アクセス権を Example Corp に付与します。

1. ロールの作成が完了したら、そのロールの Amazon リソースネーム（ARN）を Example Corp に提供します。

1. Example Corp がお客様の AWS リソースに対するアクセス許可を必要とするとき、Example Corp の担当者が AWS `sts:AssumeRole` API を呼び出します。この呼び出しには、引き受けるロールの ARN とお客様の顧客 ID に対応する ExternalId パラメータが含まれています。

リクエスト元が Example Corp の AWS アカウント であり、ロール ARN と外部 ID が正しい場合、リクエストは成功します。次に、一時的なセキュリティ認証情報が提供されます。Example Corp はその情報を使用して、お客様のロールが許可している AWS リソースにアクセスできます。

つまり、ロールのポリシーに外部 ID が含まれている場合、そのロールを引き受けるユーザーは、ロールでプリンシパルであり、正しい外部 ID を指定する必要があります。

## 外部 ID の重要なポイント
<a name="id_roles_third-party_key-points"></a>
+ 異なる AWS で複数の顧客をサポートするマルチテナント環境では、AWS アカウント アカウントごとに 1 つの外部 ID を使用することをお勧めします。この ID は、サードパーティーによって生成されたランダムな文字列である必要があります。
+ ロールを引き受けるときにサードパーティーが外部 ID を提供することを要求するには、ロールの信頼ポリシーを選択した外部 ID で更新します。
+ ロールを引き受けるときに外部 ID を提供するには、AWS CLI または AWS API を使用してそのロールを引き受けます。詳細については、「STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーション」または「STS [assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI オペレーション」を参照してください。
+ `ExternalId` の値は、2～1,224 文字で構成されている必要があります。この値は、空白のない英数字にする必要があります。次の記号を含めることもできます。プラス記号 (\$1)、等号 (=)、カンマ (,)、ピリオド (.)、アットマーク (@)、コロン (:)、スラッシュ (/)、およびハイフン (–)。

## その他のリソース
<a name="id_roles_third-party_additional_resources"></a>

第三者が所有する AWS アカウントへのアクセスを提供する方法について詳しく知りたい場合は、以下のリソースを参考にすると便利です。
+ AWS アカウント内で他のユーザーがアクションを実行できるようにする方法については、「[カスタム信頼ポリシーを使用してロールを作成する](id_roles_create_for-custom.md)」を参照してください。
+ ロールを切り替えるアクセス許可を付与する方法については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。
+ 信頼できるユーザーを作成して一時的なセキュリティ認証情報を提供する方法については、「[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)」を参照してください。

# AWS サービスへのアクセス
<a name="id_roles_common-scenarios_services"></a>

多くの AWS のサービスでは、ロールを使用して、そのサービスがアクセスできものを制御する必要があります。サービスがお客様に代わってアクションを実行するために引き受けるロールは、[サービスロール](id_roles.md#iam-term-service-role)と呼ばれます。ロールにサービスに対して特殊な目的がある場合、そのロールは[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)として分類できます。特定のサービスがロールを使用するかどうかと、使用するサービスのロールを割り当てる方法については、各サービスの [AWS ドキュメント](https://docs.aws.amazon.com/)を参照してください。

AWS が提供するサービスへのアクセスを委任するロールの作成については、「[AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)」を参照してください。

# 外部で認証されたユーザーへのアクセス (ID フェデレーション)
<a name="id_roles_common-scenarios_federated-users"></a>

社内のディレクトリなど、AWS 以外の ID をユーザーがすでに持っているとします。それらのユーザーが AWS リソースを使用する (または、それらのリソースにアクセスするアプリケーションを使用する) 必要がある場合、それらのユーザーには AWS セキュリティ認証情報も必要です。IAM ロールを使用して、ID が組織または第三者のプロバイダー (IdP) からフェデレーションされたユーザーのアクセス許可を指定できます。

**注記**  
セキュリティ上のベストプラクティスとして、IAM ユーザーを作成する代わりに、ID フェデレーションを使用して [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html) でユーザーアクセスを管理することをお勧めします。IAM ユーザーが必要な特定の状況についての情報は、「[IAMユーザー (ロールの代わりに) を作成する場合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)」を参照してください。

## Amazon Cognito を使用したモバイルまたはウェブベースのアプリのユーザーのフェデレーション
<a name="id_roles_common-scenarios_federated-users-cognito"></a>

AWS リソースにアクセスするモバイルまたはウェブベースのアプリを作成する場合、アプリが AWS にプログラムによるリクエストを送るには認証情報が必要になります。ほとんどのモバイルアプリケーションのシナリオでは、[Amazon Cognito](https://aws.amazon.com/cognito/) の使用をお勧めします。このサービスを [AWS Mobile SDK for iOS](https://aws.amazon.com/sdkforios/) および [AWS Mobile SDK for Android and Fire OS](https://aws.amazon.com/sdkforandroid/) で使用して、ユーザーの一意のIDを作成し、AWS リソースへの安全なアクセスのためにユーザーを認証できます。Amazon Cognito では、次のセクションに示されているのと同じ ID プロバイダーがサポートされます。さらに、[開発者が認証した ID](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities) と認証されていない (ゲスト) アクセスもサポートされます。また、Amazon Cognito には、ユーザーがデバイスを変えてもデータが保持されるように、ユーザーデータを同期するための API オペレーションも用意されています。詳細については、「[モバイルアプリのための Amazon Cognito](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito)」を参照してください。

## パブリック ID サービスプロバイダーまたは OpenID Connect を使用したユーザーのフェデレーション
<a name="id_roles_common-scenarios_federated-users-openId"></a>

可能な限り、モバイルおよびウェブベースのアプリケーションシナリオで Amazon Cognito を使用してください。Amazon Cognito は、パブリック ID プロバイダーサービスを使用する際の裏方作業をほとんど行います。同じサードパーティのサービスで機能し、また匿名サインインもサポートしています。ただし、より高度なシナリオでは、OpenID Connect (OIDC) と互換性がある Login with Amazon、Facebook、Google、その他 IdP でのログインなど、サードパーティのサービスを直接使用できます。これらのサービスを使用した OIDC フェデレーションの使用についての詳細は、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。

## SAML 2.0 を使用したユーザーのフェデレーション
<a name="id_roles_common-scenarios_federated-users-saml20"></a>

組織が既に SAML 2.0 (Security Assertion Markup Language 2.0) をサポートする ID プロバイダーソフトウェアパッケージを使用している場合、ID プロバイダー (IdP) としての組織と、サービスプロバイダーとしての AWS との間に信頼を作成できます。その後、SAML を使用して、AWS マネジメントコンソール へのフェデレーティッドシングルサインオン (SSO) または AWS API オペレーションを呼び出すためのフェデレーションアクセスをユーザーに許可できます。たとえば、社内で Microsoft Active Directory と Active Directory Federation Services を使用している場合は、SAML 2.0 を使用してフェデレーションが可能です。SAML 2.0 を使用したユーザーのフェデレーション方法の詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。

## カスタム ID ブローカーアプリケーションを作成するユーザーのフェデレーション
<a name="id_roles_common-scenarios_federated-users-idbroker"></a>

ID ストアに SAML 2.0 との互換性がない場合、カスタム ID ブローカーアプリケーションを作成して同じような機能を実行できます。ブローカーアプリケーションはユーザーを認証し、そのユーザー用に一時的な認証情報を AWS に要求して、それをユーザーに提供し AWS リソースにアクセスできるようにします。

たとえば、Example Corp. には、会社の AWS リソースにアクセスする社内アプリケーションを実行する必要のある従業員が多数います。従業員は、会社の ID および認証システムに既に ID があり、従業員ごとに別の IAM ユーザーを作成することは望ましくありません。

Bob は Example Corp の開発者です。Example Corp の社内アプリケーションで会社の AWS リソースにアクセスできるようにするために、カスタム ID ブローカーアプリケーションを開発しています。このアプリケーションは、従業員が Example Corp. の既存の ID および認証システムにサインインしていることを確認します。これには、LDAP や Active Directory などのシステムを使用している可能性があります。ID ブローカーアプリケーションは、従業員の一時的なセキュリティ認証情報を取得します。このシナリオは、前のシナリオ（カスタム認証システムを使用するモバイルアプリ）に似ています。ただし、AWS リソースにアクセスする必要のあるアプリケーションはすべて企業ネットワーク内で実行され、会社には既存の認証システムがあります。

一時的なセキュリティ認証情報を取得するために、ID ブローカーアプリケーションは、ユーザーのポリシーの管理方法と一時的な認証情報の有効期限に応じて、`AssumeRole` または `GetFederationToken` を呼び出して、一時的なセキュリティ認証情報を取得します (これらの API オペレーションの違いの詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」および「[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)」を参照してください)。この呼び出しは、AWS アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成される一時的なセキュリティ認証情報を返します。ID ブローカーアプリケーションは、これらの一時的なセキュリティ認証情報を社内アプリケーションで使用できるようにします。アプリは、一時的な認証情報を使用して AWS を直接呼び出すことができます。アプリは、認証情報をキャッシュし、有効期限が切れると、新しい一時的な認証情報をリクエストします。このシナリオを以下に図で示します。

![\[カスタム ID ブローカーアプリケーションを使用したワークフローの例\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)


このシナリオには次の属性があります。
+ ID ブローカーアプリケーションには、一時的なセキュリティ認証情報を作成するために IAM のトークンサービス (STS) API にアクセスする権限があります。
+ ID ブローカーアプリケーションが、従業員が既存の認証システム内で認証されていることを確認できます。
+ ユーザーは、AWS マネジメントコンソールへのアクセスを与える一時的な URL を入手できます（これはシングルサインオンと呼ばれています）。

一時的なセキュリティ認証情報の作成方法の詳細については、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。AWS マネジメントコンソールへのアクセスを取得する SAML フェデレーティッドプリンシパルの詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。

# IAM ロールの作成
<a name="id_roles_create"></a>

ロールを作成するには、AWS マネジメントコンソール、AWS CLI、Tools for Windows PowerShell、または IAM API を使用できます。

AWS マネジメントコンソールを使用する場合は、ウィザードを使用し、一連のステップに従ってロールを作成できます。AWS サービス、AWS アカウント、SAML または OIDC のフェデレーティッドプリンシパルのいずれか向けにロールを作成するかにより、ウィザードの手順が多少異なります。

**IAM ユーザーに対するロール**  
自分の AWS アカウント内か、自分が所有する他の AWS アカウントに定義されているロールにアクセス許可を委任する場合に、このロールを作成します。あるアカウントのユーザーは、同じアカウントまたは別のアカウントのロールに切り替えることができます。そのロールを使用している間、ユーザーはアクションだけを実行して、ロールによって許可されているリソースのみにアクセスできますが、元のユーザーアクセス権限は停止されます。ユーザーがそのロールを終了すると、元のユーザーのアクセス権限に戻ります。

詳細については、「[IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)」を参照してください。

クロスアカウントアクセス用のロールの作成の詳細については、「[カスタム信頼ポリシーを使用してロールを作成する](id_roles_create_for-custom.md)」を参照してください。

**AWS サービスに対するロール**  
自分に代わってアクションを実行できるサービスにアクセス許可を委任する場合に、このロールを作成します。[サービスロール](id_roles.md#iam-term-service-role)をサービスに渡す場合は、そのロールの IAM ポリシーにアクセス許可を設定して、サービスが自身に関連付けられているアクションを実行できるようにします。AWS サービスごとに異なるアクセス許可が必要です。

サービスロールの作成の詳細については、「[AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)」を参照してください。

サービスにリンクされたロールの作成の詳細については、「[サービスにリンクされたロールの作成](id_roles_create-service-linked-role.md)」を参照してください。

**ID フェデレーションに対するロール**  
AWS の外部に既に ID を持っているユーザーにアクセス許可を委任する場合に、このロールを作成します。ID プロバイダーを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要がありません。外部ユーザーは IdP を使用してサインインします。これらの外部 ID に、アカウントの AWS リソースを使用するアクセス許可を与えることができます。ID プロバイダーは、アプリケーションと共にアクセスキーのような長期的セキュリティ認証情報を配布したり埋め込んだりする必要がないので、AWS アカウントの安全性の維持に役立ちます。

詳細については、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」を参照してください。

# IAM ユーザーにアクセス許可を付与するロールを作成する
<a name="id_roles_create_for-user"></a>

IAM ロールを使用することで、お客様の AWS リソースに対するアクセス許可を提供できます。IAM ロールにより、お客様の*信頼する*アカウントと他の AWS *信頼される* アカウントとの信頼関係を確立できます。信頼するアカウントは、アクセスされるリソースを所有し、信頼されるアカウントは、リソースへのアクセスを必要とするユーザーを含みます。ただし、別のアカウントがお客様のアカウントのリソースを所有する場合があります。たとえば、信頼するアカウントが、新しいリソースの作成 (Amazon S3 バケットでの新しいオブジェクトの作成など) を、信頼されたアカウントに許可する場合があります。この場合、リソースを作成したアカウントがリソースを所有します。さらに、リソースへのアクセスを誰に許可するかも管理します。

信頼関係の作成後、IAM ユーザーまたは信頼されたアカウントのアプリケーションでは AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) の API オペレーションを使用できます。このオペレーションから提供される一時的なセキュリティ認証情報を使用して、お客様のアカウントの AWS リソースにアクセスできます。

いずれものアカウントもお客様が管理できます。または、ユーザーが属するアカウントは第三者が管理できます。ユーザーが属する他のアカウントが管理対象外の AWS アカウント である場合は、`externalId` 属性を使用することもできます。外部 ID は、お客様とサードパーティーのアカウントの管理者との間で同意した任意の単語または数値です。このオプションにより、リクエストに正しい `sts:ExternalID` が含まれている場合にのみユーザーがロールを引き受けることができるという条件が、信頼ポリシーに自動的に追加されます。詳細については、「[第三者が所有する AWS アカウント へのアクセス](id_roles_common-scenarios_third-party.md)」を参照してください。

ロールを使用してアクセス権限を委任する方法の詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」を参照してください。サービスロールを使用して、サービスからアカウントのリソースへのアクセスを許可する方法については、「[AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)」を参照してください。

## IAM ロールの作成（コンソール）
<a name="roles-creatingrole-user-console"></a>

IAM ユーザーが引き受けるロールは、AWS マネジメントコンソール を使用して作成できます。例えば、組織で複数の AWS アカウント を使用して本稼働環境から開発環境を分離しているとします。この場合、開発用アカウントのユーザーに対して、本番稼働用アカウントのリソースへのアクセスを許可するロールを作成する方法の概要情報については、「[個別の開発用アカウントと本稼働用アカウントを使用したシナリオ例](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example)」を参照してください。

**最小アクセス許可**  
次の手順を実行するには、少なくとも以下のIAM アクセス許可が必要です。  
`access-analyzer:ValidatePolicy`
`iam:AttachRolePolicy`
`iam:CreatePolicy`
`iam:CreateRole`
`iam:GetAccountSummary`
`iam:GetPolicy`
`iam:GetPolicyVersion`
`iam:GetRole`
`iam:ListAccountAliases`
`iam:ListAttachedRolePolicies`
`iam:ListOpenIDConnectProviders`
`iam:ListPolicies`
`iam:ListRolePolicies`
`iam:ListRoles`
`iam:ListRoleTags`
`iam:ListSAMLProviders`

------
#### [ Console ]

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. コンソールのナビゲーションペインで、**[ロール]**、**[ロールの作成]** の順に選択します。

1. **[AWS アカウント]** のロールタイプを選択します。

1. アカウントのロールを作成するには、**[このアカウント]** を選択します。別のアカウントのロールを作成するには、[**別の AWS アカウント**] を選択し、リソースへのアクセス許可を付与する **[アカウント ID]** を入力します。

   指定したアカウントの管理者は、そのアカウントのすべての IAM ユーザーに、このロールを引き受ける許可を付与できます。そのためには、管理者から `sts:AssumeRole` アクションの許可を付与するユーザーまたはグループにポリシーを添付します。そのポリシーで、`Resource` としてロールの ARN を指定する必要があります。

1. 管理対象外のアカウントのユーザーにアクセス許可を付与し、このロールをユーザーがプログラムで引き受ける場合は、**[外部 ID が必要]** を選択します。外部 ID は、お客様とサードパーティーのアカウントの管理者との間で同意した任意の単語または数値です。このオプションにより、リクエストに正しい `sts:ExternalID` が含まれている場合にのみユーザーがロールを引き受けることができるという条件が、信頼ポリシーに自動的に追加されます。詳細については、「[第三者が所有する AWS アカウント へのアクセス](id_roles_common-scenarios_third-party.md)」を参照してください。
**重要**  
このオプションを選択すると、AWS CLI、Tools for Windows PowerShell、または AWS API からのみの、ロールへのアクセスが制限されます。これは、AWS コンソールを使用して、その信頼ポリシーに `externalId` 条件が指定されているロールに切り替えることができないためです。ただし、関連するSDKを使用してスクリプトまたはアプリケーションを作成することで、この種のアクセスをプログラムで作成できます。詳細とサンプルスクリプトについては、AWS マネジメントコンソール セキュリティブログの「[AWS へのクロスアカウントアクセスを有効にする方法](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)」を参照してください。

1. 多要素認証 (MFA) を使用してサインインするユーザーのロールを制限するには、**[MFA が必要]** を選択します。これにより、MFA によるサインインの有無を確認する条件がロールの信頼ポリシーに追加されます。ロールを引き受けるユーザーは、設定した MFA デバイスから一時的なワンタイムパスワードを使用してサインインする必要があります。MFA 認証のないユーザーはロールを引き受けることができません。MFA の詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。

1. **[次へ]** を選択します。

1. IAM には、アカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。アクセス許可ポリシーとして使用するポリシーを選択するか、**[ポリシーの作成]** を選択して新しいブラウザタブを開き、新しいポリシーをゼロから作成します。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。ポリシーを作成したら、そのタブを閉じて元のタブに戻ります。ロールを引き受けるユーザーに許可するアクセス許可ポリシーの横にあるチェックボックスをオンにします。必要に応じて、この時点でポリシーを選択せずに、後でポリシーをロールにアタッチすることもできます。デフォルトでは、ロールにはいずれのアクセス権限もありません。

1. (オプション) [アクセス許可の境界](access_policies_boundaries.md)を設定します。これはアドバンスド機能です。

   **[アクセス許可の境界の設定]** セクションを開き、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択します。アクセス許可の境界として使用するポリシーを選択します。

1. [**次へ**] を選択します。

1. **ロール名** に、ロールの名前を入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。ロール名がポリシーまたは ARN の一部として使用される場合、ロール名は大文字と小文字が区別されます。サインイン処理中など、コンソールでロール名がユーザーに表示される場合、ロール名は大文字と小文字を区別しません。さまざまなエンティティがロールを参照する可能性があるため、作成後にロール名を編集することはできません。

1. (オプション) **[説明]** には、新しいロールの説明を入力します。

1. **[ステップ 1: 信頼済みエンティティの選択]** または **[ステップ 2: 権限の追加]** のセクションで **[編集]** を選択し、ロールのユースケースと権限を変更します。前のページに戻って編集を行います。

1. (オプション) タグをキーバリューのペアとしてアタッチして、メタデータをロールに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。

1. ロール情報を確認し、**ロールの作成** を選択します。
**重要**  
上記の手順は、必要となる設定の前半であることに注意してください。信頼されたアカウントの各ユーザーに対して、コンソールでロールを切り替えるか、プログラムでロールを引き受けるためのアクセス許可も付与する必要があります。この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

------

## IAM ロール (AWS CLI) の作成
<a name="roles-creatingrole-user-cli"></a>

AWS CLI を使用したロールの作成には、複数のステップがあります。コンソールを使用してロールを作成する場合、多くのステップは自動的に行われますが、AWS CLI を使用する場合は、各ステップを明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。

**クロスアカウントアクセス用のロールを作成するには (AWS CLI)**

1. ロール [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) を作成します。

1. マネージドアクセス許可ポリシー [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) をロールにアタッチします。

    または

   ロールのインラインアクセス許可ポリシー[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) を作成します。

1. (オプション) タグ ([aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)) をアタッチして、カスタム属性をロールに追加します。

   詳細については、「[IAM ロールのタグの管理 (AWS CLI または AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api)」を参照してください。

1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) を設定します。

   アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。

次の例では、シンプルな環境でクロスアカウントロールを作成するための最初の 2 つのステップ (最も一般的なステップ) を示します。この例では、`123456789012` アカウントの任意のユーザーに、ロールを引き受けて Amazon S3 バケット `example_bucket` を表示することを許可します。また、この例では、Windows を実行しているクライアントコンピュータを使用中であり、アカウントの認証情報とリージョンを使ってコマンドラインインターフェイスを設定済みであることを前提とします。詳細については、「[AWS コマンドラインインターフェイスの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。

この例では、ロールの作成時に、次の信頼ポリシーを最初のコマンドに含めます。この信頼ポリシーでは、`123456789012` アカウントのユーザーに対して、`AssumeRole` オペレーションを使用してロールを引き受けることを許可します。ただし、ユーザーが `SerialNumber` パラメータと `TokenCode` パラメータを使用して MFA 認証を提供することを条件とします。MFA の詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
          "Effect": "Allow",
          "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
          "Action": "sts:AssumeRole",
          "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
      }
  ]
}
```

------

**重要**  
`Principal` 要素に特定の IAM ロールまたはユーザーの ARN が含まれている場合、この ARN はポリシーの保存時に一意のプリンシパル ID に変換されます。これにより、第三者がロールやユーザーを削除して再作成することで、そのユーザーのアクセス許可をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。信頼ポリシーが表示されるときに、ARN への逆変換が行われるためです。ただし、ロールまたはユーザーを削除すると、プリンシパル ID はコンソールに表示されます。これは、AWS が ARN に ID をマッピングできなくなるためです。したがって、信頼ポリシーの `Principal` 要素で指し示しているユーザーまたはロールを削除し、再作成する場合、ロールを編集して ARN を置き換える必要があります。

2 番目のコマンドを使用する場合、既存の管理ポリシーをロールにアタッチする必要があります。以下のアクセス許可ポリシーでは、`example_bucket` Amazon S3 バケット に対して `ListBucket` アクションのみを実行することを、ロールを引き受ける任意のユーザーに許可します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
          "Effect": "Allow",
          "Action": "s3:ListBucket",
          "Resource": "arn:aws:s3:::example_bucket"
      }
  ]
}
```

------

この `Test-UserAccess-Role` ロールを作成するには、まず以前の信頼ポリシーを `trustpolicyforacct123456789012.json` という名前でローカル `policies` ドライブの `C:` フォルダに保存する必要があります。次に、以前のアクセス許可ポリシーを `PolicyForRole` という名前のカスタマー管理ポリシーとして AWS アカウント に保存します。次に、以下のコマンドを使用してロールを作成し、管理ポリシーをアタッチできます。

```
# Create the role and attach the trust policy file that allows users in the specified account to assume the role.
$ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json

# Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do.
$ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole
```

**重要**  
上記の手順は、必要となる設定の前半であることに注意してください。信頼されたアカウントに属している個々のユーザーに、ロールを切り替えるアクセス権限を付与する必要もあります。この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

ロールを作成し、このロールに AWS タスクの実行や AWS リソースへのアクセスに必要なアクセス許可を付与すると、`123456789012` アカウントのユーザーはこのロールを引き受けることができます。詳細については、「[IAM ロールに切り替える (AWS CLI)](id_roles_use_switch-role-cli.md)」を参照してください。

## IAM ロール（AWS API) の作成
<a name="roles-creatingrole-user-api"></a>

AWS API からロールを作成するには、複数のステップが必要です。コンソールでロールを作成する場合は多くのステップが自動的に実行されますが、API では各ステップを手動で明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。

**コードでロールを作成するには (AWS API)**

1. ロールとして [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) を作成します。

   ロールの信頼ポリシーに対して、ファイルの場所を指定できます。

1. マネージドアクセス許可ポリシー [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) をロールにアタッチします。

   または

   ロールのインラインアクセス許可ポリシー [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) を作成します。
**重要**  
上記の手順は、必要となる設定の前半であることに注意してください。信頼されたアカウントに属している個々のユーザーに、ロールを切り替えるアクセス権限を付与する必要もあります。この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

1. (オプション) タグ ([TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)) をアタッチして、カスタム属性をユーザーに追加します。

   詳細については、「[IAM ユーザーのタグの管理 ( AWS CLI または AWS API)](id_tags_users.md#id_tags_users_procs-cli-api)」を参照してください。

1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) を設定します。

   アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。

ロールを作成し、このロールに AWS タスクの実行や AWS リソースへのアクセスに必要なアクセス許可を付与したら、アカウントのユーザーにアクセス許可を付与して、このロールを引き受けることを許可する必要があります。ロールの引き受けに関する詳細については、「[IAM ロールを切り替える (AWS)](id_roles_use_switch-role-api.md)」を参照してください。

## IAM ロール (AWS CloudFormation) の作成
<a name="roles_creatingrole-user-cloudformation"></a>

AWS CloudFormation での IAM ロールの作成については、[AWS CloudFormationユーザガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html)の「[リソースとプロパティのリファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples) 」および「*例*」を参照してください 。

AWS CloudFormation の IAM テンプレートの詳細については、「AWS CloudFormation ユーザガイド」の「[AWS Identity and Access Management テンプレートスニペット](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html)」を参照してください。

# AWS サービスにアクセス許可を委任するロールを作成する
<a name="id_roles_create_for-service"></a>

AWS の多くのサービスでは、ロールを使用して、ユーザーに代わって該当サービスが他のサービスのリソースにアクセスすることを許可する必要があります。サービスがお客様に代わってアクションを実行するために引き受けるロールは、[サービスロール](id_roles.md#iam-term-service-role)と呼ばれます。ロールがサービスの特殊な目的を果たす場合、そのロールは[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)として分類されます。どのサービスがサービスにリンクされたロールの使用をサポートしているのか、またはサービスがあらゆる形式の一時的な認証情報をサポートしているのか確認するには「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」をご覧ください。サービスがそれぞれロールをどのように使用するのか把握するには、テーブル内のサービス名を選択し、そのサービスに関するドキュメントをご覧ください。

`PassRole` アクセス許可を設定する場合、ユーザーがロールに必要以上のアクセス許可があるロールを渡さないようにする必要があります。例えば、Alice が Amazon S3 アクションを実行する許可を持っていない場合があります。Alice が Amazon S3 アクションを許可するサービスにロールを渡すことができる場合、サービスはジョブの実行時に、Alice に代わって Amazon S3 アクションを実行できます。

ロールを使用してアクセス許可を委任する方法の詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」を参照してください。

## サービスロールのアクセス許可
<a name="id_roles_create_service-permissions"></a>

IAM エンティティ (ユーザーまたはロール) がサービスロールを作成または編集できるようにするには、アクセス許可を設定する必要があります。

**注記**  
サービスにリンクされたロールの ARN にはサービスプリンシパルが含まれています。以下のポリシーでは `SERVICE-NAME.amazonaws.com` として示されています。サービスプリンシパルは推量しないでください。サービスプリンシパルは、大文字と小文字が区別され、AWS のサービス間で異なる場合があります。サービスのサービスプリンシパルを表示するには、そのサービスにリンクされたロールのドキュメントを参照してください。

**IAM エンティティが特定のサービスロールを作成することを許可するには**

サービスロールを作成する必要のある IAM エンティティに、以下のポリシーを追加します。このポリシーでは、指定したサービスおよび特定の名前のサービスロールの作成を許可します。管理ポリシーまたはインラインポリシーをそのロールにアタッチできます。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:CreateRole",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
        }
    ]
}
```

------

**IAM エンティティが任意のサービスロールを作成することを許可するには**

AWS では、管理者ユーザーのみにサービスロールの作成を許可することをお勧めします。ロールの作成とポリシーのアタッチを許可されたユーザーは、自分のアクセス許可をエスカレートできます。代わりに、彼らが必要とするロールの作成のみを許可したポリシーを作成するか、彼らの代わりに、管理者にサービスロールを作成させます。

管理者が AWS アカウント 全体にアクセスできるポリシーをアタッチするには、[AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess)AWS 管理ポリシーを使用します。

**IAM エンティティにサービスロールの編集を許可するには**

サービスロールを編集する必要のある IAM エンティティに、以下のポリシーを追加します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "EditSpecificServiceRole",
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:DeleteRolePolicy",
                "iam:DetachRolePolicy",
                "iam:GetRole",
                "iam:GetRolePolicy",
                "iam:ListAttachedRolePolicies",
                "iam:ListRolePolicies",
                "iam:PutRolePolicy",
                "iam:UpdateRole",
                "iam:UpdateRoleDescription"
            ],
            "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
        },
        {
            "Sid": "ViewRolesAndPolicies",
            "Effect": "Allow",
            "Action": [
                "iam:GetPolicy",
                "iam:ListRoles"
            ],
            "Resource": "*"
        }
    ]
}
```

------

**IAM エンティティが特定のサービスロールを削除することを許可するには**

指定したサービスロールを削除する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。

```
{
    "Effect": "Allow",
    "Action": "iam:DeleteRole",
    "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
```

**IAM エンティティがサービスロールを削除することを許可するには**

AWS では、管理者ユーザーのみにサービスロールの削除を許可することをお勧めします。代わりに、彼らが必要とするロールの削除のみを許可したポリシーを作成するか、彼らの代わりに、管理者にサービスロールを削除させます。

管理者が AWS アカウント 全体にアクセスできるポリシーをアタッチするには、[AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess)AWS 管理ポリシーを使用します。

## AWS のサービス用ロールの作成 (コンソール)
<a name="roles-creatingrole-service-console"></a>

サービス用のロールを作成するには、AWS マネジメントコンソール を使用します。一部のサービスでは、複数のサービスロールがサポートされているため、該当サービスの「[AWS ドキュメント](https://docs.aws.amazon.com/)」を参照の上、選択するユースケースを確認してください。必要な信頼ポリシーとアクセス権限ポリシーを割り当て、サービスがお客様に代わってロールを引き受ける方法について説明します。ロールのアクセス許可を管理するために使用できるステップは、サービスでユースケースを定義する方法や、サービスにリンクされたロールを作成するかどうかに応じて異なります。

------
#### [ Console ]

**AWS のサービス (IAM コンソール) のロールを作成するには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. IAM コンソールのナビゲーションペインで、**[ロール]**、**[ロールを作成]** を選択します。

1. **信頼できるエンティティタイプ** で、**AWS のサービス** を選択します。

1. **[サービスまたはユースケース]** でサービスを選択し、次にユースケースを選択します。ユースケースは、サービスに必要な信頼ポリシーを含める定義になります。

1. [**次へ**] を選択します。

1. **[アクセス許可ポリシー]** では、オプションは選択したユースケースによって異なります。
   + サービスがロールのアクセス許可を定義している場合、アクセス許可ポリシーを選択することはできません。
   + 制限されたアクセス許可ポリシーのセットから選択します。
   + すべてのアクセス許可ポリシーから選択します。
   + アクセス許可ポリシーを選択するのではなく、ロールの作成後にポリシーを作成し、そのポリシーをロールにアタッチします。

1. (オプション) [アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)を設定します。このアドバンスド機能は、サービスロールで使用できますが、サービスにリンクされたロールではありません。

   1. **[アクセス許可の境界の設定]** セクションを開き、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択します。

      IAM には、アカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。

   1. アクセス許可の境界として使用するポリシーを選択します。

1. [**次へ**] を選択します。

1. **[ロール名]** では、オプションはサービスによって異なります。
   + サービスでロール名が定義されている場合、ロール名を編集することはできません。
   + サービスでロール名のプレフィックスが定義されている場合、オプションのサフィックスを入力できます。
   + サービスでロール名が定義されていない場合、ロールに名前を付けることができます。
**重要**  
ロールに名前を付けるときは、次のことに注意してください。  
ロール名は AWS アカウント内で一意である必要があります。ただし、大文字と小文字は区別されません。  
例えば、**PRODROLE** と **prodrole** の両方の名前でロールを作成することはできません。ロール名がポリシーまたは ARN の一部として使用される場合、ロール名は大文字と小文字が区別されます。ただし、サインインプロセスなど、コンソールにロール名がユーザーに表示される場合、ロール名は大文字と小文字が区別されません。
他のエンティティがロールを参照する可能性があるため、ロールを作成した後にロール名を編集することはできません。

1. (オプション) **[説明]** にロールの説明を入力します。

1. (オプション) ロールのユースケースとアクセス許可を編集するには、**[ステップ 1: 信頼されたエンティティを選択]** または **[ステップ 2: アクセス権限を追加]** のセクションで **[編集]** を選択します。

1. (オプション) ロールの識別、整理、検索を簡単にするには、キーと値のペアとしてタグを追加します。IAM でのタグの使用の詳細については、「*IAM ユーザーガイド*」の「[AWS Identity and Access Management リソースのタグ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。

1. ロールを確認したら、**[ロールを作成]** を選択します。

------

## サービス用のロールを作成する (AWS CLI)
<a name="roles-creatingrole-service-cli"></a>

AWS CLI を使用したロールの作成には、複数のステップがあります。コンソールを使用してロールを作成する場合、多くのステップは自動的に行われますが、AWS CLI を使用する場合は、各ステップを明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。使用しているサービスが Amazon EC2 の場合は、インスタンスプロファイルも作成してロールを追加する必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。

**AWS のサービスのロールを AWS CLI で作成するには**

1. 次の `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` コマンドは、*Test-Role* という名前のロールを作成し、それに信頼ポリシーをアタッチします。

   `aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json`

1. マネージドアクセス許可ポリシー [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) をロールにアタッチします。

   たとえば、次の `attach-role-policy` コマンドは、AWS と呼ばれる `ReadOnlyAccess` 管理ポリシーIAM ロールを `ReadOnlyRole` と呼ばれる IAM ロールロールにアタッチします。

   `aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole`

    または

   ロールのインラインアクセス許可ポリシー[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) を作成します。

   インラインアクセス許可ポリシーの追加については、以下の例を参照してください。

    `aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json`

1. (オプション) タグ ([aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)) をアタッチして、カスタム属性をロールに追加します。

   詳細については、「[IAM ロールのタグの管理 (AWS CLI または AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api)」を参照してください。

1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) を設定します。

   アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。

ロールを Amazon EC2 で使用する場合や、Amazon EC2 を使用する AWS の別のサービスで使用する場合は、ロールをインスタンスプロファイルに保存する必要があります。インスタンスプロファイルは、Amazon EC2 インスタンスの起動時にインスタンスにアタッチできるロールのコンテナです。インスタンスプロファイルに含めることができる ロールは 1 つのみであり、緩和できません。AWS マネジメントコンソールを使用してロールを作成すると、ロールと同じ名前のインスタンスプロファイルが自動的に作成されます。インスタンスプロファイルの詳細については、「[インスタンスプロファイルを使用する](id_roles_use_switch-role-ec2_instance-profiles.md)」を参照してください。ロールを使用して EC2 インスタンスを起動する方法については、「Amazon EC2 ユーザーガイド」の [Amazon EC2 リソースへのアクセスの制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)に関するページを参照してください。

**インスタンスプロファイルを作成し、これにロールを保存するには (AWS CLI)**

1. インスタンスプロファイル [aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html) を作成します。

1. ロールをインスタンスプロファイル [aws iam add-role-to-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html) に追加します。

次に示す AWS CLI のコマンド例では、ロールを作成してアクセス許可をアタッチする手順の最初の 2 つのステップを示します。また、インスタンスプロファイルを作成し、これにロールを追加する手順の最初の 2 つのステップも示します。この信頼ポリシー例では、ロールを引き受けて Amazon S3 バケット `example_bucket` を表示することを Amazon EC2 サービスに許可します。また、この例では、Windows を実行するクライアントコンピュータを使用中であり、アカウントの認証情報とリージョンを使ってコマンドラインインターフェイスを設定済みであることを前提とします。詳細については、「[AWS コマンドラインインターフェイスの設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。

この例では、ロールの作成時に、次の信頼ポリシーを最初のコマンドに含めます。この信頼ポリシーにより、Amazon EC2 サービスはロールを引き受けることを許可されます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }
}
```

------

2 番目のコマンドを使用する場合、アクセス許可ポリシーをロールにアタッチする必要があります。次のアクセス許可ポリシーの例では、Amazon S3 バケット `ListBucket` に対して `example_bucket` アクションのみを実行することをロールに許可します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}
```

------

この `Test-Role-for-EC2` ロールを作成するには、まず前の信頼ポリシーを `trustpolicyforec2.json` という名前で、前のアクセス許可ポリシーを `permissionspolicyforec2.json` という名前で、ローカル `C:` ドライブの `policies` ディレクトリに保存する必要があります。次に、以下のコマンドを使用して、ロールの作成、ポリシーのアタッチ、インスタンスプロファイルの作成、およびインスタンスプロファイルへのロールの追加を行います。

```
# Create the role and attach the trust policy that allows EC2 to assume this role.
$ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json

# Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do.
$ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json

# Create the instance profile required by EC2 to contain the role
$ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3

# Finally, add the role to the instance profile
$ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2
```

EC2 インスタンスを起動するとき、AWS コンソールを使用する場合は、[**インスタンスの詳細の設定**] ページでインスタンスプロファイル名を指定します。`aws ec2 run-instances` CLI コマンドを使用する場合は、`--iam-instance-profile` パラメータを指定します。

## サービス用のロールを作成する (AWS API)
<a name="roles-creatingrole-service-api"></a>

AWS API からロールを作成するには、複数のステップが必要です。コンソールでロールを作成する場合は多くのステップが自動的に実行されますが、API では各ステップを手動で明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。使用しているサービスが Amazon EC2 の場合は、インスタンスプロファイルも作成してロールを追加する必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。

**AWS のサービスのロールを作成するには (AWS API)**

1. ロールとして [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) を作成します。

   ロールの信頼ポリシーに対して、ファイルの場所を指定できます。

1. ロールに管理アクセス許可ポリシーをアタッチします: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)

    または

   ロールのインラインアクセス許可ポリシー [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) を作成します。

1. (オプション) タグ ([TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)) をアタッチして、カスタム属性をユーザーに追加します。

   詳細については、「[IAM ユーザーのタグの管理 ( AWS CLI または AWS API)](id_tags_users.md#id_tags_users_procs-cli-api)」を参照してください。

1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) を設定します。

   アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。

ロールを Amazon EC2 で使用する場合や、Amazon EC2 を使用する AWS の別のサービスで使用する場合は、ロールをインスタンスプロファイルに保存する必要があります。インスタンスプロファイルは、ロールのコンテナとして機能します。各インスタンスプロファイルに含めることができるロールは 1 つのみであり、増やすことはできません。AWS マネジメントコンソールでロールを作成すると、ロールと同じ名前のインスタンスプロファイルが自動的に作成されます。インスタンスプロファイルの詳細については、「[インスタンスプロファイルを使用する](id_roles_use_switch-role-ec2_instance-profiles.md)」を参照してください。ロールを使用して Amazon EC2 インスタンスを起動する方法については、「Amazon EC2 ユーザーガイド」の [Amazon EC2 リソースへのアクセスの制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)に関するページを参照してください。

**インスタンスプロファイルを作成し、これにロールを保存するには (AWS API)**

1. インスタンスプロファイル [CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html) を作成します。

1. ロールをインスタンスプロファイル [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html) に追加します。

# サービスにリンクされたロールの作成
<a name="id_roles_create-service-linked-role"></a>

サービスにリンクされたロールは、AWS のサービスに直接リンクされた一意のタイプの IAM ロールです。サービスにリンクされたロールは、サービスによって事前定義されており、お客様の代わりにサービスから他の AWS サービスを呼び出す必要のあるアクセス権限がすべて含まれています。このリンクされたサービスでも、サービスにリンクされたロールを作成、変更、削除する方法を定義しています。サービスによって、ロールが自動的に作成または削除される場合があります。そのため、ウィザードの一部、またはサービスのプロセスとして、ロールを作成、変更、削除できる場合があります。または、ロールを作成または削除するには、IAM を使用する必要がある場合があります。どの方法を使用するにしても、サービスにリンクされたロールを使用すると、サービスが自動でアクションを完了させるのに、 アクセス許可を手動で追加する必要がないため、サービスの設定プロセスが簡単になります。

**注記**  
サービスロールは、サービスにリンクされたロールとは異なることに注意してください。サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「*IAM ユーザーガイド*」の「[AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。

リンクされたサービスで、そのサービスにリンクされたロールのアクセス許可を定義します。特に定義されている場合を除き、ロールは、そのサービスでのみ引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。

ロールを削除する前に、最初に関連するリソースを削除する必要があります。これにより、リソースへのアクセス許可を誤って削除してしまうことを防ぐことができます。

**ヒント**  
サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[サービスにリンクされたロール]** 列が **[はい]** になっているサービスを検索してください。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。

## サービスにリンクされたロールのアクセス許可
<a name="service-linked-role-permissions"></a>

ユーザーまたはロールがサービスにリンクされたロールを作成または編集できるようにするには、IAM エンティティ (ユーザーまたはロール) のアクセス許可を設定する必要があります。

**注記**  
サービスにリンクされたロールの ARN にはサービスプリンシパルが含まれています。以下のポリシーでは `SERVICE-NAME.amazonaws.com` として示されています。サービスプリンシパルは推量しないでください。サービスプリンシパルは、大文字と小文字が区別され、AWS のサービス間で異なる場合があります。サービスのサービスプリンシパルを表示するには、そのサービスにリンクされたロールのドキュメントを参照してください。

**特定のサービスにリンクされたロールの作成を IAM エンティティに許可するには**

サービスにリンクされたロールを作成する必要のある IAM エンティティに、次のポリシーを追加します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*",
            "Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}}
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
        }
    ]
}
```

------

**IAM エンティティがサービスにリンクされた任意のロールを作成することを許可するには**

サービスにリンクされたロール、または必要なポリシーを含む任意のサービスロールを作成する必要のある IAM エンティティのアクセス許可ポリシーに、次のステートメントを追加します。このポリシーステートメントでは、IAM エンティティがポリシーをロールにアタッチすることは許可されません。

```
{
    "Effect": "Allow",
    "Action": "iam:CreateServiceLinkedRole",
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**IAM エンティティが任意のサービスロールの説明を編集することを許可するには**

サービスにリンクされたロール、または任意のサービスロールの説明を編集する必要のある IAM エンティティのアクセス許可ポリシーに、次のステートメントを追加します。

```
{
    "Effect": "Allow",
    "Action": "iam:UpdateRoleDescription",
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**IAM エンティティがサービスにリンクされた特定のロールを削除することを許可するには**

サービスにリンクされたロールを削除する必要のある IAM エンティティのアクセス許可ポリシーに、次のステートメントを追加します。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:DeleteServiceLinkedRole",
        "iam:GetServiceLinkedRoleDeletionStatus"
    ],
    "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
```

**IAM エンティティがサービスにリンクされた任意のロールを削除することを許可するには**

サービスロールではなく、サービスにリンクされたロールを削除する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:DeleteServiceLinkedRole",
        "iam:GetServiceLinkedRoleDeletionStatus"
    ],
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**既存のロールをサービスに渡すことを IAM エンティティに許可するには**

一部の AWS サービスでは、新しいサービスにリンクされたロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスに*ロールを渡す*アクセス許可がユーザーに必要です。ロールを渡す必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。このポリシーステートメントでは、エンティティは、渡すことができるロールのリストを表示できます。詳細については、「[AWS サービスにロールを渡すアクセス許可をユーザーに付与する](id_roles_use_passrole.md)」を参照してください。

```
{
  "Sid": "PolicyStatementToAllowUserToListRoles",
  "Effect": "Allow",
  "Action": ["iam:ListRoles"],
  "Resource": "*"
},
{
  "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
  "Effect": "Allow",
  "Action": [ "iam:PassRole" ],
  "Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ"
}
```

## サービスにリンクされたロールによる間接的なアクセス許可
<a name="create-service-linked-role-permissions-transfer"></a>

サービスにリンクされたロールによって付与されたアクセス許可は、他のユーザーおよびロールに間接的に転送できます。サービスにリンクされたロールが AWS サービスによって使用されると、そのサービスにリンクされたロールは独自のアクセス許可を使用して他の AWS サービスを呼び出すことができます。つまり、サービスにリンクされたロールを使用するサービスを呼び出すアクセス許可を持つユーザーとロールは、そのサービスにリンクされたロールがアクセスできるサービスに間接的にアクセスできる可能性があります。

たとえば、Amazon RDS DB インスタンスを作成すると、[RDS のサービスにリンクされたロール](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html)は、まだ存在しない場合は自動的に作成されます。このサービスにリンクされたロールを使用すると、RDS は、ユーザーに代わって Amazon EC2、Amazon SNS、Amazon SNS、Amazon CloudWatch Logs、Amazon Kinesis を呼び出すことを許可します。アカウントのユーザーとロールに RDS データベースの変更や作成を許可すると、RDS を呼び出すことで Amazon EC2、Amazon SNS、Amazon CloudWatch Logs ログ、Amazon Kinesis のリソースと間接的にやり取りできるようになる可能性があります。RDS はサービスにリンクされたロールを使用してこれらのリソースにアクセスするためです。

### サービスにリンクされたロールを作成する方法
<a name="create-service-linked-role"></a>

サービスにリンクされたロールを作成するメソッドは、サービスによって異なります。場合によっては、サービスにリンクされたロールを手動で作成する必要はありません。たとえば、サービス特定のアクション (リソースの作成) を完了すると、サービスによって、サービスにリンクされたロールが作成される場合があります。または、サービスにリンクされたロールのサポートを開始する前からサービスを使用していた場合は、アカウントにロールが自動的に作成される場合があります。詳細については[AWS アカウントに新しいロールが表示される](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared)を参照してください。

また、サービスにリンクされたロールは、サービスコンソール、API、CLI を使用して、手動で作成できる場合があります。サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[サービスにリンクされたロール]** 列が **[はい]** になっているサービスを検索してください。サービスにリンクされたロールをサービスで作成できるかどうかを確認するには、「**はい**」リンクを選択して、該当サービスのサービスにリンクされたロールに関するドキュメントを参照してください。

ロールの作成がサービスでサポートされていない場合は、IAM を使用して、サービスにリンクされたロールを作成できます。

**重要**  
サービスにリンクされたロールでは、[AWS アカウント の IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities)の制限に向かってカウントされますが、このロールは制限を超えてもアカウントに作成することができます。この制限を超える可能性があるのは、サービスにリンクされたロールのみです。

### サービスにリンクされたロールの作成 (コンソール)
<a name="create-service-linked-role-iam-console"></a>

IAM のサービスにリンクされたロールを作成する前に、サービスにリンクされたロールがサービスで自動的に作成されるかどうかを確認します。さらに、サービスのコンソール、API、または CLI からロールを作成できるかどうかも確認します。<a name="create-service-linked-role-iam-console"></a>

**サービスにリンクされたロールを作成するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. IAM コンソールのナビゲーションペインで **[ロール]** を選択します。続いて、**[ロールの作成]** を選択します。

1. **[AWS のサービス]** ロールタイプを選択します。

1. 提供するサービスのユースケースを選択します。ユースケースは、サービスに必要な信頼ポリシーを含めるように定義されています。その後、**[Next]** を選択します。

1. ロールにアタッチするアクセス権限ポリシーを 1 つ以上選択します。選択したユースケースに基づき、サービスで以下のいずれかを行う場合があります。
   + ロールで使用するアクセス権限を定義します。
   + 制限されたアクセス権限からの選択を許可します。
   + すべてのアクセス権限からの選択を許可します。
   + この時点でポリシーを選択できないようにし、ポリシーを作成してからロールにアタッチします。

   ロールに許可する許可を割り当てるポリシーの横にあるチェックボックスを選択し、**[次へ]** を選択します。
**注記**  
設定したアクセス権限は、ロールを使用するすべてのエンティティで有効となります。デフォルトでは、ロールにはいずれのアクセス権限もありません。

1. **[ロール名]** の場合、ロール名のカスタマイズの度合いはサービスによって定義されます。サービスのロール名が定義されている場合、このオプションを変更することはできません。その他の場合、サービスはロールのプレフィックスを定義し、オプションのサフィックスを入力できるようにするかもしれません。

   可能であれば、ロールのデフォルト名に追加するサフィックスを入力します。このサフィックスは、このロールの目的を識別するのに役立ちます。ロール名は AWS アカウント内で一意でなければなりません。大文字と小文字は区別されません。例えば、**<service-linked-role-name>\$1SAMPLE** と **<service-linked-role-name>\$1sample** というロール名を両方作成することはできません。多くのエンティティによりロールが参照されるため、作成後にロール名を変更することはできません。

1. (オプション) **[説明]** で、サービスにリンクされた新しいロールの説明を編集します。

1. 作成中にサービスにリンクされたロールにタグ付けすることはできません。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。

1. ロール情報を確認し、**ロールの作成** を選択します。

### サービスにリンクされたロールの作成 (AWS CLI)
<a name="create-service-linked-role-iam-cli"></a>

IAM でサービスにリンクされたロールを作成するには、リンクされたサービスで、サービスにリンクされたロールが自動的に作成されるかどうかと、サービスの CLI からロールを作成できるかどうかについて確認します。サービス CLI がサポートされていない場合は、IAM コマンドを使用して、ロールを引き受けるためにサービスで必要な信頼ポリシーやインラインポリシーを含めて、サービスにリンクされたロールを作成することができます。

**サービスにリンクされたロールを作成するには (AWS CLI)**

次のコマンドを実行します。

```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com
```

### サービスにリンクされたロールの作成 (AWS API)
<a name="create-service-linked-role-iam-api"></a>

IAM でサービスにリンクされたロールを作成するには、リンクされたサービスで、サービスにリンクされたロールが自動的に作成されるかどうかと、サービスの API からロールを作成できるかどうかについて確認します。サービス API がサポートされていない場合は、AWS API を使用して、ロールを引き受けるためにサービスで必要な信頼ポリシーやインラインポリシーを含めて、サービスにリンクされたロールを作成することができます。

**サービスにリンクされたロールを作成するには (AWS API)**

[CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) API コールを使用します。リクエストで、サービス名`SERVICE_NAME_URL.amazonaws.com`を指定します。

たとえば、サービスにリンクされたロール (**[Lex Bots]**) を作成するには、`lex.amazonaws.com` を使用します。

# サードパーティー ID プロバイダーにロールを作成する
<a name="id_roles_create_for-idp"></a>

AWS アカウント で IAM ユーザーを作成する代わりに、ID プロバイダーを使用できます。ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を付与できます。フェデレーションおよび認証プロバイダーについて詳しくは、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。

## OIDC と SAML のフェデレーティッドプリンシパルのロールの作成 (コンソール)
<a name="roles-creatingrole-federated-users-console"></a>

ロールを作成する手順は、選択するサードパーティープロバイダーによって異なります。
+ OpenID Connect (OIDC) については、「[OpenID Connect フェデレーション用のロールを作成する (コンソール）](id_roles_create_for-idp_oidc.md)」を参照してください。
+ SAML 2.0 については、「[SAML 2.0 フェデレーション用のロールを作成する (コンソール)](id_roles_create_for-idp_saml.md)」を参照してください。

## フェデレーションアクセス用のロールの作成 (AWS CLI)
<a name="roles-creatingrole-identityprovider-cli"></a>

サポートされている ID プロバイダー (OIDC または SAML) 用のロールを AWS CLI から作成するステップは同じです。違いは、前提条件のステップで作成する信頼ポリシーの内容です。使用するプロバイダーのタイプに合わせた**前提条件**セクションのステップに従って開始します。
+ OIDC プロバイダーについては、「[OIDC 用のロールを作成するための前提条件](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites)」を参照してください。
+ SAML プロバイダーについては、「[SAML 用のロールを作成するための前提条件](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites)」を参照してください。

AWS CLI を使用したロールの作成には、複数のステップがあります。コンソールを使用してロールを作成する場合、多くのステップは自動的に行われますが、AWS CLI を使用する場合は、各ステップを明示的に実行する必要があります。ロールを作成して、これにアクセス許可ポリシーを割り当てる必要があります。必要に応じて、ロールの[アクセス許可の境界](access_policies_boundaries.md)を設定することもできます。

**ロールを作成するには (AWS CLI)**

1. ロール [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html) を作成します。

1. アクセス許可ポリシー [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html) をロールにアタッチします。

    または

   ロールのインラインアクセス許可ポリシー[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) を作成します。

1. (オプション) タグ ([aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)) をアタッチして、カスタム属性をロールに追加します。

   詳細については、「[IAM ロールのタグの管理 (AWS CLI または AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api)」を参照してください。

1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html) を設定します。

   アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。

次の例では、シンプルな環境で ID プロバイダーのロールを作成するための最初の 2 つのステップ (最も一般的なステップ) を示します。この例では、`123456789012` アカウントの任意のユーザーに、ロールを引き受けて Amazon S3 バケット `example_bucket` を表示することを許可します。また、この例では、Windows が動作しているコンピュータで AWS CLI を実行していること、さらに認証情報を使って AWS CLI を設定済みであることを前提とします。詳細については、「[Configuring the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)」を参照してください。

次の例では、ユーザーが Amazon Cognito を使用してサインインする場合のモバイルアプリ用の信頼ポリシーを示します。この例では、*us-east:12345678-ffff-ffff-ffff-123456* は Amazon Cognito によって割り当てられた ID プール ID を表します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Sid": "RoleForCognito",
        "Effect": "Allow",
        "Principal": {"Federated": "cognito-identity.amazonaws.com"},
        "Action": "sts:AssumeRoleWithWebIdentity",
        "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
    }
}
```

------

以下のアクセス許可ポリシーでは、Amazon S3 バケット `example_bucket` に対して `ListBucket` アクションのみを実行することを、ロールを引き受ける任意のユーザーに許可します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}
```

------

この `Test-Cognito-Role` ロールを作成するには、まず前の信頼ポリシーを `trustpolicyforcognitofederation.json` という名前で、前のアクセス許可ポリシーを `permspolicyforcognitofederation.json` という名前で、ローカル `policies` ドライブの `C:` フォルダに保存する必要があります。次に、以下のコマンドを使用してロールを作成し、インラインポリシーをアタッチできます。

```
# Create the role and attach the trust policy that enables users in an account to assume the role.
$ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json

# Attach the permissions policy to the role to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json
```

## フェデレーションアクセス用のロールの作成 (AWS API)
<a name="roles-creatingrole-identityprovider-api"></a>

サポートされている ID プロバイダー (OIDC または SAML) 用のロールを AWS CLI から作成するステップは同じです。違いは、前提条件のステップで作成する信頼ポリシーの内容です。使用するプロバイダーのタイプに合わせた**前提条件**セクションのステップに従って開始します。
+ OIDC プロバイダーについては、「[OIDC 用のロールを作成するための前提条件](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites)」を参照してください。
+ SAML プロバイダーについては、「[SAML 用のロールを作成するための前提条件](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites)」を参照してください。

**ロールを作成する方法 (AWS API)**

1. ロールとして [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html) を作成します。

1. アクセス許可ポリシーとして [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html) をロールにアタッチします。

    または

   ロールのインラインアクセス許可ポリシー [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html) を作成します。

1. (オプション) タグ ([TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)) をアタッチして、カスタム属性をユーザーに追加します。

   詳細については、「[IAM ユーザーのタグの管理 ( AWS CLI または AWS API)](id_tags_users.md#id_tags_users_procs-cli-api)」を参照してください。

1. (オプション) ロールの[アクセス許可の境界](access_policies_boundaries.md) [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html) を設定します。

   アクセス許可の境界では、ロールに許可されるアクセス許可の上限を設定します。アクセス許可の境界は AWS のアドバンスド機能です。

# OpenID Connect フェデレーション用のロールを作成する (コンソール）
<a name="id_roles_create_for-idp_oidc"></a>

AWS アカウントで AWS Identity and Access Management ユーザーを作成する代わりに、OpenID Connect (OIDC) フェデレーション ID プロバイダーを使用できます。ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を付与できます。フェデレーションおよび IdPs (ID プロバイダー) について詳しくは、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。

## OIDC 用のロールを作成するための前提条件
<a name="idp_oidc_Prerequisites"></a>

OIDC フェデレーション用のロールを作成する前に、まず次の基本的なステップを実行する必要があります。<a name="oidc-prereqs"></a>

**OIDC フェデレーション用のロールを作成する準備をするには**

1. フェデレーション OIDC ID を提供する 1 つ以上のサービスにサインアップします。AWS リソースにアクセスする必要があるアプリを作成する場合は、プロバイダー情報も合わせてアプリを設定します。サインアップすると、プロバイダーからアプリに固有のアプリケーション ID または対象者 ID が提供されます。（プロバイダーが異なれば、このプロセスには異なる用語が使用されます。このガイドでは、プロバイダーでアプリを識別するプロセスに*設定*という用語を使用します。） プロバイダーごとに複数のアプリを設定できます。または 1 つのアプリに複数のプロバイダーを設定できます。ID プロバイダーの使用に関する情報は以下で確認してください。
   + [Login with Amazon 開発者センター](https://login.amazon.com/)
   + Facebook 開発者サイトの「[アプリまたはウェブサイトに Facebook ログインを追加する](https://developers.facebook.com/docs/facebook-login/v2.1)」
   + Google 開発者サイトの「[ログインでの OAuth 2.0 の使用 (OpenID Connect) ](https://developers.google.com/accounts/docs/OAuth2Login)」

1. <a name="idpoidcstep2"></a>IdP から必要な情報を受け取ったら、IAM で IdP を作成します。詳細については、「[IAM で OpenID Connect (OIDC) ID プロバイダーを作成する](id_roles_providers_create_oidc.md)」を参照してください。
**重要**  
Google、Facebook、または Amazon Cognito の OIDC IdP を使用している場合は、AWS マネジメントコンソール に個別の IAM IdP を作成しないでください。これらの OIDC ID プロバイダーは、すでに AWS に組み込まれており、ユーザーが使用できます。この手順をスキップして、次の手順で IdP を使用して新しいロールを作成します。

1. IdP 認証ユーザーが引き受けるロールのポリシーを準備します。すべてのロールに該当することですが、モバイルアプリ用のロールにも 2 つのポリシーがあります。1 つは、ロールの引き受け先を指定する信頼ポリシーです。もう 1 つはアクセス許可ポリシーです。このポリシーでは、モバイルアプリにアクセスを許可または拒否する AWS アクションやリソースを指定します。

   ウェブ IdP については、[Amazon Cognito](https://aws.amazon.com/cognito/) を使用して ID を管理することをお勧めします。この場合、次の例に示すような信頼ポリシーを使用します。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"Federated": "cognito-identity.amazonaws.com"},
           "Action": "sts:AssumeRoleWithWebIdentity",
           "Condition": {
               "StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"},
               "ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"}
           }
       }
   }
   ```

------

   `us-east-2:12345678-abcd-abcd-abcd-123456` は、Amazon Cognito が割り当てる ID プール ID に置き換えます。

   OIDC IdP を手動で設定する場合は、信頼ポリシーの作成時に以下の 3 つの値を使用して当該アプリにのみロールを引き受けることを許可します。
   + `Action` 要素で、`sts:AssumeRoleWithWebIdentity` アクションを使用します。
   + `Principal` 要素で、`{"Federated":providerUrl/providerArn}` 文字列を使用します。
     + 一部の一般的な OIDC IdP の場合、`providerUrl` は URL です。以下の例では、いくつかの一般的な IdP のプリンシパルを指定する方法を示します。

       `"Principal":{"Federated":"cognito-identity.amazonaws.com"}`

       `"Principal":{"Federated":"www.amazon.com"}`

       `"Principal":{"Federated":"graph.facebook.com"}`

       `"Principal":{"Federated":"accounts.google.com"}`
     + 他の OIDC プロバイダーの場合は、次の例のように、[Step 2](#idpoidcstep2) で作成した OIDC IdP の Amazon リソースネーム (ARN) を使用します。

       `"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}`
   + `Condition` 要素で、`StringEquals` 条件を使用してアクセス許可を制限します。ID プール ID (Amazon Cognito の場合) またはアプリ ID (他のプロバイダーの場合) をテストします。この ID プール ID は、IdP でアプリを設定したときに取得したアプリ ID と一致する必要があります。この ID 間の一致により、リクエストが自分のアプリからであることを確認できます。
**注記**  
Amazon Cognito アイデンティティプールの IAM ロールは、サービスプリンシパル `cognito-identity.amazonaws.com` を信頼してロールを引き受けます。このタイプのロールには、ロールを引き受けるプリンシパルを制限する条件キーが少なくとも 1 つ含まれている必要があります。  
[クロスアカウントの IAM ロール](access_policies-cross-account-resource-access.md)を引き受ける Amazon Cognito アイデンティティプールには、その他の考慮事項が適用されます。これらのロールの信頼ポリシーは、`cognito-identity.amazonaws.com` サービスプリンシパルを受け入れる必要があり、ロールの引き受けを目的のアイデンティティプールのユーザーに制限するために `aud` 条件キーを含める必要があります。この条件なしで Amazon Cognito アイデンティティプールを信頼するポリシーでは、意図しないアイデンティティプールのユーザーがロールを引き受けるリスクが生じます。詳細については、「Amazon Cognito デベロッパーガイド」の「[基本 (クラシック) 認証の IAM ロールの信頼ポリシー](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies)」を参照してください。

     使用している IdP に応じて、以下の例に示すような、条件要素を作成します。

     `"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}`

     `"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}`

     `"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}`

     `"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}`

     OIDC プロバイダーの場合は、次の例に示すように、OIDC IdP の完全修飾 URL と `aud` コンテキストキーを使用します。

     `"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}`
**注記**  
ロールの信頼ポリシーでプリンシパルとして指定する値は、IdP ごとに異なります。OIDC 用のロールで指定できるプリンシパルは 1 つだけです。したがって、モバイルアプリで複数の IdP からのサインインをユーザーに許可する場合は、サポートする IdP ごとに別個のロールを作成します。IdP ごとに別個の信頼ポリシーを作成します。

   ユーザーがモバイルアプリを使用して Login with Amazon からサインインする場合、次の例の信頼ポリシーが適用されます。この例では、*amzn1.application-oa2-123456* は Login with Amazon を使用するアプリを設定したときに Amazon が割り当てるアプリ ID を表します。

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForLoginWithAmazon",
             "Effect": "Allow",
             "Principal": {"Federated": "www.amazon.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}
         }]
     }
   ```

------

   ユーザーがモバイルアプリを使用して Facebook からサインインする場合、次の例の信頼ポリシーが適用されます。この例では、*111222333444555* は Facebook が割り当てるアプリ ID を表します。

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForFacebook",
             "Effect": "Allow",
             "Principal": {"Federated": "graph.facebook.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}
         }]
     }
   ```

------

   ユーザーがモバイルアプリを使用して Google からサインインする場合、次の例の信頼ポリシーが適用されます。この例では、*666777888999000* は Google が割り当てるアプリ ID を表します。

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForGoogle",
             "Effect": "Allow",
             "Principal": {"Federated": "accounts.google.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}}
         }]
     }
   ```

------

   ユーザーがモバイルアプリを使用して Amazon Cognito からサインインする場合、次の例の信頼ポリシーが適用されます。この例では、*us-east:12345678-ffff-ffff-ffff-123456* は Amazon Cognito が割り当てる ID プール ID を表します。

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForCognito",
             "Effect": "Allow",
             "Principal": {"Federated": "cognito-identity.amazonaws.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
         }]
     }
   ```

------

## OIDC 用のロールの作成
<a name="idp_oidc_Create"></a>

前提条件を満たしたら、IAM でロールを作成できます。認識された共有 OpenID Connect (OIDC) の ID プロバイダー (IdP) の場合、IAM は *ID プロバイダーコントロール*と呼ばれる JSON ウェブトークン (JWT) に特定の請求を明示的に評価する必要があります。*ID プロバイダーコントロール*を持つ OIDC IdP の詳細については、「[共有 OIDC プロバイダーの ID プロバイダーコントロール](id_roles_providers_oidc_secure-by-default.md)」を参照してください。

次の手順は、AWS マネジメントコンソール で OIDC フェデレーション用のロールを作成する方法を示します。AWS CLI または AWS API からロールを作成するには、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」の手順を参照してください。

**重要**  
Amazon Cognito を使用する場合は、Amazon Cognito コンソールを使用してロールをセットアップします。それ以外の場合は、IAM コンソールを使用して OIDC 用のロールを作成します。

**OIDC フェデレーション用の IAM ロールを作成するには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで **[ロール]** を選択した後、**[ロールの作成]** を選択します。

1. 信頼されたエンティティタイプとして **[ウェブアイデンティティ]** を選択し、**[次へ]** を選択します。

1. **[ID プロバイダー]** で、ロールの IdP を選択します。
   + 個々のウェブ IdP 用のロールを作成する場合は、**Login with Amazon**、**Facebook**、**Google** のいずれかを選択します。
**注記**  
サポートする各 IdP に対して別々のロールを作成する必要があります。
   + Amazon Cognito 用の高度なシナリオのロールを作成する場合は、**Amazon Cognito** を選択します。
**注記**  
高度なシナリオで作業する場合に限り、Amazon Cognito で使用するロールを手動で作成する必要があります。それ以外の場合は、Amazon Cognito で自動的にロールを作成できます。Amazon Cognito の詳細については、*[Amazon Cognito Developer Guide]* の [[Identity pools (federated) external identity providers]](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html) を参照してください。
   + GitHub Actions 用のロールを作成する場合は、まず GitHub OIDC プロバイダーを IAM に追加する必要があります。GitHub OIDC プロバイダーを IAM に追加したら、**token.actions.githubusercontent.com** を選択します。
**注記**  
AWS を GitHub の OIDC プロバイダーのフェデレーティッド ID として信頼するよう設定する方法については、「[GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」を参照してください。IAM IdP for GitHub に関連するロールへのアクセスを制限するベストプラクティスについては、このページの [GitHub OIDC ID プロバイダーのロールの設定](#idp_oidc_Create_GitHub) を参照してください。
   + HashiCorp Cloud Platform (HCP) Terraform のロールを作成するには、まず Terraform OIDC プロバイダーを IAM に追加することから始める必要があります。Terraform OIDC プロバイダーを IAM に追加したら、**[app.terraform.io]** を選択します。
**重要**  
HashiCorp Cloud Platform (HCP) Terraform OIDC プロバイダーの IAM ロールは、ロールの信頼ポリシーの IAM 条件キー `app.terraform.io:sub` を評価する必要があります。この条件キーは、ロールを引き受けることができる HCP Terraform の組織、プロジェクト、ワークスペース、または実行フェーズを制限します。この条件キーがない場合、信頼ポリシーは組織外の ID によってロールと AWS リソースに対するアクセスを付与しますが、これは最小特権の原則に整合しません。  
AWS アカウント内の HCP Terraform OIDC プロバイダーに関連付けられたロールのロール信頼ポリシーを設定または変更しても、IAM 条件キー `app.terraform.io:sub` を評価しない場合、エラーが発生します。さらに、ロール信頼ポリシーがこの条件キーを評価しない場合、AWS STS は認可リクエストを拒否します。

1. リクエストされた情報は、選択した OIDC プロバイダーによって異なります。
   + アプリケーション用の ID を入力します。ID のラベルは、選択するプロバイダーによって異なります。
     + Login with Amazon 用のロールを作成する場合は、アプリ ID を **[アプリケーション ID]** ボックスに入力します。
     + Facebook 用のロールを作成する場合は、アプリ ID を **[アプリケーション ID]** ボックスに入力します。
     + Google 用のロールを作成する場合は、対象者名を **[対象者]** ボックスに入力します。
     + Amazon Cognito 用のロールを作成する場合は、Amazon Cognito アプリケーション用に作成した アイデンティティプールの ID を、**[アイデンティティプール ID]** ボックスに入力します。
   + GitHub Actions のロールを作成する場合は、以下の情報を入力します。
     + **[対象者]** で [`sts.amazonaws.com`] を選択します。
     + **GitHub 組織**の場合、GitHub の組織名を入力します。GitHub 組織名は必須で、英数字 (ダッシュ (-) を含む) でなければなりません。GitHub 組織名に、ワイルドカード文字 (\$1 と ?) は使用できません。
     + (オプション) **[GitHub リポジトリ]** に、GitHub リポジトリの名前を入力します。値を指定しない場合は、デフォルトでワイルドカード (`*`) になります。
     + (オプション) **[GitHub ブランチ]** に、GitHub ブランチ名を入力します。値を指定しない場合は、デフォルトでワイルドカード (`*`) になります。
   + HashiCorp Cloud Platform (HCP) Terraform のロールを作成する場合は、次の詳細を入力します:
     + **[対象者]** で [`aws.workload.identity`] を選択します。
     + **[組織]** で、組織名を入力します。すべての組織にワイルドカード文字 (`*`) を指定できます。
     + **[プロジェクト]** で、プロジェクト名を入力します。すべてのプロジェクトにワイルドカード文字 (`*`) を指定できます。
     + **[ワークスペース]** で、ワークスペース名を入力します。すべてのワークスペースにワイルドカード文字 (`*`) を指定できます。
     + **[実行フェーズ]** で、実行フェーズ名を入力します。すべての実行フェーズにワイルドカード文字 (`*`) を指定できます。

1. (オプション) **[条件 (オプション)]**で、**[条件の追加]** を選択して、ロールによって付与されたアクセス許可を使用する前にアプリケーションのユーザーが満たしておく必要がある追加条件を作成します。例えば、特定の IAM ユーザー ID にのみ AWS リソースに対するアクセス許可を付与する条件を追加できます。ロールを作成した後に、信頼ポリシーに条件を追加することもできます。詳細については、「[ロール信頼ポリシーを更新する](id_roles_update-role-trust-policy.md)」を参照してください。

1. OIDC 情報を確認し、**[次へ]** を選択します。

1. IAM には、あなたのアカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。アクセス許可ポリシーとして使用するポリシーを選択するか、**[ポリシーの作成]** を選択して新しいブラウザタブを開き、新しいポリシーをゼロから作成します。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。ポリシーを作成したら、そのタブを閉じて元のタブに戻ります。OIDC ユーザーに割り当てるアクセス許可ポリシーの横にあるチェックボックスをオンにします。必要に応じて、この時点でポリシーを選択せずに、後でポリシーをロールにアタッチすることもできます。デフォルトでは、ロールにはいずれのアクセス権限もありません。

1. (オプション) [アクセス許可の境界](access_policies_boundaries.md)を設定します。これはアドバンスド機能です。

   **[アクセス許可の境界]** セクションを開き、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択します。アクセス許可の境界として使用するポリシーを選択します。

1. **[次へ]** を選択します。

1. **[ロール名]** に、ロールの名前を入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。大文字と小文字は区別されません。例えば、**PRODROLE** と **prodrole** というロール名を両方作成することはできません。他の AWS リソースがロールを参照している場合があるため、作成後はロールの名前を編集できません。

1. (オプション) **[説明]** には、新しいロールの説明を入力します。

1. **[ステップ 1: 信頼済みエンティティの選択]** または **[ステップ 2: 権限の追加]** のセクションで **[編集]** を選択し、ロールのユースケースと権限を変更します。

1. (オプション) ロールにメタデータを追加するには、キーバリューのペアとしてタグをアタッチします。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。

1. ロール情報を確認し、**ロールの作成** を選択します。

## GitHub OIDC ID プロバイダーのロールの設定
<a name="idp_oidc_Create_GitHub"></a>

GitHub を OpenID Connect (OIDC) ID プロバイダー (IdP) として使用する場合、ベストプラクティスは、IAM IdP に関連付けられたロールを引き受けることができるエンティティを制限することです。信頼ポリシーに条件ステートメントを含めると、ロールを特定の GitHub Organization、リポジトリ、またはブランチに制限できます。条件キー `token.actions.githubusercontent.com:sub` を文字列条件演算子と共に使用してアクセスを制限できます。条件を GitHub 組織内の特定のリポジトリまたはブランチのセットに制限することをお勧めします。AWS を GitHub の OIDC のフェデレーティッド ID として信頼するよう設定する方法については、「[GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)」(GitHub Docs - アマゾン ウェブ サービスの OpenID Connect 設定) を参照してください。

アクションワークフローまたは OIDC ポリシーで GitHub 環境を使用する場合は、セキュリティを強化するために保護ルールを環境に追加することを強くお勧めします。デプロイブランチとタグを使用して、環境にデプロイできるブランチとタグを制限します。保護ルールを使用して環境を設定する方法については、GitHub の記事「*Using environments for deployment*」(デプロイ用の環境の使用) に記載されている「[Deployment branches and tags](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags)」(デプロイブランチとタグ) を参照してください。

GitHub の OIDC IdP がロールの信頼できるプリンシパルである場合、IAM はロールの信頼ポリシー条件をチェックして条件キー `token.actions.githubusercontent.com:sub` が存在していて、その値がワイルドカード文字 (\$1 と ?) または null だけではないことを確認します。IAM は、信頼ポリシーが作成または更新されたときにこのチェックを実行します。条件キー `token.actions.githubusercontent.com:sub` が存在しない場合、またはキー値が上記の値基準を満たさない場合、リクエストは失敗し、エラーが返されます。

**重要**  
条件キー `token.actions.githubusercontent.com:sub` を特定の組織またはリポジトリに制限しない場合、管理外の組織またはリポジトリの GitHub Actions は、AWS アカウントで GitHub IAM IdP に関連付けられたロールを引き受けることができます。

以下の信頼ポリシー例は、定義済みの GitHub Organization、リポジトリ、ブランチへのアクセスを制限します。次の例では条件キー `token.actions.githubusercontent.com:sub` の値は、GitHub が文書化しているデフォルトのサブジェクト値の形式です。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
        }
      }
    }
  ]
}
```

------

次の例の条件は、定義された GitHub Organization とリポジトリへのアクセスを制限しますが、リポジトリ内の任意のブランチへのアクセスを許可します。

```
"Condition": {
  "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {    
    "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
  }
}
```

以下の条件例は、定義された GitHub Organization 内の任意のリポジトリまたはブランチへのアクセスを制限します。条件キー `token.actions.githubusercontent.com:sub` は、アクセスを GitHub 組織内からの GitHub Actions へのアクセスに制限する特定の値に制限することをお勧めします。

```
"Condition": {
  "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {    
    "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*"
  }
}
```

ポリシーの条件チェックで利用可能な OIDC フェデレーションのキーの詳細については、「[OIDC AWS フェデレーションで使用できるキー](reference_policies_iam-condition-keys.md#condition-keys-wif)」を参照してください。

# SAML 2.0 フェデレーション用のロールを作成する (コンソール)
<a name="id_roles_create_for-idp_saml"></a>

 AWS アカウント で IAM ユーザーを作成する代わりに、SAML 2.0 フェデレーションを使用できます。ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を付与できます。フェデレーションおよび認証プロバイダーについて詳しくは、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。

**注記**  
フェデレーションの耐障害性を高めるには、IdP と AWS フェデレーションを、複数の SAML サインインエンドポイントをサポートするように設定することをお勧めします。詳細については、AWS セキュリティブログの記事「[フェイルオーバーにリージョン SAML エンドポイントを使用する方法](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)」を参照してください。

## SAML 用のロールを作成するための前提条件
<a name="idp_saml_Prerequisites"></a>

SAML 2.0 フェデレーション用のロールを作成する前に、まず次の基本的なステップを実行する必要があります。<a name="saml-prereqs"></a>

**SAML 2.0 フェデレーション用のロールを作成する準備をするには**

1. <a name="idpsamlstep1"></a>SAML ベースのフェデレーション用のロールを作成する前に、IAM で SAML プロバイダーを作成する必要があります。詳細については、「[IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md)」を参照してください。

1. SAML 2.0 認証ユーザーが引き受けるロールのポリシーを準備します。すべてのロールに該当することですが、SAML フェデレーション用のロールにも 2 つのポリシーが含まれています。1 つは、ロールの引き受け先を指定するロール信頼ポリシーです。もう 1 つは IAM アクセス許可ポリシーです。このポリシーでは、SAML フェデレーティッドプリンシパルにアクセスを許可または拒否する AWS アクションやリソースが指定されます。

   ロールの信頼ポリシーを作成する場合は、以下の 3 つの値を使用して当該アプリケーションにのみロールの引き受けを許可する必要があります。
   + `Action` 要素で、`sts:AssumeRoleWithSAML` アクションを使用します。
   + `Principal` 要素で、`{"Federated":ARNofIdentityProvider}` 文字列を使用します。`ARNofIdentityProvider` を、[Step 1](#idpsamlstep1) で作成した [SAML ID プロバイダー](id_roles_providers_saml.md)の ARN と置き換えます。
   + `Condition` 要素では、 `StringEquals` 条件を使用して、SAML レスポンスの `saml:aud` 属性が、コンソールにサインインするときにブラウザに表示される URL と一致することをテストします。このサインインエンドポイント URL は、ID プロバイダーの SAML 受取人属性です。特定のリージョン内にサインイン URL を含めることができます。AWS では、フェデレーションの耐障害性を向上させるために、グローバルエンドポイントの代わりにリージョンエンドポイントを使用することをお勧めします。実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[リージョン]** 列を参照します。

     サインイン URL には、SAML プロバイダーに割り当てられる一意の識別子 AWS が含まれている必要があります。IAM コンソールで ID プロバイダーを選択して詳細ページを表示することで、一意の識別子を確認できます。

     `https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

   次の例では、SAML フェデレーティッドユーザー用に設計された信頼ポリシーを示します。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRoleWithSAML",
           "Principal": {
               "Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME"
           },
           "Condition": {
               "StringEquals": {
                   "SAML:aud": "https://region-code.signin.aws.amazon.com/saml"
               }
           }
       }
   }
   ```

------

   プリンシパル ARN は、IAM で作成した SAML プロバイダー用の実際の ARN に置き換えます。これは、独自のアカウント ID およびプロバイダー名になります。

## SAML 用のロールの作成
<a name="idp_saml_Create"></a>

前提条件のステップを完了すると、SAML ベースのフェデレーション用のロールを作成できます。

**SAML ベースのフェデレーション用のロールを作成するには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. IAM コンソールのナビゲーションペインで、**[ロール]**、**[ロールの作成]** の順に選択します。

1. **[SAML 2.0 フェデレーション]** ロールタイプを選択します。

1. **[SAML プロバイダーの選択]** で、ロールのプロバイダーを選択します。

1. SAML 2.0 のアクセスレベルメソッドを選択します。
   + **[プログラムによるアクセスのみを許可する]** を選択して、AWS API または AWS CLI からプログラムで引き受けることができるロールを作成します。
   + [**プログラムによるアクセスと AWS マネジメントコンソール によるアクセスを許可する**] を選択して、AWS マネジメントコンソール からプログラムで引き受けることのできるロールを作成します。

   作成されたロールはいずれも似ていますが、コンソールから引き受けられるロールにも、特定の条件を含む信頼ポリシーがあります。この条件により、SAML オーディエンス (`SAML:aud` 属性) が SAML プロバイダーの AWS サインインエンドポイントに設定されていることが明示的に保証されます。

1. 属性を定義する手順は、アクセスタイプによって異なります。
   + プログラムによるアクセス用のロールを作成する場合は、**[属性]** リストから属性を選択します。次に、**[値]** ボックスで、ロールに追加する値を入力します。これにより、ロールアクセスは、指定した属性を SAML 認証応答 (アサーション) に含んでいる ID プロバイダーのユーザーのみに制限されます。ロールが組織のユーザーのサブセットに限定されるように、少なくとも 1 つの属性を指定する必要があります。
   + プログラムによるアクセスと AWS マネジメントコンソール アクセスのロールを作成する場合、**[サインインエンドポイント]** セクションでは、コンソールにサインインするときにブラウザに表示される URL を定義します。このエンドポイントは、ID プロバイダーの SAML 受取人属性であり、[`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml) コンテキストキーにマッピングされます。詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。

     1. **[リージョンエンドポイント]** または **[非リージョンエンドポイント]** を選択します。フェデレーションの耐障害性を向上させるには、複数のリージョンにまたがる SAML サインインエンドポイントを使用することをお勧めします。

     1. **リージョン**では、SAML プロバイダーが AWS サインインでサポートするリージョンを選択します。

     1.  **[一意の識別子を含めるサインイン URL]** には、サインインエンドポイントに SAML ID プロバイダーに割り当てられた一意の識別子 AWS を含めるかどうかを選択します。このオプションは、暗号化された SAML アサーションに必要です。詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。

1. 信頼ポリシーに属性関連の条件をさらに追加するには、**[条件 (オプション)]** を選択し、続いて追加の条件を選択して、値を指定します。
**注記**  
最も一般的に使用される SAML 属性がリストに表示されます。IAM では、条件の作成に使用できる追加の属性をサポートしています。サポートされる属性のリストについては、「[SAML ベースのフェデレーションに利用可能なキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml)」を参照してください。リストに含まれないサポート対象の SAML 属性の条件が必要な場合、その条件は次のステップで手動で追加できます。これを行うには、ロールを作成後に信頼ポリシーを編集します。

1.  SAML 2.0 の信頼情報を確認し、**[次へ]** を選択します。

1. IAM には、あなたのアカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。アクセス許可ポリシーとして使用するポリシーを選択するか、**[ポリシーの作成]** を選択して新しいブラウザタブを開き、新しいポリシーをゼロから作成します。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。ポリシーを作成したら、そのタブを閉じて元のタブに戻ります。SAML フェデレーションユーザーに付与するアクセス許可ポリシーの横にあるチェックボックスをオンにします。必要に応じて、この時点でポリシーを選択せずに、後でポリシーをロールにアタッチすることもできます。デフォルトでは、ロールにはいずれのアクセス権限もありません。

1. (オプション) [アクセス許可の境界](access_policies_boundaries.md)を設定します。これはアドバンスド機能です。

   **[アクセス許可の境界]** セクションを開き、**[アクセス許可の境界を使用してロールのアクセス許可の上限を設定する]** を選択します。アクセス許可の境界として使用するポリシーを選択します。

1. **[次へ]** を選択します。

1. **[次へ: レビュー]** を選択します。

1. **[ロール名]** に、ロールの名前を入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。大文字と小文字は区別されません。例えば、**PRODROLE** と **prodrole** というロール名を両方作成することはできません。他の AWS リソースがロールを参照している場合があるため、作成後はロールの名前を変更できません。

1. (オプション) **[説明]** には、新しいロールの説明を入力します。

1. **[ステップ 1: 信頼済みエンティティの選択]** または **[ステップ 2: 権限の追加]** のセクションで **[編集]** を選択し、ロールのユースケースと権限を変更します。

1. (オプション) タグをキーバリューのペアとしてアタッチして、メタデータをロールに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。

1. ロール情報を確認し、**ロールの作成** を選択します。

ロールの作成後に、AWS に関する情報を使用して ID プロバイダーソフトウェアを設定し、SAML 信頼を確立します。この情報には、SAML フェデレーションユーザーが使用するロールが含まれます。これは、IdP と AWS との証明書利用者信頼の設定と呼ばれます。詳細については、「[証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する](id_roles_providers_create_saml_relying-party.md)」を参照してください。

# カスタム信頼ポリシーを使用してロールを作成する
<a name="id_roles_create_for-custom"></a>

カスタムの信頼ポリシーを作成して、アクセスを委任し、他のユーザーに自分の AWS アカウント でアクションの実行を許可することができます。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。

ロールを使用してアクセス権限を委任する方法の詳細については、「[ロールに関する用語と概念](id_roles.md#id_roles_terms-and-concepts)」を参照してください。

## カスタム信頼ポリシーを使用した IAM ロールの作成 (コンソール)
<a name="roles-creatingrole-custom-trust-policy-console"></a>

IAM ユーザーが引き受けるロールは、AWS マネジメントコンソール を使用して作成できます。例えば、組織で複数の AWS アカウント を使用して本稼働環境から開発環境を分離しているとします。開発用アカウントのユーザーに対して本番用アカウントのリソースへのアクセスを許可するロールを作成するための高レベルの情報については、「[個別の開発用アカウントと本稼働用アカウントを使用したシナリオ例](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example)」を参照してください。

**カスタム信頼ポリシーを使用してロールを作成するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. コンソールのナビゲーションペインで、**[ロール]**、**[ロールの作成]** の順に選択します。

1. **[Custom trust policy]** (カスタム信頼ポリシー) ロールタイプを選択してください。

1. **[Custom trust policy]** (カスタム信頼ポリシー) セクションで、ロールのカスタム信頼ポリシーを入力または貼り付けます。詳細については、「[IAM ポリシーの作成](access_policies_create-console.md#access_policies_create-start)」を参照してください。

1. [ポリシーの検証](access_policies_policy-validator.md)中に生成されたセキュリティ警告、エラー、または一般的な警告を解決してから、[**Next**] (次へ) を選択します。

1. (オプション) [アクセス許可の境界](access_policies_boundaries.md)を設定します。このアドバンスド機能は、サービスロールで使用できますが、サービスにリンクされたロールではありません。

   **[Permissions boundary]** (アクセス許可の境界) セクションを開き、**[Use a permissions boundary to control the maximum role permissions]** (アクセス許可の境界を使用してロールのアクセス許可の上限を設定する) を選択します。IAM には、あなたのアカウント内の AWS 管理ポリシーとカスタマー管理ポリシーのリストがあります。アクセス許可の境界として使用するポリシーを選択します。

1. [**次へ**] を選択します。

1. [**ロール名**] の場合、ロール名のカスタマイズの度合いはサービスによって定義されます。サービスのロール名が定義されている場合、このオプションを変更することはできません。それ以外の場合、サービスでロールのプレフィックスが定義され、オプションのサフィックスを入力できる場合があります。一部のサービスでは、ロールの名前全体を指定することができます。

   可能な場合は、ロール名またはロール名のサフィックスを入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。大文字と小文字は区別されません。例えば、**PRODROLE** と **prodrole** というロール名を両方作成することはできません。他の AWS リソースがロールを参照している場合があるため、作成後はロールの名前を変更できません。

1. (オプション) **[説明]** には、新しいロールの説明を入力します。

1. (オプション) **[ステップ 1: 信頼されたエンティティを選択する]** または **[ステップ 2: 許可を追加する]** セクションで **[編集]** を選択し、ロールのカスタムポリシーと許可を編集します。

1. (オプション) タグをキーバリューのペアとしてアタッチして、メタデータをロールに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。

1. ロール情報を確認し、**ロールの作成** を選択します。

# アクセス権を委任するポリシーの例
<a name="id_roles_create_policy-examples"></a>

以下の例では、AWS アカウント に別の AWS アカウント のリソースへのアクセスを許可する方法を示しています。これらの例の JSON ポリシードキュメントを使用して IAM ポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

**Topics**
+ [

## ロールを使用して他の AWS アカウント のリソースへのアクセス権を委任する
](#example-delegate-xaccount-rolesapi)
+ [

## ポリシーを使用してサービスへのアクセスを委任する
](#id_roles_create_policy-examples-access-to-services)
+ [

## リソースベースのポリシーを使用して他のアカウントの Amazon S3 バケットへのアクセス権を委任する
](#example-delegate-xaccount-S3)
+ [

## リソースベースのポリシーを使用して他のアカウントの Amazon SQS キューへのアクセス権を委任する
](#example-delegate-xaccount-SQS)
+ [

## アカウントがアクセスを拒否されているとアクセス権を委任できない
](#example-delegate-xaccount-SQS-denied)

## ロールを使用して他の AWS アカウント のリソースへのアクセス権を委任する
<a name="example-delegate-xaccount-rolesapi"></a>

 IAM ロールを使用し、あるアカウントに属しているユーザーに、他のアカウントに属している AWS リソースへのアクセスを許可する方法のチュートリアルについては、「[IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](tutorial_cross-account-with-roles.md)」を参照してください。

**重要**  
特定のロールまたはユーザーの ARN を、ロールの信頼ポリシーの `Principal` 要素に含めることができます。ポリシーを保存すると、AWS は ARN を一意のプリンシパル ID に変換します。これにより、ロールまたはユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。通常、この ID はコンソールには表示されません。これは、信頼ポリシーが表示されるときに、ARN への逆変換が行われるためです。ただし、ロールまたはユーザーを削除すると、関係が壊れます。ポリシーは、ユーザーまたはロールを再作成しても適用されません。これは、信頼ポリシーに保存されているプリンシパル ID に一致しないためです。この場合、プリンシパル ID はコンソールに表示されます。これは、AWS が ARN に ID をマッピングできなくなるためです。その結果、信頼ポリシーの `Principal` 要素で指し示しているユーザーまたはロールを削除し、再作成する場合、ロールを編集して ARN を置き換える必要があります。ポリシーを保存するときに、ARN は新しいプリンシパル ID に変換されます。

## ポリシーを使用してサービスへのアクセスを委任する
<a name="id_roles_create_policy-examples-access-to-services"></a>

次の例では、ロールにアタッチできるポリシーを示します。ポリシーは、Amazon EMR および AWS Data Pipeline の 2 つのサービスを有効にして、ロールを想定します。これらのサービスは、ロールに割り当てられた権限ポリシー (表示されていない) によって付与されたタスクを実行できます。複数のサービスプリンシパルを指定する場合に、2 つの `Service` 要素は指定できません。1 つのみ指定できます。代わりに、1 つの `Service` 要素の値として複数のサービスのプリンシパルのアレイを使用します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

------

## リソースベースのポリシーを使用して他のアカウントの Amazon S3 バケットへのアクセス権を委任する
<a name="example-delegate-xaccount-S3"></a>

この例では、アカウント A はリソースベースのポリシー (Amazon S3 [バケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html)) を利用して、アカウント A の S3 バケットへのフルアクセスをアカウント B に許可します。次に、アカウント B が IAM ユーザーポリシーを作成して、アカウント A のバケットへのアクセス権をアカウント B のいずれかのユーザーに委任します。

アカウント A の S3 バケットポリシーは以下のポリシーのようになります。この例では、アカウント A の S3 バケットの名前を amzn-s3-demo-bucket とし、アカウント B のアカウント番号を 111122223333 とします。この番号は、アカウント B の個々のユーザーまたはグループではなく、アカウント自体のみを指定します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}
```

------

また、アカウント A は Amazon S3 [アクセスコントロールリスト (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html) を使用して、アカウント B に S3 バケットまたはバケット内の 1 つのオブジェクトへのアクセスを許可することもできます。この場合、唯一変更する点は、アカウント A がアカウント B にアクセス権を付与する方法です。ただし、この例の 2 番目の部分で説明したように、アカウント B はポリシーを使用して、アカウント B の IAM グループにアクセス権を委任することになります。S3 バケットとオブジェクトのアクセス制御の詳細については、[Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html)の*アクセス制御*を参照してください。

アカウント B の管理者が、次のサンプルポリシーを作成するとします。このポリシーでは、アカウント B のグループまたはユーザーに読み取りアクセスが許可されます。前のポリシーでは、アカウント B へのアクセスが許可されます。ただし、アカウント B の個々のグループとユーザーは、グループまたはユーザーポリシーでリソースへの明示的なアクセス許可が付与されるまで、リソースにアクセスできません。このポリシーのアクセス許可は、前のクロスアカウントポリシーのアクセス許可のサブセットとしてのみ付与できます。アカウント B はそのグループとユーザーに、最初のポリシーでアカウント A から付与されたものよりも多くのアクセス権限を付与することはできません。このポリシーでは、`Action` アクションのみを許可するように `List` 要素が明示的に定義されます。このポリシーの `Resource` 要素は、アカウント A が実装するバケットポリシーの `Resource` に一致します。

このポリシーを実装するには、アカウント B は IAM を使用して、アカウント B の該当するユーザー (またはグループ) にそのポリシーをアタッチします。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}
```

------

## リソースベースのポリシーを使用して他のアカウントの Amazon SQS キューへのアクセス権を委任する
<a name="example-delegate-xaccount-SQS"></a>

以下の例では、アカウント A には Amazon SQS キューがあり、キューにアタッチされているリソースベースのポリシーを使用して、キューへのアクセスをアカウント B に許可します。その後で、アカウント B が IAM グループポリシーを使用して、アカウント B のグループにアクセス許可を委任します。

下記の例のキューポリシーでは、アカウント B にアカウント A の *queue1* というキューで `SendMessage` および `ReceiveMessage` のアクションを実行するアクセス許可が付与されます。ただし、この許可が有効なのは、2014 年 11 月 30 日の正午から午後 3 時の間だけです。アカウント B のアカウント番号は 1111-2222-3333 です。アカウント A は、Amazon SQS を使用して、このポリシーを実装します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}
```

------

アカウント B のグループにアクセス権を委任するアカウント B のポリシーは、以下の例のようになります。アカウント B は、IAM を使用して、このポリシーをグループ（またはユーザー）にアタッチします。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}
```

------

上記の IAM ユーザーポリシーの例では、アカウント B はワイルドカードを使用して、属しているユーザーに、アカウント A のキューに対するすべての Amazon SQS アクションへのアクセスを許可しています。ただし、アカウント B は、アカウント B にアクセス許可が付与されている範囲においてのみ、アクセスを委任できます。2 つ目のポリシーを持つアカウント B グループは、2014 年 11 月 30 日の正午から午後 3 時の間だけキューにアクセスできます。ユーザーが実行できるのは、アカウント A の Amazon SQS キューポリシーで定義されている `SendMessage` および `ReceiveMessage` アクションのみです。

## アカウントがアクセスを拒否されているとアクセス権を委任できない
<a name="example-delegate-xaccount-SQS-denied"></a>

AWS アカウント は、自リソースへのアクセスをユーザーの親アカウントに対して明示的に拒否している場合、自リソースへのアクセス権をそれらのユーザーに委任することはできません。この拒否は、アクセス権を付与する既存のポリシーをユーザーが持っているかどうかにかかわらず、そのアカウントのユーザーにも反映されます。

たとえば、アカウント A は自身の S3 バケットについて、アカウント B からのアクセスを明示的に拒否するバケットポリシーを作成するとします。ただし、アカウント B は、アカウント B のユーザーにアカウント A のバケットへのアクセス権を付与する IAM ユーザーポリシーを作成しています。アカウント A の S3 バケットに適用される明示的な拒否は、アカウント B のユーザーにも反映され、アカウント B のユーザーにアクセス権を付与する IAM ユーザーポリシーよりも優先されます (アクセス許可の評価方法については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください)。

アカウント A のバケットポリシーは、以下のポリシーになります。この例では、アカウント A の S3 バケットの名前を amzn-s3-demo-bucket とし、アカウント B のアカウント番号を 1111-2222-3333 とします。アカウント A は、Amazon S3 を使用して、このポリシーを実装します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
  }
}
```

------

この明示的な拒否は、アカウント A の S3 バケットにアクセスする権限を提供するアカウント B のポリシーをオーバーライドします。

# IAM ロールの管理
<a name="id_roles_manage"></a>

作成したロールをユーザー、アプリケーション、またはサービスが使用できるようにするには、該当のロールに切り替えるためのアクセス許可を付与する必要があります。グループまたはユーザーにアタッチされたポリシーを使用して、必要なアクセス許可を付与することができます。このセクションでは、ロールを使用するアクセス許可をユーザーに付与する方法について説明します。また、ユーザーが、AWS マネジメントコンソール、 Tools for Windows PowerShell、 AWS Command Line Interface (AWS CLI) 、および [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API からロールに切り替える方法についても説明します。

**重要**  
ロールの作成を IAM コンソールではなくプログラムで行う場合は、最大 64 文字までの `Path` に加えて最大 512 文字までの `RoleName` を追加できます。ただし、AWS マネジメントコンソール の [**ロールの切り替え**] 機能でロールを使用する場合は、`Path` と `RoleName` の合計が 64 文字を超えることはできません。

**Topics**
+ [

## ロールのアクセスの表示
](#roles-modify_prerequisites)
+ [

## アクセス情報に基づくポリシーの生成
](#roles-modify_gen-policy)
+ [

# ロールを切り替えるアクセス許可をユーザーに付与する
](id_roles_use_permissions-to-switch.md)
+ [

# AWS サービスにロールを渡すアクセス許可をユーザーに付与する
](id_roles_use_passrole.md)
+ [

# IAM ロールの一時的なセキュリティ認証情報を取り消す
](id_roles_use_revoke-sessions.md)
+ [

# サービスにリンクされたロールを更新する
](id_roles_update-service-linked-role.md)
+ [

# ロール信頼ポリシーを更新する
](id_roles_update-role-trust-policy.md)
+ [

# ロールに対するアクセス許可を更新する
](id_roles_update-role-permissions.md)
+ [

# ロールの設定を更新する
](id_roles_update-role-settings.md)
+ [

# ロールまたはインスタンスプロファイルを削除する
](id_roles_manage_delete.md)

## ロールのアクセスの表示
<a name="roles-modify_prerequisites"></a>

ロールのアクセス許可を変更する前に、サービスレベルの最近のアクティビティを確認する必要があります。これは、アクセス権を使用しているプリンシパル (ユーザーまたはアプリケーション) から削除しないようにするために重要です。最後にアクセスした情報を表示する方法の詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](access_policies_last-accessed.md)」を参照してください。

## アクセス情報に基づくポリシーの生成
<a name="roles-modify_gen-policy"></a>

IAM エンティティ (ユーザーまたはロール) に必要な権限を超えるアクセス許可を付与することがあります。付与するアクセス権限を調整するために、エンティティのアクセスアクティビティに基づく IAM ポリシーを生成できます。IAM Access Analyzer は AWS CloudTrail ログを確認し、指定した日付範囲内のロールが使用したアクセス許可を含むポリシーテンプレートを生成します。テンプレートを使用して、きめ細かなアクセス権限で管理ポリシーを作成し、それを IAM エンティティにアタッチできます。これにより、特定のユースケースでロールが AWS リソースとインタラクションするために必要なアクセス権限のみを付与します。詳細については、「[IAM Access Analyzer ポリシーの生成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)」を参照してください。

# ロールを切り替えるアクセス許可をユーザーに付与する
<a name="id_roles_use_permissions-to-switch"></a>

管理者が[クロスアカウントアクセス用のロールを作成する](id_roles_create_for-user.md)場合、ロールを所有するアカウント、リソース (信頼するアカウント)、およびユーザーを含むアカウント (信頼されるアカウント) の間で信頼を確立します。これを行うには、信頼するアカウントの管理者が、ロールの信頼ポリシーで信頼できるアカウント番号を `Principal` として指定します。これにより、信頼されたアカウント内のすべてのユーザーがロールを引き受けることができるようになる*可能性*があります。設定を完了するには、信頼されたアカウントの管理者がそのアカウント内の特定のグループまたはユーザーにロールを切り替えるアクセス権限を付与する必要があります。

**ロールを切り替えるアクセス許可を付与するには**

1. 信頼されたアカウントの管理者として、ユーザーの新しいポリシーを作成するか、既存のポリシーを編集して必要な要素を追加します。詳細については、「[ポリシーの作成または編集](#roles-usingrole-createpolicy)」を参照してください。

1. 次に、ロール情報を共有する方法を次の中から選択します。
   + **ロールリンク:** 詳細がすべて既に入力されている **[Switch Role]** (ロールの切り替え) ページへのリンクをユーザーに送信します。
   + **アカウント ID またはエイリアス:** ロール名とアカウント ID 番号またはアカウントのエイリアスを各ユーザーに提供します。これにより、ユーザーは [**ロールの切り替え**] ページに移動し、詳細を手動で追加できます。

   詳細については、「[ユーザーへの情報の提供](#roles-usingrole-giveuser)」を参照してください。

ロールを切り替えできるのは、IAM ユーザー、SAML フェデレーションロール、またはウェブ ID フェデレーションロールとしてサインインしている場合のみですのでご注意ください。AWS アカウントのルートユーザー としてサインインすると、ロールを切り替えることはできません。

**重要**  
AWS マネジメントコンソール で、[ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) 値を必要とするロールに切り替えることはできません。`ExternalId` パラメータをサポートする [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API を呼び出すことにより、このようなロールに切り替えることができます。

**注意事項**  
タスクを達成するために最終的にユーザーにアクセス許可を付与するので、このトピックでは、ユーザーのポリシーについて説明します。ただし、個々のユーザーに直接アクセス許可を付与することはお勧めしません。ユーザーがロールを引き受けると、そのロールに関連付けられたアクセス許可が割り当てられます。
AWS マネジメントコンソール でロールを切り替えると、コンソールは常に元の認可情報を使用して切り替えを認可します。これは、IAM ユーザー、SAML フェデレーションロール、またはウェブ ID フェデレーションロールとしてサインインする際に適用されます。例えば、RoleA に切り替える場合は、IAM では元のユーザーまたはフェデレーションロールの認証情報を使用して、RoleA の引き受けが許可されているかどうかが判断されます。その後、*RoleA を使用中*に RoleB への切り替えを試みると、**元の**ユーザーまたはフェデレーションロールの認証情報を使用して、RoleB への切り替えが認可されます。RoleA の資格情報は、このアクションには使用されません。

**Topics**
+ [

## ポリシーの作成または編集
](#roles-usingrole-createpolicy)
+ [

## ユーザーへの情報の提供
](#roles-usingrole-giveuser)

## ポリシーの作成または編集
<a name="roles-usingrole-createpolicy"></a>

ロールを引き受けるアクセス許可をユーザーに付与するポリシーには、次の `Allow` 効果を伴うステートメントを含める必要があります。
+ `sts:AssumeRole` アクション
+ `Resource` 要素でのロールの Amazon リソースネーム (ARN)

このポリシーを取得するユーザーは、(グループメンバーとして、または直接アタッチされて) 一覧表示されたリソース上のロールに切り替えることができます。

**注記**  
`Resource` が `*` に設定されている場合、ユーザーは、ユーザーのアカウントを信頼する任意のアカウントで任意のロールを引き受けることができます。（つまり、ロールの信頼ポリシーは、ユーザーのアカウントを `Principal` として指定します）。ベストプラクティスとして、[最小権限の原則](http://en.wikipedia.org/wiki/Principle_of_least_privilege)に従って、ユーザーが必要とするロールに限って完全な ARN を指定することをお勧めします。

次の例に示すポリシーでは、ユーザーは 1 つのアカウントに限ってロールを引き受けることができます。さらに、このポリシーではワイルドカード (\$1) を使用し、ロール名が文字列 `Test` で始まる場合に限り、ユーザーがロールに切り替えることができることを指定します。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::111122223333:role/Test*"
    }
}
```

------

**注記**  
ロールをユーザーに付与するアクセス権限は、既にユーザーに付与されているアクセス権限に追加されるわけではありません。ユーザーがロールに切り替えると、そのユーザーはロールによって付与されたアクセス権限と引き換えに元々付与されていたアクセス権限を一時的に喪失します。ユーザーがロールを終了すると、元のユーザーアクセス権限が自動的に復元します。例えば、ユーザーのアクセス許可では Amazon EC2 インスタンスの操作が許可されるが、これらのアクセス許可はロールのアクセス許可ポリシーで付与されないとします。この場合、ロールの使用中に、ユーザーはコンソールで Amazon EC2 インスタンスを操作できません。さらに、`AssumeRole` を介して取得された一時的な認証情報は、プログラムでは Amazon EC2 インスタンスで機能しません。

## ユーザーへの情報の提供
<a name="roles-usingrole-giveuser"></a>

ロールを作成し、このロールに切り替えるアクセス許可をユーザーに付与した後で、ユーザーに以下を提供する必要があります。
+ ロールの名前は
+ ID またはロールが含まれているアカウントエイリアス

アカウント ID とロール名が事前設定されたリンクを送信すると、ユーザーのアクセスが簡素化されます。ロールのリンクは、**[ロールの作成]** ウィザードの完了後に **[ロールを表示]** バナーを選択すると表示されます。また、クロスアカウントが有効なロールの場合は **[ロールの概要]** ページに表示されます。

または、次の形式を使用して手動でリンクを作成することもできます。次の例の 2 つのパラメータのアカウント ID またはエイリアスとロール名を置き換えます。

`https://signin.aws.amazon.com/switchrole?account=your_account_ID_or_alias&roleName=optional_path/role_name`

ユーザーにトピック「[ユーザーから IAM ロールに切り替える (コンソール)](id_roles_use_switch-role-console.md)」を参照してプロセスに従って進めてもらうことをお勧めします。ロールを引き受ける際に遭遇する可能性がある一般的な問題のトラブルシューティングを行うには、、「[ロールを引き受けることができない](troubleshoot_roles.md#troubleshoot_roles_cant-assume-role)」を参照してください。

**考慮事項**
+ プログラムでロールを作成する場合は、パスと名前を持ったロールを作成できます。、ユーザーが AWS マネジメントコンソール の[**ロールの切り替え**]ページで入力できるように、完全なパスとロール名をユーザーに提供する必要があります。例: `division_abc/subdivision_efg/role_XYZ`。
+ プログラムでロールを作成する場合は、512 文字までの `Path` と `RoleName` を追加できます。名前の長さは最大 64 文字です。ただし、AWS マネジメントコンソール の [**ロールの切り替え**] 機能でロールを使用するには、`Path` と `RoleName` の合計が 64 文字を超えることはできません。
+ セキュリティ上の理由から、[AWS CloudTrail ログを確認](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)して、AWS でアクションを実行したユーザーを調べることができます。ロール信頼ポリシーで `sts:SourceIdentity` 条件キーを使用すると、ユーザーがロールを引き受けるときに ID を指定するように要求できます。例えば、IAM ユーザーがセッション名として自分のユーザー名を指定するように要求できます。これにより、AWS の特定のアクションを実行したユーザーを特定できます。詳細については、「[`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity)」を参照してください。[`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname) 条件キーを使用すると、ユーザーがロールを引き受けるときにセッション名を指定するように要求できます。これは、ロールが異なるプリンシパルによって使用される場合に、ロールセッションを区別するのに役立ちます。

# AWS サービスにロールを渡すアクセス許可をユーザーに付与する
<a name="id_roles_use_passrole"></a>

多くの AWS サービスを設定するには、そのサービスに IAM ロールを*渡す*必要があります。これで、その後サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。大半のサービスでは、サービスにロールを渡さなければならないのはセットアップ時の 1 回のみで、サービスがロールを引き受けるたびには行いません。例えば、Amazon EC2 インスタンスで実行しているアプリケーションがあるとします。このアプリケーションには認証に使う一時的な認証情報と、AWSでアクションを実行するためのアプリケーション認可のアクセス許可が必要です。アプリケーションをセットアップする場合、こうした認証情報を提供するインスタンスで使用するよう、Amazon EC2 にロールを渡す必要があります。そのロールに IAM ポリシーをアタッチして、インスタンスで実行するアプリケーションのアクセス許可を定義します。アプリケーションは、このロールが許可しているアクションを実行する必要があるたびに、ロールを引き受けます。

ユーザーがロール (とそのアクセス許可) を AWS サービスに渡すには、そのサービスに*ロールを渡す*アクセス許可が必要になります。これにより、承認済みのユーザーのみが、アクセス許可を付与するロールを使用してサービスを設定できるようになります。ユーザーが AWS サービスにロールを渡すには、IAM ユーザー、ロール、またはグループに `PassRole` アクセス許可を付与する必要があります。

**警告**  
同じ AWS アカウントを共有するサービスに IAM ロールを渡すには、`PassRole` のアクセス許可のみ使用できます。アカウント A のロールをアカウント B のサービスに渡すには、まずアカウント A からロールを引き受けることができる IAM ロールをアカウント B に作成する必要があります。その後、アカウント B のロールをサービスに渡すことができます。詳細については、「[IAM でのクロスアカウントのリソースへのアクセス](access_policies-cross-account-resource-access.md)」を参照してください。
ロールをタグ付けした後に、`iam:PassRole` アクションでポリシー内の `ResourceTag` 条件キーを使用してロールを渡せるユーザーを制御しないようにしてください。このアプローチでは信頼できる結果は得られません。

`PassRole` アクセス許可を設定する場合、ユーザーがロールに必要以上のアクセス許可があるロールを渡さないようにする必要があります。例えば、Alice が Amazon S3 アクションを実行する許可を持っていない場合があります。Alice が Amazon S3 アクションを許可するサービスにロールを渡すことができる場合、サービスはジョブの実行時に、Alice に代わって Amazon S3 アクションを実行できます。

サービスにリンクされたロールを特定する場合は、サービスにそのロールを渡すためのアクセス許可も必要になります。一部のサービスでは、そのサービスでアクションを実行する際にアカウント内にサービスにリンクされたロールが自動的に作成されます。例えば、Amazon EC2 Auto Scaling では Auto Scaling グループが最初に作成されたときに、`AWSServiceRoleForAutoScaling` のサービスにリンクされたロールを作成します。のアクセス許可がない状態で Auto Scaling グループの作成時にサービスにリンクされたのアクセス許可がない状態で、のアクセス許可がない状態で、`iam:PassRole` のアクセス許可がない状態で、エラーが表示されます。ロールを明示的に指定しない場合、`iam:PassRole` のアクセス許可は不要で、デフォルトではそのグループで実行されるすべての操作に `AWSServiceRoleForAutoScaling` ロールを使用します。サービスにリンクされたロールをサポートするサービスを確認するには、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。サービスにリンクされたロールがサービスでアクションの実行時に自動的に作成されるかどうかを確認するには、「**はい**」リンクを選択して、該当サービスのサービスにリンクされたロールに関するドキュメントを参照してください。

ユーザーは、ロールを使用してサービスにアクセス許可を割り当てる任意の API オペレーションで、パラメータとして ARN を渡すことができます。次に、そのサービスはユーザーに `iam:PassRole` 権限があるかどうか確認します。ユーザーが渡せるロールを承認済みのロールだけに制限するには `iam:PassRole` のアクセス許可と IAM のポリシーステートメントの `Resources` 要素をフィルターに掛けることができます。

JSON ポリシーの `Condition` 要素を使用して、すべての AWS リクエストのリクエストコンテキストに含まれるキーの値をテストできます。ポリシーでの条件キーの使用の詳細については、「[IAM JSON ポリシー要素Condition](reference_policies_elements_condition.md)」をご参照ください。`iam:PassedToService` 条件キーを使用して、ロールを渡すことができるサービスのサービスプリンシパルを指定できます。ポリシーでの `iam:PassedToService` 条件キーの使用の詳細については、「[iam:PassedToService](reference_policies_iam-condition-keys.md#ck_PassedToService)」をご参照ください。

**例 1**  
インスタンスの起動時に、承認済みの一連のロールを Amazon EC2 サービスに渡すための権限をユーザーに付与したいと考えているとします。その場合、3 つの要素が必要です。
+ ロールに許可されている内容を定義し、ロールにアタッチしている IAM の*アクセス許可ポリシー* ロールが実行しなければならない操作やロールが操作を実行する上で必要とするリソースのみにアクセス許可を制限します。AWS のマネージドまたはカスタマー定義の IAM アクセス権ポリシーが使用できます。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": {
          "Effect": "Allow",
          "Action": [ "A list of the permissions the role is allowed to use" ],
          "Resource": [ "A list of the resources the role is allowed to access" ]
      }
  }
  ```

------
+ サービスにロールの引き受けを許可する、ロールの*信頼ポリシー*。例えば、次の信頼ポリシーを `UpdateAssumeRolePolicy` アクションを使用するロールにアタッチできます。この信頼ポリシーは Amazon EC2 がロールを使用し、そのロールにアタッチしているアクセス許可の使用を許可します。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": {
          "Sid": "TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole",
          "Effect": "Allow",
          "Principal": { "Service": "ec2.amazonaws.com" },
         "Action": "sts:AssumeRole"
      }
  }
  ```

------
+ 承認済みのロールのみをユーザーが渡せるように許可する、IAM ユーザーにアタッチしている IAM の*アクセス許可ポリシー*。ユーザーが渡すロールの詳細を得るため、通常 `iam:GetRole` を `iam:PassRole` に追加します。この例でユーザーが渡すことができるのは、指定されたアカウントに存在し、`EC2-roles-for-XYZ-` で始まる名前を持つロールに限ります。

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iam:GetRole",
                  "iam:PassRole"
              ],
              "Resource": "arn:aws:iam::111122223333:role/EC2-roles-for-XYZ-*"
          }
      ]
  }
  ```

------

これでユーザーは割り当てられたロールで Amazon EC2 インスタンスを起動することができます。インスタンスで実行しているアプリケーションはインスタンスプロファイルのメタデータのロールで一時的な認証情報にアクセスすることができます。ロールにアタッチされたアクセス権限ポリシーは、インスタンスに許可する操作を定義します。

**例 2**  
Amazon Relational Database Service (Amazon RDS) は、**拡張モニタリング**と呼ばれる機能をサポートしています。この機能により、Amazon RDS はエージェントを使用してデータベースインスタンスをモニタリングできます。また、Amazon RDS は Amazon CloudWatch Logs にメトリックスを記録することもできます。この機能を有効にするには、サービスロールを作成して、メトリクスをモニタリングしログに書き込む権限を Amazon RDS に付与する必要があります。

**Amazon RDS 拡張モニタリング用のロールを作成するには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. [**ロール**]、[**ロールの作成**] の順に選択します。

1. **[AWS Service]** ロールタイプを選択し、**[Use cases for other AWS のサービス]** で **[RDS]** サービスを選択します。**[RDS – Enhanced Monitoring]** (RDS – 拡張モニタリング)、**[Next]** (次へ) の順に選択します。

1. **AmazonRDSEnhancedMonitoringRole** アクセス権ポリシーを選択します。

1. [**次へ**] を選択します。

1. **[Role name]** (ロール名) に、このロールの目的を識別しやすくするロール名を入力します。ロール名は AWS アカウント アカウント内で一意である必要があります。ロール名がポリシーまたは ARN の一部として使用される場合、ロール名は大文字と小文字が区別されます。サインイン処理中など、コンソールでロール名がユーザーに表示される場合、ロール名は大文字と小文字を区別しません。さまざまなエンティティがロールを参照する可能性があるため、作成後にロール名を編集することはできません。

1. (オプション) **[説明]** には、新しいロールの説明を入力します。

1. (オプション) タグをキーバリューペアとしてアタッチして、メタデータをユーザーに追加します。IAM におけるタグの使用の詳細については、「[AWS Identity and Access Management リソースのタグ](id_tags.md)」を参照してください。

1. ロール情報を確認し、**ロールの作成** を選択します。

ロールを引き受ける `monitoring.rds.amazonaws.com` サービスのアクセス許可を付与する信頼ポリシーをロールが自動的に取得します。その後、Amazon RDS は `AmazonRDSEnhancedMonitoringRole` ポリシーが許可するすべての操作を実行できるようになります。

拡張モニタリングへのアクセスを許可するユーザーは、次に示すように、ユーアーが RDS をリストすることを許可するステートメントとユーザーがロールを渡すことを許可するステートメントを含むポリシーが必要になります。アカウント番号を自分のものに置き換え、ロールの名前をステップ 6 で指定した名前に置き換えます。

```
    {
      "Sid": "PolicyStatementToAllowUserToListRoles",
      "Effect": "Allow",
      "Action": ["iam:ListRoles"],
      "Resource": "*"
    },
    {
        "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
        "Effect": "Allow",
        "Action": [ "iam:PassRole" ],
        "Resource": "arn:aws:iam::account-id:role/RDS-Monitoring-Role"
    }
```

別のポリシーのステートメントとこのステートメントを組み合わせたり、独自のポリシーで使用することができます。代わりにユーザーが `RDS-` で始まるロールを渡せるように指定するには、以下のようにリソース ARN にあるロールの名前をワイルドカードに置き換えできます。

```
        "Resource": "arn:aws:iam::account-id:role/RDS-*"
```

## AWS CloudTrail ログ内の `iam:PassRole` アクション
<a name="id_roles_use_passrole_logs"></a>

 `PassRole` は API 呼び出しではありません。`PassRole` はアクセス許可です。つまり、IAM `PassRole` には CloudTrail ログは生成されません。CloudTrail でどのロールがどの AWS のサービス に渡されるかを確認するには、ロールを受け取る AWS のリソースを作成または変更した CloudTrail ログを確認する必要があります。例えば、ロールが作成されると AWS Lambda 関数に渡されます。`CreateFunction` アクションのログには、関数に渡されたロールの記録が表示されます。

# IAM ロールの一時的なセキュリティ認証情報を取り消す
<a name="id_roles_use_revoke-sessions"></a>

**警告**  
このページの手順に従うと、ロールを引き受けることによって作成された現在のセッションのすべてのユーザーは、すべての AWS アクションとリソースへのアクセスを拒否されます。その結果、保存されていない作業は失われます。

ユーザーが長いセッションの有効期間 (12 時間など) を使用して AWS マネジメントコンソール にアクセスできるようにすると、一時的な認証情報がすぐに期限切れになることはありません。ユーザーが意図せずに認証情報を不正なサードパーティーに公開した場合、そのパーティーはセッションの期間アクセスできます。ただし、必要がある場合は、特定の時点より前に発行したロールの認証情報の、すべてのアクセス許可をすぐに取り消しできます。指定された時間より前に発行された、そのロールのすべての一時的な認証情報が無効になります。これにより、すべてのユーザーは新しい認証情報を再認証し、リクエストしなければならなくなります。

 

**注記**  
*[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)*のセッションを取り消すことはできません。

このトピックの手順を使用してロールのアクセス許可を取り消す場合、AWS は、すべてのアクションへのすべてのアクセス許可を拒否するロールに新しいインラインポリシーをアタッチします。このポリシーに含まれる条件によって制限が適用されるのは、アクセス許可が取り消される*前*にユーザーがロールを引き受けた場合のみです。アクセス許可が取り消された*後*にユーザーがロールを引き受けた場合、拒否ポリシーはそのユーザーに適用されません。

アクセスの拒否ついての詳細は、「[一時的なセキュリティ認証情報のアクセス権限を無効にする](id_credentials_temp_control-access_disable-perms.md)」を参照してください。

**重要**  
この拒否ポリシーは、期間が長いコンソールセッションを使用するユーザーにだけでなく、指定されたロールのすべてのユーザーに適用されます。

## ロールからセッションアクセス許可を取り消すための最小限のアクセス許可
<a name="revoke-session-permissions"></a>

ロールから正常にセッションアクセス許可を取り消すには、ロールの `PutRolePolicy` アクセス許可が必要です。これにより、`AWSRevokeOlderSessions` インラインポリシーをロールにアタッチできます。

## セッションアクセス許可のキャンセル
<a name="revoke-session"></a>

ロールからセッションのアクセス許可を取り消すと、ロールを引き受けたすべてのユーザーに対するすべてのアクセス許可を拒否できます。

**注記**  
IAM アイデンティティセンターのアクセス許可セットから作成された IAM のロールを編集することはできません。IAM アイデンティティセンターでユーザーのアクティブなアクセス許可セットセッションを取り消す必要があります。詳細については、「IAM Identity Center ユーザーガイド」の「[Revoke active IAM role sessions created by permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions)」を参照してください。

**ロール認証情報のすべての現在のユーザーの、すべてのアクセス許可をすぐに拒否するには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ロール]** に続いて、アクセス許可を取り消すロールの名前 (チェックボックスではありません) を選択します。

1. 選択したロールの **[概要]** ページで、**[セッションの無効化]** タブを選択します。

1. **[セッションの無効化]** タブで、**[アクティブなセッションの無効化]** を選択します。

1. AWS によってアクションを確認するよう求められます。**[このロールのアクティブなセッションをすべて無効にすることに同意します]** のチェックボックスをオンにして、ダイアログボックスの **[アクティブなセッションの無効化]** を選択します。

   その後、IAM がロールに `AWSRevokeOlderSessions` という名前のポリシーをアタッチします。**[アクティブなセッションの無効化]** を選択すると、ポリシーは、過去にロールを引き受けたユーザーに加えて、約 30 秒後にロールを引き受けるユーザーに対するすべてのアクセスを拒否します。この将来の時間の選択では、更新されたポリシーが特定のリージョンで有効になる前に取得または更新された新しいセッションに対処するために、ポリシーの伝播遅延が考慮されます。[アクティブなセッションの無効化] を選択した後、約 30 秒が経過した後にロールを引き受けるユーザーは影響を受けません。変更がすぐに表示されるとは限らない理由については、「[行った変更がすぐに表示されないことがある](troubleshoot.md#troubleshoot_general_eventual-consistency)」をご参照ください。

**注記**  
後で再度 **[アクティブなセッションの無効化]** を選択すると、ポリシーのタイムスタンプが更新され、新しく指定された時間の前にロールを引き受けたユーザーのすべてのアクセス許可が再度拒否されます。

この方法でセッションが取り消された有効なユーザーは、作業を続行するには新しいセッション用の一時的な認証情報を取得する必要があります。この AWS CLI は、期限切れになるまで認証情報をキャッシュします。有効でなくなった、キャッシュされている認証情報の削除と更新を CLI に強制するには、次のいずれかのコマンドを実行します。

**Linux、macOS、または Unix**

```
$ rm -r ~/.aws/cli/cache
```

**Windows**

```
C:\> del /s /q %UserProfile%\.aws\cli\cache
```

## 指定した時間よりも前にセッションのアクセス許可を取り消す
<a name="revoke-session-policy"></a>

 また、AWS CLI または SDK を使用して、任意のタイミングでセッション許可を無効化することで、ポリシーの条件の要素で `aws:TokenIssueTime` キーの値を指定することもできます。

このポリシーは、`aws:TokenIssueTime` の値が指定した日時より前である場合、すべてのアクセス許可を拒否します。`aws:TokenIssueTime` の値は、一時的なセキュリティ認証情報が作成された正確な時間に相当します。`aws:TokenIssueTime` の値は、一時的なセキュリティ認証情報を使用して署名された AWS リクエストのコンテキストでのみ存在します。そのため、ポリシーの Deny ステートメントは、IAM ユーザーの長期の認証情報を使用して署名されたリクエストには影響しません。

このポリシーは、ロールにアタッチすることもできます。その場合、このポリシーは、指定した日時より前に、そのロールによって作成された一時的なセキュリティ認証情報のみに影響します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}
    }
  }
}
```

------

この方法でセッションが取り消された有効なユーザーは、作業を続行するには新しいセッション用の一時的な認証情報を取得する必要があります。この AWS CLI は、期限切れになるまで認証情報をキャッシュします。有効でなくなった、キャッシュされている認証情報の削除と更新を CLI に強制するには、次のいずれかのコマンドを実行します。

**Linux、macOS、または Unix**

```
$ rm -r ~/.aws/cli/cache
```

**Windows**

```
C:\> del /s /q %UserProfile%\.aws\cli\cache
```

# サービスにリンクされたロールを更新する
<a name="id_roles_update-service-linked-role"></a>

サービスにリンクされたロールを編集するメソッドは、サービスによって異なります。一部のサービスでは、サービスコンソール、API、CLI からサービスにリンクされたロールのアクセス権限を編集することができます。ただし、サービスにリンクされたロールを作成すると多くのエンティティによりロールが参照されるため、ロール名を変更することはできません。ロールの説明は、IAM コンソール、API、CLI から編集することができます。

サービスにリンクされたロールを使用してサポートするサービスについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[Service-Linked Role]** (サービスにリンクされたロール) 列が **[Yes]** (はい) になっているサービスを検索してください。サービスにリンクされたロールをサービスで編集できるかどうかを確認するには、「**はい**」リンクを選択して、該当サービスのサービスにリンクされたロールに関するドキュメントを参照してください。

## サービスにリンクされたロールの説明の編集 (コンソール)
<a name="edit-service-linked-role-iam-console"></a>

サービスにリンクされたロールの説明は、IAM コンソールを使用して編集できます。

**サービスにリンクされたロールの説明を編集するには (コンソール)**

1. IAM コンソールのナビゲーションペインで [**ロール**] を選択します。

1. 変更するロールの名前を選択します。

1. **ロールの説明**の右端にある**編集**を選択します。

1. ボックスに新しい説明を入力し、**保存**を選択します。

## サービスにリンクされたロールの説明の編集 (AWS CLI)
<a name="edit-service-linked-role-iam-cli"></a>

AWS CLI から IAM コマンドを使用して、サービスにリンクされたロールの説明を編集できます。

**サービスにリンクされたロールの説明を変更するには (AWS CLI)**

1. (オプション) ロールの現在の説明を表示するには、以下のコマンドを実行します。

   ```
   aws iam [get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) --role-name ROLE-NAME
   ```

   CLI コマンドでは、ARN ではなくロール名を使用してロールを参照します。例えば、ロールの ARN が `arn:aws:iam::123456789012:role/myrole` である場合、そのロールを **myrole** と参照します。

1. サービスにリンクされたロールの説明を更新するには、次のコマンドを実行します。

   ```
   aws iam [update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) --role-name ROLE-NAME --description OPTIONAL-DESCRIPTION
   ```

## サービスにリンクされたロールの説明の編集 (AWS API)
<a name="edit-service-linked-role-iam-api"></a>

サービスにリンクされたロールの説明は、AWS API を使用して編集できます。

**サービスにリンクされたロールの説明を変更するには (AWS API)**

1. (オプション) ロールの現在の説明を表示するには、次のオペレーションを呼び出し、ロールの名前を指定します。

   AWS API: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. ロールの説明を更新するには、次のオペレーションを呼び出し、ロールの名前 (およびオプションの説明) を指定します。

   AWS API: [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) 

# ロール信頼ポリシーを更新する
<a name="id_roles_update-role-trust-policy"></a>

ロールを引き受けるユーザーを変更するには、ロールの信頼ポリシーを変更する必要があります。*[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)*の信頼ポリシーは変更できません。

**注意事項**  
ユーザーがプリンシパルとしてロールの信頼ポリシーに表示されているが、そのロールを引き受けることができない場合は、ユーザーの[アクセス許可の境界](access_policies_boundaries.md)を確認します。アクセス許可の境界がユーザーに対して設定されている場合は、`sts:AssumeRole` アクションを許可する必要があります。
ロールセッション内でユーザーが現在のロールを再び引き受けることができるようにするには、ロール信頼ポリシーでロール ARN または AWS アカウント ARN をプリンシパルとして指定します。Amazon EC2、Amazon ECS、Amazon EKS、Lambda などのコンピューティングリソースを提供する AWS のサービス は、一時的な認証情報を提供し、これらの認証情報を自動的に更新します。これにより、常に有効な認証情報セットを確保できます。これらのサービスでは、一時的な認証情報を取得するために現在のロールを再度引き受ける必要はありません。ただし、[セッションタグ](id_session-tags.md)または[セッションポリシー](access_policies.md#policies_session)を渡す場合は、現在のロールを再度引き受ける必要があります。


## ロール信頼ポリシーの更新 (コンソール)
<a name="id_roles_update-trust-policy-console"></a>

**AWS マネジメントコンソールでロールの信頼ポリシーを変更するには**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. IAM コンソールのナビゲーションペインで **[ロール]** を選択します。

1. アカウントのロールの一覧で、変更するロールの名前を選択します。

1. **[信頼関係]** タブを選択し、続いて **[信頼ポリシーの編集]** を選択します。

1. 必要に応じて信頼ポリシーを編集します。ロールを引き受ける他のプリンシパルを追加するには、`Principal` 要素で指定します。以下のポリシースニペットの例では、`Principal` 要素の 2 つの AWS アカウント を参照する方法を示しています。

   ```
   "Principal": {
     "AWS": [
       "arn:aws:iam::111122223333:root",
       "arn:aws:iam::444455556666:root"
     ]
   },
   ```

   別のアカウントでプリンシパルを指定した場合、ロールの信頼ポリシーにアカウントを追加しても、クロスアカウントの信頼関係は半分しか確立されません。デフォルトでは、信頼されたアカウントのユーザーはロールを引き受けることができません。新しく信頼されたアカウントの管理者は、ロールを引き受けるアクセス許可をユーザーに付与する必要があります。これを行うには、ユーザーにアタッチするポリシーを作成または編集し、`sts:AssumeRole` アクションへのアクセスをユーザーに許可する必要があります。詳細については、次の手順または「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

   以下のポリシースニペットでは、AWS 要素で `Principal` の 2 つのサービスを参照する方法を示します。

   ```
   "Principal": {
     "Service": [
       "opsworks.amazonaws.com",
       "ec2.amazonaws.com"
     ]
   },
   ```

1. 信頼ポリシーの編集を完了したら、**[Update policy]** (ポリシーの更新) を選択して変更を保存します。

   ポリシーの構造や構文の詳細については、「[AWS Identity and Access Management でのポリシーとアクセス許可](access_policies.md)」および「[IAM JSON ポリシー要素のリファレンス](reference_policies_elements.md)」を参照してください。

**信頼された外部アカウントのユーザーにロールの使用を許可するには (コンソール)**

この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

1. 信頼された外部 AWS アカウント にサインインします。

1. ユーザーとグループのどちらにアクセス許可をアタッチするかを決定します。IAM コンソールのナビゲーションペインで **[Users]** (ユーザー) または **[User groups]** (ユーザーグループ) を適切に選択します。

1. アクセスを許可する対象となるユーザーまたはグループの名前を選択し、[**Permissions (アクセス許可)**] タブを選択します。

1. 次のいずれかを行います。
   + 既存のカスタマー管理ポリシーを編集するには、ポリシーの名前を選択してから [**ポリシーの編集**] を選択し、[**JSON**] タブを選択します。AWS の管理ポリシーを編集することはできません。AWS 管理ポリシーには AWS アイコン (![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/policy_icon.png)) が表示されます。AWS 管理ポリシーとカスタマー管理ポリシーの違いの詳細については、「[管理ポリシーとインラインポリシー](access_policies_managed-vs-inline.md)」を参照してください。
   + インラインポリシーを編集するには、ポリシーの名前の横にある矢印を選択してから、[**ポリシーの編集**] を選択します。

1. ポリシーエディターで、新しい `Statement` 要素を追加して、次のように指定します。

   ```
   {
     "Effect": "Allow",
     "Action": "sts:AssumeRole",
     "Resource": "arn:aws:iam::ACCOUNT-ID:role/ROLE-NAME"
   }
   ```

   ステートメント内の ARN を、ユーザーが引き受けるロールの ARN に置き換えます。

1. 画面のプロンプトに従って、ポリシーの編集を終了します。

## ロール信頼ポリシーの更新 (AWS CLI)
<a name="id_roles-update-trust-policy-cli"></a>

AWS CLI を使用して、誰がロールを引き受けることができるかを変更できます。

**ロールの信頼ポリシーを変更するには (AWS CLI)**

1. (オプション) 変更するロールの名前が不明である場合は、次のコマンドを実行してアカウントのロールを一覧表示します。
   + [aws iam list-roles](https://docs.aws.amazon.com/cli/latest/reference/iam/list-roles.html)

1. (オプション) ロールの現在の信頼ポリシーを表示するには、次のコマンドを実行します。
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. ロールにアクセス可能な信頼されたプリンシパルを変更するには、更新された信頼ポリシーを使用してテキストファイルを作成します。ポリシーの作成には任意のテキストエディタを使用できます。

   以下の信頼ポリシーの例では、`Principal` 要素で 2 つの AWS アカウント を参照する方法を示します。これにより、2 つの別個の AWS アカウント 内のユーザーが、このロールを引き受けることができます。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"AWS": [
               "arn:aws:iam::111122223333:root",
               "arn:aws:iam::444455556666:root"
           ]},
           "Action": "sts:AssumeRole"
       }
   }
   ```

------

   別のアカウントでプリンシパルを指定した場合、ロールの信頼ポリシーにアカウントを追加しても、クロスアカウントの信頼関係は半分しか確立されません。デフォルトでは、信頼されたアカウントのユーザーはロールを引き受けることができません。新しく信頼されたアカウントの管理者は、ロールを引き受けるアクセス許可をユーザーに付与する必要があります。これを行うには、ユーザーにアタッチするポリシーを作成または編集し、`sts:AssumeRole` アクションへのアクセスをユーザーに許可する必要があります。詳細については、次の手順または「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

1. 先ほど作成したファイルを使用して信頼ポリシーを更新するには、次のコマンドを実行します。
   + [aws iam update-assume-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-assume-role-policy.html)

**信頼された外部アカウントのユーザーにロールの使用を許可するには (AWS CLI)**

この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

1. JSON ファイルを作成し、ロールを引き受けるためのアクセス許可を付与するアクセス許可ポリシーを含めます。たとえば、次のポリシーには必要最小限のアクセス権限が含まれています。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRole",
           "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME"
       }
   }
   ```

------

   ステートメント内の ARN を、ユーザーが引き受けるロールの ARN に置き換えます。

1. 次のコマンドを実行し、信頼ポリシーが含まれている JSON ファイルを IAM にアップロードします。
   + [aws iam create-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy.html)

   このコマンドの出力には、ポリシーの ARN が含まれています。この ARN を書き留めます。後のステップで必要になります。

1. ポリシーをアタッチするユーザーまたはグループを決定します。目的のユーザーやグループの名前が不明である場合は、以下のいずれかのコマンドを使用して、アカウントのユーザーやグループを一覧表示します。
   + [aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)
   + [aws iam list-groups](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups.html)

1. 以下のいずれかのコマンドを使用して、前のステップで作成したポリシーをユーザーまたはグループにアタッチします。
   + [aws iam attach-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-user-policy.html)
   + [aws iam attach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html)

## ロール信頼ポリシーの更新 (AWS API)
<a name="id_roles-update-trust-policy-api"></a>

AWS API を使用して、誰がロールを引き受けることができるかを変更できます。

**ロールの信頼ポリシーを変更するには (AWS API)**

1. (オプション) 変更するロールの名前が不明な場合は、次のオペレーションを呼び出してアカウントのロールを一覧表示します。
   + [ListRoles](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html)

1. (オプション) ロールの現在の信頼ポリシーを表示するには、次のオペレーションを呼び出します。
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)

1. ロールにアクセス可能な信頼されたプリンシパルを変更するには、更新された信頼ポリシーを使用してテキストファイルを作成します。ポリシーの作成には任意のテキストエディタを使用できます。

   以下の信頼ポリシーの例では、`Principal` 要素で 2 つの AWS アカウント を参照する方法を示します。これにより、2 つの別個の AWS アカウント 内のユーザーが、このロールを引き受けることができます。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"AWS": [
               "arn:aws:iam::111122223333:root",
               "arn:aws:iam::444455556666:root"
           ]},
           "Action": "sts:AssumeRole"
       }
   }
   ```

------

   別のアカウントでプリンシパルを指定した場合、ロールの信頼ポリシーにアカウントを追加しても、クロスアカウントの信頼関係は半分しか確立されません。デフォルトでは、信頼されたアカウントのユーザーはロールを引き受けることができません。新しく信頼されたアカウントの管理者は、ロールを引き受けるアクセス許可をユーザーに付与する必要があります。これを行うには、ユーザーにアタッチするポリシーを作成または編集し、`sts:AssumeRole` アクションへのアクセスをユーザーに許可する必要があります。詳細については、次の手順または「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

1. 先ほど作成したファイルを使用して信頼ポリシーを更新するには、次のオペレーションを呼び出します。
   + [UpdateAssumeRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAssumeRolePolicy.html)

**信頼された外部アカウントのユーザーにロールの使用を許可するには (AWS API)**

この手順の詳細については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。

1. JSON ファイルを作成し、ロールを引き受けるためのアクセス許可を付与するアクセス許可ポリシーを含めます。たとえば、次のポリシーには必要最小限のアクセス権限が含まれています。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRole",
           "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME"
       }
   }
   ```

------

   ステートメント内の ARN を、ユーザーが引き受けるロールの ARN に置き換えます。

1. 次のオペレーションを呼び出し、信頼ポリシーが含まれている JSON ファイルを IAM にアップロードします。
   + [CreatePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicy.html)

   このオペレーションの出力には、ポリシーの ARN が含まれています。この ARN を書き留めます。後のステップで必要になります。

1. ポリシーをアタッチするユーザーまたはグループを決定します。目的のユーザーやグループの名前が不明である場合は、以下のいずれかのオペレーションを呼び出して、アカウントのユーザーやグループを一覧表示します。
   + [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)
   + [ListGroups](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroups.html)

1. 以下のいずれかのオペレーションを呼び出して、前のステップで作成したポリシーをユーザーまたはグループにアタッチします。
   +  API: [AttachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html)
   + [AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html)

# ロールに対するアクセス許可を更新する
<a name="id_roles_update-role-permissions"></a>

ロールのアクセス許可ポリシーとアクセス許可の境界を更新するには、以下の手順を使用します。

## 前提条件: ロールへのアクセスを表示する
<a name="roles-modify_prerequisites"></a>

ロールのアクセス許可を変更する前に、サービスレベルの最近のアクティビティを確認する必要があります。これは、アクセス権を使用しているプリンシパル (ユーザーまたはアプリケーション) から削除しないようにするために重要です。最後にアクセスした情報を表示する方法の詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](access_policies_last-accessed.md)」を参照してください。

## ロールに対するアクセス許可ポリシーを更新する
<a name="id_roles_update-role-permissions-policy"></a>

ロールで許可されているアクセス許可を変更するには、ロールのアクセス許可のポリシーを修正します。IAM の*[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)*のアクセス許可ポリシーは変更できません。ロールに依存するサービス内では、アクセス許可ポリシーを変更できる場合があります。サービスでこの機能がサポートされているかどうかを確認するには、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[Service-linked roles]** (サービスにリンクされたロール) 列が **[Yes]** (はい) となっているサービスを探します。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。

### ロールに対するアクセス許可ポリシーの更新 (コンソール)
<a name="id_roles_update-role-permissions-policy-console"></a>

**ロールで許可されているアクセス権限を変更するには (コンソール)**

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. IAM コンソールのナビゲーションペインで **[ロール]** を選択します。

1. 変更するロールの名前を選択し、[**Permissions (アクセス許可)**] タブを選択します。

1. 次のいずれかを行います。
   + 既存のカスタマー管理ポリシーを編集するには、ポリシーの名前を選択してから [**ポリシーの編集**] を選択します。
**注記**  
AWS の管理ポリシーを編集することはできません。AWS 管理ポリシーには AWS アイコン (![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/policy_icon.png)) が表示されます。AWS 管理ポリシーとカスタマー管理ポリシーの違いの詳細については、「[管理ポリシーとインラインポリシー](access_policies_managed-vs-inline.md)」を参照してください。
   + 既存の管理ポリシーをロールにアタッチするには、**[Add permissions]** (アクセス許可を追加) を選択して、**[Attach policies]** (ポリシーのアタッチ) を選択します。
   + 既存のインラインポリシーを編集するには、ポリシーを展開して、**[Edit]** (編集) を選択します。
   + 新しいインラインポリシーを埋め込むには、**[Add permissions]** (アクセス許可を追加) を選択して、**[Create inline policy]** (インラインポリシーの作成) を選択します。
   + ロールから既存のポリシーを削除するには、ポリシー名の横にあるチェックボックスを選択し、**[削除]** を選択します。

### ロールに対するアクセス許可ポリシーの更新 (AWS CLI)
<a name="id_roles_update_permissions-policy-cli"></a>

ロールで許可されているアクセス許可を変更するには、ロールのアクセス許可のポリシーを修正します。IAM の*[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)*のアクセス許可ポリシーは変更できません。ロールに依存するサービス内では、アクセス許可ポリシーを変更できる場合があります。サービスでこの機能がサポートされているかどうかを確認するには、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[Service-linked roles]** (サービスにリンクされたロール) 列が **[Yes]** (はい) となっているサービスを探します。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。

**ロールで許可されたアクセス許可を変更するには (AWS CLI)**

1. (オプション) ロールに現在関連付けられているアクセス許可を表示するには、以下のコマンドを実行します。

   1. [aws iam list-role-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-role-policies.html) (インラインポリシーの一覧表示)

   1. [aws iam list-attached-role-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-role-policies.html) (管理ポリシーの一覧表示)

1. ロールのアクセス権限を更新するコマンドは、管理ポリシーとインラインポリシーのいずれを更新するかによって異なります。

   管理ポリシーを更新するには、次のコマンドを実行して新しいバージョンの管理ポリシーを作成します。
   + [aws iam create-policy-version](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy-version.html)

   インラインポリシーを更新するには、次のコマンドを実行します。
   + [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

### ロールに対するアクセス許可ポリシーの更新 (AWS API)
<a name="id_roles_update_permissions-policy-api"></a>

ロールで許可されているアクセス許可を変更するには、ロールのアクセス許可のポリシーを修正します。IAM の*[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)*のアクセス許可ポリシーは変更できません。ロールに依存するサービス内では、アクセス許可ポリシーを変更できる場合があります。サービスでこの機能がサポートされているかどうかを確認するには、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照し、**[Service-linked roles]** (サービスにリンクされたロール) 列が **[Yes]** (はい) となっているサービスを探します。サービスリンクロールに関するドキュメントをサービスで表示するには、リンクで **[はい]** を選択します。

**ロールで許可されたアクセス許可を変更するには (AWS API)**

1. (オプション) ロールに現在関連付けられているアクセス許可を表示するには、以下のオペレーションを呼び出します。

   1. [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html) (インラインポリシーの一覧表示)

   1. [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html) (管理ポリシーの一覧表示)

1. ロールのアクセス許可を更新するオペレーションは、管理ポリシーとインラインポリシーのいずれを更新するかによって異なります。

   管理ポリシーを更新するには、次のオペレーションを呼び出して新しいバージョンの管理ポリシーを作成します。
   + [CreatePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html)

   インラインポリシーを更新するには、次のオペレーションを呼び出します。
   + [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)

## ロールに対するアクセス許可の境界を更新する
<a name="id_roles_update-role-permissions-boundary"></a>

ロールに許可されるアクセス許可の上限を変更するには、ロールの[アクセス許可の境界](access_policies_boundaries.md)を変更します。

### ロールに対するアクセス許可の境界の更新 (コンソール)
<a name="id_roles_update-permissions-boundary-console"></a>

**ロールのアクセス許可の境界を設定するために使用するポリシーを変更するには**

1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。

1. ナビゲーションペインで **Roles (ロール)** を選択します。

1. 変更する[permissions boundary](access_policies_boundaries.md) (許可の境界) を持つロールの名前を選択します。

1. **[アクセス許可]** タブを選択します。必要に応じて、[**Permissions boundary (アクセス許可の境界)**] セクションを開き、[**Change boundary (境界の変更)**] を選択します。

1. アクセス許可の境界として使用するポリシーを選択します。

1. [**Change boundary (境界の変更)**] を選択します。

   変更は、次にこのロールが引き受けられるまで有効になりません。

### ロールに対するアクセス許可の境界の変更 (AWS CLI)
<a name="id_roles_update_permissions-boundary-cli"></a>

**ロールのアクセス許可の境界を設定するために使用する管理ポリシーを変更するには (AWS CLI)**

1. (オプション) ロールの現在の[アクセス許可の境界](access_policies_boundaries.md)を表示するには、以下のコマンドを実行します。
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. 別の管理ポリシーを使用してロールのアクセス許可の境界を更新するには、次のコマンドを実行します。
   + [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)

   ロールにアクセス許可の境界として設定できる管理ポリシーは 1 つのみです。アクセス許可の境界を変更する場合は、ロールに許可されるアクセス許可の上限を変更します。

### ロールに対するアクセス許可の境界の更新 (AWS API)
<a name="id_roles_update-permissions-boundary-api"></a>

**ロールのアクセス許可の境界を設定するために使用する管理ポリシーを変更するには (AWS API)**

1. (オプション) ロールの現在の[アクセス許可の境界](access_policies_boundaries.md)を表示するには、以下のオペレーションを呼び出します。
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)

1. 別の管理ポリシーを使用してロールのアクセス許可の境界を更新するには、次のオペレーションを呼び出します。
   + [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)

   ロールにアクセス許可の境界として設定できる管理ポリシーは 1 つのみです。アクセス許可の境界を変更する場合は、ロールに許可されるアクセス許可の上限を変更します。

# ロールの設定を更新する
<a name="id_roles_update-role-settings"></a>

ロールの説明を更新したり、ロールの最大セッション期間を変更したりするには、以下の手順を使用します。

## ロールの説明を更新する
<a name="id_roles_update-description"></a>

ロールの説明を変更するには、説明テキストを変更します。

### ロールの説明の更新 (コンソール)
<a name="id_roles_update-description-console"></a>

**ロールの説明を変更するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. IAM コンソールのナビゲーションペインで **[ロール]** を選択します。

1. 変更するロールの名前を選択します。

1. **[Summary]** (概要) セクションで **[Edit]** (編集) を選択します。

1. ボックスに新しい説明を入力し、**[Save changes]** (変更の保存) を選択します。

### ロールの説明の更新 (AWS CLI)
<a name="id_roles_update-description-cli"></a>

**ロールの説明を変更するには (AWS CLI)**

1. (オプション) ロールの現在の説明を表示するには、次のコマンドを実行します。
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. ロールの説明を更新するには、説明パラメータを指定して、次のコマンドを実行します。
   + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html)

### ロールの説明の更新 (AWS API)
<a name="id_roles_update-description-api"></a>

**ロールの説明を変更するには (AWS API)**

1. (オプション) ロールの現在の説明を表示するには、次のオペレーションを呼び出します。
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. ロールの説明を更新するには、説明パラメータを指定して、次のオペレーションを呼び出します。
   + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html)

## ロールの最大セッション期間を更新する
<a name="id_roles_update-session-duration"></a>

コンソール、AWS CLI または AWS API を使用して、引き受けるロールの最大セッション期間設定を指定するには、最大セッション期間設定の値を変更します。この設定の値は 1 時間～ 12 時間です。値を指定しない場合、デフォルトの最大 1 時間が適用されます。この設定では、AWS サービスが引き受けるセッションは制限されません。

### ロールの最大セッション期間の更新 (コンソール)
<a name="id_roles_update-session-duration-console"></a><a name="id_roles_modify_max-session"></a>

**コンソール、AWS CLI または AWS API を使用して引き受けたロールの最大セッション期間設定を変更するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. IAM コンソールのナビゲーションペインで **[ロール]** を選択します。

1. 変更するロールの名前を選択します。

1. **[Summary]** (概要) セクションで **[Edit]** (編集) を選択します。

1. **[Maximum session duration]** (最大セッション期間) には、値を選択します。または、[**Custom duration**] (カスタム期間) を選択して、値 (秒単位) を入力します。

1. **[Save changes]** (変更の保存) をクリックします。

   変更は、次にこのロールが引き受けられるまで有効になりません。このロールの既存のセッションを取り消す方法については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](id_roles_use_revoke-sessions.md)」を参照してください。

AWS マネジメントコンソール の場合、IAM ユーザーセッションはデフォルトで 12 時間です。コンソールでロールを切り替える IAM ユーザーには、ロールに設定された最大セッション期間、または ユーザーのセッションの残り時間のいずれか短い方が付与されます。

AWS CLI または AWS API からロールを引き受けるユーザーは、この最大数まで長いセッションを要求できます。`MaxSessionDuration` 設定は、リクエストできるロールセッションの最大セッション期間を決定します。
+ AWS CLI を使用してセッション期間を指定するには、`duration-seconds` パラメータを使用します。詳細については[IAM ロールに切り替える (AWS CLI)](id_roles_use_switch-role-cli.md)を参照してください。
+ AWS API を使用してセッション期間を指定するには、`DurationSeconds` パラメータを使用します。詳細については[IAM ロールを切り替える (AWS)](id_roles_use_switch-role-api.md)を参照してください。

### ロールの最大セッション期間の更新 (AWS CLI)
<a name="id_roles_update-session-duration-cli"></a>

**注記**  
AWS CLI または API からロールを引き受けると、`duration-seconds` CLI パラメータまたは `DurationSeconds` API パラメータを使用して、より長いロールセッションをリクエストできます。`MaxSessionDuration` 設定は、`DurationSeconds` パラメータを使用してリクエストできるロールセッションの最大セッション期間を決定します。`DurationSeconds` パラメータの値を指定しない場合、セキュリティ認証情報は 1 時間有効です。

**引き受けたロールの最大セッション継続時間設定を AWS CLI で変更するには (AWS CLI)**

1. (オプション) ロールの現在の最大セッション継続時間設定を表示するには、次のコマンドを実行します。
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. ロールの最大セッション継続時間設定を更新するには、`max-session-duration` CLI パラメータまたは `MaxSessionDuration` API パラメータを指定して、次のコマンドを実行します。
   + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html)

   変更は、次にこのロールが引き受けられるまで有効になりません。このロールの既存のセッションを取り消す方法については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](id_roles_use_revoke-sessions.md)」を参照してください。

### ロールの最大セッション時間の更新 (AWS API)
<a name="id_roles_update-session-duration-api"></a>

**注記**  
AWS CLI または API からロールを引き受けると、`duration-seconds` CLI パラメータまたは `DurationSeconds` API パラメータを使用して、より長いロールセッションをリクエストできます。`MaxSessionDuration` 設定は、`DurationSeconds` パラメータを使用してリクエストできるロールセッションの最大セッション期間を決定します。`DurationSeconds` パラメータの値を指定しない場合、セキュリティ認証情報は 1 時間有効です。

**引き受けたロールの最大セッション継続時間設定を API で変更するには (AWS API)**

1. (オプション) ロールの現在の最大セッション継続時間設定を表示するには、次のオペレーションを呼び出します。
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. ロールの最大セッション継続時間設定を更新するには、`max-sessionduration` CLI パラメータまたは `MaxSessionDuration` API パラメータを指定して、次のオペレーションを呼び出します。
   + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html)

   変更は、次にこのロールが引き受けられるまで有効になりません。このロールの既存のセッションを取り消す方法については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](id_roles_use_revoke-sessions.md)」を参照してください。

# ロールまたはインスタンスプロファイルを削除する
<a name="id_roles_manage_delete"></a>

ロールが不要になった場合は、ロールとその関連する権限を削除することをお勧めします。そうすることで、使用していないエンティティがアクティブにモニタリングされたり、メンテナンスされたりすることがなくなります。

ロールが EC2 インスタンスに関連付けられている場合、インスタンスプロファイルからロールを削除した後、インスタンスプロファイルを削除することもできます。

**警告**  
削除しようとしているロールまたはインスタンスプロファイルで実行されている Amazon EC2 インスタンスがないことを確認してください。実行中のインスタンスに関連付けられているロールまたはインスタンスプロファイルを削除すると、そのインスタンスで実行されているすべてのアプリケーションが中断されます。

ロールを完全に削除しない場合は、ロールを無効にできます。そのためには、ロールのポリシーを変更してから、現在のすべてのセッションを取り消します。例えば、ロールに、すべての AWS へのアクセスを拒否したポリシーを追加できます。ロールを引き受けようとするすべてのユーザーへのアクセスを拒否するように、信頼ポリシーを編集することもできます。セッションの取り消しの詳細については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](id_roles_use_revoke-sessions.md)」を参照してください。

**Topics**
+ [

## ロールへのアクセスの表示
](#roles-delete_prerequisites)
+ [

## サービスにリンクされたロールの削除
](#id_roles_manage_delete_slr)
+ [

## IAM ロールの削除 (コンソール)
](#roles-managingrole-deleting-console)
+ [

## IAM ロール（AWS CLI) の削除
](#roles-managingrole-deleting-cli)
+ [

## IAM ロールの削除 (AWS API)
](#roles-managingrole-deleting-api)
+ [

## 関連情報
](#roles-managingrole-deleting-related-info)

## ロールへのアクセスの表示
<a name="roles-delete_prerequisites"></a>

ロールを削除する前に、ロールが最後に使用された日時を確認することをお勧めします。これを行うには、AWS マネジメントコンソール、AWS CLI、または AWS API を使用します。ロールを使用しているユーザーからアクセスを削除したくないため、この情報を表示する必要があります。

ロールの最後のアクティビティの日付が、**[最終アクセス]** タブで報告された最後の日付と一致しない場合があります。[**[最終アクセス]**](access_policies_last-accessed-view-data.md) タブでは、ロールのアクセス許可ポリシーで許可されているサービスのアクティビティのみがレポートされます。ロールの最後のアクティビティの日付には、AWS でサービスにアクセスしようとした最後の試みが含まれます。

**注記**  
ロールの直近のアクティビティと Last Accessed データの追跡期間は、400 日間です。ユーザーのリージョンが昨年内にこれらの機能をサポートし始めた場合、この期間は短くなる可能性があります。このロールは 400 日以上前に使用された可能性があります。追跡期間の詳細については、「[AWS が最終アクセス情報を追跡する場所](access_policies_last-accessed.md#last-accessed_tracking-period)」を参照してください。

**ロールが最後に使用された日時を表示するには（コンソール）**

1. AWS マネジメントコンソール にサインインして、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。

1. ナビゲーションペインで **Roles (ロール)** を選択します。

1. アクティビティを表示するロールの行を探します。検索フィールドを使用して結果を絞り込むことができます。[**Last activity (最後のアクティビティ)**] 列を表示して、ロールが最後に使用されてからの日数を確認します。ロールが追跡期間内に使用されていない場合、テーブルには [**None (なし)**] と表示されます。

1. 詳細情報を表示するには、ロールの名前を選択します。ロールの [**Summary (概要)**] ページには、ロールが最後に使用された日付を表示する [**Last activity (最後のアクティビティ)**] も含まれます。ロールが過去 400 日以内に使用されていない場合、[**Last activity (最後のアクティビティ)**] には [**Not accessed in the tracking period (追跡期間中にアクセスされていません)**] と表示されます。

**ロールが最後に使用された日時を表示するには (AWS CLI)**  
`[aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)` - `RoleLastUsed` オブジェクトを含むロールに関する情報を返すには、このコマンドを実行します。このオブジェクトには、ロールが最後に使用された `LastUsedDate` と `Region` が含まれます。`RoleLastUsed` が存在しても値が含まれていない場合、ロールは追跡期間内に使用されていません。

**ロールが最後に使用された日時を表示するには (AWS API)**  
`[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/GetRole.html)` - このオペレーションを呼び出して、`RoleLastUsed` オブジェクトを含むロールに関する情報を返します。このオブジェクトには、ロールが最後に使用された `LastUsedDate` と `Region` が含まれます。`RoleLastUsed` が存在しても値が含まれていない場合、ロールは追跡期間内に使用されていません。

## サービスにリンクされたロールの削除
<a name="id_roles_manage_delete_slr"></a>

サービスにリンクされたロールを削除する方法は、サービスによって異なります。場合によっては、サービスにリンクされたロールを手動で削除する必要はありません。たとえば、サービス特定のアクション (リソースの削除) を完了すると、サービスによって、サービスにリンクされたロールが削除される場合があります。また、サービスにリンクされたロールは、サービスコンソール、API、または AWS CLI から手動で削除できる場合があります。

リンクされたサービスで[サービスにリンクされたロール](id_roles.md#iam-term-service-linked-role)に関するドキュメントを参照して、ロールを削除する方法を確認します。アカウントのサービスにリンクされたロールを表示するには、コンソールの [IAM **ロール**] ページに移動します。サービスにリンクされたロールが、テーブルの **[Trusted entities]** (信頼されたエンティティ) 列の **[(Service-linked role)]** ((サービスにリンクされたロール)) に表示されます。ロールの [**Summary (概要)**] ページのバナーにも、そのロールがサービスにリンクされたロールであることが示されています。

サービスにリンクされたロールを削除するためのドキュメントがサービスに含まれていない場合は、IAM コンソール、AWS CLI、または API を使用してロールを削除できます。

## IAM ロールの削除 (コンソール)
<a name="roles-managingrole-deleting-console"></a>

AWS マネジメントコンソール を使用してロールを削除すると、IAM ではロールに関連付けられた管理ポリシーも自動的にデタッチされます。また、ロールに関連したインラインポリシーとロールを含む Amazon EC2 インスタンスプロファイルも自動的に削除されます。

**重要**  
場合によっては、ロールは、Amazon EC2 インスタンスプロファイルに関連付いていることがあります。また、ロールとインスタンスプロファイルの名前が同じ場合があります。このような場合は、AWS マネジメントコンソール を使用して、ロールやインスタンスプロファイルを削除できます。この関連付けは、コンソールで作成したロールとインスタンスプロファイルに対して自動的に行われます。AWS CLI、Tools for Windows PowerShell、または AWS API からロールを作成した場合は、ロールとインスタンスプロファイルで名前が異なることがあります。その場合、コンソールを使用してそれらのロールを削除することはできません。代わりに、まず、AWS CLI、Tools for Windows PowerShell、または AWS API を使用して、インスタンスプロファイルからロールを削除する必要があります。その後、ロールを削除する別の手順を実行する必要があります。

**ロールを削除するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、[**ロール**] を選択し、削除するロール名の隣にあるチェックボックスをオンにします。

1. ページの上部で、[**削除**] を選択します。

1. 確認ダイアログボックスで、最終アクセス情報を確認します。これは、選択したそれぞれのロールの AWS サービスへの最終アクセス時間を示します。これは、そのロールが現在アクティブであるかどうかを確認するのに役立ちます。続行する場合は、テキスト入力フィールドにロール名を入力し、**削除**を選択します。確実に削除する場合は、最終アクセス情報をまだロード中であっても、削除を実行できます。

**注記**  
ロールと同じ名前でない限り、コンソールを使用してインスタンスプロファイルを削除することはできません。ロールを削除する過程でインスタンスプロファイルを削除する必要があります。ロールを同時に削除することなくインスタンスプロファイルを削除するには、AWS CLI または AWS API を使用する必要があります。詳細については、次のセクションを参照してください。

## IAM ロール（AWS CLI) の削除
<a name="roles-managingrole-deleting-cli"></a>

AWS CLI を使用してロールを削除する場合、最初にそのロールに関連したインラインポリシーを削除しなければなりません。また、ロールに関連付けられた管理ポリシーもデタッチする必要があります。ロールを含む関連付けられたインスタンスプロファイルを削除する場合は、別途、削除する必要があります。

**ロールを削除するには (AWS CLI)**

1. 削除するロールの名前が分からない場合、以下のコマンドを入力してお客様のアカウントにあるロールを表示します。

   ```
   aws iam list-roles
   ```

   リストには、各ロールの Amazon リソースネーム (ARN) が含まれます。CLI コマンドでは、ARN ではなくロール名を使用してロールを参照します。例えば、ロールの ARN が `arn:aws:iam::123456789012:role/myrole` である場合、そのロールを **myrole** と参照します。

1. ロールが関連付けられたすべてのインスタンスプロファイルからロールを削除します。

   1. そのロールが関連付けられているすべてのインスタンスプロファイルを表示するには、以下のコマンドを入力します。

      ```
      aws iam list-instance-profiles-for-role --role-name role-name
      ```

   1. 各インスタンスプロファイルで以下のコマンドを入力して、インスタンスプロファイルからロールを削除します。

      ```
      aws iam remove-role-from-instance-profile --instance-profile-name instance-profile-name --role-name role-name
      ```

1. そのロールに関連するすべてのポリシーを削除します。

   1. ロールに存在するすべてのインラインポリシーを一覧表示するには、以下のコマンドを入力します。

      ```
      aws iam list-role-policies --role-name role-name
      ```

   1. ロールから各インラインポリシーを削除するには、各ポリシーで以下のコマンドを入力します。

      ```
      aws iam delete-role-policy --role-name role-name --policy-name policy-name
      ```

   1. ロールにアタッチされたすべてのマネージドポリシーを一覧表示するには、以下のコマンドを入力します。

      ```
      aws iam list-attached-role-policies --role-name role-name
      ```

   1. ロールから各マネージドポリシーをデタッチするには、各ポリシーで以下のコマンドを入力します。

      ```
      aws iam detach-role-policy --role-name role-name --policy-arn policy-arn
      ```

1. 次のコマンドを入力してロールを削除します。

   ```
   aws iam delete-role --role-name role-name
   ```

1. そのロールに関連付けられたインスタンスプロファイルを再利用する予定がない場合、以下のコマンドを入力して削除できます。

   ```
   aws iam delete-instance-profile --instance-profile-name instance-profile-name
   ```

## IAM ロールの削除 (AWS API)
<a name="roles-managingrole-deleting-api"></a>

IAM API を使用してロールを削除する場合、最初にそのロールに関連したインラインポリシーを削除しなければなりません。また、ロールに関連付けられた管理ポリシーもデタッチする必要があります。ロールを含む関連付けられたインスタンスプロファイルを削除する場合は、別途、削除する必要があります。

**ロールを削除するには (AWS API)**

1. ロールが関連付けられたすべてのインスタンスプロファイルを一覧表示するには、[ListInstanceProfilesForRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html) を呼び出します。

   インスタンスプロファイルからロールを削除するには、[RemoveRoleFromInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html) を呼び出します。ロール名およびインスタンスプロファイル名を引き渡さなければいけません。

   そのロールに関連付けられていたインスタンスプロファイルを再利用しない場合、[DeleteInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html) を呼び出して削除します。

1. ロールのすべてのインラインポリシーを一覧表示するには、[ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html) を呼び出します。

   ロールに関連付けられたインラインポリシーを削除するには、[DeleteRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRolePolicy.html) を呼び出します。ロール名およびインラインポリシー名を渡す必要があります。

1. ロールにアタッチされたすべてのマネージドポリシーを一覧表示するには、[ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html) を呼び出します。

   ロールにアタッチされたマネージドポリシーをデタッチするには、[DetachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachRolePolicy.html) を呼び出します。ロール名およびマネージドポリシー ARN を渡す必要があります。

1. ロールを削除するには、[DeleteRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRole.html) を呼び出します。

## 関連情報
<a name="roles-managingrole-deleting-related-info"></a>

インスタンスプロファイルの一般的な情報については、[インスタンスプロファイルを使用する](id_roles_use_switch-role-ec2_instance-profiles.md)を参照してください。

サービスにリンクされたロールの一般情報については、「[サービスにリンクされたロールの作成](id_roles_create-service-linked-role.md)」を参照してください。

# ロールを引き受けるための各種方法
<a name="id_roles_manage-assume"></a>

作成したロールをユーザー、アプリケーション、またはサービスが使用できるようにするには、該当のロールに[切り替えるためのアクセス許可を付与する](id_roles_use_permissions-to-switch.md)必要があります。グループまたはユーザーにアタッチされたポリシーを使用して、必要なアクセス許可を付与することができます。アクセス許可が付与されると、ユーザーは、AWS マネジメントコンソール、Tools for Windows PowerShell、AWS Command Line Interface (AWS CLI)、および [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API からロールを引き受けることができます。

**重要**  
ロールの作成を IAM コンソールではなくプログラムで行う場合は、最大 64 文字までの `Path` に加えて最大 512 文字までの `RoleName` を追加できます。ただし、AWS マネジメントコンソール の [**ロールの切り替え**] 機能でロールを使用する場合は、`Path` と `RoleName` の合計が 64 文字を超えることはできません。

ロールを引き受けるために使用される方法によって、誰がロールを引き受けることができるか、およびロールセッションがどのくらい続くかが決まります。`AssumeRole*` API オペレーションを使用する場合、引き受ける IAM ロールはリソースです。`AssumeRole*` API オペレーションを呼び出す ユーザーまたはロールはプリンシパルです。

次の表は、ロールを引き受ける方法を比較したものです。


|  ロールを引き受ける方法 |  **だれがロールを引き受けるか**  | **認証情報の有効期間を指定する方法** |  **認証情報の有効期間 (最小 \$1 最大 \$1 デフォルト)**  | 
| --- | --- | --- | --- | 
| AWS マネジメントコンソール | ユーザーまたは ([ロールの切り替え](id_roles_use_switch-role-console.md)による) ロール¹ | 最大セッション期間でロールの [概要] ページ | 15 分 \$1 最大セッション期間設定² \$1 1 時間 | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI または [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーション |  ユーザーまたはロール¹ | duration-seconds CLI または DurationSeconds API パラメータ | 15 分 \$1 最大セッション期間設定² \$1 1 時間  | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html) CLI または [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API オペレーション | SAML を使用して認証されたユーザー | duration-seconds CLI または DurationSeconds API パラメータ | 15 分 \$1 最大セッション期間設定² \$1 1 時間  | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) CLI または [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API オペレーション | OIDC プロバイダーを使用して認証されたユーザー | duration-seconds CLI または DurationSeconds API パラメータ | 15 分 \$1 最大セッション期間設定² \$1 1 時間  | 
| [ を使用して構築された](id_roles_providers_enable-console-custom-url.md)コンソール URLAssumeRole  | ユーザーまたはロール | URL の SessionDuration HTML パラメータ | 15 分 \$1 12 時間 \$1 1 時間  | 
| [ を使用して構築された](id_roles_providers_enable-console-custom-url.md)コンソール URLAssumeRoleWithSAML  | SAML を使用して認証されたユーザー | URL の SessionDuration HTML パラメータ | 15 分 \$1 12 時間 \$1 1 時間 | 
| [ を使用して構築された](id_roles_providers_enable-console-custom-url.md)コンソール URLAssumeRoleWithWebIdentity  | OIDC プロバイダーを使用して認証されたユーザー | URL の SessionDuration HTML パラメータ | 15 分 \$1 12 時間 \$1 1 時間  | 

¹ 1 つのロールの認証情報を使用して別のロールを引き受けることを[ロールの連鎖](id_roles.md#iam-term-role-chaining)と言います。ロールの連鎖を使用する場合、ロールのセッション期間は 1 時間に制限されます。これは、AWS マネジメントコンソール ロールの切り替え、AWS CLI、API オペレーションに適用されます。この制限は、ユーザー認証情報からロールを最初に引き受ける場合や、インスタンスプロファイルを使用して Amazon EC2 インスタンスで実行しているアプリケーションには適用されません。

² この設定の値は 1 時間～ 12 時間です。最大セッション期間設定の修正の詳細については、「[IAM ロールの管理](id_roles_manage.md)」を参照してください。この設定は、ロールの認証情報を取得したときにリクエストできる最大セッション期間設定を決定します。たとえば、[AssumeRole\$1](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーションを使用してロールを引き受ける場合は、`DurationSeconds` パラメータの値を使用してセッションの期間を指定できます。このパラメータを使用して、ロールセッションの期間を 900 秒 (15 分) からそのロールの最大セッション期間設定まで指定できます。コンソールでロールを切り替える IAM ユーザーには、最大セッション期間、またはユーザーのセッションの残り時間のいずれか短い方が付与されます。ロールに 5 時間の最大期間を設定することを想定しています。コンソールに 10 時間（デフォルトの最大 12 時間）サインインした IAM ユーザーがロールに切り替わります。使用可能なロールセッション期間は 2 時間です。ロールの最大値を確認する方法については、このページで後述する「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。

**メモ**  
最大セッション期間の設定では、AWS サービスが引き受けるセッションは制限されません。
Amazon EC2 IAM ロールの認証情報はロールで設定された最大セッション期間の対象にはなりません。
ロールセッション内でユーザーが現在のロールを再び引き受けることができるようにするには、ロール信頼ポリシーでロール ARN または AWS アカウント ARN をプリンシパルとして指定します。Amazon EC2、Amazon ECS、Amazon EKS、Lambda などのコンピューティングリソースを提供する AWS のサービス は、一時的な認証情報を提供し、これらの認証情報を自動的に更新します。これにより、常に有効な認証情報セットを確保できます。これらのサービスでは、一時的な認証情報を取得するために現在のロールを再度引き受ける必要はありません。ただし、[セッションタグ](id_session-tags.md)または[セッションポリシー](access_policies.md#policies_session)を渡す場合は、現在のロールを再度引き受ける必要があります。ロールの信頼ポリシーを変更してプリンシパルロールの ARN または AWS アカウント ARN を追加する方法については、[ロール信頼ポリシーを更新する](id_roles_update-role-trust-policy.md) を参照してください。

**Topics**
+ [

# ユーザーから IAM ロールに切り替える (コンソール)
](id_roles_use_switch-role-console.md)
+ [

# IAM ロールに切り替える (AWS CLI)
](id_roles_use_switch-role-cli.md)
+ [

# IAM ロールに切り替える (Tools for Windows PowerShell)
](id_roles_use_switch-role-twp.md)
+ [

# IAM ロールを切り替える (AWS)
](id_roles_use_switch-role-api.md)
+ [

# Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する
](id_roles_use_switch-role-ec2.md)
+ [

# インスタンスプロファイルを使用する
](id_roles_use_switch-role-ec2_instance-profiles.md)

# ユーザーから IAM ロールに切り替える (コンソール)
<a name="id_roles_use_switch-role-console"></a>

IAM ユーザー、IAM Identity Center でのユーザー、SAML フェデレーションロール、またはウェブ ID フェデレーションロールとしてサインインするときにロールを切り替えられます。*ロール*は、必要な AWS リソースへのアクセスに使用できる一連のアクセス許可を指定します。ただし、ロールにはサインインされませんが、一度 IAM ユーザーとしてサインインすると IAM ロールに切り替えることができます。こうすると、元のユーザーアクセス権限が一時的に無効になり、そのロールに割り当てられたアクセス権限が代わりに付与されます。ロールは、自身のアカウントのロールでも、他の AWS アカウント のロールでもかまいません。ロール、その利点、作成方法の詳細については、「[IAM ロール](id_roles.md)」と「[IAM ロールの作成](id_roles_create.md)」を参照してください。

ユーザーと切り替え後のロールのアクセス許可は、累積されません。同時に有効になるアクセス権限のセットは 1 つのみです。ロールを切り替えると、ユーザーアクセス権限が一時的に無効になり、切り替え後のロールに割り当てられたアクセス権限が有効になります。そのロールを終了すると、ユーザーアクセス権限が自動的に復元されます。

AWS マネジメントコンソール でロールを切り替えると、コンソールは常に元の認可情報を使用して切り替えを認可します。例えば、RoleA に切り替える場合は、IAM は元の認証情報を使用して、RoleA の引き受けが許可されているかどうかを判断します。その後、*RoleA を使用中に* RoleB への切り替えを試みると、AWS は引き続き RoleA の認証情報ではなく**元の**認証情報を使用して切り替えを認可します。

**注記**  
IAM アイデンティティセンターのユーザーとして、SAML フェデレーテッドロールとして、またはウェブ ID フェデレーテッドロールとしてサインインすると、セッションの開始時に IAM ロールを引き受けます。例えば、IAM アイデンティティセンターのユーザーが AWS アクセスポータルにサインインする際には、AWS リソースにアクセスする前に、ロールに関連するアクセス許可セットを選択する必要があります。

## ロールセッション
<a name="id_roles_iam_user-switch-role-sessions"></a>

ロールを切り替えると、AWS マネジメントコンソール セッションはデフォルトで 1 時間続きます。IAM ユーザーセッションはデフォルトで 12 時間です。他のユーザーについては、異なるセッション時間が定義されている場合があります。コンソールでロールを切り替えると、ロールの最大セッション期間、またはユーザーセッションの残り時間のいずれか短い方が付与されます。ロールを引き受けることでセッション時間を延長することはできません。

たとえば、ロールに対して最大セッション期間が 10 時間に設定されているとします。ロールを切り替えることを決定するまでに、コンソールにサインインしてから 8 時間が経過していました。ユーザーセッションの残り時間は 4 時間であるため、許可されるロールセッション期間は、最大セッション期間の 10 時間ではなく、4 時間になります。次の表は、コンソールでロールを切り替えるときの IAM ユーザーのセッション期間を決定する方法を示しています。


| IAM ユーザーセッションの残り時間は..。 | ロールセッションの期間は..。 | 
| --- | --- | 
| ロールの最大セッション時間より小さい | ユーザーセッションでの残り時間 | 
| ロールの最大セッション時間の長さを超えています | 最大セッション期間値 | 
| ロールの最大セッション時間と同等 | 最大セッション継続時間値 (概算) | 

1 つのロールの認証情報を使用して別のロールを引き受けることを[ロールの連鎖](id_roles.md#iam-term-role-chaining)と言います。ロールの連鎖を使用する場合、個々のロールに設定された最大セッション期間の設定に関係なく、セッション期間は 1 時間に制限されます。これは、AWS マネジメントコンソール ロールの切り替え、AWS CLI、API オペレーションに適用されます。

**注記**  
ある程度 AWS サービスコンソールは、ロールセッションの有効期限が切れたときに、アクションを実行せずにロールセッションを自動更新できます。セッションを再認証するために、ブラウザページをリロードするように求めるメッセージが表示されることがあります。

## 考慮事項
<a name="id_roles_iam_user-switch-role-considerations"></a>
+ AWS アカウントのルートユーザー としてサインインすると、ロールを切り替えることはできません。
+ ロールを切り替えるためのアクセス許可が、ポリシーによってユーザーに付与されている必要があります。手順については、「[ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)」を参照してください。
+ AWS マネジメントコンソール で、[ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) 値を必要とするロールに切り替えることはできません。`ExternalId` パラメータをサポートする [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API を呼び出すことにより、このようなロールに切り替えることができます。

## ロールを切り替えるには
<a name="id_roles_iam_user-switch-role-console-procedure"></a>

1. 「*AWS サインインサインインユーザーガイド*」の「[AWS マネジメントコンソール へのサインイン方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」のトピックで説明されているように、ユーザータイプに適したサインイン手順に従ってください。

1. AWS マネジメントコンソール で、右上のナビゲーションバーのユーザー名を選択します。通常は ***username*@*account\$1ID\$1number\$1or\$1alias*** のように表示されます。

1. ロールを切り替えるには、次のいずれかの方法を選択します。
   + **[ロールの切り替え]** を選択します。
   + マルチセッションサポートにオプトインしている場合は、**[セッションを追加]** を選択して **[ロールの切り替え]** を選択します。
**注記**  
AWS マネジメントコンソール では、1 つのウェブブラウザで最大 5 つの異なる ID に同時にサインインできます。詳細については、「*AWS マネジメントコンソール 入門ガイド*」の「[複数の入門ガイドアカウントへのサインイン](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html)」を参照してください。

1. [**ロールの切り替え**] ページで、アカウント ID 番号またはアカウントエイリアスと、管理者により提供されたロールの名前を入力します。
**注記**  
管理者が `division_abc/subdivision_efg/roleToDoX` などのパスを使用してロールを作成した場合は、[**ロール**] ボックスに完全なパスと名前を入力する必要があります。ロール名のみを入力した場合、または `Path` と `RoleName` の組み合わせの合計が 64 文字を超える場合は、ロールの切り替えは失敗します。これは、ロール名を保存するブラウザクッキーの制約です。この場合は、管理者に連絡して、パスとロール名のサイズを減らすことを依頼してください。

1. (オプション) 表示名を入力し、コンソールのナビゲーションバーでロールを強調表示する表示色を選択できます。
   + **[表示名]** で、このロールがアクティブな場合にユーザー名の代わりにナビゲーションバーに表示するテキストを入力します。名前の候補がアカウントとロールの情報に基づいて表示されますが、わかりやすい名前に変更できます。
   + **[表示色]** で、表示名を強調表示する色を選択します。

   名前と色から、ロールがアクティブになってアクセス権限が変わることがわかりやすくなります。たとえば、テスト環境にアクセスできるロールには、[**表示名**] に「**Test**」と入力し、[**色**] で緑を選択できます。本稼働環境にアクセスできるロールには、[**表示名**] に「**Production**」と入力し、[**色**] で赤を選択できます。

1. **[Switch Role]** (ロールの切り替え) を選択します。表示名と色によってナビゲーションバーのユーザー名が置き換えられ、そのロールにより付与されたアクセス許可を使用し始めることができます。

1. IAM ロールを必要とするタスクが完了したら、元のセッションに切り替えて戻ることができます。これにより、ロールによって付与される追加のアクセス許可が削除され、標準のアクセス許可に戻ります。

   1. IAM コンソールで、右上のナビゲーションバーでロールの [**表示名**] を選択します。

   1. **[スイッチバック]** を選択します。

      たとえば、アカウント番号 `123456789012` にユーザー名 `Richard` を使用してサインインしているとします。`admin-role` ロールの使用後に、ロールの使用を停止して元のアクセス許可に戻ります。ロールの使用を停止するには、**[admin-role @ 123456789012]** を選択し、**[スイッチバック]** を選択します。  
![\[IAM ロールの使用を停止し、元のユーザーに戻るためのスイッチバック機能の場所を示すグラフィックス。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/role-stop-using.png)

**ヒント**  
最近使用したいくつかのロールがメニューに表示されます。次回いずれかのロールに切り替えたい場合は、そのロールを選択するだけで切り替えることができます。ロールがメニューに表示されない場合にのみ、アカウントとロールの情報を手動で入力する必要があります。

## その他のリソース
<a name="id_roles_use_switch-role-console_additional_resources"></a>
+ [ロールを切り替えるアクセス許可をユーザーに付与する](id_roles_use_permissions-to-switch.md)
+ [AWS サービスにロールを渡すアクセス許可をユーザーに付与する](id_roles_use_passrole.md)
+ [IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)
+ [AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)
+ [IAM ロールをトラブルシューティングする](troubleshoot_roles.md)

# IAM ロールに切り替える (AWS CLI)
<a name="id_roles_use_switch-role-cli"></a>

*ロール*は、必要な AWS リソースへのアクセスに使用できる一連のアクセス許可を指定します。その点では、[AWS Identity and Access Management（IAM）のユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)に似ています。ユーザーとしてサインインすると、特定の一連のアクセス許可が付与されます。ただし、ロールにはサインインされませんが、ユーザーとしてサインインした後でロールを切り替えることができます。こうすると、元のユーザーアクセス権限が一時的に無効になり、そのロールに割り当てられたアクセス権限が代わりに付与されます。ロールは、自身のアカウントのロールでも、他の AWS アカウント のロールでもかまいません。ロールとその利点、およびロールを作成して設定する方法については、「[IAM ロール](id_roles.md)」および「[IAM ロールの作成](id_roles_create.md)」を参照してください。ロールを引き受ける別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。

**重要**  
IAM ユーザーのアクセス許可および引き受けるロールは、累積されません。同時に有効になるアクセス権限のセットは 1 つのみです。ロールを引き受けると、以前のユーザーまたはロールのアクセス許可が一時的に無効になり、切り替え後のロールに割り当てられたアクセス許可が有効になります。そのロールを終了すると、ユーザーアクセス権限が自動的に復元されます。

IAM ユーザーとしてサインインしている場合、ロールを使用して AWS CLI コマンドを実行できます。また、[外部で認証されたユーザー](id_roles_providers.md) ([SAML](id_roles_providers_saml.md) または [OIDC](id_roles_providers_oidc.md)) としてサインインしている場合にも、ロールを使用して AWS CLI コマンドを実行できます。また、インスタンスプロファイルを経由して、ロールにアタッチされた Amazon EC2 インスタンス内部から AWS CLI コマンドを実行するロールを使用できます。AWS アカウントのルートユーザー としてサインインしているときに、ロールを引き受けることはできません。

[**ロールの連鎖**](id_roles.md#iam-term-role-chaining) — ロールの連鎖を使用することもできます。この連鎖は、ロールのアクセス許可を使用して 2 つ目のロールにアクセス許可を使用します。

デフォルトでは、ロールセッションは 1 時間です。`assume-role*` CLI オペレーションを使用してこのロールを引き受ける場合は、`duration-seconds` パラメータの値を指定できます。この値は 900 秒 (15 分) からロールの最大セッション期間設定までの範囲を指定できます。コンソールでロールを変更した場合、セッションの所要時間は最大 1 時間に制限されます。ロールの最大値を確認する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。

ロールの連鎖を使用すると、セッション期間は最長である 1 時間に制限されます。この場合 `duration-seconds` パラメータを使用して 1 時間より大きい値を指定すると、オペレーションは失敗します。

## シナリオ例: 本稼働ロールに切り替える
<a name="switch-role-cli-scenario-prod-env"></a>

開発環境で作業している IAM ユーザーであるとします。このシナリオでは、[AWS CLI](https://aws.amazon.com/cli/) でコマンドラインを使用して実稼働環境を操作する必要が生じることがあります。1 つのアクセスキー認証情報のセットがすでに使用可能です。このセットは、標準の IAM ユーザーに割り当てられたアクセスキーペアである場合があります。または、SAML または OIDC のフェデレーティッドプリンシパルとしてサインインしている場合、ユーザーに最初に割り当てられたロールのアクセスキーペアである場合があります。現在のアクセス許可で特定の IAM ロールを引き受けることができるなら、AWS CLI 設定ファイルの「プロファイル」でそのロールを特定できます。このコマンドは、元のアイデンティティではなく、指定された IAM ロールのアクセス権限を使用して実行されます。このプロファイルを AWS CLI コマンドで指定すると、新しいロールを使用することになります。この場合、開発用アカウントの元のアクセス許可を同時に使用することはできません。同時に有効にできるアクセス許可のセットは 1 つのみであるためです。

**注記**  
セキュリティ上の理由から、管理者は [AWS CloudTrail ログを確認](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)して、AWS でアクションを実行したユーザーを調べることができます。管理者は、ロールを引き受けるときに、ソース ID またはロールセッション名の指定を要求する場合があります。詳細については、「[`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity)」および「[`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)」を参照してください。

**本稼働ロールに切り替えるには (AWS CLI)**

1. <a name="step-configure-default"></a>AWS CLI をはじめて使用する場合は、まず、デフォルトの CLI プロファイルを設定する必要があります。コマンドプロンプトを開き、IAM ユーザーまたはフェデレーティッドロールからのアクセスキーを使用するように、AWS CLI を設定します。詳細については、「[AWS Command Line Interface ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration)」の「*AWS Command Line Interface の設定*。」を参照してください。

   以下のように、[aws configure](https://docs.aws.amazon.com/cli/latest/reference/configure/) コマンドを実行します。

   ```
   aws configure
   ```

   プロンプトが表示されたら、次の情報を入力します。

   ```
   AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
   AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   Default region name [None]: us-east-2
   Default output format [None]: json
   ```

1. Unix または Linux の `.aws/config` ファイル、または Windows の `C:\Users\USERNAME\.aws\config` ファイルに、ロールの新しいプロファイルを作成します。次の例では、`123456789012` アカウントの `ProductionAccessRole` ロールへの切り替えをする「`prodaccess`」というプロファイルを作成します。ロール ARN は、ロールを作成したアカウント管理者から入手します。このプロファイルが呼び出されると、AWS CLI は `source_profile` の認証情報を使用してロールのための認証情報をリクエストします。そのため、`source_profile` として参照されるアイデンティティは、`role_arn` で指定されたロールの `sts:AssumeRole` アクセス権限がなければなりません。

   ```
   [profile prodaccess]
       role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole
       source_profile = default
   ```

1. 新しいプロファイルを作成した後、AWS CLI パラメータを指定した `--profile prodaccess` コマンドは、デフォルトのユーザーではなく、IAM ロールである `ProductionAccessRole` にアタッチされたアクセス権限により実行されます。

   ```
   aws iam list-users --profile prodaccess
   ```

   このコマンドが機能するのは、`ProductionAccessRole` に割り当てられたアクセス許可の下で現在の AWS アカウントのユーザーを一覧表示できる場合です。

1. 元の認証情報によって付与されるアクセス許可に戻すには、`--profile` パラメータなしでコマンドを実行します。AWS CLI は、「[Step 1](#step-configure-default)」で設定したデフォルトのプロファイルの認証情報の使用に戻ります。

詳細については、*AWS Command Line Interface ユーザーガイド*の「[ロールを引き受ける](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html)」を参照してください。

## シナリオ例: インスタンスプロファイルロールが他のアカウントのロールに切り替えることを許可する
<a name="switch-role-cli-scenario-ec2-instance"></a>

2 つの AWS アカウント を使用していて、Amazon EC2 インスタンスで実行されているアプリケーションが両方のアカウントで [AWS CLI](https://aws.amazon.com/cli/) コマンドを実行できるようにするとします。アカウント `111111111111` に EC2 インスタンスが存在すると仮定します。このインスタンスには、同じ `abcd` アカウント内の Amazon S3 バケットで読み取り専用の `amzn-s3-demo-bucket1` タスクをアプリケーションが実行する `111111111111` インスタンスプロファイルのロールが含まれています。ただし、アプリケーションは、アカウント `222222222222` でタスクを実行するために `efgh` クロスアカウントロールを引き受けることも許可されている必要があります。これを行うには、`abcd` EC2 インスタンスプロファイルのロールは次のアクセス許可ポリシーを持っている必要があります。

***アカウント 111111111111 `abcd` ロールのアクセス許可ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket1/*",
                "arn:aws:s3:::amzn-s3-demo-bucket1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}
```

------

`efgh` クロスアカウントのロールが、同じ `amzn-s3-demo-bucket2` アカウント内の `222222222222` バケットで読み取り専用 Amazon S3 タスクを許可すると仮定します。これを行うには、`efgh` クロスアカウントのロールは、以下のアクセス許可ポリシーを持っている必要があります。

***アカウント 222222222222 `efgh` ロールのアクセス許可ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket2/*",
                "arn:aws:s3:::amzn-s3-demo-bucket2"
            ]
        }
    ]
}
```

------

`efgh` ロールは `abcd` インスタンスプロファイルのロールがそれを引き受けることを許可する必要があります。これを行うには、`efgh` ロールは次の信頼ポリシーを持っている必要があります。

***アカウント 222222222222 `efgh` ロールの信頼ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}
```

------

次にアカウント `222222222222` で AWS CLI コマンドを実行するには、CLI 設定ファイルを更新する必要があります。AWS CLI 設定ファイルで、`efgh` ロールを「プロファイル」として、`abcd` EC2 インスタンスプロファイルロールを「認証情報ソース」として識別します。次に、元の `abcd` ロールではなく、`efgh` ロールのアクセス許可で CLI コマンドが実行されます。

**注記**  
セキュリティ上の目的で、AWS CloudTrail を使用して、アカウントのロールの使用を監査することができます。CloudTrail ログで異なるプリンシパルのロールが使用されている場合にロールセッションを区別するには、ロールセッション名を使用できます。このトピックで説明しているように、AWS CLI がユーザーに代わってロールを引き受けると、ロールセッション名が自動的に `AWS-CLI-session-nnnnnnnn` の形式で作成されます。ここでは *nnnnnnnn* は [Unix エポック時刻](http://wikipedia.org/wiki/Unix_time) (1970 年 1 月 1 日午前 0 時 UTC からの秒数) 形式の時刻を表す整数です。詳細については、[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) の「*CloudTrail イベントリファレンス*」を参照してください。

**EC2 インスタンスプロファイルのロールをクロスアカウントのロール (AWS CLI) に切り替えることができるようにするには**

1. デフォルトの CLI プロファイルを設定する必要はありません。代わりに、EC2 インスタンスプロファイルのメタデータから認証情報を読み込むことができます。ロールの新しいプロファイルを `.aws/config` ファイルに作成します。次の例では、`222222222222` アカウントのロール `efgh` に切り替える `instancecrossaccount` プロファイルを作成します。このプロファイルが呼び出されると、AWS CLI は EC2 インスタンスプロファイルのメタデータの認証情報を使用してロールの認証情報をリクエストします。そのため、EC2 インスタンスプロファイルのロールには、`role_arn` で指定されたロールに対する `sts:AssumeRole` アクセス許可が必要です。

   ```
   [profile instancecrossaccount]
   role_arn = arn:aws:iam::222222222222:role/efgh
   credential_source = Ec2InstanceMetadata
   ```

1. 新しいプロファイルを作成した後、パラメータ `--profile instancecrossaccount` を指定する すべての AWS CLI コマンドは、アカウント `222222222222` の `efgh` ロールにアタッチされたアクセス許可で実行されます。

   ```
   aws s3 ls amzn-s3-demo-bucket2 --profile instancecrossaccount
   ```

   このコマンドは、`efgh` ロールに割り当てられたアクセス許可で現在の AWS アカウント のユーザーを一覧表示できる場合に実行されます。

1. アカウント `111111111111` の元の EC2 インスタンスプロファイルのアクセス許可に戻るには、`--profile` パラメータなしで CLI コマンドを実行します。

詳細については、*AWS Command Line Interface ユーザーガイド*の「[ロールを引き受ける](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html)」を参照してください。

# IAM ロールに切り替える (Tools for Windows PowerShell)
<a name="id_roles_use_switch-role-twp"></a>

*ロール*は、必要な AWS リソースへのアクセスに使用できる一連のアクセス許可を指定します。その点では、[AWS Identity and Access Management（IAM）のユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)に似ています。ユーザーとしてサインインすると、特定の一連のアクセス許可が付与されます。ただし、ロールにはサインインされませんが、一度サインインするとロールを切り替えることもできます。こうすると、元のユーザーアクセス権限が一時的に無効になり、そのロールに割り当てられたアクセス権限が代わりに付与されます。ロールは、自身のアカウントのロールでも、他の AWS アカウント のロールでもかまいません。ロールとその利点、およびロールを作成して設定する方法については、「[IAM ロール](id_roles.md)」および「[IAM ロールの作成](id_roles_create.md)」を参照してください。

**重要**  
IAM ユーザーと切り替え後のロールのアクセス許可は、累積されません。同時に有効になるアクセス権限のセットは 1 つのみです。ロールを切り替えると、ユーザーアクセス権限が一時的に無効になり、切り替え後のロールに割り当てられたアクセス権限が有効になります。そのロールを終了すると、ユーザーアクセス権限が自動的に復元されます。

このセクションでは、AWS Tools for Windows PowerShell のコマンドラインで作業するときにロールを切り替える方法について説明します。

開発環境にアカウントがあり、場合によって、本稼働環境で [Tools for Windows PowerShell](https://aws.amazon.com/powershell/) のコマンドラインで作業する必要があるとします。1 つのアクセスキー認証情報のセットがすでに使用可能です。このセットは、標準の IAM ユーザーに割り当てられたアクセスキーペアです。または、SAML または OIDC のフェデレーティッドプリンシパルとしてサインインしている場合、ユーザーに最初に割り当てられたロールのアクセスキーペアである場合があります。これらの認証情報を使用して、パラメータとして新しいロールの ARN を渡す `Use-STSRole` コマンドレットを実行します。このコマンドは、リクエストされたロールの一時的なセキュリティ証明書を返します。それらの認証情報は、以降の PowerShell コマンドで、本稼働環境のリソースにアクセスするためのロールのアクセス権限と共に使用します。ロールの使用中に、開発アカウントのユーザーアクセス許可を使用することはできません。同時に有効になるアクセス許可のセットは 1 つに限られるためです。

**注記**  
セキュリティ上の理由から、管理者は [AWS CloudTrail ログを確認](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)して、AWS でアクションを実行したユーザーを調べることができます。管理者は、ロールを引き受けるときに、ソース ID またはロールセッション名の指定を要求する場合があります。詳細については、「[`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity)」および「[`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)」を参照してください。

すべてのアクセスキーとトークンは例にすぎず、実際にはそのように使用できないことに注意してください。ライブ環境の適切な値に置き換えてください。

**ロールに切り替えるには (Tools for Windows PowerShell)**

1. PowerShell コマンドプロンプトを開き、現在の IAM ユーザーまたはフェデレーションロールのアクセスキーを使用するように、デフォルトのプロファイルを設定します。Tools for Windows PowerShell を以前に使用した場合、この設定はすでに完了している可能性があります。AWS アカウントのルートユーザー ではなく、IAM ユーザーとしてサインインしている場合にのみ、ロールを切り替えることができます。

   ```
   PS C:\> Set-AWSCredentials -AccessKey AKIAIOSFODNN7EXAMPLE -SecretKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY -StoreAs MyMainUserProfile
   PS C:\> Initialize-AWSDefaults -ProfileName MyMainUserProfile -Region us-east-2
   ```

   詳細については、[AWS ユーザーガイド](https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html)の「*AWS Tools for PowerShell 認証情報の指定*」を参照してください。

1. 新しいロールの認証情報を取得するには、以下のコマンドを実行して 123456789012 アカウントの `RoleName` ロールに切り替えます。ロール ARN は、ロールを作成したアカウント管理者から入手します。コマンドには、セッション名も指定する必要があります。その名前には任意のテキストを選択できます。以下のコマンドは、認証情報をリクエストした後、返されたオブジェクトから `Credentials` プロパティオブジェクトを取得して、`$Creds` 変数に格納します。

   ```
   PS C:\> $Creds = (Use-STSRole -RoleArn "arn:aws:iam::123456789012:role/RoleName" -RoleSessionName "MyRoleSessionName").Credentials
   ```

   `$Creds` オブジェクトにはこの時点で、以降の手順に必要な `AccessKeyId`、`SecretAccessKey`、`SessionToken` 要素が格納されています。以下のサンプルコマンドに示しているのは、一般的な値です。

   ```
   PS C:\> $Creds.AccessKeyId
   AKIAIOSFODNN7EXAMPLE
   
   PS C:\> $Creds.SecretAccessKey
   wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   
   PS C:\> $Creds.SessionToken
   AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvSRyh0FW7jEXAMPLEW+vE/7s1HRp
   XviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPy
   Oj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UuysgsKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/C
   s8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87eNhyDHq6ikBQ==
   
   PS C:\> $Creds.Expiration
   Thursday, June 18, 2018 2:28:31 PM
   ```

1. 以降のコマンドでこれらの認証情報を使用するには、`-Credential` パラメータに指定します。たとえば、以下のコマンドでロールの認証情報を使用すると、そのロールに `iam:ListRoles` アクセス許可が付与されている場合にのみ、`Get-IAMRoles` コマンドレットを実行できます。

   ```
           PS C:\> get-iamroles -Credential $Creds
   ```

1. 元の認証情報に戻すには、`-Credentials $Creds` パラメータの使用を止めるだけです。PowerShell ではデフォルトのプロファイルに保存された認証情報が再び使用されるようになります。

# IAM ロールを切り替える (AWS)
<a name="id_roles_use_switch-role-api"></a>

*ロール*は、AWS リソースへのアクセスに使用できる一連のアクセス許可を指定します。その点では、[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)に似ています。ロールを引き受けることで、必要なタスクを実行したり、AWS リソースを操作したりするアクセス許可がプリンシパル (ユーザーまたはアプリケーション) に付与されます。ロールは、自身のアカウントのロールでも、他の AWS アカウント のロールでもかまいません。ロールとその利点、およびロールを作成して設定する方法については、「[IAM ロール](id_roles.md)」および「[IAM ロールの作成](id_roles_create.md)」を参照してください。ロールを引き受ける別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。

**重要**  
IAM ユーザーのアクセス許可および引き受けるロールは、累積されません。同時に有効になるアクセス権限のセットは 1 つのみです。ロールを引き受けると、以前のユーザーまたはロールのアクセス許可が一時的に無効になり、切り替え後のロールに割り当てられたアクセス許可が有効になります。そのロールを終了すると、自動的に元のアクセス許可が復元されます。

ロールを引き受けるため、アプリケーションは AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーションを呼び出して、使用するロールの ARN を渡します。このオペレーションでは、一時的な認証情報で新しいセッションを作成します。このセッションのアクセス許可は、そのロールのアイデンティティベースのポリシーと同じです。

[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) を呼び出すと、必要に応じてインラインまたは管理[セッションポリシー](access_policies.md#policies_session)を渡すことができます。セッションポリシーは、ロールまたはフェデレーションユーザーのセッションに一時的な認証情報セッションをプログラムで作成する際、パラメータとして渡す高度なポリシーです。`Policy` パラメータを使用して単一の JSON インラインセッションポリシードキュメントを渡すことができます。`PolicyArns` パラメータを使用して、最大 10 個の管理セッションポリシーを指定できます。結果として得られるセッションのアクセス許可は、エンティティの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーは、ロールの一時的な認証情報を他のユーザーに提供する必要があるときに役立ちます。他のユーザーは、ロールの一時的な認証情報を以降の AWS API コールで使用し、ロールを所有するアカウント内のリソースにアクセスできます。セッションポリシーを使用して、ID ベースのポリシーで許可されているよりも多くのアクセス許可を付与することはできません。AWS でロールの有効なアクセス許可を決定する方法の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。

![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)


IAM ユーザーまたはすでにロールを使用している[外部で認証されたユーザー](id_roles_providers.md) ([SAML](id_roles_providers_saml.md) または [OIDC](id_roles_providers_oidc.md)) としてサインインすると、`AssumeRole` を呼び出すことができます。ロールを使用して 2 つ目のロールを引き受ける、[*ロールの連鎖*](id_roles.md#iam-term-role-chaining)を使用することもできます。AWS アカウントのルートユーザー としてサインインしているときに、ロールを引き受けることはできません。

デフォルトでは、ロールセッションは 1 時間です。AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーションを使用してこのロールを引き受ける場合は、`DurationSeconds` パラメータの値を指定できます。この値は 900 秒 (15 分) からロールの最大セッション期間設定までの範囲を指定できます。ロールの最大値を確認する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。

ロールの連鎖を使用すると、セッションは最長である 1 時間に制限されます。この場合 `DurationSeconds` パラメータを使用して 1 時間より大きい値を指定すると、オペレーションは失敗します。

**注記**  
セキュリティ上の理由から、管理者は [AWS CloudTrail ログを確認](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)して、AWS でアクションを実行したユーザーを調べることができます。管理者は、ロールを引き受けるときに、ソース ID またはロールセッション名の指定を要求する場合があります。詳細については、「[`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity)」および「[`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)」を参照してください。

次のコード例は、ユーザーを作成しロールを割り当てる方法を示しています。

**警告**  
セキュリティリスクを避けるため、専用ソフトウェアの開発や実際のデータを扱うときは、IAM ユーザーを認証に使用しないでください。代わりに、[AWS IAM アイデンティティセンター](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) などの ID プロバイダーとのフェデレーションを使用してください。
+ 権限のないユーザーを作成します。
+ アカウントの Amazon S3 バケットを一覧表示する権限を付与するロールを作成します。
+ ユーザーがロールを引き受けられるようにポリシーを追加します。
+ ロールを引き受け、一時的な認証情報を使用して S3 バケットを一覧表示し、リソースをクリーンアップします。

------
#### [ .NET ]

**SDK for .NET**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/IAM#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
global using Amazon.IdentityManagement;
global using Amazon.S3;
global using Amazon.SecurityToken;
global using IAMActions;
global using IamScenariosCommon;
global using Microsoft.Extensions.DependencyInjection;
global using Microsoft.Extensions.Hosting;
global using Microsoft.Extensions.Logging;
global using Microsoft.Extensions.Logging.Console;
global using Microsoft.Extensions.Logging.Debug;


namespace IAMActions;

public class IAMWrapper
{
    private readonly IAmazonIdentityManagementService _IAMService;

    /// <summary>
    /// Constructor for the IAMWrapper class.
    /// </summary>
    /// <param name="IAMService">An IAM client object.</param>
    public IAMWrapper(IAmazonIdentityManagementService IAMService)
    {
        _IAMService = IAMService;
    }

    /// <summary>
    /// Attach an IAM policy to a role.
    /// </summary>
    /// <param name="policyArn">The policy to attach.</param>
    /// <param name="roleName">The role that the policy will be attached to.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> AttachRolePolicyAsync(string policyArn, string roleName)
    {
        var response = await _IAMService.AttachRolePolicyAsync(new AttachRolePolicyRequest
        {
            PolicyArn = policyArn,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Create an IAM access key for a user.
    /// </summary>
    /// <param name="userName">The username for which to create the IAM access
    /// key.</param>
    /// <returns>The AccessKey.</returns>
    public async Task<AccessKey> CreateAccessKeyAsync(string userName)
    {
        var response = await _IAMService.CreateAccessKeyAsync(new CreateAccessKeyRequest
        {
            UserName = userName,
        });

        return response.AccessKey;

    }


    /// <summary>
    /// Create an IAM policy.
    /// </summary>
    /// <param name="policyName">The name to give the new IAM policy.</param>
    /// <param name="policyDocument">The policy document for the new policy.</param>
    /// <returns>The new IAM policy object.</returns>
    public async Task<ManagedPolicy> CreatePolicyAsync(string policyName, string policyDocument)
    {
        var response = await _IAMService.CreatePolicyAsync(new CreatePolicyRequest
        {
            PolicyDocument = policyDocument,
            PolicyName = policyName,
        });

        return response.Policy;
    }


    /// <summary>
    /// Create a new IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <param name="rolePolicyDocument">The name of the IAM policy document
    /// for the new role.</param>
    /// <returns>The Amazon Resource Name (ARN) of the role.</returns>
    public async Task<string> CreateRoleAsync(string roleName, string rolePolicyDocument)
    {
        var request = new CreateRoleRequest
        {
            RoleName = roleName,
            AssumeRolePolicyDocument = rolePolicyDocument,
        };

        var response = await _IAMService.CreateRoleAsync(request);
        return response.Role.Arn;
    }


    /// <summary>
    /// Create an IAM service-linked role.
    /// </summary>
    /// <param name="serviceName">The name of the AWS Service.</param>
    /// <param name="description">A description of the IAM service-linked role.</param>
    /// <returns>The IAM role that was created.</returns>
    public async Task<Role> CreateServiceLinkedRoleAsync(string serviceName, string description)
    {
        var request = new CreateServiceLinkedRoleRequest
        {
            AWSServiceName = serviceName,
            Description = description
        };

        var response = await _IAMService.CreateServiceLinkedRoleAsync(request);
        return response.Role;
    }


    /// <summary>
    /// Create an IAM user.
    /// </summary>
    /// <param name="userName">The username for the new IAM user.</param>
    /// <returns>The IAM user that was created.</returns>
    public async Task<User> CreateUserAsync(string userName)
    {
        var response = await _IAMService.CreateUserAsync(new CreateUserRequest { UserName = userName });
        return response.User;
    }


    /// <summary>
    /// Delete an IAM user's access key.
    /// </summary>
    /// <param name="accessKeyId">The Id for the IAM access key.</param>
    /// <param name="userName">The username of the user that owns the IAM
    /// access key.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteAccessKeyAsync(string accessKeyId, string userName)
    {
        var response = await _IAMService.DeleteAccessKeyAsync(new DeleteAccessKeyRequest
        {
            AccessKeyId = accessKeyId,
            UserName = userName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM policy.
    /// </summary>
    /// <param name="policyArn">The Amazon Resource Name (ARN) of the policy to
    /// delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeletePolicyAsync(string policyArn)
    {
        var response = await _IAMService.DeletePolicyAsync(new DeletePolicyRequest { PolicyArn = policyArn });
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteRoleAsync(string roleName)
    {
        var response = await _IAMService.DeleteRoleAsync(new DeleteRoleRequest { RoleName = roleName });
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM role policy.
    /// </summary>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <param name="policyName">The name of the IAM role policy to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteRolePolicyAsync(string roleName, string policyName)
    {
        var response = await _IAMService.DeleteRolePolicyAsync(new DeleteRolePolicyRequest
        {
            PolicyName = policyName,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM user.
    /// </summary>
    /// <param name="userName">The username of the IAM user to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteUserAsync(string userName)
    {
        var response = await _IAMService.DeleteUserAsync(new DeleteUserRequest { UserName = userName });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM user policy.
    /// </summary>
    /// <param name="policyName">The name of the IAM policy to delete.</param>
    /// <param name="userName">The username of the IAM user.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteUserPolicyAsync(string policyName, string userName)
    {
        var response = await _IAMService.DeleteUserPolicyAsync(new DeleteUserPolicyRequest { PolicyName = policyName, UserName = userName });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Detach an IAM policy from an IAM role.
    /// </summary>
    /// <param name="policyArn">The Amazon Resource Name (ARN) of the IAM policy.</param>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DetachRolePolicyAsync(string policyArn, string roleName)
    {
        var response = await _IAMService.DetachRolePolicyAsync(new DetachRolePolicyRequest
        {
            PolicyArn = policyArn,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Gets the IAM password policy for an AWS account.
    /// </summary>
    /// <returns>The PasswordPolicy for the AWS account.</returns>
    public async Task<PasswordPolicy> GetAccountPasswordPolicyAsync()
    {
        var response = await _IAMService.GetAccountPasswordPolicyAsync(new GetAccountPasswordPolicyRequest());
        return response.PasswordPolicy;
    }


    /// <summary>
    /// Get information about an IAM policy.
    /// </summary>
    /// <param name="policyArn">The IAM policy to retrieve information for.</param>
    /// <returns>The IAM policy.</returns>
    public async Task<ManagedPolicy> GetPolicyAsync(string policyArn)
    {

        var response = await _IAMService.GetPolicyAsync(new GetPolicyRequest { PolicyArn = policyArn });
        return response.Policy;
    }


    /// <summary>
    /// Get information about an IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role to retrieve information
    /// for.</param>
    /// <returns>The IAM role that was retrieved.</returns>
    public async Task<Role> GetRoleAsync(string roleName)
    {
        var response = await _IAMService.GetRoleAsync(new GetRoleRequest
        {
            RoleName = roleName,
        });

        return response.Role;
    }


    /// <summary>
    /// Get information about an IAM user.
    /// </summary>
    /// <param name="userName">The username of the user.</param>
    /// <returns>An IAM user object.</returns>
    public async Task<User> GetUserAsync(string userName)
    {
        var response = await _IAMService.GetUserAsync(new GetUserRequest { UserName = userName });
        return response.User;
    }


    /// <summary>
    /// List the IAM role policies that are attached to an IAM role.
    /// </summary>
    /// <param name="roleName">The IAM role to list IAM policies for.</param>
    /// <returns>A list of the IAM policies attached to the IAM role.</returns>
    public async Task<List<AttachedPolicyType>> ListAttachedRolePoliciesAsync(string roleName)
    {
        var attachedPolicies = new List<AttachedPolicyType>();
        var attachedRolePoliciesPaginator = _IAMService.Paginators.ListAttachedRolePolicies(new ListAttachedRolePoliciesRequest { RoleName = roleName });

        await foreach (var response in attachedRolePoliciesPaginator.Responses)
        {
            attachedPolicies.AddRange(response.AttachedPolicies);
        }

        return attachedPolicies;
    }


    /// <summary>
    /// List IAM groups.
    /// </summary>
    /// <returns>A list of IAM groups.</returns>
    public async Task<List<Group>> ListGroupsAsync()
    {
        var groupsPaginator = _IAMService.Paginators.ListGroups(new ListGroupsRequest());
        var groups = new List<Group>();

        await foreach (var response in groupsPaginator.Responses)
        {
            groups.AddRange(response.Groups);
        }

        return groups;
    }


    /// <summary>
    /// List IAM policies.
    /// </summary>
    /// <returns>A list of the IAM policies.</returns>
    public async Task<List<ManagedPolicy>> ListPoliciesAsync()
    {
        var listPoliciesPaginator = _IAMService.Paginators.ListPolicies(new ListPoliciesRequest());
        var policies = new List<ManagedPolicy>();

        await foreach (var response in listPoliciesPaginator.Responses)
        {
            policies.AddRange(response.Policies);
        }

        return policies;
    }


    /// <summary>
    /// List IAM role policies.
    /// </summary>
    /// <param name="roleName">The IAM role for which to list IAM policies.</param>
    /// <returns>A list of IAM policy names.</returns>
    public async Task<List<string>> ListRolePoliciesAsync(string roleName)
    {
        var listRolePoliciesPaginator = _IAMService.Paginators.ListRolePolicies(new ListRolePoliciesRequest { RoleName = roleName });
        var policyNames = new List<string>();

        await foreach (var response in listRolePoliciesPaginator.Responses)
        {
            policyNames.AddRange(response.PolicyNames);
        }

        return policyNames;
    }


    /// <summary>
    /// List IAM roles.
    /// </summary>
    /// <returns>A list of IAM roles.</returns>
    public async Task<List<Role>> ListRolesAsync()
    {
        var listRolesPaginator = _IAMService.Paginators.ListRoles(new ListRolesRequest());
        var roles = new List<Role>();

        await foreach (var response in listRolesPaginator.Responses)
        {
            roles.AddRange(response.Roles);
        }

        return roles;
    }


    /// <summary>
    /// List SAML authentication providers.
    /// </summary>
    /// <returns>A list of SAML providers.</returns>
    public async Task<List<SAMLProviderListEntry>> ListSAMLProvidersAsync()
    {
        var response = await _IAMService.ListSAMLProvidersAsync(new ListSAMLProvidersRequest());
        return response.SAMLProviderList;
    }


    /// <summary>
    /// List IAM users.
    /// </summary>
    /// <returns>A list of IAM users.</returns>
    public async Task<List<User>> ListUsersAsync()
    {
        var listUsersPaginator = _IAMService.Paginators.ListUsers(new ListUsersRequest());
        var users = new List<User>();

        await foreach (var response in listUsersPaginator.Responses)
        {
            users.AddRange(response.Users);
        }

        return users;
    }


    /// <summary>
    /// Update the inline policy document embedded in a role.
    /// </summary>
    /// <param name="policyName">The name of the policy to embed.</param>
    /// <param name="roleName">The name of the role to update.</param>
    /// <param name="policyDocument">The policy document that defines the role.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> PutRolePolicyAsync(string policyName, string roleName, string policyDocument)
    {
        var request = new PutRolePolicyRequest
        {
            PolicyName = policyName,
            RoleName = roleName,
            PolicyDocument = policyDocument
        };

        var response = await _IAMService.PutRolePolicyAsync(request);
        return response.HttpStatusCode == HttpStatusCode.OK;
    }


    /// <summary>
    /// Add or update an inline policy document that is embedded in an IAM user.
    /// </summary>
    /// <param name="userName">The name of the IAM user.</param>
    /// <param name="policyName">The name of the IAM policy.</param>
    /// <param name="policyDocument">The policy document defining the IAM policy.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> PutUserPolicyAsync(string userName, string policyName, string policyDocument)
    {
        var request = new PutUserPolicyRequest
        {
            UserName = userName,
            PolicyName = policyName,
            PolicyDocument = policyDocument
        };

        var response = await _IAMService.PutUserPolicyAsync(request);
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }

    /// <summary>
    /// Wait for a new access key to be ready to use.
    /// </summary>
    /// <param name="accessKeyId">The Id of the access key.</param>
    /// <returns>A boolean value indicating the success of the action.</returns>
    public async Task<bool> WaitUntilAccessKeyIsReady(string accessKeyId)
    {
        var keyReady = false;

        do
        {
            try
            {
                var response = await _IAMService.GetAccessKeyLastUsedAsync(
                    new GetAccessKeyLastUsedRequest { AccessKeyId = accessKeyId });
                if (response.UserName is not null)
                {
                    keyReady = true;
                }
            }
            catch (NoSuchEntityException)
            {
                keyReady = false;
            }
        } while (!keyReady);

        return keyReady;
    }
}



using Microsoft.Extensions.Configuration;

namespace IAMBasics;

public class IAMBasics
{
    private static ILogger logger = null!;

    static async Task Main(string[] args)
    {
        // Set up dependency injection for the AWS service.
        using var host = Host.CreateDefaultBuilder(args)
            .ConfigureLogging(logging =>
                logging.AddFilter("System", LogLevel.Debug)
                    .AddFilter<DebugLoggerProvider>("Microsoft", LogLevel.Information)
                    .AddFilter<ConsoleLoggerProvider>("Microsoft", LogLevel.Trace))
            .ConfigureServices((_, services) =>
            services.AddAWSService<IAmazonIdentityManagementService>()
            .AddTransient<IAMWrapper>()
            .AddTransient<UIWrapper>()
            )
            .Build();

        logger = LoggerFactory.Create(builder => { builder.AddConsole(); })
            .CreateLogger<IAMBasics>();


        IConfiguration configuration = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("settings.json") // Load test settings from .json file.
            .AddJsonFile("settings.local.json",
                true) // Optionally load local settings.
            .Build();

        // Values needed for user, role, and policies.
        string userName = configuration["UserName"]!;
        string s3PolicyName = configuration["S3PolicyName"]!;
        string roleName = configuration["RoleName"]!;


        var iamWrapper = host.Services.GetRequiredService<IAMWrapper>();
        var uiWrapper = host.Services.GetRequiredService<UIWrapper>();

        uiWrapper.DisplayBasicsOverview();
        uiWrapper.PressEnter();

        // First create a user. By default, the new user has
        // no permissions.
        uiWrapper.DisplayTitle("Create User");
        Console.WriteLine($"Creating a new user with user name: {userName}.");
        var user = await iamWrapper.CreateUserAsync(userName);
        var userArn = user.Arn;

        Console.WriteLine($"Successfully created user: {userName} with ARN: {userArn}.");
        uiWrapper.WaitABit(15, "Now let's wait for the user to be ready for use.");

        // Define a role policy document that allows the new user
        // to assume the role.
        string assumeRolePolicyDocument = "{" +
          "\"Version\": \"2012-10-17\"," +
          "\"Statement\": [{" +
              "\"Effect\": \"Allow\"," +
              "\"Principal\": {" +
              $"	\"AWS\": \"{userArn}\"" +
              "}," +
              "\"Action\": \"sts:AssumeRole\"" +
          "}]" +
        "}";

        // Permissions to list all buckets.
        string policyDocument = "{" +
            "\"Version\": \"2012-10-17\"," +
            "	\"Statement\" : [{" +
                "	\"Action\" : [\"s3:ListAllMyBuckets\"]," +
                "	\"Effect\" : \"Allow\"," +
                "	\"Resource\" : \"*\"" +
            "}]" +
        "}";

        // Create an AccessKey for the user.
        uiWrapper.DisplayTitle("Create access key");
        Console.WriteLine("Now let's create an access key for the new user.");
        var accessKey = await iamWrapper.CreateAccessKeyAsync(userName);

        var accessKeyId = accessKey.AccessKeyId;
        var secretAccessKey = accessKey.SecretAccessKey;

        Console.WriteLine($"We have created the access key with Access key id: {accessKeyId}.");

        Console.WriteLine("Now let's wait until the IAM access key is ready to use.");
        var keyReady = await iamWrapper.WaitUntilAccessKeyIsReady(accessKeyId);

        // Now try listing the Amazon Simple Storage Service (Amazon S3)
        // buckets. This should fail at this point because the user doesn't
        // have permissions to perform this task.
        uiWrapper.DisplayTitle("Try to display Amazon S3 buckets");
        Console.WriteLine("Now let's try to display a list of the user's Amazon S3 buckets.");
        var s3Client1 = new AmazonS3Client(accessKeyId, secretAccessKey);
        var stsClient1 = new AmazonSecurityTokenServiceClient(accessKeyId, secretAccessKey);

        var s3Wrapper = new S3Wrapper(s3Client1, stsClient1);
        var buckets = await s3Wrapper.ListMyBucketsAsync();

        Console.WriteLine(buckets is null
            ? "As expected, the call to list the buckets has returned a null list."
            : "Something went wrong. This shouldn't have worked.");

        uiWrapper.PressEnter();

        uiWrapper.DisplayTitle("Create IAM role");
        Console.WriteLine($"Creating the role: {roleName}");

        // Creating an IAM role to allow listing the S3 buckets. A role name
        // is not case sensitive and must be unique to the account for which it
        // is created.
        var roleArn = await iamWrapper.CreateRoleAsync(roleName, assumeRolePolicyDocument);

        uiWrapper.PressEnter();

        // Create a policy with permissions to list S3 buckets.
        uiWrapper.DisplayTitle("Create IAM policy");
        Console.WriteLine($"Creating the policy: {s3PolicyName}");
        Console.WriteLine("with permissions to list the Amazon S3 buckets for the account.");
        var policy = await iamWrapper.CreatePolicyAsync(s3PolicyName, policyDocument);

        // Wait 15 seconds for the IAM policy to be available.
        uiWrapper.WaitABit(15, "Waiting for the policy to be available.");

        // Attach the policy to the role you created earlier.
        uiWrapper.DisplayTitle("Attach new IAM policy");
        Console.WriteLine("Now let's attach the policy to the role.");
        await iamWrapper.AttachRolePolicyAsync(policy.Arn, roleName);

        // Wait 15 seconds for the role to be updated.
        Console.WriteLine();
        uiWrapper.WaitABit(15, "Waiting for the policy to be attached.");

        // Use the AWS Security Token Service (AWS STS) to have the user
        // assume the role we created.
        var stsClient2 = new AmazonSecurityTokenServiceClient(accessKeyId, secretAccessKey);

        // Wait for the new credentials to become valid.
        uiWrapper.WaitABit(10, "Waiting for the credentials to be valid.");

        var assumedRoleCredentials = await s3Wrapper.AssumeS3RoleAsync("temporary-session", roleArn);

        // Try again to list the buckets using the client created with
        // the new user's credentials. This time, it should work.
        var s3Client2 = new AmazonS3Client(assumedRoleCredentials);

        s3Wrapper.UpdateClients(s3Client2, stsClient2);

        buckets = await s3Wrapper.ListMyBucketsAsync();

        uiWrapper.DisplayTitle("List Amazon S3 buckets");
        Console.WriteLine("This time we should have buckets to list.");
        if (buckets is not null)
        {
            buckets.ForEach(bucket =>
            {
                Console.WriteLine($"{bucket.BucketName} created: {bucket.CreationDate}");
            });
        }

        uiWrapper.PressEnter();

        // Now clean up all the resources used in the example.
        uiWrapper.DisplayTitle("Clean up resources");
        Console.WriteLine("Thank you for watching. The IAM Basics demo is complete.");
        Console.WriteLine("Please wait while we clean up the resources we created.");

        await iamWrapper.DetachRolePolicyAsync(policy.Arn, roleName);

        await iamWrapper.DeletePolicyAsync(policy.Arn);

        await iamWrapper.DeleteRoleAsync(roleName);

        await iamWrapper.DeleteAccessKeyAsync(accessKeyId, userName);

        await iamWrapper.DeleteUserAsync(userName);

        uiWrapper.PressEnter();

        Console.WriteLine("All done cleaning up our resources. Thank you for your patience.");
    }
}


namespace IamScenariosCommon;

using System.Net;

/// <summary>
/// A class to perform Amazon Simple Storage Service (Amazon S3) actions for
/// the IAM Basics scenario.
/// </summary>
public class S3Wrapper
{
    private IAmazonS3 _s3Service;
    private IAmazonSecurityTokenService _stsService;

    /// <summary>
    /// Constructor for the S3Wrapper class.
    /// </summary>
    /// <param name="s3Service">An Amazon S3 client object.</param>
    /// <param name="stsService">An AWS Security Token Service (AWS STS)
    /// client object.</param>
    public S3Wrapper(IAmazonS3 s3Service, IAmazonSecurityTokenService stsService)
    {
        _s3Service = s3Service;
        _stsService = stsService;
    }

    /// <summary>
    /// Assumes an AWS Identity and Access Management (IAM) role that allows
    /// Amazon S3 access for the current session.
    /// </summary>
    /// <param name="roleSession">A string representing the current session.</param>
    /// <param name="roleToAssume">The name of the IAM role to assume.</param>
    /// <returns>Credentials for the newly assumed IAM role.</returns>
    public async Task<Credentials> AssumeS3RoleAsync(string roleSession, string roleToAssume)
    {
        // Create the request to use with the AssumeRoleAsync call.
        var request = new AssumeRoleRequest()
        {
            RoleSessionName = roleSession,
            RoleArn = roleToAssume,
        };

        var response = await _stsService.AssumeRoleAsync(request);

        return response.Credentials;
    }


    /// <summary>
    /// Delete an S3 bucket.
    /// </summary>
    /// <param name="bucketName">Name of the S3 bucket to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteBucketAsync(string bucketName)
    {
        var result = await _s3Service.DeleteBucketAsync(new DeleteBucketRequest { BucketName = bucketName });
        return result.HttpStatusCode == HttpStatusCode.OK;
    }

    /// <summary>
    /// List the buckets that are owned by the user's account.
    /// </summary>
    /// <returns>Async Task.</returns>
    public async Task<List<S3Bucket>?> ListMyBucketsAsync()
    {
        try
        {
            // Get the list of buckets accessible by the new user.
            var response = await _s3Service.ListBucketsAsync();

            return response.Buckets;
        }
        catch (AmazonS3Exception ex)
        {
            // Something else went wrong. Display the error message.
            Console.WriteLine($"Error: {ex.Message}");
            return null;
        }
    }

    /// <summary>
    /// Create a new S3 bucket.
    /// </summary>
    /// <param name="bucketName">The name for the new bucket.</param>
    /// <returns>A Boolean value indicating whether the action completed
    /// successfully.</returns>
    public async Task<bool> PutBucketAsync(string bucketName)
    {
        var response = await _s3Service.PutBucketAsync(new PutBucketRequest { BucketName = bucketName });
        return response.HttpStatusCode == HttpStatusCode.OK;
    }

    /// <summary>
    /// Update the client objects with new client objects. This is available
    /// because the scenario uses the methods of this class without and then
    /// with the proper permissions to list S3 buckets.
    /// </summary>
    /// <param name="s3Service">The Amazon S3 client object.</param>
    /// <param name="stsService">The AWS STS client object.</param>
    public void UpdateClients(IAmazonS3 s3Service, IAmazonSecurityTokenService stsService)
    {
        _s3Service = s3Service;
        _stsService = stsService;
    }
}


namespace IamScenariosCommon;

public class UIWrapper
{
    public readonly string SepBar = new('-', Console.WindowWidth);

    /// <summary>
    /// Show information about the IAM Groups scenario.
    /// </summary>
    public void DisplayGroupsOverview()
    {
        Console.Clear();

        DisplayTitle("Welcome to the IAM Groups Demo");
        Console.WriteLine("This example application does the following:");
        Console.WriteLine("\t1. Creates an Amazon Identity and Access Management (IAM) group.");
        Console.WriteLine("\t2. Adds an IAM policy to the IAM group giving it full access to Amazon S3.");
        Console.WriteLine("\t3. Creates a new IAM user.");
        Console.WriteLine("\t4. Creates an IAM access key for the user.");
        Console.WriteLine("\t5. Adds the user to the IAM group.");
        Console.WriteLine("\t6. Lists the buckets on the account.");
        Console.WriteLine("\t7. Proves that the user has full Amazon S3 access by creating a bucket.");
        Console.WriteLine("\t8. List the buckets again to show the new bucket.");
        Console.WriteLine("\t9. Cleans up all the resources created.");
    }

    /// <summary>
    /// Show information about the IAM Basics scenario.
    /// </summary>
    public void DisplayBasicsOverview()
    {
        Console.Clear();

        DisplayTitle("Welcome to IAM Basics");
        Console.WriteLine("This example application does the following:");
        Console.WriteLine("\t1. Creates a user with no permissions.");
        Console.WriteLine("\t2. Creates a role and policy that grant s3:ListAllMyBuckets permission.");
        Console.WriteLine("\t3. Grants the user permission to assume the role.");
        Console.WriteLine("\t4. Creates an S3 client object as the user and tries to list buckets (this will fail).");
        Console.WriteLine("\t5. Gets temporary credentials by assuming the role.");
        Console.WriteLine("\t6. Creates a new S3 client object with the temporary credentials and lists the buckets (this will succeed).");
        Console.WriteLine("\t7. Deletes all the resources.");
    }

    /// <summary>
    /// Display a message and wait until the user presses enter.
    /// </summary>
    public void PressEnter()
    {
        Console.Write("\nPress <Enter> to continue. ");
        _ = Console.ReadLine();
        Console.WriteLine();
    }

    /// <summary>
    /// Pad a string with spaces to center it on the console display.
    /// </summary>
    /// <param name="strToCenter">The string to be centered.</param>
    /// <returns>The padded string.</returns>
    public string CenterString(string strToCenter)
    {
        var padAmount = (Console.WindowWidth - strToCenter.Length) / 2;
        var leftPad = new string(' ', padAmount);
        return $"{leftPad}{strToCenter}";
    }

    /// <summary>
    /// Display a line of hyphens, the centered text of the title, and another
    /// line of hyphens.
    /// </summary>
    /// <param name="strTitle">The string to be displayed.</param>
    public void DisplayTitle(string strTitle)
    {
        Console.WriteLine(SepBar);
        Console.WriteLine(CenterString(strTitle));
        Console.WriteLine(SepBar);
    }

    /// <summary>
    /// Display a countdown and wait for a number of seconds.
    /// </summary>
    /// <param name="numSeconds">The number of seconds to wait.</param>
    public void WaitABit(int numSeconds, string msg)
    {
        Console.WriteLine(msg);

        // Wait for the requested number of seconds.
        for (int i = numSeconds; i > 0; i--)
        {
            System.Threading.Thread.Sleep(1000);
            Console.Write($"{i}...");
        }

        PressEnter();
    }
}
```
+ API の詳細については、「*AWS SDK for .NET API リファレンス*」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Bash ]

**Bash スクリプトを使用した AWS CLI**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/aws-cli/bash-linux/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
###############################################################################
# function iam_create_user_assume_role
#
# Scenario to create an IAM user, create an IAM role, and apply the role to the user.
#
#     "IAM access" permissions are needed to run this code.
#     "STS assume role" permissions are needed to run this code. (Note: It might be necessary to
#           create a custom policy).
#
# Returns:
#       0 - If successful.
#       1 - If an error occurred.
###############################################################################
function iam_create_user_assume_role() {
  {
    if [ "$IAM_OPERATIONS_SOURCED" != "True" ]; then

      source ./iam_operations.sh
    fi
  }

  echo_repeat "*" 88
  echo "Welcome to the IAM create user and assume role demo."
  echo
  echo "This demo will create an IAM user, create an IAM role, and apply the role to the user."
  echo_repeat "*" 88
  echo

  echo -n "Enter a name for a new IAM user: "
  get_input
  user_name=$get_input_result

  local user_arn
  user_arn=$(iam_create_user -u "$user_name")

  # shellcheck disable=SC2181
  if [[ ${?} == 0 ]]; then
    echo "Created demo IAM user named $user_name"
  else
    errecho "$user_arn"
    errecho "The user failed to create. This demo will exit."
    return 1
  fi

  local access_key_response
  access_key_response=$(iam_create_user_access_key -u "$user_name")
  # shellcheck disable=SC2181
  if [[ ${?} != 0 ]]; then
    errecho "The access key failed to create. This demo will exit."
    clean_up "$user_name"
    return 1
  fi

  IFS=$'\t ' read -r -a access_key_values <<<"$access_key_response"
  local key_name=${access_key_values[0]}
  local key_secret=${access_key_values[1]}

  echo "Created access key named $key_name"

  echo "Wait 10 seconds for the user to be ready."
  sleep 10
  echo_repeat "*" 88
  echo

  local iam_role_name
  iam_role_name=$(generate_random_name "test-role")
  echo "Creating a role named $iam_role_name with user $user_name as the principal."

  local assume_role_policy_document="{
    \"Version\": \"2012-10-17\",
    \"Statement\": [{
        \"Effect\": \"Allow\",
        \"Principal\": {\"AWS\": \"$user_arn\"},
        \"Action\": \"sts:AssumeRole\"
        }]
    }"

  local role_arn
  role_arn=$(iam_create_role -n "$iam_role_name" -p "$assume_role_policy_document")

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Created IAM role named $iam_role_name"
  else
    errecho "The role failed to create. This demo will exit."
    clean_up "$user_name" "$key_name"
    return 1
  fi

  local policy_name
  policy_name=$(generate_random_name "test-policy")
  local policy_document="{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]}"

  local policy_arn
  policy_arn=$(iam_create_policy -n "$policy_name" -p "$policy_document")
  # shellcheck disable=SC2181
  if [[ ${?} == 0 ]]; then
    echo "Created  IAM policy named $policy_name"
  else
    errecho "The policy failed to create."
    clean_up "$user_name" "$key_name" "$iam_role_name"
    return 1
  fi

  if (iam_attach_role_policy -n "$iam_role_name" -p "$policy_arn"); then
    echo "Attached policy $policy_arn to role $iam_role_name"
  else
    errecho "The policy failed to attach."
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn"
    return 1
  fi

  local assume_role_policy_document="{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"$role_arn\"}]}"

  local assume_role_policy_name
  assume_role_policy_name=$(generate_random_name "test-assume-role-")

  # shellcheck disable=SC2181
  local assume_role_policy_arn
  assume_role_policy_arn=$(iam_create_policy -n "$assume_role_policy_name" -p "$assume_role_policy_document")
  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Created  IAM policy named $assume_role_policy_name for sts assume role"
  else
    errecho "The policy failed to create."
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn"
    return 1
  fi

  echo "Wait 10 seconds to give AWS time to propagate these new resources and connections."
  sleep 10
  echo_repeat "*" 88
  echo

  echo "Try to list buckets without the new user assuming the role."
  echo_repeat "*" 88
  echo

  # Set the environment variables for the created user.
  # bashsupport disable=BP2001
  export AWS_ACCESS_KEY_ID=$key_name
  # bashsupport disable=BP2001
  export AWS_SECRET_ACCESS_KEY=$key_secret

  local buckets
  buckets=$(s3_list_buckets)

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    local bucket_count
    bucket_count=$(echo "$buckets" | wc -w | xargs)
    echo "There are $bucket_count buckets in the account. This should not have happened."
  else
    errecho "Because the role with permissions has not been assumed, listing buckets failed."
  fi

  echo
  echo_repeat "*" 88
  echo "Now assume the role $iam_role_name and list the buckets."
  echo_repeat "*" 88
  echo

  local credentials

  credentials=$(sts_assume_role -r "$role_arn" -n "AssumeRoleDemoSession")
  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Assumed role $iam_role_name"
  else
    errecho "Failed to assume role."
    export AWS_ACCESS_KEY_ID=""
    export AWS_SECRET_ACCESS_KEY=""
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"
    return 1
  fi

  IFS=$'\t ' read -r -a credentials <<<"$credentials"

  export AWS_ACCESS_KEY_ID=${credentials[0]}
  export AWS_SECRET_ACCESS_KEY=${credentials[1]}
  # bashsupport disable=BP2001
  export AWS_SESSION_TOKEN=${credentials[2]}

  buckets=$(s3_list_buckets)

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    local bucket_count
    bucket_count=$(echo "$buckets" | wc -w | xargs)
    echo "There are $bucket_count buckets in the account. Listing buckets succeeded because of "
    echo "the assumed role."
  else
    errecho "Failed to list buckets. This should not happen."
    export AWS_ACCESS_KEY_ID=""
    export AWS_SECRET_ACCESS_KEY=""
    export AWS_SESSION_TOKEN=""
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"
    return 1
  fi

  local result=0
  export AWS_ACCESS_KEY_ID=""
  export AWS_SECRET_ACCESS_KEY=""

  echo
  echo_repeat "*" 88
  echo "The created resources will now be deleted."
  echo_repeat "*" 88
  echo

  clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"

  # shellcheck disable=SC2181
  if [[ ${?} -ne 0 ]]; then
    result=1
  fi

  return $result
}
```
このシナリオで使用される IAM 関数。  

```
###############################################################################
# function iam_user_exists
#
# This function checks to see if the specified AWS Identity and Access Management (IAM) user already exists.
#
# Parameters:
#       $1 - The name of the IAM user to check.
#
# Returns:
#       0 - If the user already exists.
#       1 - If the user doesn't exist.
###############################################################################
function iam_user_exists() {
  local user_name
  user_name=$1

  # Check whether the IAM user already exists.
  # We suppress all output - we're interested only in the return code.

  local errors
  errors=$(aws iam get-user \
    --user-name "$user_name" 2>&1 >/dev/null)

  local error_code=${?}

  if [[ $error_code -eq 0 ]]; then
    return 0 # 0 in Bash script means true.
  else
    if [[ $errors != *"error"*"(NoSuchEntity)"* ]]; then
      aws_cli_error_log $error_code
      errecho "Error calling iam get-user $errors"
    fi

    return 1 # 1 in Bash script means false.
  fi
}

###############################################################################
# function iam_create_user
#
# This function creates the specified IAM user, unless
# it already exists.
#
# Parameters:
#       -u user_name  -- The name of the user to create.
#
# Returns:
#       The ARN of the user.
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_user() {
  local user_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user"
    echo "Creates an AWS Identity and Access Management (IAM) user. You must supply a username:"
    echo "  -u user_name    The name of the user. It must be unique within the account."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    User name:   $user_name"
  iecho ""

  # If the user already exists, we don't want to try to create it.
  if (iam_user_exists "$user_name"); then
    errecho "ERROR: A user with that name already exists in the account."
    return 1
  fi

  response=$(aws iam create-user --user-name "$user_name" \
    --output text \
    --query 'User.Arn')

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-user operation failed.$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_create_user_access_key
#
# This function creates an IAM access key for the specified user.
#
# Parameters:
#       -u user_name -- The name of the IAM user.
#       [-f file_name] -- The optional file name for the access key output.
#
# Returns:
#       [access_key_id access_key_secret]
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_user_access_key() {
  local user_name file_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user_access_key"
    echo "Creates an AWS Identity and Access Management (IAM) key pair."
    echo "  -u user_name   The name of the IAM user."
    echo "  [-f file_name]   Optional file name for the access key output."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:f:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      f) file_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  response=$(aws iam create-access-key \
    --user-name "$user_name" \
    --output text)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-access-key operation failed.$response"
    return 1
  fi

  if [[ -n "$file_name" ]]; then
    echo "$response" >"$file_name"
  fi

  local key_id key_secret
  # shellcheck disable=SC2086
  key_id=$(echo $response | cut -f 2 -d ' ')
  # shellcheck disable=SC2086
  key_secret=$(echo $response | cut -f 4 -d ' ')

  echo "$key_id $key_secret"

  return 0
}

###############################################################################
# function iam_create_role
#
# This function creates an IAM role.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_json -- The assume role policy document.
#
# Returns:
#       The ARN of the role.
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_role() {
  local role_name policy_document response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user_access_key"
    echo "Creates an AWS Identity and Access Management (IAM) role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_json -- The assume role policy document."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_document="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_document" ]]; then
    errecho "ERROR: You must provide a policy document with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam create-role \
    --role-name "$role_name" \
    --assume-role-policy-document "$policy_document" \
    --output text \
    --query Role.Arn)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-role operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_create_policy
#
# This function creates an IAM policy.
#
# Parameters:
#       -n policy_name -- The name of the IAM policy.
#       -p policy_json -- The policy document.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_policy() {
  local policy_name policy_document response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_policy"
    echo "Creates an AWS Identity and Access Management (IAM) policy."
    echo "  -n policy_name   The name of the IAM policy."
    echo "  -p policy_json -- The policy document."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) policy_name="${OPTARG}" ;;
      p) policy_document="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$policy_name" ]]; then
    errecho "ERROR: You must provide a policy name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_document" ]]; then
    errecho "ERROR: You must provide a policy document with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam create-policy \
    --policy-name "$policy_name" \
    --policy-document "$policy_document" \
    --output text \
    --query Policy.Arn)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"
}

###############################################################################
# function iam_attach_role_policy
#
# This function attaches an IAM policy to a tole.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_ARN -- The IAM policy document ARN..
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_attach_role_policy() {
  local role_name policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_attach_role_policy"
    echo "Attaches an AWS Identity and Access Management (IAM) policy to an IAM role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_ARN -- The IAM policy document ARN."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy ARN with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam attach-role-policy \
    --role-name "$role_name" \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports attach-role-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_detach_role_policy
#
# This function detaches an IAM policy to a tole.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_ARN -- The IAM policy document ARN..
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_detach_role_policy() {
  local role_name policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_detach_role_policy"
    echo "Detaches an AWS Identity and Access Management (IAM) policy to an IAM role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_ARN -- The IAM policy document ARN."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy ARN with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam detach-role-policy \
    --role-name "$role_name" \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports detach-role-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_delete_policy
#
# This function deletes an IAM policy.
#
# Parameters:
#       -n policy_arn -- The name of the IAM policy arn.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_policy() {
  local policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_policy"
    echo "Deletes an AWS Identity and Access Management (IAM) policy"
    echo "  -n policy_arn -- The name of the IAM policy arn."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:h" option; do
    case "${option}" in
      n) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy arn with the -n parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Policy arn:  $policy_arn"
  iecho ""

  response=$(aws iam delete-policy \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-policy operation failed.\n$response"
    return 1
  fi

  iecho "delete-policy response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_role
#
# This function deletes an IAM role.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_role() {
  local role_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_role"
    echo "Deletes an AWS Identity and Access Management (IAM) role"
    echo "  -n role_name -- The name of the IAM role."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  echo "role_name:$role_name"
  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Role name:  $role_name"
  iecho ""

  response=$(aws iam delete-role \
    --role-name "$role_name")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-role operation failed.\n$response"
    return 1
  fi

  iecho "delete-role response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_access_key
#
# This function deletes an IAM access key for the specified IAM user.
#
# Parameters:
#       -u user_name  -- The name of the user.
#       -k access_key -- The access key to delete.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_access_key() {
  local user_name access_key response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_access_key"
    echo "Deletes an AWS Identity and Access Management (IAM) access key for the specified IAM user"
    echo "  -u user_name    The name of the user."
    echo "  -k access_key   The access key to delete."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:k:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      k) access_key="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  if [[ -z "$access_key" ]]; then
    errecho "ERROR: You must provide an access key with the -k parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Username:   $user_name"
  iecho "    Access key:   $access_key"
  iecho ""

  response=$(aws iam delete-access-key \
    --user-name "$user_name" \
    --access-key-id "$access_key")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-access-key operation failed.\n$response"
    return 1
  fi

  iecho "delete-access-key response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_user
#
# This function deletes the specified IAM user.
#
# Parameters:
#       -u user_name  -- The name of the user to create.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_user() {
  local user_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_user"
    echo "Deletes an AWS Identity and Access Management (IAM) user. You must supply a username:"
    echo "  -u user_name    The name of the user."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    User name:   $user_name"
  iecho ""

  # If the user does not exist, we don't want to try to delete it.
  if (! iam_user_exists "$user_name"); then
    errecho "ERROR: A user with that name does not exist in the account."
    return 1
  fi

  response=$(aws iam delete-user \
    --user-name "$user_name")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-user operation failed.$response"
    return 1
  fi

  iecho "delete-user response:$response"
  iecho

  return 0
}
```
+ API の詳細については、「*AWS CLI コマンドリファレンス*」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/PutUserPolicy)

------
#### [ C\$1\$1 ]

**SDK for C\$1\$1**  
 GitHub には、その他のリソースもあります。用例一覧を検索し、[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp/example_code/iam#code-examples)での設定と実行の方法を確認してください。

```
namespace AwsDoc {
    namespace IAM {
  
        //! Cleanup by deleting created entities.
        /*!
          \sa DeleteCreatedEntities
          \param client: IAM client.
          \param role: IAM role.
          \param user: IAM user.
          \param policy: IAM policy.
        */
        static bool DeleteCreatedEntities(const Aws::IAM::IAMClient &client,
                                          const Aws::IAM::Model::Role &role,
                                          const Aws::IAM::Model::User &user,
                                          const Aws::IAM::Model::Policy &policy);
    }

    static const int LIST_BUCKETS_WAIT_SEC = 20;

    static const char ALLOCATION_TAG[] = "example_code";
}

//! Scenario to create an IAM user, create an IAM role, and apply the role to the user.
// "IAM access" permissions are needed to run this code.
// "STS assume role" permissions are needed to run this code. (Note: It might be necessary to
//    create a custom policy).
/*!
  \sa iamCreateUserAssumeRoleScenario
  \param clientConfig: Aws client configuration.
  \return bool: Successful completion.
*/
bool AwsDoc::IAM::iamCreateUserAssumeRoleScenario(
        const Aws::Client::ClientConfiguration &clientConfig) {

    Aws::IAM::IAMClient client(clientConfig);
    Aws::IAM::Model::User user;
    Aws::IAM::Model::Role role;
    Aws::IAM::Model::Policy policy;

    // 1. Create a user.
    {
        Aws::IAM::Model::CreateUserRequest request;
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String userName = "iam-demo-user-" +
                               Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetUserName(userName);

        Aws::IAM::Model::CreateUserOutcome outcome = client.CreateUser(request);
        if (!outcome.IsSuccess()) {
            std::cout << "Error creating IAM user " << userName << ":" <<
                      outcome.GetError().GetMessage() << std::endl;
            return false;
        }
        else {
            std::cout << "Successfully created IAM user " << userName << std::endl;
        }

        user = outcome.GetResult().GetUser();
    }

    // 2. Create a role.
    {
        // Get the IAM user for the current client in order to access its ARN.
        Aws::String iamUserArn;
        {
            Aws::IAM::Model::GetUserRequest request;
            Aws::IAM::Model::GetUserOutcome outcome = client.GetUser(request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error getting Iam user. " <<
                          outcome.GetError().GetMessage() << std::endl;

                DeleteCreatedEntities(client, role, user, policy);
                return false;
            }
            else {
                std::cout << "Successfully retrieved Iam user "
                          << outcome.GetResult().GetUser().GetUserName()
                          << std::endl;
            }

            iamUserArn = outcome.GetResult().GetUser().GetArn();
        }

        Aws::IAM::Model::CreateRoleRequest request;

        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String roleName = "iam-demo-role-" +
                               Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetRoleName(roleName);

        // Build policy document for role.
        Aws::Utils::Document jsonStatement;
        jsonStatement.WithString("Effect", "Allow");

        Aws::Utils::Document jsonPrincipal;
        jsonPrincipal.WithString("AWS", iamUserArn);
        jsonStatement.WithObject("Principal", jsonPrincipal);
        jsonStatement.WithString("Action", "sts:AssumeRole");
        jsonStatement.WithObject("Condition", Aws::Utils::Document());

        Aws::Utils::Document policyDocument;
        policyDocument.WithString("Version", "2012-10-17");

        Aws::Utils::Array<Aws::Utils::Document> statements(1);
        statements[0] = jsonStatement;
        policyDocument.WithArray("Statement", statements);

        std::cout << "Setting policy for role\n   "
                  << policyDocument.View().WriteCompact() << std::endl;

        // Set role policy document as JSON string.
        request.SetAssumeRolePolicyDocument(policyDocument.View().WriteCompact());

        Aws::IAM::Model::CreateRoleOutcome outcome = client.CreateRole(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating role. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully created a role with name " << roleName
                      << std::endl;
        }

        role = outcome.GetResult().GetRole();
    }

    // 3. Create an IAM policy.
    {
        Aws::IAM::Model::CreatePolicyRequest request;
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String policyName = "iam-demo-policy-" +
                                 Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetPolicyName(policyName);

        // Build IAM policy document.
        Aws::Utils::Document jsonStatement;
        jsonStatement.WithString("Effect", "Allow");
        jsonStatement.WithString("Action", "s3:ListAllMyBuckets");
        jsonStatement.WithString("Resource", "arn:aws:s3:::*");

        Aws::Utils::Document policyDocument;
        policyDocument.WithString("Version", "2012-10-17");

        Aws::Utils::Array<Aws::Utils::Document> statements(1);
        statements[0] = jsonStatement;
        policyDocument.WithArray("Statement", statements);

        std::cout << "Creating a policy.\n   " << policyDocument.View().WriteCompact()
                  << std::endl;

        // Set IAM policy document as JSON string.
        request.SetPolicyDocument(policyDocument.View().WriteCompact());

        Aws::IAM::Model::CreatePolicyOutcome outcome = client.CreatePolicy(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating policy. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully created a policy with name, " << policyName <<
                      "." << std::endl;
        }

        policy = outcome.GetResult().GetPolicy();
    }

    // 4. Assume the new role using the AWS Security Token Service (STS).
    Aws::STS::Model::Credentials credentials;
    {
        Aws::STS::STSClient stsClient(clientConfig);

        Aws::STS::Model::AssumeRoleRequest request;
        request.SetRoleArn(role.GetArn());
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String roleSessionName = "iam-demo-role-session-" +
                                      Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetRoleSessionName(roleSessionName);

        Aws::STS::Model::AssumeRoleOutcome assumeRoleOutcome;

        // Repeatedly call AssumeRole, because there is often a delay
        // before the role is available to be assumed.
        // Repeat at most 20 times when access is denied.
        int count = 0;
        while (true) {
            assumeRoleOutcome = stsClient.AssumeRole(request);
            if (!assumeRoleOutcome.IsSuccess()) {
                if (count > 20 ||
                    assumeRoleOutcome.GetError().GetErrorType() !=
                    Aws::STS::STSErrors::ACCESS_DENIED) {
                    std::cerr << "Error assuming role after 20 tries. " <<
                              assumeRoleOutcome.GetError().GetMessage() << std::endl;

                    DeleteCreatedEntities(client, role, user, policy);
                    return false;
                }
                std::this_thread::sleep_for(std::chrono::seconds(1));
            }
            else {
                std::cout << "Successfully assumed the role after " << count
                          << " seconds." << std::endl;
                break;
            }
            count++;
        }

        credentials = assumeRoleOutcome.GetResult().GetCredentials();
    }


    // 5. List objects in the bucket (This should fail).
    {
        Aws::S3::S3Client s3Client(
                Aws::Auth::AWSCredentials(credentials.GetAccessKeyId(),
                                          credentials.GetSecretAccessKey(),
                                          credentials.GetSessionToken()),
                Aws::MakeShared<Aws::S3::S3EndpointProvider>(ALLOCATION_TAG),
                clientConfig);
        Aws::S3::Model::ListBucketsOutcome listBucketsOutcome = s3Client.ListBuckets();
        if (!listBucketsOutcome.IsSuccess()) {
            if (listBucketsOutcome.GetError().GetErrorType() !=
                Aws::S3::S3Errors::ACCESS_DENIED) {
                std::cerr << "Could not lists buckets. " <<
                          listBucketsOutcome.GetError().GetMessage() << std::endl;
            }
            else {
                std::cout
                        << "Access to list buckets denied because privileges have not been applied."
                        << std::endl;
            }
        }
        else {
            std::cerr
                    << "Successfully retrieved bucket lists when this should not happen."
                    << std::endl;
        }
    }

    // 6. Attach the policy to the role.
    {
        Aws::IAM::Model::AttachRolePolicyRequest request;
        request.SetRoleName(role.GetRoleName());
        request.WithPolicyArn(policy.GetArn());

        Aws::IAM::Model::AttachRolePolicyOutcome outcome = client.AttachRolePolicy(
                request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating policy. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully attached the policy with name, "
                      << policy.GetPolicyName() <<
                      ", to the role, " << role.GetRoleName() << "." << std::endl;
        }
    }

    int count = 0;
    // 7. List objects in the bucket (this should succeed).
    // Repeatedly call ListBuckets, because there is often a delay
    // before the policy with ListBucket permissions has been applied to the role.
    // Repeat at most LIST_BUCKETS_WAIT_SEC times when access is denied.
    while (true) {
        Aws::S3::S3Client s3Client(
                Aws::Auth::AWSCredentials(credentials.GetAccessKeyId(),
                                          credentials.GetSecretAccessKey(),
                                          credentials.GetSessionToken()),
                Aws::MakeShared<Aws::S3::S3EndpointProvider>(ALLOCATION_TAG),
                clientConfig);
        Aws::S3::Model::ListBucketsOutcome listBucketsOutcome = s3Client.ListBuckets();
        if (!listBucketsOutcome.IsSuccess()) {
            if ((count > LIST_BUCKETS_WAIT_SEC) ||
                listBucketsOutcome.GetError().GetErrorType() !=
                Aws::S3::S3Errors::ACCESS_DENIED) {
                std::cerr << "Could not lists buckets after " << LIST_BUCKETS_WAIT_SEC << " seconds. " <<
                          listBucketsOutcome.GetError().GetMessage() << std::endl;
                DeleteCreatedEntities(client, role, user, policy);
                return false;
            }

            std::this_thread::sleep_for(std::chrono::seconds(1));
        }
        else {

            std::cout << "Successfully retrieved bucket lists after " << count
                      << " seconds." << std::endl;
            break;
        }
        count++;
    }

    // 8. Delete all the created resources.
    return DeleteCreatedEntities(client, role, user, policy);
}

bool AwsDoc::IAM::DeleteCreatedEntities(const Aws::IAM::IAMClient &client,
                                        const Aws::IAM::Model::Role &role,
                                        const Aws::IAM::Model::User &user,
                                        const Aws::IAM::Model::Policy &policy) {
    bool result = true;
    if (policy.ArnHasBeenSet()) {
        // Detach the policy from the role.
        {
            Aws::IAM::Model::DetachRolePolicyRequest request;
            request.SetPolicyArn(policy.GetArn());
            request.SetRoleName(role.GetRoleName());

            Aws::IAM::Model::DetachRolePolicyOutcome outcome = client.DetachRolePolicy(
                    request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error Detaching policy from roles. " <<
                          outcome.GetError().GetMessage() << std::endl;
                result = false;
            }
            else {
                std::cout << "Successfully detached the policy with arn "
                          << policy.GetArn()
                          << " from role " << role.GetRoleName() << "." << std::endl;
            }
        }

        // Delete the policy.
        {
            Aws::IAM::Model::DeletePolicyRequest request;
            request.WithPolicyArn(policy.GetArn());

            Aws::IAM::Model::DeletePolicyOutcome outcome = client.DeletePolicy(request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error deleting policy. " <<
                          outcome.GetError().GetMessage() << std::endl;
                result = false;
            }
            else {
                std::cout << "Successfully deleted the policy with arn "
                          << policy.GetArn() << std::endl;
            }
        }

    }

    if (role.RoleIdHasBeenSet()) {
        // Delete the role.
        Aws::IAM::Model::DeleteRoleRequest request;
        request.SetRoleName(role.GetRoleName());

        Aws::IAM::Model::DeleteRoleOutcome outcome = client.DeleteRole(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error deleting role. " <<
                      outcome.GetError().GetMessage() << std::endl;
            result = false;
        }
        else {
            std::cout << "Successfully deleted the role with name "
                      << role.GetRoleName() << std::endl;
        }
    }

    if (user.ArnHasBeenSet()) {
        // Delete the user.
        Aws::IAM::Model::DeleteUserRequest request;
        request.WithUserName(user.GetUserName());

        Aws::IAM::Model::DeleteUserOutcome outcome = client.DeleteUser(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error deleting user. " <<
                      outcome.GetError().GetMessage() << std::endl;
            result = false;
        }
        else {
            std::cout << "Successfully deleted the user with name "
                      << user.GetUserName() << std::endl;
        }
    }

    return result;
}
```
+ API の詳細については、「*AWS SDK for C\$1\$1 API リファレンス*」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/PutUserPolicy)

------
#### [ Go ]

**SDK for Go V2**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。
コマンドプロンプトからインタラクティブのシナリオを実行します。  

```
import (
	"context"
	"errors"
	"fmt"
	"log"
	"math/rand"
	"strings"
	"time"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/credentials"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
	"github.com/aws/aws-sdk-go-v2/service/s3"
	"github.com/aws/aws-sdk-go-v2/service/sts"
	"github.com/aws/smithy-go"
	"github.com/awsdocs/aws-doc-sdk-examples/gov2/demotools"
	"github.com/awsdocs/aws-doc-sdk-examples/gov2/iam/actions"
)

// AssumeRoleScenario shows you how to use the AWS Identity and Access Management (IAM)
// service to perform the following actions:
//
//  1. Create a user who has no permissions.
//  2. Create a role that grants permission to list Amazon Simple Storage Service
//     (Amazon S3) buckets for the account.
//  3. Add a policy to let the user assume the role.
//  4. Try and fail to list buckets without permissions.
//  5. Assume the role and list S3 buckets using temporary credentials.
//  6. Delete the policy, role, and user.
type AssumeRoleScenario struct {
	sdkConfig      aws.Config
	accountWrapper actions.AccountWrapper
	policyWrapper  actions.PolicyWrapper
	roleWrapper    actions.RoleWrapper
	userWrapper    actions.UserWrapper
	questioner     demotools.IQuestioner
	helper         IScenarioHelper
	isTestRun      bool
}

// NewAssumeRoleScenario constructs an AssumeRoleScenario instance from a configuration.
// It uses the specified config to get an IAM client and create wrappers for the actions
// used in the scenario.
func NewAssumeRoleScenario(sdkConfig aws.Config, questioner demotools.IQuestioner,
	helper IScenarioHelper) AssumeRoleScenario {
	iamClient := iam.NewFromConfig(sdkConfig)
	return AssumeRoleScenario{
		sdkConfig:      sdkConfig,
		accountWrapper: actions.AccountWrapper{IamClient: iamClient},
		policyWrapper:  actions.PolicyWrapper{IamClient: iamClient},
		roleWrapper:    actions.RoleWrapper{IamClient: iamClient},
		userWrapper:    actions.UserWrapper{IamClient: iamClient},
		questioner:     questioner,
		helper:         helper,
	}
}

// addTestOptions appends the API options specified in the original configuration to
// another configuration. This is used to attach the middleware stubber to clients
// that are constructed during the scenario, which is needed for unit testing.
func (scenario AssumeRoleScenario) addTestOptions(scenarioConfig *aws.Config) {
	if scenario.isTestRun {
		scenarioConfig.APIOptions = append(scenarioConfig.APIOptions, scenario.sdkConfig.APIOptions...)
	}
}

// Run runs the interactive scenario.
func (scenario AssumeRoleScenario) Run(ctx context.Context) {
	defer func() {
		if r := recover(); r != nil {
			log.Printf("Something went wrong with the demo.\n")
			log.Println(r)
		}
	}()

	log.Println(strings.Repeat("-", 88))
	log.Println("Welcome to the AWS Identity and Access Management (IAM) assume role demo.")
	log.Println(strings.Repeat("-", 88))

	user := scenario.CreateUser(ctx)
	accessKey := scenario.CreateAccessKey(ctx, user)
	role := scenario.CreateRoleAndPolicies(ctx, user)
	noPermsConfig := scenario.ListBucketsWithoutPermissions(ctx, accessKey)
	scenario.ListBucketsWithAssumedRole(ctx, noPermsConfig, role)
	scenario.Cleanup(ctx, user, role)

	log.Println(strings.Repeat("-", 88))
	log.Println("Thanks for watching!")
	log.Println(strings.Repeat("-", 88))
}

// CreateUser creates a new IAM user. This user has no permissions.
func (scenario AssumeRoleScenario) CreateUser(ctx context.Context) *types.User {
	log.Println("Let's create an example user with no permissions.")
	userName := scenario.questioner.Ask("Enter a name for the example user:", demotools.NotEmpty{})
	user, err := scenario.userWrapper.GetUser(ctx, userName)
	if err != nil {
		panic(err)
	}
	if user == nil {
		user, err = scenario.userWrapper.CreateUser(ctx, userName)
		if err != nil {
			panic(err)
		}
		log.Printf("Created user %v.\n", *user.UserName)
	} else {
		log.Printf("User %v already exists.\n", *user.UserName)
	}
	log.Println(strings.Repeat("-", 88))
	return user
}

// CreateAccessKey creates an access key for the user.
func (scenario AssumeRoleScenario) CreateAccessKey(ctx context.Context, user *types.User) *types.AccessKey {
	accessKey, err := scenario.userWrapper.CreateAccessKeyPair(ctx, *user.UserName)
	if err != nil {
		panic(err)
	}
	log.Printf("Created access key %v for your user.", *accessKey.AccessKeyId)
	log.Println("Waiting a few seconds for your user to be ready...")
	scenario.helper.Pause(10)
	log.Println(strings.Repeat("-", 88))
	return accessKey
}

// CreateRoleAndPolicies creates a policy that grants permission to list S3 buckets for
// the current account and attaches the policy to a newly created role. It also adds an
// inline policy to the specified user that grants the user permission to assume the role.
func (scenario AssumeRoleScenario) CreateRoleAndPolicies(ctx context.Context, user *types.User) *types.Role {
	log.Println("Let's create a role and policy that grant permission to list S3 buckets.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	listBucketsRole, err := scenario.roleWrapper.CreateRole(ctx, scenario.helper.GetName(), *user.Arn)
	if err != nil {
		panic(err)
	}
	log.Printf("Created role %v.\n", *listBucketsRole.RoleName)
	listBucketsPolicy, err := scenario.policyWrapper.CreatePolicy(
		ctx, scenario.helper.GetName(), []string{"s3:ListAllMyBuckets"}, "arn:aws:s3:::*")
	if err != nil {
		panic(err)
	}
	log.Printf("Created policy %v.\n", *listBucketsPolicy.PolicyName)
	err = scenario.roleWrapper.AttachRolePolicy(ctx, *listBucketsPolicy.Arn, *listBucketsRole.RoleName)
	if err != nil {
		panic(err)
	}
	log.Printf("Attached policy %v to role %v.\n", *listBucketsPolicy.PolicyName,
		*listBucketsRole.RoleName)
	err = scenario.userWrapper.CreateUserPolicy(ctx, *user.UserName, scenario.helper.GetName(),
		[]string{"sts:AssumeRole"}, *listBucketsRole.Arn)
	if err != nil {
		panic(err)
	}
	log.Printf("Created an inline policy for user %v that lets the user assume the role.\n",
		*user.UserName)
	log.Println("Let's give AWS a few seconds to propagate these new resources and connections...")
	scenario.helper.Pause(10)
	log.Println(strings.Repeat("-", 88))
	return listBucketsRole
}

// ListBucketsWithoutPermissions creates an Amazon S3 client from the user's access key
// credentials and tries to list buckets for the account. Because the user does not have
// permission to perform this action, the action fails.
func (scenario AssumeRoleScenario) ListBucketsWithoutPermissions(ctx context.Context, accessKey *types.AccessKey) *aws.Config {
	log.Println("Let's try to list buckets without permissions. This should return an AccessDenied error.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	noPermsConfig, err := config.LoadDefaultConfig(ctx,
		config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider(
			*accessKey.AccessKeyId, *accessKey.SecretAccessKey, ""),
		))
	if err != nil {
		panic(err)
	}

	// Add test options if this is a test run. This is needed only for testing purposes.
	scenario.addTestOptions(&noPermsConfig)

	s3Client := s3.NewFromConfig(noPermsConfig)
	_, err = s3Client.ListBuckets(ctx, &s3.ListBucketsInput{})
	if err != nil {
		// The SDK for Go does not model the AccessDenied error, so check ErrorCode directly.
		var ae smithy.APIError
		if errors.As(err, &ae) {
			switch ae.ErrorCode() {
			case "AccessDenied":
				log.Println("Got AccessDenied error, which is the expected result because\n" +
					"the ListBuckets call was made without permissions.")
			default:
				log.Println("Expected AccessDenied, got something else.")
				panic(err)
			}
		}
	} else {
		log.Println("Expected AccessDenied error when calling ListBuckets without permissions,\n" +
			"but the call succeeded. Continuing the example anyway...")
	}
	log.Println(strings.Repeat("-", 88))
	return &noPermsConfig
}

// ListBucketsWithAssumedRole performs the following actions:
//
//  1. Creates an AWS Security Token Service (AWS STS) client from the config created from
//     the user's access key credentials.
//  2. Gets temporary credentials by assuming the role that grants permission to list the
//     buckets.
//  3. Creates an Amazon S3 client from the temporary credentials.
//  4. Lists buckets for the account. Because the temporary credentials are generated by
//     assuming the role that grants permission, the action succeeds.
func (scenario AssumeRoleScenario) ListBucketsWithAssumedRole(ctx context.Context, noPermsConfig *aws.Config, role *types.Role) {
	log.Println("Let's assume the role that grants permission to list buckets and try again.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	stsClient := sts.NewFromConfig(*noPermsConfig)
	tempCredentials, err := stsClient.AssumeRole(ctx, &sts.AssumeRoleInput{
		RoleArn:         role.Arn,
		RoleSessionName: aws.String("AssumeRoleExampleSession"),
		DurationSeconds: aws.Int32(900),
	})
	if err != nil {
		log.Printf("Couldn't assume role %v.\n", *role.RoleName)
		panic(err)
	}
	log.Printf("Assumed role %v, got temporary credentials.\n", *role.RoleName)
	assumeRoleConfig, err := config.LoadDefaultConfig(ctx,
		config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider(
			*tempCredentials.Credentials.AccessKeyId,
			*tempCredentials.Credentials.SecretAccessKey,
			*tempCredentials.Credentials.SessionToken),
		),
	)
	if err != nil {
		panic(err)
	}

	// Add test options if this is a test run. This is needed only for testing purposes.
	scenario.addTestOptions(&assumeRoleConfig)

	s3Client := s3.NewFromConfig(assumeRoleConfig)
	result, err := s3Client.ListBuckets(ctx, &s3.ListBucketsInput{})
	if err != nil {
		log.Println("Couldn't list buckets with assumed role credentials.")
		panic(err)
	}
	log.Println("Successfully called ListBuckets with assumed role credentials, \n" +
		"here are some of them:")
	for i := 0; i < len(result.Buckets) && i < 5; i++ {
		log.Printf("\t%v\n", *result.Buckets[i].Name)
	}
	log.Println(strings.Repeat("-", 88))
}

// Cleanup deletes all resources created for the scenario.
func (scenario AssumeRoleScenario) Cleanup(ctx context.Context, user *types.User, role *types.Role) {
	if scenario.questioner.AskBool(
		"Do you want to delete the resources created for this example? (y/n)", "y",
	) {
		policies, err := scenario.roleWrapper.ListAttachedRolePolicies(ctx, *role.RoleName)
		if err != nil {
			panic(err)
		}
		for _, policy := range policies {
			err = scenario.roleWrapper.DetachRolePolicy(ctx, *role.RoleName, *policy.PolicyArn)
			if err != nil {
				panic(err)
			}
			err = scenario.policyWrapper.DeletePolicy(ctx, *policy.PolicyArn)
			if err != nil {
				panic(err)
			}
			log.Printf("Detached policy %v from role %v and deleted the policy.\n",
				*policy.PolicyName, *role.RoleName)
		}
		err = scenario.roleWrapper.DeleteRole(ctx, *role.RoleName)
		if err != nil {
			panic(err)
		}
		log.Printf("Deleted role %v.\n", *role.RoleName)

		userPols, err := scenario.userWrapper.ListUserPolicies(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		for _, userPol := range userPols {
			err = scenario.userWrapper.DeleteUserPolicy(ctx, *user.UserName, userPol)
			if err != nil {
				panic(err)
			}
			log.Printf("Deleted policy %v from user %v.\n", userPol, *user.UserName)
		}
		keys, err := scenario.userWrapper.ListAccessKeys(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		for _, key := range keys {
			err = scenario.userWrapper.DeleteAccessKey(ctx, *user.UserName, *key.AccessKeyId)
			if err != nil {
				panic(err)
			}
			log.Printf("Deleted access key %v from user %v.\n", *key.AccessKeyId, *user.UserName)
		}
		err = scenario.userWrapper.DeleteUser(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		log.Printf("Deleted user %v.\n", *user.UserName)
		log.Println(strings.Repeat("-", 88))
	}

}

// IScenarioHelper abstracts input and wait functions from a scenario so that they
// can be mocked for unit testing.
type IScenarioHelper interface {
	GetName() string
	Pause(secs int)
}

const rMax = 100000

type ScenarioHelper struct {
	Prefix string
	Random *rand.Rand
}

// GetName returns a unique name formed of a prefix and a random number.
func (helper *ScenarioHelper) GetName() string {
	return fmt.Sprintf("%v%v", helper.Prefix, helper.Random.Intn(rMax))
}

// Pause waits for the specified number of seconds.
func (helper ScenarioHelper) Pause(secs int) {
	time.Sleep(time.Duration(secs) * time.Second)
}
```
アカウントアクションをラップする構造体を定義します。  

```
import (
	"context"
	"log"

	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// AccountWrapper encapsulates AWS Identity and Access Management (IAM) account actions
// used in the examples.
// It contains an IAM service client that is used to perform account actions.
type AccountWrapper struct {
	IamClient *iam.Client
}



// GetAccountPasswordPolicy gets the account password policy for the current account.
// If no policy has been set, a NoSuchEntityException is error is returned.
func (wrapper AccountWrapper) GetAccountPasswordPolicy(ctx context.Context) (*types.PasswordPolicy, error) {
	var pwPolicy *types.PasswordPolicy
	result, err := wrapper.IamClient.GetAccountPasswordPolicy(ctx,
		&iam.GetAccountPasswordPolicyInput{})
	if err != nil {
		log.Printf("Couldn't get account password policy. Here's why: %v\n", err)
	} else {
		pwPolicy = result.PasswordPolicy
	}
	return pwPolicy, err
}



// ListSAMLProviders gets the SAML providers for the account.
func (wrapper AccountWrapper) ListSAMLProviders(ctx context.Context) ([]types.SAMLProviderListEntry, error) {
	var providers []types.SAMLProviderListEntry
	result, err := wrapper.IamClient.ListSAMLProviders(ctx, &iam.ListSAMLProvidersInput{})
	if err != nil {
		log.Printf("Couldn't list SAML providers. Here's why: %v\n", err)
	} else {
		providers = result.SAMLProviderList
	}
	return providers, err
}
```
ポリシーアクションをラップする構造体を定義します。  

```
import (
	"context"
	"encoding/json"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// PolicyWrapper encapsulates AWS Identity and Access Management (IAM) policy actions
// used in the examples.
// It contains an IAM service client that is used to perform policy actions.
type PolicyWrapper struct {
	IamClient *iam.Client
}



// ListPolicies gets up to maxPolicies policies.
func (wrapper PolicyWrapper) ListPolicies(ctx context.Context, maxPolicies int32) ([]types.Policy, error) {
	var policies []types.Policy
	result, err := wrapper.IamClient.ListPolicies(ctx, &iam.ListPoliciesInput{
		MaxItems: aws.Int32(maxPolicies),
	})
	if err != nil {
		log.Printf("Couldn't list policies. Here's why: %v\n", err)
	} else {
		policies = result.Policies
	}
	return policies, err
}



// PolicyDocument defines a policy document as a Go struct that can be serialized
// to JSON.
type PolicyDocument struct {
	Version   string
	Statement []PolicyStatement
}

// PolicyStatement defines a statement in a policy document.
type PolicyStatement struct {
	Effect    string
	Action    []string
	Principal map[string]string `json:",omitempty"`
	Resource  *string           `json:",omitempty"`
}

// CreatePolicy creates a policy that grants a list of actions to the specified resource.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper PolicyWrapper) CreatePolicy(ctx context.Context, policyName string, actions []string,
	resourceArn string) (*types.Policy, error) {
	var policy *types.Policy
	policyDoc := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:   "Allow",
			Action:   actions,
			Resource: aws.String(resourceArn),
		}},
	}
	policyBytes, err := json.Marshal(policyDoc)
	if err != nil {
		log.Printf("Couldn't create policy document for %v. Here's why: %v\n", resourceArn, err)
		return nil, err
	}
	result, err := wrapper.IamClient.CreatePolicy(ctx, &iam.CreatePolicyInput{
		PolicyDocument: aws.String(string(policyBytes)),
		PolicyName:     aws.String(policyName),
	})
	if err != nil {
		log.Printf("Couldn't create policy %v. Here's why: %v\n", policyName, err)
	} else {
		policy = result.Policy
	}
	return policy, err
}



// GetPolicy gets data about a policy.
func (wrapper PolicyWrapper) GetPolicy(ctx context.Context, policyArn string) (*types.Policy, error) {
	var policy *types.Policy
	result, err := wrapper.IamClient.GetPolicy(ctx, &iam.GetPolicyInput{
		PolicyArn: aws.String(policyArn),
	})
	if err != nil {
		log.Printf("Couldn't get policy %v. Here's why: %v\n", policyArn, err)
	} else {
		policy = result.Policy
	}
	return policy, err
}



// DeletePolicy deletes a policy.
func (wrapper PolicyWrapper) DeletePolicy(ctx context.Context, policyArn string) error {
	_, err := wrapper.IamClient.DeletePolicy(ctx, &iam.DeletePolicyInput{
		PolicyArn: aws.String(policyArn),
	})
	if err != nil {
		log.Printf("Couldn't delete policy %v. Here's why: %v\n", policyArn, err)
	}
	return err
}
```
ロールアクションをラップする構造体を定義します。  

```
import (
	"context"
	"encoding/json"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// RoleWrapper encapsulates AWS Identity and Access Management (IAM) role actions
// used in the examples.
// It contains an IAM service client that is used to perform role actions.
type RoleWrapper struct {
	IamClient *iam.Client
}



// ListRoles gets up to maxRoles roles.
func (wrapper RoleWrapper) ListRoles(ctx context.Context, maxRoles int32) ([]types.Role, error) {
	var roles []types.Role
	result, err := wrapper.IamClient.ListRoles(ctx,
		&iam.ListRolesInput{MaxItems: aws.Int32(maxRoles)},
	)
	if err != nil {
		log.Printf("Couldn't list roles. Here's why: %v\n", err)
	} else {
		roles = result.Roles
	}
	return roles, err
}



// CreateRole creates a role that trusts a specified user. The trusted user can assume
// the role to acquire its permissions.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper RoleWrapper) CreateRole(ctx context.Context, roleName string, trustedUserArn string) (*types.Role, error) {
	var role *types.Role
	trustPolicy := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:    "Allow",
			Principal: map[string]string{"AWS": trustedUserArn},
			Action:    []string{"sts:AssumeRole"},
		}},
	}
	policyBytes, err := json.Marshal(trustPolicy)
	if err != nil {
		log.Printf("Couldn't create trust policy for %v. Here's why: %v\n", trustedUserArn, err)
		return nil, err
	}
	result, err := wrapper.IamClient.CreateRole(ctx, &iam.CreateRoleInput{
		AssumeRolePolicyDocument: aws.String(string(policyBytes)),
		RoleName:                 aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't create role %v. Here's why: %v\n", roleName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// GetRole gets data about a role.
func (wrapper RoleWrapper) GetRole(ctx context.Context, roleName string) (*types.Role, error) {
	var role *types.Role
	result, err := wrapper.IamClient.GetRole(ctx,
		&iam.GetRoleInput{RoleName: aws.String(roleName)})
	if err != nil {
		log.Printf("Couldn't get role %v. Here's why: %v\n", roleName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// CreateServiceLinkedRole creates a service-linked role that is owned by the specified service.
func (wrapper RoleWrapper) CreateServiceLinkedRole(ctx context.Context, serviceName string, description string) (
	*types.Role, error) {
	var role *types.Role
	result, err := wrapper.IamClient.CreateServiceLinkedRole(ctx, &iam.CreateServiceLinkedRoleInput{
		AWSServiceName: aws.String(serviceName),
		Description:    aws.String(description),
	})
	if err != nil {
		log.Printf("Couldn't create service-linked role %v. Here's why: %v\n", serviceName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// DeleteServiceLinkedRole deletes a service-linked role.
func (wrapper RoleWrapper) DeleteServiceLinkedRole(ctx context.Context, roleName string) error {
	_, err := wrapper.IamClient.DeleteServiceLinkedRole(ctx, &iam.DeleteServiceLinkedRoleInput{
		RoleName: aws.String(roleName)},
	)
	if err != nil {
		log.Printf("Couldn't delete service-linked role %v. Here's why: %v\n", roleName, err)
	}
	return err
}



// AttachRolePolicy attaches a policy to a role.
func (wrapper RoleWrapper) AttachRolePolicy(ctx context.Context, policyArn string, roleName string) error {
	_, err := wrapper.IamClient.AttachRolePolicy(ctx, &iam.AttachRolePolicyInput{
		PolicyArn: aws.String(policyArn),
		RoleName:  aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't attach policy %v to role %v. Here's why: %v\n", policyArn, roleName, err)
	}
	return err
}



// ListAttachedRolePolicies lists the policies that are attached to the specified role.
func (wrapper RoleWrapper) ListAttachedRolePolicies(ctx context.Context, roleName string) ([]types.AttachedPolicy, error) {
	var policies []types.AttachedPolicy
	result, err := wrapper.IamClient.ListAttachedRolePolicies(ctx, &iam.ListAttachedRolePoliciesInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't list attached policies for role %v. Here's why: %v\n", roleName, err)
	} else {
		policies = result.AttachedPolicies
	}
	return policies, err
}



// DetachRolePolicy detaches a policy from a role.
func (wrapper RoleWrapper) DetachRolePolicy(ctx context.Context, roleName string, policyArn string) error {
	_, err := wrapper.IamClient.DetachRolePolicy(ctx, &iam.DetachRolePolicyInput{
		PolicyArn: aws.String(policyArn),
		RoleName:  aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't detach policy from role %v. Here's why: %v\n", roleName, err)
	}
	return err
}



// ListRolePolicies lists the inline policies for a role.
func (wrapper RoleWrapper) ListRolePolicies(ctx context.Context, roleName string) ([]string, error) {
	var policies []string
	result, err := wrapper.IamClient.ListRolePolicies(ctx, &iam.ListRolePoliciesInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't list policies for role %v. Here's why: %v\n", roleName, err)
	} else {
		policies = result.PolicyNames
	}
	return policies, err
}



// DeleteRole deletes a role. All attached policies must be detached before a
// role can be deleted.
func (wrapper RoleWrapper) DeleteRole(ctx context.Context, roleName string) error {
	_, err := wrapper.IamClient.DeleteRole(ctx, &iam.DeleteRoleInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't delete role %v. Here's why: %v\n", roleName, err)
	}
	return err
}
```
ユーザーアクションをラップする構造体を定義します。  

```
import (
	"context"
	"encoding/json"
	"errors"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
	"github.com/aws/smithy-go"
)

// UserWrapper encapsulates user actions used in the examples.
// It contains an IAM service client that is used to perform user actions.
type UserWrapper struct {
	IamClient *iam.Client
}



// ListUsers gets up to maxUsers number of users.
func (wrapper UserWrapper) ListUsers(ctx context.Context, maxUsers int32) ([]types.User, error) {
	var users []types.User
	result, err := wrapper.IamClient.ListUsers(ctx, &iam.ListUsersInput{
		MaxItems: aws.Int32(maxUsers),
	})
	if err != nil {
		log.Printf("Couldn't list users. Here's why: %v\n", err)
	} else {
		users = result.Users
	}
	return users, err
}



// GetUser gets data about a user.
func (wrapper UserWrapper) GetUser(ctx context.Context, userName string) (*types.User, error) {
	var user *types.User
	result, err := wrapper.IamClient.GetUser(ctx, &iam.GetUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		var apiError smithy.APIError
		if errors.As(err, &apiError) {
			switch apiError.(type) {
			case *types.NoSuchEntityException:
				log.Printf("User %v does not exist.\n", userName)
				err = nil
			default:
				log.Printf("Couldn't get user %v. Here's why: %v\n", userName, err)
			}
		}
	} else {
		user = result.User
	}
	return user, err
}



// CreateUser creates a new user with the specified name.
func (wrapper UserWrapper) CreateUser(ctx context.Context, userName string) (*types.User, error) {
	var user *types.User
	result, err := wrapper.IamClient.CreateUser(ctx, &iam.CreateUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't create user %v. Here's why: %v\n", userName, err)
	} else {
		user = result.User
	}
	return user, err
}



// CreateUserPolicy adds an inline policy to a user. This example creates a policy that
// grants a list of actions on a specified role.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper UserWrapper) CreateUserPolicy(ctx context.Context, userName string, policyName string, actions []string,
	roleArn string) error {
	policyDoc := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:   "Allow",
			Action:   actions,
			Resource: aws.String(roleArn),
		}},
	}
	policyBytes, err := json.Marshal(policyDoc)
	if err != nil {
		log.Printf("Couldn't create policy document for %v. Here's why: %v\n", roleArn, err)
		return err
	}
	_, err = wrapper.IamClient.PutUserPolicy(ctx, &iam.PutUserPolicyInput{
		PolicyDocument: aws.String(string(policyBytes)),
		PolicyName:     aws.String(policyName),
		UserName:       aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't create policy for user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// ListUserPolicies lists the inline policies for the specified user.
func (wrapper UserWrapper) ListUserPolicies(ctx context.Context, userName string) ([]string, error) {
	var policies []string
	result, err := wrapper.IamClient.ListUserPolicies(ctx, &iam.ListUserPoliciesInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't list policies for user %v. Here's why: %v\n", userName, err)
	} else {
		policies = result.PolicyNames
	}
	return policies, err
}



// DeleteUserPolicy deletes an inline policy from a user.
func (wrapper UserWrapper) DeleteUserPolicy(ctx context.Context, userName string, policyName string) error {
	_, err := wrapper.IamClient.DeleteUserPolicy(ctx, &iam.DeleteUserPolicyInput{
		PolicyName: aws.String(policyName),
		UserName:   aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete policy from user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// DeleteUser deletes a user.
func (wrapper UserWrapper) DeleteUser(ctx context.Context, userName string) error {
	_, err := wrapper.IamClient.DeleteUser(ctx, &iam.DeleteUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// CreateAccessKeyPair creates an access key for a user. The returned access key contains
// the ID and secret credentials needed to use the key.
func (wrapper UserWrapper) CreateAccessKeyPair(ctx context.Context, userName string) (*types.AccessKey, error) {
	var key *types.AccessKey
	result, err := wrapper.IamClient.CreateAccessKey(ctx, &iam.CreateAccessKeyInput{
		UserName: aws.String(userName)})
	if err != nil {
		log.Printf("Couldn't create access key pair for user %v. Here's why: %v\n", userName, err)
	} else {
		key = result.AccessKey
	}
	return key, err
}



// DeleteAccessKey deletes an access key from a user.
func (wrapper UserWrapper) DeleteAccessKey(ctx context.Context, userName string, keyId string) error {
	_, err := wrapper.IamClient.DeleteAccessKey(ctx, &iam.DeleteAccessKeyInput{
		AccessKeyId: aws.String(keyId),
		UserName:    aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete access key %v. Here's why: %v\n", keyId, err)
	}
	return err
}



// ListAccessKeys lists the access keys for the specified user.
func (wrapper UserWrapper) ListAccessKeys(ctx context.Context, userName string) ([]types.AccessKeyMetadata, error) {
	var keys []types.AccessKeyMetadata
	result, err := wrapper.IamClient.ListAccessKeys(ctx, &iam.ListAccessKeysInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't list access keys for user %v. Here's why: %v\n", userName, err)
	} else {
		keys = result.AccessKeyMetadata
	}
	return keys, err
}
```
+ API の詳細については、「*AWS SDK for Go API リファレンス*」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.AttachRolePolicy)
  + [CreateAccessKey](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateAccessKey)
  + [CreatePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreatePolicy)
  + [CreateRole](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateRole)
  + [CreateUser](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateUser)
  + [DeleteAccessKey](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteAccessKey)
  + [DeletePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeletePolicy)
  + [DeleteRole](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteRole)
  + [DeleteUser](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteUser)
  + [DeleteUserPolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteUserPolicy)
  + [DetachRolePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DetachRolePolicy)
  + [PutUserPolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.PutUserPolicy)

------
#### [ Java ]

**SDK for Java 2.x**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。
IAM ユーザーアクションをラップする関数を作成します。  

```
/*
  To run this Java V2 code example, set up your development environment, including your credentials.

  For information, see this documentation topic:

  https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html

  This example performs these operations:

  1. Creates a user that has no permissions.
  2. Creates a role and policy that grants Amazon S3 permissions.
  3. Creates a role.
  4. Grants the user permissions.
  5. Gets temporary credentials by assuming the role.  Creates an Amazon S3 Service client object with the temporary credentials.
  6. Deletes the resources.
 */

public class IAMScenario {
    public static final String DASHES = new String(new char[80]).replace("\0", "-");
    public static final String PolicyDocument = "{" +
            "  \"Version\": \"2012-10-17\"," +
            "  \"Statement\": [" +
            "    {" +
            "        \"Effect\": \"Allow\"," +
            "        \"Action\": [" +
            "            \"s3:*\"" +
            "       ]," +
            "       \"Resource\": \"*\"" +
            "    }" +
            "   ]" +
            "}";

    public static String userArn;

    public static void main(String[] args) throws Exception {

        final String usage = """

                Usage:
                    <username> <policyName> <roleName> <roleSessionName> <bucketName>\s

                Where:
                    username - The name of the IAM user to create.\s
                    policyName - The name of the policy to create.\s
                    roleName - The name of the role to create.\s
                    roleSessionName - The name of the session required for the assumeRole operation.\s
                    bucketName - The name of the Amazon S3 bucket from which objects are read.\s
                """;

        if (args.length != 5) {
            System.out.println(usage);
            System.exit(1);
        }

        String userName = args[0];
        String policyName = args[1];
        String roleName = args[2];
        String roleSessionName = args[3];
        String bucketName = args[4];

        Region region = Region.AWS_GLOBAL;
        IamClient iam = IamClient.builder()
                .region(region)
                .build();

        System.out.println(DASHES);
        System.out.println("Welcome to the AWS IAM example scenario.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println(" 1. Create the IAM user.");
        User createUser = createIAMUser(iam, userName);

        System.out.println(DASHES);
        userArn = createUser.arn();

        AccessKey myKey = createIAMAccessKey(iam, userName);
        String accessKey = myKey.accessKeyId();
        String secretKey = myKey.secretAccessKey();
        String assumeRolePolicyDocument = "{" +
                "\"Version\": \"2012-10-17\"," +
                "\"Statement\": [{" +
                "\"Effect\": \"Allow\"," +
                "\"Principal\": {" +
                "	\"AWS\": \"" + userArn + "\"" +
                "}," +
                "\"Action\": \"sts:AssumeRole\"" +
                "}]" +
                "}";

        System.out.println(assumeRolePolicyDocument);
        System.out.println(userName + " was successfully created.");
        System.out.println(DASHES);
        System.out.println("2. Creates a policy.");
        String polArn = createIAMPolicy(iam, policyName);
        System.out.println("The policy " + polArn + " was successfully created.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("3. Creates a role.");
        TimeUnit.SECONDS.sleep(30);
        String roleArn = createIAMRole(iam, roleName, assumeRolePolicyDocument);
        System.out.println(roleArn + " was successfully created.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("4. Grants the user permissions.");
        attachIAMRolePolicy(iam, roleName, polArn);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("*** Wait for 30 secs so the resource is available");
        TimeUnit.SECONDS.sleep(30);
        System.out.println("5. Gets temporary credentials by assuming the role.");
        System.out.println("Perform an Amazon S3 Service operation using the temporary credentials.");
        assumeRole(roleArn, roleSessionName, bucketName, accessKey, secretKey);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("6 Getting ready to delete the AWS resources");
        deleteKey(iam, userName, accessKey);
        deleteRole(iam, roleName, polArn);
        deleteIAMUser(iam, userName);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("This IAM Scenario has successfully completed");
        System.out.println(DASHES);
    }

    public static AccessKey createIAMAccessKey(IamClient iam, String user) {
        try {
            CreateAccessKeyRequest request = CreateAccessKeyRequest.builder()
                    .userName(user)
                    .build();

            CreateAccessKeyResponse response = iam.createAccessKey(request);
            return response.accessKey();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return null;
    }

    public static User createIAMUser(IamClient iam, String username) {
        try {
            // Create an IamWaiter object
            IamWaiter iamWaiter = iam.waiter();
            CreateUserRequest request = CreateUserRequest.builder()
                    .userName(username)
                    .build();

            // Wait until the user is created.
            CreateUserResponse response = iam.createUser(request);
            GetUserRequest userRequest = GetUserRequest.builder()
                    .userName(response.user().userName())
                    .build();

            WaiterResponse<GetUserResponse> waitUntilUserExists = iamWaiter.waitUntilUserExists(userRequest);
            waitUntilUserExists.matched().response().ifPresent(System.out::println);
            return response.user();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return null;
    }

    public static String createIAMRole(IamClient iam, String rolename, String json) {

        try {
            CreateRoleRequest request = CreateRoleRequest.builder()
                    .roleName(rolename)
                    .assumeRolePolicyDocument(json)
                    .description("Created using the AWS SDK for Java")
                    .build();

            CreateRoleResponse response = iam.createRole(request);
            System.out.println("The ARN of the role is " + response.role().arn());
            return response.role().arn();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return "";
    }

    public static String createIAMPolicy(IamClient iam, String policyName) {
        try {
            // Create an IamWaiter object.
            IamWaiter iamWaiter = iam.waiter();
            CreatePolicyRequest request = CreatePolicyRequest.builder()
                    .policyName(policyName)
                    .policyDocument(PolicyDocument).build();

            CreatePolicyResponse response = iam.createPolicy(request);
            GetPolicyRequest polRequest = GetPolicyRequest.builder()
                    .policyArn(response.policy().arn())
                    .build();

            WaiterResponse<GetPolicyResponse> waitUntilPolicyExists = iamWaiter.waitUntilPolicyExists(polRequest);
            waitUntilPolicyExists.matched().response().ifPresent(System.out::println);
            return response.policy().arn();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return "";
    }

    public static void attachIAMRolePolicy(IamClient iam, String roleName, String policyArn) {
        try {
            ListAttachedRolePoliciesRequest request = ListAttachedRolePoliciesRequest.builder()
                    .roleName(roleName)
                    .build();

            ListAttachedRolePoliciesResponse response = iam.listAttachedRolePolicies(request);
            List<AttachedPolicy> attachedPolicies = response.attachedPolicies();
            String polArn;
            for (AttachedPolicy policy : attachedPolicies) {
                polArn = policy.policyArn();
                if (polArn.compareTo(policyArn) == 0) {
                    System.out.println(roleName + " policy is already attached to this role.");
                    return;
                }
            }

            AttachRolePolicyRequest attachRequest = AttachRolePolicyRequest.builder()
                    .roleName(roleName)
                    .policyArn(policyArn)
                    .build();

            iam.attachRolePolicy(attachRequest);
            System.out.println("Successfully attached policy " + policyArn + " to role " + roleName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    // Invoke an Amazon S3 operation using the Assumed Role.
    public static void assumeRole(String roleArn, String roleSessionName, String bucketName, String keyVal,
            String keySecret) {

        // Use the creds of the new IAM user that was created in this code example.
        AwsBasicCredentials credentials = AwsBasicCredentials.create(keyVal, keySecret);
        StsClient stsClient = StsClient.builder()
                .region(Region.US_EAST_1)
                .credentialsProvider(StaticCredentialsProvider.create(credentials))
                .build();

        try {
            AssumeRoleRequest roleRequest = AssumeRoleRequest.builder()
                    .roleArn(roleArn)
                    .roleSessionName(roleSessionName)
                    .build();

            AssumeRoleResponse roleResponse = stsClient.assumeRole(roleRequest);
            Credentials myCreds = roleResponse.credentials();
            String key = myCreds.accessKeyId();
            String secKey = myCreds.secretAccessKey();
            String secToken = myCreds.sessionToken();

            // List all objects in an Amazon S3 bucket using the temp creds retrieved by
            // invoking assumeRole.
            Region region = Region.US_EAST_1;
            S3Client s3 = S3Client.builder()
                    .credentialsProvider(
                            StaticCredentialsProvider.create(AwsSessionCredentials.create(key, secKey, secToken)))
                    .region(region)
                    .build();

            System.out.println("Created a S3Client using temp credentials.");
            System.out.println("Listing objects in " + bucketName);
            ListObjectsRequest listObjects = ListObjectsRequest.builder()
                    .bucket(bucketName)
                    .build();

            ListObjectsResponse res = s3.listObjects(listObjects);
            List<S3Object> objects = res.contents();
            for (S3Object myValue : objects) {
                System.out.println("The name of the key is " + myValue.key());
                System.out.println("The owner is " + myValue.owner());
            }

        } catch (StsException e) {
            System.err.println(e.getMessage());
            System.exit(1);
        }
    }

    public static void deleteRole(IamClient iam, String roleName, String polArn) {

        try {
            // First the policy needs to be detached.
            DetachRolePolicyRequest rolePolicyRequest = DetachRolePolicyRequest.builder()
                    .policyArn(polArn)
                    .roleName(roleName)
                    .build();

            iam.detachRolePolicy(rolePolicyRequest);

            // Delete the policy.
            DeletePolicyRequest request = DeletePolicyRequest.builder()
                    .policyArn(polArn)
                    .build();

            iam.deletePolicy(request);
            System.out.println("*** Successfully deleted " + polArn);

            // Delete the role.
            DeleteRoleRequest roleRequest = DeleteRoleRequest.builder()
                    .roleName(roleName)
                    .build();

            iam.deleteRole(roleRequest);
            System.out.println("*** Successfully deleted " + roleName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    public static void deleteKey(IamClient iam, String username, String accessKey) {
        try {
            DeleteAccessKeyRequest request = DeleteAccessKeyRequest.builder()
                    .accessKeyId(accessKey)
                    .userName(username)
                    .build();

            iam.deleteAccessKey(request);
            System.out.println("Successfully deleted access key " + accessKey +
                    " from user " + username);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    public static void deleteIAMUser(IamClient iam, String userName) {
        try {
            DeleteUserRequest request = DeleteUserRequest.builder()
                    .userName(userName)
                    .build();

            iam.deleteUser(request);
            System.out.println("*** Successfully deleted " + userName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }
}
```
+ API の詳細については、「AWS SDK for Java 2.x API リファレンス**」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/PutUserPolicy)

------
#### [ JavaScript ]

**SDK for JavaScript (v3)**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3/example_code/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。
IAM ユーザーと、Amazon S3 バケットを一覧表示するアクセス権限を付与するロールを作成します。ユーザーには、ロールの引き受けのみ権限があります。ロールを引き受けた後、一時的な認証情報を使用してアカウントのバケットを一覧表示します。  

```
import {
  CreateUserCommand,
  GetUserCommand,
  CreateAccessKeyCommand,
  CreatePolicyCommand,
  CreateRoleCommand,
  AttachRolePolicyCommand,
  DeleteAccessKeyCommand,
  DeleteUserCommand,
  DeleteRoleCommand,
  DeletePolicyCommand,
  DetachRolePolicyCommand,
  IAMClient,
} from "@aws-sdk/client-iam";
import { ListBucketsCommand, S3Client } from "@aws-sdk/client-s3";
import { AssumeRoleCommand, STSClient } from "@aws-sdk/client-sts";
import { retry } from "@aws-doc-sdk-examples/lib/utils/util-timers.js";
import { ScenarioInput } from "@aws-doc-sdk-examples/lib/scenario/index.js";

// Set the parameters.
const iamClient = new IAMClient({});
const userName = "iam_basic_test_username";
const policyName = "iam_basic_test_policy";
const roleName = "iam_basic_test_role";

/**
 * Create a new IAM user. If the user already exists, give
 * the option to delete and re-create it.
 * @param {string} name
 */
export const createUser = async (name, confirmAll = false) => {
  try {
    const { User } = await iamClient.send(
      new GetUserCommand({ UserName: name }),
    );
    const input = new ScenarioInput(
      "deleteUser",
      "Do you want to delete and remake this user?",
      { type: "confirm" },
    );
    const deleteUser = await input.handle({}, { confirmAll });
    // If the user exists, and you want to delete it, delete the user
    // and then create it again.
    if (deleteUser) {
      await iamClient.send(new DeleteUserCommand({ UserName: User.UserName }));
      await iamClient.send(new CreateUserCommand({ UserName: name }));
    } else {
      console.warn(
        `${name} already exists. The scenario may not work as expected.`,
      );
      return User;
    }
  } catch (caught) {
    // If there is no user by that name, create one.
    if (caught instanceof Error && caught.name === "NoSuchEntityException") {
      const { User } = await iamClient.send(
        new CreateUserCommand({ UserName: name }),
      );
      return User;
    }
    throw caught;
  }
};

export const main = async (confirmAll = false) => {
  // Create a user. The user has no permissions by default.
  const User = await createUser(userName, confirmAll);

  if (!User) {
    throw new Error("User not created");
  }

  // Create an access key. This key is used to authenticate the new user to
  // Amazon Simple Storage Service (Amazon S3) and AWS Security Token Service (AWS STS).
  // It's not best practice to use access keys. For more information, see https://aws.amazon.com/iam/resources/best-practices/.
  const createAccessKeyResponse = await iamClient.send(
    new CreateAccessKeyCommand({ UserName: userName }),
  );

  if (
    !createAccessKeyResponse.AccessKey?.AccessKeyId ||
    !createAccessKeyResponse.AccessKey?.SecretAccessKey
  ) {
    throw new Error("Access key not created");
  }

  const {
    AccessKey: { AccessKeyId, SecretAccessKey },
  } = createAccessKeyResponse;

  let s3Client = new S3Client({
    credentials: {
      accessKeyId: AccessKeyId,
      secretAccessKey: SecretAccessKey,
    },
  });

  // Retry the list buckets operation until it succeeds. InvalidAccessKeyId is
  // thrown while the user and access keys are still stabilizing.
  await retry({ intervalInMs: 1000, maxRetries: 300 }, async () => {
    try {
      return await listBuckets(s3Client);
    } catch (err) {
      if (err instanceof Error && err.name === "InvalidAccessKeyId") {
        throw err;
      }
    }
  });

  // Retry the create role operation until it succeeds. A MalformedPolicyDocument error
  // is thrown while the user and access keys are still stabilizing.
  const { Role } = await retry(
    {
      intervalInMs: 2000,
      maxRetries: 60,
    },
    () =>
      iamClient.send(
        new CreateRoleCommand({
          AssumeRolePolicyDocument: JSON.stringify({
            Version: "2012-10-17",
            Statement: [
              {
                Effect: "Allow",
                Principal: {
                  // Allow the previously created user to assume this role.
                  AWS: User.Arn,
                },
                Action: "sts:AssumeRole",
              },
            ],
          }),
          RoleName: roleName,
        }),
      ),
  );

  if (!Role) {
    throw new Error("Role not created");
  }

  // Create a policy that allows the user to list S3 buckets.
  const { Policy: listBucketPolicy } = await iamClient.send(
    new CreatePolicyCommand({
      PolicyDocument: JSON.stringify({
        Version: "2012-10-17",
        Statement: [
          {
            Effect: "Allow",
            Action: ["s3:ListAllMyBuckets"],
            Resource: "*",
          },
        ],
      }),
      PolicyName: policyName,
    }),
  );

  if (!listBucketPolicy) {
    throw new Error("Policy not created");
  }

  // Attach the policy granting the 's3:ListAllMyBuckets' action to the role.
  await iamClient.send(
    new AttachRolePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
      RoleName: Role.RoleName,
    }),
  );

  // Assume the role.
  const stsClient = new STSClient({
    credentials: {
      accessKeyId: AccessKeyId,
      secretAccessKey: SecretAccessKey,
    },
  });

  // Retry the assume role operation until it succeeds.
  const { Credentials } = await retry(
    { intervalInMs: 2000, maxRetries: 60 },
    () =>
      stsClient.send(
        new AssumeRoleCommand({
          RoleArn: Role.Arn,
          RoleSessionName: `iamBasicScenarioSession-${Math.floor(
            Math.random() * 1000000,
          )}`,
          DurationSeconds: 900,
        }),
      ),
  );

  if (!Credentials?.AccessKeyId || !Credentials?.SecretAccessKey) {
    throw new Error("Credentials not created");
  }

  s3Client = new S3Client({
    credentials: {
      accessKeyId: Credentials.AccessKeyId,
      secretAccessKey: Credentials.SecretAccessKey,
      sessionToken: Credentials.SessionToken,
    },
  });

  // List the S3 buckets again.
  // Retry the list buckets operation until it succeeds. AccessDenied might
  // be thrown while the role policy is still stabilizing.
  await retry({ intervalInMs: 2000, maxRetries: 120 }, () =>
    listBuckets(s3Client),
  );

  // Clean up.
  await iamClient.send(
    new DetachRolePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
      RoleName: Role.RoleName,
    }),
  );

  await iamClient.send(
    new DeletePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
    }),
  );

  await iamClient.send(
    new DeleteRoleCommand({
      RoleName: Role.RoleName,
    }),
  );

  await iamClient.send(
    new DeleteAccessKeyCommand({
      UserName: userName,
      AccessKeyId,
    }),
  );

  await iamClient.send(
    new DeleteUserCommand({
      UserName: userName,
    }),
  );
};

/**
 *
 * @param {S3Client} s3Client
 */
const listBuckets = async (s3Client) => {
  const { Buckets } = await s3Client.send(new ListBucketsCommand({}));

  if (!Buckets) {
    throw new Error("Buckets not listed");
  }

  console.log(Buckets.map((bucket) => bucket.Name).join("\n"));
};
```
+ API の詳細については、「*AWS SDK for JavaScript API リファレンス*」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/AttachRolePolicyCommand)
  + [CreateAccessKey](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateAccessKeyCommand)
  + [CreatePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreatePolicyCommand)
  + [CreateRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateRoleCommand)
  + [CreateUser](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateUserCommand)
  + [DeleteAccessKey](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteAccessKeyCommand)
  + [DeletePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeletePolicyCommand)
  + [DeleteRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteRoleCommand)
  + [DeleteUser](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteUserCommand)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteUserPolicyCommand)
  + [DetachRolePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DetachRolePolicyCommand)
  + [PutUserPolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/PutUserPolicyCommand)

------
#### [ Kotlin ]

**SDK for Kotlin**  
 GitHub には、その他のリソースもあります。用例一覧を検索し、[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin/services/iam#code-examples)での設定と実行の方法を確認してください。
IAM ユーザーアクションをラップする関数を作成します。  

```
suspend fun main(args: Array<String>) {
    val usage = """
    Usage:
        <username> <policyName> <roleName> <roleSessionName> <fileLocation> <bucketName> 

    Where:
        username - The name of the IAM user to create. 
        policyName - The name of the policy to create. 
        roleName - The name of the role to create. 
        roleSessionName - The name of the session required for the assumeRole operation. 
        fileLocation - The file location to the JSON required to create the role (see Readme). 
        bucketName - The name of the Amazon S3 bucket from which objects are read. 
    """

    if (args.size != 6) {
        println(usage)
        exitProcess(1)
    }

    val userName = args[0]
    val policyName = args[1]
    val roleName = args[2]
    val roleSessionName = args[3]
    val fileLocation = args[4]
    val bucketName = args[5]

    createUser(userName)
    println("$userName was successfully created.")

    val polArn = createPolicy(policyName)
    println("The policy $polArn was successfully created.")

    val roleArn = createRole(roleName, fileLocation)
    println("$roleArn was successfully created.")
    attachRolePolicy(roleName, polArn)

    println("*** Wait for 1 MIN so the resource is available.")
    delay(60000)
    assumeGivenRole(roleArn, roleSessionName, bucketName)

    println("*** Getting ready to delete the AWS resources.")
    deleteRole(roleName, polArn)
    deleteUser(userName)
    println("This IAM Scenario has successfully completed.")
}

suspend fun createUser(usernameVal: String?): String? {
    val request =
        CreateUserRequest {
            userName = usernameVal
        }

    IamClient { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createUser(request)
        return response.user?.userName
    }
}

suspend fun createPolicy(policyNameVal: String?): String {
    val policyDocumentValue = """
    {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:*"
                ],
                "Resource": "*"
            }
        ]
    }
    """.trimIndent()

    val request =
        CreatePolicyRequest {
            policyName = policyNameVal
            policyDocument = policyDocumentValue
        }

    IamClient.fromEnvironment { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createPolicy(request)
        return response.policy?.arn.toString()
    }
}

suspend fun createRole(
    rolenameVal: String?,
    fileLocation: String?,
): String? {
    val jsonObject = fileLocation?.let { readJsonSimpleDemo(it) } as JSONObject

    val request =
        CreateRoleRequest {
            roleName = rolenameVal
            assumeRolePolicyDocument = jsonObject.toJSONString()
            description = "Created using the AWS SDK for Kotlin"
        }

    IamClient { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createRole(request)
        return response.role?.arn
    }
}

suspend fun attachRolePolicy(
    roleNameVal: String,
    policyArnVal: String,
) {
    val request =
        ListAttachedRolePoliciesRequest {
            roleName = roleNameVal
        }

    IamClient.fromEnvironment { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.listAttachedRolePolicies(request)
        val attachedPolicies = response.attachedPolicies

        // Ensure that the policy is not attached to this role.
        val checkStatus: Int
        if (attachedPolicies != null) {
            checkStatus = checkMyList(attachedPolicies, policyArnVal)
            if (checkStatus == -1) {
                return
            }
        }

        val policyRequest =
            AttachRolePolicyRequest {
                roleName = roleNameVal
                policyArn = policyArnVal
            }
        iamClient.attachRolePolicy(policyRequest)
        println("Successfully attached policy $policyArnVal to role $roleNameVal")
    }
}

fun checkMyList(
    attachedPolicies: List<AttachedPolicy>,
    policyArnVal: String,
): Int {
    for (policy in attachedPolicies) {
        val polArn = policy.policyArn.toString()

        if (polArn.compareTo(policyArnVal) == 0) {
            println("The policy is already attached to this role.")
            return -1
        }
    }
    return 0
}

suspend fun assumeGivenRole(
    roleArnVal: String?,
    roleSessionNameVal: String?,
    bucketName: String,
) {
    val stsClient = StsClient.fromEnvironment { region = "us-east-1" }
    val roleRequest =
        AssumeRoleRequest {
            roleArn = roleArnVal
            roleSessionName = roleSessionNameVal
        }

    val roleResponse = stsClient.assumeRole(roleRequest)
    val myCreds = roleResponse.credentials
    val key = myCreds?.accessKeyId
    val secKey = myCreds?.secretAccessKey
    val secToken = myCreds?.sessionToken

    val staticCredentials = StaticCredentialsProvider {
        accessKeyId = key
        secretAccessKey = secKey
        sessionToken = secToken
    }

    // List all objects in an Amazon S3 bucket using the temp creds.
    val s3 = S3Client.fromEnvironment {
        region = "us-east-1"
        credentialsProvider = staticCredentials
    }

    println("Created a S3Client using temp credentials.")
    println("Listing objects in $bucketName")

    val listObjects =
        ListObjectsRequest {
            bucket = bucketName
        }

    val response = s3.listObjects(listObjects)
    response.contents?.forEach { myObject ->
        println("The name of the key is ${myObject.key}")
        println("The owner is ${myObject.owner}")
    }
}

suspend fun deleteRole(
    roleNameVal: String,
    polArn: String,
) {
    val iam = IamClient.fromEnvironment { region = "AWS_GLOBAL" }

    // First the policy needs to be detached.
    val rolePolicyRequest =
        DetachRolePolicyRequest {
            policyArn = polArn
            roleName = roleNameVal
        }

    iam.detachRolePolicy(rolePolicyRequest)

    // Delete the policy.
    val request =
        DeletePolicyRequest {
            policyArn = polArn
        }

    iam.deletePolicy(request)
    println("*** Successfully deleted $polArn")

    // Delete the role.
    val roleRequest =
        DeleteRoleRequest {
            roleName = roleNameVal
        }

    iam.deleteRole(roleRequest)
    println("*** Successfully deleted $roleNameVal")
}

suspend fun deleteUser(userNameVal: String) {
    val iam = IamClient.fromEnvironment { region = "AWS_GLOBAL" }
    val request =
        DeleteUserRequest {
            userName = userNameVal
        }

    iam.deleteUser(request)
    println("*** Successfully deleted $userNameVal")
}

@Throws(java.lang.Exception::class)
fun readJsonSimpleDemo(filename: String): Any? {
    val reader = FileReader(filename)
    val jsonParser = JSONParser()
    return jsonParser.parse(reader)
}
```
+ API の詳細については、「*AWS SDK for Kotlin API リファレンス*」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateAccessKey](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreatePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateRole](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateUser](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteAccessKey](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeletePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteRole](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteUser](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteUserPolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DetachRolePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [PutUserPolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)

------
#### [ PHP ]

**SDK for PHP**  
 GitHub には、その他のリソースもあります。用例一覧を検索し、[AWS コードサンプルリポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php/example_code/iam#code-examples)での設定と実行の方法を確認してください。

```
namespace Iam\Basics;

require 'vendor/autoload.php';

use Aws\Credentials\Credentials;
use Aws\S3\Exception\S3Exception;
use Aws\S3\S3Client;
use Aws\Sts\StsClient;
use Iam\IAMService;

echo("\n");
echo("--------------------------------------\n");
print("Welcome to the IAM getting started demo using PHP!\n");
echo("--------------------------------------\n");

$uuid = uniqid();
$service = new IAMService();

$user = $service->createUser("iam_demo_user_$uuid");
echo "Created user with the arn: {$user['Arn']}\n";

$key = $service->createAccessKey($user['UserName']);
$assumeRolePolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Principal\": {\"AWS\": \"{$user['Arn']}\"},
                    \"Action\": \"sts:AssumeRole\"
                }]
            }";
$assumeRoleRole = $service->createRole("iam_demo_role_$uuid", $assumeRolePolicyDocument);
echo "Created role: {$assumeRoleRole['RoleName']}\n";

$listAllBucketsPolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]
}";
$listAllBucketsPolicy = $service->createPolicy("iam_demo_policy_$uuid", $listAllBucketsPolicyDocument);
echo "Created policy: {$listAllBucketsPolicy['PolicyName']}\n";

$service->attachRolePolicy($assumeRoleRole['RoleName'], $listAllBucketsPolicy['Arn']);

$inlinePolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"{$assumeRoleRole['Arn']}\"}]
}";
$inlinePolicy = $service->createUserPolicy("iam_demo_inline_policy_$uuid", $inlinePolicyDocument, $user['UserName']);
//First, fail to list the buckets with the user
$credentials = new Credentials($key['AccessKeyId'], $key['SecretAccessKey']);
$s3Client = new S3Client(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $credentials]);
try {
    $s3Client->listBuckets([
    ]);
    echo "this should not run";
} catch (S3Exception $exception) {
    echo "successfully failed!\n";
}

$stsClient = new StsClient(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $credentials]);
sleep(10);
$assumedRole = $stsClient->assumeRole([
    'RoleArn' => $assumeRoleRole['Arn'],
    'RoleSessionName' => "DemoAssumeRoleSession_$uuid",
]);
$assumedCredentials = [
    'key' => $assumedRole['Credentials']['AccessKeyId'],
    'secret' => $assumedRole['Credentials']['SecretAccessKey'],
    'token' => $assumedRole['Credentials']['SessionToken'],
];
$s3Client = new S3Client(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $assumedCredentials]);
try {
    $s3Client->listBuckets([]);
    echo "this should now run!\n";
} catch (S3Exception $exception) {
    echo "this should now not fail\n";
}

$service->detachRolePolicy($assumeRoleRole['RoleName'], $listAllBucketsPolicy['Arn']);
$deletePolicy = $service->deletePolicy($listAllBucketsPolicy['Arn']);
echo "Delete policy: {$listAllBucketsPolicy['PolicyName']}\n";
$deletedRole = $service->deleteRole($assumeRoleRole['Arn']);
echo "Deleted role: {$assumeRoleRole['RoleName']}\n";
$deletedKey = $service->deleteAccessKey($key['AccessKeyId'], $user['UserName']);
$deletedUser = $service->deleteUser($user['UserName']);
echo "Delete user: {$user['UserName']}\n";
```
+ API の詳細については、AWS SDK for PHP API リファレンスの**以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Python ]

**SDK for Python (Boto3)**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。
IAM ユーザーと、Amazon S3 バケットを一覧表示するアクセス権限を付与するロールを作成します。ユーザーには、ロールの引き受けのみ権限があります。ロールを引き受けた後、一時的な認証情報を使用してアカウントのバケットを一覧表示します。  

```
import json
import sys
import time
from uuid import uuid4

import boto3
from botocore.exceptions import ClientError


def progress_bar(seconds):
    """Shows a simple progress bar in the command window."""
    for _ in range(seconds):
        time.sleep(1)
        print(".", end="")
        sys.stdout.flush()
    print()


def setup(iam_resource):
    """
    Creates a new user with no permissions.
    Creates an access key pair for the user.
    Creates a role with a policy that lets the user assume the role.
    Creates a policy that allows listing Amazon S3 buckets.
    Attaches the policy to the role.
    Creates an inline policy for the user that lets the user assume the role.

    :param iam_resource: A Boto3 AWS Identity and Access Management (IAM) resource
                         that has permissions to create users, roles, and policies
                         in the account.
    :return: The newly created user, user key, and role.
    """
    try:
        user = iam_resource.create_user(UserName=f"demo-user-{uuid4()}")
        print(f"Created user {user.name}.")
    except ClientError as error:
        print(
            f"Couldn't create a user for the demo. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        user_key = user.create_access_key_pair()
        print(f"Created access key pair for user.")
    except ClientError as error:
        print(
            f"Couldn't create access keys for user {user.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    print(f"Wait for user to be ready.", end="")
    progress_bar(10)

    try:
        role = iam_resource.create_role(
            RoleName=f"demo-role-{uuid4()}",
            AssumeRolePolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Principal": {"AWS": user.arn},
                            "Action": "sts:AssumeRole",
                        }
                    ],
                }
            ),
        )
        print(f"Created role {role.name}.")
    except ClientError as error:
        print(
            f"Couldn't create a role for the demo. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        policy = iam_resource.create_policy(
            PolicyName=f"demo-policy-{uuid4()}",
            PolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Action": "s3:ListAllMyBuckets",
                            "Resource": "arn:aws:s3:::*",
                        }
                    ],
                }
            ),
        )
        role.attach_policy(PolicyArn=policy.arn)
        print(f"Created policy {policy.policy_name} and attached it to the role.")
    except ClientError as error:
        print(
            f"Couldn't create a policy and attach it to role {role.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        user.create_policy(
            PolicyName=f"demo-user-policy-{uuid4()}",
            PolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Action": "sts:AssumeRole",
                            "Resource": role.arn,
                        }
                    ],
                }
            ),
        )
        print(
            f"Created an inline policy for {user.name} that lets the user assume "
            f"the role."
        )
    except ClientError as error:
        print(
            f"Couldn't create an inline policy for user {user.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    print("Give AWS time to propagate these new resources and connections.", end="")
    progress_bar(10)

    return user, user_key, role


def show_access_denied_without_role(user_key):
    """
    Shows that listing buckets without first assuming the role is not allowed.

    :param user_key: The key of the user created during setup. This user does not
                     have permission to list buckets in the account.
    """
    print(f"Try to list buckets without first assuming the role.")
    s3_denied_resource = boto3.resource(
        "s3", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret
    )
    try:
        for bucket in s3_denied_resource.buckets.all():
            print(bucket.name)
        raise RuntimeError("Expected to get AccessDenied error when listing buckets!")
    except ClientError as error:
        if error.response["Error"]["Code"] == "AccessDenied":
            print("Attempt to list buckets with no permissions: AccessDenied.")
        else:
            raise


def list_buckets_from_assumed_role(user_key, assume_role_arn, session_name):
    """
    Assumes a role that grants permission to list the Amazon S3 buckets in the account.
    Uses the temporary credentials from the role to list the buckets that are owned
    by the assumed role's account.

    :param user_key: The access key of a user that has permission to assume the role.
    :param assume_role_arn: The Amazon Resource Name (ARN) of the role that
                            grants access to list the other account's buckets.
    :param session_name: The name of the STS session.
    """
    sts_client = boto3.client(
        "sts", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret
    )
    try:
        response = sts_client.assume_role(
            RoleArn=assume_role_arn, RoleSessionName=session_name
        )
        temp_credentials = response["Credentials"]
        print(f"Assumed role {assume_role_arn} and got temporary credentials.")
    except ClientError as error:
        print(
            f"Couldn't assume role {assume_role_arn}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    # Create an S3 resource that can access the account with the temporary credentials.
    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )
    print(f"Listing buckets for the assumed role's account:")
    try:
        for bucket in s3_resource.buckets.all():
            print(bucket.name)
    except ClientError as error:
        print(
            f"Couldn't list buckets for the account. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise




def teardown(user, role):
    """
    Removes all resources created during setup.

    :param user: The demo user.
    :param role: The demo role.
    """
    try:
        for attached in role.attached_policies.all():
            policy_name = attached.policy_name
            role.detach_policy(PolicyArn=attached.arn)
            attached.delete()
            print(f"Detached and deleted {policy_name}.")
        role.delete()
        print(f"Deleted {role.name}.")
    except ClientError as error:
        print(
            "Couldn't detach policy, delete policy, or delete role. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        for user_pol in user.policies.all():
            user_pol.delete()
            print("Deleted inline user policy.")
        for key in user.access_keys.all():
            key.delete()
            print("Deleted user's access key.")
        user.delete()
        print(f"Deleted {user.name}.")
    except ClientError as error:
        print(
            "Couldn't delete user policy or delete user. Here's why: "
            f"{error.response['Error']['Message']}"
        )


def usage_demo():
    """Drives the demonstration."""
    print("-" * 88)
    print(f"Welcome to the IAM create user and assume role demo.")
    print("-" * 88)
    iam_resource = boto3.resource("iam")
    user = None
    role = None
    try:
        user, user_key, role = setup(iam_resource)
        print(f"Created {user.name} and {role.name}.")
        show_access_denied_without_role(user_key)
        list_buckets_from_assumed_role(user_key, role.arn, "AssumeRoleDemoSession")
    except Exception:
        print("Something went wrong!")
    finally:
        if user is not None and role is not None:
            teardown(user, role)
        print("Thanks for watching!")


if __name__ == "__main__":
    usage_demo()
```
+ API の詳細については、「*AWS SDK for Python (Boto3) API リファレンス*」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/PutUserPolicy)

------
#### [ Ruby ]

**SDK for Ruby**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby/example_code/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。
IAM ユーザーと、Amazon S3 バケットを一覧表示するアクセス権限を付与するロールを作成します。ユーザーには、ロールの引き受けのみ権限があります。ロールを引き受けた後、一時的な認証情報を使用してアカウントのバケットを一覧表示します。  

```
# Wraps the scenario actions.
class ScenarioCreateUserAssumeRole
  attr_reader :iam_client

  # @param [Aws::IAM::Client] iam_client: The AWS IAM client.
  def initialize(iam_client, logger: Logger.new($stdout))
    @iam_client = iam_client
    @logger = logger
  end

  # Waits for the specified number of seconds.
  #
  # @param duration [Integer] The number of seconds to wait.
  def wait(duration)
    puts('Give AWS time to propagate resources...')
    sleep(duration)
  end

  # Creates a user.
  #
  # @param user_name [String] The name to give the user.
  # @return [Aws::IAM::User] The newly created user.
  def create_user(user_name)
    user = @iam_client.create_user(user_name: user_name).user
    @logger.info("Created demo user named #{user.user_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info('Tried and failed to create demo user.')
    @logger.info("\t#{e.code}: #{e.message}")
    @logger.info("\nCan't continue the demo without a user!")
    raise
  else
    user
  end

  # Creates an access key for a user.
  #
  # @param user [Aws::IAM::User] The user that owns the key.
  # @return [Aws::IAM::AccessKeyPair] The newly created access key.
  def create_access_key_pair(user)
    user_key = @iam_client.create_access_key(user_name: user.user_name).access_key
    @logger.info("Created accesskey pair for user #{user.user_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create access keys for user #{user.user_name}.")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  else
    user_key
  end

  # Creates a role that can be assumed by a user.
  #
  # @param role_name [String] The name to give the role.
  # @param user [Aws::IAM::User] The user who is granted permission to assume the role.
  # @return [Aws::IAM::Role] The newly created role.
  def create_role(role_name, user)
    trust_policy = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Principal: { 'AWS': user.arn },
        Action: 'sts:AssumeRole'
      }]
    }.to_json
    role = @iam_client.create_role(
      role_name: role_name,
      assume_role_policy_document: trust_policy
    ).role
    @logger.info("Created role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create a role for the demo. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  else
    role
  end

  # Creates a policy that grants permission to list S3 buckets in the account, and
  # then attaches the policy to a role.
  #
  # @param policy_name [String] The name to give the policy.
  # @param role [Aws::IAM::Role] The role that the policy is attached to.
  # @return [Aws::IAM::Policy] The newly created policy.
  def create_and_attach_role_policy(policy_name, role)
    policy_document = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Action: 's3:ListAllMyBuckets',
        Resource: 'arn:aws:s3:::*'
      }]
    }.to_json
    policy = @iam_client.create_policy(
      policy_name: policy_name,
      policy_document: policy_document
    ).policy
    @iam_client.attach_role_policy(
      role_name: role.role_name,
      policy_arn: policy.arn
    )
    @logger.info("Created policy #{policy.policy_name} and attached it to role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create a policy and attach it to role #{role.role_name}. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Creates an inline policy for a user that lets the user assume a role.
  #
  # @param policy_name [String] The name to give the policy.
  # @param user [Aws::IAM::User] The user that owns the policy.
  # @param role [Aws::IAM::Role] The role that can be assumed.
  # @return [Aws::IAM::UserPolicy] The newly created policy.
  def create_user_policy(policy_name, user, role)
    policy_document = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Action: 'sts:AssumeRole',
        Resource: role.arn
      }]
    }.to_json
    @iam_client.put_user_policy(
      user_name: user.user_name,
      policy_name: policy_name,
      policy_document: policy_document
    )
    puts("Created an inline policy for #{user.user_name} that lets the user assume role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create an inline policy for user #{user.user_name}. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Creates an Amazon S3 resource with specified credentials. This is separated into a
  # factory function so that it can be mocked for unit testing.
  #
  # @param credentials [Aws::Credentials] The credentials used by the Amazon S3 resource.
  def create_s3_resource(credentials)
    Aws::S3::Resource.new(client: Aws::S3::Client.new(credentials: credentials))
  end

  # Lists the S3 buckets for the account, using the specified Amazon S3 resource.
  # Because the resource uses credentials with limited access, it may not be able to
  # list the S3 buckets.
  #
  # @param s3_resource [Aws::S3::Resource] An Amazon S3 resource.
  def list_buckets(s3_resource)
    count = 10
    s3_resource.buckets.each do |bucket|
      @logger.info "\t#{bucket.name}"
      count -= 1
      break if count.zero?
    end
  rescue Aws::Errors::ServiceError => e
    if e.code == 'AccessDenied'
      puts('Attempt to list buckets with no permissions: AccessDenied.')
    else
      @logger.info("Couldn't list buckets for the account. Here's why: ")
      @logger.info("\t#{e.code}: #{e.message}")
      raise
    end
  end

  # Creates an AWS Security Token Service (AWS STS) client with specified credentials.
  # This is separated into a factory function so that it can be mocked for unit testing.
  #
  # @param key_id [String] The ID of the access key used by the STS client.
  # @param key_secret [String] The secret part of the access key used by the STS client.
  def create_sts_client(key_id, key_secret)
    Aws::STS::Client.new(access_key_id: key_id, secret_access_key: key_secret)
  end

  # Gets temporary credentials that can be used to assume a role.
  #
  # @param role_arn [String] The ARN of the role that is assumed when these credentials
  #                          are used.
  # @param sts_client [AWS::STS::Client] An AWS STS client.
  # @return [Aws::AssumeRoleCredentials] The credentials that can be used to assume the role.
  def assume_role(role_arn, sts_client)
    credentials = Aws::AssumeRoleCredentials.new(
      client: sts_client,
      role_arn: role_arn,
      role_session_name: 'create-use-assume-role-scenario'
    )
    @logger.info("Assumed role '#{role_arn}', got temporary credentials.")
    credentials
  end

  # Deletes a role. If the role has policies attached, they are detached and
  # deleted before the role is deleted.
  #
  # @param role_name [String] The name of the role to delete.
  def delete_role(role_name)
    @iam_client.list_attached_role_policies(role_name: role_name).attached_policies.each do |policy|
      @iam_client.detach_role_policy(role_name: role_name, policy_arn: policy.policy_arn)
      @iam_client.delete_policy(policy_arn: policy.policy_arn)
      @logger.info("Detached and deleted policy #{policy.policy_name}.")
    end
    @iam_client.delete_role({ role_name: role_name })
    @logger.info("Role deleted: #{role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't detach policies and delete role #{role.name}. Here's why:")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Deletes a user. If the user has inline policies or access keys, they are deleted
  # before the user is deleted.
  #
  # @param user [Aws::IAM::User] The user to delete.
  def delete_user(user_name)
    user = @iam_client.list_access_keys(user_name: user_name).access_key_metadata
    user.each do |key|
      @iam_client.delete_access_key({ access_key_id: key.access_key_id, user_name: user_name })
      @logger.info("Deleted access key #{key.access_key_id} for user '#{user_name}'.")
    end

    @iam_client.delete_user(user_name: user_name)
    @logger.info("Deleted user '#{user_name}'.")
  rescue Aws::IAM::Errors::ServiceError => e
    @logger.error("Error deleting user '#{user_name}': #{e.message}")
  end
end

# Runs the IAM create a user and assume a role scenario.
def run_scenario(scenario)
  puts('-' * 88)
  puts('Welcome to the IAM create a user and assume a role demo!')
  puts('-' * 88)
  user = scenario.create_user("doc-example-user-#{Random.uuid}")
  user_key = scenario.create_access_key_pair(user)
  scenario.wait(10)
  role = scenario.create_role("doc-example-role-#{Random.uuid}", user)
  scenario.create_and_attach_role_policy("doc-example-role-policy-#{Random.uuid}", role)
  scenario.create_user_policy("doc-example-user-policy-#{Random.uuid}", user, role)
  scenario.wait(10)
  puts('Try to list buckets with credentials for a user who has no permissions.')
  puts('Expect AccessDenied from this call.')
  scenario.list_buckets(
    scenario.create_s3_resource(Aws::Credentials.new(user_key.access_key_id, user_key.secret_access_key))
  )
  puts('Now, assume the role that grants permission.')
  temp_credentials = scenario.assume_role(
    role.arn, scenario.create_sts_client(user_key.access_key_id, user_key.secret_access_key)
  )
  puts('Here are your buckets:')
  scenario.list_buckets(scenario.create_s3_resource(temp_credentials))
  puts("Deleting role '#{role.role_name}' and attached policies.")
  scenario.delete_role(role.role_name)
  puts("Deleting user '#{user.user_name}', policies, and keys.")
  scenario.delete_user(user.user_name)
  puts('Thanks for watching!')
  puts('-' * 88)
rescue Aws::Errors::ServiceError => e
  puts('Something went wrong with the demo.')
  puts("\t#{e.code}: #{e.message}")
end

run_scenario(ScenarioCreateUserAssumeRole.new(Aws::IAM::Client.new)) if $PROGRAM_NAME == __FILE__
```
+ API の詳細については、AWS SDK for Ruby API リファレンスの**以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Rust ]

**SDK for Rust**  
 GitHub には、その他のリソースもあります。[AWS コード例リポジトリ](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/iam#code-examples)で完全な例を見つけて、設定と実行の方法を確認してください。

```
use aws_config::meta::region::RegionProviderChain;
use aws_sdk_iam::Error as iamError;
use aws_sdk_iam::{config::Credentials as iamCredentials, config::Region, Client as iamClient};
use aws_sdk_s3::Client as s3Client;
use aws_sdk_sts::Client as stsClient;
use tokio::time::{sleep, Duration};
use uuid::Uuid;

#[tokio::main]
async fn main() -> Result<(), iamError> {
    let (client, uuid, list_all_buckets_policy_document, inline_policy_document) =
        initialize_variables().await;

    if let Err(e) = run_iam_operations(
        client,
        uuid,
        list_all_buckets_policy_document,
        inline_policy_document,
    )
    .await
    {
        println!("{:?}", e);
    };

    Ok(())
}

async fn initialize_variables() -> (iamClient, String, String, String) {
    let region_provider = RegionProviderChain::first_try(Region::new("us-west-2"));

    let shared_config = aws_config::from_env().region(region_provider).load().await;
    let client = iamClient::new(&shared_config);
    let uuid = Uuid::new_v4().to_string();

    let list_all_buckets_policy_document = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]
    }"
    .to_string();
    let inline_policy_document = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"{}\"}]
    }"
    .to_string();

    (
        client,
        uuid,
        list_all_buckets_policy_document,
        inline_policy_document,
    )
}

async fn run_iam_operations(
    client: iamClient,
    uuid: String,
    list_all_buckets_policy_document: String,
    inline_policy_document: String,
) -> Result<(), iamError> {
    let user = iam_service::create_user(&client, &format!("{}{}", "iam_demo_user_", uuid)).await?;
    println!("Created the user with the name: {}", user.user_name());
    let key = iam_service::create_access_key(&client, user.user_name()).await?;

    let assume_role_policy_document = "{
        \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Principal\": {\"AWS\": \"{}\"},
                    \"Action\": \"sts:AssumeRole\"
                }]
            }"
    .to_string()
    .replace("{}", user.arn());

    let assume_role_role = iam_service::create_role(
        &client,
        &format!("{}{}", "iam_demo_role_", uuid),
        &assume_role_policy_document,
    )
    .await?;
    println!("Created the role with the ARN: {}", assume_role_role.arn());

    let list_all_buckets_policy = iam_service::create_policy(
        &client,
        &format!("{}{}", "iam_demo_policy_", uuid),
        &list_all_buckets_policy_document,
    )
    .await?;
    println!(
        "Created policy: {}",
        list_all_buckets_policy.policy_name.as_ref().unwrap()
    );

    let attach_role_policy_result =
        iam_service::attach_role_policy(&client, &assume_role_role, &list_all_buckets_policy)
            .await?;
    println!(
        "Attached the policy to the role: {:?}",
        attach_role_policy_result
    );

    let inline_policy_name = format!("{}{}", "iam_demo_inline_policy_", uuid);
    let inline_policy_document = inline_policy_document.replace("{}", assume_role_role.arn());
    iam_service::create_user_policy(&client, &user, &inline_policy_name, &inline_policy_document)
        .await?;
    println!("Created inline policy.");

    //First, fail to list the buckets with the user.
    let creds = iamCredentials::from_keys(key.access_key_id(), key.secret_access_key(), None);
    let fail_config = aws_config::from_env()
        .credentials_provider(creds.clone())
        .load()
        .await;
    println!("Fail config: {:?}", fail_config);
    let fail_client: s3Client = s3Client::new(&fail_config);
    match fail_client.list_buckets().send().await {
        Ok(e) => {
            println!("This should not run. {:?}", e);
        }
        Err(e) => {
            println!("Successfully failed with error: {:?}", e)
        }
    }

    let sts_config = aws_config::from_env()
        .credentials_provider(creds.clone())
        .load()
        .await;
    let sts_client: stsClient = stsClient::new(&sts_config);
    sleep(Duration::from_secs(10)).await;
    let assumed_role = sts_client
        .assume_role()
        .role_arn(assume_role_role.arn())
        .role_session_name(format!("iam_demo_assumerole_session_{uuid}"))
        .send()
        .await;
    println!("Assumed role: {:?}", assumed_role);
    sleep(Duration::from_secs(10)).await;

    let assumed_credentials = iamCredentials::from_keys(
        assumed_role
            .as_ref()
            .unwrap()
            .credentials
            .as_ref()
            .unwrap()
            .access_key_id(),
        assumed_role
            .as_ref()
            .unwrap()
            .credentials
            .as_ref()
            .unwrap()
            .secret_access_key(),
        Some(
            assumed_role
                .as_ref()
                .unwrap()
                .credentials
                .as_ref()
                .unwrap()
                .session_token
                .clone(),
        ),
    );

    let succeed_config = aws_config::from_env()
        .credentials_provider(assumed_credentials)
        .load()
        .await;
    println!("succeed config: {:?}", succeed_config);
    let succeed_client: s3Client = s3Client::new(&succeed_config);
    sleep(Duration::from_secs(10)).await;
    match succeed_client.list_buckets().send().await {
        Ok(_) => {
            println!("This should now run successfully.")
        }
        Err(e) => {
            println!("This should not run. {:?}", e);
            panic!()
        }
    }

    //Clean up.
    iam_service::detach_role_policy(
        &client,
        assume_role_role.role_name(),
        list_all_buckets_policy.arn().unwrap_or_default(),
    )
    .await?;
    iam_service::delete_policy(&client, list_all_buckets_policy).await?;
    iam_service::delete_role(&client, &assume_role_role).await?;
    println!("Deleted role {}", assume_role_role.role_name());
    iam_service::delete_access_key(&client, &user, &key).await?;
    println!("Deleted key for {}", key.user_name());
    iam_service::delete_user_policy(&client, &user, &inline_policy_name).await?;
    println!("Deleted inline user policy: {}", inline_policy_name);
    iam_service::delete_user(&client, &user).await?;
    println!("Deleted user {}", user.user_name());

    Ok(())
}
```
+ API の詳細については、「*AWS SDK for Rust API リファレンス*」の以下のトピックを参照してください。
  + [AttachRolePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.attach_role_policy)
  + [CreateAccessKey](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_access_key)
  + [CreatePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_policy)
  + [CreateRole](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_role)
  + [CreateUser](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_user)
  + [DeleteAccessKey](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_access_key)
  + [DeletePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_policy)
  + [DeleteRole](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_role)
  + [DeleteUser](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_user)
  + [DeleteUserPolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_user_policy)
  + [DetachRolePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.detach_role_policy)
  + [PutUserPolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.put_user_policy)

------

# Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する
<a name="id_roles_use_switch-role-ec2"></a>

Amazon EC2 インスタンスで実行されるアプリケーションはその AWS API リクエストに AWS 認証情報を含める必要があります。デベロッパーは Amazon EC2 インスタンス内に直接 AWS 認証情報を保存し、そのインスタンス内のアプリケーションに対してそれらの認証情報の使用を許可できます。しかし、デベロッパーは認証情報を管理し、その更新時には各インスタンスに安全に渡して、各 Amazon EC2 インスタンスを更新する必要があります。これは、かなりの追加作業です。

代わりに、IAM ロールを使用すると、Amazon EC2 インスタンスで実行されるアプリケーションに対して一時的な認証情報を管理するだけで済みます。ロールを使用する場合、長期認証情報 (サインイン認証情報、アクセスキーなど) を Amazon EC2 インスタンスに配布する必要はありません。代わりに、ロールは、アプリケーションが他の AWS リソースへの呼び出しを行うときに使用できる一時的なアクセス権限を提供します。Amazon EC2 インスタンスを起動するときに、そのインスタンスに関連付ける IAM ロールを指定します。そのインスタンスで実行されるアプリケーションは、そのロールから提供される一時的な認証情報を使用して API リクエストに署名できます。

ロールを使用して、Amazon EC2 インスタンスで実行されるアプリケーションに許可を付与するには、いくつかの追加設定が必要です。Amazon EC2 インスタンスで実行されるアプリケーションは、仮想化されたオペレーティングシステムによって AWS から抽象化されます。この追加の分離のため、AWS ロールとその関連付けられた許可を Amazon EC2 インスタンスに割り当て、アプリケーションに対してそれらの使用を許可するための追加の手順が必要になります。この別手順は、インスタンスにアタッチされる*[インスタンスプロファイル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)*の作成です。インスタンスプロファイルは、ロールを含んでおり、インスタンスで実行されるアプリケーションにロールの一時的な認証情報を提供できます。それらの一時的な認証情報は、アプリケーションの API コールで、リソースへのアクセスを許可するために、または、ロールで指定されたリソースのみにアクセスを制限するために使用できます。

**注記**  
同時に Amazon EC2 インスタンスに割り当てることができるのは 1 つのロールだけです。インスタンスのすべてのアプリケーションは、同じロールとアクセス許可を共有します。Amazon ECS を利用して Amazon EC2 インスタンスを管理する場合、Amazon ECS タスクが実行されている Amazon EC2 インスタンスのロールと区別できるロールを Amazon ECS タスクに割り当てることができます。各タスクにロールを割り当てることは、最小権限アクセスの原則に沿っており、アクションとリソースをよりきめ細かく制御できます。  
詳細については、Amazon Elastic Container Service ベストプラクティスガイドの「[Amazon ECS のタスクによる IAM ロールの使用](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-iam-roles.html)」を参照してください。

この方法によるロールの使用には、いくつかの利点があります。ロールの認証情報は一時的なもので、自動的に更新されるため、開発者は認証情報を管理する必要がなく、長期のセキュリティリスクを心配する必要もありません。また、複数のインスタンスに 1 つのロールを使用する場合、その 1 つのロールに変更を加えるとその変更がすべてのインスタンスに自動的に反映されます。

**注記**  
ロールは通常、起動時に Amazon EC2 インスタンスに割り当てられますが、現在実行中の Amazon EC2 インスタンスにロールをアタッチすることもできます。実行中のインスタンスにロールをアタッチする方法については、「[Amazon EC2 の IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)」を参照してください。

**Topics**
+ [

## Amazon EC2 インスタンスのロールの仕組み
](#roles-usingrole-ec2instance-roles)
+ [

## Amazon EC2 でのロールの使用に必要なアクセス許可
](#roles-usingrole-ec2instance-permissions)
+ [

## 使用を開始するには
](#roles-usingrole-ec2instance-get-started)
+ [

## 関連情報
](#roles-usingrole-ec2instance-related-info)

## Amazon EC2 インスタンスのロールの仕組み
<a name="roles-usingrole-ec2instance-roles"></a>

以下の図では、デベロッパーは Amazon EC2 インスタンスでアプリケーションを実行しており、そのアプリケーションは `amzn-s3-demo-bucket-photos` という名前の S3 バケットにアクセスする必要があります。管理者は、`Get-pics` サービスロールを作成し、Amazon EC2 インスタンスにロールをアタッチします。ロールには、指定された S3 バケットへの読み取り専用アクセスを付与するアクセス許可ポリシーが含まれています。また、Amazon EC2 インスタンスがロールを引き受けて一時的な認証情報を取得することを許可する信頼ポリシーも含まれています。アプリケーションはインスタンスで実行されると、ロールの一時的な認証情報を使用して写真バケットにアクセスできます。管理者はデベロッパーに写真バケットにアクセスする権限を与える必要はなく、デベロッパーが認証情報を共有または管理する必要はありません。

![\[AWS リソースにアクセスする Amazon EC2 インスタンス上のアプリケーション\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/roles-usingrole-ec2roleinstance.png)


1. 管理者は、**Get-pics** ロールの作成に IAM を使用します。ロールの信頼ポリシーでは、Amazon EC2 インスタンスのみがロールを引き受けることができることを指定します。ロールのアクセス許可ポリシーでは、`amzn-s3-demo-bucket-photos` バケットに対する読み取り専用アクセス許可を指定します。

1. デベロッパーは Amazon EC2 インスタンスを起動し、`Get-pics` ロールをそのインスタンスに割り当てます。
**注記**  
IAM コンソールを使用する場合、インスタンスプロファイルは自動的に管理され、ほとんど透過的です。ただし、AWS CLI または API を使用してロールと Amazon EC2 インスタンスを作成および管理する場合、インスタンスプロファイルを作成し、別の手順でそのプロファイルにロールを割り当てる必要があります。次に、インスタンスを起動するときに、ロール名ではなくインスタンスのプロファイル名を指定する必要があります。

1. 「[インスタンスメタデータからのセキュリティ認証情報の取得](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」で説明されているように、アプリケーションは実行時に Amazon EC2 [インスタンスメタデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials)からセキュリティ認証情報を取得します。これらは、ロールを表す[一時的セキュリティ認証情報](id_credentials_temp.md)で、制限された期間の間有効です 

   一部の [AWS SDK](https://aws.amazon.com/tools/) では、デベロッパーは、一時的なセキュリティ認証情報を透過的に管理するプロバイダーを使用できます (認証情報を管理するためにその SDK によってサポートされている機能については、各 AWS SDK のドキュメントを参照してください。)

   あるいは、アプリケーションは Amazon EC2 インスタンスのインスタンスメタデータから一時的な認証情報を直接取得することもできます。認証情報とその関連する値はメタデータの `iam/security-credentials/role-name` カテゴリ (この場合は `iam/security-credentials/Get-pics`) から入手できます。アプリケーションがインスタンスメタデータから認証情報を取得する場合、アプリケーションは認証情報をキャッシュすることができます。

1. 取得された一時的な認証情報を使用して、アプリケーションは写真バケットにアクセスします。**Get-pics** ロールにアタッチされたポリシーのために、アプリケーションには読み取り専用のアクセス許可があります。

   インスタンスで使用可能な一時的な認証情報は、失効前に自動的に更新されるため、有効な認証情報のセットを常に使用できます。アプリケーションは、現在の認証情報セットが失効する前に、インスタンスメタデータから新しい認証情報セットを取得するだけで済みます。AWS SDK を使用して認証情報を管理できるため、認証情報を更新するための追加のロジックをアプリケーションに含める必要がありません。たとえば、インスタンスプロファイル認証情報プロバイダーを使用してクライアントをインスタンス化します。ただし、アプリケーションがインスタンスメタデータから一時的な認証情報を取得してキャッシュしている場合、1 時間おき、または少なくとも現在のセットが失効する 15 分前までに、更新された認証情報セットを取得する必要があります。失効時刻は、`iam/security-credentials/role-name` カテゴリに返された情報に含まれます。

## Amazon EC2 でのロールの使用に必要なアクセス許可
<a name="roles-usingrole-ec2instance-permissions"></a>

ロールを割り当てたインスタンスを起動するために、デベロッパーには Amazon EC2 インスタンスを起動する許可と IAM ロールを割り当てる許可が必要です。

以下のポリシーサンプルは、ロールを使用してインスタンスを起動させるために、ユーザーに AWS マネジメントコンソール を使用することを許可します。ポリシーにアスタリスク (`*`) を含めることで、任意のロールの割り当てとリストにある Amazon EC2 アクションの実行をユーザーに許可します。`ListInstanceProfiles` アクションでは、AWS アカウント で使用できるすべてのロールの表示をユーザーに許可します。

**Example 任意のロールが割り当てられたインスタンスを Amazon EC2 コンソールで起動するアクセス許可をユーザーに付与するポリシーの例**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "IamPassRole",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "ec2.amazonaws.com"
                }
            }
        },
        {
            "Sid": "ListEc2AndListInstanceProfiles",
            "Effect": "Allow",
            "Action": [
                "iam:ListInstanceProfiles",
                "ec2:Describe*",
                "ec2:Search*",
                "ec2:Get*"
            ],
            "Resource": "*"
        }
    ]
}
```

### Amazon EC2 インスタンスに割り当て可能なロールを制限する (PassRole を使用)
<a name="roles-usingrole-ec2instance-passrole"></a>

`PassRole` 許可を使用すると、インスタンスの起動時にユーザーが Amazon EC2 インスタンスに割り当てることのできるロールを制限できます。これにより、ユーザーに付与されているアクセス許可よりも多くのアクセス許可を持つアプリケーションをユーザーが実行することを回避できます。つまり、ユーザーは、昇格されたアクセス許可を取得することができなくなります。例えば、ユーザー Alice には、Amazon EC2 インスタンスを起動し Amazon S3 バケットを操作する許可のみがあるが、このユーザーが Amazon EC2 インスタンスに割り当てるロールには、IAM と Amazon DynamoDB を操作する許可があるとします。その場合、Alice はインスタンスを起動してログインし、一時的セキュリティ認証情報を取得して、彼女にはアクセス許可がない IAM または DynamoDB アクションを実行できます。

ユーザーが Amazon EC2 インスタンスに割り当てることのできるロールを制限するには、`PassRole` アクションを許可するポリシーを作成します。その後、Amazon EC2 インスタンスを起動するユーザー (またはそのユーザーが属する IAM グループ) にそのポリシーをアタッチします。ポリシーの `Resource` の要素に、ユーザーが Amazon EC2 インスタンスに渡すことを許可するロールを記載します。ユーザーがインスタンスを起動し、そのインスタンスにロールを割り当てるとき、Amazon EC2 は、ユーザーがそのロールの割り当てを許可されているかどうかを確認します。もちろん、ユーザーが割り当てることのできるロールに想定外のアクセス権限が含まれていないことを確認する必要があります。

**注記**  
`PassRole` は、`RunInstances` や `ListInstanceProfiles` とは異なり、API アクションではありません。それは API にロールの ARN がパラメータとして渡されるときに、必ず AWS が確認を行う許可です (またはユーザーの代わりにコンソールがこれを行います)。これにより管理者は、渡すことができるロールと、そのロールを渡すことができるユーザーを制御するのに役立ちます。この場合では、ユーザーが特定のロールを Amazon EC2 インスタンスにアタッチできるようにします。

**Example 特定のロールが割り当てられた Amazon EC2 インスタンスを起動する許可をユーザーに付与するポリシーの例**  
以下のポリシーサンプルは、ロールを使用してインスタンスを起動するために、ユーザーに Amazon EC2 API の使用を許可します。`Resource` 要素は、ロールの Amazon リソースネーム (ARN) を指定します。ポリシーで ARN を指定することで、`Get-pics` ロールのみを割り当てるアクセス許可をユーザーに付与します。インスタンスの起動時にユーザーが異なるロールを指定した場合、アクションは失敗します。ユーザーには、ロールを渡したかどうかにかかわらず、すべてのインスタンスを実行する権限があります。    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:RunInstances",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::111122223333:role/Get-pics"
        }
    ]
}
```

### インスタンスプロファイルロールが他のアカウントのロールへの切り替えることを許可する
<a name="switch-role-ec2-another-account"></a>

Amazon EC2 インスタンスで実行されているアプリケーションが別のアカウントでコマンドを実行することを許可できます。これを行うには、最初のアカウントの Amazon EC2 インスタンスロールを 2 番目のアカウントのロールに切り替えることを許可する必要があります。

2 つの AWS アカウント を使用していて Amazon EC2 インスタンスで実行されているアプリケーションが両方のアカウントで [AWS CLI](https://aws.amazon.com/cli/) コマンドを実行できるようにするとします。アカウント `111111111111` に Amazon EC2 インスタンスが存在すると仮定します。このインスタンスには、同じ `abcd` アカウント内の `amzn-s3-demo-bucket1` バケットで読み取り専用の `111111111111` タスクをアプリケーションが実行する Amazon S3 インスタンスプロファイルのロールが含まれています。ただし、アプリケーションは、アカウント `amzn-s3-demo-bucket2` の `efgh` Amazon S3 バケットにアクセスするために `222222222222` クロスアカウントロールを引き受けることも許可されている必要があります。

![\[この図は、デベロッパーがロールを使用して Amazon EC2 インスタンスを起動し、Amazon S3 バケット内の写真へのアクセスを取得する方法を示しています。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/roles-instance-profile-cross-account.png)


アプリケーションが `amzn-s3-demo-bucket1` Amazon S3 バケットにアクセスできるようにするには、`abcd` Amazon EC2 インスタンスプロファイルロールは次のアクセス許可ポリシーを持っている必要があります。

***アカウント 111111111111 `abcd` ロールのアクセス許可ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket1/*",
                "arn:aws:s3:::amzn-s3-demo-bucket1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}
```

------

この `abcd` ロールは、ロールを引き受ける上で Amazon EC2 サービスを信頼する必要があります。これを行うには、`abcd` ロールは次の信頼ポリシーを持っている必要があります。

***アカウント 111111111111 `abcd`ロールの信頼ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "abcdTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"Service": "ec2.amazonaws.com"}
        }
    ]
}
```

------

`efgh` クロスアカウントのロールが、同じ `amzn-s3-demo-bucket2` アカウント内の`222222222222` バケットで読み取り専用 Amazon S3 タスクを許可すると仮定します。これを行うには、`efgh` クロスアカウントのロールは、以下のアクセス許可ポリシーを持っている必要があります。

***アカウント 222222222222 `efgh`ロールのアクセス許可ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket2/*",
                "arn:aws:s3:::amzn-s3-demo-bucket2"
            ]
        }
    ]
}
```

------

`efgh` ロールは `abcd` インスタンスプロファイルのロールがそれを引き受けることを信頼する必要があります。これを行うには、`efgh` ロールは次の信頼ポリシーを持っている必要があります。

***アカウント 222222222222 `efgh` ロールの信頼ポリシー***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}
```

------

## 使用を開始するには
<a name="roles-usingrole-ec2instance-get-started"></a>

Amazon EC2 インスタンスでロールがどのように機能するかを理解するには、IAM コンソールでロールを作成し、そのロールが割り当てられた Amazon EC2 インスタンスを起動して、実行中のインスタンスを調べる必要があります。[インスタンスのメタデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)を調べて、ロールの一時的な認証情報がインスタンスでどのようにして使用可能になったかを確認できます。また、インスタンスで実行されるアプリケーションがそのロールをどのように使用できるかも確認できます。詳細については、以下のリソースを参照してください。
+ [IAM Roles on Amazon EC2 Instances Tutorial](https://www.youtube.com/watch?v=TlCuOjviOhk) (Amazon EC2 インスタンスでの IAM ロールのチュートリアル)。リンクされている動画では、IAM ロールを Amazon EC2 インスタンスに割り当てて、インスタンスでのアプリケーション実行時に行える操作を制御する方法について説明します。この動画は、アプリケーション (AWS SDK で記述) がロールから一時的セキュリティ認証情報を取得する仕組みについて説明しています。
+ SDK ウォークスルー。AWS SDK ドキュメント内のこれらのチュートリアルでは、Amazon EC2 インスタンスで実行されるアプリケーションがロールの一時的な認証情報を使用して Amazon S3 バケットを読み取る手順について説明しています。以下の各ウォークスルーでは、別のプログラミング言語での同様の手順について説明しています。
  + [AWS SDK for Java デベロッパーガイド](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html)の*Java 用 SDK を使用した Amazon EC2 の IAM ロールの設定* 
  + 「AWS SDK for .NET デベロッパーガイド」の「[Launch an Amazon EC2 Instance using the SDK for .NET](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/run-instance.html)」
  + *AWS SDK for Ruby デベロッパーガイド*の[Ruby 用の SDK for Ruby を使用した Amazon EC2 インスタンスの作成](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/ec2-example-create-instance.html)

## 関連情報
<a name="roles-usingrole-ec2instance-related-info"></a>

ロールの作成または Amazon EC2 インスタンスのロールに関する詳細については、次の情報を参照してください。
+ [Amazon EC2 インスタンスでの IAM ロールの使用](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)の詳細については、「Amazon EC2 ユーザーガイド」を参照してください。
+ ロールの作成については、「[IAM ロールの作成](id_roles_create.md)」を参照してください。
+ 一時的なセキュリティ認証情報の使用方法の詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」を参照してください。
+ IAM API または CLI で作業する場合、IAM インスタンスプロファイルを作成および管理する必要があります。インスタンスプロファイルの詳細については、「[インスタンスプロファイルを使用する](id_roles_use_switch-role-ec2_instance-profiles.md)」を参照してください。
+ インスタンスメタデータにあるロールの一時的なセキュリティ認証情報に関する詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスメタデータからのセキュリティ認証情報の取得](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials)」を参照してください。

# インスタンスプロファイルを使用する
<a name="id_roles_use_switch-role-ec2_instance-profiles"></a>

インスタンスプロファイルを使用して、IAM ロールを EC2 インスタンスに渡します。詳細については、[Amazon EC2 ユーザーガイド](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) の「*Amazon EC2 の IAM ロール*」を参照してください。

## インスタンスプロファイルの管理 (コンソール)
<a name="instance-profiles-manage-console"></a>

AWS マネジメントコンソール を使用して Amazon EC2 のロールを作成する場合、コンソールはインスタンスプロファイルを自動的に作成し、そのインスタンスプロファイルにロールと同じ名前を付けます。IAM ロールを使用してインスタンスを起動するのに Amazon EC2 コンソールを使用する場合、インスタンスに関連付けるロールを選択できます。コンソールに表示されるリストは実際にはインスタンスプロファイル名のリストです。コンソールでは、Amazon EC2 に関連付けられていないロールのインスタンスプロファイルは作成されません。

ロールとインスタンスプロファイルの名前が同じである場合は、AWS マネジメントコンソール を使用して Amazon EC2 の IAM ロールとインスタンスプロファイルを削除できます。インスタンスプロファイルの削除の詳細については、「[ロールまたはインスタンスプロファイルを削除する](id_roles_manage_delete.md)」を参照してください。

**注記**  
インスタンスのアクセス許可を更新するには、インスタンスプロファイルを置き換えます。この変更が有効になるまでに最大 1 時間の遅延が発生するため、インスタンスプロファイルからロールを削除することはお勧めしません。

## インスタンスプロファイルの管理 (AWS CLI または AWS API)
<a name="instance-profiles-manage-cli-api"></a>

AWS CLI または AWS API からロールを管理する場合、ロールとインスタンスプロファイルを別個のアクションとして作成します。ロールとインスタンスプロファイルには異なる名前を使用できるため、インスタンスプロファイルの名前とこれらのプロファイルに含まれるロールの名前を知っている必要があります。これにより、EC2 インスタンスを起動するときに適切なインスタンスプロファイルを選択できます。

IAM リソース (インスタンスプロファイルを含む) にタグをアタッチして、それらへのアクセスを特定、整理、制御することができます。インスタンスプロファイルにタグを付けることができるのは、AWS CLI または AWS API を使用する場合のみです。

**注記**  
インスタンスプロファイルに含めることができる IAM ロールは 1 つのみです。ただし、1 つのロールを複数のインスタンスプロファイルに含めることはできます。このインスタンスプロファイルあたり 1 ロールの制限は、緩和できません。既存のロールを削除してから、別のロールをインスタンスプロファイルに追加することはできます。その後、AWS 全体で変更が反映されるのを待つ必要があります。これは[結果整合性](https://en.wikipedia.org/wiki/Eventual_consistency)のためです。変更を強制的に実行するには、[インスタンスプロファイル](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html)の関連付けを解除してから、[インスタンスプロファイルを関連付ける](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html)か、インスタンスを停止してから再起動します。

### インスタンスプロファイルの管理 (AWS CLI)
<a name="instance-profiles-manage-cli"></a>

AWS アカウントでインスタンスプロファイルを使用するには、以下の AWS CLI コマンドを使用できます。
+ インスタンスプロファイルを作成する: [https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html)
+ インスタンスプロファイルにタグを付ける: [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html)
+ インスタンスプロファイルのタグを一覧表示する: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html)
+ インスタンスプロファイルのタグを解除する: [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html)
+ ロールをインスタンスプロファイルに追加する: [https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html) 
+ インスタンスプロファイルのリストを取得する: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles.html)、[https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles-for-role.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles-for-role.html)
+ インスタンスプロファイルの情報を取得する: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-instance-profile.html) 
+ ロールをインスタンスプロファイルから削除する: [https://docs.aws.amazon.com/cli/latest/reference/iam/remove-role-from-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-role-from-instance-profile.html)
+ インスタンスプロファイルを削除する: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-instance-profile.html) 

次のコマンドを使用して、既に実行中の EC2 インスタンスにロールをアタッチすることもできます。詳細については、「[Amazon EC2 の IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)」を参照してください。
+ ロールが含まれたインスタンスプロファイルを停止中または実行中の EC2 インスタンスにアタッチする: [https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html) 
+ EC2 インスタンスにアタッチされたインスタンスプロファイルに関する情報を取得する: [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html) 
+ ロールが含まれたインスタンスプロファイルを停止中または実行中の EC2 インスタンスからデタッチする: [https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html) 

### インスタンスプロファイルの管理 (AWS API)
<a name="instance-profiles-manage-api"></a>

以下の AWS API オペレーションを呼び出して AWS アカウント のインスタンスプロファイルを使用できます。
+ インスタンスプロファイルを作成する: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html) 
+ インスタンスプロファイルにタグを付ける: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ インスタンスプロファイルのタグを一覧表示する: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ インスタンスプロファイルのタグを解除する: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ ロールをインスタンスプロファイルに追加する: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html) 
+ インスタンスプロファイルのリストを取得する: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfiles.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfiles.html)、[https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html)
+ インスタンスプロファイルの情報を取得する: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetInstanceProfile.html) 
+ ロールをインスタンスプロファイルから削除する: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html) 
+ インスタンスプロファイルを削除する: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html) 

以下のオペレーションを呼び出して、既に実行中の EC2 インスタンスにロールをアタッチすることもできます。詳細については、「[Amazon EC2 の IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)」を参照してください。
+ ロールが含まれたインスタンスプロファイルを停止中または実行中の EC2 インスタンスにアタッチする: [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html) 
+ EC2 インスタンスにアタッチされたインスタンスプロファイルに関する情報を取得する: [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeIamInstanceProfileAssociations.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeIamInstanceProfileAssociations.html) 
+ ロールが含まれたインスタンスプロファイルを停止中または実行中の EC2 インスタンスからデタッチする: [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html) 

# ID プロバイダーと AWS とのフェデレーション
<a name="id_roles_providers"></a>

ベストプラクティスとして、AWS アカウント内に個別に IAM ユーザーを作成するのではなく、ID プロバイダーとのフェデレーションを使用して AWS リソースにアクセスするように人間のユーザーに求めることをお勧めします。ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を与えることができます。これは、会社に既に企業ユーザーディレクトリなどの独自の ID システムがある場合に便利です。また、AWS リソースへのアクセスが必要なモバイルアプリやウェブアプリケーションを作成する場合にも便利です。

**注記**  
また、IAM で SAML フェデレーションを使用するのではなく、外部 SAML ID プロバイダーを使用して [IAM アイデンティティセンター](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html)で人間ユーザーを管理することもできます。IAM アイデンティティセンターを ID プロバイダーとフェデレーションすると、組織内の複数の AWS アカウントと複数の AWS アプリケーションへのアクセスをユーザーに付与できるようになります。IAM ユーザーが必要な特定の状況についての情報は、「[IAMユーザー (ロールの代わりに) を作成する場合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)」を参照してください。

IAM アイデンティティセンターを有効にすることなく AWS アカウントを 1 つだけ使用する場合は、[OpenID Connect (OIDC)](http://openid.net/connect/) または [SAML 2.0 (Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security) を使用して ID 情報を AWS に提供する外部 IdP で IAM を使用できます。OIDC は、GitHub Actions など、AWS 上で実行しないアプリケーションを AWS リソースに接続します。よく知られている SAML ID プロバイダーの例には、Shibboleth や Active Directory Federation Services があります。

ID プロバイダーを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要がありません。IdP では、これらを行うための環境が用意されています。外部ユーザーは IdP を使用してサインインします。これらの外部 ID に、アカウントの AWS リソースを使用するアクセス許可を与えることができます。ID プロバイダーは、アクセスキーなどの長期的セキュリティ認証情報をアプリケーションに配布したり組み込んだりする必要がないので、AWS アカウントの安全性の維持に役立ちます。

以下の表に、IAM フェデレーションタイプを示します。IAM、IAM アイデンティティセンター、Amazon Cognito のうち、どのタイプが自分のユースケースに最善であるか確認してください。以下の概要と表は、ユーザーが AWS リソースへのフェデレーションアクセスを取得するために使用できる方法の概略を示しています。


| IAM フェデレーションタイプ | アカウントの種類 | アクセス管理の対象 | サポートされている ID ソース | 
| --- | --- | --- | --- | 
|  IAM Identity Center とのフェデレーション  |  AWS Organizations によって管理される複数のアカウント  |  ワークフォースの人間ユーザー  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers.html)  | 
|  IAM とのフェデレーション  |  単一のスタンドアロンアカウント  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers.html)  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers.html)  | 
|  Amazon Cognito アイデンティティプールとのフェデレーション  |  いずれか  |  リソースへのアクセスに IAM 認可を必要とするアプリのユーザー  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers.html)  | 

## IAM Identity Center とのフェデレーション
<a name="id_roles_providers_identity-center"></a>

人間ユーザーの一元的なアクセス管理を行うには、[IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) を使用して、ご自分のアカウントへのアクセスと、それらのアカウント内でのアクセス許可を管理することをお勧めします。IAM Identity Center のユーザーには、AWS リソースへの短期的な認証情報が付与されます。Active Directory、外部 ID プロバイダー (IdP)、または IAM Identity Center のディレクトリを、AWS リソースへのアクセスを割り当てるユーザーおよびグループの ID ソースとして使用できます。

IAM Identity Center は、SAML (Security Assertion Markup Language) 2.0 との ID フェデレーションをサポートしています。これにより、AWS アクセスポータル内のアプリケーションの使用が許可されているユーザーに、フェデレーションシングルサインオンアクセスを提供します。それにより、ユーザーは、AWS マネジメントコンソールやサードパーティー製アプリケーション (Microsoft 365、SAP Concur、Salesforce など) を含め、SAML をサポートするサービスへのシングルサインオンが可能になります。

## IAM とのフェデレーション
<a name="id_roles_providers_iam"></a>

IAM ID センターで人間ユーザーを管理することを強くお勧めしますが、短期間の小規模デプロイで人間ユーザーに IAM によるフェデレーティッドプリンシパルのアクセスを有効にできます。IAM では、個別の SAML 2.0 および Open ID Connect (OIDC) IdP を使用し、アクセスコントロールにフェデレーティッドプリンシパル属性を使用することができます。IAM を使用すると、コストセンター、役職、ロケールなどのユーザー属性を IdP から AWS に渡し、これらの属性に基づいてきめ細かいアクセス権限を実装できます。

ワークロードとは、アプリケーションやバックエンドプロセスなど、ビジネス価値を提供するリソースやコードの集合体のことです。ワークロードでは、AWS サービス、アプリケーション、運用ツール、およびコンポーネントにリクエストを送信するために IAM ID が必要になる場合があります。これらの ID には、Amazon EC2 インスタンスや AWS Lambda 関数などの AWS 環境で実行中のマシンが含まれます。

また、アクセスを必要とする外部の関係者のマシン ID を管理することもできます。マシン ID へのアクセスを許可するには、IAM ロールを使用できます。IAM ロールは特定のアクセス許可を持ち、ロールセッションで一時的なセキュリティ認証情報に依存することで AWS にアクセスする方法を提供します。さらに、AWS 環境にアクセスする必要がある AWS の外部のマシンが含まれる場合もあります。AWS の外部で実行されるマシンには、[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用できます。ロールの詳細については、「[IAM ロール](id_roles.md)」をご参照ください。ロールを使用して AWS アカウント へのアクセス許可を委任する方法については「[IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任](tutorial_cross-account-with-roles.md)」を参照してください。

IdP を直接 IAM にリンクするには、ID プロバイダーエンティティを作成して、AWS アカウントと IdP の間に信頼関係を確立します。IAMは、[OpenID Connect (OIDC) ](http://openid.net/connect/)または [SAML 2.0 (Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security) と互換性のある IdP をサポートします。これら IdP の AWS での使用についての詳細は、以下のセクションを参照してください。
+ [OIDC フェデレーション](id_roles_providers_oidc.md)
+ [SAML 2.0 フェデレーション](id_roles_providers_saml.md)

## Amazon Cognito アイデンティティプールとのフェデレーション
<a name="id_roles_providers_cognito"></a>

Amazon Cognito は、モバイルアプリやウェブアプリでユーザーを認証および認可したい開発者向けに設計されています。Amazon Cognito ユーザープールは、アプリにサインインおよびサインアップ機能を追加します。アイデンティティプールは、AWS で管理する保護されたリソースへのアクセス権をユーザーに付与する IAM 認証情報を提供します。アイデンティティプールは、[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API オペレーションを通じて一時セッションの認証情報を取得します。

Amazon Cognito は、SAML と OpenID Connect をサポートする外部 ID プロバイダー、Facebook、Google、Amazon などのソーシャル ID プロバイダーと連携しています。アプリは、ユーザープールまたは外部 IdP を使用してユーザーをサインインさせ、IAM ロールのカスタマイズされた一時セッションを使用して、ユーザーに代わってリソースを取得できます。

## その他のリソース
<a name="id_roles_providers_additional_resources"></a>
+ 組織の認証システムを使用して AWS マネジメントコンソール へのシングルサインオン (SSO) を有効にするカスタムフェデレーションプロキシを作成する方法のデモンストレーションについては、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。

# 一般的なシナリオ
<a name="id_federation_common_scenarios"></a>

**注記**  
人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用を必須とすることをお勧めします。AWS IAM アイデンティティセンター の使用を検討したことのある場合 IAM Identity Center を使用すると、複数の AWS アカウント へのアクセスを一元的に管理できます。ユーザーには、割り当てられたすべてのアカウントに対する MFA で保護された Single Sign-On によるアクセスを、1 つの場所から提供することができます。IAM Identity Center では、 その内部でユーザー ID の作成および管理を行います。あるいは、既存の SAML 2.0 互換 ID プロバイダーにも簡単に接続することができます。詳細については、「AWS IAM アイデンティティセンター ユーザーガイド」の「[What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」(IAM Identity Center とは?) を参照してください。

外部 ID プロバイダー (IdP) を使用して、AWS と外部 IdP 外のユーザー ID を管理できます。外部 IdP は、OpenID Connect (OIDC) または Security Assertion Markup Language (SAML) のいずれかを使用して ID 情報を AWS に提供できます。OIDC は、AWS 上で実行しないアプリケーションが AWS リソースにアクセスする必要がある場合に広く使用されます。

外部 IdP サービスとの連携を設定する場合、IAM の ID プロバイダーを作成し、外部 IdP とその設定について AWS に通知します。これにより、AWS アカウント と外部 IdP の間の信頼が確立されます。以下のトピックでは、IAM ID プロバイダーを使用する一般的なシナリオについて説明します。

**Topics**
+ [

## モバイルアプリのための Amazon Cognito
](#id_roles_providers_oidc_cognito)
+ [

## モバイルアプリの OIDC フェデレーション
](#id_roles_providers_oidc_manual)

## モバイルアプリのための Amazon Cognito
<a name="id_roles_providers_oidc_cognito"></a>

OIDC フェデレーションの推奨される使い方は、[Amazon Cognito](https://aws.amazon.com/cognito/) を使用することです。たとえば、開発者の Adele は、モバイルデバイス用のゲームを開発しています。スコアやプロファイルのようなユーザーデータは Amazon S3 と Amazon DynamoDB に保存します。Adele はこのデータを 1 台のデバイスにローカルで保存して、Amazon Cognito を使って他のデバイス間で同期を取ることもできます。セキュリティおよびメンテナンス上の理由により、長期的な AWS セキュリティ認証情報をこのゲームで配布することはできません。また、このゲームが多数のユーザーを集めることもわかっています。以上のような理由から、IAM でプレーヤーごとに新しいユーザー ID を作成することはしません。代わりに、ユーザーがよく知られた外部 ID プロバイダー (IdP) (**Login with Amazon**、**Facebook**、**Google** など) や任意の **OpenID Connect** (OIDC) 互換の IdP ですでに確立した ID を使用してサインインできるようにゲームを開発します。ゲームでは、このようなプロバイダーの認証メカニズムを活用して、ユーザーの ID を検証できます。

モバイルアプリから自分の AWS リソースにアクセスできるようにするために、Adele はまず自分の選択した IdP に開発者 ID を登録します。また、これらのプロバイダーそれぞれについてアプリケーションを設定します。ゲーム用の Amazon S3 バケットおよび DynamoDB テーブルを含む AWS アカウント で、Amazon Cognito を使用して、ゲームに必要なアクセス許可を厳密に定義する IAM ロールを作成します。OIDC IdP を使用している場合は、IAM OIDC ID プロバイダーのエンティティも作成して、AWS アカウント 内の [Amazon Cognito ID プール](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html)と IdP の間に信頼を確立します。

アプリのコードでは、前の手順で設定した IdP のサインインインターフェイスを呼び出します。IdP がユーザーのサインイン操作をすべて処理し、アプリは OAuth アクセストークンまたは OIDC ID トークンをプロバイダーから取得します。アプリは、この認証情報を、AWS アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成される一時的セキュリティ認証情報のセットと交換できます。その後、アプリはこれらの認証情報を使用して、AWS によって提供されるウェブサービスにアクセスできます。アプリは、引き受けるロールで定義されているアクセス権限に制限されます。

以下の図は、この処理の流れを単純化して示しており、IdP として Login with Amazon を使用しています。ステップ 2 については、アプリで、Facebook、Google、その他の OIDC 互換 IdP を利用することもできますが、この図には示していません。

![\[Amazon Cognito を使用してモバイルアプリケーションのユーザーのフェデレーションを行うサンプルワークフロー\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/mobile-app-web-identity-federation.diagram.png)


 

1. 顧客はモバイルデバイスでアプリを起動します。アプリはユーザーにサインインするように求めます。

1. アプリは Login with Amazon を使用して、ユーザーの認証情報を承認します。

1. このアプリは Amazon Cognito API オペレーションの `GetId` と `GetCredentialsForIdentity` を使用して、Login with Amazon ID トークンを Amazon Cognito トークンに置き換えます。Login with Amazon プロジェクトを信頼するように設定されている Amazon Cognito は、一時的なセッション認証情報として AWS STS と交換するトークンを生成します。

1. このアプリで Amazon Cognito から一時的なセキュリティ認証情報を受信します。また、アプリは Amazon Cognito のベーシック (クラシック) ワークフローを使用して、`AssumeRoleWithWebIdentity` を使用する AWS STS からトークンを取得します。詳細については、「Amazon Cognito 開発者ガイド」の「[ID プール (フェデレーション ID) 認証フロー](https://docs.aws.amazon.com/cognito/latest/developerguide/authentication-flow.html)」を参照してください。

1. アプリは一時的なセキュリティ証明書を使用して、アプリの動作に必要ないずれの AWS リソースにもアクセスできます。一時的なセキュリティ証明書に関連付けられたロールとその割り当てられたポリシーによって、アクセス可能なリソースが決まります。

以下のプロセスに従って、Amazon Cognito を使用してユーザーを認証してアプリに AWS リソースに対するアクセス許可を付与するように、アプリを設定します。このシナリオを実行するための具体的な手順については、Amazon Cognito のドキュメントを参照してください。

1. (オプション) Login with Amazon、Facebook、Google、または他の任意の OpenID Connect (OIDC) 互換 IdP で開発者としてサインアップし、プロバイダーで 1 つ以上のアプリを設定します。Amazon Cognito ではユーザーの認証されていない (ゲスト) アクセスがサポートされているので、この手順はオプションです。

1. AWS マネジメントコンソール の [Amazon Cognito](https://console.aws.amazon.com/cognito/home) に移動します。Amazon Cognito ウィザードを使用して ID プールを作成します。これは、アプリのために Amazon Cognito がエンドユーザー ID を整理しておくために使用するコンテナです。ID プールは、アプリ間で共有できます。ID プールをセットアップすると、Amazon Cognito ユーザーのアクセス許可を定義する 1 つまたは 2 つの IAM ロールが Amazon Cognito によって作成されます (1 つは認証された ID 用、2 つ目は認証されていない「ゲスト」ID 用)。

1. [AWS](https://docs.amplify.aws) Amplify をアプリと統合して、Amazon Cognito の使用に必要なファイルをインポートします。

1. ID プールの ID、AWS アカウント 番号、および ID プールに関連付けたロールの Amazon リソースネーム (ARN) を渡して、Amazon Cognito 認証情報プロバイダーのインスタンスを作成します。AWS マネジメントコンソール の Amazon Cognito ウィザードによって、作業の開始に役立つサンプルコードが提供されます。

1. アプリが AWS リソースにアクセスするときに、認証情報プロバイダーインスタンスをクライアントオブジェクトに渡します。このオブジェクトが一時的なセキュリティ認証情報をクライアントに渡します。認証情報のアクセス権限は、前に定義したロールに基づいています。

詳細については次を参照してください:
+ [AWS Amplify Framework Documentation に (Android) でサインインします](https://docs.amplify.aws/lib/auth/signin/q/platform/android/)。
+ [AWS Amplify Framework Documentation に (iOS) でサインインします](https://docs.amplify.aws/lib/auth/signin/q/platform/ios/)。

## モバイルアプリの OIDC フェデレーション
<a name="id_roles_providers_oidc_manual"></a>

最良の結果を得るには、ほぼすべての OIDC フェデレーションシナリオで Amazon Cognito を認証ブローカーとして使用してください。Amazon Cognito は使いやすく、匿名 (認証されていない) アクセスのような追加機能が用意されていて、複数のデバイスおよびプロバイダーにわたってユーザーデータが同期されます。ただし、手動で `AssumeRoleWithWebIdentity` API を呼び出すことによって OIDC フェデレーションを使用するアプリを既に作成してある場合は、それを使用し続けることができます。アプリは引き続き正常に動作します。

Amazon Cognito を**使用せずに** OIDC フェデレーションを使用するプロセスは、次の一般的な概要に従います。

1. 外部 ID プロバイダー (IdP) に開発者としてサインアップし、IdP に対してアプリを設定して、アプリの一意の ID を受け取ります。（異なる IdP は、このプロセスに異なる用語を使用します。この概要では、IdP を使用してアプリを識別するプロセスに *configure (設定) * という用語を使用します。） 各 IdP からはそれぞれ固有のアプリ ID を受け取るため、複数の IdP に対して同じアプリを設定した場合、アプリには複数のアプリ ID が与えられます。プロバイダーごとに複数のアプリを設定できます。

   以下の外部リンクで、一般的ないつくかの ID プロバイダー (IdP) の利用方法に関する情報を入手できます。
   + [Login with Amazon 開発者センター](https://login.amazon.com/) 
   + Facebook 開発者サイトの「[アプリまたはウェブサイトに Facebook ログインを追加する](https://developers.facebook.com/docs/facebook-login/v2.1)」 
   + Google 開発者サイトの「[ログインでの OAuth 2.0 の使用 (OpenID Connect) ](https://developers.google.com/accounts/docs/OAuth2Login)」
**重要**  
Google、Facebook、または Amazon Cognito の OIDC IDプロバイダーを使用する場合は、AWS マネジメントコンソール に個別の IAM ID プロバイダーを作成しないでください。AWS にはこれらの OIDC IDプロバイダーが組み込まれており、使用できます。次の手順をスキップして、ID プロバイダーを使用して新しいロールの作成に直接移動します。

1. OIDC と互換性のある Google、Facebook、または Amazon Cognito 以外の IdP を使用する場合は、IAM ID プロバイダーのエンティティを作成します。

1. IAM で、[1 つ以上のロールを作成します](id_roles_create_for-idp.md)。ロールごとに、だれがそのロールを引き受けることができるか（信頼ポリシー）、アプリのユーザーがどのアクセス権限を持つか（アクセス権限ポリシー）を定義します。通常は、アプリがサポートする IdP ごとに 1 つのロールを作成します。たとえば、ユーザーが Login with Amazon を使用してサインインするアプリで想定されるロール、ユーザーが Facebook を使用してサインインする同じアプリの 2 つ目のロール、およびユーザーが Google を使用してサインインするアプリの 3 つ目のロールを作成します。信頼関係の確立用に、IdP (Amazon.com など) を `Principal` (信頼されるエンティティ) として指定し、IdP 提供のアプリ ID と一致する `Condition` を含めます。異なるプロバイダーのロールの例は、[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)で説明されています。

1. アプリケーションで、IdP に対してユーザーを認証します。この具体的な方法は、どの IdP を使用しているか (Login with Amazon、Facebook、または Google)、どのプラットフォームでアプリを実行しているかの両方によって変わります。たとえば、Android アプリと iOS アプリや JavaScript ベースのウェブアプリとでは、認証方法が異なることがあります。

   一般的に、ユーザーがまだサインインしていない場合、IdP はサインインページを表示するように対処します。IdP はユーザーを認証した後、ユーザーに関する情報と共に認証トークンをアプリに返します。含まれる情報は、IdP が公開する情報と、ユーザーが共有する情報によって異なります。この情報はアプリで利用できます。

1. アプリで、アプリで、`AssumeRoleWithWebIdentity` アクションを*署名なし*で呼び出して、一時的なセキュリティクレデンシャルをリクエストします。リクエストでは、IdP の認証トークンを渡し、その IdP 用に作成した IAM ロールの Amazon リソースネーム (ARN) を指定します。AWS は、トークンが信頼されていて有効であることを確認します。確認できた場合、リクエストで指定したロールのアクセス許可が割り当てられた一時的セキュリティ認証情報をアプリに返します。応答には、IdP がユーザーに関連付けた一意のユーザー ID など、ユーザーに関する IdP からのメタデータも含まれます。

1. `AssumeRoleWithWebIdentity` レスポンスからの一時的セキュリティ認証情報を使用して、アプリから AWS API オペレーションへの署名付きリクエストを行います。IdP からのユーザー ID 情報は、アプリ内のユーザーを区別できます。例えば、プレフィックスまたはサフィックスとしてユーザー ID を含む Amazon S3 フォルダにオブジェクトを配置できます。これにより、そのフォルダをロックするアクセス制御ポリシーを作成して、その ID を持つユーザーに対してのみフォルダへのアクセスを許可できます。詳細については、「[AWS STS フェデレーションユーザープリンシパル](reference_policies_elements_principal.md#sts-session-principals)」を参照してください。

1. アプリで一時的なセキュリティ認証情報がキャッシュに格納されるようにすることで、アプリから AWS へのリクエストがあるたびに、新しい証明書を取得する必要がなくなります。デフォルトで、認証情報は 1 時間有効です。認証情報が失効すると (または失効前に)、`AssumeRoleWithWebIdentity` を呼び出して新しい 1 組の一時的なセキュリティ認証情報を取得します。IdP とそのトークンの管理方法によっては、`AssumeRoleWithWebIdentity` を新しく呼び出す前に、IdP のトークンを更新する必要があります。IdP のトークンも通常は一定期間後に失効するためです。AWS SDK for iOS または AWS SDK for Android を使用する場合は、[AmazonSTSCredentialsProvider](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) アクションを使用できます。このアクションは IAM の一時的な認証情報を管理し、必要に応じて更新します。

# OIDC フェデレーション
<a name="id_roles_providers_oidc"></a>

ワークフローを使用して Amazon S3 や DynamoDB にアクセスする GitHub Actions などの AWS リソースにアクセスするアプリケーションを作成するとします。

このようなワークフローを作成する場合、AWS アクセスキーで署名される必要のある AWS サービスに対してリクエストを実行します。ただし、AWS 外部のアプリケーションには AWS 認証情報を長期間保存**しない**ことを**強く**お勧めします。代わりに、「OIDC フェデレーション」を使用して、必要に応じて一時的な AWS セキュリティ認証情報を動的に要求するようにアプリケーションを設定します。提供される一時的な認証情報は、アプリケーションで必要とされるタスクの実行に必要なアクセス許可のみを持つ AWS ロールにマッピングされます。

OIDC フェデレーションを使用すると、カスタムサインインコードを作成したり独自のユーザー ID を管理したりする必要はありません。代わりに、GitHub Actions などのアプリケーションやその他の [OpenID Connect (OIDC)](http://openid.net/connect/) 互換 IdP で OIDC を使用して AWS での認証を行うことができます。JSON Web トークン (JWT) として知られる認証トークンが受け取られたら、AWS アカウント の特定のリソースを使用するアクセス許可を持つ IAM ロールにマップされる AWS の一時的なセキュリティ認証情報に変換されます。IdP を使用すると、アプリケーションで長期的なセキュリティ認証情報を埋め込んで配布する必要がないため、AWS アカウント の安全性の維持に役立ちます。

OIDC フェデレーションは、マシン間認証認証 (CI/CD パイプライン、自動スクリプト、サーバーレスアプリケーションなど) とヒューマンユーザー認証の両方をサポートします。ユーザーサインアップ、サインイン、ユーザープロファイルを管理する必要があるヒューマンユーザー認証シナリオでは、[Amazon Cognito](https://aws.amazon.com/cognito/) を ID ブローカーとして使用することを検討してください。OIDC での Amazon Cognito の使用の詳細については、「[モバイルアプリのための Amazon Cognito](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito)」を参照してください。

**注記**  
OpenID Connect (OIDC) ID プロバイダーによって発行された JSON ウェブトークン (JWT) では、トークンの有効期限を指定する有効期限が `exp` クレームに含まれています。IAM は、[OpenID Connect (OIDC) Core 1.0 標準](https://openid.net/specs/openid-connect-core-1_0.html)で許可されているように、クロックスキューを考慮し、JWT で指定された有効期限を 5 分間延長します。つまり、有効期限後 5 分以内に IAM が受信した OIDC JWT は受け入れられ、評価と処理が行われます。

**Topics**
+ [

## OIDC フェデレーションに関するその他のリソース
](#id_roles_providers_oidc_resources)
+ [

# IAM で OpenID Connect (OIDC) ID プロバイダーを作成する
](id_roles_providers_create_oidc.md)
+ [

# OpenID Connect ID プロバイダーのサムプリントを取得する
](id_roles_providers_create_oidc_verify-thumbprint.md)
+ [

# 共有 OIDC プロバイダーの ID プロバイダーコントロール
](id_roles_providers_oidc_secure-by-default.md)

## OIDC フェデレーションに関するその他のリソース
<a name="id_roles_providers_oidc_resources"></a>

OIDC フェデレーションの詳細を理解するのに、次のリソースが役に立ちます。
+ [Amazon Web Services で OpenID Connect を設定](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)することによって GitHub ワークフロー内で OpenID Connect を使用します。
+ 「Android ガイド」の「Amplify ライブラリ」にある [Amazon Cognito アイデンティティ](https://docs.amplify.aws/lib/auth/advanced/q/platform/android/) および「Swift ガイド」の「Amplify ライブラリ」にある [Amazon Cognito アイデンティティ](https://docs.amplify.aws/lib/auth/advanced/q/platform/ios/)
+ クロスアカウントアクセスと外部 ID フェデレーションを安全に設定するためのガイダンスについては、AWS セキュリティブログの「[How to use external ID when granting access to your AWS resources](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/)」を参照してください。

# IAM で OpenID Connect (OIDC) ID プロバイダーを作成する
<a name="id_roles_providers_create_oidc"></a>

* IAM OIDC ID プロバイダー*は [OpenID Connect](http://openid.net/connect/) (OIDC) 標準 (例: Google または Salesforce) をサポートする ID プロバイダー (IdP) サービスを表す IAM のエンティティです。OIDC 互換 IdP と AWS アカウント の間で信頼性を確立するときに IAM OIDC ID プロバイダーを使用します。このプロバイダーは、AWS リソースへのアクセスを必要とするモバイルアプリやウェブアプリケーションを作成するときに、カスタムサインインコードの作成や独自のユーザー ID の管理をしない場合に役立ちます。このシナリオの詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。

AWS マネジメントコンソール、AWS Command Line Interface、Tools for Windows PowerShell、または IAM API を使用して、IAM OIDC ID プロバイダーを作成および管理できます。

IAM OIDC ID プロバイダーを作成したら、1 つ以上の IAM ロールを作成する必要があります。ロールは AWS のアイデンティティであり、それ自体には (ユーザーのような) 認証情報がありません。ただし、この例では組織の IdP によって認証された OIDC フェデレーティッドプリンシパルに対し、ロールは動的に割り当てられます。このロールで、組織の IdP が AWS にアクセスするための一時的なセキュリティ認証情報をリクエストできるようにします。ロールに割り当てられたポリシーにより、ユーザーが AWS で実行できることが決定されます。サードパーティー ID プロバイダーのロールを作成するには、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」をご参照ください。

**重要**  
`oidc-provider` リソースをサポートするアクションの ID ベースのポリシーを設定する場合は、IAM は指定されたパスを含む OIDC ID プロバイダーの完全な URL を評価します。OIDC ID プロバイダーの URL にパスがある場合は、そのパスを `oidc-provider` ARN に `Resource` 要素の値として含める必要があります。URL ドメインにフォワードスラッシュおよびワイルドカード (`/*`) を追加することもできます。または、URL パスの任意の時点でワイルドカード文字 (`*` および `?`) は任意の時点で使用します。リクエスト内の OIDC ID プロバイダー URL がポリシーの `Resource` 要素で設定されている値と一致しない場合、リクエストは失敗します。

IAM OIDC フェデレーションの一般的な問題をトラブルシューティングするには、AWS re:Post の [OIDC に関連するエラーの解決](https://repost.aws/knowledge-center/iam-oidc-idp-federation)に関する記事を参照してください。

**Topics**
+ [

## 前提条件: ID プロバイダーの設定を検証する
](#manage-oidc-provider-prerequisites)
+ [

## OIDC プロバイダーの作成と管理 (コンソール)
](#manage-oidc-provider-console)
+ [

## IAM OIDC ID プロバイダーの作成と管理 (AWS CLI)
](#manage-oidc-provider-cli)
+ [

## OIDC ID プロバイダーの作成と管理 (AWS API)
](#manage-oidc-provider-api)

## 前提条件: ID プロバイダーの設定を検証する
<a name="manage-oidc-provider-prerequisites"></a>

IAM OIDC ID プロバイダーを作成する前に、IdP から次の情報を取得しておく必要があります。OIDC プロバイダー設定情報を取得する方法の詳細については、IdP のドキュメントを参照してください。

1. OIDC ID プロバイダーの公開 URL を決定します。URL は「https://」で始まる必要があります。OIDC 標準によって、パスコンポーネントは許可されますが、クエリパラメータは許可されません。通常、URL は https://server.example.org や https://example.com などのホスト名のみで構成されます。URL にポート番号を含めることはできません。

1. OIDC ID プロバイダーの URL の末尾に **/.well-known/openid-configuration** を追加して、プロバイダーの公開されている設定ドキュメントとメタデータを確認します。[OpenID Connect プロバイダー検出エンドポイント URL](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) から取得できるプロバイダーの設定ドキュメントとメタデータを含む JSON 形式の検出ドキュメントが必要です。

1. プロバイダーの設定情報に次の値が含まれていることを確認します。openid-configuration にこれらのフィールドのいずれかがない場合は、検出ドキュメントを更新する必要があります。このプロセスは ID プロバイダーによって異なる可能性があるため、IdP のドキュメントに従ってこのタスクを完了してください。
   + issuer: ご使用のドメインの URL。
   + jwks\$1uri: IAM がパブリックキーを取得する JSON Web Key Set (JWKS) エンドポイント。ご使用の ID プロバイダーで、openid-configuration に JSON Web Key Set (JWKS) エンドポイントを含んでいる必要があります。この URI は、ID プロバイダーから署名付きトークンを検証するために使用されるパブリックキーを取得する場所を定義します。
**注記**  
JSON ウェブキーセット (JWKS) には少なくとも 1 つのキーを含める必要があり、最大 100 個の RSA キーと 100 個の EC キーを含めることができます。OIDC ID プロバイダーの JWKS に 100 個を超える RSA キーまたは 100 個を超える EC キーが含まれている場合、100 個のキー制限を超えるキータイプによって署名された JWT で [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API オペレーションを使用すると、`InvalidIdentityToken` 例外が返されます。例えば、JWT が RSA アルゴリズムで署名されており、プロバイダーの JWKS に 100 個を超える RSA キーがある場合、`InvalidIdentityToken` 例外が返されます。
   + claims\$1supported: OIDC フェデレーティッドプリンシパルのアクセス許可を確認するため、AWS が IAM ポリシーで使用する必要な属性が IdP からの OIDC 認証レスポンスに含まれていることを確認するために役立つユーザーに関する情報。クレームに使用できる IAM 条件キーのリストについては、「[OIDC AWS フェデレーションで使用できるキー](reference_policies_iam-condition-keys.md#condition-keys-wif)」を参照してください。
     + aud: SON Web Tokens (JWTs) で IdP の問題が発生する audience クレーム値を決定する必要があります。audience (aud) クレームはアプリケーション固有であり、トークンの受取人を識別します。OpenID Connect プロバイダーにモバイルアプリまたはウェブアプリを登録すると、アプリケーションを識別するクライアント ID が確立されます。クライアント ID は、認証のために aud クレームで渡されるアプリケーションの一意の識別子です。aud クレームは、IAM OIDC ID プロバイダーを作成するときに Audience 値と一致する必要があります。
     + iat: クレームには、ID トークンが発行された時刻を表す `iat` の値を含める必要があります。
     + iss: ID プロバイダーの URL。URL は https:// で始まり、IAM に提供されるプロバイダー URL と呼応している必要があります。OIDC 標準によって、パスコンポーネントは許可されますが、クエリパラメータは許可されません。通常、URL は https://server.example.org や https://example.com などのホスト名のみで構成されます。URL にポート番号を含めることはできません。
   + response\$1types\$1supported: id\$1token
   + subject\$1types\$1supported: public
   + id\$1token\$1signing\$1alg\$1values\$1supported: RS256、RS384、RS512、ES256、ES384、ES512
**注記**  
以下の例では、`my_custom_claim` のような追加クレームを含めることができますが、AWS STS はクレームを無視します。  

   ```
   {
     "issuer": "https://example-domain.com",
     "jwks_uri": "https://example-domain.com/jwks/keys",
     "claims_supported": [
       "aud",
       "iat",
       "iss",
       "name",
       "sub",
       "my_custom_claim"
     ],
     "response_types_supported": [
       "id_token"
     ],
     "id_token_signing_alg_values_supported": [
       "RS256",
       "RS384",
       "RS512",
       "ES256",
       "ES384",
       "ES512"
     ],
     "subject_types_supported": [
       "public"
     ]
   }
   ```

## OIDC プロバイダーの作成と管理 (コンソール)
<a name="manage-oidc-provider-console"></a>

AWS マネジメントコンソール で IAM OIDC ID プロバイダーを作成および管理するには、次の手順に従います。

**重要**  
Google、Facebook、または Amazon Cognito の OIDC ID プロバイダーを使用している場合は、この手順を使用して別の IAM ID プロバイダーを作成しないでください。これらの OIDC ID プロバイダーは、AWS にすでに組み込まれており、使用できます。代わりに、「[OpenID Connect フェデレーション用のロールを作成する (コンソール）](id_roles_create_for-idp_oidc.md)」の手順に従って ID プロバイダーの新しいロールを作成します。

**IAM OIDC ID プロバイダーを作成するには (コンソール)**

1. <a name="idpoidcstep1"></a>IAM OIDC ID プロバイダーを作成する前に、アプリケーションを IdP に登録して*クライアント ID *を受け取る必要があります。クライアント ID (*対象者*とも呼ばれます) は、アプリを IdP に登録したときに発行されるアプリの一意の識別子です。クライアント ID を取得する方法の詳細については、IdP のドキュメントを参照してください。
**注記**  
AWS は、JSON Web Key Set (JWKS) エンドポイントの TLS 証明書を検証する信頼されたルート認証機関 (CA) のライブラリを使用して、OIDC ID プロバイダー (IdP) との通信を保護します。ご使用の OIDC IdP がこれらの信頼された CA のいずれかによる署名を受けていない証明書を信頼する場合、その IdP の設定で指定されたサムプリントを使用して通信を保護します。TLS 証明書を取得できない場合、または TLS v1.3 が必要な場合は、AWS はサムプリントの検証にフォールバックします。

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで、[**Identity providers**] (ID プロバイダ) を選択し、[**Add provider**] (プロバイダを追加) を選択します。

1. [**Configure provider**] (プロバイダーの設定) で、[**OpenID Connect**] を選択します。

1. [**プロバイダーの URL**] には IdP の URL を入力します。URL は次の制限に準拠する必要があります。
   + URL では大文字と小文字は区別されます。
   + URL は **https://** で始まる必要があります。
   + URL にポート番号を含めることはできません。
   + AWS アカウント 内で、各 IAM OIDC ID プロバイダーは一意の URL を使用する必要があります。AWS アカウント で OpenID Connect プロバイダーで既に使用されている URL を送信しようとすると、エラーが発生します。

1. **[対象者]** には、IdP に登録して [Step 1](#idpoidcstep1) で受け取ったアプリケーションのクライアント ID を入力します。このアプリケーションは AWS に対するリクエストを実行します。この IdP のクライアント ID (*対象者*) が他にも存在する場合は、後でプロバイダーの詳細ページで追加できます。
**注記**  
IdP JWT トークンに `azp` クレームが含まれている場合は、Audience 値としてこの値を入力します。  
OIDC ID プロバイダーがトークンに `aud` と `azp` の両方のクレームを設定している場合、AWS STS は `azp` クレーム内の値を `aud` クレームとして使用します。

1. (オプション) [**Add tags (タグの追加)**] では、キーバリューのペアを追加して IdP の特定と整理を行うことができます。タグを使用して、AWS リソースへのアクセスを制御することもできます。IAM OIDC ID プロバイダーのタグ付けの詳細については、「[OpenID Connect (OIDC) ID プロバイダーにタグ付けする](id_tags_oidc.md)」を参照してください。**[タグを追加]** を選択します。タグキーバリューのペアごとに値を入力します。

1. 入力した情報を確認します。完了したら、[**Add provider**] (プロバイダーを追加) を選択します。IAM は、OIDC IdP サーバー証明書の上位中間 CA サムプリントを取得して使用し、IAM OIDC ID プロバイダーを作成しようとします。
**注記**  
OIDC ID プロバイダーの証明書チェーンは、ドメインまたは発行者の URL で始まり、中間証明書が続いた後、ルート証明書で終わる必要があります。証明書チェーンの順序が異なる場合、または証明書の重複や追加が含まれる場合は、署名の不一致エラーが表示され、STS は JSON ウェブトークン (JWT) の検証に失敗します。エラーを解決するには、サーバーから返されたチェーン内の証明書の順序を修正します。証明書チェーン標準の詳細については、RFC Series ウェブサイトの [RFC 5246 の certificate\$1list](https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2) を参照してください。

1. ID プロバイダーに IAM ロールを割り当てて、ID プロバイダーによって管理される外部ユーザー ID にアカウント内の AWS リソースへのアクセス許可を与えます。ID フェデレーション用のロールの作成の詳細については、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」をご参照ください。
**注記**  
ロール信頼ポリシーで使用される OIDC IdP は、そのロール信頼ポリシーを信頼するロールと同じアカウントにある必要があります。

**IAM OIDC ID プロバイダーのサムプリントを追加または削除するには (コンソール)**
**注記**  
AWS は、JSON Web Key Set (JWKS) エンドポイントの TLS 証明書を検証する信頼されたルート認証機関 (CA) のライブラリを使用して、OIDC ID プロバイダー (IdP) との通信を保護します。ご使用の OIDC IdP がこれらの信頼された CA のいずれかによる署名を受けていない証明書を信頼する場合、その IdP の設定で指定されたサムプリントを使用して通信を保護します。TLS 証明書を取得できない場合、または TLS v1.3 が必要な場合は、AWS はサムプリントの検証にフォールバックします。

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで、**[ID プロバイダー]** を選択します。その後、更新する IAM ID プロバイダーの名前を選択します。

1. **[エンドポイント検証]** タブを選択し、**[サムプリント]** セクションで **[管理]** を選択します。新しいサムプリント値を入力するには、[**Add thumbprint**] (サムプリントを追加) を選択します。サムプリントを削除するには、削除するサムプリントの横にある [**Remove**] (削除) を選択します。
**注記**  
IAM OIDC ID プロバイダーには少なくとも 1 つのサムプリントが必要であり、最大 5 つのサムプリントを指定できます。

    完了したら、**[Save changes]** (変更を保存) を選択します。

**IAM OIDC ID プロバイダーの対象者を追加するには (コンソール)**

1. ナビゲーションペインで、[**Identity providers**] (ID プロバイダー) を選択し、更新する IAM ID プロバイダーの名前を選択します。

1. **[対象者]** セクションで **[アクション]** を選択し、**[対象者を追加]** を選択します。

1. IdP に登録して [Step 1](#idpoidcstep1) で受け取ったアプリケーションのクライアント ID を入力します。このアプリケーションは AWS に対するリクエストを実行します。その後、**[対象者を追加]** を選択します。
**注記**  
IAM OIDC ID プロバイダーには少なくとも 1 名の閲覧者が必要であり、最大 100 名まで指定できます。

**IAM OIDC ID プロバイダーの対象者を削除するには (コンソール)**

1. ナビゲーションペインで、**[ID プロバイダー]** を選択し、更新する IAM ID プロバイダーの名前を選択します。

1. **[対象者]** セクションで、削除する対象者の横にあるラジオボタンを選択し、**[アクション]** を選択します。

1.  **[対象者を削除]** を選択します。新しいウィンドウが開きます。

1. 対象者を削除すると、対象者とフェデレートする ID は対象者に関連付けられたロールを引き受けることができません。ウィンドウで、警告を読み、フィールドに単語 `remove` を入力して対象者を削除することを確認します。

1. 対象者を削除するには、**[削除]** を選択します。

**IAM OIDC ID プロバイダーを削除するには (コンソール)**

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで、**[ID プロバイダー]** を選択します。

1. 削除する IAM ID プロバイダーの横にあるチェックボックスをオンにします。新しいウィンドウが開きます。

1. フィールドに単語 `delete` を入力して、プロバイダーを削除することを確認します。その後、**[削除]** をクリックします。

## IAM OIDC ID プロバイダーの作成と管理 (AWS CLI)
<a name="manage-oidc-provider-cli"></a>

以下の AWS CLI コマンドを使用して IAM OIDC ID プロバイダーを作成および管理できます。

**IAM OIDC ID プロバイダーを作成するには (AWS CLI)**

1. (オプション) AWS アカウントのすべての IAM OIDC ID プロバイダーを一覧表示するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. 新しい IAM OIDC ID プロバイダーを作成するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/create-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-open-id-connect-provider.html)

**既存の IAM OIDC ID プロバイダー (AWS CLI) のサーバー証明書のサムプリントのリストを更新するには**
+ IAM OIDC ID プロバイダーのサーバー証明書のサムプリントのリストを更新するには、次のコマンドを実行します。
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/update-open-id-connect-provider-thumbprint.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-open-id-connect-provider-thumbprint.html)

**既存の IAM OIDC ID プロバイダー (AWS CLI) にタグを付けるには**
+ 既存の IAM OIDC ID プロバイダーにタグを付けるには、次のコマンドを実行します。
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html)

**既存の IAM OIDC ID プロバイダー (AWS CLI) のタグを一覧表示するには**
+ 既存の IAM OIDC ID プロバイダーのタグを一覧表示するには、次のコマンドを実行します。
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html)

**IAM OIDC ID プロバイダー (AWS CLI) のタグを削除するには**
+ 既存の IAM OIDC ID プロバイダーのタグを削除、次のコマンドを実行します。
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html)

**既存のIAM OIDC ID プロバイダーのクライアント ID を追加または削除するには (AWS CLI)**

1. (オプション) AWS アカウントのすべての IAM OIDC ID プロバイダーのリストを取得するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. (オプション) IAM OIDC ID プロバイダーの詳細情報を取得するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html)

1. 既存の IAM OIDC ID プロバイダーに新しいクライアント ID を追加するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/add-client-id-to-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/add-client-id-to-open-id-connect-provider.html)

1. 既存の IAM OIDC ID プロバイダーからクライアント ID を削除するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/remove-client-id-from-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-client-id-from-open-id-connect-provider.html)

**IAM OIDC ID プロバイダーを削除するには (AWS CLI)**

1. (オプション) AWS アカウントのすべての IAM OIDC ID プロバイダーのリストを取得するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. (オプション) IAM OIDC ID プロバイダーの詳細情報を取得するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html)

1. IAM OIDC ID プロバイダーを削除するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html)

## OIDC ID プロバイダーの作成と管理 (AWS API)
<a name="manage-oidc-provider-api"></a>

以下の IAM API コマンドを使用して OIDC プロバイダーを作成および管理できます。

**IAM OIDC ID プロバイダーを作成するには (AWS API)**

1. (オプション) AWS アカウントのすべての IAM OIDC ID プロバイダーのリストを取得するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. 新しい IAM OIDC ID プロバイダーを作成するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html)

**既存の IAM OIDC ID プロバイダーのサーバー証明書のサムプリントのリストを更新するには (AWS API)**
+ IAM OIDC ID プロバイダーのサーバー証明書のサムプリントのリストを更新するには、次のオペレーションを呼び出します。
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateOpenIDConnectProviderThumbprint.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateOpenIDConnectProviderThumbprint.html)

**既存の IAM OIDC ID プロバイダーにタグを付けるには (AWS API)**
+ 既存の IAM OIDC ID プロバイダーにタグを付けるには、次のオペレーションを呼び出します。
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html)

**既存の IAM OIDC ID プロバイダーのタグを一覧表示するには (AWS API)**
+ 既存の IAM OIDC ID プロバイダーのタグを一覧表示するには、次のオペレーションを呼び出します。
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html)

**既存の IAM OIDC ID プロバイダーのタグを削除するには (AWS API)**
+ 既存の IAM OIDC ID プロバイダーのタグを削除するには、次のオペレーションを呼び出します。
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html)

**既存の IAM OIDC ID プロバイダーのクライアント ID を追加または削除するには (AWS API)**

1. (オプション) AWS アカウントのすべての IAM OIDC ID プロバイダーのリストを取得するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. (オプション) IAM OIDC ID プロバイダーの詳細情報を取得するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html)

1. 既存の IAM OIDC ID プロバイダーに新しいクライアント ID を追加するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddClientIDToOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddClientIDToOpenIDConnectProvider.html)

1. 既存の IAM OIDC ID プロバイダーからクライアント ID を削除するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveClientIDFromOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveClientIDFromOpenIDConnectProvider.html)

**IAM OIDC ID プロバイダーを削除するには (AWS API)**

1. (オプション) AWS アカウントのすべての IAM OIDC ID プロバイダーのリストを取得するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. (オプション) IAM OIDC ID プロバイダーの詳細情報を取得するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html)

1. IAM OIDC ID プロバイダーを削除するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteOpenIDConnectProvider.html)

# OpenID Connect ID プロバイダーのサムプリントを取得する
<a name="id_roles_providers_create_oidc_verify-thumbprint"></a>

IAM で [OpenID Connect (OIDC) ID プロバイダーを作成する](id_roles_providers_create_oidc.md) 場合は、IAM では、外部 ID プロバイダー (IdP) が使用する証明書に署名した最上位の中間認証局 (CA) のサムプリントが必要です。拇印は、OIDC 互換 IdPの証明書を発行するために使用された CAの 証明書の署名です。IAM の OIDC ID プロバイダーを作成する場合、その IdP からの ID を信頼し、AWS アカウント へのアクセス権限を与えることになります。CA の証明書のサムプリントを使用することにより、CA によって発行された証明書を、登録されているものと同じ DNS 名で信頼します。これにより、IdP の署名証明書を更新したときに各アカウントの信頼を更新する必要がなくなります。

**重要**  
ほとんどの場合、フェデレーションサーバーは 2 つの異なる証明書を使用します。  
1 つ目は、AWS と IdP との間に HTTPS 接続を確立します。この証明書は、AWS Certificate Manager などのよく知られたパブリックルート CA で発行されています。これにより、クライアントは証明書の信頼性とステータスを確認できます。
2 つ目はトークンの暗号化に使用され、プライベートまたはパブリックのルート CA によって署名されているはずです。

IAM OIDC IDプロバイダーは、[AWS Command Line Interface、Tools for Windows PowerShell、またはIAM API ](id_roles_providers_create_oidc.md#manage-oidc-provider-cli)を使用して作成できます これらの方法を使用する場合、サムプリントを手動で指定できます。サムプリントを含めない場合、IAM は OIDC IdP サーバー証明書の最上位中間 CA サムプリントを取得します。サムプリントを含める場合は、サムプリントを手動で取得して AWS に提供する必要があります。

[IAM コンソール](id_roles_providers_create_oidc.md) を使用して OIDC ID プロバイダーを作成すると、IAM は、OIDC IdP サーバー証明書の最上位中間 CA サムプリントの取得を試みます。

あわせて、OIDC IdP のサムプリントを手動で取得し、IAM で正しいサムプリントが取得されていることを確認することをお勧めします。証明書のサムプリントの取得の詳細については、以下のセクションを参照してください。

**注記**  
AWS は、JSON Web Key Set (JWKS) エンドポイントの TLS 証明書を検証する信頼されたルート認証機関 (CA) のライブラリを使用して、OIDC ID プロバイダー (IdP) との通信を保護します。ご使用の OIDC IdP がこれらの信頼された CA のいずれかによる署名を受けていない証明書を信頼する場合、その IdP の設定で指定されたサムプリントを使用して通信を保護します。TLS 証明書を取得できない場合、または TLS v1.3 が必要な場合は、AWS はサムプリントの検証にフォールバックします。

## 証明書サムプリントを取得する
<a name="oidc-obtain-thumbprint"></a>

OIDC プロバイダーの証明書サムプリントを取得するには、ウェブブラウザと OpenSSL コマンドラインツールを使用します。ただし、IAM OIDC ID プロバイダーを作成するために証明書のサムプリントを手動で取得する必要はありません。次の手順を使用して、OIDC プロバイダーの証明書サムプリントを取得できます。

**OIDC IdP のサムプリントを取得するには**

1. OIDC IdP のサムプリントを取得する前に、OpenSSL コマンドラインツールを取得する必要があります。このツールを使用して、OIDC IdP の証明書チェーンをダウンロードし、証明書チェーンで最終的な証明書のサムプリントを作成します。OpenSSL のインストールと設定が必要な場合は、「[OpenSSL のインストール](#oidc-install-openssl)」および「[OpenSSL の設定](#oidc-configure-openssl)」の手順に従います。

1. 次のように、OIDC IdP の URL (`https://server.example.com` など) で開始し、`/.well-known/openid-configuration` を追加して IdP の設定ドキュメントの URL (以下参照) を作成します。

   **https://*server.example.com*/.well-known/openid-configuration**

   この URL をウェブブラウザで開き、*server.example.com* を IdP のサーバー名に置き換えます。

1. <a name="thumbstep2"></a>表示されたドキュメントで、ウェブブラウザを使用します。**検索**機能を使用して、テキスト `"jwks_uri"` を検索します。テキスト `"jwks_uri"` の直後のコロン (:) の後に URL があります。URL の完全修飾ドメイン名をコピーします。`https://` または最上位ドメインより後のパスは含めないでください。

   ```
   {
    "issuer": "https://accounts.example.com",
    "authorization_endpoint": "https://accounts.example.com/o/oauth2/v2/auth",
    "device_authorization_endpoint": "https://oauth2.exampleapis.com/device/code",
    "token_endpoint": "https://oauth2.exampleapis.com/token",
    "userinfo_endpoint": "https://openidconnect.exampleapis.com/v1/userinfo",
    "revocation_endpoint": "https://oauth2.exampleapis.com/revoke",
    "jwks_uri": "https://www.exampleapis.com/oauth2/v3/certs",
   ...
   ```

1. OpenSSL コマンドラインツールを使用して、次のコマンドを実行します。*keys.example.com* を、[Step 3](#thumbstep2) で取得したドメイン名に置き換えます。

   ```
   openssl s_client -servername keys.example.com -showcerts -connect keys.example.com:443
   ```

1. コマンドウィンドウで、次の例のような証明書が表示されるまでスクロールアップします。複数の証明書が表示される場合は、表示される最後 (コマンド出力の最後) の証明書を見つけます。これには認証機関チェーンの最上位中間 CA の証明書が含まれています。

   ```
   -----BEGIN CERTIFICATE-----
    MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
    VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
    b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
    BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
    MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
    VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
    b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
    YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
    21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
    rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
    Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
    nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
    FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
    NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE=
    -----END CERTIFICATE-----
   ```

   証明書 (`-----BEGIN CERTIFICATE-----` および `-----END CERTIFICATE-----` 行を含む) をコピーして、テキストファイルに貼り付けます。次に、**certificate.crt** という名前でファイルを保存します。
**注記**  
OIDC ID プロバイダーの証明書チェーンは、ドメインまたは発行者 URL で始まり、中間証明書 (存在する場合) が含まれ、ルート証明書で終わる必要があります。証明書チェーンの順序が異なる場合、または証明書の重複や追加が含まれる場合は、署名の不一致エラーが表示され、STS は JSON ウェブトークン (JWT) の検証に失敗します。エラーを解決するには、サーバーから返されたチェーン内の証明書の順序を修正します。証明書チェーン標準の詳細については、RFC Series ウェブサイトの [RFC 5246 の certificate\$1list](https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2) を参照してください。

1. OpenSSL コマンドラインツールを使用して、次のコマンドを実行します。

   ```
   openssl x509 -in certificate.crt -fingerprint -sha1 -noout
   ```

   コマンドウィンドウには、次の例のような証明書サムプリントが表示されます。

   ```
   SHA1 Fingerprint=99:0F:41:93:97:2F:2B:EC:F1:2D:DE:DA:52:37:F9:C9:52:F2:0D:9E
   ```

   この文字列からコロン（:）を削除して、次のような最終的なサムプリントを作成します。

   ```
   990F4193972F2BECF12DDEDA5237F9C952F20D9E
   ```

1. AWS CLI を使用して IAM OIDC ID プロバイダーを作成する場合は、Windows PowerShell 用ツール、または IAM API では、サムプリントの提供は任意です。作成時にサムプリントを含めない場合、IAM は OIDC IdP サーバー証明書の最上位中間 CA サムプリントを取得します。IAM OIDC ID プロバイダーを作成したら、このサムプリントを IAM によって取得されたサムプリントと比較できます。

   IAM コンソールで IAM OIDC ID プロバイダーを作成する場合、コンソールは OIDC IdP サーバー証明書の上位中間 CA サムプリントの取得を試みます。このサムプリントを IAM によって取得されたサムプリントと比較できます。IAM OIDC ID プロバイダーが作成されたら、OIDC プロバイダーの **[概要]** コンソールページの **[エンドポイント検証]** タブで IAM OIDC ID プロバイダーのサムプリントを表示できます。
**重要**  
取得したサムプリントが、IAM OIDC ID プロバイダーに表示されるサムプリントに一致しない場合は、その OIDC プロバイダーを作成しないでください。代わりに、作成した OIDC プロバイダーを削除してから、しばらく待ってから OIDC プロバイダーの作成を再試行してください。プロバイダーを使用する前に、サムプリントが一致していることを確認します。再試行してもサムプリントが一致しない場合は、[IAM フォーラム](https://forums.aws.amazon.com/forum.jspa?forumID=76)を使用して AWS にお問い合わせください。

## OpenSSL のインストール
<a name="oidc-install-openssl"></a>

まだ OpenSSL がインストールされていない場合は、このセクションの手順に従います。

**Linux または Unix で OpenSSL をインストールするには**

1. [OpenSSL: ソース、Tarballs](https://openssl.org/source/)(https://openssl.org/source/) にアクセスします。

1. 最新のソースをダウンロードし、パッケージを構築します。

**Windows へ OpenSSL をインストールするには**

1. [OpenSSL: バイナリディストリビューション](https://wiki.openssl.org/index.php/Binaries)(https://wiki.openssl.org/index.php/Binaries) にアクセスして、Windows バージョンをインストールできるサイトの一覧を参照してください。

1. 選択したサイトの指示に従って、インストールを開始します。

1. **Microsoft Visual C\$1\$1 2008 再頒布可能パッケージ**をインストールするように求められ、それがまだシステムにインストールされていない場合は、ご使用の環境に適したダウンロードリンクを選択してください。「**Microsoft Visual C\$1\$1 2008 再配布可能セットアップウィザード**」の指示に従ってください。
**注記**  
Microsoft Visual C\$1\$1 2008 再頒布可能ファイルがシステムに既にインストールされているかどうかわからない場合は、最初に OpenSSL をインストールしてみてください。Microsoft Visual C\$1\$1 2008 再頒布可能ファイルがまだインストールされていない場合、OpenSSL インストーラーに警告が表示されます。インストールする OpenSSL のバージョンと一致するアーキテクチャ (32 ビットまたは 64 ビット) をインストールすることを確認します。

1. Microsoft Visual C\$1\$1 2008 再頒布可能ファイルをインストールしたら、ご使用の環境に適したバージョンの OpenSSL バイナリを選択し、ファイルをローカルに保存します。**OpenSSL のセットアップウィザード**を起動します。

1. 「**OpenSSL のセットアップウィザード**」の指示に従ってください。

## OpenSSL の設定
<a name="oidc-configure-openssl"></a>

OpenSSL コマンドを使用する前に、OpenSSL がインストールされている場所に関する情報が含まれるように、オペレーティングシステムを構成する必要があります。

**Linux または Unix で OpenSSL を設定するには**

1. コマンドラインで、`OpenSSL_HOME` 変数を OpenSSL のインストール場所に設定します。

   ```
   $ export OpenSSL_HOME=path_to_your_OpenSSL_installation
   ```

1. OpenSSL インストールを含めるパスを設定します。

   ```
   $ export PATH=$PATH:$OpenSSL_HOME/bin
   ```
**注記**  
`export` コマンドを使用して環境変数に加えた変更は、現在のセッションでのみ有効です。環境変数をシェル設定ファイルで設定することで、環境変数に永続的な変更を加えることができます。詳細については、「インスタンスのオペレーティングシステムに関するドキュメント」を参照してください。

**Windows での OpenSSL を設定するには**

1. [**コマンドプロント**] ウィンドウを開きます。

1. `OpenSSL_HOME` 変数を OpenSSL のインストール場所に設定します。

   ```
   C:\> set OpenSSL_HOME=path_to_your_OpenSSL_installation
   ```

1. `OpenSSL_CONF` 変数を OpenSSL インストールの設定ファイルの場所に設定します。

   ```
   C:\> set OpenSSL_CONF=path_to_your_OpenSSL_installation\bin\openssl.cfg
   ```

1. OpenSSL インストールを含めるパスを設定します。

   ```
   C:\> set Path=%Path%;%OpenSSL_HOME%\bin
   ```
**注記**  
**コマンドプロンプト**ウィンドウで Windows 環境変数に加えた変更は、現在のコマンドラインセッションでのみ有効です。環境変数をシステムプロパティとして設定することで、環境変数を永続的に変更することができます。正確な手順は、使用している Windows のバージョンによって異なります。（たとえば、Windows 7では、[**コントロールパネル**]、[**システムとセキュリティ**]、[**システム**]の順に開きます。次に、[**システムの詳細設定**]、[**詳細設定**]タブ、[**環境変数**]を選択します。） 詳細については、「Windows ドキュメント」を参照してください。

# 共有 OIDC プロバイダーの ID プロバイダーコントロール
<a name="id_roles_providers_oidc_secure-by-default"></a>

認識された共有 OpenID Connect (OIDC) の ID プロバイダー (IdP) の場合、IAM はロール信頼ポリシーで特定の請求を明示的に評価することが必要になります。*ID プロバイダーコントロール*と呼ばれるこれらの必要な請求は、ロールの作成時および信頼ポリシーの更新時に IAM によって評価されます。ロール信頼ポリシーが共有 OIDC IdP によって求められるコントロールを評価しない場合、ロール作成または更新は失敗します。対象組織の承認された ID のみがロールを引き受けて AWS リソースにアクセスできるようにします。このセキュリティコントロールは、OIDC プロバイダーが複数の AWS 顧客間で共有される場合は不可欠です。



既存の OIDC ロール信頼ポリシーの場合、ID プロバイダーコントロールは IAM によって評価されません。既存の OIDC ロールのロール信頼ポリシーを変更する場合、IAM によって ID プロバイダーコントロールがロール信頼ポリシーに含まれることが必要になります。

## OIDC プロバイダータイプ
<a name="id_roles_providers_oidc_idp_types"></a>

IAM により、OIDC ID プロバイダーは**プライベート**および**共有**という 2 つの異なるタイプに分類されます。プライベート OIDC IdP は、1 つの組織によって所有および管理することができます。また、SaaS プロバイダーのテナントになることもでき、OIDC 発行者 URL は組織固有の一意の識別子として機能します。対照的に、共有 OIDC IdP は複数の組織間で使用され、OIDC 発行者 URL は共有 ID プロバイダーを使用するすべての組織で同じである可能性があります。

以下のテーブルでは、プライベート OIDC プロバイダーと共有 OIDC プロバイダーの主な違いの概要が示されます。


| 特性 | プライベート OIDC プロバイダー | 共有 OIDC プロバイダー | 
| --- | --- | --- | 
|  Issuer   |  組織に固有  |  複数の組織間で共有  | 
|  テナンシー情報  |  一意の発行者を通じて通信される  |  JWT で請求を通じて通信される  | 
|  信頼ポリシーの要件  |  特定の請求評価は不要  |  特定の請求の評価が必要  | 

## ID プロバイダーコントロールを備えた共有 OIDC ID プロバイダー
<a name="id_roles_providers_oidc_idp_shared_oidc_secure_support"></a>

IAM で OIDC プロバイダーを作成または変更すると、システムは認識された共有 OIDC プロバイダーに必要な請求を自動的に特定して評価します。ID プロバイダーコントロールがロール信頼ポリシーで設定されていない場合、ロール作成または更新は MalformedPolicyDocument エラーで失敗します。

次の表は、ロール信頼ポリシーで ID プロバイダーコントロールを必要とする共有 OIDC プロバイダーとID プロバイダーコントロールの設定に役立つ追加情報を示します。


| OIDC IdP | OIDC URL | テナンシー請求 | 必要な請求 | 
| --- | --- | --- | --- | 
| [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) |  `cognito-identity.amazonaws.com`  | aud |  `cognito-identity.amazonaws.com:aud`  | 
| [Azure Sentinel](https://learn.microsoft.com/en-us/azure/defender-for-cloud/sentinel-connected-aws) |  https://sts.windows.net/33e01921-4d64-4f8c-a055-5bdaffd5e33d  |  sts:RoleSessionName  |  sts:RoleSessionName  | 
| [Buildkite](https://buildkite.com/docs/pipelines/security/oidc/aws) |  https://agent.buildkite.com  |  sub  |  agent.buildkite.com:sub  | 
| [Codefresh SaaS](https://codefresh.io/docs/docs/integrations/oidc-pipelines/) | https://oidc.codefresh.io | sub |  oidc.codefresh.io:sub  | 
| [DVC Studio](https://dvc.org/doc/studio/user-guide/openid-connect) | https://studio.datachain.ai/api | sub |  studio.datachain.ai/api:sub  | 
| [GitHub アクション](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) | https://token.actions.githubusercontent.com | sub |  token.actions.githubusercontent.com:sub  | 
| [GitHub 監査ログストリーム](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise) | https://oidc-configuration.audit-log.githubusercontent.com | sub |  oidc-configuration.audit-log.githubusercontent.com:sub  | 
| [GitHub とトークンの比較](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) | https://vstoken.actions.githubusercontent.com | sub |  vstoken.actions.githubusercontent.com:sub  | 
| [GitLab](https://docs.gitlab.com/ci/cloud_services/aws/) | https://gitlab.com | sub |  gitlab.com:sub  | 
| [IBM Turbonomic SaaS\$1](https://www.ibm.com/docs/en/tarm/8.16.x?topic=turbonomic-setting-up-aws-iam-role-saas-deployments) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_oidc_secure-by-default.html)  | sub |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_oidc_secure-by-default.html)  | 
| [Pulumi Cloud](https://www.pulumi.com/docs/pulumi-cloud/deployments/oidc/aws/) | https://api.pulumi.com/oidc | aud |  api.pulumi.com/oidc:aud  | 
| [sandboxes.cloud](https://docs.sandboxes.cloud/docs/cloud-resources-setup) | https://sandboxes.cloud | aud |  sandboxes.cloud:aud  | 
| [Scalr](https://docs.scalr.io/docs/aws) | https://scalr.io | sub |  scalr.io:sub  | 
| [Shisho Cloud](https://shisho.dev/docs/g/getting-started/integrate-apps/aws/) | https://tokens.cloud.shisho.dev | sub |  tokens.cloud.shisho.dev:sub  | 
| [Terraform Cloud](https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/aws-configuration) | https://app.terraform.io | sub |  app.terraform.io:sub  | 
| [Upbound](https://docs.upbound.io/providers/provider-aws/authentication/) | https://proidc.upbound.io | sub |  proidc.upbound.io:sub  | 
| [Vercel グローバルエンドポイント](https://vercel.com/docs/oidc/reference) | https://oidc.vercel.com | aud |  oidc.vercel.com:aud  | 

\$1 IBM Turbonomic は、プラットフォームの新しいバージョンを使用して OIDC 発行者 URL を定期的に更新します。必要に応じて、さらに Turbonomic OIDC 発行者を共有プロバイダーとして追加します。

IAM が共有バージョンとして識別する新しい OIDC IdP の場合、ロール信頼ポリシーに必要な ID プロバイダーコントロールは文書化され、同様の方法で実施されます。

## その他のリソース
<a name="concept_additional_resources"></a>

その他のリソース:
+ OIDC フェデレーション用に IAM ロールを作成する方法の詳細については、「[OpenID Connect フェデレーション用のロールを作成する (コンソール）](id_roles_create_for-idp_oidc.md)」を参照してください。
+ クレームに使用できる IAM 条件キーのリストについては、「[OIDC AWS フェデレーションで使用できるキー](reference_policies_iam-condition-keys.md#condition-keys-wif)」を参照してください。

# SAML 2.0 フェデレーション
<a name="id_roles_providers_saml"></a>

AWS は [SAML 2.0 (Security Assertion Markup Language)](https://wiki.oasis-open.org/security) を使用した ID フェデレーションをサポートします。これは、多くの ID プロバイダー (IdP) により使用されているオープンスタンダードです。この機能はフェデレーションシングルサインオン (SSO) を有効にします。したがって、組織内の全員について IAM ユーザーを作成しなくても、ユーザーは AWS マネジメントコンソール にログインしたり、AWS API オペレーションを呼び出したりできるようになります。SAML を使用すると、[カスタム ID プロキシコードの書き込み](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html)の代わりに IdP のサービスを使用できるため、AWS を使用してフェデレーションを構成するプロセスを簡素化できます。

**注記**  
IAM SAML ID フェデレーションは、SAML ベースのフェデレーション ID プロバイダー (IdP) からの暗号化された SAML レスポンスをサポートします。IAM Identity Center と Amazon Cognito は、IAM SAML ID プロバイダーからの暗号化された SAML アサーションをサポートしていません。  
Amazon Cognito ユーザープールとの Amazon Cognito アイデンティティプールフェデレーションに、暗号化された SAML アサーションのサポートを間接的に追加できます。ユーザープールには、IAM SAML フェデレーションとは無関係で、[SAML 署名と暗号化](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-SAML-signing-encryption.html)をサポートしている SAML フェデレーションがあります。この機能は ID プールに直接拡張されませんが、ユーザープールはアイデンティティプールへの IdP にすることができます。アイデンティティプールで SAML 暗号化を使用するには、アイデンティティプールへの IdP であるユーザープールに暗号化付きの SAML プロバイダーを追加します。  
SAML プロバイダーは、ユーザープールが提供するキーを使用して SAML アサーションを暗号化できる必要があります。ユーザープールは、IAM が提供した証明書で暗号化されたアサーションを受け入れません。

IAM フェデレーションは次のユースケースをサポートします。
+ [**組織のユーザーまたはアプリケーションが AWS API オペレーションを呼び出すことを許可するフェデレーティッドアクセス**](#CreatingSAML-configuring)。このユースケースについては、次のセクションで説明します。組織で生成した SAML アサーションを (認証レスポンスの一部として) 使用して、一時的セキュリティ認証情報を取得します。このシナリオは、「[一時的なセキュリティ認証情報をリクエストする](id_credentials_temp_request.md)」および「[OIDC フェデレーション](id_roles_providers_oidc.md)」で説明されているような、IAM でサポートされている他のフェデレーションのシナリオに似ています。ただし、認証と認可のチェックの実行時は、組織の SAML 2.0 ベースの IdP によってその詳細の多くが処理されます。
+ [**組織から AWS マネジメントコンソール へのウェブベースのシングルサインオン (SSO)**](id_roles_providers_enable-console-saml.md)。ユーザーが SAML 2.0 互換 IdP でホストされる組織のポータルにサインインして、AWS に移動するオプションを選択すると、追加でサインインの情報を入力しなくてもコンソールにリダイレクトされます。サードパーティーの SAML IdP を使用してコンソールへの SSO アクセスを確立するか、外部ユーザーのコンソールアクセスを有効にするカスタム IdP を作成することができます。カスタム IdP の構築の詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。

**Topics**
+ [

## SAML ベースのフェデレーションを使用した AWS への API アクセス
](#CreatingSAML-configuring)
+ [

## SAML 2.0 ベースのフェデレーション設定の概要
](#CreatingSAML-configuring-IdP)
+ [

## AWS リソースへの SAML フェデレーションアクセスを許可するロールの概要
](#CreatingSAML-configuring-role)
+ [

## SAML ベースのフェデレーションでユーザーを一意に識別する
](#CreatingSAML-userid)
+ [

# IAM で SAML ID プロバイダーを作成する
](id_roles_providers_create_saml.md)
+ [

# 証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する
](id_roles_providers_create_saml_relying-party.md)
+ [

# サードパーティーの SAML ソリューションプロバイダーを AWS に統合する
](id_roles_providers_saml_3rd-party.md)
+ [

# 認証レスポンス用の SAML アサーションを設定する
](id_roles_providers_create_saml_assertions.md)
+ [

# SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス
](id_roles_providers_enable-console-saml.md)
+ [

# ブラウザに SAML レスポンスを表示する
](troubleshoot_saml_view-saml-response.md)

## SAML ベースのフェデレーションを使用した AWS への API アクセス
<a name="CreatingSAML-configuring"></a>

自分のコンピューターからバックアップフォルダにデータをコピーする方法を従業員に提供すると仮定します。ユーザーが、自分のコンピューターで実行できるアプリケーションを構築します。バックエンドで、アプリケーションは Amazon S3 バケットのオブジェクトを読み書きします。ユーザーは AWS に直接アクセスできません。代わりに、次のプロセスを使用します。

![\[SAML アサーションに基づいて一時的セキュリティ認証情報を取得する\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/saml-based-federation-diagram.png)


1. 組織のユーザーが、クライアントアプリを使用して、組織の IdP に認証を要求します。

1. IdP がユーザーを組織の ID ストアに対して認証します。

1. IdP はユーザーに関する情報を使用して SAML アサーションを構築し、クライアントアプリにアサーションを送信します。IAM SAML IdP の SAML 暗号化を有効にすると、このアサーションは外部 IdP によって暗号化されます。

1. クライアントアプリが、AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API を呼び出して、SAML プロバイダーの ARN、引き受けるロールの ARN、および IdP からの SAML アサーションを渡します。暗号化が有効になっている場合、クライアントアプリケーションを介して渡されたアサーションは転送中に暗号化されたままになります。

1. (オプション) AWS STS は、外部 IdP からアップロードされたプライベートキーを使用して、暗号化された SAML アサーションを復号します。

1. API は一時的なセキュリティ認証情報を含むレスポンスをクライアントアプリに返します。

1. クライアントアプリでは、一時的なセキュリティ証明書を使用して Amazon S3 API オペレーションを呼び出します。

## SAML 2.0 ベースのフェデレーション設定の概要
<a name="CreatingSAML-configuring-IdP"></a>

前述のシナリオと図に示すように SAML 2.0 ベースのフェデレーションを使用するには、事前に組織の IdP と AWS アカウント を設定して相互に信頼する必要があります。この信頼を設定するための一般的なプロセスを次の手順で説明します。組織内に、Microsoft Active Directory フェデレーションサービス (AD FS、Windows Server の一部)、Shibboleth など、[SAML 2.0 をサポートする IdP](id_roles_providers_saml_3rd-party.md)、または互換性のある他の SAML 2.0 プロバイダーを用意する必要があります。

**注記**  
フェデレーションの耐障害性を高めるには、IdP と AWS フェデレーションを、複数の SAML サインインエンドポイントをサポートするように設定することをお勧めします。詳細については、AWS セキュリティブログの記事「[フェイルオーバーにリージョン SAML エンドポイントを使用する方法](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)」を参照してください。

**組織の IdP と AWS が互いを信頼するように設定する**

1. 組織の IdP を使用し、サービスプロバイダー (SP) として AWS を登録します。`https://region-code.signin.aws.amazon.com/static/saml-metadata.xml` から SAML メタデータドキュメントを使用する

   実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[Region]** (リージョン) 列を参照します。

   任意で、`https://signin.aws.amazon.com/static/saml-metadata.xml` から SAML メタデータドキュメントが使用できます。

1. <a name="createxml"></a>組織の IdP を使用して、AWS の IAM ID プロバイダーとして IdP を記述できる同等の SAML メタデータ XML ファイルを生成します。これには、発行元名、作成日、失効日、AWS が組織からの認証応答 (アサーション) を検証するために使用するキーを含める必要があります。

   暗号化された SAML アサーションを外部 IdP から送信することを許可する場合は、組織の IdP を使用してプライベートキーファイルを生成し、このファイルを .pem ファイル形式 AWS STS で IAM SAML 設定にアップロードする必要があります。IdP にアップロードされたパブリックキーに対応する SAML 応答を復号化するには、このパブリックキーが必要です。
**注記**  
[SAML V2.0 メタデータ相互運用性プロファイルバージョン 1.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html) で定義されているように、IAM は SAML メタデータドキュメントの X.509 証明書の有効期限で評価したりアクションを実行したりすることはできません。期限切れの X.509 証明書について懸念がある場合は、組織のガバナンスとセキュリティポリシーに従って証明書の有効期限をモニタリングし、証明書をローテーションすることをお勧めします。

1. <a name="samlovrcreateentity"></a>IAM コンソールで、SAML ID プロバイダーを作成します。このプロセスの一環として、組織の IdP によって生成された SAML メタデータドキュメントとプライベート複合キーを [Step 2](#createxml) でアップロードします。詳細については、「[IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md)」を参照してください。

1. <a name="samlovrcreaterole"></a>IAM で、 1 つ以上の ロールを作成します。ロールの信頼ポリシーで SAML プロバイダーを、組織と AWS 間の信頼関係を確立するプリンシパルとして設定します。ロールのアクセス許可ポリシーは、AWS で組織のユーザーが実行できることを設定します。詳細については、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」を参照してください。
**注記**  
ロール信頼ポリシーで使用される SAML IDP は、そのロールと同じアカウントにある必要があります。

1. 組織の IdP で、組織のユーザーまたはグループを IAM ロールにマッピングするアサーションを定義します。組織内の異なるユーザーとグループは、異なる IAM ロールにマップされている場合があることに注意してください。マッピングを実行するための正確な手順は、使用している IdP によって異なります。ユーザーのフォルダに関する Amazon S3 の[前述のシナリオ](#CreatingSAML-configuring)では、すべてのユーザーを Amazon S3 アクセス許可を提供する同じロールにマッピングすることができます。詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。

   IdP が AWS コンソールに SSO を有効にすると、コンソールセッションの最大継続時間を設定できます。詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。

1. 作成中のアプリケーションで、AWS Security Token Service`AssumeRoleWithSAML` API を呼び出し、ステップ「[Step 3](#samlovrcreateentity)」で作成した SAML プロバイダーの ARN に渡します。ロールの ARN はステップ「[Step 4](#samlovrcreaterole)」で作成したものとし、現在のユーザーに関する SAML アサーションは IdP から取得したものとします。AWS では、ロールを引き受けるリクエストは SAML プロバイダーで参照される IdP からのリクエストであることを確認します。

   詳細については、[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API リファレンス* の「AWS Security Token ServiceAssumeRoleWithSAML*」を参照してください。

1. リクエストが成功すると、API から一時的セキュリティ認証情報一式が返され、アプリケーションではこれを利用して AWS に対して署名付きリクエストを作成します。前のシナリオで説明したように、アプリケーションは、現在のユーザーの情報を取得し、Amazon S3 のユーザー固有のフォルダにアクセスできます。

## AWS リソースへの SAML フェデレーションアクセスを許可するロールの概要
<a name="CreatingSAML-configuring-role"></a>

IAMで作成するロールは、組織の SAML フェデレーションプリンシパルが AWS で許可されたアクションを定義します。ロールの信頼ポリシーを作成するときは、前に `Principal` として作成した SAML プロバイダーを指定します。さらに、特定の SAML 属性に一致するユーザーにのみロールへのアクセスを許可するように、`Condition` 付きの信頼ポリシーのスコープを設定できます。たとえば、次のサンプルポリシーに示されているように、 (https://openidp.feide.no によってアサートされるように) SAML の所属が `staff` であるユーザーのみロールにアクセスできるように指定できます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::111122223333:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://us-east-1.signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}
```

------

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws-cn:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "saml:aud": "https://ap-east-1.signin.amazonaws.cn/saml",
                    "saml:iss": "https://openidp.feide.no"
                },
                "ForAllValues:StringLike": {
                    "saml:edupersonaffiliation": [
                        "staff"
                    ]
                }
            }
        }
    ]
}
```

------

**注記**  
ロール信頼ポリシーで使用される SAML IDP は、そのロールと同じアカウントにある必要があります。

ポリシーの `saml:aud` コンテキストキーは、コンソールにサインインするときにブラウザに表示される URL を指定します。このサインインエンドポイント URL は、ID プロバイダーの受取人属性と一致する必要があります。特定のリージョン内にサインイン URL を含めることができます。AWS では、フェデレーションの耐障害性を向上させるために、グローバルエンドポイントの代わりにリージョンエンドポイントを使用することをお勧めします。エンドポイントが 1 つしか設定されていない場合、エンドポイントが使用できなくなっても、AWS にフェデレーションすることはできません。実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[リージョン]** 列を参照します。

次の例は、オプションの `region-code` を使用したサインイン URL 形式を示しています。

`https://region-code.signin.aws.amazon.com/saml`

SAML 暗号化が必要な場合、サインイン URL に SAML プロバイダーに割り当てる一意の識別子 AWS が含まれている必要があります。この識別子は ID プロバイダーの詳細ページで確認できます。次の例では、サインイン URL に IdP の一意の識別子が含まれています。この識別子には、サインインパスに /acs/ を追加する必要があります。

`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

ロールのアクセス許可ポリシーでは、ロールに付与するアクセス許可を自由に指定します。たとえば、組織のユーザーが Amazon Elastic Compute Cloud インスタンスを管理できる場合、**AmazonEC2FullAccess** 管理ポリシーのように、アクセス許可ポリシーで明示的に Amazon EC2 アクションを許可します。

ポリシーでチェック可能な SAML キーの詳細については、「[SAML ベースの AWS STS フェデレーションに利用可能なキー](reference_policies_iam-condition-keys.md#condition-keys-saml)」を参照してください。

## SAML ベースのフェデレーションでユーザーを一意に識別する
<a name="CreatingSAML-userid"></a>

IAM でアクセスポリシーを作成するときに、ユーザーの ID に基づいてアクセス許可を指定できると、便利です。たとえば、SAML を使用してフェデレーションされたユーザーの情報は、アプリケーションで以下のような構造体を使用して Amazon S3 に保存することをお勧めします。

```
amzn-s3-demo-bucket/app1/user1
amzn-s3-demo-bucket/app1/user2
amzn-s3-demo-bucket/app1/user3
```

バケット (`amzn-s3-demo-bucket`) およびフォルダ (`app1`) は静的な値であるため、Amazon S3 コンソールまたは AWS CLI で作成できます。ただし、ユーザー固有のフォルダ (*user1*、*user2*、*user3* など) は、ユーザーが最初にフェデレーションプロセスを通してサインインするまでユーザーを特定する値がわからないため、実行時にコードを使用して作成する必要があります。

リソース名の一部としてユーザー固有の詳細を参照するポリシーを記述するには、ユーザー ID がポリシー条件で使用できる SAML キーで利用可能である必要があります。IAM ポリシーで使用する SAML 2.0 ベースのフェデレーションでは、次のキーを使用できます。以下のキーによって返される値を使用して、Amazon S3 フォルダなどのリソースの一意のユーザー ID を作成できます。
+ `saml:namequalifier`.`Issuer` のレスポンス値 (`saml:iss`)、`AWS` アカウント ID および IAM の SAML プロバイダーのわかりやすい名前 (ARN の最後の部分) の文字列を連結したハッシュ値。アカウント ID および SAML プロバイダーのわかりやすい名前の連結はキー `saml:doc` として、IAM のポリシーで使用できます。アカウント ID とプロバイダー名は、「123456789012/provider\$1name」のように「/」で区切る必要があります。詳細については、「`saml:doc`」の [SAML ベースの AWS STS フェデレーションに利用可能なキー](reference_policies_iam-condition-keys.md#condition-keys-saml) キーを参照してください。

  `NameQualifier` および `Subject` の組み合わせは、SAML フェデレーティッドプリンシパルを一意に識別するために使用できます。次の擬似コードは、この値の計算方法を示します。この擬似コードで `+` は連結を表し、`SHA1` は SHA-1 を使用してメッセージダイジェストを生成する関数を、`Base64` は Base-64 でエンコードされたバージョンのハッシュ出力を生成する関数を示します。

   `Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )` 

   SAML ベースのフェデレーションで利用可能なポリシーキーの詳細については、「[SAML ベースの AWS STS フェデレーションに利用可能なキー](reference_policies_iam-condition-keys.md#condition-keys-saml)」を参照してください。
+ `saml:sub`（文字列）。\$1 これはクレームの件名です。組織内の個々のユーザーを一意に識別する値が含まれます（例: `_cbb88bf52c2510eabe00c1642d4643f41430fe25e3`）。
+ `saml:sub_type`（文字列）。このキーは、`persistent`、`transient`、または SAML アサーションで使用されている `Format` および `Subject` 要素の完全な `NameID` URI とすることができます。`persistent` の値は、すべてのセッションでユーザーの `saml:sub` 値が同じことを意味します。値が `transient` の場合、ユーザーの `saml:sub` 値はセッションごとに異なります。`NameID` 要素の `Format` 属性の詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。

以下の例は前述のキーを使用して Amazon S3 のユーザー固有のフォルダにアクセス許可を付与するためのアクセスポリシーを示します。ポリシーは、Amazon S3 オブジェクトが `saml:namequalifier` と `saml:sub` の両方を含むプレフィックスを使用して特定されていることを前提としていまします。`Condition` 要素には、`saml:sub_type` が `persistent` に設定されていることを確認するテストが含まれることに注意してください。`transient`" に設定されている場合、ユーザーの `saml:sub` 値はセッションごとに異なる可能性があるため、値の組み合わせを使用してユーザー固有のフォルダを識別することはできません。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}
```

------

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}
```

------

IdP からポリシーキーにアサーションをマッピングする方法については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。

# IAM で SAML ID プロバイダーを作成する
<a name="id_roles_providers_create_saml"></a>

IAM SAML 2.0 ID プロバイダーは、[SAML 2.0 (Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security) 基準をサポートする外部 ID プロバイダー (IdP) を記述する IAM のエンティティです。Shibboleth や Active Directory フェデレーションサービスなどの SAML 互換 IdP と AWS の間に信頼を確立して、ユーザーが AWS リソースにアクセスできるようにする場合は、IAM ID プロバイダーを使用します。IAM の SAML プロバイダーは IAM 信頼ポリシーでプリンシパルとして使用されます。

このシナリオの詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。

AWS マネジメントコンソール または AWS CLI、Tools for Windows PowerShell、または AWS API 呼び出しを使用して IAM ID プロバイダーを作成および管理できます。

SAML プロバイダーを作成した後、IAM ロールを作成する必要があります。ロールは AWS のアイデンティティであり、それ自体には (ユーザーのような) 認証情報がありません。ただし、この例では IdP によって認証された SAML フェデレーティッドプリンシパルに対し、ロールは動的に割り当てられます。このロールで、IdP が AWS にアクセスするための一時的なセキュリティ認証情報をリクエストできるようにします。ロールに割り当てられたポリシーにより、ユーザーが AWS で実行できることが決定されます。SAML フェデレーション用のロールを作成するには、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」を参照してください。

最後に、ロールを作成した後、AWS および SAML フェデレーティッドプリンシパルが使用するロールに関する情報で IdP を設定することで、SAML の信頼を完了させます。これを、IdP と AWS 間の証明書利用者の設定といいます。証明書利用者の信頼を設定するには、「[証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する](id_roles_providers_create_saml_relying-party.md)」を参照してください。

**Topics**
+ [

## 前提条件
](#idp-manage-identityprovider-prerequisites)
+ [

## IAM SAML ID プロバイダーを作成および管理する (コンソール)
](#idp-manage-identityprovider-console)
+ [

## SAML 暗号化キーの管理
](#id_federation_manage-saml-encryption)
+ [

## IAM SAML ID プロバイダーを作成および管理する (AWS CLI)
](#idp-create-identityprovider-CLI)
+ [

## IAM SAML ID プロバイダーを作成および管理する (AWS API)
](#idp-create-identityprovider-API)
+ [

## 次のステップ
](#id_roles_create-for-saml-next-steps)

## 前提条件
<a name="idp-manage-identityprovider-prerequisites"></a>

SAML ID プロバイダーを作成する前に、IdP から次の情報を取得しておく必要があります。
+ IdP から SAML メタデータドキュメントを取得します。このドキュメントには発行者の名前、失効情報、およびキーが含まれており、これらを使用して、IdP から受け取った SAML 認証レスポンス (アサーション) を検証できます。メタデータドキュメントを生成するには、外部 IdP として提供されている ID 管理ソフトウェアを使用します。
**重要**  
このメタデータファイルには発行者の名前、失効情報、およびキーが含まれており、これらを使用して、IdP から受け取った SAML 認証レスポンス (アサーション) を検証できます。メタデータファイルはバイトオーダーマーク (BOM) なしで UTF-8 形式でエンコードする必要があります。BOM を削除するには、Notepad\$1\$1 などのテキスト編集ツールを使用して UTF-8 としてファイルをエンコードできます。  
SAML メタデータドキュメントの一部として含まれている X.509 証明書では、少なくとも 1024 ビットのキーサイズを使用する必要があります。また、X.509 証明書には、拡張領域が繰り返されていないことが必要です。拡張領域は使用できますが、証明書に 1 回しか出現できません。X.509 証明書がいずれかの条件を満たしていない場合、IdP の作成は失敗し、「メタデータを解析できない」エラーが返されます。  
[SAML V2.0 メタデータ相互運用性プロファイルバージョン 1.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html) で定義されているように、IAM は SAML メタデータドキュメントの X.509 証明書の有効期限で評価したりアクションを実行したりすることはできません。期限切れの X.509 証明書について懸念がある場合は、組織のガバナンスとセキュリティポリシーに従って証明書の有効期限をモニタリングし、証明書をローテーションすることをお勧めします。
+ SAML 暗号化を有効にする場合は、IdP を使用してプライベートキーファイルを生成し、このファイルを .pem ファイル形式で IAM SAML 構成にアップロードする必要があります。AWS STS は、IdP にアップロードされたパブリックキーに対応する SAML レスポンスを復号化するために、このプライベートキーが必要です。以下のアルゴリズムがサポートされています。
  + 暗号化アルゴリズム
    + AES-128
    + AES-256
    + RSA-OAEP
  + キートランスポートアルゴリズム
    + AES-CBC
    + AES-GCM

  プライベートキーを生成する手順については、ID プロバイダーのドキュメントを参照してください。
**注記**  
IAM Identity Center と Amazon Cognito は、IAM SAML ID プロバイダーからの暗号化された SAML アサーションをサポートしていません。Amazon Cognito ユーザープールとの Amazon Cognito アイデンティティプールフェデレーションに、暗号化された SAML アサーションのサポートを間接的に追加できます。ユーザープールには、IAM SAML フェデレーションとは無関係で、[SAML 署名と暗号化](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-SAML-signing-encryption.html)をサポートしている SAML フェデレーションがあります。この機能は ID プールに直接拡張されませんが、ユーザープールはアイデンティティプールへの IdP にすることができます。アイデンティティプールで SAML 暗号化を使用するには、アイデンティティプールへの IdP であるユーザープールに暗号化付きの SAML プロバイダーを追加します。  
SAML プロバイダーは、ユーザープールが提供するキーを使用して SAML アサーションを暗号化できる必要があります。ユーザープールは、IAM が提供した証明書で暗号化されたアサーションを受け入れません。

必要な SAML メタデータドキュメントの生成方法を含め、使用可能な多くの IdP を AWS と連携するように設定するステップについては、「[サードパーティーの SAML ソリューションプロバイダーを AWS に統合する](id_roles_providers_saml_3rd-party.md)」を参照してください。

SAML フェデレーションの詳細については、「[Troubleshooting SAML federation](troubleshoot_saml.md)」を参照してください。

## IAM SAML ID プロバイダーを作成および管理する (コンソール)
<a name="idp-manage-identityprovider-console"></a>

AWS マネジメントコンソール​ を使用して、IAM SAML ID プロバイダーの作成、更新、および削除を実行できます。SAML フェデレーションの詳細については、「[Troubleshooting SAML federation](troubleshoot_saml.md)」を参照してください。

**IAM SAML ID プロバイダーを作成するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ID プロバイダー]** を選択し、**[プロバイダーを追加]** を選択します。

1. **[プロバイダーの設定]** で、**[SAML]** を選択します。

1. ID プロバイダーの名前を入力します。

1. **[メタデータドキュメント]** で、**[ファイルを選択]** を選択し、[前提条件](#idp-manage-identityprovider-prerequisites) でダウンロードした SAML メタデータドキュメントを指定します。
**注記**  
SAML メタデータドキュメント内の `validUntil` または `cacheDuration` 属性は、ID プロバイダーの **[有効期限]** 日を定義します。SAML メタデータドキュメントに有効期間属性が含まれていない場合、**[有効期限]** 日が X.509 証明書の有効期限と一致しなくなります。  
IAM は、SAML メタデータドキュメント内の X.509 証明書の有効期限切れに対して評価やアクションを実行しません。期限切れの X.509 証明書について懸念がある場合は、組織のガバナンスとセキュリティポリシーに従って証明書の有効期限をモニタリングし、証明書をローテーションすることをお勧めします。

1. (オプション) **SAML 暗号化**で、**[ファイルの選択]** を選択し、[前提条件](#idp-manage-identityprovider-prerequisites) で作成したプライベートキーファイルを選択します。IdP からの暗号化されたリクエストのみを受け入れるには、**[Require encryption]** を選択します。

1. (オプション) [**Add tags (タグの追加)**] では、キーバリューのペアを追加して IdP の特定と整理を行うことができます。タグを使用して、AWS リソースへのアクセスを制御することもできます。SAML ID プロバイダーのタグ付けの詳細については、「[IAM SAML ID プロバイダーにタグ付けする](id_tags_saml.md)」を参照してください。

   **[タグを追加]** を選択します。タグキーバリューのペアごとに値を入力します。

1. 入力した情報を確認します。完了したら、**[プロバイダーを追加]** を選択します。

1. ID プロバイダーに IAM ロールを割り当てます。このロールは、ID プロバイダーによって管理される外部ユーザー ID に、アカウント内の AWS リソースへのアクセス許可を付与します。ID フェデレーション用のロールの作成の詳細については、「[サードパーティー ID プロバイダーにロールを作成する](id_roles_create_for-idp.md)」をご参照ください。
**注記**  
ロール信頼ポリシーで使用される SAML IDP は、そのロールと同じアカウントにある必要があります。

**SAML プロバイダーを削除するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ID プロバイダー]** を選択します。

1. 削除する ID プロバイダーの横にあるラジオボタンをオンにします。

1. **[削除]** を選択します。新しいウィンドウが開きます。

1. フィールドに単語 `delete` を入力して、プロバイダーを削除することを確認します。その後、**[削除]** をクリックします。

## SAML 暗号化キーの管理
<a name="id_federation_manage-saml-encryption"></a>

外部 IdP からの SAML レスポンスで暗号化されたアサーションを受信するように IAM SAML プロバイダーを設定できます。ユーザーは、`[sts:AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)` を呼び出して暗号化された SAML アサーションを使用して AWS でロールを引き受けることができます。

SAML の暗号化により、仲介者や第三者を通じて渡されたアサーションの安全を確保できます。さらに、この機能は、SAML アサーションの暗号化を義務付ける FedRAMP または内部コンプライアンスポリシー要件を満たすのに役立ちます。

IAM SAML ID プロバイダーを設定するには、「[IAM で SAML ID プロバイダーを作成する](#id_roles_providers_create_saml)」を参照してください。SAML フェデレーションの詳細については、「[Troubleshooting SAML federation](troubleshoot_saml.md)」を参照してください。

### SAML 暗号化キーのローテーション
<a name="id_federation_manage-saml-keys-rotate"></a>

IAM は、IAM SAML プロバイダーにアップロードしたプライベートキーを使用して、IdP から暗号化された SAML アサーションを復号化します。ID プロバイダーごとに最大 2 つのプライベートキーファイルを保存できるため、必要に応じてプライベートキーをローテーションできます。2 つのファイルを保存すると、各リクエストはまず、最新の **[追加日]** で復号しようとします。次に、IAM は最も古い **[追加日]** でリクエストの復号を試みます。

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. ナビゲーションペインで、**[ID プロバイダー]** を選択し、次にリストから自分のプロバイダーを選択します。

1. **[SAML encryption]** タブを選択し、**[新しいキーを追加]** を選択します。

1. **[ファイルを選択]** を選択し、IdP からダウンロードしたプライベートキーを .pem ファイルとしてアップロードします。次に、**[キーを追加]** を選択します。

1. **[Private keys for SAML decryption]** セクションで期限切れのプライベートキーファイルを選択し、**[削除]** を選択します。アサーションの復号が一度で成功するように、新しいプライベートキーを追加した後には、期限切れのプライベートキーを削除することをお勧めします。

## IAM SAML ID プロバイダーを作成および管理する (AWS CLI)
<a name="idp-create-identityprovider-CLI"></a>

AWS CLI​ を使用して、SAML プロバイダーの作成、更新、および削除を実行できます。SAML フェデレーションの詳細については、「[Troubleshooting SAML federation](troubleshoot_saml.md)」を参照してください。

**IAM ID プロバイダーを作成してメタデータドキュメントをアップロードするには (AWS CLI)**
+ 次のコマンドを実行します。[https://docs.aws.amazon.com/cli/latest/reference/iam/create-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-saml-provider.html)

**IAM SAML ID プロバイダーを更新するには (AWS CLI)**

メタデータファイル、SAML 暗号化設定を更新し、IAM SAML プロバイダーのプライベートキー復号ファイルをローテーションできます。プライベートキーをローテーションするには、新しいプライベートキーを追加し、別のリクエストで古いキーを削除します。プライベートキーのローテーションの詳細については、「[SAML 暗号化キーの管理](#id_federation_manage-saml-encryption)」を参照してください。
+ 次のコマンドを実行します。[https://docs.aws.amazon.com/cli/latest/reference/iam/update-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-saml-provider.html)

**既存の IAM ID プロバイダー (AWS CLI) にタグを付けるには**
+ 次のコマンドを実行します。[https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html)

**既存の IAM ID プロバイダー (AWS CLI) のタグを一覧表示するには**
+ 次のコマンドを実行します。[https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html)

**既存の IAM ID プロバイダー (AWS CLI) のタグを削除するには**
+ 次のコマンドを実行します。[https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html)

**IAM SAML ID プロバイダーを削除するには (AWS CLI)**

1. (オプション) すべてのプロバイダーに関する ARN、作成日、失効などの情報を表示するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-providers.html)

1. (オプション) ARN、作成日、有効期限、暗号化の設定、プライベートキーの情報など、特定のプロバイダーに関する情報を取得するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-saml-provider.html)

1. IAM ID プロバイダーを削除するには、次のコマンドを実行します。
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-saml-provider.html)

## IAM SAML ID プロバイダーを作成および管理する (AWS API)
<a name="idp-create-identityprovider-API"></a>

AWS​ API を使用して、SAML プロバイダーの作成、更新、および削除を実行できます。SAML フェデレーションの詳細については、「[Troubleshooting SAML federation](troubleshoot_saml.md)」を参照してください。

**IAM ID プロバイダーを作成してメタデータドキュメントをアップロードするには (AWS API)**
+ 呼び出すオペレーション: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html)

**IAM SAML ID プロバイダーを更新するには (AWS API)**

メタデータファイル、SAML 暗号化設定を更新し、IAM SAML プロバイダーのプライベートキー復号ファイルをローテーションできます。プライベートキーをローテーションするには、新しいプライベートキーを追加し、別のリクエストで古いキーを削除します。プライベートキーのローテーションの詳細については、「[SAML 暗号化キーの管理](#id_federation_manage-saml-encryption)」を参照してください。
+ 呼び出すオペレーション: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html)

**既存の IAM ID プロバイダーにタグを付けるには (AWS API)**
+ 呼び出すオペレーション: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html)

**既存の IAM ID プロバイダーのタグを一覧表示するには (AWS API)**
+ 呼び出すオペレーション: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html)

**既存の IAM ID プロバイダーのタグを削除するには (AWS API)**
+ 呼び出すオペレーション: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html)

**IAM ID プロバイダーを削除するには (AWS API)**

1. (オプション) すべての IdP に関する ARN、作成日、失効などの情報を表示するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviders.html)

1. (オプション) ARN、作成日、有効期限、暗号化の設定、プライベートキーの情報など、特定のプロバイダーに関する情報を取得するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetSAMLProvider.html)

1. IdP を削除するには、次のオペレーションを呼び出します。
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSAMLProvider.html)

## 次のステップ
<a name="id_roles_create-for-saml-next-steps"></a>

SAML ID プロバイダーを作成したら、IdP に対して証明書利用者の信頼を確立します。また、IdP の認証レスポンスからのクレームをポリシーで使用して、ロールへのアクセスを制御することもできます。
+ サービスプロバイダーとしての AWS について IdP に通知する必要があります。これは、IdP と AWS の間に証明書利用者の信頼を追加することと呼ばれます。証明書利用者の信頼を追加するための正確なプロセスは、使用する IdP によって異なります。詳細については、「[証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する](id_roles_providers_create_saml_relying-party.md)」を参照してください。
+ IdP が AWS へのクレームを含むレスポンスを送信すると、多くの受信クレームは AWS コンテキストキーにマッピングされます。これらのコンテキストキーを IAM ポリシーの Condition 要素に指定して、ロールへのアクセスを制御できます。詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。

# 証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する
<a name="id_roles_providers_create_saml_relying-party"></a>

IAM ID プロバイダー、および SAML アクセス用のロールを作成すると、外部 ID プロバイダー (IdP) の詳細とそのユーザーが許可されているアクションが AWS に通知されます。次のステップでは、IdP に対し、サービスプロバイダーとしての AWS について通知します。これは、IdP と AWS の間に*証明書利用者の信頼*を追加することと呼ばれます。証明書利用者の信頼を追加するための正確なプロセスは、使用する IdP によって異なります。詳細については、使用している ID 管理ソフトウェアのドキュメントを参照してください。

多くの IdP が URL の指定を許可しています。IdP はこの URL から、証明書利用者の情報と証明書が含まれる XML ドキュメントを読み取ることができます。AWS には、サインインエンドポイント URL を使用します。次の例は、オプションの `region-code` を含む URL 形式を示しています。

`https://region-code.signin.aws.amazon.com/static/saml-metadata.xml`

SAML 暗号化が必要な場合は、URL に が SAML プロバイダーに割り当てる一意の識別子 AWS を含める必要があります。この識別子は ID プロバイダーの詳細ページにあります。次の例は、一意の識別子を含むリージョンのサインイン URL を示しています。

`https://region-code.signin.aws.amazon.com/static/saml/IdP-ID/saml-metadata.xml`

実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[Region]** (リージョン) 列を参照します。AWS 値には、非リージョンエンドポイント `https://signin.aws.amazon.com/saml` を使用することもできます。

URL を直接指定できない場合は、XML ドキュメントを前述の URL からダウンロードし、ダウンロードした XML ドキュメントを IdP ソフトウェアにインポートします。

また、IdP で、AWS を証明書利用者として指定する適切なクレームルールを作成する必要があります。IdPが AWS エンドポイントにSAML応答を送信すると、1つ以上の*クレーム*を含む SAML *アサーション*が含まれます。クレームとは、ユーザーとそのグループに関する情報です。クレームルールはその情報を SAML 属性にマッピングします。SAML フェデレーティッドプリンシパルのアクセス許可を確認するため、AWS が IAM ポリシーで使用する必要な属性が IdP からの SAML 認証レスポンスに確実に含まれていることを確認できます。詳細については、以下の各トピックを参照してください。
+  [AWS リソースへの SAML フェデレーションアクセスを許可するロールの概要](id_roles_providers_saml.md#CreatingSAML-configuring-role). このトピックでは、IAM ポリシーで SAML 固有のキーを使用することに加え、SAML フェデレーティッドプリンシパルにアクセス許可を制限するために使用する方法について説明します。
+ [認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md). このトピックでは、ユーザーに関する情報を含む SAML クレームを設定する方法について説明します。クレームは SAML アサーションにバンドルされ、AWS に送信される SAML レスポンスに含まれます。AWS ポリシーによって必要とされる情報が、AWS が認識して使用できる形式で SAML アサーションに含まれていることを確認する必要があります。
+  [サードパーティーの SAML ソリューションプロバイダーを AWS に統合する](id_roles_providers_saml_3rd-party.md)。このトピックには、サードパーティの組織から提供されている、ID ソリューションを AWS と統合する方法に関するドキュメントへのリンクが記載されています。

**注記**  
フェデレーションの耐障害性を高めるには、IdP と AWS フェデレーションを、複数の SAML サインインエンドポイントをサポートするように設定することをお勧めします。詳細については、AWS セキュリティブログの記事「[フェイルオーバーにリージョン SAML エンドポイントを使用する方法](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)」を参照してください。

# サードパーティーの SAML ソリューションプロバイダーを AWS に統合する
<a name="id_roles_providers_saml_3rd-party"></a>

**注記**  
人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用を必須とすることをお勧めします。AWS IAM アイデンティティセンター の使用を検討したことのある場合 IAM Identity Center を使用すると、複数の AWS アカウント へのアクセスを一元的に管理できます。ユーザーには、割り当てられたすべてのアカウントに対する MFA で保護された Single Sign-On によるアクセスを、1 つの場所から提供することができます。IAM Identity Center では、 その内部でユーザー ID の作成および管理を行います。あるいは、既存の SAML 2.0 互換 ID プロバイダーにも簡単に接続することができます。詳細については、「AWS IAM アイデンティティセンター ユーザーガイド」の「[What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」(IAM Identity Center とは?) を参照してください。

以下のリンクは、AWS フェデレーションで動作するようにサードパーティーの SAML 2.0 ID プロバイダー (IdP) ソリューションを設定するために役立ちます。ID プロバイダーに問い合わせて、SAML トークン暗号化がサポートされているかどうかを確認してください。SAML 暗号化の要件については、「[SAML 暗号化キーの管理](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption)」を参照してください。

**ヒント**  
AWS サポートエンジニアは、ビジネスおよびエンタープライズサポートプランを利用し、サードパーティー製のソフトウェアを一部の統合タスクで実行しているお客様をサポートできます。サポートされているプラットフォームおよびアプリケーションの最新のリストについては、「AWS サポート FAQ」の「[サポート済みのサードパーティーソフトウェア](https://aws.amazon.com/premiumsupport/faqs/#what3rdParty)」を参照してください。


****  

| ソリューション | 詳細情報 | 
| --- | --- | 
| Auth0 |  [Amazon Web Services との統合](https://auth0.com/docs/integrations/aws) – Auth0 ドキュメントウェブサイトにあるこのページには、AWS マネジメントコンソール でシングルサインオン (SSO) を設定する方法を説明するリソースへのリンクがあり、JavaScript の例が含まれています。[セッションタグ](id_session-tags.md)を渡すように Auth0 を設定できます。詳細については、「[Auth0 Announces Partnership with AWS for IAM Session Tags](https://auth0.com/blog/auth0-partners-with-aws-for-iam-session-tags/)」を参照してください。 | 
| Microsoft Entra |  [チュートリアル: Microsoft Entra SSO と AWS シングルアカウントアクセスの統合](https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/amazon-web-service-tutorial) – Microsoft のウェブサイトにあるこのチュートリアルには、SAML フェデレーションを使用して Microsoft Entra (旧称: Azure AD) を ID プロバイダー (IdP) として設定する方法が記載されています。 | 
| Centrify | [AWS への SSO に SAML を使用するように Centrify を設定する](https://docs.centrify.com/Content/Applications/AppsWeb/AmazonSAML.htm) – Centrify のウェブサイトのこのページでは、AWS への SSO に SAML を使用するように Centrify を設定方法について説明しています。 | 
| CyberArk | CyberArk User Portal から SAML のシングルサインオン (SSO) 経由でログインしているユーザーが、Amazon Web Services (AWS) へアクセスできるように、[CyberArk](https://docs.cyberark.com/Product-Doc/OnlineHelp/Idaptive/Latest/en/Content/Applications/AppsWeb/AmazonSAML.htm) を設定します。 | 
| ForgeRock | [ForgeRock アイデンティティプラットフォーム](https://backstage.forgerock.com/docs/am/6.5/saml2-guide/#saml2-create-hosted-idp)は、AWS と統合されています。[セッションタグ](id_session-tags.md)を渡すように ForgeRock を設定できます。詳細については、「[Attribute Based Access Control for Amazon Web Services](https://www.forgerock.com/blog/attribute-based-access-control-amazon-web-services)」を参照してください。 | 
| Google Workspace | [Amazon Web Services クラウドアプリケーション](https://support.google.com/a/answer/6194963) – Google Workspace 管理者ヘルプサイトのこの記事は、AWS をサービスプロバイダーとし、Google Workspace をSAML 2.0 IdP として構成する方法について説明しています。 | 
| IBM | [セッションタグ](id_session-tags.md)を渡すように IBM を設定できます。詳細については、「[IBM Cloud Identity IDaaS one of first to support AWS session tags](https://community.ibm.com/community/user/security/blogs/adam-case/2019/11/25/ibm-cloud-identity-idaas-one-of-first-to-support-aws-session-tags)」を参照してください。 | 
| JumpCloud |  [Amazon AWS で Single Sign On (SSO) の IAM ロールを介してアクセス権を付与する](https://support.jumpcloud.com/support/s/article/Granting-Access-via-IAM-Roles-for-Single-Sign-On-SSO-with-Amazon-AWS) – JumpCloud ウェブサイトのこの記事では、AWS のために IAM ロールに基づいて SSO を設定して有効にする方法について説明します。 | 
| Matrix42 | [MyWorkspace 入門ガイド](https://myworkspace.matrix42.com/documents/MyWorkspace-Getting-Started-with-AWS.pdf) – このガイドでは、AWS Identity サービスを Matrix42 MyWorkspace と統合する方法について説明します。 | 
| Microsoft Active Directory フェデレーションサービス (AD FS) |  [フィールドノート: AWS IAM アイデンティティセンター と Active Directory Federation Service の統合](https://aws.amazon.com/blogs/architecture/field-notes-integrating-active-directory-federation-service-with-aws-single-sign-on/) — この AWS アーキテクチャブログの記事では、AD FS と AWS IAM アイデンティティセンター (IAM Identity Center) 間の認証フローについて説明しています。IAM Identity Center では、SAML 2.0 による ID フェデレーションがサポートされており、AD FS ソリューションとの統合が可能です。ユーザーは企業の認証情報を持つ IAM Identity Center ポータルにサインインできるので、IAM Identity Center で個別に認証情報を管理するオーバーヘッドを削減できます。また[セッションタグ](id_session-tags.md)を渡すように AD FS を設定できます。詳細については、「[Use attribute-based access control with AD FS to simplify IAM permissions management](https://aws.amazon.com/blogs/security/attribute-based-access-control-ad-fs-simplify-iam-permissions-management/)」を参照してください。  | 
| miniOrange | [AWS の SSO](http://miniorange.com/amazon-web-services-%28aws%29-single-sign-on-%28sso%29) – miniOrange ウェブサイトのこのページでは、エンタープライズ向けの AWS への安全なアクセスと、AWS アプリケーションへのアクセスの完全コントロールを確立する方法が説明されています。 | 
| Okta |  [Okta を使用した Amazon Web Services コマンドラインインターフェイスの統合](https://support.okta.com/help/Documentation/Knowledge_Article/Integrating-the-Amazon-Web-Services-Command-Line-Interface-Using-Okta) – Okta サポートサイトのこのページから、AWS で使用するように Okta を設定する方法について参照できます。[セッションタグ](id_session-tags.md)を渡すように Okta を設定できます。詳細については、「[Okta and AWS Partner to Simplify Access Via Session Tags](https://www.okta.com/blog/2019/11/okta-and-aws-partner-to-simplify-access-via-session-tags/)」を参照してください。 | 
| Okta | [AWS アカウントフェデレーション](https://help.okta.com/oie/en-us/Content/Topics/DeploymentGuides/AWS/aws-deployment.htm) – Okta ウェブサイトにあるこのセクションは、AWS の IAM Identity Center をセットアップして有効にする方法を説明します。 | 
| OneLogin | [OneLogin Knowledgebase](https://onelogin.service-now.com/support) で「SAML AWS」を検索し、単一ロールや複数ロールのシナリオで、OneLogin と AWS 間で IAM Identity Center の機能をセットアップする方法を説明する記事の一覧を表示します。[セッションタグ](id_session-tags.md)を渡すように OneLogin を設定できます。詳細については、「[OneLogin and Session Tags: Attribute-Based Access Control for AWS Resources](https://www.onelogin.com/blog/aws-session-tags-integration)」を参照してください。 | 
| Ping Identity |  [PingFederate AWS Connector](https://support.pingidentity.com/s/marketplace-integration-details?recordId=a7i1W0000004HBwQAM) – PingFederate AWS Connector の詳細を表示します。これは、シングルサインオン (SSO) と接続のプロビジョニングを簡単にセットアップするためのクイック接続テンプレートです。AWS との統合に関するドキュメントを読み、最新の PingFederate AWS Connector をダウンロードします。[セッションタグ](id_session-tags.md)を渡すように Ping ID を設定できます。詳細については、「[Announcing Ping Identity Support for Attribute-Based Access Control in AWS](https://support.pingidentity.com/s/document-item?bundleId=integrations&topicId=pon1571779451105.html)」を参照してください。  | 
| RadiantLogic | [Radiant Logic Technology Partners](http://www.radiantlogic.com/about/partners/technology-partners/) – Radiant Logic の RadiantOne Federated Identity Service を AWS に統合すると、SAML ベースの SSO のための ID ハブを提供できます。 | 
| RSA | 「[Amazon Web Services - RSA Ready 実装ガイド](https://community.rsa.com/s/article/Amazon-Web-Services-RSA-Ready-Implementation-Guide)」には、 AWS と RSA を統合するためのガイダンスが記載されています。SAML 設定の詳細については、「[Amazon Web Services - SAML My Page SSO Configuration - RSA Ready Implementation Guide](https://community.rsa.com/s/article/Amazon-Web-Services-SAML-My-Page-SSO-Configuration-RSA-Ready-Implementation-Guide)」を参照してください。 | 
| Salesforce.com |  [Salesforce から AWS への SSO を設定する方法](https://developer.salesforce.com/page/Configuring-SAML-SSO-to-AWS) – Salesforce.com 開発者サイトのこの操作手順記事では、Salesforce で ID プロバイダー (IdP) をセットアップし、AWS をサービスプロバイダーとして設定する方法が説明されています。 | 
| SecureAuth |  [AWS - SecureAuth SAML SSO](https://docs.secureauth.com/2104/en/amazon-web-services--aws---idp-initiated--integration-guide.html) – SecureAuth ウェブサイトのこの記事では、SecureAuth アプライアンス用に SAML と AWS の統合をセットアップする方法について説明されています。 | 
| Shibboleth |  [AWS マネジメントコンソール への SSO に Shibboleth を使用する方法](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console) – AWS セキュリティブログのこのエントリには、Shibboleth をセットアップして AWS の ID プロバイダーとして設定する方法をステップバイステップで示したチュートリアルがあります。[セッションタグ](id_session-tags.md)を渡すように Shibboleth を設定できます。 | 

詳細については、AWS ウェブサイトの「[IAM パートナー](https://aws.amazon.com/iam/partners/)」ページを参照してください。

# 認証レスポンス用の SAML アサーションを設定する
<a name="id_roles_providers_create_saml_assertions"></a>

組織内でユーザーの ID が確認すると、外部 ID プロバイダー (IdP) が AWS サインインエンドポイント URL に認証応答を送信します。このレスポンスは、[HTTP POST Binding for SAML 2.0](http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) 標準に従った SAML トークンを含み、さらに以下の要素または*クレーム*を含む POST リクエストであることが必要です。これらのクレームを SAML 互換 IdP に設定します。これらのクレームの入力方法については、IdP のドキュメントを参照してください。

IdP が AWS へのクレームを含むレスポンスを送信すると、多くの受信クレームは AWS コンテキストキーにマッピングされます。これらのコンテキストキーは `Condition` 要素を使用して IAM ポリシーにチェックインすることができます。使用可能なマッピングの一覧は、「[SAML 属性の AWS 信頼ポリシーコンテキストキーへのマッピング](#saml-attribute-mapping)」に掲載されています。

## `Subject` および `NameID`
<a name="saml_subject-name-id"></a>

応答には、`NotOnOrAfter` 属性と `Recipient` 属性の両方を含む `SubjectConfirmationData` 要素を持つ `SubjectConfirmation` 要素が 1 つだけ含まれている必要があります。受取人属性には、AWS サインインエンドポイント URL に一致する値を含める必要があります。IdPによっては、この属性を `ACS`、`Recipient`、または `Target` と呼ぶことがあります。

SAML 暗号化が必要な場合、サインイン URL に SAML プロバイダーに割り当てる一意の識別子 AWS が含まれている必要があります。この識別子は ID プロバイダーの詳細ページで確認できます。次の例は、オプションの `region-code` を使用したサインイン URL 形式を示しています。

`https://region-code.signin.aws.amazon.com/saml`

次の例では、サインイン URL に一意の識別子が含まれているため、サインインパスに /acs/ を追加する必要があります。

`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[Region]** (リージョン) 列を参照します。AWS 値には、グローバルサインインエンドポイント `https://signin.aws.amazon.com/saml` を使用することもできます。

`NameID` 要素は、永続的な値、一時的な値で構成することも、IdP ソリューションから提供される完全な URI で構成することもできます。永続的な値は、`NameID` の値がセッション間のユーザーでも同じになることを意味します。値が一時的な場合、ユーザーの `NameID` 値はセッションごとに異なります。シングルサインオン操作では、次の識別子タイプをサポートします。
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:entity`

例を以下に示します。マークされた値を独自の値に置き換えます。

```
<Subject>
  <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">_cbb88bf52c2510eabe00c1642d4643f41430fe25e3</NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData NotOnOrAfter="2013-11-05T02:06:42.876Z" Recipient="https://region-code.signin.aws.amazon.com/saml/SAMLSP4SHN3UIS2D558H46"/>
  </SubjectConfirmation>
</Subject>
```

**重要**  
`saml:aud` コンテキストキーは SAML 受取人属性から取得します。この属性は、SAML バージョンの OIDC オーディエンスフィールドと言えるものだからです (例えば、`accounts.google.com:aud`)。

## `PrincipalTag` SAML 属性
<a name="saml_role-session-tags"></a>

（オプション） `Name` 属性が `https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}` に設定された `Attribute` 要素を使用できます。この要素を使用すると、SAML アサーションでセッションタグとして属性を渡すことができます。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

属性をセッションタグとして渡すには、タグの値を指定する `AttributeValue` 要素を含めます。たとえば、タグのキーバリューのペア `Project` = `Marketing` と `CostCenter` = `12345` を渡すには、次の属性を使用します。タグごとに個別の `Attribute` 要素を含めます。

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project">
  <AttributeValue>Marketing</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter">
  <AttributeValue>12345</AttributeValue>
</Attribute>
```

上記のタグを推移的として設定するには、`Attribute` 属性を `Name` に設定した別の `https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys` 要素を含めます。これは、セッションタグを推移的として設定するオプションの多値属性です。推移タグは、SAML セッションを使用して AWS で別のロールを引き受けるときに保持されます。これは、[ロールの連鎖](id_roles.md#iam-term-role-chaining)と呼ばれます。たとえば、`Principal` タグ と `CostCenter` タグの両方を推移的として設定するには、次の属性を使用してキーを指定します。

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <AttributeValue>Project</AttributeValue>
  <AttributeValue>CostCenter</AttributeValue>
</Attribute>
```

## `Role` SAML 属性
<a name="saml_role-attribute"></a>

`Name` 属性が `https://aws.amazon.com/SAML/Attributes/Role` に設定された `Attribute` 要素を使用できます。この要素には、IdP によってユーザーがマッピングされている IAM SAML ID プロバイダーおよびロールおよびを一覧表示する `AttributeValue` 要素が 1 つ以上含まれます。IAM ロールと IAM ID プロバイダーは、[AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)に渡される `RoleArn` パラメーターと `PrincipalArn` パラメーターと同じ形式でコンマ区切りの ARN のペアとして指定されます。この要素には、少なくとも 1 つのロールとプロバイダーのペア（`AttributeValue` 要素）を含める必要があり、複数のペアを含めることができます。要素に複数のペアを含める場合、ユーザーが WebSSO を使用して AWS マネジメントコンソール にサインインすると、引き受けるロールを選択する画面が表示されます。

**重要**  
`Name` タグの `Attribute` 属性の値は大文字と小文字が区別されます。これは厳密に `https://aws.amazon.com/SAML/Attributes/Role` に設定する必要があります。

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/Role">
  <AttributeValue>arn:aws:iam::account-number:role/role-name1,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
  <AttributeValue>arn:aws:iam::account-number:role/role-name2,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
  <AttributeValue>arn:aws:iam::account-number:role/role-name3,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
</Attribute>
```

## `RoleSessionName` SAML 属性
<a name="saml_role-session-attribute"></a>

`Name` 属性が `https://aws.amazon.com/SAML/Attributes/RoleSessionName` に設定された `Attribute` 要素を使用できます。この要素には、ロールが引き継がれたときに発行される一時的な認証情報の識別子を提供する `AttributeValue` 要素が1つ含まれています。これを使用して、アプリケーションを使用しているユーザーに一時的な認証情報を関連付けることができます。この要素は、AWS マネジメントコンソールでユーザー情報を表示するときに使用されます。`AttributeValue` 要素の値は 2～64 文字で、英数字、アンダースコア、および **. , \$1 = @ -** (ハイフン).のみを含めることができます。スペースを含めることはできません。通常、この値はユーザー ID (`john`) またはメールアドレス (`johndoe@example.com`) です。ユーザーの表示名 (`John Doe`) のように、スペースを含む値とすることはできません。

**重要**  
`Name` タグの `Attribute` 属性の値は大文字と小文字が区別されます。これは厳密に `https://aws.amazon.com/SAML/Attributes/RoleSessionName` に設定する必要があります。

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName">
  <AttributeValue>user-id-name</AttributeValue>
</Attribute>
```

## `SessionDuration` SAML 属性
<a name="saml_role-session-duration"></a>

（オプション） `Name` 属性が `https://aws.amazon.com/SAML/Attributes/SessionDuration"` に設定された `Attribute` 要素を使用できます。この要素には、ユーザーが新しい一時的な認証情報をリクエストする前に、ユーザーが AWS マネジメントコンソール にアクセスできる時間を指定する 1 つの `AttributeValue` 要素が含まれます。値は、セッションの秒数を表す整数です。値の範囲は 900 秒 (15 分) から 43200 秒 (12 時間) です。この属性が存在しない場合は、認証情報は 1 時間有効です (`DurationSeconds` API の `AssumeRoleWithSAML` パラメータのデフォルト値)。

この属性を使用するには、AWS マネジメントコンソール でコンソールのサインインウェブエンドポイントを通じて `https://region-code.signin.aws.amazon.com/saml` へのシングルサインオンアクセスを提供する SAML プロバイダーを設定する必要があります。実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[Region]** (リージョン) 列を参照します。任意で次のURL `https://signin.aws.amazon.com/static/saml` が使用できます。この属性が AWS マネジメントコンソール にのみセッションを拡張することに注意してください。他の認証情報の存続期間を延長することはできません。ただし、`AssumeRoleWithSAML` API コール中に存在する場合は、セッション期間を*短縮*するために使用できます。呼び出しによって返される認証情報のデフォルトの有効期間は 60 分です。

また、`SessionNotOnOrAfter` 属性も定義されている場合は、2つの属性の***小さい方***の値、`SessionDuration` または `SessionNotOnOrAfter` がコンソールセッションの最大期間を確立することにも注意してください。

コンソールセッションを拡張された期間有効にする場合、認証情報が侵害されるリスクが高まります。このリスクを軽減するには、IAM コンソールの [**Role Summary**] ページで、[**Revoke Sessions**] を選択して、どのロールのアクティブなコンソールセッションもすぐに無効にできます。詳細については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](id_roles_use_revoke-sessions.md)」を参照してください。

**重要**  
`Name` タグの `Attribute` 属性の値は大文字と小文字が区別されます。これは厳密に `https://aws.amazon.com/SAML/Attributes/SessionDuration` に設定する必要があります。

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SessionDuration">
  <AttributeValue>1800</AttributeValue>
</Attribute>
```

## `SourceIdentity` SAML 属性
<a name="saml_sourceidentity"></a>

（オプション） `Name` 属性が `https://aws.amazon.com/SAML/Attributes/SourceIdentity` に設定された `Attribute` 要素を使用できます。この要素には、1 つのIAM ロールを使用しているユーザーまたはアプリケーションの識別子を提供する `AttributeValue` 要素が含まれています。SAML セッションを使用して、[ロールチェーン](id_roles.md#iam-term-role-chaining)と呼ばれる AWS の別のロールを引き受ける場合、ソースIDの値は保持されます。ソース ID の値は、ロールセッション中に実行されるすべてのアクションのリクエストに存在します。設定される値は、ロールセッション中に変更できません。その後、管理者は AWS CloudTrail ログを使用して、ソース ID 情報をモニタリングおよび監査し、共有ロールでアクションを実行したユーザーを特定します。

`AttributeValue` 要素の値は 2～64 文字で、英数字、アンダースコア、および **. , \$1 = @ -** (ハイフン).のみを含めることができます。スペースを含めることはできません。値は通常、ユーザーID（`john`）やメールアドレス（`johndoe@example.com`）など、ユーザーに関連付けられている属性です。ユーザーの表示名 (`John Doe`) のように、スペースを含む値とすることはできません。ソースアイデンティティの使用の詳細については、「[引き受けたロールで実行されるアクションのモニタリングと制御](id_credentials_temp_control-access_monitor.md)」を参照してください。

**重要**  
SAML アサーションが [`SourceIdentity`](#saml_sourceidentity) 属性を使用するように設定されている場合、信頼ポリシーにも `sts:SetSourceIdentity` アクションを含める必要があります。ソースアイデンティティの使用の詳細については、「[引き受けたロールで実行されるアクションのモニタリングと制御](id_credentials_temp_control-access_monitor.md)」を参照してください。

ソース ID 属性を渡すには、ソース ID の値を指定する `AttributeValue` 要素を含めます。たとえば、ソース ID `Diego` を渡すには次の属性を使用します。

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
  <AttributeValue>Diego</AttributeValue>
```

## SAML 属性の AWS 信頼ポリシーコンテキストキーへのマッピング
<a name="saml-attribute-mapping"></a>

このセクションの表では、よく使用される SAML 属性や、それらと AWS の信頼ポリシー条件コンテキストキーのマッピングを一覧で示します。これらのキーを使用して、ロールへのアクセスを制御できます。そのためには、SAML アクセスリクエストに付随するアサーションに含まれる値とキーを比較します。

**重要**  
これらのキーは、IAM 信頼ポリシー (誰がロールを利用するかを定義するポリシー) でのみ利用でき、アクセス許可ポリシーには適用できません。

eduPerson および eduOrg 属性の表では、値は文字列または文字列のリストとして型付けされています。文字列値の場合、`StringEquals` または `StringLike` 条件を使用して、IAM 信頼ポリシーでこれらの値をテストできます。文字列のリストを含む値の場合、`ForAnyValue` および `ForAllValues` [ポリシー set 演算子](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)を使用して、信頼ポリシーで値をテストできます。

**注記**  
AWS コンテキストキーごとに含めることができるクレームは 1 つだけです。複数含めた場合は、1 つのクレームのみが対応付けられます。

次の表は、eduPerson 属性と eduOrg 属性を示しています。


| eduPerson 属性または eduOrg 属性 (`Name` キー) | この AWS コンテキストキー (`FriendlyName` キー) へのマッピング | タイプ | 
| --- | --- | --- | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.1`   |   `eduPersonAffiliation`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.2`   |   `eduPersonNickname`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.3`   |   `eduPersonOrgDN`   |  String  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.4`   |   `eduPersonOrgUnitDN`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.5`   |   `eduPersonPrimaryAffiliation`   |  String  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.6`   |   `eduPersonPrincipalName`   |  String  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.7`   |   `eduPersonEntitlement`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.8`   |   `eduPersonPrimaryOrgUnitDN`   |  String  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.9`   |   `eduPersonScopedAffiliation`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.10`   |   `eduPersonTargetedID`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.11`   |   `eduPersonAssurance`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.2`   |   `eduOrgHomePageURI`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.3`   |   `eduOrgIdentityAuthNPolicyURI`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.4`   |   `eduOrgLegalName`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.5`   |   `eduOrgSuperiorURI`   |  文字列のリスト  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.6`   |   `eduOrgWhitePagesURI`   |  文字列のリスト  | 
|   `urn:oid:2.5.4.3`   |   `cn`   |  文字列のリスト  | 

次の表は、Active Directory 属性を示しています。


| AD 属性 | この AWS コンテキストキーへのマッピング | タイプ | 
| --- | --- | --- | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`  |  `name`  |  文字列  | 
|  `http://schemas.xmlsoap.org/claims/CommonName`  |  `commonName`  |  文字列  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`  |  `givenName`  |  文字列  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`  |  `surname`  |  文字列  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`  |  `mail`  |  文字列  | 
|  `http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid`  |  `uid`  |  String  | 

次の表は、X.500 属性を示しています。


| X.500 属性 | この AWSコンテキストキーへのマッピング | タイプ | 
| --- | --- | --- | 
|  `2.5.4.3`  |  `commonName`  |  文字列  | 
|  `2.5.4.4`  |  `surname`  |  文字列  | 
|  `2.4.5.42`  |  `givenName`  |  文字列  | 
|  `2.5.4.45`  |  `x500UniqueIdentifier`  |  文字列  | 
|  `0.9.2342.19200300100.1.1`  |  `uid`  |  文字列  | 
|  `0.9.2342.19200300100.1.3`  |  `mail`  |  文字列  | 
|  `0.9.2342.19200300.100.1.45`  |  `organizationStatus`  |  String  | 

# SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス
<a name="id_roles_providers_enable-console-saml"></a>

SAML フェデレーティッドプリンシパルの AWS マネジメントコンソール へのアクセスを許可するため、ロールを使用して SAML 2.0 互換 ID プロバイダー (IdP) および AWS を設定できます。このロールは、コンソールでタスクを実行するユーザーアクセス権限を付与します。AWS にアクセスするその他の方法を SAML フェデレーティッドプリンシパルに許可する場合、次のいずれかのトピックを参照してください。
+ AWS CLI: [IAM ロールに切り替える (AWS CLI)](id_roles_use_switch-role-cli.md)
+ [IAM ロールに切り替える (Tools for Windows PowerShell)](id_roles_use_switch-role-twp.md) Tools for Windows PowerShell
+ AWS API:[IAM ロールを切り替える (AWS)](id_roles_use_switch-role-api.md)

## 概要:
<a name="enable-console-saml-overview"></a>

次の図は、SAML 対応のシングルサインオンについて処理の流れを示しています。

**注記**  
この SAML の使用方法の場合、ワークフローでユーザーに代わって AWS マネジメントコンソールを開くため、[SAML 2.0 フェデレーション](id_roles_providers_saml.md) に示されている一般的な使用方法とは異なります。これには、`AssumeRoleWithSAML` API を直接呼び出す代わりに、AWS サインインエンドポイントを使用する必要があります。エンドポイントはユーザーの代わりに API を呼び出し、URL を返すと、それによってユーザーのブラウザが AWS マネジメントコンソールへ自動的にリダイレクトされます。

![\[SAML を使用した AWS マネジメントコンソールへのシングルサインオン (SSO)\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/saml-based-sso-to-console.diagram.png)


この図は、以下のステップを示しています。

1. ユーザーは組織のポータルにアクセスして、AWS マネジメントコンソール に移動するオプションを選択します。一般的に、組織のポータルは、組織と AWS 間の信頼の交換を処理する IdP の機能です。たとえば、Active Directory フェデレーションサービスでは、ポータル URL は次のようになります。`https://ADFSServiceName/adfs/ls/IdpInitiatedSignOn.aspx`

1. ポータルが組織内のユーザーの ID を確認します。

1. ポータルは、ユーザーを識別するアサーションを含む SAML アサーションレスポンスを生成し、ユーザーの属性を含めます。コンソールセッションが有効な期間を指定する `SessionDuration` という SAML アサーションの属性を含むよう IdP を設定できます。[セッションタグ](id_session-tags.md)として属性を渡すように IdP を設定することもできます。ポータルはこのレスポンスをクライアントブラウザに送信します。

1. クライアントブラウザは AWS のシングルサインオンエンドポイントにリダイレクトされ、SAML アサーションを投稿します。

1. エンドポイントは、ユーザーの代わりに一時的なセキュリティ認証情報をリクエストし、コンソールのサインイン URL を作成します。

1. AWS は、サインイン URL をクライアントにリダイレクトとして送信します。

1. クライアントのブラウザは AWS マネジメントコンソールにリダイレクトされます。複数の IAM ロールに対応付けられた属性を SAML 認証レスポンスが含む場合は、最初にコンソールへのアクセスするためのロールを選択する画面が表示されます。

ユーザーの立場では、この処理を意識することはありません。ユーザーは組織の内部ポータルから AWS マネジメントコンソール に移動するだけで、AWS 認証情報を指定する必要はありません。

以下のセクションでは、この動作を設定する方法の概要と、詳細なステップへのリンクをご紹介します。

## ネットワークを AWS の SAML プロバイダーとして設定する
<a name="fedconsole-config-network-as-saml"></a>

組織のネットワーク内で、組織の ID ストア (Windows Active Directory など) が、Windows Active Directory Federation Services や Shibboleth などの SAML ベースの IdP と連携するように設定します。IdP を使用して、組織を IdP として記述し、認証キーを含むドキュメントメタデータを生成します。また、AWS マネジメントコンソール ルートユーザーに対するユーザーリクエストを AWS SAML エンドポイントにルーティングして、SAML アサーションを使って認証するように、組織のポータルを設定します。metadata.xml ファイルを生成するための IdP の設定方法は、IdP によって異なります。手順については IdP の文書を参照してください。また、[サードパーティーの SAML ソリューションプロバイダーを AWS に統合する](id_roles_providers_saml_3rd-party.md) には、サポートされる数多くの SAML プロバイダーのウェブドキュメントへのリンクが掲載されています。

## IAMで SAML プロバイダーを作成するには
<a name="fedconsole-create-saml-provider"></a>

次に、AWS マネジメントコンソール にサインインし、IAM コンソールへ移動します。ここで、新しい SAML プロバイダーを作成します。これは、組織の IdP に関する情報を保持する IAM のエンティティです。このプロセスの一環として、前のセクションで組織の IdP ソフトウェアによって生成されたメタデータドキュメントをアップロードします。詳細については、「[IAM で SAML ID プロバイダーを作成する](id_roles_providers_create_saml.md)」を参照してください。

## SAML フェデレーティッドプリンシパル用に AWS でアクセス許可を設定する
<a name="fedconsole-grantperms"></a>

次のステップでは、IAM と組織の IdP の間の信頼関係を確立する IAM ロールを作成します。このロールは、フェデレーションの目的で IdP をプリンシパル（信頼されたエンティティ）として識別します。ロールは、組織の IdP によって認証されたユーザーが AWS で何を実行できるかも定義します。このロールは、IAM コンソールを使用して作成できます。ロールを引き受けることができるユーザーを示す信頼ポリシーを作成するときは、前述の IAM で作成した SAML プロバイダーを指定します。また、ユーザーがロールを引き受けるために一致する必要がある 1 つ以上の SAML 属性も指定します。たとえば、SAML の `[eduPersonOrgDN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_edupersonorgdn)` 値が `ExampleOrg` であるユーザーのみにサインインを許可するように指定できます。ロールウィザードは、そのロールが AWS マネジメントコンソールへのサインインだけで引き受けられるように、`saml:aud` 属性をテストする条件を自動的に追加します。

SAML 暗号化が必要な場合、サインイン URL に SAML プロバイダーに割り当てる一意の識別子 AWS が含まれている必要があります。この識別子は ID プロバイダーの詳細ページで確認できます。ロールの信頼ポリシーは次のようなものです。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "saml:edupersonorgdn": "ExampleOrg",
                    "saml:aud": "https://region-code.signin.aws.amazon.com/saml/acs/SAMLSP4SHN3UIS2D558H46"
                }
            }
        }
    ]
}
```

------

**注記**  
ロール信頼ポリシーで使用される SAML IDP は、そのロールと同じアカウントにある必要があります。

`https://region-code.signin.aws.amazon.com/static/saml-metadata.xml` の `saml:aud` 属性にはリージョンのエンドポイントを使用することをお勧めします。実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[Region]** (リージョン) 列を参照します。

ロールの[アクセス許可ポリシー](access_policies.md)では、任意のロール、ユーザー、グループに付与するアクセス許可を指定します。たとえば、組織のユーザーが Amazon EC2 インスタンスを管理することを許可する場合、アクセス許可ポリシーで明示的に Amazon EC2 アクションを許可します。これは、**Amazon EC2 Full Access** 管理ポリシーなどの[管理ポリシー](access_policies_manage-attach-detach.md)を割り当てることでも行えます。

SAML IdP のロールの作成に関する詳細については、「[SAML 2.0 フェデレーション用のロールを作成する (コンソール)](id_roles_create_for-idp_saml.md)」を参照してください。

## 設定の完了と SAML アサーションの作成
<a name="fedconsole-configassertions"></a>

`https://region-code.signin.aws.amazon.com/static/saml-metadata.xml` または `https://signin.aws.amazon.com/static/saml-metadata.xml` にある `saml-metadata.xml` ファイルをインストールし、AWS がお客様のサービスプロバイダーであることを SAML IdP に通知します。SAMl 暗号化が必要な場合、`https://region-code.signin.aws.amazon.com/static/saml/SAMLSP4SHN3UIS2D558H46/saml-metadata.xml` にあるファイルを使用してください。

実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[Region]** (リージョン) 列を参照します。

ファイルのインストール方法は IdP によって異なります。プロバイダーによっては、URL の入力を選択できる場合があります。この場合、IdP がお客様の代わりにファイルを取得してインストールします。また、URL からファイルをダウンロードし、ローカルファイルとして指定する必要があるプロバイダーもあります。詳細については IdP の文書を参照してください。また、[サードパーティーの SAML ソリューションプロバイダーを AWS に統合する](id_roles_providers_saml_3rd-party.md) には、サポートされる数多くの SAML プロバイダーのウェブドキュメントへのリンクが掲載されています。

また、認証レスポンスの一部として、IdP から AWS へ SAML 属性として渡す情報も設定します。この情報のほとんどは、ポリシーで評価できる条件コンテキストキーとして AWS に表示されます。これらの条件キーにより、適切なコンテキストで許可されたユーザーのみに、AWS リソースにアクセスするアクセス許可が付与されます。コンソールを使用するタイミングを制限する時間ウィンドウを指定できます。ユーザーが認証情報を更新する前にコンソールにアクセスできる最大時間（最大 12 時間）を指定できます。詳細については、[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md) を参照してください

# ブラウザに SAML レスポンスを表示する
<a name="troubleshoot_saml_view-saml-response"></a>

次の手順では、SAML 2.0 に関連する問題のトラブルシューティング時に、ブラウザからサービスプロバイダーからの SAML 応答を表示する方法について説明します。

すべてのブラウザに共通して、問題を再現できるページに移動します。次に、ブラウザごとの適切なステップに従います。

**Topics**
+ [

## Google Chrome
](#chrome)
+ [

## Mozilla Firefox
](#firefox)
+ [

## Apple Safari
](#safari)
+ [

## Base64 エンコードされた SAML レスポンスの処理
](#whatnext)

## Google Chrome
<a name="chrome"></a>

**Chrome で SAML レスポンスを表示するには**

これらのステップは、Google Chrome のバージョン 106.0.5249.103 (公式ビルド) (arm64) を使用してテストされました。別のバージョンを使用している場合、それに応じてステップの調整が必要になることがあります。

1. **F12** キーを押して、**[Developer Tools]** (デベロッパーツール) コンソールを開始します。

1. **[Network]** (ネットワーク) タブを選択し、**[Developer Tools]** (デベロッパーツール) ウィンドウの左上にある **[Preserve log]** (ログを保存) を選択します。

1. 問題を再現します。

1. (オプション) **[Developer Tools]** (デベロッパーツール) の **[Network]** (ネットワーク) ログペインに **[Method]** (メソッド) 列が表示されない場合は、任意の列ラベルを右クリックし、**[Method]** (メソッド) を選択して列を追加します。

1. **[Developer Tools]** (デベロッパーツール) の **[Network]** (ネットワーク) ログペインで **[SAML Post]** (SAML 投稿) を探します。その行を選択し、上部にある **[Payload]** (ペイロード) タブを表示します。エンコードされたリクエストを含む **[SAMLResponse]** 要素を探します。関連する値は、Base64 でエンコードされたレスポンスです。

## Mozilla Firefox
<a name="firefox"></a>

**Firefox で SAML レスポンスを表示するには**

この手順は、Mozilla Firefox のバージョン 105.0.3 (64 ビット) でテストされています。別のバージョンを使用している場合、それに応じてステップの調整が必要になることがあります。

1. **F12** を押して、**[Web Developer Tools]** (ウェブデベロッパーツール) コンソールを起動します。

1. [**Network (ネットワーク)**] タブを選択します。

1. **[Web Developer Tools]** (ウェブデベロッパーツール) ウィンドウの右上で、オプション (小さな歯車のアイコン) を選択します。**[Persist logs]** (永続ログ) を選択します。

1. 問題を再現します。

1. (オプション) **[Web Developer Tools]** (ウェブデベロッパーツール) の **[Network]** (ネットワーク) ログペインに **[Method]** (メソッド) 列が表示されない場合は、任意の列ラベルを右クリックし、**[Method]** (メソッド) を選択して列を追加します。

1. テーブルで [**POST** **SAML**] を見つけます。その行を選択し、**[Request]** (リクエスト) タブを表示して **SAMLResponse** 要素を見つけます。関連する値は、Base64 でエンコードされたレスポンスです。

## Apple Safari
<a name="safari"></a>

**Safari で SAML レスポンスを表示するには**

これらのステップは、Apple Safari のバージョン 16.0 (17614.1.25.9.10, 17614) を使用してテストされました。別のバージョンを使用している場合、それに応じてステップの調整が必要になることがあります。

1. Safari で Web Inspector を有効にします。[**設定**] ウィンドウを開き、[**Advanced (詳細)**] タブを選択して、[**Show Develop menu in the menu bar (メニューバーに開発メニューを表示)**] を選択します。

1. ここで Web Inspector を開くことができます。メニューバーで **[Develop]** (開発) を選択し、**[Show Web Inspector]** (Web インスペクターを表示) を選択します。

1. [**Network (ネットワーク)**] タブを選択します。

1. **[Web Inspector]** (Web インスペクター) ウィンドウの左上で、オプション (3 本の水平線を含む小さな円のアイコン) を選択します。**[Preserve Log]** (ログを保存) を選択します。

1. (オプション) **[Web Inspector]** (Web インスペクター) の **[Network]** (ネットワーク) ログペインに **[Method]** (メソッド) 列が表示されない場合は、任意の列ラベルを右クリックし、**[Method]** (メソッド) を選択して列を追加します。

1. 問題を再現します。

1. テーブルで [**POST** **SAML**] を見つけます。その行を選択し、[Headers] (ヘッダー) タブを表示します。

1. エンコードされたリクエストを含む **[SAMLResponse]** 要素を探します。下にスクロールして、`Request Data` という名前の `SAMLResponse` を探します。関連する値は、Base64 でエンコードされたレスポンスです。

## Base64 エンコードされた SAML レスポンスの処理
<a name="whatnext"></a>

ブラウザで Base64 エンコードされた SAML レスポンスエレメントが見つかったら、それをコピーし、任意の Base64 デコードツールを使用して、XML タグの付いたレスポンスを抽出します。

**セキュリティのヒント**  
表示している SAML レスポンスデータには重要なデータが含まれる場合があるため、*オンライン*の base64 デコーダを使用しないことをお勧めします。代わりに、ローカルコンピュータにインストールされた、ネットワーク経由で SAML データを送信しないツールを使用します。

**Windows システムの組み込みオプション (PowerShell):**

```
PS C:\> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("base64encodedtext"))
```

**MacOS および Linux システムの組み込みオプション:**

```
$ echo "base64encodedtext" | base64 --decode
```

**デコードされたファイルの値を確認する**  
デコードされた SAML レスポンスファイルの値を確認します。
+ saml:NameID 属性の値が認証されたユーザーのユーザー名と一致することを確認します。
+ https://aws.amazon.com/SAML/Attributes/Role の値を確認します。ARN と SAML プロバイダーでは大文字と小文字が区別され、[ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) はアカウントのリソースと一致する必要があります。
+ https://aws.amazon.com/SAML/Attributes/RoleSessionName の値を確認します。値は、[クレームルール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_relying-party.html)の値と一致する必要があります。
+ E メールアドレスまたはアカウント名に属性値を設定する場合は、値が正しいことを確認してください。値は、認証されたユーザーの E メールアドレスまたはアカウント名に対応する必要があります。

**エラーをチェックして設定を確認する**  
値にエラーが含まれているかどうかを確認し、次の設定が正しいことを確認します。
+ クレームルールは必須要素を満たし、すべての ARN が正しい。詳細については、「[証明書利用者の信頼およびクレームの追加によって SAML 2.0 IdP を設定する](id_roles_providers_create_saml_relying-party.md)」を参照してください。
+ IdP から最新のメタデータファイルを SAML プロバイダーで AWS にアップロードしました。詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。
+ IAM ロールの信頼ポリシーを正しく設定しました。詳細については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。

# AWS ID を外部サービスにフェデレーションする
<a name="id_roles_providers_outbound"></a>

IAM アウトバウンド ID フェデレーションを使用すると、AWS ワークロードは、長期間有効な認証情報を保存しなくても外部サービスに安全にアクセスできます。AWS ワークロードは、[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API を呼び出すことで、AWSSecurity Token Service (AWS STS) から有効期間の短い JSON ウェブトークン (JWT) をリクエストできます。これらのトークンは、暗号化によって署名され、パブリックに検証可能であり、AWS ワークロードの ID を外部サービスにアサートする包括的な一連のクレームを含んでいます。これらのトークンは、さまざまなサードパーティーのクラウドプロバイダー、SaaS プラットフォーム、セルフホストのアプリケーションで使用できます。外部サービスは、既知のエンドポイントで公開されている AWS の検証キーを使用してトークンの信頼性を検証し、トークンの情報を使用して認証と承認の判断を下します。

アウトバウンド ID フェデレーションを使用すると、API キーやパスワードなど有効期間の長い認証情報を、アプリケーションコードや環境変数に保存する必要がなくなり、セキュリティ体制が向上します。IAM ポリシーを使用して、トークン生成へのアクセスを制御し、署名アルゴリズムや許可された対象者、期間などのトークンプロパティを適用できます。すべてのトークンリクエストは AWS に記録され、セキュリティモニタリングとコンプライアンスレポートの完全な監査証跡を提供します。カスタムのクレームとして表示されるタグを使用して、トークンをカスタマイズすることもできます。それにより、外部サービスはきめ細かい、属性ベースのアクセスコントロールを実装することができます。

## 一般的なユースケース
<a name="outbound-federation-use-cases"></a>

アウトバウンド ID フェデレーションを使用すると、AWS ワークロードは次のことを安全に実行できます。
+ 外部のクラウドプロバイダーのリソースとサービスにアクセスできます。例えば、データを処理する Lambda 関数は、外部のクラウドプロバイダーのストレージサービスに結果を書き込んだり、それらのデータベースをクエリしたりできます。
+ 分析、データ処理、モニタリングなどのために、外部の software-as-a-service (SaaS) プロバイダーと統合できます。例えば、Lambda 関数はオブザーバビリティプラットフォームにメトリクスを送信できます。
+ AWS、外部のクラウドプロバイダー、オンプレミスのデータセンターのいずれかでホストされている独自のアプリケーションで認証を行い、安全なハイブリッドおよびマルチクラウドのアーキテクチャを実現できます。例えば、AWS ワークロードは、オンプレミスの Kubernetes クラスターで実行されているコンテナ化されたアプリケーションとやり取りが行えます。

## 仕組み
<a name="outbound-federation-how-it-works"></a>

![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/outbound-use-cases.png)


1. Lambda 関数は、[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API を呼び出して、AWS Security Token Service (AWS STS) から JSON ウェブトークン (JWT) をリクエストします。

1. AWS STS は、このリクエストを検証し、署名付き JWT を Lambda 関数に返します。

1. Lambda 関数は、この JWT を外部サービスに送信します。

1. 外部サービスは、トークンから発行者 URL を抽出し、信頼できる既知の発行者と一致することを確認し、OIDC 検出エンドポイントから AWS の検証キーとメタデータを取得します。

1. 外部サービスは、この検証キーを使ってトークンの署名を検証し、有効期限、サブジェクト、対象者などのクレームを検証します。

1. 検証に成功すると、外部サービスは Lambda 関数へのアクセスを許可します。

# アウトバウンド ID フェデレーションの開始方法
<a name="id_roles_providers_outbound_getting_started"></a>

このガイドでは、AWS アカウントでアウトバウンド ID フェデレーションを有効にし、最初の JSON ウェブトークン (JWT) を取得する方法について解説します ([GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API を使用)。この機能を有効にして、外部サービスとの信頼関係を設定し、IAM のアクセス許可を設定し、AWS CLI または AWS SDK for Python (Boto3) を使用してトークンをリクエストします。

## 前提条件
<a name="outbound-federation-prerequisites"></a>

開始する前に、以下を確認してください。
+ 最新バージョンの AWS CLI または Python 3.8 (以降) と Boto3 をインストール済み (AWS SDK の例の場合)
+ 信頼関係を設定できる外部サービスアカウント (外部クラウドプロバイダー、SaaS プロバイダー、テストアプリケーションなど)

**注記**  
`GetWebIdentityToken` API は STS Global エンドポイントでは使用できません。
`GetWebIdentityToken` API によって生成された JSON ウェブトークン (JWT) は、AWS への ([AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API を介した) OpenID Connect (OIDC) フェデレーションには使用できません。

## アカウントでアウトバウンド ID フェデレーションを有効にする
<a name="enable-outbound-federation"></a>

トークンをリクエストする前に、アウトバウンド ID フェデレーションを有効にする必要があります。この機能を有効にするには AWS マネジメントコンソールを使用します。[EnableOutboundWebIdentityFederation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOutboundWebIdentityFederation.html) API を使用してプログラムで有効にすることもできます。

### AWS CLI の使用
<a name="enable-using-cli"></a>

```
aws iam enable-outbound-web-identity-federation
```

### AWS SDK for Python の使用
<a name="enable-using-sdk"></a>

```
import boto3

# Create IAM client
iam_client = boto3.client('iam')

# Enable outbound identity federation
response = iam_client.enable_outbound_web_identity_federation()
print(f"Feature enabled. Issuer URL: {response['IssuerUrl']}")
print(f"Status: {response['Status']}")
```

### AWS コンソールの使用
<a name="enable-using-console"></a>

IAM に移動し、左側のナビゲーションメニューの **[アクセス管理]** のセクションで **[アカウント設定]** を選択します。

![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/outbound-screen-1.png)


この機能を有効にしたら、お使いのアカウントに固有の発行者 URL を書き留めます。この URL は、外部サービスで信頼関係を設定するときに使用します。発行者 URL は、必要に応じて [GetOutboundWebIdentityFederationInfo](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOutboundWebIdentityFederationInfo.html) API を使用して取得することもできます。

![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/outbound-screen-2.png)


## 外部サービスで信頼関係を設定する
<a name="establish-trust-relationship"></a>

AWS アカウントが発行したトークンを信頼して受け入れるように、外部サービスを設定します。具体的なステップはサービスによって異なりますが、一般的に以下の手順が含まれます。
+ AWS アカウントの発行者 URL を信頼できる ID プロバイダーとして登録する
+ 検証するクレームを設定する (対象者、サブジェクトパターン)
+ トークンクレームを外部サービスのアクセス許可にマッピングする

詳しい設定手順については、外部サービスドキュメントを参照してください。

## IAM 許可を設定する
<a name="configure-iam-permissions"></a>

[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API を呼び出すためのアクセス許可を付与する IAM ポリシーを作成し、このポリシーをトークンの生成に必要な IAM ロールにアタッチします。

以下のポリシー例では、特定の制限があるトークン生成へのアクセスを許可します。ここでは、対象者として「https://api.example.com」に対してのみトークンのリクエストを許可し、トークンの最大有効期間は 5 分 (300 秒) とします。トークンプロパティを適用する際に使用できる条件キーの一覧については、「[IAM および AWS STS の条件コンテキストキー](reference_policies_iam-condition-keys.md)」を参照してください。

### IAM ポリシーの例
<a name="example-iam-policy"></a>

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:GetWebIdentityToken",
            "Resource": "*",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "sts:IdentityTokenAudience": "https://api.example.com"
                },
                "NumericLessThanEquals": {
                    "sts:DurationSeconds": 300
                }
            }
        }
    ]
}
```

## 最初の JSON ウェブトークン (JWT) をリクエストする
<a name="request-first-jwt"></a>

JSON ウェブトークンは [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API を使用することでリクエストできます。API を呼び出すときは、次のパラメータを指定できます。
+ **Audience (必須)** トークンの意図された受信者。この値は、JWT に「aud」クレームを入力します。外部サービスは、このクレームを検証してトークンが自分たちの意図したものであることを確認します。
+ **SigningAlgorithm (必須):** トークンの署名に使用される暗号化アルゴリズム。有効な値は ES384 と RS256 です。セキュリティとパフォーマンスを最適化するときは ES384 を使用し、ECDSA をサポートしていないシステムとの互換性を高めるときは RS256 を使用します。
+ **DurationSeconds (オプション):** 秒単位で表示されるトークンの有効期間。有効な値の範囲は 60 ～ 3600 です。デフォルトは300(5分)です。セキュリティ強化のため、トークンの有効期間は短く設定することが推奨されます。
+ **Tags (オプション):** トークンにカスタムクレームとして含めるキーと値のペアのリスト。外部サービスは、これらのクレームを使って承認をきめ細かく行うことができます。

API は次のフィールドを返します。
+ **IdentityToken:** base64url でエンコードされた文字列として署名された JWT。外部サービスに対するリクエストにはこのトークンを含めます。
+ **Expiration:** トークンの有効期限を示す Unix UTC タイムスタンプ。

### AWS CLI の使用
<a name="using-aws-cli"></a>

```
aws sts get-web-identity-token \
    --audience "https://api.example.com" \
    --signing-algorithm ES384 \
    --duration-seconds 300 \
    --tags Key=team,Value=data-engineering \
           Key=environment,Value=production \
           Key=cost-center,Value=analytics
```

### AWS SDK for Python の使用
<a name="using-aws-sdk-python"></a>

```
import boto3

sts_client = boto3.client('sts')

response = sts_client.get_web_identity_token(
    Audience=['https://api.example.com'],
    DurationSeconds=300,
    SigningAlgorithm='RS256',
    Tags=[
        {'Key': 'team', 'Value': 'data-engineering'},
        {'Key': 'environment', 'Value': 'production'},
        {'Key': 'cost-center', 'Value': 'analytics'}
    ]
)

token = response['WebIdentityToken']
```

また、JWT をデコードし、PyJWT、Python–jose for Python、Nimbus JOSE\$1JWT for Java などの標準の JWT ライブラリ、または jwt.io などのデバッガーを使用して、その内容を調べることもできます。トークンに含まれるクレームの詳細については、「[トークンクレームについて](id_roles_providers_outbound_token_claims.md)」を参照してください。

## トークンを外部サービスで使用する
<a name="use-token-with-external-service"></a>

トークンを受信したら、これを外部サービスへのリクエストに含めます。方法はサービスによって異なりますが、ほとんどのサービスは承認のヘッダーでトークンを受け入れています。外部サービスは、AWS ワークロードへのアクセスを許可する前に、発行者の周知のエンドポイントから JWKS キーを取得し、トークンの署名を検証し、主要なクレームを検証するトークン検証ロジックを実装する必要があります。

## 検証キーとメタデータを OpenID Connect (OIDC) エンドポイントから取得する
<a name="fetch-verification-keys"></a>

AWS アカウントの一意の発行者 URL は、OpenID Connect (OIDC) 検出エンドポイント (トークンの検証に必要な検証キーとメタデータを含む) をホストしています。

この OIDC 検出エンドポイント URL には、一部のプロバイダーがトークンの検証に使用するメタデータが含まれています。こちらは次の場所で入手できます。

```
{issuer_url}/.well-known/openid-configuration
```

JWKS (JSON ウェブキーセット) エンドポイントには、トークン署名の検証に使用されるキーが含まれています。こちらは次の場所で入手できます。

```
{issuer_url}/.well-known/jwks.json
```

### curl を使用して JWKS を取得する
<a name="fetch-jwks-curl"></a>

```
curl https://{issuer_url}/.well-known/jwks.json
```

レスポンス:

```
{
  "keys": [
    {
      "kty": "EC",
      "use": "sig",
      "kid": "key-id-1",
      "alg": "ES384",
      "crv": "P-384",
      "x": "base64-encoded-x-coordinate",
      "y": "base64-encoded-y-coordinate"
    },
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "key-id-2",
      "n": "base64-encoded-modulus",
      "e": "AQAB"
    }
  ]
}
```

### AWS SDK for Python の使用
<a name="fetch-using-sdk"></a>

```
import requests

# Fetch Openid Configuration
open_id_config_response = requests.get("https://{issuer_url}/.well-known/openid-configuration")
open_id_config = open_id_config_response.json()

# Fetch JWKS
jwks_response = requests.get("https://{issuer_url}/.well-known/jwks.json")
jwks = jwks_response.json()
```

これらのキーは、トークンを検証するたびに取得しなくても済むようにキャッシュすることが推奨されます。

### 主要なクレームの検証
<a name="essential-claim-validations"></a>
+ **Subject (sub):** サブジェクトクレームに起こり得る IAM プリンシパル ARN パターンが含まれていることを検証します。
+ **Expiration (exp):** トークンの有効期限が切れていないことを確認します。JWT ライブラリは通常、これを自動的に処理します。
+ **Audience (aud):** 対象者がユーザーの期待値と一致することを検証します。これにより、他のサービス向けのトークンが自分のサービスで使用されることを防げます。
+ **Issuer (iss):** 発行者が信頼できる AWS アカウントと一致することを検証します。信頼できる発行者 URL のリストを管理します。

ユーザーは可能な限り、追加された AWS に固有のクレームを検証し、外部サービスにきめ細かいアクセスコントロールを実装する必要があります。例えば、org\$1id クレームを検証して AWS Organization 内の IAM プリンシパルへのアクセスを制限したり、principal\$1tags をチェックして属性ベースのアクセスコントロールを適用したり (本番環境または特定のチームのみを許可するなど)、lambda\$1source\$1function\$1arn や ec2\$1instance\$1source\$1vpc などのセッションコンテキストクレームを検証してコンピューティングリソースに基づいてアクセスを制限したりするなどです。トークンに含まれるクレームの一覧については、「[トークンクレームについて](id_roles_providers_outbound_token_claims.md)」を参照してください。

# トークンクレームについて
<a name="id_roles_providers_outbound_token_claims"></a>

[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API を呼び出すと、AWS Security Token Service によって、IAM プリンシパルのアイデンティティを表す一連のクレームを含む、署名付きの JSON ウェブトークン (JWT) が返されます。これらのトークンは [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519) に準拠しています。これらのトークンの構造と内容を理解すれば、安全な認証フローを実装し、外部サービスに適切なクレーム検証を設定し、カスタムクレームを効果的に使用して、アクセスコントロールをきめ細かく行えるようになります。

JWT には、さまざまな外部サービス間の相互運用性を促す標準の OpenID Connect (OIDC) クレーム (サブジェクト (「sub」)、対象者 (「aud」)、発行者 (「iss」) など) が含まれています。AWS STS は、AWS ID に固有のクレーム (AWS アカウント ID やプリンシパルタグなど) とセッションコンテキストのクレーム (EC2 インスタンス ARN など) を必要に応じてトークンに入力します。またカスタムのクレームを [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API にリクエストタグとして渡すことで、トークンに追加することもできます。AWS ID に固有のクレームとセッションコンテキストのクレーム、そしてカスタムクレームは、トークンの名前空間「https://sts.amazonaws.com/」の下にネストされます。

トークンに含まれるクレームの一覧については、以下のサンプルのトークンを参照してください。これらのすべてのクレームがトークン内に同時に存在するとは限りませんのでご注意ください。

```
{
  "iss": "https://abc123-def456-ghi789-jkl012.tokens.sts.global.api.aws",
  "aud": "https://api.example.com",
  "sub": "arn:aws:iam::123456789012:role/DataProcessingRole",
  "iat": 1700000000,
  "exp": 1700000900,
  "jti": "xyz123-def456-ghi789-jkl012",
  "https://sts.amazonaws.com/": {
    "aws_account": "123456789012",
    "source_region": "us-east-1",
    "org_id": "o-abc1234567",
    "ou_path": "o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/",
    "principal_tags": {
      "environment": "production",
      "team": "data-engineering",
      "cost-center": "engineering"
    },
    "lambda_source_function_arn": "arn:aws:lambda:us-east-1:123456789012:function:process-data",
    "request_tags": {
        "job-id": "job-2024-001",
        "priority": "high",
        "data-classification": "sensitive"
    }
  }
}
```

## 標準のクレーム
<a name="standard-claims"></a>

トークン内にある標準の OIDC クレームは、幅広い外部サービスとの相互運用性を促します。これらのクレームは、ほとんどの JWT ライブラリを使用して検証できます。


| Claim | 名前 | 説明 | 値の例 | 
| --- | --- | --- | --- | 
| iss | Issuer  | お使いのアカウントに固有の発行者 URL です。外部サービスは、このクレームを検証して信頼できる発行者と一致することを確認します。 | https://abc123–def456–ghi789–jkl012.tokens.sts.global.api.aws | 
| aud | 対象者 | [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) リクエストで指定された、そのトークンが対象とする受取人です。 | https://api.example.com | 
| sub | 件名 | トークンをリクエストした IAM プリンシパルの ARN です。 | arn:aws:iam::123456789012:role/DataProcessingRole | 
| iat | 発行日 | JWT が発行された時刻を特定する NumericDate 値です。 | 1700000000 | 
| exp | 有効期限 | それ以降は JWT を処理してはならない有効期限を特定する NumericDate 値です。 | 1700000900 | 
| jti | JWT ID | このトークンインスタンスの一意の識別子です。 | xyz123–def456–ghi789–jkl012 | 

## カスタムのクレーム
<a name="custom-claims"></a>

AWS STS は、標準の OIDC クレームに加えて、アイデンティティとセッションコンテキストに関するクレームを必要に応じて追加します。また、ユーザー独自のクレームを、リクエストタグとして渡すことでトークンに追加することもできます。カスタムクレームは名前空間 https://sts.amazonaws.com/ の下にネストされます。

### AWS ID クレーム
<a name="aws-identity-claims"></a>

これらのクレームは、AWS アカウント、組織構造、IAM プリンシパルに関する詳細情報を提供します。


| Claim | 説明 | 条件キーへのマップ | 値の例 | 
| --- | --- | --- | --- | 
| aws\$1account | あなたの AWS アカウント ID。 | [aws:PrincipalAccount](reference_policies_condition-keys.md#condition-keys-principalaccount) | 123456789012 | 
| source\$1region | トークンがリクエストされた AWS リージョン | [aws:RequestedRegion](reference_policies_condition-keys.md#condition-keys-requestedregion) | us–east–1 | 
| org\$1id | AWS Organizations の ID (アカウントが特定の組織に含まれる場合) | [aws:PrincipalOrgID](reference_policies_condition-keys.md#condition-keys-principalorgid) | o–abc1234567 | 
| ou\$1path | 組織単位のパス (該当する場合) | [aws:PrincipalOrgPaths](reference_policies_condition-keys.md#condition-keys-principalorgpaths) | o–a1b2c3d4e5/r–ab12/ou–ab12–11111111/ou–ab12–22222222/ | 
| principal\$1tags | IAM プリンシパルまたは引き受けられたロールセッションにアタッチされたタグ。リクエスト元の IAM プリンシパルにプリンシパルタグとセッションタグの両方がある場合にトークンがリクエストされると、セッションタグは JWT に含まれます。 | [aws:PrincipalTag/<tag-key>](reference_policies_condition-keys.md#condition-keys-principaltag) | \$1"environment": "production", "team": "data–engineering", "cost–center":"engineering"\$1 | 

### セッションコンテキストクレーム
<a name="session-context-claims"></a>

これらのクレームは、トークンリクエストの送信元のコンピューティング環境とセッションに関する情報を提供します。AWS AWS STS は、リクエストしたプリンシパルのセッションコンテキストに基づいて、これらのクレームを必要に応じて自動的に含めます。


| Claim | 説明 | 条件キーへのマップ | 値の例 | 
| --- | --- | --- | --- | 
| original\$1session\$1exp | 元のロールのセッション認証情報の有効期限 (引き受けられたロールの場合) | 該当なし | 2024–01–15T10:00:00Z | 
| federated\$1provider | フェデレーションセッションの ID プロバイダー名 | [aws:FederatedProvider](reference_policies_condition-keys.md#condition-keys-federatedprovider) | arn:aws:iam::111122223333:oidc–provider/your\$1oidc\$1provider | 
| identity\$1store\$1user\$1id | IAM アイデンティティセンターユーザー | [identitystore:UserId](reference_policies_condition-keys.md#condition-keys-identity-store-user-id) | user–abc123def456 | 
| identity\$1store\$1arn | アイデンティティセンター ID ストアの ARN | [identitystore:IdentityStoreArn](https://docs.aws.amazon.com/singlesignon/latest/userguide/condition-context-keys-sts-idc.html#condition-keys-identity-store-arn) | arn:aws:identitystore::123456789012:identitystore/d–abc1234567 | 
| ec2\$1source\$1instance\$1arn | リクエスト元の EC2 インスタンスの ARN | [ec2:SourceInstanceArn](reference_policies_condition-keys.md#condition-keys-ec2-source-instance-arn) | arn:aws:ec2:us–east–1:123456789012:instance/i–abc123def456 | 
| ec2\$1instance\$1source\$1vpc | EC2 ロールの認証情報が配信された VPC の ID | [aws:Ec2InstanceSourceVpc](reference_policies_condition-keys.md#condition-keys-ec2instancesourcevpc) | vpc–abc123def456 | 
| ec2\$1instance\$1source\$1private\$1ipv4 | EC2 インスタンスのプライベート IPv4 アドレス。 | [aws:Ec2InstanceSourcePrivateIPv4](reference_policies_condition-keys.md#condition-keys-ec2instancesourceprivateip4) | 10.0.1.25 | 
| ec2\$1role\$1delivery | インスタンスメタデータサービスのバージョン | [ec2:RoleDelivery](reference_policies_condition-keys.md#condition-keys-ec2-role-delivery) | 2 | 
| source\$1identity | プリンシパルが設定したソース ID | [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) | admin–user | 
| lambda\$1source\$1function\$1arn | 呼び出し元の Lambda 関数の ARN | [lambda:SourceFunctionArn](reference_policies_condition-keys.md#condition-keys-lambda-source-function-arn) | arn:aws:lambda:us–east–1:123456789012:function:my–function | 
| glue\$1credential\$1issuing\$1service | Glue ジョブの AWS Glue サービス識別子 | [glue:CredentialIssuingService](reference_policies_condition-keys.md#condition-keys-glue-credential-issuing) | glue.amazonaws.com | 

### リクエストタグ
<a name="request-tags"></a>

カスタムのクレームは、[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API リクエストでタグを指定することで、トークンに追加できます。これらのクレームはトークンの request\$1tags フィールドの下に表示され、承認の判断をきめ細かく行うための特定の情報を、外部サービスに渡すことを可能にします。リクエストごとに最大 50 個のタグを指定できます。

リクエストの例:

```
response = sts_client.get_web_identity_token(
    Audience=['https://api.example.com'],
    SigningAlgorithm='ES384'
    Tags=[
        {'Key': 'team', 'Value': 'data-engineering'},
        {'Key': 'cost-center', 'Value': 'analytics'},
        {'Key': 'environment', 'Value': 'production'}
    ]
)
```

トークンで生成されるクレーム

```
{
  "request_tags": {
    "team": "data-engineering",
    "cost-center": "analytics",
    "environment": "production"
  }
}
```

# IAM ポリシーによるアクセスのコントロール
<a name="id_roles_providers_outbound_policies"></a>

IAM には、アウトバウンド ID フェデレーション機能へのアクセスを制御する複数のポリシータイプが用意されています。[アイデンティティベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)を使用することで、トークンをリクエストできる IAM プリンシパルを制御し、対象者、有効期間、署名アルゴリズムなど、特定のトークンプロパティを適用することができます。[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) を使用すると、AWS Organizations 内のすべてのアカウントで、トークン生成に組織全体の制限を適用することができます。[リソースコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) (RCP) は、リソースレベルでアクセスを制御します。また、[VPC エンドポイントポリシー](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)を使用することで、VPC エンドポイントを介して AWS STS `GetWebIdentityToken` API にアクセスできるプリンシパルを制限し、セキュリティ体制にネットワークレベルのコントロールを追加することもできます。このセクションでは、これらのポリシータイプと条件キーを使用して、きめ細かいアクセスコントロールを実装する方法について説明します。

ID トークンをリクエストするには、IAM プリンシパルに `sts:GetWebIdentityToken` アクセス許可が必要です。このアクセス許可は、IAM ユーザーまたはロールにアタッチされた ID ポリシーを使用して付与します。タグ (キー、値のペア) を GetWebIdentityToken 呼び出しに渡すには、IAM プリンシパルに `sts:TagGetWebIdentityToken` アクセス許可が必要です。
+ トークンを受信できる外部サービスを制限するときは [sts:IdentityTokenAudience](reference_policies_iam-condition-keys.md#ck_identitytokenaudience) 条件キーを使用します。
+ トークンの最大有効期間を適用するときは [sts:DurationSeconds](reference_policies_iam-condition-keys.md#ck_durationseconds) 条件キーを使用します。
+ 特定の暗号化アルゴリズムを要求するときは、[sts:SigningAlgorithm](reference_policies_iam-condition-keys.md#ck_signingalgorithm) 条件キーを使用します。
+ リクエストで渡されたタグキーバリューのペアと、ポリシーで指定したタグペアを比較するときは、[aws:RequestTag](reference_policies_condition-keys.md#condition-keys-requesttag) 条件キーを使用します。
+ リクエスト内のタグキーとポリシーで指定したキーを比較するときは、[aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) 条件キーを使用します。

IAM ポリシーで使用できる条件キーの詳細については、「[IAM および AWS STS の条件コンテキストキー](reference_policies_iam-condition-keys.md)」を参照してください。

このサンプル ID ポリシーは、複数の条件キーを組み合わせています。

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowTokenGenerationWithRestrictions",
            "Effect": "Allow",
            "Action": "sts:GetWebIdentityToken",
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "sts:IdentityTokenAudience": [
                        "https://api1.example.com",
                        "https://api2.example.com"
                    ]
                },
                "NumericLessThanEquals": {
                    "sts:DurationSeconds": 300
                },
                "StringEquals": {
                    "sts:SigningAlgorithm": "ES384"
                }
            }
        }
    ]
}
```

## ベストプラクティス
<a name="outbound-best-practices"></a>

AWS ID を外部サービスに安全にフェデレーションするために、以下の推奨事項に従ってください。
+ **トークンの有効期間を短くする:** 有効期間を使用上のニーズを満たす最も短い期間に設定してトークンをリクエストします。
+ **最小特権アクセスを実装し、IAM ポリシーを使用してトークンプロパティを制限する:** `sts:GetWebIdentityToken` アクセス許可は、それを必要とする IAM プリンシパルのみに付与します。必要に応じて署名アルゴリズム、許可されたトークン対象者、トークンの最大有効期間を指定するときは条件キーを使用します。
+ **外部サービスでクレームを検証する:** セキュリティを確保するため、件名 (「sub」)、対象者 (「aud」) などの関連するクレームを必ず検証し、想定される値と一致していることを確認します。できるだけカスタムのクレームを検証し、外部サービスで承認の判断をきめ細かく行えるようにします。

# IAM の一時的な認証情報
<a name="id_credentials_temp"></a>

AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。一時的セキュリティ認証情報の機能は、長期的なアクセスキー認証情報とほとんど同じですが、次の相違点があります。
+ 一時的セキュリティ認証情報は、その名前が示すとおり、*使用期限が短く*なっています。有効期限は数分から数時間に設定できます。認証情報が失効すると、AWS はそれらを認識しなくなります。また、その認証情報によって作成された API リクエストによるあらゆるタイプのアクセスが許可されなくなります。
+ 一時的セキュリティ認証情報はユーザーとともに保存されることはなく、ユーザーのリクエストに応じて動的に生成され、提供されます。一時的セキュリティ認証情報が失効すると（または失効する前でも）、ユーザーは新しい認証情報をリクエストできます。ただし、リクエストするユーザーがまだその権限を持っている場合に限ります。

そのため、一時的な認証情報には、長期の認証情報よりも次の利点があります。
+ アプリケーションの長期の AWS セキュリティ認証情報を配布したり埋め込んだりする必要がありません。
+ ユーザーに対して AWS ID を定義せずに AWS リソースへのアクセスを許可できます。一時的認証情報は[ロール](id_roles.md)および [ID フェデレーション](id_roles_providers.md)の基本となります。
+ 一時的セキュリティ認証情報の有効期限は限られているので、認証情報が不要になった際に更新したり、明示的に取り消したりする必要がありません。一時的セキュリティ認証情報の有効期限が切れると、再利用することはできません。認証情報が有効な期間を、最大限度まで指定できます。

## AWS STS と AWS リージョン
<a name="sts-regionalization"></a>

一時的な認証情報は AWS STS によって生成されます。デフォルトでは、AWS STS は `https://sts.amazonaws.com` に 1 つのエンドポイントのあるグローバルサービスです。ただし、他のサポートされているリージョンにあるエンドポイントへの AWS STS API 呼び出しを実行することもできます。地理的に近い場所にあるリージョンのサーバーに対してリクエストを送信することによって、レイテンシー (サーバーのラグ) を低減できます。認証情報を取得したリージョンに関係なく、認証情報はグローバルに使用できます。詳細については、「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」を参照してください。

## 一時的な認証情報の一般的なシナリオ
<a name="sts-introduction"></a>

一時的な認証情報は、ID フェデレーション、委任、クロスアカウントアクセス、および IAM ロールが使用されるシナリオで便利です。

### ID フェデレーション
<a name="id-federation"></a>

AWS 以外の外部システムでユーザー ID を管理し、それらのシステムのアクセス許可からサインインするユーザーに、AWS タスクの実行や AWS リソースへのアクセスの権限を付与できます。IAM では、2 種類のアイデンティティフェデレーションがサポートされます。いずれの場合も、ID は AWS の外部に格納されます。異なる点は、外部システムが存在する場所 (データセンターまたはウェブの外部サードパーティ) です。ID フェデレーションの一時的なセキュリティ認証情報の特徴を比較するには、「[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md)」を参照してください。

外部 ID プロバイダーについては、「[ID プロバイダーと AWS とのフェデレーション](id_roles_providers.md)」を参照してください。
+ **OpenID Connect (OIDC) フェデレーション** – モバイルまたはウェブアプリケーションに対して、ユーザーに一般的なサードパーティー ID プロバイダー (Login with Amazon、Facebook、Google、OIDC 2.0 互換の任意のプロバイダーなど) を使用したサインインを求めることができます。カスタムサインインコードを作成したり、独自のユーザー ID を管理したりする必要はありません。OIDC フェデレーションを使用すると、IAM ユーザーアクセスキーなどの長期的セキュリティ認証情報をアプリケーションに配布する必要がないため、AWS アカウント を安全に保つことができます。詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。

  AWS STS OIDC フェデレーションでは、Login with Amazon、Facebook、Google、および任意の OpenID Connect (OIDC) 互換の ID プロバイダーがサポートされています。
**注記**  
モバイルアプリケーションに対しては、Amazon Cognito の使用をお勧めします。このサービスをモバイル開発用の AWS SDK と共に使用して、ユーザーの一意の ID を作成し、AWS リソースへの安全なアクセスのためにユーザーを認証できます。Amazon Cognito では、AWS STS と同じ ID プロバイダーがサポートされます。さらに、認証されていない (ゲスト) アクセスもサポートされ、ユーザーがサインインしたときにユーザーデータを移行することができます。また、Amazon Cognito には、ユーザーがデバイスを変えてもデータが保持されるように、ユーザーデータを同期するための API オペレーションも用意されています。詳細については、Amplify ドキュメントの「[Amplify による認証](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify)」を参照してください。
+ **SAML フェデレーション** - 組織のネットワークのユーザーを認証し、新しい AWS ID を作成したり、異なるサインイン認証情報でサインインすることを求めたりすることなく、それらのユーザーに AWS へのアクセスを提供できます。これは、一時アクセスに対するシングルサインオンのアプローチとして知られています。AWS STS は Security Assertion Markup Language (SAML) 2.0 のようなオープンスタンダードをサポートしており、Microsoft AD FS を通じて Microsoft Active Directory を活用することが可能です。また、SAML 2.0 を使用して、ユーザー ID フェデレーション用の独自のソリューションを管理することもできます。詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。
  + **カスタムフェデレーションブローカー** – AWS組織の認証システムを使用して リソースへのアクセスを許可することができます。シナリオの例については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。
  + **SAML 2.0 を使用したフェデレーション** – AWS 組織の認証システムと SAML を使用して、 リソースへのアクセスを許可することができます。詳細とシナリオの例については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。

### クロスアカウントアクセスのロール
<a name="role_cross-account"></a>

多くの組織は、複数の AWS アカウント を保持しています。ロールとクロスアカウントアクセスを使用すると、1 つのアカウントでユーザー ID を定義し、その ID を使用して、組織に属している他のアカウントの AWS リソースにもアクセスできるようにすることができます。これは、一時アクセスに対する*委任*アプローチとして知られています。クロスアカウントロールの作成の詳細については、「[IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)」を参照してください。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。

### Amazon EC2 の ロール
<a name="role_ec2"></a>

Amazon EC2 インスタンスでアプリケーションを実行し、これらのアプリケーションが AWS リソースにアクセスする必要がある場合は、アプリケーションの起動時に一時的セキュリティ認証情報をインスタンスに提供できます。これらの一時的なセキュリティ認証情報は、インスタンスで実行されるすべてのアプリケーションが使用できるので、インスタンスに長期的な認証情報を保存する必要がありません。詳細については、「[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する](id_roles_use_switch-role-ec2.md)」を参照してください。

IAM Amazon EC2 のロールの認証情報の詳細については、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[Amazon EC2 の IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)」を参照してください。

### その他の AWS サービス
<a name="other-services"></a>

一時的セキュリティ認証情報を使用して、ほとんどの AWS サービスにアクセスできます。一時的セキュリティ認証情報を受け入れるサービスのリストは、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照してください。

## 一時認証情報を使用するサンプルアプリケーション
<a name="id_credentials_temp_sample-apps"></a>

AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。の詳細については、「AWS STS」を参照してください。[IAM の一時的な認証情報](#id_credentials_temp)AWS STS を使用して一時的なセキュリティ認証情報を管理する方法を確認するために、完全なシナリオ例を実装する以下のサンプルアプリケーションをダウンロードできます。
+ [Windows Active Directory、ADFS、SAML 2.0 を使用して AWS へのフェデレーションを有効化する](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/) Windows アクティブディレクトリ (AD)、アクティブディレクトリフェデレーションサービス (ADFS) 2.0、SAML (セキュリティアサーションマークアップ言語) 2.0 で、エンタープライズフェデレーションを使用して AWS へのアクセスを委任する方法を示します。
+ [AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)。シングルサインオン (SSO) を有効にするカスタムフェデレーションプロキシを作成して、既存の Active Directory ユーザーが AWS マネジメントコンソール にサインインできるようにする方法を示します。
+ [Shibboleth を使用して AWS マネジメントコンソール へのシングルサインオンを行う方法](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/)。[Shibboleth](http://shibboleth.net/) と [SAML](id_roles_providers_saml.md) を使用して、AWS マネジメントコンソール へのシングルサインオン (SSO) アクセスを可能にする方法を示します。

### OIDC フェデレーションのサンプル
<a name="sts-sample-apps-wif"></a>

以下のサンプルアプリケーションは、Login with Amazon、Amazon Cognito、Facebook、Google などのプロバイダーで OIDC フェデレーションを使用する方法を示しています。これらのプロバイダーからの認証情報を一時的な AWS セキュリティ認証情報に交換して、AWS のサービスにアクセスできます。
+ [Amazon Cognitoチュートリアル](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html) – モバイル開発用の AWS SDK で Amazon Cognitoを使用することをお勧めします。Amazon Cognito は、モバイルアプリの ID を管理するための最も簡単な方法であり、同期やクロスデバイス ID のような追加機能も利用できます。Amazon Cognito の詳細については、「Amplify ドキュメント」の「[Amplify による認証](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify)」を参照してください。

## 一時的なセキュリティ認証情報のための追加リソース
<a name="id_credentials_temp_related-topics"></a>

以下のシナリオやアプリケーションは、一時的なセキュリティ認証情報の使用時に役立ちます。
+ [AWS STS SourceIdentity をアイデンティティプロバイダーと統合する方法](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/)。この記事では、Okta、Ping、OneLogin を IdP として使用し、AWS STS `SourceIdentity` 属性を設定する方法について説明します。
+  [OIDC フェデレーション](id_roles_providers_oidc.md)。このセクションでは、OIDC フェデレーションと `AssumeRoleWithWebIdentity` API を使用するときに IAM ロールを設定する方法について説明します。
+ [MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)。このトピックでは、アカウントで機密性の高い API アクションを保護するために、ロールを使用して多要素認証（MFA）を要求する方法について説明します。

AWS におけるポリシーとアクセス権限の詳細については、以下のトピックを参照してください。
+ [AWS リソースの アクセス管理](access.md)
+ [ポリシーの評価論理](reference_policies_evaluation-logic.md).
+ [Amazon Simple Storage Service ユーザーガイド](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html)の「*Amazon S3 リソースへのアクセス許可の管理*」。
+  信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。

# AWS STS 認証情報を比較する
<a name="id_credentials_sts-comparison"></a>

次の表は、一時的なセキュリティ認証情報を返す、AWS STS の API オペレーションの機能を比較したものです。ロールを引き受けることで一時的なセキュリティ認証情報をリクエストするための別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。セッションタグを渡すことができるさまざまな AWS STS API オペレーションについては、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

**注記**  
AWS STS API 呼び出しは、グローバルエンドポイントにも、リージョンのエンドポイントの 1 つに対しても送信できます。より近くのエンドポイントを選択した場合、レイテンシーを軽減し、API 呼び出しのパフォーマンスが向上します。また、元のエンドポイントとの通信ができなくなった場合は、代替リージョンのエンドポイントに呼び出しを送信することもできます。各種 AWS SDK の 1 つを使用している場合、API コールを行う前に SDK メソッドを使用してリージョンを選択します。手動で HTTP API リクエストを組み立てる場合、独自で正しいエンドポイントにリクエストを送信する必要があります。詳細については、[*リージョンとエンドポイント*の「AWS STS 」セクション](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)および「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」 を参照してください。


|  **AWS STS API**  |  **呼び出し元**  |  **認証情報の有効期間 (最小 \$1 最大 \$1 デフォルト)**  |  **MFA サポート**¹  |  **セッションポリシーのサポート**²  |  **得られた一時的な認証情報に対する制限**  | 
| --- | --- | --- | --- | --- | --- | 
|  [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)  | 既存の一時的なセキュリティ認証情報を持つ IAM ユーザーまたは IAM ロール  | 15 分 \$1 最大セッション期間設定³ \$1 1 時間  | はい  | はい |  `GetFederationToken` または `GetSessionToken` を呼び出せません。  | 
|  [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)  | 任意のユーザー。呼び出し元は、既知の ID プロバイダーからの認証を示す SAML 認証レスポンスを渡す必要があります。 | 15 分 \$1 最大セッション期間設定³ \$1 1 時間  | いいえ | はい |  `GetFederationToken` または `GetSessionToken` を呼び出せません。  | 
|  [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)  | 任意のユーザー。呼び出し元は、既知の ID プロバイダーからの認証を示す OIDC 準拠の JWT トークンを渡す必要があります。 | 15 分 \$1 最大セッション期間設定³ \$1 1 時間  | いいえ | はい |  `GetFederationToken` または `GetSessionToken` を呼び出せません。  | 
| [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | IAM ユーザーまたは AWS アカウントのルートユーザー |  IAM ユーザー: 15 分 \$1 36 時間 \$1 12 時間 ルートユーザー: 15 分 \$1 1 時間 \$1 1 時間  | いいえ  | はい  |  AWS CLI または AWS API を使用して IAM オペレーションを呼び出すことはできません。この制限はコンソールセッションには適用されません。 `GetCallerIdentity` 以外の AWS STS オペレーションは呼び出せません。⁴ コンソールへの SSO は許可されています。⁵  | 
| [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | IAM ユーザーまたは AWS アカウントのルートユーザー |  IAM ユーザー: 15 分 \$1 36 時間 \$1 12 時間 ルートユーザー: 15 分 \$1 1 時間 \$1 1 時間  | はい  | いいえ  |  リクエストに MFA 情報が含まれていない場合は、IAM API オペレーションを呼び出せません。 `AssumeRole` または `GetCallerIdentity` を除く AWS STS API オペレーションを呼び出せません。 コンソールへの SSO は許可されていません。⁶  | 

 ¹ **MFA サポート**。AssumeRole および GetSessionToken API オペレーションを呼び出すときに、多要素認証 (MFA) デバイスに関する情報を含めることができます。そうすることで、API 呼び出しによって得られた一時的なセキュリティ認証情報を、MFA デバイスで認証されたユーザーだけが使用できるようにできます。詳細については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。

 ² **セッションポリシーのサポート**。セッションポリシーは、ロールまたは AWS STS フェデレーションユーザーのセッションに一時的なセッションをプログラムで作成する際、パラメータとして渡すポリシーです。このポリシーでは、セッションに割り当てられているロールまたはユーザーのアイデンティティベースのポリシーのアクセス許可を制限しています。結果として得られるセッションのアクセス許可は、エンティティの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーを使用して、委任されているロールのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。ロールセッションのアクセス許可の詳細については、「[セッションポリシー](access_policies.md#policies_session)」を参照してください。

³ **[Maximum session duration setting]** (最大セッション期間設定)。`DurationSeconds` パラメータを使用して、ロールセッションの期間を 900 秒 (15 分) からそのロールの最大セッション期間設定まで指定できます。ロールの最大値を確認する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。

⁴ **GetCallerIdentity**。このオペレーションを実行するためのアクセス許可は必要ありません。管理者が、`sts:GetCallerIdentity` アクションへのアクセスを明示的に拒否するポリシーを IAM ユーザーまたはロールに追加しても、このオペレーションは実行できます。IAM ユーザーまたはロールがアクセスを拒否されたときに同じ情報が返されるため、アクセス許可は必要ありません。レスポンスの例については、「[iam:DeleteVirtualMFADevice を実行することを認可されていません](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa)」を参照してください。

⁵ **コンソールへのシングルサインオン (SSO)**。SSO をサポートするために、AWS でフェデレーションエンドポイント (`https://signin.aws.amazon.com/federation`) を呼び出し、一時的セキュリティ認証情報を渡すことができます。エンドポイントから返されるトークンを使用すると、パスワードを要求せずにユーザーを直接コンソールにサインインさせる URL を作成できます。詳細とサンプルスクリプトについては、[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md) および AWS セキュリティブログの「[AWS へのクロスアカウントアクセスを有効にする方法](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)」を参照してください。

⁵ 一時的な認証情報を取得した後、この認証情報をフェデレーションのシングルサインオンエンドポイントに渡して AWS マネジメントコンソール にアクセスすることはできません。詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。

# サービスベアラートークン
<a name="id_credentials_bearer"></a>

一部の AWS のサービスでは、プログラムでリソースにアクセスする前に、AWS STS サービスベアラートークンを取得するアクセス許可が必要です。これらのサービスは、従来の [API リクエストに対する AWS Signature Version 4](reference_sigv.md) を使用する代わりに、ベアラトークンの使用が必要なプロトコルをサポートします。ベアラートークンをリクエストする AWS CLI または AWS API オペレーションを実行すると、AWS のサービスはお客様に代わってベアラートークンをリクエストします。サービスによってトークンが提供され、このトークンを使用して、サービスで後続のオペレーションを実行できます。

AWS STS サービスベアラートークンには、アクセス許可に影響する可能性がある元のプリンシパル認証の情報が含まれます。この情報には、プリンシパルタグ、セッションタグ、セッションポリシーが含まれます。トークンのアクセスキー ID は、`ABIA` プレフィックスで始まります。これは、CloudTrail ログ内のサービスベアラートークンを使用して実行されたオペレーションを識別するのに役立ちます。

**重要**  
ベアラートークンは、それを生成するサービスへの呼び出しと、それが生成されたリージョンでのみ使用できます。ベアラトークンを使用して、他のサービスやリージョンでオペレーションを実行することはできません。

ベアラートークンをサポートするサービスの例は、AWS CodeArtifact です。NPM、Maven、または PIP などのパッケージマネージャを使用して AWS CodeArtifact を操作する前に、`aws codeartifact get-authorization-token` オペレーションを呼び出す必要があります。このオペレーションは、AWS CodeArtifact オペレーションを実行するために使用できるベアラートークンを返します。または、同じオペレーションを完了し、クライアントを自動的に設定する `aws codeartifact login` コマンドを使用できます。

ベアラートークンを生成する AWS のサービスでアクションを実行する場合は、IAM ポリシーに次のアクセス許可が必要です。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowServiceBearerToken",
            "Effect": "Allow",
            "Action": "sts:GetServiceBearerToken",
            "Resource": "*"
        }
    ]
}
```

------

サービスのベアラートークンの例については、「*AWS CodeArtifact* ユーザーガイド」の「[Using identity-based policies for AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html)」( でのアイデンティティベースのポリシーの使用) を参照してください。

# 一時的なセキュリティ認証情報をリクエストする
<a name="id_credentials_temp_request"></a>

一時的なセキュリティ認証情報をリクエストするには、AWS API で AWS Security Token Service (AWS STS) を使用できます。これには、AWS リソースへのアクセスを制御できる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供するオペレーションが含まれます。の詳細については、「AWS STS」を参照してください。[IAM の一時的な認証情報](id_credentials_temp.md)ロールを引き受けることで一時的なセキュリティ認証情報をリクエストするための別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。

API オペレーションを呼び出すには、いずれかの [AWS SDK](https://aws.amazon.com/tools/) を使用することができます。SDK は、Java、.NET、Python、Ruby、Android、iOS など、さまざまなプログラミング言語や環境で使用できます。SDK は、リクエストへの暗号を使用した署名、必要に応じてリクエストの再試行、エラーレスポンスの処理などのタスクを処理します。また、[AWS Security Token Service API リファレンス](https://docs.aws.amazon.com/STS/latest/APIReference/) で説明されている AWS STS Query API を使用することもできます。最後に、AWS STS コマンドは [AWS Command Line Interface](https://aws.amazon.com/documentation/cli) および [AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell) という 2 つのコマンドラインツールでサポートされています。

AWS STS API オペレーションは、アクセスキーペアやセキュリティトークンを含む一時的セキュリティ認証情報で新しいセッションを作成します。アクセスキーペアは、アクセスキー ID とシークレットキーで構成されます。ユーザー（またはユーザーが実行しているアプリケーション）はこれらの認証情報を使用して、リソースにアクセスできます。AWS STS API オペレーションを使用して、ロールセッションを作成し、プログラムでセッションポリシーとセッションタグを渡すことができます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。セッションポリシーの詳細については、「[セッションポリシー](access_policies.md#policies_session)」を参照してください。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

**注記**  
AWS STS API オペレーションから返されるセッショントークンのサイズは固定ではありません。最大サイズを仮定しないことを強くお勧めします。一般的なトークンのサイズは 4096 バイト未満ですが、変化する可能性があります。

## AWS リージョンでの AWS STS の使用
<a name="using_sts_regions"></a>

AWS STS API 呼び出しは、グローバルエンドポイントにも、リージョンのエンドポイントの 1 つに対しても送信できます。より近くのエンドポイントを選択した場合、レイテンシーを軽減し、API 呼び出しのパフォーマンスが向上します。また、元のエンドポイントとの通信ができなくなった場合は、代替リージョンのエンドポイントに呼び出しを送信することもできます。各種 AWS SDK の 1 つを使用している場合、API コールを行う前に SDK メソッドを使用してリージョンを選択します。手動で HTTP API リクエストを組み立てる場合、独自で正しいエンドポイントにリクエストを送信する必要があります。詳細については、[*リージョンとエンドポイント*の「AWS STS 」セクション](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)および「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」 を参照してください。

AWS 環境およびアプリケーションで使用する一時的な認証情報の取得に使用できる API オペレーションを、次に示します。

## カスタム ID ブローカーを介したクロスアカウントの委任とフェデレーションの認証情報のリクエスト
<a name="api_assumerole"></a>

この [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) API オペレーションは、既存の IAM ユーザーに、まだアクセスできない AWS リソースへのアクセスを許可する際に役立ちます。例えば、ユーザーが別の AWS アカウント のリソースにアクセスする必要がある場合があります。また、特権アクセスを一時的に得るための方法 ( 多要素認証 (MFA) など) としても役立ちます。アクティブなユーザーの認証情報を使用してこの API を呼び出す必要があります。誰がこの操作を呼び出すことができるのかについては、[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md) を参照してください。詳細については、「[IAM ユーザーにアクセス許可を付与するロールを作成する](id_roles_create_for-user.md)」および「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。

**カスタム ID ブローカーを通じてクロスアカウント委任とフェデレーションの一時的なセキュリティ認証情報をリクエストするには**

1. AWS セキュリティ認証情報を使用して認証します。この呼び出しは、有効な AWS セキュリティ認証情報を使用して実行される必要があります。

1. [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) 操作を呼び出します。

以下の例は、`AssumeRole` を使用したリクエストと応答のサンプルを示します。このサンプルリクエストは、含まれている[セッションポリシー](access_policies.md#policies_session)、[セッションタグ](id_session-tags.md)、[外部 ID](id_roles_common-scenarios_third-party.md)、および[ソース ID](id_credentials_temp_control-access_monitor.md) を使用して、指定された期間の `demo` ロールを引き受けます。結果のセッションには `John-session` という名前が付けられます。

**Example リクエスト例**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=AssumeRole
&RoleSessionName=John-session
&RoleArn=arn:aws::iam::123456789012:role/demo
&Policy=%7B%22Version%22%3A%222012-10-17		 	 	 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&ExternalId=123ABC
&SourceIdentity=DevUser123
&AUTHPARAMS
```

上記の例に示すポリシーの値は、次のポリシーの URL エンコードされたバージョンです。

------
#### [ JSON ]

****  

```
{"Version":"2012-10-17",		 	 	 "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]}
```

------

この例の `AUTHPARAMS` パラメータは *署名*のプレースホルダーです。署名は AWS HTTP API リクエストに含める必要がある認証情報です。[AWS SDK](https://aws.amazon.com/tools/) を使用して API リクエストを作成することをお勧めします。その利点の 1 つは、SDK がリクエストの署名を処理することです。API リクエストを手動で作成し、署名する必要がある場合は、[Amazon Web Services 全般のリファレンス] の「[署名バージョン 4 を使用して AWS リクエストに署名する](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してリクエストに署名する方法を確認してください。

一時的セキュリティ認証情報に加えて、レスポンスにはフェデレーティッドユーザーの Amazon リソースネーム（ARN）、および認証情報の有効期限が含まれています。

**Example レスポンスの例**  

```
<AssumeRoleResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<AssumeRoleResult>
<SourceIdentity>DevUser123</SourceIdentity>
<Credentials>
  <SessionToken>
   AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
   LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
   QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
   9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
   +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
  </SessionToken>
  <SecretAccessKey>
   wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2019-07-15T23:28:33.359Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
<AssumedRoleUser>
  <Arn>arn:aws:sts::123456789012:assumed-role/demo/John</Arn>
  <AssumedRoleId>ARO123EXAMPLE123:John</AssumedRoleId>
</AssumedRoleUser>
<PackedPolicySize>8</PackedPolicySize>
</AssumeRoleResult>
<ResponseMetadata>
<RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
</ResponseMetadata>
</AssumeRoleResponse>
```

**注記**  
AWS 変換では、渡されたセッションポリシーとセッションタグが、個別の制限を持つひとまとめのバイナリ形式に圧縮されます。プレーンテキストが他の要件を満たしていても、この制限ではリクエストが失敗する可能性があります。`PackedPolicySize` レスポンス要素は、リクエストのポリシーとタグがサイズ制限にどの程度近づいているかをパーセントで示します。

## OIDC プロバイダーを通じた認証情報のリクエスト
<a name="api_assumerolewithwebidentity"></a>

[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API オペレーションは、JSON ウェブトークン (JWT) と引き換えに一時的な AWS セキュリティ認証情報のセットを返します。これには、Login with Amazon、Facebook、Google などのパブリック ID プロバイダー、および GitHub アクションや Azure Devops などの OpenID Connect (OIDC) 検出と互換性のある JWTs を発行するプロバイダーが含まれます。詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。

**注記**  
`AssumeRoleWithWebIdentity` リクエストは で署名されていないため、AWS 認証情報は必要ありません。

**OIDC プロバイダーを通じた認証情報のリクエスト**

1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) 操作を呼び出します。

   を呼び出すと`AssumeRoleWithWebIdentity`、 は IdP の JSON ウェブキーセット (JWKS) で利用可能になったパブリックキーを使用してデジタル署名を検証することで、提示されたトークンAWSを検証します。トークンが有効で、IAM ロールの信頼ポリシーに規定されたすべての条件が満たされている場合、AWS は次の情報を返します。
   + 一時的なセキュリティ認証情報一式。一時的なセキュリティ認証情報は、アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成されています。
   + 引き受けたロールのロール ID と ARN。
   + 一意のユーザー ID を含む `SubjectFromWebIdentityToken` 値。

1. アプリケーションは、レスポンスで返された一時的なセキュリティ認証情報を使用して AWS APIコールを行うことができます。これは、長期的なセキュリティ認証情報を使用して AWS API 呼び出しを行うのと同じ処理です。異なる点は、AWS で一時的なセキュリティ認証情報が有効であることを確認できる、セッショントークンを含める必要があることです。

アプリケーションは、AWS STS が返した認証情報をキャッシュし、必要に応じて更新する必要があります。アプリケーションが AWS SDK を使用して構築されている場合、SDK には、有効期限が切れる前に `AssumeRoleWithWebIdentity` の呼び出しと AWS 認証情報の更新を処理できる認証情報プロバイダーがあります。詳細については、「*AWS SDKs および ツールリファレンスガイド*」の「[AWS SDKs および Tools 標準化された認証情報プロバイダー](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html)」を参照してください。

## SAML 2.0 ID プロバイダーを通じた認証情報のリクエスト
<a name="api_assumerolewithsaml"></a>

[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API オペレーションでは、組織の既存の ID システムによって認証された SAML フェデレーティッドプリンシパルに一連の一時的なセキュリティ認証情報が返されます。また、ユーザーは [SAML](https://www.oasis-open.org/standards#samlv2.0)2.0 (Security Assertion Markup Language) を使用して AWS に認証および認可情報を渡す必要があります。この API オペレーションは、SAML アサーションを生成できるソフトウェアに認証システム (Windows Active Directory、OpenLDAP など) を統合している組織で役立ちます。このような統合はユーザー ID とアクセス許可に関する情報を提供します (Active Directory Federation Services や Shibboleth など)。詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。

1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) 操作を呼び出します。

   これは署名なしの呼び出しです。つまり、リクエストを実行する前に AWS セキュリティ認証情報を認証する必要はありません。
**注記**  
`AssumeRoleWithSAML` に対する呼び出しは署名 (暗号化) されていません。そのため、信頼されている経路を通じてリクエストが送信される場合のみ、オプションのセッションポリシーを含める必要があります。そうでない場合、他のユーザーが制限を削除するようにポリシーを変更できます。

1. `AssumeRoleWithSAML` を呼び出すときに、AWS は SAML アサーションの信頼性を確認します。ID プロバイダーがアサーションを確認した場合、AWS は次の情報を返します。
   + 一時的なセキュリティ認証情報一式。一時的なセキュリティ認証情報は、アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成されています。
   + 引き受けたロールのロール ID と ARN。
   + SAML アサーションの `Audience` 要素の `Recipient` 属性値を含む `SubjectConfirmationData` 値。
   + SAML アサーションの `Issuer` 要素の値を含む `Issuer` 値。
   + `Issuer` 値、AWS アカウント ID、SAML プロバイダーのフレンドリ名から構築されたハッシュ値を含む `NameQualifier` 要素。`Subject` 要素と組み合わせると、SAML フェデレーティッドプリンシパルを一意に特定できます。
   + SAML アサーションの `Subject` 要素内の `NameID` 要素の値を含む `Subject` 要素。
   + `SubjectType` 要素の形式を示す `Subject` 要素。値は、`persistent`、`transient`、または SAML アサーションで使用されている `Format` および `Subject` 要素の完全な `NameID` URI とすることができます。`NameID` 要素の `Format` 属性の詳細については、「[認証レスポンス用の SAML アサーションを設定する](id_roles_providers_create_saml_assertions.md)」を参照してください。

1. レスポンスで返された一時的なセキュリティ認証情報を使用して AWS API コールを実行します。これは、長期的なセキュリティ認証情報を使用して AWS API 呼び出しを行うのと同じ処理です。異なる点は、AWS で一時的なセキュリティ認証情報が有効であることを確認できる、セッショントークンを含める必要があることです。

アプリで認証情報をキャッシュする必要があります。認証情報はデフォルトで 1 時間後に無効になります。[ SDK の ](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios)AmazonSTSCredentialsProviderAWS アクションを使用していない場合、再度 `AssumeRoleWithSAML` を呼び出すかどうかはお客様およびお客様のアプリによります。古い認証情報が失効する前に、このオペレーションを呼び出して新しい一時的なセキュリティ認証情報を取得します。

## カスタム ID ブローカーを通じた認証情報のリクエスト
<a name="api_getfederationtoken"></a>

[https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API オペレーションでは、AWS STS フェデレーションユーザーのプリンシパルに一連の一時的なセキュリティ認証情報が返されます。この API は、デフォルトの有効期限が大幅に長い (1 時間ではなく 12 時間) という点で `AssumeRole` とは異なります。また、`DurationSeconds` パラメータを使用して、一時的なセキュリティ認証情報が有効である期間を選択することもできます。結果として得られる認証情報は、900 秒 (15 分) から 129,600 秒 (36 時間) までの指定された期間内で有効です。有効期限を長くすると、新しい認証情報を頻繁に取得する必要がなくなるため、AWS への呼び出し回数を減少させることができます。

1. 特定の IAM ユーザーの AWS セキュリティ認証情報を使用して認証します。この呼び出しは、有効な AWS セキュリティ認証情報を使用して実行される必要があります。

1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) 操作を呼び出します。

`GetFederationToken` 呼び出しは、セッショントークン、アクセスキー、シークレットキー、失効情報で構成される一時的セキュリティ認証情報を返します。組織内でアクセス権限を管理する (たとえば、プロキシアプリケーションを使用してアクセス権限を割り当てる) 場合、`GetFederationToken` を使用できます。

以下の例に、`GetFederationToken` を使用したリクエストと応答のサンプルを示します。このリクエスト例では、指定された期間の呼び出し元ユーザーを[セッションポリシー](access_policies.md#policies_session) ARN および[セッションタグ](id_session-tags.md)とフェデレートします。結果のセッションには `Jane-session` という名前が付けられます。

**Example リクエスト例**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetFederationToken
&Name=Jane-session
&PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&AUTHPARAMS
```

前述の例に示すポリシー ARN には、次の URL エンコードされた ARN が含まれています。

`arn:aws:iam::123456789012:policy/Role1policy`

また、例の `&AUTHPARAMS` パラメータは、認証情報のプレースホルダーとして使用されることに注意してください。これは、*署名*であり、AWS HTTP API リクエストに含める必要があります。[AWS SDK](https://aws.amazon.com/tools/) を使用して API リクエストを作成することをお勧めします。その利点の 1 つは、SDK がリクエストの署名を処理することです。API リクエストを手動で作成し、署名する必要がある場合は、「Amazon Web Services 全般のリファレンス」の「[署名バージョン 4 を使用して AWS リクエストに署名する](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してリクエストに署名する方法を確認してください。

一時的セキュリティ認証情報に加えて、レスポンスにはフェデレーティッドユーザーの Amazon リソースネーム（ARN）、および認証情報の有効期限が含まれています。

**Example レスポンスの例**  

```
<GetFederationTokenResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<GetFederationTokenResult>
<Credentials>
  <SessionToken>
   AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
   LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
   QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
   9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
   +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE==
  </SessionToken>
  <SecretAccessKey>
  wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2019-04-15T23:28:33.359Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE;</AccessKeyId>
</Credentials>
<FederatedUser>
  <Arn>arn:aws:sts::123456789012:federated-user/Jean</Arn>
  <FederatedUserId>123456789012:Jean</FederatedUserId>
</FederatedUser>
<PackedPolicySize>4</PackedPolicySize>
</GetFederationTokenResult>
<ResponseMetadata>
<RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
</ResponseMetadata>
</GetFederationTokenResponse>
```

**注記**  
AWS 変換では、渡されたセッションポリシーとセッションタグが、個別の制限を持つひとまとめのバイナリ形式に圧縮されます。プレーンテキストが他の要件を満たしていても、この制限ではリクエストが失敗する可能性があります。`PackedPolicySize` レスポンス要素は、リクエストのポリシーとタグがサイズ制限にどの程度近づいているかをパーセントで示します。

AWS ではリソースレベルでアクセス許可を付与する（たとえば、Amazon S3 バケットにリソースベースのポリシーをアタッチする）ことを推奨しています。`Policy` パラメータは省略できます。ただし、AWS STS フェデレーションユーザーのプリンシパルにポリシーを含まない場合、一時的なセキュリティ認証情報によってアクセス権限が付与されません。この場合、リソースポリシーを使用してフェデレーティッドユーザーに AWS リソースへのアクセスを許可する*必要があります*。

例えば、AWS アカウント 番号が 111122223333 であり、Susan にアクセスを許可しようとしている Amazon S3 バケットがあるとします。Susan の一時的セキュリティ認証情報にはバケットのポリシーが含まれていません。この場合、Susan の ARN (`arn:aws:sts::111122223333:federated-user/Susan` など) と一致する ARN があるポリシーがバケットにあるようにする必要があります。

## 信頼されていない環境でのユーザーの認証情報のリクエスト
<a name="api_getsessiontoken"></a>

この [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) API オペレーションでは、既存の IAM ユーザーに一時的セキュリティ認証情報のセットが返ります。この API は、MFA が IAM ユーザーに対して有効なときに AWS リクエストを作成するなど、セキュリティを強化するために役立ちます。認証情報は一時的なものであるため、安全性の低い環境からリソースにアクセスする IAM ユーザーがいる場合、これによりセキュリティが強化されます。安全性の低い環境の例には、モバイルデバイスやウェブブラウザが含まれます。

1. 特定の IAM ユーザーの AWS セキュリティ認証情報を使用して認証します。この呼び出しは、有効な AWS セキュリティ認証情報を使用して実行される必要があります。

1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) 操作を呼び出します。

1. `GetSessionToken` は、セッショントークン、アクセスキー ID、およびシークレットアクセスキーから構成される一時的なセキュリティ認証情報を返します。

デフォルトでは、IAM ユーザーの一時的なセキュリティ認証情報は、最大 12 時間有効です。ただし、`DurationSeconds` パラメータを使用して最短 15 分、最長 36 時間の有効期間をリクエストできます。セキュリティ上の理由から、AWS アカウントのルートユーザー のトークンは有効期間が 1 時間に制限されます。

以下の例は、`GetSessionToken` を使用したリクエストと応答のサンプルを示します。レスポンスには、一時的なセキュリティ認証情報の有効期限も含んでいます。

**Example リクエスト例**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=1800
&AUTHPARAMS
```

この例の `AUTHPARAMS` パラメータは *署名*のプレースホルダーです。署名は AWS HTTP API リクエストに含める必要がある認証情報です。[AWS SDK](https://aws.amazon.com/tools/) を使用して API リクエストを作成することをお勧めします。その利点の 1 つは、SDK がリクエストの署名を処理することです。API リクエストを手動で作成し、署名する必要がある場合は、「*Amazon Web Services 全般のリファレンス*」の「[署名バージョン 4 を使用して AWS リクエストに署名する](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してリクエストに署名する方法を確認してください。

**Example レスポンスの例**  

```
<GetSessionTokenResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<GetSessionTokenResult>
<Credentials>
  <SessionToken>
   AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L
   To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z
   rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp
   Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE
  </SessionToken>
  <SecretAccessKey>
  wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2011-07-11T19:55:29.611Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
</GetSessionTokenResult>
<ResponseMetadata>
<RequestId>58c5dbae-abef-11e0-8cfe-09039844ac7d</RequestId>
</ResponseMetadata>
</GetSessionTokenResponse>
```

オプションで、`GetSessionToken` リクエストに、AWS の多要素認証 (MFA) で確認する `SerialNumber` および `TokenCode` 値を含めることができます。指定された値が有効であれば、AWS STS は、MFA 認証の状態を含む一時的なセキュリティ認証情報を提供します。この一時的セキュリティ認証情報を使用して、MFA で保護された API オペレーションまたは AWS ウェブサイトに、MFA 認証が有効である限りアクセスできます。

以下の例は、MFA 認証コードとデバイスのシリアルナンバーを含む `GetSessionToken` リクエストを示しています。

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=7200
&SerialNumber=YourMFADeviceSerialNumber
&TokenCode=123456
&AUTHPARAMS
```

**注記**  
AWS STS の呼び出しは、グローバルエンドポイントまたは AWS アカウント をアクティブ化しているリージョンのエンドポイントに対して行えます。詳細については、[*リージョンとエンドポイント*の「AWS STS」セクション](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)を参照してください。  
この例の `AUTHPARAMS` パラメータは *署名*のプレースホルダーです。署名は AWS HTTP API リクエストに含める必要がある認証情報です。[AWS SDK](https://aws.amazon.com/tools/) を使用して API リクエストを作成することをお勧めします。その利点の 1 つは、SDK がリクエストの署名を処理することです。API リクエストを手動で作成し、署名する必要がある場合は、[Amazon Web Services 全般のリファレンス] の「[署名バージョン 4 を使用して AWS リクエストに署名する](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)」を参照してリクエストに署名する方法を確認してください。

# AWS リソースで一時的な認証情報を使用する
<a name="id_credentials_temp_use-resources"></a>

一時的な認証情報を使用して、AWS または AWS CLI API（[AWS SDK](https://aws.amazon.com/tools/)を使用）を使用して AWS リソースのプログラム要求を行うことができます。一時的な認証情報は、IAM ユーザーの認証情報など、長期的なセキュリティ認証情報を使用するのと同じアクセス許可を提供します。ただし、いくつか違いがあります。
+ 一時的セキュリティ認証情報を使用して呼び出しを行うときは、一時的な認証情報と共に返されるセッショントークンを呼び出しに含める必要があります。AWS はセッショントークンを使用して、一時的セキュリティ認証情報を検証します。
+ 一時的な認証情報は、指定した期間が過ぎると失効します。一時認証情報が有効期限切れになると、その認証情報を使用する呼び出しはすべて失敗するため、新しい一時認証情報を生成する必要があります。一時的な認証情報は、最初に指定された間隔を超えて延長または更新することはできません。
+ 一時的な認証情報を使用してリクエストを行う場合、プリンシパルに一連のタグが含まれる場合があります。これらのタグは、引き受けるロールにアタッチされたセッションタグとタグから取得されます。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

[AWS SDK ](https://aws.amazon.com/tools)、[AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/) (AWS CLI) または [Tools for Windows PowerShell](https://aws.amazon.com/powershell) を使用している場合、一時的なセキュリティ認証情報を取得および使用する方法はコンテキストによって異なります。コード、AWS CLI、または Tools for Windows PowerShell コマンドを EC2 インスタンス内で実行している場合は、Amazon EC2 のロールを利用できます。それ以外の場合は、[AWS STS API](https://docs.aws.amazon.com/STS/latest/APIReference/) を呼び出して一時的な認証情報を取得した後、その情報を明示的に使用して AWS のサービスを呼び出すことができます。

**注記**  
AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。AWS STS の詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」を参照してください。AWS STS は、デフォルトのエンドポイントが `https://sts.amazonaws.com` にあるグローバルサービスです。このエンドポイントや他のエンドポイントから取得した認証情報はグローバルに有効ですが、このエンドポイントは米国東部 (バージニア北部) リージョンにあります。これらの認証情報は、どのリージョンのサービスとリソースでも機能します。サポートされているリージョンのいずれかにあるエンドポイントへの AWS STS API 呼び出しを実行することもできます。地理的に近い場所にあるリージョンのサーバーに対してリクエストを実行することによって、レイテンシーを低減できます。認証情報を取得したリージョンに関係なく、認証情報はグローバルに使用できます。詳細については、「[AWS リージョン で AWS STS を管理する](id_credentials_temp_enable-regions.md)」を参照してください。

**Contents**
+ [

## Amazon EC2 インスタンスでの一時的な認証情報の使用
](#using-temp-creds-sdk-ec2-instances)
+ [

## AWS SDK での一時的セキュリティ認証情報の使用
](#using-temp-creds-sdk)
+ [

## AWS CLI で一時的なセキュリティ認証情報を使用する
](#using-temp-creds-sdk-cli)
+ [

## API オペレーションで一時的なセキュリティ認証情報を使用する
](#RequestWithSTS)
+ [

## 詳細情報
](#using-temp-creds-more-info)

## Amazon EC2 インスタンスでの一時的な認証情報の使用
<a name="using-temp-creds-sdk-ec2-instances"></a>

AWS CLI コマンドまたはコードを EC2 インスタンス内で実行する場合、認証情報を取得するために推奨される方法は、[Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) のロールを使用する方法です。つまり、EC2 インスタンスで実行されているアプリケーションに付与するアクセス許可を指定する IAM ロールを作成します。インスタンスを起動するときに、このロールとインスタンスを関連付けます。

これにより、インスタンスで実行されるアプリケーション、AWS CLI、Tools for Windows PowerShell コマンドがインスタンスメタデータから自動的に一時的セキュリティ認証情報を取得できるようになります。一時的なセキュリティ認証情報を明示的に取得する必要はありません。AWS SDK、AWS CLI、および Tools for Windows PowerShell は EC2 インスタンスメタデータサービス (IMDS) から認証情報を自動的に取得して使用します。一時的なセキュリティ認証情報には、インスタンスに関連付けられたロールに定義されているアクセス権限が付与されます。

詳細情報および例については、次のセクションを参照してください。
+  [IAM ロールを使用した Amazon Elastic Compute Cloud の AWS リソースへのアクセスの許可](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) — AWS SDK for Java
+  [IAM ロールを使用したアクセスの許可](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) — AWS SDK for .NET 
+  [ロールの作成](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html) — AWS SDK for Ruby

## AWS SDK での一時的セキュリティ認証情報の使用
<a name="using-temp-creds-sdk"></a>

コード内で一時的なセキュリティ認証情報を使用するには、`AssumeRole` などの AWS STS API をプログラムから呼び出し、結果として得られる認証情報とセッショントークンを抽出します。その後、これらの値を AWS への後続の呼び出しの認証情報として使用します。以下の例は、AWS SDK を使用している場合に、一時的なセキュリティ認証情報を使用する方法を示す疑似コードです。

```
assumeRoleResult = AssumeRole(role-arn);
tempCredentials = new SessionAWSCredentials(
   assumeRoleResult.AccessKeyId, 
   assumeRoleResult.SecretAccessKey, 
   assumeRoleResult.SessionToken);
s3Request = CreateAmazonS3Client(tempCredentials);
```

Python で記述された例（[AWS SDK for Python (Boto)](https://aws.amazon.com/sdk-for-python/) を使用）については、「[IAM ロールを切り替える (AWS)](id_roles_use_switch-role-api.md)」を参照してください。この例では、`AssumeRole` を呼び出して一時的なセキュリティ認証情報を取得し、それらの認証情報を使用して Amazon S3 を呼び出します。

`AssumeRole`、`GetFederationToken`、およびその他の API オペレーションを呼び出す方法の詳細については、「[AWS Security Token Service API リファリファレンス](https://docs.aws.amazon.com/STS/latest/APIReference/)」を参照してください。結果から一時的なセキュリティ認証情報とセッショントークンを取得する方法の詳細については、お使いの SDK のドキュメントを参照してください。すべての AWS SDK に関するドキュメントは、主要な [AWS のドキュメントページ](https://aws.amazon.com/documentation)の「**SDK とツールキット**」セクションにあります。

古い認証情報が失効する前に、新しい認証情報を取得する必要があります。一部の SDK では、ユーザーの代わりに認証情報の更新処理を管理するプロバイダーを使用できます。お使いの SDK のドキュメントを確認してください。

## AWS CLI で一時的なセキュリティ認証情報を使用する
<a name="using-temp-creds-sdk-cli"></a>

AWS CLI で一時的なセキュリティ認証情報を使用できます。これは、ポリシーをテストする場合に便利です。

[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/) を使用して、[AWS STS API](https://docs.aws.amazon.com/STS/latest/APIReference/) (`AssumeRole` や `GetFederationToken` など) を呼び出し、結果の出力をキャプチャします。次の例は、出力をファイルに送信する `AssumeRole` の呼び出しを示しています。この例では、`profile` パラメータは AWS CLI 設定ファイル内のプロファイルであると想定されています。また、ロールを引き受けるアクセス許可を持つ IAM ユーザーの認証情報を参照することも想定されます。

```
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt
```

コマンドが完了したら、ルーティングした場所からアクセスキー ID、シークレットアクセスキー、セッショントークンを抽出できます。この操作は、手動またはスクリプトを使用して行うことができます。次に、これらの値を環境変数に割り当てます。

AWS CLI コマンドを実行すると、AWS CLI によって特定の順序で資格情報が検索されます。最初は環境変数で、次に構成ファイルで検索されます。したがって、一時的な認証情報を環境変数に設定すると、AWS CLI でこれらの認証情報がデフォルトで使用されます （コマンドで `profile` パラメーターを指定すると、AWS CLI は環境変数をスキップします。代わりに、AWS CLI は構成ファイルを調べます。これにより、必要に応じて環境変数の資格情報をオーバーライドできます。） 

以下の例では、環境変数に一時的なセキュリティ認証情報を設定した後で AWS CLI コマンドを呼び出しています。AWS CLI コマンドには `profile` パラメータが指定されていないため、AWS CLI で最初に環境変数内で認証情報が検索されます。その結果、一時的な認証情報が使用されます。

**Linux**

```
$ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
$ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
$ export AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of session token>
$ aws ec2 describe-instances --region us-west-1
```

**Windows**

```
C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of token> 
C:\> aws ec2 describe-instances --region us-west-1
```

## API オペレーションで一時的なセキュリティ認証情報を使用する
<a name="RequestWithSTS"></a>

AWS に対する直接 HTTPS API リクエストを行う場合、AWS Security Token Service (AWS STS) から取得した一時的セキュリティ認証情報でそれらのリクエストを署名できます。これを行うには AWS STS から受け取るアクセスキー ID とシークレットアクセスキーを使用します。長期的な認証情報を使用してリクエストに署名するのと同じ方法で、アクセスキー ID とシークレットアクセスキーを使用します。また、AWS STS から渡されるセッショントークンを API リクエストに追加します。セッショントークンは、HTTP ヘッダーに追加するか、`X-Amz-Security-Token` という名前のクエリ文字列パラメータに追加します。セッショントークンを追加するのは、HTTPヘッダー*または*クエリ文字列パラメータのいずれかです。両方には追加しません。HTTPS API リクエストの署名の詳細については、「AWS 全般のリファレンス」の「[AWS API リクエストの署名](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)」を参照してください。

## 詳細情報
<a name="using-temp-creds-more-info"></a>

他の AWS のサービスで AWS STS を使用する方法の詳細については、以下のブログ記事を参照してください。
+ **Amazon S3**。「Amazon Simple Storage Service ユーザーガイド」の「[IAM ユーザー一時クレデンシャルを使用したリクエストの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html)」または「[フェデレーションユーザー一時クレデンシャルを使用したリクエストの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html)」を参照してください。
+ **Amazon SNS** 「Amazon Simple Notification Service デベロッパーガイド」の「[Amazon SNS でのアイデンティティベースのポリシーの使用](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS)」を参照してください。
+ **Amazon SQS** 「Amazon Simple Queue Service デベロッパーガイド」の「[Amazon SQS での Identity and access management](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS)」を参照してください。
+ **Amazon SimpleDB** 『[Amazon SimpleDB 開発者ガイド](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html)』の「*一時的なセキュリティクレデンシャルの使用*」を参照してください。

# 一時的なセキュリティ認証情報のアクセス許可
<a name="id_credentials_temp_control-access"></a>

AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。の詳細については、「AWS STS」を参照してください。[IAM の一時的な認証情報](id_credentials_temp.md)AWS STS によって一時的なセキュリティ証明書が発行された後、それらの証明書は期限切れになるまで有効であり、取り消すことはできません。ただし、一時的なセキュリティ認証情報に割り当てられたアクセス権限は、認証情報を使用するリクエストがなされるたびに評価されるため、発行後にアクセス権を変更することで、認証情報を取り消すのと同等の効果を得ることができます。

以下のトピックでは、AWS のアクセス許可とポリシーに関する実用的な知識があることを前提としています。これらのトピックの詳細については、「[AWS リソースの アクセス管理](access.md)」を参照してください。

**Topics**
+ [

# AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity のアクセス権限
](id_credentials_temp_control-access_assumerole.md)
+ [

# 引き受けたロールで実行されるアクションのモニタリングと制御
](id_credentials_temp_control-access_monitor.md)
+ [

# GetFederationToken のアクセス権限
](id_credentials_temp_control-access_getfederationtoken.md)
+ [

# GetSessionToken のアクセス権限
](id_credentials_temp_control-access_getsessiontoken.md)
+ [

# 一時的なセキュリティ認証情報のアクセス権限を無効にする
](id_credentials_temp_control-access_disable-perms.md)
+ [

# 一時的なセキュリティ認証情報を作成するためのアクセス権限の付与
](id_credentials_temp_control-access_enable-create.md)
+ [

# ID 拡張コンソールセッションを使用するための許可の付与
](id_credentials_temp_control-access_sts-setcontext.md)

# AssumeRole、AssumeRoleWithSAML、AssumeRoleWithWebIdentity のアクセス権限
<a name="id_credentials_temp_control-access_assumerole"></a>

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

必要に応じて、インラインまたはマネージド [セッションポリシー](access_policies.md#policies_session) を`AssumeRole`、`AssumeRoleWithSAML`、または `AssumeRoleWithWebIdentity` API オペレーションのパラメータとして渡すことができます。セッションポリシーは、ロールの一時的な認証情報セッションのアクセス許可を制限します。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。ロールの一時的な認証情報を以降の AWS API コールで使用し、ロールを所有するアカウント内のリソースにアクセスできます。セッションポリシーを使用して、委任されているロールのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。AWS でロールの有効なアクセス許可を決定する方法の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。

![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)


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

## 例: AssumeRole を使用してアクセス権限を割り当てる
<a name="permissions-assume-role-example"></a>

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

### ロールのアクセス許可ポリシー
<a name="permissions-assume-role-example-role-access-policy"></a>

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

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

```
{
  "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/*"
    }
  ]
}
```

### パラメータとして渡されたセッションポリシー
<a name="permissions-assume-role-example-passed-policy"></a>

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

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

たとえば、API 呼び出しのパラメータとして以下のポリシーを渡すとします。このセッションを使用するユーザーには、次のアクションのみを実行するアクセス許可が付与されています。
+ `productionapp` バケットのすべてのオブジェクトをリストします。
+ `productionapp` バケットのオブジェクトを取得し格納します。

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

**Example `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/*"
    }
  ]
}
```

### リソースベースのポリシー
<a name="permissions-assume-role-example-resource-based-policy"></a>

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

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

**Example バケットポリシーの例**    
****  

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

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

# 引き受けたロールで実行されるアクションのモニタリングと制御
<a name="id_credentials_temp_control-access_monitor"></a>

[IAM ロール](id_roles.md)は、[アクセス許可](access_policies.md)が割り当てられている IAM 内のオブジェクトです。IAM IDまたは AWS の外部からのIDを使用して[そのロールを引き受ける](id_roles_manage-assume.md)と、ロールに割り当てられたアクセス許可を持つセッションを受け取ります。

AWS でアクションを実行すると、セッションに関する情報を AWS CloudTrail にログ記録して、アカウント管理者がモニタリングできるようになります。管理者は、AWS でアクションを実行する個人またはアプリケーションを識別するカスタム文字列を渡すように ID を要求するようにロールを設定できます。この ID 情報は、*ソース ID* として AWS CloudTrail に保存されます。管理者は CloudTrail のアクティビティを確認すると、ソース ID 情報を表示して、引き受けたロールセッションでアクションを実行したユーザーやアクションを判断できます。

ソースIDが設定されると、ロールセッション中に実行されるすべての AWS アクションの要求に存在します。設定された値は、ロールが AWS CLI または AWS APIを介して別のロールを引き受けるために使用される場合、[ロール連鎖](id_roles.md#iam-term-role-chaining)と呼ばれます。設定される値は、ロールセッション中に変更できません。管理者は、ソース ID の存在または値に基づいて詳細なアクセス許可を構成して、共有ロールで実行される AWS アクションをさらに制御できます。ソース ID 属性を使用できるかどうか、必須かどうか、どの値を使用できるかを決定できます。



ソース ID の使用方法は、ロールセッション名およびセッションタグとは重要な点で異なります。ソース ID 値は、設定後は変更できません。また、ロールセッションで実行される追加のアクションでも保持されます。セッションタグとロールセッション名の使用方法は次のとおりです。
+ **セッションタグ** – ロールを引き受けるとき、またはユーザーをフェデレートするときに セッションタグ を渡すこともできます。セッションタグは、ロールを引き受けるときに存在します。タグ条件キーを使用して、タグに基づいてプリンシパルにアクセス許可を付与するポリシーを定義できます。次に、CloudTrail を使用して、ロールを引き受けるか、ユーザーをフェデレートするために行われたリクエストを表示できます。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
+ **ロールセッション名** – ロール信頼ポリシーで `sts:RoleSessionName` 条件キーを使用して、ユーザーがロールを引き受けるときに特定のセッション名を提供するように要求できます。ロールセッション名は、ロールが異なるプリンシパルによって使用される場合に、ロールセッションを区別するために使用できます。ロールセッション名の詳細については、「[sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname)」を参照してください。。

ロールを引き受ける ID を制御する場合は、ソース ID を使用することをお勧めします。ソースアイデンティティは、CloudTrail ログをマイニングして、アクションを実行するためにロールを使用したユーザーを特定する場合にも役立ちます。

**Topics**
+ [

## ソース ID を使用するための設定
](#id_credentials_temp_control-access_monitor-setup)
+ [

## ソースアイデンティティについて知っておくべきこと
](#id_credentials_temp_control-access_monitor-know)
+ [

## ソース ID を設定するために必要なアクセス許可
](#id_credentials_temp_control-access_monitor-perms)
+ [

## ロールを引き受けるときのソース ID の指定
](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [

## AssumeRole でのソース ID の使用
](#id_credentials_temp_control-access_monitor-assume-role)
+ [

## AssumeRoleWithSAML を使用したソース ID の使用
](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [

## AssumeRoleWithWebIdentity によるソース ID の使用
](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [

## ソース ID 情報を使用してアクセスを制御する
](#id_credentials_temp_control-access_monitor-control-access)
+ [

## CloudTrail でのソースアイデンティティの表示
](#id_credentials_temp_control-access_monitor-ct)

## ソース ID を使用するための設定
<a name="id_credentials_temp_control-access_monitor-setup"></a>

ソース ID を使用するように設定する方法は、ロールを引き受けるときに使用される方法によって異なります。例えば、IAMユーザーは、`AssumeRole` オペレーションを直接使用してロールを引き受ける場合があります。エンタープライズ ID (ワークフォースIDとも呼ばれる) がある場合、AWS を使用して `AssumeRoleWithSAML` リソースにアクセスする可能性があります。エンドユーザーがモバイルまたはWebアプリケーションにアクセスする場合、`AssumeRoleWithWebIdentity` を使用してアクセスする可能性があります。次に、既存の環境でソース ID 情報を利用するためのを設定する方法を理解するのに役立つ概要のワークフローの概要を示します。

1. **テストユーザーおよびロールの構成** — 運用前環境を使用して、テストユーザーおよびロールを構成し、ソースアイデンティティを設定できるようにポリシーを構成します。

   フェデレーション ID に ID プロバイダー (IdP) を使用する場合は、アサーションまたはトークンでソース ID に選択したユーザー属性を渡すように IdP を設定します。

1. **ロールを引き受けるには** – ロールを想定し、テスト用に設定したユーザーとロールにソース ID を渡します。

1. **CloudTrail の確認** — CloudTrail ログでテストロールのソース ID 情報を確認します。

1. **ユーザーのトレーニング** — 運用前の環境でテストした後、必要に応じて、ソース ID 情報を渡す方法をユーザーが把握していることを確認します。本番環境でソース ID の提供をユーザーに要求する期限を設定します。

1. **本番ポリシーの設定**：本番環境のポリシーを構成し、本番ユーザーおよびロールに追加します。

1. **アクティビティのモニタリング**— CloudTrail ログを使用して、本番ロールのアクティビティをモニタリングします。

## ソースアイデンティティについて知っておくべきこと
<a name="id_credentials_temp_control-access_monitor-know"></a>

ソース ID を使用する際には、次の点に注意してください。
+ ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに `sts:SetSourceIdentity` アクセス許可が必要です。ロール信頼ポリシーでこのアクセス許可を持たないロールの場合、`AssumeRole*` オペレーションは失敗します。各ロールのロール信頼ポリシーを更新しない場合は、ソース ID を渡すために個別の IdP インスタンスを使用できます。その後、個別の IdP に接続されているロールにのみ `sts:SetSourceIdentity` アクセス許可を追加します。
+ アイデンティティーがソースアイデンティティを設定する場合、`sts:SourceIdentity` キーはリクエストに存在します。ロールセッション中に実行される後続のアクションでは、`aws:SourceIdentity` キーがリクエストに存在します。AWS は、`sts:SourceIdentity` または `aws:SourceIdentity` キーのソース ID の値を制御しません。ソース ID を要求する場合は、ユーザーまたは IdP に提供する属性を選択する必要があります。セキュリティ上の理由から、これらの値の提供方法を制御できることを確認する必要があります。
+ ソース ID の値は、2 〜 64 文字の長さである必要があり、英数字、アンダースコア、および 、**. , \$1 = @ -**(ハイフン) のみを含めることができます。テキスト **aws:** から開始するタグキーや値を作成することはできません。このプレフィックスは AWS の内部使用のために予約されています。
+ AWS サービスまたはサービスにリンクされたロールがフェデレーション ID またはワーカー ID に代わってアクションを実行する場合、ソース ID 情報は CloudTrail によってキャプチャされません。

**重要**  
AWS マネジメントコンソール でロールを切り替えるには、ロールを引き受けるときにソース ID を設定する必要があります。このようなロールを引き受けるには、AWS CLI または AWS API を呼び出して `AssumeRole` オペレーションを実行し、ソース ID パラメーターを指定します。

## ソース ID を設定するために必要なアクセス許可
<a name="id_credentials_temp_control-access_monitor-perms"></a>

API オペレーションに一致するアクションに加えて、ポリシーには次のアクセス許可のみのアクションが必要です。

```
sts:SetSourceIdentity
```
+ ソース ID を指定するには、プリンシパル (IAM ユーザーとロール) に `sts:SetSourceIdentity` へのアクセス許可が必要です。管理者は、ロールの信頼ポリシーとプリンシパルのアクセス許可ポリシーでこれを設定できます。
+ 別のロールでロールを引き受ける場合、[ロールの連鎖](id_roles.md#iam-term-role-chaining)と呼ばれるアクセス許可 `sts:SetSourceIdentity` は、ロールを引き受けるプリンシパルのアクセス許可ポリシーと、ターゲットロールのロール信頼ポリシーの両方で必要です。そうしない場合、ロールの引き受け操作は失敗します。
+ ソース ID を使用している場合、ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに `sts:SetSourceIdentity` アクセス許可が必要です。このアクセス許可なしで IdP に接続されているロールでは、`AssumeRole*` オペレーションは失敗します。各ロールのロール信頼ポリシーを更新しない場合は、ソース ID を渡すために個別の IdP インスタンスを使用し、`sts:SetSourceIdentity` アクセス許可は、個別の IdP に接続されているロールにのみ付与されます。
+ アカウントの境界を越えてソースIDを設定するには、2 箇所に `sts:SetSourceIdentity` アクセス許可を含める必要があります。これは、元のアカウントのプリンシパルのアクセス許可ポリシーと、ターゲットアカウントのロールのロール信頼ポリシーにある必要があります。例えば、ロールが[ロールの連鎖](id_roles.md#iam-term-role-chaining)を使用して別のアカウントでロールを引き受けるために使用される場合、これを行う必要がある場合があります。

アカウント管理者として、アカウントの IAM ユーザー`DevUser`が同じアカウントの `Developer_Role` を引き継ぐことを許可したいとします。ただし、ユーザーがソース ID を自分の IAM ユーザー名に設定している場合にのみ、このアクションを許可します。その場合、IAM ユーザーに以下のポリシーをアタッチできます。

**Example DevUser にアタッチされた ID ベースのポリシーの例**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AssumeRole",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/Developer_Role"
    },
    {
      "Sid": "SetAwsUserNameAsSourceIdentity",
      "Effect": "Allow",
      "Action": "sts:SetSourceIdentity",
      "Resource": "arn:aws:iam::123456789012:role/Developer_Role",
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": "${aws:username}"
        }
      }
    }
  ]
}
```

許容可能なソース ID 値を適用するには、次のロール信頼ポリシーを設定します。このポリシーは、IAM ユーザー `DevUser` にロールを引き受けてソースIDを設定するためのアクセス許可を与えます。`sts:SourceIdentity`条件キーは、許容可能なソース ID 値を定義します。

**Example ソース ID のロール信頼ポリシーの例**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowDevUserAssumeRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/DevUser"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "sts:SourceIdentity": "DevUser"
        }
      }
    }
  ]
}
```

------

ユーザーは、IAMユーザー `DevUser` の認証情報を使用して、次の `DeveloperRole` リクエストを使用して、AWS CLI を受け入れようとしています。

**Example AssumeRole CLI リクエストの例**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \ 
--source-identity DevUser \
```

AWS がリクエストを評価するとき、リクエストコンテキストには `sts:SourceIdentity` の `DevUser` が含まれます。

## ロールを引き受けるときのソース ID の指定
<a name="id_credentials_temp_control-access_monitor-specify-sourceid"></a>

AWS STS `AssumeRole*` API操作の1つを使用してロールの一時的なセキュリティクレデンシャルを取得するときに、ソースIDを指定できます。使用する API オペレーションは、ユースケースによって異なります。例えば、IAMロールを使用して、IAMユーザーに通常はアクセスできない AWS リソースへのアクセスを許可する場合は、`AssumeRole` オペレーションを使用できます。エンタープライズ ID フェデレーションを使用してワークフォースユーザーを管理する場合は、この `AssumeRoleWithSAML` オペレーションを使用できます。OIDC フェデレーションを使用して、エンドユーザーがモバイルまたはウェブアプリケーションにアクセスできるようにする場合は、`AssumeRoleWithWebIdentity` オペレーションを使用できます。このセクションでは、オペレーションごとにソース ID を使用する方法について説明します。一時的な認証情報の一般的なシナリオの詳細については、「[一時的な認証情報の一般的なシナリオ](id_credentials_temp.md#sts-introduction)」を参照してください。。

## AssumeRole でのソース ID の使用
<a name="id_credentials_temp_control-access_monitor-assume-role"></a>

`AssumeRole` オペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。IAM ユーザーまたはロールの認証情報を使用して `AssumeRole` を呼び出すことができます。ロールを引き受けるときにセッションタグを渡すには、`-–source-identity` AWS CLI オプションまたは `SourceIdentity` AWS API パラメータを使用します。次の例は、AWS CLI を使用してソースIDを指定する方法を示しています。

**Example AssumeRole CLI リクエストの例**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \ 
--source-identity Admin \
```

## AssumeRoleWithSAML を使用したソース ID の使用
<a name="id_credentials_temp_control-access_monitor-assume-role-saml"></a>

`AssumeRoleWithSAML` オペレーションを呼び出すプリンシパルは、SAMLベースのフェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。SAML ベースのフェデレーションを使用して AWS マネジメントコンソール にアクセスする方法の詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。AWS CLI または AWS API アクセスの詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。Active Directory ユーザーの SAML フェデレーションを設定するチュートリアルについては、AWS セキュリティブログの「[Active Directory フェデレーションサービスを使用した AWS フェデレーション認証 (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/)」を参照してください。

管理者は、企業ディレクトリのメンバーに AWS STS `AssumeRoleWithSAML` オペレーションを使用しての AWS フェデレーションを許可できます。これを行うには、以下のタスクを完了する必要があります。

1. [組織での SAML プロバイダーの構成](id_roles_providers_saml_3rd-party.md)。

1. [IAM で SAML プロバイダーを作成するには](id_roles_providers_create_saml.md)

1. [SAML フェデレーティッドプリンシパルにロールおよびアクセス許可を AWS で設定します。](id_roles_create_for-idp_saml.md)

1. [SAML IdP の設定を終了し、SAML 認証レスポンスのアサーションを作成する](id_roles_providers_create_saml_assertions.md)

ソース ID の SAML 属性を設定するには、`Attribute` 属性が `Name` に設定されている `https://aws.amazon.com/SAML/Attributes/SourceIdentity` 要素を含めます。`AttributeValue` 要素を使用して、ソース ID の値を指定します。例えば、次の ID 属性をソース ID として渡すとします。

`SourceIdentity:DiegoRamirez`

これらの属性を渡すには、SAML アサーションに以下の要素を含めます。

**Example SAML アサーションのスニペットの例**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
<AttributeValue>DiegoRamirez</AttributeValue>
</Attribute>
```

## AssumeRoleWithWebIdentity によるソース ID の使用
<a name="id_credentials_temp_control-access_monitor-assume-role-web-id"></a>

`AssumeRoleWithWebIdentity` オペレーションを呼び出すプリンシパルは、OpenID Connect (OIDC) 準拠のフェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。AWS マネジメントコンソール アクセスに OIDC フェデレーションを使用する方法の詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。

OpenID Connect (OIDC) からソース ID を渡すには、JSON ウェブトークン (JWT) にソース ID を含める必要があります。`AssumeRoleWithWebIdentity` リクエストを送信するときに、トークンの `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` 名前空間にセッションタグを含めます。OIDC トークンとクレームの詳細については、「Amazon Cognito 開発者ガイド」の「[ユーザープールでのトークンの使用](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)」を参照してください。

例えば、次のデコードされた JWT は、`AssumeRoleWithWebIdentity` ソースIDで `Admin` を呼び出すために使用されるトークンです。

**Example デコードされた JSON ウェブトークンの例**  

```
{
    "sub": "john",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/source_identity":"Admin"
}
```

## ソース ID 情報を使用してアクセスを制御する
<a name="id_credentials_temp_control-access_monitor-control-access"></a>

ソース ID が最初に設定されると、[sts:SourceIdentity](reference_policies_iam-condition-keys.md#ck_sourceidentity)キーがリクエストに存在します。ソース ID が設定されると、[aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity)キーは、ロールセッション中に行われた後続のすべての要求に存在します。管理者は、ソース ID 属性の存在または値に基づいて AWS アクションを実行するための条件付き承認を付与するポリシーを作成できます。

開発者にソースIDを設定して、本番環境の重要な AWS リソースへの書き込み権限を持つ重要なロールを引き受けるようにリクエストするとします。また、AWS を使用してワークフォース ID への `AssumeRoleWithSAML` アクセスを許可するとします。上級開発者の Saanvi と Diego にロールへのアクセス権のみを与えるため、ロールに対して次の信頼ポリシーを作成します。

**Example ソース ID のロール信頼ポリシーの例 (SAML)**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "SAMLProviderAssumeRoleWithSAML",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
      },
      "Action": [
        "sts:AssumeRoleWithSAML"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    },
    {
      "Sid": "SetSourceIdentitySrEngs",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
      },
      "Action": [
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "sts:SourceIdentity": [
            "Saanvi",
            "Diego"
          ]
        }
      }
    }
  ]
}
```

------

信頼ポリシーには、重要なロールを引き受けるために Saanvi または Diego のソース ID を必要とする、`sts:SourceIdentity` の条件が含まれています。

または、OIDC フェデレーションに OIDC プロバイダーを使用していて、`AssumeRoleWithWebIdentity` によってユーザーが認証される場合、信頼ポリシーは次のようになります。

**Example ソース ID のロール信頼ポリシーの例 (OIDC プロバイダー)**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
      },
      "Action": [
        "sts:AssumeRoleWithWebIdentity",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringEquals": {
          "server.example.com:aud": "oidc-audience-id"
        },
        "StringLike": {
          "sts:SourceIdentity": [
            "Saanvi",
            "Diego"
          ]
        }
      }
    }
  ]
}
```

------

### ロールチェーンとクロスアカウント要件
<a name="id_credentials_temp_control-access_monitor-chain"></a>

`CriticalRole` を想定したユーザーが別のアカウントで `CriticalRole_2` を想定できるようにしたいとします。引き受けるために取得されたロールセッションの資格情報`CriticalRole`は、[ロールの連鎖](id_roles.md#iam-term-role-chaining)を 2 番目のロール、`CriticalRole_2`別のアカウントで。ロールは、アカウントの境界を越えて引き継がれています。したがって、`sts:SetSourceIdentity`のアクセス許可は、`CriticalRole` のアクセス許可ポリシーと`CriticalRole_2`のロール信頼ポリシーの両方で付与する必要があります。

**Example CriticalRoleのアクセス権限ポリシーの例**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AssumeRoleAndSetSourceIdentity",
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
    }
  ]
}
```

------

アカウントの境界を越えてソースIDの設定を保護するために、次のロール信頼ポリシーは、`CriticalRole` のロールプリンシパルのみを信頼してソース ID を設定します。

**Example CriticalRole\$12 のロール信頼ポリシーの例**  

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/CriticalRole"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Condition": {
        "StringLike": {
          "aws:SourceIdentity": ["Saanvi","Diego"]
        }
      }
    }
  ]
}
```

------

ユーザーは、CriticalRole を引き受けることで取得したロールセッション資格情報を使用して、次の呼び出しを行います。ソース ID は、CriticalRole の仮定時に設定されているので、明示的に再度設定する必要はありません。ユーザーがソース ID を設定しようとした場合、`CriticalRole` が想定された場合、ロールの引き受けリクエストは拒否されます。

**Example AssumeRole CLI リクエストの例**  

```
aws sts assume-role \ 
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```

呼び出し元プリンシパルがロールを引き受けると、リクエスト内のソース ID は、最初に引き受けたロールセッションから保持されます。したがって、`aws:SourceIdentity` キー と `sts:SourceIdentity` キーの両方がリクエストコンテキストに存在します

## CloudTrail でのソースアイデンティティの表示
<a name="id_credentials_temp_control-access_monitor-ct"></a>

CloudTrail を使用して、ロールを引き受けるか、ユーザーをフェデレートするために行われたリクエストを表示できます。AWS でアクションを実行するための役割またはユーザーのリクエストを表示することもできます。CloudTrail ログファイルには、引き受けたロールまたはフェデレーティッドユーザーセッションのプリンシパルタグに関する情報が含まれます。詳細については、[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)を参照してください。

例えば、ユーザーが AWS STS `AssumeRole` リクエストを行い、ソースIDを設定するとします。`sourceIdentity` 情報は、CloudTrail ログの `requestParameters` キーで見つけることができます。

**Example AWS CloudTrail ログの requestParameters セクションの例**  

```
"eventVersion": "1.05",
    "userIdentity": {
        "type": "AWSAccount",
        "principalId": "AIDAJ45Q7YFFAREXAMPLE",
        "accountId": "111122223333"
    },
    "eventTime": "2020-04-02T18:20:53Z",
    "eventSource": "sts.amazonaws.com",
    "eventName": "AssumeRole",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "203.0.113.64",
    "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
    "requestParameters": {
        "roleArn": "arn:aws:iam::123456789012:role/DevRole",
        "roleSessionName": "Dev1",
        "sourceIdentity": "source-identity-value-set"
    }
```

ユーザーが引き受けたロールセッションを使用してアクションを実行する場合、ソース ID 情報は `userIdentity` キーを CloudTrail ログに追加します。

**Example AWS CloudTrail ログの userIdentity キーの例**  

```
{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
    "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
    "accountId": "123456789012",
    "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
    "sessionContext": {
      "sessionIssuer": {
        "type": "Role",
        "principalId": "AROAJ45Q7YFFAREXAMPLE",
        "arn": "arn:aws:iam::123456789012:role/DevRole",
        "accountId": "123456789012",
        "userName": "DevRole"
      },
      "webIdFederationData": {},
      "attributes": {
        "mfaAuthenticated": "false",
        "creationDate": "2021-02-21T23:46:28Z"
      },
      "sourceIdentity": "source-identity-value-present"
    }
  }
}
```

AWS STS CloudTrail ログの API イベントの例を見るには、「[CloudTrail ログの IAM API イベントの例](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api)」を参照してください。CloudTrail ログファイルに含まれる情報の詳細については、[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) の「*CloudTrail イベントリファレンス*」を参照してください。

# GetFederationToken のアクセス権限
<a name="id_credentials_temp_control-access_getfederationtoken"></a>

`GetFederationToken` オペレーションは、IAM ユーザーによって呼び出され、そのユーザーの一時的な認証情報を返します。このオペレーションでは、ユーザーを*フェデレーション*します。AWS STS フェデレーションユーザーが割り当てられたアクセス権限は、次の 2 ヶ所のいずれかで定義されます。
+ `GetFederationToken` API コールのパラメータとして渡されるセッションポリシー。（こちらが普通です)。
+ ポリシーの `Principal` 要素で AWS STS フェデレーションユーザーのセッションを明示的に指名するリソースベースのポリシー。(こちらはそれほど一般的ではありません)。

セッションポリシーは、一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。AWS STS フェデレーションユーザーのセッションを作成してセッションポリシーを渡すと、結果として得られるセッションのアクセス許可はユーザーのアイデンティティベースのポリシーおよびセッションポリシーの共通部分です。セッションポリシーを使用して、フェデレーションされているユーザーのアイデンティティベースのポリシーによって許可されている以上のアクセス許可を付与することはできません。

ほとんどの場合、`GetFederationToken` API 呼び出しでポリシーを渡さなければ、返される一時的なセキュリティ認証情報はアクセス権限を持ちません。ただし、リソースベースのポリシーでは、セッションに追加のアクセス許可を提供できます。セッションを許可されたプリンシパルとして指定するリソースベースのポリシーを使用してリソースにアクセスできます。

次の図は、ポリシーがどのように相互作用して、`GetFederationToken` の呼び出しによって返される一時的なセキュリティ認証情報のアクセス権限が決まるかを視覚的に示しています。

![\[IAM ユーザー次の図は、セッション許可がユーザーの ID ベースのポリシーとセッションポリシーで共通していることを示すチェックマークを示しています。セッション許可は、ユーザーの ID ベースのポリシーとリソースベースのポリシーで共通している場合もあります。\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)


## 例: GetFederationToken を使用してアクセス権限を割り当てる
<a name="permissions-get-federation-token-example"></a>

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

### ポリシーを IAM ユーザーにアタッチするには
<a name="permissions-get-federation-token-example-iam-user"></a>

この例では、2 つのバックエンドウェブサービスに頼ったブラウザベースのクライアントアプリケーションがあります。1 つのバックエンドサービスは、独自の ID システムを使用してクライアントアプリケーションを認証する独自の認証サーバーです。もう 1 つのバックエンドサービスは、クライアントアプリケーションの機能の一部を提供する AWS サービスです。クライアントアプリケーションはサーバーによって認証され、サーバーは適切なアクセス許可ポリシーを作成または取得します。サーバーは、続いて、`GetFederationToken` API を呼び出して一時的なセキュリティ認証情報を取得し、その認証情報をクライアントアプリケーションに返します。クライアントアプリケーションは、その後、一時的なセキュリティ認証情報を使って AWS サービスに対してリクエストを直接行うことができます。このアーキテクチャでは、AWS 長期的認証情報を埋め込まなくても、クライアントアプリケーションが AWS リクエストを実行できます。

認証サーバーは、`GetFederationToken` という名前の IAM ユーザーの長期的なセキュリティ認証情報を使用して `token-app` API を呼び出します。ただし、長期的な IAM ユーザー認証情報はサーバーにとどまり、決してクライアントには配布されません。次のポリシーの例は `token-app` IAM ユーザーにアタッチされ、AWS STS フェデレーションユーザー (クライアント) が必要とする最も広範囲なアクセス権限を定義します。AWS STS フェデレーションユーザーの一時的なセキュリティ認証情報を取得するには、認証サービスに `sts:GetFederationToken` アクセス許可が必要になることに注意してください。

**Example `token-app` を呼び出す IAMユーザー `GetFederationToken` にアタッチされたポリシーの例**    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:ListTables",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sqs:ReceiveMessage",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sns:ListSubscriptions",
      "Resource": "*"
    }
  ]
}
```

前述のポリシーは、IAM ユーザーに複数のアクセス許可を付与します。ただし、このポリシーだけで AWS STS フェデレーションユーザーにアクセス許可が付与されることはありません。この IAM ユーザーが `GetFederationToken` を呼び出して、API コールのパラメータとしてポリシーを渡さない場合、結果として得られる AWS STS フェデレーションユーザーには有効なアクセス許可がありません。

### パラメータとして渡されたセッションポリシー
<a name="permissions-get-federation-token-example-passed-policy"></a>

AWS STS フェデレーションユーザーに適切なアクセス許可を確実に割り当てる最も一般的な方法は、`GetFederationToken` API コールでセッションポリシーを渡すことです。前の例を拡張して、`GetFederationToken` が IAM ユーザー `token-app` の認証情報を使用して呼び出されると仮定します。次に、API 呼び出しのパラメータとして以下のセッションポリシーを渡すとします。結果として得られる AWS STS フェデレーションユーザーには、`productionapp` という名前の Amazon S3 バケットのコンテンツを一覧表示するアクセス許可があります。ユーザーは、`productionapp` バケット内の項目に対して Amazon S3 `GetObject`、`PutObject`、および `DeleteObject` アクションを実行できません。

アクセス許可は IAM ユーザーポリシーとユーザーが渡すセッションポリシーとの共通部分であるため、フェデレーティッドユーザーにはこれらのアクセス許可が割り当てられます。

AWS STS フェデレーションユーザーは、Amazon SNS、Amazon SQS、Amazon DynamoDB、`productionapp` を除くすべての S3 バケットでアクションを実行できませんでした。これらのアクションは、このアクセス許可が `GetFederationToken` コールに関連付けられている IAM ユーザーに付与されている場合でも拒否されます。

**Example `GetFederationToken` API 呼び出しのパラメータとして渡されるセッションポリシー**    
****  

```
{
  "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/*"]
    }
  ]
}
```

### リソースベースのポリシー
<a name="permissions-get-federation-token-resource-based-policy"></a>

一部の AWS リソースはリソースベースのポリシーをサポートし、これらのポリシーは AWS STS フェデレーションユーザーにアクセス許可を直接付与する別の仕組みを実現します。一部の AWS サービスのみでリソースに基づくポリシーをサポートしています。たとえば、Amazon S3 にはバケット、Amazon SNS にはトピック、Amazon SQS にはキューがあり、これらにポリシーをアタッチできます。リソースベースのポリシーをサポートするすべてのサービスのリストについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を参照の上、テーブルの「リソースベースのポリシー」列を確認してください。リソースベースのポリシーを使用し、AWS STS フェデレーションユーザーに直接アクセス許可を割り当てることができます。リソースベースのポリシーの `Principal` 要素で AWS STS フェデレーションユーザーの Amazon Resource Name (ARN) を指定します。以下の例では、これを表し、また `productionapp` という名前の S3 バケットを使用して前の例を拡張しています。

次のリソースベースのポリシーは、バケットにアタッチされています。このバケットポリシーでは、Carol という名前の AWS STS フェデレーションユーザーに対してバケットへのアクセスを許可します。以前に説明したポリシーの例が `token-app` IAM ユーザーにアタッチされると、Carol という名前の AWS STS フェデレーションユーザーは `productionapp` という名前のバケットに対し、`s3:GetObject`、`s3:PutObject`、`s3:DeleteObject` のアクションを実行するアクセス許可があります。これは、`GetFederationToken` API コールのパラメータとしてセッションポリシーが渡されていない場合にも当てはまります。この場合、Carol という名前の AWS STS フェデレーションユーザーは、次のリソースベースのポリシーによってアクセス権限が明示的に付与されているからです。

IAM ユーザー***と*** AWS STS フェデレーションユーザーの両方にアクセス許可が明示的に付与されている場合に限り、AWS STS フェデレーションユーザーにアクセス許可が付与されることについて覚えておきましょう。次の例のように、ポリシーの `Principal` 要素で AWS STS フェデレーションユーザーを明示的に指名するリソースベースのポリシーによって (アカウント内で) 付与することもできます。

**Example フェデレーティッドユーザーにアクセスを許可するバケットポリシーの例**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Principal": {
            "AWS": "arn:aws:sts::111122223333:federated-user/Carol"
        },
        "Effect": "Allow",
        "Action": [
            "s3:GetObject",
            "s3:PutObject",
            "s3:DeleteObject"
        ],
        "Resource": [
            "arn:aws:s3:::productionapp/*"
        ]
    }
}
```

ポリシーの評価方法の詳細については、「[ポリシーの評価論理](reference_policies_evaluation-logic.md)」を参照してください。

# GetSessionToken のアクセス権限
<a name="id_credentials_temp_control-access_getsessiontoken"></a>

`GetSessionToken` API オペレーション、あるいは `get-session-token` CLI を呼び出す主な場面は、ユーザーを多要素認証 (MFA) で認証する必要がある場合です。MFA で認証されたユーザーが要求した場合にのみ、特定のアクションを許可するポリシーを作成することができます。MFA 認可チェックを正常に渡すには、ユーザーはまず `GetSessionToken` を呼び出し、オプションの `SerialNumber` および `TokenCode` パラメータを含める必要があります。ユーザーが MFA デバイスで正常に認証されている場合、`GetSessionToken` API オペレーションで返される認証情報には MFA コンテキストが含まれています。このコンテキストは、ユーザーが MFA で認証され、MFA 認証を必要とする API オペレーションへのアクセス権限があることを示します。

## GetSessionToken に必要なアクセス権限
<a name="getsessiontoken-permissions-required"></a>

ユーザーがセッショントークンを取得するために必要なアクセス権限はありません。`GetSessionToken` オペレーションの目的は、MFA を使用してユーザーを認証することです。認証オペレーションを制御するためにポリシーを使用することはできません。

ほとんどの AWS オペレーションを実行するためのアクセス権限を付与するには、ポリシーに同じ名前のアクションを追加します。たとえば、ユーザーを作成するには、`CreateUser` API オペレーション、`create-user` CLI コマンド、または AWS マネジメントコンソール を使用する必要があります。これらのオペレーションを実行するには、`CreateUser` アクションにアクセスできるポリシーを持っている必要があります。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:CreateUser",
            "Resource": "*"
        }
    ]
}
```

------

ポリシーに `GetSessionToken` アクションを含めることはできますが、これはユーザーが `GetSessionToken` オペレーションを実行する権限に影響を及ぼしません。

## GetSessionToken によるアクセス権限付与
<a name="getsessiontoken-permissions-granted"></a>

`GetSessionToken` が IAM ユーザーの認証情報によって呼び出された場合、一時的なセキュリティ認証情報は IAM ユーザーと同じアクセス権限を持ちます。同様に、`GetSessionToken` が AWS アカウントのルートユーザー 認証情報によって呼び出された場合、一時的なセキュリティ認証情報は ルートユーザーのアクセス許可を持ちます。

**注記**  
`GetSessionToken` は、ルートユーザー認証情報を使用して呼び出さないようお勧めします。代わりに、[ベストプラクティス](best-practices-use-cases.md)に従って、必要なアクセス許可を持つ IAM ユーザーを作成します。AWS との日常的なやり取りには、これらの IAM ユーザーを使用します。

`GetSessionToken` を呼び出すときに取得する一時的な認証情報には、次の機能と制限があります。
+ フェデレーションのシングルサインオンエンドポイント `https://signin.aws.amazon.com/federation` に認証情報を渡すことで AWS マネジメントコンソール にアクセスできます。詳細については、「[AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](id_roles_providers_enable-console-custom-url.md)」を参照してください。
+ 認証情報を使用して IAM または AWS STS API オペレーションを呼び出すことは**できません**。認証情報を使用してその他の ** サービスの API オペレーションを呼び出すことは**できますAWS。

[AWS STS 認証情報を比較する](id_credentials_sts-comparison.md) で、この API オペレーションおよびその制限と機能を、一時的なセキュリティ認証情報を作成する他の API と比較してください。

`GetSessionToken` を使用した MFA 保護 API アクセスの詳細については、「[MFA を使用した安全な API アクセス](id_credentials_mfa_configure-api-require.md)」を参照してください。

# 一時的なセキュリティ認証情報のアクセス権限を無効にする
<a name="id_credentials_temp_control-access_disable-perms"></a>

一時的なセキュリティ認証情報は、期限が切れるまで有効です。これらの認証情報は、900 秒 (15 分) から最大 129,600 秒 (36 時間) までの指定された期間有効です。デフォルトのセッション時間は 43,200 秒 (12 時間) です。これらの認証情報は取り消すことができますが、認証情報を漏洩させて悪意あるアカウントの活動に利用されないようにIAM ユーザーまたはロールのアクセス許可を変更する方法もあります。一時的なセキュリティ認証情報に割り当てられるアクセス許可は、AWS のリクエストの実行に使用されるたびに評価されます。認証情報からすべてのアクセス許可を削除すると、それらを使用している AWS のリクエストは失敗します。

ポリシーの更新が有効になるまでには、数分かかる場合があります。IAM ロール セッションの場合、ロールの一時的なセキュリティ認証情報を取り消し、ロールを引き受けるすべてのユーザーに新しい認証情報の再認証およびリクエストを強制します。詳細については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)」を参照してください。

AWS アカウントのルートユーザー のアクセス許可を変更することはできません。同様に、ルートユーザーとしてサインインしているときに `GetFederationToken` または `GetSessionToken` を呼び出して作成した一時的セキュリティ認証情報のアクセス許可を変更することはできません。そのため、ルートユーザーとして `GetFederationToken` または `GetSessionToken` を呼び出さないようお勧めします。

IAM ユーザーのアクセス許可を変更する手順については、「[IAM ユーザーのアクセス許可を変更する](id_users_change-permissions.md)」を参照してください。

IAM ロールのアクセス許可を変更する手順については、「[ロールに対するアクセス許可を更新する](id_roles_update-role-permissions.md)」を参照してください。

**重要**  
IAM アイデンティティセンターのアクセス許可セットから作成された IAM のロールを編集することはできません。IAM アイデンティティセンターでユーザーのアクティブなアクセス許可セットセッションを取り消す必要があります。詳細については、「IAM Identity Center ユーザーガイド」の「[Revoke active IAM role sessions created by permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions)」を参照してください。

**Topics**
+ [

## ロールに関連するすべてのIAM ロールセッションに対するアクセスを拒否する
](#deny-access-to-all-sessions)
+ [

## IAM ロールセッションへのアクセスを拒否する
](#deny-access-to-specific-session)
+ [

## 条件コンテキストキーを使用した一時的なセキュリティ認証情報セッションへのアクセスを拒否する
](#deny-access-to-specific-session-condition-key)
+ [

## リソースベースのポリシーを使用して特定のプリンシパルへのアクセスを拒否する
](#deny-access-with-resource-based)

## ロールに関連するすべてのIAM ロールセッションに対するアクセスを拒否する
<a name="deny-access-to-all-sessions"></a>

この手順は、ロールに関連付けられた**すべての** IAM ロールセッションに対するアクセス許可を拒否します。次のような不審なアクセスが懸念される場合は、この方法を使用します。


+ クロスアカウントアクセスを使用している別のアカウントのプリンシパル
+ アカウント内の AWS リソースへのアクセス許可を持つ外部ユーザー ID
+ OIDC プロバイダーを使用して、モバイルまたはウェブアプリケーションで認証されているユーザー

`AssumeRole`、`AssumeRoleWithSAML`、または `AssumeRoleWithWebIdentity`、`GetFederationToken`、または `GetSessionToken` を呼び出して取得した一時的なセキュリティ認証情報に割り当てたアクセス許可を変更または削除するには、ロールのアクセス許可を定義する ID ベースのポリシーを編集または削除します。

**重要**  
また、プリンシパルのアクセスを許可するリソースベースのポリシーがある場合、そのリソースに対する明示的な拒否を追加する必要があります。詳細については、「[リソースベースのポリシーを使用して特定のプリンシパルへのアクセスを拒否する](#deny-access-with-resource-based)」を参照してください。

**ロールに関連する**すべて**の IAM ロールセッションへのアクセスを拒否する**

1. AWS マネジメントコンソール にサインインし、IAM コンソール を開きます。

1. ナビゲーションペインで **[ロール]** を選択します。

1. 編集するロールの名前を選択します。検索ボックスを使用してリストをフィルタリングします。

1. **[アクセス許可]** タブを選択します。

1. 編集する関連ポリシーを選択します。カスタマー管理ポリシーを編集する前に、**[エンティティアタッチ]** タブを確認して、同じポリシーがアタッチされている可能性のある他のアイデンティティへのアクセスを中断しないようにします。

1. **[JSON]** タブを選択してポリシーを更新し、すべてのリソースとアクションを拒否します。
**注記**  
これらのアクセス許可は、AWS 管理ポリシー [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) のアクセス許可と同じです。この AWS 管理ポリシーは、すべてのアクセスを拒否する IAM ユーザーまたはロールにアタッチできます。

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "DenyAll",
               "Effect": "Deny",
               "Action": [
                   "*"
               ],
               "Resource": "*"
           }
       ]
   }
   ```

------

1. **[確認]** ページで、ポリシーの **[概要]** を確認してから、**[変更の保存]** を選択して作業を保存します。

ロールのポリシーを更新すると、変更内容はそのロールに関連付けられているすべての一時的なセキュリティ認証情報のアクセス許可に影響します。これには、ロールのアクセス許可ポリシーを変更する前に発行された認証情報も含まれます。

ポリシーを更新すると、[ロールの一時的なセキュリティ認証情報を取り消し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)、ロールが発行した認証情報に対するすべてのアクセス許可をすぐに取り消すことができます。

## IAM ロールセッションへのアクセスを拒否する
<a name="deny-access-to-specific-session"></a>

IAM ロールをすべて拒否ポリシーで更新したり、ロールを完全に削除したりすると、そのロールにアクセスできるすべてのユーザーのアクセスが中断されます。ロールに関連付けられている他のすべてのセッションのアクセス許可に影響を与えずに、アクセスを拒否できます。

`Principal` は、[条件コンテキストキー](#deny-access-to-specific-session-condition-key)または[リソースベースのポリシー](#deny-access-with-resource-based)を使用してアクセス許可を拒否できます。

**ヒント**  
AWS CloudTrail ログを使用して、フェデレーションユーザーの ARN を確認できます。詳細については、「[AWS CloudTrail を使用してフェデレーションユーザーを簡単に識別する方法](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/)」を参照してください。

## 条件コンテキストキーを使用した一時的なセキュリティ認証情報セッションへのアクセスを拒否する
<a name="deny-access-to-specific-session-condition-key"></a>

認証情報を作成した IAM ユーザーまたはロールのアクセス許可に影響を与えることなく、特定の一時的なセキュリティ認証情報へのアクセスを拒否したい場合は、アイデンティティベースのポリシーで条件コンテキスト キーを使用できます。IAM ロールの場合、ポリシーの更新後は、[ロールの一時的なセキュリティ認証情報を取り消し](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)、すべての発行された認証情報をすぐに取り消すこともできます。

条件コンテキストキーの詳細については、「[AWS グローバル条件コンテキストキー](reference_policies_condition-keys.md)」を参照してください。

### aws:PrincipalArn
<a name="deny-access-condition-key-principalarn"></a>

ID ベースのポリシーで条件コンテキストキー [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) を使用して、Amazon リソースネーム (ARN) による特定のプリンシパルへのアクセスを拒否できます。これを行うには、ポリシーの Condition 要素で、一時的なセキュリティ認証情報が関連付けられている IAM ユーザー、ロール、または AWS STS フェデレーションユーザーセッションの ARN を指定します。

**ARN による特定のプリンシパルへのアクセスを拒否するには**

1. IAM コンソールのナビゲーションペインで、**[ユーザー]** または**[ロール]** を選択します。

1. 編集する IAM ユーザーまたはロールの名前を選択します。検索ボックスを使用してリストをフィルタリングします。

1. **[アクセス許可]** タブを選択します。

1. 編集する関連ポリシーを選択します。カスタマー管理ポリシーを編集する前に、**[エンティティアタッチ]** タブを確認して、同じポリシーがアタッチされている可能性のある他のアイデンティティへのアクセスを中断しないようにします。

1. **[JSON]** タブを選択し、次の例に示すようにプリンシパル ARN の拒否ステートメントを追加します。

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
           "ArnEquals": {
             "aws:PrincipalArn": [
               "arn:aws:iam::222222222222:role/ROLENAME",
               "arn:aws:iam::222222222222:user/USERNAME",
               "arn:aws:iam::222222222222:federated-user/USERNAME" 
             ]
           }
         }
       }
     ]
   }
   ```

------

1. **[確認]** ページで、ポリシーの **[概要]** を確認してから、**[変更の保存]** を選択して作業を保存します。

### aws:SourceIdentity
<a name="deny-access-condition-key-sourceidentity"></a>

ID ベースのポリシーで条件コンテキストキー [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) を使用すると、IAM ロールセッションに関連付けられている特定のソース ID へのアクセスを拒否できます。これは、プリンシパルが任意の AWS STS `assume-role`\$1 CLI コマンドまたは AWS STS `AssumeRole`\$1 API オペレーションを使用してロールを引き受けるときに、`SourceIdentity` リクエストパラメータを設定することでロールセッションを発行したのであれば、必ず適用されます。このためには、一時的なセキュリティ認証情報が関連付けられているソース ID をポリシーの `Condition` 要素に指定します。

コンテキストキー [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname) とは異なり、ソース ID を設定した後は、値を変更できません。`aws:SourceIdentity` キーは、ロールが実行するすべてのアクションのリクエストコンテキストに存在します。セッション認証情報を使用して別のロールを引き受けた場合、ソース ID は後続のロールセッションに引き継がれます。別のロールからあるロールを引き受けると、[ロールの連鎖](id_roles.md#iam-term-role-chaining)と呼ばれます。

次のポリシーは、条件コンテキストキー `aws:SourceIdentity` を使用して一時的なセキュリティ認証情報のセッションへのアクセスを拒否する方法の例を示しています。ロールセッションに関連付けられたソース ID を指定した場合、認証情報を作成したロールのアクセス許可に影響を与えることなく、その指定されたソース ID に関連付けられたロールセッションが拒否されます。この例の場合、ロールセッションの発行時にプリンシパルによって設定されたソース ID は `nikki_wolf@example.com` です。ポリシーの Condition にソース ID が含まれ、ポリシーの Effect が `Deny` に設定されているため、`nikki_wolf@example.com` ソース ID とのロールセッションで行われるリクエストは拒否されます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:SourceIdentity": [
            "nikki_wolf@example.com",
            "<source identity value>"
          ]
        }
      }
    }
  ]
}
```

------

### aws:userid
<a name="deny-access-condition-key-userid"></a>

ID ベースのポリシーで条件コンテキストキー [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) を使用して、IAM ユーザーまたはロールに関連する一時的なセキュリティ認証情報のすべてまたは特定のセッションへのアクセスを拒否できます。これを行うには、一時的なセキュリティ認証情報がポリシーの `Condition` 要素に関連付けられている IAM ユーザー、ロール、または AWS STS フェデレーションユーザーの一意の識別子 (ID) を指定します。

次のポリシーは、条件コンテキストキー `aws:userid` を使用して一時的なセキュリティ認証情報のセッションへのアクセスを拒否する方法の例を示しています。
+ `AIDAXUSER1` は、IAM ユーザー用の一意の ID を表します。コンテキストキー `aws:userid` の値として IAM ユーザーの一意の ID を指定すると、IAM ユーザーへのアクセスが拒否されます。これには、 `GetSessionToken` API を呼び出して作成された一時的なセキュリティ認証情報セッションが含まれます。
+ `AROAXROLE1:*` は、IAM ロールに関連付けられたすべてのセッションの一意の ID を表します。コンテキストキー `aws:userid` の値として、caller-specified-role-session-name の部分に IAM ロールの一意の ID とワイルドカード (\$1) 文字を指定すると、ロールに関連付けられたすべてのセッションが拒否されます。
+ `AROAXROLE2:<caller-specified-role-session-name>` は、assumed-role セッション用の一意の ID を表します。assumed-role の一意の ID の caller-specified-role-session-name の部分で、ロールのセッション名を指定するか、StringLike 条件演算子を使用する場合はワイルドカード文字を指定できます。ロールのセッション名を指定すると、認証情報を作成したロールのアクセス許可に影響を与えずに、指定されたロールのセッションが拒否されます。ロールのセッション名にワイルドカード文字を指定すると、そのロールに関連するすべてのセッションが拒否されます。
**注記**  
呼び出し側で指定したロールセッション名 (引き受けたロールセッションの一意の識別子の一部) は、ロールの連鎖の際に変更できます。ロールの連鎖は、あるロールが別のロールを引き受けると発生します。ロールセッション名は、プリンシパルが AWS STS `AssumeRole` API オペレーションを使用してロールを引き受けるときに、`RoleSessionName` リクエストパラメータを使用して設定します。
+ `account-id:<federated-user-caller-specified-name>` は、AWS STS フェデレーションユーザーのセッション用の一意の ID を表します。IAM ユーザーは `GetFederationToken` API を呼び出してこのセッションを作成します。AWS STS フェデレーションユーザーのセッションに一意の ID を指定すると、認証情報を作成した IAM ユーザーのアクセス許可に影響を与えることなく、指名されたフェデレーティッドセッションが拒否されます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:userId": [
            "AIDAXUSER1",
            "AROAXROLE1:*",
            "AROAXROLE2:<caller-specified-role-session-name>",
            "123456789012:<federated-user-caller-specified-name>"
          ]
        }
      }
    }
  ]
}
```

------

プリンシパルキーの値の具体的な例については、「[プリンシパルキーの値](reference_policies_variables.md#principaltable)」を参照してください。IAM 一意の ID とその取得方法については、「[一意の識別子](reference_identifiers.md#identifiers-unique-ids)」を参照してください。

## リソースベースのポリシーを使用して特定のプリンシパルへのアクセスを拒否する
<a name="deny-access-with-resource-based"></a>

リソースベースのポリシーを使用して特定のプリンシパルへのアクセスを制限するには、 `Condition` 要素で条件コンテキストキー [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) または [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) を使用できます。リソースベースのポリシーは、リソースにアタッチされたアクセス許可ポリシーであり、リソースにアクセスできるユーザーとそのリソースに対して実行できるアクションを制御します。

`aws:PrincipalARN` コンテキストキーを使用する場合は、ポリシーの Condition 要素で一時的なセキュリティ認証情報に関連付けられた IAM ユーザー、ロール、または AWS STS フェデレーティッドユーザーセッションの ARN を指定します。次のポリシー例は、リソースベースのポリシーで `aws:PrincipalARN` コンテキストキーを使用する方法を示しています。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Principal": "*",
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
    "Condition": {
      "ArnEquals": {
        "aws:PrincipalArn": [
          "arn:aws:iam::222222222222:role/ROLENAME",
          "arn:aws:iam::222222222222:user/USERNAME",
          "arn:aws:sts::222222222222:federated-user/USERNAME"
        ]
      }
    }
  }
}
```

------

`aws:SourceIdentity` コンテキストキーを使用する場合は、ポリシーの `Condition` 要素でロールの一時的なセキュリティ認証情報に関連付けられたソース ID 値を指定します。これは、プリンシパルが任意の AWS STS `assume-role`\$1 CLI コマンドまたは AWS STS `AssumeRole`\$1 API オペレーションを使用してロールを引き受けるときに、`SourceIdentity` リクエストパラメータを設定することでロールセッションを発行したのであれば、必ず適用されます。次の例は、リソースベースのポリシーで `aws:SourceIdentity` コンテキストキーを使用する方法を示しています。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Principal": "*",
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
    "Condition": {
      "StringLike": {
        "aws:SourceIdentity": [
          "nikki_wolf@example.com",
          "<source identity value>"
        ]
      }
    }
  }
}
```

------

プリンシパルの ID ベースのポリシーのみを更新しても、リソースベースのポリシーで許可されるアクションを実行できます。ただし、これらのアクションが ID ベースのポリシーで明示的に拒否されている場合を除きます。

**リソースベースのポリシーで特定のプリンシパルへのアクセスを拒否するには**

1. サービスがリソースベースのポリシーをサポートしているかどうかについては、「[IAM と連携する AWS のサービス](reference_aws-services-that-work-with-iam.md)」を確認してください。

1. AWS マネジメントコンソール にサインインして、サービスのコンソールを開きます。ポリシーをアタッチするコンソール内の場所は、サービスごとに異なります。

1. リソースベースのポリシーを編集します。拒否ポリシー ステートメントを追加して、認証情報の識別する情報を指定します。

   1. `Principal` 要素にワイルドカード (\$1) を入力します。プリンシパルは `Condition` 要素で制限されます。

   1. `Effect` 要素に「Deny」と入力します。

   1. `Action` に、サービスの名前空間と拒否するアクションの名前を入力します。すべてのアクションを拒否するには、ワイルドカード (\$1) 文字を使用します。例: `"s3:*"`。

   1. `Resource` 要素に、ターゲットリソースの ARN を入力します。例: `"arn:aws:s3:::amzn-s3-demo-bucket"`。

   1. `Condition` 要素で、 `aws:PrincipalARN` または `aws:SourceIdentity` コンテキストキーを指定します。

      `aws:PrincipalARN` コンテキストキーを使用する場合は、アクセスを拒否するプリンシパルの ARN を入力します。

      `aws:SourceIdentity` コンテキストキーを使用する場合は、ロールセッションで設定されたソース ID 値を入力してアクセスを拒否します。

1. 作業内容を保存します。

# 一時的なセキュリティ認証情報を作成するためのアクセス権限の付与
<a name="id_credentials_temp_control-access_enable-create"></a>

デフォルトで、IAM ユーザーには AWS STS フェデレーションユーザーおよびロールに一時的なセキュリティ認証情報を作成するアクセス許可がありません。ユーザーに上記の権限を提供するポリシーを使用する必要があります。ユーザーに直接アクセス権限を付与できますが、アクセス権限はグループに付与することを強くお勧めします。これによって、アクセス権限の管理が容易になります。ユーザーがアクセス権限に関連付けられているタスクを実行する必要がなくなった場合には、そのユーザーをグループから削除するだけです。他のユーザーがそのタスクを実行する必要がある場合には、そのユーザーをグループに追加して、アクセス権限を付与します。

AWS STS フェデレーションユーザーのセッションまたはロールに一時的なセキュリティ認証情報を作成するアクセス許可を IAM グループに付与するには、次の権限の少なくとも 1 つを付与するポリシーをアタッチします。
+ OIDC および SAML フェデレーティッドプリンシパルが IAM ロールにアクセスするには、AWS STS `AssumeRole` にアクセス許可を付与します。
+ <a name="para_gsy_hxg_1t"></a>ロールが不要な AWS STS フェデレーションユーザーには、AWS STS `GetFederationToken` にアクセス許可を付与します。

 `AssumeRole` および `GetFederationToken` の API オペレーションの違いの詳細については、「[一時的なセキュリティ認証情報をリクエストする](id_credentials_temp_request.md)」を参照してください。

また、IAM ユーザーは、一時的なセキュリティ認証情報を作成するために [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) を呼び出すこともできます。ユーザーが `GetSessionToken` を呼び出すためには、アクセス権限を必要としません。このオペレーションの目的は、MFA を使用してユーザーを認証することです。認証を制御するためにポリシーを使用することはできません。つまり、IAM ユーザーが `GetSessionToken` を呼び出して、一時的な認証情報を作成することを回避することはできません。

**Example ロールを引き受けるアクセス許可を付与するポリシー**  
以下のポリシーの例では、AWS アカウント `123123123123` の `UpdateApp` ロールに対して `AssumeRole` を呼び出すアクセス許可が与えられます。`AssumeRole` を使用する場合、フェデレーティッドユーザーの代わりにセキュリティ認証情報を作成するユーザー (またはアプリケーション) は、ロールのアクセス許可ポリシーに指定されていないあらゆるアクセス許可を委任することができません。    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
  }]
}
```

**Example フェデレーティッドユーザーの一時的なセキュリティ認証情報を作成するアクセス権限を付与するポリシーの例**  
次のポリシーの例では、`GetFederationToken` にアクセスできるアクセス許可が付与されます。    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:GetFederationToken",
    "Resource": "*"
  }]
}
```

**重要**  
IAM ユーザーが `GetFederationToken` を持つ AWS STS フェデレーションユーザーに対して一時的なセキュリティ認証情報を作成するためにアクセス権限を付与する場合、そのユーザーが独自のアクセス権限を委任できるようになりますので注意してください。IAM ユーザーや AWS アカウント へのアクセス許可の委任については、「[アクセス権を委任するポリシーの例](id_roles_create_policy-examples.md)」を参照してください。一時的なセキュリティ認証情報のアクセス許可を制御する方法の詳細については、「[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)」を参照してください。

**Example フェデレーティッドユーザーの一時的セキュリティ認証情報を作成するユーザーを限定するアクセス許可を付与するポリシーの例**  
IAM ユーザーが `GetFederationToken` 呼び出しをできるようにする場合、IAM ユーザーに委任できる権限を制限することがベストプラクティスです。例えば次のポリシーでは、名前が「*Manager*」で始まる AWS STS フェデレーションユーザーのみに対し、IAM ユーザーが一時的なセキュリティ認証情報を作成できるようにする方法を示します。    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:GetFederationToken",
    "Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
  }]
}
```

# ID 拡張コンソールセッションを使用するための許可の付与
<a name="id_credentials_temp_control-access_sts-setcontext"></a>

ID 拡張コンソールセッションでは、ユーザーがサインインするときに、AWS IAM アイデンティティセンター ユーザーとセッション ID をユーザーの AWS セッションに含めることができます。例えば、Amazon Q Developer Pro は ID 拡張コンソールセッションを使用して、サービスエクスペリエンスをパーソナライズします。ID 拡張コンソールセッションの詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[ID 拡張セッションの有効化](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html)」を参照してください。Amazon Q Developer のセットアップについては、「Amazon Q Developer ユーザーガイド」の「[Setting up Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html)」を参照してください。

ユーザーが ID 拡張コンソールセッションを利用できるようにするには、ID ベースのポリシーを使用して、ユーザー自身のコンソールセッションを表すリソースに対する `sts:SetContext` 許可を IAM プリンシパルに付与する必要があります。

**重要**  
デフォルトで、ユーザーには ID 拡張コンソールセッションのコンテキストを設定する許可がありません。これを許可するには、以下のポリシー例に示すように、ID ベースのポリシーで `sts:SetContext` アクセス許可を IAM プリンシパルに付与する必要があります。

次の ID ベースのポリシー例は、`sts:SetContext` 許可を IAM プリンシパルに付与することで、プリンシパルがプリンシパル自身の AWS コンソールセッションに ID 拡張コンソールセッションコンテキストを設定できるようにします。ポリシーリソース `arn:aws:sts::account-id:self` は、呼び出し元の AWS セッションを表します。IAM Identity Center のアクセス許可セットを使用してこのポリシーをデプロイする場合など、同じアクセス許可ポリシーが複数のアカウントにデプロイされる場合は、`account-id` ARN セグメントをワイルドカード文字 `*` に置き換えることができます。

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:SetContext",
            "Resource": "arn:aws:sts::111122223333:self"
        }
    ]
}
```

------

# AWS リージョン で AWS STS を管理する
<a name="id_credentials_temp_enable-regions"></a>

リージョンエンドポイントは、AWS Web Services の特定のリージョン内のエントリポイントの URL です。 AWS では、レイテンシーの短縮、冗長性の構築、セッショントークンの有効性の向上のために、グローバルエンドポイントではなく、リージョンの AWS Security Token Service (AWS STS) エンドポイントを使用することをお勧めします。グローバル (レガシー) AWS STS エンドポイント `https://sts.amazonaws.com` は高い可用性を備えていて、単一の AWS リージョン、米国東部 (バージニア北部）、および他のエンドポイントと同様にホストされますが、他のリージョンのエンドポイントへの自動フェイルオーバーは提供されません。
+ **レイテンシーの低減** – お客様のサービスやアプリケーションに地理的に近いエンドポイントに対して AWS STS の呼び出しを実行することにより、より低いレイテンシーとより高速な応答時間で AWS STS サービスにアクセスできます。
+ **冗長性の構築** – 予測可能な範囲に影響を封じ込めることによって、ワークロード内の障害の影響を限られた数のコンポーネントに限定できます。リージョン AWS STS エンドポイントを使用すると、コンポーネントの範囲をセッショントークンの範囲に合わせることができます。この信頼性の柱の詳細については、「AWS Well-Architected Framework」の「[障害部分を切り離してワークロードを保護する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)」を参照してください。
+ **セッショントークンの有効性を向上させる** – リージョンの AWS STS エンドポイントからのセッショントークンはすべての AWS リージョン で有効です。グローバル STS エンドポイントからのセッショントークンは、デフォルトで有効になっている AWS リージョン でのみ有効です。アカウントで新しいリージョンを有効にする場合、リージョン別 AWS STS エンドポイントからのセッショントークンを使用できます。グローバルエンドポイントの使用を選択した場合、グローバルエンドポイントに対する AWS STS セッショントークンのリージョンの互換性を変更する必要があります。これにより、トークンはすべての AWS リージョン で有効になります。

AWS STS リージョンのリストとエンドポイントの詳細については、「[AWS STS のリージョンとエンドポイント](id_credentials_temp_region-endpoints.md)」を参照してください。

**注記**  
回復性とパフォーマンスを向上させるために、AWS は、[デフォルトで有効](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)になっているリージョンの AWS Security Token Service (AWS STS) グローバルエンドポイント (`https://sts.amazonaws.com`) を変更しました。グローバルエンドポイントへの AWS STS リクエストは、ワークロードと同じ AWS リージョン で自動的に処理されます。これらの変更はオプトインリージョンにはデプロイされません。適切な AWS STS リージョンエンドポイントを使用することをお勧めします。詳細については、「[AWS STS グローバルエンドポイントの変更](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes)」を参照してください。

**Topics**
+ [

## AWS リージョン での AWS STS のアクティブ化と非アクティブ化
](#sts-regions-activate-deactivate)
+ [

## AWS STS リージョンを使用するコードの記述
](#id_credentials_temp_enable-regions_writing_code)
+ [

## グローバルエンドポイントセッショントークンの管理
](#sts-regions-manage-tokens)

## AWS リージョン での AWS STS のアクティブ化と非アクティブ化
<a name="sts-regions-activate-deactivate"></a>

リージョンに対して AWS STS エンドポイントを有効にすると、AWS STS は、AWS STS リクエストを行うアカウントのユーザーとロールに一時的な認証情報を発行できます。その後、これらの認証情報は、デフォルトで有効であるリージョン、または手動で有効にされているリージョンで使用できます。デフォルトで有効になっているリージョンでは、一時認証情報が生成されるアカウントでリージョン AWS STS エンドポイントをアクティブ化する必要があります。リクエストを行うときに、ユーザーが同じアカウントにサインインしたかまたは別のアカウントにサインインしたかは関係ありません。手動で有効化されたリージョンを使用して別の AWS アカウント のロールの一時的な認証情報をリクエストする場合、ターゲットアカウント (ロールを含むアカウント) は、AWS STS オペレーションのためにそのリージョン有効にする必要があります。これで一時的なセキュリティ認証情報が正しく生成されます。

例えば、アカウント A 内のあるユーザーが [AWS STS リージョンのエンドポイント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) `https://sts.ap-southeast-3.amazonaws.com` に `sts:AssumeRole` API リクエストを送信するとします。このリクエストは、アカウント B にある `Developer` という名前のロールの一時的な認証情報を求めるものです。これはアカウント B 内のエンティティの認証情報を作成するリクエストであるため、アカウント B が `ap-southeast-3` リージョンを有効にする必要があります。アカウント A (または他のアカウント) のユーザーは、`ap-southeast-3` AWS STS エンドポイントを呼び出して、自分のアカウントでこのリージョンがアクティブ化されているかどうかに関わらず、アカウント B の認証情報をリクエストできます。詳細については、「[Enable or disable AWS リージョン in your account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)」を参照してください。

**注記**  
アクティブなリージョンはそのアカウントで一時的な認証情報を使用するすべてのユーザーが利用できます。どの IAM ユーザーまたはロールがリージョンにアクセスできるかを制御するには、アクセス許可ポリシーで、`aws:RequestedRegion` 条件キーを使用します。

**デフォルトで有効なリージョンで AWS STS をアクティブ化または非アクティブ化するには (コンソール)**

1. IAM 管理タスクを実行するアクセス許可があるルートユーザーまたはユーザーとしてサインインします。

1. [IAM コンソール](https://console.aws.amazon.com/iam/home?#home)を開き、ナビゲーションペインで [[https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings)] を選択します。

1. **[Security Token Service (STS)]** セクションの **[Endpoints]** (エンドポイント) で、設定するリージョンを見つけ、**[STS status]** (STS ステータス) 列で **[Active]** (アクティブ) または **[Inactive]** (非アクティブ) を選択します。

1. 表示されたダイアログボックスで、**[Activate]** (有効化) または **[Deactivate]** (無効化) を選択します。

有効にする必要があるリージョンの場合、リージョンを有効にすると AWS STS が自動的にアクティブになります。リージョンを有効にすると、AWS STS はそのリージョンに対して常にアクティブになり、非アクティブ化することはできません。デフォルトで無効になっているリージョンを有効にする方法については、「AWS アカウント管理 リファレンスガイド」の「[アカウントで使用できる AWS リージョン の指定](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)」を参照してください。

## AWS STS リージョンを使用するコードの記述
<a name="id_credentials_temp_enable-regions_writing_code"></a>

リージョンをアクティブ化すると、そのリージョンに AWS STS API 呼び出しを割り振ることができます。次の Java コードスニペットは、欧州 (ミラノ)(eu-south-1) リージョンにリクエストを送信するように `AWSSecurityTokenService` オブジェクトを設定する方法を示しています。

```
EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1");
AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard()
.withCredentials(credentials)
.withEndpointConfiguration(regionEndpointConfig)
.build();
```

AWS STS では、リージョンのエンドポイントへの呼び出しを推奨します。手動でリージョンを有効にする方法については、「AWS アカウント管理 リファレンスガイド」の「[アカウントで使用できる AWS リージョン の指定](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)」を参照してください。

この例では、最初の行は `regionEndpointConfig` という `EndpointConfiguration` オブジェクトをインスタンス化し、エンドポイントの URL と AWS リージョン をパラメータとして渡します。

AWS SDK の環境変数を使用して AWS STS のリージョンエンドポイントを設定する方法については、「AWS SDK とツールリファレンスガイド」の「[AWS STS リージョンエンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)」を参照してください。

他のすべての言語とプログラミング環境の組み合わせについては、「[関連する SDK のドキュメント](https://aws.amazon.com/tools/)」を参照してください。

## グローバルエンドポイントセッショントークンの管理
<a name="sts-regions-manage-tokens"></a>

ほとんどの AWS リージョン はデフォルトですべての AWS のサービス のオペレーションに有効になっています。これらのリージョンは、AWS STS で使用できるように自動的にアクティブ化されます。アジアパシフィック (香港) など一部のリージョンは、手動で有効にする必要があります。AWS リージョン を有効および無効にする方法については、「AWS アカウント管理 リファレンスガイド」の「[アカウントで使用できる AWS リージョン の指定](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)」を参照してください。これらの AWS リージョンを有効にすると、AWS STS で使用できるように、自動的にアクティブ化されます。無効になっているリージョンの AWS STS エンドポイントをアクティブ化することはできません。すべての AWS リージョン で有効なセッショントークンには、デフォルトで有効になっているリージョンで有効なトークンを超える文字が含まれています。この設定を変更すると、一時的にトークンを保存する既存のシステムに影響する可能性があります。

この設定は、AWS マネジメントコンソール、AWS CLI、または AWS API を使用して変更できます。

**グローバルエンドポイント (コンソール) に対するセッショントークンの リージョンの互換性を変更するには**

1. IAM 管理タスクを実行するアクセス許可があるルートユーザーまたはユーザーとしてサインインします。セッショントークンの互換性を変更するには、`iam:SetSecurityTokenServicePreferences` アクションを許可するポリシーがある必要があります。

1. [[IAM コンソール]](https://console.aws.amazon.com/iam/home?#home) を開きます。ナビゲーションペインで **[アカウント設定]** を選択します。

1. **[Security Token Service (STS)]** セクションの **[Session Tokens from the STS endpoints]** (STS エンドポイントからのセッショントークン)。**[Global endpoint]** (グローバルエンドポイント) は `Valid only in AWS リージョン enabled by default` を示します。[**Change**] を選択します。

1. **[Change region compatibility]** (リージョンの互換性を変更) ダイアログボックスで、**[All AWS リージョン]** を選択します。次に、**変更の保存**を選択します。
**注記**  
すべての AWS リージョン で有効なセッショントークンには、デフォルトで有効になっているリージョンで有効なトークンを超える文字が含まれています。この設定を変更すると、一時的にトークンを保存する既存のシステムに影響する可能性があります。

**グローバルエンドポイント (AWS CLI) に対するセッショントークンの リージョンの互換性を変更するには**  
セッショントークンのバージョンを設定します。バージョン 1 トークンは、デフォルトで利用できる AWS リージョン でのみ有効です。これらのトークンは、アジアパシフィック (香港) など、手動で有効になっているリージョンでは動作しません。バージョン 2 のトークンはすべてのリージョンで有効です。ただし、バージョン 2 トークンにはさらに多くの文字が含まれており、一時的にトークンを保存するシステムに影響する可能性があります。
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html)

**グローバルエンドポイント (AWS API) に対するセッショントークンの リージョンの互換性を変更するには**  
セッショントークンのバージョンを設定します。バージョン 1 トークンは、デフォルトで利用できる AWS リージョン でのみ有効です。これらのトークンは、アジアパシフィック (香港) など、手動で有効になっているリージョンでは動作しません。バージョン 2 のトークンはすべてのリージョンで有効です。ただし、バージョン 2 トークンにはさらに多くの文字が含まれており、一時的にトークンを保存するシステムに影響する可能性があります。
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html) 

# AWS STS のリージョンとエンドポイント
<a name="id_credentials_temp_region-endpoints"></a>

**注記**  
回復性とパフォーマンスを向上させるために、AWS は、[デフォルトで有効](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)になっているリージョンの AWS Security Token Service (AWS STS) グローバルエンドポイント (`https://sts.amazonaws.com`) を変更しました。グローバルエンドポイントへの AWS STS リクエストは、ワークロードと同じ AWS リージョン で自動的に処理されます。これらの変更はオプトインリージョンにはデプロイされません。適切な AWS STS リージョンエンドポイントを使用することをお勧めします。詳細については、「[AWS STS グローバルエンドポイントの変更](#reference_sts_global_endpoint_changes)」を参照してください。

次の表に、リージョンとそのエンドポイントを一覧表示します。ここには、デフォルトでアクティブ化されるものや、ユーザーがアクティブ化または非アクティブ化できるものが示されています。

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html)

¹リージョンで使用するには、[リージョンを有効にする](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)必要があります。これにより、AWS STS が自動的にアクティブになります。これらのリージョンで AWS STS を手動でアクティブ化または非アクティブ化することはできません。

²中国で AWS を使用するには、中国内の AWS に特化されたアカウントと認証情報が必要です。

## AWS STS グローバルエンドポイントの変更
<a name="reference_sts_global_endpoint_changes"></a>

耐障害性およびパフォーマンスを強化するために、AWS は、[デフォルトで有効](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)になっているリージョンの AWS Security Token Service (AWS STS) グローバルエンドポイント (`https://sts.amazonaws.com`) を変更しました。以前、AWS STS グローバルエンドポイントへのすべてのリクエストは、単一の AWS リージョン である米国東部 (バージニア北部) によって処理されていました。[デフォルトで有効化された](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)リージョンでは、AWS STS グローバルエンドポイントへのリクエストは、米国東部 (バージニア北部) リージョンではなく、リクエスト元のリージョンで自動的に処理されます。これらの変更はオプトインリージョンにはデプロイされません。

この変更により、AWS STS は、リクエスト元のリージョンと使用された DNS リゾルバーに基づいてリクエストを処理します。AWS STS グローバルエンドポイントへのリクエストは、AWS STS グローバルエンドポイントの DNS リクエストがデフォルトで有効になっているリージョンの Amazon DNS サーバーによって処理される場合、AWS デプロイされたワークロードと同じリージョンで処理されます。リクエストがオプトインリージョンから行われた場合、またはリクエストが Amazon DNS サーバー以外の DNS リゾルバーを使用して解決された場合、AWS STS グローバルエンドポイントへのリクエストは米国東部 (バージニア北部) リージョンで引き続き処理されます。詳細については、「*Amazon Virtual Private Cloud ユーザーガイド*」の「[Amazon DNS サーバー](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS)」を参照してください。

次の表は、DNS プロバイダーに基づいて AWS STS グローバルエンドポイントへのリクエストをルーティングする方法を示します。


| DNS リゾルバー | AWS STS グローバルエンドポイントへのリクエストはローカル AWS リージョン にルーティングされますか? | 
| --- | --- | 
|  デフォルトで有効になっているリージョンの Amazon VPC の Amazon DNS リゾルバー  |  はい  | 
|  オプトインリージョンの Amazon VPC の Amazon DNS リゾルバー  |  いいえ、リクエストは米国東部 (バージニア北部) リージョンにルーティングされます  | 
|  ISP、パブリック DNS プロバイダー、その他の DNS プロバイダーによって提供される DNS リゾルバー  |  いいえ、リクエストは米国東部 (バージニア北部) リージョンにルーティングされます  | 

既存のプロセスの中断を最小限に抑えるため、AWS で次の対策が実施しました。
+ AWS STS グローバルエンドポイントに対して行われたリクエストの AWS CloudTrail ログは、米国東部 (バージニア北部) リージョンに送信されます。AWS STS リージョンエンドポイントによって処理されたリクエストの CloudTrail ログは、CloudTrail のそれぞれのリージョンに引き続きログ記録されます。
+ AWS STS グローバルエンドポイントおよびリージョンエンドポイントによって実行されるオペレーションの CloudTrail ログには、リクエストを処理したエンドポイントおよびリージョンを示す追加フィールド `endpointType` および `awsServingRegion` が含まれます。CloudTrail ログの例については、「[CloudTrail ログファイルのグローバルエンドポイントを使用した AWS STS API イベントの例](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint)」を参照してください。
+ リクエストを処理するリージョンとは関係なく、AWS STS グローバルエンドポイントに対して行われるリクエストでは `aws:RequestedRegion` 条件キーに `us-east-1` の値が含まれます。
+ AWS STS グローバルエンドポイントによって処理されたリクエストでは、リージョンの AWS STS エンドポイントと 1 秒あたりのリクエストクォータが共有されません。

オプトインリージョンでワークロードがあり、AWS STS グローバルエンドポイントをまだ使用している場合、耐障害性およびパフォーマンスを強化するために AWS STS リージョンのエンドポイントに移行することをお勧めします。リージョン AWS STS エンドポイントの設定の詳細については、「*AWS SDK およびツールリファレンスガイド*」の「[AWS STS リージョンエンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)」を参照してください。

## AWS CloudTrail とリージョンのエンドポイント
<a name="sts-regions-cloudtrail"></a>

リージョンのエンドポイントとグローバルエンドポイントへの呼び出しは、AWS CloudTrail の [`tlsDetails`] フィールドに記録されます。`us-east-2.amazonaws.com` などのリージョンのエンドポイントへの呼び出しは、CloudTrail で適切なリージョンに記録されます。グローバルエンドポイント `sts.amazonaws.com` への呼び出しは、グローバルサービスへの呼び出しとして記録されます。グローバル AWS STS エンドポイントのイベントは us-east-1 に記録されます。

**注記**  
 `tlsDetails` は、このフィールドをサポートするサービスに対してのみ表示できます。AWS CloudTrail ユーザーガイドの「[CloudTrail で TLS の詳細をサポートするサービス](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html)」を参照してください。  
詳細については、「[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)」を参照してください。

# AWS コンソールへのカスタム ID ブローカーアクセスを有効にする
<a name="id_roles_providers_enable-console-custom-url"></a>

組織のネットワークにサインインするユーザーに対して AWS マネジメントコンソール への安全なアクセスを許可するには、そのための URL を生成するコードを記述して実行できます。この URL は、AWS から取得したサインイントークンを含み、それを使って AWS に対してユーザーを認証します。結果のコンソールセッションには、フェデレーションに起因する明確な `AccessKeyId` が含まれる場合があります。関連する CloudTrail イベントを介したフェデレーションサインインのアクセスキーの使用状況を追跡するには、「[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)」と「AWS マネジメントコンソール サインインイベント」を参照してください。

**注記**  
組織で、SAML と互換性のある ID プロバイダー (IdP) を使用している場合は、コードを記述せずにコンソールにアクセスできます。これは、Microsoft の Active Directory フェデレーションサービスやオープンソースの Shibboleth などのプロバイダーで機能します。詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。

組織のユーザーによる AWS マネジメントコンソール へのアクセスを許可するには、以下の手順を実行するカスタム *ID ブローカー*を作成できます。

1. ユーザーがローカル ID システムによって認証されていることを確認する。

1. AWS Security Token Service (AWS STS) の [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) (推奨) または [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API オペレーションを呼び出して、ユーザーの一時的セキュリティ認証情報を取得する。ロールを引き受ける別の方法については、「[ロールを引き受けるための各種方法](id_roles_manage-assume.md)」を参照してください。セキュリティ認証情報を取得するときにオプションのセッションタグを渡す方法については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
   + `AssumeRole*` API オペレーションのいずれかを使用してロールの一時的なセキュリティ認証情報を取得した場合、この呼び出しに `DurationSeconds` パラメータを含めることができます。このパラメータは、ロールセッションの期間を 900 秒 (15 分) からそのロールの最大セッション期間設定まで指定します。`AssumeRole*` オペレーションで `DurationSeconds` を使用する場合、長期的な認証情報を持つ IAM ユーザーとして呼び出す必要があります。それ以外の場合は、ステップ 3 のフェデレーションエンドポイントへの呼び出しが失敗します。ロールの最大値を確認または変更する方法については、「[ロールの最大セッション期間を更新する](id_roles_update-role-settings.md#id_roles_update-session-duration)」を参照してください。
   + `GetFederationToken` API オペレーションを使用して認証情報を取得するには、呼び出しに `DurationSeconds` パラメータを含めることができます。このパラメータは、ロールセッションの継続期間を指定します。値の範囲は 900 秒 (15 分) から 129,600 秒 (36 時間) です。この API コールは、IAM ユーザーの AWS 長期的セキュリティ認証情報を使用することでのみ行うことができます。AWS アカウントのルートユーザー 認証情報を使用してこれらの呼び出しを行うこともできますが、推奨されません。ルートユーザーとしてこの呼び出しを行うと、デフォルトのセッションの継続期間は 1 時間です。900 秒 (15 分) から最長 3,600 秒 (1 時間) までセッションを指定できます。

1. AWS フェデレーションエンドポイントを呼び出し、一時的なセキュリティ認証情報を指定して、サインイントークンをリクエストする。

1. トークンを含むコンソールの URL を生成する:
   + URL で `AssumeRole*` API オペレーションのいずれかを使用する場合、`SessionDuration` HTTP パラメータを含めることができます。このパラメータはコンソールセッションの継続期間を 900 秒 (15 分) から 43200 秒 (12 時間) までの間で指定します。
   + URL で `GetFederationToken` API オペレーションを使用する場合、`DurationSeconds` パラメータを含めることができます。このパラメータは、フェデレーテッドコンソールセッションの継続期間を指定します。値の範囲は 900 秒 (15 分) から 129,600 秒 (36 時間) です。
**注記**  
`SessionDuration` は、引き受けるロールの最大セッション期間より短く設定する必要があります。例えば、引き受けるロールの最大セッション時間を 5 時間に設定するとします。`SessionDuration` パラメータは 16524 秒、または 4 時間 59 秒にすることができます。
`GetFederationToken` を使用して一時的な認証情報を取得した場合は、`SessionDuration` HTTP パラメータを使用しないでください。このオペレーションは失敗します。
1 つのロールの認証情報を使用して別のロールを引き受けることは、[*ロールの連鎖*](id_roles.md#iam-term-role-chaining)と呼ばれます。ロールの連鎖を使用すると、新しい認証情報は最長期間である 1 時間に制限されます。ロールを使用して [EC2 インスタンスで実行されるアプリケーションにアクセス許可を付与する](id_roles_use_switch-role-ec2.md)場合、これらのアプリケーションにはこの制限が適用されません。
ロールの連鎖を通じて一時的な認証情報を取得するときは、`SessionDuration` HTTP パラメータを使用しないでください。このオペレーションは失敗します。

1. URL をユーザーに渡すか、ユーザーに代わって URL を呼び出す。

フェデレーションエンドポイントによって渡される URL はその作成後から 15 分間、有効です。これは、URL に関連付けられた一時的セキュリティ認証情報の期間 (秒) とは異なります。これらの認証情報は、認証情報の作成時から、作成時に指定した期間だけ有効です。

**重要**  
URL は、関連付けられた一時的セキュリティ認証情報でアクセス許可を有効にした場合、AWS マネジメントコンソール を介した AWS リソースへのアクセスを許可することを忘れないでください。そのため、この URL は機密情報として扱う必要があります。例えば、SSL 接続による 302 HTTP レスポンスステータスコードを使用して、安全なリダイレクトによって URL を返すことをお勧めします。302 HTTP レスポンスステータスコードの詳細については、「[​RFC 2616 セクション 10.3.3](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3)」を参照してください。

これらのタスクを完了するために、[AWS Identity and Access Management (IAM) と [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/) のHTTPS クエリ API ](https://docs.aws.amazon.com/IAM/latest/APIReference/)を使用できます。または、Java、Ruby、C\$1 などのプログラミング言語を該当する [AWS SDK](https://aws.amazon.com/tools/) と共に使用できます。これらの方法のそれぞれについて、以下のトピックで説明します。

**Topics**
+ [

## IAM クエリ API オペレーションを使用したコード例
](#STSConsoleLink_manual)
+ [

## Python を使用したコード例
](#STSConsoleLink_programPython)
+ [

## Java を使用したコード例
](#STSConsoleLink_programJava)
+ [

## URL の作成方法を示す例 (Ruby)
](#STSConsoleLink_programRuby)

## IAM クエリ API オペレーションを使用したコード例
<a name="STSConsoleLink_manual"></a>

ロールやフェデレーティッドプリンシパルに対して AWS マネジメントコンソール への直接アクセスを許可する URL を作成できます。このタスクでは、IAM と AWS STS の HTTPS クエリ API を使用します。クエリリクエストの詳細については、「[クエリリクエストを行う](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html)」を参照してください。

**注記**  
以下の手順は、テキスト文字列の例を含んでいます。読みやすくするために、長い例の一部では改行が追加されています。これらの文字列をご自分で使用するときは、改行をすべて削除してください。

**ロールやフェデレーティッドプリンシパルに対して AWS マネジメントコンソール のリソースへのアクセスを許可する方法**

1. ID および認可システムでユーザーを認証します。

1. ユーザーの一時的なセキュリティ認証情報を取得します。一時的な認証情報は、アクセスキー ID、シークレットアクセスキー、およびセッショントークンで構成されています。一時的な認証情報の作成方法の詳細については、「[IAM の一時的な認証情報](id_credentials_temp.md)」を参照してください。

   一時的な認証情報を取得するには、AWS STS の [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API (推奨) または [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API を呼び出します。これらの API オペレーションの違いの詳細については、AWS セキュリティブログの「[AWS アカウントへのアクセスを安全に委任する API オプションの理解](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account)」を参照してください。
**重要**  
[GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API を使用して一時的セキュリティ認証情報を作成する場合、ロールを引き受けるユーザーに認証情報を提供するアクセス許可を指定する必要があります。`AssumeRole*` で始まるいずれの API オペレーションでも、IAM ロールを使用してアクセス許可を割り当てます。その他の API オペレーションでは、この方法は API によって異なります。詳細については、[一時的なセキュリティ認証情報のアクセス許可](id_credentials_temp_control-access.md)を参照してください。さらに、`AssumeRole*` API オペレーションを使用する場合、長期的な認証情報を使用する IAM ユーザーとして呼び出す必要があります。それ以外の場合は、ステップ 3 のフェデレーションエンドポイントへの呼び出しが失敗します。  


1. 一時的なセキュリティ認証情報を取得した後、この情報から JSON セッション文字列を生成して、サインイントークンに置き換えられるようにします。以下の例は、認証情報のエンコード方法を示しています。プレースホルダーテキストを、先ほどの手順で取得した認証情報の該当する値に置き換えます。

   ```
   {"sessionId":"*** temporary access key ID ***",
   "sessionKey":"*** temporary secret access key ***",
   "sessionToken":"*** session token ***"}
   ```

1. 前の手順からのセッション文字列を [URL エンコード](https://en.wikipedia.org/wiki/Percent-encoding)します。エンコードする情報は機密であるため、このエンコードにウェブサービスを利用しないことをお勧めします。代わりに、開発ツールキットのローカルにインストールされた関数または機能を使用して、この情報を安全にエンコードします。Python では `urllib.quote_plus` 関数、Java では `URLEncoder.encode` 関数、Ruby では `CGI.escape` 関数を使用できます。このトピックの後の例を参照してください。

1. <a name="STSConsoleLink_manual_step5"></a>
**注記**  
ここで AWS は POST リクエストをサポートします。

   AWS フェデレーションエンドポイントにリクエストを送信します。

   `https://region-code.signin.aws.amazon.com/federation` 

   実行可能な *region-code* 値のリストについては、「[AWS サインインエンドポイント](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)」の **[リージョン]** 列を参照します。任意で、以下のデフォルトの AWS サインイン フェデレーション エンドポイントが使用できます。

   `https://signin.aws.amazon.com/federation` 

   以下の例のように、リクエストには、`Action` および `Session` パラメータを含める必要があります。[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーションを (オプションで) 使用する場合は、`SessionDuration` HTTP パラメータを含める必要があります。

   ```
   Action = getSigninToken
   SessionDuration = time in seconds
   Session = *** the URL encoded JSON string created in steps 3 & 4 ***
   ```
**注記**  
このステップで以下の手順は、GET リクエストを使用する場合にのみ機能します。

   `SessionDuration` HTTP パラメータは、コンソールセッションの継続期間を指定します。これは、`DurationSeconds` パラメータを使用して指定する一時的な認証情報の期間とは異なります。`SessionDuration` の最大値を 43200 (12 時間) に指定できます。`SessionDuration` パラメータがない場合は、セッションはステップ 2 で AWS STS から取得した認証情報の期間 (デフォルトは 1 時間) をデフォルトに設定します。`DurationSeconds` パラメータを使用した期間の指定方法の詳細については、[`AssumeRole` API のドキュメント](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)を参照してください。1 時間より長いコンソールセッションを作成する機能は、フェデレーションエンドポイントの `getSigninToken` オペレーションに組み込まれます。
**注記**  
`SessionDuration` は、引き受けるロールの最大セッション期間より短く設定する必要があります。例えば、引き受けるロールの最大セッション時間を 5 時間に設定するとします。`SessionDuration` パラメータは 16524 秒、または 4 時間 59 秒にすることができます。
`GetFederationToken` を使用して一時的な認証情報を取得した場合は、`SessionDuration` HTTP パラメータを使用しないでください。このオペレーションは失敗します。
1 つのロールの認証情報を使用して別のロールを引き受けることは、[*ロールの連鎖*](id_roles.md#iam-term-role-chaining)と呼ばれます。ロールの連鎖を使用すると、新しい認証情報は最長期間である 1 時間に制限されます。ロールを使用して [EC2 インスタンスで実行されるアプリケーションにアクセス許可を付与する](id_roles_use_switch-role-ec2.md)場合、これらのアプリケーションにはこの制限が適用されません。
ロールの連鎖を通じて一時的な認証情報を取得するときは、`SessionDuration` HTTP パラメータを使用しないでください。このオペレーションは失敗します。

   長時間にわたってコンソールセッションを有効にすると、認証情報が漏洩するリスクが高くなります。このリスクを軽減するには、IAM コンソールページの **[ロールの概要]** で、**[セッションの無効化]** を選択して、どのロールのアクティブなコンソールセッションもすぐに無効にできます。詳細については、「[IAM ロールの一時的なセキュリティ認証情報を取り消す](id_roles_use_revoke-sessions.md)」を参照してください。

    以下に示しているのは、リクエストの具体的な例です。ここでは読みやすいように改行していますが、リクエストは 1 行の文字列として送信する必要があります。

   ```
   https://signin.aws.amazon.com/federation
   ?Action=getSigninToken
   &SessionDuration=1800
   &Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22
   %3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2
   2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW
   AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8
   FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5
   PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C
   UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D
   ```

   フェデレーションエンドポイントからの応答は、`SigninToken` 値を含む JSON ドキュメントです。実際には次のようになります。

   ```
   {"SigninToken":"*** the SigninToken string ***"}
   ```

1. 
**注記**  
ここで AWS は POST リクエストをサポートします。

   最後に、ユーザーが AWS マネジメントコンソール にアクセスするために使用できる URL を作成します。URL は、「[Step 5](#STSConsoleLink_manual_step5)」で使用した同じフェデレーション URL エンドポイントに以下のパラメータを追加したものです。

   ```
   ?Action = login
   &Issuer = *** the form-urlencoded URL for your internal sign-in page ***
   &Destination = *** the form-urlencoded URL to the desired AWS console page ***
   &SigninToken = *** the value of SigninToken received in the previous step ***
   ```
**注記**  
このステップの以下の手順は、GET API を使用する場合にのみ機能します。

   以下の例は、最終的な URL がどのようになるかを示します。URL は、作成時から 15 分間、有効です。URL 内に組み込まれた一時的なセキュリティ認証情報とコンソールセッションは、認証情報の初回リクエスト時に `SessionDuration` HTTP パラメータで指定した期間、有効です。

   ```
   https://signin.aws.amazon.com/federation
   ?Action=login
   &Issuer=https%3A%2F%2Fexample.com
   &Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F
   &SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC
   CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1
   WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm
   iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u
   3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv
   9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf
   nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg
   Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ
   nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm
   0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC
   RNhujg
   ```

## Python を使用したコード例
<a name="STSConsoleLink_programPython"></a>

次の例では、Python を使用してユーザーに AWS マネジメントコンソール への直接アクセスを許可する URL をプログラムで作成する方法が示されます。ここでは、以下の 2 つの例を示します。
+ GET リクエスト経由で AWS にフェデレートします
+ POST リクエスト経由で AWS にフェデレートします

どちらの例でも、[AWS SDK for Python (Boto3)](https://aws.amazon.com/tools/) や [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API を使用して、一時的なセキュリティ認証情報を取得します。

`AssumeRoleSession` 認証情報がロールの連鎖からのものである場合は、`SessionDuration` を含めないでください。`SessionDuration` を含めると、オペレーションは失敗します。

### GET リクエストの使用
<a name="post-api-py-example"></a>

```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'

# Step 1: Authenticate user in your own identity system.

# Step 2: Using the access keys for an IAM user in your AWS アカウント,
# call "AssumeRole" to get temporary access keys for the role or federated principal

# Note: Calls to AWS STS AssumeRole must be signed using the access key ID 
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables, 
# or in a configuration file, and will be discovered automatically by the 
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
sts_connection = boto3.client('sts')

assumed_role_object = sts_connection.assume_role(
    RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
    RoleSessionName="AssumeRoleSession",
)

# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)

# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials 
# as parameters.
request_parameters = "?Action=getSigninToken"
request_parameters += "&SessionDuration=43200"
if sys.version_info[0] < 3:
    def quote_plus_function(s):
        return urllib.quote_plus(s)
else:
    def quote_plus_function(s):
        return urllib.parse.quote_plus(s)
request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials)
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
r = requests.get(request_url)
# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)

# Step 5: Create URL where users can use the sign-in token to sign in to 
# the console. This URL must be used within 15 minutes after the
# sign-in token was issued.
request_parameters = "?Action=login" 
request_parameters += "&Issuer=Example.org" 
request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/")
request_parameters += "&SigninToken=" + signin_token["SigninToken"]
request_url = "https://signin.aws.amazon.com/federation" + request_parameters

# Send final URL to stdout
print (request_url)
```

### POST リクエストの使用
<a name="get-api-py-example-1"></a>

```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'
import os
from selenium import webdriver # 'pip install selenium', 'brew install chromedriver'

# Step 1: Authenticate user in your own identity system.

# Step 2: Using the access keys for an IAM user in your AAWS アカウント,
# call "AssumeRole" to get temporary access keys for the role or federated principal

# Note: Calls to AWS STS AssumeRole must be signed using the access key ID 
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables, 

# or in a configuration file, and will be discovered automatically by the 
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
if sys.version_info[0] < 3:
    def quote_plus_function(s):
        return urllib.quote_plus(s)
else:
    def quote_plus_function(s):
        return urllib.parse.quote_plus(s)

sts_connection = boto3.client('sts')

assumed_role_object = sts_connection.assume_role(
    RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
    RoleSessionName="AssumeRoleDemoSession",
)

# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)

# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials 
# as parameters.
request_parameters = {}
request_parameters['Action'] = 'getSigninToken'
request_parameters['SessionDuration'] = '43200'
request_parameters['Session'] = json_string_with_temp_credentials

request_url = "https://signin.aws.amazon.com/federation"
r = requests.post( request_url, data=request_parameters)

# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)

# Step 5: Create a POST request where users can use the sign-in token to sign in to 
# the console. The POST request must be made within 15 minutes after the
# sign-in token was issued.
request_parameters = {}
request_parameters['Action'] = 'login'
request_parameters['Issuer']='Example.org'
request_parameters['Destination'] = 'https://console.aws.amazon.com/'
request_parameters['SigninToken'] =signin_token['SigninToken']

jsrequest = '''
var form = document.createElement('form');
form.method = 'POST';
form.action = '{request_url}';
request_parameters = {request_parameters}
for (var param in request_parameters) {{
    if (request_parameters.hasOwnProperty(param)) {{
        const hiddenField = document.createElement('input');
        hiddenField.type = 'hidden';
        hiddenField.name = param;
        hiddenField.value = request_parameters[param];
        form.appendChild(hiddenField);
    }}
}}
document.body.appendChild(form);
form.submit();
'''.format(request_url=request_url, request_parameters=request_parameters)

driver = webdriver.Chrome()
driver.execute_script(jsrequest)
input("Press Enter to close the browser window...")
```

## Java を使用したコード例
<a name="STSConsoleLink_programJava"></a>

次の例では、Java を使用してユーザーに AWS マネジメントコンソール への直接アクセスを許可する URL をプログラムで作成する方法が示されます。以下のコード例では、[AWS SDK for Java](https://aws.amazon.com/documentation/sdkforjava/) を使用しています。

```
import java.net.URLEncoder;
import java.net.URL;
import java.net.URLConnection;
import java.io.BufferedReader;
import java.io.InputStreamReader;
// Available at http://www.json.org/java/index.html
import org.json.JSONObject;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient;
import com.amazonaws.services.securitytoken.model.Credentials;
import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest;
import com.amazonaws.services.securitytoken.model.GetFederationTokenResult;


/* Calls to AWS STS API operations must be signed using the access key ID 
   and secret access key of an IAM user or using existing temporary 
   credentials. The credentials should not be embedded in code. For 
   this example, the code looks for the credentials in a 
   standard configuration file.
*/
AWSCredentials credentials = 
  new PropertiesCredentials(
         AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties"));

AWSSecurityTokenServiceClient stsClient = 
  new AWSSecurityTokenServiceClient(credentials);

GetFederationTokenRequest getFederationTokenRequest = 
  new GetFederationTokenRequest();
getFederationTokenRequest.setDurationSeconds(1800);
getFederationTokenRequest.setName("UserName");

// A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console.

String policy = "{\"Version\":\"2012-10-17\",		 	 	 \"Statement\":[{\"Action\":\"sns:*\"," +
  "\"Effect\":\"Allow\",\"Resource\":\"*\"}]}";

getFederationTokenRequest.setPolicy(policy);

GetFederationTokenResult federationTokenResult = 
  stsClient.getFederationToken(getFederationTokenRequest);

Credentials federatedCredentials = federationTokenResult.getCredentials();

// The issuer parameter specifies your internal sign-in
// page, for example https://mysignin.internal.mycompany.com/.
// The console parameter specifies the URL to the destination console of the
// AWS Management Console. This example goes to Amazon SNS. 
// The signin parameter is the URL to send the request to.

String issuerURL = "https://mysignin.internal.mycompany.com/";
String consoleURL = "https://console.aws.amazon.com/sns";
String signInURL = "https://signin.aws.amazon.com/federation";
  
// Create the sign-in token using temporary credentials,
// including the access key ID,  secret access key, and session token.
String sessionJson = String.format(
  "{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}",
  "sessionId", federatedCredentials.getAccessKeyId(),
  "sessionKey", federatedCredentials.getSecretAccessKey(),
  "sessionToken", federatedCredentials.getSessionToken());
              
// Construct the sign-in request with the request sign-in token action, a
// 12-hour console session duration, and the JSON document with temporary 
// credentials as parameters.

String getSigninTokenURL = signInURL + 
                           "?Action=getSigninToken" +
                           "&DurationSeconds=43200" + 
                           "&SessionType=json&Session=" + 
                           URLEncoder.encode(sessionJson,"UTF-8");

URL url = new URL(getSigninTokenURL);

// Send the request to the AWS federation endpoint to get the sign-in token
URLConnection conn = url.openConnection ();

BufferedReader bufferReader = new BufferedReader(new 
  InputStreamReader(conn.getInputStream()));  
String returnContent = bufferReader.readLine();

String signinToken = new JSONObject(returnContent).getString("SigninToken");

String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8");

// The issuer parameter is optional, but recommended. Use it to direct users
// to your sign-in page when their session expires.

String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8");

// Finally, present the completed URL for the AWS console session to the user

String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8");
String loginURL = signInURL + "?Action=login" +
                     signinTokenParameter + issuerParameter + destinationParameter;
```

## URL の作成方法を示す例 (Ruby)
<a name="STSConsoleLink_programRuby"></a>

次の例では、Ruby を使用してユーザーに AWS マネジメントコンソール への直接アクセスを許可する URL をプログラムで作成する方法が示されます。このコード例では、[AWS SDK for Ruby](https://aws.amazon.com/documentation/sdkforruby/) を使用しています。

```
require 'rubygems'
require 'json'
require 'open-uri'
require 'cgi'
require 'aws-sdk'

# Create a new STS instance
# 
# Note: Calls to AWS STS API operations must be signed using an access key ID 
# and secret access key. The credentials can be in EC2 instance metadata 
# or in environment variables and will be automatically discovered by
# the default credentials provider in the AWS Ruby SDK. 
sts = Aws::STS::Client.new()

# The following call creates a temporary session that returns 
# temporary security credentials and a session token.
# The policy grants permissions to work
# in the AWS SNS console.

session = sts.get_federation_token({
  duration_seconds: 1800,
  name: "UserName",
  policy: "{\"Version\":\"2012-10-17\",		 	 	 \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}",
})

# The issuer value is the URL where users are directed (such as
# to your internal sign-in page) when their session expires.
#
# The console value specifies the URL to the destination console.
# This example goes to the Amazon SNS console.
#
# The sign-in value is the URL of the AWS STS federation endpoint.
issuer_url = "https://mysignin.internal.mycompany.com/"
console_url = "https://console.aws.amazon.com/sns"
signin_url = "https://signin.aws.amazon.com/federation"

# Create a block of JSON that contains the temporary credentials
# (including the access key ID, secret access key, and session token).
session_json = {
  :sessionId => session.credentials[:access_key_id],
  :sessionKey => session.credentials[:secret_access_key],
  :sessionToken => session.credentials[:session_token]
}.to_json

# Call the federation endpoint, passing the parameters
# created earlier and the session information as a JSON block. 
# The request returns a sign-in token that's valid for 15 minutes.
# Signing in to the console with the token creates a session 
# that is valid for 12 hours.
get_signin_token_url = signin_url + 
                       "?Action=getSigninToken" + 
                       "&SessionType=json&Session=" + 
                       CGI.escape(session_json)

returned_content = URI.parse(get_signin_token_url).read

# Extract the sign-in token from the information returned
# by the federation endpoint.
signin_token = JSON.parse(returned_content)['SigninToken']
signin_token_param = "&SigninToken=" + CGI.escape(signin_token)

# Create the URL to give to the user, which includes the
# sign-in token and the URL of the console to open.
# The "issuer" parameter is optional but recommended.
issuer_param = "&Issuer=" + CGI.escape(issuer_url)
destination_param = "&Destination=" + CGI.escape(console_url)
login_url = signin_url + "?Action=login" + signin_token_param + 
  issuer_param + destination_param
```

# AWS Identity and Access Management リソースのタグ
<a name="id_tags"></a>

*タグ*は、ユーザーが AWS リソースに割り当てることのできるカスタム属性ラベルです。各 タグは 2 つの部分で構成されます:
+ タグキー** (`CostCenter`、`Environment`、`Project`、`Purpose` など)。
+ タグ値**と呼ばれるオプションのフィールド (`111122223333`、`Production`、チーム名など)。タグ値を省略すると、空の文字列を使用した場合と同じになります。

これらは共にキーバリューペアと呼ばれます。IAM リソースで使用できるタグの数の制限については、「[IAM と AWS STSクォータ](reference_iam-quotas.md)」を参照してください。

**注記**  
タグキーとタグキー値での大文字と小文字の区別の詳細については、「[Case sensitivity](#case-sensitivity)」を参照してください。

タグは、AWS リソースの識別や整理に役立ちます。多くの AWS のサービスではタグ付けがサポートされるため、さまざまなサービスからリソースに同じタグを割り当てて、リソースの関連を示すことができます。例えば、Amazon S3 バケットに割り当てたタグと同じタグを IAM ロールに割り当てることができます。タグ付け戦略の詳細については、ユーザーガイドの「[AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。

IAM リソースの特定、整理、追跡に加え、IAM ポリシーのタグを使って、リソースを表示および操作できるユーザーを制御することもできます。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

AWS STS のタグを使用して、ロールを引き受けるとき、またはユーザーをフェデレートするときにカスタム属性を追加することもできます。詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

**Topics**
+ [

## AWS タグ命名規則を選択する
](#id_tags_naming)
+ [

## IAM および AWS STS でのタグ付けの規則
](#id_tags_rules)
+ [

# IAM ユーザーにタグ付けする
](id_tags_users.md)
+ [

# IAM ロールにタグ付けする
](id_tags_roles.md)
+ [

# カスタマー管理ポリシーにタグ付けする
](id_tags_customer-managed-policies.md)
+ [

# OpenID Connect (OIDC) ID プロバイダーにタグ付けする
](id_tags_oidc.md)
+ [

# IAM SAML ID プロバイダーにタグ付けする
](id_tags_saml.md)
+ [

# Amazon EC2 ロール用のインスタンスプロファイルにタグ付けする
](id_tags_instance-profiles.md)
+ [

# タグ サーバー証明書
](id_tags_server-certificates.md)
+ [

# MFA デバイスにタグ付けする
](id_tags_virtual-mfa.md)
+ [

# AWS STS でセッションタグを渡します
](id_session-tags.md)

## AWS タグ命名規則を選択する
<a name="id_tags_naming"></a>

IAM リソースにタグをアタッチする際は、タグの命名規則を慎重に選択します。すべての AWS タグに同じ規則を適用します。ポリシーでタグを使用して AWS リソースへのアクセスを制御する場合、これは特に重要です。AWS のタグをすでに使用している場合は、命名規則を確認し、必要に応じて調整します。

**注記**  
アカウントが AWS Organizations のメンバーである場合、「AWS Organizations ユーザーガイド」の「[タグポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)」を参照し、AWS Organizations でタグを使用する方法についてご確認ください。

### タグの命名に関するベストプラクティス
<a name="id_tags_naming_best_practices"></a>

ここでは、タグの命名規則に関するベストプラクティスについて説明します。

タグ名は一貫性を保って使用してください。たとえば、タグ `CostCenter` とタグ `costcenter` は別のものです。一方は財務分析とレポート用のコスト配分タグとして設定され、もう一方はそうではないかもしれません。同様に、`Name` タグは多くのリソース用の AWS コンソールで目にしますが、`name` タグはそうではありません。タグキーとタグキー値での大文字と小文字の区別の詳細については、「[Case sensitivity](#case-sensitivity)」を参照してください。

いくつかのタグは AWS により事前に定義されています。また、さまざまな AWS のサービスによって自動的に作成されます。多くの場合、AWS で定義されるタグの名前はすべて小文字で、名前に含まれる単語はハイフンで区切られ、タグのソースサービスを識別するプレフィックスが付きます。例: 
+ `aws:ec2spot:fleet-request-id` のタグは、インスタンスを起動した Amazon EC2 スポットインスタンスリクエストを識別します。
+ `aws:cloudformation:stack-name` のタグは、リソースを作成した CloudFormation スタックを識別します。
+ `elasticbeanstalk:environment-name` のタグは、リソースを作成したアプリケーションを識別します。

タグの名前を付ける際は、すべて小文字を使用し、単語はハイフンで区切り、組織名や略称を識別するプレフィックスを付けることを検討してください。例えば、AnyCompany という名前の架空の会社の場合では、次のようにタグを定義できます。
+ `anycompany:cost-center` のタグは、内部のコストセンターのコードを識別するのに使用 
+ `anycompany:environment-type` のタグは、開発、テスト、本番のいずれの環境であるかを識別するのに使用
+ `anycompany:application-id` のタグは、リソースが作成されたアプリケーションを識別するのに使用 

プレフィックスを付けることで、自分の組織が定義したタグだということが明確に識別でき、AWS または使用中のサードパーティーのツールにより定義されたタグではないことがわかります。すべて小文字を使用し、単語をハイフンで区切ることにより、タグ名に大文字を使用した場合の混乱を避けることができます。例えば、`anycompany:project-id` の方が、`ANYCOMPANY:ProjectID`、`anycompany:projectID`、`Anycompany:ProjectId` よりも覚えるのが簡単です。

## IAM および AWS STS でのタグ付けの規則
<a name="id_tags_rules"></a>

IAM および AWS STS でのタグの作成と適用を管理する多数の規則。

### 命名タグ
<a name="id_tags_rules_creating"></a>

IAM リソース、AWS STS assume-role セッション、AWS STS フェデレーションユーザーセッションのタグ命名規則を作成するときは、次の規則に従います。

**文字の要件** – タグキーバリューには、文字、数字、空白、記号 (\$1 . : / = \$1 - @) の任意の組み合わせを使用できます。

**大文字と小文字の区別** – タグキーの大文字と小文字の区別は、タグ付けされた IAM リソースの種類によって変わります。IAM ユーザーとロールのタグキーバリューのペアでは、大文字と小文字は区別されませんが、大文字と小文字は維持されます。つまり、**Department** と **department** のタグキーを別々に持つことはできません。**Department=finance** タグでユーザーをタグ付けし、**department=hr** タグを追加すると、最初のタグが置き換えられます。2 番目のタグは追加されません。

他の IAM リソースタイプでは、タグキーバリューでは大文字と小文字が区別されます。つまり、**Costcenter** と **costcenter** タグキーとを個別に使用できます。例えば、カスタマー管理ポリシーに **Costcenter = 1234** タグを付け、**costcenter = 5678** タグを追加すると、そのポリシーには **Costcenter** と **costcenter** タグキーの両方が表示されます。

ベストプラクティスとしては、大文字と小文字の扱いに一貫性がない場合は、同様のタグを使用しないことを推奨します。タグに大文字を使用する場合の戦略を決定し、その戦略をすべてのリソースタイプにわたって一貫して実装することを推奨します。タグ付けのベストプラクティスの詳細については、「AWS 全般のリファレンス」の「[AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)」を参照してください。

IAM リソースにアタッチされているタグキーの、大文字と小文字の区別の差異を次に示します。

タグキーバリューでは大文字と小文字が区別**されません**。
+ IAM ロール
+ IAM ユーザー

タグキーバリューでは大文字と小文字が区別されます。
+ カスタマー管理ポリシー
+ インスタンスプロファイル
+ OpenID Connect ID プロバイダー
+ SAML ID プロバイダー
+ サーバー証明書
+ 仮想 MFA デバイス

加えて、次のルールが適用されます。
+ テキスト **aws:** から開始するタグキーや値を作成することはできません。このタグプレフィックスは AWS 社内使用のために予約されています。
+ 空の値 (例: **phoneNumber = **) を含むタグを作成することができます。空のタグキーを作成することはできません。
+ 1 つのタグで複数の値を指定することはできませんが、カスタムの複数値構造を 1 つの値で作成することができます。たとえば、ユーザー Zhang がエンジニアリングチーム、QA チームで働いているとします。**team = Engineering** タグ、**team = QA** タグの順にアタッチする場合は、タグの値を **Engineering** から **QA** に変更します。代わりに、カスタム区切り文字を使用して 1 つのタグに複数の値を含めることができます。この例では、**team = Engineering:QA** タグを Zhang にアタッチします。
**注記**  
**team** タグを使用して、この例のエンジニアへのアクセスを制御するには、**Engineering** を含む可能性のある各設定を許可するポリシー (例: **Engineering:QA**) を作成する必要があります。ポリシーのタグの使用の詳細については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

### タグの適用と編集
<a name="id_tags_rules_applying"></a>

タグを IAM リソースにアタッチするときは、次の規則に従います。
+ ほとんどの IAM リソースにはタグを付けられますが、グループ、引き受け済みのロール、アクセスレポート、ハードウェアベース MFA デバイスにはタグを付けることができません。
+ タグエディタを使って IAM リソースにタグ付けすることはできません。タグエディタは IAM タグをサポートしていません。他のサービスでのタグエディタの使用の詳細については、「AWS Resource Groups ユーザーガイド」の「[タグエディタでの作業](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html)」を参照してください。
+ IAM リソースにタグ付けするには、特定のアクセス許可が必要です。リソースにタグを付ける、またはタグを解除するには、タグを一覧表示するアクセス許可も必要です。詳細については、このページの最後にある各 IAM リソースのトピックのリストを参照してください。
+ AWS アカウントの IAM リソースの数とサイズには制限があります。詳細については、「[IAM と AWS STSクォータ](reference_iam-quotas.md)」を参照してください。
+ 同じタグを複数の IAM リソースに適用することができます。たとえば、`AWS_Development` という名前の部門に 12 人のメンバーがあるとします。12 人のユーザーと、**department** のタグキー、**awsDevelopment** の値を持つロールを持つことができます (**department = awsDevelopment**)。また、[タグ付けをサポートする他のサービス](reference_aws-services-that-work-with-iam.md)のリソースで同じタグを使用することもできます。
+ IAM エンティティ (ユーザーまたはロール) は、タグキーが同じである複数のインスタンスを持つことはできません。たとえば、タグのキーバリューのペア **costCenter = 1234** を含むユーザーがいる場合は、タグキーバリューのペア **costCenter = 5678** をアタッチできます。IAM は、**costCenter** タグの値を **5678** に更新します。
+ IAM エンティティ (ユーザーまたはロール) にアタッチされているタグを編集するには、新しい値のタグをアタッチして、既存のタグを上書きします。例えば、タグのキーバリューのペア **department = Engineering** を持つユーザーがいるとします。そのユーザーを QA 部門に移動させる必要がある場合、**department = QA** タグのキーバリューのペアをこのユーザーにアタッチします。その結果、**department** タグキーの **Engineering** 値は、**QA** 値に置き換わります。

# IAM ユーザーにタグ付けする
<a name="id_tags_users"></a>

IAM タグのキーバリューペアを使用することで、 ユーザーにカスタム属性を追加できます。たとえば、位置情報をユーザーに追加するには、タグキー **location** とタグ値 **us\$1wa\$1seattle** を追加できます。または、3 つの位置のタグのキーバリューペアを使用できます (**loc-country = us**、**loc-state = wa**、**loc-city = seattle**)。タグを使用することにより、リソースへのユーザーアクセスや、ユーザーにアタッチできるタグを、制御できます。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

AWS STS のタグを使用して、ロールを引き受けるとき、またはユーザーをフェデレートするときにカスタム属性を追加することもできます。詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

## IAM ユーザーのタグ付けに必要なアクセス許可
<a name="id_tags_users_permissions"></a>

IAM ユーザーに、他のユーザーへのタグ付けを許可するには、アクセス許可を設定する必要があります。IAM ポリシーの次の IAM タグアクションのいずれかまたはすべてを指定することができます。
+ `iam:ListUserTags`
+ `iam:TagUser`
+ `iam:UntagUser`

**IAM ユーザーに、特定のユーザーへのタグの追加、一覧表示、または削除を許可するには**  
タグを管理する必要のある IAM ユーザーのアクセス許可ポリシーに、以下のステートメントを追加します。アカウント番号を使用し、*<username>* を、タグの管理が必要とされているユーザーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**IAM ユーザーにタグの自己管理を許可するには**  
独自のタグの管理をユーザーに許可するアクセス許可ポリシーに、以下のステートメントを追加します。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::user/${aws:username}"
}
```

**IAM ユーザーに、特定のユーザーへのタグの追加を許可するには**  
特定のユーザーのタグを追加する必要はあるが、削除やタグ付けは不要な IAM ユーザーのアクセス許可ポリシーに、以下のステートメントを追加します。

**注記**  
`iam:TagUser` アクションには、`iam:ListUserTags` アクションも含める必要があります。

このポリシーを使用するには、*<username>* を、タグの管理が必要とされているユーザーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

または、[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) などの AWS 管理ポリシーを使用して、IAM へのフルアクセスを付与することもできます。

## IAM ユーザーのタグの管理 (コンソール)
<a name="id_tags_users_procs-console"></a>

IAM ユーザーのタグを AWS マネジメントコンソール から管理できます。

**ユーザーのタグを管理するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. コンソールのナビゲーションペインで、[**Users (ユーザー)**] を選択し、編集するユーザーの名前を選択します。

1. [**タグ**] タブを選択し、以下のいずれかのアクションを完了します。
   + ユーザーがまだタグがない場合は、**[新しいタグを追加]** を選択します。
   + **[Manage tags]** (タグを管理) を選択して、既存のタグセットを管理します。

1. タグのセットを完了するには、タグを追加または削除します。次に、**変更の保存**を選択します。

## IAM ユーザーのタグの管理 ( AWS CLI または AWS API)
<a name="id_tags_users_procs-cli-api"></a>

IAM ユーザーのタグを一覧表示、アタッチ、または削除できます。IAM ユーザーのタグを管理するには、AWS CLI または AWS API を使用します。

**IAM ユーザーに現在アタッチされているタグを一覧表示するには (AWS または AWS CLI API)**
+ AWS CLI: [aws iam list-user-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-tags.html)
+ AWS API: [ListUserTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUserTags.html)

**タグを IAM ユーザーにアタッチするには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam tag-user](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-user.html)
+ AWS API: [TagUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagUser.html)

**IAM ユーザーからタグを削除するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam untag-user](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-user.html)
+ AWS API: [UntagUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagUser.html)

他の AWS サービスのリソースにタグをアタッチする方法については、これらのサービスのドキュメントを参照してください。

IAM を使用して、タグで詳細なアクセスを許可する設定については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。

# IAM ロールにタグ付けする
<a name="id_tags_roles"></a>

IAM タグのキーバリューペアを使用することで、IAM ロールにカスタム属性を追加できます。例えば、位置情報をロールに追加するには、タグキー **location** とタグ値 **us\$1wa\$1seattle** を追加します。または、3 つの位置のタグのキーバリューのペアを使用できます (**loc-country = us**、**loc-state = wa**、**loc-city = seattle**)。タグを使用することにより、リソースへのロールのアクセスや、ロールにアタッチできるタグを、制御できます。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

AWS STS のタグを使用して、ロールを引き受けるとき、またはユーザーをフェデレートするときにカスタム属性を追加することもできます。詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

## IAM ロールのタグ付けに必要なアクセス許可
<a name="id_tags_roles_permissions"></a>

IAM ロールに、他のエンティティ (ユーザーまたはロール) へのタグ付けを許可するには、アクセス許可を設定する必要があります。IAM ポリシーの次の IAM タグアクションのいずれかまたはすべてを指定することができます。
+ `iam:ListRoleTags`
+ `iam:TagRole`
+ `iam:UntagRole`
+ `iam:ListUserTags`
+ `iam:TagUser`
+ `iam:UntagUser`

**IAM ロールに、特定のユーザーへのタグの追加、一覧表示、または削除を許可するには**  
タグを管理する必要のある IAM ロールのアクセス許可ポリシーに、以下のステートメントを追加します。アカウント番号を使用し、*<username>* を、タグの管理が必要とされているユーザーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**IAM ロールに、特定のユーザーへのタグの追加を許可するには**  
特定のユーザーのタグを追加する必要はあるが、削除やタグ付けは不要な IAM ロールのアクセス許可ポリシーに、以下のステートメントを追加します。

このポリシーを使用するには、*<username>* を、タグの管理が必要とされているユーザーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**IAM ロールに、特定のロールへのタグの追加、一覧表示、または削除を許可するには**  
タグを管理する必要のある IAM ロールのアクセス許可ポリシーに、以下のステートメントを追加します。*<rolename>* を、タグの管理が必要とされているロールの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListRoleTags",
        "iam:TagRole",
        "iam:UntagRole"
    ],
    "Resource": "arn:aws:iam::<account-number>:role/<rolename>"
}
```

または、[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) などのAWS 管理ポリシーを使用して、IAM へのフルアクセスを付与することもできます。

## IAM ロールのタグの管理 (コンソール)
<a name="id_tags_roles_procs-console"></a>

IAM ロールのタグを AWS マネジメントコンソール から管理できます。

**ロールのタグを管理するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. コンソールのナビゲーションペインで、**ロール** を選択し、編集するロールの名前を選択します。

1. [**タグ**] タブを選択し、以下のいずれかのアクションを完了します。
   + ロールにまだタグがない場合は、**[Add new tag]** (新しいタグを追加) を選択します。
   + **[Manage tags]** (タグを管理) を選択して、既存のタグセットを管理します。

1. タグのセットを完了するには、タグを追加または削除します。次に、[**変更の保存**] を選択します。

## IAM ロールのタグの管理 (AWS CLI または AWS API)
<a name="id_tags_roles_procs-cli-api"></a>

IAM ロールのタグを一覧表示、アタッチ、または削除できます。IAM ロールのタグ付けを管理するには、AWS CLI または AWS API を使用します。

**IAM ロール (AWS CLI または AWS API) に現在アタッチされているタグを一覧表示するには**
+ AWS CLI: [aws iam list-role-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-role-tags.html)
+ AWS API: [ListRoleTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoleTags.html)

**タグを IAM ロール (AWS CLI または AWS API) にアタッチするには**
+ AWS CLI: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
+ AWS API: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

**IAM ロール (AWS CLI または AWS API) からタグを削除するには**
+ AWS CLI: [aws iam untag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-role.html)
+ AWS API: [UntagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagRole.html)

他の AWS サービスのリソースにタグをアタッチする方法については、これらのサービスのドキュメントを参照してください。

IAM を使用して、タグで詳細なアクセスを許可する設定については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。

# カスタマー管理ポリシーにタグ付けする
<a name="id_tags_customer-managed-policies"></a>

IAM タグのキーバリューペアを使用することにより、カスタム属性をカスタマー管理ポリシーに追加できます。例えば、部門情報を使用してポリシーにタグを付けるには、タグキーと **Department** とタグ値 **eng** を追加します。あるいは、ポリシーにタグを付けて、特定の環境 (**Environment = lab** など) 向けであることを示すこともできます。リソースへのアクセスを制御したり、どのタグをリソースにアタッチできるかを制御したりするために、タグを使用します。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

AWS STS のタグを使用して、ロールを引き受けるとき、またはユーザーをフェデレートするときにカスタム属性を追加することもできます。詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

## カスタマー管理ポリシーのタグ付けに必要なアクセス許可
<a name="id_tags_customer-managed-policies_permissions"></a>

IAM エンティティ (ユーザーまたはロール) に、カスタマー管理ポリシーへのタグ付けを許可するには、アクセス許可を設定する必要があります。IAM ポリシーの次の IAM タグアクションのいずれかまたはすべてを指定することができます。
+ `iam:ListPolicyTags`
+ `iam:TagPolicy`
+ `iam:UntagPolicy`

**IAM エンティティ (ユーザーまたはロール) にカスタマー管理ポリシーへのタグの追加、一覧表示、削除を許可するには**  
タグを管理する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。アカウント番号を使用し、*<policyname>* を、タグの管理が必要とされているポリシーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListPolicyTags",
        "iam:TagPolicy",
        "iam:UntagPolicy"
    ],
    "Resource": "arn:aws:iam::<account-number>:policy/<policyname>"
}
```

**IAM エンティティ (ユーザーまたはロール) に特定のカスタマー管理ポリシーへのタグの追加を許可するには**  
特定のポリシーのタグを追加する必要はあるが、削除は不要である IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。

**注記**  
`iam:TagPolicy` アクションには、`iam:ListPolicyTags` アクションも含める必要があります。

このポリシーを使用するには、*<policyname>* を、タグの管理が必要とされているポリシーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListPolicyTags",
        "iam:TagPolicy"
    ],
    "Resource": "arn:aws:iam::<account-number>:policy/<policyname>"
}
```

または、[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) などの AWS 管理ポリシーを使用して、IAM へのフルアクセスを付与することもできます。

## IAM カスタマー管理ポリシーのタグの管理 (コンソール)
<a name="id_tags_customer-managed-policies_procs-console"></a>

IAM カスタマー管理ポリシーのタグは、AWS マネジメントコンソール から管理できます。

**カスタマー管理ポリシーのタグを管理するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. コンソールのナビゲーションペインで、[**Policies (ポリシー)**] を選択し、続いて編集するカスタマー管理ポリシーの名前を選択します。

1. [**タグ**] タブを選択し、[**タグを管理**] を選択します。

1. タグのセットを完了するには、タグを追加または削除します。次に、**変更の保存**を選択します。

## IAM カスタマー管理ポリシーのタグの管理 (AWS CLI または AWS API)
<a name="id_tags_customer-managed-policies_procs-cli-api"></a>

IAM カスタマー管理ポリシーのタグを一覧表示、アタッチ、または削除することができます。IAM カスタマー管理ポリシーのタグを管理するには、AWS CLI または AWS API を使用します。

**IAM カスタマー管理ポリシーに現在アタッチされているタグを一覧表示するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam list-policy-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-policy-tags.html)
+ AWS API: [ListPolicyTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListPolicyTags.html)

**IAM カスタマー管理ポリシーにタグをアタッチするには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam tag-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-policy.html)
+ AWS API: [TagPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagPolicy.html)

**IAM カスタマー管理ポリシーからタグを削除するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam untag-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-policy.html)
+ AWS API: [UntagPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagPolicy.html)

他の AWS サービスのリソースにタグをアタッチする方法については、これらのサービスのドキュメントを参照してください。

IAM を使用して、タグで詳細なアクセスを許可する設定については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。

# OpenID Connect (OIDC) ID プロバイダーにタグ付けする
<a name="id_tags_oidc"></a>

IAM タグキーバリューを使用することで、IAM OpenID Connect (OIDC) ID プロバイダーにカスタム属性を追加できます。例えば、OIDC ID プロバイダーを特定するには、タグキー **google** とタグ値 **oidc** を追加します。リソースへのアクセスを制御したり、どのタグをオブジェクトにアタッチできるかを制御したりするために、タグを使用します。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

## IAM OIDC ID プロバイダーのタグ付けに必要なアクセス許可
<a name="id_tags_oidc_permissions"></a>

IAM エンティティ (ユーザーまたはロール) に IAM OIDC ID プロバイダーへのタグ付けを許可するには、アクセス許可を設定する必要があります。IAM ポリシーの次の IAM タグアクションのいずれかまたはすべてを指定することができます。
+ `iam:ListOpenIDConnectProviderTags`
+ `iam:TagOpenIDConnectProvider`
+ `iam:UntagOpenIDConnectProvider`

**IAM エンティティに IAM OIDC ID プロバイダーへのタグの追加、一覧表示、削除を許可するには**  
タグを管理する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。アカウント番号を使用し、*<OIDCProviderName>* を、タグの管理が必要とされている OIDC プロバイダーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListOpenIDConnectProviderTags",
        "iam:TagOpenIDConnectProvider",
        "iam:UntagOpenIDConnectProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:oidc-provider/<OIDCProviderName>"
}
```

**IAM エンティティ (ユーザーまたはロール) に、特定の IAM OIDC ID プロバイダーへのタグの追加を許可するには**  
特定の ID プロバイダーのタグを追加する必要はあるが、削除やタグ付けは不要である IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。

**注記**  
`iam:TagOpenIDConnectProvider` アクションには、`iam:ListOpenIDConnectProviderTags` アクションも含める必要があります。

このポリシーを使用するには、*<OIDCProviderName>* を、タグの管理が必要とされている OIDC プロバイダーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListOpenIDConnectProviderTags",
        "iam:TagOpenIDConnectProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:oidc-provider/<OIDCProviderName>"
}
```

または、[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) などの AWS 管理ポリシーを使用して、IAM へのフルアクセスを付与することもできます。

## IAM OIDC ID プロバイダーのタグの管理 (コンソール)
<a name="id_tags_oidc_procs-console"></a>

IAM OIDC ID プロバイダーのタグは AWS マネジメントコンソール から管理できます。

**OIDC ID プロバイダーのタグを管理するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. コンソールのナビゲーションペインで [**Identity providers (ID プロバイダー)**] を選択し、編集する ID プロバイダーの名前を選択します。

1. **[タグ]** タブを選択し、続いて **[タグ]** セクションで **[タグを管理]** を選択し、次のいずれかのアクションを実行します。
   + OIDC ID プロバイダーにまだタグがない場合、または新しいタグを追加する場合は、[**Add tag (タグの追加)**] を選択します。
   + 既存のタグキーバリューを編集します。
   + タグを削除するには、[**Remove tag (タグの削除)**] を選択します。

1. 次に、**変更の保存**を選択します。

## IAM OIDC ID プロバイダーのタグの管理 (AWS CLI または AWS API)
<a name="id_tags_oidc_procs-cli-api"></a>

IAM OIDC ID プロバイダーのタグを一覧表示、アタッチ、または削除することができます。IAM OIDC ID プロバイダーのタグを管理するには、AWS CLI または AWS API を使用します。

**IAM OIDC ID プロバイダーに現在アタッチされているタグを一覧表示するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam list-open-id-connect-provider-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html)
+ AWS API: [ListOpenIDConnectProviderTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html)

**IAM OIDC ID プロバイダーにタグをアタッチするには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam tag-open-id-connect-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html)
+ AWS API: [TagOpenIDConnectProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html)

**IAM OIDC ID プロバイダーのタグを削除するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam untag-open-id-connect-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html)
+ AWS API: [UntagOpenIDConnectProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html)

他の AWS サービスのリソースにタグをアタッチする方法については、これらのサービスのドキュメントを参照してください。

IAM を使用して、タグで詳細なアクセスを許可する設定については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。

# IAM SAML ID プロバイダーにタグ付けする
<a name="id_tags_saml"></a>

IAM タグのキーバリューペアを使用することで、SAML プロバイダーにカスタム属性を追加できます。例えば、プロバイダーを特定するには、タグキー **okta** とタグ値 **saml** を追加します。リソースへのアクセスを制御したり、どのタグをオブジェクトにアタッチできるかを制御したりするために、タグを使用します。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

## SAML ID プロバイダーのタグ付けに必要なアクセス許可
<a name="id_tags_saml_permissions"></a>

IAM エンティティ (ユーザーまたはロール) に SAML 2.0 ベースの ID プロバイダー (IdP) へのタグ付けを許可するには、アクセス許可を設定する必要があります。IAM ポリシーの次の IAM タグアクションのいずれかまたはすべてを指定することができます。
+ `iam:ListSAMLProviderTags`
+ `iam:TagSAMLProvider`
+ `iam:UntagSAMLProvider`

**IAM エンティティ (ユーザーまたはロール) に SAML ID プロバイダーへのタグの追加、一覧表示、削除を許可するには**  
タグを管理する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。アカウント番号を使用し、*<SAMLProviderName>* を、タグの管理が必要とされている SAML プロバイダーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListSAMLProviderTags",
        "iam:TagSAMLProvider",
        "iam:UntagSAMLProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:saml-provider/<SAMLProviderName>"
}
```

**IAM エンティティ (ユーザーまたはロール) に、特定の SAML ID プロバイダーへのタグの追加を許可するには**  
特定の SAML プロバイダーのタグを追加する必要はあるが、削除やタグ付けは不要である IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。

**注記**  
`iam:TagSAMLProvider` アクションには、`iam:ListSAMLProviderTags` アクションも含める必要があります。

このポリシーを使用するには、*<SAMLProviderName>* を、タグの管理が必要とされている SAML プロバイダーの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListSAMLProviderTags",
        "iam:TagSAMLProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:saml-provider/<SAMLProviderName>"
}
```

または、[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) などの AWS 管理ポリシーを使用して、IAM へのフルアクセスを付与することもできます。

## IAM SAML ID プロバイダーのタグの管理 (コンソール)
<a name="id_tags_saml_procs-console"></a>

IAM SAML ID プロバイダーのタグは AWS マネジメントコンソール から管理できます。

**SAML ID プロバイダーのタグを管理するには (コンソール)**

1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。

1. コンソールのナビゲーションペインで [**Identity providers (ID プロバイダー)**] を選択し、編集するSAML ID プロバイダーの名前を選択します。

1. **[タグ]** タブを選択し、続いて **[タグ]** セクションで **[タグを管理]** を選択し、次のいずれかのアクションを実行します。
   + SAML ID プロバイダーにまだタグがない場合、または新しいタグを追加する場合は、[**Add tag (タグの追加)**] を選択します。
   + 既存のタグキーバリューを編集します。
   + タグを削除するには、[**Remove tag (タグの削除)**] を選択します。

1. タグのセットを完了するには、タグを追加または削除します。次に、**変更の保存**を選択します。

## IAM SAML ID プロバイダーのタグの管理 (AWS CLI または AWS API)
<a name="id_tags_saml_procs-cli-api"></a>

IAM SAML ID プロバイダーのタグを一覧表示、アタッチ、または削除することができます。IAM SAML ID プロバイダーのタグを管理するには、AWS CLI または AWS API を使用します。

**SAML ID プロバイダーに現在アタッチされているタグを一覧表示するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam list-saml-provider-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html)
+ AWS API: [ListSAMLProviderTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html)

**SAML ID プロバイダーにタグをアタッチするには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam tag-saml-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html)
+ AWS API: [TagSAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html)

**SAML ID プロバイダーのタグを削除するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam untag-saml-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html)
+ AWS API: [UntagSAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html)

他の AWS サービスのリソースにタグをアタッチする方法については、これらのサービスのドキュメントを参照してください。

IAM を使用して、タグで詳細なアクセスを許可する設定については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。

# Amazon EC2 ロール用のインスタンスプロファイルにタグ付けする
<a name="id_tags_instance-profiles"></a>

Amazon EC2 インスタンスを起動するときに、そのインスタンスに関連付ける IAM ロールを指定します。インスタンスプロファイルは IAM ロールのコンテナであり、インスタンスの起動時に Amazon EC2 インスタンスにロール情報を渡すために使用できます。インスタンスプロファイルにタグを付けることができるのは、AWS CLI または AWS API を使用しているときです。

IAM タグのキーバリューペアを使用することで、インスタンスプロファイルにカスタム属性を追加できます。例えば、インスタンスプロファイルに部門情報を追加するには、タグキー **access-team** とタグ値 **eng** を追加します。これにより、一致するタグを持つプリンシパルは、同じタグを持つインスタンスプロファイルにアクセスできるようになります。複数のタグのキーバリューペアを使用して、チームとプロジェクト、**access-team = eng ** と **project = peg** を指定できます。タグを使用することにより、リソースへのユーザーアクセスや、ユーザーにアタッチできるタグを、制御できます。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

AWS STS のタグを使用して、ロールを引き受けるとき、またはユーザーをフェデレートするときにカスタム属性を追加することもできます。詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

## インスタンスプロファイルのタグ付けに必要なアクセス許可
<a name="id_tags_instance-profiles_permissions"></a>

IAM エンティティ (ユーザーまたはロール) にインスタンスプロファイルへのタグ付けを許可するには、アクセス許可を設定する必要があります。IAM ポリシーの次の IAM タグアクションのいずれかまたはすべてを指定することができます。
+ `iam:ListInstanceProfileTags`
+ `iam:TagInstanceProfile`
+ `iam:UntagInstanceProfile`

**IAM エンティティ (ユーザーまたはロール) にインスタンスプロファイルへのタグの追加、一覧表示、削除を許可するには**  
タグを管理する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。アカウント番号を使用し、*<InstanceProfileName>* を、タグの管理が必要とされているインスタンスプロファイルの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListInstanceProfileTags",
        "iam:TagInstanceProfile",
        "iam:UntagInstanceProfile"
    ],
    "Resource": "arn:aws:iam::<account-number>:instance-profile/<InstanceProfileName>"
}
```

**IAM エンティティ (ユーザーまたはロール) にインスタンスプロファイルへのタグの追加を許可するには**  
特定のインスタンスプロファイルのタグを追加する必要はあるが、削除は不要である IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。

**注記**  
`iam:TagInstanceProfile` アクションには、`iam:ListInstanceProfileTags` アクションも含める必要があります。

このポリシーを使用するには、*<InstanceProfileName>* を、タグの管理が必要とされているインスタンスプロファイルの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListInstanceProfileTags",
        "iam:TagInstanceProfile"
    ],
    "Resource": "arn:aws:iam::<account-number>:instance-profile/<InstanceProfileName>"
}
```

または、[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) などの AWS 管理ポリシーを使用して、IAM へのフルアクセスを付与することもできます。

## インスタンスプロファイルのタグの管理 (AWS CLI または AWS API)
<a name="id_tags_instance-profile_procs-cli-api"></a>

インスタンスプロファイルのタグを一覧表示、アタッチ、または削除することができます。AWS CLI または AWS API を使用して、インスタンスプロファイルのタグ付けを管理できます。

**インスタンスプロファイルに現在アタッチされているタグを一覧表示するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam list-instance-profile-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html)
+ AWS API: [ListInstanceProfileTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfileTags.html)

**インスタンスプロファイルにタグをアタッチするには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam tag-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html)
+ AWS API: [TagInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html)

**インスタンスプロファイルからタグを削除するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam untag-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html)
+ AWS API: [UntagInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagInstanceProfile.html)

他の AWS サービスのリソースにタグをアタッチする方法については、これらのサービスのドキュメントを参照してください。

IAM を使用して、タグで詳細なアクセスを許可する設定については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。

# タグ サーバー証明書
<a name="id_tags_server-certificates"></a>

AWS CLI を使用して SSL/TLS 証明書を管理する場合は、 または AWS APIを使用してに IAM あるサーバー証明書にタグ付けします。AWS Certificate Manager (ACM) でサポートされているリージョンの証明書については、IAM ではなく ACM を使用して、サーバー証明書をプロビジョン、管理、デプロイすることをお勧めします。サポートされていないリージョンでは、IAM を Certificate Manager として使用する必要があります。ACM がサポートするリージョンについては、「AWS 全般のリファレンス」の「[AWS Certificate Manager エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/acm.html)」を参照してください。

IAM タグのキーバリューペアを使用することで、サーバー証明書にカスタム属性を追加できます。例えば、サーバー証明書の所有者または管理者に関する情報を追加するには、タグキー **owner** とタグ値 **net-eng** を追加します。または、タグキー **CostCenter** とタグ値 **1234** を追加して、コストセンターを指定することもできます。リソースへのアクセスを制御したり、どのタグをリソースにアタッチできるかを制御したりするために、タグを使用します。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

AWS STS のタグを使用して、ロールを引き受けるとき、またはユーザーをフェデレートするときにカスタム属性を追加することもできます。詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

## サーバー証明書のタグ付けに必要なアクセス許可
<a name="id_tags_server-certificates_permissions"></a>

IAM エンティティ (ユーザーまたはロール) にサーバー証明書へのタグ付けを許可するには、アクセス許可を設定する必要があります。IAM ポリシーの次の IAM タグアクションのいずれかまたはすべてを指定することができます。
+ `iam:ListServerCertificateTags`
+ `iam:TagServerCertificate`
+ `iam:UntagServerCertificate`

**IAM エンティティ (ユーザーまたはロール) にサーバー証明書へのタグの追加、一覧表示、削除を許可するには**  
タグを管理する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。アカウント番号を使用し、*<CertificateName>* を、タグの管理が必要とされているサーバー証明書の名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListServerCertificateTags",
        "iam:TagServerCertificate",
        "iam:UntagServerCertificate"
    ],
    "Resource": "arn:aws:iam::<account-number>:server-certificate/<CertificateName>"
}
```

**IAM エンティティ (ユーザーまたはロール) に特定のサーバー証明書へのタグの追加を許可するには**  
特定の サーバー証明書のタグを追加する必要はあるが、削除やタグ付けは不要である IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。

**注記**  
`iam:TagServerCertificate` アクションには、`iam:ListServerCertificateTags` アクションも含める必要があります。

このポリシーを使用するには、*<CertificateName>* を、タグの管理が必要とされているサーバー証明書の名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListServerCertificateTags",
        "iam:TagServerCertificate"
    ],
    "Resource": "arn:aws:iam::<account-number>:server-certificate/<CertificateName>"
}
```

または、[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) などの AWS 管理ポリシーを使用して、IAM へのフルアクセスを付与することもできます。

## サーバー証明書のタグの管理 (AWS CLI または AWS API)
<a name="id_tags_server-certificates_procs-cli-api"></a>

サーバー証明書のタグを一覧表示、アタッチ、または削除できます。サーバー証明書のタグを管理するには、AWS CLI または AWS API を使用します。

**サーバー証明書に現在アタッチされているタグを一覧表示するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam list-server-certificate-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificate-tags.html)
+ AWS API: [ListServerCertificateTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServerCertificateTags.html)

**サーバー証明書にタグをアタッチするには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam tag-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-server-certificate.html)
+ AWS API: [TagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagServerCertificate.html)

**サーバー証明書からタグを削除するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam untag-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-server-certificate.html)
+ AWS API: [UntagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagServerCertificate.html)

他の AWS サービスのリソースにタグをアタッチする方法については、これらのサービスのドキュメントを参照してください。

IAM を使用して、タグで詳細なアクセスを許可する設定については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。

# MFA デバイスにタグ付けする
<a name="id_tags_virtual-mfa"></a>

IAM タグのキーバリューペアを使用することで、仮想 MFA デバイスにカスタム属性を追加できます。例えば、ユーザーの仮想 MFA デバイスのコストセンター情報を追加するには、タグキー **CostCenter** とタグ値 **1234** を追加します。リソースへのアクセスを制御したり、どのタグをオブジェクトにアタッチできるかを制御したりするために、タグを使用します。タグを使用したアクセスの制御については、「[タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御](access_iam-tags.md)」を参照してください。

AWS STS のタグを使用して、ロールを引き受けるとき、またはユーザーをフェデレートするときにカスタム属性を追加することもできます。詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。

## 仮想 MFA デバイスのタグ付けに必要なアクセス許可
<a name="id_tags_virtual-mfa_permissions"></a>

IAM エンティティ (ユーザーまたはロール) に仮想 MFA デバイスへのタグ付けを許可するには、アクセス許可を設定する必要があります。IAM ポリシーの次の IAM タグアクションのいずれかまたはすべてを指定することができます。
+ `iam:ListMFADeviceTags`
+ `iam:TagMFADevice`
+ `iam:UntagMFADevice`

**IAM エンティティ (ユーザーまたはロール) に仮想 MFA デバイスへのタグの追加、一覧表示、削除を許可するには**  
タグを管理する必要のある IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。アカウント番号を使用し、*<MFATokenID>* を、タグの管理が必要とされている MFA デバイスの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListMFADeviceTags",
        "iam:TagMFADevice",
        "iam:UntagMFADevice"
    ],
    "Resource": "arn:aws:iam::<account-number>:mfa/<MFATokenID>"
}
```

**IAM エンティティ (ユーザーまたはロール) に特定の仮想 MFA デバイスへのタグの追加を許可するには**  
特定のポリシーの MFA デバイスを追加する必要はあるが、削除は不要である IAM エンティティのアクセス許可ポリシーに、以下のステートメントを追加します。

**注記**  
`iam:TagMFADevice` アクションには、`iam:ListMFADeviceTags` アクションも含める必要があります。

このポリシーを使用するには、*<MFATokenID>* を、タグの管理が必要とされている MFA デバイスの名前に置き換えます。この例の JSON ポリシードキュメントを使用してポリシーを作成する方法については、「[JSON エディターを使用したポリシーの作成](access_policies_create-console.md#access_policies_create-json-editor)」を参照してください。

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListMFADeviceTags",
        "iam:TagMFADevice"
    ],
    "Resource": "arn:aws:iam::<account-number>:mfa/<MFATokenID>"
}
```

または、[IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) などの AWS 管理ポリシーを使用して、IAM へのフルアクセスを付与することもできます。

## 仮想 MFA デバイスのタグの管理 (AWS CLI または AWS API)
<a name="id_tags_virtual-mfa_procs-cli-api"></a>

仮想 MFA デバイスのタグを一覧表示、アタッチ、または削除できます。仮想 MFA デバイスのタグを管理するには、AWS CLI または AWS API を使用します。

**仮想 MFA デバイスに現在アタッチされているタグを一覧表示するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam list-mfa-device-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html)
+ AWS API: [ListMFADeviceTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html)

**仮想 MFA デバイスにタグをアタッチするには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam tag-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html)
+ AWS API: [TagMFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html)

**仮想 MFA デバイスからタグを削除するには (AWS CLI または AWS API)**
+ AWS CLI: [aws iam untag-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html)
+ AWS API: [UntagMFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html)

他の AWS サービスのリソースにタグをアタッチする方法については、これらのサービスのドキュメントを参照してください。

IAM を使用して、タグで詳細なアクセスを許可する設定については、「[IAM ポリシーの要素: 変数とタグ](reference_policies_variables.md)」を参照してください。

# AWS STS でセッションタグを渡します
<a name="id_session-tags"></a>

セッションタグは、AWS STS で IAM ロールを引き受けるとき、またはユーザーをフェデレートするときに渡すキーバリューのペアの属性です。これを行うには、AWS CLI または ID プロバイダー (IdP) を介して AWS STS または AWS API リクエストを実行します。AWS STS を使用して一時的なセキュリティ認証情報をリクエストすると、セッションが生成されます。セッションは有効期限があり、アクセスキーペアやセッショントークンなどの [認証情報](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) があります。セッション認証情報を使用して後続のリクエストを行う場合、[リクエストコンテキスト](reference_policies_elements_condition.md#AccessPolicyLanguage_RequestContext)には、`aws:PrincipalTag` コンテキストキーが含まれます。ポリシーの `Condition` 要素で `aws:PrincipalTag` キーを使用して、それらのタグに基づいてアクセスを許可または拒否できます。

一時的な認証情報を使用してリクエストを行う場合、プリンシパルに一連のタグが含まれる場合があります。これらのタグは、次のソースから取得されます。

1. **セッションタグ** – これらのタグは、ロールを引き受けるか、AWS CLI または AWS API を使用してユーザーをフェデレーションしたときに渡されました。これらのオペレーションの詳細については、[セッションのタグ付けオペレーション](#id_session-tags_operations) を参照してください。

1. **受信推移的セッションタグ** – これらのタグは、ロール連鎖内の前のセッションから継承されました。詳細については、このトピックで後述する「[セッションタグを使用したロールの連鎖](#id_session-tags_role-chaining)」を参照してください。

1. **IAM タグ** — IAM が引き受けたロールにアタッチされたタグ。

**Topics**
+ [

## セッションのタグ付けオペレーション
](#id_session-tags_operations)
+ [

## セッションタグについて知っておくべきこと
](#id_session-tags_know)
+ [

## セッションタグの追加に必要なアクセス許可
](#id_session-tags_permissions-required)
+ [

## AssumeRole を使用したセッションタグの受け渡し
](#id_session-tags_adding-assume-role)
+ [

## AssumeRoleWithSAML を使用したセッションタグの受け渡し
](#id_session-tags_adding-assume-role-saml)
+ [

## AssumeRoleWithWebIdentity を使用したセッションタグの受け渡し
](#id_session-tags_adding-assume-role-idp)
+ [

## GetFederationToken を使用したセッションタグの受け渡し
](#id_session-tags_adding-getfederationtoken)
+ [

## セッションタグを使用したロールの連鎖
](#id_session-tags_role-chaining)
+ [

## ABAC でのセッションタグの使用
](#id_session-tags_using-abac)
+ [

## CloudTrail でのセッションタグの表示
](#id_session-tags_ctlogs)

## セッションのタグ付けオペレーション
<a name="id_session-tags_operations"></a>

セッションタグを渡すには、AWS STS の次の AWS CLI または AWS API オペレーションを使用します。*AWS マネジメントコンソール [**[Switch Role](id_roles_use_switch-role-console.md)**] 機能では、セッションタグを渡すことはできません。*

セッションタグを推移的に設定することもできます。推移的なタグは、ロールの連鎖中も保持されます。詳細については、「[セッションタグを使用したロールの連鎖](#id_session-tags_role-chaining)」を参照してください。

次の表は、セッションタグを渡す方法を比較したものです。


|  運用 |  **だれがロールを引き受けるか**  | **タグを渡す方法** |  **推移的なタグを設定する方法**  | 
| --- | --- | --- | --- | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI または [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API オペレーション | IAM ユーザーまたはセッション | Tags API パラメータまたは --tags CLI オプション | TransitiveTagKeys API パラメータまたは --transitive-tag-keys CLI オプション | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html) CLI または [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API オペレーション | SAML ID プロバイダーを使用して認証されたユーザー | PrincipalTag SAML 属性 | TransitiveTagKeys SAML 属性 | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) CLI または [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API オペレーション | OIDC プロバイダーを使用して認証されたユーザー | PrincipalTag OIDC トークン | TransitiveTagKeys OIDC トークン | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/get-federation-token.html](https://docs.aws.amazon.com/cli/latest/reference/sts/get-federation-token.html) CLI または [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API オペレーション | IAM ユーザーまたはルートユーザー | Tags API パラメータまたは --tags CLI オプション | サポートされていません | 

セッションのタグ付けをサポートするオペレーションは、次の条件で失敗する可能性があります。
+ 50 を超えるセッションタグを渡している。
+ セッションタグキーのプレーンテキストが 128 文字を超えている。
+ セッションタグ値のプレーンテキストが 256 文字を超えている。
+ セッションポリシーのプレーンテキストの合計サイズが 2048 文字を超えている。
+ セッションポリシーとセッションタグを組み合わせた合計パックサイズが大きすぎる。オペレーションが失敗した場合、エラーメッセージは、ポリシーとタグの組み合わせが上限サイズにどれだけ近いかをパーセントで示します。

## セッションタグについて知っておくべきこと
<a name="id_session-tags_know"></a>

セッションタグを使用する前に、セッションとタグに関する次の詳細を確認してください。
+ セッションタグを使用する場合、タグを渡す ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに [`sts:TagSession`](#id_session-tags_permissions-required) アクセス許可が必要です。信頼ポリシーでこのアクセス許可を持たないロールの場合、`AssumeRole` オペレーションは失敗します。
+ セッションを要求するときに、プリンシパルタグをセッションタグとして指定できます。タグは、セッションの認証情報を使用して行うリクエストに適用されます。
+ セッションタグはキーバリューペアです。たとえば、セッションに連絡先情報を追加するには、セッションタグキー `email` とタグ値 `johndoe@example.com` を追加します。
+ セッションタグは、[IAM および AWS STSのタグ命名規則](id_tags.md#id_tags_rules_creating)に従う必要があります。このトピックでは、セッションタグに適用される大文字と小文字の区別と制限付きプレフィックスについて説明します。
+ 新しいセッションタグは、同じタグキーを持つ引き受けた既存のロールまたはフェデレーションユーザーのセッションタグをオーバーライドします (大文字/小文字は問わない)。
+ AWS マネジメントコンソール を使用してセッションタグを渡すことはできません。
+ セッションタグは、現在のセッションに対してのみ有効です。
+ セッションタグは [ロールの連鎖](id_roles.md#iam-term-role-chaining)をサポートします。デフォルトでは、AWS STS は後続のロールセッションに渡されません。ただし、セッションタグを推移的に設定することはできます。推移的なタグは、ロールの連鎖中は保持され、ロールの信頼ポリシーの評価後に一致する `ResourceTag` の値を置き換えます。詳細については、「[セッションタグを使用したロールの連鎖](#id_session-tags_role-chaining)」を参照してください。
+ セッションタグを使用して、リソースへのアクセスを制御したり、後続のセッションに渡すことができるタグを制御できます。詳細については、「[IAM チュートリアル: ABAC で SAML セッションタグを使用する](tutorial_abac-saml.md)」を参照してください。
+ セッションのプリンシパルタグ（セッションタグを含む）を AWS CloudTrail ログに表示できます。詳細については、「[CloudTrail でのセッションタグの表示](#id_session-tags_ctlogs)」を参照してください。
+ セッションタグごとに 1 つの値を渡す必要があります。AWS STS は、複数値を持つセッションタグをサポートしていません。
+ 最大 50 個のセッションタグを渡すことができます。AWS アカウントの IAM リソースの数とサイズには制限があります。詳細については、「[IAM と AWS STSクォータ](reference_iam-quotas.md)」を参照してください。
+ AWS 変換は、渡されたセッションポリシーとセッションタグを結合して、個別の制限を持つひとまとめのバイナリ形式に圧縮します。この制限を超えた場合、AWS CLI または AWS API エラーメッセージは、ポリシーとタグの組み合わせが上限サイズにどれだけ近いかをパーセントで示します。

## セッションタグの追加に必要なアクセス許可
<a name="id_session-tags_permissions-required"></a>

API オペレーションに一致するアクションに加えて、ポリシーには次のアクセス許可のみのアクションが必要です。

```
sts:TagSession
```

**重要**  
セッションタグを使用する場合、ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに `sts:TagSession` アクセス許可が必要です。このアクセス許可なしでセッションタグを渡している IdP に接続されているロールでは、`AssumeRole` オペレーションは失敗します。各ロールのロール信頼ポリシーを更新しない場合は、セッションタグを渡すために個別の IdP インスタンスを使用できます。その後、個別の IdP に接続されているロールにのみ `sts:TagSession` アクセス許可を追加します。

`sts:TagSession` アクションは、次の条件キーで使用できます。
+ `aws:PrincipalTag` – このキーを使用して、リクエストを行うプリンシパルにアタッチされたタグと、ポリシーで指定したタグを比較します。たとえば、リクエストを行うプリンシパルに指定されたタグがある場合にのみ、プリンシパルがセッションタグを渡すことを許可できます。
+ `aws:RequestTag` – このキーを使用して、リクエストで渡されたタグキーバリューのペアと、ポリシーで指定したタグペアを比較します。たとえば、プリンシパルが指定したセッションタグを渡すことを許可し、指定した値のみを渡すことができます。
+ `aws:ResourceTag` – このキーを使用して、ポリシーで指定したタグキーバリューのペアと、リソースにアタッチされているキーバリューのペアを比較します。たとえば、プリンシパルが引き受けるロールに指定されたタグが含まれている場合にのみ、セッションタグを渡すことを許可できます。
+ `aws:TagKeys` – このキーを使用して、リクエスト内のタグキーとポリシーで指定したキーを比較します。たとえば、プリンシパルが指定したタグキーを持つセッションタグのみを渡すことを許可できます。この条件キーは、渡すことができるセッションタグの最大セットを制限します。
+ `sts:TransitiveTagKeys` – このキーを使用して、リクエスト内の推移的なセッションタグキーとポリシーで指定されたセッションタグキーを比較します。たとえば、プリンシパルが特定のタグのみを推移的に設定することを許可するポリシーを記述できます。推移的なタグは、ロールの連鎖中も保持されます。詳細については、「[セッションタグを使用したロールの連鎖](#id_session-tags_role-chaining)」を参照してください。

たとえば、次の[ロール信頼ポリシー](id_roles.md#term_trust-policy)では、`test-session-tags` ユーザーはポリシーがアタッチされているロールを引き受けることができます。そのユーザーがロールを引き受けるときは、AWS CLI または AWS API を使用して、3 つの必須セッションタグと必要な[外部 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) を渡す必要があります。さらに、ユーザーは `Project` および `Department` タグを推移的に設定することもできます。

**Example セッションタグのロール信頼ポリシーの例**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowIamUserAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/test-session-tags"},
            "Condition": {
              "StringLike": {
                    "aws:RequestTag/Project": "*",
                    "aws:RequestTag/CostCenter": "*",
                    "aws:RequestTag/Department": "*"
                },
                "StringEquals": {"sts:ExternalId": "Example987"}
            }
        },
        {
            "Sid": "AllowPassSessionTagsAndTransitive",
            "Effect": "Allow",
            "Action": "sts:TagSession",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/test-session-tags"},
            "Condition": {
                "StringLike": {
                    "aws:RequestTag/Project": "*",
                    "aws:RequestTag/CostCenter": "*"
                },
                "StringEquals": {
                    "aws:RequestTag/Department": [
                        "Engineering",
                        "Marketing"
                    ]
                },
                "ForAllValues:StringEquals": {
                    "sts:TransitiveTagKeys": [
                        "Project",
                        "Department"
                    ]
                }
            }
        }
    ]
}
```

**このポリシーで行うこと**
+ `AllowIamUserAssumeRole` ステートメントは、ポリシーがアタッチされているロールを引き受けることを `test-session-tags` ユーザーに許可します。そのユーザーがロールを引き受けるときは、必要なセッションタグと[外部 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) を渡す必要があります。
  + このステートメントの最初の条件ブロックでは、ユーザーは、`Project`、`CostCenter`、および `Department` セッションタグを渡す必要があります。このステートメントではタグの値は重要ではないため、タグ値にはワイルドカード (\$1) を使用しました。このブロックでは、ユーザーは少なくともこれら 3 つのセッションタグを渡します。それ以外の場合は、このオペレーションは失敗します。ユーザーは追加のタグを渡すことができます。
  + 2 番目の条件ブロックでは、ユーザーは値 `Example987` とともに[外部 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) を渡す必要があります。
+ `AllowPassSessionTagsAndTransitive` ステートメントは、`sts:TagSession` アクセス許可のみのアクションを許可します。このアクションは、ユーザーがセッションタグを渡す前に許可する必要があります。ポリシーに 2 番目のステートメントを含まない最初のステートメントが含まれている場合、ユーザーはロールを引き受けることができません。
  + このステートメントの最初の条件ブロックでは、ユーザーは `CostCenter` および `Project` セッションタグに任意の値を渡すことができます。これを行うには、ポリシーのタグ値にワイルドカード (\$1) を使用します。この場合、[StringLike](reference_policies_elements_condition_operators.md#Conditions_String) 条件演算子を使用する必要があります。
  + 2 番目の条件ブロックでは、ユーザーは、`Department` セッションタグの `Engineering` または `Marketing` 値のみを渡すことができます。
  + 3 番目の条件ブロックは、推移的として設定できるタグの最大セットを一覧表示します。ユーザーは、サブセットを設定するか、タグを推移的として設定しないかを選択できます。追加のタグを推移的として設定することはできません。`"Null":{"sts:TransitiveTagKeys":"false"}` を含む別の条件ブロックを追加することで、タグの少なくとも 1 つを推移的として設定するよう要求できます。

## AssumeRole を使用したセッションタグの受け渡し
<a name="id_session-tags_adding-assume-role"></a>

`AssumeRole` オペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。IAM ユーザーまたはロールの認証情報を使用して `AssumeRole` を呼び出すことができます。ロールを引き受けるときにセッションタグを渡すには、`--tags` AWS CLI オプションまたは `Tags` AWS API パラメータを使用します。

タグを推移的として設定するには、`--transitive-tag-keys` AWS CLI オプションまたは `TransitiveTagKeys` AWS API パラメータを使用します。推移的なタグは、ロールの連鎖中も保持されます。詳細については、「[セッションタグを使用したロールの連鎖](#id_session-tags_role-chaining)」を参照してください。

次の例は、`AssumeRole` を使用するリクエストの例を示しています。この例では、`my-role-example` ロールを引き受けるときに `my-session` という名前のセッションを作成します。セッションタグのキーバリューペア `Project` = `Automation`、`CostCenter` = `12345`、および `Department` = `Engineering` を追加します。また、`Project` タグと `Department` のタグのキーを指定して、推移的タグとして設定します。セッションタグごとに 1 つの値を渡す必要があります。AWS STS は、複数値を持つセッションタグをサポートしていません。

**Example AssumeRole CLI リクエストの例**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/my-role-example \
--role-session-name my-session \
--tags Key=Project,Value=Automation Key=CostCenter,Value=12345 Key=Department,Value=Engineering \
--transitive-tag-keys Project Department \
--external-id Example987
```

## AssumeRoleWithSAML を使用したセッションタグの受け渡し
<a name="id_session-tags_adding-assume-role-saml"></a>

`AssumeRoleWithSAML` オペレーションは、SAML ベースのフェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。SAML ベースのフェデレーションを使用して AWS マネジメントコンソール にアクセスする方法の詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](id_roles_providers_enable-console-saml.md)」を参照してください。AWS CLI または AWS API アクセスの詳細については、「[SAML 2.0 フェデレーション](id_roles_providers_saml.md)」を参照してください。Active Directory ユーザーの SAML フェデレーションを設定するチュートリアルについては、AWS セキュリティブログの「[Active Directory フェデレーションサービスを使用した AWS フェデレーション認証 (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/)」を参照してください。

管理者は、企業ディレクトリのメンバーに AWS STS `AssumeRoleWithSAML` オペレーションを使用しての AWS フェデレーションを許可できます。これを行うには、以下のタスクを完了する必要があります。

1. [ネットワークを AWS の SAML プロバイダーとして設定する](id_roles_providers_saml_3rd-party.md)

1. [IAM で SAML プロバイダーを作成するには](id_roles_providers_create_saml.md)

1. [SAML 2.0 フェデレーション用のロールを作成する (コンソール)](id_roles_create_for-idp_saml.md)

1. [SAML IdP の設定を終了し、SAML 認証レスポンスのアサーションを作成する](id_roles_providers_create_saml_assertions.md)

AWS には、ID ソリューションを使用したセッションタグのエンドツーエンドのエクスペリエンスを認定したパートナーが含まれます。これらの ID プロバイダーを使用してセッションタグを設定する方法については、「[サードパーティーの SAML ソリューションプロバイダーを AWS に統合する](id_roles_providers_saml_3rd-party.md)」を参照してください。

SAML 属性をセッションタグとして渡すには、`Attribute` 属性を `Name` に設定した `https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}` 要素を含めます。`AttributeValue` 要素を使用して、タグの値を指定します。セッションタグごとに個別の `Attribute` 要素を含めます。

たとえば、次の ID 属性をセッションタグとして渡すとします。
+ `Project:Automation`
+ `CostCenter:12345`
+ `Department:Engineering`

これらの属性を渡すには、SAML アサーションに以下の要素を含めます。

**Example SAML アサーションのスニペットの例**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project">
  <AttributeValue>Automation</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter">
  <AttributeValue>12345</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department">
  <AttributeValue>Engineering</AttributeValue>
</Attribute>
```

上記のタグを推移的として設定するには、`Name` 属性を `https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys` に設定した別の `Attribute` 要素を含めます。推移的なタグは、ロールの連鎖中も保持されます。詳細については、「[セッションタグを使用したロールの連鎖](#id_session-tags_role-chaining)」を参照してください。

`Project` タグと `Department` タグを推移的として設定するには、次の多値属性を使用します。

**Example SAML アサーションのスニペットの例**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <AttributeValue>Project</AttributeValue>
  <AttributeValue>Department</AttributeValue>
</Attribute>
```

## AssumeRoleWithWebIdentity を使用したセッションタグの受け渡し
<a name="id_session-tags_adding-assume-role-idp"></a>

`AssumeRoleWithWebIdentity` オペレーションは、OpenID Connect (OIDC) 準拠のフェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。AWS マネジメントコンソール アクセスにウェブ ID フェデレーションを使用する方法の詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。

OpenID Connect (OIDC) からセッションタグを渡すには、`AssumeRoleWithWebIdentity` リクエストを送信するときに JSON Web Token (JWT) にセッション タグを含める必要があります。OIDC トークンとクレームの詳細については、「Amazon Cognito 開発者ガイド」の「[ユーザープールでのトークンの使用](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)」を参照してください。

AWS は、JWT にセッションタグを含めるための 2 つのクレーム形式をサポートしています。
+ ネストされたクレーム形式
+ フラット化されたクレーム形式

### ネストされたクレーム形式
<a name="id_session-tags_adding-assume-role-idp-nested-format"></a>

ネストされたクレーム形式は、JWT の `https://aws.amazon.com/tags` 名前空間内の構造を使用します。この形式では、次のようになります。
+ プリンシパルタグは、`principal_tags` キーの下にネストされたオブジェクトとして表されます。
+ 各プリンシパルタグは 1 つの文字列値です。
+ 一時的なタグキーは、`transitive_tag_keys` キーの下の配列で表されます。
+ `principal_tags` と の両方 `transitive_tag_keys` が`https://aws.amazon.com/tags` 名前空間の下にネストされます。

次の例は、ネストされたオブジェクト形式を使用したデコードされた JWT を示しています。

**Example ネストされたクレーム形式を使用したデコードされた JSON Web Token の例**  

```
{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags": {
        "principal_tags": {
            "Project": ["Automation"],
            "CostCenter": ["987654"],
            "Department": ["Engineering"]
        },
        "transitive_tag_keys": [
            "Project",
            "CostCenter"
        ]
    }
}
```

### フラット化されたクレーム形式
<a name="id_session-tags_adding-assume-role-idp-flattened-format"></a>

フラット化されたクレーム形式は、Microsoft Entra ID など、JWT クレームでネストされたオブジェクトをサポートしていない ID プロバイダーと互換性があります。この形式では、次のようになります。
+ プリンシパルタグは、プレフィックス `https://aws.amazon.com/tags/principal_tags/` を持つ個別のクレームとして表されます。
+ 各プリンシパルタグは 1 つの文字列値です。
+ トランジティブタグキーは、プレフィックス`https://aws.amazon.com/tags/transitive_tag_keys` を持つ文字列の配列として 1 つのクレームで表されます。

次に、平坦化されたクレーム形式を使用して、同じ情報がどのように表されるかを見てみましょう。

**Example フラット化されたクレーム形式を使用したデコードされた JSON Web Token の例**  

```
{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags/principal_tags/Project": "Automation",
    "https://aws.amazon.com/tags/principal_tags/CostCenter": "987654",
    "https://aws.amazon.com/tags/principal_tags/Department": "Engineering",
    "https://aws.amazon.com/tags/transitive_tag_keys": [
        "Project",
        "CostCenter"
    ]
}
```

デコードされた両方の JWT 例は、`Project`、`CostCenter`、および `Department` セッション タグを使用した `AssumeRoleWithWebIdentity` への呼び出しを示しています。どちらのトークンも、 `Project` と `CostCenter` タグをトランジティブに設定します。推移的なタグは、ロールの連鎖中も保持されます。詳細については、「[セッションタグを使用したロールの連鎖](#id_session-tags_role-chaining)」を参照してください。

フラット化されたクレーム形式は、ネストされたクレーム形式と同じ結果を実現しますが、タグにはフラット化された構造を使用します。これにより、ネストされた JSON オブジェクトが JWT クレームでサポートされていない環境にセッションタグを含めることができます。どちらの形式を使用する場合も、ID プロバイダーが適切なクレーム構造でトークンを発行するように設定されていることを確認します。 は両方のクレーム形式 AWS をサポートしているため、ID プロバイダーの特定の要件に最も適したものを選択できます。

## GetFederationToken を使用したセッションタグの受け渡し
<a name="id_session-tags_adding-getfederationtoken"></a>

`GetFederationToken` では、ユーザーをフェデレートできます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。フェデレーティッドユーザーセッションにタグを追加するには、`--tags` AWS CLI オプションまたは `Tags` AWS API パラメータを使用します。`GetFederationToken` を使用する場合、一時的な資格情報を使用してロールを引き受けることができないため、セッションタグを推移的なものとして設定することはできません。この場合、ロールチェーンを使用することはできません。

次の例は、`GetFederationToken` を使用したレスポンスのサンプルです。この例では、トークンをリクエストするときに、`my-fed-user` という名前のセッションを作成します。セッションタグのキーバリューペア `Project` = `Automation` と `Department` = `Engineering` を追加します。

**Example GetFederationToken の CLI リクエストの例**  

```
aws sts get-federation-token \
--name my-fed-user \
--tags key=Project,value=Automation key=Department,value=Engineering
```

`GetFederationToken` オペレーションによって返される一時的な認証情報を使用すると、セッションのプリンシパルタグには、ユーザーのタグと渡されたセッションタグが含まれます。

## セッションタグを使用したロールの連鎖
<a name="id_session-tags_role-chaining"></a>

1 つのロールを引き受け、一時的な認証情報を使用して別のロールを引き受けることができます。セッション間で続行できます。これを[ロールの連鎖](id_roles.md#iam-term-role-chaining)と呼びます。ロールを引き受けるときにセッションタグを渡すと、キーを推移的に設定できます。これにより、これらのセッションタグがロールチェーン内の後続のセッションに渡されるようになります。ロールタグを推移的として設定することはできません。これらのタグを後続のセッションに渡すには、セッションタグとして指定します。

**注記**  
推移的なタグは、ロールの連鎖中は保持され、ロールの信頼ポリシーの評価後に一致する `ResourceTag` の値を置き換えます。

次の例は、AWS STS がセッションタグ、推移タグ、およびロールタグをロールチェーン内の後続のセッションに渡す方法を示しています。

次のロールの連鎖シナリオ例では、AWS CLI で IAM ユーザーのアクセスキーを使用して `Role1` という名前のロールを引き受けます。次に、結果のセッション認証情報を使用して、`Role2` という名前の 2 番目のロールを引き受けます。次に、2 番目のセッション認証情報を使用して、`Role3` という 3 番目のロールを引き受けることができます。これらのリクエストは、3 つの個別のオペレーションとして発生します。各ロールはすでに IAM でタグ付けされています。また、リクエストごとに、追加のセッションタグを渡します。

![\[ロールの連鎖\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/session-tags-chaining-simple.png)


ロールをチェーン化すると、以前のセッションのタグが後のセッションにも確実に保持されるようにできます。`assume-role` CLI コマンドを使用してこれを行うには、タグをセッションタグとして渡し、タグを推移的に設定する必要があります。タグ `Star` = `1` をセッションタグとして渡します。タグ `Heart` = `1` はロールにアタッチされ、セッションの使用時にプリンシパルタグとして適用されます。ただし、`Heart` = `1` タグを自動的に 2 番目または 3 番目のセッションに渡すこともできます。これを行うには、セッションタグとして手動で含めます。作成されるセッションプリンシパルタグには、これらのタグの両方が含まれ、推移的として設定されます。

![\[ロールチェーン内の最初のロールを仮定する\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/session-tags-chaining-role1.png)


このリクエストは、次の AWS CLI コマンドを使用して実行します。

**Example AssumeRole CLI リクエストの例**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role1 \
--role-session-name Session1 \
--tags Key=Star,Value=1 Key=Heart,Value=1 \
--transitive-tag-keys Star Heart
```

次に、そのセッションの認証情報を使用して、`Role2` を引き受けます。タグ `Sun` = `2` は 2 番目のロールにアタッチされ、2 番目のセッションを使用するときにプリンシパルタグとして適用されます。`Star` タグと `Heart` タグは、最初のセッションで推移的なセッションタグから継承されます。2 番目のセッションの結果となるプリンシパルタグは、`Heart` = `1`、`Star` = `1`、および `Sun` = `2` です。`Heart` および `Star` は引き続き推移的です。`Role2` にアタッチされた `Sun` タグは、セッションタグではないため、推移的としてマークされていません。今後のセッションはこのタグを継承しません。

![\[ロールチェーンの 2 番目のロールを引き受ける\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/session-tags-chaining-role2.png)


この 2 番目のリクエストは、次の AWS CLI コマンドを使用して実行します。

**Example AssumeRole CLI リクエストの例**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role2 \
--role-session-name Session2
```

次に、2 番目のセッション認証情報を使用して、`Role3` を引き受けます。3 番目のセッションのプリンシパルタグは、新しいセッションタグ、継承された推移的セッションタグ、およびロールタグから取得されます。2 番目のセッションの `Heart` = `1` タグと `Star` = `1` タグは最初のセッションでの推移的なタグから継承されました。`Sun` = `2` セッションタグを渡そうとすると、オペレーションは失敗します。継承された `Star` = 1 セッションタグは、ロールの `Star` = `3` タグを上書きします。ロールの連鎖では、ロールの信頼ポリシーの評価後に、推移的なタグの値によって `ResourceTag` の値に一致するロールがオーバーライドされます。この例では、この例では、`Role3` がロール信頼ポリシーで `Star` を `ResourceTag` として使用し、呼び出し元のロールセッションからの推移的なタグ値に `ResourceTag` 値を設定する場合。ロールの `Lightning` タグは 3 番目のセッションにも適用され、推移的として設定されません。

![\[ロールチェーンの 3 番目のロールを引き受ける\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/images/session-tags-chaining-role3.png)


3 番目のリクエストを実行するには、次の AWS CLI コマンドを使用します。

**Example AssumeRole CLI リクエストの例**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role3 \
--role-session-name Session3
```

## ABAC でのセッションタグの使用
<a name="id_session-tags_using-abac"></a>

属性ベースのアクセスコントロール (ABAC) は、タグ属性に基づいてアクセス許可を定義する認可戦略です。

企業ユーザー ID に SAML ベースの ID プロバイダー (IdP) を使用している場合は、セッションタグを AWS に渡すように アサーションを設定できます。たとえば、企業のユーザーIDの場合、従業員が AWS にフェデレーションすると、AWS は結果のプリンシパルに属性を適用します。その後、ABAC を使用して、これらの属性に基づいてアクセス許可を許可または拒否できます。詳細については、「[IAM チュートリアル: ABAC で SAML セッションタグを使用する](tutorial_abac-saml.md)」を参照してください。

IAM Identity Center で ABAC を使用する方法の詳細については、「AWS IAM アイデンティティセンター ユーザーガイド」の「[アクセスコントロールの属性](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributesforaccesscontrol.html)」を参照してください。

## CloudTrail でのセッションタグの表示
<a name="id_session-tags_ctlogs"></a>

AWS CloudTrail を使用して、ロールを引き受けるか、ユーザーをフェデレートするために行われたリクエストを表示できます。CloudTrail ログファイルには、引き受けたロールまたはフェデレーティッドユーザーセッションのプリンシパルタグに関する情報が含まれます。詳細については、「[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)」を参照してください。

たとえば、AWS STS `AssumeRoleWithSAML` リクエストを行い、セッションタグを渡し、これらのタグを推移的として設定するとします。CloudTrail ログには、次の情報があります。

**Example AssumeRoleWithSAML CloudTrail ログの例**  

```
    "requestParameters": {
        "sAMLAssertionID": "_c0046cEXAMPLEb9d4b8eEXAMPLE2619aEXAMPLE",
        "roleSessionName": "MyRoleSessionName",
        "principalTags": {
            "CostCenter": "987654",
            "Project": "Unicorn"
        },
        "transitiveTagKeys": [
            "CostCenter",
            "Project"
        ],
        "durationSeconds": 3600,
        "roleArn": "arn:aws:iam::123456789012:role/SAMLTestRoleShibboleth",
        "principalArn": "arn:aws:iam::123456789012:saml-provider/Shibboleth"
    },
```

次の CloudTrail ログ例を参照して、セッションタグを使用するイベントを表示できます。
+ [CloudTrail ログファイル内の AWS STS ロール連鎖 API イベントの例](cloudtrail-integration.md#stscloudtrailexample-assumerole)
+ [CloudTrail ログファイル内の SAML AWS STS API イベントの例](cloudtrail-integration.md#stscloudtrailexample_saml)
+ [CloudTrail ログファイル内の OIDC AWS STS API イベントの例](cloudtrail-integration.md#stscloudtrailexample_web-identity)