

# IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任
<a name="tutorial_cross-account-with-roles"></a>

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

このチュートリアルでは、ロールを使用して、**ターゲット**と**ソース**と呼ばれる、さまざまな AWS アカウント にあるリソースへのアクセスを委任する方法を説明します。特定のアカウントにあるリソースを別のアカウントのユーザーと共有します。このようにクロスアカウントアクセスを設定することで、お客様はアカウントごとに IAM ユーザーを作成する必要がなくなります。また、ユーザーは、異なる AWS アカウント のアカウントのリソースにアクセスするために、あるアカウントからサインアウトして別のアカウントにサインインする必要がなくなります。ロールを設定した後、AWS マネジメントコンソール、AWS CLI、API からロールを使用する方法について説明します。

このチュートリアルでは、**ターゲット**アカウントが、さまざまなアプリケーションやチームがアクセスするアプリケーションデータを管理します。各アカウントでは、Amazon S3 バケットにアプリケーション情報を保存します。IAM ユーザーは、**ソース**アカウントで管理します。ソースアカウントには、**デベロッパー**と**アナリスト**の 2 つの IAM ユーザーロールがあります。デベロッパーとアナリストは、**ソース**アカウントを使用して、複数のマイクロサービスによって共有されるデータを生成します。どちらのロールにも、ソースアカウントで作業し、そこにあるリソースにアクセスするための許可が付与されています。デベロッパーは、**ターゲット**アカウントの共有データを随時更新する必要があります。デベロッパーは、このデータを `amzn-s3-demo-bucket-shared-container` という Amazon S3 バケットに保存します。

このチュートリアルを終了すると、次のようになります。
+ **ターゲット**アカウントで特定のロールを引き受けることができる**ソース**アカウント (信頼されたアカウント) のユーザー。
+ 特定の Amazon S3 バケットへのアクセスを許可される**ターゲット**アカウント (信頼するアカウント) のロール。
+ **ターゲット**アカウントの `amzn-s3-demo-bucket-shared-container` バケット。

デベロッパーは、AWS マネジメントコンソール でロールを使用して**ターゲット**アカウントの `amzn-s3-demo-bucket-shared-container` バケットにアクセスできます。さらに、ロールにより提供される一時的な認証情報によって認証された API コールを使用してバケットにアクセスすることもできます。アナリストによるロールの使用の類似の試みは失敗します。

このワークフローに 3 つの基本的なステップがあります:

**[ターゲットアカウントにロールを作成する](#tutorial_cross-account-with-roles-1)**  
まず、AWS マネジメントコンソール を使用して**ターゲット**アカウント (ID 番号 999999999999) と**ソース**アカウント (ID 番号 111111111111) との間の信頼を確立します。まず、UpdateData という名前の IAM ロールを作成します。ロールの作成時に、**ソース**アカウントを信頼されたエンティティとして定義し、信頼されたユーザーが `amzn-s3-demo-bucket-shared-container` バケットを更新することを許可する許可ポリシーを指定します。

**[ロールにアクセス許可を付与する](#tutorial_cross-account-with-roles-2)**  
このセクションでは、ロールポリシーを変更して、アナリストが `UpdateData` ロールにアクセスするのを拒否します。このシナリオではアナリストに PowerUser アクセス許可があるため、ロールの使用を明示的に拒否する必要があります。

**[ロールを切り換えてアクセスをテストする](#tutorial_cross-account-with-roles-3)**  
最後にデベロッパーとして、`UpdateData` ロールを使用して**ターゲット**アカウントの `amzn-s3-demo-bucket-shared-container` バケットを更新します。AWS コンソール、AWS CLI、API を使用してロールにアクセスする方法について説明します。

## 考慮事項
<a name="tutorial_cross-account-with-roles-considerations"></a>

IAM ロールを使用して AWS アカウント 間でリソースアクセスを委任する前に、次を考慮することが重要です。
+ AWS アカウントのルートユーザー としてサインインしているときに、ロールを切り替えることはできません。
+ IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。例えば、標準 `aws` パーティションの米国西部 (北カリフォルニア)と、`aws-cn` パーティションの中国 (北京) にアカウントがあるとします。中国 (北京) アカウントの Amazon S3 リソースベースのポリシーを使用して、標準 `aws` アカウントのユーザーにアクセスを許可することはできません。
+ AWS IAM アイデンティティセンター を使用すると、Security Assertion Markup Language (SAML) を使用して、外部 AWS アカウント (AWS Organizations の外部のアカウント) のシングルサインオン (SSO) を容易にすることができます。詳細については、「[ Integrate external AWS アカウント into AWS IAM アイデンティティセンター for central access management with independent billing using SAML 2.0](https://community.aws/content/2dIMI8N7w7tGxbE0KQMrkSBfae4/aws-iam-identity-center-integration-with-external-aws-accounts-for-independent-billing?lang=en)」を参照してください。
+ Amazon EC2 インスタンスや AWS Lambda 関数などの AWS リソースにロールを関連付けることができます。詳細については、「[AWS サービスにアクセス許可を委任するロールを作成する](id_roles_create_for-service.md)」を参照してください。
+ アプリケーションが別の AWS アカウント でロールを引き受けるようにする場合は、AWS SDK を使用してクロスアカウントロールを引き受けることができます。詳細については、「AWS SDK およびツールのリファレンスガイド」の「[Authentication and access](https://docs.aws.amazon.com//sdkref/latest/guide/access.html)」を参照してください。
+ AWS マネジメントコンソール を使ったロールの切り替えは、`ExternalId` を必要としないアカウントでのみ機能します。たとえば、アカウントへのアクセス権を第三者に付与し、アクセス許可ポリシーの `Condition` 要素に `ExternalId` を要求するとします。その場合、第三者は AWS API またはコマンドラインツールを使用してのみ、お客様のアカウントにアクセスできます。第三者は、`ExternalId` の値を指定する必要があるため、コンソールを使用できません。このシナリオの詳細については、「AWS マネジメントコンソール」、および「[第三者が所有する AWS アカウント へのアクセス](id_roles_common-scenarios_third-party.md) セキュリティブログ」の「[How to enable cross account access to the AWS](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)」を参照してください。

## 前提条件
<a name="tutorial_cross-account-with-roles-prereqs"></a>

このチュートリアルでは、以下を実行済みであることを前提としています。
+ 使用できる AWS アカウント を、それぞれ**ソース**アカウントと**ターゲット**アカウントを表す **2** つのアカウントに分けます。
+ **ソース**アカウントのユーザーとロールは次のように作成および構成されます。  
****    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+ **ターゲット**アカウントでユーザーを作成する必要はありません。
+ **ターゲット**アカウントで作成された Amazon S3 バケット。このチュートリアルでは `amzn-s3-demo-bucket-shared-container` と呼びますが、S3 バケット名はグローバルに一意である必要があるため、別の名前のバケットを使用する必要があります。

## ターゲットアカウントにロールを作成する
<a name="tutorial_cross-account-with-roles-1"></a>

ある AWS アカウント のユーザーに別の AWS アカウント のリソースへのアクセスを許可できます。このチュートリアルでは、誰がアクセスできるか、およびそのロールに切り替えるユーザーにどのような許可を付与するかを定義するロールを作成することでこれを実行します。

チュートリアルのこのステップでは、**ターゲット**アカウントにロールを作成し、**ソース**アカウントを信頼されたエンティティとして指定します。また、ロールのアクセス許可を `amzn-s3-demo-bucket-shared-container` バケットでの読み書き専用に制限します。ロールを使用するアクセス許可が付与されるすべてのユーザーは、`shared-container` バケットに対する読み取りと書き込みを実行できます。

ロールを作成する前に、**ソース** AWS アカウント のアカウント ID が必要です。各 AWS アカウント には、固有の識別子であるアカウント ID が割り当てられています。

**ソース AWS アカウント ID を取得するには**

1. **ソース**アカウントの管理者として AWS マネジメントコンソール にサインインし、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。

1. IAM コンソールで、右上のナビゲーションバーのユーザー名を選択します。通常は ***username*@*account\$1ID\$1number\$1or\$1alias*** のように表示されます。

   このシナリオでは、アカウント ID 111111111111 を**ソース**アカウントとして使用します。ただし、テスト環境でこのシナリオを使用する場合は、有効なアカウント ID を使用する必要があります。

**ソースアカウントで使用できるロールをターゲットアカウントで作成するには**

1. **ターゲット**アカウントの管理者として AWS マネジメントコンソール にサインインし、IAM コンソールを開きます。

1. ロールを作成する前に、ロールに必要なアクセス許可を定義する管理ポリシーを準備します。後の手順で、このポリシーをロールにアタッチします。

   `amzn-s3-demo-bucket-shared-container` バケットの読み込みおよび書き込みのアクセスを設定します。AWS には Amazon S3 管理ポリシーがありますが、単一の Amazon S3 バケットへの読み取りおよび書き込みアクセスを提供するポリシーはありません。代わりにポリシーを自作することができます。

   ナビゲーションペインで、[**Policies (ポリシー)**] を選択し、[**Create Policy (ポリシーの作成)**] を選択します。

1. [**JSON**] タブを選択し、以下の JSON ポリシードキュメントからテキストをコピーします。**[JSON]** (JSON) テキストボックスにこのテキストを貼り付け、リソース ARN (`arn:aws:s3:::shared-container`) を、Amazon S3 バケットの実際の ARN に置き換えます。

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

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "s3:ListAllMyBuckets",
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": [
           "s3:ListBucket",
           "s3:GetBucketLocation"
          ],
         "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container"
       },
       {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject",
           "s3:PutObject",
           "s3:DeleteObject"
         ],
         "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-shared-container/*"
       }
     ]
   }
   ```

------

   `ListAllMyBuckets` アクションは、リクエストの認証済み送信者によって所有されているすべてのバケットを一覧表示するアクセス許可を付与します。`ListBucket` アクセス許可は、ユーザーに `amzn-s3-demo-bucket-shared-container` バケットにあるオブジェクトの閲覧を許可します。`GetObject`、`PutObject`、`DeleteObject` アクセス許可によって、ユーザーは `amzn-s3-demo-bucket-shared-container` バケットの内容を表示、更新、および削除できます。
**注記**  
いつでも **[ビジュアル]** と **[JSON]** エディタオプションを切り替えることができます。ただし、**[Visual]** エディタで **[次へ]** に変更または選択した場合、IAM はポリシーを再構成して visual エディタに合わせて最適化することがあります。詳細については、「[ポリシーの再構成](troubleshoot_policies.md#troubleshoot_viseditor-restructure)」を参照してください。

1. **[確認および作成]** ページで、ポリシー名として「**read-write-app-bucket**」と入力します。ポリシーによって割り当てられたアクセス許可を確認し、**[ポリシーの作成]** を選択して作業を保存します。

   新しいポリシーが管理ポリシーの一覧に表示されます。

1. ナビゲーションペインで **[ロール]** を選択した後、**[ロールの作成]** を選択します。

1. **[AWS アカウント]** のロールタイプを選択します。

1. **[アカウント ID]** で、**ソース**アカウント ID を入力します。

   このチュートリアルでは、**ソース**アカウントにサンプルのアカウント ID **111111111111** を使用します。有効なアカウント ID を使用してください。使用しているアカウント ID が無効 ( **111111111111** など) の場合は、IAM で新しいロールを作成することはできません。

   現時点では、ロールを引き受けるために、外部 ID や多要素認証 (MFA) は必要ありません。これらのオプションは選択していない状態にしておきます。詳細については、「[IAM の AWS 多要素認証](id_credentials_mfa.md)」を参照してください。

1. [**Next: Permissions**] (次へ: アクセス許可) を選択して、そのロールに関連するアクセス許可を設定します。

1. 以前に作成したポリシーの横にあるチェックボックスをオンにします。
**ヒント**  
**[Filter]** (フィルター) で、**[Customer managed]** (カスタマー管理ポリシー) を選択してリストをフィルター処理し、自分で作成したポリシーのみが含まれるようにします。これにより、AWS が作成したポリシーが非表示になり、必要なポリシーを見つけるのが簡単になります。

   その後、**[Next]** を選択します。

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

1. (オプション) **[説明]** には、新しいロールの説明を入力します。

1. ロールを確認したら、[**ロールの作成**] を選択します。

    

   ロールのリストで、`UpdateData` ロールが表示されます。

ここで、ロールに固有の識別子である Amazon リソースネーム (ARN) を取得しなければいけません。ソースアカウントでデベロッパーのロールを変更する際には、ターゲットアカウントからロール ARN を指定して、許可を付与または拒否します。

**UpdateData の ARN を取得するには**

1. IAM コンソールのナビゲーションペインで **[ロール]** を選択します。

1. ロールのリストで、[`UpdateData`] ロールを選択します。

1. 詳細ペインの [**Summary (概要)**] セクションで、[**ロール ARN**] の値をコピーします。

   ターゲットアカウントのアカウント ID が 999999999999 であるため、ロール ARN は `arn:aws:iam::999999999999:role/UpdateData` となります。ターゲットアカウントでは、実際の AWS アカウント ID を指定してください。

この時点で、**ターゲット**アカウントと**ソース**アカウントの間に信頼が確立されています。そのためには、**ソース**アカウントを信頼されたプリンシパルとして識別するロールを**ターゲット**アカウントに作成します。また、`UpdateData` ロールに切り替えるユーザーが何を実行できるかについても定義しました。

次に、デベロッパーロールの許可を変更します。

## ロールにアクセス許可を付与する
<a name="tutorial_cross-account-with-roles-2"></a>

この時点で、アナリストとデベロッパーの両方には、**ソース**アカウントのデータを管理できるようにする許可が付与されています。ロールの切り替えを許可するアクセス許可を追加するには、この必要な手順に従ってください。

**UpdateData ロールに切り替えることを許可するようにデベロッパーロールを変更するには**

1. **ソース**アカウントの管理者としてサインインし、IAM コンソールを開きます。

1. **[ロール]**、**[デベロッパー]** の順に選択します。

1. [**アクセス許可**]タブを選択し、[**アクセス許可の追加**]を選択してから、[**インラインポリシーの作成]**を選択します。

1. **JSON** タブを選択します。

1. 次のポリシーステートメントを追加して、ターゲットアカウントの `UpdateData` ロールに対する `AssumeRole` アクションを許可します。必ず `Resource` 要素の *DESTINATION-ACCOUNT-ID* を、ターゲットアカウントの実際の AWS アカウント ID に変更してください。

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

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRole",
           "Resource": "arn:aws:iam::111122223333:role/UpdateData"
       }
   }
   ```

