越来越多的用户将其整个IT基础架构部署到公共云。 但是，如果防病毒控制不足，则会在客户的基础架构中带来严重的网络风险。 实践表明，多达80％的现有病毒可以在虚拟环境中完美生活。 在这篇文章中，我们将讨论如何保护公共云中的IT资源以及为什么传统的防病毒软件不太适合这些目的。
首先，我们将告诉您如何得出这样的结论：通常的防病毒保护工具不适用于公共云，并且需要其他保护资源的方法。
首先，提供商通常会提供必要的措施，以确保在较高级别上保护其云平台。 例如，我们在#CloudMTS处分析所有网络流量，监视云的安全日志并定期执行渗透测试。 提供给各个客户的云段也必须得到可靠的保护。
其次，对抗网络风险的经典版本涉及在每个虚拟机上安装防病毒软件及其控件。 但是，在使用大量虚拟机的情况下，这种做法可能效率低下，并且需要大量的计算资源，从而额外增加了客户的基础架构负担，并降低了云的整体性能。 这已成为寻找为客户的虚拟机构建有效的防病毒保护新方法的关键前提。
另外，市场上可用的大多数防病毒解决方案都无法解决公共云环境中保护IT资源的问题。 通常，它们是重量级的EPP解决方案（端点保护平台），此外，它们没有在云提供商的客户端方面提供必要的自定义选项。
显而易见，传统的防病毒解决方案不适合在云中工作，因为它们在更新和扫描过程中会严重加载虚拟基础架构，并且没有必要的角色管理和设置级别。 接下来，我们将详细分析为什么云需要新的防病毒保护方法。
防病毒软件应该能够在公共云中做什么
因此，让我们注意在虚拟环境中工作的细节：
更新和批量计划检查的效率。 如果大量使用传统防病毒软件的虚拟机一次启动更新，则所谓的“风暴”将在云中发生。 托管多个虚拟机的ESXi主机的容量可能不足以处理默认情况下启动的一系列相同类型的任务。 从云提供商的角度来看，这样的问题可能导致许多ESXi主机上的额外负载，最终将导致云虚拟基础架构的性能下降。 除其他因素外，这可能会影响其他云客户端的虚拟机的性能。 开始大规模扫描时，可能会发生类似的情况：磁盘系统对来自不同用户的许多相同类型请求的同时处理将对整个云的性能产生不利影响。 存储系统的工作容量降低很可能会影响所有客户。 这种痉挛性负载既不影响提供商，也不令其客户满意，因为它们会影响云中的“邻居”。 从这个角度来看，传统的防病毒软件可能是个大问题。
安全隔离。 如果在系统中检测到可能感染病毒的文件或文档，则将其发送到隔离区。 当然，可以立即删除受感染的文件，但这对于大多数公司而言通常是不可接受的。 不适合在提供者的云中运行的公司企业防病毒软件通常具有一个公共隔离区-所有受感染的对象都落入其中。 例如，在公司用户的计算机上找到的。 云提供商的客户在其自己的细分市场（或租户）中“生活”。 这些细分市场是不透明且相互隔离的：客户彼此之间并不了解，当然也看不到其他人在云中放置的内容。 显然，在将由云中所有防病毒用户访问的常规隔离区中，包含潜在机密信息或商业秘密的文档可能会进入该隔离区。 这对于提供商及其客户是不可接受的。 因此，只能有一个解决方案-这是针对其网段中每个客户端的个人隔离区，提供者和其他客户端都无法访问。
个别安全策略。 云中的每个客户端都是一个单独的公司，其IT部门将设置自己的安全策略。 例如，管理员定义扫描规则和防病毒扫描计划。 因此，每个组织应拥有自己的控制中心来配置防病毒策略。 同时，设置不应影响云的其他客户端，并且提供程序应能够确保例如对所有客户端虚拟机正常执行防病毒更新。
组织计费和许可。 云模型的特点是灵活性，只涉及客户使用的IT资源量。 例如，如果考虑到季节性因素，则可以快速增加或减少资源量-全部基于当前对计算能力的需求。 传统的防病毒软件不那么灵活-通常，客户端购买许可证的时间为一年，用于预定数量的服务器或工作站。 云用户会根据其当前需求定期断开连接并连接其他虚拟机-因此，防病毒许可证必须支持相同的模型。
第二个问题是许可证将确切适用于什么。 传统防病毒软件是根据服务器或工作站的数量获得许可的。 受保护的虚拟机数量的许可证不太适合云模型。 客户端可以从可用资源中创建任意数量的虚拟机，例如五台或十台计算机。 大多数客户没有此编号；作为提供者，我们无法跟踪其更改。 从技术上讲，无法通过CPU进行许可：客户端会收到应获得许可的虚拟处理器（vCPU）。 因此，新的防病毒保护模型应包括客户确定其将收到防病毒许可证的vCPU数量的可能性。
遵守法律。 重要的一点是，由于应用的解决方案必须确保符合监管机构的要求。 例如，云的“居民”经常使用个人数据。 在这种情况下，提供商必须拥有一个单独的经过认证的云部分，该部分完全符合《个人数据法》的要求。 这样，公司就不需要“构建”整个系统来自行处理个人数据：购买经过认证的设备，进行连接和配置，以及通过认证。 为了为此类客户端提供ISPD的网络保护，防病毒软件还必须符合俄罗斯法律的要求并具有FSTEC证书。
我们检查了公共云中防病毒保护必须满足的那些强制性标准。 接下来，我们将分享自己的经验，以适应防病毒解决方案以在提供商的云中工作。
我该如何交朋友防病毒和云
正如我们的经验所表明的那样，为描述和文档选择一个是一回事，就复杂性而言，在已经运行的云环境中将其付诸实践是完全不同的任务。 我们将告诉您我们在实践中做了什么，以及如何使防病毒软件适应提供商的公共云。 防病毒解决方案供应商是卡巴斯基，其产品组合中包含针对云环境的防病毒保护解决方案。 我们选择了Kaspersky Security for Virtualization（Light Agent）。
它包括用于卡巴斯基安全中心的单个控制台。 轻代理和安全虚拟机（SVM）和KSC集成服务器。
在我们研究了卡巴斯基解决方案的体系结构并与供应商的工程师一起进行了首次测试之后，出现了将服务集成到云中的问题。 第一次实施是在莫斯科云站点上联合进行的。 这就是我们所了解的。
为了最大程度地减少网络流量，决定将SVM放置在每个ESXi主机上，并将SVM“绑定”到ESXi主机。 在这种情况下，受保护的虚拟机的轻型代理访问它们正在其上运行的特定ESXi主机的SVM。 主KSC选择了一个单独的行政租户。 结果，KSC的下属位于每个客户的租户中，并转向位于管理部门的上级KSC。 这样的方案可以使您快速解决客户租户中出现的问题。
除了增加防病毒解决方案本身组件的问题外，我们还面临着通过创建其他VxLAN来组织网络交互的任务。 尽管该解决方案最初是针对具有私有云的企业客户而设计的-借助NSX Edge的工程学独创性和技术灵活性，我们还是能够解决与租户和许可分离相关的所有问题。
我们与卡巴斯基工程师紧密合作。 因此，在根据系统组件之间的网络交互来分析解决方案体系结构的过程中，发现除了从轻型代理访问SVM之外，还需要反馈-从SVM到轻型代理。 由于在云的不同租户中存在虚拟机的相同网络设置，因此在多租户环境中无法实现这种网络连接。 因此，应我们的要求，供应商的同事重新设计了轻型代理与SVM之间的网络交互机制，从而消除了从SVM到轻型代理的网络连接需求。
在莫斯科云站点上部署和测试该解决方案之后，我们将其复制到其他站点，包括经过认证的云部门。 现在，该服务可在全国所有地区使用。
IB解决方案的体系结构是新方法的一部分
公共云环境中防病毒解决方案的一般方案如下：
公共云环境中的防病毒解决方案工作方案#CloudMTS我们描述了云中解决方案各个元素的工作特点：
•一个单一的控制台，允许客户集中管理保护系统：运行检查，监视更新和监视隔离区。 您可以在网段中配置各个安全策略。
应该注意的是，尽管我们是服务提供商，但我们不会干扰客户设置的设置。 我们唯一能做的就是在需要迁移的情况下将安全策略重置为标准。 例如，如果客户不小心将其拧紧或大大削弱了它们，则可能有必要。 公司始终可以获得带有默认策略的控制中心，然后可以自行配置。 卡巴斯基安全中心的缺点是该平台仅适用于Microsoft操作系统。 尽管轻量级代理可以与基于Windows和Linux的计算机一起使用。 但是，卡巴斯基实验室承诺，在不久的将来KSC也将在Linux下运行。 KSC的重要功能之一是管理隔离的能力。 我们云中的每个客户公司都是个人的。 这种方法消除了被病毒感染的文档意外落入公共领域的情况，就像具有常规隔离区的经典公司防病毒软件一样。
•轻质剂。 作为新模型的一部分，每台虚拟机上都安装了轻型代理Kaspersky Security。 这样就无需在每个VM上存储防病毒数据库，从而减少了使用的磁盘空间量。 该服务与云基础架构集成在一起，并通过SVM运行，从而提高了ESXi主机上虚拟机的密度以及整个云系统的性能。 轻代理为每个虚拟机建立一个作业队列：检查文件系统，内存等。 但是SVM负责执行这些操作，我们将在后面讨论。 该代理还充当防火墙，监视安全策略，将受感染的文件发送到隔离区，并监视安装该代理的操作系统的整体“运行状况”。 所有这些都可以使用已经提到的单个控制台进行控制。
•安全虚拟机。 所有资源密集型任务（防病毒数据库更新，计划的扫描）均由单独的安全虚拟机（SVM）处理。 她负责成熟的反病毒引擎及其数据库的操作。 公司的IT基础架构可能包含多个SVM。 这种方法提高了系统的可靠性-如果一台机器出现故障并且在三十秒内没有响应，则代理会自动开始寻找其他机器。
•KSC集成服务器。 主KSC的组件之一，它根据其设置中指定的算法将其SVM分配给灯光代理，还控制SVM的可用性。 因此，该软件模块可在所有SVM云基础架构上提供负载平衡。
云算法：减少基础架构负担
通常，防病毒算法可以表示如下。 代理访问虚拟机中的文件并进行检查。 验证结果存储在SVM判决的公共集中式数据库中（称为“共享缓存”），每个条目中标识一个唯一的样本文件。 使用此方法，可以确保同一文件没有连续扫描多次（例如，如果在不同的虚拟机上打开了该文件）。 仅当文件已被修改或手动开始扫描后，才会再次扫描文件。
在提供商的云中实施防病毒解决方案该图显示了在云中实施解决方案的一般方案。 卡巴斯基安全管理中心主要部署在云的控制区域中，并且使用KSC集成服务器在每个ESXi主机上部署了一个单独的SVM（每个ESXi主机都有自己的SVM，与VMware vCenter Server上的特殊设置相关联）。 客户端在其云段中工作，这些云段托管具有代理的虚拟机。 它们通过从属于主KSC的各个KSC服务器进行管理。 如果需要保护少量虚拟机（最多5个），则可以授予客户端访问专用KSC专用服务器的虚拟控制台的权限。 客户端KSC与主KSC以及轻型代理和SVM之间的联网是通过EdgeGW客户端虚拟路由器使用NAT完成的。
根据我们的估计以及供应商同事的测试结果，与使用传统防病毒软件的系统相比，Light Agent可将客户端虚拟基础架构上的负载减少约25％。 特别是，用于物理环境的标准防病毒卡巴斯基端点安全（KES）消耗的服务器处理器时间（2.95％）几乎是基于轻量级基于代理的虚拟化解决方案（1.67％）的两倍。
CPU负载比较图
对磁盘的写访问会观察到类似的情况：对于经典防病毒软件，它是1011 IOPS，对于云防病毒软件是671 IOPS。
该图比较磁盘访问率
性能提升有助于维持基础架构的稳定性并利用计算能力。 通过适应公共云环境中的工作，该解决方案不会降低云性能：它执行集中的文件检查并更新下载，从而分配负载。 这意味着，一方面，不会遗漏与云基础架构相关的威胁；另一方面，与传统的防病毒软件相比，虚拟机的平均资源需求将减少25％。
在功能方面，两个解决方案彼此非常相似：下表提供了比较表。 但是，如上面的测试结果所示，在云中，将解决方案用于虚拟环境仍然是最佳选择。
关于资费作为新方法的一部分。 我们决定使用一种模型，该模型允许您通过vCPU数量获得许可证。 这意味着许可证的数量将等于vCPU的数量。 可以通过
在站点上保留请求来测试防病毒。
在关于云相关主题的下一篇文章中，我们将讨论基于云的WAF的发展以及最佳选择：硬件，软件还是云。
该文本由#CloudMTS云提供商的员工编写：首席架构师Denis Myagkov和IB产品开发经理Alexey Afanasyev。