Антивирус для хранилища элементов

Иллюстрации

Показать все

Изобретение относится к области антивирусной защиты. Техническим результатом является повышение надежности антивирусной защиты. Обеспечены системы и методологии для интеграции антивирусной АВ Подключаемой Программы (Программ) как части Хранилища Элементов. Семантику для работы АВ Подключаемой Программы (Программ) обеспечивает реляционное Хранилище Элементов путем использования компонента метаданных и компонента сканирования, связанных с Хранилищем Элементов. Компонент метаданных может обеспечивать значение сигнатуры, связанное с Хранилищем Элементов, которое может представлять время сканирования данных и результат для каждого просканированного элемента. Компонент сканирования может обеспечивать формирование очереди элементов в хранилище данных в синхронном и/или асинхронном режиме как для сканирования, так и для очистки посредством АВ Подключаемой Программы, предоставляемой поставщиками. 6 н. и 23 з.п. ф-лы, 14 ил.

Реферат

ПЕРЕКРЕСТНЫЕ ССЫЛКИ НА СВЯЗАННЫЕ ЗАЯВКИ

Изобретение по настоящей заявке испрашивает приоритет по предварительной заявке № 60/581,569, поданной 21 июня 2004 г., на изобретение под названием АНТИВИРУС ДЛЯ ХРАНИЛИЩА ЭЛЕМЕНТОВ и предварительной заявке № 60/581,896, поданной 22 июня 2004 г., на изобретение под названием АНТИВИРУС ДЛЯ ХРАНИЛИЩА ЭЛЕМЕНТОВ. Материалы этих заявок включены в настоящую посредством ссылки.

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Настоящее изобретение в основном относится к антивирусной защите, более конкретно к системам и способам, которые облегчают интеграцию антивирусной Подключаемой Программы (Программ) со средой Хранилища Элементов, в которой Элементы могут быть описаны в терминах отношений и атрибутов.

УРОВЕНЬ ТЕХНИКИ

Растущие достижения в области компьютерной техники (например, скорость микропроцессоров, емкость памяти, пропускная способность при передаче данных, функциональность программного обеспечения и тому подобные) в целом содействовали расширению применения компьютерной техники в различных отраслях промышленности. Еще более мощные серверные системы, которые часто выполнены как совокупность серверов, часто обеспечивают для обслуживания запросов, исходящих от внешних источников, таких как Всемирная Паутина (World Wide Web), например. Поскольку локальные Интранет-системы стали более сложными и задействуются для обслуживания больших сетевых нагрузок и соответствующих приложений, запросы внутренних систем соответственно также выросли. Как таковое, большинство деловых данных хранится в хранилищах данных с управляющими системами.

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

Данные внутри хранилища данных могут быть организованы путем одной или большего количества таблиц, причем соответствующие таблицы включают в себя набор записей, а запись может включать в себя набор полей. Обычно записи индексируют как строки в таблице, а поля записей обычно индексируют как столбцы, так что пара строка/столбец позволяет формировать ссылку на конкретные данные в таблице. Типично такие хранилища данных могут быть отображены как организованные подборки соответствующей информации, сохраненные как "записи", имеющие "поля" информации в них. Например, хранилище данных о финансах может иметь запись для финансовых транзакций, такую как дебиторская задолженность, заимствованные средства, потребительская информация и тому подобное. Между самим по себе реальным хранилищем данных (то есть данными, реально сохраненными в устройстве хранения) и пользователями системы управляющая или операционная система обычно может обеспечить программную прослойку или слой. Как таковое, хранилище данных может оградить пользователей от забот о деталях нижележащего аппаратного уровня. Как правило, все запросы пользователей на доступ к данным обрабатываются системным администратором. Например, информация может быть добавлена в файлы данных или удалена из них, информация может быть отыскана в таких файлах, или эти файлы могут быть обновлены информацией и тому подобное, все это может быть осуществлено без знания пользователя о выполнении нижележащей системы.

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

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

С другой стороны, в реляционных Хранилищах Элементов содержимое может существовать в элементе, тогда как элемент может включать в себя множество свойств, причем каждое свойство может быть связано с различными другими элементами. Таким образом, выполнение сохранения в Хранилище Элементов и считывание из хранилища могут содержать результаты, которые могут быть собраны в одно целое по множеству свойств и множеству элементов. Это может создать иной принцип, такой как создание пути обновления или считывания с множеством свойств. Вирусы могут использовать такую компоновку для того, чтобы прятаться в «кусках», например, вирус может сохранять зашифрованное тело 'X' в свойствах объекта и распространяться при опросе хранилища и декодировании на клиенте зашифрованного свойства, такого как метаданные для изображения, которые могут выглядеть невинными для антивирусных программ.

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

Таким образом, существует необходимость в устранении вышеуказанных недостатков, связанных с традиционными системами и методологиями, относящимися к функционированию Хранилища Элементов.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

В соответствии с настоящим изобретением обеспечены системы и способы построения ожиданий и семантики антивирусной (АВ) Подключаемой Программы (Программ) в реляционном Хранилище Элементов посредством применения компонента метаданных и компонента сканирования, связанных с Хранилищем Элементов. Такой компонент метаданных может обеспечивать набор правил и/или логики в Хранилище Элементов для предписывания антивирусной Подключаемой Программе, когда сканировать содержимое, как сканировать, когда делать недействительным и тому подобное. Компонент метаданных может также обеспечивать значение сигнатуры, присваиваемое Хранилищу Элементов, которое может представлять время сканирования данных, с указанным пространством (например, указанными столбцами) в реляционном Хранилище Элементов для идентификации результата такого сканирования (например, чистый результат, подозрительный результат, инфицированный результат, не нужно сканировать и тому подобное). Интерфейс Прикладного Программирования (ИПП) может быть обеспечен для вызова Подключаемой Программы, как требуется, для обновления сигнатур и установки нового значения сигнатуры. Дополнительно для сбалансирования скорости/тщательности, с которыми элементы как результаты запроса должны быть представлены пользователю, могут быть предложены различные варианты проведения сканирования в зависимости от риска того, что такие результаты будут просканированы не полностью. Например, пользователь может пожелать пожертвовать тщательностью (например, примет неполные результаты в ответ на запрос) для получения преимущества в том, что все вносящее вклад в результаты содержимое будет полностью просканировано.

Более того, дополнительный набор правил в Хранилище Элементов может устанавливать отношения между элементами, тогда как набор правил может дополнительно позволять определять отношения и обеспечивать информацию, необходимую для синтаксического анализа по структуре данных для определения отношений текста к элементам. Более того, для обеспечения необходимого набора правил и представления нужной информации может быть использована некоторая схема. Например, для представления компонентов соответствующих сущностей для представлений «в памяти» может быть обеспечена объектная модель документа. Дополнительно компонент сканирования может обеспечивать формирование очереди элементов в хранилище данных в синхронном и/или асинхронном режиме как для сканирования, так и для очистки посредством АВ Подключаемой Программы.

В соответствии с одним вариантом настоящего изобретения для обеспечения обратной совместимости Хранилища Элементов (и его АВ Подключаемых Программ) с общепринятыми файлами (например, файлами потоков данных и приложений) может быть обеспечена компоновка драйверов фильтров, пакетно собранных по Множественным Провайдерам по Универсальному соглашению об Именовании (МУП, Multiple Universal Naming convention Providers (MUP)) (Универсальное Соглашение об Именовании (УСН, Universal Naming Convention (UNC)) позволяет использовать конвенцию об именовании для файлов, что обеспечивает машинно независимые средства обнаружения файла). Такое непосредственное разделение на слои компонентов фильтров по МУП провайдерам обеспечивает компонент файловой системы, который обслуживает запросы ВВОДА/ВЫВОДА для пространства имен УСН. Таким образом, та же видимость содержимого, доступного Хранилищу Элементов, может быть обеспечена АВ Подключаемой Программе.

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 - структурная схема реляционного Хранилища Элементов, которое использует антивирусную (АВ) Подключаемую Программу, в соответствии с вариантом настоящего изобретения;

Фиг.2 - структурная схема компонента сканирования в соответствии с вариантом настоящего изобретения;

Фиг.3 - методология предварительного сканирования в соответствии с вариантом настоящего изобретения;

Фиг.4a-4д - различные стадии создания и сканирования строк в соответствии с примером варианта осуществления настоящего изобретения;

Фиг.5 - разделенная на слои компоновка фильтров для конкретной системной архитектуры в соответствии с вариантом настоящего изобретения;

Фиг.6 - краткое, приводимое в виде примера, описание системы для преобразования документов в структуры данных, находящиеся в памяти Хранилища Элементов, в соответствии с вариантом настоящего изобретения;

Фиг.7 - цикл предварительного сканирования данных в Хранилище Элементов в соответствии с вариантом настоящего изобретения;

Фиг.8 - очередь предварительной очистки данных в Хранилище Элементов в соответствии с вариантом настоящего изобретения;

Фиг.9 - структурная схема, схематически представляющая подходящее компьютерное окружение, в котором можно осуществить различные варианты настоящего изобретения;

Фиг.10 - система клиент-сервер, на которой можно применять методологию антивирусного сканирования, в соответствии с одним из вариантов настоящего изобретения.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

На Фиг.1 представлена структурная схема реляционного Хранилища 100 Элементов, которое взаимодействует с антивирусной (АВ) Подключаемой Программой 130, в соответствии с вариантом настоящего изобретения. Традиционно Хранилище 100 Элементов данных может быть реляционной базой данных, которая использует три признака, а именно элементы, связи и атрибуты. Элемент может представлять любую «вещь», которую пользователь, такой как клиент, желает представить как элемент, и может быть уникально идентифицирован ИД (ID) элемента. Связь обеспечивает именованное, направленное отношение между двумя элементами. Атрибут связывает помеченное значение с элементом. Элементы описывают в терминах связей и атрибутов. Связи представляют взаимосвязи элементов, а атрибуты представляют другую информацию об элементах.

Более того, в такой реляционной среде хранения данных данные могут быть сохранены как строки в одной или нескольких таблицах. К хранилищу данных можно обращаться посредством одного или множества запросов в виде транзакций с T1 по TN включительно (N - целое число). Такие транзакции могут, например, включать в себя манипулирование строчного уровня данными в Хранилище 100 Элементов. Транзакции 112, 114, 116 могут иметь доступ к хранилищу данных на основании уровня избирательного доступа, присвоенного им хранилищем данных (например, доступ только для считывания, доступ считывания/записи и тому подобный), к тем данным, которые имеют особую важность.

Хранилище 100 Элементов по настоящему изобретению может включать в себя компонент 110 метаданных и компонент 120 сканирования. Компонент 110 метаданных может обеспечивать набор правил и/или логику в пределах хранилища 110 данных для управления операциями антивирусной Подключаемой Программы 130. Компонент 110 метаданных может обеспечивать семантику для АВ Подключаемой Программы 130, такую как когда сканировать, как сканировать, когда делать недействительным и тому подобное.

Более того, компонент 110 метаданных может обеспечивать указание приемлемого уровня запрета для статуса текущих вирусов, которые известны на момент времени выполнения сканирования на вирусы хранилища 100 данных. Например, приемлемый уровень запрета может быть обозначен временной отметкой, причем хранилищу может быть присвоена глобальная АВ временная отметка сигнатуры, с присвоенным значением «VIRUSSIGNATURETS».

Пример Языка Определения Данных (ЯОД, DDL) для инициализации Интерфейса Прикладного Программирования (ИПП) для вызова Подключаемой Программы для обновления сигнатур и установки нового значения сигнатуры может включать в себя:

GetNewVirusSignature();

GetCurrentVirusSignature().

