МОДЕЛЬ КОНТРОЛЯ ДОСТУПА D-TBAC С УЧЁТОМ ТРЕБОВАНИЙ К ВЫПОЛНЕНИЮ ЗАДАЧ Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 681.3.07

Модель контроля доступа Б-ТБЛС с учётом

В настоящей статье представлена модель контроля доступа Э-ТБЛС, расширяющая ТВАС. Представленная модель учитывает требования к выполнению задач. Формально определены элементы модели, её свойства, а также правила преобразования состояний.

Ключевые слова: компьютерная безопасность, математические модели безопасности, разграничение доступа, динамические системы, задачи, ТВАС, требования.

1. Введение

В современных компьютерных системах предъявляются повышенные требования к уровню их безопасности. Одним из компонентов системы безопасности является разграничение доступа пользователей на объекты системы.

В существующих моделях разграничения доступа, в том числе ориентированных на задачи, предполагается, что одна и та же задача будет решена субъектом системы через использование одного множества объектов, к которому ему предоставляется доступ. Однако такие модели не учитывают, что в системе могут присутствовать равнозначные объекты, которые имеют одинаковые функциональные возможности, но обладают различными характеристиками [1, 2]. Равнозначные объекты по некоторому признаку, например, по функциональности, объединяются в несколько подмножеств множества объектов, которые назовём группами равнозначных объектов. Такие системы могут быть ориентированы на выполнение множества задач, для решения которых могут предъявляться определённые требования. От того, каким из равнозначных объектов воспользуется субъект при решении поставленной перед ним задачи, может зависеть как безопасность её решения, так и безопасность всей системы в целом. Поэтому в зависимости от различных факторов следует предоставлять субъекту различные доступы к равнозначным объектам. Набор таких факторов будет формировать определённые требования к решению задач субъектами системы.

Таким образом, целью представленной работы является формальное описание модели контроля доступа, которая позволяет:

1) выделять минимально необходимые права доступа субъектам системы при наличии в ней объектов с одинаковыми функциональными возможностями;

2) предъявлять набор требований к процессу выполнения задачи субъектом системы;

3) использовать модель в динамических системах.

Для достижения поставленной цели в статье решаются следующие задачи:

1) определение множества элементов, из которых состоит предлагаемая модель;

2) определение свойств предлагаемой модели, описывающих безопасность системы;

3) определение множества запросов, с помощью которых изменяется состояние системы;

4) определение правил преобразования состояний системы, функционирующей в соответствии с предлагаемой моделью.

к выполнению задач

С. А. Лапин

*

""Публикация подготовлена в рамках поддержанного РГНФ научного проекта № 16-33-01160

2. Связанные работы

В этом разделе обсуждаются способы решения поставленной во введении задачи на основе анализа существующей литературы. Рассматриваются как классические модели разграничения доступа (ХРУ, RBAC), так и модели, предназначенные для использования в динамических системах (TBAC, DEBAC), с точки зрения избыточности предоставляемых прав доступа, разделения их в соответствии с задачами, а также гибкости и сложности администрирования политики безопасности.

В модели Харрисона-Руззо-Ульмана (ХРУ) [3, 4] разграничение прав доступа определяется матрицей доступа, строками которой являются субъекты, а столбцы - объектами. Т.к. в матрице доступов необходимо перечислить для каждого субъекта системы доступы, которыми он обладает к каждому объекту, то, очевидно, разграничение доступа к равнозначным объектам возможно только в случае, когда субъекту предоставляется доступ только к одному объекту из группы. При таком способе использования модели очевидны следующие недостатки:

1. Субъекту предоставляются недостаточные права доступа. Субъект имеет доступ только к одному объекту из каждой группы, что при наличии в системе равнозначных объектов может привести к некорректному решению поставленной задачи и повлечь за собой угрозы безопасности системы.

2. Множество прав доступа субъекта статично. Вне зависимости от того, какую задачу выполняет субъект в системе, множество его прав доступа остаётся постоянным.

Основной моделью, реализующей мандатное разграничение прав доступа, является классическая модель Белла-ЛаПадулы (Bell-LaPadula) [5]. Модель ориентирована прежде всего на контроль за информационными потоками, возникающими в системе, на которые накладывается ряд ограничений, препятствующих возникновению таких потоков от объектов с большим уровнем конфиденциальности к объектам с меньшим уровнем конфиденциальности [3]. Каждому объекту в системе назначается определенный уровень конфиденциальности. Такие уровни образуют решетку уровней конфиденциальности. Применительно к рассматриваемой задаче наиболее выгодно назначать различные метки конфиденциальности равнозначным объектам в зависимости от предъявляемых требований. Однако использование такого подхода имеет следующие сложности, обуславливаемые определениями модели Белла-ЛаПадулы:

