針對云計算中敏感數(shù)據(jù)存在的安全問題，在B/S的使用場景下，提出了一個基于http代理的數(shù)據(jù)加密上傳服務(wù)設(shè)計方案。在http協(xié)議層架設(shè)一個對用戶透明的代理，實現(xiàn)對用戶上傳的本地數(shù)據(jù)進行加密，然后再傳送到云端，這樣在云端保存的將是加密后的數(shù)據(jù)，如果無法正確解密，這些密文即使泄露出去也不會泄露太多的信息量，降低了云計算數(shù)據(jù)存儲服務(wù)中的數(shù)據(jù)安全風險。

一、云中數(shù)據(jù)存儲的安全風險

把數(shù)據(jù)存儲在云端，并由此衍生的服務(wù)可以有很多形式，不過都要遭受同樣的風險，數(shù)據(jù)泄露。由于用戶的數(shù)據(jù)都保存在云端，所以云服務(wù)提供商就擁有了對數(shù)據(jù)的優(yōu)先訪問權(quán)，以下幾種原因可能導(dǎo)致用戶的數(shù)據(jù)被泄露出去：

(1)云服務(wù)提供商或者數(shù)據(jù)維護人員惡意出賣用戶數(shù)據(jù)。

(2)數(shù)據(jù)中心遭到攻擊，導(dǎo)致用戶數(shù)據(jù)泄露。

(3)由于數(shù)據(jù)隔離措施的不完善，我們的數(shù)據(jù)可能被我們在云端的“鄰居”非法訪問。

(4)由于云計算本身的安全機制，用戶的數(shù)據(jù)在云端會有多個備份，這也增加了數(shù)據(jù)泄露的風險。

無論哪種原因，只要用戶數(shù)據(jù)泄露出去，都可能對用戶造成重大的人身財產(chǎn)損失，但是用戶一旦把數(shù)據(jù)上傳到了云端，就失去了對數(shù)據(jù)的維護和有效控制，難以找到有效措施去防范數(shù)據(jù)的泄露。所以，用戶不得不面臨以下幾個難題：

(1)本地可能并沒有數(shù)據(jù)的備份，數(shù)據(jù)都在云端。

(2)本地沒有足夠的計算和存儲能力完成對數(shù)據(jù)的加密操作或者不方便安裝數(shù)據(jù)加密程序。

(3)云應(yīng)用服務(wù)不足以信任，也無法向我們證明我們的數(shù)據(jù)已經(jīng)被安全的存儲并且被正確的使用。

這些安全風險的存在對各種云應(yīng)用服務(wù)的發(fā)展將造成不小的障礙和制約。現(xiàn)有的安全機制多是從虛擬化或者資源池層面使用技術(shù)手段來保障數(shù)據(jù)的完整性、隔離性和機密性，而且安全機制的性能也是各個云服務(wù)提供商自己宣稱的。難以給用戶一個切身的數(shù)據(jù)安全得到了保障的體驗。

二、HTTP加密代理部署架構(gòu)

為了提升用戶的“安全感”，本文提出了一個在應(yīng)用層面解決數(shù)據(jù)存儲安全問題的方案，即由可信第三方部署實施一個基于HTTP代理的數(shù)據(jù)加密上傳服務(wù)。該服務(wù)在用戶數(shù)據(jù)上傳到其他云應(yīng)用服務(wù)之前對其進行加密。加密代理的部署架構(gòu)如圖2-1所示：

HTTP加密代理部署在客戶端和云應(yīng)用服務(wù)端之間，對用戶通過瘦客戶端中的瀏覽器發(fā)出的http請求進行過濾和攔截，把用戶要上傳的文件進行加密操作，然后再以客戶端的身份通過http請求把密文上傳到目標云服務(wù)。

三、加密上傳服務(wù)流程

1、上傳處理總體流程

數(shù)據(jù)加密上傳服務(wù)主要包括兩個實體，客戶端(Chent)和代理端(Proxy)。具體流程如圖3-1所示：

主要處理步驟如下：

(1)用戶在上傳附件之前，要先選擇是否使用加密代理。

(2)若不使用加密代理，則按照原本的服務(wù)流程進行，代理端不會截獲客戶端的HTTP請求。

(3)若使用加密代理，則客戶端會把HTTP請求發(fā)送到代理端。

(4)代理端通過網(wǎng)絡(luò)技術(shù)接收到HTTP數(shù)據(jù)包，根據(jù)HTTP數(shù)據(jù)包格式對其進行解析，分析該請求是否用來上傳附件。

(5)若沒有上傳附件，則不改變請求的內(nèi)容，轉(zhuǎn)發(fā)給云應(yīng)用服務(wù)端。

(6)若有上傳附件，則把附件內(nèi)容提取出來，并進行加密，生成密文文件。

(7)用密文文件代替明文文件，重新生成一個httpRequest，發(fā)送到云應(yīng)用服務(wù)端。

(8)接收云應(yīng)用發(fā)回的httpResponse，判斷附件是否上傳成功。

(9)若上傳成功，則把此消息封裝成新的httpResponse數(shù)據(jù)包，發(fā)給客戶端。

(10)若上傳不成功，則可以考慮重發(fā)，或者把解析出的原因（比如服務(wù)中斷）重新封裝成httpResponse，發(fā)給客戶端。

由以上流程可以看出，加密上傳服務(wù)是一個可選的服務(wù)，用戶可根據(jù)需求選擇是否使用。選擇了則可以使用服務(wù)提供的加密上傳的功能，不選擇則跟原本的云應(yīng)用服務(wù)場景沒有差別。

2、核心功能模塊

代理服務(wù)要跟兩個實體進行交互，一個是客戶端，由它發(fā)起上傳附件的請求，代理最終也要把服務(wù)器的響應(yīng)反饋給客戶端；另一個是云應(yīng)用服務(wù)器，代理需要把客戶端發(fā)來的明文轉(zhuǎn)化成密文后，再以云應(yīng)用客戶端的身份把上傳附件的請求發(fā)送到云應(yīng)用服務(wù)器，然后等待服務(wù)器的響應(yīng)消息。

在此過程中，為了保證代理的“中間層”的特點及有效的與客戶端和云應(yīng)用服務(wù)進行交互，并且使模型及各部分功能更加清晰，代理服務(wù)可以分成三個模塊：分別是HTTP數(shù)據(jù)包的接收模塊、加密模塊和發(fā)送模塊。

(1)接收模塊

接收模塊負責接收HTTP數(shù)據(jù)包，包括兩種情況：

(a)接收模塊接收客戶端提交表單時發(fā)來的httpRequest，解析這個數(shù)據(jù)包并判斷是否上傳了附件，若上傳了附件，則進入加密模塊；否則直接進入發(fā)送模塊，把請求轉(zhuǎn)發(fā)給云應(yīng)用服務(wù)器。

(b)接收模塊接收云應(yīng)用服務(wù)器的響應(yīng)httpResponse，解析該數(shù)據(jù)包并判斷附件是否上傳成功。若上傳成功，進入發(fā)送模塊，把該響應(yīng)轉(zhuǎn)發(fā)給客戶端；如果上傳不成功，可選擇進入發(fā)送模塊重發(fā)上傳附件的請求，也可直接把該上傳不成功的響應(yīng)轉(zhuǎn)發(fā)給客戶端。

(2)加密模塊

加密模塊是該加密服務(wù)最主要的部分，它的功能就是完成對上傳數(shù)據(jù)的加密工作。其工作流程如圖3-2所示：當客戶端提交了一個包含上傳附件的HTTP請求時，接收模塊會把解析出的附件內(nèi)容以參數(shù)的形式傳遞給加密模塊。加密模塊要使用合適的加密方法對數(shù)據(jù)進行加密，然后把密文傳遞給發(fā)送模塊。

(3)發(fā)送模塊

發(fā)送模塊負責發(fā)送HTTP消息，包括httpRequest和httpResponse。發(fā)送模塊有三種接入情況：

(a)當客戶端的請求消息中不需要上傳附件的時候，則從接收模塊直接進入發(fā)送模塊，參數(shù)包括目標云應(yīng)用服務(wù)器的url等，把請求消息發(fā)送到云應(yīng)用服務(wù)端。

(b)接收模塊接收到來自云應(yīng)用服務(wù)器的httpResponse，并且分析出附件已經(jīng)成功上傳后，發(fā)送模塊要先獲得對應(yīng)的客戶端url，然后生成一個新的httpResponse，包含此成功上傳消息，發(fā)送到客戶端。

(c)加密模塊對明文數(shù)據(jù)加密并生成密文后，流程進入發(fā)送模塊。發(fā)送模塊從加密模塊獲得密文，從接收模塊獲得目標云應(yīng)用服務(wù)器的url，構(gòu)造httpRequest，發(fā)送到云應(yīng)用服務(wù)器，上傳密文附件。

三、加密技術(shù)設(shè)計

1、加密算法的選擇

現(xiàn)代密碼學(xué)主要包括對稱密鑰密碼學(xué)和非對稱密鑰密碼學(xué)，兩者的不同點如下表所示：

從安全性能、加密效率及密鑰管理等方面考慮，加密代理使用對稱加密中的經(jīng)典加密算法AES。根據(jù)安全領(lǐng)域內(nèi)的研究成果看，AES已基本可以抵御現(xiàn)有的常用攻擊手段，包括強力攻擊、滲透攻擊、XSL攻擊、差分分析及線性密碼分析等；并且加密效率和密鑰管理也要明顯優(yōu)于非對稱加密算法，所以使用AES作為加密代理的加密算法比較合適。

2、包含身份信息的密鑰

數(shù)據(jù)加密上傳服務(wù)使用的加密密鑰跟傳統(tǒng)的隨機產(chǎn)生密鑰的方法略有不同。不同之處在于本設(shè)計在隨機產(chǎn)生密鑰的時候要包含用戶身份信息。采用基于身份的密鑰的原因主要考慮以下幾點：

(1)數(shù)據(jù)加密上傳服務(wù)的使用場景中用戶多是使用瘦客戶端訪問云服務(wù)，由于瘦客戶端對安裝程序的限制，我們很難把密鑰存儲在外設(shè)中，使用的時候再由外設(shè)導(dǎo)入。所以本服務(wù)要為用戶提供密鑰的存儲。

(2)由于云計算多租戶的特性和資源池的使用，使得用戶并沒有一個純粹的自己的用戶空間，所以數(shù)據(jù)隔離是云安全的一個難題。如果數(shù)據(jù)隔離的力度不夠，用戶的隱私數(shù)據(jù)，比如密鑰，就有可能被他的“鄰居”訪問。為了保證密鑰能夠被身份正確的用戶合法的使用，可以在密鑰中加入身份的信息。這樣在密鑰在被使用或者提取之前，可以先對用戶身份進行驗證。

(3)基于身份的認證雖然不是因云計算而產(chǎn)生，卻是云計算中非常重要的認證技術(shù)。所以我們在這種認證技術(shù)保證了用戶合法身份的前提下，把其身份信息加入到密鑰的生成方法中，可以最大限度的保證密鑰的唯一合法性。

基于身份的密鑰的生成算法可以有多種不同的實現(xiàn)方式，不過要保證兩個基本要求：

(1)基于身份的密鑰要支持對用戶身份的驗證，以確保有且僅有一個用戶可以合法的使用該密鑰。

(2)密鑰中的身份信息不能被輕易破譯出來。因為存儲在數(shù)據(jù)中心的密鑰比存儲在外設(shè)中的密鑰泄露的風險大，所以要保證即使加密密鑰泄露了，也不能從密鑰本身破譯出用戶身份。因為前文提到密鑰在使用之前需要對用戶身份進行驗證，所以即使攻擊者非法取得了密鑰，但是他沒有密鑰對應(yīng)的身份信息，依然無法使用該密鑰。

四、方案分析

本節(jié)從安全性、適用性和擴展性三方面來對加密上傳服務(wù)進行分析：

(1)安全性

加密服務(wù)最重要的目標就是保證安全，從應(yīng)用功能層面，本服務(wù)得使用戶的數(shù)據(jù)在進入云應(yīng)用服務(wù)之前完成了加密操作，使用戶數(shù)據(jù)在云中的流轉(zhuǎn)完全以密文的形式，抵御了云端數(shù)據(jù)泄露帶來的安全隱患。從技術(shù)層面，AES加密算法的安全性能從目前的密碼學(xué)發(fā)展程度上看還是很強的。即使密文泄露了，用戶也基本不用擔心隱私信息的泄露。

(2)適用性

加密代理位于云應(yīng)用服務(wù)和客戶端之間，以HTTP代理的形式提供加密服務(wù)?？蛻舳撕驮茟?yīng)用服務(wù)的對外通信依然通過原始的HTTP協(xié)議，不用做出任何改變，所以加密代理保證了對客戶端和云應(yīng)用服務(wù)的透明性。也使得加密上傳服務(wù)變成了一種可選擇購買和使用的服務(wù)，增加了服務(wù)使用的靈活性。

(3)擴展性

應(yīng)用層面上，由于加密代理是針對http請求中的上傳附件做加密操作，并沒有其他特殊規(guī)定，所以只要是提供了上傳附件功能的云應(yīng)用，都可以使用加密上傳服務(wù)來加密上傳的附件。這使得它的應(yīng)用不會局限于某一種web服務(wù)。技術(shù)層面上，加密代理使用的是AES算法，但是隨著密碼學(xué)的發(fā)展，可能會研究出更適合加密代理的算法，或者為了實現(xiàn)更高的安全性，需要把多種加密算法結(jié)合使用，那么只要把加密模塊中的算法實現(xiàn)部分替換成新算法即可。對加密算法的使用實現(xiàn)了彈性的擴展。

admin

收藏 海報分享