CC BY
173
ПРИКЛАДНАЯ ДИСКРЕТНАЯ МАТЕМАТИКА
2008 Математические основы компьютерной безопасности № 1(1)
МАТЕМАТИЧЕСКИЕ ОСНОВЫ КОМПЬЮТЕРНОЙ БЕЗОПАСНОСТИ
УДК 004.94
БАЗОВАЯ РОЛЕВАЯ ДП-МОДЕЛЬ П.Н. Девянин
Институт криптографии, связи и информатики Академии ФСБ России, г. Москва E-mail: [email protected]
На основе ролевых моделей (RBAC) и ДП-моделей компьютерных систем с дискреционным или мандатным управлением доступом строится базовая ролевая ДП-модель. С учетом фактических ролей, прав доступа и возможных действий недоверенных сессий анализируются правила преобразования состояний системы. Обосновываются условия передачи прав доступа ролей сессиями пользователей.
Ключевые слова: компьютерная безопасность, математические модели безопасности, ролевая модель.
Ролевое управление доступом (РУД) [1 - 3] является современным, эффективным механизмом защиты компьютерных систем (КС). С использованием иерархии ролей возможно обеспечение управления доступом, точно соответствующего должностным обязанностям пользователей КС. При этом используемые в РУД механизмы статических и динамических ограничений позволяют реализовать на основе РУД дискреционное или мандатное управление доступом.
Модифицируем определения семейства ролевых моделей RBAC [1 - 3], базовой ДП-модели, БК ДП-модели, ФАС ДП-модели и мандатной ДП-модели [4] для обеспечения возможности анализировать условия реализации информационных потоков по памяти и по времени в КС с РУД. Модифицированную ДП-модель будем называть базовой ролевой ДП-моделью (или, сокращенно, БР ДП-моделью). При этом используем следующие обозначения:
E = O и C - множество сущностей, где O - множество объектов, C - множество контейнеров;
U - множество пользователей, при этом пользователи по определению не являются сущностями;
Lu - множество доверенных пользователей;
Nu - множество недоверенных пользователей, при этом выполняются равенства: Lu и Nu = U, Lu n Nu = 0;
S с E - множество субъект-сессий пользователей;
LS - множество доверенных субъект-сессий;
NS - множество недоверенных субъект-сессий, при этом выполняется равенство LS n NS = 0;
R - множество ролей;
AR - множество административных ролей (AR n R = 0);
Rr = {readr, writer, appendr, executer, ownr} - множество видов прав доступа;
Ra = {reada, writea, appenda, owna} - множество видов доступа;
Rf = {writem, write,} - множество видов информационных потоков;
Rraf = Rr и Ra и Rf - множество видов прав доступа, видов доступа и видов информационных потоков, при этом множества Rr, Ra, Rf попарно не пересекаются;
P с E х Rr - множество прав доступа к сущностям;
UA: U ^ 2r- функция авторизованных ролей пользователей;
AUA: U^ 2ar- функция авторизованных административных ролей пользователей;
PA: R ^ 2Р- функция прав доступа ролей;
user: S ^ U - функция принадлежности субъект-сессии пользователю, задающая для каждого субъект-сессии пользователя, от имени которого она активизирована;
roles: S ^ 2r и 2м - функция текущих ролей субъект-сессий, задающая для пользователя роли, на которые авторизован активизированный от его имени данный субъект-сессия, при этом в каждом состоянии системы для каждого субъект-сессии s е S выполняется включение roles(s) с UA(user(s)) и AUA(user(s));
can_manage_rights: AR ^ 2R - функция администрирования прав доступа ролей, определяющая для каждой административной роли множество ролей, для которых разрешено включать или удалять права доступа во множества их прав доступа с использованием данной административной роли.
Определение 1. Иерархией сущностей называется заданное на множестве сущностей E отношение частичного порядка «<», удовлетворяющее условию: если для сущности e е E имеются сущности e1, e2 е E, такие, что e< e2, e< ei, то e1< e2 или e2< ei. В случае, когда для двух сущностей eb е2 е E выполняются условия e1< e2 и e1 Ф e2, будем говорить, что сущность е1 содержится в сущности-контейнере e2, и будем использовать обозначение e1<e2.
Определение 2. Определим HE: E ^ 2е - функцию иерархии сущностей, сопоставляющую каждой сущности с е E множество сущностей HE(c) с E и удовлетворяющую следующим условиям.
Условие 1. Если сущность e е HE(c), то e < с и не найдется сущности-контейнера de C, такой, что e < d, d < с.
Условие 2. Для любых сущностей e1, e2 е E, e1 Ф e2, по определению выполняются равенство HE(e1) п HE(e2) = 0 и условия:
- если o е O, то выполняется равенство HE(o) = 0;
- если e1 < e2, то или e1, e2 е E \ S, или e1, e2 е S;
- если e е E \ S, то HE(e) с E \ S;
- если s е S, то HE(s) с S.
Определение 3. Иерархией ролей в БР ДП-модели называется заданное на множестве ролей R отношение частичного порядка «<». При этом по определению выполняется условие: для пользователя и е U, если роли r, r' е R, такие, что r е UA(u) и r' < r, то выполняются условия т'е UA(u). В случае, когда для двух ролей r1, r2 е R выполняются условия r1 < r2 и r1 Ф r2, будем использовать обозначение r1 < r2.
Определение 4. Определим HR: R ^ 2R - функцию иерархии ролей, сопоставляющую каждой роли r е R множество ролей HR(r) с R и удовлетворяющую условию: если роль r' е HR(r), то r' < r и не существует роли r'' е R, такой, что r' < r'', r'' < r.
Определение 5. Иерархией административных ролей в БР ДП-модели называется заданное на множестве ролей AR отношение частичного порядка «<». При этом по определению выполняется условие: для пользователя и е U, если административные роли r, r' е AR, такие, что r е AUA(u) и r' < r, то выполняются условия /е AUA(u). В случае, когда для двух ролей r1, ^е AR выполняются условия r1< r2 и г1фг2, будем использовать обозначение ri< r2.
Определение 6. Определим HAR: AR ^ 2AR - функцию иерархии административных ролей, сопоставляющую каждой роли r е AR множество ролей HAR(r) с AR и удовлетворяющую условию: если роль r' е HAR(r), то r' < r и не существует роли r'' е AR, такой, что r' < r'', r'' < r.
Определение 7. Пусть определены: множества пользователей U, сущностей E, субъект-сессий S, прав доступа к сущностям P, доверенных пользователей Ьи, доверенных субъект-сессий LS, множество доступов субъект-сессий к сущностям A с S х E х Ra, множество информационных потоков F с E х E х Rf, функции авторизованных ролей пользователей UA, авторизованных административных ролей пользователей AUA, прав доступа ролей PA, принадлежности субъект-сессии пользователю user, текущих ролей субъект-сессии roles, иерархии ролей HR, иерархии административных ролей HAR, иерархии сущностей HE. Определим G = (UA, AUA, PA, user, roles, A, F, HR, HAR, HE, L№ LS) - состояние системы.
Используем обозначения:
Z(G*, OP) - система, при этом: G* - множество всех возможных состояний, OP - множество правил преобразования состояний G A op G' - переход системы Z(G*, OP) из состояния G в состояние G' с использованием правила преобразования состояний op е OP.
Если для системы Z(G*, OP) определено начальное состояние, то будем использовать обозначение: Z(G*, OP, G0) - система Z(G*, OP) с начальным состоянием G0.
БР ДП-модель предназначена для анализа условий реализации в КС с РУД информационных потоков, и в ее рамках не предполагается исследовать вопросы администрирования множества ролей, иерархии ролей, иерархии административных ролей, множеств авторизованных ролей пользователей, параметров ограничений. Таким образом, будем использовать следующее предположение.
Предположение 1. В рамках БР ДП-модели на траекториях функционирования системы не изменяются: значения множеств U, Lv, R, функции UA, AUA, HR, HAR. В БР ДП-модели не используются динамические ограничения.
В БР ДП-модели пользователи или субъект-сессии могут быть доверенными или недоверенными. При этом в отличие от доверенных субъектов систем с дискреционным управлением доступом доверенные пользователи или субъект-сессии могут не обладать ролями, включающими все права доступа ко всем сущностям системы. Чтобы не усложнять описание правил преобразования состояний системы в рамках БР ДП-модели, целесообразно использовать следующие предположение и определение.
Предположение 2. Каждый пользователь или субъект-сессия системы Z(G*, OP) вне зависимости от имеющихся у нее авторизованных ролей является либо доверенной, либо недоверенной. Доверенные поль-
зователи или субъект-сессии не создают новых субъект-сессий. Каждый недоверенный пользователь или субъект-сессия могут создать только недоверенную субъект-сессию.
Определение 8. Доверенную субъект-сессию назовем корректной относительно информационных потоков по времени, если она не участвует в их реализации.
Используем обозначения:
LFS с LS - множество доверенных субъект-сессий корректных относительно информационных потоков по времени, NFS с LS - множество доверенных субъект-сессий некорректных относительно информационных потоков по времени, при этом по определению выполняются равенства LFS n NFS = 0, LFS и NFS = LS.
В рамках предположений 1 и 2 будем использовать следующее сокращенное обозначение для состояния системы G = (PA, user, roles, A, F, HE).
Предположение 3. Только информационный поток по памяти к сущности, функционально ассоциированной с субъект-сессией, приводит к изменению вида преобразования данных, реализуемого этой субъект-сессией. Функционально ассоциированными с субъект-сессией являются сущности, от которых зависит вид преобразования данных, реализуемого субъект-сессией в данном или некотором последующем состоянии системы Z(G*, OP). Множество сущностей, функционально ассоциированных с субъект-сессией, не изменяется в процессе функционирования системы.
В существующих КС при создании субъект-сессии множество функционально-ассоциированных с ней сущностей может задаваться в зависимости от многих параметров (например, в зависимости от пользователя, создающего субъект-сессию, от сущности, из которой создается субъект-сессия, или от компьютера, на котором создается субъект-сессия). Для упрощения описания правил преобразования состояний в дальнейшем будем использовать следующее предположение.
Предположение 4. При создании новой субъект-сессии s множество функционально ассоциированных с ней сущностей задается только в зависимости от сущности, из которой создается субъект-сессия s, и пользователя, который либо создает субъект-сессию s, либо от имени которого другая субъект-сессия создает субъект-сессию s.
Используем следующие обозначения:
[s] с E и U - множество сущностей, функционально ассоциированных с субъект-сессией s (при этом по определению выполняется условие s е [s]), и пользователей, каждый из которых может создать субъект-сессию, являющуюся функционально ассоциированной сущностью с субъект-сессией s.
fa: U х E ^ 2е и 2U - функция, задающая множества сущностей, функционально ассоциированных с субъект-сессией, при ее создании пользователем (или от имени пользователя другой субъект-сессией) из сущности.
Определение 9. Доверенную субъект-сессию у назовем функционально корректной, если во множество функционально ассоциированных с ней сущностей [y] не входят недоверенные субъект-сессии.
Определение 10. Доверенную субъект-сессию y назовем корректной относительно доверенной субъект-сессии у' и сущности e (не являющейся доверенной субъект-сессией), если субъект-сессия y не реализует информационный поток по памяти от сущности e к сущности e', функционально ассоциированной с доверенной субъект-сессией y'.
Используем обозначение:
y(E) с E х LS - множество пар вида доверенная субъект-сессия и сущность, относительно которых корректна доверенная субъект-сессия у.
Предположение 5. Субъект-сессии могут иметь друг к другу только доступ владения owna. Роли могут обладать к субъект-сессиям только правом доступа владения ownr. Если субъект-сессия si реализовала информационный поток по памяти от себя к сущности, функционально ассоциированной с другой субъект-сессией s2, то субъект-сессия s1 получает: доступ владения owna к субъект-сессии s2, возможность использовать роли из множества ролей roles(s2) (при этом субъект-сессия s1 не может изменить множество текущих ролей roles(s2)), возможность получать доступ владения owna к субъект-сессиям, доступом владения к которым обладает субъект-сессия s2, возможность использовать административные роли субъект-сессии s2 для осуществления действий над ролями и сущностями, которые позволяют ей выполнять права доступа ролей субъект-сессии s2.
Используем следующие обозначения:
de_facto_roles: S ^ 2R и AR - функция фактических текущих ролей субъект-сессий, при этом по определению в каждом состоянии системы G = (PA, user, roles, A, F, HE) для каждой субъект-сессии s1 е S выполняется равенство: de_facto_roles(s1) = roles(s1) и {r е R и AR: существует s2 е S, (s1, s2, owna) е A и r е roles(s2)}.
de_facto_rights: S ^ 2P - функция фактических текущих прав доступа субъект-сессий, при этом по определению в каждом состоянии системы G = (PA, user, roles, A, F, HE) для каждой субъект-сессии s е S выполняется равенство: de_facto_rights(s) = {p е P: существует r е de_facto_roles(s) иp е PA(r)}.
defactoactions: S ^ 2Р х 2R - функция фактических возможных действий субъект-сессий, при этом по определению в каждом состоянии системы G = (PA, user, roles, A, F, HE) для каждой субъект-сессии s1 е S выполняется равенство: de_facto_actions(s 1) = (PA(roles(s1)) х can_manage_rights(roles(s1) n AR)) и {(p, r) е P х R: существует s2 е S, (s1, s2, owna) е A, r е can_manage_rights(AR n roles(s2)) ие PA(roles(s2))}.
В рамках БР ДП-модели используются следующие 19 правил преобразования состояний: take_role(x, r), remove_role(x, r), grant_right(x, r, (y, ar)), remove_right(x, r, (y, ar)), create_entity(x, r, y, z),
create_first_session(u, r, y, z), create_session(x, r, y, z), delete_entity(x, y, z), rename_entity(x, y, z), control(x, y, z), access_own(x, y), take_access_own(x, y, z), access_read(x, y), access_write(x, y), access_append(x, y),
flow(x, y, y', z), find(x, y, z), post(x, y, z),pass(x, y, z). Дадим определение.
Определение 11. Монотонное правило преобразования состояний - правило преобразования состояний из множества OP, применение которого не приводит к удалению из состояний: ролей из множества текущих ролей субъект-сессии, прав доступа ролей к сущностям, субъект-сессий или сущностей, доступов субъект-сессий к сущностям, информационных потоков.
По определению 11 немонотонными правилами преобразования состояний будут являться: remove_role(x, r), remove_right(x, r, (y, ar)), delete_entity(x, y, z). Возможно доказать утверждение 1.
Утверждение 1. Пусть Go = (PA0, user0, roles0, A0, F0, HE0) - начальное состояние системы Z(G*, OP, G0). Пусть также существуют состояния системы G1, ..., GN = (PAN, userN, rolesN, AN, FN, HEN) и правила преобразования состояний op1, ., opN, такие, что G0 Á^ G1 Áop2 ... ÁopN GN, где N > 0. Тогда существуют состояния G'1, ..., G'M = (PA'M, user'M, roles'M, A'M, F'M, H'EM), где M> 0, и монотонные правила преобразования состояний op\, ..., op'Mтакие, что G0 Áop1 G'1 Áop2 ... ÁopMG'M и выполняются следующие условия.
Условие 1. Верно включение SN с S'M, и для каждого субъект-сессии s е SN выполняются условия: userN(s) = user'M(s), rolesN(s) с roles'M(s).
Условие 2. Верно включение EN с E'M, и для каждой сущности e е EN выполняется условие
HENÍe) с H'ElÁe).
Условие 3. Для каждой роли r е R выполняется условие PAN(r) с PA'M(r).
Условие 4. Верно включение AN с A'M.
Условие 5. Верно включение FN с F'M.
Таким образом, в рамках БР ДП-модели при анализе условий передачи прав доступа, реализации информационных потоков по памяти или по времени возможно использование только монотонных правил преобразования состояний. При исследовании в статье условий передачи прав доступа ролей кооперирующими субъект-сессиями пользователей не применяются следующие монотонные правила: create_entity(x, r, y, z), create_session(x, r, y, z), rename_entity(x, y, z), access_read(x, y), flow(x, y, y', z), find(x, y, z), pass(x, y, z). Данные правила преобразования состояний введены в БР ДП-модель для анализа условий реализации информационных потоков по времени. Следовательно, приведем в таблице условия и результаты применения только правил преобразования состояний, которые необходимы для анализа условий передачи прав доступа ролей.
Монотонные правила преобразования состояний, используемые для передачи прав доступа ролей
Правило Исходное состояние G = (PA, user, roles, A, F, HE) Результирующее состояние G' = (PA', user', roles', A', F, HE')
1 2 3
take role(x, r) x e S, r e UA(user(x)) и AUA(user(x)) S' = S, E = E, PA'= PA, user'=user, A'= A, F = F, HE = HE, roles'(x) = roles(x) и {r} и для x' e S \ {x} выполняется равенство roles'(x') = roles(x')
grant right(x, r, (y, ar)) x e S, y e E, (y, ar) e P и ((y, ownr), r) e defacto actions(x) S' = S, E' = E, user' = user, roles' = roles, A' = A, HE = HE, PA'(r) = PA(r) и {(y, ar)}, и для r' e R \ {r} выполняется равенство PA'(r') = PA(r'), если x e (NS и NFS) n S, то F' = F и {(x, s, writet): s e (NS и NFS) n S, x Ф s и r e de facto roles(s)}, если x e LFS n S, то F' = F
createfirst session (u, r, y, z) u e Nu, y e E, z £. E, (y, execute,) e PA(UA(u)) и r e can manage rights(AUA(u)) S' = S и {z}, E' = E и {z}, A' = A, user'(z) = u, для s e S выполняется равенство user'(s)=user(s), F' = F, roles'(z) = 0, для s e S выполняется равенство roles'(s) = roles(s), [z] = fa(u, y), HE'(z) = 0, для e e E выполняется равенство HE'(e) = HE(e), PA'(r) = PA(r) и {(z, ownr)}, для r' e R \ {r} выполняется равенство PA'(r') = PA(r')
control(x, y, z) x, y e S, x Ф y, z e E, z e [y] и или x = z, или (x, z, writem) e F S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE'= HE, A' = A и {(x, y, owna)}, если x e (NS и NFS) n S, то F' = F и {(x, e, writet): e e E, x Ф e и y < e}, если x e LFS n S, то F' = F
Продолжение таблицы
1 2 3
access ownix, y) x, y e S, x Ф y, (y, ownr) e defacto rights(x) S' = S, E' = E, PA' = PA, user' = user, roles'= roles, HE = HE, A' = A и {(x, y, owna)}, если x e (NS и NFS) n S, то F' = F и {(x, e, write,): e e E, x Ф e и y < e}, если x e LFS n S, то F' = F
take access ownix, y, z) x, y, z e S, x Ф z, {(x, y, owna), (y, z, own,)} с A S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE = HE, A' = A и {(x, z, owna)}, если x e (NS и NFS) n S, то F' = F и {(x, e, write,): e e E, x Ф e и z < e}, если x e LFS n S, то F' = F
access write(x, y) x e S, (y, writer) e defacto rights(x) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE = HE, A' = A и {(x, y, writea)}, если x e (NS и NFS) n S, то F' = F и {(x, y, writem)} и {(x, e, write,): e e E, x Ф e и y < e}, если x e LFS n S, то F' = F и {(x, y, writem)}
access append(x, y) x e S, (y, appendr) e defacto rights(x) S' = S, E' = E, PA' = PA, user' = user, roles' = roles, HE = HE, A' = A и {(x, y, appenda)}, если x e (NS и NFS) n S, то F' = F и {(x, y, writem)} и {(x, e, write,): e e E, x Ф e и y < e}, если x e LFS n S, то F' = F и {(x, y, writem)}
post(x, y, z) x, z e S, y e E, x Ф z, (y, readr) e defacto rights(z) и или (y, a) e de facto rights(x), где a e {writer, appendr}, или (x, y, a) e F, где a e {writem, write} S' = S, E' = E, PA' = PA, user' = user, roles' = roles, A' = A, HE = HE, если a Ф write,, то F' = F и {(x, z, writem)}, если a = write, и x, z e (NS и NFS) n S, то F' = F и {(x, z, write,)}, если a = write, и {x, z} n (LFS n S) Ф 0, то F' = F
Зависимость условий и результатов применения правил преобразования состояний БР ДП-модели показана на рис. 1.
Рис. 1. Зависимость условий и результатов применения правил преобразования состояний
Проанализируем случай, когда для передачи права доступа ролей непосредственно взаимодействуют только две субъект-сессии.
Определение 12. Назовем траекторию функционирования системы Е(0*, ОР) траекторией без кооперации доверенных и недоверенных субъект-сессий для передачи прав доступа, если при ее реализации используются монотонные правила преобразования состояний, и доверенные субъект-сессии: не берут роли во множество текущих ролей, не дают другим ролям права доступа к сущностям, не получают доступ владения к субъект-сессиям.
Определение 13. Пусть G0 = (PA0, user0, roles0, A0, F0, HE0) - состояние системы Z(G*, OP), в котором существуют пользователь u e U и право доступа к сущности (e, a) e P0. Определим предикат can_share((e, a), u, G0), который будет истинным тогда и только тогда, когда существуют состояния G1, ..., Gn = (PAN, userN, rolesN, An, Fn, Hen) и правила преобразования состояний op\, opN, такие, что G0 Âopj Gi Àop2 . ÀopN Gn является траекторией без кооперации доверенных и недоверенных субъект-сессий для передачи прав доступа, и существует субъект-сессия x e SN, такая, что userN(x) = u, и право доступа к сущности (e, a) e de_facto_rightsN(x), где N > 0.
Для упрощения записи алгоритмически проверяемых необходимых и достаточных условий истинности предиката can_share((y, a), u, G0) используем следующие определения.
Определение 14. Пусть G = (PA, user, roles, A, F, HE) - состояние системы Z(G*, OP), в котором существуют недоверенный пользователь или недоверенная субъект-сессия x e Nu u (NS n S), субъект-сессия или недоверенный пользователь y e Nu u S. Определим предикат directly_access_own(x, y, G), который будет истинным тогда и только тогда, когда выполняется одно из следующих условий 1 - 4.
Условие 1. Если y e Nu и x e Nu, то существуют сущность ey e E и роль ry e R, такие, что (ey, executer) e PA(UA(y)), ry e can_manage_rights(AUA(y)), и выполняется одно из условий: (ry e UA(x)), или (x e fa(y, ey)), или (существует сущность e e E, такая, что (e, P) e PA(UA(x)), где P e {writer, appendr, ownr}, и или e e fa(y, ey), или (e, y) e PA(UA(y)), где y e {readr, ownr}).
Условие 2. Если y e Nu и x e NS n S, то существуют сущность ey e E и роль ry e R, такие, что (ey, executer) e PA(UA(y)), ry e can_manage_rights(AUA(y)), и выполняется одно из условий: или (ry e UA(user(x))), или (x e fa(y, ey)), или (существует сущность e e E, такая, что (e, P) e PA(UA(user(x)), где P e {writer, appendr, ownr}, или (x, e, writem) e F, и или e e fa(y, ey), или (e, y) e PA(UA(y)), где y e {readr, ownr}).
Условие 3. Если ye S и x e Nu, то выполняется одно из условий: или ((y, ownr) e PA(UA(x))), или (x e [y]), или (существует сущность e e E, такая, что (e, P) e PA(UA(x)), где P e {writer, appendr, ownr}, и или e e [y], или y e NS n S, (e, y) e PA(UA(user(y))), где y e {readr, ownr}, или y e LS n S, (e, readr) e PA(roles(y)),
e) г y(E)).
Условие 4. Если y e S и x e NS n S, то выполняется одно из условий: или ((y, ownr) e PA(UA(user(x)))), или (x e [y]), или ((x, y, owna) e A), или (существует сущность e e E, такая, что (e, P) e PA(UA(user(x)), где P e {writer, appendr, ownr}, или (x, e, writem) e F, и или e e [y], или y e NS n S, (e, y) e PA(UA(user(y))), где
y e {readr, ownr}, или y e LS n S, (e, readr) e PA(roles(y)), (y, e) г y(E)).
Определение 15. Пусть G = (PA, user, roles, A, F, HE) - состояние системы Z(G*, OP), в котором недоверенная субъект-сессия или недоверенный пользователь x e Nu u (NS n S), субъект-сессия или недоверенный пользователь y e Nu u S. Определим предикат directly_grant_right(x, y, G), который будет истинным тогда и только тогда, когда выполняется одно из следующих условий 1 - 4.
Условие 1. Если y e Nu и x e Nu, то существует роль r e can_manage_rights(AUA(x)) n UA(y).
Условие 2. Если y e Nu и x e NS n S, то существуют роль r e can_manage_rights(AUA(user(x))) n UA(y).
Условие 3. Если y e S и x e Nu, то выполняется одно из условий:
- y e NS n S и существуют роль r e can_manage_rights(AUA(x)) n UA(user(y));
- y e LS n S и существуют роль r e can_manage_rights(AUA(x)) n roles(y).
Условие 4. Если y e S и x e NS n S, то выполняется одно из условий:
- y e NS n S и существуют роль r e can_manage_rights(AUA(user(x))) n UA(user(y)).
- y e LS n S и существуют роль r e can_manage_rights(AUA(user(x))) n roles(y).
Возможно доказать утверждения 2 и 3, в которых обосновываются достаточные условия истинности предиката can_share((e, a), x, G0) для случая, когда при передаче прав доступа ролей взаимодействуют только две субъект-сессии двух пользователей.
Утверждение 2. Пусть G0 = (PA0, user0, roles0, A0, F0, HE0) - состояние системы Z(G*, OP), в котором существуют недоверенный пользователь или недоверенная субъект-сессия x e Nu u (NS n S0), субъект-сессия или недоверенный пользователь y e Nu u S0 и право доступа к сущности (e, a) e P0. Пусть истинен предикат directly_access_own(x, y, G0) и выполняется одно из условий:
- если y e Nu, то (e, a) e PA0(UA0(y));
- если y e NS n S0, то (e, a) e PA0(UA0(user0(y)));
- если y e LS n S0, то (e, a) e PA0(roles0(y)).
Тогда выполняется одно из следующих условий.
Условие 1. Если x e Nu, то истинен предикат can_share((e, a), x, G0).
Условие 2. Если x e NS n S0, то истинен предикат can_share((e, a), user0(x), G0).
Утверждение 3. Пусть G0 = (PA0, user0, roles0, A0, F0, HE0) - состояние системы Z(G*, OP), в котором существуют недоверенный пользователь или недоверенная субъект-сессия x e Nu u (NS n S0), субъект-сессия
или недоверенный пользователь у є Nu и S0 и право доступа к сущности (e, а) є P0. Пусть истинен предикат directly_grant_right(x, у, G0) и выполняется одно из условий:
- если x є Nu, то (e, ownr) є PA0(UA0(x));
- если x є NS n S0, то (e, ownr) є PA0(UA0(user0(x))).
Тогда выполняется одно из условий.
Условие 1. Если у є Nu, то истинен предикат can_share((e, а), у, G0).
Условие 2. Если у є S0, то истинен предикат can_share((e, а), user0(y), G0).
Таким образом, с применением БР ДП-модели возможен анализ условий передачи прав доступа ролей в
КС с РУД. В дальнейшем возможно обоснование условий возникновения в КС с РУД информационных по-
токов по памяти или по времени.
ЛИТЕРАТУРА
1. Девянин П.Н. Модели безопасности компьютерных систем: Учеб. пособие для студ. высш. учеб. заведений. М.: Издательский центр «Академия», 2005. 144 с.
2. Bishop M. Computer Security: Art and Science. 2002. 1084 p.
3. Sandhu R. Role-Based Access Control, Advanced in Computers // Academic Press. 1998. V. 46.
4. Девянин П.Н. Анализ безопасности управления доступом и информационными потоками в компьютерных системах. М.: Радио и связь, 2006. 176 с.
