メニュー
AWS Identity and Access Management
ユーザーガイド

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

このチュートリアルでは、ユーザーが所有する異なる AWS アカウント(Production および Development)にあるリソースへのアクセスを委任するロールを使用する方法を学びます。1 つのアカウントにあるリソースを、異なるアカウントのユーザーと共有します。この方法でクロスアカウントアクセスをセットアップすると、各アカウントで個別の IAM ユーザーを作成する必要がなく、ユーザーはいったんサインアウトして別のアカウントへ再サインインする必要なく他の AWS アカウントにあるリソースへアクセスできるようになります。ロールを設定すると、AWS マネジメントコンソール、AWS CLI、API からロールを使用する方法を参照してください。

このチュートリアルでは、Production アカウントは既存のアプリケーションを管理しており、開発アカウントは開発者とテスターが自由にアプリケーションをテストできるサンドボックスを想定しています。各アカウントでは、アプリケーション情報が Amazon S3 バケットに格納されています。お客様は開発アカウントの IAM ユーザーを管理しており、開発とテスターの 2 つの IAM グループがあるとします。どちらのグループのユーザーにも、Development アカウントで作業し、そのリソースにアクセスするアクセス許可があります。ときどき、開発者が Production アカウントのライブアプリケーションを更新する必要があります。これらのアプリケーションでは、productionapp と呼ばれる Amazon S3 バケットに保存されます。

このチュートリアルの終了時に、Development アカウント (信頼される側のアカウント) のユーザーに、Production アカウント (信頼する側のアカウント) の productionapp バケットにアクセスを許可するロールを、Production アカウントに作成します。開発者は、AWS マネジメントコンソール でロールを使用して Production アカウントの productionapp バケットにアクセスできます。さらに、ロールにより提供される一時的な認証情報によって認証された API 呼び出しを使用してバケットにアクセスすることもできます。テスターがそのロールを使用して同様の操作を行うことはできません。

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

ステップ 1 - ロールの作成

まず、AWS マネジメントコンソール を使用して Production アカウント(ID 番号 999999999999)と Development アカウント(ID 番号 111111111111)間の信頼を確立するには、UpdateApp という名前が付いた IAM ロールを作成します。ロールの作成時に、Development アカウントを信頼されたエンティティとして定義し、信頼されたユーザーに productionapp バケットを更新する許可を与えるアクセス許可ポリシーを特定します。

ステップ 2 - ロールへのアクセスを許可する

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

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

最後に、開発者として、UpdateAPP ロールを使用して Production アカウントの productionapp バケットを更新します。AWS コンソール、AWS CLI、API を使用してロールにアクセスする方法について説明します。

前提条件

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

  • 使用できる AWS アカウントを、それぞれ Development アカウントと Production アカウントを表す 2 つのアカウントに分けます。

  • Development アカウントのユーザーとグループは、以下のように作成され設定されます:

    ユーザー グループ アクセス許可
    David 開発者 両方のユーザーが Development アカウントの AWS マネジメントコンソール にサインインして使用できます。
    Theresa テスター
  • Production アカウントにはユーザーまたはグループを作成する必要はありません。

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

ステップ 1 - ロールの作成

ある AWS アカウントに属しているユーザーが他の AWS アカウントのリソースへアクセスできるようにするには、リソースにアクセスできるユーザーを定義するロールを作成します。また、このロールに切り替えるユーザーに対して付与されるアクセス許可についても定義します。

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

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

開発 AWS アカウント ID を取得するには

  1. アマゾン ウェブ サービスのウェブサイトにアクセスし、[My Account] の上にカーソルを置き、[AWS Management Console] を選択します。その後で、開発アカウント用の AWS マネジメントコンソール にサインインします。

  2. ナビゲーションバーで、[Support]、[Support Center] の順に選択します。アカウント番号は、画面右上([Support] メニューの下)に示されています。アカウント ID は、12 桁の数字です。このシナリオでは、開発アカウント ID を 111111111111 とします。ただし、テスト環境でシナリオを再構築する場合は、有効なアカウント ID を使用してください。