1. Назначенные уровни конфиденциальности объектов распространяются на все субъекты системы.

2. При наличии нескольких требований к выполнению одной задачи необходима функция, которая по некоторому правилу в соответствии с набором требований назначит уровни конфиденциальности для объектов системы, используя единственную решетку уровней конфиденциальности.

3. Не определены условия, по которым следует изменять метки конфиденциальности равнозначных объектов в соответствии с требованиями, предъявляемыми к решению задачи.

4. Возникают сложности в администрировании политики безопасности. Изменение меток конфиденциальности объектов для каждой задачи, которая назначается для выполнения субъекту, приводит к непрозрачности политики безопасности и, как следствие, может повлечь за собой ошибки, приводящие к компрометации защищаемой информации.

Широко применяется модель контроля доступа на основе ролей (Role-based Access Control, RBAC) [3, 6, 7], с помощью которой возможно выполнить тонкую настройку правил контроля доступа [8, 9]. Модель RBAC контролирует доступ субъектов системы на объекты в соответствии с совокупностью действий и обязанностей, связанных с определённым видом деятельности субъектов. Такие полномочия представляют собой семантические конструкции, называемые ролями субъектов, которые лежат в основе политики разграничения доступа. Роли поз-

воляют конкретным лицам получить доступ к объектам в той степени, в какой это необходимо им для выполнения своих обязанностей. Однако данная модель имеет целый ряд недостатков для применения в динамических системах, которые перечислены в [10, 11, 12, 13, 14, 15, 16]. В рассматриваемом аспекте для каждой роли необходимо определять права доступа, исходя из всевозможных комбинаций использования равнозначных объектов. Таким образом, роли будут сформированы так, что каждая из них предоставляет доступ только к одному из равнозначных объектов группы. RBAC позволяет разграничить доступ субъектов в системе относительно выполняемых ими задач в отдельности и при этом предоставляет инструменты для разграничения доступа к равнозначным объектам. Более того, права доступа пользователя в системе не являются постоянными и могут изменяться в зависимости от того, с какой ролью авторизовался пользователь [9]. Отметим следующие недостатки использования RBAC:

1. Решение, на какую из доступных пользователю ролей авторизоваться, принимает сам пользователь. При этом им могут быть допущены ошибки, связанные с выбором роли, а это может повлиять на безопасность системы.

2. Значительно увеличивается количество определяемых ролей по сравнению с реальным количеством функциональных обязанностей пользователя в системе.

3. Усложняются процедуры администрирования системы безопасности как на этапе её формирования, так и при внесении изменений. Данный недостаток является следствием предыдущего. Очевидно, что в реальных системах с большим количеством задач и равнозначных объектов количество определяемых ролей будет достаточно большим. В свою очередь, это может привести к возникновению ошибок, росту числа уязвимостей и пр., что негативно сказывается на системе безопасности.

В основе модели Task-based Authorization Controls (TBAC) [17] лежит понятие «задача». Права доступа пользователей изменяются с учётом специфики выполняемой задачи, на которую он авторизован в данный момент, что обеспечивает динамический контроль доступа [15, 18]. Использование модели TBAC в данном контексте имеет следующие положительные стороны:

1. В соответствии с определениями модели разграничение прав доступа субъектов системы происходит в соответствии с задачами, которые они выполняют в отдельности.

2. Права субъектов в системе не являются постоянными и предоставляются только на время выполнения ими назначенной задачи.

3. Модель позволяет реализовать разграничение доступа к равнозначным объектам системы путём добавления нескольких этапов авторизации для задач.

4. Для добавления новых субъектов системы необходимо только назначить для них этапы авторизации.

Однако администрирование политики безопасности при таком подходе является затруднительным. Это связано с большим количеством этапов авторизации, значительно превышающим количество задач, которые решаются в системе. Более того, её размер будет многократно увеличиваться, если в такую систему будут добавляться новые равнозначные объекты или задачи. Это может привести к ошибкам в системе разграничения прав доступа и, как следствие, к неверному функционированию системы безопасности.

В работах [10, 11, 16] предлагаются гибридные варианты моделей контроля доступа, построенных на основе RBAC и TBAC. Такие модели предоставляют механизмы по изменению доступов субъектов в процессе функционирования системы. Однако они сохраняют недостатки как RBAC, так и TBAC.

