Модель аннулирования URA99

Моделирование систем защиты информации

Лабораторная работа №3

Тема: Администрирование ролевой модели доступа

Цель работы: изучение принципов администрирования ролевой модели безопасности с помощью ролей

Теоретическая часть

Контроль доступа, основанный на ролях (RBAC) – гибкая и нейтральная технология контроля доступа. Для больших систем – с сотнями ролей, тысячами пользователей и миллионами разрешений – управление ролями, пользователями, разрешениями и их взаимоотношениями – тяжелая задача, которая не может быть сконцентрирована в маленькой команде сетевых администраторов. Существует привлекательная возможность использовать RBAC для облегчения децентрализации администрирования RBAC. Модель ARBAC99 предназначена для этой цели. ARBAC99 имеет 3 подмодели: URA99 (для ролевого администрирования ролей пользователей), PRA99 (для ролевого администрирования разрешений), RRA99 (для ролевого администрирования ролей).

Основные понятия

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

Очень часто можно услышать вопрос: «В чем различие между ролями и группами?». Группы пользователей как единица контроля доступа обычно предусмотрены в большинстве систем контроля доступа. Основное отличие между большинством разработок групп и концепцией ролей является то, что группы обычно рассматриваются как совокупность пользователей с одной стороны и совокупность разрешений с другой. Роль служит как посредник между этими совокупностями.

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

Подмодель URA 97

Рассмотрим модель URA97, используемую для управления назначением пользовательской роли. Мы определяем URA97 в двух аспектах, связанных с предоставлением пользователю членства в роли и отменой членства пользователя. Модель URA97 специально разработана с очень ограниченными возможностями. Например, создание пользователей и ролей – вне её компетенции. Несмотря на простоту, URA97 довольно мощная модель, и значительно превосходит существующие административные модели для назначения пользовательской роли. Эта модель также применима вне RBAC для назначения групп пользователей.

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

В некоторых системах можно определять роль, скажем – младший офицер безопасности (JSO), – члены которой имеют административный контроль над некоторым количеством постоянных ролей, к примеру, A, B и C. Таким образом, ограниченные административные полномочия предоставлены роли JSO. К сожалению, эти системы обычно предоставляют роли JSO полный контроль над ролями A, B и C. Член JSO может не только добавлять пользователей к A, B и C, но и удалять пользователей из этих ролей, а также добавлять и удалять права. Кроме того, нет никакого контроля, под которым пользователи могут быть добавлены к ролям A, B и C членами JSO. Наконец, членам JSO разрешено назначать A, B и C младшими членами любой роли в существующей иерархии (пока это не приведёт к циклу). Все это совмещается с классическими представлениями о контроле, благодаря чему JSO эффективно обозначаются как "владельцы" ролей A, B и C, и поэтому могут делать с этими ролями всё, что захотят.

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

Определение 1. Условие необходимой предпосылки – булевское выражение, использующее операторы Ù и Ú над переменными вида x и` x, где x – постоянная роль то есть, x Î R). Условие необходимой предпосылки оценивается для пользователя u, полагая x истинным, если ($ x ¢ ³ x) (u, x ¢) Î UA, и – истинным, если (" x ¢ ³ x) (u, x ¢) Ï UA. Для данного набора ролей R обозначим как CR все возможные условия необходимой предпосылки, которые могут быть сформированы, используя роли из R.

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

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

Определение 2. Модель URA97 контролирует назначение пользовательской роли посредством отношения can-assign ÍARxCRx2^R.

Значение can-assign (x, y, { a, b, c }) в том, что член административной роли x (или член административной роли, которая является старшей для x), может назначать пользователя, текущее членство (или отсутствие членства) которого в постоянных ролях удовлетворяет условию необходимой предпосылки y, членом постоянных ролей a, b или c [1].

Чтобы оценить мотивацию отношения can-assign рассмотрим иерархию роли на рис. 1 и иерархию административной роли на рис. 2. Рис. 1 показывает постоянные роли, которые существуют в техническом отделе. Е – самая младшая роль, которая назначается всем служащим в организации. В пределах технического отдела есть самая младшая роль ED и самая старшая роль DIR. Между ними есть роли для двух проектов в пределах отдела, проект 1 – слева и проект 2 – справа. Каждый проект имеет старшую роль – роль руководителя проекта (PL1 и PL2) и младшую роль – роль инженера (E1 и E2). Между этими ролями каждый проект имеет две несравнимых роли: промышленный инженер (PE1 и PE2) и инженер по качеству (QE1 и QE2).

Рис. 1 Пример ролевой иерархии

 

Рис. 2 Пример иерархии административных ролей

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

Рис. 2 показывает иерархию административных ролей, которая сосуществует с показанной на рис. 1. Самая главная роль – старшее должностное лицо, отвечающее за безопасность (SSO). Главный интерес для нас представляют административные роли, младшие по отношению к SSO. Они состоят из двух ролей начальников охраны проектов (PSO1 и PSO2) и роли начальника безопасности отдела (DSO) со связями, показанными на рисунке.

Для иллюстрации определим отношение can-assign, показанное в Табл. 1 в столбце Role Set набора роли. В этом примере присутствует простейшее условие необходимой предпосылки испытания членства в отдельной роли, известной как роль необходимой предпосылки.

Роль PSO1 несет частичную ответственность за роли проекта 1. Пусть Алиса будет членом роли PSO1 и Боб – членом роли ED. Алиса может назначать Боба на любую из ролей E1, PE1 и QE1, но не на роль PL1. К тому же, если Чарли не член роли ED, то Алиса не может назначать его на какую-либо из ролей проекта 1. Следовательно, Алиса имеет полномочия, для назначения пользователей на роли E1, PE1 и QE1, что обеспечивает этим пользователям членство в роли ED. Обратите внимание на то, что если Алиса назначает Боба на PE1, он не нуждается в явном назначении на E1, так как права E1 будут унаследованы через иерархию роли. Роль PSO2 аналогична PSO1, но по отношению к проекту 2. Роль DSO наследует полномочия ролей PSO1 и PSO2, но может далее добавлять пользователей, являющихся членами ED к ролям PL1 и PL2. Роль SSO может добавлять пользователей, находящихся в E роли к роли ED, также как добавлять пользователей, находящихся в роли ED к роли DIR. Это гарантирует, что даже SSO должен будет зарегистрировать пользователя в роли ED прежде, чем этот пользователь будет зарегистрирован в роли старшей по отношению к ED. Это – разумная спецификация для can-assign. Есть, конечно, масса других одинаково разумных спецификаций в этом плане. Это – вопрос решения политики, и наша модель обеспечивает необходимую гибкость.

Вообще, можно было бы ожидать, что назначаемая роль является старшей по отношению к роли, изначально требовавшейся пользователю. То есть если мы имеем, can-assign (a, b, C) тогда b младший, по отношению ко всем ролям c Î C. Мы полагаем, что это обычно будет иметь место, но мы не требуем этого в модели. Это позволяет URA97 быть применимой к ситуациям, где нет никакой иерархии роли или где такое ограничение не может быть соответствующим.

Таким образом, для DSO мы определили набор ролей как {PL1, PL2} и других значений наследуемых от PSO1 и PSO2.

Can-assign с Ролями Необходимой предпосылки (prereq. role)Таблица 1

Admin. Role	Prereq. Role	Role Set	Role Range
PSO1 PSO2 DSO SSO SSO	ED ED ED E ED	{E1, PE1, QE1} {E2, PE2, QE2} {PL1, PL2} {ED} {DIR}	[E1, PL1) [E2, PL2) (ED, DIR) [ED, ED] (ED, DIR]

Аналогично для SSO. Однако явное перечисление набора ролей было бы громоздким, особенно если бы мы работали с десятками или сотнями проектов в отделе. Кроме того, явное перечисление не эластично относительно изменений в иерархии роли. Предположим, что третий проект представлен в отделе ролями E3, PE3, QE3, PL3 и PSO3 аналогично соответствующим ролям для проектов 1 и 2. Мы можем добавить следующую строку к Таблице 1.

Admin. Role	Prereq. Role	Role Set
PSO3	ED	{E3, PE3, QE3}

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

Рассмотрите вместо этого значение диапазона, показанное в Таблице 1 в столбце Role Range диапазона ролей. Столбцы Role Set и Role Range Таблицы 1 показывают одинаковые наборы ролей. Диапазон ролей определяет этот набор, опознавая диапазон в пределах иерархии роли на рисунке 1 (a) посредством известного закрытого и открытого значения интервала.

Определение 3. Наборы ролей определены в модели URA97 следующими выражениями:

[ x,y ] = { r Î R | x ³ r Ù r ³ y }

[ x, y) = { r Î R | x ³ r Ù r > y }

(x, y ] = { r Î R | x > r Ù r ³ y }

(x, y) = { r Î R | x > r Ù r>y }

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

Admin. Role	Prereq. Role	Role Range
PSO3	ED	[E3, PL3)

Никаких других изменений не требуется. Начиная с [ED, DIR), диапазон, указанный для DSO автоматически приобретет PL3.

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

Строго говоря, набор ролей и диапазон ролей – спецификации таблицы 1. Набором ролей, DSO явно разрешено зарегистрировать пользователей в PL1 и PL2, и наследуется от PSO1 и PSO2 возможность регистрации пользователей в других ролях проектов 1 и 2. С другой стороны, диапазоном ролей, DSO явно разрешено зарегистрировать пользователей во всех ролях проектов 1 и 2. Результат будет тот же самый. Однако если модифицирована иерархия роли или права PSO1 или PSO2, результат может отличаться. Роль DSO, устанавливающая права, может быть заменена следующей строкой, чтобы сделать это почти идентичным указанному диапазону роли.

Admin. Role	Prereq. Role	Role Set
DSO	ED	{E1, PE1, QE1, PL1, E2, PE2, QE2, PL2}

Теперь, даже если роли PSO1 и PSO2 Таблицы 1 изменены соответственно в наборы ролей {E1} и {E2}, DSO роль будет все еще сохранять административные полномочия над всеми ролями проекта 1 и проекта 2. Конечно, явные и неявные спецификации никогда не будут вести себя точно тождественно при всех обстоятельствах. Например, введение нового проекта 3 покажет различия как описано выше. Наоборот, диапазон ролей DSO в Таблице 1 может быть заменен следующими строками, чтобы сделать это почти идентичным указанному набору ролей.

Admin. Role	Prereq. Role	Role Range
DSO DSO	ED ED	[PL1, PL1] [PL2, PL2]

Аналогична ситуация с ролью SSO в Таблице 1. Ясно, что мы должны учитывать воздействие будущих изменений, при определении отношения can-assign.

Пример can-assign, который использует скорее условия необходимой предпосылки, чем роли необходимой предпосылки, показывается в Таблице 2. Права для PSO1 и PSO2 были изменены по сравнению с Таблицей 1.

Позвольте нам рассмотреть кортежи PSO1 (анализ для PSO2 аналогичен). Первый кортеж разрешает PSO1 назначать пользователей с ролью необходимой предпосылки ED в E1.

Can-assign с Условиями Необходимой предпосылки Таблица 2

Admin. Role	Prereq. Condition	Role Range
PSO1	ED	[E1, E1]
PSO1		[PE1, PE1]
PSO1		[QE1, QE1]
PSO1	PE1ÙQE1	[PL1, PL1]
PSO2	ED	[E2, E2]
PSO2		[PE2, PE2]
PSO2		[QE2, QE2]
PSO2	PE2ÙQE2	[PL2, PL2]
DSO	ED	(ED, DIR)
SSO	E	[ED, ED]
SSO	ED	(ED, DIR]

Второй разрешает PSO1 назначать пользователей роли PE1 с условием необходимой предпосылки EDÙ . Точно так же третий кортеж разрешает PSO1 назначать пользователей роли QE1 с условием необходимой предпосылки EDÙ . Взятые вместе второй и третий кортежи разрешают PSO1 назначить пользователю, являющемуся членом ED, роль PE1 или QE1, но не обе. Это показывает, как в URA97 могут быть предписаны взаимно исключающие роли. PE1 и QE1 взаимно исключают друг друга по отношению к власти PSO1. Однако для DSO и SSO они не являются взаимно исключающими. Следовательно, понятие взаимного исключения в URA97 – относительное. Четвертый кортеж разрешает PSO1 назначить пользователю, являющемуся членом ролей PE1 и QE1, роль PL1. Конечно, пользователь мог стать членом и PE1, и QE1 только посредством более мощного администратора, чем PSO1.

Теперь обратимся к рассмотрению отмены моделей в URA97. Цель состоит в том, чтобы определить модель отмены, которая является совместимой с философией RBAC. Это заставляет нас отойти от классических подходов к отмене.

В типичном подходе к отмене (аннулированию) есть, по крайней мере, две проблемы, которые представляют сложность. Предположим, что Алиса предоставляет Бобу некоторые права P. Это сделано по усмотрению Алисы, потому что Алиса является или владельцем объекта, которому принадлежит P или наделена административными полномочиями на P фактическим владельцем. Алиса может позже отменить P для Боба. Теперь предположите, что Боб получил разрешение на P от Алисы и от Чарли. Если Алиса отменяет P для Боба, он все еще сохраняет права P благодаря Чарли. Связанная передача позволяет каскад отмен. Предположим, что разрешение Чарли было в свою очередь предоставлено Алисой, тогда возможно разрешение Боба должно закончиться с отменяющими действиями Алисы. А возможно и нет, потому что Алиса отменила только прямое предоставление прав Бобу, но не косвенное через Чарли, которое в действительности произошло по усмотрению Чарли. В массе литературы исследованы возникающие тонкости, особенно когда осуществлены иерархические группы и отрицательные разрешения или отрицания.

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

Теперь мы представим наше примечание для обеспечения аннулирования.

Определение 4. Модель URA97 контролирует аннулирование пользовательской роли посредством отношения can-revoke ÍARx2^R.

Значение can-revoke (x, Y) состоит в том, что член административной роли x (или член административной роли, которая является старшей оп отношению к x) может отменять членство пользователя в любой постоянной роли y Î Y. Y определяется посредством выражений в определении 3. Будем говорить, что Y определяет диапазон аннулирования.

Считается что операция аннулирования в URA97 слабая, потому что она применяется только к ролям, которые отменяются непосредственно. Предположим, что Боб - член PE1 и E1. Если Алиса отменяет членство Боба в E1, он продолжает быть членом старшей роли PE1 и поэтому может пользоваться правами роли E1. Чтобы определить понятие слабого аннулирования введем следующую терминологию. UA – отношение назначения пользователя.

Определение 5. Будем говорить, что пользователь U - явный член роли x, если (U, x) Î UA, и что U является неявным членом роли x если для некоторого x ¢ > x ( U, x ¢) Î UA.Слабое аннулирование влияет только на явное членство. Ниже указано его понятное установленное значение.

[Слабое Аннулирование] Пусть Алиса имеет сеанс с административными ролями А={ }, и пусть она попытается произвести слабое аннулирование Боба от роли x.

Пример отношения can-revoke Таблица 3

Admin. Role	Role Range
PSO1 PSO2 DSO SSO	[E1, PL1) [E2, PL2) (ED, DIR) [ED, DIR]

Пример Сильного аннулирования Таблица 4

User	E1	PE1	QE1	PL1	DIR	Alice revokes user from E1
Bob Cathy Dave Eve	Yes Yes Yes Yes	Yes Yes Yes Yes	No Yes Yes Yes	No No Yes Yes	No No No Yes	Removed from E1, PE1 Removed from E1, PE1, QE1 No effect No effect

Если Боб – не явный член x, эта операция не произведет никакого эффекта, в противном случае, если существует кортеж can-revoke (b, Y) такой, что a_iÎA, a_i³b и x Î Y, отменяется явное членство Боба в x.

Сильное аннулирование членства U в x требует, чтобы для U было отменено не только явное членство в x, но также и явное (или неявное) членство во всех ролях, старших по отношению к x. Однако сильное аннулирование в URA97 вступает в силу только в том случае, если все неявные аннулирования расположенные выше в иерархии роли находятся в пределах диапазона аннулирования административных ролей, участвующих в сеансе. Сильное аннулирование теоретически эквивалентно последовательности слабых аннулирований, но это – удобная и полезная для администраторов операция.

Рассмотрим пример can-revoke показанный в Таблице 3 и интерпретируем его в контексте иерархий на рисунках 1 и 2. Пусть Алиса будет членом PSO1, и пусть это будет единственной административной ролью, которую она имеет. Алиса уполномочена производить сильное аннулирование членства пользователей в ролях E1, PE1 и QE1. Таблица 4 иллюстрирует результат сильного аннулирования Алисой членства пользователя в роли E1. Алиса не может осуществить сильное аннулирование членства Дейва и Эви в E1, потому что они – члены старших ролей, находящихся вне полномочий Алисы на аннулирование. Если бы Алиса была назначена на роль DSO, она могла бы осуществить сильное аннулирование членства Дейва в E1, но все еще не могла бы произвести эту операцию по отношению к Эви. Чтобы осуществить сильное аннулирование членства Эви в E1, Алиса должна быть членом роли SSO.

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

[Сильное Аннулирование] Пусть Алиса имеет сеанс с административными ролями А={ }, и пусть она попытается произвести сильное аннулирование Боба от роли x. Найдем все роли y ³ x, такие что Боб – член y. Осуществим слабое аннулирование членства Боба во всех таких y, как сделала бы это Алиса. Если какое-либо из слабых аннулирований не сработает, то сильное аннулирование не будет иметь никакого эффекта, в противном случае все слабые аннулирования будут успешными.

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

Итак, мы рассмотрели каскадирование аннулирования вверх в иерархии роли. Кроме этого есть также и нисходящий эффект каскадирования. Рассмотрим Боба в нашем примере, являющегося членом E1 и PE1. Предположим далее, что Боб – явный член PE1 и таким образом неявный член E1. Что произойдет, если Алиса исключит Боба из PE1? Если мы удалим (Боб, PE1) из отношения UA, неявное членство Боба в E1 будет также удалено. С другой стороны, если Боб - явный член PE1 и также явный член E1, тогда аннулирование Алисой Боба в PE1 не удаляет его из E1. Операции аннулирования, которые мы определили в URA97, приводят к следующему эффекту.

Свойство 1. Неявное членство в роли a зависит от явного членства в некоторой старшей роли b >a. Поэтому, когда явное членство пользователя в роли b отменяется, то неявное членство в младшей роли a также автоматически отменяется, если только не существует некоторой другой старшей роли c > a, в который пользователь продолжает быть явным членом.

Обратите внимание, что наши примеры can-assign в Таблице 1 и can-revoke в таблице 3, комплементарны в том что, каждая административная роль имеет один и тот же диапазон для добавления пользователей и удаления пользователей от ролей. Хотя это было бы общим случаем, мы не навязываем это как требование к нашей модели.

Итак, URA97 контролирует назначение пользовательской роли посредством отношения can-assign ÍARxCRx2^R. Наборы ролей определяются с помощью выражений приведенных в определении 3. Назначение имеет простой характер, благодаря чему can-assign (a, b, C) разрешает сеанс с административной ролью a ¢ ³ a для назначения любому пользователю, удовлетворяющему условию необходимой предпосылки b, любой роли c Î C. Условие необходимой предпосылки – булевское выражение, использующее обычно операторы Ù и Ú над переменными вида x и` x, обозначающими соответственно членство и не-членство в постоянной роли x. Аннулирование управляется в URA97 отношением, can-revoke ÍARxCRx2^R. Слабое аннулирование применяется только для явного членства в отдельной роли. Сильное аннулирование распространяется каскадом вверх в иерархии роли. В обоих случаях аннулирования распространяются каскадом вниз как отмечено в свойстве 1.

Модель URA99

Модель URA99 основывается на модели URA97. Членство пользователя в роли может быть мобильным или стационарным. Мобильное членство пользователя u в роли x означает, что u может использовать разрешения роли x, и члены административных ролей могут использовать это членство для того, чтобы присвоить пользователя u другим ролям. Стационарное членство пользователя u в роли x означает, что u может использовать разрешения роли x, но члены административных ролей не могут использовать это членство для того, чтобы присвоить пользователя u другим ролям.

Для формализации этого различия мы полагаем, что каждая роль x содержит две подроли Mx и IMx. Членство в Mx является мобильным, а членство в IMx является стационарным. Для совместимости с URA97 мы определим набор ролей R для содержания мобильных и стационарных ролей.

Определение 6. Для данного набора ролей R1 мы определим роли для URA99: R={Mx,IMx | x Î R1}.

При помощи этого определения отношение присвоения пользователя в URA97, UAÍUxR по существу остается неизменным в URA99. Присваивание пользователя к Mx означает что пользователь – мобильный член x. Аналогично, присваивание пользователя к IMx означает, что пользователь является стационарным членом x.

Комбинируя мобильное и стационарное членство с понятием явного и неявного членства, дает нам четыре отдельных типа ролевого членства в URA99.

Определение 7. Для любой роли x существуют 4 типа членства пользователь-роль.

