云CIO:关于云安全性的两个最大谎言

将云安全讨论视为一个黑白问题,即公有云不安全而私有云是安全的,这过于简单化,使追求这两种云环境的组织容易受到攻击。

一项又一项的调查表明,安全性是潜在用户对公共云计算的最大关注。 这里例如,2010年4月的一项调查显示,有45%的受访者认为云计算的风险大于收益。 CA和Ponemon Institute进行了调查 并发现了类似的问题。但是他们也发现尽管有这些担忧,部署还是发生了。和类似的 调查和结果 继续发布,表明对安全性的不信任仍然存在。

当然,有关云计算的大多数担忧都与公共变量有关。全世界的IT从业人员不断提出关于使用公共场所的相同问题 云服务提供商 (CSP)。例如,本周我在台湾,而昨天我在台湾云技术联盟上发了言。超过250人参加了,并且可以预见的是,向我提出的第一个问题是:“公共云计算是否足够安全,我是否应该使用私有云来避免任何安全问题?”似乎各地的人们都感到公共CSP不受信任。

但是,将云安全讨论归为“公共云不安全,私有云安全”的公式表示过于简单化了。简而言之,在这个观点上有两个大谎言(或者更仁慈地是两个基本的误解),这两个根源都在于对安全产品和实践的这种新的计算方式的根本改变。

云安全谎言#1

第一个大谎言是,按照定义,私有云计算仅通过将其部署在公司自己的数据中心的边界内的事实来确保安全。这种误解源于以下事实:云计算与传统计算包含两个关键区别:虚拟化和动态性。

第一个区别是云计算的技术基础基于虚拟机监控程序的存在,它具有将计算(以及随之而来的安全威胁)与传统安全工具之一隔离的作用:检查网络流量中是否存在不合适或恶意的数据包。由于驻留在同一服务器上的虚拟机可以通过虚拟机管理程序内的流量进行完全通信,因此可以将数据包从一台计算机发送到另一台计算机,而无需访问物理网络,在物理网络中通常会安装安全设备来检查流量。

至关重要的是,这意味着,如果一台虚拟机受到威胁,它甚至可以在没有典型组织保护措施的情况下将危险流量发送到另一台虚拟机。换句话说,一个不安全的应用程序可以将攻击传达给另一个应用程序,而无需组织的安全措施来发挥作用。仅仅因为组织的应用程序驻留在私有云中并不能保护它免受此安全问题。

当然,可能会指出,香草虚拟化存在此问题,而没有涉及云计算的任何方面。这种观察是正确的。云计算代表了虚拟化与自动化的结合,正是在第二个元素中,出现了私有云的另一个安全缺陷。

云计算应用程序受益于这种自动化,以实现敏捷性和弹性-通过快速移动虚拟机并旋转其他虚拟机以管理不断变化的负载模式来响应不断变化的应用程序条件的能力。这意味着新实例仅需几分钟即可联机,而无需任何手动交互。这意味着任何必需的软件安装或配置也必须自动化,以便在新实例加入现有应用程序池时可以立即将其用作资源。

这也意味着任何必需的安全软件都必须自动安装和配置,而无需人工干预。不幸的是,许多组织依靠安全人员或系统管理员来手动安装和配置必要的安全组件,这通常是在安装和配置了机器其余软件组件之后的第二步。

换句话说,许多组织的安全实践与云需求之间存在不匹配。实际上,假设私有云是安全的,这是不正确的。在安全和基础结构实践与自动实例化保持一致之前,您将拥有一个漏洞。

此外,使它们保持一致至关重要。否则,您可能会面临应用程序自动化超出安全实践的情况,这不是一个好情况。可以肯定的是,人们不愿意试图解释为什么所谓的安全私有云最终暴露出一个漏洞,因为云计算的自动化特性并未在软件基础架构的所有部分中得到扩展。

因此,有关云计算的第一个大谎言是私有云本质上是安全的。什么是第二个?

云安全谎言2

关于云计算安全性的第二个谎言与关于公共云安全性的假设有关。具体来说,公共云计算中的安全性完全取决于CSP。现实情况是,服务提供商世界中的安全性是提供商和用户之间共同承担的责任,前者负责基础架构中的安全性,直到应用程序和托管环境之间的接口点为止,而用户则负责安全性。与环境进行交互,更重要的是,与应用程序本身进行交互。

无法根据环境安全性界面正确配置应用程序,或者未采取适当的应用程序级安全性预防措施,将使用户面临无法由任何提供商承担责任的问题。

让我举一个例子。我们合作过的一家公司已将其核心应用程序放置在Amazon Web Services(AWS)中。不幸的是,它没有就如何使用AWS安全性机制实施适当的安全性实践,也没有解决简单的应用程序设计问题。

实际上,Amazon提供了一种虚拟机级别的防火墙(称为安全组),可以对其进行配置以允许数据包访问特定端口。关于安全组的最佳实践是对它们进行分区,以便每个虚拟机都可以使用非常细粒度的端口访问。这样可以确保只有适合该类型计算机的流量才能进入实例。例如,Web服务器虚拟机配置为允许端口80上的流量进入实例,而数据库虚拟机配置为不允许端口80上的流量进入实例。这可以使用Web流量从外部阻止对数据库实例(包含关键应用程序数据)的攻击。

要构建安全的应用程序,必须正确使用安全组。该组织没有。它使用一个安全组来处理所有实例的所有流量,这意味着每种类型的实例都暴露于发往任何实例的任何类型的流量。显然,AWS安全机制使用不善。

关于组织的应用程序本身,它实施了不良的安全实践。它没有在不同类型的计算机之间划分应用程序代码,而是将所有应用程序代码加载到一个实例中,这意味着为公司网站接收流量的同一实例也包含运行专有算法的代码。

关于这种情况的重要事实:如果该组织假设所有安全责任都由CSP(在这种情况下为Amazon Web Services)承担,那将是极其疏忽,因为它没有采取重要步骤来解决没有CSP的安全问题可能负责。这就是分担责任的含义-双方都必须加强控制方面的安全性,否则,将意味着应用程序将不安全。即使CSP在其控制范围内针对云应用程序的各个部分正确完成了所有操作,但如果应用程序所有者无法正确执行其安全职责,则该应用程序将是不安全的。

我一直在与安全人员会面,讨论有关公共CSP的安全性,他们拒绝考虑他们在这些环境中的公司责任,坚持将每个安全主题重新引向对CSP责任的关注。

坦率地说,这让我感到震惊,因为这暗示着我拒绝认真解决创建尽可能安全的基于公共CSP的应用程序的必要工作。似乎所有安全责任都由CSP承担的态度使安全人员及其扩展公司(在其范围内)免于对在CSP环境中运行的应用程序中的安全故障承担任何责任。所讨论的个人坚决拥护私有云,声称其优越的固有安全性不足为奇。

现实情况是,组织越来越多地打算在公共CSP环境中部署应用程序。安全小组必须向前迈进,以确保其组织采取一切可能的步骤来实现尽可能安全的应用程序,这至关重要,这意味着组织本身在这方面需要采取什么步骤。

可以这么说,安全性是 第三轨 计算的概念。它经常被引用为私有云的固有优势和公共云计算的根本缺陷。实际上,事实真相比这些立场所暗示的更加模糊。在不认真考虑如何缓解公共云环境的情况下主张推定的安全缺陷似乎是不负责任的,并且有证据表明断言意味着被解雇,而无需进一步研究缓解技术。

管理和配置不当的私有云应用程序可能非常脆弱,而管理和配置正确的公共云应用程序可以实现非常好的安全性。将情况描述为黑白很简单,这不利于讨论。

在这两种环境中,效率更高的方法是查询在时间,预算和风险承受力的约束下,必须采取什么措施才能实现尽可能安全的应用程序。安全性绝不是黑色或白色的问题,而是考虑到特定环境和应用程序的具体细节,如何使浅灰色阴影成为可能。未能承认这样做对这个主题以及如何最好地确保组织的基础架构尽可能高效和具有成本效益不利。

伯纳德·金是咨询公司的首席执行官 超级策略,专门研究虚拟化,云计算和相关问题。他还是迄今为止最畅销的虚拟化书籍“虚拟化的傻瓜”的作者。

在Twitter上关注Bernard Golden @伯纳德·金。在Twitter上关注CIO.com的所有内容 @CIOonline

版权© 2011 IDG通讯,Inc.