上个月，在对我们的Azure环境进行常规访问审计时，我偶然发现了一个名为svc-dataloader-poc的服务账户，这个账户已有793天——整整两年未被使用过。当我查看其权限时，不禁倒吸一口凉气：它拥有对我们三个生产订阅(包括客户数据库)的所有者级访问权限，该账户是为一个从未投入使用的概念验证迁移项目而创建的，创建该账户的承包商已于18个月前离职，没人知道这个账户的存在。

这并非个例，在同一次审计中，我发现了47个类似的账户，47扇敞开的大门。

以下是2026年每位安全领导者都必须面对的残酷现实：在过去十年里，我们致力于完善针对人类用户的多因素身份验证(MFA)部署和零信任架构，但与此同时，我们的环境中却悄然滋生着其他问题。服务账户、API密钥、自动化凭证、AI智能体……这些非人类身份的数量，如今在大多数企业中已远超实际员工数量，这一比例在五年前还显得荒谬至极。ManageEngine发布的《2026年身份安全展望》报告显示，企业报告的机器与人类比例高达100:1，有些甚至达到了500:1，而这些身份中的绝大多数，完全不在我们的治理计划之内。

我们锁好了前门，但后门却一直敞开着。

为何此次非人类身份(NHI)的激增与众不同

机器身份并非新鲜事物，变化在于其激增的速度。五年前，一个典型的企业应用程序是一个与数据库通信的单体应用，而如今，同样的应用程序已拆分为50个微服务，每个微服务都需要凭证与其他服务通信，在自动扩展过程中启动的每个Kubernetes Pod都会创建工作负载身份，每个GitHub Actions工作流都会生成令牌，每次Terraform运行都会配置服务主体。我曾亲眼见证，一个单一的部署流水线在20分钟内创建的机器身份数量，超过了我们整个公司的人类用户数量。

随后，自主式AI的出现，又进一步加剧了这一问题，这些并非回答问题的聊天机器人，而是被授权自主执行命令、移动生产数据、修改配置和触发下游工作流的系统，Microsoft Copilot可以访问你的SharePoint，GitHub Copilot可以向你的代码仓库提交代码，你营销团队刚刚部署的AI助手可以从Salesforce中提取客户记录。One Identity预测，2026年将出现首起因权限过大的自主式AI导致的重大安全漏洞。更可怕的是，这看起来并不像一次攻击，它看起来就像系统在执行其设计的功能一样。

我们的身份和访问管理(IAM)系统从未为此设计，它们假设身份属于有经理的人类，这些经理会对访问审查邮件做出回应，并最终辞职或退休，而机器身份没有经理，它们从不对认证活动做出响应，它们不会离职，OWASP非人类身份十大风险中，不当离职处理被列为首要风险。当项目被取消、供应商集成被弃用、开发人员离职时——有人记得删除服务账户吗?根据我在多个企业中运行IAM项目的经验，答案几乎是否定的。

我不断发现的三大盲点

在云安全和身份管理领域工作多年后，我发现无论在哪里都能看到某些模式。在我评估的几乎每个环境中，都存在三个特别突出的问题。

• 本不应存在的机密信息。我仍然在源文件中发现硬编码的API密钥，在2026年，这仍然存在。去年，GitGuardian在公共GitHub代码库中检测到了1300万条暴露的机密信息。Google API密钥、MongoDB凭证、AWS访问密钥——就明文摆在那里，任人窃取，但公共代码库甚至不是最大的问题。在我自己的评估中，我发现生产数据库密码出现在Jira工单、Slack消息、Confluence运行手册和共享的Google文档中。一位同事曾发现，一个支付网关的管理令牌被粘贴到了2023年的Teams聊天中，仍然有效，仍然授予完全访问权限。一旦机密信息泄露到协作工具中，你就失去了控制，它们会被复制、转发、索引、存档，它们永远不会真正消失。

