IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 - AWS Identity and Access Management
考慮事項前提条件ターゲットアカウントにロールを作成するロールにアクセス許可を付与するロールを切り換えてアクセスをテストする追加リソース[概要]

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

重要

IAM ベストプラクティスでは、長期的な認証情報を持つIAMユーザーを使用するのではなく、一時的な認証情報を使用して AWS にアクセスするために、IDプロバイダーとのフェデレーションを使用することを人間ユーザーに求めることを推奨します。

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

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

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

  • ターゲットアカウントで特定のロールを引き受けることができるソースアカウント (信頼されたアカウント) のユーザー。

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

  • ターゲットアカウントの shared-container バケット。

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

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

ターゲットアカウントにロールを作成する

まず、AWS Management Console を使用してターゲットアカウント (ID 番号 999999999999) とソースアカウント (ID 番号 111111111111) との間の信頼を確立します。まず、UpdateData という名前の IAM ロールを作成します。ロールの作成時に、ソースアカウントを信頼されたエンティティとして定義し、信頼されたユーザーが shared-container バケットを更新することを許可する許可ポリシーを指定します。

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

このセクションでは、ロールポリシーを変更して、アナリストが UpdateData ロールにアクセスするのを拒否します。このシナリオではアナリストに PowerUser アクセス許可があるため、ロールの使用を明示的に拒否する必要があります。

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

最後にデベロッパーとして、UpdateData ロールを使用してターゲットアカウントの shared-container バケットを更新します。AWS コンソール、AWS CLI、API を使用してロールにアクセスする方法について説明します。

考慮事項

IAM ロールを使用して AWS アカウント 間でリソースアクセスを委任する前に、次を考慮することが重要です。

  • AWS アカウントのルートユーザー としてサインインしているときに、ロールを切り替えることはできません。

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

  • AWS IAM Identity Center を使用すると、Security Assertion Markup Language (SAML) を使用して、外部 AWS アカウント (AWS Organizations の外部のアカウント) のシングルサインオン (SSO) を容易にすることができます。詳細については、「 Integrate external AWS アカウント into AWS IAM Identity Center for central access management with independent billing using SAML 2.0」を参照してください。

  • Amazon EC2 インスタンスや AWS Lambda 関数などの AWS リソースにロールを関連付けることができます。詳細については、「AWS サービスにアクセス許可を委任するロールを作成する」を参照してください。

  • アプリケーションが別の AWS アカウント でロールを引き受けるようにする場合は、AWS SDK を使用してクロスアカウントロールを引き受けることができます。詳細については、「AWS SDK およびツールのリファレンスガイド」の「Authentication and access」を参照してください。

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

前提条件

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

  • 使用できる AWS アカウント を、それぞれソースアカウントとターゲットアカウントを表す 2 つのアカウントに分けます。

  • ソースアカウントのユーザーとロールは次のように作成および構成されます。

    役割 ユーザー アクセス許可
    開発者 David どちらのユーザーもソースアカウントでサインインでき、AWS Management Console を使用できます。
    アナリスト Jane

  • ターゲットアカウントでユーザーを作成する必要はありません。

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

ターゲットアカウントにロールを作成する

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

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

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

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

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

  2. IAM コンソールで、右上のナビゲーションバーのユーザー名を選択します。通常は username@account_ID_number_or_alias のように表示されます。

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

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

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

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

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

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

  3. [JSON] タブを選択し、以下の JSON ポリシードキュメントからテキストをコピーします。[JSON] (JSON) テキストボックスにこのテキストを貼り付け、リソース ARN (arn:aws:s3:::shared-container) を、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:::shared-container"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::shared-container/*"
    }
  ]
}

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

    注記

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

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

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

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

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

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

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

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

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

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

    ヒント

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

    [次へ] を選択します。

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

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

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

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

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

UpdateData の ARN を取得するには

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  8. [Create policy] を選択します。

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

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

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

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

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

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

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

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

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

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

  7. [Create policy] を選択します。

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

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

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

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

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

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

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

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 はターゲットアカウント ID 番号 (999999999999) およびロール名 (UpdateData) を入力する必要があります。

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

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

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

  6. David が次回にロールに切り替えるために、ナビゲーションバーの [ID] メニューを選択すると、ターゲットエントリが前回からそのままになっています。そのエントリを選択するだけで、アカウント 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 は次のコマンドを実行してロールの切り替えプロセスを開始し、ターゲットアカウントで 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"
    }
}

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

    重要

    頻繁に利用される構成設定および認証情報を AWS CLI が維持するファイルに保存することができます。詳細については、「AWS Command Line Interface ユーザーガイド」の「Using existing configuration and credentials files」を参照してください。

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

    aws s3 ls s3://shared-container

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

AssumeRole (AWS API) の使用

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

ロールを引き受けるには

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

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

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

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

次のリソースは、このチュートリアルのトピックの詳細を理解するのに役立ちます。

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

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

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

[概要]

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