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

Agile RBAC?

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

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

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

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

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

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

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

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

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

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

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