【虚拟化安全】全面虚拟化安全风险列表&专业安全建议

本文罗列了服务器虚拟化、桌面虚拟化、网络虚拟化、存储虚拟化及应用虚拟化5种虚拟化方式可能存在的安全风险，并为各种风险提供了安全建议。快来检测一下你的虚拟化环境安全吗？

一、服务器虚拟化

编号	安全风险	安全建议
（一）	服务器虚拟化技术自身的潜在缺陷，会引起若干安全风险
（1-1）	虚拟机逃逸是指利用虚拟机软件或者虚拟机中运行的软件的漏洞进行攻击，以达到攻击或控制虚拟机宿主操作系统的目的。由于新技术的潜在缺陷，这种攻击的可能性很大，攻击者可能渗透到管理系统（裸机型）、HostOS（宿主型）或其它GuestOS中，实现对系统的拒绝服务、越权、甚至并安装Rootkit实现完全控制。	安装、使用最新版本的虚拟机软件，在安装虚拟机相关插件时考虑其安全性。
（二）	服务器虚拟化受服务器硬件实体影响，会引起若干安全风险
（2-1）	服务器虚拟化后，每台服务器都将支持若干个重要的资源密集型应用程序，这些应用程序将会争夺同一硬件服务器的带宽、内存、处理器和存储等资源，在这个过程中这些关键应用程序可能会遇到网络瓶颈和性能问题，并且可能会引起服务器负载过重。	合理分配带宽、内存、处理器和存储等资源，并进行实时监控和动态调整。
（2-2）	服务器虚拟化后，多个GuestOS存在于一个服务器硬件实体上，一但硬件出现断电、机器过热升温、硬盘等故障问题导致服务器或HostOS崩溃，多个GuestOS将都受到影响，这样所有的应用都会中断，这种环境比常规环境中一台服务器崩溃引起一个应用中断带来的问题要严重的多。	保障机房基础环境的温度、湿度在合理范围，保障电力供应，防范机房漏水
（2-3）	同一台物理机上安装的多个虚拟化服务器中的一台或多台在遭受到拒绝服务攻击后，由于CPU、内存过渡消耗导致该物理机及其他虚拟化服务器无法响应	部署抗D产品，合理分配资源
（2-4）	采用虚拟化安全产品时，比如Vmsafe开启全面的深度包检测或内存分析时，可能导致开销过大	部署VMsafe之前，需要首先完成相应的计划、测试和评估工作
（三）	服务器虚拟化影响传统网络架构，会引起若干安全风险
（3-1）	采用虚拟化技术之前，用户可以在防火墙设备上建立多个隔离区，进行严格的访问控制，对不同的服务器采取不同的规则进行管理，即使有服务器遭受到攻击，危害仅局限在一个隔离区内，影响范围不会太大。而采用虚拟化技术后，所有GuestOS会集中连接到同一台虚拟交换机或实体交换机与外部网络通信，使得原来通过防火墙采取的防护措施就会失效，如果一台GuestOS发生问题，安全问题就会通过网络扩散到其他的GuestOS。	安装虚拟防火墙并进行访问控制规则的设置
（3-2）	采用虚拟化技术之前，用户可以在网络中通过镜像、Netflow等方式进行端到端的流量监听与检测。采用虚拟化技术后，来自相同物理机上的VM之间，其通信流量不经过传统的网络之间，无论是VM之间的攻击数据，还是攻击之后传输数据的隐蔽信道，传统的基于网络流量监听的检测技术都将完全失效，如：入侵检测、审计等。（虚拟机间通过硬件的背板而不是网络进行通信）	安装虚拟IDS、防毒墙，对相同物理机上的VM之间的流量进行入侵检测和病毒防范。
（四）	服务器虚拟化影响传统运维技术，会引起若干安全风险
（4-1）	在虚拟机迁移中，常见有静态迁移和动态迁移，无论那种形式，虚拟机在不同服务器之间迁移并且这种迁移经常会是自动完成，这可能会让一些重要的虚拟机迁移到不安全的物理服务器上。	在进行虚拟机迁移时，确保迁移后的物理服务器所在区域的安全级别高于或等于迁移前的物理服务器。
（4-2）	虚拟化存储的动态迁移过程，无法对数据进行分类，存在泄漏重要数据的风险。	建议对存储的迁移进行安全管理，例如对重要数据采用手动迁移的策略。
（4-3）	从原来的物理机将系统迁移到虚拟机平台上(P2v)，或是将虚拟机从这个虚拟平台迁移到另一虚拟平台上(V2V)。其成功迁移的前提条件是迁移前后的物理机必须拥有类似甚至完全相同的硬件,源和目的的差异很有可能造成迁移的失败。	提前确认迁移前后的物理机是否拥有完全相同或类似的硬件并测试迁移是否能成功。
（4-4）	许多用户会保持重要的VM镜像，这些标准VM镜像可以制作出新的虚拟机，从而快速部署或灾难恢复，但是这样一来，标准VM镜像的脆弱性就会被复制传播，如杀毒软件病毒库未更新、系统补丁未升级等。	定期对VM镜像进行补丁更新和病毒库更新，在需要快速部署或灾难恢复前确保补丁和病毒库为最新。
（4-5）	为GuestOS安装补丁的进度跟不上为虚拟机用户使用的实际需要。每个GuestOS仍是一台单独的服务器，每个GuestOS必须像单独的物理服务器那样使用补丁和维护以便及时修补潜在的安全漏洞。	虚拟机也要和物理服务器一样，需要对操作系统和应用程序进行及时的补丁更新。可以考虑使用WSUS补丁更新服务器。
（4-6）	采用虚拟化技术之前，针对服务器的加固主要是操作系统及应用的加固，采用虚拟化技术后，服务器的加固包括物理服务器（HostOS）加固、虚拟化应用（Hypervisor）的加固、GuestOS及其应用的加固、VM镜像的加固，对传统的加固提出了挑战，对技术人员的水平提出了更高的要求。	制定安全配置基线，对虚拟化服务器各部分进行安全加固。
（4-7）	虚拟化灾备的安全管理，由于虚拟化设备需要定期的自动备份，对这些备份的镜像的管理和镜像备份的手段的安全性，如备份服务器的安全性以及备份数据的安全性等。	建议对灾备区域进行安全规划，并制定严格的保密措施。
（4-8）	虚拟化的数据销毁机制，残存数据是否能够完全粉碎，防止数据恢复窃取机密信息。	建议建立数据销毁机制，并利用文件粉碎类工具进行销毁。
（五）	服务器虚拟化的采购管理中，外部环境“不成熟”会引起若干安全风险
（5-1）	企业遭受服务器虚拟化产品厂商的“绑架”。由于至今尚无虚拟化格式标准出现，各虚拟化产品厂商的产品间无法互通或转移，这将会使用户系统与某一种虚拟化产品死死地绑在一起。一旦这一产品系列停止研发或其厂商倒闭，用户系统的持续运行、迁移和升级将会极其困难。	确认虚拟化产品的兼容性、可靠性、可扩展性能否满足实际需求。尽量选择领导型的厂商、具有一定标准和向市场开放的产品，这样在一定程度上，可以有效地规避这一问题。
（5-2）	服务器虚拟化产品厂商技术支持不足并依赖厂商支持	确认虚拟化产品厂商能提供及时有效的售后服务。
（5-3）	服务器虚拟化产品已知漏洞修复时间过长或无人修复	确认虚拟化产品厂商有充足的研发实力对后续发现的漏洞进行及时有效的修复。
（六）	服务器虚拟化的运维管理中，会引起若干安全风险
（6-1）	测试用虚拟机与重要的虚拟机存放于同一虚拟局域网中，这会给渗透攻击带来机会。	按照重要程度的不同，将虚拟机划分到不同的Vlan当中。
（6-2）	存在问题的虚拟机组不经加固接入生产环境	虚拟机组在接入生成环境前需进行加固和恶意代码排查，并确认各虚拟机使用的IP、主机名等特有信息，避免接入后产生网络冲突。
（6-3）	使用移动存储设备若能够拷贝VM镜像，可能会面临随意传播甚至泄露	禁止使用移动存储设备访问存放VM镜像的主机，或在管理上进行要求。
（6-4）	VM镜像不定期加固或更新升级，可能导致漏洞未及时修补，更易遭受攻击风险。	针对VM镜像制定合理的补丁更新计划。
（6-5）	GuestOS补丁若使用已有的补丁管理系统，需要考虑兼容性，或授权范围。	测试GuestOS与补丁管理系统的兼容性，确保授权范围内的GuestOS均可以下载、安装补丁程序。
（6-6）	服务器虚拟化的管理员权限过大，对HostOS和GuestOS过度使用。	限制虚拟化管理员的权限在合理范围内。
（6-7）	使用终端管理软件进行终端管理时，可能由于兼容性问题导致终端管理功能失效。	测试终端管理程序对GuestOS进行管理时，相关管理功能是否可以生效。
（6-8）	部分管理方式无法通过堡垒机进行安全管控，比如使用client连接vSphere	采用其他策略，比如设置ACL对client的IP地址进行限制。
（6-9）	没有设置专门进行虚拟化运维的团队	建议设置虚拟化运维岗，对虚拟化知识进行系统学习、应用和传播。
（6-10）	VM镜像版本控制不严格导致将存在安全问题版本的VM上线	对VM镜像进行版本控制，并辅以明确的标记。
（七）	服务器虚拟化的合规管理中，会引起若干安全风险
（7-1）	安全等级或安全区域不同的Guest OS部署在同一物理机	在同一台物理机上，安装安全等级类似或相同的Guest OS
（7-2）	相同物理机上VM之间的流量难以进行传统的安全审计	开启操作系统和应用程序的日志审计，详细记录各种事件

