CC BY
144
2012 Математические основы компьютерной безопасности №2(16)
МАТЕМАТИЧЕСКИЕ ОСНОВЫ КОМПЬЮТЕРНОЙ БЕЗОПАСНОСТИ
УДК 004.056.52
СЕМАНТИЧЕСКАЯ РОЛЕВАЯ МОДЕЛЬ УПРАВЛЕНИЯ ДОСТУПОМ
Н. А. Семенова
Московский государственный институт электроники и математики (ТУ), г. Москва,
Россия
E-mail: natasha_sem@inbox.ru
Приводится описание расширения ролевой модели RBAC, используемой для управления доступом в автоматизированную информационную систему (АИС) предприятия, за счёт введения семантического контекста, позволяющего отразить взаимосвязь между должностными обязанностями сотрудников и ролями, назначенными соответствующим им учётным записям пользователей в системе. Основное отличие модели — возможность автоматизации операций назначения и отзыва ролей. Приведено доказательство безопасности системы ролевого управления доступом, построенной на основе предложенной семантической модели.
Ключевые слова: ролевое управление доступом, автоматизация управления ролями.
Введение
Модель ролевого управления доступом RBAC [1] применяется для построения систем управления доступом в АИС. Одной из особенностей классической модели RBAC является то, что все операции по назначению и отзыву ролей выполняются вручную администраторами системы. При большом количестве ролей в АИС нагрузка на администраторов возрастает, что может привести к увеличению времени, необходимому для обеспечения пользователя АИС, соответствующего некоторому сотруднику предприятия, всеми нужными ему для выполнения должностных обязанностей правами доступа [2]. В данной работе предлагается ролевая модель управления доступом, основанная на классической модели и позволяющая автоматизировать назначение и отзыв ролей учётным записям пользователей при наступлении в системе ряда определённых событий.
1. Основные понятия и определения классической модели RBAC
Рассмотрим некоторые основные понятия классической модели RBAC, которые потребуются для дальнейшего описания [3]:
P — множество возможных прав доступа;
U — множество учётных записей пользователей системы;
R С 2Р — множество ролей системы;
UA : U ^ 2R — функция, задающая для каждой учетной записи пользователя множество ролей, на которые она может быть авторизована;
PA : R ^ 2Р — функция, задающая для каждой роли множество прав доступа. При этом для каждого права доступа pEP существует роль teR, такая, что pEPA(r);
user : S ^ U — функция, задающая для каждой сессии учётную запись, от имени которой она авторизована.
Определение 1. Иерархией ролей в классической модели ролевого управления доступом называется заданное на множестве ролей R отношение частичного порядка ^. При этом по определению выполняется условие: для учётной записи пользователя u Е U если ri,r2 Е R, r1 е UA(u) и ri ^ r2, то r2 Е UA(u).
Зададим RH С R х R — иерархическое отношение на множестве ролей — следующим образом: (r1 ^ r2) ^ ((r1,r2) Е RH). Если r1 ^ r2, то r1 считается старшей по отношению к r2 (предком r2), а r2 —младшей (потомком r1).
Определение 2. Два права доступа p1,p2 Е P называются статически взаимоисключающими, если они не могут входить в состав одной и той же роли одновременно: для любой r Е R выполняется неравенство {p1,p2} П PA(r) ^ 1.
Определение 3. Две роли r1,r2 Е R называются статически взаимоисключающими, если они не могут быть назначены одной учётной записи пользователя одновременно: для любой u Е U выполняется неравенство {r1,r2} П UA(u) ^ 1.
Определение 4. Множество предварительных условий CR — это множество, включающее в себя ограничения на роли, которыми должна обладать учётная запись пользователя, чтобы быть назначенной на новую роль, а также ограничения взаимного исключения ролей. Пусть zr : U ^ {false, true} — функция, такая, что zr(u) = true тогда и только тогда, когда для u Е U и r Е R выполняется условие r Е UA(u). Пусть cr : U ^ {false, true} — функция, такая, что cr (u) = cr (zri (u),...,zrk (u)), где u Е U; r,r-]_,... ,rk Е R; r = ri для i = 1,... ,k и cr (y1,..., yk) — булева функция от k переменных. Тогда CR = {cri,...,crt} — множество функций, определяющих, при каких условиях той или иной учётной записи пользователя может быть назначена некоторая роль rj Е R.
Для обеспечения возможности администрирования множества назначенных учётным записям пользователей ролей используем следующие функции, определённые в стандарте ARBAC’97 [4]:
— AP — множество административных прав доступа;
— AR С 2ap — множество административных ролей;
— APA : AR ^ 2ap — функция, задающая для каждой административной роли множество административных прав доступа; при этом для каждого права доступа p Е AP существует роль r Е AR, такая, что p Е APA(r);
— AUA : U ^ 2ar — функция, задающая для каждой учётной записи пользователя множество административных ролей, на которые она может быть авторизована;
— can_assign : AR ^ CR х 2r — функция, определяющая для каждой административной роли множество ролей, которые могут быть назначены учётной записи пользователя с использованием данной административной роли при выполнении заданных предварительных условий CR;
— can_revoke : AR ^ 2r — функция, определяющая для каждой административной роли множество ролей, которые могут быть отозваны у учётной записи пользователя с использованием данной административной роли;
— roles : S ^ 2r U AR — функция, задающая для учётной записи пользователя множество ролей, на которые она авторизована в данной сессии. При этом в каждый момент времени для каждой сессии s Е S выполняется условие roles(s) Е Е UA(user(s)) U AUA(user(s)).
Определение 5. Под классической системой ролевого управления доступом будем понимать конечный автомат, заданный кортежем K = {T,Q,a, Ф), где Г — множество состояний; Q — множество запросов на доступ к объектам АИС; Ф — множество действий, переводящих систему из состояния в состояние; a : Г х Q ^ {true, false} — функция, определяющая, является ли запрос истинным в заданном состоянии. Состояние системы задаётся кортежем y = (S,U,UA, user, roles) Є Г, а правила перехода между состояниями определяются предварительными условиями CR.
Таким образом, классическая модель RBAC не содержит в себе информацию о связи между должностными обязанностями пользователей и ролями, назначенными их учётным записям (о семантическом смысле назначения ролей). Ещё одним важным ограничением классической модели RBAC является то, что роли всегда назначаются и отзываются сессией, инициированной некоторой учётной записью пользователя системы, обладающей административными правами, и не могут быть назначены (отозваны) при наступлении заданного события, поскольку модель не содержит в себе средств описания событий и логики реакции на них. Далее описаны предлагаемые расширения классической модели за счёт введения семантического контекста.
2. Семантическая ролевая модель управления доступом
2.1. Иерархия ролей «по предусловию»
В классической модели RBAC считается, что родительская роль содержит в себе все права дочерних ролей, а также более высокопривилегированные права доступа, чем дочерние (например, роль «Начальник отдела» является родительской для роли «Рядовой сотрудник» и содержит как все права доступа, назначенные рядовым сотрудникам, так и права, которыми обладают только руководители структурной единицы предприятия). В реальных АИС иерархические отношения между ролями обычно имеют следующий смысл [5]: меньшая роль описывает некоторые базовые права доступа к объекту, а родительские роли — более функциональные права доступа. В качестве примеров таких АИС можно привести службу каталогов ActiveDirectory [5], где базовым правом доступа является включение учётной записи в домен (роль DomainUsers), а также СУБД Oracle [6], содержащую базовые права доступа CONNECT и CREATESESSION, разрешающие создание соединения с базой данных (роль DatabaseUser). Таким образом, родительские роли в общем случае не включают в себя права доступа дочерних ролей. В то же время можно показать, что в классической модели RBAC существует неявно выраженная зависимость между предварительными условиями назначения ролей, находящихся в иерархической связи друг с другом. Пусть в классической модели RBAC роль ri является старшей для роли r2. Тогда, по определению 1, для учётной записи пользователя и Є U если (r1,r2) Є RH, r1 Є UA(u) и r1 ^ r2, то r2 Є UA(u). В этом случае можно утверждать, что учётная запись пользователя и удовлетворяет условиям: если сГ1 (и) = true, то сГ2 (и) = true, в противном случае роль r2 не могла бы быть назначена учётной записи пользователя. Таким образом, существует неявным образом выраженная зависимость между предварительными условиями назначения ролей r1 и r2.
Переопределим иерархические связи между ролями, используя описание множества предварительных условий CR.
Определение 6. Иерархией ролей «по предусловию» будем называть заданное на множестве ролей R отношение строгого порядка >. При этом для учётной записи пользователя и Є U если (r1,r2) Є RH, r1 > r2 и сГ1 (и) = true, то cr2 (и) = true и
cri (u) = cri (z\(u),... , cr2 (u),... , zk(u)). Роль t\ будем называть предком т2 «по предусловию».
Таким образом, по определению, для возможности авторизации на некоторую роль учётная запись пользователя должна удовлетворять и всем предварительным условиям для дочерней роли.
Предположение 1. В данной работе предполагается, что в модели действуют ограничения статического взаимного исключения прав доступа для ролей, состоящих в иерархических отношениях: для каждого множества ролей, состоящих в иерархии, каждое право доступа может входить в состав только одной роли: P = PA(r\) U • • • U UPA(rm), где (ri, Tj) E RH; PA(ri) П PA(rj) = 0 для 1 ^ i < j ^ m, Ti, Tj E R.
Предположение 2. Будем считать, что если для некоторой административной роли ra E AR и роли r E R выполняется условие r E can_Tevoke(ra), то для каждой роли r0 E R, такой, что т0 > т, выполняется условие r0 E can_revoke(ra).
Сформулируем ряд утверждений, описывающих свойства ролевой модели управления доступом, в которой выполняются условия предположений 1 и 2, а иерархия ролей строится по определению 6.
1) Отзыв у учётной записи пользователя родительской роли не влечёт за собой автоматического отзыва всех дочерних ролей, поскольку множества прав доступа, входящих в родительскую и дочерние роли, не пересекаются (не выполняется требование, справедливое для классической модели: если т\ ^ т2, то PA(r\) D PA(t2)).
2) Отзыв дочерней роли приводит к отзыву всех родительских ролей. По определению 6, при удалении у учётной записи пользователя u некоторой роли т для u перестают выполняться предварительные условия для всех ролей, родительских для т. Это означает, что в результате удаления т у учётной записи пользователя одновременно отзываются и все родительские для т роли. Для возможности каскадного удаления ролей у учётной записи пользователя необходимо выполнение условий предположения 2.
3) Каскадное назначение прав на отзыв административным ролям в направлении «снизу вверх» не влечёт за собой превышения прав доступа административных пользователей, поскольку родительские роли не включают в себя права доступа дочерних ролей.
Определение 7. Пусть INIT : Ф ^ 2U — функция, задающая для каждого действия о E Ф множество возможных инициаторов его выполнения. Говорим, что субъекты (учётные записи) из множества значений функции INIT(о) С U могут быть инициаторами действия о E Ф, переводящего систему (r,Q,a, Ф) из состояния y E Г в состояние Yg E Г, если сессии, функционирующие от имени данных субъектов, могут выполнить действие о E Ф, приводящее к переходу модели из состояния Y E Г в состояние Yg E Г, т. е. если существует действие о E Ф, для которого выполняются следующие условия:
— тй(о) E INIT(о), где init : Ф ^ U — функция, такая, что тй(о) = user(s), если
сессия s выполнила действие о;
— о1^) = Yg.
Таким образом, для каждого возможного действия в системе значение функции INIT — это совокупность учётных записей пользователей, обладающих в рамках заданной сессии s административными правами, позволяющими им выполнить данное действие. Будем использовать обозначение INIT(о\,о2,... ,о^) = INIT(о^ х xINIT(о2) х • • • х INIT(оi).
Пример 1. Множество учётных записей пользователей, обладающих возможностью назначить роль т E R учётной записи пользователя u E U, задаётся выражением {ua E U : ua E AUA(can_assign-1 (cr (u),r))}, где cr E CR — предварительное условие, определяющее, может ли роль т быть назначена учётной записи пользователя u.
2.2. А т р и б у т ы у ч ё т н о й з а п и с и п о л ь з о в а т е л я
Дадим определение семантически осмысленной ролевой модели, являющейся расширением классической модели ролевого управления доступом. Введём следующие дополнительные обозначения:
— A — множество атрибутов учётных записей пользователей. Элементами A являются атрибуты, характеризующие положение сотрудника, соответствующего учётной записи пользователя АИС, в организационно-штатной структуре предприятия, его должность и другие признаки, позволяющие определить его служебные обязанности. Например, A = {a1,a2} = {«Должность», «Отдел»}.
— V — множество допустимых значений атрибутов. Для каждого элемента множества A множество V содержит вектор значений, которые может принимать данный атрибут: V = {(vij)}, где i — номер атрибута из A; j = 1,...,Ni; Ni — число возможных значений атрибута ai E A.
— values : A ^ 2V — функция, задающая для каждого атрибута множество его допустимых значений. Например, V = {values(a1), values(a2)} = {(v1), (v2)} = = {(v11,v12,v13), (v21,v22,v23)}={(«Специалист», «Старший специалист», «Ведущий специалист»), («Бухгалтерия», «Отдел Кадров», «Разработка»)}.
Для обеспечения возможности администрирования множества атрибутов учётных записей пользователей используем функцию can_change_attr : AR ^ 2U, определяющую для каждой административной роли множество учётных записей, атрибуты которых могут быть изменены с использованием данной административной роли. Покажем теперь, каким образом определение элементов множества учётных записей пользователей U может быть расширено за счёт данных об атрибутах учётных записей пользователей.
Определение 8. Множество атрибут-пользователей U — это множество векторов (u, ux1,..., uxna), где uxi E values(ai), u E U.
Элементы множества U описывают учётные записи пользователей АИС в соответствии с должностными обязанностями, выполняемыми связанными с ними сотрудниками. При этом будем считать, что для й = (u,ux1,... ,uxna) E U заданы функции, аналогичные функциям для элементов из множества U, следующим образом:
— cr (u) = cr (u);
— UA(u) = UA(u);
— AUA(u) = AUA(u).
Пример 2. Элемент множества U, представляющий учётную запись пользователя АИС, соответствующую сотруднику отдела кадров, занимающему должность старшего специалиста, может быть представлен как й = (u, «Старший специалист», «Отдел кадров»), где u — элемент множества U, соответствующий данной учётной записи пользователя в АИС.
Для обеспечения возможности автоматического (без вмешательства администратора) изменения множества авторизованных ролей учетных записей пользователей АИС при изменении атрибутов, описывающих их должностные обязанности, необходимо ввести в модель управления доступом следующие элементы:
— учётную запись пользователя system, от имени которой выполняются все автоматические операции по изменению авторизованных ролей учётных записей пользователей АИС;
— учётную запись пользователя attribute_source, от имени которой выполняются все автоматические операции по изменению атрибутов учётных записей пользователей АИС. Учётная запись пользователя attribute_source обладает административной ролью rua E AR, дающей право изменения атрибутов учётной записи любого пользователя из U, но не авторизована ни на одну из других ролей из AR или R: UA(attribute_source) = rua;
— правила, описывающие взаимосвязь между атрибутами учётных записей пользователей и назначенными им ролями. Будем называть такие правила атрибут-условиями.
Определение 9. Определим множество атрибут-условий CA.
Пусть t : U ^ {false, true} — функция, такая, что ti(ii) = true тогда и только тогда, когда для u E U выполняется условие uxi = t.
Пусть car : U ^ {false, true} — функция, такая, что car (u) = car (t1 (u) ,... , tna (u)), u E U, r E R, где car (y1,... ,yna) —булева функция от na переменных, na = 1,..., A. Тогда CA = {car1,... , cart} —множество функций, определяющих, при каких ограничениях на атрибуты той или иной учётной записи пользователя может быть назначена некоторая роль ri E R.
Пример 3. Пусть A = {a1,a2} = {«Должность», «Отдел»}, V = {values(a1), values(a2)} = {(«Специалист», «Старший специалист», «Ведущий специалист»), («Бухгалтерия», «Отдел Кадров», «Разработка»)}. Тогда условие для роли т, назначаемой учётной записи пользователя u, соответствующего сотруднику бухгалтерии с должностью «Ведущий специалист», имеет вид car(u) = (t1(ii),t2(ii)) =(«Ведущий специалист»(u), «Бухгалтерия»(u)).
Определение 10. Если роль т имеет связанное атрибут-условие car E CA и назначение её учётной записи пользователя ui по этому условию инициировано сессией от имени учётной записи пользователя system, то такое назначение называется автоматическим, а роль — атрибут-ролью.
Атрибут-роль т E Ra может быть автоматически назначена учётной записи пользователя (u,ux1.. .uxna) = u E U тогда и только тогда, когда car(u) = true и выполняются предварительные условия из CR (т. е. cr(u) = true).
Определение 11. Роли, для которых не существует ни одного атрибут-условия car E CA, будем называть классическими, а способ их назначения учётным записям пользователей — классическим.
По определению функции can_assign классическая роль т E Rk может быть назначена учётной записи пользователя (u,ux1,... ,uxna) = u E U сессией, функционирующей от имени администратора u2 E U, тогда и только тогда, когда т E E can_assign (CR, AUA(u2)).
Предположение 3. Будем считать, что если для некоторой роли т E R существует атрибут-условие car E CA, то она всегда назначается автоматически и не может быть назначена классическим способом. В этом случае множество всех ролей R может быть представлено в виде R = Rk U Ra, Rk П Ra = 0, где Rk — классические роли и Ra — множество атрибут-ролей.
Предположение 4. Будем считать, что учётная запись system авторизована на все административные роли ARa E AR, такие, что can_revoke-1(ARa) = Ra и can_assign-1(ARa) = Ra.
Утверждение 1. Пусть атрибут-роли т1,т2 E Ra таковы, что т1 > т2 и атрибут-условие для роли т2 имеет вид car2 (u) = car2 (t1(U),... ,tk(u)). Тогда атрибут-условие для роли т1 имеет вид cari (u) = cari (tk+1(U),... ,car2 (u),... ,tk+p(u)), tj, E values(aj), т. е. для возможности авторизации на некоторую роль учётная запись пользователя должна удовлетворять и всем атрибут-условиям для дочерних ролей.
Доказательство. Пусть r1 E UA(U), u E U, r1 E Ra. Отсюда следует, что cari (й) = true. По определению иерархии, т2 E UA(U) и car2 (й) = true. Таким образом, из cari (u) = true всегда следует car2 (u) = true. Следовательно, car2 (u) = true является необходимым условием для cari (u) = true, и cari (u) = = cari (t1(u),..., car2 (u),... ,tk (u)). ■
Определение 12. Функция ограничения действий над учётной записью пользователя — это функция H : U х Г х Ф ^ 2х*, значение которой для каждого действия
о,1 E Ф, выполненного над учётной записью пользователя u E U и приведшего систему в текущее состояние Y E Г, равно множеству действий, которые могут быть выполнены над заданной учётной записью пользователя для перехода в последующее состояние. Множество Ф всех возможных действий над учётной записью пользователя описано в таблице.
Пример 4. Пусть H (u, Yt, о-]) = {о2, о3,... , оч}. Это означает, что после выполнения над учётной записью пользователя ui действия о1 над данной учётной записью в системе могут быть выполнены только действия из подмножества {о2, о3,... , од} С Ф.
Определение 13. Траектория переходов Tr : U х Г х Г х H ^ 2'* —это функция, задающая конечную последовательность действий y% E Ф, которая должна быть выполнена над учётной записью пользователя ui E Ui в системе, находящейся в состоянии Yo E Г, для перехода системы в некоторое новое состояние y1 E Г при условии, что множество возможных действия ограничено значением функции H(u,Yo, Ф).
Траектория используется пользователем system для определения последовательности выполнения автоматических действий по отзыву и назначению ролей.
Предположение 5. Администраторы системы могут выполнять действия над учётными записями пользователей в произвольном порядке при условии, что одновременно над этими учётными записями не выполняет никаких действий сессия от имени system (т. е. в текущий момент времени траектория действий для данной учетной записи пользователя пуста).
Пусть Tt(U,y0,Y, H(й^0,о0)) = {о1,... ,оп}. Введём обозначения: tr [0] = о1 — первое действие, выполненное в системе над учётной записью й из состояния Y0; tr [1] = о2 —второе действие и т.д. То есть если Y = оп (... о2(о1(о0^)))), то Tt(U, Yo, Y, H (й, Yo, оо)) = (tr [0] ,... ,tr [n]) = (о1,..., оп), где Oi E H (u,Yi,tr [i - 1]). Ограничения на разрешённые для каждого состояния системы действия и порядок их выполнения необходимы, так как операторы не являются коммутативными. Результирующее состояние системы зависит от порядка, в котором были выполнены действия.
Правила преобразования состояний семантической ролевой модели
Правило Исходное состояние Yi = (S, Ui, U Ai, useri, rolesi, H, TRi) Результирующее состояние Y2 = (s, U 2, UA2, user2, roles2, H,TR2^
7i=take role(x,r) — активация сессией одной из авторизи-рованных ролей 71 G H (user (x), Yi, 7), x1 G S, r G R, r G UA (user (x)) H (user (x) , Y2, 71) = H (user (x) , Yi, 7), TR2 = TRi, S2 = Si, PA2 = PAi, user2 = useri, UA2 = UAi, roles2 (x) = = rolesi (x) U {r}, для x2 € S \ {xi} выполняется roles2 (x2 ) = rolesi (x2 )
a2=remove role(x,r) — удаление из сессии одной из ранее активированных ролей S2 G H (user (x), Yi,7), xi G S, r G R, r G roles (x) TR2 = TRi, S2 = Si, PA2 = PAi, H (user (x), Y2, 72) = H (user (x), Yi, 7), user2 = useri, UA2 = UAi, roles2 (xi) = = rolesi (xi) \ {r}, для x2 € S \ {xi} выполняется roles2 (x2 ) = rolesi (x2 )
73 = assign role(ui, U2,r) — назначение роли классическим способом 73 G H(ui,Yi,7), ui, u,2 G U, r G Rk, r G can assign(CR, AU A (u2)) H (ui,Y2,73) = H (ui,Yi, 7), S2 = Si, PA2 = = PAi, user'2 = useri, roles2 (xi) = rolesi (xi) \ {r}, для u € U \ {ui} выполняется UA2 (u) = UAi (u), UA2 u) = UAi u)U{r}, roles2 = rolesi
74=revoke role(ui, U2,r) — отзыв роли классическим способом 74 G H (ui,Yi,7), x G S, ui,u2 G U, r G Rk, r G G can revoke (AUA (u,2)); для всех x, таких, что user (x) = ui, выполняется r = roles (x) TR2 = TRi; если для r существуют родительские роли, то H (ui, Y2,74) = {74} (нельзя выполнять никаких действий, пока родительские роли не будут отозваны); иначе H (ui, Y2, 74) = H (ui,Yi,7); S2 = Si, PA2 = PAi, user2 = useri, для u € U \ {ui} выполняется UA2 (u) = UAi (u), UA2 (ui) = = UAi (ui) \ {r}, roles2 (x) = rolesi (x) \ {r}
75 = change user -attr (u,i,v) — изменение значения i-го атрибута учётной записи пользователя на новое значение v tri [0] =75, 75GH (u, Yi, 7), x G S, u = (u, uxi, ..., uxi, ...,xn) G U, xi = v tr2 [0] = 78, H (u,Y2,75) = {78} (после изменения атрибутов нельзя выполнять никаких действий, кроме перерасчёта ролей), u = (u, uxi,... ,v,..., uxn), для u € U \ {u} выполняется U2 = U i, S2 = Si, PA2 = PAi, user2 = useri, UA2 = UAi, roles2 = rolesi
76 = auto assign -role (ui, r) — автоматическое назначение роли tri [0] = 76, x G S, ui G U, r G Ra, car (ui) = true H(ui,Y2,76) = {76,7r}, U2 = Ui, S2 = Si, PA2 = PAi, user2 = useri, для u € U \ {ui} выполняется UA2 (u) = UAi (u), UA2 (ui) = = UAi (ui) U {r}, roles2 = rolesi
77 = auto revoke -role (ui, r) — автоматический отзыв роли tri[0] = 77, x G S, ui G G U, r G UA (ui), r G Ra, car (ui) = false H (ui, Y2, 77) = {76,77}, U2 = Ui, S2 = = Si, PA2 = PAi, user2 = useri, для u,2 € € U \ {ui} выполняется UA2 (u2) = UAi (u-2), UA2 (ui) = UAi (ui) \ {r}, roles2 = rolesi
78 = auto recalculate^) — построение траектории автоматического отзыва и назначения ролей tri[0] = 78, u G U H (u,Y2,78) = {76,77}, TR2 = TRi П {77i, 772, ...,77k ,76i, ... ,76m}, где 77i —действие по отзыву роли ri € Ra, 76j — действие по назначению роли rj € Ra, S2 = Si, PA2 = PAi, user2 = useri, UA2 = UAi
Пример 5. Последовательный отзыв всех родительских ролей при отзыве дочерней роли у учётной записи пользователя и Е и может быть выражен следующей траекторией: Тт (и, ^ц, Ъ+1, Н (и, ^ц, &п)) = (аг2,... , агч), где аГ1 —действие по отзыву роли Т\ и г2,... ,Тд — родительские роли для Т\. Таким образом, ни одно другое действие над данной учётной записью пользователя в системе не может быть выполнено, пока у неё не будут отозваны все роли, согласно иерархии.
Определение 14. Семантически осмысленная модель ролевого управления доступом задается множествами и, Я, Р, ЯН, СА, СЯ, V, А, АЯ, АР и функциями РА,
U A, AUA, H, Tr, roles и user. При этом множества CA, A, V, U составляют семантический контекст ролевой модели.
Семантический контекст ролевой модели отражает связь между множествами учётных записей, прав доступа и ролей, организационно-штатной структурой и спецификой деятельности предприятия.
Предположение 6. В рамках данной работы считается, что административные роли AR не имеют семантической составляющей и назначаются всегда классическим способом.
Расширив определение 5 за счет семантического контекста и учёта траектории переходов, введём определение семантической системы ролевого управления доступом.
Определение 15. Семантическая система ролевого управления доступом — это конечный автомат Е = (Г, Q,a, Ф), состояния которого задаются кортежем y =
= (s,U ,U A,user,roles, H,Tr^ € Г , а правила перехода между состояниями определяются предварительными условиями CR, атрибут-условиями CA, функцией ограничения действий H и траекторией Tr.
Предположение 7. Предполагается, что множества P, R, RH, A, V, AR, а также условия CR и CA не изменяются в процессе функционирования системы.
3. Анализ безопасности семантической системы ролевого управления доступом
3.1. Изменение атрибутов учётной записи и расчёт т р а е к т о р и и п е р е х о д а с и с т е м ы м е ж д у с о с т о я н и я м и
Сформулируем и обоснуем правила, на основании которых определяется порядок следования элементов в траектории Tr.
Утверждение 2. Пусть в результате успешного выполнения действия а5 система Е = (Г, Q,a, Ф) перешла в состояние Yi, где атрибуты учетной записи пользователя U € U изменились таким образом, что необходимо отозвать у него атрибут-роли r11,r12,... , rik € Ra и назначить ему атрибут-роли r21, r22,... , r2m € Ra, переведя систему в состояние y2. Пусть Tr (U,Y1 ,Y2,H) —траектория перехода из состояния Y1 в состояние y2. Переход из состояния Y1 в состояние y2 по траектории Tr возможен только в том случае, если построенная траектория удовлетворяет следующим свойствам:
1) действия а7 по отзыву ролей должны следовать в траектории перед действиями по назначению ролей
2) если ri и rj — такие роли, что ri > rj, то (rj) должно следовать в траектории раньше, чем a7 (ri), и a6 (ri) должно выполняться раньше, чем a6 (rj).
Доказательство. Покажем достаточность выполнения условий 1 и 2 для возможности перехода по заданной траектории TR. Невозможность выполнения одного или более действий в траектории перехода может произойти в одном из двух случаев.
С л у ч а й 1. Пусть последовательность действий в траектории TR такова, что некоторой учётной записи U необходимо автоматически назначить роль ra, но данное назначение противоречит предварительным условиям CR, так как учётная запись пользователя U уже авторизована на роли из множества {r11, r12,... , r1k} С Ra, исключающие назначение роли ra. Данная ситуация противоречит условию 1 утверждения, так как действия по отзыву ролей r11, r12,... , r1k всегда выполняются до выполнения действий по назначению новых ролей.
Случай 2. Пусть последовательность действий в траектории TR такова, что некоторой учётной записи и необходимо автоматически назначить роль ra, но данное назначение противоречит предварительным условиям CR, так как учётная запись пользователя и не авторизована на роли из множества {r21, r22, r2y-i,... , r2y+\,... ,r1m} С Ra, являющиеся предусловием для назначения роли ra. По определению иерархии, если роль r2 является предусловием для роли ri, то r1 > r2. Следовательно, данная ситуация противоречит условию 2 утверждения, так как дочерние роли назначаются учётной записи пользователя раньше, чем родительские роли. ■
Замечание. Условия утверждения 2 являются необходимыми, но не достаточными для перехода в состояние y2. Невозможность выполнения действий, заданных траекторией, может произойти также в результате некорректного определения предварительных условий, если две или более ролей из множества {r21, r22,... , r2m} С Ra являются взаимоисключающими. Если предварительные условия CR не противоречат атрибут-условиям CA и ни одна из ролей r21,r22,..., r2m G Ra не исключает других ролей из того же множества, то условия утверждения являются необходимыми и достаточными для перехода в состояние y2 по вычисленной траектории Tr.
Утверждение 3. Пусть семантически осмысленная система ролевого управления доступами Е = (Г, Q,a, Ф) содержит только атрибут-роли (т. е. R = Ra, ARa = AR) и учётную запись system, от имени которой инициируется сессия, выполняющая автоматический перерасчёт назначенных учётной записи пользователя ролей при изменении её атрибутов согласно траектории, удовлетворяющей условиям утверждения 2. Пусть атрибуты учётной записи пользователя полностью описывают его должностные обязанности и все изменения атрибутов передаются в каталог системы ролевого управления доступом. Тогда каждая учётная запись пользователя и G U всегда имеет набор ролей, соответствующих его должностным обязанностям.
Доказательство. Пусть должностные обязанности учётной записи пользователя, соответствующей некоторому сотруднику предприятия, характеризуются набором атрибутов A = a1,a2,... ,aN. Пусть r1,r2 G Ra — атрибут-роли, с которыми связаны различные атрибут-условия car1 и car2 соответственно. Пусть первоначально должностные обязанности учётной записи пользователя и были таковы, что car1 (и) = true и car2 (и) = false. В таком случае учётной записи пользователя назначена только роль r1 и соответствующие ей права доступа. Пусть после смены должности атрибуты учётной записи пользователя изменяются таким образом, что car1 (и) = false и car2 (и) = true. В этом случае, согласно правилам, приведённым в таблице, и определению атрибут-роли, в системе инициируется автоматический отзыв роли r1 и автоматическое назначение роли r2. Поскольку, по определению модели RBAC, права доступа назначаются учётной записи пользователя только посредством ролей, она будет обладать только правами доступа, соответствующими новой должности связанного с ней сотрудника. ■
3.2. Анализ действий по переходу между состояниями Проведем анализ действия change_nser_attr, выполняемого сессией от имени учётной записи attribute_scmrce. Выполнение действия change_,user_attr (и,г,ь) для заданного состояния системы является успешным только в том случае, если выполняются следующие условия:
— значение некоторого атрибута учётной записи пользователя, соответствующего сотруднику в системе учёта кадров предприятия, не совпадает со значением соот-
ветствующего атрибута учётной записи связанного пользователя U € U в каталоге учётных записей системы ролевого управления доступом;
— в данный момент времени над учётной записью пользователя не выполняется никаких действий (Tr(U,Yi,Y2, H) = 0). В случае успешного выполнения действия над заданным состоянием системы Y1 = (U1,UA1,User1 ,roles1) новое состояние
Y1 = (Ü2, U A2,user2,roles^j отличается от исходного множеством значений U.
Результатом успешного выполнения действия по изменению атрибутов учётной записи
U1 = (U,UX1, . . . ,UXi, . . . ,UXn) € U является состояние, в котором U2 = (jJ1 \ {U}^ U
U{u2}, где U2 = (u,ux1 ,... ,v,. . . ,UXn), v = UXi. В случае неуспешного выполнения действия состояние системы не изменится.
Проведем анализ действий auto_assign_role и auto_revoke_role, выполняемых сессией-инициатором system. Выполнение действия auto_assign_role (U, r) для заданного состояния системы является успешным только в том случае, если выполняются следующие условия:
— выполняются атрибут-условия назначения роли car (U) = true;
— выполняются предварительные условия CR. Поскольку субъект system авторизован на все возможные административные роли для управления назначениями атрибут-ролей, то значение функции can_assign (CR, AUA (system)) зависит только от аргумента CR;
— a6 является текущим значением траектории (tr[0] = а6).
В случае успешного выполнения действия над заданным состоянием системы Y1 = (U1, UA1,user1,roles1) новое состояние y2 = (u2,UA2,user2,roles2^ отличается от исходного значением функции UA. Результатом успешного выполнения действия является состояние, для которого UA2(u1) = UA1(u1) U {r}. Выполненное действие удаляется из траектории. В случае неуспешного выполнения действия состояние системы не изменится.
Рассмотрим действие автоматического отзыва роли auto_revoke_role (U,r), где сессия от имени учётной записи пользователя system отзывает у учётной записи пользователя U роль r € Ra. Выполнение данного действия для заданного состояния системы является успешным только в том случае, если:
— учётная запись пользователя U авторизована на роль r, т. е. r € UA (u);
— значения атрибутов учётной записи пользователя не соответствуют атрибут-условиям назначения для роли r, т. е. car (U) = false;
— а7 является текущим значением траектории (tr[0] = а7).
В случае успешного выполнения действия над заданным состоянием системы Y1 = (U1, UA1,user1,roles1) новое состояние y2 = (u2,UA2,user2,roles2^ отличается от исходного значением функции UA. Результатом успешного выполнения действия является состояние, для которого UA2(u1) = UA1(u1) \ ({r} U up (r)), где up (r) —множество ролей, больших r. Выполненное действие удаляется из траектории. В случае неуспешного выполнения действия состояние системы не изменится.
Рассмотрим действие auto_recalculate (U). Условием выполнения данного действия является переход системы в состояние, где а8 является единственным возможным действием: H(U,Y,&) = {^e}, TR[0] = а8. Согласно таблице, такая ситуация возможна в результате успешного выполнения действия а5. Результатом выполнения действия
является траектория Tr, состоящая из действий а6 и а7 в соответствии с количеством ролей, которые необходимо назначить или отозвать.
Проведем анализ действий а3 = assign_rcle и а4 = revoke_role, выполняемых сессией от имени учетной записи администратора системы admin G IN IT {а3,а4}. Выполнение действия assign_role(admin, и, r) для заданного состояния системы Y1 является успешным только в том случае, если выполняются следующие условия:
— r G Rk — классическая роль;
— выполняются предварительные условия CR : cr (и) = true;
— r G can_assign (CR,AUA (admin));
— a3 G H (u,y,&) и над учётной записью пользователя в данный момент не выполняется никаких других действий — Trfa,^,^, H) = 0.
В случае успешного выполнения действия над заданным состоянием системы Y1 = (U1, U A1,nser1,r0les1) новое состояние Y2 = (u2 ,U A2,'User2,roles2^ отличается от исходного значением функции UA. Результатом успешного выполнения действия является состояние, для которого UA2 (и) = UA1 (и) U {r}. В случае неуспешного выполнения действия состояние системы не изменится.
Аналогичные условия выполняются для действия классического отзыва роли revoke_role(admin, и, r), где сессия от имени учётной записи администратора admin отзывает у учётной записи пользователя и роль r G Rk. Выполнение данного действия для заданного состояния системы является успешным только в том случае, если:
— r G Rk — классическая роль;
— {r} U ир (r) С can_revoke (AUA (admin)), где ир (r) — множество ролей, старших r;
— а4 G H (u,y,&) и над учётной записью пользователя в данный момент не выполняется никаких других действий — Trfa,^,^, H) = 0.
В случае успешного выполнения действия над заданным состоянием системы Y1 = (U 1, UA1,user1,roles1) новое состояние y2 = (u2,U A2,'user2,roles-^ отличается от исходного значением функции U A. Результатом успешного выполнения действия является состояние, для которого UA2 (и) = UA1 (и) \ ({r} U ир (r)). Выполненное действие удаляется из траектории. В случае неуспешного выполнения действия состояние системы не изменится.
3.3. Критерий безопасности функционирования системы Сформулируем критерий безопасного функционирования системы семантического ролевого управления доступом и покажем, что в случае, когда управление назначениями атрибут-ролей осуществляется автоматически от лица единственной доверенной учётной записи system G IN IT (а), а классические роли управляются исключительно сессиями, функционирующими от имени учётных записей пользователей из подмножества администраторов Ua С INIT(а), Ua П {system} = 0, то система является безопасной с точки зрения данного критерия.
Определение 16. Состояние y G Г системы ролевого управления доступом Е = (r,Q,a, Ф) называется безопасным, если каждой учётной записи пользователя и G U назначены только роли, не противоречащие условиями CR и CA.
Определение 17. Система Е = (r,Q,a, Ф) называется безопасной, если любое состояние Yg, достижимое из начального безопасного состояния y посредством действий, инициированных сессией от имени любой из учётных записей пользователей и G IN IT (Ф), является безопасным.
Теорема 1. Пусть семантически осмысленная система ролевого управления доступом Е = (Г, Q, a, Ф) обладает следующими свойствами:
1) все действия по назначению и отзыву атрибут-ролей Ra G R инициируются автоматически в порядке, определённом траекторией Tr;
2) множество значений функции IN IT (а5) включает в себя ровно одну учётную запись пользователя attribute _scurce, т. е. IN IT (а5) = {attribute_source};
3) множество значений функции IN IT (а6,а7) включает в себя ровно одну учётную запись пользователя system, т. е. INIT (а6,а7) = {system};
4) INIT (а3, а4) = Ua, при этом INIT (а3, а4) П INIT (а6),а7) = 0.
Тогда, если начальное состояние ролевой модели Yo = (jJ0,U A0,'user0,roles0^ является безопасным, то система Е является безопасной.
Доказательство. Пусть начальное состояние ролевой модели y0 является безопасным. Поскольку при выполнении действий а3 и а6 по назначению роли учётной записи пользователя осуществляется проверка того, что новое назначение не противоречит предварительным условиям CR, нарушение свойства безопасности системы при переходе из Y0 в новое состояние Yg может произойти только в следующих случаях.
С л у ч а й 1. Невозможность автоматического назначения роли в результате назначения взаимоисключающей роли администратором системы: а6 (а3 (а5 (y0))) = Yg. Пусть атрибуты учётной записи пользователя в системе были изменены в результате действия а5 и сессией администратора и(1 G Ua инициируется выполнение действия а3 по назначению классической роли rk до того, как сессия system инициирует действие а6 по назначению атрибут-роли ra. После инициализации а6 может возникнуть ситуация, когда атрибут-роль ra должна быть назначена учётной записи пользователя по условиям CA, но не может быть назначена по условиям CR, так как роль rk является взаимоисключающей с ra. Данная ситуация противоречит условию 1 теоремы, так как любые другие действия над учётной записью пользователя в системе запрещены до завершения цепочки действий а7 и а6, выполняемых согласно траектории, рассчитанной при выполнении а8. Действие а8 является единственным разрешённым действием после успешного выполнения а5, и до завершения а8 любые другие действия над заданной учётной записью запрещены.
С л у ч а й 2. Невозможность автоматического назначения роли в результате отзыва администратором системы роли, входящей в предусловие: а7 (а4 (а5 (y0))) = Yg. Пусть атрибуты учётной записи пользователя в системе были изменены в результате действия а5 и сессия администратора иa G Ua инициирует выполнение действия а4 по отзыву классической роли rk до того, как сессия system инициирует действие а6 по назначению атрибут-роли ra. После инициализации а4 может возникнуть ситуация, когда роль rk должна быть назначена учётной записи пользователя по условиям CA, но не может быть назначена ей по условиям CR, так как авторизация на роль rk является обязательным предусловием назначения ra. Аналогично случаю 1, данная ситуация противоречит условию 1 теоремы.
С л у ч а й 3. После завершения перерасчёта ролей сессия администратора отзывает роль, дочернюю для автоматически назначенной роли а4 (а6 (а5 (y0))) = Yg. Пусть атрибуты учётной записи пользователя в системе изменены в результате действия а5 и атрибут-роль ra назначена автоматически действием а6, но на следующем шаге сессия администратора и(1 G Ua инициирует выполнение действия а4 по отзыву классической роли r'k, которая является дочерней (необходимым предусловием) для роли ra. После инициализации а4 может возникнуть ситуация, когда атрибут-роль ra должна быть на-
значена учётной записи пользователя по условиям CA, но не может быть назначена по условиям CR, так как роль rk является предварительным условием для ra. Данная ситуация противоречит условиям 3 и 4 теоремы. Если классическая роль rk обязательно назначается всем учётным записям пользователей, обладающим ролью ra, то это означает, что rk > ra. Следовательно, rk G can_assign (CR,AUA (щ)) и, по определению функции INIT (а), 4a G INIT (а6, а7). Но тогда либо INIT (a3,a4)nIN IT (а6, а7) = 0, либо роль rk имеет атрибут-условие назначения и не является классической. Противоречие.
С л у ч а й 4. Наличие двух и более администраторов атрибут-ролей.
Пусть а7 (а6 (а5 (y0))) = Yg и права по администрированию атрибут-ролей назначены одновременно двум и более учётным записям пользователей system1 и system2. Атрибуты учётной записи пользователя в системе были изменены в результате действия а5, и сессия system1 G INIT (а6,а7) инициирует выполнение действия а6 по назначению атрибут-роли ra1 до того, как сессия system2 G INIT (а6,а7) инициирует действие а7 по отзыву атрибут-роли ra2, являющейся взаимоисключающей для ra1. После инициализации а6 возможна ситуация, когда роль ra1 может быть назначена учётной записи пользователя по условиям CA, но её назначение блокируется условиями CR, так как роль ra2 является взаимоисключающей с ra1 . Данный случай противоречит требованию 3 теоремы о единственности субъекта system. ■
Утверждение 4. Необходимым условием для выполнения свойства 4 в теореме 1 является то, что если некоторая роль ra G R является атрибут-ролью, то все её старшие роли также являются атрибут-ролями.
Доказательство. От противного. Если атрибут-роль ra обязательно назначается всем учётным записям пользователей, авторизованным на классическую роль r'kGR, то это означает, что rk > ra. По предположению 2 в этом случае для некоторой административной роли r G AR, такой, что ra G can_revoke (r), выполняется условие rk G can_revoke (r). Следовательно, либо INIT (а3,а4) П INIT (а6,а7) = 0, либо роль rk имеет атрибут-условие назначения и не является классической. Получили противоречие. ■
Замечание Свойство распространения атрибут-условий вверх по иерархии доказано в утверждении 1. Поскольку по предположению 7 на протяжении функционирования системы ролевая иерархия R H остаётся неизменной, то не может возникнуть ситуации, когда классическая роль включена в иерархию атрибут-ролей администратором системы. По определению множества IN IT (а), свойство 3 в теореме эквивалентно требованию AR = ARa U ARk, ARa П ARk = 0, где ARa — административные роли для атрибут-ролей, ARk — административные роли для классических ролей. Следовательно, достаточным условием выполнения свойства 3 в теореме 1 является введение ограничения статического взаимного исключения ролей из подмножеств ARa и ARk.
Заключение
Дополнение классической модели RBAC за счет семантического контекста позволяет адаптировать её к условиям функционирования реальных АИС предприятий, где каждой учётной записи пользователя АИС соответствует сотрудник предприятия с определённым набором должностных обязанностей, а также автоматизировать операции назначения и отзыва ролей. Ряд элементов классической модели и правила преобразования состояний переопределены для возможности разделения операций по назначению ролей на автоматические и выполняющиеся сессиями, функционирующи-
ми от имени администраторов системы. Кроме того, в семантической модели вводится определение иерархии ролей, отличное от классического, не требующее обязательного включения прав доступа дочерних ролей в родительские, так как это свойство не всегда выполняется в реальных системах. Безопасность системы ролевого управления доступом, построенной на основе предложенной модели, подтверждается проведённым анализом переходов между состояниями.
ЛИТЕРАТУРА
1. http://csrc.nist.gov/rbac/rbacSTD-ACM.pdf — National Institute of Standards and Technology, Proposed Standard for Role-Based Access Control.
2. Ferraiolo D., Kuhn D., and Chandramoul R. Role Based Access Control. NewYork: ARTECH HOUSE, INC, 2003. 337 с.
3. Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками: учеб. пособие для вузов. М: Горячая линия — Телеком, 2011. 320 с.
4. 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.
5. Нокс Д. Создание эффективной системы безопасности для Oracle Database 10g. М: Лори, 2007. 576 с.
6. Джоханссон Дж. Обеспечение безопасности. Ресурсы Windows Server 2008. СПб.: Русская редакция, 2009. 544 с.
