Ролевое управление доступом

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

Таким решением является ролевое управление доступом (РУД). Суть его в том, что между пользователями и их привилегиями появляются про­межуточные сущности — роли. Для каждого пользователя одновременно могут быть активными несколько ролей, каждая из которых дает ему оп­ределенные права ( рис. 9.2).

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

Ролевой доступ развивается более 10 лет (сама идея ролей, разумеет­ся, значительно старше) как на уровне операционных систем, так и в рам­ках СУБД и других информационных сервисов. В частности, существуют реализации ролевого доступа для Web-серверов.

В 2001 г. Национальный институт стандартов и технологий США предложил проект стандарта ролевого управления доступом (см. http://csrc.nist.gov/rbac/), основные положения которого мы и рассмотрим.

Ролевое управление доступом оперирует следующими основными понятиями:

• пользователь (человек, интеллектуальный автономный агент и т.п.);

• сеанс работы пользователя;

• роль (обычно определяется в соответствии с организационной структурой);

• объект (сущность, доступ к которой разграничивается; напри­мер, файл ОС или таблица СУБД);

• операция (зависит от объекта; для файлов ОС — чтение, запись, выполнение и т.п.; для таблиц СУБД — вставка, удаление и т.п., для прикладных объектов операции могут быть более сложными);

• право доступа (разрешение выполнять определенные операции над определенными объектами).

Ролям приписываются пользователи и права доступа; можно счи­тать, что они (роли) именуют отношения «многие ко многим» между пользователями и правами. Роли могут быть приписаны многим пользо­вателям; один пользователь может быть приписан нескольким ролям. Во время сеанса работы пользователя активизируется подмножество ролей, которым он приписан, в результате чего он становится обладателем объе­динения прав, приписанных активным ролям. Одновременно пользова­тель может открыть несколько сеансов.

Между ролями может быть определено отношение частичного порядка, называемое наследованием. Если роль г2 является наследницей rl, то все права rl приписываются г2, а все пользователи г2 приписываются rl. Очевидно, что наследование ролей соответствует наследованию классов в объектно-ориентированном программировании, только правам доступа соответствуют методы классов, а пользователям — объекты (экземпляры) классов (рис. 9.2).

Рис.9.2. Схема распределения ролей

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

Можно представить себе формирование иерархии ролей, начиная с минимума прав (и максимума пользователей), приписываемых роли «со­трудник», с постепенным уточнением состава пользователей и добавле­нием прав (роли «системный администратор», «бухгалтер» и т.п.), вплоть до роли «руководитель» (что, впрочем, не значит, что руководителю предоставляются неограниченные права; как и другим ролям, в соответ­ствии с принципом минимизации привилегий, этой роли целесообразно разрешить только то, что необходимо для выполнения служебных обязан­ностей).

Для реализации еще одного упоминавшегося ранее важного прин­ципа информационной безопасности вводится понятие разделения обя­занностей, причем в двух видах: статическом и динамическом.

Статическое разделение обязанностей налагает ограничения на припи­сывание пользователей ролям. В простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному множеству дру­гих ролей. В общем случае данное ограничение задается как пара «множество ролей число» (где множество состоит, по крайней мере, из двух ролей, а чис­ло должно быть больше 1), так что никакой пользователь не может быть при­писан указанному (или большему) числу ролей из заданного множества. На­пример, могут существовать пять бухгалтерских ролей, но политика безопас­ности допускает членство не более чем в двух таких ролях (здесь число равно 3).

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

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

Рассматриваемый проект стандарта содержит спецификации трех категорий функций, необходимых для администрирования РУД:

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

2. Вспомогательные функции (обслуживание сеансов работы пользова­телей): открыть сеанс работы пользователя с активацией подразуме­ваемого набора ролей; активировать новую роль, деактивировать роль; проверить правомерность доступа.

3. Информационные функции (получение сведений о текущей конфигу­рации с учетом отношения наследования). Здесь проводится разде­ление на обязательные и необязательные функции. К числу первых принадлежит получение списка пользователей, приписанных роли, и списка ролей, которым приписан пользователь.

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

Можно надеяться, что предлагаемый стандарт поможет сформиро­вать единую терминологию и, что более важно, позволит оценивать РУД-продукты с единых позиций, по единой шкале.