从分域防护到体系免疫：数字政府“云数网端智”一体化安全建设方法论

摘要

数字政府的安全边界正在发生结构性变化。过去以网络、主机、应用和数据库为中心的信息系统安全，建立在相对稳定的系统边界、清晰的管理责任和可预测的访问路径之上；今天，政务云、政务网络、政务数据平台、移动与物联终端、人工智能模型、知识库和智能体共同构成持续变化的数字化运行环境。数据在云、网、端和智能应用之间不断流动，身份由自然人扩展到设备、服务、模型和智能体，业务执行由人工操作逐步延伸到模型辅助决策和智能体自主行动。传统分域建设仍然必要，但仅依靠云安全、数据安全、网络安全、终端安全和人工智能安全的并列叠加，已经无法充分解释和控制跨域风险。

本文提出数字政府“云数网端智”一体化安全方法论。该方法论不以建设一个更大的安全平台为目标，而以形成统一的安全治理操作系统为目标：以业务为牵引，以数据为主线，以身份为纽带，以策略为核心，以证据为基础，以运营为保障。全文首先梳理数字政府安全对象和制度要求的演进逻辑，继而识别传统分域建设在资产、身份、策略、证据、责任和运营方面的结构性断层；在此基础上，构建统一安全对象模型、统一策略控制平面、统一证据平面和跨域运营闭环，并将模型、知识库、生成内容和智能体动作纳入同一治理框架。为避免方法论停留在概念层，本文进一步给出对象、动作、控制和证据的最小契约，说明策略决策、证据保全、控制验证、故障降级和持续授权的工程机制，最后形成分阶段建设路线、成熟度模型、指标体系、可证伪条件与实施边界。

本文的核心结论是：数字政府一体化安全的本质，不是将五类产品汇集到同一张大屏，而是使跨云、跨网、跨系统、跨数据域和跨智能应用的安全决策能够基于统一对象和实时上下文执行，并以完整证据证明控制真实有效。只有当政策义务、技术控制、组织责任和运行证据能够形成闭环，数字政府安全才可能从“合规建设”进一步走向“可验证治理”和“体系韧性”。

关键词： 数字政府；云数网端智；数据安全；零信任；人工智能治理；智能体安全；持续授权；安全运营；数字韧性

一、问题的提出：数字政府安全为何必须从分域防护走向体系治理

1.1 数字政府已经不再是一组信息系统

传统电子政务建设通常以部门、业务系统和项目为基本单位。一个系统拥有相对明确的服务器、数据库、网络边界、账号体系和运维责任，安全建设也因此围绕系统定级、边界防护、主机加固、应用测试、数据备份和日志审计展开。这一模式在相当长时间内是合理的，因为业务边界与技术边界大体重合，系统的使用者、数据来源和访问路径相对稳定。

数字政府改变了这一前提。政务云将计算、存储和平台能力集中承载；政务网络将不同层级、不同部门和不同区域连接起来；政务大数据平台推动数据目录化、共享化和服务化；移动终端、物联网设备、边缘节点和自助终端使业务入口高度分散；人工智能平台进一步引入模型、知识库、向量数据库、提示词、插件、工具和智能体。越来越多的政务业务不再由一个系统独立完成，而是由身份认证、数据查询、API调用、算法分析、模型推理和人工审批共同组成。

这意味着，数字政府的实际运行单元已经从“系统”转变为“跨系统业务过程”。一个看似简单的政务问答、辅助审批或城市治理事件，背后可能同时调用政务云资源、跨部门数据接口、知识库、行业模型、地图服务、消息平台和移动终端。任何一个环节的身份伪造、权限继承、数据污染、接口越权或模型误判，都可能沿业务链向下游传播。安全边界不再与某一系统边界重合，而是围绕业务、数据和行动动态生成。

图 1｜安全对象的演进改变了控制单位：从连接和资源，扩展到数据用途、智能体动作与可验证结果。

1.2 “云数网端智”不是五个对象的简单并列

“云数网端智”可以作为观察数字政府技术体系的五个主要视角，但不能被误解为五套互不相关的安全专业：

• 云是资源、算力、平台和运行环境的集中承载体；
• 数是政府履职、公共服务和智能分析的核心对象与生产要素；
• 网是连接关系、服务调用和策略执行的基础设施；
• 端是人员、设备、现实环境与数字业务交互的入口；
• 智是模型、知识、推理、生成和自动化行动能力。

五者之间存在强耦合关系。云资源配置决定数据和模型的运行边界；网络连接决定服务、数据和工具能否被访问；终端状态影响身份可信度和数据泄露风险；数据质量、来源和权限决定模型输出的可信性；智能体又可能通过API和工具改变云资源、修改业务数据或触发终端动作。因此，“智”不是附加在“云数网端”之后的新模块，而是会反向改变其余四域的安全机制。

如果仍然按照传统产品分类分别建设，通常会出现同一对象在不同平台中被重复命名、同一身份在不同系统中具有不同权限语义、同一风险在不同控制台中产生不一致结论的情况。安全团队能够看到大量告警，却难以回答最基本的问题：是谁、以什么身份、在什么业务目的下、通过什么终端和网络路径、访问了哪些数据、调用了哪个模型或工具、产生了什么结果、哪个控制本应生效但没有生效。

1.3 一体化安全要解决的不是“看见更多”，而是“控制一致”

很多一体化安全项目首先想到的是统一门户、统一日志平台或安全态势大屏。这些能力有价值，但它们主要解决信息汇聚问题，而非控制一致性问题。真正的一体化至少必须满足四个条件：

第一，对象一致。不同系统中的用户、设备、云资源、数据、API、模型和智能体能够被唯一识别并建立关系。

第二，策略一致。身份权限、网络访问、数据使用、终端行为和模型动作能够共享相同的风险上下文，避免相互矛盾。

第三，执行一致。策略能够在云、网、数、端、智各类执行点真正落地，并反馈执行结果。

第四，证据一致。事件发生后能够将审批、策略、访问、推理、动作、处置和验证记录关联为完整证据链。

因此，可以把一体化安全能力表达为：

一体化安全能力 = 全域可见性 × 策略一致性 × 控制联动性 × 证据完整性 × 运营闭环性

采用乘法而非加法，是为了强调其中任何一项严重缺失，都可能使整体能力失效。只有资产而没有策略，形成的是更完整的台账；只有策略而没有执行反馈，形成的是制度假设；只有告警而没有证据关联，形成的是事件噪声；只有自动化而没有责任与验证，可能放大错误处置。

1.4 本文的研究边界

本文讨论的是面向数字政府整体运行的安全架构与建设方法，不替代以下专项工作：

• 涉密信息系统分级保护及保密管理；
• 关键信息基础设施专项保护；
• 网络安全等级保护和密码应用安全性评估；
• 个人信息保护影响评估与合规审计；
• 数据出境安全管理；
• 具体行业的专门监管要求；
• 单一产品或平台的技术选型。

“一体化”不是取消专项制度，而是解决专项制度在同一数字政府环境中如何协调、如何共享证据、如何避免控制冲突的问题。

1.5 核心命题、成立条件与可证伪边界

本文提出的不是“集中化必然更安全”，也不是“数据汇聚越多越安全”。一体化安全成立，至少依赖四个可以被检验的命题。

第一，跨域对象能够被稳定识别。如果同一人员、服务、数据、模型或智能体在不同域中无法关联，跨域策略只能依赖模糊匹配，错误关联会比没有关联更危险。

第二，策略决定能够到达真实执行点。如果统一平台只能生成建议，不能影响云控制面、数据网关、API网关、终端代理或智能体工具代理，那么所谓策略一致性只是展示层一致。

第三，执行结果能够形成可复核证据。如果只能证明“发出了策略”，不能证明“执行点接受、执行且产生预期结果”，则控制有效性仍未成立。

第四，体系能够在错误与故障下安全退化。如果策略服务、身份服务、证据链路或自动化编排故障会导致大面积误放行、误阻断或业务不可恢复，一体化反而制造新的系统性风险。

因此，本文把以下情况定义为明确的非完成状态：对象覆盖率很高但关键关系准确率未知；策略已经集中编写但执行点未绑定；日志已经汇聚但无法关联策略版本和执行结果；自动化处置已经上线但未经过影子运行、失败注入和回滚测试；模型或智能体已经登记但其数据权限、工具能力和委托关系仍不可证明。出现这些状态时，只能声明“完成局部纳管”或“具备试运行条件”，不能声明一体化安全能力已经形成。

二、制度逻辑：从网络边界合规到数据活动和智能行为治理

2.1 法律与政策要求的对象正在扩展

我国数字政府安全制度体系并不是由单一文件构成，而是由网络安全、数据安全、个人信息保护、关键信息基础设施保护、密码应用、政务数据共享、公共数据开发利用和人工智能治理等多类制度共同构成。其演进方向可以概括为三个变化。

其一，保护对象由网络和信息系统扩展到数据处理活动。数据的收集、存储、使用、加工、传输、提供、公开和删除，不再只是系统内部操作，而是具有独立法律责任的活动。

其二，责任主体由系统建设单位扩展到数据处理者、平台运营者、受托处理者、第三方服务提供者和人工智能服务提供者。委托建设或采购服务不能自然转移法定责任。

其三，合规评价由“是否部署某项措施”逐步转向“是否能够证明责任落实、风险评估、控制运行和事件处置”。网络数据处理、重要数据保护、个人信息权益保障和人工智能内容标识等要求，都需要持续运行的证据，而非一次性验收材料。

国务院关于加强数字政府建设的指导意见明确要求构建全方位、多层级、一体化安全防护体系，强化数据全生命周期安全管理和技术防护，并形成跨地区、跨部门、跨层级的协同联动机制。这一政策表述对一体化安全的意义在于：安全不再被视为单个项目的附属模块，而被视为数字政府总体架构、责任体系和运行机制的一部分。[1]

2.2 政策不能直接转化为产品清单

制度文本通常规定义务、目标、原则和责任，但不会给出某一地区、某一部门的具体技术架构。把政策条款直接映射为产品采购项，容易产生三类偏差。

第一类偏差是控制替代责任。例如，部署数据防泄漏系统不能替代数据分类分级、处理目的管理、授权审批和责任确认；部署堡垒机不能替代特权账号治理和运维活动审查。

第二类偏差是功能替代有效性。系统具备审计功能，不意味着审计日志完整、时间同步、字段准确、留存合规或能够支持事件复盘。

第三类偏差是合规替代安全。等级保护、密码应用安全性评估、个人信息保护影响评估等制度提供重要基线，但无法自动覆盖跨云共享、智能体工具调用、知识库污染等新型风险。

因此，政策落实需要形成一条可审计的转化链：

法律与政策义务 → 标准和控制目标 → 组织制度与责任 → 技术控制点 → 运行记录 → 有效性验证 → 持续纠偏

图 2｜制度要求只有经过义务拆解、控制设计、执行绑定、证据契约和有效性验证，才会转化为可审计能力。

2.3 标准体系应被用作“控制词典”，而非形式性引用

数字政府安全涉及大量国家标准、行业标准和国际标准。标准的价值不在于参考文献数量，而在于为组织提供相对稳定的控制术语、评价方法和证据要求。例如：

• 网络安全等级保护相关标准提供系统安全保护基线；
• 数据分类分级相关标准提供数据识别、分级因素和保护差异化的基础方法；
• 个人信息相关标准提供最小必要、告知同意、影响评估和权益响应的操作框架；
• 云计算安全标准提供租户隔离、虚拟化、云服务和责任共担要求；
• 零信任、身份治理和访问控制标准可用于设计持续验证机制；
• 人工智能风险管理和安全治理标准可用于模型生命周期、生成内容和智能体行为控制。

但必须注意，标准之间的适用对象、强制程度、发布日期和术语口径并不完全一致。建设单位不能简单把多个标准条款拼接为一张检查表，而应建立本地化“控制词典”：对同义控制进行归并，对不同适用条件进行标注，对强制性要求与推荐性要求进行区分，并明确每项控制的责任主体、执行点、证据类型和验证频率。

2.4 数据要素开发利用使安全目标发生变化

在数据共享开放和公共数据开发利用场景中，安全目标不能仅表述为“防止数据泄露”。如果安全措施导致数据无法依法共享、无法支撑政府履职或公共服务，同样不符合数字政府建设目标。更准确的目标是：

在明确权责、目的、范围和责任的条件下，使数据能够被合法、正当、必要、可控、可审计地使用，并在风险超过阈值时及时限制或终止。

这要求安全体系从传统的存储保护扩展到数据使用控制。数据被谁使用、用于什么目的、在何种环境中使用、允许形成何种派生数据、能否导出、能否用于模型训练、结果能否回写业务系统，都需要策略化表达。数据共享接口的一次授权不应被视为永久授权，尤其是在数据敏感度、调用频率、使用主体或业务目的发生变化时，应触发重新评估。

《网络数据安全管理条例》自2025年1月1日起施行，进一步明确了网络数据处理活动、重要数据识别申报、风险评估和相关责任要求。对数字政府而言，这意味着重要数据治理不能停留在目录层面，而应连接到处理活动、系统、接口、责任人和风险评估证据。[2]

2.5 人工智能治理把责任链延伸到内容和行动

生成式人工智能引入了传统系统安全中并不突出的风险：模型输出具有概率性，知识库检索可能受到提示注入影响，模型可能生成事实错误或不当内容，智能体可以调用工具并产生现实后果。我国生成式人工智能服务治理和人工智能生成合成内容标识制度，已经将训练数据、生成内容、服务责任、显式标识和隐式标识等纳入治理范围。[3][4]

对政府内部智能应用而言，仅做内容安全过滤并不足够。至少需要回答：

1. 模型使用了哪些数据和知识来源；
2. 检索结果是否超出用户本身的数据权限；
3. 模型输出是否可追溯到来源和模型版本；
4. 智能体是否能够调用高风险工具；
5. 动作是否经过独立授权；
6. 结果是否回写业务系统；
7. 错误是否能够回滚；
8. 重大决策是否保留人工复核。

由此，安全责任链从“数据处理责任”进一步延伸为“数据—模型—内容—行动责任”。

2.6 真正困难的是“制度—组织—技术”的多次转译

数字政府安全常见的深层问题，并非没有制度，也并非完全没有技术，而是同一要求在多次转译中逐步失真。法律政策以权利、义务、责任和公共利益为语言；管理制度以角色、流程、审批和问责为语言；技术系统以主体、客体、属性、规则和接口为语言；运营团队最终面对的则是事件、告警、工单和证据。这四种语言不能天然一一对应。

例如，“在实现处理目的的最小范围内使用个人信息”不是一条静态访问控制规则。它至少需要先界定业务目的和法定职责，再确定实现该目的所需的数据字段、时间范围和主体，随后把这些判断转化为接口字段、查询条件、导出限制和保留期限，最后通过访问日志、审批记录和抽样测试证明限制实际生效。任何一环缺失，都可能出现形式上有制度、技术上有权限、实际上仍然过度处理的情况。

这种转译存在四类不可消除的张力。

其一，法律判断具有情境性，技术策略追求确定性。公共利益、紧急状态、法定职责和个体权益之间的权衡，不能完全预编码。技术系统必须知道何时停止自动决策并升级给有权责任人。

其二，组织责任相对稳定，技术对象快速变化。部门职责可能数年不变，而云实例、数据表、模型版本和服务身份每天变化。责任不能只绑定到易变的技术标识，也不能只停留在抽象部门名称，需要通过业务对象和责任角色建立可继承映射。

其三，合规义务强调底线，安全工程处理对抗与不确定性。满足明示条款并不能自动覆盖组合攻击、供应链变化和模型涌现行为。合规基线必须与威胁建模、失败注入和持续验证并行。

其四，技术控制倾向于局部最优，政府治理要求整体正当。严格阻断可能降低泄露风险，却也可能妨碍紧急救助、行政履职和公共服务；提高共享效率可能创造公共价值，也可能扩大用途漂移和二次使用风险。安全架构必须同时说明风险降低、业务影响和权利影响，不能以“系统判定”掩盖价值取舍。

因此，政策映射的正确交付物不是一张“条款—产品”表，而是一组可追踪链：义务由谁解释，适用于哪些业务和对象，通过什么制度与技术控制实现，在何处执行，产生何种证据，谁验证有效，何种变化会使结论失效。只有这条链能够被逐级追问，安全治理才不至于在宏观正确与微观失效之间断裂。

三、现状诊断：分域建设为何难以形成整体能力

3.1 资产断层：同一对象在不同平台中不是同一个对象

云管理平台关注实例、容器、镜像和安全组；网络平台关注IP、端口、链路和流量；数据平台关注目录、库表、字段和接口；终端平台关注设备、用户和软件；人工智能平台关注模型、知识库、提示模板和工具。每个平台都有自己的对象命名和生命周期。

当统一标识缺失时，一个风险事件无法跨域关联。例如，某个异常API调用对应哪个业务系统、哪个云实例、哪个数据集、哪个部门、哪个模型和哪个责任人，通常需要人工查询多个台账。台账之间的时间差和命名差异又会导致误判。所谓“统一资产管理”如果仅汇集设备数量，而不能表达对象关系、责任和动态状态，其价值非常有限。

3.2 身份断层：自然人身份、机器身份和代理身份相互割裂

传统身份治理主要管理人员账号和角色。云原生和智能化环境中，机器身份数量可能远超人员身份，包括服务账号、API密钥、证书、容器身份、工作负载身份、模型服务身份和智能体身份。智能体还可能代表人员或组织执行任务，形成“代理身份”。

如果只对登录用户授权，而不对服务和智能体的后续动作授权，就会出现权限传递失控。用户本来只有查询权限，但智能体通过高权限工具账号执行了修改；应用本来只能访问某类数据，但共享的服务账号可以访问更大范围。身份治理必须从账号管理转向“身份—委托—能力—动作”治理。

3.3 策略断层：不同控制域使用不同语义

网络策略通常表达“谁可以连接谁”；数据策略表达“谁可以访问哪些数据”；终端策略表达“设备处于何种状态”；云策略表达“资源如何配置”；模型策略表达“允许使用哪些模型或工具”。这些策略如果没有共同的主体、客体、目的、上下文和风险语义，就无法进行一致决策。

例如，数据系统认为某用户有权查看敏感字段，但终端系统已经发现设备处于高风险状态；网络层仍允许连接，数据层仍按静态角色放行。又如，模型平台允许智能体调用某API，但该API背后的数据权限并未考虑智能体代理关系。策略断层使得任何单点控制都可能被其他域绕过。

3.4 证据断层：日志很多，但无法证明发生了什么

安全运营常见问题不是没有日志，而是日志无法形成证据。主要表现为：

• 时间不同步，事件顺序无法确定；
• 主体标识不一致，无法确认同一用户或服务；
• 关键字段缺失，无法判断请求目的和结果；
• 日志只记录调用成功，不记录数据范围和策略版本；
• 模型推理日志与工具调用日志分离；
• 审批记录、策略决定和执行记录无法关联；
• 日志完整性和保全机制不足。

这些问题使事件调查停留在经验判断，难以支持责任认定、复盘改进和合规审计。

3.5 责任断层：技术边界变化快于组织边界

数字政府项目涉及业务部门、数据管理部门、信息化部门、安全部门、云服务商、软件开发商、数据服务商和模型服务商。合同中往往对建设任务描述详细，但对运行期安全责任、证据提供、事件响应、模型更新和供应链变更规定不足。

尤其需要警惕“平台负责安全”的模糊表述。平台可以提供控制能力，但业务数据是否应被使用、模型输出是否可用于决策、智能体能否执行某动作，最终仍需要业务责任人和数据责任人作出判断。技术平台不能替代治理授权。

3.6 运营断层：验收关注部署，运行关注风险

项目验收通常关注功能是否上线、设备是否纳管、规则是否配置、报告是否生成；实际运营则需要关注风险是否被发现、处置是否及时、控制是否生效、业务是否恢复、规则是否改进。如果建设成果没有清晰的运行责任和度量指标，平台上线后容易演变为告警展示系统。

图 3｜专业控制并不等于整体能力；真正的失效往往发生在五域之间的对象、身份、策略、证据、责任与运营接缝。

上述六类断层共同说明：分域安全不是错误，而是不充分。云、数、网、端、智仍需要专业控制，但必须在对象、身份、策略、证据、责任和运营层形成贯通。

四、方法论基础：以统一对象模型重构安全治理

4.1 从资产清单到安全对象图谱

传统资产管理回答“有什么”；一体化对象模型还要回答“它与谁相关、处于什么状态、承担什么责任、产生什么证据”。对象模型至少包括四类要素：

1. 对象：人员、组织、设备、云资源、应用、API、数据集、字段、模型、知识库、智能体、工具等；
2. 关系：拥有、管理、部署、调用、处理、委托、继承、派生、连接、依赖；
3. 状态：在线状态、配置状态、风险状态、授权状态、合规状态、版本状态；
4. 证据：审批、策略、日志、扫描、评估、测试、告警、工单、复盘。

图 4｜统一对象图谱以关系和证据连接组织、身份、算力、应用、模型、数据、终端与网络，为跨域决策提供共同语义。

统一对象模型不是要替代所有专业平台，而是为跨域决策提供共同语义。专业平台仍然维护高精度数据，但关键对象和关系应被同步到统一图谱，并具备来源、时间和置信度标记。

4.2 对象唯一标识是跨域关联的前提

统一对象模型最容易被忽视的是标识治理。IP地址、主机名、账号名或模型名称都不能稳定代表对象。需要为关键对象设计持久标识，并维护别名、历史关系和版本。例如：

• 一个云实例重建后是否仍是同一业务对象；
• 一个数据表重命名后如何保持血缘关系；
• 一个模型升级后是否产生新的模型对象；
• 一个智能体使用不同会话执行任务时如何关联；
• 一个服务账号被多个应用共享时如何拆分责任。

对象标识体系应与配置管理数据库、数据目录、身份目录、API目录和模型注册表建立映射。无法确定关系时，应显式标记为待确认，而不是依靠推测自动合并。

4.3 业务过程是风险分析的主线

对象图谱的最终用途不是画关系图，而是支撑业务过程分析。每个重要业务过程都应建立最小安全模型：

业务目标 → 参与主体 → 使用终端 → 调用应用/API → 处理数据 → 使用模型/工具 → 产生结果 → 决策与回写 → 证据与责任

这种模型能够识别传统系统边界之外的风险。例如，数据查询本身合法，但查询结果被模型用于另一个目的；模型输出本身无敏感信息，但被智能体组合后触发了高风险动作；单个API权限合理，但多个API组合形成越权能力。

4.4 数据对象必须覆盖派生数据和智能化中间状态

传统数据资产目录通常关注数据库、库表和字段。智能化场景还需要纳入：

• 训练集、验证集和评测集；
• 特征和嵌入向量；
• 知识库文档及分块；
• 向量数据库；
• 系统提示词与提示模板；
• 对话上下文与长期记忆；
• 检索结果；
• 模型输出和生成内容；
• 智能体计划、工具参数和动作结果。

这些对象可能包含原始数据的敏感信息，也可能形成新的推断信息。删除原始数据并不意味着所有派生对象已被删除。因此，数据生命周期需要扩展为派生链管理。

图 5｜智能化场景的数据治理边界必须覆盖派生链：原始数据之外，特征、向量、上下文、记忆、输出和行动结果都需要控制与证据。

4.5 统一模型应避免“无限建模”

对象图谱并非越大越好。无限采集对象和关系会带来成本、质量和隐私风险。建议采用风险驱动原则，优先纳入：

• 关键业务过程涉及的对象；
• 重要数据和大规模个人信息处理活动；
• 高权限身份和机器身份；
• 对外服务和跨部门接口；
• 高影响模型和智能体；
• 关键基础设施和核心云资源；
• 已发生事件或高频变更对象。

对象模型的质量指标应包括覆盖率、唯一性、关系准确率、更新时间、责任明确率和证据可用率，而非单纯对象数量。

4.6 用四类最小契约把对象图谱变成可执行系统

统一对象模型只有在能够进入策略和证据流程时才具有工程价值。建议用四类最小契约约束不同平台之间的语义交换。

对象契约描述被治理对象，可表达为：

O = ⟨object_id, type, owner, tenant, attributes, state, relations, provenance, observed_at⟩

其中，object_id必须稳定且不可被展示名称替代；owner和tenant用于表达责任及隔离边界；relations保存调用、处理、部署、委托和派生关系；provenance与observed_at说明对象事实来自何处、在何时有效。任何无法确认来源和时间的属性，都不应直接进入高风险自动决策。

动作契约描述一次拟议行为，可表达为：

A = ⟨subject, delegator, object, operation, purpose, context, parameters, budget, expected_effect⟩

它不仅回答“谁访问什么”，还回答“代表谁、为什么、以何种参数、在什么预算和影响范围内执行”。这里的预算可以是次数、金额、Token、数据行数、对象数量、运行时长或外部调用额度。对于智能体，动作提议必须先结构化为该契约，再进入授权流程，不能把自然语言计划直接视为可执行指令。

控制契约把制度义务转化为可测试控制，可表达为：

C = ⟨objective, applicability, condition, decision, obligation, enforcement_point, evidence, test, owner⟩

decision可以是允许、拒绝、降权、脱敏、限时、只读、审批或沙箱执行；obligation表示放行后仍必须履行的要求，例如水印、留痕、用途限制、二次确认和到期删除；test规定如何证明控制有效，而不是只证明功能存在。

证据契约连接决定、执行与结果，可表达为：

E = ⟨event_id, correlation_id, object_snapshot, policy_version, decision, enforcement, result, integrity, event_time⟩

其中，correlation_id贯穿业务请求、策略决定、执行动作、业务结果和处置复盘；object_snapshot保存决定发生时的关键上下文，避免用事后状态解释历史事件；integrity记录签名、摘要、可信时间或保全状态。四类契约共同构成跨域协同的最小语义，不要求所有平台使用同一产品，却要求关键输入输出能够被一致解释、独立验证和重放。

4.7 “统一”应当统一语义和保证目标，而不是消灭自治边界

一体化建设容易滑向技术集中主义：认为只要把对象、策略、日志和运营全部汇入一个平台，就能获得一致性。这个判断忽略了数字政府天然存在多级管理、部门职责、数据主权、业务专业性和故障隔离要求。过度集中不仅难以落地，还可能形成单点错误、越权汇聚和平台锁定。

更合理的模式是联邦式统一：中央层统一标识规则、最小契约、控制词典、证据质量、策略接口和跨域保证目标；部门或区域保留专业对象、局部策略、数据细节和执行自治。只有需要跨域判断的最小上下文进入共同控制面，敏感原始数据和专业细节尽量留在本域。统一平台看到的不是所有数据，而是足以作出特定决定、且来源和时效可证明的必要事实。

联邦模式的难点不在API联通，而在权威来源冲突。例如，人事目录认定人员仍在岗，业务系统认定其项目权限已结束，终端系统认定设备高风险，数据系统却保留历史角色授权。此时不能简单采用“最新值”或“中心值”，而应为不同属性指定权威来源、有效期和冲突规则：身份状态由组织目录负责，业务委托由业务责任系统负责，设备姿态由终端控制负责，最终动作决定由策略控制面综合形成。对于无法自动裁决的冲突，应默认收敛权限并进入人工核验。

因此，一体化的最小共识应是：对象可关联、语义可交换、策略可组合、执行可证明、故障可隔离。超出这个范围的集中化必须证明其必要性和比例性。若为了“统一视图”收集了与决策无关的大量个人信息和业务数据，一体化平台本身就会成为新的高价值风险源。

五、总体架构：纵向分层、横向贯通、双平面驱动

5.1 总体架构原则

数字政府“云数网端智”一体化安全总体架构应遵循以下原则：

• 业务牵引：安全控制服务于政府履职和公共服务连续性；
• 责任先行：控制权与责任相匹配，委托关系可追溯；
• 数据主线：围绕数据处理活动和派生链组织保护；
• 身份统一：覆盖人员、设备、服务、模型和智能体；
• 策略解耦：决策逻辑与执行点解耦，支持跨域一致控制；
• 证据原生：控制执行必须同时产生可审计证据；
• 持续验证：不以一次认证、一次评估或一次验收替代持续判断；
• 韧性优先：在攻击、故障和误操作下保障关键业务连续；
• 渐进建设：优先解决高风险业务链，不追求一次性全量平台化。

图 6｜总体架构以治理与运营为两侧约束，以策略和证据双平面为中枢，并在云、数、网、端、智执行面闭合。

5.2 战略与业务层：安全目标必须可解释为业务后果

安全架构的顶层不是安全产品，而是政府履职、公共服务、城市治理、监管执法和应急指挥。每项安全控制都应能够解释其保护的业务结果。例如：

• 身份持续验证保护的是审批和执法行为的真实性；
• 数据使用控制保护的是政务数据依法共享和公民权益；
• 模型评测保护的是辅助决策的可靠性；
• 智能体动作授权保护的是业务操作的可控性；
• 灾备和韧性保护的是关键公共服务连续性。

只有将安全风险翻译为业务影响，才能合理确定优先级，避免低风险问题消耗大量资源，而高影响业务链缺乏保护。建议对每一个关键业务建立“业务影响画像”，至少包括服务对象、法定职责、停摆后果、错误决策后果、数据敏感性、峰值压力、依赖系统、人工替代能力和恢复目标。

5.3 统一安全治理层：建立共同的责任与控制词典

治理层负责统一组织责任、制度规则、架构标准、风险口径和评价机制。其主要产出不应只是制度文件，而应包括：

• 云数网端智安全责任矩阵；
• 统一对象和术语表；
• 控制词典及适用条件；
• 数据和模型分类分级规则；
• 高风险业务和动作目录；
• 架构安全评审机制；
• 供应链安全要求；
• 例外审批和风险接受机制；
• 关键指标与审计证据清单。

治理层还应明确“谁有权改变策略”。安全部门可以提出风险限制，但涉及业务可用性、数据使用目的和智能体动作权限时，需要业务、数据和技术责任人共同参与。建议采用RACI或更细化的责任分配方法，区分最终负责、具体执行、协商参与和知会对象；对于高风险数据处理和智能体动作，还应明确批准者、验证者和事后审查者，避免同一主体同时拥有开发、审批、执行和核验权。

5.4 策略控制平面：把安全要求转化为动态决策

策略控制平面是架构的核心。它接收主体身份、设备姿态、业务目的、数据等级、环境风险、模型状态和历史行为等上下文，输出允许、拒绝、降权、脱敏、审批、限时、只读等决定，并将决定下发到云、网络、数据、终端和智能执行点。

图 7｜策略控制平面把身份、姿态、目的、数据和风险上下文转化为可追溯决定，并将执行结果反馈到下一次策略重算。

策略控制平面的关键不是集中部署一个决策引擎，而是建立统一策略语义和决策接口。策略可以由多个专业引擎共同执行，但应保证：

• 主体和客体标识一致；
• 决策输入可解释；
• 策略版本可追踪；
• 例外有明确期限；
• 执行结果可反馈；
• 冲突策略有优先级；
• 高风险动作可转人工审批。

策略即代码可以提升一致性和可测试性，但不能把复杂治理判断完全技术化。涉及法律解释、公共利益、数据目的变更和重大业务影响时，仍需人工决策和正式授权。

策略设计还应遵循“默认拒绝、显式允许、最小能力、时间受限、目的绑定、结果可追踪”的原则。传统权限管理常以资源为中心，回答“谁能访问什么”；一体化策略还必须回答“为什么访问、如何访问、能做什么、允许产生什么结果、何时需要重新判断”。对于数据和智能体动作，目的和结果尤其关键。

5.5 证据与分析平面：从日志中心升级为证据系统

证据平面负责采集云审计、网络流量、数据访问、终端行为、API调用、模型推理和智能体动作等遥测，并进行时间、主体、对象、动作、策略和结果的语义关联。

图 8｜证据平面不是日志汇聚，而是一条从遥测接入、语义标准化到事件图谱、风险推理、处置编排和验证复盘的证明流水线。

与传统日志平台相比，证据平面应新增五项能力：

1. 证据标识：为同一业务过程和事件建立关联ID；
2. 策略关联：记录执行时使用的策略版本和决策输入；
3. 完整性保障：对关键证据进行防篡改、签名、时间戳或可信存证；
4. 因果假设：区分时间相关、统计相关和因果结论，保留推理依据；
5. 复现能力：允许基于历史上下文重放决策，验证策略是否正确。

“安全大脑”如果没有高质量对象和证据，只能生成更快的低可信判断。分析智能化必须建立在数据质量、语义一致和证据完整之上。证据平面还应对数据来源和置信度进行标注，避免不同质量的证据被等同使用。

5.5.1 证据不是二元存在，而应具有可声明的证明等级

同一条日志在不同治理问题中的证明能力不同。为了避免把“有记录”误写成“已证明”，可将证据划分为四个工程等级：

• E0 线索级：告警、异常评分或人工描述，只能说明需要调查；
• E1 事件级：具有时间、主体、对象、动作和结果等基本字段，能够证明某个观测发生；
• E2 控制级：事件可关联策略版本、决策输入、执行点及执行结果，能够证明某项控制是否实际生效；
• E3 保证级：关键证据具备完整性、来源、可信时间、保全链和独立复现条件，可用于重大事件复核、责任审计或持续保证。

等级越高，采集、留存和隐私成本越高，不应把所有遥测都建设为E3。正确做法是根据业务影响、法律责任、动作可逆性和争议概率，为不同对象和事件指定最低证据等级。例如，一般网络扫描告警可停留在E0或E1，而高权限数据导出、重要策略变更、智能体业务写入和重大自动化处置应至少达到E2；涉及关键决策、重大事故或独立审计的证据链，则需要按E3设计。

5.6 安全能力层：控制必须落到专业执行点

统一架构不意味着所有控制由一个平台执行。云、数、网、端、智具有不同技术机制：

• 云侧需要配置治理、工作负载保护、镜像与供应链、密钥和租户隔离；
• 数据侧需要分类分级、脱敏、加密、使用控制、数据库审计和数据流追踪；
• 网络侧需要分区、微隔离、API安全、流量检测和连接控制；
• 终端侧需要设备可信、补丁、应用控制、外设与数据防泄漏；
• 智能侧需要数据与模型治理、提示防护、内容安全、模型评测、工具约束和动作审计。

一体化要求这些执行点接受共同策略并反馈结果，而不是以一个通用产品替代专业能力。

5.7 架构的三个关键接口

整体架构能否落地，取决于三个接口是否设计清楚。

对象接口负责在不同平台间交换对象标识、属性、关系和状态。对象接口必须支持增量更新、来源标记、版本和冲突处理。

策略接口负责传递策略请求、上下文、决定、义务和执行结果。策略接口需要保证低延迟、容错和可审计，并设计在决策服务不可用时的安全降级方式。

证据接口负责传递结构化事件、关联ID、策略版本和结果。证据接口应有字段规范、时间同步要求、完整性保障和留存策略。

如果没有明确接口，一体化平台只能依靠定制开发连接各类系统，最终形成高耦合、难维护的新烟囱。

