一场没有密码的入侵

Google威胁情报团队披露了一起让许多安全从业者沉默良久的数据窃取事件。

攻击者没有破解任何Salesforce账号。没有向任何员工发送钓鱼邮件。没有在凌晨发起大量失败登录，也没有触发任何异常行为告警。他们只是拿着一枚与Salesloft Drift第三方应用相关的已泄露OAuth令牌，悄悄推开了多家企业Salesforce实例的大门，批量导出账户、用户、商机和工单数据。

更令人不安的是，攻击者拿到这批数据之后，并没有就此收手。他们在导出的信息中反复搜寻AWS访问密钥、数据库密码和Snowflake令牌——试图把一次SaaS层面的入侵，变成进入整个云环境的跳板。

Google在通报中特别强调：这次事件并非源于Salesforce核心平台本身的漏洞。

换句话说，受害企业可能密码策略完善，多因素认证全面覆盖，员工安全意识培训年年举办，零信任架构刚刚完成部署——但依然挡不住这次攻击。

因为攻击者根本就没有走"人"这扇门。

我们一直在守护一扇错误的门

过去十余年，企业身份安全的演进几乎完全围绕"人"展开。

从推广密码管理器到强制多因素认证，从部署单点登录到引入行为分析，安全团队构建了越来越精密的员工身份防护体系。我们知道张三应该从哪个城市登录，用哪台设备，在什么时段访问哪些系统。

一旦出现异常，告警会在分钟内触发。

这套体系并没有错。它非常必要，而且它确实在发挥作用。

但它只守住了今天企业数字资产访问入口的一部分。

云原生时代，真正在夜以继日访问企业系统的，已经不只是员工。容器在调用数据库，微服务在相互请求，CI/CD流水线在向云平台发布制品，SaaS集成在读取客户信息，自动化脚本在处理财务数据，AI智能体在调用邮件、文档和业务系统——这些机器到机器的认证请求，数量早已远远超过人类的登录行为。

而我们为这些机器准备的身份管理体系，几乎还停留在原始状态。

技术媒体DZone近期刊发的一篇文章，为这种失衡状态给出了一个精准的命名：机器身份债务。

什么是机器身份

在深入理解这一概念之前，有必要先澄清一个常见的误解。

机器身份，不是"给服务器起一个用户名"这么简单。

它是代码、应用、服务、容器、工作负载和自动化系统，在访问其他资源时用来证明"我是谁、我能做什么"的数字凭证。它可能表现为一枚API密钥、一个OAuth令牌、一张客户端证书、一个Kubernetes ServiceAccount、一个云IAM角色，也可能是某个SaaS集成、机器人程序或AI智能体调用企业系统时持有的访问授权。

这些身份的数量，在现代企业里几乎是天文数字，而且它们的生命周期往往远比人类账号漫长，管理却比人类账号松散得多。

一个员工离职时，企业通常有完整的流程：停用账号、回收设备、撤销权限、注销门禁。整个过程在数小时内完成。

但一个已经下线的微服务、被遗忘在角落的测试脚本、三年前接入的第三方SaaS应用——它们所持有的密钥和令牌，可能至今仍然有效。没有人记得它们的存在，没有人知道它们能访问什么，也没有人负责在适当的时候终止它们的权限。

它们安静地存在着，直到某一天，被不该看见它们的人发现。

机器身份债务：一种沉默的累积

"技术债"这个概念，软件工程师们再熟悉不过。项目赶工期时临时选择不够优雅的实现方案，系统不会立即崩溃，但维护成本和潜在风险会随时间悄悄累积，直到某一天以一场重构危机或严重故障的形式集中爆发。

机器身份债务遵循同样的逻辑，只是累积的不是代码缺陷，而是未经持续治理的"信任"。

每创建一个长期不过期的API密钥，是在借入一笔身份债务。每批准一个多年不复核的OAuth授权，是在借入一笔身份债务。每保留一个无人认领的服务账号，给某条部署流水线赋予明显超出任务需要的管理员权限，把密码和令牌随手复制进代码、工单、聊天记录或文档——每一次，都是在借入一笔身份债务。