------

   `Allow` エフェクトは、デベロッパーグループがターゲットアカウントの `UpdateData` ロールにアクセスすることを明示的に許可します。どのデベロッパーがこのロールにアクセスしようとしても成功します。

1. **[ポリシーの確認]** を選択します。

1. **allow-assume-S3-role-in-destination** などの**名前**を入力します。

1. [**Create policy**] (ポリシーの作成) を選択します。

ほとんどの環境では、次の手順は必要ありません。ただし、PowerUserAccess アクセス許可を使用している場合、グループによってはロールを切り替えることができます。次の手順は、ロールを引き受けることができないようにアナリストグループに `"Deny"` 許可を追加する方法を示しています。お客様の環境でこの手順が必要ない場合は、追加しないことをお勧めします。`"Deny"` アクセス許可を追加すると、アクセス許可の全体的な状況が複雑になり、管理しづらくなります。`"Deny"` アクセス許可は、他に良いオプションがない場合のみ使用してください。

**アナリストのロールを変更して、`UpdateData` ロールを引き受けるための許可を拒否する**

1. **[ロール]** を選択し、**[アナリスト]** を選択します。

1. [**アクセス許可**]タブを選択し、[**アクセス許可の追加**]を選択してから、[**インラインポリシーの作成]**を選択します。

