3. Dr.Web Enterprise Security Suite Версия 12.0 от 23.09.21. Руководство администратора Доктор Веб
 Скачать 4.42 Mb.
|
|
Глава 9: Настройка Сервера Dr.Web Местоположение конфигурационных файлов приведено в разделе Сервер Dr.Web 2. Единое имя Сервера Для всех Серверов должны быть заданы одинаковые IP-адрес или DNS-имя Сервера, используемые при формировании файлов инсталляции Агента для станций антивирусной сети. Данное имя задается через Центр управления: Администрирование → Конфигурация Сервера Dr.Web → вкладка Сеть → вкладка Загрузка → поле Адрес Сервера Dr.Web. Настройки этого раздела хранятся в конфигурационном файле download.conf (описание файла приведено в документе Приложения, в п. Ж3. Конфигурационный файл download.conf ). 3. Настройка использования кластера На DNS сервере в сети необходимо зарегистрировать общее имя кластера для каждого отдельного Сервера и задать метод балансировки нагрузки. Для автоматического применения настроек в кластере Серверов Dr.Web необходимо использование специального кластерного протокола. Для настройки кластерного протокола необходимо для каждого из Серверов в Центре управления перейти в меню Администрирование → Конфигурация Сервера Dr.Web и задать следующие настройки: a) Для включения кластерного протокола на вкладке Модули установите флаг Протокол кластера Серверов Dr.Web. b) Для настройки параметров взаимодействия Серверов в составе кластера на вкладке Кластер задайте соответствующие параметры. c) После задания всех необходимых параметров, нажмите кнопку Сохранить и перезагрузите Серверы. Например · Multicast-группа: 232.0.0.1 · Порт: 11111 · Интерфейс: 0.0.0.0 В данном примере для всех Серверов кластера настраиваются транспорты для всех интерфейсов. В иных случаях, например, когда одна из сетей является внешней для кластера, и через нее подключаются Агенты, а вторая сеть является внутрикластерной, то кластерный протокол лучше открывать только для интерфейсов внутренней сети. В этом случае в качестве интерфейсов необходимо задавать адреса вида 192.168.1.1 , ..., 192.168.1.N. Руководство администратора 352 Глава 9: Настройка Сервера Dr.Web 4. Единая база данных Для возможности работы с одной базой данных все Серверы Dr.Web должны быть одинаковой версии. Все Серверы Dr.Web в пределах одного кластера должны работать с единой внешней базой данных. Как и в случае использования базы данных без организации кластера, каждый из Серверов обращается к базе данных независимо, и все данные Серверов хранятся раздельно. Везде, где это актуально, Сервер забирает из базы данных только записи, привязанные к его ID, который является уникальным для каждого Сервера. Использование единой базы данных позволяет Серверам работать с Агентами, изначально зарегистрированными на других Серверах кластера. При создании кластера Серверов с единой базой данных необходимо учитывать следующие особенности: · База данных может быть установлена как отдельно от всех Серверов, так и на одном из компьютеров, на котором установлен Сервер кластера. · База данных должна быть создана до установки первого Сервера кластера или до момента подключения первого Сервера к базе данных. · В процессе добавления новых узлов в кластер (за исключением первого Сервера), при установке Серверов не рекомендуется сразу задание единой базы данных, которая используется в данном кластере. Иначе это может привести к удалению информации, уже хранящейся в базе данных. Рекомендуется устанавливать Серверы изначально с внутренней базой данных, а после установки переключать их на единую внешнюю базу данных. Переключить Серверы на использование внешней базы данных можно через Центр управления: в меню Администрирование → Конфигурация Сервера Dr.Web → на вкладке База данных или через конфигурационный файл Серверов drwcsd.conf · За исключением первого Сервера кластера, не рекомендуется вводить в кластер Серверы, уже функционирующие в антивирусной сети с иной внешней или внутренней базой данных. Это приведет к потере данных: информации о станциях, статистике, настройках (за исключением настроек, хранящихся в конфигурационных файлах), так как при импорте данные в базе полностью удаляются. В данном случае возможен только частичный импорт некоторых настроек. 5. Одна версия репозитория На всех Серверах кластера репозитории должны содержать обновления одной и той же версии. Достижение данного требования возможно одним из следующих способов: · Одновременно обновлять все Серверы кластера с ВСО. В данном случае все Серверы будут содержать самую последнюю версию обновлений. Обновление Руководство администратора 353 Глава 9: Настройка Сервера Dr.Web репозиториев всех Серверов также возможно настроить с локальной зоны обновлений, с которой будет раздаваться одна и та же подтвержденная версия обновлений продуктов, или же самая последняя в случае создания зеркала ВСО. · Допускается создание гибридной структуры, сочетающей в себе как кластер Серверов, так и иерархическую структуру на основе межсерверных связей. При этом один из Серверов (может быть как Сервером кластера, так и не входящим в кластер) назначается главным и получает обновления с ВСО. Остальные Серверы кластера — подчиненные — получают обновления с главного Сервера по межсерверным связям. В случае настройки обновления Серверов кластера с локальной зоны (зеркала ВСО) или с главного Сервера необходимо следить за функционированием этой зоны или главного Сервера. В случае выхода из строя узла, раздающего обновления, необходимо перенастроить один из других Серверов на роль главного Сервера или создать новую зону обновлений для получения обновлений с ВСО соответственно. 6. Особенности распределения лицензий для станций Для распределения лицензий между Серверами кластера могут использоваться следующие подходы: a) В пределах кластера не настраивается иерархическая структура Серверов. Достаточно добавить лицензионный ключ (или несколько ключей) на одном из Серверов кластера. Информация об этом лицензионном ключе будет записана в общую базу данных. Таким образом, лицензионный ключ будет использоваться всеми Серверами кластера одновременно. Общее количество лицензий, хранящихся в общей базе данных, должно соответствовать общему количеству станций, обслуживаемых всеми Серверами кластера. Для возможности использования лицензионного ключа на всех Серверах кластера, а не только на том, на котором ключ был добавлен, остальные Серверы кластера необходимо перезагрузить после добавления ключа. b) Возможно создание гибридной структуры, сочетающей в себе как кластер Серверов, так и иерархическую структуру на основе межсерверных связей. Подобная структура будет полезна, если при обслуживании Агентов используются Серверы как входящие в кластер, так и не входящие. В этом случае осуществляется распространение необходимого количества лицензий из лицензионного файла по межсерверной связи непосредственно в процессе работы: · С Сервера, не входящего в кластер, на один из Серверов кластера. Распространенные лицензии будут использоваться всеми Серверами кластера как описано в п. а). · С одного из Серверов кластера (т. е. из ключа, используемого всеми Серверами кластера) на Сервер, не входящий в кластер. Настройка распространения необходимого количества лицензий на необходимый срок осуществляется вручную администратором антивирусной сети (подробнее см. раздел Распространение лицензий по межсерверным связям ). Руководство администратора 354 Глава 9: Настройка Сервера Dr.Web Например, можете настроить иерархическую структуру Серверов и выделить главный Сервер (может быть как Сервером кластера, так и не входящим в кластер), который будет раздавать как обновления репозитория, так и лицензии из лицензионного файла. 7. Задания в расписании Серверов Чтобы исключить дублирование запросов к БД, рекомендуется выполнять только на одном из Серверов следующие задания из расписания Сервера: Purge Old Data, Backup sensitive data, Purge old stations, Purge expired stations, Purge unsent IS events. Например, на Сервере, который расположен на том же компьютере, что и единая внешняя база данных. Или на наиболее производительном компьютере кластера, если конфигурации Серверов различаются, и база данных установлена на отдельном компьютере. 9.15. Интеграция c инфраструктурой виртуальных рабочих мест Dr.Web Enterprise Security Suite поддерживает интеграцию с инфраструктурой виртуальных рабочих мест (VDI). Такая возможность полезна при работе с тонкими клиентами, поддерживающими работу в терминальном режиме по протоколу RDP. Работа антивирусной сети при этом организуется следующим образом: 1. Администратор антивирусной сети создает эталонный образ виртуальной станции с предустановленным ПО и Агентом Dr.Web, после чего подключает эталон к Серверу. 2. Из созданного эталона клонируются необходимые виртуальные станции. 3. По истечении заданного срока виртуальные станции удаляются. Впоследствии виртуальные станции создаются заново из эталонного образа по мере необходимости. Чтобы подготовить антивирусную сеть к работе с VDI 1. Выберите пункт Антивирусная сеть в главном меню Центра управления и создайте новую станцию, которая будет служить эталонным образом. 2. Установите на созданную станцию Агент Dr.Web и все необходимое ПО. Подключите станцию к Серверу. 3. В том же разделе создайте новую группу , в которой будут размещаться виртуальные станции. Руководство администратора 355 Глава 9: Настройка Сервера Dr.Web 4. Настройте порядок регистрации виртуальных станций. Для этого в Центре управления перейдите в раздел Администрирование → Пользовательские процедуры . Добавьте новую процедуру на основе события Новичок подключается к Серверу. В поле Текст процедуры укажите: local args = ... -- args.id, args.address, args.station if args.id == ' <идентификатор_эталонной_станции>' then return { "id", dwcore.get_uuid(), "pgroup", " <идентификатор_первичной_группы>" } end В качестве <идентификатора_эталонной_станции> необходимо указать ID эталонной станции, созданной на этапе 1 . В качестве <идентификатора_первичной_группы> укажите ID группы, созданной на этапе 3 . Данная информация всегда доступна в свойствах объектов в дереве Антивирусной сети. При клонировании каждая новая виртуальная станция будет получать идентификатор, совпадающий с идентификатором эталонной станции. По условиям процедуры, при подключении станции к Серверу Dr.Web для нее генерируется новый UUID, после чего станция регистрируется в первичной группе с указанным идентификатором. При написании процедуры рекомендуется сверяться со встроенным шаблоном процедуры Новичок подключается к Серверу. Для уточнения информации, в том числе возможных альтернативных параметров и возвращаемых значений, в Центре управления в дереве процедур выберите Examples of the hooks → Новички → Новичок подключается к Серверу. Плановое удаление неактивных виртуальных станций Для рационального распределения лицензий, а также для предотвращения скопления в базе данных информации об удаленных виртуальных станциях, необходимо настроить задание по автоматическому удалению неактивных станций. Под неактивными подразумеваются станции, которые не подключались к Серверу в течение указанного срока. Для подготовки задания по автоматическому удалению неактивных станций 1. В Центре управления перейдите в раздел Администрирование → Планировщик заданий Сервера Dr.Web. 2. Создайте новое задание, нажав кнопку Создать задание на панели инструментов. Руководство администратора 356 Глава 9: Настройка Сервера Dr.Web 3. На вкладке Действие в выпадающем списке выберите Выполнение скрипта, после чего импортируйте из отдельного файла, либо введите вручную следующий Lua- скрипт в поле ниже: local adminName = 'admin' -- указываем ID группы local gid = ' <идентификатор__первичной_группы>' -- задаем период неактивности (в секундах) local interval = 86400 require('st-db-state') require('core/datetime') require('core/admins/admins') local lastseen = Datetime.timeUnixstampToDBFormat(Datetime.nowTimestamp() - interval) local stations = {} -- выполняем запрос к базе данных local res, err1 = DBuilder() :select('id, lastseenat') :from('stations') :where('gid', gid) :where('lastseenat '..dwcore.base64_decode('PA=='), lastseen) :where('state !=', st_db_state.st_db_state_logged_in) :get() if res and next(res) then for i = 1, #res do table.insert(stations, res[i][1]) end end -- удаляем неактивные станции local function delete_stations(ids) local admin, err = Admin:initWithLogin(adminName) require 'core/admins/admins' require('core/stations/stations') local status, results_stations = Stations:delete(ids, admin) return '' end return delete_stations(stations) Руководство администратора 357 Глава 9: Настройка Сервера Dr.Web В качестве <идентификатора_первичной_группы> укажите ID группы, созданной на этапе 3 при подготовке к работе с VDI. Данный скрипт обращается к базе данных, получает ID станций, не подключавшихся к Серверу в течение последних 24 часов (86400 секунд), и удаляет эти станции из группы с указанным ID. Рекомендуется обновлять эталонный образ каждый раз после обновления антивирусных компонентов, требующего перезагрузки операционной системы. После обновления проверьте и при необходимости скорректируйте идентификатор эталонной станции в тексте процедуры. Руководство администратора 358 Глава 10: Обновление компонентов Dr.Web Enterprise Security Suite в процессе работы Глава 10: Обновление компонентов Dr.Web Enterprise Security Suite в процессе работы В данной главе описано обновление компонентов Dr.Web Enterprise Security Suite, которое осуществляется в процессе работы продукта и не подходит для перехода на новую версию. Обновление продукта и его компонентов до новой версии описано в Руководстве по установке, в разделе Глава 7: Обновление компонентов Dr.Web Enterprise Security Suite Перед началом обновления Dr.Web Enterprise Security Suite и его отдельных компонентов настоятельно рекомендуем проверить корректность настроек протокола TCP/IP для возможности доступа в интернет. В частности, должна быть включена и содержать корректные настройки служба DNS. Перед обновлением ПО рекомендуется настроить конфигурацию репозитория, в том числе доступ к ВСО Dr.Web (см. п. Общая конфигурация репозитория ). 10.1. Обновление Сервера Dr.Web и восстановление из резервной копии Центр управления предоставляет следующие возможности по управлению ПО Сервера Dr.Web: · Обновление ПО Сервера на одну из доступных версий, скачанных из ВСО, и хранящихся в репозитории Сервера. Описание настроек обновления репозитория с ВСО приведены в разделе Управление репозиторием Сервера Dr.Web · Откат ПО Сервера к сохраненной резервной копии. Резервные копии Сервера создаются автоматически при переходе к новой версии в разделе Обновления Сервера Dr.Web (шаг 4 в процедуре ниже). Обновление Сервера также возможно осуществлять при помощи дистрибутива Сервера. Описание процедуры приведено в Руководстве по установке, в разделе Обновление Сервера Dr.Web для ОС Windows или Обновление Сервера Dr.Web для ОС семейства UNIX Не все обновления Сервера содержат файл дистрибутива. Некоторые их них возможно установить только через Центр управления. При обновлении Сервера под ОС семейства UNIX через Центр управления, версия Сервера в пакетном менеджере ОС не изменится. Руководство администратора 359 Глава 10: Обновление компонентов Dr.Web Enterprise Security Suite в процессе работы Для управления ПО Сервера Dr.Web: 1. Выберите пункт Администрирование в главном меню Центра управления, в открывшемся окне выберите пункт управляющего меню Сервер Dr.Web. 2. Для перехода к списку версий Сервера выполните одно из следующих действий: · Нажмите на текущую версию Сервера в главном окне. · Нажмите кнопку Список версий. 3. Откроется раздел Обновления Сервера Dr.Web со списком доступных обновлений и резервных копий Сервера. При этом: · В списке Текущая версия указана версия Сервера, которая используется в данный момент. В разделе Список изменений приведен краткий список новых возможностей и список ошибок, исправленных в данной версии относительно предыдущей версии обновления. · В списке Все версии приведен список обновлений для данного Сервера, скачанных с ВСО. В разделе Список изменений приведен краткий список новых возможностей и исправленных ошибок для каждого из обновлений. Для версии, соответствующей первоначальной установке Сервера из инсталляционного пакета, раздел Список изменений пуст. · В списке Резервные копии приведен список резервных копий, сохраненных для данного Сервера. В разделе Дата приводится информация о дате резервного копирования. 4. Для обновления ПО Сервера установите опцию напротив нужной версии Сервера в списке Все версии и нажмите кнопку Сохранить. Произвести обновление можно только на более позднюю версию Сервера относительно используемой в данный момент. В процессе обновления Сервера текущая версия сохраняется как резервная копия (помещается в раздел Резервные копии), а версия, на которую осуществляется обновление, перемещается из раздела Все версии в раздел Текущая версия. Резервные копии сохраняются в следующем каталоге: var → update → backup → <старая_версия>-<новая_версия> В процессе обновления создается или дополняется файл журнала var → dwupdater.log 5. Для отката ПО Сервера к сохраненной резервной копии установите опцию напротив нужной версии Сервера в списке Резервные копии и нажмите кнопку Сохранить. В процессе отката ПО Сервера, резервная копия, на которую осуществляется переход, помещается в раздел Текущая версия. |