Семантическая ролевая модель управления доступом | ПДМ. 2012. № 2(16).

Семантическая ролевая модель управления доступом

Приводится описание расширения ролевой модели RBAC, используемой дляуправления доступом в автоматизированную информационную систему (АИС)предприятия, за счёт введения семантического контекста, позволяющего отразить взаимосвязь между должностными обязанностями сотрудников и ролями,назначенными соответствующим им учётным записям пользователей в системе.Основное отличие модели - возможность автоматизации операций назначения иотзыва ролей. Приведено доказательство безопасности системы ролевого управления доступом, построенной на основе предложенной семантической модели.

Semantic Role Based Access Control Model.pdf ВведениеМодель ролевого управления доступом RBAC [1] применяется для построения си-стем управления доступом в АИС. Одной из особенностей классической модели R B ACявляется то, что все операции по назначению и отзыву ролей выполняются вручнуюадминистраторами системы. При большом количестве ролей в АИС нагрузка на ад-министраторов возрастает, что может привести к увеличению времени, необходимомудля обеспечения пользователя АИС, соответствующего некоторому сотруднику пред-приятия, всеми нужными ему для выполнения должностных обязанностей правамидоступа [2]. В данной работе предлагается ролевая модель управления доступом, осно-ванная на классической модели и позволяющая автоматизировать назначение и отзывролей учётным записям пользователей при наступлении в системе ряда определённыхсобытий.1. Основные понятия и определения классической модели RBACРассмотрим некоторые основные понятия классической модели RBAC, которыепотребуются для дальнейшего описания [3]:P - множество возможных прав доступа;U - множество учётных записей пользователей системы;R С 2P - множество ролей системы;UA : U ^ 2r - функция, задающая для каждой учетной записи пользователямножество ролей, на которые она может быть авторизована;PA : R ^ 2P - функция, задающая для каждой роли множество прав доступа.При этом для каждого права доступа р Е Р существует роль rER, такая, что pEPA(r);user : S ^ U - функция, задающая для каждой сессии учётную запись, от именикоторой она авторизована.Определение 1. Иерархией ролей в классической модели ролевого управлениядоступом называется заданное на множестве ролей R отношение частичного поряд-ка При этом по определению выполняется условие: для учётной записи пользова-теля u Е U если r1 ,r2 Е R, r1 Е UA(u) и r1 ^ r2, то r2 Е UA(u).Зададим RH С R х R - иерархическое отношение на множестве ролей - следую-щим образом: (r1 ^ r2) ^ ((r1 , r 2 ) Е RH). Если r1 ^ r2, то r1 считается старшей поотношению к r2 (предком r2 ), а r2 -младшей (потомком r1).Определение 2. Два права доступа р 1 , р 2 Е Р называются статически взаимоис-ключающими, если они не могут входить в состав одной и той же роли одновременно:для любой r Е R выполняется неравенство { р 1 , р 2 } П P A ( r ) ^ 1.Определение 3. Две роли r1 , r 2 Е R называются статически взаимоисключаю-щими, если они не могут быть назначены одной учётной записи пользователя одно-временно: для любой u Е U выполняется неравенство { r 1 , r 2 } П UA(u) ^ 1.Определение 4. Множество предварительных условий CR - это множество,включающее в себя ограничения на роли, которыми должна обладать учётная записьпользователя, чтобы быть назначенной на новую роль, а также ограничения взаимногоисключения ролей. Пусть zr : U ^ { f a l s e , t r u e } - функция, такая, что zr(u) = trueтогда и только тогда, когда для u Е U и r Е R выполняется условие r Е UA(u). Пустьcr : U ^ { f a l s e , t r u e } - функция, такая, что cr (u) = cr (zr i ( u ) , . . . , z r k (u)), где u Е U;r, r 1 , . . . , ^ Е R; r = r для i = 1 , . . . , k и cr ( y 1 , . . . , ук) - булева функция от k пере-менных. Тогда CR = { c r i , . . . , c r t } - множество функций, определяющих, при какихусловиях той или иной учётной записи пользователя может быть назначена некотораяроль rj Е R.Для обеспечения возможности администрирования множества назначенных учёт-ным записям пользователей ролей используем следующие функции, определённыев стандарте ARBAC'97 [4]:- AP - множество административных прав доступа;- AR С 2 a p - множество административных ролей;- A P A : AR ^ 2 a p - функция, задающая для каждой административной роли мно-жество административных прав доступа; при этом для каждого права доступар Е AP существует роль r Е AR, такая, что р Е A P A ( r );- AUA : U ^ 2 a r - функция, задающая для каждой учётной записи пользователямножество административных ролей, на которые она может быть авторизована;- can_assign : AR ^ CR х 2R - функция, определяющая для каждой администра-тивной роли множество ролей, которые могут быть назначены учётной записипользователя с использованием данной административной роли при выполнениизаданных предварительных условий CR;- rnn^evoke : AR ^ 2R - функция, определяющая для каждой административнойроли множество ролей, которые могут быть отозваны у учётной записи пользова-теля с использованием данной административной роли;- ro/es : S ^ 2r U AR - функция, задающая для учётной записи пользователя мно-жество ролей, на которые она авторизована в данной сессии. При этом в каж-дый момент времени для каждой сессии s Е S выполняется условие ro/es(s) ЕЕ UA(user(s)) U AUA(user(s)).Определение 5. Под классической системой ролевого управления доступом бу-дем понимать конечный автомат, заданный кортежем K = (Г, Q, а, Ф), где Г - множе-ство состояний; Q - множество запросов на доступ к объектам АИС; Ф - множестводействий, переводящих систему из состояния в состояние; a : Г х Q ^ { t r u e , f a l s e } -функция, определяющая, является ли запрос истинным в заданном состоянии. Состо-яние системы задаётся кортежем 7 = (S, U, UA,user, ro/es) Е Г, а правила переходамежду состояниями определяются предварительными условиями CR.Таким образом, классическая модель R B A C не содержит в себе информацию освязи между должностными обязанностями пользователей и ролями, назначеннымиих учётным записям (о семантическом смысле назначения ролей). Ещё одним важнымограничением классической модели R B A C является то, что роли всегда назначают-ся и отзываются сессией, инициированной некоторой учётной записью пользователясистемы, обладающей административными правами, и не могут быть назначены (ото-званы) при наступлении заданного события, поскольку модель не содержит в себесредств описания событий и логики реакции на них. Далее описаны предлагаемыерасширения классической модели за счёт введения семантического контекста.2. Семантическая ролевая модель управления доступом2.1. И е р а р х и я р о л е й « п о п р е д у с л о в и ю »В классической модели R B A C считается, что родительская роль содержит в се-бе все права дочерних ролей, а также более высокопривилегированные права досту-па, чем дочерние (например, роль «Начальник отдела» является родительской дляроли «Рядовой сотрудник» и содержит как все права доступа, назначенные рядо-вым сотрудникам, так и права, которыми обладают только руководители структур-ной единицы предприятия). В реальных АИС иерархические отношения между ро-лями обычно имеют следующий смысл [5]: меньшая роль описывает некоторые ба-зовые права доступа к объекту, а родительские роли - более функциональные пра-ва доступа. В качестве примеров таких АИС можно привести службу каталоговActiveDirectory [5], где базовым правом доступа является включение учётной записив домен (роль DomainUsers), а также СУБД Orac/e [6], содержащую базовые правадоступа C O N N E C T и C R E A T E S E S S I O N , разрешающие создание соединения с ба-зойданных (роль DatabaseUser). Таким образом, родительские роли в общем случаене включают в себя права доступа дочерних ролей. В то же время можно показать,что в классической модели R B A C существует неявно выраженная зависимость междупредварительными условиями назначения ролей, находящихся в иерархической свя-зи друг с другом. Пусть в классической модели R B A C роль r1 является старшейдля роли r2. Тогда, по определению 1, для учётной записи пользователя u Е U если( r 1 , r 2 ) Е RH, r1 Е UA(u) и r1 ^ r2, то r2 Е UA(u). В этом случае можно утверждать,что учётная запись пользователя u удовлетворяет условиям: если cr i (u) = true, тоcr2 (u) = true, в противном случае роль r2 не могла бы быть назначена учётной записипользователя. Таким образом, существует неявным образом выраженная зависимостьмежду предварительными условиями назначения ролей r1 и r2.Переопределим иерархические связи между ролями, используя описание множе-ства предварительных условий CR.Определение 6. Иерархией ролей «по предусловию» будем называть заданноена множестве ролей R отношение строгого порядка >. При этом для учётной записипользователя u Е U если (r1 , r 2 ) Е RH, r1 > r2 и cr i (u) = true, то cr2 (u) = true иcr i (u) = cr i ( z 1 ( u ) , . . . , cr2 ( u ) , . . . , гк (u)). Роль r1 будем называть предком r2 «по пред-условию».Таким образом, по определению, для возможности авторизации на некоторую рольучётная запись пользователя должна удовлетворять и всем предварительным услови-ям для дочерней роли.П р е д п о л о ж е н и е 1. В данной работе предполагается, что в модели действуютограничения статического взаимного исключения прав доступа для ролей, состоящихв иерархических отношениях: для каждого множества ролей, состоящих в иерархии,каждое право доступа может входить в состав только одной роли: Р = PA(r1 ) U UUP A ( r m ) , где (r,, r,) Е RH; PA(r,) П P A f o ) = 0 для 1 ^ i < j ^ m, r,, r, Е R.П р е д п о л о ж е н и е 2. Будем считать, что если для некоторой административнойроли ra Е AR и роли r Е R выполняется условие r Е rnn_revoke(ra), то для каждойроли ro Е R, такой, что r0 > r, выполняется условие r0 Е mn_revoke(ra ).Сформулируем ряд утверждений, описывающих свойства ролевой модели управ-ления доступом, в которой выполняются условия предположений 1 и 2, а иерархияролей строится по определению 6.1) Отзыв у учётной записи пользователя родительской роли не влечёт за собой ав-томатического отзыва всех дочерних ролей, поскольку множества прав доступа, вхо-дящих в родительскую и дочерние роли, не пересекаются (не выполняется требование,справедливое для классической модели: если r1 ^ r2, то PA(r1 ) D PA(r2 ) ).2) Отзыв дочерней роли приводит к отзыву всех родительских ролей. По определе-нию 6, при удалении у учётной записи пользователя u некоторой роли r для u переста-ют выполняться предварительные условия для всех ролей, родительских для r. Этоозначает, что в результате удаления r у учётной записи пользователя одновременно от-зываются и все родительские для r роли. Для возможности каскадного удаления ролейу учётной записи пользователя необходимо выполнение условий предположения 2.3) Каскадное назначение прав на отзыв административным ролям в направлении«снизу вверх» не влечёт за собой превышения прав доступа административных поль-зователей, поскольку родительские роли не включают в себя права доступа дочернихролей.Определение 7. Пусть I N I T : Ф ^ 2U - функция, задающая для каждого дей-ствия а Е Ф множество возможных инициаторов его выполнения. Говорим, что субъ-екты (учётные записи) из множества значений функции I N I T ( а ) С U могут бытьинициаторами действия а Е Ф, переводящего систему ( Г , ^ , а , Ф) из состояния Y Е Гв состояние Yg Е Г, если сессии, функционирующие от имени данных субъектов, мо-гут выполнить действие а Е Ф, приводящее к переходу модели из состояния 7 Е Гв состояние Yg Е Г, т. е. если существует действие а Е Ф, для которого выполняютсяследующие условия:- т й ( а ) Е I N I T ( а ) , где init : Ф ^ U - функция, такая, что т й ( а ) = user(s), еслисессия s выполнила действие а;- а1 ( 7 ) = Yg.Таким образом, для каждого возможного действия в системе значение функцииI N I T - это совокупность учётных записей пользователей, обладающих в рамках за-данной сессии s административными правами, позволяющими им выполнить дан-ное действие. Будем использовать обозначение I N I T ( а 1 , а 2 , . . . , а,) = I N I T ( а 1 ) хx I N I T (а2) х х I N I T (а,).П р и м е р 1. Множество учётных записей пользователей, обладающих возможно-стью назначить роль r Е R учётной записи пользователя u Е U, задаётся выражением{ua Е U : ua Е A U A ( c a n _ a s s i g n - 1 (cr ( u ) , r ) ) } , где cr Е CR - предварительное условие,определяющее, может ли роль r быть назначена учётной записи пользователя u.2.2. А т р и б у т ы у ч ё т н о й з а п и с и п о л ь з о в а т е л яДадим определение семантически осмысленной ролевой модели, являющейся рас-ширением классической модели ролевого управления доступом. Введём следующиедополнительные обозначения:- A - множество атрибутов учётных записей пользователей. Элементами A являют-ся атрибуты, характеризующие положение сотрудника, соответствующего учётнойзаписи пользователя АИС, в организационно-штатной структуре предприятия, егодолжность и другие признаки, позволяющие определить его служебные обязанно-сти. Например, A = { a 1 , a 2 } = {«Должность», «Отдел»}.- V - множество допустимых значений атрибутов. Для каждого элемента множе-ства A множество V содержит вектор значений, которые может принимать дан-ный атрибут: V = { ( v j ) } , где i - номер атрибута из A; j = 1 , . . . , N ^ ; Nj - числовозможных значений атрибута a Е A.- values : A ^ 2V - функция, задающая для каждого атрибута множество егодопустимых значений. Например, V = {va/ues(a1 ) , va/ues(a2 ) } = {(v1 ) , (v2 ) } == {(v1 1 , v12, v13), ( v 2 1 , v 2 2 , v 2 3)}={(«Специалист», «Старший специалист», «Ведущийспециалист»), («Бухгалтерия», «Отдел Кадров», «Разработка»)}.Для обеспечения возможности администрирования множества атрибутов учётныхзаписей пользователей используем функцию can_change_attr : AR ^ 2U, опреде-ляющую для каждой административной роли множество учётных записей, атрибу-ты которых могут быть изменены с использованием данной административной роли.Покажем теперь, каким образом определение элементов множества учётных записейпользователей U может быть расширено за счёт данных об атрибутах учётных записейпользователей.Определение 8. Множество атрибут-пользователей U - это множество векторов(u, u x 1 , . . . , uxraa), где uxi Е va/ues(a^, u Е U.Элементы множества U описывают учётные записи пользователей АИС в соответ-ствии с должностными обязанностями, выполняемыми связанными с ними сотрудни-ками. При этом будем считать, что для u = ( u , u x 1 , . . . ,uxraa) Е U заданы функции,аналогичные функциям для элементовиз множества U, следующим образом:- cr (u) = cr (u);- UA(u) = UA(u);- AUA(u) = AUA(u).П р и м е р 2. Элемент множества U, представляющий учётную запись пользовате-ля АИС, соответствующую сотруднику отдела кадров, занимающему должность стар-шего специалиста, может быть представлен как u = (u, «Старший специалист», «От-дел кадров»), где u - элемент множества U, соответствующий данной учётной записипользователя в АИС.Для обеспечения возможности автоматического (без вмешательства администра-тора) изменения множества авторизованных ролей учетных записей пользователейАИС при изменении атрибутов, описывающих их должностные обязанности, необхо-димо ввести в модель управления доступом следующие элементы:учётную запись пользователя system, от имени которой выполняются все автома-тические операции по изменению авторизованных ролей учётных записей пользо-вателей АИС;- учётную запись пользователя attribute _ source, от имени которой выполняются всеавтоматические операции по изменению атрибутов учётных записей пользователейАИС. Учётная запись пользователя attribute _ source обладает административнойролью rua Е AR, дающей право изменения атрибутов учётной записи любого поль-зователя из U, но не авторизована ни на одну из других ролей из AR или R:UA(attribute_source) = rua;- правила, описывающие взаимосвязь между атрибутами учётных записей пользо-вателей и назначенными им ролями. Будем называть такие правила атрибут-усло-виями.Определение 9. Определим множество атрибут-условий CA.Пусть t : U ^ { f a l s e , t r u e } - функция, такая, что t,(u) = true тогда и толькотогда, когда для u Е U выполняется условие ux, = t.Пусть car : U ^ { f a l s e , t r u e } - функция, такая, что car (u) = car (t1 (u) , . . . , tna (u)),u Е U, r Е R, где car ( y 1 , . . . , yn a ) -булева функция от na переменных, na = 1 , . . . , A.Тогда CA = { c a r 1 , . . . , car t } -множество функций, определяющих, при каких ограни-чениях на атрибуты той или иной учётной записи пользователя может быть назначенанекоторая роль r, Е R.П р и м е р 3. Пусть A = {a1 , a 2 } = {«Должность», «Отдел»}, V = {va/ues(a1 ),va/ues(a2 ) } = {(«Специалист», «Старший специалист», «Ведущий специалист»),(«Бухгалтерия», «Отдел Кадров», «Разработка»)}. Тогда условие для роли r, назна-чаемой учётной записи пользователя u, соответствующего сотруднику бухгалтериис должностью «Ведущий специалист», имеет вид car(u) = (t1 (u), t2(u)) =(«Ведущийспециалист» (u), «Бухгалтерия» (u)).Определение 10. Если роль r имеет связанное атрибут-условие car Е CA и на-значение её учётной записи пользователя u по этому условию инициировано сессиейот имени учётной записи пользователя system, то такое назначение называется авто-матическим, а роль - атрибут-ролью.Атрибут-роль r Е Ra может быть автоматически назначена учётной записи поль-зователя ( u , u x 1 . . . uxn a ) = u Е U тогда и только тогда, когда car(u) = t r u e и выпол-няются предварительные условия из CR (т.е. cr(u) = true).Определение 11. Роли, для которых не существует ни одного атрибут-условияcar Е CA, будем называть классическими, а способ их назначения учётным записямпользователей - классическим.По определению функции can_assign классическая роль r Е Rk может бытьназначена учётной записи пользователя (u, u x 1 , . . . , uxn a ) = u Е U сессией, функ-ционирующей от имени администратора u2 Е U, тогда и только тогда, когда r ЕЕ can_assign (CR, AUA(u2 ) ).П р е д п о л о ж е н и е 3. Будем считать, что если для некоторой роли r Е R существуетатрибут-условие car Е CA, то она всегда назначается автоматически и не может бытьназначена классическим способом. В этом случае множество всех ролей R может бытьпредставлено в виде R = Rk U Ra , Rk П Ra = 0, где RA; - классические роли и Ra -множество атрибут-ролей.П р е д п о л о ж е н и е 4. Будем считать, что учётная запись system авторизованана все административные роли ARa Е AR, такие, что can_revoke 1(ARa ) = R, иc a n _ a s s i g n - 1 ( A R „ ) = RaУ т в е р ж д е н и е 1. Пусть атрибут-роли r1 , r 2 Е Ra таковы, что r1 > r2 и атрибут-условие для роли r2 имеет вид car2 (u) = car2 ( t 1 ( u ) , . . . ,tk (u)). Тогда атрибут-условиедля роли r1 имеет вид car i (u) = car i ( t k + 1 ( u ) , . . . , c a r 2 ( u ) , . . . , tk+p(u)), ti Е va/ues(ai ),т. е. для возможности авторизации на некоторую роль учётная запись пользователядолжна удовлетворять и всем атрибут-условиям для дочерних ролей.Доказательство. Пусть r1 Е UA(u), u Е U, r1 Е Ra . Отсюда следует,что car i (u) = true. По определению иерархии, r2 Е UA(u) и car2 (u) = true. Та-ким образом, из car i (u) = true всегда следует car2 (u) = true. Следовательно,car2 (u) = true является необходимым условием для car i (u) = true, и car i (u) == car i (t1 ( u ) , . . . , car2 ( u ) , . . . , tk (u)). Определение 12. Функция ограничения действий над учётной записью пользо-вателя - это функция H : U х Г х Ф ^ 2Ф, значение которой для каждого действияa Е Ф, выполненного над учётной записью пользователя u Е U и приведшего системув текущее состояние Y Е Г, равно множеству действий, которые могут быть выполненынад заданной учётной записью пользователя для перехода в последующее состояние.Множество Ф всех возможных действий над учётной записью пользователя описанов таблице.П р и м е р 4. Пусть H (u, Yt, a1 ) = {a2 , a 3 , . . . , a q } . Это означает, что после выполне-ния над учётной записью пользователя u действия а1 над данной учётной записью в си-стеме могут быть выполнены только действия из подмножества {a2 , a 3 , . . . , a q } С Ф.Определение 13. Траектория переходов Tr : U х Г х Г х H ^ 2Ф -это функ-ция, задающая конечную последовательность действий Yi Е Ф, которая должна бытьвыполнена над учётной записью пользователя u Е U в системе, находящейся в состо-янии Yo Е Г, для перехода системы в некоторое новое состояние Y1 Е Г при условии,что множество возможных действия ограничено значением функции H(u, Yo, Ф).Траектория используется пользователем system для определения последователь-ности выполнения автоматических действий по отзыву и назначению ролей.П р е д п о л о ж е н и е 5. Администраторы системы могут выполнять действия надучётными записями пользователей в произвольном порядке при условии, что одно-временно над этими учётными записями не выполняет никаких действий сессия отимени system (т. е. в текущиймомент времени траектория действий для данной учет-ной записи пользователя пуста).Пусть Tr(u,Yo,Y, H (u,Yo,^o)) = { ^ 1 , . . . , ^ n } . Введём обозначения: tr [0] = a1 -первое действие, выполненное в системе над учётной записью u из состояния Yo;tr [1] = a2 -второе действие и т.д. То есть если Y = (...02(04(00 (Yo)))), тоTr(u, Yo, Y, H (u,Yo,0o)) = (tr [0] , . . . , t r [n]) = ( 0 1 , . . . , an), где 0i Е H (u,Yi,tr [i - 1]).Ограничения на разрешённые для каждого состояния системы действия и порядок ихвыполнения необходимы, так как операторы не являются коммутативными. Результи-рующее состояние системы зависит от порядка, в котором были выполнены действия.Правила преобразования состояний семантической ролевой моделиПравилоИсходное состояниеYi = (S, U\, UA\, user i,rolesi, H, TRi)Y2Результирующее состояниеS,U2,UA2, user2, roles2, H, TR2ai=take_role(x, r) -активация сессиейодной из авторизи-рованных ролейai Е H (user (x), Yi, a),xi Е S, r Е R,r Е UA (user (x))H (user (x), Y2, ai) = H (user (x), Yi, a),TR2 = TRi, S2 = S1, PA2 = PAi,user'2 = useri, UA2 = UAi, roles2 (x) == rolesi (x) U {r}, для x2 Е S \ { x i } выпол-няется roles2 (x2) = rolesi (x2)a2=remove_role(x, r)- удаление из сес-сии одной из ранееактивированныхролейs2 Е H (user (x) ,Yi,a),xi Е S, r Е R, r Е roles (x)TR2 = TRi, S2 = S1, PA2 = PAi,H (user (x), Y2, a2) = H (user (x), Yi, a),user2 = useri, UA2 = UAi, roles2 (xi) == rolesi (xi) \ {r}, для x2 Е S \ { x i } выпол-няется roles2 (x2) = rolesi (x2)as = assign _role(ui,u,2,r) - назначениероли классическимспособомas Е H(ui,Yi,a),ui, u,2 Е U, r Е Rk,r Е can_assign(CR,AUA (u2))H (ui,Y2,as) = H (ui, Yi, a), S2 = Si, PA2 == PAi, user2 = useri, roles2 (xi) = rolesi(xi) \ {r}, для u Е U \ {ui} выполняетсяUA2 (u) = UA1 (u), UA2 u) = UA1 u)U{r},roles2 = rolesia4=revoke _role(ui,u2 , r) - отзыв ро-ли классическимспособомa4 Е H (ui,Yi, a), x Е S,ui,u2 Е U, r Е Rk, r ЕЕ can_revoke (AUA (u,2));для всех x, таких, чтоuser (x) = ui, выполняет-ся r = roles (x)TR2 = TRi; если для r существуют родитель-ские роли, то H (ui,Y2,a4) = {a4} (нельзявыполнять никаких действий, пока родитель-ские роли не будут отозваны);иначе H (ui,Y2,a4) = H (ui,Yi,a); S2 = Si,PA2 = PAi, user2 = useri, для й Е U \ {ui}выполняется UA2 (u) = UAi (u), UA2 (ui) == UAi (ui) \ {r}, roles2 (x) = rolesi (x) \ {r}a^ = change _user _-attr (u, i, v) - изме-нение значения i-гоатрибута учётнойзаписи пользователяна новое значение vtri [0]=a5, a5EH (u,Yi,a),x Е S, u = (u, uxi, ..., uxi,...,xn) Е U, xi = vtr2 [0] = a8, H (u,Y2,a5) = {a8} (после изме-нения атрибутов нельзя выполнять никакихдействий, кроме перерасчёта ролей),u = (u, uxi,... ,v,..., uxn), для u Е U \ {u}выполняется U2 = U 1, S2 = Si, PA2 = PAi,user2 = useri, UA2 = UAi, roles2 = rolesiae = auto _assign_-role (ui, r) - автома-тическое назначениеролиtri [0] = a6, x Е S, ui Е U,r Е Ra, car (ui) = trueH(ui,Y2,ae) = {ae,a7}, U2 = Ui, S2 = Si,PA2 = PAi, user2 = useri, для й Е U \ {ui}выполняется UA2 (u ) = UAi (u ), UA2 (ui) == UAi (ui) U {r}, roles2 = rolesi= auto_revoke_-role (ui, r) - автома-тический отзыв ролиtri[0] = a7, x Е S, ui ЕЕ U, r Е UA (ui), r Е Ra,car (ui) = falseH (ui,Y2,ar) = {a6,ar}, U2 = Ui, S2 == Si, PA2 = PAi, user2 = useri, для u2 ЕЕ U \ {ui} выполняется UA2 (u2) = UAi (u2),UA2 (ui) = UAi (ui) \ {r}, roles2 = rolesia% = auto _r ecalculate(u) - построениетраектории автома-тического отзыва иназначения ролейtr1[0] = a8, u Е UH (u,Y2,a8) = {ae,ar}, TR2 = TRi П { a n,a72,...,a7k ,aei,... ,aem}, где an -действиепо отзыву роли ri Е Ra, aej - действие по на-значению роли rj Е Ra, S2 = Si, PA2 = PAi,user2 = useri, UA2 = UAiП р и м е р 5. Последовательный отзыв всех родительских ролей при отзыве до-черней роли у учётной записи пользователя u Е U может бытьвыражен следующейтраекторией: Tr (u, Yt, Yt+ъ H (u, Yt, аГ1)) = (аГ 2 , . . . , , где аГ1 -действие по отзывуроли r1 и r 2 , . . . , rq - родительские роли для r1. Таким образом, ни одно другое дей-ствие над данной учётной записью пользователя в системе не может быть выполнено,пока у неё не будут отозваны все роли, согласно иерархии.Определение 14. Семантически осмысленная модель ролевого управления до-ступом задается множествами U, R, P, RH, CA, CR, V, A, AR, AP и функциями PA,UA, AUA, H, Tr, ro/es и user. При этом множества CA, A, V, U составляют семанти-ческий контекст ролевой модели.Семантический контекст ролевой модели отражает связь между множествами учёт-ных записей, прав доступа и ролей, организационно-штатной структурой и спецификойдеятельности предприятия.П р е д п о л о ж е н и е 6. В рамках данной работы считается, что административныероли AR не имеют семантической составляющей и назначаются всегда классическимспособом.Расширив определение 5 за счет семантического контекста и учёта траектории пе-реходов, введём определение семантической системы ролевого управления доступом.Определение 15. Семантическая система ролевого управления доступом - этоконечный автомат Е = (Г, Q, a, Ф), состояния которого задаются кортежем Y == ^S, U, UA, user, ro/es, H, T r j Е Г , а правила перехода между состояниями опре-деляются предварительными условиями CR, атрибут-условиями CA, функцией огра-ничения действий H и траекторией Tr.П р е д п о л о ж е н и е 7. Предполагается, что множества P, R, RH, A, V, AR, а такжеусловия CR и CA не изменяются в процессе функционирования системы.3. Анализ безопасности семантической системыролевого управления доступом3.1. И з м е н е н и е а т р и б у т о в у ч ё т н о й з а п и с и и р а с ч ё тт р а е к т о р и и п е р е х о д а с и с т е м ы м е ж д у с о с т о я н и я м иСформулируем и обоснуем правила, на основании которых определяется порядокследования элементов в траектории Tr.У т в е р ж д е н и е 2. Пусть в результате успешного выполнения действия a5 систе-ма Е = (Г, Q, a, Ф) перешла в состояние Yi, где атрибуты учетной записи пользовате-ля u Е U изменились таким образом, что необходимо отозвать у него атрибут-ролиr 1 1 , r 1 2 , . . . , r1k Е Ra и назначить ему атрибут-роли r21, r 2 2 , . . . , r 2 m Е Ra , переведя си-стему в состояние Y2. Пусть Tr (u,Yi, Y2,H) -траектория перехода из состояния Yiв состояние Y2. Переход из состояния Yi в состояние Y2 по траектории Tr возможентолько в том случае, если построенная траектория удовлетворяет следующим свой-ствам:1) действия a7 по отзыву ролей должны следовать в траектории перед действиямипо назначению ролей a6;2) если ri и rj - такие роли, что ri > rj, то a7 (rj) должно следовать в траекториираньше, чем a7 (ri), и (ri ) должно выполняться раньше, чем (rj).Доказательство. Покажем достаточность выполнения условий 1 и 2 для воз-можности переходапо заданной траектории TR. Невозможность выполнения одногоили более действий в траектории перехода может произойти в одном из двух случаев.С л у ч а й 1. Пусть последовательность действий в траектории TR такова, чтонекоторой учётной записи u необходимо автоматически назначить роль ra, но дан-ное назначение противоречит предварительным условиям CR, так как учётная записьпользователя u уже авторизована на роли из множества {r1 1 , r 1 2 , . . . , r1k} С Ra , исклю-чающие назначение роли ra. Данная ситуация противоречит условию 1 утверждения,так как действия по отзыву ролей r11, r 1 2 , . . . , r1k всегда выполняются до выполнениядействий по назначению новых ролей.С л у ч а й 2. Пусть последовательность действий в траектории TR тако-ва, что некоторой учётной записи u необходимо автоматически назначить роль ra,но данное назначение противоречит предварительным условиям CR, так как учёт-ная запись пользователя u не авторизована на роли из множества {r2 1 , r22, r 2 y - 1 , . . . ,r 2 y+1 , . . . , r 1 m } С Ra , являющиеся предусловием для назначения роли ra. По опреде-лению иерархии, если роль r2 является предусловием для роли r1, то r1 > r2. Следо-вательно, данная ситуация противоречит условию 2 утверждения, так как дочерниероли назначаются учётной записи пользователя раньше, чем родительские роли. Замечание. Условия утверждения 2 являются необходимыми, но не достаточнымидля перехода в состояние Y2. Невозможность выполнения действий, заданных траекто-рией, может произойти также в результате некорректного определения предваритель-ных условий, если две или более ролей из множества {r2 1 , r 2 2 , . . . , r 2 m } С Ra являютсявзаимоисключающими. Если предварительные условия CR не противоречат атрибут-условиям CA и ни одна из ролей r21, r 2 2 , . . . , r 2 m Е Ra не исключает других ролей изтого же множества, то условия утверждения являются необходимыми и достаточнымидля перехода в состояние Y2 по вычисленной траектории Tr.У т в е р ж д е н и е 3. Пусть семантически осмысленная система ролевого управле-ния доступами Е = (Г, Q, a, Ф) содержит только атрибут-роли (т. е. R = Ra , ARa = AR)и учётную запись system, от имени которой инициируется сессия, выполняющая ав-томатический перерасчёт назначенных учётной записи пользователя ролей при изме-нении её атрибутов согласно траектории, удовлетворяющей условиям утверждения 2.Пусть атрибуты учётной записи пользователя полностью описывают его должност-ные обязанности и все изменения атрибутов передаются в каталог системы ролевогоуправления доступом. Тогда каждая учётная запись пользователя u Е U всегда имеетнабор ролей, соответствующих его должностным обязанностям.Доказательство. Пусть должностные обязанности учётной записи пользовате-ля, соответствующей некоторому сотруднику предприятия, характеризуются набороматрибутов A = a 1 , a 2 , . . . , a N . Пусть r1 , r 2 Е Ra - атрибут-роли, с которыми связаныразличные атрибут-условия car1 и car 2 соответственно. Пусть первоначально долж-ностные обязанности учётной записи пользователя u были таковы, что car1 (u) = t r ueи car 2 (u) = f a l s e . В таком случае учётной записи пользователя назначена толькороль r1 и соответствующие ей права доступа. Пусть после смены должности атри-буты учётной записи пользователя изменяются таким образом, что car1 (u) = f a l s e иcar 2 (u) = true. В этом случае, согласно правилам, приведённым в таблице, и определе-нию атрибут-роли, в системе инициируется автоматический отзыв роли r1 и автомати-ческое назначение роли r2. Поскольку, по определению модели RBAC, права доступаназначаются учётной записи пользователя только посредством ролей, она будет обла-дать только правами доступа, соответствующими новой должности связанного с нейсотрудника. 3.2. А н а л и з д е й с т в и й п о п е р е х о д у м е ж д у с о с т о я н и я м иПроведем анализ действия change_user_attr, выполняемого сессией от имениучётной записи attribute_source. Выполнение действия change_user_attr ( u , i , v ) длязаданного состояния системы является успешным только в том случае, если выполня-ются следующие условия:- значение некоторого атрибута учётной записи пользователя, соответствующего со-труднику в системе учёта кадров предприятия, не совпадает со значением соот-ветствующего атрибута учётной записи связанного пользователя u Е U в каталогеучётных записей системы ролевого управления доступом;- в данный момент времени над учётной записью пользователя не выполняется ни-каких действий (Tr(u, Yi, Y2, H) = 0 ) . В случае успешного выполнения действиянад заданным состоянием системы Yi = (Ui, UA1,user1 , r o / e s 1 ) новое состояниеYi = ^U2, UA2 , user2, ro/es2^ отличается от исходного множеством значений U.Результатом успешного выполнения действия по изменению атрибутов учётной записиu = ( u , u x i , . . . , u x i , . . . , uxn ) Е U является состояние, в котором U2 = \ { u } ^ UU{ u 2 } , где u2 = (u, u x i , . . . , v , . . . , uxn ) , v = uxi . В случае неуспешного выполнениядействия состояние системы не изменится.Проведем анализ действий auto_assign_ro/e и auto_revoke_ro/e, выполняемыхсессией-инициатором system. Выполнение действия a u t o _ a s s i g n _ r o / e (u, r) для задан-ного состояния системы является успешным только в том случае, если выполняютсяследующие условия:- выполняются атрибут-условия назначения роли car (u) = true;- выполняются предварительные условия CR. Поскольку субъект system автори-зован на все возможные административные роли для управления назначениямиатрибут-ролей, то значение функции can_assign (CR, AUA (system)) зависит толь-ко от аргумента CR;- 06 является текущим значением траектории (tr[0] = a6 ).В случае успешного выполнения действия над заданным состоянием системы Yi = (Ui,UAi , u s e r i , r o / e s i ) новое состояние Y2 = (U2, UA2 , user2, r o / e s 2 j отличается от исход-ного значением функции UA. Результатом успешного выполнения действия являетсясостояние, для которого UA2(ui~i) = UAi(uti ) U { r } . Выполненное действие удаляет-ся из траектории. В случае неуспешного выполнения действия состояние системы неизменится.Рассмотрим действие автоматического отзыва роли auto_revoke_ro/e ( u , r ) , гдесессия от имени учётной записи пользователя system отзывает у учётной записи поль-зователя u роль r Е Ra . Выполнение данного действия для заданного состояния си-стемы является успешным только в том случае, если:- учётная запись пользователя u авторизована на роль r, т. е. r Е UA (u);- значения атрибутов учётной записи пользователя не соответствуют атрибут-условиям назначения для роли r, т. е. car (u) = f a l s e ;- a7 является текущим значением траектории (tr[0] = a7 ).В случае успешного выполнения действия над заданным состоянием системы Yi = (Ui,UAi , u s e r i , r o / e s i ) новое состояние Y2 = (U2, UA2 , user2, r o / e s 2 j отличается от исход-ного значением функции UA. Результатом успешного выполнения действия являетсясостояние, для которого UA2(uTi) = UAi(uti ) \ ( { r } U up (r)), где up (r) -множество ро-лей, больших r. Выполненное действие удаляется из траектории. В случае неуспешноговыполнения действия состояние системы не изменится.Рассмотрим действие auto_reca/cu/ate (u). Условием выполнения данного действияявляется переход системы в состояние, где a8 является единственным возможным дей-ствием: H(u,Y,a) = {a8 } , TR[0] = a8 . Согласно таблице, такая ситуация возможнав результате успешного выполнения действия a5 . Результатом выполнения действияявляется траектория Tr, состоящая из действий а6 и а7 в соответствии с количествомролей, которые необходимо назначить или отозвать.Проведем анализ действий а3 = assign_ro/e и а4 = revoke_ro/e, выполняемыхсессией от имени учетной записи администратора системы admin Е I N I T { а 3 , а 4 }.Выполнение действия assign_ro/e(admin, u, r) для заданного состояния системы Yiявляется успешным только в том случае, если выполняются следующие условия:- r Е Rk - классическая роль;- выполняются предварительные условия CR : cr (u) = true;- r Е can_assign ( C R , A U A (admin));- а3 Е H (u, y, а) и над учётной записью пользователя в данный момент не выполня-ется никаких других действий - Tr(u, Yi, Y2, H) = 0.В случае успешного выполнения действия над заданным состоянием системы Yi = (Ui,UA1,user1 , r o / e s 1 ) новое состояние y2 = (U2, UA2 , user2, r o / e s 2 j отличается от исход-ного значением функции UA. Результатом успешного выполнения действия являетсясостояние, для которого UA2 (u) = UA1 (u) U { r } . В случае неуспешного выполнениядействия состояние системы не изменится.Аналогичные условия выполняются для действия классического отзыва ролиrevoke_ro/e(admin, u, r), где сессия от имени учётной записи администратора adminотзывает у учётной записи пользователя u роль r Е Rk. Выполнение данного действиядля заданного состояния системы является успешным только в том случае, если:- r Е Rk - классическая роль;- { r } U up (r) С can_revoke (AUA (admin)), где up (r) - множество ролей, старших r;- а4 Е H (u, y, а) и над учётной записью пользователя в данный момент не выполня-ется никаких других действий - Tr(u, Yi, Y2, H) = 0.В случае успешного выполнения действия над заданным состоянием системы Yi = (Ui,UA1,user1 , r o / e s 1 ) новое состояние y2 = (U2, UA2 , user2, r o / e s 2 j отличается от исход-ного значением функции UA. Результатом успешного выполнения действия являетсясостояние, для которого UA2 (u) = UA1 (u) \ ( { r } U up (r)). Выполненное действие уда-ляется из траектории. В случае неуспешного выполнения действия состояние системыне изменится.3.3. К р и т е р и й б е з о п а с н о с т и ф у н к ц и о н и р о в а н и я с и с т е мыСформулируем критерий безопасного функционирования системы семантическогоролевого управления доступом и покажем, что в случае, когда управление назначени-ями атрибут-ролей осуществляется автоматически от лица единственной довереннойучётной записи system Е I N I T (а), а классические роли управляются исключительносессиями, функционирующимиот имени учётных записей пользователей из подмно-жества администраторов Ua С I N I T (а), Ua П {system} = 0, то система являетсябезопасной с точки зрения данного критерия.Определение 16. Состояние y Е Г системы ролевого управления доступомЕ = (Г, Q , a , Ф) называется безопасным, если каждой учётной записи пользователяu Е U назначены только роли, не противоречащие условиями CR и CA.Определение 17. Система Е = (Г, Q , a , Ф) называется безопасной, если любоесостояние Yg, достижимое из начального безопасного состояния y посредством дей-ствий, инициированных сессией от имени любой из учётных записей пользователейu Е I N I T ( Ф ) , является безопасным.Т е о р е м а 1. Пусть семантически осмысленная система ролевого управления до-ступом Е = (Г, Q, a, Ф) обладает следующими свойствами:1) все действия по назначению и отзыву атрибут-ролей R0 Е R инициируютсяавтоматически в порядке, определённом траекторией Tr;2) множество значений функции I N I T (a5) включает в себя ровно одну учётнуюзапись пользователя attribute_source, т.е. I N I T (a5) = {attribute_source};3) множество значений функции I N I T ( a 6 , a 7 ) включает в себя ровно одну учёт-ную запись пользователя system, т.е. I N I T ( a 6 , a 7 ) = {system};4) I N I T (аз, 04) = U0, при этом I N I T (03, 04) П I N I T (0-5,07) = 0.Тогда, если начальное состояние ролевой модели Yo = ^Uo, UAo , usero , ro/eso^ яв-ляется безопасным, то система Е является безопасной.Доказательство. Пусть начальное состояние ролевой модели Y0 является безо-пасным. Поскольку при выполнении действий 03 и 06 по назначению роли учётнойзаписи пользователя осуществляется проверка того, что новое назначение не противо-речит предварительным условиям CR, нарушение свойства безопасности системы припереходе из Yo в новое состояние Yg может произойти только в следующих случаях.С л у ч а й 1. Невозможность автоматического назначения роли в результате на-значения взаимоисключающей роли администратором системы: 06 (03 (05 (Yo))) = Yg.Пусть атрибуты учётной записи пользователя в системе были изменены в результатедействия 05 и сессией администратора u0 Е U0 инициируется выполнение действия 03по назначению классической роли до того, как сессия system инициирует действие 06по назначению атрибут-роли r0. После инициализации 06 может возникнуть ситуация,когда атрибут-роль r0 должна быть назначена учётной записи пользователя по усло-виям CA, но не может быть назначена по условиям CR, так как роль являетсявзаимоисключающей с r0. Данная ситуация противоречит условию 1 теоремы, так каклюбые другие действия над учётной записью пользователя в системе запрещены дозавершения цепочки действий 07 и 06 , выполняемых согласно траектории, рассчитан-ной при выполнении 08. Действие 08 является единственным разрешённым действиемпосле успешного выполнения 05 , и до завершения 08 любые другие действия над за-данной учётной записью запрещены.С л у ч

