Защита серверов и рабочих станций

Основные требования к системе администрирования

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

1. Требования к подсистеме управления
   • Возможность удаленно и централизованно администрировать антивирусное ПО, установленное в сети: обязательно - АПО для защиты рабочих станций и серверов Windows, желательно - всех остальных антивирусов того же производителя
   • Возможность удаленно изменять настройки любого антивируса, подключенного к системе администрирования
   • Возможность централизованно создавать, модифицировать, запускать и удалять задачи, причем как для отдельных клиентов, так и для произвольных их групп
   • Возможность создавать групповые политики - базовые настройки для групп клиентов
   • Возможность контролировать соблюдение групповых политик - запрет на изменение настроек локальными пользователями, независимо от их привилегий
   • Возможность построения иерархической системы управления для оптимизации трафика, связанного с администраторской деятельностью - как правило, применяется иерархия серверов управления
   • Контроль состояния антивирусной защиты в сети
2. Требования к подсистеме обновления
   • Построение иерархической системы обновления с гибкими возможностями организации промежуточных источников для минимизации трафика связанного с распространением обновлений
   • Контроль содержимого всех промежуточных источников обновления - по возможности
   • Откат обновлений антивирусных баз - желательно, централизованный
   • Поддержка двух режимов обновления - вытягивания и проталкивания
3. Требования к подсистеме диагностики
   • Поддержка нескольких каналов доставки уведомлений:
     • электронная почта
     • сетевые уведомления (NET SEND, аналогичные средства Novell Netware и т. п.)
     • SNMP
     • запись в журналы Windows
     • пересылка на сервер управления
   • Централизованный сбор и хранение информации о событиях
   • Гибкая настройка регистрируемых типов событий и текста уведомлений
   • Поддержка режима тестирования доставки уведомлений
   • Анализ частоты заражений и генерация события типа "вирусная атака" с отправкой уведомления администратору антивирусной безопасности
   • Анализ событий при помощи фильтров
   • Генерация сводных отчетов, как правило:
     • отчет о наиболее распространенных вирусах
     • отчет о наиболее заражаемых клиентах
     • отчет о версиях антивирусных баз
     • отчет об используемых версиях АПО
     • отчет о защите сети
     • отчет об использовании лицензий
     • отчет об ошибках
   • Желательно - генерация отчетов по расписанию
4. Требования к подсистеме внедрения
   • Автоматическое обнаружение незащищенных узлов
   • Поддержка различных методов удаленной установки:
     • форсированная установка через RPC
     • установка через сценарии запуска (login script)
     • другие способы - желательно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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