谁能进你的系统，这份名单谁签过字

一 为什么这一格今年被单独拎出来

企业管"谁能进系统"这件事管了二十年，问法一直很固定：谁的账号、什么岗位、开哪些权限、离职当天谁去关掉。四个问题各有责任人——人事发通知、用人部门审批、IT 执行、审计抽查。链条是闭合的，出了问题能找到那一格上签字的人。

2026 年断的是另外半条。几份口径并不一致的研究今年都指到同一件事：**能进系统的东西，大半已经不是人。**KPMG 在 2026 年 9 月那份年度安全考量里写得很平白——AI 代理、服务账号、机器凭证这一类非人身份，数量已经超过人类用户。另一份被反复引用的 Entro Security 2025 年报告给了区间：企业环境里机器身份与人类身份的平均比例在四十五比一到八十二比一之间，云原生环境里能到四万比一（这两个数本文按二手转述处理，未取原文）。

"人走了有流程，账号走了没有流程"，这是断点的第一层。第二层更要紧：**这些账号你通知不到。**它不请假、不离职、不回复那封"请确认您的权限仍然需要"的邮件，也不会在一季度一次的复核会上说"我这侧其实早就不用了"。项目结束、外包撤场、脚本改名，账号原地留着，权限一寸不少。OWASP 那份非人身份风险清单里，生命周期缺位被排在最前面的一条；IBM 的术语页在解释这一类风险时也说得很直接——机器身份没法上双因素认证，被盗的那一枚凭证往往就足够接管整个账户。

于是今年的安全预算评审里多了一道新问句。它不是"我们有没有上防火墙"，也不是"要不要再买一套工具"，而是：**这份名单，谁签过字。**这篇文章全部九节，都在回答这一句该怎么问、先问哪一类、以及怎么把工时花在真正会出事的那几行上。

二 名单上有四类身份，后两类通常没人认领

多数公司的权限名单不是"没管"，是按一种分类在管，而现实已经分成四种。第一类是本公司员工，这条链最成熟；第二类是外部协作方——实施顾问、代运营、外包开发、驻场人员，有审批但到期通常靠人记；第三类是服务账号与密钥，系统之间互相调用用的那枚凭证；第四类是今年新长出来的自动化与 AI 代理，它替人动手，却常常直接继承某个人的身份。

身份类别	谁创建	谁审批	有没有到期	出事谁签字
本公司员工	IT 按人事通知建	用人部门主管	离职当天关闭，流程有	明确
外部协作方	IT 或业务部门直接建	合同或项目经理	靠人记，多数没有	常常模糊
服务账号与密钥	开发或运维自建	多数没有独立审批	几乎没有	找不到人
自动化与 AI 代理	项目组建	看项目，一般没有	没有	说不清

这张表的重点在第三列和第四列。前两类有"创建要有人同意"这道闸，后两类在多数公司是自己长出来的：一份 2026 年 5 月发布、经媒体转述的 Orchid Security 研究报告给的数字是——67% 的非人账户直接在应用程序内部创建，完全脱离身份管理系统的视野；57% 的应用允许绕过集中式身份提供商做认证。同一份报告另一格值得记住：企业环境里"看不见"的身份占到 57%，超过可见身份的比例 43%。

也就是说，第三、四类身份的规模在涨，而它们没有第二列。这不是执行力问题，是分类问题：拿管人的那套流程去管一枚密钥，注定管不住——它没有部门、没有主管、不会自己走进办公室要求开通权限。

所以第一件要做的事不是买工具，也不是发起一次全公司权限大清查，而是把名单按这四类重新摊一遍，然后承认：只有前两类的现有流程是有效的，后两类需要另立一套。

三 三个"无主"数字：分母不同，别拿来互相印证

"无主账户"这一格，2026 年市面上有三个常被引用的数字，形状很像但量法完全不同，混着用会得出很离谱的结论。

第一个是 40%。出处是那份 Orchid Security 的 2026 年现状报告：40% 的账户沦为孤儿账户，在原始用户离开之后仍保持可用状态。它的分母是"账户"，判据是"创建人或用主已经不在了"。这个数之所以高，和第二节那两格是同一件事——账号是在应用里自己长出来的，本来就没人登记。

第二个是 8%，来自另一份 2026 年 5 月经社区文章转述的 Veza 研究报告：平均 824,000 个孤儿账户，占全部账户的 8%，且仍保留有效权限。分母同样是账户，但判据更窄——它要能确认原主已离开。同一份报告里还有三个更刺眼的数：平均每位企业员工持有约 96,000 项权限；非人身份与人类身份的比例是十七比一；不到 1% 的非人身份控制着 80% 的云资源。

第三个是 65%，出自 Tenable 2026 年那份云和 AI 安全风险报告：65% 的企业潜藏"被遗忘"的云凭据，这些密钥要么不再使用、要么长期不轮换，并且与高风险身份绑定。这是厂商研究页面的口径，属一手发布、但天然带宣传性。它的分母是"企业有没有这问题"，不是"多少账户无主"。

三个数字放一起，正确的读法是这样：40% 与 8% 的差在判据宽严，不在谁对谁错；65% 说的是"有多少家中招"，不能换算成账户比例。真正三家都同意的只有一条方向——名单里存在一批没人负责、权限还很高的账号，而且这部分不是长尾，是主力。Veza 那份里"不到 1% 的身份控制 80% 的资源"这一格尤其值得管理层记住：风险不在数量，在权重。

还有一条容易被跳过的组合。Orchid 那份报告专门给了一个词，叫毒性组合——它说的不是单个漏洞，是几格叠在一起：一个具备高权限的孤儿账户；一个既绕过集中身份提供商、又把凭证明文写进应用的应用；一个既不记录日志也没人监管的休眠账户。单独看每一格都"不算大事"，叠起来就是一条完全不受监控的通路。该报告同一份数据里给的分量：70% 的应用存在特权账户过多，57% 的应用允许非受管路径认证，36% 的凭证以明文硬编码在应用里。

四 为什么机器账号比人难管：三道结构性的坎

把这一格做小容易，做大难，是因为它撞在三道结构性的坎上，不是"再强调一下"就能过的。

**第一道：没有第二道验证。**人的账号可以被要求刷脸、输动态码；机器身份不行——它是程序在调用程序，那枚凭证本身就是全部身份。IBM 的术语页把这一条列在风险清单里：非人身份通常没有多因素认证，因此凭证一旦被盗，就足以完成接管，还能横向移动和提权。同一页也说了另一半原因：正因为这些身份撑起 DevOps 流程和备份作业，组织往往给它们高于实际需求的权限。那份 Entro 报告的数字更硬——97% 的机器身份拥有超出实际需求的权限，68% 的组织承认自己对这些身份监控不足，只有 15% 对防御这类攻击有高度信心。

第二道：它不会回应，也就不会到期。权限治理最省钱的机制是"让本人确认"，一年一次，成本几乎为零。这套机制对人有效，对密钥完全无效。OWASP 那份清单里的原话（按二手转述）大意是：传统身份管理假设身份属于会离职的人，而机器身份没有经理、不响应审查邮件，一旦项目取消或供应商走人，账户就原地不动。于是"到期"这一格在机器身份上不是没配好，是根本没人按下那个开关。

**第三道：明文会自己扩散。**一份密钥一旦进了工单系统、群聊、共享文档、镜像文件，它就再也回不到"只有两处存着"的状态——复制、转发、索引、存档，每一环都不需要谁批准。SpyCloud 那份 2026 年的身份暴露研究给了外部一侧的量级：2025 年重新捕获的暴露 API 密钥与令牌约 1810 万个，其中与 AI 工具相关的凭证或会话令牌约 620 万个；同一年被钓鱼获取的身份记录约 2860 万条，近一半是企业用户（均按二手转述）。另一家常被引用的 GitGuardian，上一年度在公共代码仓库里扫出的暴露密钥量级在千万条（二手，具体年度口径本文未核）。

三道坎合起来解释了为什么这一格的正确顺序不是"先上一次工具"。工具解决的是可见性，而这三道里前两道要解决的是规则：谁有权创建、要不要到期、到期谁批。规则没定，工具只会把一份没人认领的名单变成一份带图表的、没人认领的名单。

五 已经付过学费的三条连锁：一枚凭证能带走多少东西

