Среди наших клиентов есть компании, которые используют решения Kaspersky как корпоративный стандарт и самостоятельно управляют антивирусной защитой. Казалось бы, им не очень подходит сервис виртуальных рабочих столов, в котором за антивирусом следит провайдер. Сегодня покажу, как заказчики могут сами управлять защитой без ущерба для безопасности виртуальных рабочих столов.
В
В первой части статьи покажу, как мы управляем решением в облаке, и сравню показатели «облачного» Kaspersky с традиционным Endpoint Security. Вторая часть будет про возможности самостоятельного управления.
Как мы управляем решением
Вот как выглядит архитектура решения в нашем облаке. Для антивируса мы выделяем два сетевых сегмента:
- клиентский cегмент, где находятся виртуальные рабочие места пользователей,
- менеджмент-сегмент, где находится серверная часть антивируса.
Менеджмент-сегмент остается под контролем наших инженеров, заказчик не имеет доступа к этой части. Менеджмент-сегмент включает в себя главный сервер администрирования KSC, который содержит файлы лицензий, ключи для активации клиентских рабочих мест.
Вот из чего состоит решение в терминах «Лаборатории Касперского».
- На виртуальные рабочие столы пользователей ставится легкий агент (LA). Он не занимается проверками файлов, а отправляет их на SVM и ждет «вердикта сверху». В результате ресурсы пользовательского рабочего стола не тратятся на антивирусную активность, а сотрудники не жалуются, что «VDI тормозит».
- Проверяет отдельная виртуальная машина защиты (Security virtual machine, SVM). Это выделенное устройство безопасности, на котором размещаются базы данных вредоносного ПО. Во время проверок нагрузка возлагается на SVM: через нее легкий агент общается с сервером.
- Kaspersky security center (KSC) управляет виртуальными машинами защиты. Это консоль с настройками задач и политик, которые будут применяться на конечных устройствах.
Эта схема работы обещает экономию до 30% аппаратных ресурсов пользовательской машины по сравнению с антивирусом на компьютере пользователя. Посмотрим, что на практике.
Для сравнения взял свой рабочий ноутбук с установленным Kaspersky Endpoint Security, запустил проверку и посмотрел на потребление ресурсов:
А вот та же самая ситуация на виртуальном рабочем столе со схожими характеристиками в нашей инфраструктуре. Памяти ест примерно одинаково, но загрузка ЦП ниже в два раза:
Сам KSC тоже довольно требовательный к ресурсам. Мы выделяем под него
достаточно, чтобы и администратору было комфортно работать. Смотрите сами:
Что остается под контролем заказчика
Итак, с задачами на стороне провайдера разобрались, теперь предоставим заказчику управление антивирусной защитой. Для этого мы создаем дочерний сервер KSC и выносим его в клиентский сегмент:
Зайдем в консоль на клиентском KSC и посмотрим, какие настройки будут у заказчика по дефолту.
Мониторинг. На первой вкладке видим панель мониторинга. Сразу понятно, на какие проблемные места стоит обратить внимание:
Перейдем дальше к статистике. Несколько примеров, что здесь можно посмотреть.
Здесь администратор сразу увидит, если на каких-то машинах не установилось обновление
или возникла другая проблема, связанная с ПО на виртуальных рабочих столах. Их
обновление может сказаться на безопасности всей виртуальной машины:
В этой вкладке можно проанализировать найденные угрозы до конкретной найденной угрозы на защищаемых устройствах:
В третьей вкладке есть все возможные варианты преднастроенных отчетов. Заказчики могут создать свои отчеты из шаблонов, выбрать, какая информация будет отображаться. Можно настроить отправку на почту по расписанию или просматривать отчеты локально с сервера
администрирования (KSC).
Группы администрирования. Справа видим все управляемые устройства: в нашем случае – виртуальные рабочие столы под управлением сервера KSC.
Их можно объединять в группы, чтобы создать общие задачи и групповые политики для разных подразделений или для всех пользователей одновременно.
Как только заказчик создал виртуальную машину в приватном облаке, она сразу определяется в сети, и Kaspersky отправляет ее в нераспределенные устройства:
На нераспределенные устройства не распространяются групповые политики. Чтобы не раскидывать виртуальные рабочие столы по группам вручную, можно использовать правила. Так мы автоматизируем перенос устройств в группы.
Например, виртуальные рабочие столы с Windows 10, но без установленного агента администрирования попадут в группу VDI_1, а с Windows 10 и установленным агентом, попадут в группу VDI_2. По аналогии с этим, устройства можно также автоматически распределять на основе их доменной принадлежности, по расположению в разных сетях и по определенным тегам, которые клиент может задать исходя из своих задач и потребностей самостоятельно.
Для создания правила просто запускаем мастер распределения устройств по группам:
Групповые задачи. С помощью задач KSC автоматизирует выполнение определенных правил в определенное время или с наступлением определенного момента, к примеру: выполнение проверки на вирусы выполняется в нерабочее время или при «простое» виртуальной машины, что, в свою очередь, снижает нагрузку на ВМ. В этом разделе удобно по расписанию запускать проверки на виртуальных рабочих столах внутри группы, а также обновлять вирусные базы.
Вот полный список доступных задач:
Групповые политики. С дочернего KSС заказчик может самостоятельно распространять защиту на новые виртуальные рабочие столы, обновлять сигнатуры, настраивать исключения
для файлов и сетей, строить отчеты, а также управлять всеми видами проверок своих машин. В том числе – ограничивать доступ до конкретных файлов, сайтов или хостов.
Политики и правила главного сервера можно включить обратно, если что-то пойдет не так. В самом плохом случае при неверной настройке легкие агенты потеряют связь с SVM и оставят виртуальные рабочие столы без защиты. Наши инженеры тут же получат уведомление об этом и смогут включить наследование политик с главного сервера KSC.
Это основные настройки, о которых я хотел рассказать сегодня.
Источник: habr.com