Ключевые слова

ролевое управление доступом, автоматизация управления ролями, RBAC, automated role management

Авторы

ФИООрганизацияДополнительноE-mail
Семенова Наталья АндреевнаМосковский государственный институт электроники и математикиаспиранткаnatasha_sem@inbox.ru
Всего: 1

Ссылки

http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf - National Institute of Standards and Technology, Proposed Standard for Role-Based Access Control.
Ferraiolo D., Kuhn D., and Chandramoul R. Role Based Access Control. NewYork: ARTECH HOUSE, INC, 2003. 337 с.
Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками: учеб. пособие для вузов. М: Горячая линия - Телеком, 2011. 320 с.
Sandhu R. S., Bhamidipati V., and Munawer Q. The ARBAC97 model for role-based aministration of roles // ACM Trans. Information and Systems Security. No.2(1). NewYork: ACM Publishing, 1999. P. 105-135.
Нокс Д. Создание эффективной системы безопасности для Oracle Database 10g. М: Лори, 2007. 576 с.
Джоханссон Дж. Обеспечение безопасности. Ресурсы Windows Server 2008. СПб.: Русская редакция, 2009. 544 с.
 Семантическая ролевая модель управления доступом | ПДМ. 2012. № 2(16).

Семантическая ролевая модель управления доступом | ПДМ. 2012. № 2(16).

Полнотекстовая версия