1. Явный мобильный член EMx: uÎEMxº(u,Mx)ÎUA

2. Явный стационарный член EIMx: uÎEIMxº(u,IMx)ÎU0041

3. Неявный мобильный член ImMx: uÎImMxº($x’>x)(u,Mx’)ÎUA

4. Неявный стационарный член ImIMx: uÎImIMxº($x’>x)(u,IMx’)ÎUA

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

EMx>EIMx>ImMx>ImIMx

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

Рис. 3. Наследование мобильности и стационарности.

Для объяснения наследования мобильного и стационарного членства в роли, мы первым делом рассмотрим иерархию двух ролей показанных на рис. 3(а) где роль x1 является старшей по отношению к роли x2. Пользователь Алиса, являющаяся явным мобильным членом роли x1 (Алиса Î EMx1) является неявным мобильным членом x2 (Алиса Î ImMx2). Аналогично наследование применяется для стационарных пользователей. Следовательно, если Боб является явным стационарным членом роли x1 (Боб Î EIMx1) он также является неявным стационарным членом роли x2 (Боб Î ImIMx2).

Далее рассмотрим иерархию ролей на рис. 3(b). Пусть Боб будет явным мобильным членом роли x1 и явным стационарным членом роли x2. Теперь Боб является неявным мобильным членом роли x3 (т.к. он явный мобильный член в x1) и является неявным стационарным членом роли x3 (т.к. он явный стационарный член в x2). Следуя правилу превосходства мобильное членство сильнее, чем стационарное. Это означает, что Боб будет иметь неявное мобильное членство в роли x3.

Наконец, рассмотрим иерархию ролей на рис. 3(с). Пусть Боб – явный мобильный член роли x3. Таким образом, Боб – неявный мобильный член ролей x1 и x2 в иерархии. Пусть Боб – явный стационарный член x2. Тогда по правилу превосходства Боб будет стационарным в x2, несмотря на то, что он мобильный в x1. Явное стационарное членство Боба перекрывает неявное мобильное членство.

Значение предварительного условия в URA97 довольно-таки открыто, так как определение членства роли – простое. В URA99 нам нужно интерпретировать предварительное условие в терминах мобильного/стационарного и явного/неявного членства. В URA99 предварительные условия определены в терминах x и (не x) как и в URA97 (лучше, чем в терминах Mx, IMx, не Mx и не IMx). Членство и отсутствие членства в роли интерпретируем ниже.

Определение 8. В модели предоставления URA99 предварительное условие оценивается для пользователя u, интерпретируя значение x как истину, если: uÎEMxÈ(uÎImMxÇuÏEIMx), и значение (не x) как правду, если: uÏEMxÇuÏEIMxÇuÏImMxÇuÏImIMx

Другими словами x обозначает мобильное членство (явное или неявное), а (не x) обозначает отсутствие какого-либо членства. Заметим невозможность истинности одновременно x и (не x). Однако они могут быть ложью одновременно (когда uÎEIMx и uÏEMx).

