309-AWS SAP AWS 「理論・実践・一問道場」sts:AssumeRole
sts:AssumeRole理論
AWSでのクロスアカウントアクセスとsts:AssumeRoleの基本
AWSで複数のアカウントを管理する際、特定のアカウントのユーザーが別のアカウントのリソースにアクセスするためには、
sts:AssumeRoleを使用します。以下にその重要なポイントを簡単に説明します。sts:AssumeRoleの基本
sts:AssumeRoleは、AWSのセキュリティトークンサービス（STS）が提供する操作で、あるIAMユーザーや役割が別の役割を引き受け、その役割の権限を一時的に得ることができます。
- この操作を通じて、ユーザーは別のアカウントのリソースにアクセスしたり、管理者がアクセス権を一時的に付与したりすることができます。
クロスアカウントアクセスを設定するための主な手順
- 信頼ポリシーの設定（ターゲット役割の設定）
- クロスアカウントアクセスを許可するため、ターゲット役割（例えば、Account Bの役割）の信頼ポリシーに、アクセスを許可するアカウントまたはユーザーを指定します。
例：
- アイデンティティポリシーの設定（ユーザーの設定）
- 元のアカウント（例えば、Account A）のユーザーに対して、
sts:AssumeRoleを実行するための権限を設定します。
例：
- 役割の引き受け
- ユーザーが
sts:AssumeRoleを実行して一時的なセキュリティトークンを取得し、ターゲットアカウントのリソースにアクセスできるようになります。
重要なポイント
- 信頼ポリシー：ターゲット役割の信頼ポリシーで、どのアカウントやユーザーが役割を引き受けられるかを定義します。
- アイデンティティポリシー：リクエスト元のユーザーや役割に、
sts:AssumeRoleを実行する権限を与える必要があります。
- 最小権限の原則：アクセスを必要最小限に抑えるように設定することがセキュリティ向上に繋がります。
sts:AssumeRoleを使う理由
- セキュリティ：一時的なアクセス権を付与することで、長期間のアクセス権の漏洩リスクを減らすことができます。
- 柔軟性：複数アカウント間でアクセスを制御するのに役立ちます。信頼ポリシーに基づいて細かいアクセス制御が可能です。
これらの手順と概念を理解しておくことで、AWS環境内で安全かつ効率的にリソースを管理できます。
実践
略
一問道場
Question #309
トピック 1
ある企業がAWS Organizationsを使用してマルチアカウント構成を採用しています。このアカウント構成の現在のセキュリティ設定には、SCP（サービスコントロールポリシー）、リソースベースポリシー、アイデンティティベースポリシー、トラストポリシー、セッションポリシーが含まれています。
ソリューションアーキテクトは、Account A のIAMユーザーが Account B のロールを引き受けることを許可する必要があります。
ソリューションアーキテクトがこの要件を満たすために実行する必要があるステップの組み合わせはどれですか？（3つ選択）
A. Account A のSCPを設定してアクションを許可する。
B. リソースベースポリシーを設定してアクションを許可する。
C. Account A のユーザーに対するアイデンティティベースポリシーを設定してアクションを許可する。
D. Account B のユーザーに対するアイデンティティベースポリシーを設定してアクションを許可する。
E. Account B のターゲットロールに対するトラストポリシーを設定してアクションを許可する。
F. セッションポリシーを設定してアクションを許可し、GetSessionToken API操作でプログラム的に渡すことを許可する。
解説:
IAMユーザーが別のアカウントのロールを引き受けるための設定手順
AWS Organizations内のマルチアカウント構成で、IAMユーザーが1つのアカウント（Account A）から別のアカウント（Account B）のロールを引き受けるには、以下の設定が必要です。
必須ステップの詳細
1. アイデンティティベースポリシーの設定 (選択肢C)
- 設定内容:
- Account A のIAMユーザーにアイデンティティベースポリシーを設定し、
sts:AssumeRoleアクションを許可する必要があります。 - このポリシーにより、IAMユーザーがAccount Bのロールを引き受けることが可能になります。
- 例: IAMユーザーのポリシー
2. トラストポリシーの設定 (選択肢E)
- 設定内容:
- Account B のターゲットロールにトラストポリシーを設定し、Account A のIAMユーザーまたはその所属アカウントを信頼するように設定します。
- トラストポリシーは、ロールの信頼関係を定義し、ロールを引き受けるエンティティ（ユーザーやアカウント）を指定します。
- 例: ターゲットロールのトラストポリシー
または、Account A 全体を信頼する場合:
3. SCPの設定 (選択肢A)
- 設定内容:
- Account A で適用されるSCP（サービスコントロールポリシー）が
sts:AssumeRoleアクションを明示的に許可するか、少なくともブロックしないように設定されている必要があります。 - SCPはOrganizations内のすべてのポリシーよりも優先されるため、許可を忘れるとポリシーの設定が無効になります。
- 例: SCPポリシー
他の選択肢について
B. リソースベースポリシーを設定する
- リソースベースポリシーはS3バケットなどに対して使用されるもので、IAMロールには適用されません。そのため、この選択肢は不適切です。
D. Account BのIAMユーザーにアイデンティティベースポリシーを設定する
- Account BでIAMユーザーを使用する要件は提示されておらず、ターゲットはロールの設定です。この選択肢は不要です。
F. セッションポリシーを設定する
- セッションポリシーは一時的な権限をさらに制限する場合に使用されますが、このケースでは特に要件として求められていません。
正解
- A. SCPの設定
- C. Account AのIAMユーザーにアイデンティティベースポリシーを設定
- E. Account Bのロールにトラストポリシーを設定
- Author:minami
- URL:https://www.minami.ac.cn/private-license/176d7ae8-88e2-80af-98ac-cfebbc4d16c8
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
Relate Posts
