Подсистема управления

Для того, чтобы эффективно осуществлять удаленное управление даже отдельными узлами, оснащенными антивирусным ПО, необходимо где-то хранить параметры доступа к этим узлам - адреса, идентификаторы и т.п. Т.е. вопрос о централизованном характере системы управления возникает буквально сразу же. Как показывает практика, именно централизованный вариант является наиболее удобным и эффективным, поскольку все системы управления построены по одному и тому описанному ниже принципу.

Система управления строится на базе трех компонентов:

• Сервера управления
• Консоли управления
• Агента

Функции компонентов распределены следующим образом:

• Консоль управления- является интерфейсом для доступа к функциям сервера управления и транзитом через сервер управления и агент - к функциям локально установленных антивирусных средств, допускает удаленное подключение к серверу управления
• Сервер управления- предоставляет возможности удаленной настройки отдельных клиентов и их групп, формирования задач для групп клиентов и централизованного хранения их настроек, помимо этого хранит информацию о подключенных к нему узлах
• Агент- выполняет посредническую функцию между сервером управления и антивирусными комплексами, установленными на узлах, применяя локально переданные настройки и выполняя локальный запуск задач

Защищенный узел сети с установленным агентом принято называть клиентом или клиентским компьютером того сервера управления, к которому подключен агент.

Пример. В Kaspersky Administration Kit структура решения полностью совпадает с описанной, имеются:

• Сервер администрирования
• Консоль администрирования
• Агент администрирования

В других системах управления, встречаются варианты, когда сервер и консоль управления объединены в общий модуль, или же когда агент является составной частью антивируса, неотделимой от него

Совокупность всех агентов, подключенных к серверу управления приятно называть логической сетью или антивирусной сетью. Понятно, что в одной сети может существовать несколько логических сетей. Также понятно, что один и тот же узел может входить только в одну логическую сеть: если допустить обратное - получится полная неразбериха с правами и порядком удаленного управления антивирусами на узлах. Принимая во внимание возможность наличия нескольких логических сетей, возникает проблема их взаимодействия - подробнее об этом речь пойдет ниже.

Как только возникает вопрос об изменении настроек или о запуске задач одновременно на группе компьютеров, возникает и вопрос о структуре и взаимосвязи этих групп. Сегодня можно встретить два подхода к реализации работы с группами:

• Группы формируются произвольным образом каждый раз, когда возникает необходимость в управлении набором компьютеров, характеризующихся теми или иными признаками, например, на которых не обновлены антивирусные базы. Возможно сохранение информации о составе групп для повторного использования. Сохраненные группы могут пересекаться, т. е. включать одни и те же узлы
• Группы создаются на постоянной основе (возможно тоже с учетом каких-либо признаков, но менее подверженных изменениям) и не пересекаются по составу. Возможен только перенос узлов из одной группы в другую

Первый подход обладает большей гибкостью, при желании можно назначить задачу произвольному набору компьютеров, в зависимости от того, как складывается ситуация. Однако этот подход не позволяет эффективно отслеживать состояние настроек антивирусной защиты на узлах. Действительно, в какой-то момент времени настройки узла могут быть изменены вместе с одной группой компьютеров, в другой момент - уже с другой группой, в третий момент - индивидуально. В результате априори узнать, какие настройки используются на конкретном узле не представляется возможным, что приводит к ненужной неразберихе и потере контроля над состоянием защиты.

При втором подходе гибкость, очевидно меньше, зато появляется возможность задавать постоянные настройки для групп компьютеров и контролировать сохранение этих настроек в неизменном виде. С таким подходом уже гораздо проще отслеживать уровень защиты.

Пример. В Kaspersky Administration Kit используются постоянные группы компьютеров, которые могут создаваться как полностью вручную, так и автоматически на основании структуры Windows-сети - доменов и рабочих групп. Каждый из узлов может входить только в одну группу.

Таким образом, складывается структура элементов управления:

• Узлы- т. е. отдельные компьютеры, защищенные антивирусным ПО
• Группы- объединения узлов

Для чего вообще имеет смысл объединять компьютеры в группы? По сути, цели две:

• Выполнение задач на группе компьютеров
• Задание общих настроек для группы компьютеров

Достижение первой цели возможно в любой структуре групп: как первого, так и второго типа. Действительно, нет никакого противоречия в том, что узел входит в две группы и на нем выполняются задачи, сформированные для каждой из групп. Вторая цель достижима только в структуре с постоянными группами, составы которых не пересекаются. Это тоже вполне понятно, если для группы заданы настройки, которые должны быть справедливы для всех узлов этой группы, то для узла входящего в две группы одновременно возникает противоречие: неясно, настройки какой группы на нем будут использоваться.

Пример. Создание задач в Kaspersky Administration Kit не ограничено структурой групп. Задачи могут быть групповыми, т. е. относящимися к конкретной группе, так и глобальными, что в данном случае означает возможность сопоставления задачи произвольному объединению узлов, не являющихся группой и даже относящихся к различным группам.

Как правило, настройки заданные на уровне группы называются политикой. Отличия в этих терминах можно кратко сформулировать следующим образом: настройки - это "как есть", а политика - "как должно быть". В силу императивного характера политик, они предполагают наличие неких механизмов контроля. Практикуется два подхода:

• При отклонении настроек антивирусного ПО на узле от политики группы, агент формирует событие, о котором извещается администратор антивирусной безопасности
• Антивирусное ПО либо агент обладает механизмом блокирования изменения настроек АПО, т. е. при такой схеме отклонение попросту невозможно

Понятно, что такая категоричность не всегда удобна - легко представить себе ситуацию, при которой некоторые настройки должны быть зафиксированы жестко, а некоторые могут быть изменены локальными пользователями без особого ущерба качеству защиты. Большинство систем управления позволяют выборочно отмечать обязательные и необязательные параметры политики.

Пример. В Kaspersky Administration Kit используется смешанный подход. В первую очередь имеются политики, отдельные настройки которых могут быть отмечены как обязательные или необязательные. Эти настройки охватывают все аспекты работы антивирусных средств. Изменение обязательных параметров на локальных компьютерах полностью заблокировано. Но также выделяются и рекомендуемые настройки защиты, при отклонении от которых формируется уведомление администратору антивирусной безопасности. Такая реализация позволяет использовать преимущества обоих подходов.

Помимо этого, в Kaspersky Administration Kit реализована гибкая система применения политик, основанная на том, что настройки и политики четко разделяются даже на уровне локальных компьютеров и хранятся независимо. Применение политики может происходить одним из трех способов на выбор администратора:

• Политика не изменяет локальные настройки. Это означает, что применение политики выражается только в том, что вместо локальных настроек применяются настройки обязательных параметров политики, но после снятия атрибута обязательности или после удаления политики, снова применяются локальные настройки, которые остаются такими же, какими были до применения политики
• Политика заменяет настройки обязательных параметров. В этом случае при применении политики не только начинают действовать настройки обязательных параметров, но и локальные настройки заменяются настройками этих обязательных параметров. Следовательно, после снятия атрибута обязательности или после удаления политики, будут действовать те же настройки, что были в политике, а не локальные настройки, которые были до применения политики. На необязательные параметры политика никакого воздействия не оказывает
• Политика заменяет все локальные настройки. Т. е. независимо от установки атрибута обязательности все локальные настройки заменяются настройками политики, после этого необязательные параметры, как и прежде, могут быть изменены пользователем произвольным образом

Нередко в составе группы естественным образом выделяется подгруппа клиентов, для которых требуется незначительно изменить политику или создать отдельную групповую задачу. В этом случае было бы удобно выделить подгруппу в отдельную группу, являющуюся элементом исходной группы, чтобы в ней продолжали действовать групповые задачи и политики исходной группы. Многие системы управления поддерживают такую возможность. В этом случае логическая сеть будет представлять собой иерархическую структуру групп. Тут же возникает вопрос о применении задач и политик в такой системе. Возможны разные походы.

Пример. В Kaspersky Administration Kit групповая задача относится ко всем элементам группы - клиентам и подгруппам. Политика точно так же относится ко всем элементам группы, если только на уровне одной из подгрупп она не переопределена, т. е. не задана другая политика. При этом обязательные параметры групповой политики на уровне подгрупп переопределены быть не могут и остаются обязательными в создаваемых политиках подгрупп.

Структура групп, настройки групповых задач и политик, а также нередко и данные диагностики - вся эта информация должна так или иначе храниться на сервере и быть доступной для анализа и обработки. Как правило, для этих целей используется внешний сервер баз данных, по сути - четвертый компонент системы управления. Чаще всего в системах управления применятся бесплатная модификация Microsoft SQL Server 2000 - Microsoft SQL Server Desktop Engine 2000 или коротко MSDE 2000

Пример. В Kaspersky Administration Kit также используется внешний сервер баз данных и именно MSDE 2000. Это ПО входит в поставку Kaspersky Administration Kit и включает в себя встроенный Service Pack 3, устраняющий уязвимость, используемую для распространения червем Slammer

Поддерживается в Kaspersky Administration Kit и работа с полноценным Microsoft SQL Server 2000

Кроме вопроса удобства, который выражается в механизмах групп, групповых задач и политик, существует также вопрос производительности системы управления. Например, если в организации имеется несколько филиалов, каналы связи между которыми весьма ограничены, одновременное применение политики может вызвать перегрузку канала связи с филиалом.

Чтобы избежать этой ситуации используются следующие методы:

• Иерархия серверов управления
• Ограничения на связь между сервером управления и подключенными к нему агентами

Механизм иерархии серверов управления заключается в том, что одни сервера управления могут подключаться к другим. Соответственно подключаемый сервер будет подчиненным, а тот, к которому производится подключение - главным. При этом степень взаимодействия между главными и подчиненными серверами может быть разной.

Один из вариантов взаимодействия - подчиненные сервера согласно заданному расписанию передают на главный сервер данные диагностики, таким образом, чтобы на главном сервере имелась полная информация о состоянии защиты в сети. Недостатки данного подхода очевидны - настройку групп, групповых задач и политик придется выполнять независимо на каждом сервере, нет возможности создания задач для всех клиентов сети.

Второй вариант - группы управления привязываются к серверам управления, все управление происходит прозрачно, т.е. подчиненные сервера управления выполняют сугубо вспомогательную передаточную функцию, все действия по части управления выполняются на главном сервере управления. Недостатки - необходимость создавать отдельный сервер для каждой группы, низкая функциональность подчиненных серверов.

Применяются и другие, достаточно сложные для описания схемы реализации.

Пример. Иерархия Серверов администрирования реализована и в Kaspersky Administration Kit. Подчиненные Сервера входят в качестве элементов в состав групп главного Сервера, причем входят вместе со всей своей логической подсетью. Следовательно, к ним применяются групповые задачи и политики и такие задачи и политики называются унаследованными. Количество подчиненных Серверов, входящих в одну группу не ограничено

Принцип применения тот же, что и в иерархии групп - унаследованные задачи применяются ко всем клиентам подчиненного Сервера, унаследованные политики действуют также на всех клиентах, если только не переопределены на уровне групп или подгрупп подчиненного Сервера. Обязательные параметры по-прежнему переопределять нельзя и они остаются обязательными в создаваемых политиках.

Подчиненные Сервера остаются полноценными Серверами администрирования и позволяют выполнять все те же функции, что и главные Сервера. Единственное ограничение - переопределение политик, о котором говорилось выше. Структура групп, настройки задачи и политик, база событий хранятся независимо на всех Серверах администрирования. Передача данных о событиях происходит только по запросу в момент сбора информации для формирования отчета.

Доступ к подчиненным Серверам возможен как напрямую, так и через интерфейс главного Сервера администрирования.

Еще одним фактором иерархии серверов является ее глубина. Чаще всего можно встретить двухуровневую иерархию, где есть ровно один главный сервер управления, к которому подключены все остальные сервера управления. Однако есть реализации допускающие произвольную глубину иерархии.

Пример. Kaspersky Administration Kit позволяет создавать иерархию Серверов администрирования любой глубины. В этом случае один и тот же Сервер администрирования может выступать в роли подчиненного и в роли главного. Каждый Сервер администрирования может иметь только один главный Сервер и сколько угодно подчиненных.

Немаловажным аспектом системы управления является организация доступа к ее функциям. Реализация разграничения доступа может быть самой разной. Можно выделить следующие характерные схемы:

1. Разграничение прав доступа отсутствует, для подключения к серверу нужно знать только его адрес - на практике практически не встречается
2. Идентификация пользователей, имеющих право доступа к серверу отсутствует, для доступа к серверу необходимо указать пароль доступа. Подключившийся пользователь получает неограниченные права в рамках системы управления
3. Идентификация и аутентификация пользователей основана на системе пользователей Windows. Для определения прав доступа используются группы Windows
4. Идентификация и аутентификация пользователей основана на системе пользователей Windows. Права доступа определяются на основе встроенных в систему управления механизмов создания групп и распределения прав
5. Идентификация, аутентификация и разграничение доступа базируются на встроенных в систему управления средствах и не задействуют внешних систем

Пример. В Kaspersky Administration Kit используется третья схема реализации. Выделяется две группы пользователей - администраторы и операторы логической сети, первые имеют неограниченные права, вторые могут только просматривать настройки и создавать отчеты

Для идентификации, аутентификации и разграничения доступа используются средства Windows. Права администраторов логической сети получают пользователи с правами локальных администраторов компьютера, на котором установлен Сервер администрирования, и пользователи, входящие в локальную группу KLAdmins, права операторов логической сети получают пользователи, входящие в локальную группу KLOperators. Все прочие пользователи прав доступа к Серверу администрирования не получают