Agile RBAC?

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

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

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

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

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

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

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

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

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний: