Когда мы слышим или употребляем выражение RBAC (Role-Based Access Control, ролевая модель управления доступом), какой смысл мы вкладываем в него в первую очередь? Конечно, использование ролей. Это центральный элемент данной модели управления доступом. Как показывает практика, модель, действительно, хороша. Используется сейчас очень широко, по большей части заменяя альтернативные модели – DAC (Discretionary Access Control, избирательное управление доступом), MAC (Mandatory Access Control, мандатное управление доступом). Про достоинства RBAC мы немало рассказывали на конференциях, на наших вебинарах, в заметках на портале.
При всех своих преимуществах, удобстве и плюсах использования RBAC критически зависит от важной аналитической работы – проектирования или формирования ролей. Что это такое. Деятельность по разработке и проектированию ролей включает в себя сбор, анализ и формирование непротиворечивых и согласованных “пакетов” разрешений на доступ к разнообразным ИТ-ресурсам. Ресурсами могут выступать бизнес-приложения, таблицы баз данных, файловые хранилища, промышленные и тестовые среды, подписки, внешние сервисы и т.п. Как вы можете заметить, довольно разнородный набор ресурсов, серьёзно отличающихся друг от друга архитектурными особенностями.
Тонкость и важность работы аналитика / проектировщика ролей состоит в том, чтобы принять к сведению и учесть в проектируемых ролях все возможные ограничения совместимости отдельных разрешений ИТ-ресурсов с точки зрения принятых в организации политик информационной безопасности. Так, определённые разрешения никак не могут быть совмещены в одной и той же роли. Например, роль “Операционист” состоит из множества отдельных полномочий в разных ИТ-системах. Одно из таких разрешений – возможность проведения платежа в сторону контрагента при условии согласования платежа со стороны финансового контролёра, имеющего разрешение на выполнение действий в ИТ-системе, которые позволяют одобрить платёж. Однако, по принципу разделения полномочий и принятой в организации политике организации доступа согласование платежа и его проведение не может осуществляться одним и тем же сотрудником. Поэтому возникает необходимость в создании отдельной роли, назовём её “Контролёр”, которая будет содержать в себе данное разрешение. При этом роли “Операционист” и “Контролёр” не могут быть назначены одному и тому же сотруднику одновременно.
Кроме начального определения и формирования ролей, требуется ещё и поддерживать созданную ролевую модель в актуальном состоянии. В целом, преимущества RBAC заметно усиливаются, если в организации стабильная организационная структура, стабильный ИТ-ландшафт, малое количество изменений ролей, при этом большое количество сотрудников, высокая текучесть кадров. Но в эпоху Agile-подходов в организациях, конечно, только и разговоров, что о стабильности и неизменности (нет)…
Как же поспевать за темпом изменений? Увеличить количество аналитиков ролей? Отказаться от ролевой модели? Давайте попробуем вместе разобраться, как можно поступить. Меняться может многое: бизнес-процессы, за ними – бизнес-приложения, организационная структура. Всё это неизменно ведёт к изменению уже применяемых в управлении доступом в организации ролей. На увеличение количества ставок персонала в организации может быть наложено ограничение. И отказ от использования ролевой модели, на мой взгляд, тоже не лучший выбор.
Представим, что мы наблюдаем два состояния. Первое – использование дискреционной модели. Второе – использование стабильной, сложившейся и малоизменяемой ролевой модели. Определённо, для тех, кто уже попробовал на практике ролевую модель с её прозрачностью, соответствием бизнес-процессам, масштабируемостью, легкостью администрирования прав доступа, первое состояние будет шагом назад. А второе состояние недостижимо в силу объективных причин – высокого темпа изменений. Полагаю, истина где-то рядом (с). И нужно промежуточное решение.
Моё мнение – выделять в деятельности организации относительно стабильные области. Например, банковской АБС уже не первый десяток лет, корпоративному хранилищу данных – чуть меньше, но менять их пока что не планируют. Данные системы обеспечивают конкретные бизнес-процессы (кредитование физических лиц или депозиты, кассовое обслуживание и т.п.), которые выполняют банковские сотрудники на должностях операционистов, кассиров, контролёров и пр. Это – стабильная зона. В “нестабильной” зоне происходят изменения в части используемых ИТ-ресурсов. Так, раньше сотрудники отсылали отчёты по электронной почте, а теперь руководство хочет видеть их в системе автоматизации. Но пока оно не определилось, в какой именно, поэтому смена систем происходит довольно часто…
Аналитики / проектировщики ролей на базе стабильных бизнес-процессов и относительно стабильных областей бизнес-процессов могут формировать роли обычным (привычным) способом. Это будет та основа, “костяк”, которая будет назначаться всем имеющим соответствующие полномочия сотрудникам. А к ней затем уже можно добавлять отдельные разрешения для конкретных используемых ИТ-ресурсов для каждого сотрудника. В итоге получится набор базовых ролей, которые будут относительно неизменными, и выдаваемые по запросу отдельные дополнительные разрешения. По мере того, как новые ИТ-ресурсы будут вливаться в ИТ-ландшафт и становиться его уже неотъемлемой частью, можно будет включать присущие им разрешения в общую ролевую модель организации.
