讓我們正視現(xiàn)實吧。服務(wù)供應(yīng)商們通常不愿為用戶提供無縫切換機制，畢竟把用戶拱手送給競爭對頭實在不是那么令人痛快。但客戶則很有可能并沒有足夠地意識到，服務(wù)供應(yīng)商同樣有能力且確實會設(shè)下種種障礙留住消費者——無論這個供應(yīng)商有多粗心大意。也就是說，他們很容易就能通過設(shè)計刻意提高交接工作的難度，借以提高客戶對自己的依賴程度(也就是所謂用戶‘粘性’)。

 

這種情況在云計算領(lǐng)域當然同樣存在：再次強調(diào)，即使是表面上并不工于算計的云服務(wù)供應(yīng)商有時也會故意增加交接流程的難度，而最常見的手段之一就是安全控制。

 

安全控制的目的在于限制使用者對數(shù)據(jù)的訪問方式，而這往往成為服務(wù)供應(yīng)商最有力的擋箭牌。“安全要求”這一借口堪稱屢試不爽之法寶，有了這面大旗、供應(yīng)商就可以堂而皇之地拒絕(有時是不能、有時是不愿)為用戶提供關(guān)鍵性數(shù)據(jù)模塊，并最終達成阻撓平穩(wěn)交接的目的。

 

有鑒于此，我們需要通過一系列問題來弄清當前安全控制架構(gòu)的具體情況，這樣才能避免陷入云計算供應(yīng)商們的“留客”陷阱。大家不妨通過以下幾個問題及對應(yīng)策略幫助自己擺脫已購服務(wù)及相關(guān)數(shù)據(jù)的糾纏，從而按照預(yù)定計劃調(diào)整業(yè)務(wù)流程。

 

 

頭一個重要議題，同時也是不容含糊的內(nèi)容——我們發(fā)送至服務(wù)供應(yīng)商處的數(shù)據(jù)到底該歸誰所有?除非大家在服務(wù)合約上明確規(guī)定了生成數(shù)據(jù)的所有權(quán)劃分，否則這個問題的答案恐怕比我們的想象更加復(fù)雜。信譽顯著的服務(wù)供應(yīng)商會將數(shù)據(jù)的所有權(quán)毫不猶豫劃歸用戶，但事實上并不是每家供應(yīng)商都如此注重信譽。請大家務(wù)必在合約中注明，由業(yè)務(wù)流程生成的所有數(shù)據(jù)在協(xié)作周期內(nèi)都歸用戶方所有，這非常重要。

 

 

假如我們已經(jīng)明確了自己對于數(shù)據(jù)的所有權(quán)，接下來的問題就是：服務(wù)供應(yīng)商將以怎樣的形式向用戶返還數(shù)據(jù)?返還數(shù)據(jù)又會采用何種格式?我們發(fā)現(xiàn)當合作關(guān)系結(jié)束之后，供應(yīng)商往往會以相當麻煩的格式將數(shù)據(jù)提交給用戶，導(dǎo)致大家無法輕易加以使用。舉例來說，專門尋找一種用戶不具備的工具制作出備份磁帶。為了避免這一難題，我們需要在合約中明確數(shù)據(jù)應(yīng)以哪類格式進行返還，而且***是那種無論何時都能輕松使用的格式。另外，通過測試確保供應(yīng)商有能力滿足約定，這樣才能避免在實際過渡時發(fā)生意外事故。

 

 

請注意，包括加密在內(nèi)的多種數(shù)據(jù)安全控制機制都能防止用戶對數(shù)據(jù)進行邏輯訪問，即使數(shù)據(jù)的歸屬權(quán)并無爭議。舉例來說，如果數(shù)據(jù)本身經(jīng)過加密，我們是否有權(quán)訪問加密密鑰?再次強調(diào)，請務(wù)必通過測試確保自己對數(shù)據(jù)擁有訪問能力。特別強調(diào)：請注意那些可能在特定元素中采取列級加密(column-level encryption)的數(shù)據(jù)庫結(jié)構(gòu)。因為***，這一特性可能不會在信息輸出時被馬上察覺;第二，一旦加密機制被部署至應(yīng)用程序?qū)?，我們將只能通過供應(yīng)商手中的密鑰方可訪問。大家不妨考慮自己保留一份密鑰(當然，前提是安全得到保障)，這樣當供應(yīng)商不再提供服務(wù)時，我們就不必把寶貴數(shù)據(jù)的命運交由態(tài)度消極的前合作方加以擺布。

 

 

對于基礎(chǔ)設(shè)施即服務(wù)(簡稱IaaS)領(lǐng)域，當數(shù)據(jù)成為虛擬鏡像的一部分時，大家需要確保自己同時擁有對應(yīng)用程序與底層操作系統(tǒng)進行管理員級訪問的能力。一旦失去管理密碼，我們不僅很難訪問系統(tǒng)、甚至對物理硬件也會失去控制。因此如果供應(yīng)商將數(shù)據(jù)以虛擬機鏡像形式返還，請保證自己能夠真正訪問服務(wù)的操作系統(tǒng)及應(yīng)用程序?qū)印?/div>