如何将STS临时AccessKey映射到跨账号切换角色的真实IAM用户

核心思路 #

跨账号角色切换时，账号B的CloudTrail会记录两个关键事件：AssumeRole（角色切换动作）和StartSession（SessionManager启动动作），通过关联这两个事件的临时AccessKeyId，就能找到原始IAM用户信息。

具体步骤 #

• 步骤1：提取AssumeRole事件中的关联信息
  在账号B的CloudTrail日志中筛选AssumeRole事件，找到对应会话的记录：

  • 从userIdentity.arn字段获取账号A的原始IAM用户ARN（格式类似arn:aws:iam::账号AID:user/真实用户名）
  • 记录responseElements.credentials.accessKeyId字段的临时AccessKeyId

• 步骤2：关联SessionManager的StartSession事件
  在账号B的CloudTrail中筛选StartSession事件（对应CLI访问SessionManager的操作），找到目标会话的userIdentity.accessKeyId字段，将其与步骤1的临时AccessKeyId匹配，即可对应到原始IAM用户。

• 步骤3：确保CloudTrail配置正确
  确认账号B的CloudTrail已启用全局服务事件（包含STS服务），否则无法捕获跨账号的AssumeRole操作日志。

批量查询方案（用Athena） #

如果需要批量处理日志，可通过AWS Athena编写SQL查询直接关联两类事件：

SELECT
  -- 原始IAM用户信息
  assume.userIdentity.arn AS original_user_arn,
  -- 临时AccessKeyId
  start_session.userIdentity.accessKeyId AS temp_access_key,
  -- SessionManager会话ID
  start_session.responseElements.sessionId
FROM
  your_cloudtrail_athena_table assume
JOIN
  your_cloudtrail_athena_table start_session
ON
  assume.responseElements.credentials.accessKeyId = start_session.userIdentity.accessKeyId
WHERE
  assume.eventName = 'AssumeRole'
  AND start_session.eventName = 'StartSession'
  AND start_session.userIdentity.type = 'AssumedRole'

关键注意事项 #

• 临时AccessKeyId仅在角色会话有效期内有效，但CloudTrail日志会长期保留（取决于你的日志存储策略），过期后仍可通过日志回溯关联。
• 账号A的CloudTrail也会记录该AssumeRole事件，可用于交叉验证原始用户信息。

内容的提问来源于stack exchange，提问作者Seff