当我在阅读各种博客、IT 产业分析以及媒体报导时，我发现许多矛盾的观点。某些作者认为云计算较为安全，有些则特别强调新的安全挑战。由于“云”的概念目前仍在雏形阶段，因此到处充斥着许多似是而非的论点。以下是我最常听到的五大云计算盲区：
盲区1 基础架构服务(Infrastructure-as-a-Service，简称 IaaS) 供应商所提供的虚拟私人“云”就像企业内部数据中心一样安全
虚拟私人“云”是IaaS领域所衍生出来的新兴概念，可让企业透过VPN连线至“云”的资源，IaaS厂商会提供一段企业专属的IP范围。这种运算方式的问题在于您仍旧与其他企业共用硬件资源与交换网络，彼此间仅藉由虚拟区域网络(VLAN)隔离。然而组态设定错误的情况时有所闻。根据最近一份研究显示，澳洲有31%的信息外泄事件是“第三方厂商如云计算或SaaS供应商的错误所造成”。
盲区2 您不需要一家以上的IaaS供应商
将所有鸡蛋都放在同一个篮子，万一篮子打翻了就很危险，云计算也一样。虽然采用单一IaaS供应商较容易管理，但却也形成单一故障点。仰赖单一IaaS供应商的风险是，万一厂商遭到分散式阻断DDOS攻击，企业的运营就可能发生中断，就像Bitbucket的例子。
另一个单一故障点(SPOF)的例子是 Rackspace，一辆卡车撞上了某个变电箱而导致Rackspace数据中心电力中断，业务因而停摆。由于意外在所难免，因此，要防止单一故障点，就要拥有一家以上的IaaS供应商。
建立备份据点是达成灾难复原的主要方法之一，云计算的时代也一样。企业或许不需要一个热于待命的失败点，但却应该规划并测试如何在需要的时候迅速将运营切换至第二家供应商。虽然像Amazon“可用性区间”这类的作法可降低上述风险，但并不能完全消除单一故障点的可能性。
盲区3 私人“云”同样也适用实体数据中心的安全方案
其思维逻辑是，数据中心原本的边境防御就已成效良好，而私人“云”也受到同样的保护，所以应该没问题。只可惜，情况通常并非如此。私人”云” 有其新的挑战，这些挑战是传统静态数据中心所没有的。虚拟化与云计算加大了攻击面，共享储存就是一个例子。
另外还有一些新的状况，例如系统管理员不小心用 vMotion 将某个服务器从安全区域移到DMZ。此外，VLAN 组态设定错误也可能导致信息未妥善隔离。还有，同一个vShield区域内的VM之间不受监控的信息流量呢?在一个混合式”云”环境中，当一个应用程序移到”云”，其虚拟机器周围却没有安全防护将会如何?仰赖IaaS厂商所提供的基本防火墙规则，甚至连IDS/IPS也没有，可能会让某些企业感到不安。
盲区4 “云”服务供应商会负起安全的责任
虽然SaaS或PaaS服务供应商通常会在服务条款中提供安全保障，在IaaS领域却不然。虽然IaaS厂商会采取一些安全措施，并且在文宣中强调其安全措施，但IaaS环境的安全性终究是企业与IaaS 厂商应该共同负担的责任，而且，最终的责任通常还是落在企业本身。IaaS供应商的服务条款中有关安全的章节应该会强调这一点。
不仅如此，虽然供应商会负起安全的责任，但万一发生信息外泄事件，企业本身仍旧须承担最终的责任。毕竟，那是您的信息。
盲区5 我的“云”服务厂商有SAS 70 Type II程序，因此我的信息安全无虞
SAS 70 Type II内核的确是不错的安全基础，也是确保厂商在检查期间安全控管措施正常运作的一项工具，但这并不等于安全性。而且可能给人一种安全感的假象。内核所看的是过去的状况，虽然过去的绩效对未来具指标性 (至少在数据中心安全方面)，但绝非未来的保证。一旦公司发生大规模或不预期的人事变动，就可能让原本扎实完整的安全措施一夕之间瓦解。此外，SAS 70也无法防止心生不满的员工对公司或客户挟怨报复。
SAS 70 Type II内核无法检查内核范围以外的项目。在内核检查表上的项目您或许严格控管，但漏洞却可能在检查范围之外。再者，任何流程的内核都无法涵盖执行流程的人。厂商的用人原则为何?SAS 70 Type II内核并不一定涵盖用人原则。凡人都可能犯错，当然也绝非完美。
SAS 70审查并没有一套标准作法。这类内核是内核者与受内核对象彼此共同设计出来，目的在于测试特定业务流程的控管措施。而控管措施可能无法包山包海，所以，在原先预定之外的项目，即使对业务服务很重要也不在测试范围内。因此，在将关键业务流程交给任何服务供应商之前，您应该对 SAS 70内核有所存疑。而且，理想的内核不应该只专注于信息安全，而是应该延伸至服务永续性、厂商管理、备份复原、人事制度等其他领域。
不论公共“云”或私人“云”在降低成本、提升企业灵活度方面都能提供优异的企业价值。不过，建议您在挑选之前还是应该先认清其中的安全挑战。
