Среди наших клиентов есть компании, которые используют решения Kaspersky как корпоративный стандарт и самостоятельно управляют антивирусной защитой. Казалось бы, им не очень подходит сервис виртуальных рабочих столов, в котором за антивирусом следит провайдер. Сегодня покажу, как заказчики могут сами управлять защитой без ущерба для безопасности виртуальных рабочих столов.
В прошлом посте мы уже рассказали в целом, как защищаем виртуальные рабочие столы заказчиков. Антивирус в рамках сервиса VDI помогает усилить защиту машин в облаке и самостоятельно ее контролировать.
В первой части статьи покажу, как мы управляем решением в облаке, и сравню показатели «облачного» Kaspersky с традиционным Endpoint Security. Вторая часть будет про возможности самостоятельного управления.
Вот как выглядит архитектура решения в нашем облаке. Для антивируса мы выделяем два сетевых сегмента:
Менеджмент-сегмент остается под контролем наших инженеров, заказчик не имеет доступа к этой части. Менеджмент-сегмент включает в себя главный сервер администрирования KSC, который содержит файлы лицензий, ключи для активации клиентских рабочих мест.
Вот из чего состоит решение в терминах «Лаборатории Касперского».
Эта схема работы обещает экономию до 30% аппаратных ресурсов пользовательской машины по сравнению с антивирусом на компьютере пользователя. Посмотрим, что на практике.
Для сравнения взял свой рабочий ноутбук с установленным Kaspersky Endpoint Security, запустил проверку и посмотрел на потребление ресурсов:
А вот та же самая ситуация на виртуальном рабочем столе со схожими характеристиками в нашей инфраструктуре. Памяти ест примерно одинаково, но загрузка ЦП ниже в два раза:
Сам KSC тоже довольно требовательный к ресурсам. Мы выделяем под него
достаточно, чтобы и администратору было комфортно работать. Смотрите сами:
Зайдем в консоль на клиентском KSC и посмотрим, какие настройки будут у заказчика по дефолту.
Мониторинг. На первой вкладке видим панель мониторинга. Сразу понятно, на какие проблемные места стоит обратить внимание:
Перейдем дальше к статистике. Несколько примеров, что здесь можно посмотреть.
Здесь администратор сразу увидит, если на каких-то машинах не установилось обновление
или возникла другая проблема, связанная с ПО на виртуальных рабочих столах. Их
обновление может сказаться на безопасности всей виртуальной машины:
В этой вкладке можно проанализировать найденные угрозы до конкретной найденной угрозы на защищаемых устройствах:
В третьей вкладке есть все возможные варианты преднастроенных отчетов. Заказчики могут создать свои отчеты из шаблонов, выбрать, какая информация будет отображаться. Можно настроить отправку на почту по расписанию или просматривать отчеты локально с сервера
администрирования (KSC).
Группы администрирования. Справа видим все управляемые устройства: в нашем случае – виртуальные рабочие столы под управлением сервера KSC.
Их можно объединять в группы, чтобы создать общие задачи и групповые политики для разных подразделений или для всех пользователей одновременно.
Как только заказчик создал виртуальную машину в приватном облаке, она сразу определяется в сети, и Kaspersky отправляет ее в нераспределенные устройства:
На нераспределенные устройства не распространяются групповые политики. Чтобы не раскидывать виртуальные рабочие столы по группам вручную, можно использовать правила. Так мы автоматизируем перенос устройств в группы.
Например, виртуальные рабочие столы с Windows 10, но без установленного агента администрирования попадут в группу VDI_1, а с Windows 10 и установленным агентом, попадут в группу VDI_2. По аналогии с этим, устройства можно также автоматически распределять на основе их доменной принадлежности, по расположению в разных сетях и по определенным тегам, которые клиент может задать исходя из своих задач и потребностей самостоятельно.
Для создания правила просто запускаем мастер распределения устройств по группам:
Групповые задачи. С помощью задач KSC автоматизирует выполнение определенных правил в определенное время или с наступлением определенного момента, к примеру: выполнение проверки на вирусы выполняется в нерабочее время или при «простое» виртуальной машины, что, в свою очередь, снижает нагрузку на ВМ. В этом разделе удобно по расписанию запускать проверки на виртуальных рабочих столах внутри группы, а также обновлять вирусные базы.
Вот полный список доступных задач:
Групповые политики. С дочернего KSС заказчик может самостоятельно распространять защиту на новые виртуальные рабочие столы, обновлять сигнатуры, настраивать исключения
для файлов и сетей, строить отчеты, а также управлять всеми видами проверок своих машин. В том числе – ограничивать доступ до конкретных файлов, сайтов или хостов.
Политики и правила главного сервера можно включить обратно, если что-то пойдет не так. В самом плохом случае при неверной настройке легкие агенты потеряют связь с SVM и оставят виртуальные рабочие столы без защиты. Наши инженеры тут же получат уведомление об этом и смогут включить наследование политик с главного сервера KSC.
Это основные настройки, о которых я хотел рассказать сегодня.
В прошлом посте мы уже рассказали в целом, как защищаем виртуальные рабочие столы заказчиков. Антивирус в рамках сервиса VDI помогает усилить защиту машин в облаке и самостоятельно ее контролировать.
В первой части статьи покажу, как мы управляем решением в облаке, и сравню показатели «облачного» 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.
Это основные настройки, о которых я хотел рассказать сегодня.
teecat
Только файлы? А если троян уже в памяти (ранее был неизвестен защите)? И прочие места, где водится бесфайловая нечисть
ManiFEs Автор
В контексте статьи я имел в виду запущенную задачу сканирования системы. Чтобы ее не нагружать, подозрительные файлы проверяются на стороне SVM. Легкий агент самодостаточный и может на лету определить вирус при попадании в систему – по имеющейся базе, которую он получает от SVM.
teecat
Это понятно, но опять речь о файлах. Вредоносная программа на момент проникновения может быть не известна базам антивируса и запущена (на момент проникновения по статистике антивирусу известно хорошо если процентов 50 вредоносных программ (с учетом эвристики)). Соответственно нужно проверять не только файлы. память, процессы и тд и и тп. Как обстоит дело с этим?
ManiFEs Автор
Вы верно подметили, для подобных проблем в касперском предусмотрен эвристический метод проверки поведения той или иной сущности. Также есть возможность проверки файлов с использованием облачной среды обмена KSN, в том числе, неизвестными угрозами и их сигнатурами.
На данный момент проблем с актуальностью баз со стороны касперского не наблюдалась и ранее неизвестные угрозы касперский отрабатывал на ура.
teecat
Нет. Эвристики проверяют файл до старта. И я написал, что эвристики не помогают. Это миф. Давайте не будем заниматься пропагандой. На необнаружение вредоносный файл проверяется на сервисах типа вирустотал. И атакуют тем, что там не обнаруживается. И такого не менее 30-40 процентов от созданного в день злоумышленниками. Предотвращается их запуск превентивной (поведенческой) защитой.
Ни одна антивирусная программа в мире не может знать все до одной вредоносные программы в момент проникновения
Соответственно вопрос остается. Каким образом выявить вредоносную программу, пропущенную при запуске проверкой базами и не обнаруженную по поведению? В обычном антивирусе это выявляет тот же антируткит проверкой процессов после очередного обновления. А в легком агента?
ManiFEs Автор
Легкий агент по компонентам защиты ничем не отличается от «полноразмерного» решения для настольных ПК, ноутбуков и т.д. Исходя из этого, действовать он будет в точности как и kaspersky endpoint security, поскольку в проверке по умолчанию включен пункт «выполнять поиск программ, предназначенных для скрытия следов вредоносной программы в системе (руткитов)». Соответственно, Легкий агент так же следит за запущенными в системе процессами, как и его старший собрат.
teecat
Во избежание хочу сказать, что ни в коем случае не хочу сказать, что продукт Касперского плохой. По сути мы обсуждаем преимущества и недостатки архитектуры легкого агента.
А теперь к вопросу. Итого у нас получается, что легкий агент имеет возможность проверять как файлы, так и процессы со всякими секторами. Поскольку априори существуют неизвестные на момент запуска/проникновения вредоносные программы, то как минимум раз в полчаса/час — после прихода обновления все виртуальные машины должны проверить все запущенные процессы, а также по хорошему все файлы, которые нужны для работы процесса. Тоесть передать память на проверку во внешнюю виртуальную машину. И если в случае файлов можно проверить файл, одинаковый для всех виртуальных машин один раз на все машины, то процессы скорее всего так не проверишь. И тут возникает вопрос. Проверка локальным антивирусом процессов скорее всего быстрее, чем облачным, так как в случае облачного раз в час (примем так, хотя процесс может быть заражен в любой момент каким бесфайловым троем) нужно передать объекты на проверку в центральную машину. Соответственно центральная машина должна быть нехилой мощности, прямо пропорциональной количеству обслуживаемых виртуальных машин — ибо вставать им в очередь на проверку не очень хорошая идея
Прав я или нет?
ManiFEs Автор
Не совсем так. Дело в том, что виртуальная машина защиты (SVM) — это что-то в роде Appliance. Развертывание происходит на саму виртуализацию, используемую для создания VDI. Конечная нагрузка на эту систему будет зависеть от количества подключаемых Легких агентов.
Но даже вариант с перегрузом по количеству Легких агентов предусмотрен. Нагрузка автоматически распределяется между множеством SVM по алгоритмам балансировки в KSC. Можно управлять балансировкой вручную, например, ограничивать определенные SVM и указывать жесткую привязку Легкого агента к одной или нескольким выделенным машинам защиты.
Замечаний по работе такой системы у нас не возникло, в большинстве случаев используем автоматическую балансировку нагрузки на SVM. В дальнейшем планируем еще одну статью по сравнению Легкого агента с Endpoint, которая расставит все точки над Й!)