它不会让构建失败，也不会直接导致业务中断，因此极其容易被忽视。

但一旦某枚凭据落入攻击者手中，企业将一次性偿还所有积累下来的"利息"。

这类债务大致可以归结为六种形态：长期有效且缺乏轮换策略的凭据；已不再对应真实工作负载的服务账号；审批后无人复核的第三方OAuth授权；散落在代码、工单、聊天记录与知识库中的敏感信息；权限范围远大于业务所需的IAM角色；以及没有明确责任人的机器身份。

而其中最危险的，并不一定是某一枚已知泄露的密钥。

最危险的，是企业无法回答三个最基础的问题：

我们现在到底拥有多少机器身份？每个身份由谁负责？它能够访问哪些资源？

当资产清单、实际权限和责任归属长期脱节，企业面临的就不再是一次普通的密钥清理工作，而是一种更深层的困境——"身份破产"：没有人敢确认哪些账号可以删除，也没有人能说清楚撤销某项授权是否会让生产系统在凌晨突然中断。

到了这个阶段，治理往往不是由年度规划推动的，而是被一次安全事件强行启动。

传统检测为什么视而不见

围绕人类账号设计的安全检测体系，建立在几个看似合理的假设之上：账号有明确的使用者；登录行为不会每秒发生数万次；凭据被盗后，攻击者会呈现出异地登录、陌生设备、深夜访问或短时间内大量认证失败等可疑特征。

这些假设放到机器身份上，几乎全部失效。

一个服务账号每天认证一万次，完全正常。一条CI/CD流水线在凌晨三点部署，可能正是预定计划。一个SaaS集成从境外云节点访问企业数据，可能正是其产品架构的设计如此。

对机器身份而言，"发生了大量访问"本身并不意味着异常。真正需要判断的是：这枚凭据是否仍由正确的工作负载持有？它是否正在执行最初被授权的那些操作？它的访问范围是否悄悄发生了偏移？

Salesloft Drift事件之所以值得反复咀嚼，正是因为攻击者使用的是一枚完全有效的令牌。系统看到的不是"非法登录"，而是一个被正式授权的应用在调用接口——一切看起来都那么正常。

密码策略没有失效。多因素认证没有失效。员工行为分析没有失效。只是这些防线根本就不覆盖这次攻击真正利用的那条入口。

数字的规模让问题更加触目惊心。GitGuardian对Verizon 2025年《数据泄露调查报告》的解读显示，公共代码托管平台中被发现的暴露秘密达到441780个；GitHub中泄露秘密的修复时间中位数长达94天。这意味着，一枚已经公开曝光的凭据，可能在将近三个月内仍然有效，为攻击者留下充足的搜索、验证和利用窗口。

更现实的是，秘密并不只存在于代码仓库。开发人员为了排查故障，可能把访问令牌贴进工单；运维人员为了协作，可能把数据库连接信息发进聊天群；客服记录中可能出现客户无意中提交的云密钥；知识库和配置文档里也可能长期保存着测试环境密码。只扫描Git仓库的企业，会漏掉大量真正在业务流转中暴露的敏感凭据。

第三方应用：信任的放大器

云时代的企业系统很少孤立存在。CRM连接营销平台，客服连接邮件和工单，数据平台连接对象存储，自动化工具连接代码仓库和云账户。每完成一次集成，企业就向一个外部实体授予了新的信任。

这种信任具有明显的放大效应。

一个第三方SaaS供应商可能同时服务数百家客户。一旦其中某枚令牌、某套供应链组件或某个集成平台被攻破，风险就可以跨越多个租户瞬间扩散。受害企业自身可能没有弱密码，也没有未修补的互联网漏洞，但攻击者仍然可以沿着供应商早已获得的授权通道悄然进入。

