Основанные на репутации решения по авторизации

Основанные на репутации решения по авторизации

Иллюстрации

Показать все

Реферат

Уровень техники

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

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

Сущность изобретения

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

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

Краткое описание чертежей

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

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

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

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

Фиг.5 иллюстрирует примерный модуль авторизации, выполненный с возможностью принимать запрос и ввод авторизации и выводить решение об авторизации.

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

Подробное описание изобретения

Обзор

Следующий документ описывает инструментальные средства, имеющие вышеупомянутые возможности и допускающие формирование значения репутации актора, формирование ввода авторизации, по меньшей мере, частично на основе значения репутации, сравнение ввода авторизации с политикой авторизации и принятие решений об авторизации на основе сравнения. Два примерных окружения, в которых инструментальные средства могут активировать эти и другие действия, излагаются ниже в разделе, озаглавленном "Примерные операционные окружения". Далее идет раздел, озаглавленный "Компоновщик значений репутации", который описывает один примерный способ, которым инструментальные средства могут действовать для того, чтобы создавать значение репутации актора из метаданных репутации. Четвертый раздел, озаглавленный "Компоновщик вводов авторизации", описывает как инструментальные средства могут работать, чтобы формировать ввод авторизации из значения репутации актора. Пятый раздел, озаглавленный "Модуль авторизации", поясняет способы, которыми инструментальные средства могут действовать для того, чтобы принимать решения об авторизации на основе ввода авторизации, указывающего значение репутации актора. Заключительный раздел, озаглавленный "Примерная реализация", описывает один неограничивающий способ, которым заявленные инструментальные средства могут совместно работать. Этот краткий обзор, включая данные заголовки разделов и резюме, предоставляется для удобства читателя и не имеет намерение ограничивать объем формулы изобретения или озаглавленных разделов.

Примерные операционные окружения

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

Фиг.1, в общем, иллюстрирует одно такое операционное окружение как 100, в котором пользователь 102 может оперировать клиентским устройством 104. Клиентское устройство 104, в общем, является вычислительным устройством, таким как персональный компьютер, и может включать в себя локального поставщика 106 услуг. Локальный поставщик 106 услуг может являться неотъемлемой частью, быть доступным посредством или являться отдельным от клиентского устройства 104. В некоторых случаях локальный поставщик 106 услуг может содержать накопитель на дисках, накопитель флэш-памяти, ZIP-накопитель или любое другое устройство, допускающее подключение к машиночитаемым носителям. Например, локальный поставщик 106 услуг может содержать накопитель CD/DVD, в который машиночитаемый носитель, включающий в себя приложение, может быть вставлен и выполнен.

Клиентское устройство 104 может подключаться через сеть 108 к удаленному поставщику 110 услуг. Удаленный поставщик 110 услуг может содержать сервер и т.п., с которого пользователь и клиентское устройство могут загружать приложение, программу или другой актор, допускающий запрос на операцию. Клиентское устройство также может подключаться через сеть к компоновщику 112 значений репутации. Как описано подробно ниже, компоновщик значений репутации может формировать значение 114 репутации, подходящее для использования при принятии решения по авторизации.

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

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

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

В примерном окружении 100 пользователь может желать предоставлять актору возможность выполняться на клиентском устройстве 104. Этот актор может быть запущен из локального поставщика 106 услуг или из удаленного поставщика 110 услуг. В первом случае актор может осуществлять локальный запрос 120, чтобы выполнять некоторую операцию с объектом клиентского устройства 104. Этот объект может содержать файл, документ, изображение или любые другие данные, находящиеся или доступные посредством клиентского устройства. Например, актор может запрашивать через локальный запрос 120, чтобы считывать, записывать или открывать файл, находящийся на клиентском устройстве 104. Аналогично, когда приложение и т.п. запущено из удаленного поставщика 110 услуг, актор может осуществлять удаленный запрос 122, чтобы выполнять некоторую операцию с некоторым объектом, находящимся или доступным посредством клиентского устройства. Как пояснено подробно ниже, клиентское устройство может сначала стремиться верифицировать репутацию актора до предоставления или запрета на разрешение актору выполнять запрошенную операцию.

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

Модуль 128 управления доступом может включать в себя компоновщик 130 вводов авторизации и модуль 132 авторизации. Компоновщик 130 вводов авторизации может служить для того, чтобы принимать значения 114 репутации, а также другие компоненты, поясненные ниже, и создавать ввод авторизации для использования при принятии решений об авторизации. Модуль 132 авторизации, между тем, может включать в себя модуль 134 правил. Модуль 134 правил может реализовывать локальные или удаленные правила или компоненты политики авторизации для использования при решении, следует ли предоставлять доступ акторам, добивающимся разрешения. Модуль 132 авторизации может принимать ввод авторизации от компоновщика 130 вводов авторизации и сравнивать ввод авторизации с одним или более правилами в модуле правил. В зависимости от значения ввода авторизации, а также конфигурации модуля правил модуль авторизации может разрешать или запрещать запрос актора на то, чтобы выполнять конкретную операцию для конкретного запрашиваемого объекта. Другие результаты также могут иметь место, например предложение посредством модуля 128 управления доступом пользователю определять, следует ли давать возможность запрошенной операции осуществляться. Кроме того, хотя модуль управления доступом показан как часть клиентского устройства, он также может находиться удаленно, возможно, составляя часть компоновщика 112 значений репутации.

Как проиллюстрировано на фиг.1 и пояснено выше, актор может осуществлять либо локальный или удаленный запрос, чтобы выполнять некоторую операцию с объектом. В ответ клиентское устройство 104 может запрашивать, и компоновщик 112 значений репутации может предоставлять значение 114 репутации, служащее признаком репутации актора. Это значение репутации затем может быть предоставлено в модуль управления доступом и, возможно, компоновщик 130 вводов авторизации. В этих вариантах осуществления компоновщик вводов авторизации затем может использовать это значение, а также другие компоненты, поясненные ниже, чтобы формировать ввод авторизации, служащий признаком репутации актора. Ввод авторизации затем может быть предоставлен в модуль авторизации, который может сравнивать ввод авторизации с правилами в модуле 134 правил. Модуль 132 авторизации затем может выводить решение о доступе или авторизации относительно того, следует ли предоставлять доступ актору или следует ли возможность пользователю 102 решать. В вариантах осуществления, где модуль управления доступом содержит часть компоновщика 112 значений репутации, компоновщик значений репутации сам может просто предоставлять решение о доступе или авторизации в клиентское устройство.

Фиг.2, в общем, иллюстрирует другое операционное окружение как 200, в котором заявленные инструментальные средства также могут работать. Фиг.2 содержит многие из тех же элементов, что проиллюстрированы и описаны со ссылкой на фиг.1. В окружении 200, тем не менее, поставщик 202 репутации может замещать компоновщик 112 значений репутации из окружения 100. Аналогично компоновщику 112 значений репутации поставщик 202 репутации может принимать метаданные 116 репутации от поставщиков 118 метаданных репутации. Здесь, тем не менее, поставщик 202 репутации также может выводить метаданные 116 репутации, возможно, в ответ на запрос от клиентского устройства 104. С другой стороны, хотя один поставщик репутации показан, несколько поставщиков репутации могут существовать и использоваться при принятии решений об авторизации.

Как проиллюстрировано, клиентское устройство 104 может включать в себя один или более машиночитаемых носителей 204, которые могут включать в себя модуль 206 управления доступом. Аналогично модулю 128 управления доступом модуль 206 управления доступом может включать в себя компоновщик 130 вводов авторизации, модуль 132 авторизации и модуль 134 правил. Модуль 206 управления доступом, тем не менее, дополнительно может включать в себя компоновщик 208 значений репутации. Компоновщик 208 значений репутации может функционировать способом, аналогичным компоновщику 112 значений репутации. Таким образом, компоновщик значений репутации может принимать метаданные 116 репутации и создавать и выводить значение репутации.

Следовательно, в этих вариантах осуществления актор, такой как приложение, может запрашивать, чтобы выполнять некоторую операцию с объектом, находящимся или доступным посредством клиентского устройства 104. В ответ метаданные 116 репутации, компилированные посредством поставщика 202 репутации, могут быть предоставлены в клиентское устройство. Более конкретно, метаданные 116 репутации могут быть предоставлены в компоновщик 208 значений репутации, который может выводить значение репутации в компоновщик 130 вводов авторизации. Как пояснено выше, компоновщик 130 вводов авторизации может принимать это значение репутации и создавать ввод авторизации. Ввод затем может быть предоставлен в модуль 132 авторизации, который может сравнивать ввод с одним или более правилами или компонентов политики в модуле 134 правил. Модуль 132 авторизации затем может выводить решение о доступе или авторизации, как пояснено подробно ниже.

