Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Расширенная модель Take-Grant 6 страница




для u Î U, если r, r ’ Î AR, r Î AUA (u) и r ’ ≤ r, то r ’Î AUA (u).

Общая структура элементов модели администрирования ролевого управления доступом имеет следующий вид (рис. 10.1).

Административные роли по своему назначению могут быть разделены на три группы:

- администрирование множеств авторизованных ролей пользователей;

- администрирование множеств прав доступа, которыми обладает роли;

- администрирование иерархии ролей.

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

 

Администрирование множеств авторизованных ролей пользователей

При администрировании множеств авторизованных ролей пользователей изменяются значения функции UA, для чего определяются специальные административные роли из множества AR. При этом следует задать:

- для каждой административной роли множество ролей, множества авторизованных пользователей которых она позволяет изменять;

 

 

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

Рассмотрим пример.

Пример 10.1. Пусть заданы иерархия ролей (рис. 10.2(а)) и иерархия административных ролей (рис. 10.2(б)).

Минимальная роль в иерархии ¾ служащий (E). Иерархия ролей разработчиков проектов имеет максимальную роль ¾ директор (DIR), и минимальную роль ¾ инженер (ED). В организации выполняются работы по двум проектам. В каждом проекте заданы максимальная роль ¾ руководитель проекта (PL 1, PL 2 соответственно), минимальная роль ¾ инженер проекта (E 1, E 2 соответственно) и несравнимые между собой роли ¾ инженер по производству (PE 1, PE 2 соответственно) и инженер по контролю (QE 1, QE 2 соответственно). Иерархия административных ролей состоит из четырех ролей с максимальной ролью ¾ старший офицер безопасности (SSO).

 

В рассматриваемом примере административная роль PSO 1 позволяет включать во множества авторизованных ролей пользователя роли PE 1, QE 1, E 1. При этом для того, чтобы любая из перечисленных ролей могла быть включена во множество авторизованных ролей пользователя, он уже должен обладать ролью ED. ■

Для роли x Î R обозначим:

x: U → { false, true } ¾ булева функция такая, что по определению для пользователя u Î U справедливо равенство x (u) = true тогда и только тогда, когда x Î UA (u).

Определение 10.2. Предварительным условием для роли r Î R называется булева функция cr: U → { false, true } такая, что по определению для пользователя u Î U справедливо равенство cr (u) = cr (x 1(u), …, xk (u)), где u Î U, x 1, …, xk Î R и cr (y 1, …, yk) ¾ булева функция от k булевых переменных. При этом роль r Î R может быть включена во множество авторизованных ролей пользователя u Î U, если cr (u) = true.

Обозначим через CR все предварительные условия для ролей из R.

Определение 10.3. Для администрирования множеств авторизованных ролей пользователей на множестве административных ролей задаются функции:

- can-assignr: AR ® CR ´ 2 R ¾ функция, задающая для каждой административной роли множество ролей, которые могут быть включены во множество авторизованных ролей пользователя с использованием данной административной роли при выполнении заданных предварительных условий;

- can-revoker: AR ® 2 R ¾ функция, задающая для каждой административной роли множество ролей, которые могут быть исключены из множества авторизованных ролей пользователя с использованием данной административной роли.

Как правило, множество ролей, являющееся значением функций can-assignr или can-revoker, задается интервалом ролей одного из четырех видов:

- [ x, y ] = { x ’Î R, где x £ x ’и x ’£ y };

- (x, y ] = { x ’Î R, где x < x ’и x ’£ y };

- [ x, y) = { x ’Î R, где x £ x ’и x ’< y };

- (x, y) = { x ’Î R, где x < x ’и x ’< y },

где x, y Î R.

Пример 10.2. Рассмотрим иерархию ролей и иерархию административных ролей из примера 10.1. Зададим значения функций can-assignr (табл. 10.1) и can-revoker (табл. 10.2) соответственно для административных ролей PSO1, PSO2 и DSO.

 

Таблица 10.1. Значения функции can-assignr

Административная роль Предварительное условие Множество ролей
PSO 1 ED [ E 1, PL 1)
PSO 2 ED [ E 2, PL 2)
DSO ED and (not PL 1) [ PL 2, PL 2]
DSO ED and (not PL 2) [ PL 1, PL 1]

 

Таблица 10.2. Значения функции can-revoker

Административная роль Множество ролей
PSO 1 [ E 1, PL 1)
PSO 2 [ E 2, PL 2)
DSO (ED, DIR)

 

Таким образом, административная роль PSO 1позволяет включить для пользователя, уже обладающего ролью ED,во множество его авторизованных ролей роли E 1, PEQE 1. Административная роль DSO позволяет включить для пользователя, уже обладающего ролью ED,во множество его авторизованных ролей роль PL 1, при этом данный пользователь не должен обладать ролью PL 2. ■

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

