大模型上了火山方舟：數(shù)據(jù)唯你可見，唯你所用，唯你所有

金磊 發(fā)自 凹非寺

量子位 | 公眾號 QbitAI

大模型的發(fā)展呈現(xiàn)出追風(fēng)逐日般的速度，但與之相伴的安全問題，也是頻頻被曝光。

正如此前ChatGPT所曝出的案例中，黑客可以利用漏洞給AI植入虛假記憶，在后續(xù)回答中出現(xiàn)誤導(dǎo)信息。

而且還能植入惡意指令，持續(xù)獲取用戶聊天數(shù)據(jù)。

即便開啟新的對話也是無濟于事，簡直就是大寫的“陰魂不散”：

試想這種對話一旦涉及機密的內(nèi)容，那帶來后果和損失可以說是不敢想象。

可怕，著實是有些可怕。

但反觀國內(nèi)的大模型玩家，卻似乎鮮有黑客入侵、數(shù)據(jù)泄露等安全問題的存在。

為何會如此？

帶著這個疑問，我們找到了大模型服務(wù)平臺火山方舟的團隊，在與火山引擎智能算法負(fù)責(zé)人、火山方舟負(fù)責(zé)人吳迪做了深入交談之后，得到了這樣的答案：

這是因為火山方舟從Day 1開始就把安全植入基因，把它當(dāng)作基本的產(chǎn)品功能來實現(xiàn)。

目前我們已經(jīng)做到了模型和會話等數(shù)據(jù)全周期都是安全可信的，而且是會話無痕的那種。

一言蔽之，就是你的數(shù)據(jù)，唯你可見，唯你所用，唯你所有。

那么火山方舟具體又是如何做到的，我們繼續(xù)往下看。

火山方舟：在我這，會話無痕

傳統(tǒng)的數(shù)據(jù)安全保護方案，已經(jīng)不能被套用到AI大模型時代。

這就是目前大模型玩家們在安全方面所面臨的最根本且真實的難題。

因為傳統(tǒng)的私有化部署方案，多數(shù)是屬于數(shù)據(jù)不動模型動，這種方法難以跟上云上大模型的快速迭代，且基礎(chǔ)算力的單位成本遠(yuǎn)高于公有云集中調(diào)度。

因此，現(xiàn)在更適合的一種方案應(yīng)當(dāng)是模型不動數(shù)據(jù)動，企業(yè)需要將數(shù)據(jù)上傳到云中，以此來利用最先進的大模型能力。

如何讓用戶充分信任云上數(shù)據(jù)的安全性始終是一個難題。

加之在技術(shù)層面上，主流的隱私計算技術(shù)也無法滿足生產(chǎn)級別性能要求。

例如可用的TEE技術(shù)雖然成熟，但保護GPU等異構(gòu)高算力硬件，是依然在探討和研究中，無法直接大規(guī)模用于生產(chǎn)環(huán)境；MPC等多方安全計算技術(shù)也很難在大模型的吞吐、延遲與大模型的效果之間取得平衡。

而火山方舟的全周期安全方案，卻能直擊上述的痛點，并且很好地提供安全保護的能力。

整體來看，這套方案共分為四大維度，分別是：

• 鏈路全加密
• 數(shù)據(jù)高保密
• 環(huán)境強隔離
• 操作可審計

接下來，我們就把整套方案拆分開來，深入到每個維度來看下火山方舟是如何搞安全的。

鏈路全加密

在大模型應(yīng)用中，數(shù)據(jù)流轉(zhuǎn)的每個環(huán)節(jié)都可能面臨風(fēng)險，特別是當(dāng)數(shù)據(jù)從用戶端發(fā)送到云端進行處理的時候。

對此，火山方舟平臺采用了“雙層加密”方案，即在數(shù)據(jù)傳輸過程中實施網(wǎng)絡(luò)層和應(yīng)用層的雙重加密。

首先是在網(wǎng)絡(luò)層，火山方舟使用了HTTPS協(xié)議，這就像給數(shù)據(jù)通道加上了一層防護罩，讓數(shù)據(jù)在傳輸過程中被安全封裝。