编号	安全风险	安全建议
（一）	桌面虚拟化技术自身的潜在缺陷，会引起若干安全风险
（1-1）	桌面虚拟化的安全性，依赖于用户选择的技术实现的方式，因此存在由于技术自身缺陷，如0day漏洞等，可能会导致桌面虚拟化不可用或导致其他的安全风险	及时关注厂商安全通告，及时对产品进行安全补丁更新和升级
（二）	桌面虚拟化受硬件实体影响，会引起若干安全风险
（2-1）	服务器端采用虚拟化技术，如vSphere、XenServer、Hyper-V等，可能存在由于产品自身缺陷或漏洞被利用，导致服务器端崩溃和不可用	及时了解和关注产品安全公告，加强漏洞管理，及时升级更新
（2-2）	单个服务器可接受的用户数或客户端连接数未进行限制，导致资源负载过高	设置安全基线和配置规范，对客户端连接数进行合理配置，合理分配资源
（2-3）	如客户端使用胖PC机的方式，可能由于自身的安全问题，如补丁缺失、病毒蠕虫等影响网络中的桌面虚拟化应用	严格限制胖PC的方式在桌面虚拟化环境中的使用
（三）	桌面虚拟化影响传统网络架构，会引起若干安全风险
（3-1）	客户端不直接与外部网络进行连接，业务通讯都由服务器端服务转发，在服务器端出现网络故障时，会直接影响客户端桌面的可用性	服务器端进行网络冗余设置
（3-2）	BYOD手持设备会导致在不安全的网络中登录或使用远程虚拟桌面	为BYOD设置安全的登录方式，选取安全的客户端连接程序
（3-3）	网络的边界不再仅限于办公环境和数据中心之间	合理区分网络区域和边界，在新的边界区域采取合理的安全措施
（四）	传统技术对桌面虚拟化的影响，会引起若干安全风险
（4-1）	终端用户连接远程虚拟桌面，数据泄密的风险	使用SSL加密、VPN、SDH专线等传输等方式进行连接
（4-2）	终端用户登录用户名和密码暴力破解的风险	使用OTP等技术，防止用户名密码遭受暴力破解攻击
（4-3）	终端用户连接远程虚拟桌面，未设置连接超时，导致身份冒用	设置严格的超时限制，防止冒用
（4-4）	终端用户非法复制粘贴服务器端的数据	在桌面虚拟化组件中禁用或者单向禁用粘贴板
（4-5）	终端用户非法使用USB设备进行映射，拷贝敏感数据	允许或禁止USB映射，终端上禁用USB接口，单向配置USB只读
（五）	桌面虚拟化的采购管理中，外部环境“不成熟”会引起若干安全风险
（5-1）	各厂商的桌面虚拟化产品，安全特性、功能侧重点各不相同，导致存在不同的安全风险。	采购前，充分考虑安全需求和业务实现，寻找最佳的平衡点
（六）	桌面虚拟化的运维管理中，会引起若干安全风险
（6-1）	移动终端的设备管理不善容易出现敏感数据泄漏的风险	设置严格的安全策略，限制在移动终端设备上保存诸如用户名和密码等敏感信息
（七）	桌面虚拟化的合规管理中，会引起若干安全风险
（7-1）	使用BYOD模式，在合规上，由于移动终端设备的特殊性，导致安全管控缺失。	设置严格的安全管理制度，满足合规需求

