IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 - AWS Identity and Access Management

IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任

このチュートリアルでは、ロールを使用して、お客様が所有する作成および開発という異なる AWS アカウント のリソースへのアクセスを委任する方法について説明します。特定のアカウントにあるリソースを別のアカウントのユーザーと共有します。このようにクロスアカウントアクセスを設定することで、お客様はアカウントごとに IAM ユーザーを作成する必要がなくなります。また、ユーザーは、異なる AWS アカウント のアカウントのリソースにアクセスするために、あるアカウントからサインアウトして別のアカウントにサインインする必要がなくなります。ロールを設定した後、AWS Management Console、AWS CLI、API からロールを使用する方法について説明します。

注記

IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。たとえば、標準 aws パーティションの米国西部 (北カリフォルニア) にアカウントがあるとします。aws-cn パーティションの 中国 (北京) にもアカウントがあります。標準 aws アカウントで、中国 (北京) のアカウントの Amazon S3 リソースベースのポリシーを使用して、ユーザーにアクセスを許可することはできません。

このチュートリアルでは、本番稼働用アカウントがライブアプリケーションを管理しています。デベロッパーやテスターは、開発アカウントをサンドボックスとして使用して、自由にアプリケーションをテストます。各アカウントでは、Amazon S3 バケットにアプリケーション情報を保存します。開発アカウントの IAM ユーザーを管理しており、開発テスターの 2 つの IAM グループがあるとします。どちらのユーザーグループにも、開発用アカウントで作業し、そのリソースにアクセスするアクセス許可があります。ときどき、デベロッパーが本番稼働用アカウントのライブアプリケーションを更新する必要があります。デベロッパーは、これらのアプリケーションを productionapp という Amazon S3 バケットに保存します。

このチュートリアルを終了すると、次のようになります。

  • 本番稼働用アカウントで特定のロールを引き受けることができる開発アカウント (信頼できるアカウント) のユーザー。

  • 特定のAmazon S3 バケットへのアクセスを許可される本番稼働用アカウント (信頼するアカウント) のロール。

  • 本番稼働用アカウントの productionapp バケット。

デベロッパーは、AWS Management Console でロールを使用して本番稼働用アカウントの productionapp バケットにアクセスできます。さらに、ロールにより提供される一時的な認証情報によって認証された API コールを使用してバケットにアクセスすることもできます。テスターがそのロールを使用して同様の操作を行うことはできません。

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

本番稼働用アカウントでロールを作成する

まず、AWS Management Console を使用して本番稼働用アカウント (ID 番号 999999999999) と開発用アカウント (ID 番号 111111111111) との間の信頼を確立します。続いて、UpdateApp という IAM ロールを作成します。ロールの作成時に、開発用アカウントを信頼されたエンティティとして定義し、信頼されたユーザーに productionapp バケットを更新する許可を与えるアクセス許可ポリシーを特定します。

ロールにアクセス許可を付与する

チュートリアルのこのステップでは、IAM ユーザーグループを変更して、テスターの UpdateApp ロールへのアクセスを拒否するようにします。このシナリオではテスターに PowerUser アクセス許可があるため、ロールの使用を明示的に拒否する必要があります。

ロールを切り換えてアクセスをテストする

最後にデベロッパーとして、UpdateApp ロールを使用して本番稼働用アカウントの productionapp バケットを更新します。AWS コンソール、AWS CLI、API を使用してロールにアクセスする方法について説明します。

前提条件

このチュートリアルでは、以下を実行済みであることを前提としています。

  • 使用できる AWS アカウント を、それぞれ開発用アカウントと本番稼働用アカウントを表す 2 つのアカウントに分けます。

  • 開発用アカウントのユーザーとユーザーグループは、次のように作成され、設定されます。

    ユーザー ユーザーグループ 許可
    David 開発者 どちらのユーザーも開発用アカウントでサインインでき、AWS Management Console を使用できます。
    Jane テスター
  • 本番稼働用アカウントにはユーザーまたはユーザーグループを作成する必要はありません。

  • 本番稼働用アカウントで作成された Amazon S3 バケット。このチュートリアルでは ProductionApp と呼びますが、S3 バケット名はグローバルに一意である必要があるため、別の名前のバケットを使用する必要があります。

本番稼働用アカウントでロールを作成する

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

チュートリアルのこのステップでは、本番稼働用アカウントにロールを作成し、開発アカウントを信頼されたエンティティとして指定します。また、ロールのアクセス許可を productionapp バケットでの読み書き専用に制限します。ロールを使用するアクセス許可が付与されるすべてのユーザーは、productionapp バケットに対する読み取りと書き込みを実行できます。

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