如果只留一段给管理层看，留这一节。因为这一格的账单从来不是按"少了一个账号"计的，是按"一枚凭证带着人走遍了整片系统"计的。

**第一条：一个服务账号，把一家供应商的客户名单变成了攻击者的入口。**2023 年 10 月那起 Okta 支援系统入侵，事后披露的根本原因不是高级漏洞，是一枚服务账号的凭证泄露。攻击者用它存取客户上传的文件、提取登录会话凭证，影响范围从最初披露的一百三十四名，扩大到一万八千四百名曾开立支援工单的客户。连锁的下一环更能说明问题：Cloudflare 是受影响的客户之一，在紧急轮换凭证的过程中有四组被漏掉，攻击者正是用这四组非人身份凭证进了 Jira、Confluence 与 Bitbucket 的代码库，最终 Cloudflare 被迫轮换超过五千组正式环境凭证，并对四千八百九十三个系统做全面鉴识分析（以上按媒体回顾转述，二手）。**四组被漏掉的凭证，代价是五千组重换。**这就是"无主账号"这一格最直白的价格标签。

**第二条：机器人偷令牌，两百多个客户实例被串起来。**IBM 在解释非人身份带来的供应链风险时给的近年例子是 2025 年的 Salesloft Drift 事件：攻击者利用一个聊天机器人窃取 OAuth 令牌，再用这些令牌访问数百个 Salesforce 实例。这一条的要害在于路径——不是数据库被攻破，是"一个本来就有权限的自动化角色"被劫持了。它不触发任何异常告警，因为它的每一次调用看起来都是正常业务。

**第三条：今年新的那一族，规模比前两条大一个量级。**2026 年 6 月被威胁情报平台披露的大规模凭证窃取事件（代号 FortiBleed）里，约七万五千台防火墙与 VPN 网关设备的登录凭证疑遭窃取，攻击者曾针对超过三十二万台设备发起约十一亿六千万次登录凭证尝试，且已确认与两个勒索软件即服务团伙相关（二手转述）。同一族里还有 2026 年 2 月那起云存储暴露：判据是共享访问签名令牌加上存储账户配成公开访问、没用私有端点；以及那篇把 2026 年攻击归因到"人为失误加非人身份管理薄弱"的研究里给的入口——某大型制造案例里攻击者靠的不是漏洞利用，是暴力破解了一个运维账号的弱口令。

三条连起来是一条判断：**攻击面已经从"人的密码"搬到"机器的凭证"，而后者既不设第二道验证，也长期不轮换。**那份研究同一处给的配比读数可以当体温计用——过去一年内至少遭过一次身份入侵的组织占 71%，平均每家三次；只有 24% 的组织常态化监控异常登录，不足三分之一的组织定期轮换非人凭证（二手）。成本那一侧：身份相关攻击的平均恢复成本一百六十四万美元、中位数七十五万美元；另一份 2026 年的泄露成本研究给的口径是只有 46% 的组织对非人身份做了安全防护。

六 先按"权重乘无主"排序：这份名单怎么盘得起

多数公司在这一格上的真实做法，是把权限系统导出的表发下去，让各部门在两周内逐行确认。这份做法的失败方式很稳定：**一千二百行表格，最后是在二十分钟的会上整批签掉的。**审的人只认得前五十行，剩下的全部打勾。所以真正的对手不是"工时不够"，是"逐行确认"这个机制本身在长名单上必然退化成橡皮章。

换序就行。用两个筛子，都只用系统里已有的字段，不需要买工具：

次序	判据	为什么要先问它	盘的动作
第一档	权限最高、且创建人已经离开	一枚顶一整片；泄露即接管	一项项问：干什么用、最后一次调用是哪天、能不能停
第二档	绕过集中认证入口、或凭证写在代码与配置里	无日志、无监管，出事查不到	迁进统一入口，改保管位置，定轮换周期
第三档	长期不活动、但从没停用的休眠账号	它是攻击者最喜欢的侧门	默认停用，谁要用谁回来重新申请
第四档	其余有主、权限常规、活动频繁	大概率是对的	批量挂到期日，不逐字问

这张表的量法可以照自己系统里的字段直接跑：把"权限包含管理类角色"与"用主工号已不在职名单"两列取交集，通常只有几十行；再把"最近九十天无调用记录"那一列单独筛一次。第二档那两格（明文、绕过集中认证）在多数公司要靠问而不是查，因为凭证可能躺在工单、共享文档或镜像文件里，而这三处都不会出现在身份管理系统的报表上。

排完之后再谈工时，账才算得清。这里给一道演示题，分母全部是自设的效率假设，不代表任何一家的报价：一家三百人的公司，四类身份合计名单一千二百项。按"逐行确认、每项五分钟"算是一百人时，约十二点五个人日——这个数排不出日程，所以现实里它被压缩成一次会议。若按上面那张表只逐条问第一、二、三档，规模大致落在几十到一百项区间；一项按三十分钟问清创建人、用途、最后一次调用时间与停用后果，是二十五到五十人时，三个人日到六个人日。同样的预算，前者买到一份签过字的表，后者买到几十个被人认真看过、真的能停下来的账号。

顺带一条同族对照：〈依赖被投毒，先查谁有按回车的权限〉讲的是构建与发布链路上的写权限，那一篇的问题是"谁能让代码进生产"；这一篇问的是"谁能让数据出来"。两篇的名单可能重叠，但判据不同——那一篇看提交权限，这一篇看凭证与到期日。

七 拿去问的那七句话

这七句是给你带进会议室的，问 IT 负责人、问外包供应商、问实施顾问都可以。每一句后面标了"什么答案算过关"，因为这一格的常见失败不是没人答，是答案听起来都对。

第一句：这份名单从哪个系统导出，导的那一刻它是不是最新的。过关答案要说得出具体系统名和导出时间，并承认有几个系统不在里面。"我找一下"不算过关——找不到一份完整名单，本身就是这一格的结论。

**第二句：谁可以不等任何人同意，就自己建一个账号或一枚密钥。**过关答案是"没有这种人，创建都走同一个入口"。这份研究里 67% 的非人账户在应用内部直接创建这一格，说的就是这条防线在多数公司是开着的。

**第三句：一枚密钥的到期日默认是什么，到期之后是自动续还是自动停。**过关答案是"到期默认停，续要重新申请"。若答案是"没有到期这一说"，第三档那些休眠账号就有了明确的来源。

**第四句：上一次真正停掉一个还能用的账号，是什么时候，谁提的。**过关答案要有人名和时间点。提不出具体一次，说明这套机制只在文档里跑过。

**第五句：权限最高的那几枚凭证，创建人还在不在公司；不在的现在谁负责。**这一句对着毒性组合那一格问。过关答案不需要多，只需要"这几枚，现在登记在某个人名下，他能回答用途"。

**第六句：自动化脚本和 AI 助手调用系统时用的是谁的身份，日志里能不能把人做的那部分和机器做的那部分分开。**过关答案是它有独立身份、权限是单独申请的一份。若答案是"用的还是某某的账号"，那这个人离职的那天，这一整套自动化要么停摆、要么变成一整批无主权限。

**第七句：上一轮审计查出来的无主账号，处理率是多少，剩下那些的原因写在哪个地方。**过关答案是一份带责任人和日期、并且这次能读出上一轮遗留项的清单。只有本次发现数、没有上次处理数，说明这张表每年都在重新发现同一批问题。

八 什么时候这一格会变贵，什么时候会自己变便宜

这一格不是恒定的工作量，它随三个条件明显起伏，值得在做下一年预算时先判档。

**会自己变便宜的三种情况。**一是集中身份入口真的覆盖了大多数系统——第三节里"57% 的应用绕过集中式身份提供商"那一格一旦收掉，名单就从"多个系统各有一份"变成"一份"，后面所有动作的成本都跟着降。二是密钥进了统一保管、并按周期自动轮换，明文扩散和长期不轮换那两格被同一件事解决。三是并购、系统合并或供应商更换——这类事件会强制两类名单并表，是很多公司第一次真正看清自己有多少无主账号的时刻。如果今年本来就有这类动作，权限盘点搭进去做，边际成本几乎为零。

**会变贵的三种情况。**一是多套自建系统并存且没有统一认证入口，每一套都要单独导一次名单、单独问一遍；二是自动化与 AI 代理的数量在半年内从几枚涨到几十枚，第四类身份自己长出来；三是外包与驻场用对方自己的账号体系，那部分权限根本不在你的名单上，却进得去你的系统。