Более общий поход по формированию правил контроля доступа для динамических систем представлен моделью Dynamic Event-Based Access Control (DEBAC) [14]. Фундаментальным понятием модели DEBAC является «событие». В DEBAC права пользователя изменяются только при наступлении какого-либо события, которое определено в системе. В соответствии

с набором правил, которые должны быть применены при обработке данного события, могут измениться и права доступа пользователя в системе. Стоит отметить, что наступление события влечёт за собой и изменение требований по доступу пользователя к объектам системы. Отметим положительные стороны использования модели DEBAC:

1. В соответствии с определениями модели разграничение прав доступа субъектов системы происходит в соответствии с отдельными задачами, которые они выполняют.

2. Права субъектов в системе не являются постоянными и предоставляются только на некоторый период времени.

3. Модель позволяет реализовать разграничение доступа к равнозначным объектам системы путём добавления нескольких событий, которые соответствуют одной задаче.

Недостатком использования DEBAC является процедура администрирования политики. В основе своей это связано с тем, что для каждого пользователя необходимо определить множество событий, в которых он может участвовать. Очевидно, что это влечёт за собой усложнение формирования и дальнейшего сопровождения политики безопасности.

Таким образом, использование как классических моделей безопасности (ХРУ, RBAC), так и моделей, реализующих динамический контроль доступа (TBAC, DEBAC), имеет недостатки в рассматриваемом аспекте. При этом более приемлемым подходом для решения поставленной задачи является использование динамических моделей, основанных на задачах или событиях. Однако их применение в рассматриваемом аспекте представляется громоздким и затруднительным с точки зрения администрирования.

Наличие недостатков использования рассмотренных моделей безопасности в том числе связано с тем, что в них предполагается решение задачи субъектом путем применения одного и того же множества объектов, к которому ему предоставляется доступ. Однако не учитываются такие особенности системы, как наличие равнозначных объектов и требований к процессу решения задачи. В зависимости от таких требований для решения одной и той же задачи субъекту могут предоставляться различные доступы к равнозначным объектам. Таким образом, возникает необходимость создания модели, учитывающей такие особенности системы.

В работе [19] неформально описывается модель D-Task-based Authorization Controls (D-TBAC), где D означает множество требований в соответствии с элементами системы, учитывающая перечисленные особенности и позволяющая решить поставленную во введении задачу. Она предоставляет механизм, позволяющий выделять минимальные права доступа субъектам системы при решении ими задач с учетом требований к их выполнению. Однако требуется её формальное определение.

3. Модель D-TBAC

Предлагаемая модель состоит из следующих элементов:

S — множество субъектов;

T — множество задач;

O — множество объектов;

G = (gi) I Vgi С O и Vgi, gj Е G gi П gj = 0, где gi = gj — множество групп объектов;

R — множество видов доступа (например, read, write, execute);

P = 2GxR — множество операций над группами объектов;

D — множество требований;

L — множество решёток уровней требований и свойств объектов;

ST : S ^ 2T — функция, определяющая для каждого субъекта множество задач, которые он может выполнять;

TP : T ^ 2P — функция, определяющая для каждой задачи множество операций;

ТВ : Т ^ 2° — функция, определяющая для каждой задачи множество требований, которые должны быть выполнены при её выполнении;

ВЬ : В ^ Ь, Уй Е В 3\(1а, <) Е Ь : ВЬ(й) = (1а, <) — функция, задающая для каждого требования решётку, на которой определяется его уровень;

: й ^ , <) и {попе}, где й Е В и ВЬ(й) = (1а, <) — функция, определяющая уровень требования, где попе означает, что уровень требования не определён;

ОЬ : О ^ Ь, У о € О 3\(1а, <) Е Ь : ОЬ(о) = (1а, <) — функция, задающая для каждого объекта решетку его свойств;

¡0 : о ^ <), где о Е О и ОЬ(о) = , <) — функция, определяющая свойство объекта.

Определение 1. Требование й Е В называется значимым для подмножества объектов Оа С О, если Уо Е Оа выполняется равенство ВЬ(й) = ОЬ(о).

ВО С В х О | У(й,о) Е ВО верно ВЬ(й) = ОЬ(о) — множество пар значимых требований и объектов.

Для любой пары (й,о) Е ВО определим двойку функций (¡а, ¡0) Е ВЬ(й) х ОЬ(о), определяющих уровень требования й Е В и уровень свойств объекта о Е О, для которого такое требование является значимым.

Тогда {в,г, (¡^¡0)) Е У С 5 х Т х (ВЬ(й) х ВО (о)), где У(й,о) Е ВО — тройка, определяющая уровень требования й Е В к объекту о Е О при решении задачи г Е Т субъектом в Е 5.

