Havenlon｜Policy 不是神谕（六）：攻击者为什么总是寻找最宽松的策略来源-开发者社区

攻击者不需要证明所有策略都错，只需要找到一个愿意说"可以"的入口。

摘要

当一个系统同时拥有多种 Policy 时，人们很容易产生一种安全感：SaaS 有组织策略，本地有额度和目标限制，审批平台有人确认，风控系统有风险评分，执行设备还有自己的规则。看起来，策略越多，攻击者需要突破的防线就越多。

但现实往往恰好相反。如果这些策略之间的关系是"只要其中一个来源允许，请求就可以继续"，那么多策略并不会形成多重防线，它们会形成多个可供选择的入口。

攻击者不会平均攻击所有策略，不会执着于突破最坚固的设备边界，也不会主动选择审计最严格、限制最多的流程。他们会寻找最宽松的阈值、最模糊的权限、最容易被污染的上下文、最容易受时间压力影响的人、最旧的本地状态、最容易被重新解释的审批结果、最容易被业务理由临时放宽的路径。

对攻击者来说，真正重要的问题不是"系统一共有多少条 Policy"，而是"哪一条 Policy 最容易给我一个可以继续向前的答案"。

前五篇分别证明了 SaaS、本地、人各有边界。这一篇切换到攻击者视角，把前面的理论转成对抗性分析：如果系统没有明确的收敛原则，攻击者最终面对的不是多层约束，而是一场"寻找最宽松裁判"的游戏。这也为后续几篇的收敛机制铺路。

一、攻击者不会攻击系统的平均强度

安全设计经常关注系统最强的部分。团队会强调云端使用了严格身份认证、审批需要多人参与、本地设备具有硬件安全边界、敏感操作经过风险评分、所有请求都有日志、执行参数经过签名。这些能力都很重要，但攻击者不会按照系统架构图，从第一层开始依次突破。

他们不问"这个系统整体上有多安全"，他们问"哪一条路径最便宜"。这就是安全工程里的最小阻力路径（path of least resistance）。如果硬件边界很难突破，他们就不会优先攻击硬件；如果管理员账号难以窃取，他们可能改为诱导一个正常用户；如果高风险流程需要多人审批，他们可能把操作拆成多个低风险动作；如果新目标需要严格审核，他们可能复用一个已有白名单目标；如果本地限制很严格，他们可能寻找一个仍使用旧策略的节点。

所以，一个系统的真实安全强度，往往不由最坚固的边界决定，而由最容易被利用的策略来源决定。这就是经典的木桶效应 / 最弱环节（weakest link）——安全强度等于最薄弱一环，而不是最强一环的平均。

二、多种 Policy 可能变成多条放行路径

假设一个系统有四种策略来源：SaaS Policy、本地 Policy、人工审批、风险模型。表面上，这像是四重保障。但如果系统的实际逻辑是：

SaaS 允许，或者 本地允许，或者 审批完成，或者 风险评分正常， 则继续执行。

那么这不是四重保障，而是四条通道。攻击者不需要同时让四个来源都接受请求，只需要选择最容易操纵的一个：SaaS 很严格但本地仍保留旧白名单；本地限额很低但人工审批可以临时提高额度；审批流程很复杂但风险模型可以将请求标记为低风险自动放行；高风险工具受限但某个通用自动化接口权限过宽。

系统内部可能认为这些路径是为了提高可用性，但在攻击者眼中，它们都是替代入口。这本质上是一个逻辑结构问题：只要不同策略来源之间存在OR关系（任一允许即可继续），攻击者就会进行策略来源选择。他们不会击败策略系统，他们会让系统自己选出最宽松的答案。OR是给攻击者的礼物，AND才是给防御者的约束——这是本篇最核心的一句话。

三、最宽松的来源不一定是规则最少的来源

"最宽松"不一定意味着 Policy 文档里写着更低的限制。有时一套规则看起来非常严格，却因为输入容易被操纵而变得宽松。

例如一条 SaaS Policy 规定"只有真实订单、可信供应商、双人审批并且低风险时才能执行付款"。这条规则本身并不宽松，但如果攻击者可以创建虚假订单、注册一个看似正常的供应商、污染风险数据、诱导审批人、修改显示名称，那么这条 Policy 在现实中可能比一条固定本地额度更容易通过。

同样，一条本地规则"只允许向白名单目标执行"看起来非常严格，但如果白名单长期不更新，或者目标控制权已经变化，那么"白名单"也可能成为宽松入口。

