虚拟似乎是最近的 IT 热门话题之一，它能够带来低成本、ROI（高投资回报率）、易管理等优点。在这些灼目的优点下，似乎很少有人考虑到它背后也隐藏着一些问题。然而，正如所有的新技术一样，虚拟的背后也隐藏着值得大家注意的安全忧患。
正如 InfoQ 早前发布的文章《虚拟化导论》中所述，虚拟包括了两个主题：合并多个资源以单一的形态呈现，或者将一个资源显示为多个。无论是哪种决策，都需要考虑到一些安全问题，考虑到数据泄露、认证和访问权限、信息资源的破坏等。
在深入主题之前值得指出的是，本文的目的并不在于一味地赞颂虚拟技术，也没有要刻意去鸡蛋里挑骨头说它不好。虚拟技术确实有它的独到之处，但是用户在利用这些特性的时候，却也在越来越高的安全警惕性的要求下付出很大代价。当然，这也不是说虚拟系统或者网络本身使得在这些环境下运行的虚拟技术愈发不安全。
一旦说到安全这个话题，通常会提到下面这三个典型的领域：
- 机密性
- 完整性
- 访问性
国际标准化组织（International Standards Organization）曾经这样定义机密性：“它确保只有那些获得授权的对象才能够访问对应信息。”机密性在需求和限制所有人对该信息的访问权限的基础上，允许特定用户访问该数据。典型的实现机密性的工具包括文件访问权限、网络访问控制列表、防火墙规则等。
Wikipedia 对完整性的定义是：“一种确认数据在任何操作（比如传输、存储或读取）过程中是否保持完整的方法，能够防止数据被恶意篡改，关联的特定操作，数据质量的期望。”完整性确保用户访问的数据确确实实是其所应该接受的数据。典型的系统完整性检查工具有：checksum、hash（比如 MD5）、诸如 CVS 或 Subversion 这样的版本控制工具等。
数据的访问性指的是访问所需系统和数据的能力。这意味着当用户请求数据的时候，如果系统故障或数据删除使得被请求数据无法访问，那就影响到安全问题了。很多公司都使用高可用性性配置、失败转移、可热交换的驱动器等方式来保证数据的访问性。
另外，明确我们系统安全究竟能够保护系统免受怎样的危险也是至关重要的。下面列出的几个定义在讨论安全问题的时候会很有用：
- 漏洞 —— 系统中能够被攻击者利用来强行破坏系统的完整性的弱点。产生漏洞的原因可以是软件的 bug，可以是配置错误，有可以是太过简单的用户密码。
- 威胁 —— 漏洞向上一级就是威胁，也就是指漏洞被攻击者利用的可能性。威胁也包括发生攻击的几率。出于这个原因，攻击者往往首先攻击那些简单的密码，而一些软件漏洞可能存在了很多年也没有被利用而引发专门的攻击。
- 入侵工具 —— 入侵工具可是是一个软件，一段数据，也可以是一串命令，利用 bug、小错误或者漏洞使得系统发生计划或者意料之外的行为。简而言之，入侵工具也就是利用漏洞的一段代码或者一串命令。
当硬件和服务器是一对一关系的时候，安全问题相对来说就比较简单。系统管理员可以配置操作系统，安装脚本来确保设备安全启动，确保数据管理员和开发人员都可以通过固定路径配置应用程序。网络工程师和安全小组可以配置防火墙规则、路由规则，限制对特定服务器、硬盘以及服务的访问权限。由于系统是捆绑到单一硬件之上，并且布置在特定子网的一个特定数据中心中，所以这些静态的安全措施很有用。服务器的物理形态必须安置在另一个子网中，否则，必须通过网线将服务器直接连接到另一个网络。无论怎样，虚拟技术都可以关闭、复制、移动服务器，或者将服务器直接引入到另一个网络。系统能够简单地转移到所应用的网络之外，或者索性就不连接到网络，这也意味着需要适当执行其他一些新操作。
安全是最早采用虚拟技术的领域，主要关注于可行性和机密性。实际上，一些曾经的流行词汇就起源于虚拟机的最初应用：
VPN —— Virtual Private Network 的发明是为了在“危机四伏”的 Internet 上安全地传输专有或者机密数据。数据在传输之前进行加密，以此保证它的机密性。但 VPN 并不严格地进行网络多播，它只是允许同一个公共网络上可以寻在多个私有通道而已。
MPLS/VLAN —— Multiprotocol label switching 和 virtual local area networks 都通过 tagging 来允许不同的网络数据能够在同一块硬件上传播。tagging 将不同的网络区分开来，同时防止某个虚拟网络侵入到另一虚拟网络中去。
防火墙分区（Firewall partitioning） —— 防火墙在划分到不同的网络中去以后，可以创建多个防火墙规则组，这可以将传输的数据分流到 logging 设备甚或是攻击侦测系统中去。另外，防火墙分区还可以根据数据传输所使用的端口来决定多规则组的运用。防火墙可以扩展到单一网关设备之外，更类似于扮演高级数据传输警察的角色。
虚拟主机（Virtual hosts） —— 像 VMware 这样的软件使得系统管理员完全可以通过复制系统映像来摆脱完整的系统。系统配置可以强化安全防范，包括最近的打包更新等。另外，在发生系统用户被盗用的情况下，可以从已知的未被篡改的资源点恢复系统镜像，当然也可以有规律的定期恢复镜像。
网络端口模糊化（Network Port Obfuscation） —— 在 host 上安装端口模糊化工具，可以有效地防止黑客扫描你的网络。黑客扫描某个网络的时候，往往会扫描 1－65535 之间的所有网络端口（无论是 TCP 还是 UDP 端口都会被扫描）。一旦发现某个开放的端口号，黑客则会试图寻找跟这个端口相关的漏洞。但是对于安装了端口模糊化工具的 host，他能够对发送到这 65536 个端口中任何一个端口上的请求予以回复，甚至是提供虚假的连接成功的消息。比方说一个 windows 的 host 可以回复黑客说这是一个 Unix 系统，甚至可是什么都不回复。
可访问性 —— 如果整个系统由 server farm 构成，即使其中一半服务器出于维护的需求而关闭，用户也无从得知这些服务器的服务断供，因为另一半服务器还在正常运行。这样一来，用户不会注意到一个甚至是多个硬件的破损，系统的其他部分完全可以正常处理用户请求。另外，系统的升级和打补丁可以分步进行，以此保证信息的可访问性。尽管虚拟技术可以改进可访问性，但可访问性仍然受到其它一些因素的影响：
管理程序的失败会导致受其约束的多个虚拟系统同时崩溃。尽管应该在不同的物理 host 上部署多个冗余系统，但一些应用程序还是有可能导致多个系统同时崩溃。一个一个恢复这些系统可能很困难，如果遇到系统管理员忽略了正式的系统管理文档的整理的情况，就更雪上加霜了，而这样的事情却屡见不鲜。
保密性—— 目前为止，这是虚拟技术最难保证的安全因素。由于虚拟系统的启动和关闭非常简单，系统管理员一个简单的输入错误就能改变整个虚拟网络，整个网络的安全机制立马就可能受到影响，让系统安全管理员防不胜防。从下面两个例子中，你可以看到虚拟技术也会带来危险：
- 比方说有一个服务器，它的安全配置相对比较宽松，因为这个服务器会被安置到非常安全的虚拟 LAN——vLAN 4 上。然而，在配置整个系统的时候，网络管理员一不小心把系统安置在 vLAN 5 上，而这个网络可以通过 Internet 直接访问。由于用户仍然可以访问到这个 host，没有人注意任何问题。一个星期之后，就有人发现这个网络存在着安全漏洞，这个漏洞非但导致一些可访问的 host 的用户帐户被盗取，甚至还波及到网络上的另外一些 host。如果说整个网络是通过网线连接，配置了特定的交换机的话，就不会有这样的安全漏洞，但这个系统中运用了虚拟技术，一个微小的输入错误，却足以导致多个 host 的用户帐号被盗取。
- 又比如某个系统将一个虚拟 host 配置成应用服务器为用户提供人力资源的数据库访问。Host 激活了安全机制，用户通过 host 上的应用程序以正确的方式访问数据库。由于这个服务器的配置地很好，系统运行得不错，另一个应用程序开发组的成员通过申请得到了一个该 host 的虚拟镜像的复制。这个复制将那些将服务器连接到数据库的脚本和后端配置，甚至用户名和密码，一应包含在了最后的虚拟镜像中。任何开发人员只要加载了这个虚拟镜像，就能访问人力资源应用程序的信息，甚至能访问每个员工的薪资和个人信息。
在这两个例子中，虚拟技术都不是造成信息泄露的罪魁祸首，但由于技术人员在应用该技术的过程中没有清楚的意识到它可能引起的安全隐患，才在无意中把数据暴露给那些不该拥有访问权限的人。
完整性 —— 虚拟系统的应用也可能影响到数据的完整性。虚拟机能够被简单的复制和移动这个特性就暗藏着一个最大的忧患。下面举两个例子来说明其中的原因：
- 比方说虚拟机 A 连接到一号数据库，然后所有的读写操作都如设计的那样正常运行。如果把虚拟机 A 拷贝到虚拟机 B，这两个虚拟机都拥有相同的权限以相同的方式访问一号数据库。如果整个系统采用的机制处理不当的话，就有可能导致这个数据库中的数据被覆写，也有可能导致数据无法正确的得到 commit。因此，如果覆写应用程序，而这一应用程序又将被置于虚拟机的话，覆写时就需要确保以正确的方式访问数据。
- 再比如一个 server farm 中的服务器是同一个虚拟机的复制镜像，假设这些镜像是虚拟机 1－5。再假设虚拟机 1 发生服务断供，但是由于倒班，夜班轮值的系统管理员没有意识到发生断供的只是一个虚拟机，于是在这个虚拟机 1 上做了一些修补，并且重启了该系统。这样一来，本该完全一致的五个系统之间就有了偏差。这可能影响到性能，也可能在开始审核的时候引发有关违反既定步骤及操作的争议。出于这个原因，如果在发生断供的时候对其中任何一个虚拟机作任何修改，管理员应当在核心复制镜像上做同样的修改。在排除紧急故障之后，这些修改都应该复制到核心复制镜像上，核心复制镜像则负责将修改再复制到其它镜像上。
无论何时无论引入什么新技术，总有那么个人（往往是那些让人喜出望外的开发人员）迅速宣布说这项技术可以解决你所面对的所有问题，说它多么地事半功倍。虚拟技术也未能免其俗，当时提出的最大的卖点恰恰是上文所提到的可能带来的安全忧患，正所谓世上没有十全十美：
攻击管理程序 —— 对于物理系统的每个层次，都存在着相对的攻击，虚拟机的使用则又添加了一个新的层次。除了物理层、网络层、系统层、应用层，有时候也可能带有的数据库层以外，引入的虚拟技术可能引发针对虚拟机管理程序的攻击。这些攻击大致有下列几种类型：
- DOS 攻击——这类攻击永远是选择脚本工具的小孩最喜欢的“恶作剧”。这类攻击旨在关闭管理程序，“顺手牵羊”再关掉几台机器，为攻击者继续下一步活动省下不少时间。和针对单一物理系统的 DOS 攻击相比，同样的多路复用功能是虚拟技术的至宝，却也可能被利用而成为祸害。
- 虚拟机跳转 —— 攻击者在利用管理程序中的安全漏洞后以某个一般用户的身份登录其中一个虚拟 host，之后又跳转到另一个 host，比如从一个 windows host 跳转到另一个 host 上，这样的攻击是可能的。尽管目前还没有人明确指出有类似的漏洞存在，但这样的攻击完全是有可能实现的。实际上，在最初实现虚拟 LAN（即 vLAN）的时候，系统是可以通过重新标上另一个 802.1q 的标签，从而允许用户跳转到另一个 lan 上。
- Host 网络通信拦截 —— 攻击者还有可能利用管理程序来监听系统之间的调用。某些时候，一些“寄宿”的操作系统有可能向“宿主”系统发送系统调用请求，甚至是发送调用硬件的请求。一旦攻击者攻破系统就能跟踪到相关的分页文件、内存或者磁盘读写等。
尽管目前为止还没有在管理程序中发现很多漏洞，但这也可能因为虚拟技术还处在发展初期。任何新技术受到的关注越多，被发现的漏洞就越多。曾经有人引用 OpenBSD 的创始人 Theo de Raadt 说过的一段话：“如果你不是个愚笨的人，如果你相信全世界那些无法编写出一个不含有安全漏洞的操作系统或应用程序的工程师中还是能找到一群人突然之间写出一个没有任何安全漏洞的虚拟层来，那你绝对是鬼迷心窍了。”
实现虚拟技术时，在把虚拟 host 和管理程序转移到产品服务器之前，估量可能产生的影响是非常重要的。最需要值得注意的是，明确指定规则，根据这些规则来决定哪些应用程序能够保留在同一个管理程序下，决定该如何移动这些虚拟系统。
规则应该按需要做适当的更新，防止保留在同一个管理程序下的应用程序的合并。比如说，一个安全度比较低的应用程序, 就不应该和可以从 Internet 访问的虚拟 host 保留在同一个系统上。尽管目前没有什么危险，但一旦明天发现什么新的漏洞，这两个应用程序马上就深陷危机了。现今已经有很多安全规则都指明了系统应该如何与逻辑观念划分开来，指明了应用程序是否应该和数据库分隔开来。然而，在应用虚拟技术的时候这些规则就有点过时了。在实现虚拟技术之前更新这些规则，也许能够减少今后的麻烦，也避免在执行系统移植时受到负责安全的工作人员的反对。
需要更新的第二个地方则是虚拟 host 活动所遵循的规则。应用程序、数据库或系统保留在物理 host 上时，移除数据就比较困难，并且系统也常常会被重建。鉴于这些原因，数据可以相对地保留在那些需要使用这些数据的对象上。在虚拟技术下，复制虚拟 host 还会造成额外的麻烦。数据的复制镜像可以在原数据载体之外移动，但原始数据本身却仍然保持最初状态。这时候就可能发生数据偷窃，而且如果两个虚拟机都配置有访问同一个数据库的能力，那么就会发生数据异常。由于这些原因，必须重新制定规则，在改写规则的时候应该考虑到系统的虚拟实例。
另一个你可能需要考虑的操作是使用“master”虚拟机。使用 master 的话，产品的复制就可以推到管理程序中去。一旦有任何修改，无论修改发生在系统的哪个点上，都可以通过 master 移植到所有的镜像上。在将新的修改以波浪式推入到各个镜像中去的过程中，还应该要允许系统能够连续回复其所收到的请求，允许在发生任何问题的时候实现系统升级失败回滚。此外，如果使用 master 复制，开发和测试环境都应该及时刷新，使用 host 最新的复制版本。
事实证明，虚拟技术正如其最初所承诺的那样，确实是系统管理和开发的福音。但在它确确实实实现它的潜能之前，安全因素仍然需要周密考虑。和所有技术一样，在把技术投入实现之前，都必须做缜密的分析。在选择实现虚拟技术之前，分别度量对业务和保密性、数据完整性、可访问性的需求，才能把虚拟机用在该用的地方，真正发挥它的优势，尽量避免在供应商的压力下盲目使用。
查阅英文原文： Virtualization and Security 。
志愿参与 InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。
评论