作為一個概念來說，的定義是非常模糊的，很多希望對其界定的嘗試最終都失敗了。但是，我們又必須使用到它。畢竟，它是存在商業(yè)價值的，如果被忽略，就會影響到競爭優(yōu)勢的增加。因此，我們需要了解如何將這一新興技術安全地融合到自身的業(yè)務流程中。
對云進行準確定義
為了讓概念更清晰，方便大家的理解，我將云計算定義為由第三方提供的為業(yè)務流程提供技術支持或者服務的所有基礎設施或服務。為了在最大程度上提高商業(yè)價值，這其中也應該包括按需擴展性和增強的業(yè)務流程連續(xù)性。舉例來說：
供應商開發(fā)和托管的網(wǎng)絡服務，它們已經(jīng)被集成到內(nèi)部開發(fā)的系統(tǒng)中，但需要通過網(wǎng)絡進行訪問供應商對由內(nèi)部工作人員開發(fā)和管理的托管應用進行管理將全部系統(tǒng)整體(包括工資、會計等部分在內(nèi))遷移到一家由供應商托管的網(wǎng)站上
隨著云技術的逐漸成熟，它可以提供的服務也處于發(fā)展變化的過程中。但在這里有一個基本前提，它給大型提供的靈活性，給中小型企業(yè)提供的機會，是有可能超過預算限制的。
問題的關鍵在于風險
從作為一名安全專家的角度來看，我認為對和云服務有關的風險進行評估和管理就相當于對現(xiàn)有風險管理流程的調整。因此，答案非常簡單：實際執(zhí)行需要花費一定量的工作時間。
如果貴公司中沒有應用風險管理框架的話，要做的第一件事情就是建立一個。保護公司數(shù)據(jù)安全的關鍵就是平衡業(yè)務面臨的風險。通常的處理模式是確定、減輕和匯總面臨的風險，并與業(yè)務經(jīng)理和審計人員進行合作，將其控制在適當?shù)姆秶铩Ｈ绻疽呀?jīng)建立了備用框架的話，你要做的就是將它擴展開。
圖1顯示的就是一般公司風險邊界的簡單模型。在信息技術人員設計并實施內(nèi)部解決前，安全分析人員需要對風險進行評估。無論如何，風險的可管理邊界是外圍。通過連接到云服務供應商上，沒有常規(guī)進程可以帶來威脅模型。
圖1：內(nèi)部風險邊界
如圖2所示，的一體化前進道路導致危險的邊界進一步擴展。我們的目的不是希望云成為"外面"的東西。正好相反，它應該是連接到企業(yè)中的一個高增值環(huán)節(jié)。根據(jù)總體規(guī)劃，風險管理的邊界應該擴展到可以將所有業(yè)務服務都包括進去的情況。
圖2：擴展風險邊界
差距在哪里
擴展風險邊界并不僅僅等于提出這樣的問題就萬事大吉了。將云整合起來需要考慮到供應商的提供商怎么進行特別處理這樣的額外因素。下面的列表，就是我認為對云服務提供商進行評估時，應該考慮到的方面：
云服務提供商是否通過了來自外界的實體認證，可以實現(xiàn)對安全性的有效管理(采用美國注冊會計師協(xié)會第70號服務機構審計準則、管理體系國際標準等類規(guī)則)？是否存在內(nèi)部控制機制？它們將怎么處理我的內(nèi)部控制機制？這之間存在什么差距，這些差距是否合理？
有多少數(shù)據(jù)會被涉及進來？公司是否必須提供更多的數(shù)據(jù)？云服務提供商應該獲得多少數(shù)據(jù)，這樣做的原因是什么？
云服務提供商是否了解我對安全的期望？這些期望是否會包含在合同中？如果云服務提供商沒有遵守合同中對安全的要求，我可以采取什么樣的懲罰措施？合同是否容許我進行定期審計來確認數(shù)據(jù)受到保護的實際情況？
該列表中包含的就是最基本的問題。這基于我假設你已經(jīng)實現(xiàn)了對傳輸過程的數(shù)據(jù)進行保護，擁有強大靈活的訪問控制機制的前提。如果沒有作到這一點的話，在擴展到云之前，你可能還有更大的問題需要解決。
結論
不要逃離云。它并不是你的敵人，你將會被同化。問題的關鍵不在于你是否會將云服務整合起來，而是如何管理好面臨的相關風險。所有的供應商都會是合適的選擇么？答案顯然是否定的。因此，對云供應商進行選擇就如同內(nèi)部軟件、硬件或服務提供商的選擇過程是一樣的。了解自身需求，就期望進行溝通，對供應商的契合程度進行評估。如果有需要的話，指出在管理方面發(fā)現(xiàn)的問題，與供應商合作，改善控制功能。