В соответствии с вариантом настоящего изобретения строки, связанные с таблицами хранилища 100 данных могут включать в себя две строки для определения двух свойств, а именно «последнее Сканирование Сигнатуры Вируса» и «Состояние Сканирования», что будет более детально описано далее. Вкратце, «последнее Сканирование Сигнатуры Вируса» представляет сохраненную построчную временную отметку, на которой последнее антивирусное (АВ) сканирование хранилища 100 данных было завершено по строке, а “Состояние Сканирования” показывает, является ли содержимое строки «чистым», «подозрительным» или «инфицированным». При создании строки система автоматически устанавливает значение «последнее Сканирование Сигнатуры Вируса» в ноль, а состояние содержимого строки в «подозрительно». Может быть обеспечен Интерфейс Прикладного Программирования (ИПП) для вызова антивирусной Подключаемой Программы 130, которая применяется для сканирования хранилища 100 данных, как требуется, обновления сигнатур и установки нового значения сигнатуры. Соответственно компонент метаданных может предоставлять значение сигнатуры, связанное с Хранилищем 100 Элементов, которое может представлять время сканирования данных, с пространством, выделенным в реляционном хранилище, для идентификации результата такого сканирования (например, чистый результат, подозрительный результат, инфицированный результат). Очевидным является, что хотя антивирусная проверка может быть функцией, выполняемой системой по умолчанию, компоненту метаданных может быть присвоено «не нужно проверять», когда пользователь решает не сканировать определенные элементы.

Хранилище 100 Элементов может также включать в себя компонент сканирования 120, который использует надежным образом Подключаемую Программу 130. Компонент сканирования может обеспечивать формирование очередности элементов (например, недавние обновления, изменения и тому подобное) в Хранилище Элементов в синхронном и/или асинхронном режиме как для сканирования, так и для очистки АВ Подключаемой Программой, которая поставляется сторонними поставщиками.

На Фиг.2 представлена структурная схема, иллюстрирующая компонент 120 сканирования, дополнительно включающий в себя компонент 210 асинхронной очередизации (Предварительное Сканирование) и компонент 220 синхронной очередизации (Сканирование в Доступе). Обычно АВ Подключаемая Программа не может обнаружить новый кусочный вирус при входе в Хранилище Элементов. Поэтому могут быть запущены АВ Подключаемые Программы для анализа всего содержимого Хранилища 200 Элементов. Соответственно АВ Подключаемые Программы не ограничены конкретным доменом Хранилища 200 Элементов, даже если пользователь подключен к такому конкретному домену. В дополнение Хранилище 200 Элементов может также использовать компонент 230 планирования, который формирует очередь содержимого Хранилища Элементов для сканирования АВ Подключаемой Программой. Очевидным является, что компонент 230 планирования также может быть частью компонента 120 сканирования, хотя на Фиг.2 он и показан как отдельный компонент. Такой компонент может ставить в очередь и убирать из очереди содержимое, вызывать АВ Подключаемую Программу и на основании результатов обновлять компонент метаданных.

Традиционно Хранилище 200 Элементов может использовать компонент 210 асинхронной очередизации для очереди «Предварительного Сканирования» посредством автоматической постановки в очередь новых или обновленных элементов для сканирования на вирусы или очистки от вирусов. Элементы, упорядоченные в очередь, могут быть разупорядочены Хранилищем 200 Элементов, например, посредством компонента 230, а подходящий АВ интерфейс может быть вызван синхронно.

Расписание несканированных элементов для обработки АВ Подключаемой Программой может быть предоставлено в ИПП «Элемент Имеет Вирус». Такой вызов может быть выдан синхронно, и Хранилище 200 Элементов может обновить соответствующий АВ компонент метаданных в Хранилище Элементов, основываясь на Булевом результате этого вызова. Например, если интерфейс выдает значение «TRUE» («ИСТИННО»), объект может быть обозначен как содержащий вирус, и АВ статус для строки обновлен как:

lastVirusSignatureScanTS =@@VIRUSSIGNATURETS AND scanState = “infected”.

Также, если интерфейс выдаст значение «FALSE» («ЛОЖНО»), объект будет признан не содержащим вирус. Соответственно АВ статус для строки может быть обновлен как:

lastVirusSignatureScanTS =@@VIRUSSIGNATURETS and scanState = “clean”.