В С 23х°хЯ — множество возможных множеств текущих доступов в системе;

СТ С 23хТ — множество текущих задач в системе.

Структура элементов модели Б-ТБАС представлена на рис. 1.

Рис. 1. Структура элементов модели Б-ТВАС

Определение 2. Пусть определены: множества субъектов Б, объектов О, задач Т, групп объектов С, видов доступа Я, операций Р, требований В, решёток требований и свойств объектов Ь, множество доступов В, а также функции, задающие задачи для субъектов БТ, права доступа задач ТР, требования для задач ТВ, решётки для требований ВЬ, решётки свойств для объектов ОЬ, а также функция У.

Тогда V = (Б, Т, О, С, Я, Р, В, Ь, БТ, ТР, ТВ, ВЬ, ОЬ, СТ, В, У) — состояние системы.

Введем обозначения:

Q — множество команд в системе;

Ш : Q х V ^ V — функция переходов, где Ш(д, у) = V* означает, что система по команде д Е Q из состояния V перешла в состояние V*;

Определение 3. Под системой будем понимать конечный автомат ^*,^,у0), где V* — множество всех возможных состояний системы, — начальное состояние системы.

Утверждение 1. В модели предполагается, что множества Б, Т, О, С, К, Р, Б, Ь и функции БТ, ТР, ТБ, БЬ, ОЬ не меняются в процессе функционирования системы.

Принимая во внимание утверждение 1, будем использовать сокращённое обозначение для состояния системы V = (СТ, В, У).

Утверждение 2. В модели Б-ТБЛС предполагается, что в состоянии ь0:

• СТ = 0 — выполняемые задачи в данный момент времени отсутствуют;

• В = 0 — субъекты не имеют прав доступа на объекты системы;

• У (в, о) е БО (¡а = попе, ¡а) => У(в,г, (¡а, ¡а)) е У верно (в, г, (¡а = попе, ¡а)) — уровни требований не определены.

В модели рассматриваются следующие запросы, входящие во множество Ц:

• set_demad(s,t, й,уа1) — запрос, задающий для требования в, е Б его уровнень ¡а = ьа1 для выполнения задачи г е Т субъектом в е Б;

• start_task(s,t) — запрос запуска процесса решения задачи г е БТ (в) субъектом в е Б;

• stop_task(s) — запрос прекращения решения задач субъектом в е Б.

Безопасность системы определяется с помощью четырёх свойств:

• d-свойство — свойство требования;

• ^свойство — свойство задачи;

• /-свойство — свойство полноты;

• ¡-свойство — свойство единственности.

Определение 4. Объект о е О называется соответствующим значимому требованию в е Б относительно (¡а, ¡а) е БЬ(в) х ОЬ(о), если ¡а = ¡а.

Определение 5. Объект о е О называется минимально удалённым от уровня значимого требования относительно (¡а = попе, ¡а) е БЬ(в) х ОЬ(о), когда ¡а < ¡а и $о е О | о, о е д, для которого выполняется ¡а < ¡а> < ¡а.

Определение 6. Объект о е О обладает d-свойством относительно (¡а, ¡а) е БЬ(в) х ОЬ(о), если о е О соответствует значимому требованию в е Б или минимально удалён от него.

Определение 7. Доступ (в, о, г) е БхОхК обладаетd-свойством относительно (в, г, (¡а, ¡а)), когда объект о е О обладает d-свойством относительно (¡а, ¡а).

Определение 8. Состояние системы (СТ,В,У) е V обладает d-свойством, когда выполняется одно из условий:

• если СТ = 0, то каждый доступ (в, о, г) е В обладает d-свойством относительно (в,г, (¡а, ¡а)) е У;

• если СТ = 0, то В = 0.

Обладание системы в каждом её состоянии d-свойством означает, что любой субъект в е Б в каждый момент времени при выполнении задачи г е Т имеет доступ к объектам, которые максимально могут удовлетворить предъявляемым требованиям.

Определение 9. Доступ (в, о, г) е Б х О х К обладает ^свойством относительно (в, г) е Б х Т , когда выполняются два условия:

1. г е БТ (в);

2. Зд е С I о е д и (д,г) = р е ТР (г).

Определение 10. Состояние системы (СТ, В, У) е V обладает ^свойством, когда выполняется одно из условий:

• если СТ = 0, то каждый элемент (в, о, г) е В обладет ^свойством относительно элемента (в, г) е СТ;

• если СТ = 0, то В = 0.

Обладание системы в каждом её состоянии исвойством означает, что каждый доступ, который присутствует в данном состоянии системы, относится к выполнению задачи г Е Т субъектом в Е Б.

