HyperStratus咨询公司首席执行官伯纳德.戈尔登(Bernard Golden)撰文指出，一个接一个的调查表明，对于公有云计算，安全是潜在用户最担心的问题。例如，2010年4月的一项调查指出，45%的以上的受访者认为云计算带来的风险超过了收益。CA和Ponemon Institute进行的一项调查也发现了用户有此类担心。但是，他们还发现，尽管用户存在这种疑问，云应用还是在部署着。类似调查和结果的持续发布表明人们对云计算安全的不信任继续存在着。
不可否认，大多数对云计算安全的担心都与公有云计算有关。全球IT从业者不断地对使用一个公有云服务提供商提出同样的问题。例如，戈尔登近期去了*并且在*云SIG会议上发表了演讲。有250人参加了这个会议。正如预料的那样，人们向他提出的第一个问题是“公有云计算环境足够安全吗，我是否应该使用私有云以避免安全问题?”所有的人似乎都认为公有云服务提供商是不可信赖的。
然而，把云安全的讨论归结为“公有云不安全，私有云安全”的公式似乎过于简单化。简单地说，这个观点存在两个大谎言(或者说是两个基本的误会)。主要原因是这种新的计算模式迫使安全产品和方法发生了巨大变化。
第一个云安全谎言：私有云很安全
第一个谎言是私有云是安全的。这个结论的依据仅仅是私有云的定义：私有云是在企业自己的数据中心边界范围内部署的。这个误解产生于这样一个事实：云计算包含与传统的计算不同的两个关键区别：虚拟化和动态性。
第一个区别是，云计算的技术基础建立在一个应用的管理程序的基础上。管理程序能够把计算(及其相关的安全威胁)与传统的安全工具隔离开，检查网络通讯中不适当的或者恶意的数据包。由于在同一台服务器中的虚拟机能够完全通过管理程序中的通信进行沟通，数据包能够从一个虚拟机发送到另一个虚拟机，不必经过物理网络。而一般安装的安全设备通常会在物理网络检查通讯流量。
至关重要的是，这意味着如果一个虚拟机被攻破，它能够把危险的通信发送到另一个虚拟机，传统的防护措施甚至都不会察觉。换句话说，一个不安全的应用程序能够造成对其他虚拟机的攻击，用户采用的安全措施对此却无能为力。仅仅因为一个用户的应用程序位于私有云并不能确保这个应用程序不会出现安全问题。
当然，人们也许会指出，这个问题是与虚拟化一起出现的，没有涉及到云计算的任何方面。这个观点是正确的。云计算代表了虚拟化与自动化的结合。它是导致私有云出现另一个安全缺陷的第二个因素。
云计算应用程序得益于自动化以实现灵活性和弹性，能够通过快速迁移虚拟机和启动额外的虚拟机来管理不断变化的流量负载类型，并对不断变化的应用状况做出回应。这意味着新的实例在几分钟之内就可以上线，不需要任何人工干预。这也意味着任何必要的软件安装或者配置也必须实现自动化。这样，当新的实例加入现有的应用程序池的时候，它能够立即作为一个资源被其他应用使用。
同样，它还意味着任何必须的安全软件必须自动化地进行安装和配置，不能有人工干预。遗憾的是，目前许多机构还必须依靠安全人员或者系统管理员人工安装和配置必要的安全组件，而且这通常是作为这台机器的其它软件组件安装和配置完毕之后的第二个步骤。
换句话说，许多机构在安全措施实践与云要求的现实方面是不匹配的。现在可以认为私有云本身是安全的这个观点是不正确的。在用户的安全和基础设施实践与自动化的实例一致之前，肯定会产生安全漏洞。
而且，使它们一致是非常重要的。否则，可能出现这种情况：用户的应用程序自动化超过了安全实践的应对能力。这不是一个好现象。毫无疑问，人们不想面对为什么好像安全的私有云最终还是有安全漏洞，因为云计算的自动化特征还没有扩展到软件基础设施的所有方面。
因此，关于云计算的第一个大谎言的结果是：私有云本身就是不安全的。
第二个云安全谎言：公有云很不安全
关于云计算安全的第二个谎言是对公有云安全的假设，特别是错误的认为公有云计算的安全完全取决于云服务提供商。现实是，服务提供商领域的安全是提供商与用户共同承担的责任。服务提供商负责基础设施的安全以及应用程序与托管环境之间接口的安全；用户负责接入环境接口的安全，更重要的是负责应用程序本身的内部安全。
没有正确地配置应用程序，如环境安全接口，或者没有采取适当的应用程序级安全预防措施，会使用户产生一些问题。任何提供商也许都不会对这种来自用户应用程序内部的安全问题承担责任。
让笔者提供一个例子。与我们合作的一家公司把自己核心的应用程序放在亚马逊的Web服务中。遗憾的是这家公司既没有针对亚马逊Web服务安全机制可能存在的漏洞部署安全措施，也没有针对应用程序设计的问题采取安全防御措施。
实际上，亚马逊提供了一个虚拟机级别的防火墙(称作安全组)。人们配置这个防火墙以允许数据包访问具体的端口。与安全组有关的最佳做法是对它们进行分区，这样，就会为每一个虚拟机提供非常精细的访问端口。这将保证只有适用于那种机器类型的通信流量才能够访问一个实例。例如，一台Web服务器虚拟机经过配置允许端口80上的通信访问这个实例，同时，数据库虚拟机经过配置允许端口80上的通信访问这个实例。这就阻止了来自外部的利用web通信对包含重要应用程序数据的数据库实例的攻击。
要建立一个安全的应用程序，人们必须正确地使用安全组。但下述这个用户没有这样做。它对于访问所有实例的通信都使用一个安全组。这意味着访问任何实例的任何类型的通信都可以访问每一种类型的实例。这显然是没有正确使用亚马逊Web服务安全机制的一个例子。
关于用户的应用程序本身，它也采用了很糟糕的安全措施。它没有在不同类型的机器之中对应用程序代码进行分区，而是把所有的应用程序代码都装载到同一个实例中。这个实例可以接收来自其企业网站的通信流量，以及包含专有算法的代码。
这种情况的关键事实是：如果这个用户以为所有的安全责任都由云服务提供商来承担(在这个案例中是亚马逊Web服务)，这将是一个严重的疏忽，因为用户本身没有采取重要的步骤来解决安全问题，而这个安全问题是任何一个云服务提供商都不会承担相关责任的。这就是共同承担责任的意义——双方必须建立自己控制的安全范畴。如果没有这样做，就意味着应用程序是不安全的。即使云服务提供商在自己控制的范围内所做的一切都是正确而且完善的，若是这个应用程序的所有者没有正确地履行自己的责任，这个应用程序也将会变得不安全。
戈尔登称，我曾经见过许多安全人员讨论有关公有云服务提供商的问题。他们拒绝承担自己的公司在公有云环境中应该承担的责任，坚持把每一个安全问题转向对云服务提供商的担心。
坦率地说，这使我感到他们的想法很轻率。因为这暗示着他们拒绝认真地做一些必要的工作以便创建一个基于公有云服务提供商的尽可能安全的应用程序。这个态度显示，好像所有的安全责任都在云服务提供商身上，再进一步发展就是认为他的公司与在公有云服务提供商环境中运行的应用程序的任何安全事故都无关。因此，以下这种论点并不让人感到意外：有关人士坚决支持私有云，声称私有云与公有云相比有优越的安全性。
现实情况是，用户正在越来越多地在公有云服务提供商环境中部署应用程序。安全组织保证自己采取一切可能的步骤尽可能安全地执行应用程序是非常重要的。这意味着用户本身也需要在这方面采取些相关的措施。
因此，安全是云计算的第三条轨道。安全一直被说成是私有云固有的好处和公有云计算的基本缺陷。实际上，事实比这些情况暗示的还要模糊不清。断言公有云环境有安全缺陷，不认真考虑如何缓解这些不安全因素，是不很负责任的说法。
一个管理不善和配置糟糕的私有云应用程序是同样会非常容易受到攻击。而一个管理妥当的和配置合格的公共云应用程序却能够达到很好的安全性。把这种情况描绘成非黑即白地简单化，会危害云环境的正常发展。
在如何选择两种不同的云环境时，更有建设性的做法是询问必须采取什么行动才能实现在时间、预算和容许风险的条件下尽可能保证应用程序安全的目标。考虑到一个具体的环境和应用，安全从来不是一个或黑或白的简单问题，而是如何尽可能地将两种云计算类型所面临的安全灰色地带如何照亮的问题。如果没有意识到上述观点，对于如何保证一个企业的基础设施建设尽可能提高效率和节约成本来说没有一点好处。