近期參與了一個跟華爲數據交換的項目，簡單聊聊華爲的數據交換方案及使用心得。
先簡單說一下背景：數據交換旨在建立企業互信，消除數據孤島。行業數據都是各企業花費了大量精力整理得到的，一時間公開完全不可行。但是LLM的發展，基礎模型需要越來越多的數據，這在倒逼企業合作，加之美國在相關方面的封鎖，消除數據孤島開始凸顯其重要性。當然LoRA的出現也給LLM提供了另外一種解決方案：外掛行業知識庫，這個問題就不在這裏介紹了。
公司希望使用自己的數據，基於盤古大模型訓練出我們自己的大模型。我有幸參與了與華爲的數據交換項目，接觸到華爲雲的OBS（Object Storage Service，對象存儲服務）。
最初操作OBS的時候，第一感覺就是這是個網盤，企業不限速網盤，複雜的操作讓人本能的反感（做產品的第一要訣：讓產品連傻子都用的起來，能點擊一次解決問題，就不要讓用戶點兩次）。各種配置眼花繚亂，期間更是有開發參與調試，真是讓人無語且崩潰，不過想到這事沒有前人在做也就釋然了，通力合作把事情做成纔是關鍵。
具體配置不展開了，只說說關於數據交換過程中數據安全傳輸的兩套方案及禁止下載的配置。
先定義一下數據交換過程的生命週期，數據交換過程從數據提供方上傳數據到OBS開始，到數據接收方從平臺（EDS或者OBS）下載數據爲止。至於爲什麼不討論數據上傳前和下載後可能的安全問題，我認爲基於企業互信，這部分是不需要在數據交換項目中討論的。企業互信是因，數據交換是果，我們很難看到兩個沒有信任關係的企業會有數據交換的可能。
方案1，EDS數據交換空間，針對場景是兩個（或多個）企業進行數據交換。數據提供方可以一對多的提供數據，數據接收方則根據數據合約來使用數據，讓數據在流通的全流程內安全可追溯。數據提供方將數據上傳到OBS，使用EDS的連接器將數據接入（簡易理解，就是把數據從一個網盤接入另一個網盤，實際上有堡壘機等一系列安全措施保護數據安全），在EDS中生成數據合約，限定數據的使用期限、下載次數和下載工具。數據接收方在接到數據合約之後，按照合約內容將數據歸檔，在限定期間內使用下載工具下載數據。
這個方案的好處就是數據從OBS接入EDS開始，全流程高度可控，數據不上架、不生成合約，消費方是無法看到和使用的。唯一可能產生數據泄露的地方在於，一是數據提供方上傳數據到OBS後是可以下載的，這種情況是數據提供方自行泄露；這個方案的壞處就是，有很多需要配置的地方，上述過程中基本上沒有提及堡壘機等其他服務，用戶自行配置基本上不可能，建議華爲能出一個基礎的配置模板，否則用戶就得享受一對一服務了，其實也挺不錯喲。
下文中禁止下載的配置，其實也可以用於解決方案1中數據提供方上傳數據到OBS後下載的情況。
方案2，使用OBS交換數據。OBS是一個存儲服務，理解成網盤更方便，但是通過配置權限，也可以讓他變成一個便捷的數據交換工具。其核心配置就是禁止數據下載。
起初的時候一直不理解爲什麼要對數據提供方限制下載，直到我發現數據接收方是華爲。事情的起因是我們雙方對數據安全傳輸方案的選取上有分歧，我們傾向全流程安全可控的方案1，但是經過成本、時間、效率等一系列的評估之後，排除了方案1。此時華爲方提出了另一種方案，他們提供OBS，並給我們提供相應的IAM賬號，只能上傳不能下載。其實我們也是可以提供同樣的配置，但是效果完全不一樣。假設數據提供方提供OBS、IAM賬戶且配置禁止下載後，由於IAM的主賬號在數據提供方，主賬號可以隨意修改權限，出現數據泄露的現象的話雙方都有可能。但是如果是數據接收方提供OBS、IAM賬號且配置禁止下載，我們就會發現數據提供方不能隨意修改權限，只能上傳不能下載，數據泄露的可能只在數據接收方。在感慨了一聲華爲有擔當之後，我們果斷採取華爲的方案，他們提供OBS、IAM賬號配置禁止下載。
方案2的好處就相當明顯了，配置簡單的同時保證了安全性。
接下來再說OBS數據禁止下載的配置。
