简介由全国数据标准化技术委员会发布的可信数据空间技术架构技术文件定位为国家数据基础设施中的关键组成部分面向数据基础设施规划、建设、运营及管理人员指导地方、行业、领域、企业开展可信数据空间的建设与运营。文档以PDF格式提供共1个文件压缩包约1.74MB清晰呈现术语定义、功能架构、交互关系、核心业务流程及安全要求等模块。已有260人学习下载适合关注数据要素流通与跨域共享的从业者深入学习。内容重点阐释数字合约管理、数据使用控制、身份管理、接入连接器管理等核心功能并针对数字合约、数据产品、空间运行提出安全要求结合国家区块链网络实现区块链互通为跨企业产业数据交换协同、跨学科科学数据共享分析等场景给出可落地的技术框架有助于读者理解从登记、发现到创建逻辑空间及数据流通利用的完整链路。1. 可信数据空间一份数据流通基础设施架构标准的工程解读做跨企业数据协同的人多半都有过这种体验数据提供方怕数据被拿去乱用使用方又怕拿到的是残缺数据双方私下签了一摞协议出了事照样扯不清。可信数据空间这类基础设施就是为了把“信任”从合同文本变成技术可验证的约束。它是一套以数字合约和使用控制为核心的数据流通利用基础设施由数据标准化归口单位发布技术文件 TC609-6-2025-01明确了服务平台加接入连接器的基本组成以及登记、发现、创建、流通四个关键业务流程。这份架构标准适合正在规划或建设数据基础设施的技术负责人、平台架构师和运营管理者解决的是多方数据共享时“如何保证数据按约定使用”的落地问题。简单说它给“数据可信流通”画了一张可施工的图纸而不是停留在概念层面。2. 可信数据空间的整体架构服务平台与接入连接器的功能边界读这份标准时我最大的感受是它把“可信数据空间”描述得很克制不搞一套新概念体系而是把自己定位成国家数据基础设施里的一个业务节点继承数据基础设施参考架构的基本约束再结合自身特征做功能扩展。这样设计有个好处所有建设经验都能复用既有数据基础设施的成果不必从零起步。从物理组成看一套可信数据空间系统只有两类必选实体可信数据空间服务平台和接入连接器。服务平台支撑运营方管理整个空间连接器是参与方进入空间的入口。逻辑上一个服务平台可以支撑多个逻辑可信数据空间每个逻辑空间有自己独立的参与主体、资源目录和共识规则。2.1 服务平台7个必备功能与按需扩展模块服务平台在架构里是“承上启下”的位置——向上对接区域/行业功能节点向下管理接入连接器。标准给它规定了7个必备功能模块身份管理、接入连接器管理、目录管理、数字合约管理、可信数据空间管理、数据使用控制以及可选的国际空间互通网关。这里有几个容易被低估的点。身份管理不是简单的登录认证而是要和区域/行业功能节点打通支持代理注册、跨域身份互认。接入连接器管理除了注册注销还包含运行监测和能力适配能力适配是后续合约执行不翻车的关键。目录管理要区分数据产品登记和服务目录登记行为发生在功能节点层上架行为才发生在可信数据空间层。平台还可以按需复用或集成数据交易、开发应用中心、数据托管、存证审计等模块。标准里给出了一个功能集合我整理了一下功能模块必备/可选核心职责身份管理必备身份注册、认证、更新、注销接入连接器管理必备连接器注册/注销、认证、运行监测、能力适配目录管理必备产品登记、产品目录、使用申请、服务目录数字合约管理必备策略模板、合约签署、备案、解除可信数据空间管理必备逻辑空间创建/删除、配置修改、成员管理、运行监测数据使用控制必备数据使用环境、控制策略执行、使用存证国际空间互通网关可选跨国际数据空间数据流通数据交易按需数据市场、需求中心、计量计费、交易订单开发应用中心按需数据治理、数据开发、工具支撑、应用承载数据托管按需托管环境、产品授权、代理交付、代理记录存证审计按需日志存证、日志查验、审计追溯、日志上报实际建设时我一般建议先把7个必备模块做成“最小可用版本”尤其是数字合约管理和数据使用控制这两个是可信数据空间的灵魂不能为了赶进度先砍掉。交易、托管这类模块可以后补因为标准里写了“宜按需复用其他业务节点的功能”你不做可以对接已有的交易平台。2.2 接入连接器5项功能扩展与数据入口定位连接器是容易被做成“又一个网关”的组件。标准里它承担的任务比网关重得多它既是数据提供方接入本地数据系统的入口也是数据使用方运行算法和应用的环境还是数字合约执行使用控制的载体。它不只是转发请求而是要能执行策略。接入连接器在基础身份管理之外需要扩展5项功能数据资源管理、数据产品管理、数字合约管理、数据交付、数据使用控制。注意这里没有把身份管理算进扩展项因为连接器本身必须具备用户身份管理和连接器身份管理能力这是底线不需要额外强调。数据资源管理解决的是“本地数据怎么进连接器”——支持对象存储、数据库、本地文件服务器等多样化接入。数据产品管理解决的是“资源怎么变成可流通的产品”——基于已接入数据资源封装配置使用策略和交付前预处理策略然后上架。数据交付解决的是“数据怎么给到使用方”——可以交付原始数据、脱敏后数据也可以交付计算结果。数据使用控制解决的是“使用方拿到数据后能做什么、不能做什么”。连接器的能力适配是个容易忽略的关键动作。同一个连接器可以加入多个逻辑可信数据空间但每个空间对数据资源管理、产品管理、合约管理、使用控制的要求可能不一样。服务平台在做能力适配时不能只做一次配置就认为“这个连接器所有策略都能执行”而是要把每个逻辑空间支持的策略模板和连接器实际能力做一次核对。2.3 服务平台、连接器与功能节点三者如何协同理解交互关系是看明白这份文档的另一个关键。标准用“三统一”把关系串了起来统一目录标识、统一身份登记、统一接口要求。服务平台和连接器加入数据基础设施时身份、标识、目录必须和区域/行业功能节点互通。具体交互上用户通过数据基础设施公共服务发现全域的可信数据空间以及数据产品、数据服务。发现动作发生在功能节点层不在空间内部完成。数据使用方发现某个数据产品后按该空间的业务规则申请加入签约时由服务平台向双方连接器下发控制指令。连接器之间可以直接传输数据但控制指令和存证上报都要经由服务平台和功能节点。还有一点容易被忽视数据服务方的角色是动态的——它对原始数据提供方来说是使用方对最终数据使用方来说是提供方。这意味着服务方接入连接器时连接器既要具备数据交付能力也要具备数据使用控制能力两头都得顾全。3. 数字合约与使用控制可信机制的技术内核可信数据空间里的“可信”二字不是一句口号而是由两个技术支柱撑起来的数字合约表达“预期”使用控制保证“符合预期”。前者把数据内容、使用者、使用方式、使用次数、使用范围、使用环境等写成一纸数字化承诺后者在数据的传输、存储、使用和销毁环节通过技术手段做约束。两者缺一不可没有数字合约使用控制没有依据没有使用控制数字合约就是一张废纸。3.1 数字合约从策略模板到签约备案的完整链路数字合约本质上是对数据的流通和使用行为做“预期管理”。标准里给了服务平台一套最核心的能力策略模板、合约签署、合约备案、合约解除。策略模板是降低签约成本的工具。数据提供方不必每次协商都从头逐条写约束而是从模板里选一个或多个策略组合。模板里的策略至少包括11种限定数据产品内容、限定交付连接器、限定使用连接器、限定使用者、限定使用操作、限定使用次数、限定使用时长、限定可见范围、限定可用范围、使用时通知、使用后销毁。不同逻辑可信数据空间可以根据行业特征定义自己的模板组合——医疗空间和供应链空间的侧重点必然不同。签约流程在实际工程里往往不是一次完成的。数据使用方通过连接器发出使用申请基于数据产品要求和服务平台提供的模板创建合约双方可以多轮协商协商完成即签订。合约签订后服务平台要按数据交易控制指令流程向数据提供方和使用方连接器下发策略。这一段流程在标准里写得比较简略但实际开发时控制指令的下发格式、失败重试机制、连接器回执确认都是要反复打磨的地方。合约解除也值得留意。标准要求在解除后终止相关连接器上的合约履行并在备案模块里标记解除信息。我遇到过一种情况合约解除了但连接器侧的策略缓存没清掉数据提供方仍然能看到使用方在继续访问。这个细节在联调时要专门测。3.2 使用控制数据使用环境、策略执行与存证审计使用控制要管住的是“数据被使用的那一刻”。标准强调控制机制要集成在数据应用、算法和运行环境中确保参与方按照数字合约约定的策略对数据进行分析、计算和处理。数据使用环境是使用控制的前提。连接器要提供一个软硬件环境让使用方按照合约要求通过算法和应用使用数据产品。这个环境可以集成隐私保护计算、数据沙箱、数据匿名化、智能合约等增强技术。实际建设时我见过很多方案把力量全花在“数据交付加密”上却忽略了“使用过程可控”——数据到了使用方环境里能否限制他只跑指定算法、只查指定字段才是使用控制的难点。控制策略执行要求连接器与数据使用环境联动对使用行为做实时监测与控制。这里的“实时”是个玄学词真正做到需要定义清楚监测粒度是按请求级做拦截还是按会话级做审计标准里没有展开但工程上必须自己做取舍。我一般建议在请求入口做策略校验在数据访问层做行为拦截两者配合。使用存证要求连接器将数据使用过程日志做细粒度存证并上报到服务平台存证审计系统。细粒度三个字很容易被忽略很多实现只记录了“谁在什么时间用了哪个产品”连执行了哪条查询都没记。等到审计追溯的时候只能看出大概行为看不出是否符合合约。这个问题在第5章避坑里会专门展开。3.3 关键参数11种使用控制策略怎么落成配置标准列的11种策略让很多研发团队不知道怎么落地。实际工程里这些策略最终都会变成合约对象里的一个策略字段集合。我习惯把策略参数设计成一张对照表研发照着表去开发策略类型含义典型配置参数配置示例限定数据产品内容限定可用的数据范围product_id、field_listDP-2025-P0001仅用户表限定交付连接器数据只能交付给指定连接器allowed_delivery_connectorsCONN-B-002限定使用连接器只能在指定连接器上使用数据allowed_usage_connectorsCONN-B-002限定使用者允许使用数据的主体allowed_usersUSER-001限定使用操作允许执行的操作类型allowed_operationsquery、compute限定使用次数最多可使用次数max_usage_count3限定使用时长可使用的起止时间validity_start、validity_end2025-05-01T00:00:00Z限定可见范围数据对哪些主体可见visible_toSPACE-MED-01限定可用范围数据可被使用的计算环境范围allowed_runtimecluster-id-01使用时通知触发使用行为时通知相关方notify_to回调地址、webhook使用后销毁使用结束后销毁数据副本destroy_after_usetrue/false基于这张表一个典型的数字合约配置可以写成这样{ digital_contract: { contract_id: TDS-2025-C0001, data_product_id: DP-2025-P0001, provider_connector_id: CONN-A-001, consumer_connector_id: CONN-B-002, policies: { allowed_users: [USER-001], allowed_operations: [query, compute], max_usage_count: 3, validity_period: { start: 2025-05-01T00:00:00Z, end: 2025-05-31T23:59:59Z }, visibility_scope: [SPACE-MED-01], destroy_after_use: true } } }这段配置的逻辑很直白允许指定用户在一个月内对该产品执行查询和计算最多3次使用范围限定在特定逻辑空间使用后必须销毁副本。注意max_usage_count和destroy_after_use是组合使用的——没有销毁策略的次数限制存在被绕过风险没有次数限制的销毁策略又会让审计无据可依。选策略时不要单点考虑要把整个合约当成一个整体来设计。4. 业务流程实操拆解登记、发现、创建、流通四步闭环标准把业务流程归纳为四步登记可信数据空间、发现可信数据空间、创建逻辑可信数据空间、数据流通利用。这四步不是枯燥的流程罗列而是从建设方视角到使用方视角的完整闭环。落地上我给团队培训时会把每一步拆成“谁、做什么、依赖什么、产出什么”。4.1 登记与发现接入数据基础设施的第一步登记环节的参与方包括可信数据空间运营方、用户、连接器、数据产品和数据服务。这里有个容易混淆的点登记动作发生在服务平台和区域/行业功能节点之间而不是只在空间内部完成。创建可信数据空间时要按业务节点登记流程上报基本信息用户身份可以由服务平台代理注册也可以用区域/行业功能节点里已有的身份直接登录连接器同理新连接器注册分配身份老连接器直接申请加入数据产品则先在功能节点完成登记拿到唯一标识再在空间内上架。整个登记过程的产物如下表参与方动作依赖组件产物可信数据空间运营方创建空间并登记服务平台、区域/行业功能节点空间唯一标识用户注册或已有身份登录服务平台身份管理、功能节点数字身份连接器注册连接器或申请加入服务平台连接器管理连接器身份信息数据提供方登记数据产品目录管理、功能节点数据产品唯一标识数据服务方发布数据服务目录管理服务目录记录发现环节强调的是“全局视角”。用户通过数据基础设施公共服务能够发现全域的可信数据空间、数据产品和服务而不是只看到某一个空间内部的自建目录。这意味着服务平台与功能节点之间的目录同步不能滞后太久。我见过有团队用T1同步目录结果数据产品在功能节点已经登记完了空间侧三天后才看到。做数据基础设施时效性就是可用性目录同步至少要支撑准实时增量同步。4.2 创建逻辑可信数据空间成员、资源、策略的绑定创建逻辑可信数据空间是这套架构里最体现“逻辑”二字的地方。物理上一套平台可以支撑多个空间每个空间由限定的参与主体、数据资源和共识规则构成。比如一个医疗数据空间参与方是医院、药物研发方、医学研究方一个供应链数据空间参与方是链上的上下游企业。两者共用同一套服务平台但互不可见。创建动作由运营方发起调用可信数据空间管理模块创建空间配置名称、描述、支持的使用控制策略然后按照业务节点登记流程上报基本信息。之后是成员管理数据使用方、提供方、服务方先申请加入审批通过后授予资源访问权限。最后是运行监测服务平台将空间运行信息和业务信息上报功能节点。这个环节的关键不在创建本身而在“共享基础设施上的逻辑隔离”。多个逻辑空间共用一套平台和连接器隔离必须落实在后端鉴权逻辑里。数据产品的元数据要带可见空间列表查询时必须按空间过滤不能只在前端做菜单隐藏。这个问题我在第5章里还要集中说一次它是实际项目里最高发的越权漏洞。4.3 数据流通利用从合约签订到交付与使用的完整链路数据流通利用环节是把前面所有设计落到业务价值的地方。标准里描述的完整链路是数据使用方通过连接器向数据产品发出使用申请服务平台基于策略模板创建数字合约双方多轮协商协商完成即签订合约平台向双方连接器下发控制指令提供方连接器按合约对数据产品做交付前处理可以交付原始数据、脱敏数据或通过隐私保护计算、数据沙箱交付计算结果数据传到使用方连接器后使用方在使用环境中按照合约调用使用过程日志细粒度存证并上报。这一步的实际工作流我一般建议用状态机来管理申请中、协商中、已签订、交付中、使用中、已终止。每个状态迁移都触发相应的事件比如“已签订”要触发控制指令下发“使用中”要触发存证日志上报。状态机的好处是结算方便——每次合约签订和履行情况都可以作为计量计费的依据。这里的血泪经验是交付前处理不能只做“一次性脱敏”。合约里如果限制了使用次数和使用时长那么数据交付后使用方连接器必须在每次访问时重新校验策略状态。数据到了使用方手里提供方已经管不住了能不能管住全看使用方连接器的控制策略执行模块是否可靠。5. 落地避坑指南身份对接、目录同步、策略匹配的5个真实问题5.1 身份注册“代理”模式与原有身份系统的冲突现象新用户通过服务平台代理注册后在原有业务系统里没有对应身份老用户用区域/行业功能节点已注册身份登录时平台无法完成本地映射导致用户反复登录失败。原因服务平台代理功能节点的身份服务但本地身份体系和数据基础设施数字身份之间没有做绑定关系。常见做法是用手机号或邮箱当主键结果一个用户在不同业务里注册了不同账号身份对不上。解决上线前必须梳理身份映射表明确外部主键。我一般会让研发把用户唯一标识绑定关系落到独立字段老用户首次登录强制走一次身份绑定流程。注销本地身份时不影响全局数字身份——这个边界要在代码里写清楚不能把功能节点侧的身份也一起删了。5.2 数据目录只同步不校验跨空间检索不到产品现象数据产品在本空间数据产品目录里能正常查到但通过区域/行业功能节点查其他空间资源时搜不到。原因数据产品在功能节点登记时元数据不规范分类分级、适用场景、数据类型、使用策略等标签缺失或填写错误。另一个常见原因是只做了首次同步产品后续变更没有重新上报功能节点侧信息过期。解决在登记和上架环节把元数据校验做成强制项缺分类分级就拦截。补一个目录巡检任务每半小时比对一次本空间目录和功能节点目录的记录数与状态发现不一致自动重推。从那时起我再也没让团队依赖人工手工同步目录全部改成定时任务自动对账。5.3 策略模板与连接器能力不匹配合约履行时翻车现象数字合约里选了“使用后销毁”策略使用方连接器根本没有销毁模块策略静默失败数据副本一直留在使用方环境里。原因服务平台提供了丰富的策略模板但连接器能力适配没有覆盖全部策略。很多团队验证连接器时只测了连接、认证、基础数据收发没逐项核对策略执行能力。解决做一个能力矩阵表每个连接器加入空间前逐项核对它能支持的策略类型。策略下发时连接器返回“不支持”状态平台必须给出明确错误提示不能静默丢弃。签约前强制校验连接器能力集能力不足直接阻断签约流程把问题拦在签约前。5.4 存证日志粒度太粗审计溯源追不到具体行为现象事后审计时只能查到“某用户在某个时间段用了某数据产品”查不到具体操作了哪条记录、跑了什么算法、输出了什么结果。原因标准要求细粒度日志但连接器实现时只记录了基础访问日志没有记录数据请求参数、算法信息、输出结果摘要和用户操作上下文。解决在连接器里做两层日志访问日志记录时间、用户、产品、操作类型执行日志记录数据请求的具体条件、涉及数据量、算法名称、输出摘要。两层日志用同一个关联ID串起来再通过哈希链或区块链存证防篡改。上报给存证审计系统的报文包含这个关联ID审计时才能回溯完整链路。5.5 逻辑可信数据空间与物理平台边界混淆权限失控现象多个逻辑空间共用一套服务平台管理员以为空间做了隔离结果非本空间成员通过连接器直连的方式访问到了其他空间的数据产品。原因逻辑空间是生态关系集合不是物理隔离边界。物理上大家共享同一套平台和连接器如果权限模型只按空间ID做前端过滤后端接口没有空间维度鉴权就会出现越权访问。解决在服务接口层每个数据产品和服务的元数据都带“可见空间列表”查询时后端严格按空间过滤前端展示层不做可信判断。逻辑空间之间做目录隔离但共享的公共产品可以根据策略模板开放。权限粒度细化到数据产品和服务级别不能只到空间级别。注意逻辑可信数据空间是“逻辑”隔离不是“物理”隔离。设计权限模型时默认前提是同一个物理实例上所有代码路径都可能被访问必须在最底层接口做空间维度校验不能依赖上层逻辑。6. 进阶技巧最小功能自检清单与互操作测试设计6.1 最小功能自检清单标准明确了可信数据空间的最小功能集合但没有给你一张现成的验收表。我一般习惯按平台侧和连接器侧分开做自检。平台侧覆盖身份管理四项、连接器管理四项、目录管理四项、合约管理四项、空间管理四项、使用控制三项、存证审计四项。连接器侧覆盖身份管理三项、资源管理三项、产品管理三项、合约管理三项、交付三项、使用控制三项。功能“都有”还不够关键是能串起来。我常用的验收方式是跑一个最小闭环注册用户、注册连接器、登记数据产品、上架产品、发起使用申请、签订合约、交付数据、使用产品、上报存证日志。全链路跑通才算具备基本可用性。6.2 互操作测试设计互操作测试有两个层面一是平台与区域/行业功能节点之间二是连接器与服务平台之间。第一层测试用“三统一”作为断言统一目录标识产品登记后拿到的标识能在功能节点查询到统一身份登记用户身份在功能节点全局唯一且可认证统一接口目录上报、状态上报、控制指令的报文格式符合规范字段要求。第二层测试重点放在数字合约执行控制。我习惯设计一套用例把使用次数设为3次第4次访问必须被拒绝把使用时长设为10分钟超时访问必须被中断限定交付连接器把数据发给指定连接器以外的节点必须失败限定可见范围非成员空间用户查询产品必须返回空。这些用例全部通过才认为连接器具备上线条件。6.3 验收时的一个硬习惯实际项目里我发现最容易漏的是“使用后销毁”策略。标准里写的是数据产品使用后销毁但这个策略依赖连接器主动清理数据副本连接器如果没有清理能力合约就空转了。从那以后每次验收我都会把策略模板完整过一遍一个策略一张测试卡片宁可多测三步也不放过一条分支。希望帮到你。本文还有配套的精品资源点击获取