一、为什么"人离职、机器人不退"会成为凭据治理黑洞

过去十年，企业身份管理的重心一直在"人"身上：招聘时开账号、调岗时改权限、离职时禁用目录账号。这套流程在纯人工办公时代基本够用。但当生产环境里跑着大量自动化脚本、RPA 流程机器人、数据同步任务、对外部系统调用的 API 令牌时，问题开始变形。

一个真实场景是：财务共享中心的小张离职了，HR 在人力资源系统里标记离职，IT 在域控里禁用了他的域账号。看上去人走茶凉，凭据已回收。但小张在职时为了方便每日对账，把一套金蝶系统的共享账号密码写进了 RPA 机器人的配置文件里，又把一张可长期刷新的 API 令牌放在了定时任务的環境变量中。小张走后，机器人照常每天凌晨两点登录金蝶拉取报表，API 令牌照常调用接口——这些行为的"主体"名义上还是那套共享账号，可没人说得清它到底代表小张本人、代表财务组的某个角色、还是代表一台无人认领的机器。

这就是"人离职、机器人不退"的本质：凭据的归属对象不是人，而是某种持续运行的非人实体，而人的离职事件并没有触发非人实体凭据的回收链路。当审计要追问"这笔异常登录取自谁"时，答案是一个共享账号，而共享账号背后已经没有在册的员工，于是责任归属落空。

从治理视角看，这类问题的根因有四条：

1. 员工凭据与服务账号凭据混在同一个保险箱里，没有生命周期边界；
2. 机器人、API 令牌这类非人身份没有明确的"责任人"字段，归属不清；
3. 离职编排只动了人，没有编排"人名下的非人凭据"；
4. 审计日志只记"哪个账号做了什么"，没有把行为回溯到"当时操作的员工或授权人"。

下文逐一拆解。

二、服务账号与员工账号：两条不同的凭据生命周期

要治理，先要承认一个事实：服务账号（机器人、自动化任务、API）和员工账号（自然人登录）是两种生命周期形态完全不同的凭据，不能用同一套策略管理。

维度	员工账号凭据	服务账号凭据
生命周期起点	入职，由 HR/IT 触发开通	业务上线或系统集成时创建
持有主体	自然人，有真实身份与工号	非人实体，无工号，仅有逻辑标识
使用频率	工作日规律使用，存在明显空窗	长期在线或定时触发，7×24 不停
下线触发	离职、调岗、长期休假	业务下线、接口废弃、责任人变更
审计归属	可自然归属到工号	默认只能归属到账号本身，需额外挂接责任人
轮换策略	可随密码策略定期改密	更应自动化轮换，且需零停机切换
典型风险	弱口令、复用口令、离职权限残留	令牌长期不换、责任人悬空、失陷后横向移动

最关键的差异在最后两行：员工凭据可以靠"人"这个强身份来锚定责任，而服务凭据天然没有责任人，必须人工补一个"归属人"字段。一旦这条归属链断裂，机器就真的"无人认领"了。

共享账号是这条对比表里最容易被忽略的第三类。它既不是纯粹的员工账号，也不是纯粹的服务账号，而是"多个自然人共享同一个秘密"的结构。制造产线的值班账号、电商客服外包的工单后台账号、供应链协同里的供应商查询账号，都属于这一类。它们的危险不在于密码强度，而在于秘密的扩散面：一个人离职，密码不会自动失效，只要他还记得那串字符，就能在任何一台设备上继续登录。这意味着共享账号不能简单地套用员工账号的"禁用"逻辑，也不能套用服务账号的"轮换"逻辑，而必须引入代填与授权两个机制，让密码始终留在保险箱里，让"谁能登"由授权矩阵决定，而非由"谁知道密码"决定。把共享账号单列一类，是凭据分类建模里最容易被低估的一步。

另外要注意共享账号这一特殊形态：它表面上是给员工用的，实际被一个小组甚至一个团队轮流使用，比如车企研发外包团队共用的代码仓库账号、电商客服外包团队共用的后台工单账号。它既不是纯粹的员工账号，也不是纯粹的服务账号，而是"多人对一个秘密"的结构，最容易出现密码明文散落、离职后还能登录的情况。共享账号管理因此必须单独对待，核心动作是让密码不落地、让每次使用可审计。

三、机器人身份如何归属：从"谁在用"到"谁拥有"