二、桌面虚拟化

三、网络虚拟化

编号	安全风险	安全建议
（一）	网络设备虚拟化后OS自身的潜在安全缺陷，会引起若干安全风险
（1-1）	网络层设备的虚拟化相较于传统硬件网络设备，属于较为新兴的技术和发展方向，传统的硬件设备经过多年的考验和漏洞修复，自身OS安全方面较为强壮，而虚拟化网络设备在这方面刚刚起步不久，自身OS会存在潜在的安全缺陷。	定期关注厂商官网发布的安全更新，如有重大安全漏洞，应当及时升级OS为较新的稳定版本
（二）	网络设备虚拟化受服务器硬件实体影响，会引起若干安全风险
（2-1）	网络虚拟化后，虚拟网络设备本身的资源控制机制，以及依赖服务器底层系统的控制，可能存在性能瓶颈，影响终端的可用性。	合理分配带宽、内存、处理器和存储等资源，并对硬件服务器和虚拟网络设备的性能进行监控，调整到合理的范围内
（2-2）	网络设备虚拟化后，多种网络支撑设备均存在于一个服务器硬件实体上，一但硬件出现断电、机器过热升温、硬盘等故障问题导致虚拟网络设备崩溃，其上的客户端和应用将全面受到影响，这样所有的应用都会中断，导致业务中断。	保障机房基础环境的温度、湿度在合理范围，保障电力供应，防范机房漏水
（2-3）	同一台物理机上安装的虚拟网络设备在遭受到拒绝服务攻击后，由于CPU、内存过渡消耗导致该物理机及其他虚拟化终端无法响应	部署抗DDoS产品，合理分配资源
（三）	网络设备的虚拟化影响传统网络架构，会引起若干安全风险
（3-1）	采用虚拟化技术之前，用户可以在网络中通过镜像、Netflow等方式进行端到端的流量监听与检测。采用虚拟化技术后，来自相同物理机上的虚拟网络设备之间，其通信流量不经过传统的网络，传统的基于网络流量监听的检测技术都将完全失效，如：入侵检测、审计等。（虚拟网络设备间通过硬件的背板而不是网络进行通信）	利用虚拟化的网络安全设备对虚拟网络进行安全规划，如安装虚拟IDS、防毒墙，对相同物理机上的虚拟网络设备之间的流量进行入侵检测和病毒防范。
（四）	网络设备虚拟化的采购管理中，外部环境“不成熟”会引起若干安全风险
（4-1）	企业遭受网络设备虚拟化产品厂商的“绑架”	确认网络虚拟化产品的兼容性、可靠性、可扩展性能否满足实际需求。
（4-2）	网络设备虚拟化产品厂商技术支持不足并依赖厂商支持	确认网络虚拟化产品厂商能提供及时有效的售后服务。
（4-3）	网络设备虚拟化产品已知漏洞修复时间过长或无人修复	确认网络虚拟化产品厂商有充足的研发实力对后续发现的漏洞进行及时有效的修复。
（五）	网络虚拟化的运维管理中，会引起若干安全风险
（5-1）	缺乏网络虚拟化专门的运维人员/团队，虚拟化网络的配置和使用方式和传统同类型硬件设备有较大的不同，可能会导致配置不当或配置缺陷的问题发生。	针对运维人员进行网络虚拟化培训和相关厂商的虚拟化网络设备培训。
（5-2）	虚拟网络设备的不定期加固或更新升级，可能导致漏洞未及时修补，更易遭受攻击风险。	针对虚拟化网络设备制定合理的OS更新计划。
（5-3）	网络设备虚拟化的管理员权限过大，对HostOS和GuestOS过度使用。	限制网络设备虚拟化管理员的权限在合理范围内。
（5-4）	虚拟化网络设备自身的安全配置问题，可能因部分安全功能未启用而导致潜在的安全攻击等。	定期对虚拟化网络设备进行安全评估和加固。

