临时账号管理须坚持“按需发放、限时可用、自动回收”，核心在于流程闭环、权限最小化与操作可追溯；需明确适用场景、双人审批、≤72小时有效期、禁用高危权限、自动化生命周期管控、强制密钥认证、全面权限回收及180天完整审计。
临时账号管理的核心是“按需发放、限时可用、自动回收”，关键不在技术难度，而在于流程是否闭环、权限是否最小化、动作是否可追溯。
明确临时账号的适用场景和审批规则
不是所有短期访问都需要建账号。开发联调、第三方运维、紧急故障排查等场景才应启用临时账号；内部员工常规工作不应走临时通道。必须设定硬性审批环节：申请人提交用途、时长、所需权限清单，由系统负责人+安全管理员双签批准，审批记录存入审计日志。
- 单次有效期建议≤72小时，最长不超过7天
- 禁止授予 root / Administrator 或 sudo ALL 权限，仅开放必要目录、命令、端口
- 账号命名须含标识，如 tmp-dev-张三-20260607 或 ext-mysql-audit-20260607
用自动化工具实现创建与到期自动禁用
手动删账号极易遗漏，必须依赖系统能力保障时效性。Linux 可结合 useradd -e（指定过期日期）+ PAM time限制；Windows 域环境用 Group Policy 设置账户过期时间。更推荐统一接入身份平台（如 JumpServer、Keycloak 或自建 OAuth2+RBAC 服务），账号创建即绑定生命周期策略，到期前1小时自动发邮件提醒，到期后秒级冻结登录能力（SSH / RDP / Web 控制台全部失效）。
- 所有临时账号必须强制启用 SSH key 登录，禁用密码认证
- 若使用堡垒机，确保会话录像、命令审计、键盘记录全开启
- 避免在脚本中硬编码账号信息，改用动态凭证（如 HashiCorp Vault 签发短期 token）
权限回收要覆盖“显性”与“隐性”入口
停用账号只是第一步。还需同步清理其留下的权限痕迹：删除 sudoers 中的例外条目、撤回数据库白名单 IP 和账号授权、关闭关联的 API Key 或云平台子用户 AccessKey、移除其加入的 Linux 用户组（如 docker、wheel）。特别注意 CI/CD 流水线配置、定时任务（crontab）、systemd service 文件里可能残留的账号调用。
- 回收操作完成后，执行 getent passwd | grep tmp- 和 sudo -lU 用户名 快速验证
- 每周跑一次权限巡检脚本，比对账号列表与 sudoers / db grants / cloud IAM 等策略源
- 对高危操作（如删除数据库账号）设置二次确认或 require MFA 才能执行
保留完整审计线索并定期复盘
每次临时账号的申请、审批、登录、操作、回收，都应形成时间戳一致、来源可溯的日志链。日志至少留存180天，且不可被账号本人修改或删除。每月抽样检查5%的已回收账号，验证其生命周期是否真实闭环、权限是否彻底清除、是否存在越权行为。
- 日志字段至少包含：申请人、审批人、服务器IP、登录时间、命令历史、回收触发方式（自动/手动）、回收时间
- 将临时账号滥用事件纳入安全事件响应预案，例如发现某账号在过期后仍登录，立即触发告警并隔离主机
- 每季度输出《临时账号治理报告》，统计平均存活时长、超期率、高频申请部门、TOP 权限类型