1. **JSON** タブを選択します。

1. 次のポリシーステートメントを追加して、`AssumeRole` ロールに対する `UpdateData` アクションを拒否します。必ず `Resource` 要素の *DESTINATION-ACCOUNT-ID* を、ターゲットアカウントの実際の AWS アカウント ID に変更してください。

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

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Deny",
           "Action": "sts:AssumeRole",
           "Resource": "arn:aws:iam::111122223333:role/UpdateData"
       }
   }
   ```

------

   `Deny` エフェクトは、アナリストグループがターゲットアカウントの `UpdateData` ロールにアクセスすることを明示的に拒否します。そのロールにアクセスしようとするアナリストは、アクセス拒否のメッセージを受け取ります。

1. **[ポリシーの確認]** を選択します。

1. **deny-assume-S3-role-in-destination** のような**名前**を入力します。

1. [**Create policy**] (ポリシーの作成) を選択します。

これで、デベロッパーロールは、ターゲットアカウントの `UpdateData` ロールを使用するための許可を持つようになりました。アナリストロールは、`UpdateData` ロールを使用できません。

次に、デベロッパーの David がターゲットアカウントの `amzn-s3-demo-bucket-shared-container` バケットにアクセスする方法について説明します。David は、AWS マネジメントコンソール、AWS CLI、または AWS API からバケットにアクセスできます。

## ロールを切り換えてアクセスをテストする
<a name="tutorial_cross-account-with-roles-3"></a>

このチュートリアルの最初の 2 つのステップを完了した時点で、**ターゲット**アカウントのリソースに対するアクセス許可を付与するロールがあります。また、**ソース**アカウントには 1 つのロールがあり、ユーザーはそのロールの使用を許可されています。このステップでは、AWS マネジメントコンソール、AWS CLI、および AWS API のロールへの切り替えについて説明します。

IAM ロールの使用時に発生する可能性がある一般的な問題のヘルプについては、「[IAM ロールをトラブルシューティングする](troubleshoot_roles.md)」を参照してください。

### ロールの切り替え (コンソール)
<a name="switch-tutorial_cross-account-with-roles"></a>

David が AWS マネジメントコンソール の**ターゲット**アカウントのデータを更新する必要がある場合は、**[ロールの切り替え]** を使用して更新できます。アカウント ID またはエイリアスとロール名を指定すれば、David のアクセス権限は、ロールによって許可されているものに直ちに切り替わります。次に、David はコンソールを使用して `amzn-s3-demo-bucket-shared-container` バケットを使用できますが、**ターゲット**の他のリソースは一切使用できません。David がロールを使用中に、**ソース**アカウントのパワーユーザー特権を使用することもできません。これは、同時に有効にできるアクセス許可のセットは 1 つのみであるためです。

David が IAM で **[Switch Role]** (ロールの切り替え) ページに移動するには、2 つの方法があります。
+ David は事前定義されたロールの切り替え設定を指すリンクを管理者から受け取ります。リンクは [**ロールの作成**] ウィザードの最終ページ、またはクロスアカウントロールの [**ロールの概要**] ページで管理者に提供されます。このリンクを選択すると、[**ロールの切り替え**] ページに移動します。このページには、[**Account ID (アカウント ID)**] および [**ロール名**] フィールドがすでに入力されています。David は、**[ロールの切り替え]** ボタンを選択するだけです。
+ 管理者はメールでリンクを送信しませんが、代わりに [**Account ID (アカウント ID)**] 番号および [**ロール名**] の値を送信します。役割を切り替えるには、デビッドは手動でその値を入力する必要があります。これを次の手順に示します。

**ロールを引き受けるには**

1. David は、**ソース**アカウントで通常のユーザーを使用して AWS マネジメントコンソール にサインインします。

1. 管理者がユーザーに E メールするリンクを選択します。これにより、David は、**[ロールの切り替え]** ページに移動されます。このページには、アカウント ID、エイリアス、およびロール名情報がすでに入力されています。

   -または-

   David は、ナビゲーションバーのユーザー名 (ID メニュー) を選択してから、[**Switch Roles**.] (ロールの切り替え) を選択します。

   David がこの方法で初めて [Switch Role] (スイッチロール) ページにアクセスする場合は、初回アクセス用の **[Switch Role]** (スイッチロール) ページが表示されます。このページでは、ロールを切り替えて AWS アカウント 全体にわたるリソースを管理できるようにする方法についての追加情報が説明されます。David がこの手順の残りを完了するには、このページの **[Switch Role]** (ロールの切り替え) ボタンを選択する必要があります。

1. 次に、ロールにアクセスするために、David はターゲットアカウント ID 番号 (`999999999999`) およびロール名 (`UpdateData`) を入力する必要があります。

   またDavid は、現在 IAM でアクティブなロールと、関連するアクセス許可をモニタリングしたいと考えています。この情報を追跡するために、[**Display Name (表示名)**] テキストボックスに「`Destination`」と入力し、赤色のオプションを選択して、[**Switch Role (スイッチロール)**] を選択します。

1. これで、David は Amazon S3 コンソールを使用して、`UpdateData` ロールがアクセス許可を持つ バケットなどのリソースを操作できます。

1. 完了すると、David は元のアクセス権限に戻ることができます。そのためには、ナビゲーションバーのロール表示名 **[ターゲット]** を選択してから、**[David @ 111111111111 に戻る]** を選択します。

1. David が次回にロールに切り替えるために、ナビゲーションバーの **[ID]** メニューを選択すると、ターゲットエントリが前回からそのままになっています。そのエントリを選択するだけで、アカウント ID とロール名を再入力することなく、すぐにロールに切り替えることができます。

### ロールの切り替え (AWS CLI)
<a name="switch-cli-tutorial_cross-account-with-roles"></a>

 David がコマンドラインで**ターゲット**の環境を操作する必要がある場合、[AWS CLI](https://aws.amazon.com/cli/) を使用してこの切り替えを行うことができます。`aws sts assume-role` コマンドを実行し、ロールの ARN を渡して、そのロールの一時的なセキュリティ認証情報を取得します。次に、環境変数でそれらの認証情報を設定し、それ以降の AWS CLI コマンドが、ロールのアクセス許可を使用して動作するようにします。David がロールを使用中に、**ソース**アカウントのパワーユーザーの特権を使用することはできません。これは、一度に有効にできる許可のセットは 1 つのみであるためです。

すべてのアクセスキーとトークンは例にすぎず、実際にはそのように使用できないことに注意してください。ライブ環境の適切な値に置き換えてください。

**ロールを引き受けるには**

1. David はコマンドプロンプトウィンドウを開き、次のコマンドを実行して、AWS CLI クライアントが動作していることを確認します。

   ```
   aws help
   ```
**注記**  
David のデフォルト環境では、`David` コマンドで作成したデフォルトのプロファイルから、`aws configure` ユーザー認証情報を使用します。詳細については、「[AWS Command Line Interface ユーザーガイド](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration)」の「*AWS Command Line Interface の設定*。」を参照してください。

1. David は次のコマンドを実行してロールの切り替えプロセスを開始し、**ターゲット**アカウントで `UpdateData` ロールに切り替えます。ロールを作成した管理者から、ロールの ARN を取得しました。コマンドでは、セッション名も提供する必要もあります。セッション名には任意のテキストを選択できます。

   ```
   aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateData" --role-session-name "David-ProdUpdate"
   ```

   出力には次のように表示されます。

   ```
   {
       "Credentials": {
           "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
           "SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
   CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDy
   EXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
   sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87e
   NhyDHq6ikBQ==",
           "Expiration": "2014-12-11T23:08:07Z",
           "AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
       }
   }
   ```

1. 出力の [認証情報] セクションには、3 つの必要な情報が表示されます。
   + `AccessKeyId`
   + `SecretAccessKey`
   + `SessionToken`

   以降の呼び出しでこれらのパラメータを使用するには、AWS CLI 環境を設定する必要があります。認証情報を設定するさまざまな方法の詳細については、「[AWS Command Line Interface の設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#config-settings-and-precedence)」を参照してください。セッショントークンの取得をサポートしていないため、`aws configure` コマンドを使用することはできません。ただし、設定ファイルに手動で情報を入力することができます。これらは有効期限が比較的短い一時的な認証情報なので、現在のコマンドラインセッションの環境に追加するのが最も簡単です。

1. David は、環境に 3 つの値を追加するため、前のステップの出力を切り取り、次のコマンドに貼り付けます。セッショントークン出力の改行の問題に対応するため、シンプルなテキストエディターで切り取りと貼り付けを行います。ここではわかりやすくするために改行して表示されていますが、1 行の長い文字列として入力する必要があります。

   以下の例では「set」が環境変数を作成するためのコマンドとなっている Windows 環境で指定されたコマンドを示しています。Linux または Mac コンピュータでは、代わりに「export」コマンドを使用します。この例における他の部分はすべて、3 つの環境で有効です。

   Windows Powershell 用ツールの使用方法の詳細については、[IAM ロールに切り替える (Tools for Windows PowerShell)](id_roles_use_switch-role-twp.md) を参照してください。

   ```
   set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
   set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
   Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
   MPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
   EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHen
   DHq6ikBQ==
   ```

   この時点で、次のコマンドはいずれも、これらの認証情報によって識別されたロールのアクセス権限で実行されます。David の場合は、`UpdateData` ロールです。
**重要**  
頻繁に利用される構成設定および認証情報を AWS CLI が維持するファイルに保存することができます。詳細については、「AWS Command Line Interface ユーザーガイド」の「[Using existing configuration and credentials files](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-existing)」を参照してください。

1. ターゲットアカウントのリソースにアクセスするコマンドを実行します。この例では、David は次のコマンドを使用して S3 バケットのコンテンツの一覧を示します。

   ```
   aws s3 ls s3://shared-container
   ```

   Amazon S3 バケット名は共通にユニークであるため、バケットを所有するアカウント ID を指定する必要はありません。その他の AWS サービスのリソースにアクセスするには、そのリソースを参照するために必要なコマンドと構文について記載されている対象サービスの AWS CLI のドキュメントを参照してください。

### AssumeRole (AWS API) の使用
<a name="api-tutorial_cross-account-with-roles"></a>

David は、コードから**ターゲット**アカウントを更新する必要がある場合、`AssumeRole` を呼び出し、`UpdateData` ロールを取得します。この呼び出しは、David が**ターゲット**アカウントにある `amzn-s3-demo-bucket-shared-container` バケットにアクセスするために使用できる一時的な認証情報を返します。これらの認証情報を使用して、David は `amzn-s3-demo-bucket-shared-container` バケットを更新する API 呼び出しを行うことができます。ただし、**ソース**アカウントのパワーユーザー許可を持っていても、**ターゲット**アカウントの他のリソースにアクセスするために API コールを実行することはできません。

**ロールを引き受けるには**

1. デイビッドは、アプリケーションの一部として `AssumeRole` を呼び出します。ユーザーは、`UpdateData` ARN: `arn:aws:iam::999999999999:role/UpdateData` と指定する必要があります。

   `AssumeRole` 呼び出しからのレスポンスには、`AccessKeyId` と `SecretAccessKey` を含む一時的な認証情報が含まれています。また、認証情報の有効期限を示す `Expiration` 時間も含まれており、新しい認証情報をリクエストする必要があります。AWS SDK を使用してロールチェーニングを設定すると、多くの認証情報プロバイダーは、失効前に認証情報を自動的に更新します。

1. 一時的な認証情報を使用して、デイビッドは `s3:PutObject` 呼び出しを行い、`amzn-s3-demo-bucket-shared-container` バケットを更新します。ユーザーは、`AuthParams` パラメータとして API 呼び出しに認証情報を渡します。ロールの一時的な認証情報は `amzn-s3-demo-bucket-shared-container` バケットでの読み取りおよび書き込み専用のアクセスであるため、ターゲットアカウントでの他のアクションは拒否されます。

コードの例 (Python を使用) については、「[IAM ロールを切り替える (AWS)](id_roles_use_switch-role-api.md)」を参照してください。

## その他のリソース
<a name="tutorial_cross-account-with-roles-related"></a>

次のリソースは、このチュートリアルのトピックの詳細を理解するのに役立ちます。
+ IAM ユーザーの詳細については、「[IAM アイデンティティ](id.md)」を参照してください。
+ Amazon S3 バケットの詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingABucket.html)」を参照してください。
+  信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「[IAM Access Analyzer とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)」を参照してください。

## 概要
<a name="tutorial_cross-account-with-roles-summary"></a>

これでクロスアカウント API アクセスのチュートリアルが終了しました。他のアカウントと信頼を構築するロールを作成し、信頼されたエンティティが実行できるアクションを定義しました。次に、ロールポリシーを変更して、どの IAM ユーザーがロールにアクセスできるかを制御しました。その結果、**ソース**アカウントのデベロッパーは、一時的な認証情報を使用して**ターゲット**アカウントにある `amzn-s3-demo-bucket-shared-container` バケットを更新することができます。