數字政府隱私計算落地案例介紹

導讀：本文將介紹數字政府隱私計算相關背景，技術路線，以及一些落地案例。

全文目錄：

• 背景介紹

• 技術路線

• 案例分享

• 落地難點

• 建議思路

分享嘉賓｜張黔榮 啟明星辰 資料安全專家

編輯整理｜劉倩 浙江工業大學

出品社群｜DataFun

---

01

背景介紹

早在 2018 年，關於資料可用不可見等各種概念已經提出，當時數字政府領域的廠商和網際網路公司提出的是可信共享交換這個概念。當時底層用的是沙箱來實現資料可用不可見。後來在國務院辦公廳釋出了<公共資料資源開發利用試點方案>，以及後面十四五規劃的資料要素化的一些檔案出臺以後，帶動了整個隱私計算行業的發展。所以現在從技術和可行環境來看，沙箱技術比多方技術和聯邦學習要相對落後。

各地的法律法規，各種資料應用條例，資料開發條例也紛紛來支援資料開發利用，提供資料服務和資料產品的加工。所以從條例和政策的角度，是想解決資料的權屬和安全問題。隱私計算在計算環節裡面能保證資料權屬，能夠最大化釋放資料的價值，為各個資料的提供方和需求方提供安全，減少顧慮。

02

技術路線

1. 隱私計算技術

從現在各地政府招標的專案和規劃設計來看，會嘗試使用多種技術來解決資料開發利用和資料流通的問題，也有一些地方提出，在資料做好分類分級之後，對低敏感的資料用可信執行環境和安全沙箱來解決，而中敏感的資料可能用多方安全計算這種技術來解決，對於高敏感的資料，可能用聯學習再加部分的同態來解決資料的共享交換問題。

2. 多方安全計算

關於信任基礎，對於多方安全計算，信任的是底層的密碼協議。

3. 聯邦學習

對於聯邦學習是保證本地資料不出庫的信任機制。

4. 可信執行環境

對於可行執行環境，不管是軟環境還是硬環境，信任的是晶片和構建的沙箱環境。

5. 安全沙箱

對於安全沙箱來說，信任的是封閉、安全、自由的計算環境。

對於不同的技術，在具體實施落地時，有一些不同的需要注意的問題。比如安全沙箱，最大的問題是安全沙箱放在哪裡。政府與銀行合作的專案，資料都要進到沙箱，那麼沙箱是放在政府端，還是放在銀行，還是構建一個分散式沙箱，因為資料進了沙箱之後還是需要解密的，沙箱裡面的資料在計算完成之後，是否能夠把原始資料釋放掉或者消除掉。

03

案例分享

下面具體介紹幾個數字政府案例。

政府領域是對外賦能的，而金融領域可能是對內的，政府資料相對來說價值含量比較高，但政府內部資料共享確實存在難點和痛點。目前大多是透過共享交換平臺來進行資料共享交換，但是對於一些委辦廳局不願意把自己敏感度比較高，或者價值含量比較高的資料共享出來，可以透過隱私計算平臺或者隱私保護技術來共享。

1. 政府內部資料共享

第一個案例是某自然資源廳的個人不動產資料調查，需要核查領導幹部的一些房產資訊，但核查時，不能讓自然資源廳的相關人員知道到底查的是誰。為避免發生洩密事件，現有的查詢的手段和方式為，同步一份自然資源廳的不動產庫，直接同步到組織部或者是監察委。還有一種方式，是透過拿專線的方式對接過去，但是這時候會存在一個問題，需要定期更新組織部不動產的資料庫，這就造成了更新的問題、傳輸的安全性問題、以及耗費大量人力和物力的問題。所以當時該自然資源廳就提出用隱私計算隱匿查詢的功能來幫助組織部去保護查詢人的資訊。但是這時候還會引出一個問題，就是隱私計算的接入節點對接的是自然資源廳不動產的資料庫或者快取庫，接入節點對接不動產資料庫和快取庫時是有讀寫記錄的，關於這一點，其實在隱私計算和不動產庫的讀寫過程中，需要加入混淆的手段，比如可以同時讀取 N 多人的查詢記錄，或者是加一些不是想查詢的人的一些記錄。所以在這個方案裡面，如果不做查詢多個人的這種手段，那麼保護的只是從不動產資料庫到組織部門的查詢頁面的中間過程。所以從考慮到端對端完整性的角度來說，對接不動產資料庫的查詢輸入查詢條件的時候需要做一些相應混淆手段和安全手段。

這個案例是具有可複製性的。從公開的資訊裡面可以看到，湖南其實在 2019 年就已經啟動了不動產登記的共享交換系統，已經與組織部、監察委、民政廳進行了對接。現在對接的方式是基於明文的方式來進行共享交換，隱私計算廠商在與湖南的政府部門探討用密文的方式來幫助他們更好地完成資料共享交換。

2. 政府與企業資料開發利用