很多团队把服务账号当成"匿名工具"，只在配置文件里放一个账号密码，既不登记主人，也不登记用途。等到出事，谁也说不清这个机器人归哪个组、出于什么业务需要存在。

治理的第一步，是建立一张服务身份登记表，把每一个非人实体映射到一个明确的责任人（通常是创建它的员工或其直属主管），并标注业务目的与预计生命周期。

一个最小可用的登记结构如下：

{
  "bot_id": "fin-rpa-reconcile-01",
  "display_name": "财务对账RPA",
  "owner_employee_id": "E10231",
  "backup_owner": "E10877",
  "business": "每日银行流水与金蝶报表对账",
  "target_system": "金蝶",
  "secret_id": "vault://fin/kd-shared",
  "created_at": "2025-03-11",
  "review_due": "2026-03-11",
  "status": "active"
}

这里有三个要点：

• owner_employee_id 是强约束，机器人必须挂在一个在职员工名下，不能是空值；
• backup_owner 是容灾，防止唯一责任人离职后机器人变成孤儿；
• review_due 是定期复核，强迫业务方确认这个机器人还有没有必要存在。

归属的本质，是把"非人实体的行为"绑定到"人"。当 owner 离职时，编排系统应当把 owner_employee_id 先转移给 backup_owner 或主管，再继续后续动作，而不是让机器人直接失主。这正是分离治理的核心动作：人走了，机器人的归属要有人接，而不是让机器人自己消失或自己悬空。

这里还藏着一个组织治理的细节：机器人的归属人不能随意填，应当是可被验证的在册员工，且最好与其业务职责一致。实践中常出现两种偏差，一是把归属挂在某个已经长期不实际负责该业务的"元老"名下，导致复核流于形式；二是把一批机器人统一挂在一个共享的"服务账号"名下，等于用一个新的非人实体去归属另一个非人实体，责任链再次断掉。正确的做法是归属必须落到自然人工号，且复核时由直属主管或备份归属人确认业务仍在运行。对跨部门、跨外包的机器人，还应要求创建时附带一段业务说明与预计下线时间，让归属从"登记"那一刻起就带有生命周期预期，而不是无限期挂账。

在供应链审核场景里这一点尤其重要。外包人员使用期结束后，其名下的服务账号、接口令牌必须随归属转移或立即失效，否则审核链路会被一个早已不在册的外包身份长期穿透。

四、员工离职后的凭据回收编排

真正能被审计、能被复盘的回收，不是"手动改几个密码"，而是一段可被机器执行的编排流程（orchestration）。它把"员工离职"这个事件，翻译成一连串确定性的凭据动作。

一个可落地的编排逻辑（伪代码）如下：

# 离职凭据回收编排（演示用伪代码）
class OffboardOrchestrator:
    def recycle(self, employee_id):
        # 1. 冻结该员工本人所有直接凭据
        self.iam.suspend_user(employee_id)

        # 2. 检索该员工名下归属的服务账号 / 机器人 / API 令牌
        items = self.registry.find_owned_by(employee_id)

        for item in items:
            # 3. 立即轮换秘密，使旧凭据失效（零停机由新凭据承接）
            self.vault.rotate_secret(item.secret_id)

            # 4. 转移归属：优先 backup_owner，其次直属主管
            new_owner = item.backup_owner or self.orgchart.manager_of(employee_id)
            self.registry.transfer_ownership(item, new_owner)

            # 5. 写审计：谁、何时、哪个号、做了什么
            self.audit.log(
                event="credential_recycled",
                actor="offboard_pipeline",
                human_ref=employee_id,
                bot=item.bot_id,
                new_owner=new_owner,
                ts=now()
            )

        # 6. 回收该员工作为共享账号"授权使用人"的资格
        self.share.unbind_user_from_all_shared(employee_id)

这段编排的价值在于三点：第一，服务账号不随员工直接删除，而是先轮换秘密再转移归属，保证业务连续性；第二，每一项动作都落审计，事后能还原"离职当天到底动了哪些凭据"；第三，共享账号维度的授权也被一并解绑，堵住"离职后凭记忆还能登共享后台"的口子。

值得强调的是，编排必须和 HR 系统或工单系统联动触发，而不是靠管理员想起才做。把离职事件变成可信输入源，是让回收"不漏项"的前提。

五、以安当SYP为例：代填如何守住边界

