Подсистема обновления

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

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

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

т. е. больше одного часа.

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

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

Путей решения у этой проблемы фактически два:

• Уменьшать размер обновлений- путь экстенсивный, поскольку защищаемая сеть может иметь и 10000 и даже большее количество узлов, а пропускная способность сети на некоторых участках может быть и 256 кбит/с и даже 64. Таким образом, проблема все равно будет возникать
• Использование промежуточных источников обновления- позволяет эффективно сократить количество обращений к каждому источнику путем введения дополнительных промежуточных источников обновления в необходимом количестве

Таким образом, система обновления - это набор средств и способов организации и контроля промежуточных источников обновления.

В общем случае система обновления может иметь такие типы структур:

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

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

В рассмотренных схемах обновления не конкретизирована структура источников. На практике встречаются следующие их типы:

• Внутренний FTP- или HTTP-сервер
• Общая папка в сети Microsoft (или Novell)
• Специализированный источник обновления на базе клиентского антивируса либо агента управления
• Полностью специализированный сервер обновления

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

Так, для обновления внутреннего FTP- или HTTP-сервера, администраторам потребуется использовать дополнительные средства для автоматической загрузки обновлений и размещения их на серверах. То же касается и общей папки сети Microsoft.

В случае с источником на базе клиента вопрос с автоматической загрузкой отпадает, однако дальнейший контроль источника обновлений в этом случае обычно отсутствует.

Пример. В Антивирусе Касперского для Windows Workstations (и для Windows File Servers) имеется опция загружать копию источника обновлений антивирусных баз в отдельный каталог для ретрансляции. В дальнейшем к этому каталогу можно представить доступ в рамках сети Microsoft, либо по протоколам FTP или HTTP. Тем не менее, проконтролировать, какая версия антивирусных баз хранится в источнике обновлений, возможности нет.

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

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

Пример. В Kaspersky Administration Kit Сервера администрирования могут выполнять также и функции серверов обновления: загружать обновления из источника верхнего уровня и распространять их среди подключенных клиентов. Дополнительным преимуществом такого подхода является использование для передачи обновлений на клиенты транспорта системы управления - данные передаются непосредственно от Сервера администрирования к Агентам без необходимости в какой-либо дополнительной авторизации

В вопросе обновления клиентов очень важна своевременность. Антивирусные базы должны доставляться в кратчайшие сроки после их выпуска. С другой стороны, как уже было показано выше, одновременное обновление большого количества клиентов может приводить если и не к перегрузке сети (если используется эффективная система источников обновления), то по крайней мере к снижению ее эффективности. Чтобы этого не происходило, обновление в различных группах часто разносят по времени при помощи планирования запуска задач. Дополнительно используется метод случайной задержки, когда запланированные на одно время задачи стартуют не синхронно, а выдерживают паузу случайной длины в рамках заданного интервала. Например, создается расписание запуска обновления в 13:00 со случайно задержкой в пределах 20 минут.

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

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

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

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