虚拟化环境中的安全

在2008年拉斯维加斯的黑帽安全会议上，笔者展示了历时两年的安全研究结果，其《虚拟化（安全）启示录四骑士》试图让观众了解虚拟化和安全相交融的过去、现在和未来。
这个报告侧重于展示虚拟化计算、存储和网络的实际运作是如何从根本上破坏安全性的；其“四骑士”可以归结为：
1. 整合物理设备功能，将它们重组作为一个整体的虚拟设备，这将会产生低性能的解决方案，无法扩展，且难以管理。
2. 如果虚拟安全解决方案没有正确地整合虚拟平台的安全功能及其编排系统，那么，性能、灵活性和可扩展性都将受到影响。
3. 复杂的、高度可用的虚拟安全应用和网络拓扑将需要完全不同的架构、技术和运营模式。
4. 虚拟化安全可能会引导企业从采购以硬件为中心的产品转移到更受软件驱动的产品，同时，运营变化将需要彻底改革，但企业往往不太管理这些软成本。
尽管虚拟化是为了提供更好的安全性，但虚拟化平台供应商普遍缺乏IT安全知识，这可能会打击早期的部署热情。这些供应商没有完全掌握运营模式，也无法解决网络专家、安全从业人员和供应商30多年的部署所构建的孤岛运作障碍。同时，安全从业人员几乎没有虚拟化的经验。
为什么早期努力不够
在笔者进行研究时，只有极少数传统安全厂商已经开始生产其物理设备的虚拟版本。这些早期解决方案并没有被很好地融入到虚拟化平台的“编排”工作流程或者网络数据路径，它们也不是“虚拟化感知的”。大多数解决方案几乎不了解环境或者工作负载，它们只是被部署来提供保护。
同样的问题也困扰着围绕这些虚拟化部署的传统物理安全，不过我们可以人为地通过外围“咽喉要道”和架构传输流量来解决这个问题，通常将虚拟化环境的流量转向到物理设备，然后传回来。虽然这种方法属于“集装箱式”且是隔离的，但这种方法使得部署和保护应用编程低效甚至无效。
大部分新奇的虚拟安全解决方案都试图复制非虚拟化环境的部署和运作架构，而缺少创造、部署或破坏虚拟网络和工作负载的灵活性和速度。这些解决方案还缺乏可视性，并且没有考虑这些虚拟网络的不成熟性，这可能导致安全控制很盲目。
让这个问题进一步复杂化的是，供应商没能认识到安全和合规团队曾经用来监控、测试和缓解威胁的设备和程序。安全供应商的假设是，安全团队能够理解这些解决方案，并将它们整合到流程。然而，操作孤岛和缺乏虚拟化技巧让这不太可能实现，但也不是完全不可能。工作负载的短暂性和完全移动性，再加上构成安全和信任的外围模型的熟悉的物理架构开始扩展，这意味着需要新模型的出现。
很多初创公司开始推出专用的虚拟化感知解决方案，并在虚拟结构中，重新构建安全讨论和围绕安全的运营模式。但是，很多这种努力很快“搁浅”，主要是由于平台供应商试图在本地提供安全功能，但是集成接触点很糟糕。在虚拟环境中，以前负责安全的人不再控制安全政策的制定、部署和执行。
越来越多的事情在改变……
五年后，在利用虚拟化来提供整体安全态势方面几乎没什么进展。在大多数情况下，这仍然是一个连接问题，而不是服务层问题，服务层被整合到基础设施或者直接绑定到工作负载。
供应商来来去去，很多现在的供应商从根本上被虚拟化运营模式打乱了。这些虚拟化/管理程序平台供应商仍然是实现有效安全性的关键所在。（笔者认为这将会成为主流虚拟化平台供应商首席技术官的博客战争的关键所在，我们可能会看到安全进入虚拟环境的最糟糕用例变成现实）。
我们已经花了五年时间挣扎于复杂的部署情况，其中“不适当地”整合了传统的安全设备。再加上到混合模式的缓慢迁移—其中的虚拟设备遭受着“四骑士”的弊病，以及基于平台的安全功能来实现无缝集成的缓慢进展和可用性，我们不难看出为什么我们还没有看到安全生态系统的振兴。
需要注意的是，大多数虚拟化安全解决方案（基础设施为中心的世界观）仍然专注于这样的复制物理部署和设计模式：利用基于（虚拟）网络的设备形成因素以及试图集成管理程序来实现“虚拟化感知”。最近，云计算和“软件定义一切”的影响正在阻止新安全模型的部署让位给更灵活、自动化和集成的安全产品。
这在很大程度上是因为虚拟化平台被打乱了，从基本的计算、网络和服务器资源虚拟化（主要专注于管理程序作为附加价值）演变为自动化的、动态的、服务为中心的云计算。这进一步转移了重点、功能和使用这些解决方案的用户。
在企业中，开源虚拟化和编排平台（例如OpenStack和Apache CloudStack）的出现正在推动跨管理程序（超越领导供应商VMWare）提供安全的需要。
云计算将会演变为一种混合模型，这种模型互连着内部部署虚拟化基础设施和类似云计算的可编程应用及服务交付平台，以及公共云平台中的资源，这加剧了提升和加快我们安全架构和运营做法的需要。
虽然基础设施的安全性仍然非常重要，但这种转变让我们意识到，我们也需要保护应用工作负载以及它们带来的信息。这意味着我们应较少注重传统的政策执行标准，例如IP地址和VLAN，更注重附加政策到（完全集成到这些平台的编排系统的）工作负载。