因此，判断某个策略来源是否宽松，不能只看规则文本，还要看输入是否容易伪造、状态是否可能过期、上下文是否可以包装、配置是否容易修改、决策是否容易受人影响、结果是否可以被复用、异常时是否默认放行。一个看起来严格、但依据脆弱的 Policy，可能比一条简单固定的限制更加危险——规则的强度，不会超过它所依赖的输入的强度。

四、攻击者最喜欢模糊的授权

明确授权很难被扩大。例如"允许在今天 14:00 前，向账户 X 支付 20,000 元，仅允许执行一次"——目标、金额、时间和次数都受限，攻击者即使获得这次授权，也很难将它用于另一个动作。

但模糊授权不同："允许处理供应商付款""允许 Agent 执行退款""允许管理员管理生产环境""允许成员进行紧急操作"。这些描述的是一类能力，而不是一次具体动作。攻击者喜欢这类 Policy，因为它们留下了大量解释空间：处理退款可以是多少金额？向哪个账户？执行多少次？可以修改目标吗？失败后可以自动重试吗？"管理生产环境"是否包括导出数据、替换证书和修改权限？

如果这些边界没有明确写入执行约束，宽泛授权就会成为一个可以持续利用的能力入口。这与第五篇讲的"有限授权"正是一体两面：授权越粗，攻击者的可解释空间越大。所以攻击者寻找的往往不是完全没有限制的系统，而是限制写得足够模糊、可以被重新解释的系统。

五、业务例外，经常是最宽松的策略来源

大多数系统在正常流程之外都会保留例外机制：紧急审批、管理员强制放行、临时提高额度、跳过风险检查、手工补录状态、离线执行、故障期间使用旧策略、特殊客户快速通道、事后补审。这些机制通常是为了保证业务连续性，系统不能因为某个服务暂时故障就完全停止所有工作。

但例外机制也经常成为攻击者最关注的地方。因为正常 Policy 经过长期设计、测试和审计，而例外 Policy 往往是在压力下临时增加的——文档不完整、使用频率低、审计不足、权限集中、判断依赖口头说明、条件更模糊、缺乏自动化约束、默认相信高权限操作人。

攻击者不一定需要突破正常流程，他们可能只需要制造一个看似合理的异常："系统故障了""客户非常紧急""风控暂时不可用""负责人无法联系""必须先执行，之后再补材料"。一旦系统进入例外流程，原本严格的 Policy 可能迅速被降低。因此，安全系统必须把例外路径视为核心攻击面，而不是边缘流程——它往往就是那条最短、最亮的路。

六、攻击者会利用策略之间的语义差异

不同策略来源通常使用不同语言理解同一个动作。业务系统说"这是一次供应商付款"，审批系统说"这是一张已完成双人审批的工单"，本地 Policy 说"这是一个金额低于上限、目标在白名单中的请求"，执行设备只看到"使用密钥槽位 3 对 Payload H 进行签名"。

这些说法可能都在描述同一个动作，但它们关注的内容不同。攻击者可以利用这些语义差异：业务系统确认了供应商名称但本地只验证账户标识；审批人批准了退款任务但执行层允许任意退款目标；SaaS 限制单笔金额但本地只检查每日总额；风险系统分析用户行为却不检查最终参数；设备验证 Payload 完整却不知道 Payload 是否符合原始业务意图。

每一层都可能正确完成自己的检查，但不同层检查的不是同一个对象。攻击者只需要让请求在每一层都呈现出"足够合法"的局部形态——这就是策略来源之间的语义缝隙。如果系统没有使用统一的 Intent 将这些判断绑定起来（第二、四、五篇反复强调的 Intent Hash），攻击者就可以在不同策略之间切换描述：让业务系统批准一个故事，让本地系统验证另一组字段，最后让执行层完成第三种解释。

七、攻击者会把高风险动作拆成低风险动作

当 Policy 对大额、高频或高权限操作施加严格限制时，攻击者通常不会正面挑战阈值，他们会拆分：将一笔大额转账拆成多笔小额、将一次大规模数据导出拆成多次查询、将永久权限提升拆成多个临时授权、将完整攻击链拆成多个看似正常的工具调用、通过多账户多设备多时间窗口分散行为。

每个动作单独看都可能满足 Policy——单笔金额没有超限，单次导出数量不大，每个工具调用都有权限，每次操作之间相隔足够长——但组合起来，系统已经发生了高风险变化。这就是经典的切香肠攻击（salami slicing）。