OAuth授权管理是其中最值得警惕的盲区。员工账号通常会在离职时被及时停用，但第三方应用的OAuth授权往往不会随人员变化自动终止。项目结束、人员调岗，当初批准接入的人早已不知去向，应用却可能仍然安静地持有读取客户信息、邮件、工单乃至云资源的权限，年复一年。

因此，第三方风险管理不能止步于供应商认证和安全报告。企业还需要持续回答更具体的问题：它当前持有哪些令牌？令牌允许访问哪些对象？是否具备写入、导出或管理权限？多久没有被实际使用？谁是内部业务负责人？一旦发生安全事件，企业能否在分钟级别完成撤销，而不是被动等待供应商统一处置？

AI智能体，下一个身份危机引爆点

如果说过去的机器身份治理主要面对微服务和CI/CD系统，那么AI智能体正在将这个问题推向一个新的量级。

传统脚本执行预先写好的步骤，行为边界相对清晰。AI智能体则可能根据任务目标自主选择工具、组合调用多个API，在运行过程中访问邮件、文档、数据库、代码仓库和各类业务系统。

一旦企业给智能体配置了长期有效、权限过大的凭据，它就不只是一个效率工具，而成为了一个高权限主体——而且是一个行为远比传统服务账号难以预测的主体。

这里的风险未必来自"AI被攻击"。更常见的问题可能恰恰来自权限设计本身：为了让智能体顺利完成任务，开发团队一次性授予了过多权限；测试阶段使用的令牌被带入了生产环境；多个智能体共享同一身份，导致无法区分具体是哪个行为导致了哪次数据访问；任务结束后，临时权限没有自动失效；智能体在调用外部工具时，又将企业的信任进一步传递给了新的第三方。

AI智能体并不是现有机器身份数量的简单叠加，而是会加速信任关系的复杂化。若企业仍以"一个员工对应一个账号"的思维理解身份治理，将越来越难以解释系统中真正发生的访问行为。

如何开始偿还这笔债务

治理机器身份，不能从采购某款新产品开始，而应从重建身份生命周期开始。

第一步，建立统一清单，强制绑定责任人。企业需要系统盘点API密钥、服务账号、OAuth应用、客户端证书、云IAM角色、Kubernetes身份、CI/CD凭据和AI智能体授权。每个身份都应关联业务用途、技术负责人、权限范围、创建时间、最后使用时间和预计失效时间。一枚名为"test-service"的旧凭据，可能仍然拥有生产数据库和云控制台的访问权限。名称可以骗人，真实的授权关系不会。

第二步，优先淘汰长期静态凭据。凭据的生命周期越短，泄露后可被利用的窗口越小。能够使用短期令牌、工作负载身份或角色临时凭证的场景，应尽量避免长期API Key。对无法立即改造的系统，也应建立自动轮换、集中保管和泄露后快速吊销机制。"定期更换"不能只是制度文件里的一行字，而必须落实为可验证的自动化流程。

第三步，把最小权限从口号变为可验证的策略。读取数据的集成不应默认获得写入权限。部署测试环境的流水线不应能够管理生产账户。权限需要能够被版本化、审计和定期复核。对于高权限操作，可以采用即时授权机制：任务开始时发放权限，任务完成后自动撤销。

第四步，单独治理第三方OAuth授权。定期审查所有连接外部系统的第三方应用，重点检查授权范围、使用频率和当前负责人。长期未使用、无法确认业务必要性或权限明显过大的授权，应立即撤销。对于新接入的第三方应用，审批不应只问"能否接入"，而应问"接入后能看到什么"，以及"出现安全事件时如何一键撤销"。

第五步，把秘密扫描扩展到完整协作链路。代码仓库扫描只是起点，还应覆盖CI/CD日志、容器镜像、工单系统、聊天工具、文档平台和客服数据。更重要的是，仅仅删除代码中的字符串并不等于风险消失——历史提交、克隆仓库和日志副本中可能仍然保留同一凭据。一旦确认秘密已进入不受控环境，正确的处置方式不是"把它删掉"，而是立即将其视为已泄露，完成吊销、轮换和影响范围排查。

