АБСТРАГИРОВАНИЕ ПОЛИТИКИ БЕЗОПАСНОСТИ ОТ И ПРЕОБРАЗОВАНИЕ В СОБСТВЕННЫЕ ПРЕДСТАВЛЕНИЯ МЕХАНИЗМОВ ПРОВЕРКИ ДОСТУПА Российский патент 2012 года по МПК G06F21/00 

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

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

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

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

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

4. Невозможно идентифицировать осуществления доступа, которые нарушают определенную политику контроля доступа.

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

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

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

8. Нет легкого механизма для делегирования персональных разрешений другим лицам или механизмам для разделения административной ответственности между лицами в строго ограниченной манере.

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

Таким образом, необходимы процессы и система, которые бы преодолевали данные недостатки.

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

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

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

Ниже приводится описание других преимуществ и характеристик изобретения.

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

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

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

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

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

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

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

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

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

Подробное описание

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

Примерные вычислительные окружения

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

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

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

Примерная система для реализации аспектов изобретения включает в себя вычислительное устройство общего назначения в форме компьютера 241. Компоненты компьютера 241 могут включать в себя, но не ограничиваются, блок 259 обработки, системную память 222 и системную шину 221, которая соединяет разные компоненты системы, включая системную память и блок 259 обработки. Системная шина 221 может быть любой структуры, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, использует любой вариант шинной архитектуры. В качестве примера, но не ограничения, можно привести такие шинные архитектуры как архитектура промышленного стандарта (ISA), микроканальная архитектура шины (MCA), расширенная архитектура шины промышленного стандарта (EISA), шина ассоциации по стандартизации в области видеотехники (VESA), шина межсоединения периферийных компонентов (PCI), также известная как Мезанинная, и ее последователь стандарт PCI-Express.

Компьютер 241 обычно включает в себя несколько компьютерночитаемых носителей. Компьютерночитаемые носители могут быть любыми возможными носителями, к которым может осуществлять доступ компьютер 241, и включать в себя энергозависимые и энергонезависимые носители, съемные и несъемные носители. В качестве примера, но не ограничения, компьютерночитаемые носители могут содержать компьютерные носители хранения и носители связи. Компьютерные носители хранения включают в себя энергозависимые и энергонезависимые носители, съемные и несъемные носители, реализованные любым методом или технологией для хранения информации, такими как компьютерночитаемые инструкции, структуры данных, программные модули или другие данные. Компьютерные носители хранения включают в себя, но этим не ограничивается, RAM, ROM, EEPROM, флэш-память или другие технологии памяти, CD-ROM, цифровые универсальные диски (DVD) или другие оптические дисковые накопители, магнитные кассеты, магнитные пленки, магнитные дисковые хранилища или другие магнитные устройства хранения, или любой другой носитель, который может использоваться для хранения желаемой информации и к которому может осуществлять доступ компьютер 241. Носители связи обычно воплощают компьютерночитаемые инструкции, структуры данных, программные модули и другие данные в модулированном сигнале данных, таком как несущая волна или другой транспортный механизм, и включают в себя любой носитель доставки информации. Термин "модулированный сигнал данных" означает сигнал, который имеет одну или более из его характеристик, установленных или измененных так, чтобы кодировать информацию в сигнале. В качестве примера носителей связи, но не ограничения, носители связи включают в себя проводные носители, такие как кабельная сеть или прямое кабельное соединение, и беспроводные носители: акустические, RF, инфракрасные и другие беспроводные носители. Комбинация любых из них тоже должна быть включена в объем компьютерночитаемых носителей.

Системная память 222 включает в себя компьютерный носитель хранения в форме энергозависимой и/или энергонезависимой памяти, такой как постоянное запоминающее устройство (ROM) 223 и оперативная память (RAM) 260. Базовая система ввода-вывода 224 (BIOS) содержит основные подпрограммы, которые помогают передавать информацию между элементами в пределах компьютера 241, например, во время запуска, и обычно хранится в ROM 223. RAM 260 обычно содержит данные и/или модули программ, которые доступны немедленно и/или непосредственно исполняются блоком 259 обработки. В качестве примера, но не ограничения, фиг.1 иллюстрирует операционную систему 225, прикладные программы 226, другие модули 227 программ и данные 228 программ.