Обращаясь теперь к компоненту 220 синхронной очередизации (Сканирование в Доступе) в хранилище, подобный компонент может быть выполнен так, что когда бы ни выполнялось чтение Хранилища Элементов, обычно гарантировано, что результат будет обычно содержать только элементы, которые имеют scanState=”clean”(«чистый»). Таким образом, Синхронное АВ в пути считывания обычно позволяет гарантировать, что клиент сможет получать наиболее актуальные наборы результатов, пока при обработке запроса не будет обнаружен реальный вирус. Несмотря на это могут существовать сценарии, в которых за такую гарантию может быть заплачена высокая цена. Например, первый пользователь размещает множество новых фотографий в Домене Элементов, тогда как второй пользователь выполняет поиск Документов Word. Второго пользователя тогда могут попросить подождать, пока запрашивающая сторона не просканирует размещенные фотографии первого пользователя.

В то же время каждый раз, когда выполняют запрос, результаты могут быть неполными, если диапазон элементов, в отношении которых выполняют запрос, полностью не АВ сканирован. Соответственно настоящее изобретение вводит «принудительное» сканирование как часть компонента синхронной очередизации, основываясь на установке “переменной сеанса”, определяется способ, которым приложение должно себя вести. Приложение может либо полагаться на оптимистический подход и принять результат транзакции, даже несмотря на то что он неполный, поскольку АВ Подключаемая Программа не обращалась ко всему содержимому Хранилища 200 Элементов. Альтернативно, если Хранилище 200 Элементов обнаружит, что некоторые из элементов, которые могут потенциально внести вклад в результат запроса, не были сканированы, сканирование осуществляют побочно для обеспечения включения такого содержимого в результаты транзакции.

По существу, для управления тем, следует ли проверять элементы поточно или нет, вводят новую опцию @@VIRUSCHECKONREAD набора сеансового уровня. Когда такому полю присвоено значение «0», все считываемые запросы учитывают только строки с scanState = “clean” («чистый»). Подобным образом, когда присвоено значение «1», строки с scanState!= “clean” («чистый») сканируют при выполнении запроса принудительно.

Предикат затем может быть изменен для вычисления:

WHERE (lastSignatureScan = @@VIRUSSIGNATURETS

AND scanState = “clean”)

OR (@@VIRUSCHECKONREAD = 1 AND

lastSignatureScan! = @@VIRUSSIGNATURETS AND

ItemHasVirus (ItemId) = 0)).

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

В еще одном варианте настоящего изобретения компонент 230 планирования может планировать инфицированные Элементы для обработки посредством ИПП АВ Подключаемой Программы CleanItem. Такой вызов может быть выдан синхронно, и АВ метаданные могут быть обновлены в Хранилище 200 Элементов на основании Булевого результата этого вызова. Например, если интерфейс выдает значение «TRUE» («ИСТИННО»), объект был очищен. Затем АВ статус строки может быть обновлен на lastVirusSignatureScanTS = @@VIRUSSIGNATURETS, а значение для scanState = “clean” («чистый»). С другой стороны, если интерфейс выдает FALSE («ЛОЖНО»), объект обычно может быть неочищенным, а АВ статус для строки обновлен в lastVirusSignatureScanTS = @@VIRUSSIGNATURETS, и значение для scanState = “infected” («инфицирован»).

На Фиг.3 проиллюстрирована методология 300 для предварительного сканирования в соответствии с одним вариантом настоящего изобретения. Первоначально на 310 Хранилище Элементов завершает обновление компонента метаданных на основании результатов АВ Подключаемой Программы по содержимому Хранилища Элементов. Далее на 315 полную (по всему хранилищу) сигнатуру Хранилища Элементов обновляют с тем, чтобы отразить недавнее сканирование АВ Подключаемой Программой. Далее Хранилище Элементов может поместить окончившие функционирование элементы обратно в очередь на 320 для последующего АВ сканирования. Дополнительно недавние обновления могут также ожидать в такой приоритетной очереди. Как было детально раскрыто ранее, Элементы, упорядоченные в очередь, могут быть разупорядочены Хранилищем Элементов, и подходящий АВ интерфейс может быть синхронно вызван на 325. Методология затем замыкается обратно на этап 310, когда Хранилище Элементов завершает обновление компонента метаданных, основываясь на результатах АВ Подключаемой Программы. Хотя и приведенный в качестве примера способ проиллюстрирован и описан здесь в виде набора блоков, представляющего различные события и/или действия, настоящее изобретение не ограничено проиллюстрированным порядком таких блоков. Например, в соответствии с изобретением некоторые действия или события могут иметь место в различных порядках и/или одновременно с другими действиями и событиями, помимо порядка, проиллюстрированного здесь. Кроме того, для осуществления методологии в соответствии с настоящим изобретением могут потребоваться не все представленные блоки, события и действия. Более того, представляется очевидным, что приведенный в качестве примера способ и другие способы в соответствии с изобретением могут быть осуществлены совместно с проиллюстрированным и описанным здесь способом, а также и совместно с другими системами и устройствами, здесь не проиллюстрированными и не описанными.

Как представлено на Фиг.4a-4д, представленные в качестве иллюстрации строки, связанные с таблицами Хранилища Элементов, включают в себя два столбца для определения двух свойств, а именно «последнее Сканирование Сигнатуры Вируса» и «Состояние Сканирования». Вообще говоря, основной операционной чертой реляционного хранилища данных является способность осуществлять ассоциативные запросы по таблицам. К набору сущностей, хранимых в таблицах, можно осуществить доступ, используя язык обработки наборов (например, SQL (Язык Структурированных Запросов, Structured Query Language)). Язык описывает одну или несколько таблиц как источник данных и выводит только те строки (ту строку), если имеется, которые удовлетворяют заданному условию. Например, так же, как и описано ранее, Хранилище Элементов может быть реляционной базой данных, объектной базой данных и/или объектно-реляционной базой данных. В случае реляционных баз данных набор сущностей одной и той же структуры называют таблицей, а каждую сущность называют строкой. Компоненты структуры называют столбцами. Реляционная база данных может включать в себя одну таблицу или множество таблиц. Приведенное в качестве примера обновление сигнатуры таблицы на Фиг.4a-4д может быть подвергнуто сканированию на вирус в соответствии с вариантом настоящего изобретения. Очевидным является, что хранилище данных по настоящему изобретению предполагает существование данных в форме как общеизвестных потоков данных, так и реляционных объектов. Содержимое такой таблицы должно быть защищено от вирусной атаки, например, когда от него зависит результат запроса. В частности, когда коды злоумышленника могут воспользоваться закодированными строками, размещенными в хранилище, которые могут быть раскодированы в клиентском пространстве и распространяться по электронной почте. Например, вирус может хранить зашифрованное тело “X” в свойстве элемента, так что он может распространять себя посредством запроса к хранилищу и декодирования зашифрованного свойства на клиенте. При исполнении запроса хранилище данных по настоящему изобретению может использовать механизм очередизации для формирования очереди элементов в таблице в синхронном и/или асинхронном режиме как для сканирования, так и для очистки антивирусной Подключаемой Программой, предоставляемой поставщиками. После этого механизм реляционного Хранилища Элементов может обеспечить ответ на информацию запроса, основываясь на запросе и, значительно, пользовательской контекстной информации.

На Фиг.4a представлено создание строки, причем система автоматически устанавливает lastVirusSignatureScanTS = 0 и scanState = “suspect” («подозрительно»). Строка может сохранять эти значения до тех пор, пока АВ Подключаемая Программа просканирует строку, после чего она будет содержать временную отметку сканирования плюс результат сканирования, как представлено на Фиг.4б в виде статуса «clean» («чисто»). На Фиг.4в представлено обновление для строки, причем Хранилище Элементов автоматически установило scanState = “suspect” («подозрительно»), но не изменило значение lastVirusSignatureScanTS. Антивирусная Подключаемая Программа ответственна за сканирование строк Элемент, Связь или Расширение и указания, что либо каждый из Элементов не содержит вируса, либо он инфицирован. На Фиг.4г представлено чистое состояние, причем Хранилище Элементов устанавливает lastVirusSignatureScanTS на текущее значение @@VIRUSSIGNATURETS и свойство scanState на «clean» («чисто»). Подобным образом на Фиг.4д представлен альтернативный сценарий, в котором Элемент инфицирован. Как таковое, Хранилище Элементов устанавливает lastVirusSignatureScanTS в @@VIRUSSIGNATURETS со свойством scanState на «infected» («инфицировано»), что может вызвать помещение Элемента на «карантин». Соответственно такой элемент нуждается в дезинфицировании Подключаемой Программой перед тем, как его содержимое может стать доступным вновь для будущих запросов.

