所有している別の AWS アカウント へのアクセス権を IAM ユーザーに提供 - AWS Identity and Access Management
個別の開発用アカウントと本稼働用アカウントを使用したシナリオ例詳細情報

所有している別の AWS アカウント へのアクセス権を IAM ユーザーに提供

IAM ユーザーには、AWS アカウント 内のロール、または所有する他の AWS アカウント で定義されたロールに切り替えるアクセス許可を付与することができます。

注記

お客様が所有または制御していないアカウントへのアクセス権を付与する場合は、このトピックの「第三者が所有する AWS アカウント へのアクセス権を付与する」を参照してください。

組織の業務に不可欠な Amazon EC2 インスタンスがあるとします。このインスタンスを終了するためのアクセス許可をユーザーに直接付与する代わりに、これらの権限を持つロールを作成できます。次に、インスタンスを終了する必要があるときに、このロールに切り替えることを管理者に許可します。これにより、インスタンスに次の保護レイヤーが追加されます。

  • ユーザーにロールを引き受けるアクセス権限を明示的に付与する必要があります。

  • ユーザーは、アクティブに AWS Management Console を使用してロールに切り替えるか、AWS CLI または AWS API を使用してロールを引き受ける必要があります。

  • MFA デバイスでサインインしているユーザーのみがロールを引き受けることができるように、ロールに多要素認証 (MFA) 保護を追加できます。ロールを引き受けるユーザーが最初に多要素認証 (MFA) を使用して認証されるようにロールを設定する方法については、「MFA 保護 API アクセスの設定」を参照してください。

このアプローチを使用して最小権限の原則を強制することをお勧めします。つまり、昇格されたアクセス許可の使用は、特定のタスクに必要なときのみに制限されます。ロールを使用すると、機密性の高い環境が誤って変更されるのを防ぐことができます (特に、ロールが必要なときだけ使用されるように監査と組み合わせている場合)。

この目的でロールを作成する場合、ユーザーがロールの信頼ポリシーの Principal 要素にアクセスする必要のあるアカウントを ID で指定します。その後、その他のアカウントの特定のユーザーに、そのロールに切り替えるためのアクセス権限を付与できます。信頼ゾーン (信頼できる組織またはアカウント) 外にあるアカウントのプリンシパルにロールを引き受けるアクセス権があるかどうかについては、「IAM Access Analyzer とは」を参照してください。

あるアカウントのユーザーは、同じアカウントまたは別のアカウントのロールに切り替えることができます。そのロールを使用している間、ユーザーはアクションだけを実行して、ロールによって許可されているリソースのみにアクセスできますが、元のユーザーアクセス権限は停止されます。ユーザーがそのロールを終了すると、元のユーザーのアクセス権限に戻ります。

個別の開発用アカウントと本稼働用アカウントを使用したシナリオ例

本稼働環境から開発環境を分離するための複数の AWS アカウント が組織に存在するとします。開発アカウントのユーザーは、本番稼働用アカウントでリソースにアクセスすることが必要になる場合があります。たとえば、開発環境から本番稼働環境に更新を昇格させる場合、クロスアカウントアクセスが必要になることがあります。両方のアカウントで作業するユーザーにそれぞれの ID（およびパスワード）を作成することも可能ですが、複数のアカウントに対する複数の認証情報を管理する必要があり、ID 管理が困難になります。以下の図では、すべてのユーザーは開発用アカウントで管理されていますが、数名の開発者は本稼働用アカウントに制限付きでアクセスする必要があります。開発用アカウントにはテスターと開発者の 2 つのグループがあり、それぞれ個別のポリシーがあります。

ロールを使用して別のアカウントのユーザーにアクセス権限を委任する

  1. 管理者は、本番稼働用アカウントで IAM を使用し、このアカウントで UpdateApp ロールを作成します。ロールでは、管理者は開発用アカウントを Principal として指定する信頼ポリシーを定義します。これは、開発用アカウントの認証されたユーザーが UpdateApp ロールを使用できることを意味します。また、管理者は、productionapp という Amazon S3 バケットに対する読み取りと書き込みを指定するロールについてのアクセス許可ポリシーを定義します。

    次に、管理者は、このロールを引き受ける必要がある任意のユーザーと該当情報を共有します。この情報は、ロールのアカウント番号と名前 (AWS コンソールユーザーの場合)、または Amazon リソースネーム (ARN) (AWS CLI または AWS API アクセスの場合) です。ロールの ARN は arn:aws:iam::123456789012:role/UpdateApp のようになります。これは、ロールの名前が UpdateApp で、ロールがアカウント番号 123456789012 に作成されたことを意味します。

    注記

    管理者は、ロールを引き受けるユーザーが最初に多要素認証 (MFA) を使用して認証されるように、オプションでロールを設定できます。詳細については、「MFA 保護 API アクセスの設定」を参照してください。

  2. 開発アカウントでは、管理者は開発者グループのメンバーに対して、このロールに切り替えるアクセス許可を付与します。これは、Developers グループに AWS Security Token Service（AWS STS）UpdateApp ロールの AssumeRole API を呼び出すアクセス権限を付与することで行われます。これにより、開発用アカウントの Developers グループに所属する IAM ユーザーは、本稼働用アカウントの UpdateApp ロールに切り替えることができます。Developers グループに所属しないの他のユーザーには、そのロールに切り替えるアクセス許可がないため、本番稼働用アカウントの S3 バケットにはアクセスできません。

  3. ユーザーは、ロールへの切り替えをリクエストします。

    • AWS コンソール: ユーザーはナビゲーションバーのアカウント名を選択してから、[ロールの切り替え] を選択します。ユーザーは、アカウント ID（またはエイリアス）とロール名を指定します。または、管理者からメールで送信されたリンクをクリックすることもできます。リンクをクリックすると、詳細がすでに入力された [ロールの切り替え] ページに移動します。

    • AWS API/AWS CLI: 開発用アカウントの Developers グループに所属するユーザーが AssumeRole 関数を呼び出し、UpdateApp ロールの認証情報を取得します。呼び出しの一部として、ユーザーが UpdateApp ロールの ARN を指定します。Testers グループのユーザーが同じ要求をしても、テスターは UpdateApp ロールの ARN に対して AssumeRole を呼び出すことは許可されていないため、その要求は拒否されます。

  4. AWS STS が一時的な認証情報を返します。

    • AWS コンソール: AWS STS はリクエストをロールの信頼ポリシーと照合し、そのリクエストが信頼されたエンティティ (開発用アカウント) からであることを確認します。照合の後、AWS STS は AWS コンソールに一時的セキュリティ認証情報を返します。

    • API/CLI: AWS STS は、リクエストをロールの信頼ポリシーと照合し、信頼されたエンティティ (Development アカウント) からであることを確認します。照合の後、AWS STS はアプリケーションに一時的セキュリティ認証情報を返します。

  5. 一時的な認証情報により、AWS リソースにアクセスすることができます。

    • AWS コンソール: AWS コンソールは、後続のすべてのコンソールアクション (この場合は、productionapp バケットの読み書き) でユーザーの代わりに一時的な認証情報を使用します。コンソールは、本稼働用アカウントにある他のリソースにはアクセスできません。ユーザーがロールを終了すると、ユーザーのアクセス権限がロールに切り替える前に持っていた元のアクセス権限に戻ります。

    • API/CLI: アプリケーションは、その一時的な認証情報を使用して productionapp バケットを更新します。一時的な認証情報を使用し、アプリケーションは productionapp バケットでのみ読み書きを行うことができますが、本番稼働用アカウントにあるその他のリソースにはアクセスできません。アプリケーションは、ロールを終了する必要はありませんが、その代わりに一時的な認証情報の使用を停止し、後続の API 呼び出しで元の認証情報の使用する必要があります。

詳細情報

詳細については、次を参照してください。