云端可以协同治理，但不应该拥有最终执行事实。
先讲一件让整个云安全行业后背发凉的事。
2023 年，一个代号Storm-0558的攻击组织，拿到了微软的一把消费级账户签名密钥（MSA key）。就凭这一把密钥，加上微软代码里的一个校验漏洞，他们可以伪造出微软云的身份令牌——而且本该只对消费者账户有效的密钥，因为漏洞，连企业邮箱的令牌也能伪造。结果，他们凭空"变"出了合法凭证，读取了约 25 个组织的邮件，其中包括美国国务院、商务部（连商务部长本人的邮箱）以及国会工作人员。
请注意这里的要害：攻击者没有去逐个攻破这些政府机构。他们攻破的是那个"最终说了算的裁判"——微软云颁发身份的权威本身。当云端是"谁被允许"的最终事实来源时，偷到云端的那枚印章，就等于伪造了所有人的许可。更讽刺的是，事后连微软和美国网络安全审查委员会（CSRB）都无法确定这把密钥究竟是怎么被偷走的。
这件事，正是本篇要讲的核心。
今天绝大多数企业系统最终都会走向云端：成员管理在云端，策略配置在云端，审批在云端，设备状态在云端，日志报表也在云端。对组织来说这太自然了——信息集中后更易协作、统一管理、跨地域运行。所以 SaaS 当然重要。它让复杂治理变得可见，把分散的人和设备组织起来，让企业知道谁提了请求、谁参与了审批、哪些策略在生效。
但有一个容易被忽略的问题：
负责协同治理的系统，是否也应该拥有最终执行权？
很多架构默认答案是"应该"——既然云端已经掌握身份、权限、审批、策略和状态，它似乎最适合判断一个动作能不能发生。可一旦 SaaS 成了最后裁判，整个系统就回到了那个熟悉的单点假设：只要云端判断允许，本地就必须执行。而这意味着，所有真正重要的拒绝能力，最终仍然服从于一个可以被远程访问、远程配置、远程攻破的软件控制面。
一、SaaS 擅长组织共识，不等于它天然掌握执行事实
云端治理最大的优势是能看见全局：组织有哪些成员、成员什么关系、谁有审批资格、策略如何配置、过去有哪些操作、哪些设备在线、哪些请求在等待。
这些信息让 SaaS 非常适合做一系列重要工作：组织成员与角色、分发策略、协调多人审批、同步治理状态、聚合日志与证据、提供报表告警审计视图。从这个角度看，SaaS 更像一个协调中心，把不同主体的判断汇总成一套可执行的治理结果。
但"组织形成了什么判断"和"最后究竟发生了什么"，不是同一个问题：
云端知道某请求已获批准，却未必能直接确认本地真正执行的对象是否变化；
它知道策略要求金额不超过某阈值，却未必掌握执行时的完整上下文；
它知道某设备上次心跳正常，却不能仅凭这一点证明设备当前内部状态没异常；
它记录到系统"声称"完成了某操作，却不能因为收到一个成功状态，就认定真实执行已按预期发生。
所以，SaaS 可以组织治理共识，却不该仅凭自己汇总出的结果，就成为最终执行事实的唯一来源。共识是"大家想怎样"，执行事实是"现实里真的发生了什么"——这中间隔着一整条可能被污染的链路。
二、云端看到的是治理状态，本地面对的是执行现实
SaaS 和本地执行边界，看到的是两个不同的世界。
云端看到的，通常是抽象后的治理信息：谁发起了请求、谁参与了审批、哪些策略被匹配、请求属于什么类型、设备报告了什么状态、业务系统提交了哪些参数。
本地执行边界面对的，是更接近最终动作的事实：真正的目标对象是谁、最终金额和参数是什么、当前设备状态是否允许、本地密钥和执行槽位是否可用、执行上下文是否与审批时一致、通信是否完整、是否存在策略冲突或状态异常。
两类信息都有价值，但用途不同。云端更擅长回答"组织是否同意这件事？"，本地边界更适合回答"这个动作在当前真实状态下能不能发生？"
如果把这两个问题全交给 SaaS，系统就默认了一件很难成立的事：云端对本地事实拥有完整、实时且不可被欺骗的理解。但现实里，网络会中断，状态会延迟，设备会变化，参数可能在链路中被替换，业务系统和云端也可能对同一动作形成不同解释。
越靠近真实执行，事实才越完整。所以最终裁决，必须尽量靠近最终执行点。
这正是零信任架构（NIST SP 800-207）里PDP / PEP分工的深层含义：策略决策点（PDP）可以在云端"思考应不应该"，但策略执行点（PEP）必须在最靠近资源的地方"守住能不能"。SaaS 是天生的 PDP，它不该越俎代庖去做那个最靠后的 PEP。
三、如果 SaaS 可以强制放行，本地边界就只是远程外设
很多系统虽然加了硬件设备或本地控制器，但最终权力仍留在云端：设备接收 SaaS 下发的"允许执行"，按云端策略工作，云端管理员能修改本地规则，SaaS 能进入紧急模式强制放行，设备拒绝后云端还能发更高权限命令覆盖结果。
这种架构表面上有本地硬件，实际上没有形成独立执行边界——本地设备只是云端软件的外设。它负责保存密钥、完成计算或执行动作，但不拥有真正的裁决权。所有决定仍由 SaaS 作出，硬件只是把云端结论落实到现实。
和把执行直接放云端相比，它可能在密钥保护和设备隔离上有改进，但权力结构没有根本变化。只要攻击者控制了 SaaS、或拿到足够高的云端权限，他仍然能让系统最终执行。
所以判断一个本地边界真不真，不能只看"有没有设备"，而要看两条（延续第八、十篇）：
它能不能对 SaaS 说"不"？这个"不"能不能被同一个 SaaS 远程撤销？
如果答案是否定的，那么最终裁判仍然是云端——硬件只是它的一层执行外壳。
四、SaaS 失陷的危险，不只是数据泄露，而是治理被重写
企业通常把 SaaS 风险理解成数据问题：账号被盗、客户信息泄露、配置被查看、日志被下载。这些当然重要。
但当 SaaS 进入执行链后，它还有一类更高影响的能力：它可以改变组织如何形成"允许执行"的结论。
攻击者一旦进入云端治理层，往往不需要直接攻击本地执行系统，他可以合法地重写规则：修改成员角色、增加新审批人、降低多人审批阈值、调整风险规则、把陌生地址加白名单、修改策略生效范围、改变设备绑定关系、伪造或重放治理状态、让异常请求看起来符合当前规则。
Storm-0558 就是这种性质的极端形态——攻击者没有"绕过"微软的认证，他伪造了认证本身。当本地边界无条件相信云端时，攻击者不必绕过安全流程，他只需要重写安全流程。
这类攻击最隐蔽的地方在于，系统表面上仍在按规则运行：审批通过了，策略匹配了，成员权限有效，请求格式正确，日志也可能完整——只是定义"什么算正确"的那套云端治理，已经被改掉了。
所以 SaaS 不能成为唯一裁判，不只是因为它可能宕机，而是因为它本身就是一个高价值攻击面。
五、云端管理员也不应该成为最终执行根
SaaS 往往需要管理员来管理组织、成员、策略、设备和恢复流程，这是正常运维需求。但如果云端管理员能直接决定最终执行，那整个系统依然押在"一个高权限身份永远可信"上。
管理员账号可能被盗，会话可能被劫持，终端可能中毒，内部人员可能作恶，AI 助手也可能误导管理员完成危险配置。即便管理员本人毫无问题，围绕他的整个软件环境仍可能失陷（这正是第九篇 Owner ≠ God 的延伸）。
所以云端管理员可以拥有治理权限，却不该通过一条远程指令直接获得最终执行权。他可以提策略变更、发起设备迁移、调整成员、推动恢复——但对高风险动作，最终边界仍应保留独立约束。否则，所有复杂治理最终只是为了把权力重新集中到一个超级管理员身上。
六、SaaS Policy 是输入，不是神谕
很多企业把策略引擎当成系统的大脑：金额低于阈值就放行、陌生对象需额外审批、异常时间拒绝执行、高风险设备进入限制模式。这些 Policy 很重要，它们把组织治理转化成了可执行规则。
但策略本身有局限：它可能过期，可能配错，可能遗漏本地状态，可能只覆盖云端看得见的信息，也可能在一次攻击中被篡改。
所以 SaaS Policy 更合理的角色，是最终裁决的一个输入，而不是不可质疑的命令。本地边界可以接收云端策略，也可以验证：策略是否有效？是否适用于当前状态？是否与本地约束冲突？
这里有一条特别重要的原则——当多个策略来源不一致、或云端允许而本地拒绝时，系统不能默认"云端权威更高"，也不能选那个最方便执行的结果。对于高风险执行，应该收敛到更严格的一方（fail-safe / converge-to-stricter）：
def final_decision(cloud_policy, local_policy, action): # 高风险动作：任一独立域说"拒绝"，就拒绝——取更严格者，而非更方便者 if is_high_risk(action): if cloud_policy.deny or local_policy.deny: return DENY return ALLOW if (cloud_policy.allow and local_policy.allow) else DENY # 低风险动作可以更偏可用性 ...
因为策略的价值，不是让动作一定发生，而是限制动作在什么条件下才可以发生。
七、SaaS 适合做 Bletchley，不应该替代 Enigma
在 Havenlon 的架构里，可以用两个名字来理解这种分工——它们本身就取自二战密码史：布莱切利园（Bletchley Park）是集结了无数聪明头脑、组织协同破译的地方，而 Enigma 是那台真正决定"密文能不能成立"的机器。
Bletchley，对应治理与协同。它组织成员、策略、审批、同步、证据汇总和跨设备协调。它看见的是"组织如何形成判断"，负责把不同来源的信息，整理成执行边界可用的治理结果。
Enigma，对应最终执行。它面对的是实际动作、最终参数、本地状态，以及"这个动作到底能不能穿过边界"。
二者的关系不该是：Bletchley 下命令，Enigma 无条件照做。更合理的是：
Bletchley 提供治理输入，Enigma 完成最终裁决。
┌──────── Bletchley（云端 / 治理平面 / PDP）────────┐ │ 成员 · 角色 · 策略 · 多人审批 · 状态同步 · 证据聚合 │ │ 产出：这个请求经过了哪些治理、组织是否同意 │ └───────────────────────┬───────────────────────────┘ │ 治理输入（不是命令） ▼ ┌──────── Enigma（本地 / 执行边界 / PEP）───────────┐ │ 最终对象 · 参数 · 本地状态 · 意图一致性 · 冲突检测 │ │ 裁决：这个动作，现在到底能不能发生 │ └───────────────────────────────────────────────────┘
云端可以说："这个请求经过了哪些审批、当前策略是什么、哪些主体同意了、建议如何处理。"但本地边界仍要根据自身状态和执行事实判断："这个动作现在能不能发生。"这不是相互竞争，而是职责分离——Bletchley 把组织的复杂判断组织起来，Enigma 确保这些判断不能未经独立边界就直接进入现实。
八、没有云端时，系统应该收缩，而不是自动失去边界
如果 SaaS 不是最终裁判，那云端失联时怎么办？这是个现实问题——设备会离线，网络会中断，SaaS 会维护，企业也希望云端不可用时能继续做部分操作。
最危险的设计，是云端一断，本地就自动进入宽松模式。因为这等于给攻击者递了一张纸条：只要切断云端，就能降低安全要求（回想第八篇：任何 Fail-Open 都是一份"制造故障即可绕过"的攻击说明书）。
更合理的做法，是根据预先定义的本地状态收缩能力：低风险、可验证、已预授权的动作可以继续；高风险、依赖最新治理状态或多人协同的动作暂时拒绝；系统保留诊断、恢复和必要维护能力；等云端重连后再同步状态与证据。
这会牺牲一部分可用性，但守住了一条原则：
云端不可用，不等于边界必须消失。
本地权威的意义之一，正是在 SaaS 不可用或不可信时，仍然拥有有限但真实的判断能力。
九、云端记录不等于执行证据
SaaS 很适合保存日志，集中展示谁在何时发起请求、审批如何完成、策略如何匹配、设备报告了什么结果。但云端日志不能单独定义执行事实。
因为日志通常来自各系统的上报：业务系统说"请求已提交"，审批系统说"流程已通过"，设备说"执行成功"，SaaS 把这些状态汇总成一条看起来完整的记录。但关键问题仍然没被回答：设备执行的是否就是审批的那个动作？参数有没有在链路中变化？本地拒绝是否被错误解释成了别的状态？关键证据是否由执行边界独立生成？
如果所有证据都由云端统一解释，那么 SaaS 既是治理者、又是记录者、还是历史的最终解释者——这会让系统缺少真正独立的执行证明（第九篇讲过：掌握执行权的人不该同时掌握历史解释权）。
更可靠的做法，是让最终执行边界产生自己的、可验证的证据（例如由 Enigma 本地签名、并以哈希链/append-only 形式记录），再同步到 SaaS。云端负责聚合与展示，但不能随意改写本地已经形成的执行事实。
SaaS 可以保存证据，但证据不能只由 SaaS 自己证明。
十、云端和本地之间，不应该是单向服从关系
传统云端控制架构往往是中心化的：云端下发 → 设备执行 → 云端查询 → 设备汇报。这适合普通设备管理，但不适合承担最终执行裁决的系统。
在执行安全架构里，云端和本地更像两个不同权威的协作：云端掌握组织治理信息，本地掌握执行状态和物理边界。两者需要交换信息，也需要相互约束——云端不能无条件覆盖本地，本地也不能完全忽略组织治理。
只有当云端策略、成员意愿、本地状态和最终参数共同满足条件时，动作才进入执行。这不是为了制造冲突，而是为了防止任何单一层成为绝对权威。这在分布式信任里叫分离信任（split trust）/ 多方共识：
真正可靠的治理，不是让所有组件听命于一个中心，而是让不同权力在关键动作前形成收敛。
十一、SaaS 的价值，不在于拥有最终权力，而在于组织复杂治理
有些产品认为，只有掌握最终执行权，SaaS 才真正有价值。其实不然。
SaaS 最擅长的，从来不是"成为最后那块芯片"，而是组织那些本地设备不适合完成的复杂工作：管理大规模成员、处理跨地域审批、配置策略模板、提供风险视图、同步设备状态、聚合执行证据、支持组织协作、管理生命周期和恢复流程。这些能力，让它成为治理平面，而不是执行事实本身。
把最终执行权从 SaaS 拆出来，不是削弱云端，而是让云端不必承担它无法可靠承担的绝对责任。一个 SaaS 如果既要负责治理、又要保证每一次真实执行绝对正确，那它就必须成为一个永不失陷的超级系统——这显然不现实（Okta、微软这样的巨头都会被攻破）。
更成熟的架构，是让 SaaS 在自己擅长的地方发挥作用，同时坦然承认它也可能故障、被攻破或判断不完整，并为这种可能提前设计好边界。
十二、为什么 SaaS 不能成为最后裁判
因为云端看到的是"组织如何形成判断"，却不一定拥有"最后执行时的全部事实"。
因为 SaaS 可能被攻破，策略可能被重写，管理员身份也可能失陷。
因为云端审批通过，只能证明治理流程形成了某种结果，不能自动证明本地动作仍与最初意图一致。
因为如果 SaaS 可以远程撤销所有本地拒绝，那么所谓独立硬件边界，就只是一层执行外壳。
所以，SaaS 应该负责协同治理，而不是垄断最终执行事实。它可以提出、可以协调、可以审批、可以同步、可以记录、可以给出策略结果——但最后那个不可逆的动作，仍然应该经过一个靠近执行点、拥有独立状态、具备真实拒绝能力的边界。
Havenlon 里 Bletchley 的价值，不是成为一个无所不能的云端大脑，而是把组织治理变成可靠的输入；Enigma 的价值，则是让这些输入在进入现实之前，仍要面对最后一次独立裁决。
云端可以告诉系统："组织认为这件事可以继续。"
但它不应该单独定义："所以，这件事已经可以发生。"
因为真正成熟的系统，不能把最终事实，交给任何一个可以被远程说服的中心。Storm-0558 偷走的那把密钥提醒我们：当云端是唯一的裁判，攻破云端，就等于攻破了每一个相信它的人。
这是《Havenlon｜安全讲人话》系列的第十一篇。下一篇我们看清这道边界的另一半——硬件（Enigma）到底扮演什么角色：不是为了"更神秘、更高级"，而只是为了让最后一步"更难被软件随意改写"。
参考来源（本文引用的真实事件与技术概念）
Analysis of Storm-0558 techniques for unauthorized email access — Microsoft Security
Chinese hackers forged authentication tokens to breach government emails — Help Net Security
Compromised Microsoft Key: More Impactful Than We Thought — Wiz
Zero Trust Architecture — NIST SP 800-207
