当证据真正进入执行路径之后一个长期被归类为异常处理的问题会立刻升级为安全问题某个必要条件无法确认时动作应该继续还是停止在普通业务系统里这属于可用性范畴。依赖服务超时、风控接口暂时不可达、状态同步延迟工程上可以按业务重要性选择降级、缓存、重试或继续。这些选择通常由 SRE 与业务方共同决定安全团队未必参与。而当被影响的是支付、交易、生产变更、基础设施控制或物理设备操作时无法确认条件成立的含义发生了变化——它意味着系统已经失去了允许动作发生的证明。上一篇建立了执行证据的状态空间除了真与假还有 Missing、Expired、Conflict 与 Unknown。本篇要处理的是这些状态应当被解释成什么以及这种解释在工程实现中是如何丢失的。需要先说清楚立场Fail-Open 与 Fail-Secure 都不是普遍正确的答案。真正要回答的是——什么样的失败可以被安全地容忍什么样的失败一旦被默认放行就会直接改变系统的执行安全语义。一、Fail-Open 把不确定性当作可用性问题Fail-Secure 把它当作执行资格缺失Fail-Open 的逻辑并不难理解。安全服务暂时不可用时如果系统立即拒绝全部请求可能造成大面积业务中断因此选择带着降级保护继续运行。一个内容服务在实时风险评分不可得时仍允许读取非敏感资源这是完全合理的工程决策——它在可用性与安全保证之间做了一次有意识的权衡。高风险执行路径的逻辑不同。如果一次受保护动作要求批准有效、状态新鲜、对象已绑定、边界未越那么其中任一条件无法确认时系统不能推导出大概没问题。因为它要证明的命题不是没有发现它不安全而是已经证明它满足全部必要条件。这两个命题的差距恰好就是不确定性所占据的那块区域。于是两种策略的分野可以表述为Fail-Open 在无法完成安全检查时优先维持业务运行Fail-Secure 在无法证明必要执行条件时不允许受保护动作继续。Fail-Open 把不确定性当作可用性问题Fail-Secure 把不确定性当作执行资格的缺失。二、Unknown、Missing、Expired 成因不同但都不能生成 ALLOW这三种状态的语义各不相同值得分开对待。Unknown意味着系统无法判断。它既不是 False——系统并未确认条件不成立——也不是 True。把它默认解释为 True 会带来一个具体的攻击面转移攻击者不再需要伪造一个安全状态只需要让状态验证系统不可达。攻击路径从伪造证据变成让证据源下线而后者的成本通常低一到两个数量级。Missing意味着必要证明不存在。它与明确拒绝不同这个区别在运维层面很重要——系统应当报告批准缺失而不是批准被拒绝因为两者需要的响应完全不同前者要去找批准人或修复证据链路后者要去理解为什么被拒。但在 ALLOW 语义上二者结论一致必要条件未被建立。Missing 不代表有人说了不但它代表还没有足够的事实说出一个可被证明的是。Expired意味着这份证据曾经真实但已失去代表当前现实的资格。它不是假的只是过时了。签名依然可以验证通过——这正是危险之处因为最容易实现的校验签名是否有效恰好不是需要的那个校验是否仍然相关。继续使用过期证据等于允许过去的状态授权现在的执行。把这些放在一起执行决策面对的是一个六值状态空间状态含义能否满足必要执行条件Valid条件已被有效证明是False已证明条件不成立否Unknown无法判断否Missing必要证明不存在否Expired证明曾有效但已失去时效否Conflict存在互不一致的证明否真正的工程难点不在于承认这张表而在于这些状态在实现中极易被悄悄折叠掉。上游返回ERR_TIMEOUT中间层捕获异常后使用默认值再往下传递时它已经变成condition true执行器看到的是一个干净的布尔值完全不知道它是被推导出来的还是被默认出来的。安全语义就是在这一次次异常翻译中丢失的而且每一步单独看都符合健壮性这个正当目标。因此这些状态必须是一等决策语义而不是错误码。还有一条与之配套的要求状态的解释权必须集中。如果每一层各自决定超时算什么、缺失算什么那么执行器最终看到的是各层默认值合成的结果没有任何一个组件对整体语义负责也没有任何人能说清系统在部分故障下的真实行为。协议层面应当直接规定只有 Valid 能满足必要条件其余状态一律向上如实传递。系统必须能够区分已经证明条件不成立和没能证明条件成立但在 ALLOW 面前两者的结论相同。三、Conflict 的处理规则本身就是一个 Authority冲突是这几种状态里最容易被低估的一种。设想两个独立数据源分别声明对象处于活跃与暂停状态两份证据都有合法签名、都来自已认证主体、都在有效窗口内。问题不再是有没有证据而是系统同时持有多个不能同时为真的版本。很多实现会选择一条简单规则取最新的那份或者相信主数据源或者相信控制面。这些规则本身都可能合理但它们有一个必须被看见的性质——决定采信哪一份就是在决定执行是否发生。如果这条规则没有被写进 Authority Map那么系统里就存在一个未被建模的权力而第一篇给出的 Authority Completeness 要求恰恰是所有能够影响受保护动作的权力都必须显式建模。冲突解析规则符合这个定义它却常常只是某个函数里的一行判断。一旦它未被建模攻击面就随之出现攻击者不需要伪造证据也不需要让证据源下线只需要制造一次冲突让系统按照它已知的解析规则选中对自己有利的那个版本。这比伪造签名容易得多。这里需要做一个限定否则容易走向过度反应。冲突不总是攻击的产物它经常只是分布式系统的正常现象——网络分区、复制延迟、多主写入、时钟偏移都会产生短暂的不一致而这种不一致通常会自行收敛。因此合理的规则应当区分两类可容忍的暂时不一致例如两份证据描述的是同一趋势的不同时间点可以通过等待收敛或取更严格的那一份来处理不可解释的矛盾例如两份同时刻、同来源、语义互斥的声明它意味着系统对现实的描述已经不可信此时受保护执行必须停止。区分标准应当事先写下来而不是在故障中临时判断。缺少证据意味着系统不知道证据冲突意味着系统同时知道了几个不能同时成立的版本而选择相信哪一个本身就是一种执行权。四、Fail-Secure 的核心不是倾向拒绝而是 ALLOW 只能被正向推导Fail-Secure 常被简化为出错就拒绝这个表述太粗也容易招致合理的反对。它真正约束的不是拒绝的频率而是 ALLOW 的产生方式。高风险执行的允许语义应当是C₁ ∧ C₂ ∧ C₃ ∧ C₄ → ALLOW只有当全部条件被明确证明成立才能得到 ALLOW。它不能来自另一条推理没有已知失败 → ALLOW这两条逻辑在正常运行时输出完全相同的结果在部分故障时却分道扬镳。前者是资格证明后者是未检出失败而后者的可靠性完全取决于检测覆盖率。这个差别之所以在自动执行系统里格外重要是因为现实中的问题很少以明确的 False 出现。更常见的形态是数据还没到、状态源超时、批准服务异常、时钟不同步、证据无法解析、两个来源互相矛盾、某个组件暂时失联。如果所有这些都被没明确发现危险那就继续吸收掉执行安全会被大量异常路径持续侵蚀而且每一条侵蚀路径在代码评审中看起来都像是良好的容错设计。Fail-Secure 的核心不是默认拒绝而是 ALLOW 必须被完整证明不能由没有发现问题推导出来。五、Fail-Secure 必须绑定受保护执行它不是一条全局原则这里必须守住边界不是所有系统、所有请求、所有失败都应该 Fail-Secure。把任何不确定性都解释成拒绝系统会迅速变得不可用而不可用本身也是一种损失在某些场景下还是安全损失——一个在证据缺失时拒绝开门的消防通道控制系统可能造成远大于误开门的后果。判断依据不应该是这个系统重不重要而应该是一次具体比较短暂拒绝的成本与错误执行的期望损失。这个比较有一个容易被忽略的维度——两者的时间形状不同。拒绝执行的成本随时间线性累积并且在证据链路恢复的那一刻停止增长事后还可以补做错误执行的损失在瞬间就已经全额实现修复系统并不能把钱转回来也不能让被删除的集群回到删除前的状态。正是这个不对称使得在不可逆路径上即便拒绝的即时成本看起来更高偏向 Fail-Secure 仍然是正确的——因为两者的成本不在同一个尺度上比较。因此适合严格 Fail-Secure 的路径有相当清晰的特征现实后果明显、操作不可逆或恢复成本很高、涉及资金、生产系统、基础设施边界或物理设备、且错误执行的损失显著高于短暂拒绝的代价。同一套系统内部完全可以并存两种策略——读取路径 Fail-Open受保护执行路径 Fail-Secure甚至同一个接口的不同参数区间也可以适用不同策略小额走宽松路径大额走严格路径。Fail-Secure 不否定可用性它规定的是在受保护执行路径上不能用可用性偏好替代执行资格。六、最危险的失败方式是安全组件失效之后执行权反而变大有一个非常直接的方法可以检验一个系统的失败策略当安全组件发生故障时主体能够执行的动作范围是变小还是变大正常状态下 Agent 单笔最多执行一万。策略服务不可用时系统为了保证业务连续性切换到旁路模式Agent 可以直接调用底层支付接口。这个系统具备了一个极其危险的性质——安全机制越坏主体的执行权越大。攻击者因此不需要突破策略只需要让策略不可用而让一个服务不可用通常比让它做出错误判断容易得多。这类设计等于给攻击者提供了明确的攻击目标和最省力的路径。这条要求可以形式化为一个不变量并且它与本系列第二篇的度量方式正好对上在任何故障状态下主体的可达执行状态空间必须是正常状态下的子集。最小执行权讨论的是正常状态下这个空间应该多小安全退化要求的是故障状态下它不能反而变大。合理的退化方向是完整能力 → 受限能力 → 安全停止而不是完整控制 → 安全组件失效 → 无约束执行任何一条降级后放宽的路径都应当在架构评审中被单独标记出来并给出理由。一个安全系统最危险的失败方式不是它停止工作而是它失败之后把原本受限的执行权重新放大。七、拒绝执行不等于关停系统而这一点必须被主动测试反对 Fail-Secure 的一个常见理由是把它理解成安全组件一故障整个业务就停摆。这不是它的必然形态。真正需要停止的只是那部分无法继续证明资格的受保护执行。系统仍然可以接收任务、生成意图、排队等待、保存上下文、读取状态、执行低风险操作、请求人工介入、维持可观测性。一个设备控制系统可以在某处证据丢失时拒绝执行高风险机械动作同时继续提供遥测与健康检查。拒绝执行与关停系统的距离有多大取决于高风险能力与普通能力是否被拆开——这正好与最小执行权相接如果一个主体的全部能力被绑定在同一份凭据、同一条路径上那么任何一次证据缺失都只能整体拒绝如果高风险能力已经被单独隔离Fail-Secure 的可用性代价会显著下降。执行边界划得越清楚安全停止的范围就越小。而这些行为必须被主动测试因为它们几乎不会在正常运行中暴露。多数团队测试的是正常情况下是否正确放行以及策略明确拒绝时是否挡住——这两个场景都位于状态空间的两端。有价值的测试恰恰在中间主动制造批准服务超时、状态证据过期、时钟偏移、签名无法验证、两份状态互相冲突、计数器缺失、上下文只传了一半、决策与执行之间网络中断、某个 Authority 完全无响应。然后观察一件事——系统里是否仍然存在一条让受保护执行发生的路径。如果存在证据缺失 → 回退逻辑 → 执行那么 Fail-Secure 就有缺口无论文档里怎么写。这也是执行安全测试与普通业务测试的分界。业务测试覆盖 True 与 False执行安全测试必须覆盖 Incomplete、Uncertain 与 Inconsistent因为攻击者未必试图让安全系统给出错误答案他可能只是让系统得不出答案然后利用默认处理逻辑完成执行。Fail-Secure 真正要防的不是判断错了而是无法判断却仍然执行。结语为不完整的世界定义 ALLOW真实世界不会给安全系统提供完美输入。网络会延迟设备会掉线服务会崩溃状态会在两次读取之间变化上游会传来不完整的上下文多个系统之间会出现暂时不一致。执行安全面对的从来不是一个条件始终清晰的世界而是一个长期存在 Unknown、Missing、Expired 与 Conflict 的世界。Fail-Open 与 Fail-Secure 的真正分歧就在于如何解释这种不完整性。这也让上一篇的执行证据获得了完整的安全语义。证据如果只是系统希望拥有的数据那么它缺席时无非少一条记录只有当没有证据就没有 ALLOW这条规则被真正执行证据才成为 ALLOW 的构成要件而不是它的装饰。第三阶段到此完成执行从事后可以查清为什么出事推进到事前必须证明为什么可以发生并且明确了证明不完整时系统应当如何自处。接下来的问题来自这一阶段留下的一个副产品。为了判断谁能提供哪一份证据、谁能修改条件、谁的失效会导致哪些条件无法建立、以及冲突解析规则实际掌握在谁手里系统需要一张图。但这张图不是传统意义上描述谁属于哪个组、谁拥有哪个角色、谁能访问哪个资源的身份关系图——那张图回答不了谁能影响哪一段执行因果链。两张图的节点可能相同边的含义却完全不同。这就是下一篇Identity Graph vs Authority Graph。