Кроме того, значения функции can-revoker определяются в общем случае без учета иерархии ролей. Следовательно, может оказаться, что для некоторой административной роли разрешено удаление роли r Î R из множества авторизованных ролей UA (u) пользователя u Î U. Если при этом найдется роль r ’Î R такая, что rr ’ и r ’ Î UA (u), то удаление роли r из множества авторизованных ролей пользователя u не будет иметь эффекта, так как права доступа роли r являются подмножеством прав доступа роли r ’, авторизованным пользователем которой останется пользователь u.

Одним из путей решения данной проблемы может являться каскадное удаление. При каскадном удалении, если роль r удаляется из множества авторизованных ролей пользователя, то из этого множества должны быть удалены все роли r ’ такие, что rr ’. Однако если для некоторой административной роли ar Î AR выполняются условия r Î can-revoker (ar), r ’ Ï can-revoker (ar), то каскадное удаление будет невозможно. Таким образом, порядок задания значений функции can-revoker и процедура удаления роли из множества авторизованных ролей пользователя требуют дополнительного уточнения.

 

Администрирование множеств прав доступа, которыми обладает роли

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

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

Определение 10.4. Для администрирования множеств прав доступа, которыми обладает роли, на множестве административных ролей задаются:

- can-assignp: AR ® CR ´ 2 R ¾ функция, задающая для каждой административной роли множество ролей, для которых разрешено включать права доступа во множества прав доступа с использованием данной административной роли при выполнении заданных предварительных условий;

- can-revokep: AR ® 2 R ¾ функция, задающая для каждой административной роли множество ролей, для которых разрешено удаление прав доступа из множеств прав доступа с использованием данной административной роли.

Пример 10.3. Рассмотрим иерархию ролей и иерархию административных ролей из примера 10.1. Зададим значения функций can-assignp (табл. 10.3) и can-revokep (табл. 10.4) соответственно для административных ролей PSO1, PSO2 и DSO.

 

Таблица 10.3. Значения функции can-assignp

Административная роль Предварительное условие Множество ролей
DSO DIR [PL1, PL1]
DSO DIR [PL2, PL2]
PSO 1 PL1 and (not QE1) [PE1, PE1]
PSO 1 PL1 and (not PE1) [QE1, QE1]
PSO 2 PL2 and (not QE2) [PE2, PE2]
PSO 2 PL2 and (not PE2) [QE2, QE2]

 

Таблица 10.4. Значения функции can-revokep

Административная роль Множество ролей
DSO (ED, DIR)
PSO1 [QE1, QE1]
PSO1 [PE1, PE1]
PSO2 [QE2, QE2]
PSO2 [PE2, PE2]

 

Таким образом, административная роль DSO позволяет включить права доступа, входящие во множество прав доступа роли DIR, во множества прав доступа ролей PL 1, PL 2. При чем данные права доступа могут быть включены во множества прав доступа ролей, находящихся ниже PL 1, PL 2 по иерархии. Административная роль PSO 1позволяет включить права доступа, входящие во множество прав доступа роли PL 1, во множества прав доступа ролей PE 1 и QE 1, но только в каждую по отдельности. Административная роль DSO позволяет удалять права доступа из множеств прав доступа ролей, находящихся в иерархии между ролями ED и DIR, а административная роль PSO 1позволяет удалять права доступа из множеств прав доступа ролей PE 1 и QE 1. ■

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

 

Администрирование иерархии ролей

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

- возможности ¾ множества прав доступа и других возможностей;

- группы ¾ множества пользователей и других групп;

- объединения ¾ множества пользователей, прав доступа, групп, возможностей и других объединений.

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

На основе иерархий возможностей, групп и объединений задается иерархия ролей, элементами которой являются роли-возможности, роли-группы, роли-объединения (UP -роли).

Определение 10.5. Роли-возможности ¾ роли, которые обладают только заданные в соответствующей возможности правами доступа.

Определение 10.6. Роли-группы ¾ роли, на которые могут быть авторизованы одновременно только все пользователи соответствующей группы.

Определение 10.7. Роли-объединения ¾ роли, которые обладают возможностями, правами доступа, и, на которые могут быть авторизованы группы пользователей и отдельные пользователи.

Роли-объединения являются общим случаем ролей, рассматриваемых в модели администрирования ролевого управления доступом.

Определение 10.8. Роль-объединение r 1в иерархии ролей превосходит роль-объединение r 2, если выполняются условия:

- возможности и права доступа роли r 2являются подмножеством возможностей и прав доступа роли r 1,