• 服务账户权限过高。这个问题让我愤怒，因为它完全可以避免，开发人员需要为一个新的Lambda函数创建一个服务账户，他们面临着截止日期的压力，弄清楚确切的最小权限需要时间，所以他们直接附加了AdministratorAccess权限，然后继续工作，函数运行正常，没人再回头查看。现在，这个账户拥有了对你整个AWS环境的“上帝模式”访问权限，而实际上它只需要对一个S3存储桶的读取权限。想象一下，这种情况在每个团队、每个冲刺周期、每年都会发生。Entro Security发布的《2025年非人类身份状态报告》显示，97%的非人类身份拥有过多权限，97%!更令人震惊的是，只有0.01%的机器身份控制着80%的云资源，一旦这些账户中的一个被攻破，攻击者就能掌控你的整个环境。

• 完全没有生命周期管理。当员工离职时，人力资源部门会启动离职流程，访问权限会被撤销，这是一个有流程的过程，那么，当不再需要服务账户时会发生什么?什么都不会发生，它就留在那里，我经常发现账户有六个月、十二个月，甚至三年未被触碰过——但仍然拥有生产访问权限。Veza的研究发现，休眠账户数量逐年几乎翻倍，孤立身份增长了40%，在一组数据中，有78000名前员工仍然拥有有效凭证，因为人力资源系统将他们标记为非活跃状态，但没人撤销他们的服务账户，这些不是理论上的漏洞，这些是等待被发现的活跃凭证。

安全领导者的切实前进路径

承认问题是第一步，解决问题则需要像对待人类用户一样，用同样的治理原则来对待机器身份。根据我看到的实际有效的方法，以下是我建议的重点。

• 建立真正的清单。你看不见的就无法保护，首先，发现你环境中的每一个非人类身份，每个云平台上的服务账户，应用程序中的每个API密钥，存储库、配置文件、CI/CD流水线中的每个机密信息，有权访问你系统的每个第三方集成，与我合作的大多数组织都严重低估了他们的足迹，实际数量通常是团队预期的三到五倍，这不能是一次手动操作或年度审计，身份的创建速度超过了人类计数的能力，实现自动化发现并使其持续进行。

• 强制实施最小权限原则，无一例外。每个非人类身份都需要被限定在其功能所需的最小访问权限范围内，是的，这需要工作，是的，开发人员会反对，但还是要这么做，从新的部署开始，使最小权限成为默认设置，对于现有账户，将分配的权限与实际使用模式进行比较，你会发现很多账户拥有广泛访问权限，但实际上只触碰了一两个资源，这些都是快速取胜的机会，在任何非人类身份获得提升的权限之前，都需要获得安全批准，使其成为一道门槛，而不是一个建议。

• 尽可能消除静态凭证。长期存在的机密信息是大多数非人类身份泄露的根源，目标应该是完全消除它们，用自动过期的短期令牌替换永久API密钥，实施即时访问，为特定任务授予权限，并在任务完成后立即撤销，按照预定的时间表(对于敏感系统，可以是每周、每天，甚至每小时)自动轮换凭证，研究表明，71%的非人类身份没有在推荐的时间范围内轮换，凭证每多存在一天，攻击者就有可能多一天在未被发现的情况下使用它。

安全行业对于2026年已达成明确共识：机器身份将成为云环境中的主要攻击途径，Tenable预测了这一点，Delinea预测了这一点，One Identity也预测了这一点，攻击者已经知道，攻破服务账户往往比针对人类更容易且更隐蔽，他们不再破门而入，他们正从我们忘记锁的门走进来。

那些能够提前应对这一威胁的企业，将是那些像对待高管账户一样严肃对待其非人类身份的企业，全面可见，严格治理，无一例外，那些继续将非人类身份视为事后考虑的企业，将是那些需要向董事会解释为何一个已取消项目的被遗忘服务账户导致整个系统崩溃的企业。

我们多年前就锁好了前门，但我们已经很久没有加固后门了。