在企業IT網絡通信領域中，安全一直是用戶非常關注的話題。云計算、大數據及移動化讓企業的安全形勢變得更加復雜和嚴峻。然而，云計算、大數據及移動化是大勢所趨，也的確能大大降低企業的成本和提高企業的效率，改變企業的運營方式和思維方式，所以，很多企業在考慮向云計算遷移，但又顧慮重重，考慮最多的是安全問題。任何事物都具有兩面性，云計算也不例外，但不能因噎廢食，特別是在這個技術飛快發展的時代，如果不及時抓住技術的趨勢，充分地利用技術，就可能在激烈的競爭中很快失去優勢。那么，如果向云計算遷移，如何揚長避短呢?云計算存在哪些不安全因素呢?在向云計算遷移的過程中應該注意些什么呢?在向云計算遷移的過程中應該采取哪些安全策略呢?本文將和大家分享向云計算遷移過程中的一些安全思路和做法。供大家參考，并歡迎補充。
一、知己知彼 明察秋毫俯瞰云計算不安之因素
兵家有云：知己知彼，百戰不殆。企業用戶在向云計算遷移前，也需要全面了解自己的需求，明察秋毫，以全局的眼光充分認識云計算的安全風險和不安全因素，做好充分的準備來應對、抵抗和消除安全風險，使自己心中有數，有備無患。下面列出了一些云計算的安全風險和不安全因素，以供企業用戶了然于胸。
云服務提供商采用的安全標準不統一，這使得企業用戶在選擇時很迷惑。
沒有經過充分了解和評估云計算服務提供商的系統環境和相關風險，就貿然采用云服務。
云計算和移動化讓整個企業的安全邊界就沒有了，使數據分散在多個設備和云服務中，這樣企業的數據存儲就很混亂，面臨著數據丟失和永遠失去知識產權的風險。
沒有選用恰當的云模式。
賬戶或服務流量被劫持。
分布式拒絕服務(DDoS)。
不安全的云API會帶來多種風險。
SAS 70標準已經不適用于高速發展的云服務，而且它最初的設計目的是監督企業遵守財務報告規則。
對于多租戶云服務來說，如果數據庫設計不合理，只要有一個用戶的應用程序存在一個漏洞，就可以讓攻擊者獲取這個用戶的數據，甚至還能危及到其他用戶。
不靠譜的云服務提供商或者不可抗拒的災難可能導致用戶的數據丟失。
為了綁定用戶，云服務提供商往往不為用戶提供無縫切換機制，經常用安全控制的借口拒絕為用戶提供關鍵性數據模塊，增加交接的困難。
不懷好意的內部人員破壞性地訪問網絡、系統或數據。
完全依賴云服務供應商的安全性，沒有將云服務供應商的安全策略與企業本身的安全策略結合到一起。
沒有做好監督工作。
很多企業制定了詳細的云安全策略后，就將其束之高閣了，再也不去修改其內容了，這是一個非常嚴重的錯誤，往往使企業遭遇安全問題。
二、步步為營 有的放矢保障云計算安全之策略
充分認識了云計算的安全風險和不安全因素之后，就可以步步為營，有針對性地逐一制定安全策略，有的放矢，保障云計算安全。下面列出了一些讓云計算更安全的方法和策略。供大家參考，并歡迎補充。
在向云計算遷移之前，做好充分地準備，進行充分地調查和評估。
通過可靠的安全標準對云服務提供商進行安全評估。規模最大且參與者眾多的安全標準機構是CSA(Cloud Security Alliance)，即云安全聯盟。
當對云服務提供商進行評估時，如果云服務提供商能夠保證一個審計標準，這樣要好于只聽供應商一面之詞。
評估云服務提供商時，不要把重點放在SAS 70認證上。
在對云服務提供商進行評估時，要對基于云的系統進行安全評估和審計，這個過程必須包括：網絡和系統漏洞評估、服務器/工作站/移動設備合規性評估、云/管理程序基礎設施評估。
企業用戶需要確保在服務水平協議中云服務提供商有自己的業務連續性、備份和災難恢復計劃，并確保該協議涵蓋恢復時間目標/恢復點目標(RTO/RPO)以及性能和帶寬基線要求。
在向云計算遷移之前，企業用戶需要考慮的因素有：企業用戶希望遷移到云中的應用程序的關鍵程度、合規問題、必需的服務水平、負載的使用模式，以及應用程序與其它企業功能的集成程度。
企業需要全面調查云服務供應商的安全技術和過程，并檢查云服務供應商如何保障企業數據及他們自己的基礎架構的安全。企業尤其需要關注如下方面：
應用程序和數據的可移植性：供應商是否允許企業將現有的應用程序、數據和過程導出到云中?能輕松地將這些導回來嗎?
數據中心的物理安全性：云服務服務供應商如何從物理上保護其數據中心?他們使用哪種類型的數據中心?他們的數據中心操作員得到過怎樣的培訓，有什么技能?
訪問和操作的安全性：云服務供應商如何控制對物理機器的訪問?誰能夠訪問這些機器?它們如何管理這些機器?
虛擬數據中心的安全性：云架構是效率的關鍵。企業應當查明獨立的組件(如網絡節點、存儲節點等)是如何構建的，還要調查這些組件的集成和安全保障方法。
應用程序和數據的安全性：云解決方案必須支持由企業自己定義組、角色，要有精細的基于角色的訪問控制，還要有正確的口令策略和數據(靜態數據和傳輸的動態數據)加密。
通過一些問題弄清楚云服務提供商安全控制架構的具體情況，避免陷入云計算提供商們的“留客”陷阱。其中的問題包括：
企業用戶發送到云服務提供商處的數據到底該歸誰所有?企業用戶一定要在合同中注明，由業務流程生成的所有數據在協作周期內都歸用戶方所有，這非常重要。
云服務提供商如何將數據返還給用戶?企業用戶需要在合同中明確數據應以哪類格式進行返還，而且返還的數據格式最好無論何時都能輕松使用。通過測試確保云服務供應商有能力滿足合同中的約定。
企業用戶能真正訪問數據嗎?如果數據本身經過加密，企業用戶是否有權訪問加密密鑰?企業一定要通過測試確保自己對數據擁有訪問能力。
資源訪問如何處理?對于基礎設施即服務(IaaS)領域，當數據成為虛擬鏡像的一部分時，企業用戶需要確保自己同時擁有對應用程序與底層操作系統進行管理員級訪問的能力。
能否訪問用戶數據?如果云服務提供商打造了一套用于容納用戶信息的數據存儲體系(包括用戶ID、角色、權限以及身份驗證信息等)，企業用戶自己也需要建立同樣的體系，確保自己有能力將包括用戶信息在內的所有備份數據重新導入服務流程，因為這部分數據很可能被單獨保存在應用程序數據之外。
參考其他客戶的評價和意見。
對云服務進行反復測試。
選用適當的云模式。
企業用戶需要將數據恢復時間、恢復點內容以及數據完整性評估方法都列入服務水平協議中，并明確列出懲罰措施。
與云服務提供商簽訂的安全條款內容應盡可能詳細，將防止未授權訪問、安全標準年度認證以及定期的漏洞測試等內容都以明文的方式列入合同。
將云安全與企業自身的安全策略結合到一起。
在為云計算修改安全策略時，企業需要考慮的因素有：數據存儲在哪里、如何保護數據、誰可以訪問數據、合規問題、服務等級約定(SLA)等。
分析云API的安全性。通過云服務提供商的API文檔，確定其API安全性;通過安全的渠道保護傳輸的安全，如SSL/TLS 或IPSec;進行身份驗證與授權，可以通過提問一些問題來驗證，如：API可以管理用戶名和密碼的加密嗎?可以管理雙因素身份認證屬性嗎?可以創建并維護細粒度的授權策略嗎?內部身份管理系統和屬性之間具有連續性嗎?以及內部身份管理系統和云提供商提供的API擴展屬性之間具有連續性嗎?向云服務提供商提出要求，能夠對API進行滲透測試和漏洞評估。
許多云服務提供商為客戶提供利用API的訪問和身份驗證機制的加密密鑰，保護這些密鑰至關重要。
企業用戶必須確定數據的重要程度，并檢查用于數據傳輸的加密工具是否成熟。
采取集中存儲數據，讓有權限的人可以訪問它，無論員工是否離開公司。
避免將機密數據存儲在云端，關鍵性業務數據及規則性信息最好把握在自己手中。
對靜態的、使用中的和傳輸的數據進行加密。
企業應使用最強健的加密密鑰技術，如同態密鑰管理來強化密鑰的安全，并保護好密鑰以及做好定期的備份。
在云加密問題上，企業必須負起責任，關鍵是定義哪些團隊應為數據的安全負責。
對于已經實施了強加密的數據來說，企業應該僅允許有工作需要的員工訪問，而且要培訓這些員工如何訪問加密數據，可以從什么地方訪問，并要求他們遵循安全規程。
IT部門需要提供簡單易用的工具來替代員工使用的不安全的共享工具來操作數據。
如果企業期望基于云的應用更多地通過共有Wi-Fi熱點訪問，SSL加密應該能夠保護整個信息流。
使用公共密鑰存儲服務或者技術時，要確保密鑰永遠不會用應用代碼或者數據存儲在云端。
將云存儲、數據加密和網站安全手段結合起來，可以為企業防御網絡威脅構建強健的安全陣線。
每年對云服務提供商提供的服務進行第三方安全審計和認證，如果出現數據泄露事故，用戶有權終止云服務合同。
確定雙方的安全責任。
在云服務提供商由于失誤造成企業用戶的安全損失后，確定云服務提供商應該承擔什么責任。
云服務提供商會盡量避免在云服務合同中承擔任何賠償責任，頂多是延長服務期限，在這種情況下，企業應該將抵償的服務期限延長到24-36個月，而不是常見的12個月。
京公網安備 11010502049343號