「メールアドレス確認ページ」がどこにあ…
このチュートリアルでは、ロールを使用して、お客様が所有する異なる AWS アカウント Production および Development にあるリソースへのアクセスを委任する方法について説明します。 特定のアカウントにあるリソースを別のアカウントのユーザーと共有します。 このようにクロスアカウントアクセスを設定することで、お客様は、アカウントごとに IAM ユーザーを作成する必要がなくなります。 また、ユーザーは、異なる AWS アカウントにあるリソースにアクセスするために、あるアカウントからサインアウトして別のアカウントにサインインする必要がなくなります。 ロールを設定した後、AWS マネジメントコンソール、AWS CLI、API からロールを使用する方法について説明します。 IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。 たとえば、標準 aws パーティションの 米国西部 北カリフォルニア にアカウントがあるとします。 aws-cn パーティションの 中国 北京 にもアカウントがあります。 標準 aws アカウントで、中国 北京 のアカウントの Amazon S3 リソースベースのポリシーを使用して、ユーザーにアクセスを許可することはできません。 このチュートリアルでは、本番稼働用アカウントが、ライブアプリケーションを管理しているとします。 開発アカウントは、開発者やテスターが自由にアプリケーションをテストできるサンドボックスです。 各アカウントでは、アプリケーション情報が Amazon S3 バケットに格納されています。 開発アカウントの IAM ユーザーを管理しており、開発とテスターの 2 つの IAM グループがあるとします。 どちらのグループのユーザーにも、Development アカウントで作業し、そのリソースにアクセスするアクセス許可があります。 ときどき、開発者が Production アカウントのライブアプリケーションを更新する必要があります。 これらのアプリケーションは、 productionapp という Amazon S3 バケットに保存されます。 このチュートリアルを終了すると、次のようになります。 Production アカウントで特定のロールを引き受けることができる Development アカウント（信頼できるアカウント）のユーザー。 特定の Amazon S3 バケットへのアクセスを許可される Production アカウント（信頼するアカウント）のロール。 Production アカウントの productionapp バケット。 開発者は、AWS マネジメントコンソール でロールを使用して Production アカウントの productionapp バケットにアクセスできます。 さらに、ロールにより提供される一時的な認証情報によって認証された API 呼び出しを使用してバケットにアクセスすることもできます。 テスターがそのロールを使用して同様の操作を行うことはできません。 このワークフローには 3 つの基本的なステップがあります。 まず、AWS マネジメントコンソール を使用して Production アカウント ID 番号 999999999999 と Development アカウント ID 番号 111111111111 との間の信頼を確立します。 続いて、 UpdateApp という IAM ロールを作成します。 ロールの作成時に、Development アカウントを信頼されたエンティティとして定義し、信頼されたユーザーに productionapp バケットを更新する許可を与えるアクセス許可ポリシーを特定します。 チュートリアルのこのステップでは、IAM グループポリシーを変更して、テスターが UpdateApp ロールへのアクセスを拒否されるようにします。 このシナリオではテスターに PowerUser アクセス許可があるため、ロールの使用を明示的に拒否する必要があります。 最後に、開発者として、 UpdateApp ロールを使用して Production アカウントの productionapp バケットを更新します。 AWS コンソール、AWS CLI、API を使用してロールにアクセスする方法について説明します。 前提条件 このチュートリアルでは、以下を実行済みであることを前提としています。 ユーザー グループ アクセス許可 David 開発者 両方のユーザーが Development アカウントの AWS マネジメントコンソール にサインインして使用できます。 Theresa テスター• Production アカウントにはユーザーまたはグループを作成する必要はありません。 Production アカウントで作成された Amazon S3 バケット。 このチュートリアルでは ProductionApp と呼びますが、S3 バケット名はグローバルに一意である必要があるため、別の名前のバケットを使用する必要があります。 ステップ 1: ロールの作成 ある AWS アカウントのユーザーに別の AWS アカウントのリソースへのアクセスを許可できます。 これを行うには、ロールを作成し、そのロールにアクセスできるユーザーと、そのロールに切り替えるユーザーに付与するアクセス許可を定義します。 チュートリアルのこのステップでは、本番稼働用アカウントにロールを作成し、開発アカウントを信頼されたエンティティとして指定します。 また、ロールのアクセス許可を productionapp バケットでの読み書き専用に制限します。 ロールを使用するアクセス許可が付与されるすべてのユーザーは、 productionapp バケットに対する読み取りと書き込みを実行できます。 ロールを作成する前に、開発 AWS アカウントのアカウント ID が必要です。 アカウント ID は、各 AWS アカウントに割り当てられる固有の識別子です。 開発アカウントで使用できるロールを本番稼働用アカウントで作成するには• Production アカウントの管理者として AWS マネジメントコンソールにサインインし、IAM コンソールを開きます。 ロールを作成する前に、ロールに必要なアクセス許可を定義する管理ポリシーを準備します。 後の手順で、このポリシーをロールにアタッチします。 productionapp バケットの読み込みおよび書き込みのアクセスを設定します。 AWS には Amazon S3 管理ポリシーがありますが、1 つの Amazon S3 バケットへの読み取りおよび書き込みアクセス用には提供されていないため、代わりにポリシーを自作することができます。 左側のナビゲーションペインで、[ ポリシー]、[ ポリシーの作成] の順に選択します。 [ JSON] タブを選択し、以下の JSON ポリシードキュメントからテキストをコピーします。 JSON テキストボックスにこのテキストを貼り付け、リソース ARN arn:aws:s3:::productionapp を、S3 バケットに該当する実際の ARN に置き換えます。 GetObject、 PutObject、 DeleteObject アクセス許可によって、ユーザーは productionapp バケットの内容を表示、更新、および削除できます。 完了したら、[ ポリシーの確認] を選択します。 によって、構文エラーがある場合はレポートされます。 いつでも [ Visual editor ビジュアルエディタ ] タブと [ JSON] タブを切り替えることができます。 ただし、[ Visual editor ビジュアルエディタ ] タブで [ ポリシーの確認] を変更または選択した場合、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。 詳細については、「」を参照してください。 [ Review 確認 ] ページで、ポリシー名として「 read-write-app-bucket」と入力します。 ポリシーの [ Summary 概要 ] で、ポリシーによって割り当てられたアクセス許可を確認し、[ ポリシーの作成] を選択して作業を保存します。 新しいポリシーが管理ポリシーの一覧に表示されます。 左側のナビゲーションペインで、[ ロール]、[ ロールの作成] の順に選択します。 [ 別の AWS アカウント] ロールタイプを選択します。 [ Account ID アカウント ID ] で、開発アカウント ID を入力します。 このチュートリアルでは、開発アカウントにサンプルのアカウント ID 111111111111 を使用します。 有効なアカウント ID を使用してください。 使用しているアカウント ID が無効 111111111111 など の場合は、IAM で新しいロールを作成することはできません。 現時点では、ロールを引き受けるために、外部 ID や多要素認証 MFA は必要ありません。 従って、これらのオプションは選択していない状態にしておきます。 詳細については、「」を参照してください。 [ Next: Permissions 次へ: アクセス許可 ] を選択して、そのロールに関連するアクセス許可を設定します。 以前に作成したポリシーの横にあるチェックボックスを選択します。 [ フィルター] で、[ カスタマー管理ポリシー] を選択してリストをフィルター処理し、自分で作成したポリシーのみが含まれるようにします。 これにより、AWS が作成したポリシーが非表示になり、探しているポリシーを見つけるのが簡単になります。 その後 [ 次へ: タグ] を選択します。 オプション タグをキー - 値のペアとしてアタッチして、メタデータをユーザーに追加します。 IAM におけるタグの使用の詳細については、「」を参照してください。 次に、[ Next: Review] を選択し、ロール名に「 UpdateApp」と入力します。 オプション [ Role description] に、新しいロールの説明を入力します。 ロールを確認したら、[ ロールの作成] を選択します。 ロールのリストで、 UpdateApp ロールが表示されます。 ここで、ロールに固有の識別子である Amazon リソースネーム ARN を取得しなければいけません。 開発者グループやテスターグループのポリシーを変更するとき、アクセス許可を許可または拒否するためのロールの ARN を指定します。 UpdateApp の ARN を取得するには• IAM コンソールの [Navigation] ペインで [ Roles] を選択します。 ロールのリストで、[ UpdateApp] ロールを選択します。 詳細ペインの [ Summary 概要 ] セクションで、[ ロール ARN] の値をコピーします。 "本稼働用" アカウントでは、実際の AWS アカウント ID を指定してください。 この時点で、本番稼働用アカウントと開発用アカウント間の信頼が確立されました。 そのためには、開発用アカウントを信頼されたプリンシパルとして識別するロールを本番稼働用アカウントに作成します。 また、 UpdateApp ロールに切り替えるユーザーが何を実行できるかについても定義しました。 次は、グループのアクセス許可を修正します。 ステップ 2: ロールへのアクセスを許可する この時点では、Testers グループと Developers グループのメンバーにはいずれも、Development アカウントで自由にアプリケーションをテストできるアクセス権限があります。 ここでは、ロールの切り替えを許可するアクセス権限を追加するために必要なステップを示します。 UpdateApp ロールに切り替えることを許可するように Developers グループを変更するには• Development アカウントの管理者としてサインインし、IAM コンソールを開きます。 [ グループ]、[ Developers] の順に選択します。 [ Permissions アクセス許可 ] タブを選択し、[ インラインポリシー] セクションを展開したら、[ グループポリシーの作成] を選択します。 インラインポリシーがまだ存在しない場合、ボタンは表示されません。 代わりに、[To create one, click here. ] の最後にあるリンクを選択します。 [ カスタムポリシー] を選択してから、[ Select 選択 ] ボタンを選択します。 ポリシー名 allow-assume-S3-role-in-production など を入力します。 次のポリシーステートメントを追加して、Production アカウントの UpdateApp ロールに対する AssumeRole アクションを許可します。 必ず Resource 要素の PRODUCTION-ACCOUNT-ID を、Production アカウントの実際の AWS アカウント ID に変更してください。 どの開発者がこのロールにアクセスしようとしても成功します。 [ ポリシーの適用] を選択して、Developer グループにポリシーを追加します。 ほとんどの環境では、次の手順は通常必要ありません。 ただし、パワーユーザーアクセス権限を使用している場合、グループによってはロールを切り替えることができます。 次の手順は、ロールを引き受けることができないように Testers グループに "Deny" アクセス許可を追加する方法を示しています。 この手順が環境で必要ない場合は追加しないことをお勧めします。 「Deny」アクセス許可を追加すると、アクセス許可の全体的な状況が複雑になり、管理しづらくなります。 "Deny" アクセス権限は、他に良いオプションがない場合のみ使用してください。 UpdateApp ロールを引き継ぐためのアクセス権限を拒否するように Testers グループを変更するには• [ グループ]、[ Testers] の順に選択します。 [ Permissions アクセス許可 ] タブを選択し、[ インラインポリシー] セクションを展開したら、[ グループポリシーの作成] を選択します。 [ カスタムポリシー] を選択してから、[ Select 選択 ] ボタンを選択します。 ポリシー名 deny-assume-S3-role-in-production など を入力します。 次のポリシーステートメントを追加して、 AssumeRole ロールに対する UpdateApp アクションを拒否します。 必ず Resource 要素の PRODUCTION-ACCOUNT-ID を、Production アカウントの実際の AWS アカウント ID に変更してください。 そのロールにアクセスしようとするテスターは、アクセス拒否のメッセージを受け取ります。 [ ポリシーの適用] を選択して、テスターグループにポリシーを追加します。 これで、Developers グループは、Production アカウントの UpdateApp ロールを使用するためのアクセス許可を持つようになりました。 Testers グループは、 UpdateApp ロールを使用できません。 次に、開発者の David が本番稼働用アカウントの productionapp バケットにアクセスする方法について説明します。 David は、AWS マネジメントコンソール、AWS CLI、または AWS API からバケットにアクセスできます。 ステップ 3: ロールを切り換えてアクセスをテストする このチュートリアルの最初の 2 つのステップを完了した時点で、Production アカウントのリソースに対するアクセス権限を付与するロールがあります。 また、Development アカウントには、そのロールを使用できるユーザーで構成されたグループもあります。 このロールは使用可能になっています。 このステップでは、AWS マネジメントコンソール、AWS CLI、および AWS API のロールへの切り替えについて説明します。 ロールの切り替えは、IAM ユーザーまたはフェデレーティッドユーザーとしてサインインしている場合にのみ可能です。 さらに、Amazon EC2 インスタンスを起動してアプリケーションを実行すると、そのアプリケーションはそのインスタンスプロファイルを通じてロールを引き受けることができます。 AWS アカウントのルートユーザー としてサインインしているときに、ロールを切り替えることはできません。 ロールの切り替え コンソール David が AWS マネジメントコンソール で本稼働環境を操作する必要がある場合は、[ ロールの切り替え] を使用することができます。 アカウント ID またはエイリアスとロール名を指定すれば、David のアクセス権限は、ロールによって許可されているものに直ちに切り替わります。 次に、David はコンソールを使用して productionapp バケットを操作することができますが、本稼働環境の他のリソースは一切操作できません。 また、そのロール使用中に、開発用アカウントのパワーユーザーアクセス権限を使用することはできません。 これは、同時に有効にできるアクセス許可のセットは 1 つのみであるためです。 AWS マネジメントコンソールを使ったロールの切り替えは、 ExternalId を必要としないアカウントでのみ機能します。 たとえば、アカウントへのアクセス権を第三者に付与し、アクセス許可ポリシーの Condition 要素に ExternalId を要求するとします。 その場合、第三者は AWS API またはコマンドラインツールを使用してのみ、お客様のアカウントにアクセスできます。 第三者は ExternalId の値を指定できないため、コンソールを使用できません。 このシナリオの詳細については、『 AWS セキュリティブログ』の「」および「」を参照してください。 David が [ ロールの切り替え] ページに移動するには、2 つの方法があります。 David は事前定義されたロールの切り替え設定を指すリンクを管理者から受け取ります。 リンクは [ ロールの作成] ウィザードの最終ページ、またはクロスアカウントロールの [ ロールの概要] ページで管理者に提供されます。 このリンクを選択すると、[ ロールの切り替え] ページに移動します。 このページには、[ Account ID アカウント ID ] および [ ロール名] フィールドがすでに入力されています。 David は、[ ロールの切り替え] ボタンを選択するだけで作業は完了します。 管理者はメールでリンクを送信しませんが、代わりに [ Account ID アカウント ID ] 番号および [ ロール名] の値を送信します。 David は、手動でこれらを入力してロールを切り替える必要があります。 これを次の手順に示します。 ロールを割り当てるには• David は、開発用グループの通常のユーザーを使用して AWS マネジメントコンソール にサインインします。 管理者から受け取ったメールのリンクを選択します。 これにより、[ ロールの切り替え] ページに移動します。 このページには、アカウント ID、エイリアス、およびロール名情報がすでに入力されています。 —または— ナビゲーションバーのユーザー名 [ID] メニュー を選択してから、[ ロールの切り替え] を選択します。 David がこの方法で初めて [Switch Role スイッチロール ] ページにアクセスする場合は、初回アクセス用の [ Switch Role スイッチロール ] ページが表示されます。 このページでは、ロールを切り替えて AWS アカウント全体にわたるリソースを管理できるようにする方法についての追加情報が説明されます。 David がこの手順の残りを完了するには、このページの [ ロールの切り替え] ボタンを選択する必要があります。 次に、ロールにアクセスするために、David は Production アカウント ID 番号 999999999999 およびロール名 UpdateApp を入力する必要があります。 また、David は、現在アクティブなロール（および関連するアクセス許可）をモニタリングしたいと考えています。 この情報を追跡するために、[ Display Name 表示名 ] テキストボックスに「 PRODUCTION」と入力し、赤色のオプションを選択して、[ Switch Role スイッチロール ] を選択します。 これで、David は Amazon S3 コンソールを使用して、 UpdateApp ロールがアクセス許可を持つ Amazon S3 バケットなどのリソースを操作できます。 必要な作業を終了したら、David は元のアクセス権限に戻ることができます。 そのためには、ナビゲーションバーのロール表示名 [ PRODUCTION] を選択してから、[ Back to David 111111111111] を選択します。 David が次回にロールに切り替えるために、ナビゲーションバーの [Identity] メニューを選択すると、PRODUCTION エントリが前回からそのままになっています。 そのエントリを選択するだけで、アカウント ID とロール名を再入力することなく、すぐにロールに切り替えることができます。 ロールの切り替え AWS CLI David がコマンドラインで本稼働環境を操作する必要がある場合、 を使用してこの切り替えを行うことができます。 aws sts assume-role コマンドを実行し、ロールの ARN を渡して、そのロールの一時的なセキュリティ認証情報を取得します。 次に、環境変数でそれらの認証情報を設定し、それ以降の AWS CLI コマンドが、ロールのアクセス許可を使用して動作するようにします。 また、そのロール使用中に、開発用アカウントのパワーユーザーアクセス権限を使用することはできません。 同時に有効にできるアクセス許可のセットは 1 つのみであるためです。 すべてのアクセスキーとトークンは例にすぎず、実際にはそのように使用できないことに注意してください。 ライブ環境の適切な値に置き換えてください。 出力の [Credentials] セクションには、3 つの必要な情報が表示されます。 AccessKeyId• SecretAccessKey• SessionToken 以降の呼び出しでこれらのパラメータを使用するには、AWS CLI 環境を設定する必要があります。 認証情報を設定するさまざまな方法の詳細については、「」を参照してください。 セッショントークンの取得をサポートしていないため、 aws configure コマンドを使用することはできません。 ただし、設定ファイルに手動で情報を入力することができます。 これらは有効期限が比較的短い一時的な認証情報なので、現在のコマンドラインセッションの環境に追加するのが最も簡単です。 David は、環境に 3 つの値を追加するため、前のステップの出力を切り取り、次のコマンドに貼り付けます。 セッショントークン出力の改行の問題に対応するため、シンプルなテキストエディターで切り取りと貼り付けを行います。 ここではわかりやすくするために改行して表示されていますが、1 行の長い文字列として入力する必要があります。 David の場合は、 UpdateApp ロールです。 Production アカウントのリソースにアクセスするコマンドを実行します。 この例では、David は次のコマンドを使用して S3 バケットのコンテンツの一覧を示します。 その他の AWS サービスのリソースにアクセスするには、そのリソースを参照するために必要なコマンドと構文について記載されている対象サービスの AWS CLI のドキュメントを参照してください。 AssumeRole AWS API の使用 David は、コードから Production アカウントを更新する必要がある場合、 AssumeRole を呼び出し、 UpdateApp ロールを取得します。 この呼び出しは、David が Production アカウントにある productionapp バケットにアクセスするために使用できる一時的な認証情報を返します。 これらの認証情報を使用して、David は productionapp バケットを更新する API 呼び出しを行うことができます。 ただし、開発用アカウントのパワーユーザーアクセス権限を持っていても、本番稼働用アカウントの他のリソースにアクセスする API 呼び出しを行うことはできません。 ロールを割り当てるには• デイビッドは、アプリケーションの一部として AssumeRole を呼び出します。 AssumeRole 呼び出しからのレスポンスには、 AccessKeyId と SecretAccessKey を含む一時的な認証情報が含まれています。 また、認証情報の有効期限を示す Expiration 時間も含まれており、新しい認証情報をリクエストする必要があります。 一時的な認証情報を使用して、デイビッドは s3:PutObject 呼び出しを行い、 productionapp バケットを更新します。 David は、 AuthParams パラメータとして API 呼び出しに認証情報を渡します。 ロールの一時的な認証情報は productionapp バケットでの読み取りおよび書き込み専用のアクセスであるため、本番稼働用アカウントでの他のアクションは拒否されます。 コードの例 Python を使用 については、「」を参照してください。 関連リソース• IAM ユーザーおよびグループの詳細については、「」を参照してください。 Amazon S3 バケットの詳細については、『 Amazon Simple Storage Service 入門ガイド』の「」を参照してください。 信頼ゾーン 信頼できる組織またはアカウント 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「」を参照してください。 概要 これでクロスアカウント API アクセスのチュートリアルが終了しました。 他のアカウントと信頼を構築するロールを作成し、信頼されたエンティティが実行できるアクションを定義しました。 次に、どの IAM ユーザーがロールを取得できるのかを制御するグループポリシーを修正しました。 その結果、開発アカウントの開発者は、一時的な認証情報を使用して本番稼働用アカウントにある productionapp バケットを更新することができます。
次の
