《执行控制工程》作者手记 06｜把权力分成三份，为什么仍然可能只有一种权力

本文是《执行控制工程》（Execution Control Engineering）的作者手记。 它不是书籍正文的摘要或重写，而是围绕本章问题、工程背景与写作之后的进一步思考。

在设计安全系统的时候，我们似乎总是倾向于相信，参与者越多，权力就越不容易集中。一项敏感操作如果由一个人批准，我们可能觉得不够安全，于是增加第二个审批人；如果两个人仍然不够放心，就引入第三个参与者，或者要求多个部门共同确认。到了软件系统中，同样的思维会表现为更多签名、更多服务、更长的审批链，以及更多相互配合的安全组件。

这些做法并不一定有问题。增加参与者可能提高某些操作的门槛，多重审批可能减少部分人为疏忽，门限密码学也能够改变单个密钥份额泄露后的安全性质。问题在于，我们经常进一步假定，只要参与者数量增加，最终执行权力就已经发生了结构性分解。

写《执行控制工程》第六章的时候，我希望认真检查的正是这一步推论。

第五章已经提出，最终执行裁决权不必由某一个主体独自持有，多个彼此独立、各自必要的约束可以共同决定一次具体 Action 是否具备继续执行的资格。但这句话一旦进入工程实践，很容易被简化成一个数量问题：既然可以由多个约束共同形成权威，那么增加更多审批、更多签名、更多节点，是不是就意味着系统越来越接近真正的权威分解？

我认为这里存在一个非常重要的陷阱。因为我们真正需要分开的，可能根本不是参与者的人数，而是那些能够让现实执行最终发生的不同性质的权力。

一、为什么数量总是比结构更容易令人信服

工程组织天然偏好能够计数和验收的东西。三级审批已经配置完成，五个服务已经部署，两套独立凭据已经生成，三名负责人已经完成签字，这些事实都可以写进项目计划、架构说明和合规报告，也能够被管理者和审计人员直接检查。

相比之下，证明一项执行权力真正被结构性分解，就没有那么容易。我们不能仅仅展示一张组织架构图，或者列出多个服务名称，就断言这些主体之间已经形成不能互相替代、继承或覆盖的权威关系。因为名称和位置可以分别存在，而真正决定现实动作的控制路径仍然可能汇聚到同一个地方。

例如，一笔高风险付款需要三个人依次审批。三个人来自不同部门，每个人都需要独立登录并确认。这当然比一个人直接完成审批增加了流程要求，但如果三个人看到的是同一份可能被单一来源改变的材料，依赖同一套状态判断，而最终的执行能力仍然能够由某个共同控制根独立释放，那么人数增加这件事本身，就不足以证明最终执行权已经得到真正分解。

这种区别在密码学系统中同样值得注意。把一把密钥分成多个份额，可以改变获得完整密钥能力所需要满足的条件，却不必然创造出多种性质不同的 Authority。如果所有份额最终只是为了恢复同一种操作能力，那么份额数量与权威种类仍然不能直接画等号。

所以我逐渐觉得，安全工程最需要警惕的，并不是使用数量指标，而是让数量指标替代结构判断。当一个系统因为拥有更多参与者就被宣称为“已经分权”时，我们实际上可能还没有真正回答，它究竟把什么权力从什么权力中分离了出来。

增加参与者可以提高取得某项能力的门槛，但不能仅凭参与者数量，就证明决定现实执行的权威已经发生结构性分解。

二、真正需要分开的，是性质不同的 Authority

在讨论 Authority Decomposition 时，一个经常被忽略的问题是，我们究竟在分解什么。

如果原来由一个主体完成的判断，现在交给三个人重复完成，那么我们首先得到的是三个判断参与者。如果原来由一把密钥控制的操作，现在需要三个密钥份额共同恢复，那么改变的是取得这项能力的条件。这些安排可能带来安全收益，但它们并不能自动证明系统已经形成不同性质、不能互相替代的 Authority。

权威分解所关心的，是一次具体受保护动作所依赖的权力关系是否真正发生变化。不同 Authority 应当具有各自的约束意义，不能因为某个主体拥有其中一项能力，就自动继承另外一项能力，也不能让某一项权力在没有相应约束的情况下关闭、替代或者覆盖其他必要约束。

这意味着，权威分解不能只发生在组织结构图中，也不能只表现为服务数量的增加。它需要触及真实控制关系，尤其是那些从上游意图、判断和资格一路延伸到最终现实动作的关系。

假设一个系统把原来单一服务承担的操作拆成三个微服务，分别负责请求处理、策略判断和最终执行。从软件架构角度看，这已经形成了清楚的模块边界，也可能提高系统的可维护性。但如果三个服务仍然共享一个能够覆盖全部约束的控制身份，或者存在一条不需要经过其他必要判断就能够产生同等现实结果的路径，那么服务数量的增加仍然不能证明权威分解已经成立。

这里还必须保持一个界限：讨论不同性质的 Authority，并不意味着本章已经给出了 Authority 的完整分类，也不意味着凭证、运行时、策略来源和执行域必须按照某一种固定架构进行部署。这些都可能是观察权威关系的工程位置，但它们不是一张已经被证明充分的部署清单。

第六章真正要求我们改变的，是观察方式：不再满足于确认系统里存在多少参与者，而是继续检查不同权力之间究竟能否自动继承、替代或覆盖。

把同一种能力拆成多个份额，不等于把不同性质的权威真正分开；权威分解改变的应当是实际控制关系，而不只是参与方式。

三、判断分解是否成立，必须回到具体 Action 和威胁模型

如果不能通过人数、签名数量或者服务数量判断权威分解，那么我们究竟应该怎样继续检查？

第六章给出了一条非常重要、但必须严格限定使用方向的判据：在已经声明的威胁模型下，允许失陷的主体集合，是否仍然能够独立闭合从意图到现实改变的因果链。

这句话把问题从系统外观重新拉回了现实执行。

所谓闭合因果链，关注的是一个主体集合是否能够在缺少其他必要约束的情况下，仍然使某项受保护的 Action 最终进入现实。也就是说，我们不再简单地数有多少主体参与，而是要检查，在给定失陷假设下，哪些主体真正掌握了足以让这次动作发生的控制关系。

这条判据还有两个不能忽略的限定。

首先，它必须针对具体的受保护 Action。一个系统可能包含转账、配置变更、普通查询和设备操作，不同动作所依赖的权威关系并不必然相同。因此，我们不能因为某一个操作已经具有多方约束，就把“整个系统已经完成分权”当作通用结论。

其次，它必须在已声明的 Threat Model 下使用。不同失陷假设会改变我们需要检查的主体集合和控制关系。没有明确这个前提，仅仅说某个系统“足够分散”或者“能够抵抗单点失陷”，往往缺少可以核对的判断范围。

但我认为这里最值得强调的，是这条判据仍然只能用于排除。

如果我们发现某个被允许失陷的主体集合仍然能够独立完成从意图到现实改变的整条链，那么相应的权威分解主张就面临明确问题。可是，如果没有发现这样的路径，也不能反过来宣布完整的 Authority Decomposition 已经获得证明，因为权威分解还涉及其他尚未完全形式化的结构条件。

这种不对称非常重要。它意味着我们可以通过检查发现某种分解主张为什么不成立，却不能因为某一轮检查没有发现问题，就直接把整个结构认证为已经充分独立。

权威分解不能由参与方数量证明，而需要检查在已声明的威胁模型下，允许失陷的主体集合是否仍能独立闭合具体 Action 的现实执行因果链。

四、多人审批、门限签名和职责分离为什么不能直接等于分权

把前面的判据带回日常工程实践，就能够重新理解许多我们已经非常熟悉的安全措施。

多人审批、简单多数表决、名义上的多重签名、门限授权和密钥分片，通常都会改变使用某项能力所需要的参与条件。它们可能使单个参与者更难独自完成某种操作，也可能减少凭据单点泄露造成的风险。但这些措施首先处理的是同一种能力如何被共同取得，而不是自动建立性质不同的 Authority。

组织职责分离则发生在另一层。它可以规定谁负责申请、谁负责审核、谁负责执行，以及不同团队之间应当如何协调。这样的安排对于治理、责任追踪和组织管理十分重要，却不能仅凭职责已经划分，就证明最终现实执行一定受到彼此不可替代的权威约束。

微服务拆分和纵深防御也是类似的情况。更多服务、更多安全层和更复杂的部署拓扑，可以改善模块隔离、故障处理或者其他安全属性，但不能直接回答这些层之间是否共享同一个能够同时影响它们的控制来源。

因此，这些措施并不应该被简单评价为“没有用”。真正需要反对的，是因为它们存在，就自动授予整个系统“权威已经分解”的结论。

例如，门限密码学可以非常有效地限制单个密钥份额直接恢复完整签名能力，但如果最终恢复出来的仍然是同一种执行权力，那么它解决的问题与 Authority Decomposition 所要求的不同性质权威之间的结构分离，仍然需要分别分析。二者可以结合，却不能被视为天然等价。

我觉得这也是《执行控制工程》必须与传统权限控制、密码学保护和组织治理保持清楚边界的原因。它不是要取代这些机制，而是要求我们准确说明每种机制究竟证明了什么，避免把某一个方面的安全改进扩大成对整个执行权威结构的保证。

多人审批、门限签名和职责分离都可能增强安全性，但“需要更多人才能使用同一种能力”，与“不同 Authority 不能互相替代或覆盖”，仍然是两种不同的结构。

五、现实事故中，多方参与也不必然形成完整的执行约束

第六章使用 Macondo 井事故作为现实压力测试，我认为这个案例最值得关注的，并不是参与者数量有多少，而是它提醒我们，组织层面已经存在职责分工，并不意味着某个具体判断所需的权威关系已经自然建立。

2010 年的 Macondo 井事故涉及作业者、平台所有与运营方，以及固井承包商等多个组织角色。在这样的作业体系里，参与者并不只有一个，合同和职责分工也已经存在。如果只根据组织数量判断，我们很容易认为这里天然拥有多方参与和相互制约。

但在本书采用的已核验材料中，关于负压测试存在两个特别值得保留的事实：当时没有指导该测试实施与解释的法规或行业标准，而平台运营方主张，其人员不负责解释测试，也不负责作出“井已安全、作业可以继续”的判断。

这两项事实所能支持的结论是有限的，却具有明确的工程启发。

多方参与可以真实存在，职责也可以已经在组织层面被分配，但这并不自动说明，针对某项具体判断，实际执行链上的 Authority 已经获得充分且清楚的结构性分离。

这里必须避免另一个方向的过度解释。我们不能仅凭上述事实，就认定事故必然由某个单一的权威缺口造成，也不能直接指定最终否决权应当由哪个组织或者岗位持有。Macondo 的完整事故原因更加复杂，这一章并不试图用一个权威分解问题重新解释整起事故。

它在这里承担的是压力测试作用，而不是理论证明。

我认为这种克制同样值得保留在作者手记中。现实案例的价值，并不总是证明理论已经正确，有时候它只是帮助我们识别一个被习惯性忽略的问题：即使组织中存在多个参与方，某项实际决定仍然可能没有获得我们想象中的那种独立约束。

所以真正需要检查的，不是名单上出现了多少公司或者负责人，而是具体动作所依赖的判断和约束，到底通过什么结构发挥作用。

组织里有多个参与方，只能说明责任和工作可能被分配给不同主体；它不能单独证明，决定现实执行的 Authority 已经形成不能互相替代的结构。

六、权威分解不是越多越好，也不能变成一项简单评分

讨论分权很容易产生一种新的误区：既然数量增加不能直接证明分解，那么是不是应该继续把权力拆得更加彻底，使参与者之间的关系越来越复杂，直到任何一个主体都无法独立完成任何事情？

这种想法仍然在把一个结构问题转换成程度问题。

权威分解当然可能降低某些单一主体独立完成受保护动作的能力，但它并不意味着分解越多就一定越安全。更多组件意味着更多需要维护的关系，更多控制可能带来新的状态依赖和协作成本，而一个在已声明威胁模型下可以接受的集中结构，也不能仅仅因为“集中”就被判定为不安全。

第六章进一步提出 Execution Threshold 作为一种受限的观察角度：针对某次具体受保护动作，攻击者最少需要控制哪些 Authority，才能完成这次执行？

我觉得这个问题很有价值，因为它重新把注意力从系统整体的“分权程度”拉回某次具体 Action。不同动作可能具有不同约束，某一个操作需要跨越的 Authority，也不能自动成为另一个操作的安全结论。

