クロスアカウントアクセス（IAMロール）難易度 標準無料
アカウントA（111111111111）の分析チームが、アカウントB（222222222222）が所有するS3バケットへプログラムから継続的にアクセスする必要がある。要件は次の3点である。
- 長期のアクセスキーを発行・共有しない
- 付与する権限は当該バケットへの読み取りのみに限定する（最小権限）
- 誰が・いつアクセスしたかを CloudTrail で追跡できる
この要件を満たす設計として最も適切なものを選べ。（単一選択）
- AアカウントBに、対象バケットの読み取り専用ポリシーを付けたIAMロールを作成し、信頼ポリシーでアカウントAからの
sts:AssumeRoleを許可する。アカウントAはこのロールを引き受けて一時認証情報でアクセスする - BアカウントBにアカウントA専用のIAMユーザーを作成し、そのアクセスキーIDとシークレットアクセスキーをアカウントAのチームへ共有して使わせる
- C対象のS3バケットをパブリック読み取り可能に設定し、アカウントAのアプリケーションが認証なしでオブジェクトを取得できるようにする
- DアカウントAとアカウントBの双方に同じ内容のIAMユーザーを個別に作成し、パスワードポリシーだけ統一して運用する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
クロスアカウントで一時的かつ監査可能なアクセスを実現する標準パターンは、アカウントBにIAMロールを作成し、
そのロールの信頼ポリシー（trust policy）でアカウントA（またはアカウントA内の特定プリンシパル）を
sts:AssumeRole できるプリンシパルとして許可することである。
- ロールのアクセス許可ポリシーには、対象バケットへの
s3:GetObject/s3:ListBucketのみを許可する最小権限のポリシーを付与する。 - アカウントAのユーザー/アプリケーションは
sts:AssumeRoleを呼び出し、有効期限付きの一時的セキュリティ認証情報（アクセスキーID・シークレットキー・セッショントークン）を取得して利用する。 AssumeRoleの呼び出し自体・および発行された一時認証情報でのAPI呼び出しはCloudTrailに記録され、誰がいつどのロールを引き受けてアクセスしたかを追跡できる。
これにより長期キーの管理・ローテーション負担を避けつつ、最小権限と監査性を同時に満たせる。
- B長期のアクセスキーを発行・共有することになり、要件の「長期キーを共有しない」に反する。漏えい時の失効・ローテーションも運用負荷が高い。
- C不特定多数からアクセス可能になり最小権限に反する。誰がアクセスしたかの主体識別もできず監査要件も満たさない。
- Dアカウントをまたぐアクセスの委譲になっておらず、ユーザーの二重管理が発生する。長期認証情報の共有問題も解決しない。
ひっかけ： 「IAMユーザーを作ってアクセスキーを共有する（B）」という一見手早い方法は、長期認証情報の漏えいリスクとローテーション負担を抱える。
また「バケットを公開設定にする（C）」は要件の最小権限・監査性のいずれも満たさない。一時認証情報＋ロール引き受け＝クロスアカウントの定石であることを押さえる。
公式ドキュメント・関連IAM User Guide ― Providing access to AWS accounts owned by third parties↗STS API Reference ― AssumeRole↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）