Определение 11. Состояние системы (СТ, В, У) Е V обладает/-свойством, когда выполняется одно из условий:

• если СТ = 0, то У (в,г) Е СТ и Уд Е С | (д,г) = р Е ТР (г), верно что 3!о Е д 1 (в,о,г) Е В;

• если СТ = 0, то В = 0.

Обладание системы в каждом её состоянии свойством означает, что каждый субъект в любой момент времени при выполнении задачи имеет все необходимые доступы к объектам.

Определение 12. Множество текущих задач СТ обладает ¡-свойством, когда выполняется условие: Ув Е Б верно 1СТ П (в х Т)| ^ 1.

Определение 13. Состояние системы (СТ,В,У) Е V обладает ¡-свойством, когда СТ обладает ¡-свойством.

Обладание системы в каждом её состоянии ¡-свойством означает, что любой субъект в Е Б в каждый момент времени может выполнять не более одной задачи г Е Т.

Определение 14. Состояние системы (СТ,В,У) Е V называется безопасным, когда оно обладает одновременно ё-свойством, исвойством, /-свойством и ¡-свойством.

Определение 15. Система ^^^*,Ш,у0) называется безопасной, когда каждое её состояние безопасно.

Правила преобразования состояний системы в модели Б-ТВАС показаны в табл. 1.

В модели определено множество объектов системы. При этом объекты по некоторому признаку, например, по функциональности, объединяются, образуя непересекающееся множество групп С. Операции, которые возможно выполнять над группой в процессе решения задачи г Е Т, определяет функция ТР. Если над группой д Е С допускается выполнение операции р Е Р , то её выполнение допускается над любым объектом о Е С .

В модели представлено множество требований В . Отображение ТВ ставит в соответствие каждой задаче подмножество требований, которые должны быть выполнены при её выполнении. Каждое требование может иметь различный уровень. Поэтому для каждого требования существует своя решётка уровней (1а, <) Е Ь. Уровень требования определяется значением функции .

Каждый объект из каждой группы имеет уровень характеристик своих свойств относительно значимого для него требования. Уровень таких свойств отображается на решётку уровней требования и свойств объекта функцией ¡0. В одной группе не может существовать несколько объектов, имеющих одинаковый уровень характеристик. В группе может не существовать объекта с уровнем своих характеристик, совпадающим с требуемым уровнем значимого для него требования. В таком случае из группы предоставляется доступ на объект, уровень свойств которого минимально отличается от требуемого и не превышает его.

Состояние системы может изменяться только путём применения в ней трёх команд. Команда устанавливает уровень требования й Е В для решения задачи г Е Т субъектом в Е Б. Значение этой функции определяет, к какому объекту будет предоставлен доступ субъекту в Е Б при выполнении задачи г Е Т. Изменение уровня требования в процессе выполнения задачи субъектом не влияет на его текущие доступы в системе. start_task(s,t) запускает процесс решения задачи г Е Т субъектом в Е Б. При выполнении такой команды в системе субъекту предоставляются все необходимые доступы, которые удовлетворяют обозначенным четырём свойствам. stop_task(s) прекращает выполнение всех задач в системе субъектом в Е Б. Т.к. из ¡-свойства следует, что в системе может выполняться только одна задача одним субъектом, то при выполнении данной команды система переходит в состояние, из которого исключены все доступы субъекта в Е Б. Стоит обратить внимание, что важен

Таблица 1. Правила преобразования состояний системы в модели D-TBAC

Команда Условия выполнения Исходное состояние V = (CT, B, Y) Результирующее состояние V' = (CT' ,B', Y')

set demad(s,t, d,val) отсутствуют s e S, t e T, d e D, DL(d) = (ld, <) , val e (ld, <) CT' = CT B' = B, Y' = Y \((s,t, (fd,fo)))U U((s,t, (val, fo))), V(s,t, (fd,fo)) Е Y

