我与许多虚拟化安全人员有过交流，他们正在耐心地等泄露的VMware虚拟机管理程序代码下一次公之于众。但是许多人真正心存疑问的是，这会不会因而改变威胁格局、导致风险加大到让人无法接受的地步。我们不妨看一下当前虚拟机环境里面的虚拟机管理程序威胁格局，确定情形是不是果真如此，这类源代码会在哪些方面带来影响。在源代码完全公之于众之前，现在可不可以采取任何措施，更有效地保护自己的环境?不过，我们首先应该明白一点：VMware的代码已经被许多人看到了，不仅仅是VMware内部的人，还有其他机构的人：具体来说指发布通用标准评估保证等级(CC EAL)认证的那些人，还有某些合作伙伴(以便集成工作可以继续开展下去)。除此之外，我们还要明白虚拟机环境当前面临的威胁，确定风险会不会加大。虚拟机环境主要面临如下几个方面的威胁，它们可能触及虚拟机管理程序，也可能不触及。
•管理层
管理层威胁最容易被人钻空子，可能会引起最严重的危害，那是由于它们让攻击者能够以管理员用户、授权用户或其他重要用户的身份访问虚拟机管理程序管理层。倘若不法分子获得了这种访问权，就能影响虚拟机的可用性、完整性和机密性。这类攻击有可能让不法分子完全访问所有虚拟机。VMware的虚拟机管理程序的管理堆栈里面仍有一个未知因素，那就是驻留在虚拟机管理程序本身内部的管理组件里面所使用的API(应用编程接口)。
•虚拟机逃离
虚拟机逃离攻击(Escape the VM attack)似乎是所有虚拟机环境攻击的祸根，因为攻击有可能从一个虚拟机跳转到另一个虚拟机。在云环境中，这可能会带来灾难性的后果，因为一个租户(即用户)会影响另一个租户的虚拟机的机密性和完整性。尽管这种类型的攻击其可能性确实存在，还没有发生过攻击在虚拟机之间跳转的一起事件。在1型虚拟机管理程序上，我们已经看到了这一幕：来自最近邻居的指令(首先攻击亚马逊Xen，后来迅速得到消除;机密性)，导致虚拟机崩溃(通常与准虚拟化的驱动程序有关;可用性)，但是不法分子还无法在虚拟机之间跳转。可以访问与虚拟机管理程序里面的虚拟机管理层有关的代码，也许会改变这种威胁格局，但是考虑到现在有那么多只眼睛盯着这种类型的攻击，风险也许不会大幅加大。
•驱动程序攻击
驱动程序攻击是旨在从下面发动的攻击，几乎总是会影响虚拟机环境的可用性和完整性。尽管所有主要的厂商都针对VMware虚拟机管理程序开发了驱动程序，但是我们不知道每一种设备的内部组件。考虑到驱动程序几乎都像Linux，我们在过去能够猜测到那些内部组件。
•直接的虚拟机管理程序攻击
目前没有任何直接的虚拟机管理程序攻击，所有攻击目前都通过管理API、驱动程序或者企图从访客操作系统里面进入到虚拟机管理层来发动。虚拟机管理程序与所有这些组件进行联系，以便根据需要来调度和分配资源。然而，配置不当的虚拟工作负载会给其他工作负载带来不利影响，导致拒绝服务，最终影响虚拟机的可用性。毕竟，这是一种共享式资源环境。拥有虚拟机管理程序的代码会加大这种风险，但是攻击仍需要通过其他层才能发动。
•存储攻击
现在有越来越多的攻击企图直接绕过虚拟机管理程序，径直针对存储层。这些攻击企图给虚拟机管理程序分配存储资源的机制带来不利影响，或者窃取驻留在磁盘上的数据。一些攻击采用了虚拟机管理程序管理层攻击以访问存储系统，但我们将那些攻击归入到虚拟机管理程序管理层攻击;而存储攻击只针对存储网络及相关组件。这种攻击会影响虚拟机的可用性、完整性和机密性;拥有清楚定义了数据在存储上位置的代码将有助于这些攻击。
这每一种攻击都会带来各自的风险，可能会招致灾难。但是我们不妨关注一下现有的两种开源虚拟机管理程序：Xen和KVM。这些虚拟机管理程序广受检查，而且其代码一开始就公之于众;但我们仍没遇到过虚拟机逃离攻击、驱动程序攻击或针对特定虚拟机管理程序的驱动程序攻击得逞的情况，但是的确遇到过管理层攻击和不是针对特定虚拟机管理程序的存储攻击。没错，这种代码公布后，遇到更多管理层攻击的可能性确实加大。但是我们还不知道代码与潜在攻击诡计有着怎样的联系。
那么，面对这种代码的公布，我们该如何防患于未然呢?那就是遵循最佳实践。比如隔离你的管理网络，采用基于合理角色的访问控制措施，确保任何第三方的驱动程序来源可靠，在你的虚拟机容器里面设定所有的隔离设置，静态磁盘加密，合理运用资源限额，以及限制准虚拟化驱动程序的使用。所有这些最佳实践我们之前有过讨论。
代码公之于众后，任何因这种代码公布而起的攻击很快就会出现，但是这会导致风险比你今天面临的风险更大吗?不会，如今我们在管理组件方面的安全原本就很松懈，没有遵循最佳实践，也没有注意机密性和完整性。如果这些方面我们都做到了，就会拥有安全的多租户环境，而不是仅仅可信任的环境。
现在越来越多的企业在运用最佳实践来保护虚拟机环境，但是我们离实现目标还有很长一段路要走。单单进行适当的管理网络隔离就是项艰巨的任务。如果说目前你的虚拟机环境面临实际风险，那就是没有遵循现有的最佳实践，而不是说代码即将泄密。