Компьютер 241 может также включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители хранения. В качестве примера, фиг.1 иллюстрирует накопитель 238 на жестких дисках, который читает с или пишет на несъемные, энергонезависимые магнитные носители, накопитель 239 на магнитных дисках, который читает с или пишет на съемный, энергонезависимый магнитный диск 254, и накопитель 240 на оптических дисках, который читает с или пишет на съемный, энергонезависимый оптический диск 253, например CD-ROM или другие оптические носители. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители хранения, которые могут использоваться в примерном рабочем окружении, включают в себя, но не ограничены этим, кассеты с магнитной лентой, карты флэш-памяти, цифровые универсальные диски, цифровую видеоленту, твердотельное RAM, твердотельное ROM и т.п. Накопитель 238 на жестких дисках обычно подключается к системной шине 221 через интерфейс несъемной памяти, например интерфейс 234, и накопитель 239 на магнитных дисках и накопитель 240 на оптических дисках обычно подключаются к системной шине 221 через интерфейс съемной памяти, например интерфейсом 235.

Диски и их ассоциированные компьютерные носители хранения, обсуждаемые выше и иллюстрированные на фиг.1, предоставляют хранение компьютерночитаемых инструкций, структур данных, программных модулей и других данных для компьютера 241. В фиг.1, например, накопитель 238 на жестких дисках проиллюстрирован как хранящий операционную систему 258, прикладные программы 257, другие программные модули 256 и данные 255 программ. Следует обратить внимание, что эти компоненты могут быть такими же или отличаться от операционной системы 225, прикладных программ 226, других программных модулей 227 и данных 228 программ. Операционная система 258, прикладные программы 257, другие программные модули 256 и данные 255 программ изображены другими ссылками, чтобы иллюстрировать, что, как минимум, они - различные копии. Пользователь может ввести команды и информацию в компьютер 241 через устройства ввода данных, например клавиатуру 251 и указывающее устройство 252, обычно называемое мышью, шаровым указателем или сенсорной панелью. Другие устройства ввода данных (не показаны) могут включать в себя микрофон, джойстик, игровую панель, спутниковую антенну, сканер или подобное. Эти и другие устройства ввода данных часто подключаются к блоку 259 обработки через пользовательский интерфейс 236 ввода, который присоединен к системной шине, но могут быть подключены другим интерфейсом и шинной структурой, например параллельным портом, игровым портом или универсальной последовательной шиной (USB). Монитор 242 или другой тип устройства отображения также подключается к системной шине 221 через интерфейс, например небезопасный или безопасный видеоинтерфейс 232. Безопасный видеостандарт может быть стандартом Высококачественного Интерфейса Мультимедиа (HDMI). В дополнение к монитору компьютеры могут также включать в себя другие периферийные устройства вывода, такие как громкоговорители 244 и принтер 243, которые могут быть подключены через периферийный интерфейс 233 вывода.

Компьютер 241 может работать в сетевом окружении, используя логические подключения с одним или более удаленными компьютерами, например удаленным компьютером 246. Удаленный компьютер 246 может быть персональным компьютером, сервером, маршрутизатором, сетевым PC, одноранговым устройством или другим общим сетевым узлом и обычно включает многие или все элементы, описанные выше относительно компьютера 241, хотя только запоминающее устройство памяти 247 было проиллюстрировано на фиг.1. Логические подключения, изображенные на фиг.1, включают локальную сеть (LAN) 245 и глобальную сеть (WAN) 249, но могут также включать другие сети. Такие сетевые среды являются обычными в офисах, компьютерных сетях в масштабах предприятия, Интрасети и Интернете.

При использовании в сетевом окружении LAN компьютер 241 подключен к LAN 245 через сетевой интерфейс или адаптер 237. При использовании в сетевом окружении WAN компьютер 241 обычно включает в себя модем 250 или другие средства для установления связи по WAN 249, например Интернет. Модем 250, который может быть внутренним или внешним, может быть подключен к системной шине 221 через пользовательский интерфейс 236 ввода или другой подходящий механизм. В сетевом окружении модули программы, изображенные относительно компьютера 241, или рядом с ним, могут быть сохранены в удаленном запоминающем устройстве памяти. В качестве примера, но не ограничения, фиг.1 иллюстрирует удаленные прикладные программы 248 как расположенные на устройстве 247 памяти. Необходимо понимать, что показанные сетевые соединения являются примерными, и могут использоваться другие средства установления линии связи между компьютерами.

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

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

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

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

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

Фиг.2 предоставляет схематическую диаграмму рабочей сетевой среды или распределенной вычислительной среды. Среда содержит вычислительные устройства 271, 272, 276 и 277, а также объекты 273, 274 и 275 и базу 278 данных. Каждая из этих сущностей 271, 272, 273, 274, 275, 276, 277 и 278 может включать или использовать программы, способы, хранилища данных, программируемую логику и т.д. Сущности 271, 272, 273, 274, 275, 276, 277 и 278 могут использоваться в тех же самых или различных устройствах, например в карманных компьютерах, аудио/видеоустройствах, MP3-плеерах, персональных компьютерах и т.д. Каждая сущность 271, 272, 273, 274, 275, 276, 277 и 278 может поддержать связь с другой сущностью 271, 272, 273, 274, 275, 276, 277 и 278 посредством сети 270 связи. В этом отношении, любая сущность может отвечать за обслуживание и обновление базы 278 данных или другого элемента хранения.

Эта сеть 270 может самостоятельно включать другие вычислительные сущности, которые предоставляют службы системе фиг.2 и могут самостоятельно представлять несколько связанных сетей. В соответствии с аспектом изобретения, каждая сущность 271, 272, 273, 274, 275, 276, 277 и 278 может содержать дискретные функциональные программные модули, которые могли бы использовать API или другой объект, программное обеспечение, программно-аппаратное обеспечение и/или аппаратное обеспечение для того, чтобы запрашивать службы одной или более других сущностей 271, 272, 273, 274, 275, 276, 277 и 278.

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

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

Сетевая инфраструктура может содержать главный компьютер топологий сети, например, клиент-серверных, пиринговых или гибридных архитектур. "Клиент" - член класса или группы, который использует службы другого класса или группы, к которой он не относится. В вычислении клиент - это процесс, то есть просто набор инструкций или задач, который запрашивает службу, предоставляемую другой программой. Клиентский процесс использует запрошенную службу без необходимости "знать" любые рабочие подробности о другой программе или самой службе. В архитектуре клиент-сервер, в частности в сетевой системе, клиент обычно является компьютером, который обращается к общедоступным сетевым ресурсам, предоставленным другим компьютером, например сервером. В примере фиг.2 любая сущность 271, 272, 273, 274, 275, 276, 277 и 278 может считаться клиентом, сервером или и тем, и другим в зависимости от обстоятельств.

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

Клиент(ы) и сервер(ы) осуществляют связь друг с другом, используя функциональные возможности, предоставленные уровнем(нями) протокола. Например, Протокол передачи гипертекста (HTTP) является общим протоколом, который используется в связи со всемирной паутиной (WWW), или "Web." Как правило, компьютерный сетевой адрес, например адрес протокола Интернет (IP), или другая ссылка, например универсальный указатель ресурсов (URL), могут использоваться, чтобы идентифицировать сервер или клиентские компьютеры друг перед другом. Сетевой адрес может упоминаться как адрес URL. Связь может быть предоставлена по носителю связи, например, клиент(ы) и сервер(ы) могут быть соединены друг с другом через подключение(я) TCP/IP для высокоскоростной связи.

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

Абстракция и механизмы проверки доступа

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

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

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

Выразительность:

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

b. Возможность определить, кто сделал такие утверждения.

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

d. Возможность создавать более высокоуровневые конструкции политик, используя примитивы выразительности. Это значит, что примитивы не слишком стеснены в своем выразительном объеме.

Декларативная семантика и монотонность:

a. Возможность составить и объединить утверждения и получить тот же самый набор следствий независимо от порядка, в котором они обрабатываются.

b. Возможность согласовать следствия с "доказательствами", созданными из выражений политики.

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

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

a. Возможность вычислить следствия декларативных утверждений в эффективном виде.

b. Анализ и запрос журнала аудита эффективны.

Примитивы внутреннего механизма проверки доступа (или некоторое заданное подмножество внутренностей) идентифицируются. То есть данные, используемые существующими механизмами проверки доступа, чтобы принять решение разрешить доступ. Примеры этих примитивов - определения ролей и присваивание ролей (Диспетчер авторизации (AzMan) и ASP.NET); лицензии управления правами (RMS, IPP); ACL (совместное использование файлов, системы сетевой защиты и т.д.).

Эти примитивы затем характеризуются как предикаты на языке политики. Например, запись контроля доступа (АСЕ) в ACL может соответствовать предикату "chuckr может читать foo.txt". Другим примером может быть, для приложения AzMan, "chuckr в роли разработчика". Может существовать много таких примитивов в зависимости от различных механизмов проверки доступа. Эти примитивы упоминаются как разрешения.

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

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

Примерные сценарии

Следующий пример иллюстрирует разделение цели от реализации и конфигурирование значения цели в низкоуровневом механизме проверки доступа.

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

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

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

Цель состоит в том, чтобы заключить, что может быть выражено в системе управления доступом (то есть некурсивные выражения 303) от выражений политики (то есть курсивные выражения 301).

Следующее правило 301 политики фиксирует вышеупомянутое поведение:

System says Principal "X" can do Action "Y" to Resource "Z"

If System says Principal "0" is the owner of Resource "Z"

And If Principal "0" says Principal "X" can do Action "Y" to Resource "Z".

Предположим, что следующая информация 305 известна:

System says Peter is the owner of foo.txt

Peter says Ravi can read foo.txt

Peter says John can print foo.txt.

Из вышеупомянутого возможно, чтобы логически заключить 307 следующие права доступа 303:

System says Ravi can read foo.txt

System says John can print foo.txt.

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

Peter says Principal "X" can read foo.txt

If Bob says Principal "X" can read foo.txt.

Предположим, что следующая дополнительная информация 405 известна:

Bob says Tom can read foo.txt.

Возможно, чтобы логически заключить 307 следующее:

Peter says Tom can read foo.txt,

и впоследствии логически заключить 307 следующее разрешение 403:

System says Tom can read foo.txt.

Обратимся далее к фиг.5, на которой показана блок-схема, иллюстрирующая ввод результирующих примерных разрешений в представление механизма проверки доступа. Именно эти некурсивные выражения 403, 303 (то есть разрешения) вводятся 501 в представление механизма проверки доступа 503, чтобы реализовать политику безопасности 301.

Обратимся далее к фиг.6, на которой показана блок-схема, иллюстрирующая предоставление доказательства, следующее из примерного события доступа и аудита. Предположим, что Том действительно читает foo.txt 601, и соответствующее событие аудита создается 603. Полная причина вычисляется 605 для Тома, с разрешением читать foo.txt, используя выражения политики 301.

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

Tom can read Foo.txt because:

System says Tom can read Foo.txt because:

System says Peter is the owner of Foo.txt

And Peter says Tom can read Foo.txt because:

Bob says Tom can read Foo.txt.

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

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

Основанный на ролях механизм 701 управления доступом (RBAC), который поддерживает делегирование, предоставлен пользователям через подходящие управляемые политикой пользовательские интерфейсы 703. Пользователи, которые конфигурируют политику, рассматривают только те аспекты политики, которые им позволено рассматривать или конфигурировать. Как только такая политика сконфигурирована, ее значение фиксируется в основной модели 705 политики, которая является основой системы.

Модель основной политики 705 используется в следующих целях.

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

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

- Учитывает вычисление представления разрешений в формате, который является подходящим для механизма 707 проверки доступа (например, ACL и Роли AzMan).

- Рационализирует доступы, объявленные как события 709 аудита с политикой предоставленной модели 711 аудита, чтобы определить, как политика обеспечивает доступ.

Система, у которой есть большинство вышеупомянутых возможностей, эффективно добавляет хорошо разделенные возможности делегации, например, к ролям AzMan и ACL, не изменяя ни одного из низкоуровневых механизмов 713 проверки доступа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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