云安全五大盲区 企业安全任重而道远

 

 

虚拟私人”云”是 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 内核有所存疑。而且，理想的内核不应该只专注于信息安全，而是应该延伸至服务永续性、厂商管理、备份复原、人事制度等其他领域。

 

不论公共”云”或私人”云”在降低成本、提升企业灵活度方面都能提供优异的企业价值。不过，建议您在挑选之前还是应该先认清其中的安全挑战。