特权账号的风险不在“有权限”，而在“用了没人知道”
运维人员、第三方厂商、系统管理员手里的特权账号，是攻击者最想拿到的目标——拿到它，就不需要再找漏洞。但在多数单位里，特权账号恰恰是管理最松的一类资产：共用、口令长期不改、用完不回收、操作无记录。
一个关键的认知转变是：特权账号的风险不在于它权限高，而在于它被使用时没有观察者和约束。 因此特权账号管理的目标不是“把权限收小”（那会影响业务），而是让每一次特权操作都可授权、可观察、可回溯。
四个控制点
账号纳管。先解决“有哪些特权账号”这个最基本的问题。要重点清理三类：离职与转岗人员遗留的孤儿账号、多人共用的共享账号、以及系统内置但从未管理的默认账号。纳管之后，口令交由系统集中托管并自动轮换，停止人工记忆与手工传递。
统一认证。特权访问应经过统一入口并启用多因子认证。更进一步的做法是按工单临时授权：平时不给权限，需要运维时凭工单开通、事后自动回收。这样即使凭证泄露，攻击窗口也被压缩到工单有效期内。
会话管控。通过协议代理接管运维会话，对高危命令做实时识别与拦截。这一层要特别注意“不能只审计不阻断”——只记录不阻拦，等于事故发生后才有价值。同时要保证代理自身的健壮性，避免成为新的单点。
操作审计。全程录像加命令级日志，做到能回放“谁在什么时间对哪台设备执行了什么”。审计数据的完整性很重要：日志与录像应当集中存储、与操作者权限分离，防止被操作者本人删除。
工控与关基场景的特殊约束
在工业控制与关键信息基础设施场景里，直接套用 IT 侧的 PAM 方案会踩坑，需要额外考虑三点：
- 可用性优先：运维代理不能因为自身故障阻断对生产系统的正常运维，必须可旁路、可降级；
- 协议兼容：大量工控设备只支持私有协议或串口访问，代理层需要支持协议适配，而不是只覆盖 SSH/RDP；
- 谨慎改口令：部分老旧设备强制改密可能导致服务异常，需要先在测试环境验证，并保留回退方案。
常见的落地缺口
- 只纳管了服务器账号，漏掉网络设备、安全设备、数据库与工控设备；
- 第三方远程运维走的是单独开通的 VPN，绕过了 PAM 体系；
- 口令自动轮换覆盖不全，仍有口令写在脚本或配置文件里；
- 审计日志保留期过短，或与业务日志混存，事后无法独立取证。
一句话总结：特权账号管理的验收标准不是“装了一套系统”，而是随便抽一次特权操作，都能回答出“谁授权的、做了什么、有没有越界”。