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

Agile RBAC?

Когда мы слышим или употребляем выражение RBAC (Role-Based Access Control, ролевая модель управления доступом), какой смысл мы вкладываем в него в первую очередь? Конечно, использование ролей. Это центральный элемент данной модели управления доступом. Как показывает практика, модель, действительно, хороша. Используется сейчас очень широко, по большей части заменяя альтернативные модели — DAC (Discretionary Access Control, избирательное управление доступом), MAC (Mandatory Access Control, мандатное управление доступом). Про достоинства RBAC мы немало рассказывали на конференциях, на наших вебинарах, в заметках на портале.

При всех своих преимуществах, удобстве и плюсах использования RBAC критически зависит от важной аналитической работы — проектирования или формирования ролей. Что это такое. Деятельность по разработке и проектированию ролей включает в себя сбор, анализ и формирование непротиворечивых и согласованных «пакетов» разрешений на доступ к разнообразным ИТ-ресурсам. Ресурсами могут выступать бизнес-приложения, таблицы баз данных, файловые хранилища, промышленные и тестовые среды, подписки, внешние сервисы и т.п. Как вы можете заметить, довольно разнородный набор ресурсов, серьёзно отличающихся друг от друга архитектурными особенностями.

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

Кроме начального определения и формирования ролей, требуется ещё и поддерживать созданную ролевую модель в актуальном состоянии. В целом, преимущества RBAC заметно усиливаются, если в организации стабильная организационная структура, стабильный ИТ-ландшафт, малое количество изменений ролей, при этом большое количество сотрудников, высокая текучесть кадров. Но в эпоху Agile-подходов в организациях, конечно, только и разговоров, что о стабильности и неизменности (нет)...

Как же поспевать за темпом изменений? Увеличить количество аналитиков ролей? Отказаться от ролевой модели? Давайте попробуем вместе разобраться, как можно поступить. Меняться может многое: бизнес-процессы, за ними — бизнес-приложения, организационная структура. Всё это неизменно ведёт к изменению уже применяемых в управлении доступом в организации ролей. На увеличение количества ставок персонала в организации может быть наложено ограничение. И отказ от использования ролевой модели, на мой взгляд, тоже не лучший выбор.

Представим, что мы наблюдаем два состояния. Первое — использование дискреционной модели. Второе — использование стабильной, сложившейся и малоизменяемой ролевой модели. Определённо, для тех, кто уже попробовал на практике ролевую модель с её прозрачностью, соответствием бизнес-процессам, масштабируемостью, легкостью администрирования прав доступа, первое состояние будет шагом назад. А второе состояние недостижимо в силу объективных причин — высокого темпа изменений. Полагаю, истина где-то рядом ©. И нужно промежуточное решение.

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

Аналитики / проектировщики ролей на базе стабильных бизнес-процессов и относительно стабильных областей бизнес-процессов могут формировать роли обычным (привычным) способом. Это будет та основа, «костяк», которая будет назначаться всем имеющим соответствующие полномочия сотрудникам. А к ней затем уже можно добавлять отдельные разрешения для конкретных используемых ИТ-ресурсов для каждого сотрудника. В итоге получится набор базовых ролей, которые будут относительно неизменными, и выдаваемые по запросу отдельные дополнительные разрешения. По мере того, как новые ИТ-ресурсы будут вливаться в ИТ-ландшафт и становиться его уже неотъемлемой частью, можно будет включать присущие им разрешения в общую ролевую модель организации.

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

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

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

  • Рубрики

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

    • Определяем полюс потребителя
      При анализе и построении «путешествия заказчика» (customer journey) одной из важнейших задач является получение ответов на ряд вопросов, а именно: кто конкретно …
    • Семь распространённых мифов о DevOps
      В сообществе разработчиков бытует множество мифов о DevOps. И это и неудивительно, учитывая, сколько новшеств привнесла эта концепция за последние годы. DevOps — это …
    • Разрешение конфликтов в Agile-командах
      Большинство людей предпочло бы избегать конфликтов. Как специалисты по проектам, мы знаем, что это неизбежно, и мы также знаем, что несогласие может быть конструктивным. Но при …
    • Очередность прохождения курсов ITIL 4
      Имеет ли значение, в каком порядке проходить курсы по ITIL? Рассказывает аккредитованный тренер по ITIL 4 Игорь Фадеев. Cleverics — первая в России и одна из первых в …
    • 1 октября конференция «Роботизация бизнес-процессов 2020»
      1 октября 2020 издательство «Открытые системы» проведет ежегодную конференцию «Роботизация бизнес-процессов 2020» https://www.osp.ru/iz/rpa2020, где на одной площадке будут …
    • ITIL® 4 DITS — огонь, вода и медные трубы
      Мы уже писали о скором релизе последнего экзамена в сертификационной линейке ITIL 4 Digital and IT Strategy (DITS). Сейчас стоит добавить следующее (из информации, которую можно …
    • Как бизнес-аналитику встроиться в гибкую среду?
      Есть ли роль бизнес-аналитика в гибкой среде? Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики  зачастую считают, что они должны …
    • Деловая игра Grab@Pizza: вкусный кейс
      Деловые игры – один из наиболее эффективных видов тренинга, позволяющий на основе близкого к реальному кейса попрактиковаться в выстраивании любой работы. Участники деловой игры …
    • ITAM & SAMday пройдёт в Москве 2 октября
      ITAM & SAMday  – всероссийская независимая конференция, посвященная вопросам управления ИТ-активами и программными активами — пройдёт в Москве 2 октября в режиме …
    • Бэклог! — Как много в этом слове ...
      Команды, работающие над развитием различных продуктов, имеют одну общую цель: обеспечить максимальную скорость изменения своего продукта для реализации возникающих потребностей …
  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT