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

Agile RBAC?

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

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

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

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

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

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

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

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

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

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

Ваш адрес 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