簡介由全國數(shù)據(jù)標(biāo)準(zhǔn)化技術(shù)委員會發(fā)布的《可信數(shù)據(jù)空間 技術(shù)架構(gòu)》規(guī)范文件面向從事數(shù)據(jù)基礎(chǔ)設(shè)施建設(shè)、運(yùn)營與管理的技術(shù)人員及相關(guān)管理人員為地方、行業(yè)、領(lǐng)域和企業(yè)開展可信數(shù)據(jù)空間規(guī)劃、建設(shè)與運(yùn)營提供權(quán)威指導(dǎo)。文檔明確可信數(shù)據(jù)空間作為數(shù)據(jù)流通利用基礎(chǔ)設(shè)施的定位圍繞身份管理、接入連接器管理、目錄管理、數(shù)字合約管理、數(shù)據(jù)使用控制等核心功能梳理服務(wù)平臺與接入連接器、區(qū)域/行業(yè)功能節(jié)點(diǎn)的交互關(guān)系以及登記、發(fā)現(xiàn)、創(chuàng)建邏輯空間、數(shù)據(jù)流通利用等業(yè)務(wù)流程。針對跨企業(yè)、跨行業(yè)產(chǎn)業(yè)數(shù)據(jù)交換以及跨領(lǐng)域、跨學(xué)科科學(xué)數(shù)據(jù)共享分析場景文件給出數(shù)字合約、數(shù)據(jù)產(chǎn)品和空間運(yùn)行的安全要求有助于構(gòu)建安全可信的數(shù)據(jù)共享生態(tài)。資源為單份PDF文檔壓縮包共1個文件、約1.74MB目錄清晰適合作為可信數(shù)據(jù)空間架構(gòu)設(shè)計與數(shù)據(jù)基礎(chǔ)設(shè)施建設(shè)的直接參考。目前已有260人瀏覽學(xué)習(xí)。1. 可信數(shù)據(jù)空間技術(shù)架構(gòu)先想清楚它解決的痛點(diǎn)是什么現(xiàn)實中一個常見場景某供應(yīng)鏈平臺需要向銀行提供上下游企業(yè)的真實經(jīng)營數(shù)據(jù)來做融資風(fēng)控但數(shù)據(jù)源企業(yè)不敢把核心系統(tǒng)數(shù)據(jù)直接給出去銀行也不敢相信平臺轉(zhuǎn)交的截圖和 PDF。傳統(tǒng)接口能傳數(shù)據(jù)卻傳不了信任——數(shù)據(jù)交出去了無法控制用途拿到數(shù)據(jù)的人無法證明其來源和真實性出了問題說不清責(zé)任?？尚艛?shù)據(jù)空間正是為解決這類“跨主體、跨系統(tǒng)、不可控”的數(shù)據(jù)流通難題而生它要構(gòu)建的是一個各方規(guī)則互認(rèn)、權(quán)責(zé)清晰、行為可證、全程可追溯的流通利用生態(tài)讓數(shù)據(jù)像在可信生態(tài)系統(tǒng)中按合約流動而不是靠信任對方人品來完成交易。它既不替代數(shù)據(jù)倉庫也不是新的大數(shù)據(jù)平臺而是一層解決“可信”問題的流通基礎(chǔ)設(shè)施。2. 可信數(shù)據(jù)空間的架構(gòu)內(nèi)核把“可信”拆成可落地的六層組件2.1 可信數(shù)據(jù)空間與數(shù)據(jù)交易所、API 管道的本質(zhì)區(qū)別很多團(tuán)隊第一次接觸可信數(shù)據(jù)空間會自然地拿它與數(shù)據(jù)交易所、API 網(wǎng)關(guān)做對比。數(shù)據(jù)交易所核心解決“確權(quán)與交易撮合”問題把數(shù)據(jù)像商品一樣掛牌、競價、交割A(yù)PI 網(wǎng)關(guān)解決“系統(tǒng)間調(diào)用與鑒權(quán)”問題強(qiáng)調(diào)連接和轉(zhuǎn)發(fā)?？尚艛?shù)據(jù)空間解決的則是“流通全程的可信與控制”問題它不只關(guān)心一次請求是否鑒權(quán)通過還關(guān)心數(shù)據(jù)被用什么、用多久、用完能否刪除、違約時能否舉證。三個概念不應(yīng)混用一個可信數(shù)據(jù)空間內(nèi)完全可以內(nèi)嵌 API 能力也可以與數(shù)據(jù)交易所對接。常見做法是把它理解為“數(shù)據(jù)流通的運(yùn)營環(huán)境”提供參與方身份互認(rèn)、數(shù)據(jù)資源描述、使用控制策略、可信執(zhí)行、過程存證、爭議仲裁這六個核心域。其中任意一個域缺失國繞“可信”的閉環(huán)就斷掉了。對比項數(shù)據(jù)交易所API 網(wǎng)關(guān)可信數(shù)據(jù)空間核心問題確權(quán)與撮合連接與鑒權(quán)流通過程的可信與控制信任保障交易合規(guī)背書傳輸憑證身份互認(rèn)策略執(zhí)行全程存證數(shù)據(jù)控制粒度粗粒度中粒度細(xì)粒度到字段與用途事后追溯弱弱強(qiáng)支持舉證定位交易場所技術(shù)通道流通基礎(chǔ)設(shè)施2.2 參與方身份與信任錨數(shù)據(jù)空間里的“可信”由誰背書可信數(shù)據(jù)空間要做的第一件事是讓每個參與方都有一份可驗證、可吊銷的身份憑證。數(shù)據(jù)提供方、消費(fèi)方、運(yùn)營方、監(jiān)管方都會申請屬于自己的數(shù)字證書證書由空間內(nèi)的根信任錨統(tǒng)一簽發(fā)和背書。信任錨是整個體系最底層的那把鑰匙它決定了誰有資格進(jìn)入這個生態(tài)。落地時信任錨往往由一個中立運(yùn)營主體承擔(dān)。參與方身份信息經(jīng)過主體審核后簽發(fā)證書證書包含參與方編碼、角色、公鑰信息、有效期。每個參與者持有的證書都是其數(shù)據(jù)行為的身份基礎(chǔ)后續(xù)的接口調(diào)用、策略協(xié)商、日志上報都基于該憑證做簽名和加密。這個設(shè)計的價值在于信任不用逐對建立。數(shù)據(jù)提供方不需要單獨(dú)和幾十個消費(fèi)方做安全協(xié)議對接只要大家都信任同一個信任錨彼此通過驗證對方證書鏈就能確認(rèn)身份合法。這也是“可信生態(tài)”的真正含義中心化背書、去中心化協(xié)作。2.3 數(shù)據(jù)資源目錄與數(shù)據(jù)模型流通的是描述而不是文件拷貝明確了參與方身份只是第一步下一步是讓數(shù)據(jù)提供方能夠把自己的數(shù)據(jù)“說清楚”?？尚艛?shù)據(jù)空間內(nèi)流通的不再是原始文件而是數(shù)據(jù)的描述信息加受控的訪問能力數(shù)據(jù)資源在數(shù)據(jù)源側(cè)物理保留。數(shù)據(jù)目錄負(fù)責(zé)登記這些描述數(shù)據(jù)集名稱、結(jié)構(gòu)、更新頻率、字段字典、樣本數(shù)據(jù)、使用條件、計費(fèi)方式、數(shù)據(jù)質(zhì)量等級。這一設(shè)計解決了兩個現(xiàn)實問題。第一數(shù)據(jù)提供方不必把數(shù)據(jù)搬到某個中心倉庫避免了“數(shù)據(jù)離域”的心理障礙和安全風(fēng)險第二消費(fèi)方在授權(quán)前就能通過目錄了解數(shù)據(jù)的基本情況減少盲目申請。數(shù)據(jù)模型則負(fù)責(zé)明確這些描述信息的語義規(guī)范。同一字段在不同企業(yè)里有不同叫法若沒有統(tǒng)一模型目錄信息仍難以被人和機(jī)器理解。常見做法是先產(chǎn)出核心實體模型如企業(yè)、個人、訂單、信用記錄等再讓數(shù)據(jù)提供方按模型映射自身字段。實踐中的一個注意點(diǎn)目錄不等同于數(shù)據(jù)中臺的元數(shù)據(jù)管理。元數(shù)據(jù)管理面向企業(yè)內(nèi)部的數(shù)據(jù)資產(chǎn)盤點(diǎn)目錄面向跨組織的數(shù)據(jù)發(fā)現(xiàn)與共享契約因此目錄中的信息需要更偏業(yè)務(wù)化和市場化——消費(fèi)方關(guān)心的是數(shù)據(jù)是否新鮮、覆蓋多少主體、字段是否可對齊這些都應(yīng)體現(xiàn)在目錄條目上。2.4 連接器與數(shù)據(jù)使用控制策略可信邊界的最后防線數(shù)據(jù)資源放入目錄并經(jīng)授權(quán)后真正發(fā)生數(shù)據(jù)交換的是連接器。連接器部署在數(shù)據(jù)提供方和消費(fèi)方兩側(cè)由提供方側(cè)連接器控制數(shù)據(jù)出域由消費(fèi)方側(cè)連接器保證數(shù)據(jù)按合約被使用?？尚趴刂频年P(guān)鍵是策略它描述“誰可以在什么條件下、以什么用途、在多長時間內(nèi)使用哪些數(shù)據(jù)”。常見策略模型會把約束拆成五類主體約束、目的約束、時間約束、次數(shù)約束、范圍約束。一份典型的策略文件可能包含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} ] }這段策略定義了三個技術(shù)要點(diǎn)。其一消費(fèi)方 B 只能把訂單數(shù)據(jù)用于“貸款風(fēng)控”這是目的約束防止數(shù)據(jù)被挪作他用其二有效期和調(diào)用頻率共同限制使用窗口每天最多調(diào) 3 次其三字段掩碼和數(shù)據(jù)過期時間實現(xiàn)精細(xì)化脫敏與生命周期管理消費(fèi)到期后數(shù)據(jù)在消費(fèi)側(cè)必須刪除。策略執(zhí)行后剩余的信任問題就是消費(fèi)方有沒有在環(huán)境里篡改策略或繞過執(zhí)行。因此可信數(shù)據(jù)空間通常配合可信執(zhí)行環(huán)境或數(shù)據(jù)沙箱來加固消費(fèi)方側(cè)讓數(shù)據(jù)處理活動發(fā)生在可驗證的受控環(huán)境中。早期試點(diǎn)不必強(qiáng)制上機(jī)密計算但至少要保證策略引擎運(yùn)行在獨(dú)立的服務(wù)進(jìn)程里并具備防篡改日志。2.5 存證、審計與爭議仲裁事后可追溯才算真正閉環(huán)可信不能只做在事前和事中一旦數(shù)據(jù)已經(jīng)流通總要面對“萬一發(fā)生爭議如何取證”的挑戰(zhàn)?？尚艛?shù)據(jù)空間會在交換的關(guān)鍵節(jié)點(diǎn)上產(chǎn)生存證信息包括策略協(xié)商記錄、數(shù)據(jù)請求記錄、策略執(zhí)行結(jié)果、數(shù)據(jù)使用方上報的處理摘要、數(shù)據(jù)刪除報告等。這些記錄經(jīng)過簽名后形成不可篡改的審計鏈。常見做法是將存證哈希同步寫入?yún)^(qū)塊鏈系統(tǒng)或具備司法效力的存證服務(wù)。不必把所有原始數(shù)據(jù)上鏈只要把存證摘要和時間戳上鏈即可原始日志由運(yùn)營方數(shù)據(jù)庫保存事后爭議時用摘要哈希校驗數(shù)據(jù)庫記錄是否完整。數(shù)據(jù)使用方也應(yīng)有一種機(jī)制來證明自己“確實在按策略用數(shù)據(jù)”這就是使用回報它把消費(fèi)方的處理過程定期匯總給提供方存證讓數(shù)據(jù)出域后的行為對提供方保持透明。2.6 從單域到跨域可信數(shù)據(jù)空間互聯(lián)的技術(shù)承接當(dāng)多個可信數(shù)據(jù)空間各自建成后新的需求出現(xiàn)了一個空間里的數(shù)據(jù)提供方如何被另一個空間里的消費(fèi)方發(fā)現(xiàn)和使用。這就進(jìn)入空間互聯(lián)問題?？缈臻g互聯(lián)不能簡單把兩套證書體系打通就完事還涉及目錄互操作、策略互認(rèn)和存證互通。常見的技術(shù)方案是建立空間間的信任背書關(guān)系由上一級或第三方信任錨進(jìn)行跨域身份背書目錄通過鏡像或聯(lián)邦查詢實現(xiàn)跨域發(fā)現(xiàn)策略互認(rèn)則意味著雙方空間需要統(tǒng)一策略語法或至少支持翻譯轉(zhuǎn)換。一個務(wù)實的做法是先以“跨空間查詢目錄”為試點(diǎn)再逐步開放跨空間數(shù)據(jù)調(diào)用不要一開始就追求所有策略語義完全對齊。國內(nèi)相關(guān)可信數(shù)據(jù)空間建設(shè)指南對互聯(lián)架構(gòu)已有描述跨域互認(rèn)機(jī)制目前仍有不少細(xì)節(jié)依賴各方既有的行業(yè)規(guī)范實施時要依據(jù)實際對接方來收斂。3. 從零跑通一個最小可信數(shù)據(jù)空間實施路徑與配置參考3.1 最小落地尚需哪幾個角色與組件評估一個可信數(shù)據(jù)空間項目是否具備實施條件先看角色是否齊備。最小可運(yùn)行的空間必須包含四類角色運(yùn)營方負(fù)責(zé)信任錨、目錄服務(wù)和存證服務(wù)的運(yùn)行維護(hù)數(shù)據(jù)提供方提供數(shù)據(jù)資源并部署連接器數(shù)據(jù)消費(fèi)方申請數(shù)據(jù)并在自身側(cè)部署消費(fèi)端組件監(jiān)管方具備查看審計日志權(quán)限。許多試點(diǎn)項目會忽略監(jiān)管方角色導(dǎo)致審計數(shù)據(jù)無人使用。即使剛開始監(jiān)管方并不活躍也應(yīng)當(dāng)在架構(gòu)中預(yù)留其訪問通道。組件方面最小集合需要一個身份認(rèn)證服務(wù)、一個數(shù)據(jù)目錄服務(wù)、一套策略管理服務(wù)、一個存證服務(wù)以及兩側(cè)的連接器。把這些組件全部部署在同一個 Kubernetes 集群或傳統(tǒng)虛機(jī)環(huán)境均可初期不必追求全面容器化。3.2 數(shù)據(jù)資源盤點(diǎn)、分級與接口改造最先做的往往是臟活接入可信數(shù)據(jù)空間最耗費(fèi)精力的不是搭建組件而是把數(shù)據(jù)資源的家底盤清楚。一個數(shù)據(jù)提供方可能有幾十個庫表但真正值得拿出來共享的往往只有少數(shù)高價值數(shù)據(jù)集。盤點(diǎn)階段要回答四個問題庫表里有多少敏感字段水能否開放原樣數(shù)據(jù)數(shù)據(jù)更新頻率是多少是否適合做實時接口數(shù)據(jù)能否按消費(fèi)方維度做行級過濾或字段脫敏數(shù)據(jù)質(zhì)量是否穩(wěn)定能否支撐簽約承諾。數(shù)據(jù)分級強(qiáng)烈建議直接參考行業(yè)通用分類無條件開放、有條件開放、協(xié)議共享、禁止開放?？尚艛?shù)據(jù)空間的定位決定了它主要處理前三級。接口改造是有條件開放和協(xié)議共享數(shù)據(jù)的主要工作量。常見做法是在原系統(tǒng)服務(wù)外增加一層數(shù)據(jù)服務(wù)接口讓數(shù)據(jù)空間連接器通過該接口取得數(shù)據(jù)。接口設(shè)計要以最小開放為原則只暴露所需字段并配合參數(shù)化條件查詢防大表全量掃描。3.3 用連接器接入一個數(shù)據(jù)服務(wù)典型配置示例連接器是每次數(shù)據(jù)交換的必經(jīng)之路。下面給出一份偏服務(wù)端的數(shù)據(jù)提供方連接器配置模板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;" />