在本系列的前一篇文章“虚拟网络的隐藏风险”我们讨论了微软Hyper-V虚拟网络系统中的潜在风险问题。那些准备实施虚拟化架构的管理员，应该把这些安全相关的问题加入规划时的考虑因素中去。那些系统中随处可见的虚拟化管理程序（hypervisor），为我们的虚拟主机带来了很多单点故障的潜在风险。而且静态的虚拟机如果不能随着系统环境不断升级更新的话，也增加了其发生风险的可能性。
　　
　　但是您是否也同样了解运行虚拟机本身也会带来一些潜在的风险。尤其是在虚拟机托管的管理方式中，假如管理本身存在问题时，我们就需要面对很多安全风险和法规遵从方面的问题。

　　在配置管理物理机时，不同的法规提供了不同级别的安全规范要求。美国联邦桌面核心组态（FDCC The Federal Desktop Core Configuration standard）和支付卡行业数据安全标准（PCI DSS the Payment Card Industry Data Security Standard），在安全管理和基础架构要求上，是一些相对比较特殊的行业规范要求。其他的一些，如美国金融服务现代化法案（Gramm-Leach-Bliley Act）和塞班斯法案（Sarbanes-Oxley Act），则是相对比较通用的安全要求。TechTarget特约专家Michael Cobb曾经在文章“PCI DSS and its impacts on virtual environments in an article”中分享了一些虚拟环境及安全法规的相关内容。

　　在那篇文章中，他指出在PCI DSS 2.2.1规范中要求每台服务器只能提供单一的功能服务。这样的话，一台运行了多个虚拟机的虚拟主机就和这项要求相违背。另外，在法规中要求，对数据的安全管理、检测、诊断和修复需要在系统内进行，以确保数据一致性。通过这些要求方式，确保了当有变更发生时，用户所有操作都有日志可查、不同主机间是相互隔离的，而且可以获得相应的风险提示。

　　安全问题在物理机环境中已经是非常大的一项挑战了，通常需要部署多种产品以达到法规遵从的目的。但是在虚拟机环境中，这种挑战变得更加地复杂和艰巨。

　　在一个高可用的虚拟环境中，虚拟机的部署不是一个静态的过程，而是处在不断地迁移过程中。我们假设有一个部署了多个Hyper-V节点的集群环境。在一段时间之后，由于负载均衡和主机故障恢复的原因，很可能一些虚拟机已经动态地从一台主机迁移到另外一台主机上。一般来说，我们认为这是虚拟环境的优势之一，因为这种高可用的架构确保了虚拟机即使在发生故障的情况下仍然可以持续运行。

　　但是，如同我在这个系列的前一篇文章“virtual networks are not like physical networks”中提到的：虚拟网络环境和物理环境是不同的。通常我们看到的Hype-V虚拟交换机只是思科物理设备的一个子集。一些物理设备中常见的，如建立访问控制列表（ACLs）的方式并不能适用于Hyper-V主机的虚拟网络交换机中。这些ACL可以对到达虚拟主机的访问起到一定防护作用，但是对于主机内部，同一个虚拟交换机上的虚拟机之间的通讯，并不能发挥相应的功能。这样的话，对于同一虚拟交换机之间的主机而言，就无法在网络层实现分离，因而失去了应有的防护。

　　因此，那些高安全性和法规遵从性的虚拟机负载，决不能允许安置在同一台主机上。实现这个目的的方式有很多种。第一种方式是明确地指定，哪些节点可以访问和管理这些特定地虚拟机。这可以通过在Failover Cluster Management管理向导中指定虚拟机集群资源的所有者的方式来实现。如果您只有很少几台虚拟机不能做到分类处理，您可以通过配置每台虚拟机所有者之间的排它性访问权限来实现，以阻止他们在同一个节点内部做故障切换。

　　第二种方式是使用微软在Windows操作系统中内置的主机层防火墙功能。这项服务可以阻止虚拟机在内部随意地切换，但是在很多环境的安全策略中，并不支持使用微软的主机层防火墙作为唯一的安全管理方式。

　　第三种方式是根据安全级别的要求，创建多个不同的虚拟机集群。那些需要高安全和法规遵从的虚拟机可以单独放置在属于它们自己的集群系统中，从而可以为这些集群设置特殊的管理规则。那些要求相对较低的，如提供基础设施服务的主机，就可以转移到低安全级别设置的环境中。

　　我写这一系列文章的目的是为了帮助您更好地意识到，在虚拟机解决很多问题的同时也给我们带来了更多地挑战。尽管相比物理机环境，虚拟化在节省物理空间、电源和冷却等方面取得了令人瞩目地成绩，而且它可以很有效地改善IT环境的管理。但是它同样为我们提出了一系列需要提前规划地安全管理问题，管理员们需要意识到：虚拟环境和物理环境相比，在管理和准备工作上是有非常大差别的。