第六步，从一次认证走向持续验证。新的安全边界不应只问"这枚令牌是否有效"，还要问"这个工作负载现在是否仍值得信任"。SPIFFE和SPIRE提供了一种颇具代表性的思路：根据工作负载实际运行的环境属性，签发短期、可验证的身份，而不是依赖长期写入配置文件的静态秘密。Pinterest、Square、Uber和ByteDance等企业均已公开分享过相关实践。

安全管理需要新的提问方式

许多企业衡量身份安全时，仍然主要关注员工多因素认证覆盖率、弱密码数量、离职账号停用时间和异常登录次数。这些指标仍然重要，但已经远远不足以衡量机器身份风险。

企业还需要开始关注：机器凭据的平均有效期、静态凭据占比、没有责任人的服务账号数量、长期未使用但仍然有效的身份数量、第三方OAuth授权复核率，以及企业发现凭据泄露后完成吊销所需的时间。

最后这个指标尤其值得关注。扫描工具发现了泄露的秘密，并不意味着风险已经消失。只有旧凭据被确认失效、相关系统完成影响排查，事件才算真正进入可控状态。

同样重要的，是建立身份关系图，回答一枚凭据能够沿着哪些信任链访问其他系统。一个客服平台令牌本身可能只能读取工单，但工单中可能保存着云密钥；云密钥能够访问对象存储；对象存储中可能包含代码、配置文件和客户数据。攻击者利用的往往不是单个权限，而是多个看似合理的权限组合之后形成的攻击路径。

这不是安全部门的独角戏

机器身份通常由开发、运维、平台工程、数据团队、业务部门和第三方供应商共同创建。安全部门可能负责制定规范，却未必知道某个服务账号是否可以删除；开发人员知道账号用途，却未必了解它已经拥有跨系统权限；采购部门知道供应商合同，却未必掌握OAuth令牌的实际授权范围。

因此，机器身份治理不能简单归结为"让安全部门把密钥管起来"。

企业需要让不同角色各归其位：业务负责人判断集成是否仍有必要，系统负责人确认身份用途，平台团队提供短期凭据和自动轮换能力，安全团队负责风险策略、监测和审计，采购与法务则需要把令牌管理、事件通知和撤销机制纳入供应商合同要求。

尤其是在新项目上线时，机器身份的治理成本应当被纳入架构设计阶段的预算。创建一个服务账号看似只需要几分钟，但围绕它产生的资产登记、权限审批、日志记录、轮换、应急吊销和最终下线，都需要持续投入。只预算"如何创建"，不预算"如何治理"，正是机器身份债务不断累积的根本原因。

结语：我们的系统，到底在信任谁

过去，安全团队最常问的问题是：谁登录了系统？

未来，更重要的问题将是：哪个工作负载正在访问系统？它为什么拥有这项权限？这种信任是否仍然有效？

机器身份债务之所以危险，恰恰在于它通常不以故障形式出现。一个过期项目遗留的服务账号不会主动报警，一枚多年未轮换的令牌也不会影响业务运行，一项过度授权的OAuth集成甚至会让某些流程看起来更加顺畅。它们看起来都在"正常工作"，直到凭据落入了不该拥有它的人手中。

今天真正支撑业务运行的，已经是由人类账号、机器身份和第三方信任共同组成的复杂网络。在这个网络中，最危险的凭据往往不是明显非法的凭据，而是一枚完全有效、长期无人关注、权限仍然在线的凭据。

攻击者不需要让系统犯错。他们只需要接管系统已经决定信任的那个对象。

真正成熟的云安全，不是等事件发生后查清攻击者拿走了什么，而是在事件发生之前，就能够准确回答——我们的系统，到底在信任谁？

信息来源：51CTO https://www.51cto.com/article/850411.html