開発 AWS アカウント ID を取得するには
  1. 開発用アカウントの管理者として AWS Management Console にサインインし、https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。

  2. ナビゲーションバーで、[サポート]、[サポートセンター] の順に選択します。現在サインインしている 12 桁のアカウント番号 (ID) は、サポートセンターナビゲーションペインを使用します。このシナリオでは、アカウント ID 111111111111 を開発用アカウントとして使用します。ただし、テスト環境でこのシナリオを使用する場合は、有効なアカウント ID を使用する必要があります。

開発アカウントで使用できるロールを本番稼働用アカウントで作成するには
  1. 本番稼働用アカウントの管理者として AWS Management Console にサインインし、IAM コンソールを開きます。

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

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

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

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

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

    ListAllMyBuckets アクションは、リクエストの認証済み送信者によって所有されているすべてのバケットを一覧表示するアクセス許可を付与します。ListBucket アクセス許可は、ユーザーに productionapp バケットにあるオブジェクトの閲覧を許可します。GetObjectPutObjectDeleteObject アクセス許可によって、ユーザーは productionapp バケットの内容を表示、更新、および削除できます。

  4. ポリシーの検証中に生成されたセキュリティ警告、エラー、または一般的な警告を解決してから、[Next] (次へ) を選択します。

    注記

    いつでも [Visual] と [JSON] エディタオプションを切り替えることができます。ただし、[Visual] エディタで [] に変更または選択した場合、IAM はポリシーを再構成して visual エディタに合わせて最適化することがあります。詳細については、「ポリシーの再構成」を参照してください。

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

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

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

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

  8. [Account ID] (アカウント ID) で、開発アカウント ID を入力します。

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

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

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

  10. 以前に作成したポリシーの横にあるチェックボックスを選択します。

    ヒント

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

    次に、[次へ] を選択します。

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

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

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

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

ここで、ロールに固有の識別子である Amazon リソースネーム (ARN) を取得しなければいけません。デベロッパーやテスターのユーザーグループのポリシーを変更するとき、アクセス許可を許可または拒否するためのロールの ARN を指定します。

UpdateApp の ARN を取得するには
  1. IAM コンソールのナビゲーションペインで [Roles] (ロール) をクリックします。

  2. ロールのリストで、[UpdateApp] ロールを選択します。

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

    Production アカウントのアカウント ID が 999999999999 であるため、ロール ARN は arn:aws:iam::999999999999:role/UpdateApp となります。本番稼働用アカウントでは、実際の AWS アカウント ID を指定してください。

この時点で、本番稼働用アカウントと開発用アカウント間の信頼が確立されました。そのためには、開発用アカウントを信頼されたプリンシパルとして識別するロールを本番稼働用アカウントに作成します。また、UpdateApp ロールに切り替えるユーザーが何を実行できるかについても定義しました。

次は、ユーザーグループのアクセス許可を修正します。

ロールにアクセス許可を付与する

この時点では、Testers と Developers のユーザーグループのメンバーにはいずれも、開発アカウントで自由にアプリケーションをテストできるアクセス許可があります。ロールの切り替えを許可するアクセス許可を追加するには、この必要な手順に従ってください。

UpdateApp ロールに切り替えることを許可するように Developers ユーザーグループを変更するには
  1. 開発用アカウントの管理者としてサインインし、IAM コンソールを開きます。

  2. [ユーザーグループ]、[Developers (開発者)] の順に選択します。

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

  4. [JSON] タブを選択します。

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

    { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp" } }

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

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

  7. allow-assume-S3-role-in-production などの名前を入力します。

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

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

UpdateApp ロールを引き継ぐためのアクセス許可を拒否するようにテスターユーザーグループを変更するには
  1. [ユーザーグループ]、[Testers] の順に選択します。

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

  3. [JSON] タブを選択します。

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

    { "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateApp" } }

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

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

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

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

これで、Developers ユーザーグループは、Production アカウントの UpdateApp ロールを使用するためのアクセス許可を持つようになりました。Testers ユーザーグループは、UpdateApp ロールを使用できません。

次に、デベロッパーの David が本番稼働用アカウントの productionapp バケットにアクセスする方法について説明します。David は、AWS Management Console、AWS CLI、または AWS API からバケットにアクセスできます。

ロールを切り換えてアクセスをテストする

このチュートリアルの最初の 2 つのステップを完了した時点で、本番稼働用アカウントのリソースに対するアクセス許可を付与するロールがあります。また、開発用アカウントには、そのロールを使用できるユーザーで構成されたユーザーグループもあります。このステップでは、AWS Management Console、AWS CLI、および AWS API のロールへの切り替えについて説明します。

重要

ロールの切り替えは、IAM ユーザーまたはフェデレーティッドユーザーとしてサインインした場合にのみ可能です。さらに、Amazon EC2 インスタンスを起動してアプリケーションを実行すると、そのアプリケーションはそのインスタンスプロファイルを通じてロールを引き受けることができます。AWS アカウントのルートユーザー としてサインインしているときに、ロールを切り替えることはできません。

