Ролевой подход широко используется в управлении доступом. В его основе находится RBAC, или ролевая модель, обладающая многими существенными преимуществами по сравнению с другими традиционными моделями (MAC, DAC).
Так, например, в мандатной (MAC) модели предполагается, что у пользователя есть мандат или допуск к определённому классу информации. Сами информационные ресурсы в этой модели классифицируются и также разделяются по уровням допуска. Грифы секретности: “особой важности”, “совершенно секретные”, “секретные” – это примеры использования данной модели. Модель довольно простая, но ей не хватает гибкости: представьте, что все информационные ресурсы одного уровня допуска доступны всем пользователям с соответствующим мандатом. Увеличивать количество классов – это снижение простоты, наглядности.
В дискреционной (DAC) модели доступ к информационным ресурсам осуществляется к конкретным операциям или отдельным его объектам для каждого пользователя. На входе – множество пользователей информационного ресурса и множество объектов и операций над ними. Администратор доступа к информационному ресурсу формирует условную матрицу, таблицу / список доступа, где на пересечениях столбцов (пользователи) и строк (объекты и действия) проставляется признак разрешения доступа.
В ролевой модели доступ выдаётся не к классам информации, не напрямую к объектам и операциям в информационном ресурсе, а к определённым их группам, объединённых по какому-то признаку. Этим признаком зачастую является сценарий / функция использования данного набора прав доступа. Например, “администратор системы”, “пользователь модуля N” и т.п. Это удобно: при разработке системы уже закладываются определённые наборы прав, и доступ предоставляется к ним.
Масштабируя ролевую модель от уровня отдельного приложения до всего ИТ-ландшафта организации, мы приходим к функциональным или бизнес-ролям в границах всего предприятия или его подразделений. Бизнес-роль – это по факту набор отдельных (системных) ролей информационных ресурсов / ИТ-систем. Наглядность, простота назначения, соответствие бизнес-процессам и подразделениям, возможность запрета использования смежных ролей (разграничение полномочий), иерархия ролей (возможность выстраивания цепочек связанных ролей “родительская-дочерняя”) – всё это удобные возможности данной модели.
А теперь давайте предположим, что в отлаженную и работающую ролевую модель предприятия необходимо внести изменения. Для начала давайте поймём, чем они могут быть вызваны. Я выделяю следующие триггеры, отражающие изменение бизнес-окружения, ведущие к необходимости пересмотра модели:
- изменение ИТ-ландшафта: замена системы, вывод системы из эксплуатации
- изменение бизнес-процессов
- изменение организационной структуры
При замене системы на другую (переход от одного вендора к другому, переход внутри вендора от кастомного решения к дистрибутивному) может измениться, либо полностью изменяется набор системных ролей в приложении. При изменении бизнес-процессов может измениться набор системных ролей сразу в нескольких системах. При изменении организационной структуры могут быть затронуты роли в границах “бывших” подразделений. Всё это требует пересмотра и актуализации ролевой модели организации, если мы хотим продолжать использовать её для управления доступом.
Как быть готовым к подобным изменениям, как планировать свои действия при их наступлении? В первую очередь необходимо определить охват затронутых изменениями бизнес-ролей и системных ролей, которые их формируют.
Если это замена системы, то нужно составить перечень архивируемых ролей из прежней системы и добавляемых ролей из новой. Затем определить, какие из системных ролей прежней системы соответствуют ролям новой, построив таблицу соответствия “старая-новая” роль. После перехода на новую систему роли прежней системы отправляются в архив, а бизнес-роли, в которых они содержались, обновляются в версии и переходят на роли новой системы. Пользователям назначаются обновлённые бизнес-роли, для чего создаются соответствующие записи доступа.
Изменение бизнес-процессов отражается на поддерживающих их системах в виде появления новых или изменения имеющихся системных ролей внутри данных систем вследствие возникновения новых объектов и операций над ними. Здесь акцент делается не на соответствии изменяемых ролей, а на привязке новых ролей к исполнителям (должность, подразделение), поскольку при изменении процесса исполнители могут поменяться.
Если планируются изменения в структуре организации, например, слияние, разделение или возникновение новых управлений или департаментов, нужно понять, что за новые организационные единицы возникнут с точки зрения выполняемых функций: “старое-старое” (все выполняемые функции прежние, набор бизнес-ролей подразделения тот же), “старое-новое” (к старым функциям добавились новые, к бизнес-ролям основного подразделения добавились бизнес-роли сливаемого), “новое” (вновь организованное подразделение со своим набором бизнес-ролей).
Коллеги, а как вы готовитесь к переменам, как планируете изменения бизнес-ролей? Поделитесь, пожалуйста, и своим опытом.