Отношение can-assign URA97 заменяется двумя следующими отношениями.

Определение 9. Присвоение пользователя роли как мобильного члена авторизуется отношением can-assign-MÍARxCRx2^R, а как немобильного члена отношением can-assign-IMÍARxCRx2^R.

Значение can-assign-M(x,y,Z) состоит в том, что член административной роли x (или член административной роли старшей, чем x) может присваивать пользователя, чье текущее членство, или отсутствие членства в обычных ролях удовлетворяет предпосылке y, обычной роли zÎZ как мобильного члена. Значение can-assign-IM(x,y,Z) в том, что член административной роли x (или член административной роли старшей, чем x) может присваивать пользователя, чье текущее членство (или его отсутствие) в обычных ролях удовлетворяет предпосылке y, обычной роли zÎZ как стационарного пользователя.

Примеры can-assign-M и can-assign-IM показаны в Таблицах 3 и 4.

Администраторская роль	Предварительное условие	Диапазон ролей
PSO1	ED	[E1,PL1)
PSO2	ED	[E2,PL2)
DSO	EDÇnot (PL2)	[PL1,PL1]
DSO	EDÇnot (PL1)	[PL2,PL2]
SSO	ED	(ED,DIR]
SSO	E	[ED,ED]

 

Администраторская роль	Предварительное условие	Диапазон ролей
PSO1	ED	[E1,PL1)
PSO2	ED	[E2,PL2)
DSO	EDÇnot (PL2)	[PL1,PL1]
DSO	EDÇnot (PL1)	[PL2,PL2]
SSO	ED	(ED,DIR]
SSO	E	[ED,ED]
DSO	E	[ED,ED]

