虛擬私人”云”是 IaaS 領域所衍生出來的新興概念，可讓企業透過VPN連線至”云”的資源，IaaS 廠商會提供一段企業專屬的 IP 范圍。這種運算方式的問題在于您仍舊與其他企業共用硬件資源與交換網絡，彼此間僅藉由虛擬區域網絡 (VLAN) 隔離。然而組態設定錯誤的情況時有所聞。根據最近一份研究顯示，澳洲有 31% 的信息外泄事件是“第三方廠商如云計算或 SaaS 供應商的錯誤所造成”。

 

 

將所有雞蛋都放在同一個籃子，萬一籃子打翻了就很危險，云計算也一樣。雖然采用單一 IaaS 供應商較容易管理，但卻也形成單一故障點。仰賴單一 IaaS 供應商的風險是，萬一廠商遭到分散式阻斷DDOS攻擊，企業的運營就可能發生中斷，就像 Bitbucket 的例子。

 

另一個單一故障點 (SPOF) 的例子是 Rackspace，一輛卡車撞上了某個變電箱而導致 Rackspace 數據中心電力中斷，業務因而停擺。由于意外在所難免，因此，要防止單一故障點，就要擁有一家以上的 IaaS 供應商。

 

建立備份據點，是達成災難復原的主要方法之一，云計算的時代也一樣。企業或許不需要一個熱于待命的失敗點，但卻應該規劃并測試如何在需要的時候迅速將運營切換至第二家供應商。雖然像 Amazon“可用性區間”這類的作法可降低上述風險，但并不能完全消除單一故障點的可能性。

 

 

其思維邏輯是，數據中心原本的邊境防御就已成效良好，而私人”云”也受到同樣的保護，所以應該沒問題。只可惜，情況通常并非如此。私人”云” 有其新的挑戰，這些挑戰是傳統靜態數據中心所沒有的。虛擬化與云計算加大了攻擊面，共享儲存就是一個例子。

 

另外還有一些新的狀況，例如系統管理員不小心用 vMotion 將某個服務器（服務器租用找億恩柯南：QQ 965171276)從安全區域移到 DMZ。此外，VLAN 組態設定錯誤也可能導致信息未妥善隔離。還有，同一個 vShield 區域內的 VM 之間不受監控的信息流量呢?在一個混合式”云”環境中，當一個應用程序移到”云”，其虛擬機器周圍卻沒有安全防護將會如何?仰賴 IaaS 廠商所提供的基本防火墻規則，甚至連 IDS/IPS 也沒有，可能會讓某些企業感到不安。

 

 

雖然 SaaS 或 PaaS 服務供應商通常會在服務條款中提供安全保障，在 IaaS 領域卻不然。雖然 IaaS 廠商會采取一些安全措施，并且在文宣中強調其安全措施，但 IaaS 環境的安全性終究是企業與 IaaS 廠商應該共同負擔的責任，而且，最終的責任通常還是落在企業本身。IaaS 供應商的服務條款中有關安全的章節應該會強調這一點。

 

不僅如此，雖然供應商會負起安全的責任，但萬一發生信息外泄事件，企業本身仍舊須承擔最終的責任。畢竟，那是您的信息。

 

 

SAS 70 Type II 內核的確是不錯的安全基礎，也是確保廠商在檢查期間安全控管措施正常運作的一項工具，但這并不等于安全性。而且可能給人一種安全感的假象。內核所看的是過去的狀況，雖然過去的績效對未來具指標性 (至少在數據中心安全方面)，但絕非未來的保證。一旦公司發生大規模或不預期的人事變動，就可能讓原本扎實完整的安全措施一夕之間瓦解。此外，SAS 70 也無法防止心生不滿的員工對公司或客戶挾怨報復。

 

SAS 70 Type II 內核無法檢查內核范圍以外的項目。在內核檢查表上的項目您或許嚴格控管，但漏洞卻可能在檢查范圍之外。再者，任何流程的內核都無法涵蓋執行流程的人。廠商的用人原則為何?SAS 70 Type II 內核并不一定涵蓋用人原則。凡人都可能犯錯，當然也絕非完美。

 

SAS70 審查并沒有一套標準作法。這類內核是內核者與受內核對象彼此共同設計出來，目的在于測試特定業務流程的控管措施。而控管措施可能無法包山包海，所以，在原先預定之外的項目，即使對業務服務很重要也不在測試范圍內。因此，在將關鍵業務流程交給任何服務供應商之前，您應該對 SAS 70 內核有所存疑。而且，理想的內核不應該只專注于信息安全，而是應該延伸至服務永續性、廠商管理、備份復原、人事制度等其他領域。

 

不論公共”云”或私人”云”在降低成本、提升企業靈活度方面都能提供優異的企業價值。不過，建議您在挑選之前還是應該先認清其中的安全挑戰。