Диссертация (1152223), страница 66
Текст из файла (страница 66)
Таким образом, дорожка на схеме процесса санкционирует доступ к операциям, а не к данным,как показано на рисунке 4.22 Б. Принадлежность к роли определяет разрешение выполнитьоперацию, по сути метод, который изменяет объект данных, но не устанавливает права доступак самому объекту. Для сравнения, разрешение записи в некоторый файл позволяет редактировать данные, но он не определяет, каким образом файл может быть изменён.РазрешениеА)Б)СубъектСубъектРольОбъектРазрешениеРольОперацияОбъектРисунок 4.22 - Процессно-ролевая модельИсточник: составлено авторомМожно говорить, что субъект исполняет роль, роль имеет разрешение исполнить операцию, операция определяет метод работы с объектом данных.
При этом один субъект можетиметь несколько ролей, а роль — включать множество субъектов; роль может иметь несколькоразрешений, открывая доступ к разным операциям, а одно разрешение может принадлежатьмногим ролям; операция может изменять множество объектов данных, последний может бытьизменён разными операциями. Таким образом, имеют место связи многие ко многим.Модели разграничения доступа в процессно-ориентированных системахВ последнее время появилось несколько формализованных моделей разделения доступа,которые используется для авторизации в процессно-ориентированных системах.
Рассмотримнекоторые из моделей.Ролевая модель доступа RBACШирокое распространение получила так называемая ролевая модель доступа (Role BasedAccess Control) [288], получившая статус национального стандарта [289], аналогичные требования содержатся в рекомендациях банка России [290]. Выделяют три уровня расширений: плоская модель (RBAC0), иерархии ролей (RBAC1), статическое (RBAC2) и динамическое (RBAC3)разделения обязанностей.Начальный уровень RBAC0 в точности соответствует ранее рассмотренной процессноролевой модели.
Иерархия ролей RBAC1 определяет наследования функций и их объединения вроли. Под статическим разделением обязанностей RBAC2 понимают выделение взаимоисключающих функций, распределение их по ролям на этапе моделирования процесса. Распределение254пользователей по ролям так же происходит до начала исполнения. Никаких дополнительныхизменений распределения пользователей в ходе исполнения не происходит.Динамическое разделение обязанностей RBAC3 подразумевает уточнение состава ролейнепосредственно в ходе исполнения. Для этого вводятся два новых понятия сессия и авторизация.
Будем разделять сеансы работы пользователя и сессии. Сеанс включает все время работыпользователя с момента регистрации и до его выхода из учётной записи. Сессия связана с обработкой одного производственного задания. В начале каждой сессии происходит авторизацияпользователя в назначенные ему роли. При этом динамически проверяются бизнес-правила, исключающие авторизацию во взаимоисключающих ролях.
Например, если пользователь уже былавторизован в соответствующей роли, авторизация во взаимоисключающей роли ему будет запрещена. Кроме того, используется понятие мощности роли, ограничивающее максимальноечисло лиц, которые могут быть авторизованы в роли в рамках одной сессии. Модель RBACпервоначально разрабатывалась для функционально ориентированных ИС [291], но она так жешироко используется в процессных системах. Рисунок 4.23 изображает обобщённую модельRBAC 0-3. Она показывает, что роли находятся в иерархической связи, образуя дерево. Отображение пользователей на роли происходит статически (SSD), либо динамически (DSD), в последнем случае роли присваиваются только на соответствующую сессию.Иерархия ролейПрисвоениеРазрешенийролиНазначениепользователяна рольСтатическоеназначениеСубъектРольРазрешениеОбъектСессионная рольСессияДинамическоеназначениеРисунок 4.23 - Модель RBAC 0 — 3Источник: составлено автором по материалам [291]Модель RBAC наряду с достоинствами обладает ей недостатком, т.к.
она учитывает разделение обязанностей, но игнорирует их связывание. Возникают сложности с моделированиемисторического аспекта и назначением на основе доступа к общим данным. Модель не разделяетпроцедуры отбора и назначения исполнителя.Преимущества и недостатки ролевой моделиПодведём итог, выделим преимущества и недостатки ролевой модели. Правильно сформированная ролевая структура представляет собой логический уровень модели, связывающийдиаграмму потока работ с организационной структурой компании и инвариантна изменениюоргструктуры или штатного состава. Иерархия ролей должна образовываться не методом синте-255за, реализуемого путём объединения операций, выполняемых одним участником, а методомфункционально декомпозиции работ.
Вместе с тем, ролевой модели присущи серьёзные недостатки:Роль помогает отобрать потенциальных исполнителей, но не позволяет описать процедуруназначения и полномочия исполнителя, связанные с исполнением одного задания.Роль определяет права доступа к операциям, но не к данным процесса. Как следствие,пользователю невозможно делегировать права на какой-то определённый информационный объект.Роль не учитывает права доступа к экземплярам процесса.Если не пользоваться составными ролями, количество ролей становится равным числуопераций процесса, управление администрирование усложняется.
А если использовать составные роли, возникает неоднозначность описания прав доступа. Мы не можем определить права к каждой операции в отдельности.Администрирование синтезированных составных иерархических ролей трудоёмко в рамках одного процесса. А в рамках многих процессов становится неподъёмной задачей.Пооперационная система разграничения доступаЧто бы расширить возможности и реализовать динамическое разделение обязанностей, вводится пооперационная (Task Based Authorization Control) модель доступа [292].
Она предполагает,что для каждого шага процесса можно индивидуально определить правила отбора исполнителя. Вмодель RBAC было введено понятие сессия, но её длительность не оговаривалась. Предположимтеперь, что сессия однозначно связана с длительностью одной операции, которая рассматривается как отдельный шаг исполнения, исполняемый в соответствующем контексте, который накладывает соответствующие ограничения на отбор исполнителей для данного задания. Управлениеправами доступа становится динамическим и децентрализованным, разрешения проверяются, активизируются и отменяются по мере исполнения каждого шага, как показано на рисунке 4.24.Иерархия Орг. ЕдОрг. ЕдиницаНазначениепользователяна рольURAСубъектСессия субъектаSUAСессияПрисвоениеИерархия ролей ролиполномочийRPAРольПолномочияСессионная рольSRAЭкземплярзаданияTRAОперацияTPAЗаданиеРисунок 4.24 - Модель TBACИсточник: составлено автором по материалам [292]Объект256Предполагается, что есть центральный пул ресурсов (сотрудников предприятия) среди которых следует выбрать одного реального исполнителя операции.
Выбор осуществляется с помощью двух наборов свойств, первый определяет свойства, которым должен удовлетворятькандидат, второй — разрешения, которые будут предоставлены отобранному исполнителю. Отбор и назначение исполнителя осуществляются динамически, причём выделяется жизненныйцикл разрешения, связанный с циклом исполнения данной операции процесса. Разрешение действительно во время исполнения операции и не действительно все остальное время.Представим себе два территориальных офиса компании.
Сотрудники обоих принадлежатодинаковым ролям, но они не должны видеть заявки другого офиса. Если, кроме того, существует требование, что внутри каждого из офисов существуют дополнительные правила разделения или связывания обязанностей, реализация накрадывающихся требований становитсянеобычайно сложной задачей. В рамках ролевой модели описать ограничения невозможно. Врамках пооперационной модели доступа перечисленные ограничения образуют контекст задачи, хотя и очень сложный.Наряду с описанными преимуществами, пооперационная модель доступа обладает недостатками.
Во-первых, она не имеет явного визуального представления на схеме процесса. Критерии отбора исполнителей не изображаются, но программируются, налицо отказ от моделеориентированной разработки. Во-вторых, отбор и назначение исполнителя осуществляютсяпрограммно, причём код оказывается «размазан» по модели процесса.
Сопровождение модели,внесение в неё изменений оказываются трудоёмкими. В случае любого изменения модели процесса объем изменений в модели, связанный с перепрограммированием логики распределенияработ окажется недопустимо высоким. Теряются основные преимущества процессноориентированного подхода. В-третьих, модель процесса оказывается мало удобной для визуального анализа, поскольку многие детали оказываются запрограммированы и на схеме процесса не отображаются. Указанные проблемы происходят, поскольку эта модель не содержит промежуточный логический слой, который отделял логическое понятие роль от конкретного исполнителя.
Вследствие утери логического слоя модель теряет гибкость, становится привязанной к конкретному исполнителю и конкретной организационной структуре.Параметрические ролиПараметрические роли [293] не включены в каноническую спецификацию RBAC, но ониявляются её естественным расширением. Если мы хотим визуально отобразить логику выбораисполнителя в соответствии с некоторым критерием, нам придётся расщепить роль на подроли,принадлежность к которым определяется каким-либо квалифицирующим свойством, причёмкаждая изображается отдельно на диаграмме процесса.
При этом соответствующая функция бу-257дет многократно повторяться на нескольких ролях. Вместо этого определим иерархию ролей,причём свяжем подчинённую роль нижнего уровня с некоторым справочником, содержащимлинейный классификатор. Значение классифицирующего параметра должно быть определенодо начала исполнения задания. Справочник может быть статическим или динамическим. В первом случае, число позиций справочника заранее определено, во втором, оно может меняться походу работы. В момент авторизации исполнителя на роль происходит проверка бизнес-правилаи из всех исполнителей роли верхнего уровня происходит отбор потенциальных исполнителей,удовлетворяющих критериям отбора. В результате могут быть отобрано несколько кандидатов,так что потребуется процедура выбора реального исполнителя.Поскольку применение параметрических ролей не регламентировано, аналитики используют их как для отбора кандидатов, так и для выбора исполнителя, описывая стратегию разделения обязанностей, что создаёт определённую путаницу.
Возможности параметрических ролейнедостаточно исследованы. Они помогают в ситуации, кода выбор исполнителя определяетсялинейным выбором. Но неясно, как действовать, если параметров отбора несколько. Можнопредложить рассмотреть многопараметрические роли, в которой допускаются справочник,имеющий сложную структуру. Но если ввести в отбор все возможные критерии, мы приходим кпооперационной системе авторизации, со всеми её недостаткамиНаучная новизна и практическая значимость метода моделирования ролей бизнес-процессаНаучная новизна полученного результата заключается в разработке метода отображенияролевой перспективы модели бизнес-процесса на организационную структуру предприятия, отличающегося тем, что роль участника рассматривается в качестве промежуточного логическогослоя модели процесса, который связывает диаграмму потоков работ и организационно-штатнуюструктуру компании, что делает модель процесса инвариантной изменениям штатного расписания или распределения ответственности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