Таблица 3 идентична Таблице 1. Конечно, предварительное условие теперь интерпретируется по-другому. Верхние 6 строк Таблицы 4 повторяют Таблицу 3. Это означает, что мобильное или стационарное членство предоставляется по усмотрению отдельных администраторов. URA99 требует, чтобы авторизация на предоставление мобильного или стационарного членства была явно определена в этой манере. Последняя строка Таблицы 4 авторизует DSO записывать любого работника как стационарного члена ED. DSO не имеет полномочий на запись работников в качестве мобильных членов ED. Эта возможность принадлежит SSO. В этом примере DSO может записывать работника как стационарного члена ED, а позже SSO может продвинуть его членство до мобильного.

Модель аннулирования URA99

Модель аннулирования URA99 фиксирует недостаток симметрии между моделями предоставления и аннулирования в URA97 которая довольно-таки независима от мобильности. Она также имеет дело с аннулированием мобильного и стационарного членства.

В URA97 отношение can-assign включает предварительные условия, но can-revoke – нет. Чтобы увидеть полезность предварительных условий в этом контексте рассмотрим случай, когда PSO1 контролирует присвоение пользователя роли в проекте 1. Если Боб член E1 тогда PSO1 может присвоить Боба к любой роли в проекте 1, то есть E1, PE1 и QE1. Эти присвоения управляются отношением can-assign. Предположим, что PSO1 не хочет, чтобы Боб был членом любой роли вне проекта 1, т.к. его членство в других ролях снизят эффективность его работы. Если Боб присвоен роли, которая попадает за проект 1, то PSO1 должен иметь право чтобы аннулировать членство. URA97 не предоставляет такое право аннулирования роли. Предварительные условия в can-revoke – единственное, что может предоставить эту возможность.

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

Определение 10. Модель URA99 авторизует аннулирование мобильного членства посредством отношения can-revoke-MÍARxCRx2^R и аннулирование стационарного членства посредством отношения can-revoke-IMÍARxCRx2^R.

Значение can-revoke-M(x,y,{a,b,c}) состоит в том, что член административной роли x (или член административной роли старшей, чем x) может аннулировать мобильное членство пользователя в ролях a,b,c в зависимости от предварительного условия y. Аналогично для can-revoke-IM.

Пример данных отношений приведен в Таблицах 5 и 6.

Администраторская роль	Предварительное условие	Диапазон ролей
PSO1	E	[E1,PL1)
PSO2	E	[E2,PL2)
DSO	E	(ED,DIR)
SSO	E	(ED,DIR]
PSO1	E1	[E2,PL2)
PSO2	E2	[E1,PL1)

 

Администраторская роль

Предварительное условие

Диапазон ролей

123	Поделиться: