1. IAM 用户清单导出与治理基线盘点
为什么先做用户清单盘点
IAM 治理的第一步不是改权限，而是把"人"这个主体盘清楚。用户清单是后续角色梳理、策略审计、权限收敛的共同底座。本案例的目标是从 IAM 系统导出全量用户清单，补齐状态、创建时间、最后登录时间、负责人等字段，建立一份可复用的治理基线，并据此识别长期未登录、无负责人等异常账号。
导出字段与治理基线结构
从 IAM 控制台或 API 导出用户时，至少需要以下字段才能支撑治理判断。不同云厂商字段名略有差异，但语义一致：
| 字段 | 含义 | 治理用途 |
|---|---|---|
| user_name | 用户登录名 | 唯一标识 |
| user_id | 系统内部唯一 ID | 关联策略、密钥 |
| status | active / inactive / locked | 识别停用未清理账号 |
| create_date | 账号创建时间 | 识别新建未纳管账号 |
| last_login | 最后登录时间 | 识别长期未登录 |
| owner | 负责人 / 归属团队 | 识别无负责人账号 |
| mfa_enabled | 是否启用多因素 | 识别弱认证账号 |
导出时优先使用 API 而非控制台截图，便于批量处理和定期复跑。若只能从控制台导出 CSV，注意时间字段的时区是否统一。
治理基线判定规则
把导出数据整理成基线表后，用以下规则打标。规则阈值可根据组织安全策略调整，这里给出教学示例值：
- 长期未登录：last_login 距今超过 90 天，或从未登录（last_login 为空）。
- 无负责人：owner 字段为空或为默认占位值（如 unknown、N/A）。
- 停用未清理：status 为 inactive 或 locked，但账号仍存在。
- 弱认证：mfa_enabled 为 false 且 status 为 active。
从导出到异常清单的关键处理
导出原始数据后，需要做三步处理才能得到可用的治理基线：
- 字段标准化：统一时间格式（建议 ISO 8601 UTC），把空值统一为 NULL，避免"从未登录"和"字段缺失"混淆。
- 打标计算：对每条记录计算
days_since_login = now - last_login，并按规则打上异常标签。 - 排序与输出：按异常类型和严重度排序，输出账号名、异常类型、最后登录时间、负责人、建议动作五列。
教学示例：假设导出 5 条用户记录，处理结果如下（示例数据，非真实运行结果）：
| user_name | status | last_login | owner | 异常标签 |
|---|---|---|---|---|
| alice | active | 2024-06-01 | team-a | 无 |
| bob | active | 2023-01-15 | team-b | 长期未登录 |
| carol | inactive | 2023-11-20 | NULL | 停用未清理 + 无负责人 |
| dave | active | NULL | NULL | 从未登录 + 无负责人 |
| eve | active | 2024-05-10 | team-c | 弱认证（MFA 未启用） |
验证与复跑
基线建立后，用两个动作验证其有效性：
- 交叉核对：随机抽取 3 个被标记为"长期未登录"的账号，回到 IAM 控制台确认其最后登录时间与导出数据一致。
- 复跑对比：下个月再次导出，对比异常账号数量是否下降。若某类异常持续增长，说明对应的治理动作未落地。
注意：导出数据包含账号名、登录时间等敏感信息，应存放在受控目录，避免通过邮件或即时通讯工具明文传输。建议导出后立即计算哈希并记录，便于后续校验数据完整性。