Служба репутации контента на основе декларации
Иллюстрации
Показать всеИзобретение относится к области безопасности. Технический результат - эффективная защита контента. Серверная система, выполненная с возможностью обработки деклараций контента для элементов данных, в которой база данных может сохранять множество деклараций контента для ранее оцененных элементов данных, причем каждая декларация из множества деклараций контента является связываемой в базе данных с соответствующим сохраненным цифровым отпечатком ранее оцененного элемента данных. Один или несколько серверов могут быть сконфигурированы для приема определенного цифрового отпечатка элемента данных от клиентского устройства на другом сетевом узле, для подачи запроса к базе данных с использованием определенного цифрового отпечатка в качестве первичного ключа и для передачи одной или нескольких деклараций контента, возвращенных по запросу, на клиентское устройство. В некоторых вариантах осуществления сервер(ы) может быть дополнительно сконфигурирован для приема декларации(ий) контента и цифрового отпечатка, связанного с ней, от одного или нескольких компьютеров на другом сетевом узле, и для обеспечения сохранения принятой декларации(ий) контента и цифрового отпечатка, связанного с ней, в базе данных. 3 н. и 17 з.п. ф-лы, 7 ил., 2 табл.
Реферат
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Для того чтобы гарантировать, что цифровые данные соответствуют политикам бизнеса, обеспечения безопасности и другим политикам, тенденцией в последние годы было подвергать такие данные непрерывно увеличивающемуся числу процессов оценки перед осуществлением доступа. Примеры таких процессов включают в себя «санитарные» сканирования (на наличие вирусов), фильтрацию, классификации и анализ данных. В частности интенсивные в вычислительном отношении операции могут включать в себя, например, сканирования на наличие вируса/программы-шпиона, обнаружение спама, обнаружения ключевых слов, обнаружение вредоносных/ненадлежащих/запрещенных универсальных указателей информационных ресурсов (URL), предотвращение утечки данных, классификацию данных и т.д.
Число технологий сканирования/классификации, которым должна подвергаться порция контента, продолжало увеличиваться со временем. Кроме того, размер типичной порции контента, которая нуждается в сканировании, изменился в большую сторону и не показал признака стабилизации. Обе эти тенденции имеют результатом постоянно увеличивающийся объем ресурсов компьютера (центрального процесса (ЦП, CPU), памяти, полосы частот сети и т.д.), которые необходимы для выполнения сканирования/классификации.
Проблема дополнительно осложняется фактом, что данные обычно должны многократно повторно анализироваться, повторно сканироваться и/или повторно классифицироваться различными продуктами обеспечения безопасности и соответствия, если перемещаются внутри или по сетям компьютеров. Эти продукты обычно устанавливаются на настольных компьютерах, блокнотных компьютерах типа «ноутбук», различных серверах (подобных почтовому, файловому, обеспечения сотрудничества и т.д.) и службах в «облаке». Поскольку данные проходят каждую точку из этих точек маршрута, одинаковые, интенсивные в вычислительном отношении операции часто выполняются еще и еще раз. Это имеет следствием сниженные производительность и пропускную способность системы и требует установки дополнительных аппаратных средств, программного обеспечения и т.д. В отношении услуг, дополнительные издержки могут оказывать прямое влияние на рентабельность услуги.
КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
В некоторых вариантах осуществления изобретения система может содержать базу данных и один или несколько серверов. База данных может, например, сохранять множество деклараций контента для ранее оцененных элементов данных, причем каждая декларация из множества деклараций контента связывается в базе данных с соответствующим сохраненным цифровым «отпечатком» (идентификационной меткой) оцененного ранее элемента данных. Сервер(ы) может, например, конфигурироваться для приема определенного цифрового отпечатка элемента данных от клиентского устройства на другом сетевом узле, для подачи запроса к базе данных с использованием определенного цифрового отпечатка в качестве первичного ключа и для передачи одной или нескольких деклараций контента, возвращенных по запросу, на клиентское устройство.
В некоторых вариантах осуществления сервер(ы) может быть дополнительно сконфигурирован с возможностью принимать декларацию(и) контента и цифровой отпечаток, связанный с ней, от одного или нескольких компьютеров на другом сетевом узле и побуждать сохранение в базе данных принятой декларации(ий) контента и цифрового отпечатка, связанного с ней.
В некоторых вариантах осуществления клиентское устройство может содержать один или несколько компьютеров, сконфигурированных с возможностью обрабатывать элемент данных с помощью хеш-функции для определения цифрового отпечатка элемента данных, посылать на сервер(ы) первое сообщение, содержащее определенный цифровой отпечаток элемента данных, принимать от сервера(ов) второе сообщение, содержащее декларацию(и) контента, возвращенную по запросу, и принимать решение относительно того, каким образом далее обрабатывать элемент данных, на основании декларации(ий) контента, включенной во второе сообщение.
В некоторых вариантах осуществления способ идентификации одной или нескольких деклараций контента для элемента данных заключает в себе сравнение цифрового отпечатка элемента данных с сохраненным цифровым отпечатком, связанным с декларацией(ями) контента. Если определенный цифровой отпечаток совпадает с сохраненным цифровым отпечатком, то определяют, что одна или несколько деклараций контента связаны с определенным цифровым отпечатком элемента данных.
В некоторых вариантах осуществления один или несколько машиночитаемых носителей кодируются командами, которые при исполнении одним или несколькими процессорами на первом сетевом узле побуждают процессор(ы) выполнять способ идентификации одной или нескольких деклараций контента относительно элемента данных, который включает в себя этапы (a) сравнения определенного цифрового отпечатка элемента данных с сохраненным цифровым отпечатком, связанным с декларацией(ями) контента, и (b) если определенный цифровой отпечаток совпадает с сохраненным цифровым отпечатком, то определения того, что одна или несколько деклараций контента связаны с определенным цифровым отпечатком элемента данных.
В некоторых вариантах осуществления декларация(и) контента и цифровой отпечаток, связанный с ней, могут приниматься от одного или нескольких компьютеров на другом сетевом узле, и принятая декларация(и) контента и цифровой отпечаток, связанный с ней, могут быть хранимыми постоянно.
В некоторых вариантах осуществления определенный цифровой отпечаток может приниматься от одного или нескольких компьютеров в другом сетевом узле, и декларация(и) контента, определенная подлежащей связыванию с определенным цифровым отпечатком элемента данных, может передаваться на один или несколько компьютеров в другом сетевом узле.
В некоторых вариантах осуществления сертификат контента, включающий в себя и хранимый цифровой отпечаток, и декларацию(и) контента, может приниматься от одного или нескольких компьютеров в другом сетевом узле.
В дополнение к предшествующим иллюстративным вариантам осуществления или вместо них, одно или несколько из нижеследующих характеристик, признаков и/или функций могут быть дополнительно или альтернативно представлены или применены на практике согласно некоторым вариантам осуществления изобретения:
• Результаты «санитарии», фильтрации, классификации контента и других процессов анализа контента могут быть выражены в виде набора деклараций контента.
• формирование (цифровых) отпечатков может использоваться в качестве неагрессивного и надежного механизма для связывания деклараций контента с данными, которые были обработаны.
• Служба репутации контента может принять, агрегировать и сохранять декларации контента, поданные участвующими доверенными сторонами.
• Служба репутации контента может запрашиваться относительно деклараций, связанных с конкретной порцией данных.
• Существующие декларации контента могут объявляться недействительными, если изменяется конфигурация и/или политика безопасности, которая использовалась при выдаче этих деклараций.
• Чувствительные ко времени декларации могут быть аннулированы и удалены из базы данных службы репутации при истечении заранее заданного периода времени.
• Служба репутации контента может быть независимой от форматов данных, являющихся защищаемыми. Например, когда вычисляется цифровой отпечаток, данные можно интерпретировать просто как поток байтов, а не как данные конкретного формата, так что сведения о форматах данных системе не требуются.
• Служба репутации контента может быть независимой от транспортных протоколов, используемых для переноса данных.
• Служба репутации контента может быть независимой от типа хранилища, где хранятся данные.
• Со службой репутации контента можно осуществлять связь (с целью подачи и запроса деклараций), используя различные сетевые протоколы.
• Использование службы репутации контента может обеспечить, что декларации, которые были созданы для файла (или другого цифрового контента), будут связываться со всеми другими копиями того же файла.
• Экспортирование набора деклараций контента и запись его состояния (сериализация) в защищенный и верифицируемый "сертификат контента" могут позволять его передачу заинтересованным сторонам, которые по некоторым причинам не могут осуществлять связь непосредственно со службой репутации (или вовсе не осведомлены о ней). Система может, например, использовать в качестве средства известные и принятые, основанные на стандартах технологии, чтобы форматировать и защищать такой сертификат контента. Клиентское приложение может, например, быть способным связывать сертификат контента с данными, для которых он был выдан, а также считывать одну или несколько деклараций относительно таких данных.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Не подразумевается, что сопроводительные чертежи вычерчены в масштабе. На чертежах каждый идентичный или почти идентичный компонент, который иллюстрируется на различных фигурах, представлен сходной числовой позицией. В целях ясности не каждый компонент может помечаться позицией на каждом чертеже.
На чертежах:
Фиг.1 - схема, показывающая иллюстративный пример сети, в которой различные клиенты могут осуществлять доступ к службе репутации контента;
Фиг.2 - иллюстративный пример процедуры, которую клиент может исполнять, чтобы подать одну или несколько деклараций на службу репутации контента;
Фиг.3 - иллюстративный пример процедуры, которую клиент может исполнять для приема одной или нескольких существующих деклараций, сохраняемых службой репутации контента;
Фиг.4 - концептуальное представление набора деклараций, включая фактические данные декларации для изображения;
Фиг.5 - иллюстративный пример процедуры, которая может исполняться сервером службы репутации контента, чтобы обрабатывать клиентский запрос на подачу декларации;
Фиг.6 - иллюстративный пример процедуры, которую сервер службы репутации контента может исполнять, чтобы обрабатывать клиентский запрос для извлечения и возврата декларации контента; и
Фиг.7 - иллюстративный пример того, как может выглядеть набор деклараций, показанный на Фиг.4, если экспортируется в качестве сертификата контента.
ПОДРОБНОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
Авторы установили, что выполняемое существующими системами избыточное сканирование имеет место, поскольку прикладная программа или служба, исполняющаяся на одном компьютере, неспособна использовать результаты, которые создавались другими приложениями (исполняющимися на том же компьютере или на одном или нескольких различных компьютерах) над тем же контентом. Антивирусные приложения являются хорошим примером. В существующих системах файл (и возможно его идентичные копии), перемещающийся внутри организации, обычно должен многократно сканироваться, если он перемещается между различными компьютерами и серверами (электронной почты, файловым, обеспечения сотрудничества и т.д.). Заявители дополнительно установили, что такие повторные сканирования и классификация могут избегаться, например, путем обеспечения защищенного способа совместного использования результатов предшествующих сканирований и классификаций со всеми экземплярами того же приложения или службы и других заинтересованных сторон, которые могут использовать эти результаты.
В некоторых вариантах осуществления настоящего изобретения результаты сканирований, классификаций или любых других операций, выполняемых над цифровым контентом, могут сохраняться в виде набора деклараций контента в централизованном репозитории (хранилище), являющемся доступным заинтересованным сторонам, таким образом, что декларации связываются с данными, по которым они формировались. В некоторых вариантах осуществления, например, это может выполняться благодаря использованию централизованной службы репутации контента, которая является доступной по сети. Такой механизм может позволять, что будущие повторные сканирования и/или повторные классификации неизмененных (или дублированных) данных избегаются полностью или, по меньшей мере, частично. В некоторых вариантах осуществления результаты (наборы деклараций) могут храниться отдельно от данных, к которым относится декларация, и процесс не потребует каких-либо модификаций для самих данных. Такое решение может таким образом обеспечить целостность и аутентичность любых выданных деклараций.
В некоторых вариантах осуществления результаты для различных типов контента на основании технологий «санитарии» и/или фильтрации, которые выполняются в течение анализа/контроля/сканирования контента, могут быть сделаны доступными в виде набора деклараций контента. Доверенные службы и приложения могут, например, подавать результаты своих операций на службу репутации контента для хранения наряду с идентификатором, который может использоваться впоследствии для доступа к таким результатом. В некоторых вариантах осуществления, например, цифровой отпечаток для оцененного контента может использоваться в качестве такового идентификатора. Любая участвующая сторона может после этого запросить существующие декларации для заданной порции цифрового контента путем вычисления цифрового отпечатка рассматриваемых данных (или иного определения идентификатора) и посылки его в виде части запроса на службу репутации контента. Служба репутации контента может затем возвратить декларации (если имеются), связанные с данными, на запрашивающий узел. Служба репутации контента может, например, сохранять декларации в реляционной базе данных, которая использует идентификатор в качестве ключа.
Подобный способ может таким образом позволять, чтобы декларации контента повторно использовались в будущее время для различного назначения. Одно такое назначение может состоять в возможности избегать повторный анализ/контроль/сканирование данных, когда они не изменяются, если они проходят компьютеры в сети. Другое такое назначение может состоять в предоставлении возможности потребителям данных для принятия верифицируемых доверительных решений, используя набор деклараций контента. Еще одно назначение может состоять в уменьшении потребления ресурсов компьютера, используемых для «санитарии», фильтрации, классификации и других проверок контента по сети. Кроме того, в некоторых вариантах осуществления, анализ деклараций контента, находящихся в базе данных службы репутации контента, может предоставить приемлемую статистическую информацию в отношении использования данных, географической миграции данных, источников инфекции и т.д.
На фиг.1 показан иллюстративный вариант осуществления системы 100, в которой на службу 102 репутации контента можно осуществлять доступ по сети 104. Как показано, служба 102 репутации контента может, например, содержать один или несколько серверов 106 (или другие вычислительные устройства) с наличием достаточных вычислительных возможностей для обработки запросов от всех из остальных устройств в системе 100, которым необходимо осуществлять доступ к службе 102. Вычислительные устройства службы 102 репутации контента могут принимать любую форму из многочисленных форм, в зависимости от операционных требований и масштаба системы 100, в которой она развернута, и изобретение не требует использования вычислительных устройств какого-либо конкретного типа или конфигурации. Для крупномасштабных реализаций могут, например, использоваться традиционные способы масштабирования и/или балансировки загрузки, чтобы распределять обработку запросов между различными серверами и/или другими вычислительными ресурсами, развернутыми в рамках службы 102.
База данных 108 может иметь любую форму из многочисленных форм и конфигураций, и изобретение не ограничивается использованием какого-либо конкретного типа базы данных. В некоторых вариантах осуществления, например, база данных 108 может быть реляционной базой данных, которая хранит и осуществляет доступ к одной или нескольким декларациям контента, связанным с конкретными порциями цифрового контента, используя ключи. В некоторых вариантах осуществления такие ключи могут, например, содержать цифровые отпечатки для цифрового контента, для которого служба поддерживает одну или несколько деклараций контента. В зависимости от соображений рабочей характеристики и размера базы данных могут использоваться различные таблицы и внешние ключи, чтобы улучшить рабочие характеристики. Например, в некоторых вариантах осуществления, таблица может отображать цифровые отпечатки на внутренние ключи идентификационных атрибутов, и каждый такой внутренний ключ идентификационных атрибутов может использоваться для осуществления доступа к одной или нескольким декларациям контента, связанным с ним. Следует оценить, однако, что в других вариантах осуществления база данных 108 может содержать любую другую архитектуру базы данных или механизм хранения данных, способный связывать идентификаторы (например, цифровые отпечатки) с соответствующими хранимыми декларациями. В некоторых вариантах осуществления декларации контента могут даже сохраняться в адресно-индексированном устройстве хранения, например накопителе на жестком диске или оперативном запоминающем устройстве (ОЗУ, RAM), и может использоваться таблица для отображения цифровых отпечатков (или прочего другого идентификатора) на адреса в памяти для соответствующих деклараций контента. Как используется в документе, термин "база данных" предназначен охватывать все такие архитектуры хранения.
Сеть 104 может быть любой из многочисленных сетей или группами сетей и изобретение не ограничивается использованием сети какого-либо конкретного типа конфигурации. Сеть 104 может, например, содержать локальную сеть, такую как используется в корпоративной среде, и/или глобальную сеть, такую как сеть Интернет. Любая архитектура сети и/или протокол связи могут использоваться в различных вариантах осуществления. Лишь несколько примеров подходящих сетей и протоколов включают в себя стандарт Ethernet, «маркерное кольцо», протокол управления передачей/Интернет-протокол (TCP/IP), протокол передачи гипертекста (HTTP), простой протокол доступа к объектам (SOAP), архитектуру передачи представительного состояния (REST), удаленный вызов процедуры (RPC), (стандарт расширяемого языка разметки) XML-RPC и т.д.
Как показано на фиг.1, в дополнение к самой службе 102 репутации контента, система 100 может дополнительно содержать различные клиенты, которые могут осуществлять связь со службой 102 по сети 104. Иллюстрируются несколько примеров вычислительных устройств, которые могут быть клиентами службы (например, поскольку они способны подавать декларации контента на службу 102 и/или способны осуществлять доступ к декларациям, поддерживаемым службой). Следует оценить, однако, что могут использоваться типы устройств в дополнение к показанным или вместо них, и изобретение не ограничивается использованием какого-либо конкретного типа устройства. В примере по фиг.1 иллюстрируемые клиенты включают в себя портативный компьютер 110, принтер/факс/сканер 112, сервер 114, настольный компьютер 116 и переносное вычислительное устройство (например, персональный цифровой ассистент (PDA), смартфон и т.д.) 118.
Как используется в настоящем документе, "сетевой узел" относится к устройству или группе устройств, которые имеют или совместно используют уникальный адрес, или компонент адреса, в сети. При некоторых обстоятельствах данный сетевой узел может содержать один или несколько подузлов. В таком случае один компонент сетевого адреса может однозначно идентифицировать узел в сети, а другой компонент адреса может однозначно идентифицировать каждый из подузлов. В примере по фиг.1 каждая единица из службы 102 репутации контента, портативного компьютера 110, принтера/факса/сканера 112, сервера 114, настольного компьютера 116 и переносного вычислительного устройства 118 может находиться в другом узле сети 104.
В некоторых вариантах осуществления служба 102 репутации контента может, например, принять, агрегировать, сохранить и предоставить по запросу декларации о цифровом контенте (файлах или любом другом типе данных). Кроме того, в некоторых вариантах осуществления, могут предприниматься шаги для обеспечения, что только доверенным сторонам позволяется подавать декларации на службу 102. В таких вариантах осуществления декларации, поданные от неизвестных или недоверенных клиентов, не будут приняты. В некоторых вариантах осуществления не имеется ограничений относительно того, каким клиентам разрешается просматривать существующие декларации.
Как отмечено выше, в некоторых вариантах осуществления декларации могут связываться с данными с помощью цифровых отпечатков. Вычисление цифрового отпечатка может выполняться любым из многочисленных способов, и изобретение не ограничивается каким-либо конкретным способом формирования отпечатков. В некоторых вариантах осуществления, например, цифровые отпечатки могут вычисляться с использованием криптографической хэш-функции. Такая реализация может обеспечить хорошее единообразие результирующих цифровых отпечатков и, в зависимости от используемой хэш-функции, может существенно минимизировать возможность коллизий (либо случайных, либо намеренных). Поскольку криптографическая хэш-функция является односторонней, является невозможным вывести исходный контент (или даже его характер) исходя из значения хэш-функции. Примерами подходящих хэш-функций являются функции по стандартному алгоритму шифрования методом хэширования SHA-1, SHA-256, и SHA-512. Следует оценить, однако, что другие способы формирования отпечатков могут дополнительно или альтернативно использоваться в некоторых вариантах осуществления. Например, для приложений, где безопасность данных не является предметом рассмотрения, может дополнительно или альтернативно использоваться некриптографическая хэш-функция.
Цифровые отпечатки могут в целом надежно определяться с минимальным вычислительным усилием, и одинаковая порция данных будет всегда выдавать одинаковый цифровой отпечаток. Соответственно, в вариантах осуществления, которые используют цифровые отпечатки в качестве идентификаторов деклараций, любая модификация по отношению к данным будет иметь результатом другой цифровой отпечаток и автоматически разорвет связь всех существующих деклараций с модифицированной копией файла.
На фиг.2 и 3 показаны примеры, каким образом клиенты могут использовать цифровые отпечатки при взаимодействии со службой 102 репутации контента. В частности, на фиг.2 показан иллюстративный пример процедуры, которую клиент (например, одно из вычислительных устройств 110, 112, 114, 116 и 118, показанных на фиг.1) может исполнять, чтобы подать одну или несколько деклараций на службу 102 репутации контента, и на фиг.3 показан пример процедуры, которую клиент может исполнять для приема одной или нескольких существующих деклараций, поддерживаемых службой 102. Иллюстрируемые процедуры, например, могут быть реализованы с использованием команд, хранимых в читаемом компьютером носителе, к которым процессор клиентской машины может осуществлять доступ и исполнять их.
Как показано на фиг.2, после обработки данных (например, выполнения сканирования на наличие вируса или вредоносного программного обеспечения, классификации данных и т.д.) (этап 202) клиент может создать одну декларацию или несколько деклараций, выражающих результаты обработки, которая была непосредственно выполнена (этап 204). После создания одной или нескольких деклараций клиент может вычислить цифровой отпечаток для данных (этап 206) и затем подать одну или несколько деклараций вместе с вычисленным цифровым отпечатком данных на службу 102 репутации контента, например, путем посылки сообщения на службу 102 через сеть 104 (этап 208). Как обсуждено дополнительно ниже, в некоторых вариантах осуществления такое сообщение может включать в себя цифровой сертификат клиентской стороны, подписанный доверенным центром сертификации (Certification Authority), идентифицирующий продукт, используемый для создания одной или нескольких деклараций. Такой способ может, например, помочь предотвращению потенциальных атак, намеренных испортить базу данных 108.
Как показано на фиг.3, прежде чем передать ресурсы на оценивание контента конкретной порции данных (например, путем выполнения сканирования на наличие вируса или вредоносного программного обеспечения, классификации данных и т.д.), клиент может вычислить цифровой отпечаток для данных (этап 302) и подать цифровой отпечаток на службу 102 репутации контента в виде части запроса существующих деклараций (этап 304). Если служба репутации 102 идентифицирует какие-либо декларации, связанные с поданным цифровым отпечатком, она может извлечь и возвратить эти декларации на клиент (этап 306). Клиент может затем принять дальнейшее решение относительно того, оценивать ли данные и/или каким образом оценивать, на основании информации, содержащейся в любой из возвращенных деклараций (этап 308). В некоторых вариантах осуществления сообщения, принятые службой 102 репутации контента, могут нести действительный, верифицируемый сертификат, таким образом позволяя клиентам подтвердить, что они осуществляют связь с доверенным источником. Кроме того, в некоторых вариантах осуществления возвращенные декларации также могут быть подписаны в цифровой форме, чтобы дополнительно повысить безопасность и надежность системы.
В некоторых вариантах осуществления неограниченное число деклараций контента может связываться с данной порцией данных. Хотя такие декларации могут создаваться различными доверенными издателями, в случае, если они выданы по той же порции данных (каковое дает такое же значение цифрового отпечатка), они все могут быть сгруппированы согласно цифровому отпечатку.
В некоторых реализациях, когда клиент выполняет запрос на службу 102 репутации контента, чтобы возвратить декларации о цифровом контенте, клиент может либо запросить все существующие декларации, либо сузить объем возвращаемого набора путем указания типа деклараций, которыми он интересуется (например, издатель, время, в которое декларации были выданы, утверждения контента и т.д.).
Как отмечено выше, в некоторых реализациях, любая модификация данных приведет к другому вычисленному цифровому отпечатку. Таким образом, любая модификация файла будет автоматически разрывать связь файла со всеми ранее выданными декларациями.
В Таблице 1 (ниже) показан иллюстративный пример характеристик/атрибутов, которые могут содержаться в одиночной декларации контента.
ТАБЛИЦА 1 | |
Свойство | Описание |
Claim Type (Тип декларации) | Тип декларации. Может иметься ряд заранее заданных типов деклараций контента. Потребители службы репутации контента также могут определять свои собственные типы декларации. |
Claim Time(Время декларации) | Дата и время, когда декларация была выдана. |
Assertion (Утверждение) | Утверждение относительно контента. Смысл утверждения может интерпретироваться в соответствии с типом декларации. Например, если типом декларации является "Вирус" и утверждением является "PropertyAbsent", то может интерпретироваться означающим, что контент без вирусов. Аналогично, тип декларации "MaliciousURL" вместе с утверждением "PropertyPresent" может интерпретироваться означающим, что контент содержит вредоносный URL. В дополнение к заранее заданным утверждениям, издатели деклараций могут задать свои собственные утверждения. |
Issuer(Издатель) | Объект, который выпустил эту декларацию. Это может, например, идентифицировать конкретное приложение, службу, пользователя и т.д. |
Data(Данные) | Необязательные специальные данные, которые издатель может присоединить к декларации. Служба репутации не должна пытаться интерпретировать эти данные; она может просто сохранять их и возвращать их назад с декларацией, если запрошены. Например, антивирусное приложение может подавать версию средства обработки вирусов или подписи вместе с каждой декларацией вируса, которую он делает. Таким образом, когда он принимает декларации обратно, он может определить, что процессор вирусов или подписи были обновлены после того, как декларация, которую он только что принял, была выдана. Он таким образом может принять решение сканировать файл в любом случае, несмотря на существующую декларацию, что файл является чистым, и затем подать новую декларацию. |
Как указано ранее, в некоторых вариантах осуществления, множественные декларации, потенциально выданные различными объектами, могут существовать в базе данных 108 службы 102 репутации контента. Если запрошены, такие декларации могут быть возвращены в виде "набора деклараций".
В Таблице 2 (ниже) показан иллюстративный пример того, каким образом такой набор деклараций может быть форматирован.
ТАБЛИЦА 2 | |
Набор деклараций | |
Алгоритм формирования отпечатков | |
Значение цифрового отпечатка | |
Декларация 1 | |
Декларация 2 | |
Декларация... | |
Декларация N |
Фиг.4 является концептуальным представлением набора деклараций, включающим фактические данные декларации (в этом случае, для изображения).
В некоторых вариантах осуществления различные наборы деклараций могут быть возвращены в различных форматах в зависимости от протокола, используемого для осуществления связи со службой 102 репутации контента. Клиенты могут, например, осуществлять связь со службой, используя сообщения SOAP (веб-услуга) или любого другого сетевого протокола, который поддерживает защиту на основании либо соединения, либо передачи пакетов/сообщений (например, REST, HTTP, RPC, XML-PRC и т.д.). В некоторых вариантах осуществления реализация службы может также поддерживать множественные привязки и/или быть в состоянии осуществлять связь, используя различные протоколы одновременно. Служба репутации контента может быть установлена в помещениях, в облаке или и там, и там.
Как отмечено выше, в некоторых вариантах осуществления, чтобы предотвращать порчу базы данных и другие типы атак, только доверенным приложениям можно позволять подавать декларации контента. Доверительный механизм может, например, использовать широко используемые промышленные стандарты, такие как WS-Trust и сертификаты стороны клиента и сервера для такой цели.
В некоторых вариантах осуществления, независимо от протокола, используемого для осуществления связи со службой 102 репутации контента, все декларации контента могут храниться в централизованной реляционной базе данных 108 с цифровым отпечатком, используемым в качестве первичного ключа.
На фиг.5 и 6 показаны примеры того, каким образом служба 102 репутации контента может обрабатывать принятые запросы от клиентов, чтобы подавать и извлекать декларации контента. В частности на фиг.5 показан иллюстративный пример процедуры, которую один или несколько серверов 106 службы 102 репутации контента могут исполнять, вместе с базой данных 108, чтобы обрабатывать клиентский запрос для подачи одной или нескольких деклараций, и на фиг.6 показан пример процедуры, которую такой сервер(ы) может исполнять, вместе с базой данных, чтобы обрабатывать клиентский запрос для извлечения и возврата одной или нескольких деклараций контента. Иллюстрируемые процедуры могут, например, реализовываться, используя команды, сохраненные в одном или нескольких читаемых компьютером носителях, к которым может осуществлять доступ и которые может исполнять один или несколько процессоров сервера(ов) 106 и/или контроллеров базы данных 108.
Как показано на фиг.5, приняв запрос клиента для подачи одной или нескольких деклараций на службу 102 (этап 502), если та же декларация (например, тот же тип декларации и утверждения) еще не существуют в базе данных 108 (см. этап 503), сервер 106 может форматировать принятую декларацию(и) и записать ее(их) в базу данных 108, используя принятый цифровой отпечаток в качестве первичного ключа для элемента базы данных (этап 504). Как отмечено выше, в некоторых вариантах осуществления сервер(ы) 106 может отказаться принять какие-либо новые подачи деклараций, которые не подписаны доверенным центром сертификации, или не идентифицирует продукт, используемый, для создания декларации.
В некоторых вариантах осуществления, если установлено, что такая же декларация уже существует в базе данных 108 для поданного цифрового отпечатка (см. этап 503), служба 102 репутации контента может оценивать контент новой декларации по отношению к таковой, существующей декларации и обновлять некоторую или всю информацию в декларации на основании этой оценки (этап 505).
Одним примером сценария, в котором служба 102 репутации контента может обновлять информацию для существующей декларации, является тот, где, например, недавно поданная декларация содержит версию подписи вируса, которая является более новой, чем версия подписи вируса существующей декларации, связанной с тем же цифровым отпечатком. Такой сценарий может иметь место, например, когда клиент принимает решение сканировать файл, несмотря на наличие существующей декларации для файла, поскольку клиент обладает более новой версией подписи вируса, чем та, которая отражена в существующей декларации. После выполнения сканирования с использованием обновленной версии подписи вируса клиент в таком сценарии может, например, подать декларацию вируса (отражающую версию подписи вируса, которая использовалась для сканирования) на службу 102 репутации контента.
При приеме службой 102 репутации контента такой декларации, она может, например, определить, что декларация того же типа, с тем же утверждением (и возможно даже от того же издателя) уже существует. Служба 102 репутации контента может затем, например, сравнить версии подписи вируса, а также даты и времена создания соответственных деклараций и обновить элементы в базе данных 108 (например, столбцы базы данных) тем, что она определяет являющимся самой актуальной и достоверной информацией для декларации. В случае обновленной версии подписи вируса обновленные элементы для существующей декларации могут, например, включать в себя дату и время сканирования вируса и версии подписи вируса, используемой при сканировании.
Как показано на фиг.6, приняв запрос клиента, извлечь существующие декларации (этап 602), сервер 106 может сформулировать запрос базы данных, используя цифровой отпечаток, включенный в клиентский запрос, в качестве первичного ключа (этап 604). Если совпадающий цифровой отпечаток существует в базе данных 108 (этап 606), сервер 106 может извлечь декларацию(и), связанную с цифровым отпечатком (этап 608), отфильтровать эти декларации согласно любому критерию, указанному клиентом (этап 609), и осуществить возврат данных отфильтрованных деклараций (которые могут быть либо подмножеством данных извлеченных деклараций, либо всем набором деклараций, если фильтрация не используется, или если какие-либо критерии фильтрации клиент не определил) на запрашивающий клиент (этап 610). Если соответствующий цифровой отпечаток не существует в базе данных (этап 606), сервер 106 может информировать клиент, что не были найдены соответствующие декларации (этап 612). Служба 102 репутации контента может таким образом идентифицировать любые декларации, которые связаны с данной порцией данных, путем сравнения вычисленного цифрового отпечатка данных (принятого от клиента) с цифровым отпечатком, сохраненным в базе данных, который связан с декларациями, для рассматриваемых данных.
Практически, декларации контента могут создаваться, когда данные подвергаются некоторому типу анализа впервые в рамках системы 100. После этого, поскольку данные перемещаются внутри системы и к ним необходимо осуществлять доступ, ранее выданные декларации могут использоваться для получения необходимо