拥有系统的人也不应该能单独造成灾难性执行。先讲一个特别反讽的真实案例。2020 到 2021 年网络设备巨头 Ubiquiti 遭遇了一场严重的数据泄露。事后美国司法部查明作案的不是外部黑客而是公司内部一位高级工程师 Nickolas Sharp——而他的岗位恰恰是负责云基础设施安全的人。他利用自己可信内部人的管理员权限从公司的 AWS 和 GitHub 里盗走了大量机密AWS Secrets Manager 里的密钥、1400 多份任务定义文件、1100 多个代码仓库。然后他伪装成匿名黑客向自己的公司勒索近 200 万美元在 FBI 上门后又摇身一变伪装成吹哨人给媒体投放假故事声称泄露是外部漏洞导致的。他甚至动过日志——因为他有权限。最后是一次网络中断意外暴露了他的家庭 IP才让整件事败露。这个案子把本篇的主题摆到了极致那个被系统赋予最高信任、负责守护安全的人本身就是最大的风险。很多系统默认Owner 拥有最终权力创建成员、修改规则、调整权限、关闭服务、迁移资产紧急时还能越过普通流程。这在早期很常见也好理解——系统总得有个最终负责人否则出事谁来处理但最终负责不该自然等于可以单独做任何事。创始人、老板、管理员、Owner 当然可以拥有治理权可如果一个人同时拥有提出动作、修改规则、批准流程、绕过限制和完成最终执行的全部能力那所谓治理最终会退化成一句话只要 Owner 想做系统就必须照做。这在管理上看着高效在安全上却意味着整个系统仍然押在一个单点假设上Owner 永远不会被攻击、不会被误导、不会误操作也不会在压力、冲突或恶意下做出灾难性决定。现实中没有任何角色配得上这种假设。一、所有权和无限执行权不是一回事拥有一家公司不代表一个人可以不经任何程序划走全部资金担任银行负责人不代表他能独自从金库搬走所有资产拥有一栋大楼也不代表他能在有人使用时随意关闭全部消防系统。现实世界早就把所有权、治理权、具体执行权分得清清楚楚公司属于股东但付款仍要走财务流程董事会能定战略但重大交易仍需审议授权老板能任命管理员但管理员的操作仍受审计和职责分离约束。这样设计不是因为不相信老板而是因为成熟制度从不把灾难性能力集中在任何一个人身上。数字系统却常常反着来。一个 Owner 账号可以修改成员、重置密钥、更改审批条件、关闭风控、创建新管理员、删除日志、触发资产操作甚至在紧急模式下直接绕过约束。单看每一项都是管理功能组合起来它们却形成了一种近乎无限的最终权力。这时Owner 已经不只是治理系统的人他成了系统里的神。二、Owner 可能可信但他的账号、设备和上下文未必可信安全设计最容易犯的错是把这个人值得信任直接等同于这个角色可以无限授权。即便 Owner 本人毫无恶意围绕他的整个执行环境也可能出问题账号可能被钓鱼会话可能被劫持设备可能中招浏览器插件可能篡改页面云端控制台可能被攻破AI 助手可能给出错误摘要员工可能利用 Owner 的信任诱导他批准异常操作而人在疲劳、焦虑、紧急压力下也可能忽略平时绝不会忽略的细节。所以 Owner 风险从来不只是这个人会不会作恶更现实的问题是系统能不能确定——每一次以 Owner 名义发出的动作真的代表 Owner 当时完整、准确的意图如果这一点无法被证明那么仅凭角色够高级就放弃执行边界是极其危险的。在安全里这叫过度授信的特权账户over-privileged privileged account问题——而针对它的整套方法论PAM特权访问管理核心思想恰恰是权限越高越要被约束、被监控、被最小化而不是越自由。一个成熟的系统应该保护 Owner而不是要求 Owner 永远完美。三、真正危险的不是 Owner 能做很多事而是他能在同一条链上做完所有事Owner 拥有广泛治理能力本身不一定有问题。问题在于这些能力之间有没有独立边界。一个 Owner 可以提出策略变更治理权可以任命新成员组织管理权可以发起高风险执行业务权——这些分开看都正常。但如果他还能单独批准自己的请求、修改本地约束、关闭执行检查、并立即完成最终动作那么所有权力其实都挤在同一个控制面里。这就像一个人既能写规则又能解释规则还能宣布自己不受规则约束最后亲自执行。这种系统看起来模块很多实际上没有真正的权力分离。所以 Owner ≠ God 的核心不是削弱 Owner而是把几种本质不同的权力拆开发起权 ─┐ 治理权 ─┤ 策略修改权 ─┼─ 可以同属一个组织 恢复权 ─┤ 但不该在任何时刻 最终执行权 ─┘ 被一个远程角色无条件合并这正是经典安全原则职责分离Separation of Duties的延伸——只不过这一次它要约束的不是普通员工而是那个最容易被豁免的人Owner 自己。这些权力可以由同一个组织控制却不应该在任何一次操作里被一个人一次性攥全。四、Owner 单点失陷的灾难半径通常最大普通成员账号被攻破影响可能局限在某个项目、某批数据、某种操作管理员账号被攻破范围更大但仍受组织和业务边界限制。Owner 一旦失陷攻击者往往不只是获得现有权限而是能改变权限本身创建新成员、提升权限、取消多人治理、修改策略、关闭告警、更换绑定设备、启用恢复机制、删除证据。这意味着 Owner 风险有一种特殊性质它不仅能使用系统还能重新定义系统允许什么。Edward Snowden 事件就是这种性质的极端体现——一个系统管理员/承包商角色凭借过度宽泛的访问权就足以带走一整个情报机构的核心机密。攻击面不在于他多聪明而在于那个角色被授予的权力半径实在太大。前一篇讲的 SolarWinds 是攻破远程通道这一篇讲的是攻破最高身份——殊途同归。如果最终执行边界也服从 Owner 的远程命令那么攻击者一旦控制 Owner就不必再逐层突破其他防线——他可以直接把这些防线改成允许状态。所以 Owner 的权力越大越需要有一部分能力不由 Owner 单独决定。这不是不尊重所有权恰恰是为了防止一次身份失陷把整个系统的灾难半径扩张到最大。五、治理权应该允许改变规则但不能让规则在一次执行中瞬间消失Owner 当然需要修改系统——企业会发展成员会变业务会调整风险模型会更新。一个完全不能被治理和升级的系统不可能长期运行。但修改规则和绕过规则必须区分。修改规则应该是一个明确的过程可能需要等待期可能需要多人同意可能需要本地确认可能需要更换设备或重建信任可能在生效前留下清晰、不可伪造的记录。而绕过规则通常是一次性的权力声明这次不算先执行再说我是 Owner立即放行。前者是在重新治理系统后者是在执行发生前取消系统的意义。如果 Owner 能在同一次高风险操作里先改规则、再按新规则批准自己、最后立即执行那么形式上每一步都有记录实质上仍然是单点权力。所以真正有效的治理必须让规则变更和具体执行之间保持距离比如规则变更设置生效等待期、且不能作用于当前正在进行的这一次请求。否则规则只会约束那些没有修改权的人。六、Owner 也需要被系统保护很多产品把限制 Owner理解成不信任 Owner。其实正相反——Owner 往往是最需要被保护的人。他承担最大的责任管理最重要的资产拥有最广的操作范围也是攻击者最有价值的目标。一旦出事外界不会只问系统有没有漏洞还会问谁批准的、谁执行的、谁拥有最终权力。如果系统把所有责任都压在 Owner 的一次点击上它并没有真正帮 Owner 治理风险只是在事故后找到一个可以追责的人。更好的系统应该帮 Owner 做到一件事即使自己的账号被攻破、判断被误导、情绪处于极端状态也无法单独把整个组织推入灾难。这和银行金库需要双人开启、核武器需要多重授权、重大公司决策需要董事会程序是同一种制度思想。限制不是削弱权力而是让权力不必依赖个人永远正确。七、多人审批也可能被 Owner 权力轻易架空有些系统看似已经解决了单点问题因为重大动作需要多人审批。但要接着追问一句Owner 是否拥有下面这些能力——随时移除审批人临时降低审批人数创建新的审批成员修改审批阈值宣布进入紧急模式在审批失败后直接强制执行如果这些能力都由 Owner 单独掌握那么多人审批只是平时流程不是最终结构。正常状态下系统要求三个人同意到真正关键的时刻Owner 一键把规则改成一个人同意。这样的多人治理更像产品功能而不是权力边界。真正的共同治理必须让参与者之间形成相互约束而不是所有人的资格都来自同一个可以随时撤回的中心角色。用密码学治理的语言说这对应M-of-N 门限机制threshold / quorumdef can_execute_critical(action, signers): # 关键Owner 只是 N 个参与者之一不能单独达成门限 # 也不能在这次请求里临时把 M 改小、或把其他签名人踢掉 valid [s for s in signers if is_independent(s) and verifies(s, action)] return len(valid) REQUIRED_M # M-of-NOwner 无法单方越过Owner 可以组织治理但不能随意取消治理对自己的约束。否则多人机制只是 Owner 暂时借给别人的权力。八、Owner 不应拥有清除证据的能力除了执行权Owner 对证据的控制同样关键。如果一个人能发起高风险动作、批准它、完成它还能删掉相关日志那么系统就无法证明真实发生过什么。回到开头的 Ubiquiti 案——那位内部人之所以敢一边作案一边编造外部黑客的故事正是因为他掌握着能被他自己改写的日志系统。很多传统后台把日志当普通业务数据Owner 或超级管理员可以清理历史、重置审计表、关闭日志服务甚至修改时间和状态。从运维看很方便从治理看却意味着——掌握执行权的人同时掌握了历史解释权。成熟的执行安全需要让关键证据独立于普通管理权限。技术上这有成熟做法仅追加append-only、防篡改tamper-evident的日志——比如 WORM一次写入、多次读取存储或用哈希链 / Merkle 结构把每条记录和前一条锁在一起任何一处被删改整条链的校验都会立刻崩掉。Owner 可以查看证据、可以发起归档和迁移但不该能悄无声息地让一段高风险执行从历史里消失。因为共同治理不只意味着没人能单独执行也意味着没人能单独改写执行已经发生过的事实。九、Owner ≠ God不等于 Owner 没有最终责任强调 Owner 不是神不是要造一个没有负责人的系统。恰恰相反Owner 仍然承担最终治理责任决定系统采用什么规则、选择哪些成员参与共同治理、定义哪些动作属于高风险、准备设备故障与成员离线时的恢复方案、对系统长期运行负责。但责任不必和即时、无限的执行权绑定。一个国家的最高负责人承担治理责任不代表他能独自完成所有重大执行一个公司的董事长承担组织责任也不代表所有资金都该由他一人支取。制度的成熟之处正在于责任可以集中灾难性执行能力却应被分散和约束。Owner 的价值应该体现在治理结构的设计上而不是体现在随时可以取消结构上。十、怎样让 Owner 保持治理权却失去单点毁灭能力这不是简单地不给 Owner 权限而是让 Owner 拥有治理能力同时让高风险结果需要额外条件才能发生重大执行需要多个独立角色共同参与关键规则变更不能立即用于当前请求生效等待期高风险恢复需要物理设备、替换流程或明确等待期本地执行边界不能被 Owner 远程强制关闭第八篇讲的无远程后门策略冲突时系统收缩到更安全状态Safe Mode而不是服从最高权限者关键证据不能由发起或审批者单独删除不同层级只能完成各自职责不能在一次操作中合并全部权力。这些设计确实会增加成本让某些紧急操作变慢要求组织提前做好治理准备也会让 Owner 在少数情况下感到被系统拒绝。但这恰恰是结构有效的证明。值得一提的是这套思路在主流云平台早已是标准实践。AWS 官方对权限最高的root 账户给出的建议是开启 MFA、把它锁进抽屉、日常运维绝不使用它而是用受限的 IAM 角色去做事。连云上那个上帝账户都被设计成平时不该被动用——这本身就是 Owner ≠ God 最好的工业注脚。如果 Owner 永远不会被拒绝那么 Owner 仍然是最终执行根。十一、真正成熟的系统不依赖一个绝对好人很多安全架构的底层假设其实非常古老总有一个人是最终可信的。过去是系统管理员后来是公司 Owner再后来是云平台控制台、Root 账号、密钥持有人——只要这个人足够可靠系统就安全。但这不是可靠架构只是把所有风险集中到了一个身份上。Ubiquiti 那位负责安全的工程师、Snowden 那个承包商都曾是各自系统里最该可信的人。真正成熟的系统应该默认Owner 可能误判管理员可能失陷AI 可能误导SaaS 可能被攻破审批人可能理解错设备也可能故障。它解决问题的方式不是去寻找一个更值得信任的人而是让任何一个人的失效都无法直接变成灾难。这在分布式系统里有一个精确的对应概念——拜占庭容错Byzantine Fault Tolerance系统的正确性不建立在每个节点都诚实的前提上而是设计成即使一部分节点作恶或失效整体依然安全。把它翻译到治理上就是分层不信任不是所有人都不可信而是任何人都不应该成为唯一必须永远可信的那个人。十二、Owner 不是神Owner 可以拥有系统可以定义治理方式可以选择成员可以推动升级可以对最终结果负责。但他不应该因为拥有这些权力就能绕过所有边界、单独完成灾难性执行。因为系统真正要防范的从来不只是外部攻击者还包括合法账号被攻破、管理员被误导、组织在压力下做出错误决定、以及最高权限被用于错误动作。如果一个系统在面对普通成员时层层设防却在面对 Owner 时取消所有约束那么它并没有真正建立安全边界——它只是把所有防线的钥匙交给了一个人。Havenlon 强调的 Owner ≠ God不是一句反权威的口号而是一条工程原则治理可以有中心灾难性执行能力不能只有一个中心。Owner 可以管理门闩可以维护门闩可以决定什么时候更换门闩。但他不该在门外通过一只远程按钮随时让门闩失去作用。因为一道真正有效的执行边界必须能够在必要的时候对所有人说不——也包括拥有它的人。这是《Havenlon安全讲人话》系列的第九篇。下一篇我们上升到一个更根本的问题为什么软件不能永远管住软件——当判断、审批和执行都活在同一个软件世界里攻击者只要攻破一个世界就够了。这也是 Havenlon 为什么最终要走向物理边界的起点。参考来源本文引用的真实事件与经典实践Ubiquiti data breach orchestrated by trusted insider, says DoJ — IT ProFeds get guilty plea in Ubiquiti data extortion case — The RecordUbiquiti dev charged with data-breaching own employer — The RegisterAWS: Root user best practices for your AWS account — AWS Documentation