Компоновщик значений репутации

Фиг.3 иллюстрирует вычислительное устройство 300, включающее в себя один или более машиночитаемых носителей 302, которые могут соединяться с компоновщиком 304 значений репутации. Компоновщик значений репутации может являться неотъемлемой частью, быть доступным посредством или являться отдельным от машиночитаемых носителей. Компоновщик значений репутации может функционировать многими из способов, поясненных выше в отношении компоновщиков 112 и/или 208 значений репутации. Кроме того, хотя фиг.1 и 2 иллюстрируют, что метаданные 116 репутации предоставляются удаленно, метаданные репутации также могут быть предоставлены локально в клиентском устройстве 104.

Как проиллюстрировано на фиг.3, компоновщик 304 значений репутации может принимать метаданные 116 репутации. Как пояснено выше в отношении компоновщиков 112 и 208 значений репутации, компоновщик 304 значений репутации может создавать и выводить значение 114 репутации, которое служит признаком репутации актора. С другой стороны, метаданные 116 репутации могут исходить из одного или более поставщиков 118 метаданных репутации и т.п. Поставщики метаданных репутации могут быть членами онлайнового сообщества или могут быть программой из состава пакета программного обеспечения, допускающей отслеживание репутаций акторов через независимое рецензирование и анализ продукта и операции с компьютерным субъектом. Поставщик 118 метаданных репутации также может содержать подписную программу, на которую пользователи должны подписываться для того, чтобы принимать метаданные 116 репутации или значение 114 репутации. По сути, репутация актора может эволюционировать со временем, по мере того как все больше членов сообщества или вычислительных субъектов предоставляют ввод, касающийся репутации актора. Следует понимать, что хотя несколько конкретных способов компилирования метаданных 116 репутации предоставлено, эта информация может быть компилирована любым способом, выполненным с возможностью собирать метаданные, служащие признаком репутаций акторов.

Компоновщик 304 значений репутации может находиться или удаленно относительно клиентского устройства, как показано на фиг.1, или локально, как показано на фиг.2. В предшествующих вариантах осуществления клиентское устройство или некоторый модуль, выполняющийся на нем, может отправлять запрос на значение репутации, касающееся определенного актора. Этот запрос может включать в себя атрибут, который уникально идентифицирует актора, для которого требуется значение репутации. В некоторых случаях этот атрибут может содержать атрибут с цифровой подписью, такой как криптографический аутентификатор сообщения. В этих случаях, когда локальный клиент запрашивает информацию о репутации запросов от одного или более компоновщика(ей) репутации, компоновщик(и) репутации может предоставлять локальному клиенту одно или более значений репутации. Каждый компоновщик, возможно, уже агрегировал несколько фрагментов метаданных 116 репутации в значение 114 репутации. Если несколько компоновщиков существуют, то клиентское устройство может компилировать их в итоговое значение репутации.

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

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

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

- известные вредоносные программы;

- возможно, программа-шпион;

- сообщено, что программа-троян;

- программное обеспечение обновлено посредством поставщика;

- программное обеспечение устарело для поставщика;

- программное обеспечение больше не поддерживается;

- известная уязвимость безопасности;

- исправления для программного обеспечения доступны;

- 85%-ная положительная репутация;

- 23%-ная отрицательная репутация;

- 23234 установки;

- документ с цифровой подписью издателя.

- исходный сетевой адрес, по которому получено программное обеспечение.

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

Компоновщик вводов авторизации

Фиг.4 иллюстрирует вычислительное устройство 400, включающее в себя один или более машиночитаемых носителей 402, которые, как показано, включают в себя модуль 404 управления доступом. Модуль 404 управления доступом может соединяться с компоновщиком 406 вводов авторизации, который может являться неотъемлемой частью, быть доступным посредством или являться отдельным от машиночитаемых носителей 402 и/или модуля 404 управления доступом. Компоновщик 406 вводов авторизации может содержать многие из тех же признаков, что описаны выше в отношении компоновщика 130 вводов авторизации.

Как проиллюстрировано, компоновщик 406 вводов авторизации может принимать значение 114 репутации, возможно, от компоновщиков 112, 208 или 304 значений репутации. Компоновщик 406 вводов авторизации также может принимать другие вводы, такие как идентификационные данные 408 пользователя, тип 410 актора и/или тип 412 системы. Эти дополнительные вводы наряду со значением 114 репутации могут помогать формировать вывод ввода 414 авторизации. Как пояснено выше, ввод авторизации может содержать результат этих вводов и в конечном счете может быть сравнен с правилом или компонентом политики, чтобы определять, должен ли быть предоставлен запрошенный доступ актору.

Идентификационные данные 408 пользователя представляют идентификационные данные пользователя (к примеру, 102), управляющего клиентским устройством (к примеру, 104). Идентификационные данные 408 пользователя вносят вклад в результирующее значение ввода 414 авторизации, поскольку различные пользователи могут иметь различные разрешения. Тип 410 актора упоминается как характер актора, запрашивающего доступ. Например, тип актора может содержать один или более из следующих типов: приложение; программа установки; динамически подключаемая библиотека и/или программа установки. Другие типы также могут существовать на основе метки объекта. С другой стороны, тип актора вносит вклад в результирующее значение ввода 414 авторизации, поскольку различные типы акторов могут иметь различные уровни разрешения. Например, тип актора протокола передачи файлов (FTP) может считаться менее заслуживающим доверия, чем альтернативное приложение, такое как текстовый процессор. Конечно, это также может зависеть от типа 412 системы, который упоминается как тип системы, к которой актор желает осуществлять доступ. Например, тип 412 системы может содержать персональный компьютер, промышленный сервер, FTP-сервер и т.п.

Чтобы подчеркнуть то, как тип 412 системы может влиять на выводимый ввод 414 авторизации, внимание возвращается к примеру типа актора FTP, поясненному выше. Если типом 412 системы, к которой актор желает осуществлять доступ, является персональный компьютер, то тип актора FTP 410 может считаться менее заслуживающим доверия. Тем не менее, если типом 412 системы является FTP-сервер, то FTP-актор 410 может в большей степени считаться более заслуживающим доверия. Здесь более вероятно, что программа FTP, выполняющаяся на персональном компьютере, является вредоносной программой, программой-шпионом и т.п., тогда как это менее вероятно является истиной, если программа FTP выполняется на FTP-сервере.

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

Модуль авторизации

Фиг.5 иллюстрирует вычислительное устройство 500, включающее в себя один или более машиночитаемых носителей 502, которые могут включать в себя модуль 504 управления доступом. Как проиллюстрировано, модуль 504 управления доступом включает в себя модуль 506 авторизации, который в свою очередь включает в себя модуль 508 правил. Модуль 506 авторизации может функционировать многими из таких же способов, как описано выше в отношении модуля 132 авторизации. Аналогично модуль 508 правил может функционировать многими из таких же способов, как модуль 134 правил.

Фиг.5 также иллюстрирует модуль 506 авторизации, принимающий запрос 510. Актор (к примеру, приложение), в общем, отправляет запрос 510, который может быть аналогичным или идентичным локальному запросу 120 и/или удаленному запросу 122, поясненным выше. Актор может запрашивать, чтобы выполнять некоторую операцию (к примеру, считывание, запись, удаление, открытие) с объектом (к примеру, файлом), находящимся или доступным посредством вычислительного устройства 500. В дополнение к запросу модуль 506 авторизации также может принимать ввод 414 авторизации. Как пояснено выше, ввод 414 авторизации, по меньшей мере, частично служит признаком репутации актора, стремящегося выполнять операцию с объектом. Так же как пояснено выше, другие компоненты также могут предоставлять ввод во ввод 414 авторизации. Тем не менее, если ввод 414 авторизации не включает в себя другие компоненты, ввод 414 авторизации состоит просто из значения репутации актора.