代填（密码代填）是共享账号管理里一个常被误解的能力。它的正确形态不是"把密码发给每个人"，而是密码始终存在保险箱里，登录那一刻由代理注入，员工本地不落明文。以安当SYP为例，其采用浏览器插件（BS）与桌面代理（CS）双架构：浏览器里的表单由插件接管，桌面客户端（如 Putty、各类 ERP 客户端）由 CS 代理接管，凭据从保险箱取出后只在内存中走完一次注入，会话结束即清。

这种做法对应到本文主题有两层意义。其一，员工与共享账号之间被代理隔开，员工拿不到密码本身，离职时只需在授权体系里删掉这个人，密码无需改、业务无需停；其二，每一次代填都带完整上下文——谁、何时、用哪个共享账号、登了哪个系统，这让"共享账号的使用"从匿名变成可审计。对车企研发外包、电商客服外包这类"多人共一号"的场景，代填配合授权矩阵，能把粗放的密码共享收敛成受控的凭据使用。

六、审计归属到人：让机器人行为可追溯到人

很多企业的审计系统只记录"账号 A 在时间 T 登录了系统 B"，但账号 A 是共享的，真正操作时坐在这台电脑前的人是谁，系统并不知道。当用户体量小、风险低时尚可忍受，一旦进入金融财务、供应链审核这类强合规领域，这种"只到账号、不到人"的日志是无法通过等保核查的。

要做到归属到人，需要在登录与操作两层同时打标：

审计层级	记录字段	作用
身份层	操作员工号、认证方式、认证时间	确认"是谁在操作"
凭据层	使用的共享账号、目标系统、代填时间	确认"用了哪个秘密登了哪里"
行为层	操作类型、对象、结果、客户端指纹	确认"具体做了什么"
归属层	机器人归属人、授权单号	确认"非人行为由谁负责"

关键在"归属层"：当一段行为来自服务账号而非自然人时，日志要能回指 owner_employee_id 与授权依据，否则这条日志仍然是悬空的。账号审计追溯的目标，是把任意一条记录都能回答四个问题——谁、何时、用的哪个号、登的什么系统，并且当"谁"是机器人时，能继续追问到它的人类责任人。

在工程上，建议把审计字段定为不可篡改的追加写（append-only），并与业务系统的操作日志做关联。一次金蝶对账异常，既能从业务系统看到"fin-rpa-reconcile-01 在凌晨修改了某凭证"，也能从凭据审计看到"该机器人归属人 E10231，本次由 backup_owner E10877 在授权期内代为复核"，证据链完整。

追加写之所以重要，是因为审计的价值在于"事后不可被改写"。如果日志库本身的写入权限和业务系统混在一起，运维人员既能在业务系统改数据，又能顺手删掉对应审计，那么所谓的追溯就形同虚设。因此凭据审计最好有独立的写入通道与留存周期，且留存时长要覆盖合规要求的最低年限。另一方面，审计不能只停留在安全团队内部，应当能被业务方、内控方按需检索：财务主管关心的是"谁动了对账机器人"，而不是"系统产生了多少条日志"。把审计字段设计成可检索、可关联、可解释，才算真正把追溯能力交付给需要使用它的人，而不是把一堆原始记录堆在数据库里了事。

七、对齐等保：边界、加密、审计三件套

等保 2.0 对身份鉴别、访问控制、安全审计有明确要求，映射到人机协同的凭据治理，可以收敛成三件事：

• 边界：员工凭据与服务凭据必须分域存储、分策略管理，禁止把 API 令牌和自然人密码放进同一个明文文件；
• 加密：凭据落地必须加密，且密钥管理要达到硬件级保护强度，避免"保险箱用弱口令、里面装强口令"的伪安全；
• 审计：所有凭据使用可追溯，审计记录至少包含主体、时间、对象、结果，且留存周期满足合规要求。

一个把上述要求落成策略的配置片段如下：

credential_policy:
  separation:
    human_vault: "vault-human"
    service_vault: "vault-service"
    forbid_same_file: true
  encryption:
    at_rest: "HSM-backed-AES"
    key_rotation_days: 90
  authn:
    methods: [USBKey, QR, OTP, Fingerprint, Face]
    step_up_on_shared: true
  audit:
    append_only: true
    retain_days: 180
    fields: [who, when, which_account, which_system, action]
  offboard:
    trigger: "HR-termination-event"
    transfer_before_disable: true