開発アカウントで使用できるロールを生産アカウントで作成するには

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

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

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

    左側のナビゲーションペインで [Policies] を選択し、[Create Policy] を選択します。

  3. [Create Your Own Policy] の横の [Select] を選択します。

  4. ポリシー名に [read-write-app-bucket] を入力します。

  5. ポリシードキュメントに以下のアクセス許可を追加します。リソース ARN(arn:aws:s3:::productionapp)は、S3 バケットに適した実際の ARN に置き換えてください。

    Copy
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "arn:aws:s3:::*" }, { "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/*" } ] }

    ListBucket アクセス許可は、ユーザーに productionapp バケットにあるオブジェクトの閲覧を許可します。GetObjectPutObjectDeleteObject アクセス許可によって、ユーザーは productionapp バケットの内容を表示、更新、および削除できます。

  6. [Create Policy] を選択します。

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

  7. 左側のナビゲーションペインで [Roles] を選択し、続いて [Create New Role] を選択します。

  8. ロールの名前として [UpdateAPP] を入力し、[Next Step] を選択します。

  9. [Select Role Type] で [Role for Cross-Account Access] を選択し、[Provide access between AWS accounts you own] の横にある [Select] を選択します。

  10. 開発アカウント ID を入力します。

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

    ロールを適用するのにユーザーは多要素認証(MFA)が必要なくなったので、このオプションを選択していない状態にしておきます。お客様の環境でこのオプションを選択すると、Multi-Factor Authentication のプログラムやデバイスからワンタイムパスワード (OTP) を使用してサインインするユーザーだけが、ロールを引き受けることができます。ロールを切り替えるときにユーザーは OTP を入力できません。OTP は、ユーザーが初めてサインインするときに入力する必要があります。詳細については、「AWS での多要素認証 (MFA) の使用」を参照してください。

  11. [Next Step] を選択し、そのロールに関連するアクセス許可を設定します。

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

    ヒント

    [Filter] では、[Customer Managed Policies] を選択してリストをフィルタし、自分で作成したポリシーのみを含めます。これにより、AWS が作成したポリシーが非表示になり、探しているポリシーを見つけるのが簡単になります。

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

  13. [Review] ページが表示されます。このページで作成前のロールの設定を確認できます。このページで注意する重要な項目は、このロールを使用する必要があるユーザーに送信できるリンクです。ユーザーがこのリンクを選択すると、[Switch Role] ページがすぐに表示されます。このページには、[Account ID] と [Role Name] がすでに設定されています。このリンクは、クロスアカウントロールの [Role Summary] ページで後で確認することもできます。

    注記

    後で簡単に選択できるように、IAM コンソールは使用する最後の 5 つのロールをキャッシュします。ユーザーが 6 つ以上のロールを必要とする場合は、アクセスを簡単にするために以下のソリューションを検討してください。

    • 少数のユーザーがロールを切り替える場合は、送信されたリンクを各ユーザーがブックマークすることをお勧めします。

    • 多数のユーザーがロールを切り替える場合は、ユーザーがアクセスする必要のあるリンクをすべて含むウェブページのような中心となる場所を作成することを検討します。

    リンクのフォーマットは次のとおりです。

    https://signin.aws.amazon.com/switchrole?account=ACCOUNT_NUMBER&roleName=ROLE_NAME&displayName=DISPLAYNAME

  14. ロールを確認したら、[Create Role] を選択します。

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

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

UpdateAPP の ARN を取得するには

  1. IAM コンソールの [Navigation] ペインで [Roles] を選択します。

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

  3. 詳細ペインの [Summary] セクションで、[Role ARN] の値をコピーします。

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

これで、開発アカウントを信頼されたプリンシパルとして指定するロールが生産アカウントに作成され、生産アカウントと開発アカウントの間に信頼関係が確立されました。また、UpdateApp ロールに切り替えるユーザーが何を実行できるかについても定義しました。

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

ステップ 2 - ロールへのアクセスを許可する

この時点では、Testers グループと Developers グループのメンバーにはいずれも、Development アカウントで自由にアプリケーションをテストできるアクセス権限があります。ここでは、ロールの切り替えを許可するアクセス権限を追加するために必要なステップを示します。

UpdateApp ロールに切り替えることを許可するように Developers グループを変更するには

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

  2. [Groups] を選択して、[Developers] を選択します。

  3. [Permissions] タブを選択して、[Inline Policies] セクションを展開し、[Create Group Policy] を選択します。インラインポリシーがまだ存在しない場合、ボタンは表示されません。代わりに、[To create one, click here.] の最後にあるリンクを選択します。

  4. [Custom Policy] を選択し、[Select] ボタンを選択します。

  5. allow-assume-S3-role-in-production」のようにポリシー名を入力します。

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

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

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

  7. [Apply Policy] を選択して、Developer グループにポリシーを追加します。

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

UpdateApp ロールを引き継ぐためのアクセス権限を拒否するように Testers グループを変更するには

  1. [Groups] を選択して、[Testers] を選択します。

  2. [Permissions] タブを選択して、[Inline Policies] セクションを展開し、[Create Group Policy] を選択します。

  3. [Custom Policy] を選択し、[Select] ボタンを選択します。

  4. deny-assume-S3-role-in-production」のようにポリシー名を入力します。

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

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

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

  6. [Apply Policy] を選択して、テスターグループにポリシーを追加します。

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

次に、開発者の David が AWS マネジメントコンソール、および AWS CLI コマンド、AssumeRole API 呼び出しを使用して Production アカウントで productionapp バケットにアクセスする方法について説明します。

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

このチュートリアルの最初の 2 つのステップを完了すると、Production アカウントのリソースへのアクセス権限を付与するロールと、ユーザーがそのロールの使用が許可される、Development アカウントの 1 つのグループが作成されます。このロールは現在使用可能であり、このステップでは、AWS マネジメントコンソール、AWS CLI、および AWS API のロールへの切り替えについて説明します。

重要

IAM ユーザー、すでにロールを使用している 外部で認証されたユーザー (SAML または OIDC) としてサインインしている場合、または、インスタンスプロファイルによるロールにアタッチされた Amazon EC2 インスタンスから実行する場合のみ、ロールを切り替えることができます。 AWS アカウントの root ユーザーとしてサインインしているときに、ロールを切り替えることはできません。

AWS マネジメントコンソール を使用したロールの切り替え

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

重要

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

David が [Switch Role] ページに移動するには、2 つの方法があります:

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

  • 管理者はメールでリンクを送信しませんが、代わりに [Account ID] 番号および [Role Name] の値を送信します。David は、手動でこれらを入力してロールを切り替える必要があります。これを次の手順に示します。

AWS マネジメントコンソール でロールを使用するには

  1. David は、Development グループの通常のユーザーを使用して AWS にログインします。

  2. 管理者から受け取ったメールのリンクを選択します。これにより、[Switch Role] ページに移動します。このページには、アカウント ID、エイリアス、およびロール名情報が既に入力されています。

    - または -

    ナビゲーションバーのユーザー名([Identity] メニュー)を選択し、[Switch Role] を選択します。

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

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

    また、現在アクティブなロール (および関連するアクセス権限) を継続して把握するため、David は [Display Name] テキストボックスに「PRODUCTION」と入力し、赤のオプションを選択して、[Switch Role] を選択します。

  4. これで David は、Amazon S3 コンソールを使用して Amazon S3 バケットを操作したり、ロールにアクセス権限がある UpdateApp ロールにアクセス権限がある他のリソースを操作できます。

  5. 必要な作業を終了したら、David はナビゲーションバーの PRODUCTION ロール表示名を選択し、[Back to David @ 111111111111] を選択して元のアクセス権限に戻ることができます。

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

AWS CLI を使用したロールの切り替え

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

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

AWS CLI でロールを使用するには

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

    Copy
    aws help

    注記

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

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

    Copy
    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 行の長い文字列として入力する必要があります。

    Copy
    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 バケットのコンテンツの一覧を示します。

    Copy
    aws s3 ls s3://productionapp

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

API からの AssumeRole の使用

David は、コードから Production アカウントを更新する必要がある場合、AssumeRole を呼び出し、UpdateAPP ロールを取得します。この呼び出しは、David が Production アカウントにある productionapp バケットにアクセスするために使用できる一時的な認証情報を返します。Development アカウントでは、David はパワーユーザーの権限があります、これらの認証情報を使用して、API 呼び出しで productionapp バケットを更新することはできますが、API 呼び出しで Production アカウントにある他のリソースにはアクセスできません。

API 呼び出しを行ってロールを使用するには

  1. デイビッドは、アプリケーションの一部として AssumeRole を呼び出します。デイビッドは UpdateAPP ARN: arn:aws:iam::999999999999:role/UpdateAPP を特定しなければいけません。

    AssumeRole 呼び出しの応答には、認証情報がいつ失効し、新しい認証情報をリクエストする必要があるかを示す、SecretAccessKeyAccessKeyId、および Expiration を持つ一時的な認証情報が含まれます。

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

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

概要

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