5.8 控制平面故障必须预先定义安全降级语义

统一策略和证据平面提高协同效率，也扩大了故障影响面。建设时必须明确：当身份目录、策略决策点、证据总线、时间服务或外部风险源不可用时，各类业务应如何退化。不能用一句“高可用部署”替代故障语义设计。

建议按业务风险预设四类模式。

• 拒绝关闭（fail closed）：高风险写入、批量导出、特权操作和智能体不可逆动作在无法取得可靠决定时停止执行；
• 受限继续：公共服务查询等连续性要求较高的场景可使用最近一次可信策略缓存，但必须缩短会话、降低数据范围、禁止高风险动作并补记证据；
• 人工接管：策略冲突、风险不确定或证据缺失时进入双人复核、线下授权或应急流程；
• 隔离运行：核心业务在外部依赖故障时切换到本地最小策略集和最小数据集，恢复后再执行差异核验。

每一种降级都应声明最大持续时间、允许动作、禁止动作、责任人、恢复条件和补偿性证据。还应通过身份服务超时、策略版本不一致、消息积压、时钟漂移、证据丢包和自动化回滚失败等故障注入，验证系统是否按照设计退化。未经故障验证的高可用，只是架构愿望，不是可计入能力的证据。

5.9 策略一致不等于策略相同，关键在于冲突可以被确定裁决

云、网、数、端、智五域的控制目标并不总是一致。网络侧可能允许某服务连接，数据侧因用途变化而拒绝读取；业务侧要求紧急处置，终端侧却因设备风险要求阻断；模型侧认为工具调用符合任务计划，数据侧认为返回字段超出最小必要范围。若控制面只负责“下发统一规则”，面对真实冲突时就会失去解释能力。

策略组合需要预先定义至少五类关系：高位义务对一般策略的优先关系，拒绝与允许的覆盖关系，紧急例外的触发和到期，数据与业务责任人的共同批准，以及局部执行点无法实现附加义务时的处理。一般情况下，高风险写操作应采用“任一关键控制拒绝即拒绝”，低风险查询可以采用“满足全部强制义务后允许”；紧急例外不能删除原规则，而应生成有时间、范围、批准人和补偿控制的独立决定。

更重要的是，冲突裁决不能只给出最终结果。证据中应保留参与决策的策略、适用条件、冲突类型、优先规则和被覆盖的决定。否则，运营团队只能看到“拒绝”或“允许”，无法判断是正常优先级、配置错误还是某一域状态过期。策略一致性的真正含义，是同样的输入和版本可以得到可重复结果，不同结果能够被上下文差异解释，而不是所有控制域永远给出相同答案。

六、五域安全机制：从独立防护到协同控制

6.1 云安全：从资源防护转向可信运行环境

政务云通常承载大量跨部门系统和数据。云安全的核心矛盾是资源集中带来的效率与风险集中并存。需要重点控制：

• 云账号和管理面权限；
• 租户隔离与网络分区；
• 安全组、对象存储和公网暴露配置；
• 云原生工作负载、容器和编排平台；
• 镜像、依赖和软件供应链；
• 密钥、证书和机密管理；
• 云API和自动化运维；
• GPU、模型服务和智算资源；
• 多云、混合云和第三方云服务责任。

云配置变化速度远高于传统物理环境，年度检查不足以控制风险。应采用持续配置评估、基础设施即代码审查和策略即代码验证。对关键工作负载，可结合可信计算、机密计算和远程证明提升运行环境可信度，但不能将硬件证明误解为应用、数据或模型整体可信。

云与其他域的协同点包括：数据等级决定存储与计算区域；身份风险决定云管理权限；网络策略随工作负载动态变化；模型风险决定GPU资源和外部连接限制；云审计进入统一证据平面。

6.2 数据安全：从静态保护转向可控使用

数据安全应围绕数据处理活动组织，而不是只围绕数据库。核心能力包括：

• 数据目录和责任归属；
• 分类分级与重要数据识别；
• 数据处理目的和法律依据；
• 最小必要和字段级访问控制；
• 数据脱敏、加密和密钥管理；
• 数据共享、开放和委托处理评估；
• 数据接口和批量导出控制；
• 数据血缘和派生链；
• 数据质量、污染和完整性；
• 数据删除、归档和可验证销毁；
• 数据安全风险评估和事件响应。

数据分类分级必须与控制策略绑定。如果分级结果只存在于Excel台账，不能驱动访问、导出、共享和模型训练限制，就不会形成真实保护。

对数据共享，应把授权从“接口开通”细化为主体、目的、字段、频率、时限、用途、存储、再共享、派生和删除等条件。对公共数据授权运营，还需要区分原始数据、加工产品和结果输出的责任边界。

数据安全治理还应引入“用途漂移”监测。某项数据最初为统计分析开放，但后来被用于个体画像、自动决策或模型训练，风险性质可能发生根本变化。用途变化应触发重新评估，而不能沿用原授权。

6.3 网络安全：从边界阻断转向连接关系治理

数字政府网络环境包括政务外网、互联网区、行业专网、云内网络、跨云连接、API网络、服务网格、物联网和移动通信。传统以IP和端口为中心的控制难以应对动态工作负载和服务身份。

网络安全需要逐步转向：

• 基于身份和服务的连接策略；
• 业务域和数据域分区；
• 东西向微隔离；
• API发现、认证、授权和调用行为分析；
• 服务网格和工作负载身份；
• 加密传输和证书生命周期管理；
• 网络行为分析与威胁检测；
• 高风险连接动态降权或中断；
• 网络路径与数据流关联。

网络不是一体化安全的“中间层”，而是策略执行和证据获取的重要平面。网络控制应同时理解连接双方的身份、业务目的和数据敏感性。

6.4 终端安全：从设备管理转向业务入口可信

终端包括办公电脑、移动设备、自助终端、物联网设备、边缘节点和第三方运维终端。终端是人员身份、现实环境和数字业务的交汇点。主要风险包括设备失陷、账号冒用、恶意软件、数据复制、外设泄露、远程运维和不受管设备接入。

一体化终端安全不应仅报告病毒和补丁，而应向策略控制平面提供设备姿态：设备是否受管、补丁是否达标、是否存在高风险进程、磁盘是否加密、位置是否异常、用户行为是否偏离基线。数据和应用系统据此动态决定是否允许访问敏感数据、是否只读、是否限制下载或是否要求二次认证。

对物联网和边缘终端，还应关注设备身份、固件更新、弱口令、物理暴露、通信协议和生命周期退出。大量低成本设备长期在线但缺乏更新能力，可能成为横向移动和数据污染入口。

6.5 智能安全：从模型安全扩展到智能行为安全

“智”至少包括算力平台、数据与知识、基础模型、行业模型、智能应用和智能体。其风险可以分为六层：

1. 数据层：训练数据污染、知识库越权、敏感信息进入提示与记忆；
2. 模型层：后门、模型窃取、越狱、幻觉和能力漂移；
3. 检索层：提示注入、恶意文档、引用错误和权限旁路；
4. 应用层：输出过滤不足、会话隔离缺失、插件风险；
5. 工具层：高权限工具、参数注入、调用链劫持；
6. 行动层：错误决策、越权回写、批量操作和不可逆影响。

对政府内部模型，最重要的不是追求绝对“无幻觉”，而是根据使用场景建立风险分级。低风险场景可以允许模型生成辅助性文本；高风险场景如行政决定、执法、财政支付、公共安全和重大资源调度，应保留明确的人工复核、依据引用和责任链。

6.6 五域协同控制的典型场景

场景一：高风险终端访问敏感数据。 终端平台发现设备感染风险，身份平台仍能确认用户身份，数据平台也存在静态权限。一体化策略应综合设备姿态和数据等级，将访问降为只读、限制导出并触发二次认证，而不是简单依赖任何单一平台。

场景二：模型服务访问跨部门知识库。 模型平台只负责推理，知识库属于其他部门。策略控制应继承用户和智能体身份，按照文档权限过滤检索结果，并记录检索依据和输出引用。

场景三：智能体调用政务API。 智能体生成动作计划后，策略引擎根据委托关系、工具风险、参数范围和业务时段作出决定；高风险动作转人工审批，执行结果写入证据平面。

场景四：云资源配置变化导致数据暴露。 对象存储配置被修改为公网可访问，云侧持续配置评估发现异常，数据目录识别其中包含敏感数据，网络和云控制立即收敛暴露面，同时生成事件证据并通知责任人。

场景五：跨区域数据共享异常增长。 API调用量和字段范围明显偏离既定业务目的，策略控制平面触发限流和复核，证据平面关联调用主体、数据对象、审批记录和下游使用情况。

这些场景说明，一体化不是额外增加一层告警，而是让不同域的状态共同参与决策。

6.7 五域不是对称的“五根柱子”，而是不同性质的治理变量

把云、数、网、端、智画成五个等宽方框，便于展示，却容易造成错误理解。五域在业务链中的角色并不对称：云和网主要提供运行与连接条件，端连接人和现实环境，数据既是保护对象也是决策输入，智能系统则开始同时扮演处理者、建议者和行动代理。它们的风险传播方向、控制时点和责任属性都不同。

云与网的典型风险是环境和路径失控：配置错误、隔离失效或连接暴露会改变其他对象可达性。端的典型风险是入口真实性与环境可信不足：即使账号真实，设备或现实操作环境也可能不可信。数据的典型风险是用途漂移与不可逆扩散：一次合法访问可能被后续组合、推断和派生为新的敏感信息。智能系统的典型风险则是不确定判断与可执行能力结合：模型错误一旦绑定工具、预算和自动化速度，就可能越过“错误信息”阶段，直接形成业务后果。

因此，五域协同不应追求每域建设相同数量的能力，而应围绕业务链寻找控制杠杆。云网端状态主要作为“能否进入、能否持续、是否降权”的上下文；数据策略主要约束“为何使用、使用多少、能产生什么派生”；智能策略主要约束“能建议什么、能调用什么、能否形成现实效果”。真正贯穿五域的是身份与委托、对象关系、动作契约和证据关联，而不是五套产品目录。

这也解释了为什么“智”不能作为最后追加的安全模块：当模型只生成草稿时，它更接近应用组件；当模型选择工具、制定计划并写回业务时，它成为新的非人主体。治理对象从模型参数转向“被授权的行动能力”，原有身份、数据、网络和云控制都必须随之重新解释。

七、跨域风险：为什么低强度输入可能形成高影响后果

7.1 风险由机制放大，而非由输入规模决定

传统安全运营容易以流量、攻击次数或恶意样本数量判断风险。但在云数网端智环境中，低强度输入可能触发高权限、自动化和大范围业务流程。例如，一段恶意提示可能诱导智能体检索超出权限的数据，调用高权限API，再将结果回写业务系统。输入本身很小，影响却可能很大。

风险放大主要由以下变量决定：

• 权限继承范围；
• 自动化执行速度；
• API和工具组合能力；
• 数据共享和业务耦合程度；
• 操作是否可逆；
• 是否存在人工复核；
• 影响对象和公共服务范围。

图 9｜低强度输入会被权限能力、自动化速度、传播范围和业务关键度逐级放大；检测、恢复和人工接管构成必要减震机制。

因此，风险度量不能只关注攻击强度，还应关注“机制放大系数”。一个可用于实践的分析框架是：

风险影响 ≈ 输入恶意度 × 权限能力 × 自动化速度 × 传播范围 × 业务关键度 ÷ 可检测性与可恢复性

该表达式不是精确数学模型，而是提示评估人员关注传统漏洞评分之外的系统机制。

在实际评估中，更稳妥的方法不是为每个变量制造看似精确的分数，而是建立可核验的分级依据。权限能力可由可访问对象、可执行动作和可委托层级刻画；自动化速度可由单位时间动作量和人工介入窗口刻画；传播范围可由下游依赖、租户数量和跨区域接口刻画；业务关键度可由法定职责、公共服务影响和不可逆后果刻画；可检测性与可恢复性则必须由真实演练和历史数据证明。若分母仅来自“已部署监测”和“具备备份”等功能声明，风险会被系统性低估。

该模型还隐含三个重要条件：变量之间可能相关，不能简单重复计分；放大效应常有阈值，超过权限、数量或时间阈值后可能发生非线性跃迁；恢复能力只对可恢复范围有效，不能抵消隐私泄露、错误行政决定等不可逆后果。因此，公式适合用于结构化讨论、优先级比较和场景测试设计，不适合作为脱离业务证据的单一“综合风险分”。

7.2 API和工具是跨域风险的主要接口

数字政府的跨系统协同越来越依赖API。人工智能和智能体进一步将API变为可被模型自动选择和组合的工具。API治理因此必须同时覆盖：

• 目录与责任；
• 认证与授权；
• 字段和数据范围；
• 调用频率与批量限制；
• 参数校验；
• 业务目的；
• 异常行为；
• 版本与下线；
• 智能体可用工具白名单；
• 工具调用审计。

传统API密钥只证明调用者持有凭据，不能证明调用目的合法。对高风险API，应支持细粒度令牌、短时授权、动作级审批、参数约束和结果回传。

7.3 共享身份和高权限服务账号是风险放大器

多个应用共享同一服务账号，会破坏责任可追溯性；模型或智能体使用高权限账号，则可能绕过终端和用户权限。应逐步采用工作负载身份和短期凭据，避免长期密钥；对智能体应建立独立身份、委托关系和能力边界。

7.4 自动化响应本身也可能成为风险

安全编排和自动化响应能够缩短处置时间，但错误规则可能造成大范围中断。自动化程度越高，越需要：

• 处置影响评估；
• 分级授权；
• 沙箱或影子模式；
• 幂等和回滚能力；
• 人工接管；
• 变更审计；
• 处置后验证。

一体化安全不追求“全部自动化”，而追求“在可证明安全的范围内自动化”。

7.5 供应链耦合带来的隐性传播

云平台、开源组件、数据服务、模型服务和第三方插件构成复杂供应链。供应链风险往往不是直接攻击政府系统，而是通过更新、依赖、镜像、模型权重、知识库文档或外部API进入。应建立组件和模型清单、来源证明、版本变更、漏洞影响分析和退出方案。对于无法验证来源或无法获得关键安全证据的供应商，应将其视为风险条件，而不是用合同表述掩盖证据缺失。

7.6 用对抗路径检验“跨域联动”是否真的成立

跨域能力最容易在正常流程中被高估。验证时应主动选择能够推翻设计假设的路径，而不是只运行预期会通过的用例。至少应覆盖：合法身份在高风险终端上访问敏感数据；低权限智能体通过共享服务账号调用高权限API；知识库文档触发间接提示注入；对象标识发生漂移导致策略绑定错误；执行点离线时使用过期策略；自动化处置在误判后无法完整回滚；供应商更新改变模型或接口行为但未触发复审。

一次对抗测试不应只给出“攻击成功/失败”。它要同时验证五件事：入口控制是否识别异常，跨域状态是否进入决策，执行点是否实施限制，证据链是否完整，业务是否能够恢复。若攻击被阻断但没有形成可复核证据，只能证明某次结果正确；若产生告警但动作继续完成，则只能证明看见风险；若控制有效却造成无法接受的公共服务中断，则说明策略仍不具备生产可用性。

八、智能体治理：从会话权限到动作级持续授权

8.1 智能体改变了授权对象

传统授权通常在用户登录或访问资源时进行。智能体可能在获得任务后自主规划多个步骤，调用多个工具，读取和组合多类数据，并在较长时间内持续执行。一次初始授权无法覆盖后续所有动作。

因此，授权对象应从“是否允许使用智能体”细化为：

某智能体在代表某主体、为实现某目的、处于某上下文时，是否可以调用某工具，对某数据或系统执行某动作，并承担何种义务和限制。

这里至少包含六个必须独立表达的变量：委托主体、智能体身份、任务目的、工具能力、数据范围和动作后果。任何一个变量发生变化，都可能使原授权失效。授权还需要区分“提出建议”“生成草稿”“发起请求”“执行操作”和“形成法律或业务效果”等不同能力层级。

8.2 动作级持续授权的核心机制

图 10｜智能体授权必须在动作级持续成立：每次工具调用和业务写入都重新评估主体、数据、目的、预算、影响与风险。

动作级持续授权至少包括：

1. 身份与委托：明确智能体代表谁、授权来自谁、有效期多久；
2. 上下文感知：识别设备、网络、业务、数据、时间和风险状态；
3. 动作提议：智能体先生成结构化动作计划，而非直接执行；
4. 策略决策：对工具、参数、数据范围和影响进行判断；
5. 受控执行：在沙箱、代理或策略执行点中运行；
6. 证据记录：保存决策输入、策略版本、调用结果和影响；
7. 风险更新：根据行为和结果动态调整权限。

动作决策可以抽象为：

D, Ω = F(S, G, O, A, P, C, R, H)

其中，S为当前主体和智能体身份，G为委托链，O为目标对象，A为拟议动作，P为业务目的，C为实时上下文，R为当前风险，H为历史行为；输出D是允许、拒绝、降权、审批或沙箱执行等决定，Ω是必须同时履行的义务集合。义务可以包括字段脱敏、限定工具、缩小参数、限额、加水印、人工确认、结果复核、保留证据或在指定时间内自动撤销。

这个抽象强调两点。其一，授权结果不是永久权限，而是特定动作在特定上下文中的一次决定；其二，“允许”不是流程终点，执行点还必须证明义务被满足。例如，策略允许智能体生成审批意见，但附带“不得直接写入正式决定、必须标注来源、必须由责任人确认”的义务；若工具代理不能执行这些义务，即使主体有权限，也应拒绝该动作。

高风险动作应支持双人审批、限额、延迟执行、模拟预览和人工接管。对于不可逆动作，应优先采用“提议—确认—执行”模式。对于批量动作，应设置数量、金额、时间和对象范围上限，避免模型在错误规划下造成大规模影响。

8.3 权限不应由提示词控制

在系统提示词中写入“不得访问敏感数据”不能替代技术授权。提示词属于模型行为约束，可能被注入、覆盖或误解。真正的权限控制必须在模型之外的执行点实施，确保即使模型产生违规请求，工具层和数据层也会拒绝。

提示词可用于表达操作规则和辅助模型理解，但不能作为安全边界。需要将提示约束、工具声明、策略执行和审计分别设计，避免把模型的“服从”当作控制有效性。

8.4 RAG必须继承原始数据权限

知识库检索增强生成容易出现“检索层越权”：用户无权查看原始文档，但模型通过统一知识库检索后输出了相关内容。RAG系统应在检索前执行权限过滤，并将用户、智能体、文档、分块和数据等级纳入策略。向量相似度不能替代访问控制。

还需要控制分块和嵌入过程。文档权限变化时，相关分块和向量索引应同步更新；文档删除时，应验证向量、缓存和模型记忆是否被清理；检索结果应保留来源引用，便于判断输出是否有依据。

8.5 智能体记忆需要独立治理

长期记忆可能保存个人信息、工作秘密或业务上下文。应明确记忆的来源、用途、保留期限、可见范围和删除机制。不同用户、部门和任务之间必须隔离，避免跨会话泄露。记忆写入也应经过策略控制，防止恶意输入长期污染智能体行为。

建议将智能体记忆分为会话临时记忆、任务记忆、用户偏好记忆、组织知识和安全审计记忆。不同类型采用不同的保留、访问和删除规则。安全审计记忆不能被智能体自行修改，用户偏好记忆则应支持查看和纠正。

8.6 模型和智能体评测应面向任务风险

通用模型排行榜不能代表政府场景安全。评测应覆盖：

• 任务正确性和事实依据；
• 数据权限继承；
• 提示注入抵抗；
• 敏感信息泄露；
• 工具选择和参数安全；
• 拒绝策略的稳定性；
• 高风险动作升级；
• 人工接管能力；
• 版本更新后的回归；
• 对抗条件下的恢复。

评测结果应与允许使用的业务场景绑定。一个模型可以适合内部知识问答，但不一定适合自动审批；可以适合生成材料草稿，但不一定适合直接对外发布。

九、零信任织体：身份、数据、网络和模型的持续协同

零信任常被简化为身份认证或远程访问方案。对于云数网端智环境，更适合将其理解为一种跨域决策原则：任何主体、设备、服务、模型或智能体的信任都不是永久的，访问和行动必须基于当前上下文持续评估。

图 11｜零信任不是单点登录或网络隔离，而是把身份、资源、行为和结果信号织入访问前、访问中与行动后的持续评估。

9.1 统一身份不等于单点登录

单点登录解决身份认证体验，但不能解决机器身份、委托关系、权限过度和持续风险。统一身份体系应覆盖：

• 人员身份和组织关系；
• 设备身份和姿态；
• 应用与服务身份；
• 工作负载身份；
• API客户端身份；
• 模型服务身份；
• 智能体身份；
• 委托和代理关系；
• 凭据生命周期。

机器身份治理的关键是减少长期静态凭据，使用可轮换、短时、可绑定工作负载的凭据，并确保身份与具体运行实例、环境和任务关联。否则，泄露的密钥可以在不同环境中长期复用。

9.2 权限模型应从RBAC扩展为多因素决策

基于角色的访问控制仍是重要基础，但难以表达复杂场景。可在RBAC基础上结合属性、关系、目的和风险：

• 角色决定基础能力；
• 属性描述主体、数据和环境；
• 关系表达组织、委托和业务依赖；
• 目的限制数据使用场景；
• 风险决定动态降权；
• 义务规定脱敏、审计、审批或删除要求。

采用复杂策略模型时，需要防止策略不可理解。每次拒绝或降权应能够给出可解释原因，策略冲突应有确定规则，关键策略应具备测试用例和变更审查。

9.3 持续验证必须覆盖访问中和行动后

传统认证在访问前完成。持续验证还应关注访问过程中的行为变化和行动结果。例如，用户在正常终端登录后突然进行大批量查询，应触发二次验证或限流；智能体获得工具权限后连续执行异常组合动作，应暂停并转人工；模型输出被业务系统采纳后，应记录最终结果和人工修改。

行动后验证尤其重要。某个动作在执行前看似低风险，但执行结果可能影响大量对象；某项模型建议被人工修改，也说明模型在该场景存在偏差。结果反馈应进入风险模型，形成后续策略调整依据。

9.4 持续评估不是维护一个永久“信任分”

跨域持续评估可以抽象为状态更新：

T(t+1) = G[T(t), I(t), B(t), R(t), E(t)]

其中，I(t)表示当前身份和委托状态，B(t)表示行为变化，R(t)表示资源、数据和模型风险，E(t)表示动作结果及其证据。这里的T不是对主体永久贴标签的单一分数，而是针对具体业务、对象和动作的可撤销判断。相同用户在同一时刻，对公开信息查询可能保持正常权限，对重要数据导出则可能被要求二次认证和审批。

持续评估系统必须说明信号来源、时效、缺失值处理、冲突规则和触发阈值。设备姿态过期、模型风险源不可用或行为基线尚未建立时，系统不应假装拥有完整判断。对于自动降权、会话中止和策略重算，还要记录触发信号、旧决定、新决定及其业务影响，使团队能够判断是风险收敛还是误阻断。

9.5 零信任建设应避免三个误区

第一，把零信任等同于采购某种访问代理。代理是执行点之一，不是完整架构。

第二，把“永不信任”理解为频繁打断业务。真正目标是基于上下文降低不必要摩擦，对高风险场景增加验证。

第三，只管理人员访问，不管理服务、API和智能体。未来最具规模的访问主体可能是非人身份。

