CC BY
52
УДК 004.056 DOI: 10.25513/2222-8772.2018.4.128-138
О ПРЕДСТАВЛЕНИИ НЕКОТОРЫХ РОЛЕВЫХ МОДЕЛЕЙ РАЗГРАНИЧЕНИЯ ДОСТУПА ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ МОДЕЛЬЮ HRU
Омский государственный университет им. Ф.М. Достоевского, Омск, Россия
Аннотация. Рассматривается возможность представления ролевых политик безопасности с помощью объектно-ориентированных дискреционных моделей разделения доступа. Рассмотрены ролевая модель без иерархии, а также ролевая модель с иерархией с наследованием «сверху». Полномочия ролевой модели представлены в виде наборов пар «объект — право доступа». Построена иерархия классов модели OOHRU, отражающая ролевую политику разграничения доступа. Описаны команды модели OOHRU, соответствующие переназначению ролей в исходной модели.
Ключевые слова: ролевые модели разграничения доступа, OOHRU, иерархия ролей.
Введение
Дискреционные политики безопасности известны ещё с 70-х годов прошлого столетия и традиционно базируются на субъектно-объектной парадигме компьютерной системы. Однако в связи с возрастающей актуальностью объектно-ориентированного подхода к построению компьютерных систем возникает необходимость в пересмотре классических политик безопасности. Так, например, в [1] была предложена объектно-ориентированная модель разграничения доступа, базирующаяся на модели HRU (Харриссона-Руззо-Ульмана) [2], однако обладающая более широкими возможностями, в частности, в рамках охвата компьютерных систем, которые можно описать с помощью этой модели.
Ролевые политики разграничения доступа стали широко известны только в 90-х годах после выхода работ Феррайоло и Куна [3]. Они отличаются от списков контроля доступа (ACL), используемых в системах управления доступом, основанных на дискреционных моделях безопасности, тем, что позволяют назначать на сложные операции с составными данными, а не только на атомарные операции с низкоуровневыми объектами данных.
Концепции иерархии ролей и ограничений позволяют создать или смоделировать контроль доступа на основе решетки доступов. RBAC широко используется для управления пользовательскими привилегиями в пределах единой системы или приложения. Список таких систем включает в себя Microsoft
С.В. Усов
к.т.н., доцент, e-mail: raintower@mail.ru
Active Directory, FreeBSD, Solaris, СУБД Oracle, PostgreSQL 8.1 и множество других. В работах Рави Санду (Ravi Sandhu) [4] было показано, что технология управления доступом на основе ролей обладает достаточной гибкостью для моделирования как дискреционных, так и мандатных политик безопасности. Однако в данных работах моделируются лишь частные дискреционные политики, близкие по структуре к Take-Grant, но заметно отличающиеся от HRU.
В данной работе будет построено ролевое описание некоторого частного случая объектно-ориентированной модели HRU, но в первую очередь мы рассмотрим обратное отображение, позволяющее смоделировать ролевую политику разграничения доступа на основе дискреционной модели Харриссона-Руззо-Ульмана.
В работе [5] была предложена иерархическая модель OOHRU, устройство которой подразумевает, что объект o, находящийся на более низком уровне иерархии, чем объект о', обладает меньшим набором прав (как в отношении доступа к другим объектам, так и в отношении ограничения доступа других объектов по отношению к себе) по сравнению с объектом о'. Такая структура напоминает решётку иерархии ролей, что позволяет предположить структурную близость данных моделей.
1. Объектно-ориентированная модель безопасности с дискреционным разграничением доступа (OOHRU)
Компьютерная система в OOHRU рассматривается в виде множества объектов O, разбитых по множеству классов K (все объекты одного класса имеют одинаковый набор полей и методов), обладающих открытыми полями f е F и скрытыми полями р е P, а также методами обработки полей s е S. Здесь F = (JfceK k.F — множество всевозможных открытых полей всех объектов и классов, k.F — множество открытых полей класса к (каждый объект класса к обладает тем же набором k.F открытых полей), аналогично определяются P и S. Причём если поле k.f наследуется классом к у класса к', то соответствующее поле класса к' мы будем для удобства обозначать именно k'.f, подчёркивая тем самым их взаимосвязь (таким образом, f е k.F и f е k'.F). Пусть Ofc е O — множество объектов класса к е K. В случае, если требуется уточнить класс объекта, поле f объекта ок е Ok будем обозначать ок.f, поле f класса к — k.f. Для скрытых полей класса будем использовать аналогичные обозначения.
Для построения модели дискреционного разделения доступов для каждого объекта и для каждого класса вводится дополнительное скрытое поле М, содержащее локальную матрицу доступов, и методы работы с матрицей доступов. Строки матрицы доступов объекта о соответствуют объектам и классам системы, столбцы — полям и методам объекта о, а в ячейке, находящейся на пересечении строки, соответствующей объекту о', и столбца, соответствующего полю либо методу х еX= F U S, находится подмножество множества R прав доступа, определённых в системе, которое обозначается о.М[о',ж]. Модификация матриц доступа производится посредством выполнения команд системы безопасности, о которых будет сказано ниже.
Модель безопасности OOHRU называется иерархической (или моделью с иерархией), если на множестве объектов O задан частичный порядок-иерархия, и в любой момент работы системы для любых двух объектов о, о' е O таких, что о' ^ о, для любого поля или метода х е X, общего для объектов о и о', и для любого поля или метода х' е X объекта о" е O, то верно следующее: о".М\о,х'] С о".М[о',х'] и о'.М[о",х] С о.М[о",х]. Здесь и далее — отношение частичного порядка, задающее иерархию.
Состояние системы в модели HRU изменяется под действием команд, которые состоят из условной части и последовательности элементарных операторов [2], которая выполняется, только если истинна условная часть. Список элементарных операторов в OOHRU включает [5]:
1. Create(ok,k) — создаёт объект ок класса к е K, если ок е O.
2. Destroy(ok) — уничтожает объект ок е O.
3. Enter(r,ok,о'к .f) — вносит право доступа г в о'к .М[ок,о'к ./], где ок -объект класса к, о'к — объект класса к'.
4. Delete(r,ok,о'к .f) — удаляет право доступа г из о'к .М[ок,о'к .f].
5. Grant(r,ok,о'к .s) — разрешает вызов объектом ок метода о'к .s.
6. Deprive(r,ok,о'к .s) — запрещает вызов объектом ок метода о'к .s.
Изменения, производимые операторами, отражаются в матрицах доступа
объектов системы. Подробное описание модели OOHRU можно найти в [5].
2. Ролевая политика безопасности
Ролевая политика разграничения доступа вводит в субъектно-объектную модель компьютерной системы новый класс активных сущностей — класс ролей.
Компьютерная система представляется совокупностью следующих множеств: множества пользователей U, множества ролей R, множества полномочий P и множества сеансов работы пользователей с системой [3]. Множество объектов системы не задаётся в явном виде, а представляется через множество полномочий P: каждое полномочие заключает в себе отношение на декартовом произведении множества прав доступа и множества объектов системы.
Ролевые отношения устанавливаются отображениями, связывающими множество ролей с множеством полномочий и множеством пользователей.
Управление доступом осуществляется на основе изменения множества активных сеансов системы. Каждому сеансу с е С сопоставляется пользователь ис е U, подмножество доступных пользователю в рамках данного сеанса ролей Rc С R и подмножество допустимых полномочий Рс С P. Считается, что система функционирует безопасно, если пользователь ис может осуществлять действия только в рамках полномочий из множества Рс во время сеанса с е С.
На множестве ролей в реальных системах обычно возникает иерархия, индуцированная организационно-управленческими схемами организаций, в которых эксплуатируется система. Как правило, подчинённость ролей в иерархии включает наследование прав и полномочий, которое может быть направлено как «снизу», так и «сверху».
При наследовании «сверху» подчинённый субъект наследует права родительских субъектов. Такой подход, тесно связанный с объектно-ориентированной парадигмой, редко упоминается при рассмотрении ролевых моделей разграничения доступа, но на деле бывает очень полезен, когда иерархия ролей строится путём «от абстрактного к конкретному». Так, например, можно рассмотреть фрагмент иерархии «Сотрудник — Сотрудник финансового отдела — Бухгалтер — Главный бухгалтер». Здесь каждая последующая роль цепочки является уточнением предыдущей. Сохраняя полномочия роли-родителя, она получает новые полномочия.
Однако базовые ролевые модели эксплуатируют наследование «снизу». Здесь можно выделить три ключевых подхода к построению иерархии:
1. Строгий таксономический листовой подход. Всё множество полномочий разбивается на непересекающиеся подмножества, каждое из подмножеств приписывается листу дерева иерархии ролей. Роль в нелистовой вершине наделяется множеством полномочий, являющимся объединением множеств полномочий непосредственно подчинённых ролей (соответствие между ролями и полномочиями, таким образом, индуцируется полномочиями листовых вершин и устанавливается при движении по дереву ролей снизу вверх).
2. Нестрогий таксономический листовой подход. Единственное отличие от предыдущего подхода — отсутствие требования на запрет пересечения подмножеств полномочий, сопоставленных листовым вершинам.
3. Иерархически охватный подход. Граф такой иерархии ролей не обязан быть деревом (но, конечно, не может содержать сильных циклов). При таком подходе считается, что если пользователю сопоставлена некоторая роль г Е И., то ему также должны быть сопоставлены и все роли, подчинённые г. Что позволяет исключить из роли г полномочия, уже содержащиеся в подчинённых ей ролях.
3. Связь между субъектно-объектной ролевой моделью без иерархии на множестве ролей и OOHRU
Основной результат данной работы заключается в том, что субъектно-объектная ролевая модель может быть реализована объектно-ориентированной моделью ООН^.
В первую очередь договоримся представлять полномочия ролевой модели в виде совокупности так называемых «элементарных» полномочий, каждое из которых задаётся парой (х, г) и заключает в себе право доступа г Е Я к объекту или группе одинаковых объектов х субъектно-объектной ролевой модели. В качестве г может также выступать право вызова, если х представляет собой активную сущность системы.
Дабы избежать путаницы в обозначениях, переобозначим множества ролевой модели следующим образом:
2 = ,... гп} — множество ролей системы,
У = {у1,у2,...ут} — множество полномочий системы,
X — множество всех объектов системы (в рамках субъектно-объектной парадигмы),
z.y — элементарное полномочие у, относящееся к роли z. z.Y — полный набор полномочий роли z, z.Y G Y.
Базовая ролевая политика разграничения доступа подразумевает статичность подсистемы безопасности в рамках одного сеанса, то есть полномочия неизменны, к каждой роли относится фиксированный набор полномочий, и каждому пользователю назначен неизменный в течение сеанса набор ролей. Таким образом, перераспределения прав доступа в смысле дискреционной политики безопасности не происходит. Построим иерархическую объектно-ориентированную модель HRU £' = (0(t),M(t),K,R), соответствующую данной субъектно-объектной ролевой модели S = (U, Z,Y,C).
Во-первых, сформируем множество R прав доступа модели £', вычленив права доступа г из элементарных полномочий. Во-вторых, представим каждое полномочие у G Y матрицей, строки которой подписаны элементами из множества R, столбцы — элементами из множества X, а на пересечении строки г и столбца a G X стоит 1, если полномочие у подразумевает право доступа г к объекту а, в противном случае стоит 0.
Рассмотрим всевозможные подмножества ролей из Z, всего их 2га. Каждому такому подмножеству a G 2Z сопоставим класс ka G К. Иерархия на классах вводится естественным образом: класс ка является непосредственным наследником класса kß, если и только если существует такая роль z, что а = ß U z.
(На самом деле достаточно ввести только классы, соответствующие наборам ролей, которыми могут наделяться пользователи системы, чтобы избежать избыточности классов. В этом случае иерархия строится аналогичным образом: класс ка является непосредственным наследником класса kß если и только если существует такое подмножество ролей 7 с Z, что а = ß U 7, но ни для какого подмножества 7' с 7 класса kßUy не существует.)
В дальнейшем мы будем ссылаться на эту иерархию классов как на естественную иерархию подмножеств ролей.
Теперь если пользователь u G U при авторизации на сеанс с G С получает набор ролей а, то в модели £' в классе ка создаётся новый объект ou G О. Каждый такой объект содержит в качестве private-поля собственную матрицу доступов (заполняется при создании объекта на основе совокупности всех элементарных полномочий, которыми обладает пользователь u во время сеанса с), поле идентификатора и методы, необходимые для работы с объектами системы. Так, например, каждому полномочию может соответствовать свой метод.
Также нам необходимо ввести классы для объектов доступа ролевой модели. Так как в ролевой модели отсутствует формальное описание объектов системы, извлекать объекты будем из полномочий. Пусть X — множество всех объектов системы (в рамках субъектно-объектной парадигмы). Произведём разбиение на этом множестве по следующему правилу: два объекта а и b из X отнесём к разным блокам разбиения, если выполнено хотя бы одно из следующих условий:
1. Объекты а и b обладают принципиально различной природой (как,
например, текстовый документ и исполняемое приложение), то есть требуют различного набора методов взаимодействий.
2. Существует полномочие у е Y, в матрице которого столбцы, соответствующие объектам а и Ь, не совпадают.
Таким образом, объекты попадают в один блок разбиения, если над ними можно осуществлять одни и те же операции одними и теми же методами, и в матрице любого полномочия столбцы этих объектов совпадают.
Поскольку система конечна, конечным окажется и число блоков разбиения. Каждому такому блоку X' С X сопоставим класс кх', а каждому объекту этого блока — объект класса кх'. Структура объектов класса будет повторять структуру объектов исходной системы.
Переход от субъектно-объектной модели множества X к объектно-ориентированной HRU-модели произведём согласно алгоритму, изложенному в работе [5]. В частности, пассивной сущности х е X субъектно-объектной модели будет соответствовать объект о, содержащий поле f, содержащее информацию объекта х, и приватное поле М — матрицу доступов. Активной сущности х' субъектно-объектной модели будет соответствовать объект о', содержащий метод s, выполняющий активные функции субъекта х', и приватное поле М — матрицу доступов.
Заполнение матриц доступов объектов происходит следующим образом: если множество ролей а е 2Z содержит роль с элементарным полномочием у = (x,r) = (o.f,r), где х — объект субъектно-объектной модели, объектно-ориентированной интерпретацией которого является объект о, то в матрицу доступов объекта о в ячейку на пересечении строки поля f и столбца класса ка заносится право доступа г: о.М[ka,f] := о.М[ka,f] U г.
Если множество ролей а содержит роль с элементарным полномочием у = (х',r) = (o'.s,r), где х' — субъект субъектно-объектной модели, объектно-ориентированной интерпретацией которого является объект о', а г — право вызова процедуры, то в матрицу доступов объекта о в ячейку на пересечении строки метода f и столбца класса ка заносится 1: о.М[ka,f] := 1.
Отсутствие перераспределения доступов в рамках одного сеанса влечёт отсутствие таких элементарных операторов, как Enter, Delete, Grant, Deprive в командах модели £'. Старт пользователем и сеанса с, в котором ему назначается множество ролей а, будет выражен в £' следующей командой: CommandStartSession_ _о,(ои : ка) Create(ou, ка).
Команда завершения сеанса этим же пользователем: С ommandEndSession_ _о.(ои : ка) Destroy (ои).
Тот факт, что перед стартом сеанса выполняется проверка возможности пользователю и назначить множество ролей а, может быть также отражён исключительно средствами модели OOHRU. Для этого вне иерархии введём два дополнительных класса: класс сеансов кс и класс пользователей ки. Для каждого сеанса с в класс кс помещается объект ос, содержащий поле-идентификатор сеанса, метод user инициализации пользователя и матрицу
доступов. Для каждого пользователя и в класс кц помещается объект о*и, содержащий метод user и матрицу доступов. Аналогичный метод user будут содержать все классы и объекты естественной иерархии подмножеств ролей. Роль этого метода формальна, нам потребуется лишь соответствующая ему ячейка в матрице доступов содержащего его объекта (класса).
Положим, что сеанс с подразумевает назначение пользователю и ролей из множества а. В этом случае при создании объекта ос происходит модификация матриц доступа объекта о*и и класса ка следующей командой:
CommandCreateSession_a(oc : кс; о*и : кц; ка) Create(oc, кс), Grant(oc, о *и .user), Grant(oc, ka.user).
При выполнении этой команды матрицы доступов модифицируются следующим образом: о *и .М[oc,user] = 1, ка.М[oc,user] = 1 (объект ос получает право запускать метод user объекта о*и, относящегося к пользователю и, и аналогичный метод класса ка). Команда может быть выполнена, только если пользователь и зарегистрирован в системе, при регистрации был создан соответствующий ему объект о*и.
Теперь в команду сеанса мы можем включить проверку возможности пользователю и назначить множество ролей а:
CommandStartSession_a(oc : кс; о*и : kv; Ой : ка) If
о *и .М[ос, user] = 1 and ка.М[oc,user] = 1 then
Create(ou, ка).
Для смены набора назначенных ролей а на набор @ пользователю необходимо завершить текущий сеанс и начать новый, в котором ему будет назначен требуемый набор ролей (конечно, если такой сеанс существует). В OOHRU это осуществимо последовательностью команд:
С ommandEndSession_a,
С ommandStartSession_[3.
Также средства OOHRU позволяют модифицировать множество привилегий, назначенных роли z, однако это потребует введения в модель дополнительных сущностей.
Заметим, что построенная нами модель OOHRU будет однородной в зоне классов естественной иерархии подмножеств ролей. Сформулируем полученный результат в виде теоремы.
Теорема 1. Для любой субъектно-объектной базовой ролевой модели, свободной от иерархии, существует реализующая её иерархическая модель OOHRU.
4. Связь между субъектно-объектной ролевой моделью с иерархией на множестве ролей и OOHRU. Случай наследования «сверху»
Перейдём к рассмотрению случая ролевой модели с иерархией, основанной на наследовании «сверху». Классы объектов, а также вспомогательные класс пользователей и класс сеансов в реализующей её модели OOHRU останутся неизменными, необходимо построить лишь иерархию классов ролей.
Иерархия классов ролей в OOHRU будет повторять иерархию ролей в исходной ролевой модели. Так, каждой роли z будет сопоставлен класс kz, и если роль z' является непосредственным потомком роли z в исходной модели (при этом набор полномочий z.Y роли z будет содержаться в наборе полномочий z'.Y роли z'), то класс kz' будет непосредственным потомком класса kz в OOHRU. В дальнейшем мы будем называть такую иерархию в OOHRU индуцированной иерархией ролей.
Как и ранее, если пользователь u g U при авторизации на сеанс с g С получает роль z, то в модели £' в классе kz создаётся новый объект ои. Каждый такой объект содержит в качестве private-поля собственную матрицу доступов (заполняется при создании объекта на основе совокупности всех элементарных полномочий, которыми обладает пользователь u во время сеанса с), поле идентификатора и методы, необходимые для работы с объектами системы. Так, например, каждому полномочию может соответствовать свой метод.
Переход от субъектно-объектной модели множества X к объектно-ориентированной HRU-модели произведём согласно алгоритму, изложенному в работе [5].
Заполнение матриц доступов объектов происходит следующим образом: если роль z обладает элементарным полномочием у = (x,r) = (o.f,r), где х — объект субъектно-объектной модели, объектно-ориентированной интерпретацией которого является объект о, то в матрицу доступов объекта о в ячейку на пересечении строки поля f и столбца класса kz заносится право доступа г: о.М[kz,f] := о.М[kz,f] U г.
Если роль z обладает элементарным полномочием у = (х',г) = (о'.р,г), где х' — субъект субъектно-объектной модели, объектно-ориентированной интерпретацией которого является объект о', а г — право вызова процедуры, то в матрицу доступов объекта о в ячейку на пересечении строки метода f и столбца класса kz заносится 1: о.М[kz, f] = 1.
Дополним OOHRU командой старта сеанса с пользователем u с авторизацией его на роль z и командой завершения сеанса.
CommandStartSession_z(ou : kz) Create(ou, kz).
Команда завершения сеанса этим же пользователем:
CommandEndSession_z(ou : kz) Destroy (ou).
Первая команда может быть дополнена проверкой возможности сеанса с:
CommandStartSession_z(oc : kc; o*u : ku ; ou : kz)
If
ou.M[oc,useг] = 1 and kz.M[oc,useг] = 1 then
Créâte(ou, kz).
Существенное отличие от случая ролевой модели без иерархии заключается в том, что каждый пользовательский объект в индуцированной иерархии ролей соответствует одной роли из числа назначенных субъекту. В информационных системах, эксплуатирующих подход иерархии «вниз» на множестве ролей, назначение одной роли субъекту кажется достаточным, поскольку роль определяется непосредственно сферой обязанностей пользователя, и при необходимости совмещения нескольких обязанностей достаточно создать роль, являющуюся в иерархии наследницей ролей, упомянутых выше обязанностей. Так, если в системе существуют роли z и z', которые необходимо назначить одному пользователю, совмещающему соответствующие обязанности, то достаточно создать новую роль z", набор полномочий которой будет являться объединением наборов полномочий ролей z и z', а сама роль z" — наследником как z, так и z'.
Однако если необходимо назначить пользователю u роли z и z' в рамках уже построенной системы безопасности, достаточно создать при назначении пользователя на эти роли два отвечающих пользователю u объекта как в классе kz, так и в классе kz> :
CommandStartSession_{z,z'}(ou : kz, o'u : kz<) Créâte(ou, kz), Create(o'u, kz<).
CommandEndSession_{z,z'}(ou : kz, o'u : kz<) Dest roy( ou), Dest roy( o'u).
Аналогичные команды можно использовать для произвольного набора ролей а.
Как и в случае ролевой модели, свободной от иерархии, для смены набора назначенных ролей а на набор [3 пользователю необходимо завершить текущий сеанс и начать новый, в котором ему будет назначен требуемый набор ролей.
Модификация множества привилегий, назначенных роли z, осуществима следующим образом. Допустим, роли z\... zt являются непосредственными потомками роли , которой необходимо добавить новое элементарное полномочие у = (о. f, г), то есть право доступа г к полю f объекта о некоторого класса k0. Для этого используем команду
CommandAddPermission_z_r_f (kz ,о : ka) Enter(r, kz, o.f).
Данная команда не нарушает наследование прав доступа в иерархии, поскольку в OOHRU оператор Ente г может быть выполнен, только если соблюдены так называемые условия целостности [1]:
(г Е о. M [ kzi, f])& ...&(r E о. M [kZs, f]).
При необходимости добавить более широкий набор полномочий, расширяем список элементарных операторов Enter в команде, добавляющих необходимые права доступа. Если элементарное полномочие содержит право вызова метода s объекта о некоторого класса к0, используем команду несколько иного вида:
CommandAddPermission_z_s(kz,о : к0) Grant(kz, o.s).
Удаление элементарного полномочия осуществляется аналогичным способом, только условия целостности будут наложены уже на родительские классы:
CommandDeletePermission_z_r_f (kz ,о : к0) Delete (г, kz, o.f).
Модификация строк матриц доступа объекта о, соответствующих объектам класса kz, не требуется за отсутствием таковых, поскольку изменение набора полномочий, соответствующего роли, не может осуществляться в ролевой модели безопасности во время сеанса, завязанного на эту роль. Тем самым доказана
Теорема 2. Для любой субъектно-объектной иерархической ролевой модели с наследованием «сверху» существует реализующая её иерархическая модель OOHRU.
Литература
1. Усов С.В. Объектно-ориентированный подход в построении политики безопасности. Системы с естественной иерархией. // Математические структуры и моделирование. 2010. N. 21. С. 152-162.
2. Harrison M.A., Ruzzo W.L., Ulman J.D. Protection in Operating Systems // Communications of the ACM. 1975. Р. 14-25.
3. Ferraiolo D.F., Kuhn D.R. Role-Based Access Control // 15th National Computer Security Conference. 1992. P. 554-563.
4. Sandhu R., Munawer Q. How to do discretionary access control using roles // 3rd ACM Workshop on Role-Based Access Control. 1998. P. 47-54.
5. Усов С.В. Об отношении между дискреционными моделями объектно-ориентированных и субъектно-объектных компьютерных систем // Проблемы информационной безопасности. Компьютерные системы. 2013. Т. 3. C. 18-26.
ON THE REPRESENTATION OF ROLE-BASED ACCESS CONTROL MODELS BY OBJECT-ORIENTED HRU MODEL
S.V. Usov
Ph.D. (Eng.), Associste Professor, e-mail: raintower@mail.ru Dostoevsky Omsk State University, Omsk, Russia
Abstract. In this paper the possibility of representing of some types of role-based access control models by object-oriented discretionary access control model is considered. The role-based security model without hierarchy and the role-based security model with hierarchy with inheritance "from above" are considered. The permissions of the role-based access control model are represented as a set of pairs of object and access right. A hierarchy of classes of the object-oriented HRU model based on the role-based access control policy is constructed. Commands of the object-oriented HRU model corresponding to the reassignment of roles in the original role-based model are described.
Keywords: role-based access control model, object-oriented discretionary access control model, role hierarchy.
Дата поступления в редакцию: 15.11.2018
