Базовая ролевая ДП-модель

Тип работы:
Реферат
Предмет:
ТЕХНИЧЕСКИЕ НАУКИ


Узнать стоимость

Детальная информация о работе

Выдержка из работы

ПРИКЛАДНАЯ ДИСКРЕТНАЯ МАТЕМАТИКА
2008 Математические основы компьютерной безопасности № 1(1)
МАТЕМАТИЧЕСКИЕ ОСНОВЫ КОМПЬЮТЕРНОЙ БЕЗОПАСНОСТИ
УДК 004. 94
БАЗОВАЯ РОЛЕВАЯ ДП-МОДЕЛЬ П.Н. Девянин
Институт криптографии, связи и информатики Академии ФСБ России, г. Москва E-mail: peter_devyanin@hotmail. com
На основе ролевых моделей (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 отношение частичного порядка «& lt-«, удовлетворяющее условию: если для сущности e е E имеются сущности e1, e2 е E, такие, что e& lt- e2, e& lt- ei, то e1& lt- e2 или e2& lt- ei. В случае, когда для двух сущностей eb е2 е E выполняются условия e1& lt- e2 и e1 Ф e2, будем говорить, что сущность е1 содержится в сущности-контейнере e2, и будем использовать обозначение e1& lt-e2.
Определение 2. Определим HE: E ^ 2е — функцию иерархии сущностей, сопоставляющую каждой сущности с е E множество сущностей HE© с E и удовлетворяющую следующим условиям.
Условие 1. Если сущность e е HE©, то e & lt- с и не найдется сущности-контейнера de C, такой, что e & lt- d, d & lt- с.
Условие 2. Для любых сущностей e1, e2 е E, e1 Ф e2, по определению выполняются равенство HE (e1) п HE (e2) = 0 и условия:
— если o е O, то выполняется равенство HE (o) = 0-
— если e1 & lt- e2, то или e1, e2 е E S, или e1, e2 е S-
— если e е E S, то HE (e) с E S-
— если s е S, то HE (s) с S.
Определение 3. Иерархией ролей в БР ДП-модели называется заданное на множестве ролей R отношение частичного порядка «& lt-«. При этом по определению выполняется условие: для пользователя и е U, если роли r, r'- е R, такие, что r е UA (u) и r'- & lt- r, то выполняются условия т'-е UA (u). В случае, когда для двух ролей r1, r2 е R выполняются условия r1 & lt- r2 и r1 Ф r2, будем использовать обозначение r1 & lt- r2.
Определение 4. Определим HR: R ^ 2R — функцию иерархии ролей, сопоставляющую каждой роли r е R множество ролей HR® с R и удовлетворяющую условию: если роль r'- е HR®, то r'- & lt- r и не существует роли r'-'- е R, такой, что r'- & lt- r'-'-, r'-'- & lt- r.
Определение 5. Иерархией административных ролей в БР ДП-модели называется заданное на множестве ролей AR отношение частичного порядка «& lt-«. При этом по определению выполняется условие: для пользователя и е U, если административные роли r, r'- е AR, такие, что r е AUA (u) и r'- & lt- r, то выполняются условия /е AUA (u). В случае, когда для двух ролей r1,е AR выполняются условия r1& lt- r2 и г1фг2, будем использовать обозначение ri& lt- r2.
Определение 6. Определим HAR: AR ^ 2AR — функцию иерархии административных ролей, сопоставляющую каждой роли r е AR множество ролей HAR® с AR и удовлетворяющую условию: если роль r'- е HAR®, то r'- & lt- r и не существует роли r'-'- е AR, такой, что r'- & lt- r'-'-, r'-'- & lt- 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®}.
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 A^ G1 Aop2 … AopN GN, где N & gt- 0. Тогда существуют состояния G'-1, …, G'-M = (PA'-M, user'-M, roles'-M, A'-M, F'-M, H'-EM), где M& gt- 0, и монотонные правила преобразования состояний op, …, op'-Mтакие, что G0 Aop1 G'-1 Aop2 … AopMG'-M и выполняются следующие условия.
Условие 1. Верно включение SN с S'-M, и для каждого субъект-сессии s е SN выполняются условия: userN (s) = user'-M (s), rolesN (s) с roles'-M (s).
Условие 2. Верно включение EN с E'-M, и для каждой сущности e е EN выполняется условие
HENIe) с H'-ElAe).
Условие 3. Для каждой роли r е R выполняется условие PAN® с PA'-M®.
Условие 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'-® = PA® и {(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'-® = PA® и {(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 & lt- 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 & lt- 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 & lt- 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 & lt- 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 & lt- 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 Aopj Gi Aop2. AopN Gn является траекторией без кооперации доверенных и недоверенных субъект-сессий для передачи прав доступа, и существует субъект-сессия x e SN, такая, что userN (x) = u, и право доступа к сущности (e, a) e de_facto_rightsN (x), где N & gt- 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 с.

ПоказатьСвернуть
Заполнить форму текущей работой