Модуль 506 авторизации может сравнивать ввод 414 авторизации с правилами, созданными и/или реализованными посредством модуля 508 правил. Это сравнение может служить для того, чтобы определять, должен или нет быть предоставлено актору разрешение выполнять запрос 510, который может быть выведен в форме решения 512 об авторизации. В соответствии с правилами или компонентами политики, реализованными посредством модуля 508 правил, решение 512 об авторизации может предоставлять актору разрешение выполнять запрошенную авторизацию, может запрещать актору разрешение или может запрашивать пользователя выбирать то, следует ли предоставлять актору разрешение. Примерные правила для типа актора пакета установки могут содержать следующее:

- не устанавливать, если ввод 414 авторизации является "плохим"

- запрашивать пользователя, если ввод 414 авторизации является "неизвестным"

- давать возможность установки, если ввод 414 авторизации является "хорошим".

В некоторых случаях, используя вышеупомянутый набор правил, ввод 414 авторизации может состоять просто из значения 114 репутации. Здесь решение 512 об авторизации может предоставлять актору разрешение, если значение репутации "хорошо", в то же время запрещая актору разрешение, если значение репутации "плохо". Кроме того, решение об авторизации может запрашивать пользователя выбирать, если значение репутации "неизвестно". Как этот пример иллюстрирует, модуль 506 авторизации может принимать автоматические или заранее определенные решения на основе ввода авторизации и реализованных правил или модуль авторизации может подчиняться пользователю при окончательном решении.

Кроме того, модуль 508 правил может содержать правила с варьирующимися уровнями детализации. Например, модуль 506 авторизации и/или модуль 508 правил также может оценивать характер запроса 510 при принятии решения 512 об авторизации. Чтобы подчеркнуть это, следующий примерный список содержит комплексные правила авторизации, которые модуль 508 правил может реализовывать при принятии решения об авторизации:

- не разрешать установку, если <1000 хороших отчетов;

- не разрешать изменения портов брандмауэра для неизвестной репутации;

- разрешать изменения в системном реестре только для "хороших" программных компонентов;

- разрешать *.doc-файлы, но не *.xls-файлы;

- разрешать документы с цифровой подписью, но не разрешать без подписи;

- запрашивать пользователя относительно решения по установке программного обеспечения, если неизвестная репутация;

- не воспроизводить мультимедиа, если голосование по репутации составляет меньше чем 5000 голосов;

- разрешать только определенным акторам выполняться на устройстве с определенными операционными системами;

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

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

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

Примерная реализация

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

Со ссылкой на фиг.1 предположим, что пользователь 102 загружает приложение от удаленного поставщика 110 услуг через сеть 108 и запускает установку этого приложения на клиентском устройстве 104. В этом случае загруженное приложение может пытаться открывать порт в брандмауэре клиентского устройства 104. Прежде чем доступ предоставляется, тем не менее, компонент брандмауэра вызывает модуль 128 управления доступом, чтобы проверять репутацию приложения, запрашивающего изменение порта. Если модуль 128 управления доступом уже имеет значение 114 репутации, кэшированное для этого приложения, то он может использовать это значение. Если модуль 128 управления доступом не имеет значения репутации, тем не менее, то он может запрашивать значение репутации от компоновщика 112 значений репутации. Конечно, модуль 128 управления доступом вместо этого может запрашивать метаданные 116 репутации от поставщика 202 репутации в некоторых случаях.

В любом случае модуль управления доступом принимает или формирует значение 114 репутации для вызывающего приложения. Модуль 128 управления доступом затем может использовать это значение репутации и, возможно, другие компоненты, такие как тип системы, чтобы формировать ввод авторизации с помощью компоновщика 130 вводов авторизации. В текущем примере другие компоненты не вводятся, и ввод авторизации просто содержит это значение репутации. Компоновщик 130 вводов авторизации затем предоставляет основанный на репутации ввод авторизации в модуль 132 авторизации, который сравнивает основанный на репутации ввод авторизации приложения с политикой авторизации из модуля 134 правил. Здесь значение репутации приложения может быть помечено "плохое", и политика авторизации может заявлять, что "плохие" приложения не могут открывать порты в брандмауэре. Следовательно, можно не допускать открытия посредством приложения порта брандмауэра. Наконец, пользователь может быть визуально уведомлен относительно запрета через пользовательский интерфейс.

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

Заключение

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