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