不过，Execution Threshold 在本章并不是一套已经完成的工程度量，更不是一个可以直接计算安全等级的公式。它帮助我们提出结构性问题，却没有因此给出统一评分方法。

同样，Blast Radius 所关心的现实后果范围，也不能与权威分解程度直接混为一谈。某次动作需要控制哪些 Authority，和它一旦错误发生会造成多大影响，属于不同层面的判断。

即使我们通过 Execution Budget 限制单笔金额、操作次数或者执行频率，也不能认为风险已经完全消失，因为这种限制又会进一步依赖预算所使用的状态来源是否可信。系统可能降低了一类风险，同时把一部分风险重新转移到了另外一个条件之上。

因此，我更愿意把权威分解理解为一种受明确条件约束的工程分析，而不是一项追求最大化的指标。它首先要求我们说明保护什么动作、采用什么失陷假设，以及不同 Authority 怎样参与最终现实执行。

权威分解不是参与者越多越好，也不是结构越复杂越安全；它是否有意义，始终取决于具体 Action、已声明的威胁模型以及真实的权力关系。

七、人数的问题结束以后，真正的独立性问题才开始

写完第六章以后，我觉得“多加几个人不等于分权”这句话并不只是反对某一种常见做法，而是试图纠正我们评价执行控制结构时的一种习惯。

我们太容易把能够被观察和清点的东西，当成真正需要证明的东西。审批人数可以统计，签名数量可以统计，服务实例可以统计，安全层数也可以统计。但 Authority 之间是否形成了不能自动继承、替代和覆盖的约束关系，却不会仅仅因为这些数字增加，就自然得到证明。

权威分解真正需要面对的，是一次具体动作如何从意图一路抵达现实，以及在已声明的威胁模型下，允许失陷的主体集合是否仍然能够独立闭合这条因果链。

这个判断让我们能够排除一些只有形式分散、没有实质结构变化的安排，却仍然没有给出完整的权威分解定义。我们还不能仅凭几个控制看起来分开，就宣布它们已经具备真正的独立性。

而这一点也带来了下一章必须回答的问题。

如果多个 Authority 被部署在不同服务里，由不同团队负责，使用不同的密钥，甚至运行在不同的物理设备上，它们是否已经足够独立？如果这些控制最终依赖同一套身份管理、更新机制、恢复通道或者其他共同控制来源，那么所谓的独立是否仍然成立？

更进一步，即使某一项执行约束真实存在，如果受到约束的主体可以自行修改、关闭或者放宽这项约束，那么我们究竟是在面对一条独立执行边界，还是只是在使用一项可以被自身控制者改变的默认配置？

这些问题已经超出了简单的数量判断，但它们恰恰说明，第六章没有结束权威分解的讨论，而是把它推进到了更加严格的位置。

真正的权威分解不是把同一种权力交给更多主体，而是让决定现实执行的不同必要约束，不能因为某一个主体的能力就被自动继承、替代或覆盖。

到了这里，我们终于可以暂时放下“还需要增加多少人”这个问题，转而面对一个更难、也更基础的工程判断：

那些已经被分开放置的 Authority，究竟在什么条件下，才算真正独立？

关于《执行控制工程》

《执行控制工程》（Execution Control Engineering）是Execution Engineering Trilogy第二卷。

本书讨论一个具体的工程问题：

在一次动作真正改变现实之前，它必须满足什么条件，才有资格被执行？

在线阅读

• 繁體中文版 https://havenlon.com/zh-tw/research/books/execution-control-engineering/

• English Edition https://havenlon.com/research/books/execution-control-engineering/

• Amazon Kindle Amazon.com: Execution Control Engineering: Designing the Boundary Between Authorization and Execution (Execution Engineering Trilogy Book 2) eBook : Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: Kindle Store

• Amazon Paperback Execution Control Engineering: Designing the Boundary Between Authorization and Execution (Execution Engineering Trilogy): Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: 9798177920689: Amazon.com: Books

© 2026 Lin Wang / Havenlon.

本文为作者手记，与《执行控制工程》正式书籍正文相互独立。 未经授权，请勿全文转载或用于商业再出版。 引用请注明作者及出处。