На Фиг.5 представлена структурная схема конкретной разделенной на слои (уровни) компоновки в соответствии с вариантом настоящего изобретения. Обычно Хранилище Элементов по настоящему изобретению предполагает существование данных в форме как общеизвестных потоков данных, так и реляционных объектов. Соответственно, а также и для того, чтобы обеспечить обратную совместимость Хранилища Элементов и его АВ Подключаемых программ с общепринятыми файлами (например, файлами потоков данных и приложений), настоящее изобретение применяет новую архитектуру для файлов фильтров, в которой компонент 515 Множественного Провайдера по Универсальному соглашению об Именовании (МУП, Multiple Universal Naming convention Provider (MUP)) регистрирует как файловая система, а УСИ провайдеры обычно нет. Вообще говоря, может быть гарантировано, что все ВВОДЫ/ВЫВОДЫ УСИ обычно будут проходить через МУП. Соответственно, как показано на Фиг.5, пакет фильтров файлов, например АВ фильтр и тому подобные, (510, 520, 530) может подключать себя к МУП (например, располагать себя слоем по МУП) и фильтровать все ВВОДЫ/ВЫВОДЫ УСИ, которые включают в себя ВВОД/ВЫВОД файлового потока элементов в Хранилище Элементов. Универсальное Соглашение об Именовании (УСИ, Universal Naming Convention (UNC)) позволяет использовать конвенцию об именовании для файлов, что обеспечивает машинно независимые средства для обнаружения файла. МУП компонент 515 функционирует как файловая система для доступа к пространству имен УСИ, причем то же пространство имен директорий и имен файлов, видимое Хранилищу Элементов, также видимо и АВ Подключаемой Программе.

Как показано, режим 550 Ядра может функционировать как ядро или сердцевина операционной системы компьютера. Такая операционная система обычно ответственна за обработку данных и управление вводом и выводом. Режим 550 Ядра как часть операционной системы загружается первым и остается в основной памяти. В дополнение к тому, что он является ответственным за управление обработкой, управление файлами и управление памятью, компонент 550 Ядра обычно обеспечивает существенные службы или процедуры, требуемые приложениями и драйверами. Например, процедуры могут относиться к планированию ВВОДА/ВЫВОДА, буферизации, использования вторичной памяти для буферизации, обработки ошибок и тому подобного. Более того, следует учесть, что используемый здесь термин «служба режима 550 Ядра» распространяется на любую службу, процедуру, драйвер, приложение или иной компонент, который может быть размещен в адресном пространстве Ядра.

В связанном варианте настоящего изобретения может быть обеспечен набор интерфейсов как часть взаимодействия АВ Подключаемой Программы, предоставляемой поставщиками, и механизма реляционного Хранилища Элементов. Такой интерфейс может, например, быть в виде набора программных заглушек и/или заполнителей для программ, которые могут быть разработаны поставщиками для связывания предоставляемой АВ Подключаемой Программы с реляционным Хранилищем Элементов. Такие интерфейсы могут применяться поставщиками для сканирования и очистки Элементов, Расширений и Связей. Например:

BOOL ScanItem (ItemId itemId)
BOOL ScanExtension (ItemId itemId, ExtensionId extId)
BOOL ScanLink (ItemId itemId, LinkId linkId)

Каждый интерфейс может выдавать Булево значение состояния. Такое значение может быть установлено в «true» («истинно»), если обнаружено, что элемент содержит вирус (или участвует в «кусочной» атаке), и установлено в «false» («ложно»), если элемент не содержит вирус. Аналогично примеры процедуры очистки могут включать в себя:

BOOL CleanItem (ItemId itemId)
BOOL CleanExtension (ItemId itemId, ExtensionId extId)
BOOL CleanLink (ItemId itemId, LinkId linkId)

Каждый интерфейс может выдать Булево значение состояния, которое может быть установ