ロールの切り替え (コンソール)

David が AWS Management Console で本番稼働用環境を操作する必要がある場合は、[Switch Role] (ロールの切り替え) を使用することができます。アカウント ID またはエイリアスとロール名を指定すれば、David のアクセス権限は、ロールによって許可されているものに直ちに切り替わります。次に、David はコンソールを使用して productionapp バケットを操作することができますが、本稼働環境の他のリソースは一切操作できません。David がロールを使用中に、開発用アカウントのパワーユーザーアクセス許可を使用することはできません。これは、同時に有効にできるアクセス許可のセットは 1 つのみであるためです。

重要

AWS Management Console を使ったロールの切り替えは、ExternalId を必要としないアカウントでのみ機能します。たとえば、アカウントへのアクセス権を第三者に付与し、アクセス許可ポリシーの Condition 要素に ExternalId を要求するとします。その場合、第三者は AWS API またはコマンドラインツールを使用してのみ、お客様のアカウントにアクセスできます。第三者は ExternalId の値を指定できないため、コンソールを使用できません。このシナリオの詳細については、『AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法 セキュリティブログ』の「AWS Management Console」および「AWS へのクロスアカウントアクセスを有効にする方法」を参照してください。

David が IAM で [Switch Role] (ロールの切り替え) ページに移動するには、2 つの方法があります。

  • David は事前定義されたロールの切り替え設定を指すリンクを管理者から受け取ります。リンクは [ロールの作成] ウィザードの最終ページ、またはクロスアカウントロールの [ロールの概要] ページで管理者に提供されます。このリンクを選択すると、[ロールの切り替え] ページに移動します。このページには、[Account ID (アカウント ID)] および [ロール名] フィールドがすでに入力されています。David は、[Switch Roles] (ロールの切り替え) ボタンを選択するだけです。

  • 管理者はメールでリンクを送信しませんが、代わりに [Account ID (アカウント ID)] 番号および [ロール名] の値を送信します。役割を切り替えるには、デビッドは手動でその値を入力する必要があります。これを次の手順に示します。

ロールを割り当てるには
  1. David は、開発用ユーザーグループの通常のユーザーを使用して AWS Management Console にサインインします。

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

    -または-

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

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

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

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

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

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

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

ロールの切り替え (AWS CLI)

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

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

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

    aws help
    注記

    David のデフォルト環境では、David コマンドで作成したデフォルトのプロファイルから、aws configure ユーザー認証情報を使用します。詳細については、『AWS Command Line Interface ユーザーガイド』の「AWS Command Line Interface の設定。」を参照してください。

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

    aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateApp" --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" } }
  3. 出力の [Credentials] (認証情報) セクションには、3 つの必要な情報が表示されます。

    • AccessKeyId

    • SecretAccessKey

    • SessionToken

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

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

    注記

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

    Windows Powershell 用ツールの使用方法の詳細については、IAM ロールへの切り替え (Tools for Windows PowerShell) を参照してください。

    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 の場合は、UpdateApp ロールです。

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

    aws s3 ls s3://productionapp

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

AssumeRole (AWS API) の使用

David は、コードから本番稼働用アカウントを更新する必要がある場合、 AssumeRole を呼び出し、UpdateApp ロールを取得します。この呼び出しは、David が本番稼働用アカウントにある productionapp バケットにアクセスするために使用できる一時的な認証情報を返します。これらの認証情報を使用して、David は productionapp バケットを更新する API 呼び出しを行うことができます。ただし、開発用アカウントのパワーユーザーアクセス許可を持っていても、本番稼働用アカウントの他のリソースにアクセスする API コールを行うことはできません。

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

    AssumeRole 呼び出しからのレスポンスには、AccessKeyIdSecretAccessKey を含む一時的な認証情報が含まれています。また、認証情報の有効期限を示す Expiration 時間も含まれており、新しい認証情報をリクエストする必要があります。

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

コードの例 (Python を使用) については、「IAM ロール (AWS API) の切り替え」を参照してください。

  • IAM ユーザーとユーザーグループの詳細については、「IAM ID (ユーザー、ユーザーグループ、ロール)」を参照してください。

  • Amazon S3 バケットの詳細については、Amazon Simple Storage Service ユーザーガイドの「バケットの作成」を参照してください。

  • 信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を参照してください。

まとめ

これでクロスアカウント API アクセスのチュートリアルが終了しました。他のアカウントと信頼を構築するロールを作成し、信頼されたエンティティが実行できるアクションを定義しました。次に、どの IAM ユーザーがロールを取得できるのかを制御するグループポリシーを修正しました。その結果、開発アカウントのデベロッパーは、一時的な認証情報を使用して本番稼働用アカウントにある productionapp バケットを更新することができます。