同時，平臺還使用了mTLS（Mutual Transport Layer Security，即雙向認(rèn)證傳輸層安全協(xié)議），這可以理解為“雙保險”，因為不僅用戶會驗證方舟平臺的身份，方舟平臺也會反向驗證用戶的身份。

這種方式類似于寄送包裹時不僅需要寄件人和收件人的地址驗證，快遞員還會在每個傳送節(jié)點核查包裹是否安全抵達目標(biāo)地址，確保沒有被篡改。

這一層安全措施有效防止中間人攻擊，即攻擊者試圖在傳輸鏈路中截取或篡改數(shù)據(jù)的行為。

然而，僅僅依賴網(wǎng)絡(luò)層加密還不足以保證數(shù)據(jù)絕對安全，因為如果數(shù)據(jù)在網(wǎng)絡(luò)傳輸中被誤導(dǎo)到錯誤的地址，那么即便是密文也有可能被破解。

因此，火山方舟還增加了應(yīng)用層的會話加密，進一步確保數(shù)據(jù)即便落到不正確的接收端，也無法被解密讀取。

網(wǎng)絡(luò)層的加密就像給一個文件加了一層保險盒，而應(yīng)用層加密就如同再給保險盒上了一把鎖，雙重保險確保即便有人攔截了這個文件，也無從打開它。

在應(yīng)用層加密中，每個推理實例都被賦予了一個唯一的身份認(rèn)證證書，類似于每個人都有自己的身份證號。

用戶的數(shù)據(jù)會使用這個證書的公鑰進行加密，而只有當(dāng)數(shù)據(jù)抵達擁有對應(yīng)私鑰的火山方舟安全沙箱內(nèi)，才會被解密。

這一設(shè)計如同用戶的數(shù)據(jù)在送達火山方舟之前被打上了獨特的印記，只有持有匹配“鑰匙”的平臺安全環(huán)境才能將其解密和使用。

這樣一來，平臺確保了用戶數(shù)據(jù)在傳輸中始終處于封閉的“安全通道”中，未經(jīng)授權(quán)的任何人都無法解鎖并查看數(shù)據(jù)。

數(shù)據(jù)高保密

這一步驟核心在于如何確保數(shù)據(jù)在平臺的傳輸、使用和存儲過程中始終處于極高的保密狀態(tài)。

數(shù)據(jù)高保密不僅涵蓋了對數(shù)據(jù)存儲、加密等方面的多重保護，更以沙箱環(huán)境為基礎(chǔ)，確保數(shù)據(jù)即便在平臺內(nèi)部流轉(zhuǎn)時也不會暴露給任何未經(jīng)授權(quán)的用戶。

這一保密策略類似于把數(shù)據(jù)鎖進一個“加密金庫”中，無論是外界的攻擊者還是平臺的內(nèi)部人員都無法直接接觸到未加密的原始數(shù)據(jù)。

對此，火山方舟采取的策略是：

從數(shù)據(jù)上傳之初就以密文形式加密存儲，只有當(dāng)數(shù)據(jù)進入沙箱內(nèi)存時才會被解密。

對于模型訓(xùn)練，用戶可以通過火山引擎提供的密鑰管理服務(wù)（KMS）功能，設(shè)置自定義密鑰對數(shù)據(jù)進行加密，并將數(shù)據(jù)存儲在用戶自己的TOS（對象存儲服務(wù)）內(nèi)。

這一環(huán)節(jié)可視作給數(shù)據(jù)“穿上盔甲”后再送到平臺，即便數(shù)據(jù)被截獲，攻擊者也只能看到加密后的“密文”，無法獲取數(shù)據(jù)的真實內(nèi)容。

然后，在平臺內(nèi)部，數(shù)據(jù)被分配到安全沙箱中并以密文狀態(tài)存儲，只有在安全沙箱的內(nèi)存中才能夠短暫解密以供訓(xùn)練使用。