十、安全运营：从告警中心到风险闭环和体系进化

10.1 一体化运营的目标是缩短风险暴露时间

安全运营不应以接入日志数量、产生告警数量或关闭工单数量作为主要成效。更有意义的指标包括：

• 关键对象发现时间；
• 高风险事件确认时间；
• 处置决策时间；
• 控制执行时间；
• 业务恢复时间；
• 根因确认率；
• 复发率；
• 控制有效性；
• 证据完整率。

图 12｜运营闭环以风险暴露时间为核心：更早发现、更快限制、更稳恢复、较少复发，并把验证结果转化为规则与架构更新。

10.2 运营闭环的六个阶段

• 感知：发现资产、身份、数据流、模型、配置和行为变化。
• 研判：进行关联分析、影响评估和因果假设，区分异常、风险和事件。
• 决策：明确责任主体、处置优先级、业务影响和可接受风险。
• 响应：执行阻断、隔离、降权、回滚、修复和恢复。
• 验证：复测控制是否生效，确认影响是否收敛，评估残余风险。
• 进化：更新规则、策略、架构、制度、培训和供应链要求。

缺少验证和进化，所谓闭环只是“工单关闭”。建议每个重大事件形成问题陈述、事实时间线、影响范围、根因、促成因素、控制失效点、处置效果、残余风险和改进责任清单。

10.3 事件研判要区分事实、推论和假设

安全报告常把工具告警直接写成攻击事实。高质量研判应分层表达：

• 已确认事实：由日志、流量、配置或测试直接证明；
• 合理推论：由多项证据支持，但仍可能有其他解释；
• 待验证假设：用于指导下一步调查；
• 未知事项：因证据缺失暂时无法判断。

这种分层既提高专业性，也避免错误归责和过度处置。重大事件报告还应列出证据缺口，明确哪些结论因日志缺失、时间不同步或第三方不提供证据而无法确认。

10.4 人工智能可以辅助运营，但不能替代证据

大模型可用于告警摘要、关联线索、查询生成和处置建议，但其结论必须回到原始证据验证。安全运营中的模型输出应标记来源、置信度和使用范围。重大事件定性、影响确认和责任判断不应仅依赖生成式模型。

对自动化研判模型，应监测误报、漏报、概念漂移和数据偏差。模型版本、规则版本和训练数据变化都应记录，以便解释为什么同一事件在不同时间得到不同结论。

10.5 运营组织应围绕能力而非产品分组

传统SOC常按设备或产品安排人员。更合理的方式是按能力和场景组织，包括：

• 资产与暴露面治理；
• 身份和权限治理；
• 数据安全运营；
• 云与云原生安全；
• API和应用安全；
• 终端与物联网安全；
• 模型和智能体安全；
• 威胁检测与事件响应；
• 控制验证和韧性演练。

这些能力可以由不同团队承担，但应使用统一对象、事件分级、工单和证据规范。

10.6 证据平面提高的是“可知性”，不能自动等同于事实真相

日志、流量、审计记录和模型轨迹都是系统对事件的观测，不是事件本身。传感器可能遗漏，时钟可能偏移，主体标识可能被冒用，应用日志可能只记录成功路径，供应商平台可能对内部处理不透明。即使所有记录都未被篡改，它们仍可能只呈现局部视角。

因此，证据分析必须同时处理三类不确定性：来源不确定性，即记录是否来自预期组件和真实运行实例；语义不确定性，即字段在不同系统中是否表达同一含义；覆盖不确定性，即未记录是否代表未发生。完整性校验主要解决“记录是否被改变”，不能解决“是否漏记”和“解释是否正确”。

重大判断应尽量采用独立来源交叉印证。例如，敏感数据导出不能只依据应用返回成功，还应关联数据网关记录、对象快照、终端落地或外发行为以及后续处置结果；智能体动作不能只依据模型轨迹，还应关联工具代理、目标系统和业务对象状态。若多个证据都源于同一上游组件，它们并不真正独立。

这要求证据平台保留反证能力：允许分析人员看到缺失字段、冲突记录、无法解释的时间间隔和替代假设，而不是只生成一条“最可能故事”。一体化分析的价值不在于消除不确定性，而在于使不确定性可见、可追问，并明确还需要什么证据才能升级结论。

十一、评价体系：以控制有效性和业务韧性衡量建设成效

11.1 五类核心指标

一体化安全评价可分为五类：

1. 覆盖性：关键业务、对象、身份、数据、模型和日志是否纳管；
2. 一致性：跨域对象、身份和策略是否使用共同语义；
3. 有效性：控制能否真实预防、发现、限制和恢复风险；
4. 闭环性：事件是否完成发现、处置、验证和改进；
5. 韧性：关键业务在攻击、故障和误操作下是否持续运行并恢复。

指标应避免只追求百分比。覆盖率达到较高水平，如果遗漏的恰好是关键业务或高权限身份，仍然存在重大风险。因此，应将对象重要性和风险权重纳入指标。

11.2 建设完成率不能代表能力形成度

应明确区分：

• 建设完成率：系统、接口和功能是否上线；
• 运行使用率：是否被业务和运营团队持续使用；
• 控制有效率：是否在测试和事件中证明有效；
• 风险收敛度：高风险暴露是否减少；
• 韧性水平：关键业务是否能够承受和恢复。

项目验收应至少包含功能验收、数据质量验收、控制测试、流程演练和证据核验。仅凭厂商演示不能证明能力形成。

11.3 建立控制有效性验证机制

控制有效性验证可采用：

• 配置审查；
• 自动化合规测试；
• 攻击模拟；
• 渗透测试；
• 数据访问回放；
• 策略单元测试；
• 故障演练；
• 智能体红队测试；
• 恢复演练；
• 证据抽样核验。

验证应针对具体控制目标，而非笼统证明“系统安全”。例如，验证“高风险终端无法导出敏感数据”“无权限用户无法通过RAG获得受限文档内容”“智能体无法绕过审批调用支付接口”。

11.4 成熟度模型

图 13｜成熟度由跨域协同和可验证性定义；每一级都必须通过证据门，不能以设备数量替代控制有效性。

成熟度可以分为五级：

• L1 分散建设：各域独立建设，只能看见局部；
• L2 统一纳管：资产、制度和日志开始统一；
• L3 策略协同：身份、数据和网络控制可以联动；
• L4 风险自适应：动态决策、自动编排和持续验证形成闭环；
• L5 韧性自治：具备预测、仿真、自愈和架构进化能力。

L5不意味着无人管理，而意味着系统能够在明确责任和边界下自动维持关键控制，并将重大不确定性及时升级给人。组织不应盲目追求最高等级，而应依据业务风险、资源和技术条件确定目标水平。

11.5 建议的关键绩效指标

可选取以下指标作为建设与运营的共同语言：

• 关键业务对象覆盖率；
• 对象责任明确率；
• 高权限机器身份短期凭据使用率；
• 敏感数据策略绑定率；
• 高风险API动作级授权覆盖率；
• 模型与知识库登记率；
• 关键日志字段完整率；
• 跨域事件自动关联率；
• 重大事件证据完整率；
• 控制验证通过率；
• 高风险问题平均暴露时长；
• 事件复发率；
• 关键业务恢复目标达成率；
• 例外策略按期关闭率；
• 供应链关键证据可获得率。

这些指标必须定义分母、口径、数据来源和责任人，否则容易被形式化。

11.6 把“能力形成”转化为可计算、可抽样、可复核的量

为了避免同一指标在不同汇报中改变口径，至少应固化四类基础计算。

控制覆盖率不是“已接入系统数/系统总数”，而应按风险权重计算：

Coverage = Σ(wᵢ × coveredᵢ) / Σwᵢ

其中，wᵢ来自业务影响、数据敏感度和动作风险。低风险对象的大量接入不能掩盖关键对象未覆盖。

证据完整率应以事件契约中的必需字段和关键链路为分母：

Completeness = 已满足的必需证据项 / 应满足的必需证据项

字段存在但为空、时间超出容差、主体无法解析或策略版本不可定位，都应计为缺失。重大事件还应单独计算从请求、决定、执行、结果到复盘的链路闭合率。

风险暴露时间应从风险达到可检测条件时起算，到有效控制完成且业务状态得到验证时结束，而不是在工单“关闭”时结束。恢复验证率则以已经通过独立业务校验的恢复对象为分子，避免把服务启动或备份还原误写成业务恢复。

所有指标都应保存数据来源、查询逻辑、样本范围、排除条件和责任人，并允许抽样回到原始证据。无法复算的漂亮百分比，不应进入验收结论。

十二、建设路线：以高风险业务链为切入点渐进实施

12.1 阶段一：摸清范围、对象、责任和基线

优先完成：

• 数字政府总体业务和技术架构梳理；
• 关键业务过程和数据流识别；
• 云数网端智对象清单及关系图谱；
• 数据分类分级和重要数据识别；
• 人员、机器和智能体身份盘点；
• 对外接口和高权限工具清单；
• 政策标准差距分析；
• 高风险场景和责任矩阵。

本阶段的验收成果不应只是台账，而应包括可验证的对象覆盖率、责任明确率和高风险问题清单。对于无法确认的对象和关系，应形成待办和责任人，不应人为填充“完整率”。

12.2 阶段二：建立统一控制与证据基础

重点建设：

• 统一身份和非人身份治理；
• 数据目录、分类分级和使用策略；
• 云配置、终端姿态和网络分区基线；
• API目录和认证授权规范；
• 模型、知识库和智能体注册管理；
• 日志字段、时间同步和证据关联规范；
• 关键策略和审批流程数字化；
• 供应链安全条款和证据要求。

本阶段应优先解决基础数据质量和接口问题。没有可靠对象、身份和日志，后续智能分析和自动化处置不会可靠。

12.3 阶段三：形成跨域策略和事件联动

实现：

• 设备风险驱动应用和数据访问限制；
• 数据等级驱动云存储、网络和导出策略；
• 身份异常驱动会话降权；
• 模型风险驱动知识库和工具权限调整；
• 智能体动作级授权；
• 跨域事件关联和自动化处置；
• 控制有效性持续验证。

联动建设应先从少量高价值场景开始，明确触发条件、执行动作、业务影响、回滚方式和验证标准。未经影子运行和测试，不宜直接大规模自动阻断。

12.4 阶段四：建设韧性和体系进化能力

进一步开展：

• 关键业务数字孪生与攻击仿真；
• 风险预测和异常机制识别；
• 自动化恢复和策略回滚；
• 智能体红队与安全评测；
• 供应链持续监测；
• 成熟度评估和架构迭代；
• 跨部门、跨区域协同演练。

图 14｜建设路线以对象与责任、通用控制、证据与验证、运营与韧性四条工作流协同推进，并以阶段门控制范围和承诺。

12.5 明确不应一次性完成的事项

一体化安全不是一次性“顶层设计＋平台采购”。以下目标不应被承诺为一次完成：

• 全量对象100%准确关联；
• 所有系统立即统一身份；
• 所有策略集中到单一引擎；
• 所有处置自动化；
• 所有模型输出绝对正确；
• 所有数据流完全可见；
• 所有风险可预测。

合理做法是明确优先范围、质量阈值、遗留风险和迭代机制。每个阶段都要定义“未完成状态”：哪些对象未纳管、哪些策略仍依赖人工、哪些证据仍缺失、哪些风险暂时接受，以及接受期限。

12.6 四个阶段必须由“证据门”连接，而不是由时间计划自动推进

建设路线不是四个按月份排列的采购包。上一阶段的关键假设没有得到证据支持，下一阶段的自动化和集中化只会放大错误。因此，每个阶段都应设置能够阻止项目虚假前进的证据门。

证据门一：范围闭合。 首批关键业务链的对象、责任、数据流和高风险动作能够被定位；未知对象和争议关系被显式登记。若关键主体或责任人仍不明确，不进入统一策略建设。