start task(s,t) $(s,t*) Е CT, где t* Е T s e S t e ST(s) Y' = Y, CT' = CT U (s,t) и для CT' верно ¡-свойство, B' = B U Bnew, где Bnew С s x O x R с S x O x R и V(s, o, r) Е Bnew верно d-свойство, t-свойство и для ((s, t), Bnew ,Y') верно f-свойство

stop task(s) отсутствуют s e S Y' = Y, CT' = CT \ CToid, CToid = s x T с S x T, B = B \ Bold, Bold = s x O x R с S x O x R

порядок использования данных команд: не допускается применение команды start_task(s,t), если в системе субъект s Е S уже выполняет какую-либо задачу.

4. Применение модели D-TBAC

Для иллюстрации использования предлагаемой модели контроля доступа рассмотрим учреждение здравоохранения. Каждый субъект системы — врач, предоставляющий услуги лечения пациента. Пусть объектами, к которым необходимо контролировать доступ, являются лекарственные препараты. Для лечения одного и того же заболевания в распоряжении врача могут находиться различные препараты, имеющие одинаковые функциональные возможности (обезболивающие, успокоительные и пр.), но различные характеристики (стоимость, влияние на организм, побочные эффекты, привыкание и др.). Поэтому к процессу лечения пациента применяются определённые требования. При выполнении задачи субъект должен иметь доступ только к одному препарату из каждой группы объектов. В соответствии с определениями модели D-TBAC имеем следующие элементы:

S = (doctorI, doctor 2, doctor3) — множество субъектов состоит из множества врачей;

T = {treatmentl,treatment2} — множество задач состоит из двух способов лечения;

O = {drugl,drug2,drug3,drug4,drug5,drug6,drug7} — множество объектов состоит из имеющихся в больнице препаратов;

G = {gl = {drugl,drug3 ,drug6},g2 = {drug2,drug5},g3 = {drug4,drug7}} —множество групп объектов образуется исходя из функционального назначения препаратов;

R = {apply} — множество видов доступа состоит из одного элемента — «применить»;

P = {pl = gl х apply,p2 = g2 x apply,p3 = g3 x apply} — множество операций над группами объектов;

D = {price, effect, sideE f fect} — к задачам лечения пациента могут предъявляться требования по стоимости, эффекту и побочному влиянию на организм лекарственных препаратов;

L = { (Iprice, <) = {low, medium, high}, (leffect, <) = {low, high}}, (lsideEffect, <) = = {low, high}} — множество решёток, задающих уровни требований и свойства объектов относительно требований;

ST (doctor l) = ST (doctor 2) = {treatment^, ST (doctors) = {treatment2 }} —для каждого врача определены задачи, которые он может выполнять;

TP(treatmentl) = {pl,p2}, TP(treatment2) = {p2,ps} — функция, определяющая права доступа при решении задач;

TD(treatmentl) = {price, eff fect},TD(treatment2) = {price, sideEffect} —функция TD задаёт для каждой задачи множество требований, которые должны быть выполнены при её решении;

DL(price) = (lPrice, <), DL(effect) = (leffect, <), DL(sideEffect) = (lsideEffect, <) — для каждого требования задаётся своя решётка уровней;

Для каждого препарата определим решётку, отображающую уровень его свойств относительно значимого требования, следующим образом:

OL(drugl) = OL(drugs) = OL(drug6) = (leffect, <),

OL(drug2) = OL(drug5) = (lprice, <),

OL(drug4) = OL(drugj) = (lsideEffect, <).

Для каждого объекта o G O определён уровень его характеристик fo относительно значимого к нему требования. Значения функции fo для каждого объекта представлены на рис. 2.

DO = {(effect,drugl), (ef fect,drug3), (effect, drug6), (price, drug5),

(price, drug6), (sideE f fect, drug4), (sideE f fect, drug7)} — множество пар значимых требований и объектов.

Структура связей между элементами модели D-TBAC применительно к медицинскому учреждению показана на рис. 3.

Состояние системы может изменяться путём использования трёх команд: set demad, start task, stop task. Пусть начальное состояние системы V = (CT, B, Y) будет:

• CT = 0;

• B = 0;

• ^(s, t, (fd, fo)) G Y верно (s, t, (fd = none, fo)).

Пусть субъекту doctorl необходимо выполнить задачу treatmentl в определённых требованиях. Тогда последовательность преобразований системы в соответствии с моделью D-TBAC будет выглядеть, как представлено в табл. 2, в которой через V = (CT,B,Y) обозначено исходное состояние системы (до выполнения команды), а через V = (CT ,B,Y) обозначено результирующее состояние системы (после выполнения команды).

Аналогичным образом модель позволяет выполнить задачу treatmentl субъектом doctor2 , но уже в других требованиях к применению лекарственных препаратов. При этом различные уровни требований, которые могут быть установлены субъектам doctorl и doctor2 для выполнения задачи treatmentl, не имеют корреляции относительно множества доступов для

Effect high

medium

drugc

drug1

low dr"g3

Price high

low-

drug,

drug.

sideEffect

high dr^g7

low dr"g4

Рис. 2. Характеристики лекарственных препаратов относительно значимых требований

doctor j doctor 2 doctor 3

group.

V ргер? J

дгоир2 —удюир3

Objects

