Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT