Все больше пользователей выводят в публичное облако всю свою ИТ-инфраструктуру. Однако в случае недостаточности антивирусного контроля в инфраструктуре заказчика возникают серьезные кибер-риски. Практика показывает, что до 80% существующих вирусов отлично живут в виртуальной среде. В этом посте расскажем о том, как защитить ИТ-ресурсы в публичном облаке и почему традиционные антивирусы не совсем подходят для этих целей.
Для начала расскажем, как мы подошли к мысли о том, что для публичного облака не подходят привычные инструменты антивирусной защиты и требуются иные подходы к защите ресурсов.
Во-первых, как правило, провайдеры обеспечивают необходимые меры, чтобы гарантировать защиту своих облачных платформ на высоком уровне. Например, мы в #CloudMTS анализируем весь сетевой трафик, мониторим логи систем безопасности нашего облака, регулярно выполняем пентесты. Сегменты облака, отданные отдельным клиентам, также должны быть надежно защищены.
Во-вторых, классический вариант борьбы с кибер-рисками подразумевает установку антивируса и средств управления им на каждую виртуальную машину. Однако при большом числе виртуальных машин такая практика может быть неэффективной и требовать значительных объемов вычислительных ресурсов, тем самым, дополнительно нагружая инфраструктуру заказчика и снижая общую производительность облака. Это стало ключевой предпосылкой для поиска новых подходов к построению эффективной антивирусной защиты виртуальных машин заказчиков.
Кроме того, большинство имеющихся на рынке антивирусных решений не адаптированы для решения задач защиты ИТ-ресурсов в публичной облачной среде. Как правило, они представляют собой тяжеловесные EPP-решения (Endpoint Protection Platforms), которые, к тому же, не дают возможности необходимой кастомизации на стороне клиентов облачного провайдера.
Становится очевидно, что традиционные антивирусные решения плохо подходят для работы в облаке, так как они серьезно нагружают виртуальную инфраструктуру во время обновлений и сканирования, также не имеют необходимых уровней ролевого управления и настроек. Далее подробно разберем, в силу каких причин облако нуждается в новых подходах по антивирусной защите.
Что должен уметь антивирус в публичном облаке
Итак, обратим внимание на специфику работы в виртуальной среде:
Эффективность проведения обновлений и массовые проверки по расписанию. Если значительное количество виртуальных машин, использующих традиционный антивирус, единовременно инициируют обновление, в облаке произойдет так называемый «шторм» обновлений. Мощности ESXi-хоста, на котором размещаются несколько виртуальных машин, может не хватить для обработки шквала однотипных задач, запущенных по умолчанию. С точки зрения облачного провайдера, такая проблема может привести к дополнительным нагрузкам на целый ряд ESXi-хостов, что в итоге приведет к падению производительности виртуальной инфраструктуры облака. Это может отразиться, в том числе, на производительности виртуальных машин других клиентов облака. Аналогичная ситуация может сложиться при запуске массового сканирования: одновременная обработка дисковой системой множества однотипных запросов от разных пользователей будет негативно влиять на производительность всего облака. С большой долей вероятности снижение работоспособности СХД отразится на всех клиентах. Такие скачкообразные нагрузки не радуют ни провайдера, ни его заказчиков, так как влияют на «соседей» в облаке. С этой точки зрения традиционный антивирус может представлять большую проблему.
Безопасный карантин. Если в системе обнаружен файл или документ, потенциально зараженный вирусом, он отправляется в карантин. Конечно, зараженный файл можно сразу удалить, но это часто не приемлемо для большинства компаний. Корпоративные enterprise-антивирусы, которые не адаптированы для работы в облаке провайдера, имеют, как правило, общую карантинную зону — в неё попадают все зараженные объекты. Например, обнаруженные на компьютерах пользователей компании. Клиенты же облачного провайдера «живут» в собственных сегментах (или тенантах). Эти сегменты непрозрачны и изолированы: клиенты не знают друг о друге и, конечно, не видят, что размещают в облаке другие. Очевидно, что в общий карантин, к которому будут обращаться все пользователи антивируса в облаке, потенциально может попасть документ, содержащий конфиденциальную информацию или коммерческую тайну. Это неприемлемо для провайдера и его клиентов. Поэтому решение может быть только одно – это персональный карантин у каждого клиента в его сегменте, куда нет доступа ни у провайдера, ни у других клиентов.
Индивидуальные политики безопасности. Каждый клиент в облаке — это отдельная компания, ИТ-отдел которой устанавливает свои политики безопасности. Например, администраторы определяют правила сканирования и расписание антивирусных проверок. Соответственно, каждая организация должна иметь свой центр управления для настройки политик антивируса. При этом задаваемые настройки не должны влиять на других клиентов облака, а провайдер должен иметь возможность удостовериться в том, что, например, обновления антивируса проходят в штатном режиме для всех виртуальных машин клиента.
Организация биллинга и лицензирование. Облачная модель характеризуется гибкостью и предполагает оплату только того объема ИТ-ресурсов, который был использован заказчиком. Если есть необходимость, например, в виду фактора сезонности, то объем ресурсов можно оперативно увеличивать или сокращать — все исходя из текущих потребностей в вычислительных мощностях. Традиционный антивирус не настолько гибок — как правило, клиент покупает лицензию на год на заранее определенное количество серверов или рабочих станций. Пользователи же облака регулярно отключают и подключают дополнительные виртуальные машины в зависимости от своих текущих потребностей — соответственно антивирусные лицензии должны поддерживать такую же модель.
Второй вопрос заключается в том, на что именно будет распространяться лицензия. Традиционный антивирус лицензируется по количеству серверов или рабочих станций. Лицензии по количеству защищаемых виртуальных машин не совсем подходят в рамках облачной модели. Клиент может из имеющихся ресурсов создать любое удобное ему число виртуальных машин, например, пять или десять машин. Это число у большинства клиентов не постоянно, отслеживать его изменение для нас, как провайдера, не представляется возможным. Лицензировать по CPU нет технической возможности: клиенты получают виртуальные процессоры (vCPU), по которым и должно осуществляться лицензирование. Таким образом, новая модель антивирусной защиты должна предполагать возможность определения заказчиком необходимого числа vCPU, на которые он будет получать антивирусные лицензии.
Соответствие законодательству. Важный пункт, так как применяемые решения должны обеспечивать выполнение требований регулятора. Например, часто «жители» облака работает с персональными данными. В таком случае провайдер должен располагать отдельным аттестованным сегментом облака, который полностью соответствует требованиям закона «О персональных данных». Тогда компаниям не нужно самостоятельно «строить» всю систему для работы с персональными данными: приобретать сертифицированное оборудование, подключать его и настраивать, проходить аттестацию. Для кибер-защиты ИСПДн таких клиентов антивирус также должен соответствовать требованиям российского законодательства, иметь сертификат ФСТЭК.
Мы рассмотрели те обязательные критерии, которым должна удовлетворять антивирусная защита в публичном облаке. Далее поделимся собственным опытом по адаптации антивирусного решения для работы в облаке провайдера.
Как можно подружить антивирус и облако
Как показал наш опыт, выбрать решение по описанию и документации — это одно, а реализовать на практике в уже работающей облачной среде — совсем другая задача по уровню сложности. Расскажем, что мы делали на практике и как адаптировали антивирус для работы в публичном облаке провайдера. Вендором антивирусного решения стал Kaspersky, у которого в портфеле есть решения по антивирусной защите для облачных сред. Мы остановились на «Kaspersky Security для виртуальных сред» (Легкий агент).
Оно включает в себя единую консоль Kaspersky Security Center. Легкий агент и виртуальные машины безопасности (SVM, Security Virtual Machine) и сервер интеграции KSC.
После того, как мы изучили архитектуру решения Kaspersky и провели первые тесты совместно с инженерами вендора, встал вопрос по интеграции сервиса в облако. Первое внедрение было выполнено совместными силами на московской площадке облака. И вот, что мы поняли.
Для того чтобы минимизировать сетевой трафик, было принято решение на каждом ESXi-хосте расположить SVM и «привязать» SVM к ESXi-хостам. В таком случае легкие агенты защищаемых виртуальных машин обращаются к SVM именно того ESXi-хоста, на котором они запущены. Для главного KSC был выбран отдельный административный тенант. В результате подчиненные KSC располагаются в тенантах каждого отдельного клиента и обращаются к вышестоящему KSC, расположенному в менеджмент-сегменте. Такая схема позволяет быстро решать проблемы, возникающие в тенантах клиентов.
Помимо вопросов с поднятием компонентов самого антивирусного решения перед нами встала задача по организации сетевого взаимодействия через создание дополнительных VxLAN. И хотя решение изначально было предназначено для enterprise-клиентов с частными облаками — с помощью инженерной смекалки и технологической гибкости NSX Edge нам удалось решить все задачи, связанные с разделением тенантов и лицензированием.
Мы работали в плотной связке с инженерами Kaspersky. Так, в процессе анализа архитектуры решения в части сетевого взаимодействия между компонентами системы было установлено, что, помимо доступа от легких агентов к SVM, также необходима обратная связь – от SVM к легким агентам. Данная сетевая связанность невозможна в multitenant-среде ввиду возможности существования идентичных сетевых настроек виртуальных машин в разных тенантах облака. Поэтому по нашей просьбе коллегами из вендора был переработан механизм сетевого взаимодействия между легким агентом и SVM в части исключения необходимости сетевой связанности от SVM к легким агентам.
После того, как решение было развернуто и протестировано на московской площадке облака, мы растиражировали его на остальные площадки, включая аттестованный сегмент облака. Cейчас сервис доступен во всех регионах страны.
Архитектура ИБ-решения в рамках нового подхода
Общая схема работы антивирусного решения в публичной облачной среде выглядит следующим образом:
Схема работы антивирусного решения в публичной облачной среде #CloudMTS
Опишем особенности работы отдельных элементов решения в облаке:
• Единая консоль, которая позволяет клиентам централизованно управлять системой защиты: запускать проверки, контролировать обновления и наблюдать за карантинными зонами. Есть возможность настраивать индивидуальные политики безопасности в рамках своего сегмента.
Следует отметить, что мы хотя и являемся поставщиком сервиса, но не вмешиваемся в настройки, устанавливаемые клиентами. Единственное, что мы можем сделать — это сбросить политики безопасности до стандартных в случае необходимости перенастройки. Например, это может понадобиться, если клиент случайно ужесточил их или значительно ослабил. Компания всегда может получить центр управления с дефолтными политиками, которые затем может самостоятельно настроить. Минус Kaspersky Security Center в том, что пока платформа доступна только для операционной системы Microsoft. Хотя легкие агенты могут работать как с Windows, так и с Linux-машинами. Однако в «Лаборатории Касперского» обещают, что уже в ближайшее время KSC заработает и под ОС Linux. Одна из важных функций KSC — возможность управления карантином. У каждой компании-клиента в нашем облаке он персональный. Такой подход исключает ситуации, когда зараженный вирусом документ случайно попадает на всеобщее обозрение, как это могло бы произойти в случае с классическим корпоративным антивирусом с общим карантином.
• Легкие агенты. В рамках новой модели на каждую виртуальную машину устанавливается легкий агент Kaspersky Security. Это позволяет не хранить антивирусную базу данных на каждой VM, что сокращает объем занимаемого дискового пространства. Сервис интегрирован с инфраструктурой облака и работает через SVM, что повышает плотность виртуальных машин на ESXi-хосте и производительность всей облачной системы. Легкий агент выстраивает очередь заданий для каждой виртуальной машины: проверить файловую систему, память и т.д. Но за выполнение этих операций отвечает уже SVM, о которой поговорим дальше. Также агент выполняет функции межсетевого экрана, контролирует политики безопасности, отправляет зараженные файлы в карантин и мониторит общее «здоровье» операционной системы, на которой установлен. Всем этим можно управлять с помощью уже упомянутой единой консоли.
• Security Virtual Machine. Всеми ресурсоемкими задачами (обновлениями антивирусных баз, проверками по расписанию) занимается отдельная Security Virtual Machine (SVM). Она отвечает за работу полновесного антивирусного движка и баз к нему. ИТ-инфраструктура компании может включать несколько SVM. Такой подход повышает надежность системы — если какая-то машина выходит из строя и не отвечает на протяжении тридцати секунд, агенты автоматически начинают искать другую.
• Сервер интеграции KSC. Один из компонентов главного KSC, который назначает в соответствии с заданным в его настройках алгоритмом, легким агентам свои SVM, а также контролирует доступность SVM. Таким образом данный программный модуль обеспечивает балансировку нагрузки на все SVM облачной инфраструктуры.
Алгоритм работы в облаке: снижение нагрузки на инфраструктуру
В целом алгоритм работы антивируса можно представить следующим образом. Агент обращается к файлу на виртуальной машине и проверяет его. Результат проверки сохраняется в общей централизованной базе вердиктов SVM (она называется Shared Cache), каждая запись в которой идентифицирует уникальный образец файла. Такой подход позволяет следить, чтобы один и тот же файл не проверялся несколько раз подряд (например, если его открыли на разных виртуальных машинах). Файл сканируется повторно только в том случае, если в него внесли изменения или проверка была запущена вручную.
Реализация антивирусного решения в облаке провайдера
На изображении представлена общая схема реализации решения в облаке. В управляющей зоне облака развернут главный Kaspersky Security Center, а на каждом ESXi-хосте при помощи сервера интеграции KSC развернута индивидуальная SVM (к каждому ESXi-хосту специальными настройками на VMware vCenter Server привязан свой SVM). Клиенты работают в своих сегментах облака, где размещаются виртуальные машины с агентами. Управляются они через индивидуальные KSC-серверы, подчиненные главному KSC. В случае необходимости защиты небольшого количества виртуальных машин (до 5) клиенту может предоставляться доступ к виртуальной консоли специального выделенного сервера KSC. Сетевое взаимодействие между клиентскими KSС и главным KSC, а также легкими агентами и SVM осуществляется при помощи NAT через клиентские виртуальные маршрутизаторы EdgeGW.
По нашим оценкам и результатам тестов коллег в вендоре, Легкий агент снижает нагрузку на виртуальную инфраструктуру клиентов примерно на 25% (если сравнивать с системой, использующей традиционное антивирусное ПО). В частности, стандартный антивирус Kaspersky Endpoint Security (KES) для физических сред расходует почти в два раза больше процессорного времени сервера (2,95%), чем решение для виртуализации на базе легких агентов (1,67%).
График сравнения нагрузки на процессор
Похожая ситуация наблюдается с частотой обращений к диску по записи: для классического антивируса она составляет 1011 IOPS, для облачного антивируса — 671 IOPS.
График сравнения частоты обращений к диску
Выигрыш по производительности позволяет поддерживать стабильность инфраструктуры и эффективнее использовать вычислительные мощности. За счет адаптации для работы в публичной облачной среде решение не снижает производительности облака: оно осуществляет централизованную проверку файлов и загрузку обновлений, распределяя нагрузку. Это значит, что, с одной стороны, не будут пропущены актуальные для облачной инфраструктуры угрозы, с другой — в среднем на 25% снизятся требования к ресурсам виртуальных машин по сравнению с традиционным антивирусом.
По функциональности оба решения сильно напоминают друг друга: ниже приведена сравнительная таблица. Однако в облаке, как показывают приведенные выше результаты тестирований, все же оптимальнее использовать решение для виртуальных сред.
Про тарификацию в рамках нового подхода. Мы приняли решение использовать модель, которая позволяет получать лицензии по количеству vCPU. Это значит, что число лицензий будет равно числу vCPU. Антивирус можно протестировать, оставив заявку .
В следующем материале по облачной тематике мы расскажем об эволюции облачных WAF и том, что лучше выбрать: железо, ПО или облако.
Текст подготовили сотрудники облачного провайдера #CloudMTS: Денис Мягков, ведущий архитектор и Алексей Афанасьев, менеджер по развитию продуктов ИБ.
Источник: habr.com