权限漏洞平均暴露14天：自动修复为何卡在最后一环

云成本浪费能自动关停，同样的技术用在安全权限上却几乎没人敢碰。一个IAM错误配置从被发现到被修复，平均要在工单队列里躺14天——这14天就是攻击窗口本身。

一个典型的14天漏洞周期

想象这个场景：云配置漂移检测器发现一个IAM主体（身份与访问管理中的用户或角色）拥有通配符S3:*权限——这意味着它能访问所有S3存储桶。告警出现在云安全态势管理（CSPM）控制台，工程师看到，创建工单，丢进安全 backlog。

工单静静等待。下一个冲刺周期，工程师终于捡起它，阅读上下文，登录控制台，编辑策略，关闭工单。

根据Lacework《2023云威胁报告》对企业环境的测量，这个流程平均耗时14天。而实际修改策略只需要4分钟。14天的暴露时间来自队列深度、冲刺边界和上下文切换开销，而非技术难度。

审计环节的成本同样累积。当SOC 2审计师要求查看IAM错误配置的及时修复证据时，工单显示"周一创建，次周五解决"——这个时间线无法被辩护为"及时控制"。

成本自动化为何能跑通，安全却不行

闲置虚拟机午夜自动关闭，超配实例按计划缩容——云成本自动化已是标配。同样的闭环架构应用于IAM过度授权和安全组漂移，却 largely unexplored（很大程度上未被探索）。

核心差异在第四步：评估。

闭环云修复模式遵循四阶段循环：检测偏差、评估是否可安全自动修复、执行修复、生成审计记录。这被称为DERA循环：检测（Detect）、评估（Evaluate）、修复（Remediate）、审计（Audit）。

成本修复的评估很简单：这台实例连续7天空闲？是，关闭。安全修复的评估却要回答更棘手的问题：这个主体当前是否在使用？是否有活跃会话？是否在豁免清单上？如果修复错误，能否回滚？

评估关卡是自动修复能在生产环境安全运行的关键。没有它，系统会在修复错误配置的同时制造故障。有了它，只有确定安全的案例进入自动化，边缘案例进入更短的人工审核队列。

从"信任人"到"信任系统"的切换点

检测-工单模式是一种"信任人"模式。它假设工程师会在可接受的时间窗口内行动。10个服务时，这个假设成立。100个服务、每个服务40个活跃IAM主体时，人工审核瓶颈无法跟上发现量的节奏。

自动IAM修复消除的是窗口本身，而非仅仅是错误配置。错误配置被创建与被修复之间的间隙，就是漏洞利用发生的时机。

这种方法可将工单队列减少90%——不是通过忽略问题，而是通过将确定性案例从人工流程中剥离。剩余10%的复杂案例获得更快的响应，因为队列不再被淹没。

当安全团队还在争论"自动修复会不会太激进"时，攻击者已经在扫描那些创建后第3天、第7天、第12天仍未修复的通配符权限。14天不是运营不便，是设计选择的结果。而设计选择可以被重新设计。

如果评估关卡能做到"修复错误时可回滚"，安全团队是否还有理由坚持那14天的人工队列？