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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

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

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT