https://newera17031.activehosted.com/index.php?action=social&chash=19de10adbaa1b2ee13f77f679fa1483a.2906&nosocial=1
https://newera17031.activehosted.com/index.php?action=social&chash=19de10adbaa1b2ee13f77f679fa1483a.2906&nosocial=1

觀點

資料在雲端?談雲端儲存的安全性議題

2011 / 10 / 27
紀博文
資料在雲端?談雲端儲存的安全性議題

過去,「無所不在的運算」(Ubiquitous Computing)只是一個概念性的口號,但今天卻透過雲端運算的相關技術而得以實現。而在眾多的雲端服務裡面,儲存服務應該算是最被使用者喜愛的服務,只要將資料儲存到雲端上,不管什麼時候、什麼裝置都可以存取到所需要的資料,再也不用煩惱同步問題以及資料攜帶的麻煩。常見的雲端儲存服務有Dropbox[1]Amazon S3[2]iCloud[3]等。

 

儘管在雲端儲存的架構下帶給使用者更大的便利,同時卻衍生了新的問題。過去個人的資料都是由自己保管,所以資料安全的責任都在自己身上;一旦將資料交由第三者幫忙儲存,又怎麼能保證對方一定會妥善保管資料安全?出問題的時候,到底是該由誰來負責呢?種種的議題都非常得探討與深思。本文將探討公有雲端儲存系統所會遇到的各種安全性議題,同時也會介紹目前相關的技術,最後以筆者的看法作個總結。

 

 

資料保密性

 

使用雲端儲存服務時,必須要有一個正確認知,那就是所有的資料都是交由第三方幫忙儲存,這也意味著雲端服務的提供商有能力去窺探資料。舉個例子來,當我們在使用Gmail的郵件服務時,往往可以看到旁邊會出現跟郵件容相關的廣告,這就是Google看」了郵件容證據,如圖一所示(在這裡雖然使用了「看」一詞,主要是表示Google確實有瀏覽一封郵件的容,可是按照Google的服務條款[4],它確實有權這樣)。其實並不單單只有Google這樣雲端同步軟體供應商Dropbox的隱私協定中也明確提到,他們有權可看到資料容(當然囉,按照合約上的寫法,是只有極少數的人在極少數的情況下才可觀看資料容)。

 

圖1、Gmail的截圖。從右邊的廣告來看,很明顯的看出Google確有瀏覽信件容。

 

 

那麼加密的話如何呢?最直覺的方法就是將資料先進行加密,然後再儲存到雲端系統上,如此一來,雲端儲存供應商也無法觀看資料的容了,當然假設前提是使用者有好好保管金鑰沒有遺失。然而這樣的作法雖然簡單,但在實行上卻存在下問題:

 

金鑰管理上的麻煩

 

明之前先來看看使用加密機制的一種使用情境,以便於了解這個機制的一些問題阿明將電腦上的mp3案放到雲端儲存空間上,希望之後透過網路就可以到處欣賞自己喜歡的音樂。結果當想要透過智慧型手機聽音樂時,手機的螢幕上卻顯示:「請輸入解密所需要的金鑰」,阿明只好透過SD卡將金鑰由電腦拷貝到手機上(這時候的金鑰傳遞可不能透過網路空間,不然金鑰被雲端儲存供應商知道了不就跟沒加密一樣嗎?);等阿明到公司以後,想在閒暇之餘利用公司電腦聽聽音樂,他才發現他居然要把之前拷貝的動作再做一遍,他開始思索把音樂放到雲端跟把音樂放到SD卡帶著走到底有什麼不同.

 

雲端服務最大的優勢之一就是無所不在的運算能力,不管透過甚麼樣的終端設備,只要能連上網路就能存取服務、資料。一旦資料進行加密了,當使用者想透過不同設備存取雲端資料時,他必須先把該資料所會用到的金鑰傳輸到不同的設備上,這樣才能解開下載的加密資料進而觀看裡面的容,某種程度上這樣的行為抹煞了雲端儲存的優點,因為使用者不再是隨處都能存取資料的態,相反地,他還必須隨身攜帶必要的相關資料(如上述例子提及的金鑰)。

 

此外,當儲存的案數目大到一定程度的時候,所需要的金鑰數目也非常可觀。的確,使用者是可以利用同一把金鑰加密所有儲存於雲端的資料,這是一個方便的作法,不是一個好的使用習慣。當金鑰不小心遺失的時候,所有透過這把金鑰加密的資料全部都有外洩的風險如果資料都使用不同的金鑰,那麼金鑰的管理就是一件令人非常頭大的事情。儘管市面上有非常多的帳金鑰管理軟體,但是這軟體的特性就是只給使用者自己使用,在公用電腦上並不合適,且在不同裝置之間進行同也很麻煩。那,能不能把金鑰的管理也交給雲端服務來呢?當然可以,像是1Password[8]就可以配合Dropbox提供這樣的服務,但前提是使用者必須要完全信任該雲端服務供應商。不過話又回來,如果要信任某個雲端供應商,何不就直接信任提供雲端儲存服務的供應商呢?那這樣就不需要對資料進行加密了。

 

雲端上的資料處理服務

 

很多時候,雲端儲存服務並不是單單提供資料儲存的服務,還會更進一提供資料處理的功能,如Google docs[5]Microsoft Office Live[6]DropTunes[7]等。但如果資料被加密起來,雲端服務供應商看不到資料的容,那這些資料又如何能被處理呢?其實在密碼學的領域中確實有一種技術能解決這樣的問題,就是同代加密演算法(Homomorphic Encryption)。所謂的同代加密就是能對加密中的資料進行運算,並且在解密過後的資料上生對應的效果。我們可以利用加密演算法來運算。所代表的意義是,就算雲端儲存供應商不知道使用者的秘密金鑰,只要以儲存在它那邊的資料,也就是,配合上配對的運算功能,那麼雲端服務供應商依舊可以對資料進行處理並提供相關的服務。其實,有這樣特性的加密演算法並不少見,最常見的一種就是RSA的公開金鑰加密演算法。

 

要加密雲端的資料不是不可行,只是會大大降低雲端儲存的便利性。那回到最原始的話題,到底雲端儲存需不需要加密的功能呢?其實這個問題要回到使用者的基本需求,到底使用者希望把甚麼樣的資料儲存在雲端上?如果是相當機密的資料,那放在雲端上保險嗎?反過來,如果並不是敏感的資料,那有必要用加密這種難以管理又有一堆麻煩的方式嗎?其實這個問題都必須回到使用者自己身上,到底使用者本身有多在意資料的安全性。資訊安全本身跟使用的便利性本質上是衝突的,使用者要自己去決定是否要加密雲端上的資料,或是要信任雲端儲存的供應商。


雲端資料管理的可信度

 

上面的章節我們談到的是資料的保密性,接下來我們要探討的則是儲存在雲端的資料管理問題,包含案的驗證以及案的刪除。


 

案是否真的被好好儲存?

 

gmail推出以來,電子信箱的容量越來越大。Google也在這樣的趨勢下,提出了「封存郵件」的概念。所謂的封存,意思是使用者不用再刪除郵件了(因為空間大),只要把很久以前的信件塵封起來,乍看之下,因為看不到該郵件了,就好像是刪除一樣,等有需要時候仍然可以透過「搜尋」的方式把該封郵件找出來。問題來了,你怎麼知道「封存」的郵件是真的存在呢?還是有沒有可能Google為了節省空間,而把封存已久都沒有存取的郵件給偷偷刪除了呢?再想想看另外一個情況,今天Amazon提供了雲端儲存的服務,當有問題發生的時候(像是之前Amazon在愛爾蘭的Data Center發生了一些問題),Amazon會不會為了自家公司的信譽而隱瞞資料遺失的情形呢?上述的情形純屬假設的情況而不代表那些公司會這麼,只是站在一般使用者的立場我們確實可以對雲端儲存服務供應商提出我們的疑問。

 

要確認自己的資料是否被正確的儲存,最簡單的方法就是把所有的資料下載下來,並且一份一份的檢視資料的正確性。然而這卻是不切實際的作法。案少的時候或許還好處理,一旦在雲端儲存的案過多的話,怎麼可能將這麼龐大的資料從網路上下載下來再一一檢視?不管是網路下載或是人工都很不合成本,更不用這樣的檢應該要是定期的,花費的力氣將會更大。


目前有許多的研究來討論如何解決這個問題,也就是PDP(Provable Data Possession)證明有正確擁有資料的方式。這些研究最早是從資料庫的領域出發,現在被運用到雲端儲存系統上面。PDP常見的流程如圖2

 

圖2、PDP的基本流程。

 

當使用者想要將資料儲存到雲端儲存空間時,首先會計算資料的特徵值並加以儲存在本機端,之後再對資料進行必要的修改,然後傳送到雲端儲存空間儲存。在這裡所謂的「必要修改」一般指的是多加上一些額外的資料,這些資料將在驗證的時候用來計算擁有資料的「證據」。在這裡要特別強調的是,一旦使用者將資料上傳到雲端後,我們就假設資料會從使用者的本機端移除(不然也不需要使用雲端儲存了),也就是使用者除了之前計算出來的特徵值以外不會有本來的資料。當使用者要驗證資料是否被正確儲存時,使用這會先生一組挑戰傳給雲端儲存伺服器,雲端儲存伺服器就會根據這組挑戰以及之前使用者多塞的一些資料,計算出一組證據回傳給使用者。使用者會將證據和特徵值進行比對,如果比對通過的話,則代表雲端儲存供應商有好好地保存資料,如果沒有的話就代表雲端儲存供應商那邊的資料是有問題的。當然上述的流程還有許多的變形,像是將特徵值儲存在另外一個雲端服務提供者,這樣可以減輕使用者自我管理特徵值的麻煩。而特徵值的計算也有各式各樣的方法,像是透過RSA的機制,或是透過Pairing的密碼學基礎等,這裡就不再加以描述。

 

刪除案?

 

上一小節在討論的是案是否有好好地被儲存在雲端,這一小節則是要討論另一個相反地問題,當使用者刪除了儲存在雲端的資料時,有沒有辦法確認資料真的已經被刪除了呢?像是雲端儲存供應商有沒有可能謊,沒有刪除資料卻回覆使用者資料已經被刪除了;或者是雲端儲存供應商因為有將資料進行多份的儲存機制(如Amazon,或是像Google所使用的The Google File System[10]),有沒有可能有漏刪掉其中某一份儲存的資料呢?這個問題對使用者來很難確認,因為所有的機制都掌握在雲端儲存供應商那邊。一個很直覺方法是,將要儲存的資料用金鑰加密,然後把加密後的資料傳送到雲端儲存空間,金鑰則保留在使用者自己手上。當資料刪除的時候,除了通知雲端儲存服務供應商刪除資料以外,也把自己手上對應的金鑰刪除。這樣一來,即便雲端儲存服務供應商沒有真的刪除資料,因為金鑰已經被刪除了,所以也沒有人能解開這組資料(金鑰遺失或是密碼系統被破解不在討論範圍)。

 

使用這個機制最大的麻煩,其實就在之前所討論的容裡面已經描述過了,主要就是金鑰的維護是一件很不方便的事情。為了解決這個問題,美國華盛頓大學發展了一套機制,叫做Vanish[11]Vanish最大的好處就是利用分散式的方式來儲存加密資料的金鑰,並且賦予金鑰一定的生命週期。這套機制所用的技術叫做分散式雜湊表(DHT, Distributed Hash Table)

 

DHT最常被用在下載技術,如BT或是Kad等。透過一個雜湊表的對應將資料分散傳播到網路的各個地方,而要取得資料的時候再將眾多的資料塊取得回來組合。Vanish處理金鑰的方式就是這樣,一開始金鑰會被分散成各小部份,然後分散到網路的各節點上,當要讀取資料的時候,會再到各節點去取回、組成金鑰,再進行資料解密(見圖三)。而當一段時間沒有人存取金鑰的話,各節點會把自己所有的一小部份金鑰刪除,一旦無法構成完整的金鑰,就意謂著資料已經被安全的刪除了。這種方法可以簡化管理上的麻煩,同時也利用了雲端的特性,把金鑰存到網路上而不用單單保存在本機端,最妙的是,雖然金鑰儲存在網路上,但由於個網路節點所擁有的不過是部份金鑰,所以除非所有節點合起來共謀洩漏金鑰,不然只有金鑰的一部分還是無法取得資料。

 

 

資料遺失的責任歸屬

 

上面幾節都在討論雲端儲存一些技術上的問題,甚至還提到了如何驗證資料真的有被好好存在雲端的相關技術。但當資料遺失的時候該找誰負責呢?或者,能找誰賠償呢?在這一小節裡,我們要略過技術上的問題,來看看幾個雲端儲存服務供應商所提供的合約怎麼。不過在這邊要先特別明一點,大部分的雲端儲存服務供應商都有完善的備援機制,所以資料遺失事件理論上是不太容易發生的,在這裡我們的討論純粹是集中在「如果真的不幸發生的話怎麼辦?」

首先來看看Dropbox的部份:

You, and not Dropbox, are responsible for maintaining and protecting all of your stuff. Dropbox will not be liable for any loss or corruption of your stuff, or for any costs or expenses associated with backing up or restoring any of your stuff.[12]

 

上面的條文意味著什麼呢?簡單來Dropbox不會為你的資料作任何備份的動作,這個動作要由使用者自己完成,並且Dropbox不負任何資料遺失的責任。再來看看Amazon的部份:

Data that is maintained within running instances on Amazon EC2, or within Amazon S3 and Amazon SimpleDB, is all customer data and therefore AWS does not perform backups.[13]

很明顯的,Amazon也不會為資料作備份。這也暗示了資料遺失的風險是使用者自己要承擔的。而Dropbox的服務是架構在Amazon的儲存服務上,所以囉,Amazon沒有提供的服務Dropbox自然也無法提供。有讀者可能會從Amazon的文件看到下面一句話:Data stored in Amazon S3, Amazon SimpleDB, or Amazon Elastic Block Store is redundantly stored in multiple physical locations as a normal part of those services and at no additional charge.而覺得Amazon有進行備份的工作,但其實這段話代表的只是Amazon資料的儲存方式是多點儲存,以避免單一儲存點壞掉的情況,但如果使用者資料有遺失的時候依然不在Amazon的賠償範圍裡面。

 

最後再來看看Google的相關條款[4]

Google、其子公司及關係企業,及其授權人,就以下事項並未向台端作出聲明或保證
(A)  
台端對服務之使用將符合台端需求;
(B)  
台端對服務之使用將不受中斷,且及時、安全、無錯誤

(C)  
台端因使用服務而獲得之任何資訊,皆屬準確或可靠;及

(D)  
台端連同服務獲得提供之任何軟體所發生之操作或功能瑕疵將獲得改正。

 

很明顯我們可以看到,Google也不對資料的可靠性作任何的保證。那資料遺失的責任歸屬到底該歸誰呢?從上面的例子來看,風險都要由使用者自己承擔,雲端儲存服務供應商並不會承擔責任,畢竟所有使用者在使用服務前都有簽署「我同意」。所以,儘管雲端儲存很方便,但使用者自己的備份還是不可少的。

 

 

結論

 

此篇文章,筆者分析了雲端儲存相關安全性的問題,乍看之下似乎對雲端儲存服務並不是相當的信任,但事實上,筆者依然有在使用上述的雲端服務。理由很簡單,就是「方便」兩個字。因此,比較好的使用方法,應該是先將資料進行分類,將比較不重要的資料放在公有雲上,比較私密的資料則放在私有雲上。當然,這樣的前提是一般用有能力架設並自行管理私有雲的服務。所以還是回到最原始的問題──「安全」和「便利」

 

(本文圖片皆由作者提供,作者任職於網路通訊研究機構。如您對本文有任何感想,歡迎來信交流:isnews@newera.messefrankfurt.com〉