| 摘要： HyperStratus咨询公司首席执行官伯纳德·戈尔登(Bernard Golden)撰文指出，一个接一个的调查表明，对于公共云计算，安全是潜在用户最担心的问题。例如，2010年4月的一项调查指出，45%的以上的受访者感到云计算的风险超过了收益。CA和Ponemon Institute进行的一项调查也发现了类似的担心。但是，他们还发现，尽管有这些担心，云应用还是在部署着。类似的调查和结果的继续发布表明人们对安全的不信任继续存在。 |
第二个云安全谎言
关于云计算安全的第二个谎言是对公共云安全的推测，特别是推测公共云计算的安全完全取决于云服务提供商。现实是，服务提供商领域的安全是提供商与用户共同承担的责任。服务提供商负责基础设施的安全以及应用程序与托管的环境之间的接口的安全;用户负责接入这个环境的接口的安全，更重要的是负责应用程序本身的内部安全。
没有正确地配置应用程序，如环境安全接口或者没有采取适当的应用程序级安全预防措施，会使用户产生一些问题。任何提供商也许都不会对这种问题承担责任。
让我提供一个例子。与我们合作的一家公司把自己核心的应用程序放在亚马逊Web服务中。遗憾的是这家公司在如果使用亚马逊Web服务安全机制或者简单应用程序设计问题等方面没有采取适当的安全措施。
实际上，亚马逊提供一个虚拟机级别的防火墙(称作安全组)。人们配置这个防火墙以允许数据包访问具体的端口。与安全组有关的最佳做法是对它们分区，这样，就会为每一个虚拟化提供非常精细的访问端口。这将保证只有适用于那种类型机器的通讯能够访问一个实例。例如，一台Web服务器虚拟机经过配置允许端口80上的通讯访问这个实例，同时，数据库虚拟机经过配置允许端口80上的通讯访问这个实例。这就阻止了来自外部的利用web通讯对包含重要应用程序数据的数据库实例的攻击。
要建立一个安全的应用程序，人们必须正确地使用安全组。这个机构没有这样做。它对于访问所有实例的通讯都使用一个安全组。这意味着访问任何实例的任何类型的通讯都可以访问每一种类型的实例。这显然是糟糕地使用亚马逊Web服务安全机制的一个例子。
关于机构的应用程序本身，它采用了糟糕的安全做法。它没有在不同类型的机器之中对应用程序代码分区，它把所有的应用程序代码都装载到同一个实例中。这个实例接收其企业网站的通讯，并且还有也在它上面运行的包含专有算法的代码。
这种情况的关键事实是：如果这个机构以为所有的安全责任都由云服务提供商(在这个案例中是亚马逊Web服务)，这将是一个严重的疏忽，因为它没有采取重要步骤解决安全问题，而这个安全问题是没有任何一个云服务提供商会承担责任的。这是共同承担责任的意义—双方必须建立自己控制的安全方面。没有这样做，意味着应用程序是不安全的。即使云服务提供商在自己控制的范围内所做的一切都是正确的，如果这个应用程序的拥有者没有正确地履行自己的责任，这个应用程序也将是不安全的。
戈尔登称，我曾经会见过许多安全人员讨论有关公告云服务提供商的问题。他们拒绝认为自己的公司在这些环境中的责任，坚持把每一个安全话题转向担心云服务提供商的责任。
坦率地说，这使我感到他们是轻率的，因为这暗示他们拒绝认真地做一些必要的工作以便创建一个基于公共云服务提供商的尽可能安全的应用程序。这个态度好像所有的安全责任都在云服务提供商身上，与安全人员无关，进一步扩展就是他的公司与在云服务提供商环境中运行的应用程序的任何安全事故无关。因此，这种情况并不让人感到意外：有关人士坚决支持私有云，声称私有云有优越的安全性。
现实是，机构正在越来越多地在公共云服务提供商环境中部署应用程序。安全组织前进一步保证自己的机构采取一切可能的步骤尽可能安全地执行应用程序是非常重要的。这意味着机构本身需要在这方面采取些什么步骤。
因此，安全是云计算的第三条轨道。安全一直被说成是私有云固有的好处和公共云计算的基本缺陷。实际上，事实比这些情况暗示的还要模糊不清。断言公共云环境有安全缺陷，不认真考虑如何缓解这些不安全因素，似乎是不负责任的。这个证据表明这种观点认为研究缓解安全问题的技术是没有必要。
一个管理不善和配置糟糕的私有云应用程序是非常容易受到攻击的。一个管理妥当的和配置合格的公共云应用程序能够达到很好的安全性。把这种情况描绘非黑的和白的是简单化，会危害这个讨论。
在这两个环境中的更有建设性的做法是询问必须采取什么行动才能实现在时间、预算和容许风险的条件下尽可能保证应用程序安全的目标。考虑到一个具体环境和应用，安全从来不是一个或者黑色或者白色的简单问题，而是如何尽可能地照亮一个阴影的问题。不承认这个问题会破坏这个话题的讨论，影响如何最好地保证一个机构的基础设施以及尽可能地高效率和节省成本等问题。
责任编辑：Alice
评论表单加载中...