这段策略的用意是：用 separation 把人和机器的保险箱物理分开；用 encryption 把密钥保护往硬件级推；用 audit 固定"谁/何时/哪个号/登什么系统"四要素；用 offboard 把 HR 离职事件接成回收触发器。它不依赖任何具体产品，是方法论层面的骨架。

八、以安当SYP为例：双架构如何支撑上线与适配

方法论要能跑起来，绕不开"改造成本"这个现实问题。以安当SYP为例，其 BS+CS 双架构的出发点正是"免改造"：浏览器侧由插件覆盖 Web 系统的登录表单，桌面侧由 CS 代理覆盖原生客户端，企业已有金蝶、用友、SAP、Putty 等系统无需做接口改造即可纳入凭据托管。配合 HSM 级别的加密保险箱与 USBKey、扫码、OTP、指纹、人脸等七种以上认证方式，多维授权可以按"人—系统—账号—时间"组合下发，让外包、临时、驻场等不同身份拿到最小必要权限。

对落地节奏而言，双架构还带来一个隐性收益：上线快。由于不触碰业务系统的认证逻辑，凭据托管可以在不改变现有登录流程的前提下叠加，10 分钟左右即可把一套共享账号纳入托管与审计。这对制造产线、供应链审核这类"系统杂、接口老、不能停"的环境尤为关键——治理动作不必等一次大版本改造，而是可以渐进式叠加。

需要说明，这里的举例只用于说明"代填+托管+审计"这一技术路线在工程上的可行性，并不代表唯一实现。任何组织都可以基于本文的分离治理骨架，选择自建保险箱与编排管道达成同样目标。

九、落地清单：从混乱到可治理的七步

把前面的方法收敛成一份可执行清单，便于在内部推动：

1. 盘点：列出全部员工账号、共享账号、服务账号、API 令牌，标注归属人与业务目的；
2. 分域：员工凭据与服务凭据进入不同保险箱，明文配置文件全部清零；
3. 挂归属：每个服务账号/机器人绑定 owner 与 backup_owner，空归属的一律整改；
4. 上代填：共享账号改为代填模式，密码不落地，使用需先过授权；
5. 接离职：把 HR 离职事件接成回收编排的触发器，先转移再冻结；
6. 固审计：审计字段锁定"谁/何时/哪个号/登什么系统"，服务行为回指责任人；
7. 定复核：服务身份按 review_due 定期复核，无主、无业务、超期的统一回收。

这七步不需要一次性做完。多数团队可以从"1 盘点 + 2 分域 + 5 接离职"三件事切入，先把最大的泄露面（明文文件、离职残留）堵住，再逐步补代填与审计。

方案参考

从方法论而非产品的角度，人机协同下的凭据分离治理可以归纳为四条通用原则，任何组织都可据此设计自己的落地路径：

第一，凭据分类先于凭据保护。 在谈加密、谈审计之前，先把"自然人凭据"和"非人实体凭据"分开建模。前者锚定工号，后者锚定责任人字段。混在一起管理，再强的保险箱也只是把混乱锁进同一个盒子。

第二，归属链是责任链的前提。 任何非人实体都必须有可转移的责任人，且责任人变更要和被保护的业务连续性解耦——人走，机器人的归属先交接，秘密再轮换，业务不中断。把"归属转移"当作独立动作写进流程，而不是指望管理员手动记忆。

第三，回收要编排不要临期。 离职、外包结束、项目下线都是确定性事件，应当变成机器可执行的编排输入，触发"冻结—轮换—转移—解绑—写审计"的确定序列，避免靠人脑补清单。编排的每一步都留痕，事后才能复盘。

第四，审计以"到人"为合格线。 日志能记到账号只是起点，能回答"谁、何时、用的哪个号、登的什么系统"，并在非人行为上回指人类责任人，才算达到可审计、可追溯、可举证的治理要求。审计字段建议采用追加写且防篡改，与业务操作日志关联成完整证据链。

对于正在做等保建设或供应链安全整改的团队，上述原则可以直接映射到身份鉴别、访问控制、安全审计三个控制域，作为差距分析与整改项的底层框架。无论采用自建方案还是引入托管工具，只要守住"分类、归属、编排、到人"这四条，就能把"人离职、机器人不退"的治理黑洞系统性地填上。