- пользователи и группы пользователей, которые могут быть авторизованы на роль r 1, являются подмножеством множества пользователей и групп пользователей, которые могут быть авторизованы на роль r 2.

Определение 10.9. Для администрирования возможностей и групп пользователей на множестве административных ролей задаются функции:

- can-assigna: AR ® CR ´ 2 UPR ¾ функция, задающая для каждой административной роли множество ролей-объединений, во множество прав доступа которых разрешено включать возможности с использованием данной административной роли при выполнении заданных предварительных условий;

- can-revokea: AR ® 2 UPR ¾ функция, задающая для каждой административной роли множество ролей-объединений, из множества прав доступа которых разрешено удаление возможностей с использованием данной административной роли;

- can-assigng: AR ® CR ´ 2 UPR ¾ функция, задающая для каждой административной роли множество ролей-объединений, которые разрешено включать во множество авторизованных ролей групп пользователей с использованием данной административной роли при выполнении заданных предварительных условий;

- can-revokeg: AR ® 2 UPR ¾ функция, задающая для каждой административной роли множество ролей-объединений, которые разрешено удалять из множество авторизованных ролей групп пользователей с использованием данной административной роли.

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

Необходимость определения иерархий возможностей и групп обусловлена также тем, что построенные на их основе правила администрирования отличны друг от друга. Предварительные условия, заданные в функции can-assigna, используется аналогично предварительным условиям, заданным в функции can-assignp, а предварительные условия, заданные в функции can-assigng, используется аналогично предварительным условиям, заданным в функции can-assignr. Например, для того, чтобы во множество прав доступа роли-объединения была включена возможность, данная возможность должна входить во множества прав доступа ролей, указанных в предварительном условии функции can-assigna. А для того, чтобы роль-объединение была включена во множество авторизованных ролей группы пользователей, пользователи данной группы должны уже обладать ролями в соотвествии с предварительным условием функции can-assigng.

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

Определение 10.10. Для администрирования иерархии ролей (добавления и удаления ролей, включение или удаление отношений иерархии) на множестве административных ролей задается

can-modify: AR ® 2 UPR ¾ функция, определяющая для каждой административной роли интервал ролей (исключая границы интервала), на котором возможно изменение иерархии ролей с использованием данной административной роли.

Пример 10.4. Рассмотрим иерархию ролей и иерархию административных ролей из примера 10.1. Определим значения функции can-modify (табл. 10.5) для административных ролей PSODSO.

 

Таблица 10.5. Значения функции can-modify

Административная роль Множество ролей
PSO 1 (E 1, PL 1)
DSO (ED, DIR)

 

Таким образом, административные роли PSODSO позволяют изменять иерархию ролей на интервалах, соответственно, (E 1, PL 1) и (ED, DIR). ■

Описанные способы задания правил администрирования иерархии ролей в общем случае требуют уточнения. Так, например, возможно возникновение следующей ситуации. Пользователь с административной ролью DSO удаляет из иерархии роль PL 1. В то же время роль PL 1 входит в предварительные условия и участвует в определении интервалов значений функций can-assignr и can-revoker. Таким образом, для административной роли DSO должно быть запрещено удаление ролей, участвующих в задании значений и предварительных условий функций администрирования.

Кроме того, возможна следующая ситуация. Рассмотрим пример.

Пример 10.5. Рассмотрим иерархию ролей и иерархию административных ролей из примера 10.1, и функцию can-modify, значения которой заданы в соответствии с табл. 10.5 (рис. 10.3).

 

 

Предположим, что пользователь с административной ролью DSO добавил в иерархию ролей роли X и Y. Так как пользователь с административной ролью PSO 1 может изменять иерархию ролей на интервале ролей (E 1, PL 1), пусть он определит роль QE 1 как старшую над ролью PE 1. Таким образом, административная роль PSO 1 позволяет задать роль X старшей над ролью Y, несмотря на то, что эти роли не входят в определенный для PSO 1 интервал (E 1, PL 1).

Возможна реализация нескольких подходов по определению порядка администрирования иерархии ролей в данной ситуации. Во-первых, можно запретить пользователю с административной ролью DSO добавлять роли X и Y, так как это нарушает целостность интервала (E 1, PL 1), на котором разрешено администрирование для роли PSO 1. Во-вторых, можно запретить пользователю с административной ролью PSO 1 определять роль QE 1 старшей над ролью PE 1. В-третьих, можно разрешить выполнять все запрашиваемые действия с использованием административных ролей DSO и PSO 1. ■

 

Модель мандатного ролевого управления доступом

Защита от угрозы конфиденциальности информации

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

Рассмотрим подход, реализующий мандатное управление доступом на основе базовой модели ролевого управления доступом.

Используем следующие обозначения:

U ¾ множество пользователей (субъектов);

O ¾ множество объектов;

(L, £) ¾ решетка уровней конфиденциальности;

c: U ® L ¾ функция уровней доступа пользователей;

c: О ® L ¾ функция уровней конфиденциальности объектов;

A = { read, write } ¾ виды доступа.

Будем различать два вида мандатного управления доступом: либеральный и строгий (в смысле Белла-ЛаПадулы).

Определение 10.11. Доступ (s, (o, r))Î S ´ P является безопасным для либерального мандатного управления доступом, если выполняется одной из условий:

- r = read и c (user (s)) ³ c (o) (ss -свойство);

- r = write и, если существует доступ (s, (o ’, read)) Î S ´ P, то c (o) ³ c (o ’) (либеральное *-свойство).

Определение 10.12. Доступ (s, o, r) Î S ´ P является безопасным для строгого мандатного управления доступом, если выполняется одной из условий:

- r = read и c (user (s)) ³ c (o) (ss -свойство);

- r = write и, если существует доступ (s, (o ’, read)) Î S ´ P, то c (o) = c (o ’) (строгое *-свойство).

Построим систему ролевого управления доступом. Пусть

R = { x _ read | x Î L } È { x _ write | x Î L } ¾ множество ролей;

P = {(o, read) | o Î O } È {(o, write) | o Î O } ¾ множество прав доступа.

Зададим на множестве ролей R иерархию, при этом иерархии ролей на множествах { x _ read | x Î L } и { x _ write | x Î L } будут независимы.

Определение 10.13. Иерархией на множестве ролей R в соответствии с требованиями либерального мандатного управления доступом называется отношение частичного порядка «≤», где для ролей r, r ’ Î R справедливо неравенство rr ’, если выполняется одно из условий:

- r = x _ read, r ’= x ’_ read и xx ’;

- r = x _ write, r ’= x ’_ write и x ’≤ x.

Определение 10.14. Иерархией на множестве ролей R в соответствии с требованиями строгого мандатного управления доступом называется отношение частичного порядка «≤», где для ролей r, r ’ Î R справедливо неравенство rr ’, если выполняется одно из условий:

- r = x _ read, r ’= x ’_ read и xx ’;

- r = x _ write, r ’= x ’_ write и x = x ’ (каждая роль вида x _ write сравнима только сама с собой).

Определение 10.15. Модель ролевого управления доступом соответствует требованиям либерального мандатного управления доступом, если иерархия на множестве ролей R соответствует требованиям определения 10.14, и выполняются ограничения:

- ограничение функции UA ¾ для каждого пользователя u Î U роль x _ read = Å(UA (u) Ç { y _ read | y Î L }) Î UA (u) (здесь x ­ = c (u)) и { y _ write | y Î L } Ì UA (u);

- ограничение функции roles ¾ для каждой сессии s Î S справедливо равенство roles (s) = { y _ read | y Î L, y £ x } È { x _ write };

- ограничение функции PA ¾ должно выполняться:

· для каждого x Î L доступ (o, read) Î PA (x _ read) тогда и только тогда, когда доступ (o, write) Î PA (x _ write);

· для каждого доступа (o, read) Î P существует единственная роль x _ read: (o, read) Î PA (x _ read) (здесь x ­ = c (o)).

Определение 10.16. Модель ролевого управления доступом соответствует требованиям строгого мандатного управления доступом, если иерархия на множестве ролей R соответствует требованиям определения 10.15, и выполняются ограничения:

- ограничение функции UA ¾ для каждого пользователя u Î U роль x _ read = Å(UA (u) Ç { y _ read | y Î L }) Î UA (u) (здесь x ­ = c (u)) и { y _ write | y Î L } Ì UA (u);

- ограничение функции roles ¾ для каждой сессии s Î S справедливо равенство roles (s) = { x _ read, x _ write };

- ограничение функции PA ¾ должно выполняться:

· для каждого x Î L доступ (o, read) Î PA (x _ read) тогда и только тогда, когда доступ (o, write) Î PA (x _ write);

· для каждого доступа (o, read) Î P существует единственная роль x _ read: (o, read) Î PA (x _ read) (здесь x ­ = c (o)).

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

В рамках модели мандатного ролевого управления доступом дадим определение информационного потока.

Определение 10.17. Будем считать, что существует информационный поток от объекта o Î O к объекту o ’ Î O тогда и только тогда, когда существуют роли r, r ’ Î R, сессия s Î S такие, что (o, read) Î PA (r), (o ’, write) Î PA (r ’) и r, r ’ Î roles (s).




Поделиться с друзьями:


Дата добавления: 2014-11-20; Просмотров: 935; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.073 сек.