你公司的人身份治理堪称模范——多因素认证覆盖全员，最小权限严格执行，每季度做一次访问评审。可一旦问起机器身份，运维可能只报出一个少报了至少五成的数字，至于谁创建、谁在用、谁负责轮换，答案从“不太清楚”一路滑到“完全不知道”。这些服务账号、API 密钥、CI/CD 令牌和机器人凭证的数量，动辄比员工总数高出几个数量级，却长期处于无主状态。

凌晨两点，安全工程师被报警声拽出睡眠。秘密检测工具刚捕获到一条 GitHub 个人访问令牌，它居然带有生产基础设施的写权限，而且还躺在公开仓库里。此刻，真正的竞速开始：你必须在攻击者发现之前找到令牌的主人并完成轮换。工程师翻出泄露那次提交的作者信息，发现对方已经离职六个月。去 Slack 里搜库名，翻出十二个讨论串，没一个给出结论。再查组织结构图，这个团队今年已重组了两次。最后只好挨个联系那些“可能认识可能了解情况”的人。四十五分钟过去，总算得到一个“应该没错了”的答案，凭运气把令牌轮换掉，也许什么都没发生，也许只差那一步就被攻破。

打开网易新闻 查看精彩图片

这种场面反复上演，不是因为安全人员粗心，而在于大多数组织压根没有为机器身份建立归属。它们在产品迭代的冲刺中被草率创建，随着团队交接被继承，项目结束后就被遗忘在角落里。当凌晨的泄露事件把权责裂缝撕开时，大家才发现根本找不到一个真正负责的人。

再回看你对人类账号的管理：所有账户都有明确所有者，离职自动触发注销流程，审计日志和审批链路清晰可见。可一旦切换到服务账号，连到底有多少个都说不准，多数团队会低估至少五成。创建者信息丢失、使用者分散各处，轮到该轮换或注销时，无人站出来。这层机器身份治理的空白，已经不是工具或者人的单一问题，而是整个责任体系的断层。

GitGuardian 在 NHI 治理中直接把所有权机制加了进来。产品会从你现有的工具里自动推荐出可能的负责人，团队也可以按自己的方式灵活分配归属，让每个服务账号都落到具体人头上。相关解决方案给出的，正是一种干脆利落的解法：不再靠半夜翻聊天记录和旧文档拼凑线索，而是在平时就把机器身份同真正的责任人绑定起来。