通過這一設(shè)計，火山方舟平臺建立了一個“只有沙箱能讀懂?dāng)?shù)據(jù)”的密鑰體系，確保數(shù)據(jù)在離開沙箱后始終以密文狀態(tài)存在。

這就好比“密鑰控制”，即每一組數(shù)據(jù)都配有一把“加密鎖”和“解密鑰匙”。

這把鑰匙由用戶控制，只有用戶允許時才能使用。比如當(dāng)企業(yè)客戶需要上傳訓(xùn)練數(shù)據(jù)集時，可以事先利用TOS的加密功能對數(shù)據(jù)進行處理。

然后火山方舟平臺將密文數(shù)據(jù)掛載到安全沙箱環(huán)境中，在內(nèi)存中完成解密后，數(shù)據(jù)才會被投入訓(xùn)練系統(tǒng)。

此外，火山方舟平臺的數(shù)據(jù)高保密功能還擴展到了精調(diào)模型的存儲和管理環(huán)節(jié)。

對于每一個完成精調(diào)的模型，平臺都會以加密的形式存儲在對象存儲或云文件系統(tǒng)中，確保只有授權(quán)用戶能讀取和使用。

同時，為了保證模型的高效加載和運行性能，火山方舟平臺利用GPU加密庫，讓模型在加載和運行過程中能夠直接在 GPU 上完成解密和加密處理。

這種方式極大地提升了數(shù)據(jù)流轉(zhuǎn)效率，確保在不犧牲模型推理速度的情況下依然保持?jǐn)?shù)據(jù)的高度安全。

在安全沙箱之內(nèi)，還有一個“任務(wù)級隔離”的策略。

在平臺上，每個模型任務(wù)被劃分為獨立的“安全隔間”，即使在多租戶并發(fā)的情況下，用戶數(shù)據(jù)之間也不會互相干擾。

這樣的隔離策略讓每一個任務(wù)都像被鎖在自己的“小隔間”中，即便其他租戶發(fā)生任何安全事件，也不會影響到當(dāng)前任務(wù)的安全性。

環(huán)境強隔離

火山方舟的“環(huán)境強隔離”方案，不僅涉及到上述我們提到的任務(wù)級隔離，更包括了防止數(shù)據(jù)泄露、確保安全操作、監(jiān)控內(nèi)部流量等方面的多層次措施。

環(huán)境強隔離的首要任務(wù)是讓每個模型任務(wù)擁有一個獨立、隔離的“安全區(qū)域”，這一設(shè)計類似于給每個任務(wù)分配了一個“安全艙”。

在實際操作中，火山方舟為每個任務(wù)使用了隔離容器，確保每個任務(wù)實例在一個安全且封閉的容器環(huán)境中獨立運行。

為了達到高安全性，這些容器不僅隔離了彼此的網(wǎng)絡(luò)流量，還限制了容器內(nèi)部的操作權(quán)限，防止任務(wù)間出現(xiàn)橫向數(shù)據(jù)傳輸，確保不同任務(wù)間的數(shù)據(jù)不會相互干擾。

為了進一步加強任務(wù)的隔離性，火山方舟在容器的基礎(chǔ)上設(shè)計了一層動態(tài)網(wǎng)絡(luò)隔離。

這項技術(shù)確保每個任務(wù)都擁有獨立的、專屬的網(wǎng)絡(luò)策略。

具體而言，當(dāng)一個任務(wù)被創(chuàng)建時，系統(tǒng)會自動生成一套動態(tài)的網(wǎng)絡(luò)配置，適用于該任務(wù)的全生命周期；從任務(wù)創(chuàng)建到結(jié)束，無論任務(wù)間是否位于同一云網(wǎng)絡(luò)環(huán)境下，它們之間的網(wǎng)絡(luò)連接始終被嚴(yán)格隔離。

除此之外，火山方舟還為任務(wù)實例部署了容器沙箱技術(shù)。容器沙箱技術(shù)通過添加多層安全防護，使得容器在隔離性上得到了大幅提升。

此處用到的是一項字節(jié)跳動開發(fā)的開源技術(shù)“VERM Armor”，這項技術(shù)為容器提供了一種實時阻斷威脅的機制，一旦容器檢測到潛在的安全漏洞，就會立即阻止危險行為的繼續(xù)。

在環(huán)境強隔離的設(shè)計中，火山方舟還確保了關(guān)鍵數(shù)據(jù)的“只讀存取”功能。任務(wù)實例在使用模型和數(shù)據(jù)時僅具備讀取權(quán)限，不能對數(shù)據(jù)進行修改。

此外，火山方舟還部署了可信數(shù)據(jù)訪問代理系統(tǒng)，進一步加強了數(shù)據(jù)的隔離性和安全性。

系統(tǒng)不僅能確保數(shù)據(jù)請求的來源和權(quán)限檢查，還能防止容器中的數(shù)據(jù)未經(jīng)授權(quán)發(fā)送到外部環(huán)境。

這一設(shè)計就像海關(guān)檢驗程序，每一個進出任務(wù)隔間的數(shù)據(jù)請求都要經(jīng)過嚴(yán)格審查，任何未經(jīng)授權(quán)的數(shù)據(jù)傳輸都會被攔截。

這種多層級的防護策略，使得用戶數(shù)據(jù)即便在任務(wù)隔間內(nèi)部也處于嚴(yán)格的監(jiān)控之下。

操作可審計

這一步驟的核心在于實現(xiàn)“可驗證的安全性”，讓所有涉及數(shù)據(jù)的操作都能被完整記錄，并在必要時追溯來源。

操作可審計主要通過“審計日志”功能來實現(xiàn)。

每當(dāng)用戶的數(shù)據(jù)在平臺內(nèi)被訪問、傳輸、處理或刪除時，系統(tǒng)會自動生成詳細(xì)的操作記錄。

這些日志如同“監(jiān)控錄像”，詳細(xì)記錄了操作的時間、操作人、操作內(nèi)容和操作結(jié)果。

就好比“數(shù)據(jù)使用的完整痕跡”，用戶可以像檢查銀行賬單一樣審查自己的數(shù)據(jù)是否在未經(jīng)授權(quán)的情況下被訪問或操作。

這種設(shè)計不僅提升了數(shù)據(jù)的安全性，還增強了用戶對平臺的信任。

此外，火山方舟的審計日志設(shè)計遵循“透明可信”的理念。

用戶可通過方舟控制臺隨時查看自己的數(shù)據(jù)操作日志，了解自己的數(shù)據(jù)在平臺上的流轉(zhuǎn)情況。

火山方舟還提供了多重驗證機制，用戶可以將平臺的操作日志與自己系統(tǒng)的操作記錄相對比，以確保數(shù)據(jù)處理的真實、準(zhǔn)確性。

這種交叉驗證機制類似于“多重備份驗證”，讓用戶更放心地監(jiān)控數(shù)據(jù)安全。

同時，火山方舟的審計日志不僅記錄了標(biāo)準(zhǔn)操作，還能夠標(biāo)記異常操作并自動觸發(fā)警報。

如果出現(xiàn)越權(quán)訪問或操作不當(dāng)?shù)那闆r，系統(tǒng)中的監(jiān)控指標(biāo)會立即發(fā)生變化。

這一設(shè)計如同銀行的“風(fēng)險預(yù)警系統(tǒng)”，任何可疑操作都會在第一時間被標(biāo)記，用戶能清晰看到平臺在安全保護上的責(zé)任與能力。

總而言之，在火山平臺這里，數(shù)據(jù)所到之處，處處都是安全措施。

不僅要“Don’t be evil”，更要“Can’t be evil”

在與吳迪的交流過程中，他還特別提及了內(nèi)部每隔幾天便會上演“火山方舟與藍軍攻防”的安全機制。

這個機制不僅是火山方舟對內(nèi)部系統(tǒng)進行嚴(yán)格檢驗的方式，更是確保平臺始終處于最佳防御狀態(tài)的一項重要實踐。

通過這種攻防演練，火山方舟團隊能夠模擬真實的攻擊環(huán)境，檢測安全系統(tǒng)的穩(wěn)健性，及時發(fā)現(xiàn)和修補潛在漏洞。

這種演練源自軍隊訓(xùn)練，藍軍模擬攻擊，火山方舟防守阻止。

藍軍由專業(yè)內(nèi)部團隊組成，模擬密碼破解、權(quán)限提升、數(shù)據(jù)竊取等網(wǎng)絡(luò)攻擊，嘗試突破平臺防護?；鹕椒街蹌t負(fù)責(zé)監(jiān)測、識別并阻止這些入侵，采取實時監(jiān)控、迅速響應(yīng)和修復(fù)漏洞等措施。

這種演練包括日常、小型和大型攻防演練。小型演練每月或每兩月一次，大型演練每季度或半年一次，通常聯(lián)合外部白帽團隊進行，以模擬更復(fù)雜的攻擊場景。

吳迪指出，這種機制幫助團隊不斷發(fā)現(xiàn)并修復(fù)安全隱患，提升應(yīng)對真實攻擊的能力。

并且已成為火山方舟安全體系的重要組成部分，不僅提高了團隊的安全意識和技術(shù)水平，也讓用戶感受到平臺在安全保障上的持續(xù)努力。

在談到眾多環(huán)節(jié)中哪個才是最重要的，在吳迪認(rèn)為，內(nèi)部人員的操作是安全風(fēng)險的一個重要根源。

而這也正是我們剛才提到的，火山方舟引入了可信代理和堡壘機的雙重管理機制的原因所在，可以確保所有運維人員的操作都經(jīng)過嚴(yán)格的權(quán)限申請并全程錄屏。

吳迪還提出，火山方舟的安全理念正在從“Don’t be evil”向“Can’t be evil”演進。

所謂“Don’t be evil”意味著平臺通過可驗證的安全審計結(jié)合加密隔離等技術(shù)，確保除了用戶之外的任何一方，包括平臺內(nèi)部人員，如果違反數(shù)據(jù)安全策略，都能夠被第一時間發(fā)現(xiàn)并追責(zé)。

而“Can’t be evil”則意味著平臺將通過進一步的技術(shù)手段，使得惡意行為從根本上不可實施，這包括可信度量技術(shù)、以及泌態(tài)計算等技術(shù)的應(yīng)用，能夠主動減少攻擊面，并且提升用戶數(shù)據(jù)隱私保護級別。。

并且火山方舟的安全能力，是從第一天就開始建設(shè)，像鋼筋水泥一樣澆筑在產(chǎn)品里，而不是先蓋好房子又裝修。從下面這張圖的時間線中便可一目了然：

展望未來，吳迪認(rèn)為生成式AI技術(shù)的發(fā)展速度極為迅猛，這也給安全防護帶來了前所未有的挑戰(zhàn)。

特別是在多模態(tài)生成式AI應(yīng)用場景中，例如視頻、音頻等多種輸入與輸出模式下，如何在技術(shù)復(fù)雜性不斷增加的情況下維持高標(biāo)準(zhǔn)的安全性，是未來的重大挑戰(zhàn)之一。

他表示，火山方舟將繼續(xù)探索加密硬件技術(shù)、跨行業(yè)聯(lián)合安全方案等新興技術(shù)，以確保在技術(shù)快速發(fā)展和用戶體驗之間實現(xiàn)最佳平衡。

而在我們問及吳迪，在搞安全的過程中，是否有令他印象深刻的故事時，他這樣回答道：

我們沒有故事，要有故事就成事故了。

總而言之，縱觀火山方舟的整體安全互信方案，是已經(jīng)做到了“科技道路千萬條，安全第一條”。

參考鏈接：
[1]https://www.youtube.com/watch?v=zb0q5AW5ns8&t=3s
[2]https://mp.weixin.qq.com/s/dLY3gH165TbdP4KqTXHXjw