证据门二：控制可执行。 至少一组跨域控制使用真实对象和真实执行点完成端到端测试，策略版本、决定、义务、执行和结果能够关联。若只能演示控制台或模拟数据，不进入规模化联动。

证据门三：联动可恢复。 跨域策略经过影子运行、误报评估、故障注入、回滚和人工接管测试，业务影响处于可接受范围。若自动化只有成功路径，不进入高风险生产处置。

证据门四：能力可持续。 组织已经具备策略维护、证据质量监测、事件复盘、供应链变更评审和周期验证责任，关键指标能够从原始证据复算。若能力仍依赖项目组或厂商驻场的个人经验，只能视为项目能力，不能视为治理能力。

证据门不是为了拖慢建设，而是为了避免把范围不清、对象错误和不可恢复的控制带入更大范围。若某一阶段未通过，应缩小场景、修复基础事实或保留人工控制，而不是通过降低验收口径使路线图继续“变绿”。

十三、实施重点与失效模式

13.1 最常见的五种失效模式

失效模式一：把一体化等同于平台化。 结果是形成新的“大烟囱”，专业控制仍然割裂。

失效模式二：只做数据汇聚，不做对象语义。 日志量增加，但事件关联和责任定位仍依赖人工。

失效模式三：只做统一身份，不治理机器身份。 人员账号更规范，但服务账号、密钥和智能体权限成为新盲区。

失效模式四：只做AI内容过滤，不控制工具动作。 模型输出看似合规，但仍可通过高权限工具造成业务影响。

失效模式五：强调自动化，不设计回滚和人工接管。 错误策略和误判被快速放大。

此外还存在“指标替代目标”的风险：为了提高纳管率、闭环率或自动化率，团队可能将低价值对象纳入统计、快速关闭工单或自动执行低风险动作，却没有降低关键业务风险。指标必须服务于风险判断，而不能成为新的形式主义。

13.2 采购与合同应转向可验证交付

建设合同除功能要求外，应明确：

• 对象和接口开放要求；
• 日志字段和证据质量；
• 策略执行与反馈能力；
• 数据和模型变更通知；
• 漏洞和事件响应时限；
• 供应链组件清单；
• 模型和知识库版本管理；
• 退出、迁移和数据删除；
• 测试、演练和验收方法；
• 运行期服务和责任边界。

供应商声称“支持”某项能力，不应直接视为完成。必须通过配置、测试、日志和运行记录验证。对于无法开放接口、无法提供关键证据或高度绑定厂商的能力，应评估长期锁定风险。

13.3 数据和模型供应链需要统一管理

数据可能来自外部采购、共享交换、公开来源和业务采集；模型可能来自开源、商业服务、私有训练和第三方API。应建立供应链清单，记录来源、许可、版本、更新、依赖、已知风险和退出方案。

对模型更新，应重新评估能力变化、输出风险、数据使用和工具兼容性。不能假设同一模型名称的不同版本具有相同安全属性。模型供应商的安全承诺还应落实为可检查的部署方式、数据保留、日志、隔离、漏洞响应和退出机制。

13.4 安全组织需要从专业分工走向联合决策

云、网络、数据、终端和AI安全仍需专业团队，但重大策略应由跨职能机制决策。建议设立：

• 数字政府安全架构委员会；
• 数据与模型风险评审机制；
• 高风险动作授权机制；
• 重大事件联合研判机制；
• 供应链安全评审机制；
• 控制有效性审查机制。

联合决策不是增加会议，而是解决跨域责任无人承担的问题。每个机制应有明确触发条件、输入材料、决策权限、时限和记录要求。

13.5 架构复杂度本身也是风险

一体化容易引入大量接口、中间平台和策略依赖。若策略控制平面或对象图谱成为单点故障，可能影响大量业务。架构设计应考虑：

• 决策服务高可用；
• 本地策略缓存和安全降级；
• 控制平面与数据平面隔离；
• 关键策略的确定性；
• 接口限流和防重放；
• 数据最小化；
• 故障域隔离；
• 灾备和恢复；
• 变更回滚；
• 架构可观测性。

宏大的架构必须能够分解为可运行、可测试、可恢复的组件，否则宏大只会转化为复杂。

13.6 一体化本身可能制造新的系统性风险

一体化的收益来自共享对象、策略、证据和运营能力；其风险也来自同一机制。一条错误的统一标识映射可能把权限授予错误主体，一次策略发布可能同时影响多个域，一个受攻击的编排平台可能把合法控制能力变成横向操作工具，一套失真的全局指标可能使管理层同时误判多个部门。

因此，一体化架构需要反向回答四个问题。第一，中心组件被攻击后能够触达多少对象和执行点；第二，错误策略的最大爆炸半径是多少；第三，部门能否独立停止接收错误决定并切换到本地最小策略；第四，中心平台掌握的数据和能力是否超过其治理责任所必需。

控制这些风险不能只依靠加固中心平台，还要在架构上限制权力：策略编写、审批、发布和验证分离；高影响发布采用分批、金丝雀和自动回滚；执行点校验策略来源、版本、适用范围和有效期；跨域编排使用最小权限和短期凭据；对象图谱变更进入质量门和双向核验；中心平台只获取决策所需的最小上下文。

还应定期实施“错误中心”演练：故意下发冲突策略、注入错误对象关系、模拟策略签名失效、切断证据总线或让中心风险评分漂移，观察局部执行点能否拒绝异常输入、限制影响并恢复。只有能够约束自身权力的一体化，才不会从消除烟囱走向制造更大的单一故障域。

十四、前瞻判断：未来数字政府安全的五个演进方向

14.1 从身份治理走向“身份与能力治理”

未来重点不只是账号属于谁，而是主体具有什么能力、通过何种委托获得、可以执行何种动作。机器身份和智能体能力将成为治理重点。能力将被表达为可组合、可限制、可撤销的授权单元，而不是宽泛角色。

14.2 从数据访问控制走向“数据使用与派生控制”

数据进入模型、向量库、记忆和生成内容后，传统数据库权限无法覆盖。数据政策需要伴随数据及其派生物传播，并能够限制用途、输出和再共享。数据治理将更关注“使用后的结果”和“派生责任”。

14.3 从日志分析走向“可验证事件图谱”

安全证据将不再是孤立日志，而是包含主体、对象、动作、策略、结果和因果关系的事件图谱。事件调查和合规审计将更多依赖证据图，而非手工截图。可信时间、完整性和可复现性将成为重要基础能力。

14.4 从安全自动化走向“受控自治”

智能体可辅助监测、研判和响应，但必须处于动作授权、预算限制、回滚和人工接管机制之下。安全自治的前提是可验证控制，而不是模型能力更强。自治系统必须能够解释行动依据，并在不确定性过高时停止。

14.5 从静态合规走向“持续保证”

未来的安全评价将更加关注控制是否持续生效。架构、配置、数据、模型和业务变化都可能使原有评估结论失效。持续保证要求将测试、证据和风险更新嵌入日常运行。等保、密评、数据安全评估、个人信息保护和AI治理等专项工作，也将更需要共享持续证据。

十五、目标范式：建设可验证的数字政府安全治理操作系统

数字政府“云数网端智”一体化安全不是一个新产品类别，也不是对原有安全概念的重新包装。它源于数字政府运行机制的根本变化：资源高度云化，数据跨域流动，连接动态化，终端多样化，模型和智能体开始参与认知、决策与行动。传统分域控制仍然不可替代，但必须在统一对象、统一身份、统一策略、统一证据和统一运营层面形成协同。

本文提出的目标架构可以概括为：

• 以业务结果定义安全目标；
• 以统一对象模型连接云数网端智；
• 以策略控制平面实现动态、细粒度和跨域一致决策；
• 以证据平面证明控制执行和责任落实；
• 以动作级持续授权约束智能体；
• 以运营闭环推动规则、架构和制度持续进化；
• 以控制有效性和业务韧性评价建设成效。

图 15｜目标范式不是新的产品大类，而是以统一对象、统一策略、统一证据和持续保证为内核的安全治理操作系统。

“体系免疫”并不意味着系统不会遭受攻击、不会发生错误或不再需要人员参与。其更严格的含义是：体系能够持续发现自身状态变化，识别风险传播机制，在适当层级实施限制，证明控制真实发生，并将事件经验转化为新的规则和架构能力。

数字政府下一阶段的安全差距，不主要取决于部署了多少设备，而取决于能否回答并证明以下问题：

谁以何种身份，在何种业务目的和风险上下文下，通过何种终端与网络路径，访问了哪些数据，调用了哪个模型或工具，执行了什么动作，产生了什么结果；哪项策略作出了决定，哪一控制点执行了决定，证据是否完整，风险是否收敛，体系是否因此得到改进。

当这些问题能够被持续、准确和可验证地回答时，“云数网端智”才真正从五个建设领域转化为一体化安全能力。

十六、落地治理：把方法论转化为可执行的工程制度

16.1 建立“架构决策记录”而非只保留会议纪要

一体化安全建设涉及大量跨部门取舍，例如是否允许某类数据进入模型、某个智能体是否可以直接回写业务系统、统一策略服务故障时采用拒绝还是降级、跨部门接口的日志由谁保存。此类问题不能只在会议中形成口头共识，应建立架构决策记录，至少写明问题背景、候选方案、选择理由、反对意见、证据基础、适用边界、责任人、复审条件和失效触发器。

架构决策记录的价值在于保留当时的约束和假设。未来业务、法规、模型或供应商发生变化时，可以判断原决策是否仍然成立，而不是把既有设计当作永久事实。对于高风险决策，应设置定期复审日期；对于依赖暂时性补偿控制的例外，应明确到期和退出条件。

16.2 用“控制卡片”连接政策、工程和运营

建议将关键安全要求固化为标准化控制卡片。每张卡片至少包含：控制目标、风险场景、适用对象、责任主体、决策规则、执行点、输入数据、输出证据、测试方法、失败模式、例外流程和验证频率。

例如，“高风险终端不得导出敏感数据”这一控制，不能只写成制度条款。其输入包括终端姿态、用户身份、数据等级和导出动作；执行点可能位于终端、应用和数据网关；输出证据包括策略决定、拦截记录和用户提示；测试方法应覆盖受管终端、未受管终端、离线终端、批量导出和API绕过等场景。只有形成控制卡片，制度要求才能被工程实现、被运营验证、被审计复核。

16.3 以“场景包”组织跨域建设

大型一体化项目最容易因范围过大而失控。更可行的组织方式是构建场景包，每个场景包围绕一条关键业务链，包含对象模型、数据流、威胁模型、策略、执行点、证据、演练和指标。首批场景宜选择风险高、跨域明显、责任相对清晰且能够验证价值的业务，例如敏感数据跨部门共享、第三方远程运维、模型访问内部知识库、智能体调用高风险API和关键云资源暴露面变化。

场景包完成后，再把其中可复用的身份、策略、证据和编排能力沉淀为公共能力。这样形成的是“由场景验证公共能力”，而不是先建设一个抽象大平台，再寻找使用场景。

16.4 设定技术债和遗留风险台账

现实环境中不可能一次消除所有历史系统问题。部分老旧系统无法接入统一身份，部分设备无法提供完整日志，部分供应商无法开放策略接口。对此应建立技术债和遗留风险台账，记录风险描述、影响对象、临时补偿控制、责任人、计划期限和接受批准。

技术债不能被隐含在“后续优化”中。若某项缺陷使关键控制无法验证，应明确其阻断性质；若暂时接受风险，应说明接受依据和期限。通过台账，可以防止项目验收后遗留问题永久化，也可以为后续预算和改造提供证据。

16.5 建立独立验证与红队机制

控制的设计者和实施者不应是唯一验证者。建议对关键控制建立独立验证机制，由不直接负责开发和日常运维的团队执行配置审查、策略测试、攻击模拟、数据权限回放和智能体红队。验证结果应直接面向控制目标，而不是面向产品功能。

智能体红队尤其需要覆盖间接提示注入、恶意知识库文档、工具参数操纵、跨工具组合、记忆污染、权限继承和人工审批绕过。测试不仅要观察模型是否生成危险文本，还要验证外部执行点能否阻止危险动作。

16.6 将安全能力纳入业务上线门禁

一体化安全不能只在项目验收前集中检查。新系统、新接口、新数据共享、新模型和新智能体上线时，应进入统一门禁流程。门禁至少检查：对象是否登记、责任是否明确、数据是否分级、身份和权限是否设计、日志和证据是否满足要求、供应链是否可追溯、异常和恢复是否测试。

门禁不应成为简单的材料审批。对于低风险变更，可采用自动化规则快速通过；对于高风险业务，应进行架构评审和场景测试。上线后还应设置观察期，根据真实运行数据确认控制有效。

16.7 形成“年度评估＋持续监测＋事件触发复审”机制

年度评估可以提供总体状态，但不足以覆盖快速变化。建议形成三类互补机制：年度或周期性评估用于系统性检查；持续监测用于发现配置、身份、数据流和模型状态变化；事件触发复审用于在重大漏洞、数据用途变化、模型更新、供应商变更或安全事件后重新判断。

三者共同构成持续保证。其目标不是不断增加检查，而是让评估结论具有明确有效期和触发条件。当支撑结论的关键假设改变时，原结论自动进入待复审状态。

16.8 最终验收的最低判据

一体化安全项目只有在以下条件同时成立时，才可声明形成阶段性能力：关键对象和责任可定位，核心策略已经在真实执行点运行，策略决定与执行结果能够被证据关联，高风险场景完成独立测试，失败时存在安全降级与恢复方案，遗留问题已进入有期限的风险台账。缺少其中任何一项，都只能表述为“完成局部建设”或“具备试运行条件”，不能表述为体系已经建成。

十七、结语：把安全能力从“存在”变成“可证明”

数字政府安全建设的关键分水岭，不是专业控制是否齐全，而是这些控制能否在同一业务过程上协同作出正确决定，并留下足以复核的证据。统一对象解决“控制谁”，统一策略解决“如何决定”，统一证据解决“如何证明”，持续运营解决“如何在变化中保持有效”。四者缺一，所谓一体化都可能退化为资产汇总、告警汇聚或产品拼接。

因此，建设不应从“大平台蓝图”起步，而应从一条高风险、跨域、可验证的业务链起步：明确对象与责任，建立动作级策略，设计证据契约，执行真实场景测试，再把经验证的能力沉淀为公共组件。只有经得起失败注入、独立验证和事件复盘的控制，才应被计入体系能力。

“体系免疫”最终表达的不是绝对安全，而是一种可以持续感知变化、限制风险传播、证明控制有效并从事件中进化的治理能力。当这种能力能够被稳定复现，数字政府安全才真正从建设项目转化为长期运行机制。

参考文献

A. 法律、行政法规与部门规章

[1] 国务院. 《国务院关于加强数字政府建设的指导意见》, 国发〔2022〕14号, 2022.

[2] 国务院. 《网络数据安全管理条例》, 国务院令第790号, 2024，2025年1月1日起施行.

[3] 国家互联网信息办公室等. 《生成式人工智能服务管理暂行办法》, 2023.

[4] 国家互联网信息办公室、工业和信息化部、公安部、国家广播电视总局. 《人工智能生成合成内容标识办法》, 2025.

[5] 全国人民代表大会常务委员会. 《关于修改〈中华人民共和国网络安全法〉的决定》及修正文本, 2025年10月28日通过，2026年1月1日起施行.

[6] 全国人民代表大会常务委员会. 《中华人民共和国数据安全法》, 2021.

[7] 全国人民代表大会常务委员会. 《中华人民共和国个人信息保护法》, 2021.

[8] 国务院. 《关键信息基础设施安全保护条例》, 国务院令第745号, 2021.

[9] 国家互联网信息办公室. 《数据出境安全评估办法》, 2022.

[10] 国家互联网信息办公室. 《个人信息出境标准合同办法》, 2023.

[11] 国家互联网信息办公室. 《促进和规范数据跨境流动规定》, 2024.

[12] 国家互联网信息办公室等. 《互联网信息服务算法推荐管理规定》, 2021公布，2022年施行.

[13] 国家互联网信息办公室等. 《互联网信息服务深度合成管理规定》, 2022.

[14] 国家互联网信息办公室. 《个人信息保护合规审计管理办法》, 2025.

[15] 国务院. 《商用密码管理条例》, 国务院令第760号, 2023修订.

B. 数字政府、数据基础制度与公共数据政策

[16] 国务院办公厅. 《全国一体化政务大数据体系建设指南》, 2022.

[17] 中共中央、国务院. 《关于构建数据基础制度更好发挥数据要素作用的意见》, 2022.

[18] 中共中央、国务院. 《数字中国建设整体布局规划》, 2023.

[19] 国家数据局等. 《“数据要素×”三年行动计划（2024—2026年）》, 2023.

[20] 中共中央办公厅、国务院办公厅. 《关于加快公共数据资源开发利用的意见》, 2024.

[21] 国务院. 《政务信息资源共享管理暂行办法》, 国发〔2016〕51号, 2016.

[22] 国家发展改革委、国家数据局. 《公共数据资源登记管理暂行办法》；国家数据局. 《公共数据资源授权运营实施规范（试行）》, 2025.

[23] 国家数据局. 《可信数据空间发展行动计划（2024—2028年）》, 2024.

C. 国内国家标准与技术基线

[24] GB/T 22239—2019《信息安全技术 网络安全等级保护基本要求》.

[25] GB/T 25070—2019《信息安全技术 网络安全等级保护安全设计技术要求》.

[26] GB/T 28448—2019《信息安全技术 网络安全等级保护测评要求》.

[27] GB/T 28449—2018《信息安全技术 网络安全等级保护测评过程指南》.

[28] GB/T 20984—2022《信息安全技术 信息安全风险评估方法》.

[29] GB/T 20988—2025《网络安全技术 信息系统灾难恢复规范》, 2026年1月1日起实施；替代GB/T 20988—2007.

[30] GB/T 35273—2020《信息安全技术 个人信息安全规范》.

[31] GB/T 39335—2020《信息安全技术 个人信息安全影响评估指南》.

[32] GB/T 37964—2019《信息安全技术 个人信息去标识化指南》.

[33] GB/T 43697—2024《数据安全技术 数据分类分级规则》.

[34] GB/T 41479—2022《信息安全技术 网络数据处理安全要求》.

[35] GB/T 37973—2019《信息安全技术 大数据安全管理指南》.

[36] GB/T 35274—2023《数据安全技术 大数据服务安全能力要求》；替代GB/T 35274—2017.

[37] GB/T 31167—2023《信息安全技术 云计算服务安全指南》.

[38] GB/T 31168—2023《信息安全技术 云计算服务安全能力要求》.

[39] GB/T 39786—2021《信息安全技术 信息系统密码应用基本要求》.

[40] GB/T 32905—2016《信息安全技术 SM3密码杂凑算法》.

[41] GB/T 32907—2016《信息安全技术 SM4分组密码算法》.

[42] GB/T 32918（系列）《信息安全技术 SM2椭圆曲线公钥密码算法》.

[43] GB/T 42460—2023《信息安全技术 个人信息去标识化效果评估指南》.

[44] GB/T 42574—2023《信息安全技术 个人信息处理中告知和同意的实施指南》.

[45] GB/T 42888—2023《信息安全技术 机器学习算法安全评估规范》；GB 45438—2025《网络安全技术 人工智能生成合成内容标识方法》.

D. 国际标准与权威框架

[46] ISO/IEC. ISO/IEC 27001:2022, Information security management systems — Requirements, 2022；含Amendment 1:2024.

[47] ISO/IEC. ISO/IEC 27002:2022, Information security controls, 2022.

[48] ISO/IEC. ISO/IEC 27005:2022, Guidance on managing information security risks, 2022.

[49] ISO/IEC. ISO/IEC 27017:2015, Information security controls for cloud services, 2015；第二版在本文核验时处于出版流程，尚未以已发布版替代2015版.

[50] ISO/IEC. ISO/IEC 27018:2025, Guidelines for protection of PII in public clouds acting as PII processors, 2025.

[51] ISO/IEC. ISO/IEC 27701:2025, Privacy information management systems — Requirements and guidance, 2025；替代2019版.

[52] ISO/IEC. ISO/IEC 27035 series, Information security incident management.

[53] ISO. ISO 22301:2019, Business continuity management systems — Requirements, 2019；含Amendment 1:2024.

[54] ISO/IEC. ISO/IEC 23894:2023, Artificial intelligence — Guidance on risk management, 2023.

[55] ISO/IEC. ISO/IEC 42001:2023, Artificial intelligence — Management system, 2023.

[56] ISO/IEC. ISO/IEC 22989:2022, Artificial intelligence concepts and terminology, 2022.

[57] ISO/IEC. ISO/IEC 23053:2022, Framework for AI systems using machine learning, 2022.

[58] ISO/IEC. ISO/IEC 38507:2022, Governance implications of the use of artificial intelligence by organizations, 2022.

[59] ISO/IEC. ISO/IEC 5338:2023, AI system life cycle processes, 2023.

[60] NIST. Cybersecurity Framework 2.0, 2024.

[61] NIST. SP 800-207: Zero Trust Architecture, 2020.

[62] NIST. SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, 2020，含后续更新.

[63] NIST. AI 100-1: Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023.

[64] NIST. AI 600-1: Artificial Intelligence Risk Management Framework — Generative Artificial Intelligence Profile, 2024.

[65] NIST. SP 800-218: Secure Software Development Framework, 2022.

[66] CISA. Zero Trust Maturity Model, Version 2.0, 2023.

[67] Cloud Security Alliance. Cloud Controls Matrix, current release.

[68] Cloud Security Alliance. Security Guidance for Critical Areas of Focus in Cloud Computing, Version 5.

[69] ENISA. Cybersecurity of AI and Standardisation, 2023.

[70] OECD. Recommendation of the Council on Artificial Intelligence, OECD/LEGAL/0449，2019并经后续修订.

E. 云原生、供应链、身份与智能体安全参考

[71] CNCF TAG Security. Cloud Native Security Whitepaper, Version 2.

[72] OpenID Foundation. OpenID Connect Core 1.0 incorporating errata set 2.

[73] IETF. RFC 9700: Best Current Practice for OAuth 2.0 Security, BCP 240, 2025.

[74] SPIFFE. SPIFFE overview and workload identity specifications.

[75] SLSA. Supply-chain Levels for Software Artifacts, Specification v1.1.

[76] The Update Framework. The Update Framework Specification.

[77] in-toto. Software supply-chain integrity framework and specifications.

[78] MITRE. ATT&CK knowledge base.

[79] MITRE. ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems.

[80] OWASP GenAI Security Project. OWASP Top 10 for Large Language Model Applications, current release.

[81] OWASP GenAI Security Project. Agentic AI — Threats and Mitigations.

[82] Google. Secure AI Framework (SAIF).

[83] Microsoft. AI security in the Microsoft Zero Trust Workshop.

[84] AWS. Well-Architected Framework — Security Pillar；Generative AI Lens.

F. 引用与适用性说明

本文优先链接法律法规发布机关、全国标准信息公共服务平台、标准组织和框架维护机构的一手页面。标准与框架的版本状态以本文最后核验日（2026年7月13日）为准；在正式立项、招标、测评或公开发布前，仍应再次核验标准状态、实施日期、替代关系及具体适用范围。地方性法规、行业监管要求和本地制度不以泛化条目代替，应根据项目所属地区、行业、数据类型和业务责任另行建立适用性清单。