给下一年预算的一句话判据：先问"名单有几份"，再问"要不要买工具"。前者决定工作量下限，后者只决定效率上限。工具在一份没人签字的名单上，产出的是一张没人签字的图表。

九 AI 代理进系统之前，"它用谁的身份"要先写死

第四节那三道坎在 AI 代理身上会同时出现，而且更极端：它既是机器身份（没有第二道验证、不会回应审查），又常常拿着人的权限（继承创建者那份名单），还会自己动手（一次调用可能读遍整片数据）。2026 年 3 月那届 RSA 安全大会的现场综述里，身份安全那一栏的新提法已经把 AI 代理列为与"人""设备"并列的第三类受保护实体；KPMG 那份年度考量给出的方向是给机器身份配自动化的发现与监控。厂商方案侧也出现了同一条做法：每个代理要有独立的身份标识与权限边界，避免默认继承创建者的全部权限，并对即将引入的代理做最小权限与即时授权，而不是发一枚长期有效的万能钥匙。也有研究机构做了个更直白的预测——2026 年第一起由此触发的重大事故，会来自一个权限过大的 AI。这一条本文按未证实处理，但它指的方向不需要靠预测也成立。

摊到采购与立项那一格，AI 助手要上线之前，这三格得写在工单或合同里，而不是留给上线后再补。

要写死的一格	写成什么样算清楚	没写会发生什么
它用谁的身份	它自己的身份，权限单独申请一份	用某个人的账号跑，那人离职后要么停摆要么无主
它能读哪些数据	列到库或表这一层，超出要另外申请	默认继承创建者权限，一次问句读到全库
它能不能替人写	只读还是可写，写哪些对象，谁审批	出了事故无法区分是人做的还是它做的

最后回到文章开头那一句。这份名单谁签过字——问的不是有没有一张表，而是那几十行最高权重、又没有主人的凭证，现在能不能说出一个人名。第二节那张四类身份的表、第三节三个数字的读法、第六节那把"权重乘无主"的筛子、第七句后面那七句话，都只是为了让这一问在下一轮预算会上问得出来、并且得到一个带人名的回答。

关于这些数字的档级

Tenable 那一格 65%、KPMG 那句"非人身份已超过人类用户"，出自厂商官方发布页，算一手口径，但两者都带宣传性质，读时按厂商自己的结论看。OWASP 非人身份十大风险的条目内容，本文是从 IBM 官方术语页读到的，属一手对二手的引用；Salesloft Drift 那一起事件同样取自那一页。Orchid Security 那份 2026 年现状报告的 57%、67%、70%、40%、36% 几格，Veza 报告的 8%、824,000、96,000、十七比一与"不到 1% 控制 80%"，Entro 的 45 比一到 82 比一、40,000 比一、97%、68%、15%，SpyCloud 的一千八百一十万、六百二十万、两千八百六十万与四百倍，IBM 数据泄露成本研究里"46% 对非人身份做了防护"那一格，以及"71% 至少遭过一次身份入侵、平均三次、24% 监控异常登录、三分之一都不到轮换非人凭证、平均恢复成本一百六十四万美元中位数七十五万美元"整组，全部来自媒体、社区文章与聚合站转述，没有取到原文，一律按二手算。FortiBleed 的七万五千台与十一亿六千万次、某制造案例的弱口令入口、那起云存储暴露的成因，同属二手且未取原始公告；Okta 与 Cloudflare 那两段的数字取自一篇 2026 年 6 月的回顾报道，事件本身有双方公开披露，具体数字本文未回到原始公告核对。GitGuardian 那一格只给量级，年度口径未核。"2026 年第一起重大事故来自权限过大的 AI"是研究机构的预测，按未证实处理。

第六节那道工时演示题的四个分母——一千二百项名单、每项五分钟、每项三十分钟、三百人规模——都是自设假设，不是任何一家的报价，也不是任何一次真实项目的人力记录。换成你自己名单里的实际行数与你能排出的实际工时，结论只跟着"逐行确认在长名单上必然退化成整批签字"这一条机制变，不会跟着数字变。