四、存储虚拟化

编号	安全风险	安全建议
（一）	存储虚拟化技术自身的潜在缺陷，会引起若干安全风险
（1-1）	虚拟存储技术最受关注的问题是数据安全问题,因为虚拟存储把所有数据都放在了一个系统环境下,一旦出现安全事件，将导致严重的信息泄露。	制定严格的、各层次的、全方位的访问控制策略，依据最小权限原则限制读取、写入和其他操作。
（1-2）	一款存储虚拟化产品只能对有限的存储空间起作用，其扩展性和性能可能成为瓶颈。	在部署产品之前要进行系统测试，提前对扩展性进行评估。
（1-3）	当前的存储虚拟化技术在数据库的支持方面不够，如果对这些结构化的数据类型不太注意，造成的后果可能不堪设想。	对于存储结构化数据，需要与厂商确认并进行测试，确保不存在结构化数据丢失、损坏等情况发生。
（1-4）	存储虚拟化允许同一个虚拟池上存储设备的简单数据迁移以及异构磁盘子系统的复制，那么，企业关键数据的第二份拷贝的安全性将尤为重要。	对于企业关键数据的拷贝，应限制可以进行此操作的人员，并详细记录拷贝后的位置、创建时间、大小等信息，并加强拷贝文件的安全性。
（二）	存储虚拟化的采购管理中，外部环境“不成熟”会引起若干安全风险
（2-1）	基于阵列的存储虚拟化产品只是对自己厂家的产品有效。基于主机或者光纤的存储虚拟化产品也是对某些特定厂家的软件或者设备有效。	需要检查存储虚拟化产品是否跟自己当前的存储环境兼容。
（三）	存储虚拟化的运维管理中，会引起若干安全风险
（3-1）	实施存储虚拟化之后，对于数据生命周期的管理，每天的数据备份、数据保护、归档以及灾难恢复为企业管理带来了新的挑战。	由存储管理人员根据新情况制定完善的备份、恢复计划，关注数据生命周期的整个过程并采取相应措施。
（3-2）	对于企业关键业务，存储管理人员需要重新考虑新的虚拟存储环境的适用性，欠缺的考虑可能导致关键业务运行不稳定等后果。	完善测试企业关键业务在虚拟存储环境的适用性，包括业务稳定性、业务响应时间、业务数据完整性等关键指标。
（3-3）	在实施虚拟化之前，存储系统可能处于一种分散、难于管理的状态，虚拟化之后，存储管理人员可以把多个存储系统整合到一个网络环境中去，而通过统一的方式去管理这个网络环境。这给管理人员决定何时实施存储虚拟化带来了挑战，不恰当的实施时间会增加企业大量的成本。	合理评估实施存储虚拟化前后的差异，依据这些差异决定合适的实施时间。
（3-4）	在实施存储虚拟化过程中，未对企业业务数据进行合理分类和规划，导致存储虚拟化效率降低，并增加管理成本。	对企业业务数据进行合理分类和规划，对企业关键数据、结构化数据、个性化数据分别进行安全性、数据可用性等测试。
（3-5）	缺乏对存储层次、服务级别的规划，导致实施存储虚拟化过程中制定错误的策略。	在数据访问、数据可用性、数据安全、数据响应时间、数据保护等服务级别之上，针对重要业务（如灾难恢复）进行高优先级处理并存储在高性能的存储层次之上。