这需要共同努力
老实说，如果要在虚拟环境提供受风险驱动的良好的安全和合规功能，这在很大程度上取决于对需要保护的应用和信息的了解。这包括适当地考虑威胁模式和业务影响；调整架构和方法；平衡运营和技术的影响。虚拟化和云计算都是这些方程式中简单的运作和部署变量。
在这里并没有什么神奇的方法，只有一些务实的做法。
当笔者询问IT安全经理对于虚拟化环境中“最佳做法”的考虑因素时，笔者强调了提供各种解决方案的不同类型的供应商之间的复杂的相互作用：
1.虚拟化平台供应商
2. 云平台供应商
3. 编排平台供应商
4. 网络平台供应商（包括软件定义网络）
5. 安全行业生态系统供应商
6. 管理、风险和合规供应商
很多人敏锐地指出，在很多情况下，第1到第4项是由一些平台供应商作为整合功能集在本地提供。并且，与IT中的很多事情一样，虚拟领域的安全性需要权衡这些捆绑服务。
多种选择和供应商战略往往意味着复杂性，而单一选择和缺乏多样性则提供更紧密的集成和更少的移动部件。根据安全和合规企业的成熟度（以及它们与其余IT部门的集成度），这些元素之间的紧张关系可能将控制局面或者最终带来相当的破坏性和无效性。
简短的回答是，你需要安全作为一个普遍功能（服务），遍布在这些组件中，并将其在良好定义的抽象的消费模式中连接在一起。
唯一不变的就是变化
安全运营团队和审计师在选择自己的解决方案时，他们必须应对方法、模型、语言、功能和政策的差异性。在现在这个日新月异的世界，面对新类型的威胁元素的出现；新计算模式、平台、语言和应用架构的快速部署；选择要走的路往往不是容易的事情。
现有环境必须平衡现在的技术和运营模式，确保不会出现问题。这意味着在一段时间内，以及面对多个更新，混合安全模式将会发展下去，还可能会遭遇我们现在所知道的效率低下以及一些相同的并发症。
计算虚拟化把我们带到了这样一个位置，即开发人员、系统管理员、安全和合规团队将企业虚拟化数据中心的原子单元定义为虚拟机（VM），这已经成为我们新的外围。
我们最终将需要拥抱这个新的外围，而现在我们被自动化和自助服务云计算打乱了阵脚。这些功能将抽象化移动到VM之上，并将侧重于可编程平台以及接口，这将迫使我们调和应用为中心或工作负载为中心的安全观。
随着聪明的IT企业开始采取行动，拥抱平台为中心和可编程的企业观，利用持续的应用交付和部署的灵活性，而不是纯基础设施，DevOps的文化和运营概念将让我们更深入和重新审视我们的安全做法。
安全和合规团队需要培训和投资于与虚拟化、云计算、平台即服务和应用为中心安全相关的技能集。作为安全领导，如果你还不采取行动，并努力进入“软件定义一切”的世界，你和你的团队将处于危险之中。
要了解如何解决虚拟化和安全战略，重要的是学习虚拟化平台供应商可以为你提供什么，并基于这个评估，安全生态系统必须如何填补空白和保持兼容性。
从来没有人说这是一件容易的事……