废弃账号如何快速识别与清理？

在数字资产管理的日常运维中，废弃账户往往像潜伏在角落里的“影子员工”，看似无害却暗藏危机。它们不仅占用存储资源、混淆权限矩阵，更可能成为攻击者提权或横向移动的跳板。许多安全事件的事后复盘都指向一个被长期忽视的环节：未能及时识别并清理这些已失去实际意义的身份凭证。

定义“废弃”：不止是久未登录

识别废弃账户，首先要明确标准。单纯依据“最后登录时间”一刀切并不可靠。一个技术定义是：在特定时间段内（如90天或180天）没有任何主动交互行为，且其关联的业务功能已失效或责任人已变更的账户。交互行为包括登录、API调用、文件访问、权限变更等审计日志事件。 更精确的识别需要结合业务上下文。例如：

• 员工离职或转岗：其个人账户及因项目而创建的各类服务账号。
• 临时或测试账户：为特定短期任务（如压力测试、演示环境）创建的账户，任务结束后未被禁用。
• 僵尸应用账户：因应用下线、功能迭代而残留的后台服务账号。
• 权限冗余账户：同一用户拥有多个权限重叠的账户，通常只使用其中一个。

构建自动化识别流水线

手动核查账户清单效率低下且易遗漏。一个高效的识别流程应尽量自动化。

数据源聚合

你需要从多个系统拉取数据，进行交叉比对：

• 身份目录：如Active Directory, LDAP, 云身份提供商(IAM)的用户列表及属性（部门、职位、入职/离职日期）。
• 应用日志：核心业务系统、数据库、中间件的认证与访问日志。
• 网络设备日志：VPN、堡垒机的登录记录。
• 工单/HR系统：离职流程单据、权限申请记录。

将这些数据通过一个中央化的日志分析平台（如ELK Stack, Splunk）或安全信息与事件管理（SIEM）系统进行聚合。

设定识别规则与评分模型

基于聚合数据，可以设定规则引擎自动标记可疑账户。例如：

规则1：离职日期 > 90天 AND 最近登录时间 < 离职日期 → 高概率废弃
规则2：账户创建时间 > 180天 AND 登录次数 = 0 → 高概率废弃
规则3：过去30天内权限角色为“管理员”但0次登录 → 高风险告警

更高级的做法是引入评分模型，综合“最后活动时间”、“活动频率”、“权限等级”、“关联资源活跃度”等因素，为每个账户计算一个“废弃风险分数”，定期生成待审查列表。

执行清理：安全与审计并重

识别出目标账户后，清理动作需谨慎，避免误伤。

1. 通知与确认：对于疑似个人用户账户，应通过备用联系方式通知持有人，给予一段宽限期（如7天）进行确认或申领。自动化邮件通知需包含账户信息、判定依据和申诉链接。
2. 权限回收而非立即删除：直接删除账户可能破坏审计链条（历史操作记录需关联用户ID）。标准操作是：
3. 立即禁用认证（禁用密码、吊销访问令牌）。
4. 移除所有群组成员身份和直接分配的角色权限。
5. 将账户移至“禁用账户”组织单元（OU），并打上“Disabled”标签和禁用日期。
6. 归档与记录：在配置管理数据库（CMDB）或类似资产系统中更新账户状态。记录清理操作的人员、时间、原因（依据哪条规则），以备审计。
7. 最终删除策略：制定数据保留政策，规定禁用状态账户的保留期限（例如，财务系统保留7年以满足合规，测试系统保留180天）。到期后，由自动化脚本执行物理删除。

把清理变成持续运营

账户清理不应是每年一次的“大扫除”。将其融入日常运营流程更为关键：

• 入职/离职流程自动化：将账户的创建、禁用与HR流程强绑定，从源头上减少“孤儿账户”。
• 定期报告与问责：每月向各部门负责人发送其管辖范围内的闲置账户报告，要求确认或处理。
• 权限定期审阅：每季度或每半年，强制要求业务负责人审阅并确认其下属的所有账户权限是否仍然必要。

说到底，清理废弃账户是一场与熵增的持久战。它需要的不是复杂的工具，而是将“身份生命周期管理”这一理念，转化为可检查、可执行、可追溯的日常动作。当识别与清理的循环能够自动、平滑地运转时，整个系统的安全基线便悄然稳固了许多。