AWS Organizations / SCP条件キー活用難易度 高無料
組織のセキュリティチームは、クロスアカウントでロールを引き受けて作業する運用者について、「誰が実際にそのロールを使って操作したか」をCloudTrailログ上で個人単位まで追跡できるようにしたい。現状はロール名（例：BreakGlassAdminRole）でしかログに残らず、複数人が同じロールを使い回すと個人特定ができない。この要件を満たす設計として最も適切なものを選べ。（単一選択）
- A
sts:AssumeRole呼び出し時にSourceIdentityパラメータへ個人識別子を設定させ、それ以降のすべてのAPI呼び出しのCloudTrailログに引き継がれるようにする。SCPでSourceIdentity未設定のAssumeRoleを拒否するガードレールも併用する - BCloudTrailのデフォルトログに記録される
assumedRoleUserのロール名だけで、個人ごとの操作を十分に特定できるため追加設定は不要である - C運用者ごとに個別のIAMユーザーを作成し、共有ロールの使用自体を廃止して、各自のIAMユーザーの認証情報を直接使わせる
- Dロールのセッション名（
RoleSessionName）にランダムなUUIDを設定し、UUIDと申請書を突き合わせて事後に個人を特定する運用にする
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
複数人で共有するIAMロールを使う場合、CloudTrailのデフォルトのログには引き受けたロール名（assumedRoleUser）は残るが、
「元々誰がそのロールを引き受けたか」という個人識別情報は残らないのが課題になる。この課題を解決するのが
STSのSourceIdentity機能である。
sts:AssumeRole呼び出し時にSourceIdentityパラメータ（例：社員のログインIDやメールアドレス）を渡すと、 ロールを引き受けた後のすべてのAPI呼び出しのCloudTrailログに、このSourceIdentityの値が記録され続ける （ロールの多段引き受け＝ロールチェイニングをしても伝播する）。- これにより、複数人が同じ共有ロールを使っていても、個々のAPI呼び出しがどの個人に紐づくかをログから特定できる。
- ロールの信頼ポリシーで
sts:SetSourceIdentityアクションを許可しておく必要があり、 かつSCP等で「SourceIdentityが設定されていないAssumeRoleを拒否する」ようなガードレールを組み合わせることで、 設定漏れによる追跡不能な引き受けを防止できる。
- B誤り。
assumedRoleUserはロール（セッション名含む）の情報にとどまり、共有ロールを使い回す場合は個人まで一意に特定できない。SourceIdentityの明示設定が必要。 - C一時的な共有ロール運用（Break-glass的な特権昇格）を廃止すると、最小権限・監査・ローテーションの観点でのメリットが失われる可能性があり、要件（個人追跡の実現）に対しては過剰かつ別の運用課題を生む。
- DランダムなUUIDは申請書との突合という手動プロセスに依存し自動化されず、また改ざん・偽装のリスクもある。AWSネイティブに個人識別情報をログへ伝播させる
SourceIdentityの方が堅牢。
ひっかけ： 「CloudTrailのデフォルトログだけで個人特定は十分できる（誤答の1つ）」という誤解に注意。
共有ロールのユースケースでは
SourceIdentityを明示的に設定しない限り、個人までは追跡できない
（ロール名は記録されるが、それを引き受けた「元の人物」の情報は別途伝播させる必要がある）。AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）