Рис. 3. Структура элементов модели Б-ТБЛС применительно к медицинскому учреждению

данных субъектов между собой. Аналогично требования, установленные для решения задачи treatment2 субъектом doctor3, не влияют на доступы субъектов doctor\ и doctor2. Таким образом, каждый врач учреждения здравоохранения имеет доступ к минимальному набору лекарств, необходимых для выполнения своей задачи, при этом установленные требования к процедуре лечения никак не влияют на множество доступов других врачей, даже при условии выполнения одной и той же задачи.

Таблица 2. Последовательность преобразований состояния системы

Запрос Результирующее состояние

set_demad(doctori, treatmenti, effect, medium) CT' = CT, B' = B, Y = Y \ Yold U Ynew, Yoid = {(doctori, treatment], (feffect = none, fdrugs = low)), (doctorl,treatmentl, (feffect = none, fdrugi = medium)), (doctori, treatment], (feffect = none, fdrug6 = high))}, Ynew = {(doctori, treatment], (feffect = medium, fdrug3 = low)), (doctorl,treatmentl, (feffect = medium, fdrugi = medium)), (doctorl,treatmentl, (feffect = medium, fdrug6 = high))},

set_demad(doctori, treatmentl, price, high) CT' = CT, B' = B, Y = Y \ Yold U Ynew, Yoid = {(doctori, treatment], (fprice = none,fdrug6 = low)), (doctorl,treatmentl, (fprice = none, fdrug2 = high))}, Ynew = {(doctori, treatmenti, (fprice = high, fdrug6 = low)), (doctori, treatmenti, (fprice = high,fdrug2 = high)),

start_task(doctorl, treatment]) Y' = Y, CT = CT U {doctori, treatmenti}, B = B U Bnew, Bnew = {(doctori, drugi, apply), (doctori, drug2, apply)}

stop_task(doctori) Y' = Y, CT = CT \ {doctori, treatmenti}, B = B \ Bold, Bold = {(doctori, drugi, apply), (doctori, drug2, apply)}

5. Заключение

В настоящей статье предложена и формально определена модель Б-ТВАС, расширяющая ТВАС. Как показано в разделе 2, применение существующих моделей разграничения доступа в рассматриваемых системах является затруднительным. Это связано с тем, что в них предполагается, что одна и та же задача будет решена субъектом системы через использование одного множества объектов, к которому ему предоставляется доступ. Однако не учитывается, что к процессу решения задачи могут предъявляться определённые требования. В зависимости от таких требований для решения одной и той же задачи субъекту могут предоставляться различные доступы к равнозначным объектам.

В разделе 3 формально определены множества элементов, из которых состоит модель Б-ТВАС, свойства представленной модели, описывающие безопасность системы, а также правила, в соответствии с которыми система переходит из одного состояние в другое. Модель Б-ТВАС предоставляет механизм, позволяющий выделить минимальные права доступа субъектов системы к равнозначным объектам. В разделе 4 показано, каким образом возможно применить модель Б-ТВАС в учреждении здравоохранения.

Среди достоинств предлагаемой модели можно обозначить следующие:

1. Модель позволяет предъявлять субъекту требования к процессу решения поставленной задачи.

2. Модель предоставляет прозрачные правила для разграничения прав доступа на равнозначные объекты из каждой группы.

3. Модель выделяет минимально необходимые права доступа субъектам системы при наличии в ней равнозначных объектов.

4. Разграничение прав доступа субъектов системы на объекты системы происходит в соответствии с задачами, которые они выполняют в данный момент времени.

5. Модель позволяет реализовать динамический контроль доступа.

6. Простота администрирования политики безопасности, построенной в соответствии с моделью.

Представленная в данной статье модель Б-ТВАС может найти применение в динамических системах, в которых стоит вопрос выбора объектов для решения определенного круга задач, в кибер-физических системах, в информационных и телекоммуникационных системах [1]. Однако модель нуждается в дальнейшем её исследовании. Особый интерес представляют исследования, ориентированные на применение модели Б-ТВАС в рамках существующих моделей безопасности в качестве их дополнения и построения гибридных моделей.

Из всего вышесказанного следует, что поставленная во введении цель достигнута, а обозначенные задачи решены.

Литература

1. Лапин С. А. Применение модели контроля доступа D-TBAC для разграничения доступа пользователей к каналу связи в системах предоставления мультимедиа контента // Сборник научных статей международной конференции «Ломоносовские чтения на Алтае: фундаментальные проблемы науки и образования». Барнаул, 20-24 октября, 2015. C. 11291132.

