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