Моделирование систем защиты информации Лабораторная работа №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¹.

Чтобы оценить мотивацию отношения 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 в столбцеRoleSet набора роли. В этом примере присутствует простейшее условие необходимой предпосылки испытания членства в отдельной роли, известной как роль необходимой предпосылки.

Роль 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 в столбце RoleRangeдиапазона ролей. СтолбцыRoleSet иRoleRangeТаблицы 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.