Актуализация бизнес-ролей

Ролевой подход широко используется в управлении доступом. В его основе находится RBAC, или ролевая модель, обладающая многими существенными преимуществами по сравнению с другими традиционными моделями (MAC, DAC).

Так, например, в мандатной (MAC) модели предполагается, что у пользователя есть мандат или допуск к определённому классу информации. Сами информационные ресурсы в этой модели классифицируются и также разделяются по уровням допуска. Грифы секретности: «особой важности», «совершенно секретные», «секретные» — это примеры использования данной модели. Модель довольно простая, но ей не хватает гибкости: представьте, что все информационные ресурсы одного уровня допуска доступны всем пользователям с соответствующим мандатом. Увеличивать количество классов — это снижение простоты, наглядности.

В дискреционной (DAC) модели доступ к информационным ресурсам осуществляется к конкретным операциям или отдельным его  объектам для каждого пользователя. На входе — множество пользователей информационного ресурса и множество объектов и операций над ними. Администратор доступа к информационному ресурсу формирует условную матрицу, таблицу / список доступа, где на пересечениях столбцов (пользователи) и строк (объекты и действия) проставляется признак разрешения доступа.

В ролевой модели доступ выдаётся не к классам информации, не напрямую к объектам и операциям в информационном ресурсе, а к определённым их группам, объединённых по какому-то признаку. Этим признаком зачастую является сценарий / функция использования данного набора прав доступа. Например, «администратор системы», «пользователь модуля N» и т.п. Это удобно: при разработке системы уже закладываются определённые наборы прав, и доступ предоставляется к ним.

Масштабируя ролевую модель от уровня отдельного приложения до всего ИТ-ландшафта организации, мы приходим к функциональным или бизнес-ролям в границах всего предприятия или его подразделений. Бизнес-роль — это по факту набор отдельных (системных) ролей информационных ресурсов / ИТ-систем. Наглядность, простота назначения, соответствие бизнес-процессам и подразделениям, возможность запрета использования смежных ролей (разграничение полномочий), иерархия ролей (возможность выстраивания цепочек связанных ролей «родительская-дочерняя») — всё это удобные возможности данной модели.

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

  • изменение ИТ-ландшафта: замена системы, вывод системы из эксплуатации
  • изменение бизнес-процессов
  • изменение организационной структуры

При замене системы на другую (переход от одного вендора к другому, переход внутри вендора от кастомного решения к дистрибутивному) может измениться, либо полностью изменяется набор системных ролей в приложении. При изменении бизнес-процессов может измениться набор системных ролей сразу в нескольких системах. При изменении организационной структуры могут быть затронуты роли в границах «бывших» подразделений. Всё это требует пересмотра и актуализации ролевой модели организации, если мы хотим продолжать использовать её для управления доступом.

Как быть готовым к подобным изменениям, как планировать свои действия при их наступлении? В первую очередь необходимо определить охват затронутых изменениями бизнес-ролей и системных ролей, которые их формируют.

Если это замена системы, то нужно составить перечень архивируемых ролей из прежней системы и добавляемых ролей из новой. Затем определить, какие из системных ролей прежней системы соответствуют ролям новой, построив таблицу соответствия «старая-новая» роль. После перехода на новую систему роли прежней системы отправляются в архив, а бизнес-роли, в которых они содержались, обновляются в версии и переходят на роли новой системы. Пользователям назначаются обновлённые бизнес-роли, для чего создаются соответствующие записи доступа.

Изменение бизнес-процессов отражается на поддерживающих их системах в виде появления новых или изменения имеющихся системных ролей внутри данных систем вследствие возникновения новых объектов и операций над ними. Здесь акцент делается не на соответствии изменяемых ролей, а на привязке новых ролей к исполнителям (должность, подразделение), поскольку при изменении процесса исполнители могут поменяться.

Если планируются изменения в структуре организации, например, слияние, разделение или возникновение новых управлений или департаментов, нужно понять, что за новые организационные единицы возникнут с точки зрения выполняемых функций: «старое-старое» (все выполняемые функции прежние, набор бизнес-ролей подразделения тот же), «старое-новое» (к старым функциям добавились новые, к бизнес-ролям основного подразделения добавились бизнес-роли сливаемого), «новое» (вновь организованное подразделение со своим набором бизнес-ролей).

Коллеги, а как вы готовитесь к переменам, как планируете изменения бизнес-ролей? Поделитесь, пожалуйста, и своим опытом.

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

Узнайте больше!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20