2. Лапин С. А. Применение модели разграничения доступа D-TBAC в медицинском учреждении для контроля доступа к лекарственным препаратам // Новые информационные технологии и системы: сб. науч. ст. XII Междунар. науч.-тех. конф. Пенза, 15-19 ноября, 2015. C. 184—187.

3. Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками. Учебное пособие для вузов. 2-е изд., испр. и доп. М.: Горячая линия-Телеком, 2013. 338 с.

4. Harrison, Michael A. and Ruzzo, Walter L. and Ullman, Jeffrey D. Protection in Operating Systems // Commun. ACM. 1976. V. 19, № 8. P. 461-471.

5. Bell D., LaPadula L. Secure Computer Systems: Unified Exposition and Multics Interpretation // Bedford, Mass. MITRE Corp. 1976. MTR 2997. Rev. 1.

6. Sandhu R. Role-based Access Control // Advances in Computers. 1998. V. 46. P. 237-286.

7. Ferraiolo D., Sandhu R, Gavrila S., Kuhn R, Chandramouli, R. Proposed NIST Standard for Role-based Access Control // ACM Trans. Inf. Syst. Secur 2001. V. 4, № 3. P. 224-274.

8. Головин А. В., Поляков В. В., Лапин С. А. Ролевое разграничение доступа для автоматизированного рабочего места пользователя при оперативном удаленном управлении конфиденциальной информацией // Доклады Томского государственного университета систем управления и радиоэлектроники. 2010. Т. 21, № 1. С. 143—145.

9. Лепешкин О. М., Харечкин П. В. Анализ моделей разграничения доступа, реализованных в современных социотехнических системах // Инфокоммуникационные технологии. 2008. Т. 6, №2. С. 91-93.

10. Лепешкин О. М., Харечкин П. В. Функционально-ролевая модель управления доступом в социотехнических системах // Известия Южного федерального университета. Технические науки. 2009. Т. 100, № 11. С. 52—57.

11. Zhang C., Hu Y, Zhang G. Task-role based dual system access control model // IJCSNS International Journal of Computer Science and Network Security. 2006. V. 6, № 7 P. 211-215.

12. Ferraiolo D., CuginiJ., KuhnR. Role-based access control (RBAC): Features and motivations // Proceedings of 11th annual computer security application conference. New Orleans, Louisiana, December 11-15, 1995. P. 241-248.

13. Freudenthal E., Pesin T., Port L., Keenan E., Karamcheti V. dRBAC: distributed role-based access control for dynamic coalition environments // Proceedings of the 22-nd International Conference on Distributed Computing Systems (ICDCS'02). Vienna, Austria, July 2-5, 2002. P. 411-420.

14. Bertolissi, Clara and Fernández, Maribel and Barker, Steve Dynamic event-based access control as term rewriting // 21st Annual IFIP WG 11.3 Working Conference on Data and Applications Security. Redondo Beach, CA, USA, July 8-11, 2007. P. 195-210.

15. Lu, Yahui and Zhang, Li and Sun, Jiaguang Task-activity based access control for process collaboration environments // Computers in Industry. 2009. V. 60, № 6. P. 403-415.

16. Oh S., Park S. Task-role-based access control model // Information Systems. 2003. V. 28, № 6. P. 533-562.

17. Thomas R. K., Sandhu R S. Task-based authorization controls (TBAC): A family of models for active and enterprise-oriented authorization management // Proceedings of the IFIP TC11 WG11.3 Eleventh International Conference on Database Securty XI: Status and Prospects. Lake Tahoe, California, USA, August 10-13, 1997. P. 166-181.

18. Cvrcek D. Access Control in Workflow Systems // MOSIS'99 Proceedings. RoZnov pod Radhostem, CZ, April 27-29, 1999. P 93-100.

19. Лапин С. А. Неформальное описание модели разграничения доступа на основе задач с учетом требований к их выполнению // Проблемы правовой и технической защиты информации. 2015. № 3. С. 52—57.

Статья поступила в редакцию 01.12.2015; переработанный вариант - 28.03.2016.

Лапин Сергей Александрович

аспирант кафедры прикладной физики, электроники и информационной безопасности АлтГУ (656049, Барнаул, пр. Ленина, 86), тел. 8 (3852) 364809, e-mail: lapinsa567@gmail. com.

Access control model D-TBAC with the requirements to carry out tasks

S. Lapin

This article describes access control model D-TBAC which extends TBAC. The presented model takes into account the requirements for performing the tasks. Model elements, properties, and rules of the states transformation are formally defined.

Keywords: IT-security, mathematical models of security, access control, dynamical systems, tasks, TBAC, requirements.