纵深防御是安全工程中最经典也最有效的架构原则之一。它的思想很直接：不要把系统安全押在单一控制点上，而是在不同位置部署多层控制，即使某一层被绕过，攻击者仍然要继续突破后续控制才能接近敏感资源。身份认证、网络隔离、访问控制、应用层校验、WAF、EDR、运行时检测、审计，都可以是其中的一层。这个原则经受住了几十年的实践检验，本篇没有任何意图去削弱它。
需要单独提出来讨论的是另一个问题：当系统进入高风险现实执行之后，多层防御是否意味着最终执行权已经被拆开。
答案是不一定，而且判断依据与"层数"无关。一个系统可以拥有五层、十层安全机制，但如果这些机制最终都能被同一个管理域、同一个控制平面或同一组密钥重新定义，那么从执行权的角度看，它们可能共享同一个根。纵深防御统计的是攻击者要经过多少道控制；Authority Decomposition 追问的是这些控制背后究竟有多少个真正独立、不能相互替代的权力来源。这是两个不同的变量，而且它们之间没有必然关系。
一、层数统计的是控制位置，Authority 统计的是权力来源
一个典型的纵深防御结构是：
入口控制 → 身份验证 → Authorization → 应用校验 → 执行保护 → 审计
攻击者要完成一次高风险操作，需要连续绕过多个机制。这显著提高了攻击成本，也降低了单个漏洞直接演化成严重事故的概率。
但这些"层"描述的是安全控制所处的位置，而 Authority 描述的是谁掌握改变执行结果的哪一部分权力。设想一个系统同时部署了 IAM、策略引擎、批准服务、执行网关和执行器。从纵深防御视角看这是五层。如果同一个管理身份能够修改 IAM 角色、修改策略、替换批准服务信任的公钥、改写网关配置、部署新版执行器并读取最终凭据，那么这五层在权力结构上收敛到同一个节点：
graph LR
IAM[IAM] --> PE[Policy Engine] --> AP[Approval Service] --> GW[Execution Gateway] --> EX[Executor] --> REAL[受保护现实动作]
ADMIN[管理域] -.配置 / 密钥 / 部署.-> IAM
ADMIN -.-> PE
ADMIN -.-> AP
ADMIN -.-> GW
ADMIN -.-> EX
横向那条链是纵深防御看到的结构，虚线那组边是 Authority 分析看到的结构。攻击者要突破的未必是五道独立边界——取得那个管理根，五层可以同时失效。
部署拓扑同样不能证明独立性。五个微服务分属五个容器、五个命名空间甚至五个可用区，从软件工程角度确实是五个组件，但如果它们的配置来自同一个源、密钥由同一个域签发、镜像由同一条流水线产出，那么它们在因果权力上仍然是一个。反过来也成立：两个逻辑功能可以位于同一块物理板卡上，却因为使用不同的硬件密钥、不同的信任根、彼此不可覆盖的安全域而构成两个真正独立的 Authority——这样的两者，可能比两个部署在不同云上的普通服务更独立。
服务边界是软件架构概念，Authority 边界是安全因果概念；进程、主机与云账号的分离都不是独立性的充分条件。
二、纵深防御的有效性建立在"失效相互独立"这个未被言明的假设上
纵深防御为什么直觉上有效，可以用一个粗糙的模型说明：假设有 n 层控制，每层被单独绕过的概率是 p，那么全部被绕过的概率是 p 的 n 次方。层数增加，风险指数下降。这个推理在很多场景下是对的，也是纵深防御被广泛采纳的原因。
但这个乘法有一个前提——各层的失效必须相互独立。可靠性工程很早就命名了破坏这个前提的现象：共因失效（Common-Mode Failure），即多个看似独立的部件依赖同一个底层条件，一旦该条件失效，它们同时失效。此时总失效概率不再是 p 的 n 次方，而是趋近于那个共同因子自身的失效概率，与层数几乎无关。
在执行系统里，最常见的共同因子有几个：管理身份、配置来源、密钥管理域、部署流水线、身份提供方。假设一个系统有三道检查——策略检查、批准检查、执行检查——但三者运行在同一个环境中，配置读自同一个数据库，密钥由同一个密钥管理域签发，且同一个平台管理员可以修改它们的代码。表面上是三道检查，面对"管理身份失陷"这个事件时，它们是一道。攻击者可以同时修改策略、写入虚假批准、替换检查逻辑、取得凭据。
这不是说这种架构没有价值。它对钓鱼、单个服务的漏洞、越权访问、误配置这类局部问题依然提供三层保护，而这些问题在现实中的发生频率远高于管理域失陷。真正的问题在声明：如果一个系统声称能够抵抗管理域失陷，那么共享该管理域的层不能被计入独立边界。安全声明的强度不能超过它所依赖的最弱共同因子。
两个控制只有在其中一个失陷时另一个仍然保有独立否决能力，才构成执行意义上的两个 Authority。
三、纵深防御提高突破成本，Authority Decomposition 改变单点失陷的后果
两者对抗的其实是两类不同的单点失败。
纵深防御关心的是控制失效：某一道控制被绕过之后，后面还有没有下一道。攻击者拿到一份凭据不等于能进入生产环境，进入生产环境还要面对网络分段，穿过分段还要面对应用层授权与运行时防护。每一层都在追问同一件事——攻击者还需要继续突破多少。
Authority Decomposition 关心的是权力失效：某一个主体失陷之后，它自己能走完多长的因果链。如果一个 Agent 被完全控制，而它拥有的权力只是提出意图，那么它虽然已经失陷，仍然缺少独立批准、有效状态证据、最终凭据以及执行器要求的绑定证明。此时系统的安全性不来自"Agent 前面还有三道防火墙"——攻击者已经在防火墙内部了——而来自这个主体本身没有完整的执行权。
两者的差别在事故形态上很清楚。WAF 被绕过不意味着身份层同时失效，这正是纵深防御的价值所在。但如果一个平台管理员能够直接关闭 WAF、重写身份策略、替换执行器并导出凭据，那问题就不是"某一层被绕过"，而是多层同时失去意义。前者是控制冗余不足，后者是权力过度集中，它们需要不同的补救手段：前者加控制有用，后者加控制无用。
Defense in Depth 提高突破系统的成本；Authority Decomposition 降低单一失陷主体能够独立造成的现实后果。
四、Authority Decomposition 拆的不是软件，而是完成一次动作所必需的因果权力
做 Authority Decomposition 不应该从"要把系统拆成几个服务"开始，而应该从一个受保护动作倒推：要让这件事真正发生，系统中必须有哪些权力参与。上一篇已经列举过执行链上的几类 Authority，这里不重复。本篇要处理的是更容易出问题的那一半——这些权力之间发生了哪些未经分析的隐含合并。
合并往往不是设计决策，而是实现的副产品：两件事恰好写在同一个服务里，或者恰好由同一份配置驱动。但每一种合并都会让某一条本应成立的约束失去支撑：
| 被合并的两种权力 | 合并后果 | 失效的约束 |
|---|---|---|
| Intent Authority + Credential Authority | 提议者同时是执行者 | 提议与执行之间不再有独立环节 |
| Policy Authority + 不变量修改权 | 判断者同时是立法者 | 执行底线可被判断方自行关闭 |
| Approval Authority + Target 定义权 | 批准者可自行定义被批准对象 | 批准与对象之间的绑定形同虚设 |
| Execution Authority + Evidence 生成权 | 执行者自证条件已满足 | 证据不再是独立输入 |
| 被约束方 + Boundary 计数权 | 消耗量由被限额的一方自报 | 累计边界可以被无限重置 |
最后一行值得单独说明，因为它最隐蔽。上一篇提到执行边界常常表现为额度、频率、累计敞口这类可消耗的量，而这些量必须有人计数。如果计数器由被这个额度约束的主体自己维护——常见形态是 Agent 在本地缓存"今天已用多少"，或者编排层在请求里附带一个累计值——那么这条边界的实际上限不是配置里写的数字，而是这个主体愿意上报的数字。
发现这类合并的方法不是审查架构图，而是对每一条本应成立的约束反过来问：如果我是这条约束所限制的那个主体，我能不能自己让它成立。
Authority Decomposition 拆的不是软件模块，而是完成一次现实动作所必须凑齐的因果权力。
五、判断 Authority 是否独立，要看控制面、密钥材料与否决能力
独立性不能靠"不同团队负责"或"服务分开部署"来断定。至少要过三关。
第一，控制面是否独立。 如果两个 Authority 最终都能被同一个控制平面重新配置——修改代码、改写配置、替换镜像、注入环境变量——那么在允许该控制平面失陷的威胁模型下，它们不是两个 Authority。
第二，密钥材料是否独立。 如果多个环节最终依赖同一把根密钥，那么这把密钥就是真正的 Final Authority，环节数量不改变这一点。反过来，如果不同 Authority 持有各自的密钥材料，且任何一方都无法替另一方生成有效证明，结构独立性会实质性增强。
第三，是否具备独立否决能力。 上一篇已经说明否决权是 Final Authority 的关键能力；在本篇它进一步成为计数的判据。判断一个环节算不算一个 Authority，不要看它能不能参与批准，而要看：当上游所有主体都要求执行时，它能否因为自己的必要条件不满足而独立拒绝。做不到，它就只是流水线上的一个工位，不是一个安全意义上的权力主体。Who can say ALLOW 决定谁参与流程；Who can still say DENY 决定谁构成 Authority。
还有一点在计算时经常被忽略：独立性是有方向的。A 相对 B 独立，不蕴含 B 相对 A 独立。一个由硬件安全模块持有的签名权，相对云控制面可能是独立的——控制面无法伪造它的签名；但云控制面可能仍然能够阻止请求到达它，或者干脆不调用它。前一种独立性保证"不能伪造执行"，后一种缺失意味着"可以阻断执行"。在完整性目标下前者足够，在可用性目标下不够。因此独立性必须针对每一对 Authority 和每一种安全属性分别判断，不能笼统地说"这两个是独立的"。
真正独立的 Authority，不是能够参与批准的那一个，而是在其他所有主体都要求执行时仍然可以独立拒绝的那一个。
六、拆分是有成本的，目标不是权力最多，而是不存在不该存在的单点执行权
既然分解能降低单点风险，是不是 Authority 越多越好？显然不是。每引入一个独立 Authority，系统都要付出可观的代价：协议复杂度上升，端到端延迟增加，密钥管理与轮换负担加重，状态一致性更难保证，故障模式变多，可用性下降，运维与排障成本上升。而且新增的每一个 Authority 本身也是一个可能失效或被攻击的对象——分解到某个程度之后，边际收益会开始为负。
因此合理的工程目标不是"一切都要分开"，而是一个有约束的问题：根据受保护动作的风险与声明的威胁模型，拆出足够多、且确实必要的独立 Authority，使得允许失陷的主体集合无法独立完成这次执行。这与门限式安全的思路有相似之处——例如要求任一单点失陷都不足以成事，或者在四个 Authority 中容忍其中一个失陷——但它不要求像门限密码学那样的形式化结构，判据落在因果可达性上而非代数结构上。
这也意味着 Authority Decomposition 永远是相对于威胁模型的。如果一个系统明确信任云管理员，那么把 IAM、策略、批准与执行器放在同一个云账号里是完全合理的设计，因为管理员失陷不在模型内。但如果安全目标变成"即使管理域被攻陷，某类高风险动作仍不能被任意执行"，那么最终凭据、独立批准或某些执行不变量中至少要有一部分位于该管理域之外——否则"控制管理域 → 重新配置全部控制 → 执行"始终是一条完整且畅通的因果路径。
要让这个判断可讨论，必须先写清楚四件事：哪些 Authority 允许失陷，哪些组合允许同时失陷，哪些信任根必须保持完整，哪些现实动作被列为受保护执行。这四项定义清楚之前，"我们的架构是分层的"不构成任何安全声明。
七、攻击者走的是最短路径，安全性取决于有没有便宜的执行捷径
攻击者不会按照架构图规定的顺序逐层推进，他找的是最短路径。如果一个系统有十层控制，而管理员凭据可以直接取得最终执行密钥，那么真实的攻击路径就是三步：控制管理身份、取得凭据、执行。另外九层在这条路径上根本不存在——它们防护的是别的路径。
由此可以给出执行安全在架构评审中真正该做的分析：从每一个允许失陷的 Authority 出发，检查到受保护执行之间是否存在一条足够短的可达路径。如果存在 A → Execution 这样的直连，那么 A 就持有极强的单点执行权，无论它在图上被画在第几层。如果所有可行路径都必须形如 A + B + C + 不变量校验 → Execution，且 A、B、C 之间具备上一章意义上的真实独立性，那么攻击者必须凑齐多份因果权力才能成事。
这类可达性分析需要一种与分层图不同的表达方式——分层图擅长说明职责归属，不擅长暴露跨层的捷径，因为捷径恰恰是那些不沿着层次走的边。用什么结构来表达它、以及它与身份关系图的区别是什么，是本系列第四阶段的主题，这里只需要确认一点：评审对象应当是路径，不是层数。
有价值的安全分层，不是让攻击路径看起来更长，而是让任何单一 Authority 都不存在一条直达现实执行的捷径。
结语：控制冗余与权力分离
Authority Decomposition 不是纵深防御的替代品，两者解决的问题不重叠。身份失陷之后还有设备检查，网络边界被突破之后还有应用授权，应用存在漏洞时还有运行时防护，动作发生之后还有监控与告警——这些层次实实在在地提高了系统韧性，而且它们拦下的事件数量远多于权力集中类问题。纵深防御提供的是控制冗余，Authority Decomposition 提供的是因果权力分离，一个强调机制的层次性，一个强调权力的结构性。足够强的执行架构需要同时满足两个条件：攻击者必须经过多种不同性质的控制，并且任何允许失陷的单一 Authority 都无法让这些控制同时失效。
至此本系列第二阶段完成。上一篇建立的是 Policy Engine ≠ Final Authority，本篇建立的是 Security Layers ≠ Independent Authorities。两者合在一起，把安全评审的提问从"我们部署了多少安全机制"转向"这些机制背后有多少个真正独立、不可相互替代的执行权"。这是一个从数量到结构的转变，也是执行安全区别于传统架构评审的地方。
但把权力拆开之后，一个新的问题立刻出现。多个独立 Authority 意味着每一方都要向系统证明自己那部分条件成立——批准方要证明批准过，状态方要证明状态如此，执行方要证明边界未被越过。这些证明从哪里来，什么时候产生，被谁验证？如果它们只是各自写下的日志，那么它们记录的是已经发生的事，无法参与决定事情能否发生；而执行安全需要的恰恰是后者。日志与证据在形态上很像，在系统中的位置却完全不同。这就是下一篇：Audit Log vs Execution Evidence。
231
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
