零信任卡在没人敢动老权限，勒索病毒可不等你

过去两年，零信任几乎成了安全架构升级的默认答案。方案汇报里不出现“持续验证”“最小权限”“微分段”，似乎就落后于时代。但真正在落地一线待过的人都清楚一个尴尬现实：很多组织的零信任项目，卡在了最不该卡的地方——没人敢动那些跑了七八年甚至十几年的老权限。

这不是技术问题，而是组织问题。零信任的核心动作之一，是把过去“默认信任、一次授权长期有效”的权限模型，改成“每次访问都验证、权限随场景收缩”。听起来很干净，但一旦落到实际系统上，你会发现大量老权限根本没有清晰的归属人。它们可能是某个已离职工程师留下的服务账号，可能是某个早已下线的业务遗留的数据库白名单，也可能是某套内部工具为了方便调试而长期开放的超级权限。谁都说不清这些权限还有没有用，但谁也不敢删——万一删了，某个没人记得的流程断了，责任算谁的？

于是出现一种奇特状态：零信任的控制台建起来了，策略引擎上线了，可视化报表也做得漂漂亮亮，但真正的高危权限依旧原地不动。项目组把这类权限标注为“待确认”，一待就是几个季度。安全团队不敢动，业务团队不想动，运维团队不愿背锅。零信任被供在架构图上，老权限躺在生产环境里，两者相安无事，直到勒索病毒找上门。

勒索病毒的逻辑从来不看你的架构图有多先进。它只关心一件事：从入口到横向移动，哪条路径阻力最小。而长期未清理的老权限，恰恰是横向移动最好的跳板。一个遗留的服务账号，可能拥有跨多个子网的读写权限；一条陈旧的远程管理通道，可能绕过了新上线的身份验证网关。攻击者不需要正面突破零信任的策略层，只需要找到那些“零信任管不到”的缝隙。更麻烦的是，这类权限往往不在资产清单里，日志覆盖也不完整，等发现异常时，加密行为可能已经铺开。

这里有一个被普遍低估的时间差：零信任的建设周期以年计，而勒索病毒的突破周期以小时计。前者需要梳理身份、重构策略、改造应用、推动业务配合，每一步都涉及协调和妥协；后者只需要一个弱口令、一个未打补丁的暴露面、一个没人认领的高权限账号。当组织还在为“这个老权限到底能不能回收”开会讨论时，攻击者已经在用同样的权限做权限提升了。

问题的根源不在于零信任理念本身，而在于很多落地路径把“权限治理”这件苦活往后放了。厂商演示时喜欢讲策略编排和动态授权，因为这些看起来技术含量高、界面效果好；但真正决定零信任成败的，是那些脏活累活：账号盘点、权限归属确认、僵尸权限清理、服务账号托管。这些工作没有炫目的界面，却直接决定了攻击面能不能收窄。

更现实的困境是，老权限背后往往绑着老业务。一套运行了十年的内部系统，可能只支持固定IP加固定账号访问，改造它需要业务停机、预算审批、供应商配合，周期和成本都不低。于是安全团队选择妥协：先不动它，等业务迁移了再说。但业务迁移本身又是个漫长过程，一年两年过去，这套系统还在跑，权限还在用，风险还在累积。零信任项目在这种妥协中被逐渐稀释，最后变成一层叠加在旧架构上的“外挂”，而不是真正的架构替换。

要打破这个僵局，思路需要调整。第一，把“权限清理”从零信任项目的附属任务提升为独立的前置工程，先做减法再做加法。在部署复杂策略之前，先完成一轮高权限账号和僵尸权限的集中治理，哪怕范围有限，也要形成可复用的归属确认机制。第二，对确实无法立即回收的老权限，采取“隔离加监控”的过渡策略：用网络层微分段限制其可达范围，用行为基线监控其使用模式，把“不敢动”变成“动不了、看得住”。第三，把权限生命周期管理写进运维流程，新权限申请必须带过期时间和责任人，从源头减少下一批“老权限”的产生。

零信任不是买一套平台就能完成的状态，而是一场持续的权限收敛运动。它的敌人不只是外部攻击者，还有组织内部对历史包袱的回避。勒索病毒不会因为你的零信任项目还在推进就暂停攻击，它只会顺着最松的那条权限链一路向下。真正需要回答的问题不是“零信任架构什么时候建完”，而是“那些没人敢动的老权限，今天能不能先收掉一批”。

安全建设的残酷之处在于，攻击者只验证结果，不体谅过程。架构图上的零信任再完整，也挡不住一个被遗忘的超级账号。与其在策略编排上反复打磨，不如先拿起权限清单，把那些“待确认”一个个变成“已回收”。这件事没有捷径，但越早开始，勒索病毒能走的路就越窄。