这说明攻击者不只寻找最宽松的策略来源，还会寻找最宽松的策略粒度。如果 Policy 只判断单次动作，而不理解累计状态、关联行为和完整执行链，攻击者就可以在规则允许范围内完成规则本来想阻止的事情。所以高风险 Policy 必须关注累计金额、累计次数、目标关联、时间窗口、多步骤组合、多账户协同、一系列动作的最终效果。否则，攻击者不需要突破阈值，只需要绕着阈值走。

八、攻击者会复用过去的合法状态

历史上的合法状态，往往是非常有价值的攻击资源：已经过审批的请求、已进入白名单的目标、已签发的成员证书、已授权的 Agent 会话、已通过风险评估的设备、已批准的工单、已建立的供应商关系、已缓存的本地权限。

这些状态本来都是真实合法的，攻击者不需要伪造它们，只需要让系统在不合适的时间继续相信它们：复用已过期的审批、在成员被撤销后使用旧凭证、利用旧策略版本继续执行、在目标控制权变化后继续使用白名单、将一次执行许可用于多次重试、将一个 Intent 的批准结果绑定到另一个 Payload、利用离线节点尚未更新的状态。

攻击者喜欢旧状态，因为它已经通过了所有检查，自带合法性——这正是第二篇 TOCTOU 与状态陈旧的对抗性利用。系统真正需要防止的，不只是伪造的ALLOW，还包括曾经真实、现在已经失效的ALLOW。

九、攻击者会优先选择最容易影响的人和"系统不能停"的心理

当系统保留人工审批时，攻击者会评估不同审批人的行为特征，寻找工作量最大的人、最依赖 AI 摘要的人、对底层参数最不熟悉的人、最担心阻碍业务的人、经常处理紧急请求的人、习惯快速清空待办的人。这不是因为这些人能力差，而是因为审批判断受工作环境影响。攻击者会针对性构造请求：选择对方最忙的时间、模仿熟悉的业务格式、使用常见金额、引用真实项目、制造管理层已同意的印象、强调时间压力、把关键变化隐藏在大量正常信息中。如果多人审批共享同一个上下文，攻击者甚至不需要分别说服每个人，只需要污染所有人看到的同一份材料（第五篇的多人审批陷阱）。

另一条更隐蔽的路径，是利用组织"系统不能停"的心理。当 Policy 阻止执行时，团队常会认为 Policy 太严格、风控误报、同步延迟不该影响业务、安全流程拖慢交付，于是增加一个临时开关、由管理员手动放行、允许使用上一次状态，或把高风险动作重新分类为普通操作。攻击者非常清楚：一个不能被直接突破的 Policy，可能会被组织自己放宽。所以他们可能故意制造大量拒绝、服务异常、风控噪声、同步故障、审批拥堵、业务中断压力——目的不一定是直接完成攻击，而是让组织主动降低防线。这类攻击针对的不只是技术系统，还针对组织对可用性与安全性的权衡方式。如果系统没有预先设计受控降级，业务压力最终往往会产生非正式绕过。

十、策略回退顺序，决定了攻击者的目标

当主要 Policy 不可用时，系统通常会采用回退逻辑：

云端不可用 → 使用本地缓存 本地状态异常 → 请求管理员确认 管理员无法响应 → 使用紧急流程

回退机制看起来是为了增加韧性，但它也定义了一条从严格到宽松的路径。如果每次失败都会让系统进入更宽松的策略来源，那么攻击者只需要让前面的严格策略不可用：阻断 SaaS 连接让系统使用旧缓存、制造本地状态异常引导管理员强制放行、让风险服务超时触发默认低风险、使审批系统拥堵启用紧急权限、破坏状态同步使节点继续使用旧规则。

此时攻击者不需要欺骗严格 Policy，只需要让系统自动退到宽松 Policy。所以安全的回退不应该意味着"检查越失败，限制越少"，而应该意味着"状态越不确定，执行能力越小"。这正是Fail-Secure（安全优先降级）与普通业务降级最本质的区别：普通降级为了保住可用性而放宽，安全降级为了保住边界而收缩。

十一、最危险的策略来源，是默认允许的来源

有些 Policy 的逻辑是"没有发现问题，就允许"。这类策略依赖识别已知风险，只要请求没有触发黑名单、异常阈值或检测规则就会继续。这种设计在许多低风险业务中很常见，但在高风险执行中可能非常危险——因为攻击者不需要证明请求安全，只需要避免被现有规则识别：使用从未被标记的新账户、保持金额低于异常阈值、模仿正常时间和频率、使用合法身份、通过正常接口、避免触发已知攻击特征。

