简介由全国数据标准化技术委员会发布的《可信数据空间 技术架构》规范文件面向从事数据基础设施建设、运营与管理的技术人员及相关管理人员为地方、行业、领域和企业开展可信数据空间规划、建设与运营提供权威指导。文档明确可信数据空间作为数据流通利用基础设施的定位围绕身份管理、接入连接器管理、目录管理、数字合约管理、数据使用控制等核心功能梳理服务平台与接入连接器、区域/行业功能节点的交互关系以及登记、发现、创建逻辑空间、数据流通利用等业务流程。针对跨企业、跨行业产业数据交换以及跨领域、跨学科科学数据共享分析场景文件给出数字合约、数据产品和空间运行的安全要求有助于构建安全可信的数据共享生态。资源为单份PDF文档压缩包共1个文件、约1.74MB目录清晰适合作为可信数据空间架构设计与数据基础设施建设的直接参考。目前已有260人浏览学习。1. 可信数据空间技术架构先想清楚它解决的痛点是什么现实中一个常见场景某供应链平台需要向银行提供上下游企业的真实经营数据来做融资风控但数据源企业不敢把核心系统数据直接给出去银行也不敢相信平台转交的截图和 PDF。传统接口能传数据却传不了信任——数据交出去了无法控制用途拿到数据的人无法证明其来源和真实性出了问题说不清责任。可信数据空间正是为解决这类“跨主体、跨系统、不可控”的数据流通难题而生它要构建的是一个各方规则互认、权责清晰、行为可证、全程可追溯的流通利用生态让数据像在可信生态系统中按合约流动而不是靠信任对方人品来完成交易。它既不替代数据仓库也不是新的大数据平台而是一层解决“可信”问题的流通基础设施。2. 可信数据空间的架构内核把“可信”拆成可落地的六层组件2.1 可信数据空间与数据交易所、API 管道的本质区别很多团队第一次接触可信数据空间会自然地拿它与数据交易所、API 网关做对比。数据交易所核心解决“确权与交易撮合”问题把数据像商品一样挂牌、竞价、交割API 网关解决“系统间调用与鉴权”问题强调连接和转发。可信数据空间解决的则是“流通全程的可信与控制”问题它不只关心一次请求是否鉴权通过还关心数据被用什么、用多久、用完能否删除、违约时能否举证。三个概念不应混用一个可信数据空间内完全可以内嵌 API 能力也可以与数据交易所对接。常见做法是把它理解为“数据流通的运营环境”提供参与方身份互认、数据资源描述、使用控制策略、可信执行、过程存证、争议仲裁这六个核心域。其中任意一个域缺失国绕“可信”的闭环就断掉了。对比项数据交易所API 网关可信数据空间核心问题确权与撮合连接与鉴权流通过程的可信与控制信任保障交易合规背书传输凭证身份互认策略执行全程存证数据控制粒度粗粒度中粒度细粒度到字段与用途事后追溯弱弱强支持举证定位交易场所技术通道流通基础设施2.2 参与方身份与信任锚数据空间里的“可信”由谁背书可信数据空间要做的第一件事是让每个参与方都有一份可验证、可吊销的身份凭证。数据提供方、消费方、运营方、监管方都会申请属于自己的数字证书证书由空间内的根信任锚统一签发和背书。信任锚是整个体系最底层的那把钥匙它决定了谁有资格进入这个生态。落地时信任锚往往由一个中立运营主体承担。参与方身份信息经过主体审核后签发证书证书包含参与方编码、角色、公钥信息、有效期。每个参与者持有的证书都是其数据行为的身份基础后续的接口调用、策略协商、日志上报都基于该凭证做签名和加密。这个设计的价值在于信任不用逐对建立。数据提供方不需要单独和几十个消费方做安全协议对接只要大家都信任同一个信任锚彼此通过验证对方证书链就能确认身份合法。这也是“可信生态”的真正含义中心化背书、去中心化协作。2.3 数据资源目录与数据模型流通的是描述而不是文件拷贝明确了参与方身份只是第一步下一步是让数据提供方能够把自己的数据“说清楚”。可信数据空间内流通的不再是原始文件而是数据的描述信息加受控的访问能力数据资源在数据源侧物理保留。数据目录负责登记这些描述数据集名称、结构、更新频率、字段字典、样本数据、使用条件、计费方式、数据质量等级。这一设计解决了两个现实问题。第一数据提供方不必把数据搬到某个中心仓库避免了“数据离域”的心理障碍和安全风险第二消费方在授权前就能通过目录了解数据的基本情况减少盲目申请。数据模型则负责明确这些描述信息的语义规范。同一字段在不同企业里有不同叫法若没有统一模型目录信息仍难以被人和机器理解。常见做法是先产出核心实体模型如企业、个人、订单、信用记录等再让数据提供方按模型映射自身字段。实践中的一个注意点目录不等同于数据中台的元数据管理。元数据管理面向企业内部的数据资产盘点目录面向跨组织的数据发现与共享契约因此目录中的信息需要更偏业务化和市场化——消费方关心的是数据是否新鲜、覆盖多少主体、字段是否可对齐这些都应体现在目录条目上。2.4 连接器与数据使用控制策略可信边界的最后防线数据资源放入目录并经授权后真正发生数据交换的是连接器。连接器部署在数据提供方和消费方两侧由提供方侧连接器控制数据出域由消费方侧连接器保证数据按合约被使用。可信控制的关键是策略它描述“谁可以在什么条件下、以什么用途、在多长时间内使用哪些数据”。常见策略模型会把约束拆成五类主体约束、目的约束、时间约束、次数约束、范围约束。一份典型的策略文件可能包含policy { policyId: P20250601001, providerId: provider_A, consumerId: consumer_B, dataResourceId: DS_ORDER_2025, constraints: [ {type: purpose, value: loan_risk_control}, {type: time, from: 2025-06-01T00:00:00Z, to: 2025-12-31T23:59:59Z}, {type: frequency, value: 3, unit: day}, {type: fieldMask, fields: [order_amount, repay_status]}, {type: dataExpiry, mode: delete_after, duration: 30d}, {type: consumerAudit, value: True} ] }这段策略定义了三个技术要点。其一消费方 B 只能把订单数据用于“贷款风控”这是目的约束防止数据被挪作他用其二有效期和调用频率共同限制使用窗口每天最多调 3 次其三字段掩码和数据过期时间实现精细化脱敏与生命周期管理消费到期后数据在消费侧必须删除。策略执行后剩余的信任问题就是消费方有没有在环境里篡改策略或绕过执行。因此可信数据空间通常配合可信执行环境或数据沙箱来加固消费方侧让数据处理活动发生在可验证的受控环境中。早期试点不必强制上机密计算但至少要保证策略引擎运行在独立的服务进程里并具备防篡改日志。2.5 存证、审计与争议仲裁事后可追溯才算真正闭环可信不能只做在事前和事中一旦数据已经流通总要面对“万一发生争议如何取证”的挑战。可信数据空间会在交换的关键节点上产生存证信息包括策略协商记录、数据请求记录、策略执行结果、数据使用方上报的处理摘要、数据删除报告等。这些记录经过签名后形成不可篡改的审计链。常见做法是将存证哈希同步写入区块链系统或具备司法效力的存证服务。不必把所有原始数据上链只要把存证摘要和时间戳上链即可原始日志由运营方数据库保存事后争议时用摘要哈希校验数据库记录是否完整。数据使用方也应有一种机制来证明自己“确实在按策略用数据”这就是使用回报它把消费方的处理过程定期汇总给提供方存证让数据出域后的行为对提供方保持透明。2.6 从单域到跨域可信数据空间互联的技术承接当多个可信数据空间各自建成后新的需求出现了一个空间里的数据提供方如何被另一个空间里的消费方发现和使用。这就进入空间互联问题。跨空间互联不能简单把两套证书体系打通就完事还涉及目录互操作、策略互认和存证互通。常见的技术方案是建立空间间的信任背书关系由上一级或第三方信任锚进行跨域身份背书目录通过镜像或联邦查询实现跨域发现策略互认则意味着双方空间需要统一策略语法或至少支持翻译转换。一个务实的做法是先以“跨空间查询目录”为试点再逐步开放跨空间数据调用不要一开始就追求所有策略语义完全对齐。国内相关可信数据空间建设指南对互联架构已有描述跨域互认机制目前仍有不少细节依赖各方既有的行业规范实施时要依据实际对接方来收敛。3. 从零跑通一个最小可信数据空间实施路径与配置参考3.1 最小落地尚需哪几个角色与组件评估一个可信数据空间项目是否具备实施条件先看角色是否齐备。最小可运行的空间必须包含四类角色运营方负责信任锚、目录服务和存证服务的运行维护数据提供方提供数据资源并部署连接器数据消费方申请数据并在自身侧部署消费端组件监管方具备查看审计日志权限。许多试点项目会忽略监管方角色导致审计数据无人使用。即使刚开始监管方并不活跃也应当在架构中预留其访问通道。组件方面最小集合需要一个身份认证服务、一个数据目录服务、一套策略管理服务、一个存证服务以及两侧的连接器。把这些组件全部部署在同一个 Kubernetes 集群或传统虚机环境均可初期不必追求全面容器化。3.2 数据资源盘点、分级与接口改造最先做的往往是脏活接入可信数据空间最耗费精力的不是搭建组件而是把数据资源的家底盘清楚。一个数据提供方可能有几十个库表但真正值得拿出来共享的往往只有少数高价值数据集。盘点阶段要回答四个问题库表里有多少敏感字段水能否开放原样数据数据更新频率是多少是否适合做实时接口数据能否按消费方维度做行级过滤或字段脱敏数据质量是否稳定能否支撑签约承诺。数据分级强烈建议直接参考行业通用分类无条件开放、有条件开放、协议共享、禁止开放。可信数据空间的定位决定了它主要处理前三级。接口改造是有条件开放和协议共享数据的主要工作量。常见做法是在原系统服务外增加一层数据服务接口让数据空间连接器通过该接口取得数据。接口设计要以最小开放为原则只暴露所需字段并配合参数化条件查询防大表全量扫描。3.3 用连接器接入一个数据服务典型配置示例连接器是每次数据交换的必经之路。下面给出一份偏服务端的数据提供方连接器配置模板connector: id: provider-connector-01 role: provider trustAnchor: https://ta.xxx-space.cn/ca identity: certFile: /etc/dspace/certs/provider-a.pem keyFile: /etc/dspace/certs/provider-a-key.pem catalog: enabled: true publishUrl: https://catalog.xxx-space.cn/resources resource: id: DS_ORDER_2025 name: 订单流水脱敏集 visibility: restricted contact: style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />