第二十六章 安全、隐私与系统持续运行
利益相关者资本治理一旦依赖数字系统，系统出错就可能改变参与者的现实处境：贡献证据找不到，权益余额错误，支付被阻断，管理权限被误用，或者本应只供特定主体查阅的资料被长期公开。安全因此关乎资产、记录与服务，也关乎谁能够继续行使权利、质疑决定并获得补救。
上一章把业务、证据、规则、权益与治理组织为相互连接的模块。本章进一步检查这套架构在攻击、故障和长期运行中能否维持其制度承诺。技术防护可以降低特定风险，隐私安排可以限制信息使用，持续运行机制则使故障不至于使历史关系和未履行请求消失。三者需要一起设计。
本章不会把“区块链难以篡改”当作安全的总答案。不可随意改写的账本，仍可能保存错误输入；自动执行的合约，仍可能忠实执行不合适的规则；多个节点仍可能共同依赖同一把管理密钥。应当从要保护的关系出发，逐一说明可能失去什么、由谁控制、怎样发现异常以及失败后如何恢复。
一、威胁模型与关键资产识别
威胁模型首先要确定保护对象。资金和链上资产容易被看见，但关键资产还包括原始业务证据、身份与代理关系、有效规则版本、分配资格、未履行请求、审计日志和能够恢复服务的密钥。某一记录虽然没有市场价格，若它是证明贡献或请求的唯一依据，丢失后仍可能给参与者造成重大损害。
保护对象应按其作用区分。数字资产需要防止未经授权的转移与重复兑现；证据需要完整、可得和正确关联；规则需要保持版本与生效范围；个人资料需要限制披露；支付和申诉渠道需要保持可用。不同对象有不同失败方式，不能用一次链上交易成功证明整套制度已经安全。
威胁还要识别谁具有能力接近这些对象。外部攻击者、恶意参与者、越权员工、被盗用账户的操作者，以及虽无恶意但会误操作的维护者，可能从不同入口造成相似后果。协作企业、云服务商和外部数据提供者也掌握部分事实与运行能力。建模不应假设所有组织都诚实可靠，也不应把每个参与者预设为敌人；需要识别各方实际可以改变什么。
权限关系比组织名称更能揭示风险。谁能够签发身份凭证、提交业务事实、修改评价参数、升级合约、暂停系统、提出支付指令、访问个人资料，以及批准恢复运行，应逐项列出。多项权限集中在同一主体时，控制链会缩短，但独立核验也会减少；分散权限则可能降低单点风险，却增加协调时间。选择要结合后果和可恢复性。
风险评估应沿业务过程进行。设立任务时可能发生虚假身份或越权承诺；提交贡献时可能重复报送或伪造交付；评价时可能采用错误权重；形成权益时可能跳过授权；支付时可能错付或重复执行；争议时可能隐藏关键材料。每个环节都应问：错误能否被发现，何时发现，能够阻断多少后续动作，以及谁负责通知受影响者。
安全还包含可用性。一项服务即使没有资产被盗，只要参与者持续无法查看证据、提出异议或领取已成立回报，制度履行也可能受到损害。需要识别哪些功能必须连续运行，哪些可以临时停用，以及中断期间怎样保存申请时间和原有请求。维护系统的能力，是权利兑现条件的一部分。
隐私风险则不止“数据库泄漏”。公开地址与身份资料之间的关联、多个系统共用同一标识、访问日志被用于推断工作关系，均可能让原本分散的信息被重新拼接。若一个贡献者只有通过公开自己的客户、薪酬或合作网络才能证明贡献，制度设计本身就在制造不必要的暴露。
| 关键对象 | 典型失效方式 | 应保留的恢复条件 |
|---|---|---|
| 资产和支付请求 | 越权转移、重复支付、余额错误 | 独立对账、未了请求与授权记录 |
| 证据与贡献历史 | 丢失、伪造、错误归属 | 原始来源、版本、异议及复核路径 |
| 规则与治理权限 | 未授权升级、参数篡改、集中控制 | 有效文本、决定记录与权限交接 |
| 身份和个人资料 | 冒用、关联推断、越界披露 | 代理核验、访问记录与限制机制 |
| 运行能力 | 节点中断、服务商退出、密钥遗失 | 备份、替代办理和恢复责任人 |
威胁模型需要区分发生概率与损害程度，也要考虑风险会否沿模块扩大。一份错误证据可能通过自动接口进入贡献评价、权益配置和支付；一次管理密钥失陷可能影响所有后续规则。优先保护的不是最显眼的功能，而是可能造成重大、难以逆转后果的连接点。
美国国家标准与技术研究院的网络安全框架将网络安全管理置于组织风险管理之中，强调用系统化方法理解和改善风险。本书借其风险视角说明：技术控制需与治理责任、持续监测及恢复能力一起安排，而不是以一份安全认证代替具体制度判断。NIST：网络安全框架 2.0〔1〕
模型还需随着实践修订。新增合作组织、改变资金托管方式、引入新的身份服务或调整治理门槛，都可能产生新的控制点。一次演练或审查通过，只证明当时的特定范围；应记录前提、未覆盖部分和下一次复核条件，使安全判断能够随着制度变化更新。
二、合约、密钥、预言机与治理攻击面
智能合约风险首先来自规则与程序之间的差距。规则文本要求的限制如果没有进入代码，程序会允许制度不认可的动作；代码中多出未经授权的限制，又可能阻碍合法请求。审查应同时对照有效制度、测试输入和实际部署版本，不能只检查代码能否在理想条件下执行。
合约还可能在边界条件下出现意外行为。精度处理、跨期状态、批量操作失败、外部合约调用及升级兼容，都可能影响权益或资金。上线前应有适当测试和独立复核；上线后应监测异常金额、权限调用和状态变化。审查范围必须包括被调用的外部组件和管理员能够改变的配置，否则一份“代码已审计”结论可能遮蔽最重要的动态权限。
不可升级与可升级都存在代价。不可升级有助于使执行逻辑更可预测，但发现缺陷后可能难以修复；可升级使纠错更灵活，也给掌握升级权的人更大影响力。选择前应说明升级条件、批准机构、等待期、可核验的变更说明、回退能力与未了请求处理，避免技术架构先于治理决定确定权力边界。
密钥保护的是操作能力，密钥控制不等于现实权利归属。资产转移、参数变更、合约升级与紧急暂停若使用不同权限，应分别配置并记录授权。高风险操作可以增加多人参与、时间间隔或独立复核；同时需要确认多把密钥是否由不同主体实际保管，以及遗失或人员变动时如何安全交接。
私钥被盗、签名设备故障或继任人员无法接手，会以不同方式造成中断。系统应在日常运行前建立权限清单、恢复程序和撤销路径，规定谁可以启动恢复、怎样核验身份、旧权限如何失效。未经有效审查的“找回密钥”机制也可能成为夺取控制权的入口，因此恢复能力与滥用限制应同时设计。
预言机及其他外部输入会把链下陈述带入自动执行。报价、履约状态、身份资格或客户使用结果，都可能依赖外部提供者。系统能核验消息来自被指定接口，却未必能判断来源事实准确。重要输入需要明确采集方式、提供者、复核者、更新时间和异常值处理；若一个输入源被操纵便能触发大额分配，应限制其单次影响或增加独立核验。
外部数据中断也要有明确后果。报价停止更新时，不能默默沿用旧值完成一项原本依赖实时价格的兑现；业务系统暂时无法确认验收，也不能把“没有反对”解释为已验收。对于有条件的自动执行，应预先规定过期数据、来源分歧和校验失败时进入什么待审状态。
治理攻击面经常隐藏在技术权限之外。少量主体可能通过掌握提案入口、代表授权、投票权重或议程安排改变基本规则；也可能利用紧急权限长期暂停异议者的领取。治理程序应核查资格来源、权重集中、利益冲突、修订门槛以及恢复正常程序的途径。一次形式上有效的投票，若超越适用权限，仍需要制度审查。
智能合约中的角色控制可以限制某个地址可执行的操作，但无法独立判断地址背后的组织授权是否持续有效。OpenZeppelin 的访问控制资料区分角色及其授予、撤销过程；在利益相关者资本治理中，这些技术角色需要映射到可核验的职责、代理和交接记录。OpenZeppelin：角色与访问控制〔2〕
各类攻击面之间还可能形成连锁。虚假数据进入贡献确认，随后利用管理员权限降低审查要求，再通过自动分配转移资源，最后借助日志访问限制阻碍追查，任何单点防护都难以覆盖全过程。系统需要让异常信号在模块之间相互印证，并使监督者能够及时取得必要材料。
防护措施也可能增加新权力。能够冻结账户、替换预言机或接管系统的人，需要受到授权、记录和复核约束。安全措施的意义，是让风险可被限制并使责任可追溯；若处置者完全不受监督，系统可能以防护之名引入新的治理风险。
三、数据最小化、保留期限与删除需求
治理系统需要保存证据以便确认贡献和处理争议，也可能必须回应个人资料的访问、更正与删除需求。二者不能靠一句“全部上链”或“全部删除”解决。设计之初就应问每项数据为何收集、谁会使用、需要保存多久、到期后如何处置，以及出现请求时由谁判断是否仍有保存依据。
数据最小化从任务开始。证明某人符合参加项目的年龄条件，未必需要复制其完整证件；确认某项交付按时完成，也不一定需要公开整个内部工作记录。业务处理者应只取得完成当前判断所必需的资料，并说明若需进一步复核，怎样在授权范围内访问更详细的来源。
W3C《可验证凭证数据模型》在隐私讨论中建议发行者限制凭证内容，核验者也应只请求完成特定交易所需的信息。该原则适用于本书的身份和资格接口：能证明限定条件时，不应默认披露全部身份与履历；即使采用可验证凭证，接收方仍须决定如何使用与保存取得的信息。W3C：可验证凭证与数据最小化〔3〕
最小化还包括限制重复复制。个人资料如果在业务、人事、证据、链上索引和审计库中各存一份，任何一处泄漏都会扩大影响，后续更正也难以同步。系统可以保留受控的来源位置和必要引用，让授权审查者按需获取；不必为了接口便利把所有原始材料传播到每个节点。
公开链上的数据尤其需要审慎选择。即使只上传摘要，若摘要对应低熵或容易猜测的个人信息、与公开标识持续关联，仍可能支持推断或匹配。加密内容放在可长期复制的链上，也不能仅凭当时无法解密就保证未来永不暴露。应先判断某项可核验需求能否由链下保存、选择性披露或受控查询满足，再决定是否上链。
保留期限应按数据类别与用途确定。身份材料、项目原始文件、分配依据、支付回执和审计日志可能具有不同期限与访问要求。期限不宜只有一个全系统默认值，应说明起算事件、延长保留的条件、到期审查与删除方式。过期数据若仍被用于新评价，也需检查是否超出原定用途。
制度中的历史请求可能要求在较长时间内保留必要证据。若参与者尚未领取已成立权益，或者仍存在真实争议，过早销毁唯一依据会损害其复核能力。另一方面，不能因为“未来可能有人争议”就无限期保存全部个人明细。可以按证据重要性和开放权限分层保留，并定期检查继续保存的理由。
删除请求需要区分对象和位置。原始资料可以在满足条件时从受控存储中删除，公开账本的既有记录往往无法同样处理；因此应在设计时减少个人信息进入难以修改的共享层。对已经进入账本的记录，可在有依据时停止继续展示、取消不再必要的索引关联、修正当前状态并限制链下材料可得性，但不能向参与者保证已经发生的公开复制会随之消失。
加密、失效密钥或断开映射可以降低某些数据继续被识别的可能性，其效果仍取决于其他副本、公开关联和未来技术条件。把密钥删除称为“绝对删除”，可能夸大控制能力。组织应向相关主体解释采取了哪些措施，哪些痕迹因系统特性仍可能存在，并据此改进未来的数据收集方式。
更正需求与删除需求也不一样。贡献者指出身份归属错误时，可能更需要保留原证明并更正当前归属；对无关的私人材料则可能需要彻底移除可控副本。制度应提供可以区分两类请求的受理程序，记录决定依据并允许必要复核，而不是让技术管理员按一个“删除按钮”处理全部情况。
访问控制须随角色变化更新。项目负责人离任后，不应继续读取原项目全部个人资料；审计者完成特定任务后，也不应永久持有材料副本。权限授予与撤销、访问目的、必要日志和异常提醒共同构成使用边界。防止未经授权访问，并不意味着监督者必须被排除在所有必要证据之外；可核验监督可以通过范围受限的查验实现。
隐私与透明不是非此即彼。参与者可以了解自己的贡献依据、规则和权益结果，治理机构可以审查总量与异常，公众可以了解制度的基本安排，而不必让所有人看到每个人的薪酬、健康、客户或争议明细。衡量隐私设计是否有效，应同时看过度披露是否减少、必要的纠错和问责是否仍能进行。
四、灾难恢复、系统迁移与长期维护
持续运行意味着在事故发生后仍能恢复关键服务和制度关系。节点、云平台、身份服务、密钥保管或支付接口都可能中断；更换运营者和长期维护经费不足也可能让系统逐渐不可用。恢复方案需要面对这些原因，而不是只保留一份数据库备份。
恢复目标应由业务后果确定。何时必须让参与者重新查询请求，多久内要恢复支付，允许哪些操作短暂停止，以及在中断期间怎样受理异议，需要有明确安排。不同功能可有不同优先级：停止新增发放可能可以接受，丢失已成立请求或关闭全部申诉渠道则会给参与者带来不同性质的影响。
备份要覆盖制度所需的全部状态。账本数据、业务证据、规则文本和程序版本、身份映射、未完成操作、权限清单及外部支付回执，应能在恢复时互相核对。只有区块链节点的副本，不能重建已经丢失的合同或原始交付材料；只有业务库的备份，也可能解释不了链上状态何以变化。
恢复演练应验证可用性，而不仅检查文件存在。应能在隔离环境中读取备份，重建某项任务从业务到权益的关系，复算金额，并核对迁移后的未付请求。若演练依赖一位已经离任的工程师记住不成文的密钥和操作步骤，就说明组织还没有真正取得恢复能力。
密钥恢复尤其要兼顾连续性与控制。重要操作密钥可以采用适当的分散保管与交接程序，记录谁能在何种条件下启动恢复，以及旧权限怎样失效。过于集中的备份可能变成新的单点风险；完全没有可操作的恢复安排，则可能让正常离任或设备损坏变成永久失权。技术形式应服从已确认的授权关系。
事故期间应保留单一的业务状态判断。旧系统可能还在处理请求，新系统又可能根据备份再次执行；若两边同时支付或生成权益，同一义务就可能被重复处理。恢复程序需明确停机边界、最后可信状态、仍在途的链上与链下操作，以及何时由新系统取得唯一执行权。对结果未明的交易，应先核查实际结果再决定重试。
迁移并非仅仅复制数据。采用新的账本、合约或服务商时，需要保证身份、证据、规则版本、权益请求及历史支付之间的关系能够延续。迁移方案应说明旧记录如何验证、哪些状态映射到新系统、哪些请求仍由原义务主体履行，以及未同意迁移的参与者如何取得必要服务。旧系统停止运营不能自动消灭旧制度下的承诺。
迁移中的技术签名也不能替代组织授权。运维人员可以证明某份数据从旧系统导入新系统，是否有权改变权益内容、延长锁定或更换支付义务人，是另外的问题。重大迁移应采用有权决定，公开对比新旧结果，并为差异提供复核和纠正渠道。
长期维护需要持续的资金、人员和治理安排。合约依赖的组件可能需要更新，密钥管理与安全监测要有人承担，数据存储和审计取用也有长期成本。收益模型或业务规模变化时，应再次核对这些成本由谁支付；若仅靠一次开发预算而没有维持资源，系统最初运行成功并不能说明它可以支持跨期资本治理。
服务商替换应能实际演练。组织要能导出有权限的材料、独立核验历史状态、接通替代服务并维持必要功能。合同中写有“数据归客户所有”，如果原始证据格式不可读、签名验证依赖已停用接口，或停机期间无人接收异议，制度上的退出仍然难以实现。
对于系统最终不再适合继续运行的情形，也应提前设计结束程序。停止新任务、清理在途操作、保存必要历史、结清未了请求、通知参与者和安排后续查询，是有序退出的组成部分。系统停服可以是经营决定，权利义务是否终止仍要依据具体制度判断；不能让服务器关闭成为事实上的单方免除。
本书提出一个需要检验的方向：将安全与持续运行能力作为制度有效性的组成部分，而不是上线之后附加的技术指标。应观察故障能否被及时发现、损害能否限制、个人资料是否按用途使用、备份能否重建实际请求，以及更换系统时参与者是否仍可取得证明和救济。只有这些能力与共同创造的长期关系相匹配，制度技术才具有可持续的基础。
下一章将讨论实施路径与制度迁移，进一步说明组织怎样从制度界定和历史数据核验开始，形成一个范围有限、能够验收的运行闭环，并安排试运行、人员培训和退出条件。
定稿补强：跨攻击面的持续运行控制
持续运行需要把密码、密钥、预言机、数据、治理与恢复放进同一威胁模型。算法退役、恢复权滥用、来源同谋、隐私泄露、暂停权限失控和迁移失败可能相互放大。控制清单应记录资产、攻击者能力、依赖、检测、限制损失、恢复和责任人，而不能只列技术漏洞名称。
灾难恢复应验证的不只是服务重新启动，还包括检查点来源、历史验证环境、密钥和权限更新、链下证据可取回、子账和总账对账、临时权限撤销及受影响者通知。数据恢复也应遵守最小化、保留和删除安排；从备份恢复不能使已经到期或应删除的数据无期限复活。
本章工具与图表
本章的制度关系可结合附录九使用。附录用于形成可填写、可核对的工作成果，不能把模板中的默认项视为已经生效的组织规则。
图25-1 利益相关者资本治理整体技术架构。 业务、证据、规则、权益和治理分层连接；链上链下按验证价值和责任配置
本章注释
[SRC-060] 美国国家标准与技术研究院（NIST）：网络安全框架 2.0。原文或官方页面
- 本章引证：NIST：网络安全框架 2.0。
- 支持范围：用于说明公共机构对风险、身份、评估或技术能力的框架性要求，本书引用主题包括：NIST：网络安全框架 2.0。
- 使用边界：框架提供分析与控制依据，不替代组织对具体事实、成本和责任的独立判断。
- 证据等级：B（官方机构、协议项目或公共组织发布的说明与指南）；链接状态：已完成可访问性核验，核验日：2026-10-08。
[SRC-016] OpenZeppelin：OpenZeppelin文档：延迟操作与时间锁。原文或官方页面
- 本章引证：OpenZeppelin：角色与访问控制。
- 支持范围：用于展示具体实现方式、工具接口或实践中的可行安排，本书引用主题包括：OpenZeppelin文档：延迟操作与时间锁、OpenZeppelin：访问控制与角色权限、OpenZeppelin：角色与访问控制。
- 使用边界：实现资料用于说明可行技术路径，不等同于独立安全审计、法律效力或经营效果证明。
- 证据等级：C（实现层或第三方技术资料，用于说明具体工具与实践）；链接状态：已完成可访问性核验，核验日：2026-10-08。
[SRC-076] 万维网联盟（W3C）：Verifiable Credentials Data Model v2.0。原文或官方页面
- 本章引证：W3C：可验证凭证与数据最小化。
- 支持范围：用于确认标准或技术规范对数据结构、验证条件、协议流程及接口语义的明文规定，本书引用主题包括：W3C：可验证凭证数据模型 2.0、W3C：可验证凭证中的选择性披露与隐私考虑、W3C：可验证凭证的参与角色与验证边界、W3C：可验证凭证的验证与业务判断、W3C：可验证凭证与数据最小化。
- 使用边界：符合技术规范只说明相应格式或过程条件，不自动证明链下事实真实、权利合法或制度正当。
- 证据等级：A（原始法律、正式标准、原始研究或正式规范）；链接状态：已完成可访问性核验，核验日：2026-10-08。