五、应用虚拟化

编号	安全风险	安全建议
（一）	应用程序虚拟化技术自身的潜在缺陷，会引起若干安全风险
（1-1）	应用程序虚拟化只支持Windows操作系统平台，对Linux/UNIX系统平台不支持或支持差。	在Windows操作系统平台上搭建AppV
（1-2）	基于代理的应用程序虚拟化要求应用程序在可以运行前代理必须可用，那么代理程序自身的可靠性、稳定性、安全性就显得更为重要。	确认代理程序自身的可靠性、稳定性、安全性，当有更新版本时及时进行更新。
（1-3）	无代理的应用程序虚拟化是完全可移植的，任何用户可以复制一个无代理的虚拟化应用程序并拿到任何系统上运行。	嵌入许可和许可保护机制到已封装的应用程序中，确保程序只能在允许的环境运行。
（二）	应用程序虚拟化受服务器硬件实体影响，会引起若干安全风险
（2-1）	应用程序虚拟化后，可能由于同时连接虚拟化服务器的终端过多，或有多个耗资源的应用程序同时运行，导致服务器性能不足，无法为更多终端提供服务。	合理分配应用程序虚拟化服务器服务的终端数量和提供的应用程序数量。
（三）	应用程序虚拟化影响传统运维技术，会引起若干安全风险
（3-1）	应用程序虚拟化需要对所有的应用程序进行重新部署，且需要全新“干净”的操作系统支持，在部署后还要进行测试。这给运维人员带来了较大的工作量和复杂度。	首先对要求最苛刻的应用程序进行部署，并确认程序能否正常运行，再逐步部署其他应用程序并逐个测试。
（四）	应用程序虚拟化的采购管理中，外部环境“不成熟”会引起若干安全风险
（4-1）	AppV软件包需要运行在最新版本的Windows操作系统上时，需要AppV引擎升级到支持最新版本Windows操作系统，但这段升级的时间并不由我们主导。	确认应用程序虚拟化厂商有充足的研发实力能提供新的AppV引擎对新版Windows操作系统进行支持。
（五）	应用程序虚拟化的运维管理中，会引起若干安全风险
（5-1）	AppV技术依靠本地的缓存来运行应用程序，不合理的缓存控制可能导致磁盘空间占满或应用程序的滥用。	根据所需应用程序的持续性制定缓存控制措施。
（5-2）	当虚拟应用程序需要更新时，只需更新中央存储库，如果中央存储库中更新的应用程序存在安全风险，将导致存在安全风险的应用程序快速传播。	建议从应用程序官方网站下载应用程序，在执行病毒扫描、MD5校验等安全措施后，由专人负责对中央存储库中的应用程序进行更新。
（5-3）	大多数AppV技术与活动目录集成，需要创建组并将其附加到应用程序分配中，组中的用户将拥有访问应用程序的权限，因此，不合理的应用程序访问权限分配将导致未授权用户对应用程序的访问。	确认附加到应用程序的组成员是否应该有访问应用程序的权限，并设置应用程序的许可数量。
（5-4）	在AppV的生命周期管理中，缺失的环节可能导致用户仍使用低版本或存在漏洞的应用程序，或者使用已要求删除的应用程序。	在AppV生命周期管理中，对于部署、提供给用户、更新、退役几个重要环节进行监督和管理。避免存在未更新的AppV或应删除但未删除的AppV。