Рано или поздно каждому администратору безопасности Kaspersky Security Center придётся столкнуться с радостями и трудностями переезда сервера администрирования, в связи с абсолютно различными причинами, начиная от миграции локальных мощностей в ЦОД, и заканчивая невозможностью обновления старого ПО.
И многие, подозреваю, хотели бы знать различные подводные камни, возникавшие в аналогичных ситуациях, детали о тонкостях планирования инфраструктуры серверов администрирования и узнать каким бэйзлайнам (стандартам) развёртывания следовать.
Немного о себе - меня зовут Григорий, являюсь сертифицированным специалистом Kaspersky по направлению Kaspersky Endpoint Security and Management (Медленно но верно двигаюсь к статусу Kaspersky Certified Systems Engineer), имею опыт работы с различными продуктами Kaspersky (и не только) около трёх лет.
Подготовка
Анализ текущей инфраструктуры
Для грамотного построения новой инфраструктуры антивирусной защиты организации требуется с умом подойти к анализу уже построенной.
Вопросы которые следует изучить в первую очередь:
-
Тип развёртывания. Kaspersky Labs сформировало типовые конфигурации, которые следует использовать в сети организации (Которые в целом встречаются на практике чаще всего): Один офис (Подробнее в справке Kaspersky Security Center); Несколько крупных географически распределенных офисов (Подробнее в справке Kaspersky Security Center); Множество небольших географически распределенных офисов (Подробнее в справке Kaspersky Security Center); Если ваша конфигурация развёртывания отличается от всех вышеописанных (исключая случаи гибридного развёртывания, при наличии одновременно и крупных и малых филиалов в Организации) - настоятельно рекомендую в новом развёртывании присмотреться к вышеописанным схемам, или их аналогам в зависимости от типа IT-инфраструктуры (Например, если сотрудники работают удалённо в приватном облаке Организации, и только через VDI - имеет смысл организовать в нём единый сервер администрирования, т.к. защищаемые сервисы и рабочие станции будут находится в единой сетевой среде; Это в свою очередь будет аналогом типа развёртывания Один офис в облачном исполнении).
-
Производительность. По моему опыту - все вопросы связанные с мониторингом производительности серверов замечательно перекрываются с использованием интеграции между собой Zabbix и Grafana, например при помощи плагина. Item'ы Zabbix, которые лично я использую для мониторинга производительности сервера администрирования это:
-
CPU utilization (Утилизация CPU);
-
Memory utilization (Утилизация RAM);
-
FS [(<Буква диска>)]: Space: Available (Динамика свободного места на диске);
-
FS [(<Буква диска>)]: Space: Used (Динамика использованного места на диске);
-
0 [(<Буква диска>)]: Disk utilization by idle time (Время простоя диска); Уверен что многие Хабрчане, более погруженные в дебри сбора и анализа различных метрик производительности серверов смогут подсказать и более изощрённые или простые решения в комментариях :^) Если после проведения анализа производительности, по каким-либо критериям её не хватает текущему развёртыванию - в первую очередь обратите внимание на соответствие типа развёртывание текущей структуре сети организации (Не следует развёртывать один-единственный сервер администрирования на БД SQL-express на 30 крупных филиалов Организации, в которой находится более 15000 устройств); На более поздних этапах, после оптимизации типа развёртывания - следует чуть более щепетильно подойти к вопросу конфигурации как самого сервера администрирования и его БД, так и к конфигурации конечных политик/задач и параметрам хранения событий;
-
Определение требований к новой инфраструктуре
Насчёт определения самой структуры защиты Организации существует весьма прозрачная статья в справке Kaspersky Security Center, но помимо этого следует обратить внимание на:
-
Имеющийся ИТ-ландшафт предприятия Поскольку при новом развёртывании Kaspersky Security Center его необходимо изолировать от основной доменной сети предприятия, для предотвращения его компрометации в случае захвата контроля над доменом. Это является прямой рекомендацией вендора (см. пункт "Исключение Сервера администрирования из домена") Обращу внимание так же на две вещи: - При изоляции необходимо не забыть про порты, используемые Kaspersky Security Center в ходе работы. - А так же вспомнить про наличие удалённых сотрудников Организации, которых тоже нужно защищать. Организовать их подключение в контур предприятия можно через шлюз соединений
-
Аппаратные и программные требования Настоятельно рекомендую обратить пристальное внимание на корректный выбор базы данных (причём обязательно с запасом на будущее; подробнее про ограничения БД тут; подробнее про требования к "железу" для сервера администрирования и СУБД здесь) а так же, по возможности, разнести компоненты Kaspersky Security Center (СУБД, Сервер администрирования, Веб-консоль, Файловое хранилище) на разные сервера (Для совокупного повышения производительности каждого из компонентов по отдельности)
Резервное копирование
Настоятельно рекомендую, если вы желаете сохранить текущие настройки и конфигурацию сервера администрирования - при воссоздании сервера администрирования использовать утилиту klbackup и резервную копию сервера администрирования.
По умолчанию задача резервного копирования сервера администрирования сохраняет их в следующих директориях:
C:ProgramDataKasperskyLabadminkit1093Backup - для версий 13.2 и младше
C:ProgramDataKasperskySCSC_Backup (или же %ALLUSERSPROFILE%Application DataKasperskySCSC_Backup) - для версий 14 и старше
Так же важная деталь - если вы хотите восстановить сервер администрирования из резервной копии, то в обязательном порядке:
-
Если будете менять базу данных с SQL Server на MySQL или MariaDB - запускайте утилиту klbackup в интерактивном режиме и включите "Перенос данных в формате MySQL/MariaDB". Аналогично применимо и к переносу SQL Server на Azure SQL - выбирайте "Перенести в формат Azure";
-
Если в качестве СУБД будет так же использоваться SQL Server - её версия на новом сервере должна быть такой же, или выше, чем та, которая установлена на старом.
Настройка нового сервера администрирования
После установки СУБД и сервера администрирования (в выбранной вами конфигурации) - можете приступать к его восстановлению, если не хотите настраивать всё с нуля:
-
Запустите утилиту klbackup, находящуюся в папке установки сервера администрирования, в интерактивном режиме;
-
В открывшемся окне выберите пункт "Выполнить восстановление данных Сервера администрирования";
-
В параметрах восстановления укажите папку, содержащую резервную копию сервера администрирования, и пароль от архива с резервной копией;
-
После указания параметров - нажимайте Далее и ждите окончание работы мастера восстановления.
О том, как восстановить сервер администрирования в тихом режиме, при помощи командной строки - читайте в справке KSC.
Если вы решили, что восстановление сервера администрирования по какой либо причине вам не подходит, то после установки СУБД и сервера администрирования и прохождения мастера первоначальной настройки можно приступать к конфигурированию необходимых для работы параметров.
Иерархия групп администрирования
Честно скажу по своему опыту, что неавтоматизированное создание групп администрирования - вещь достаточно нудная и абсолютно не оптимизированная по временным затратам, особенно если вам необходимо создание достаточно большого количества групп.
Для создания большого количества групп администрирования - рекомендую использовать встроенный функционал создания структуры групп.
Её можно воссоздать из иерархии групп Active Directory, структуры сетевых доменов или из текстового файла (в моей практике, в большинстве случаев, использовался последний вариант).
Например для того, чтобы создать в группе Управляемые устройства подгруппы филиала А и филиала Б необходимо использовать текстовый файл со следующим содержанием:
Управляемые устройства
-Филиал А
-Филиал Б
Политики и профили политик
В зависимости от используемых средств защиты конечных точек необходимо настроить для необходимых вам групп администрирования соответствующие политики (Kaspesky Endpoint Security для Windows, для Linux, Лёгкий агент и т.д.)
В случае KES для Windows - рекомендую обращать особое внимание на:
-
Конфигурацию событий В большом масштабе это влияет на производительность БД (отключением отправки некритических событий на сервер администрирования), а так же на возможность мониторинга настоящих критических событий для администраторов безопасности (обнаружено много вирусов, программа безопасности не запущена, и т.д.); Во многих случаях наиболее удобно осуществлять мониторинг и обработку таких событий через email-нотификации, так как многие ServiceDesk-системы достаточно просто интегрируются именно с почтой. Конфигурация находится в разделе Event Configuration во вкладках, соответствующих типу события.
-
Конфигурация модулей Анализ поведения и Защита от сетевых угроз Поскольку, в некоторых случаях, данные модули могут привести в том числе к блокировке самого хоста, где работает средство защиты информации (От себя упомяну такой случай при генерации отчётов в Microsoft PowerBI в связке с Microsoft SQL); Настоятельно рекомендую сначала тестировать их в режиме информирования перед тем, как начинать блокировать соединения на "боевых" сервисах (Разделы Advanced Threat Protection -> Behavior Detection и Essential Threat Protection -> Network Threat Protection).
-
Конфигурацию модулей DR (Detection and Response) Если в вашей Организации используется MDR или KATA в составе KEDR Expert (В ином случае DR работать не будет). Конфигурация находится в разделе Detection and Response -> Managed Detection and Response/Endpoint Detection and Response (KATA)
-
Конфигурацию модуля Анализ журналов Может быть достаточно полезной, поскольку можно создать собственные правила обнаружений нетипичной активности в системных журналах, а так же дополнительно сохранять такие действия в журнал событий антивируса (Security Control -> Log Inspection).
-
Конфигурацию Адаптивного контроля аномалий Поскольку иногда может воспринять легитимные утилиты или скрипты IT-администраторов как угрозу и заблокировать их выполнение (Security Control -> Adaptive Anomaly Control).
-
Конфигурацию Локальных задач В своих инсталляциях всегда оставляю возможность запускать локальные задачи непосредственно из локального интерфейса пользователей (Поскольку это удобно, и в экстренных ситуациях требуется быстрее чем за 15 минут произвести антивирусную проверку устройства "на месте") Так же для задачи сканирования из контекстного меню выставляю параметр "Максимальной защиты", поскольку данный тип проверки используется, в моей практике крайне редко, и не для плановых проверок. Сканирование съёмных накопителей произвожу в режиме "Детальное сканирование" поскольку достаточно часто встречал ситуации, когда некоторые "продвинутые" сотрудники пытались самолично произвести оценку защищённости активов компании при помощи redteam-инструментария. Режим фонового сканирования оставляю включённым, поскольку она не является настолько же ресурсоёмкой, как задача полного сканирования, но при этом проверяет достаточно чувствительные места в ОС (автозапуск, загрузочный сектор, системная память, системный раздел) Конфигурации находятся в разделах Local Tasks -> Task management/Scan from Context Menu/ Removable Drives Scan/Background Scan
-
Конфигурацию Исключений и доверенных приложений Если вы используете различные продукты Microsoft (SCCM, Exchange Server и т.д.) - рекомендую проверить наличие всех исключений для данных продуктов. Так же если вы используете сторонние приложения, которые конфликтуют со средствами антивирусной защиты - лучше не забывать добавлять их в исключения перед началом эксплуатации САВЗ. Конфигурация находится в разделах General settings -> Exclusions and object types -> Scan exclusions/Trusted applications
-
Конфигурацию Парольной защиты Настоятельно рекомендую включать парольную защиту во всех политиках KES для Windows (думаю, что объяснять причины этому не стоит) не забыв ввести пару логин-пароль для администратора антивирусной защиты (на практике ставлю разные, случайно-сгенерированные логины и пароли на каждую политику в разделе General settings -> Interface -> Password protection), а так же не забыть во всех параметрах политики "закрыть замки", чтобы обычный пользователь не мог изменить ни один из параметров политики. В случае с KES для Linux:
-
Конфигурация областей защиты от файловых угроз Поскольку сканирование всей файловой подсистемы существенно повышает нагрузку на ОС (Essential Theat Protection -> File Threat Protection -> Scan)
-
Конфигурация исключений (папки, маски файлов, процессы, названия угрозы) Если вы хотите, чтобы все сервисы продолжали работать в штатном режиме (например инсталляции Jira или Confluence) Essential Theat Protection -> File Threat Protection exclusions Essential Theat Protection -> Network Threat Protection -> Exclusions Advanced Threat Protection -> Anti-Cryptor -> Exclusions by mask Advanced Threat Protection -> Behavior Detection -> Exclusions by proccess Security Controls -> System Integrity Monitoring -> Monitoring exclusions/Exclusions by mask
-
Конфигурацию сканирования контейнеров Для того, чтобы чувствительный сервис внезапно упал, без попытки дезинфекции контейнера (General settings -> Container Scan settings)
-
Конфигурацию производительности В обязательном порядке настройте ограничения по использованию CPU и RAM для задач сканирования и самого антивируса, для предупреждения ситуации отказа в обслуживании сервиса, из-за отсутствия свободных ресурсов (General settings -> Application settings) Для агента администрирования:
-
Настройте защиту агента от неавторизованного удаления или выключения, а так же параметры парольной защиты (вкладка Settings)
-
Если в Организации есть удалённые сотрудники - не забудьте про профили соединений (Connectivity -> Connection profiles)
Задачи
Следующие типы задач должны быть на каждом сервере администрирования, вне зависимости от типа лицензии, которую вы используете для управляемых устройств:
-
Поиск вредоносного ПО
Стоит запускать не реже трёх раз в неделю, лучше в вечернее время, с учётом того, что пропущенные задачи будут запускаться автоматически, если устройство было недоступно в определённое время (Но вы можете использовать Wake-On-Lan, если вам это позволяет делать сетевая инфраструктура Организации и конфигурация конечных точек) -
Инвентаризация
При различных реализациях становиться достаточно ресурсоёмкой задачей как на конечных устройствах, так и для базы данных сервера администрирования. Без серьёзной необходимости не рекомендую включать инвентаризацию DLL-файлов, а так же запускать задачу только на эталонных устройствах. -
Обновление баз
Рекомендую запускать на регулярной основе, не реже двух раз в неделю. Если желаете уменьшить нагрузку от задачи - в качестве серверов обновлений можно поставить только сервера обновления Лаборатории Касперского (Kaspersky Update Servers) -
(Если лицензия распространяется через задачу) Добавление ключа
Лицензии и их распространение
Есть несколько способов распространять лицензии на программы безопасности:
-
При помощи групповых задач
-
В составе инсталляционного пакета
-
Автоматически
Наиболее удобным способом является автоматическое распространение лицензии, но оно является наименее контролируемым, поскольку лицензии выдаются даже на те устройства, которые не входят ни в одну из управляемых групп администрирования.
Задачи, к сожалению, не представляется возможным настроить достаточно гибко, чтобы активировались только те устройства, у которых отсутствует действующая лицензия (В выборках это настроить не представляется возможным, поскольку не существует соответствующего статуса устройства).
В составе инсталляционного пакета распространение лицензии является приемлемым, но в случае утечки пакета вы так же предоставите злоумышленнику лишнюю корпоративную лицензию на антивирус.
По своему опыту могу рекомендовать использовать последний способ распространения лицензий, при этом грамотно закрыв доступ до инсталляционных пакетов с лицензиями.
Параметры сервера администрирования
Лично я практически на каждой инсталляции сервера администрирования делаю следующие вещи:
-
Удаляю у группы BUILTINAdministrators права в Kaspersky Security Center (Перед этим не забыв предоставить своей учётной записи все необходимые привилегии и роли);
-
Отключаю ручное назначение точек распространения (можете оставить, если конечно хотите, чтобы внезапно ваш почтовый сервер или рабочая станция сотрудника с еле живым Pentium'ом стала точкой распространения :^));
-
Заранее настраиваю нужные правила перемещения для неуправляемых устройств, чтобы не испытывать боль от их ручного перемещения;
-
Формирую точечные профили политик для чувствительных сервисов, и для сетевой изоляции по тегам управляемых устройств.
Смена сервера администрирования для агентов
Настоятельно рекомендую производить смену сервера администрирования для выделенной тестовой группы управляемых активов.
Если для подключения к серверу используется шлюз соединения в демилитаризованной зоне - так же необходимо работает ли подключение через него, при помощи установки специально сформированного пакета с указанным шлюзом соединения.
А так же важная деталь - если в вашей инфраструктуре используется дисковое или файловое шифрование с использованием Kaspersky Security Center - предварительно, перед переносом данных устройств на новый сервер администрирования, необходимо при помощи параметров политики настроить их расшифровку.
Для того, чтобы сменить сервер администрирования необходимо создать задачу "Смена сервера администрирования", далее в поле "Сервер администрирования" вводим DNS-имя или IP-адрес нового сервера администрирования. Далее выбираем группу/выборку/устройства, которую вы выбрали для тестирования переезда и корректируем последующие параметры задачи.
Для любителей всё делать при помощи скриптов - смену сервера администрирования можно реализовать через встроенную в агент утилиту klmover.
Пример команды смены сервера администрирования через данную утилиту:
"C:Program Files (x86)Kaspersky LabNetworkAgentklmover.exe" -address ksc.domain.local
Уже её запуск на конечных хостах можно реализовать при помощи powershell и winrm.
Заключение
Если у кого-то остались вопросы относительно статьи, предложения, дополнительные темы, которые хотелось бы раскрыть более подробно - буду рад об этом услышать в комментариях.
Подводя итоги могу лишь сказать, что документация по продуктам играет ключевую роль в успешном внедрении и эксплуатации ПО. Она служит не только источником знаний для разработчиков, но и является важным инструментом для комьюнити, помогая ему эффективно использовать различные решения.
Всем хорошей документации, и спасибо за прочтение :^)
Автор: agseyn
