Научная статья на тему 'Базовая ролевая ДП-модель'

Базовая ролевая ДП-модель Текст научной статьи по специальности «Автоматика. Вычислительная техника»

465
63
Поделиться
Ключевые слова
КОМПЬЮТЕРНАЯ БЕЗОПАСНОСТЬ / МАТЕМАТИЧЕСКИЕ МОДЕЛИ БЕЗОПАСНОСТИ / РОЛЕВАЯ МОДЕЛЬ

Аннотация научной статьи по автоматике и вычислительной технике, автор научной работы — Девянин Петр Николаевич

На основе ролевых моделей (RBAC) и ДП-моделей компьютерных систем с дискреционным или мандатным управлением доступом строится базовая ролевая ДП-модель. С учетом фактических ролей, прав доступа и возможных действий недоверенных сессий анализируются правила преобразования состояний системы. Обосновываются условия передачи прав доступа ролей сессиями пользователей.

BASE ROLE DP-MODEL

This article represents a base role DP-model constructed on the basis of group rolebased access control (RBAC) models and DP-models computer systems with discretionary or mandatory access control. The singularities of functioning modern computer systems take into account in base role DP-model including distinctions in conditions of functioning and the cooperation of trusted and nontrusted user sessions, in conditions of realization of information flows by memory or by time, and also possibility of getting the nontrusted session control above the trusted session while realization of information flows by memory on entity which is functionally associated with the trusted session. Monotonous and nonmonotonic rules of transformation of conditions of system are described in details and analyzed while sets of actual roles, rights of access and possible actions of the nontrusted sessions are used. Sufficient conditions of access rights transfer roles are substantiated by user sessions

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Текст научной работы на тему «Базовая ролевая ДП-модель»

ПРИКЛАДНАЯ ДИСКРЕТНАЯ МАТЕМАТИКА

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 - множество доверенных субъект-сессий;

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Определение 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.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

БР ДП-модель предназначена для анализа условий реализации в КС с РУД информационных потоков, и в ее рамках не предполагается исследовать вопросы администрирования множества ролей, иерархии ролей, иерархии административных ролей, множеств авторизованных ролей пользователей, параметров ограничений. Таким образом, будем использовать следующее предположение.

Предположение 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 - функция, задающая множества сущностей, функционально ассоциированных с субъект-сессией, при ее создании пользователем (или от имени пользователя другой субъект-сессией) из сущности.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Определение 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 и выполняются следующие условия.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Условие 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

Продолжение таблицы

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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}).

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Условие 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) и выполняется одно из условий:

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

- если 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).

Таким образом, с применением БР ДП-модели возможен анализ условий передачи прав доступа ролей в

КС с РУД. В дальнейшем возможно обоснование условий возникновения в КС с РУД информационных по-

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

токов по памяти или по времени.

ЛИТЕРАТУРА

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 с.