政府與企業的資料開發利用，這是對外賦能的。金融機構需要政府資料，在沒有隱私計算的時候明確提出需要原始資料，在政府沒有大資料局之前，各家商業銀行直接透過專線對接公積金中心和社保、婚姻、不動產等資訊，政府直接把明文資訊給到商業銀行。隨著安全法和個人資訊保護法出臺之後，各地的大資料局和一些相關的委辦廳局擔心商業銀行把資料用於其他用途，根據現在國家釋出的政策檔案，個人資訊保護法裡面明確提出要盡到告知同意的義務，所以現在各家商業銀行都會跑到大資料局去要個人消費貸或者是中小企業貸款的資料，也願意提供有償的資料服務，但是大資料局作為資料的持有方，需要對原始資料的權屬和價值來進行保護，可以透過隱私計算平臺把各類的關於個人或者企業的政務資料加工成資料產品。比如在這個案例中，就加工成了個人信用評分，然後給到商業銀行。

在這個案例中，存在一些困難，首先就是大資料局本身不懂金融業務，隱私計算廠商也不懂金融風控的業務，在這樣的情況下，一般都是讓銀行來提出他需要的業務模型。但是這個業務模型大資料局還得進行稽核，比如提的模型直接就可能會把原始資料給拿走，所以在商業銀行提出的個人信用評分模型，需要由大資料局來進行稽核，稽核同意之後才可以讓隱私計算平臺讀取資料來進行計算把結果給到銀行。

對於銀行來說困難程度也不低，因為原來是直接拿原始資料到風控模型裡，但是一旦把個人信用評分這個子模型拆出來，對原有的業務模型會產生影響。各家銀行的風控模型都不一樣，有些會影響比較小，有些可能就得重新調引數，對原有的風控模型影響就比較大，所以這也是在具體落地時會出現的難點，涉及到銀行內部業務部門、技術部門之間的溝通和協調。因此在這個案例中，需要商業銀行和大資料局達成共識，透過隱私計算來開展相關的業務，才能保證專案順利落地。

在具體操作過程中，還需要考慮資料質量問題。商業銀行要去核查納稅局的資料是否符合要求，資料準不準，所以在上線的時候，還需要隱私計算平臺對大資料局的資料質量做一次核驗，目前業內大部分隱私計算平臺都沒有針對核驗的功能，所以採用線下的 MD5 校驗技術來對大資料局的資料和銀行存量客戶的資料來做一次核對，核對完了之後，雙方對資料資料質量的結果都比較滿意，業務模型也經過了大資料的稽核，再由隱私計算的廠商把業務模型寫到平臺上，當然也可以由銀行的技術部門來透過隱私計算平臺的開發工具寫到平臺上。這一過程對銀行來說，保護的是銀行的模型引數，對大資料局而言，保護的是公積金、社保、婚姻等原始資料。一般部署形態會有幾種方式，一種方式是分散式的，有幾個計算節點在銀行，有幾個計算節點在大資料局。還有一種方式就是如果銀行充分信任政府的話，可以把計算節點都放在政務雲或者政務外網這一端。如果大資料局足夠信任銀行，也可以把節點都放到商業銀行。部署方案根據各方具體需求來靈活落地。目前大資料局跟商業銀行之間最好還是採用專線來進行對接，考慮到任務排程和計算的準確性，透過專線比較穩定。

3. 公共資料運營平臺

公共資料運營平臺是在政策檔案十四五規劃市場要素改革配置意見明確提出來的，政府可以授權單位來進行公共資料的運營。成都授權的是國有企業，海南省大資料局授權給了中國電信，合肥授權給了合肥大資料公司，所以合肥、成都和海南的案例，政府單位還是授權給了國有企業，政府單位在這個過程中，是作為監管單位，各家承接的公共資料運營的公司或者平臺承擔的只是資料運營職責。但是目前看到的業內的公共資料運營就是這幾家單位，都是做了一個網站，招了一些資料服務商，資料提供方，還有演算法提供方以及資料需求方購買方等等，從上架的產品來說，大部分還是一些軟體類或者是介面呼叫類，其中關於隱私計算提供的產品數量還是比較少的。根本原因就是確實現在沒有一個專業的隊伍對公共資料到底提供什麼樣的資料產品服務有一個清晰的認識，第二就是公共資料運營平臺的設計和跟業務需求方的對接會存在溝通問題。總體來說目前全國各地大體的模式就是政府會授權給某一家單位，由這個單位來進行公共資料的運營，運營的收益是給到相關的國有單位。關於資料的買賣和定價可以以市場的形式或者是協商的形式來對資料產品進行定價，不管價格高低都歸屬國有資產，也解決了防止國有資產流失的問題。從政府角度考慮，承擔監管就是等於是把監管權和運營權分開了，就能防止政府既當裁判員又當運動員的狀態。

4. 資料交易所/中心

最早北京提出利用隱私計算來構建資料交易 3. 0 模式，後面上海資料交易所也將隱私計算納到資料交易體系的技術範圍，廣東相對謹慎一些，還是希望做公共資料的認證。比如廣東發了公共資料資源的憑證，而具體的資料運營會交給廣東省資料交易中心或者是委託的單位來做，而政府只做認證和確權相關事情。深圳目前打算構建的是沙箱模式，就深圳市交易公司提供交易平臺，各方資料放到這個交易平臺裡面來進行開發利用，這個交易平臺可以保證資料安全，深圳確實以隱私計算和各種安全手段來保護了資料權屬，為了讓更多參與方參與到平臺上的運營。

04

落地難點

目前隱私計算在行業內落地相對來說比較困難，不管是在數字政府領域還是金融領域。

• 第一個問題就是經濟的問題，目前試點專案的金額比較少。同時目前行業內的各個廠商的開發人員成本，去各地擴充專案的成本，以及他去做 PC 和技術驗證等等相關成本比較高，有很多的專案都是虧損的，再加上目前隱私計算的廠商越來越多，行業內競爭越來越激烈。

• 第二是安全性問題，在跟政府單位去溝通時都會面臨到如何證明平臺是安全的，不管是多方安全計算還是聯邦學習，資料是否不能被攻破，如何證明在計算的過程中資料不能被別人拿走，目前各個廠家確實沒有辦法來自證清白，也沒有權威機構有相關的安全認認證。

• 第三是實際應用場景的問題，現在隱私計算的廠家大部分精力和投入全部投在平臺上，而沒有相應的業務人才去幫客戶梳理業務。各個參與方協調起來比較困難，比如政府內部有各個處使，銀行有科技部門、業務部門、研究院等部門。需要各方溝通，場景才可能落地，而且落地的場景確實要解決資料需求方的問題，別人才有可能會買單，或者是認可平臺。

• 第四是平臺效能和友好性的問題，對於政府單位來說技術開發水平相對較低，現在的平臺使用起來較複雜，購買意願不強。目前在落地的專案裡面，都是由隱私計算的廠商來提供的資料模型的開發服務放到隱私計算平臺上。大多數隱私計算平臺都是基本功能，並沒有解決政府部門關心的業務流程。

05

建議思路

政府行業內非常關心業務流程，而對於底層技術的關心程度並沒有那麼高，所以建議各個隱私計算廠商的開發人員可以更加關注業務層，去幫助客戶更好地使用平臺。

• 資料管理功能：資料管理功能現在大部分廠商都會有，因為要對接資料，應著重考慮產品對接，以及平臺在政府的整個資訊化系統架構中所處的位置。

• 資料分類分級：透過分類分級，判斷是否該用隱私計算平臺來進行計算，還是用沙箱，或多方安全計算，亦或是聯邦學習來進行計算。

• 資料的確權與授權：比較複雜。

• 資料服務開發：如果從面對不同場景使用不同的隱私計算的技術來說，確實在資料服務開發裡面的開發工具還需要統一接入平臺來對接底層各類計算平臺。

• 資料供需對接：目前從各個平臺來說，資料的供需對接僅僅停留在申請什麼資料，提一個表單，給到資料的需求方，未來需要更精細化，以提供給客戶更好的體驗。

• 安全管控和合規稽核：真正的模型稽核目前還難以用技術手段實現，基本仍是人工稽核，無論是用人工還是用智慧化的手段，這個環節在資料流通的過程中都是必不可少的。

• 資料安全閘道器：資料計算結果如何給到資料的需求方，需要對這些介面進行管理，並對流量進行監控，一旦發生資料洩露事件，需要對介面進行熔斷保護，可以上到區塊鏈平臺上，也可以存在自己的庫，有一些廠家是以區塊鏈的合約來驅動隱私計算的任務。

06

精彩問答

Q1：國內隱私計算公司未來的發展情況會是什麼樣？

A1：我所瞭解的一些情況是，目前隱私計算的廠商大部分都在轉向做資料服務了，它們需要給政府單位，客戶提供一個明確的解決方案，客戶才會買單。另一個方向就是開源，這是往技術層走的。大部分廠商為了收入和利潤，還是走的資料服務方向。

Q2：一般而言，資料質量有問題，是指資料不準確甚至有錯誤，如果原始資料就有質量問題，是很難發現的。但是在案例二中透過 MD5 對比就能判斷資料質量，這個能解釋一下嗎？

A2：首先，如果資料質量問題出在原始資料上是沒法解決的。但是，銀行自己有一些存量資料，可以用自己的存量資料與政府資料來做比對，而這僅僅是做一個比對，不能解決原始資料的質量問題。銀行作為客戶，如果對質量認可，就願意買單，否則可以要求再去做資料清洗和治理，再做比對。

Q3：資料運營會不會造成個人隱私資料洩露，分析的時候如何保障？

A3：個人隱私資料是要經過授權的，政府單位有要求，是需要個人授權，隱私計算才在具體的場景裡面進行服務，如果沒有經過個人授權，政府一般是不會把個人資料給到相關單位的，這一點可以放心。