公有云“不安全”？

　　实际上，亚马逊提供了一个虚拟机级别的防火墙(称作安全组)。人们配置这个防火墙以允许数据包访问具体的端口。与安全组有关的最佳做法是对它们进行分区，这样，就会为每一个虚拟机提供非常精细的访问端口。这将保证只有适用于那种机器类型的通信流量才能够访问一个实例。例如，一台Web服务器虚拟机经过配置允许端口80上的通信访问这个实例，同时，数据库虚拟机经过配置允许端口80上的通信访问这个实例。这就阻止了来自外部的利用web通信对包含重要应用程序数据的数据库实例的攻击。

　　要建立一个安全的应用程序，人们必须正确地使用安全组。但下述这个用户没有这样做。它对于访问所有实例的通信都使用一个安全组。这意味着访问任何实例的任何类型的通信都可以访问每一种类型的实例。这显然是没有正确使用亚马逊Web服务安全机制的一个例子。

　　关于用户的应用程序本身，它也采用了很糟糕的安全措施。它没有在不同类型的机器之中对应用程序代码进行分区，而是把所有的应用程序代码都装载到同一个实例中。这个实例可以接收来自其企业网站的通信流量，以及包含专有算法的代码。

　　这种情况的关键事实是：如果这个用户以为所有的安全责任都由云服务提供商来承担(在这个案例中是亚马逊Web服务)，这将是一个严重的疏忽，因为用户本身没有采取重要的步骤来解决安全问题，而这个安全问题是任何一个云服务提供商都不会承担相关责任的。这就是共同承担责任的意义——双方必须建立自己控制的安全范畴。如果没有这样做，就意味着应用程序是不安全的。即使云服务提供商在自己控制的范围内所做的一切都是正确而且完善的，若是这个应用程序的所有者没有正确地履行自己的责任，这个应用程序也将会变得不安全。

　　戈尔登称，我曾经见过许多安全人员讨论有关公有云服务提供商的问题。他们拒绝承担自己的公司在公有云环境中应该承担的责任，坚持把每一个安全问题转向对云服务提供商的担心。

　　坦率地说，这使我感到他们的想法很轻率。因为这暗示着他们拒绝认真地做一些必要的工作以便创建一个基于公有云服务提供商的尽可能安全的应用程序。这个态度显示，好像所有的安全责任都在云服务提供商身上，再进一步发展就是认为他的公司与在公有云服务提供商环境中运行的应用程序的任何安全事故都无关。因此，以下这种论点并不让人感到意外：有关人士坚决支持私有云，声称私有云与公有云相比有优越的安全性。

　　现实情况是，用户正在越来越多地在公有云服务提供商环境中部署应用程序。安全组织保证自己采取一切可能的步骤尽可能安全地执行应用程序是非常重要的。这意味着用户本身也需要在这方面采取些相关的措施。

　　因此，安全是云计算的第三条轨道。安全一直被说成是私有云固有的好处和公有云计算的基本缺陷。实际上，事实比这些情况暗示的还要模糊不清。断言公有云环境有安全缺陷，不认真考虑如何缓解这些不安全因素，是不很负责任的说法。

　　一个管理不善和配置糟糕的私有云应用程序是同样会非常容易受到攻击。而一个管理妥当的和配置合格的公共云应用程序却能够达到很好的安全性。把这种情况描绘成非黑即白地简单化，会危害云环境的正常发展。

　　在如何选择两种不同的云环境时，更有建设性的做法是询问必须采取什么行动才能实现在时间、预算和容许风险的条件下尽可能保证应用程序安全的目标。考虑到一个具体的环境和应用，安全从来不是一个或黑或白的简单问题，而是如何尽可能地将两种云计算类型所面临的安全灰色地带如何照亮的问题。如果没有意识到上述观点，对于如何保证一个企业的基础设施建设尽可能提高效率和节约成本来说没有一点好处。

　　编看编想：云计算火热中的冷静

　　自云计算的概念提出以来，有关云计算的安全问题一直是被关注的重点。虽然说最近两年云计算的产品不断充斥着整个市场，但是用户也不应该被包裹着云计算外衣的形形色色的产品冲昏了头。这些产品是真的实现了云计算吗?其实，在记者看来，云计算还没有像表面上显示的已经成熟到了产品化的程度。它的安全问题一直还未完美解决。

　　就像上述那篇文章写的那样，无论是公有云和私有云，自动化是其最先要实现的目标之一。而现实情况却是，安全设备的安装还得依靠人工的干预。另外，虚拟化带来的安全问题也只是才刚刚起步，至少目前来看，虚拟环境中的安全与传统物理环境中的安全措施相比，还有很大一截需要追赶。所以，想要迁移至云计算环境中的用户，请擦亮自己的眼睛，详细了解用户与云计算供应商所要承担的安全责任，因为安全的云计算环境是需要用户与供应商共同来维护的。