系统会因为"没有证据证明它危险"而允许。但：

没有发现风险，不等于已经证明安全。

这就是default-allow（默认允许）与 default-deny（默认拒绝）的根本分野。对不可逆、高影响执行，更合理的问题应该是"是否已经具备足够证据证明它可以在当前边界内发生"，而不是"有没有发现它危险"。这两种逻辑看起来相近，实际上代表完全相反的安全方向——一个把举证责任放在防御者身上，一个放在请求本身身上。

十二、攻击者会制造策略冲突，然后选择有利结果

如果不同 Policy 给出不同结论，系统必须决定如何处理：SaaS 允许本地拒绝、本地允许风险模型拒绝、审批通过但设备状态异常、业务系统标记紧急但额度已用尽、新 Policy 拒绝但旧节点仍然允许。

如果系统的处理原则是"找一个能够继续业务的解释"，攻击者就会主动制造冲突，因为冲突会创造人工介入和例外空间。他们可以说"本地状态可能过期""风险模型可能误报""审批人已经同意""SaaS 才是最新状态""设备检查太保守""业务损失正在扩大"。最终，组织可能选择最有利于继续执行的来源。

但从安全角度看，策略冲突真正表达的是：系统无法证明所有关键状态一致。这时最合理的结果不应是选择最宽松者，而应是收缩——降低额度、限制目标、重新审批、重新同步状态、暂停高风险动作、进入 Safe Mode。如果策略冲突总由业务优先解决，攻击者就会把"制造冲突"变成一种放行工具。这一点，是第八到十一篇"取更严格者"的直接动机。

十三、攻击者会寻找没有被证据绑定的 Policy 结果

一个没有绑定具体证据的 Policy 结果，非常容易被复用：

approved = true risk = low member_authorized = true

这些结果没有说明对哪个 Intent、对哪些参数、使用哪个 Policy 版本、在什么时间、基于什么状态、有效到什么时候、可以执行多少次。攻击者可以尝试把它用于另一个目标、更高金额、不同操作、多次重试、更晚的时间、已变化的风险状态、另一个设备或节点。

所以攻击者最喜欢可移植的ALLOW——它像一张没有姓名、日期和用途的通行证（第五篇的 bearer token）。真正安全的 Policy 结果必须难以迁移，它需要绑定 Intent Hash、最终参数、Policy Hash、状态 Epoch、身份、设备、时间窗口、次数与额度。这样，一次允许才只能用于它真正批准的那件事情。让ALLOW不可移植，就等于抽走了攻击者手里最好用的那张牌。

十四、策略来源越多，攻击者越会进行 "Policy Shopping"

在法律、监管和商业环境中有一个常见现象：当不同地区、不同规则或不同机构给出不同标准时，人们会选择最有利的一方（监管套利）。攻击者在复杂系统中也会做同样的事情，可以把它称为Policy Shopping——策略挑选。

他们会测试：哪个接口限制最低、哪个节点状态最旧、哪个审批人最容易通过、哪个业务类型审核最弱、哪个工具权限最宽、哪种请求分类更容易自动执行、哪个时间窗口监控最少、哪个区域或租户使用旧策略、哪个异常流程最容易被触发。

一旦找到更宽松的来源，他们就会重新包装请求，使其符合那个来源的语言：一笔资金转移可以被包装成退款，一次权限提升可以被包装成故障恢复，一次数据导出可以被包装成报告生成，一次高风险配置修改可以被包装成常规维护。这说明多策略系统必须防止请求在策略来源之间随意迁移——不能因为换了一个分类、接口或流程，就让同一风险动作获得更宽松的判断。

十五、多策略的价值，不是让请求更容易找到通过路径

有些系统引入多策略是为了提高成功率：一个来源无法判断就交给另一个，一个引擎拒绝就由人工复核，本地无法确认就询问云端，云端不可用就使用缓存。这种设计从业务角度看很合理，它尽可能避免一个单点判断阻塞整个流程。

但如果所有替代路径的目的都是"最终找到一个允许"，那么多策略系统的真实目标就变成了"让请求更容易通过"——这与安全系统的目标恰好相反。安全中的多策略应该用于补充视野、发现冲突、相互否决、收缩权限、限制单点错误、提供不同类型的证据，而不是用于不断尝试直到某一层给出ALLOW。

真正的多策略安全不是容错式放行，而是约束式收敛。

这句话，可以看作从"发现问题"（前六篇）转向"给出机制"（后六篇）的枢纽。

十六、任何一个来源都不应成为绕过其他来源的捷径

一个合理的策略体系需要明确规定：SaaS 允许不能绕过本地拒绝，本地允许不能绕过云端冻结，人工审批通过不能绕过参数不一致，风险评分正常不能绕过额度限制，紧急流程不能取消不可突破的底线，管理员权限不能伪造执行事实，网络离线不能自动扩大本地权限。

也就是说，每个 Policy 来源都只能在自己的职责范围内提供判断，它不能因为自己给出允许，就覆盖其他来源的限制。这里再次回到贯穿全系列的不对称原则：

不同来源的ALLOW不应该互相替代；而不同来源的DENY或限制，应当能够有效收缩执行空间。

正是这种不对称，从结构上堵死了 policy shopping——因为无论攻击者挑到哪个宽松来源，那个来源的ALLOW都无法抵消其他来源的DENY。

十七、对高风险执行，策略应该向交集收敛

假设三个策略来源分别给出结果。SaaS Policy：单笔最高 100,000，目标 A/B/C 可用，有效期 30 分钟。本地 Policy：单笔最高 50,000，目标 A/B 可用，有效期 10 分钟。审批 Policy：允许向目标 A 支付 30,000，仅执行一次，有效期 5 分钟。

系统最终允许的范围不应该是三者的并集（最高 100,000、A/B/C 都可以、30 分钟内有效），因为这相当于把每个来源最宽松的部分拼接起来。更合理的结果应该是交集：金额最高 30,000、只允许目标 A、仅一次、5 分钟内有效。

这就是策略收敛。它不问"哪一个来源权威最大"，而问"所有必要来源共同允许的最小安全范围是什么"。攻击者无法再通过挑选某一个来源获得更宽权限，因为最终执行能力由多个来源的共同交集决定。

需要补充的是，"取交集"并不意味着系统必须把所有 Policy 机械地做布尔 AND。不同策略承担不同职责——有些是必需条件，有些是附加限制，有些信号只负责拒绝，有些低风险动作可以在明确的本地预授权下离线完成。真正重要的不是形式上的 AND，而是方向始终一致：不确定性增加时权限缩小，冲突出现时执行收缩，状态失效时旧许可失效，新增能力时需要更多独立确认，任何单点失陷都不能自动扩大执行范围。这个"取更严格者"的机制，正是第八到十篇要展开的核心。

十八、让攻击者面对最严格边界，把关注点放在"最小失控损失"

一个普通的多策略系统是"只要找到一个可以放行的来源，请求就能继续"；一个真正安全的多策略系统是"任何来源提出的必要限制，都会进入最终执行边界"。前者让攻击者做策略挑选，后者让攻击者必须同时满足所有不可绕过的约束。

于是，攻击者即使诱导了审批人，也无法突破本地额度；即使接管了 SaaS，也无法替换最终 Intent；即使利用旧本地状态，也会被最新撤销证明阻止；即使风险模型没有发现异常，也不能绕过目标和次数限制。这并不保证系统永远不会判断错误，但它改变了错误的后果——单个 Policy 错误不再足以直接导致灾难性执行，攻击者必须跨越多个真正独立的边界。

这把安全的核心问题从"如何让每个策略来源都永不犯错"改写成"当某一个来源犯错时，系统最多会失控到什么程度"（第三篇的 assume breach、blast radius）。如果一个审批错误最多允许向既有目标执行一次小额操作、在短时间窗口内完成、不能修改目标、不能自动重试、仍受本地额度约束，那么错误的后果就被限制了；如果一个 SaaS 账号被接管后仍然无法加入新目标、无法提高本地额度、无法绕过物理确认、无法伪造设备证据、无法独自执行，那么云端失陷不会自动演变成全部失控。

这就是策略体系真正需要追求的能力：不是让所有来源永远正确，而是让最宽松来源也无法独自造成最大损失。

十九、结语：安全取决于最容易说"可以"的那一层

攻击者从来不会尊重系统设计者想象中的流程顺序。他们不会因为系统有五层 Policy，就老老实实地突破五层。他们会观察哪一层状态最旧、哪一层权限最宽、哪一层输入最容易污染、哪一层最容易受业务压力影响、哪一层允许复用旧结果、哪一层在异常时默认继续、哪一层可以覆盖其他来源的拒绝，然后把请求包装成那一层最愿意接受的样子。

所以，一个系统拥有多少策略来源，并不是最重要的问题。真正重要的是：