Получить консультацию по Solar inRights

Разграничение доступа на основе ролей (ролевая модель управления или RBAC) – популярный подход, использующийся в различных информационных системах (далее – ИС), приложениях и сервисах: базах данных, программах учета, CRM, облачных платформах и так далее. Например, RBAC применяется для управления полномочиями пользователей в Kubernetes, в Yii2, SELinux («Линукс» с повышенной безопасностью), Exchange Server и множестве других решений, которые используются компаниями из разных сфер. Управление доступом на основе ролей можно организовать и в других ИС (приложениях), даже если это не предусмотрено разработчиками «в базе». Делается это с помощью IdM-системы. Практически все решения этого класса (и Solar InRights, в частности) ориентированы как раз на использование RBAC с возможностью «подмешивания» других моделей.

Роли в ролевой модели и управление ими

Один из главных плюсов ролевого управления доступом – гибкость. С его помощью также можно смоделировать другие модели (например, DAC или MAC). Также RBAC является основанием или расширением для LBAC (управление доступом на основе решетки). За счет этого модель получила широкое распространение и популярность у компаний из разных сфер. Ей даже посвящено несколько международных стандартов. Основные из них: INCITS 359-2012, INCITS 494-2012, INCITS 459-2011.

Предоставление пользователям доступа к информационным системам/ресурсам в RBAC и наделение их полномочиями осуществляется через роли.

Роль – это совокупность прав доступа, на основе которых проверяется возможность выполнения пользователем того или иного действия в целевой информационной системе. Также ее описывают как круг пользователей/сотрудников, которым может быть поручена определенная функция. Роли в целевых информационных системах повторяют бизнес-роли в компании (т. е. RBAC позволяет выстроить систему управления доступом практически в полном соответствии с корпоративной иерархией и структурой компании). Они могут быть простыми (разрешать какое-то одно действие) и составными (объединять множество операций и полномочий). Одному сотруднику может присваиваться любое количество ролей (в зависимости от должности). За счет этого и обеспечивается гибкость: например, работникам на одинаковых должностях можно предоставлять различные полномочия.

В качестве примера роли можно рассмотреть пользователя root в Unix-подобных системах. Это – суперпользователь, который обладает неограниченными полномочиями. Такую роль могут использовать разные администраторы системы.

Операции по управлению ролями пользователей

В современных IdM-системах реализованы различные функции по управлению ролями. Например, в Solar InRigts с ними можно производить следующие действия:

  • Создание. Это процесс привязки роли к целевой информационной системе (далее – ИС) и определения возможностей/полномочий, которые она предоставляет пользователю, которому назначена.

  • Анализ. Позволяет быстро оценить, в каких системах авторизован сотрудник компании и какие права ему там предоставлены. За счет этого специалист по информационной безопасности или руководитель в любой момент времени владеет полной картиной, касающейся доступов и полномочий сотрудников компании в разных ИС.

  • Изменение, активация, деактивация. При изменении состава роли происходит автоматическое централизованное изменение полномочий/доступов пользователей, которым она назначена. Это экономит немало времени на внесении необходимых изменений.

  • Объединение по группам (каталогам). В больших компаниях с множеством сотрудников при использовании RBAC образуются сложные многомерные модели. Благодаря возможности объединения ролей по группам обеспечивается их максимальное приближение к штатной структуре, упрощается поиск нужной информации о пользователях, их правах/доступах/полномочиях.

  • Установка запретов на сочетание полномочий. Это обеспечивает управление SoD-конфликтами. Запреты на сочетание полномочий/доступов могут устанавливаться как в рамках какой-то одной роли, так и между ними.

Важно учитывать, что роль может включать в себя должностной, типовой или индивидуальный доступ, и выстраивать процессы управления, отталкиваясь от этого. Должностной – это набор полномочий, который предоставляется сотрудникам одного подразделения на одинаковых должностях (например, роль с таким доступом может звучать как «Менеджер отдела продаж»). Типовой предоставляется с учетом специфики работы сотрудника или для выполнения определенных функций (например, «Менеджер отдела продаж филиала N»). Индивидуальный предоставляется для решения конкретной задачи, поставленной работнику. При использовании RBAC таких доступов не должно быть более 5–10% от общего количества. В противном случае управлять полномочиями становится сложнее и модель от ролевой больше отклоняется в сторону дискреционной (DAC).

Еще одна важная составляющая процесса управления ролями пользователей – их регулярный аудит или ресертификация. Он сводится к проверке соответствия полномочий пользователей в ИС назначенным им ролям. Это позволяет выявлять доступы и права, полученные дополнительно по отдельным заявкам и принять решение об изменении/дополнении стандартных ролей. Или же проводится проверка на соответствие полномочий той или иной роли действующему функционалу работника или подразделения, чтобы вовремя скорректировать ролевую модель. Также за счет этого обнаруживаются неактивные учетные записи, которые могут стать источниками инцидентов в сфере информационной безопасности, избыточные полномочия и другие ситуации, которые могут привести к нарушению ИБ компании.

Возможно ли ручное управление ролями пользователей в компании? Вполне. Но все зависит от количества сотрудников и ИС, использующихся в организации. Опыт показывает, что вручную управление возможно в компаниях с количеством сотрудников до 100 человек. Если сотрудников около 500 – это будет значительно труднее. Если штат еще больше – свыше 1000, – на управление в ручном режиме уйдет немало времени и лучше подумать о внедрении IdM или аналогичного решения. ПО этого класса позволяет реализовать в компании ролевую RBAC и обеспечить эффективное управление процессами, связанными с предоставлением доступа к корпоративной информации.

ДРУГИЕ СТАТЬИ ПРОДУКТА

Еще больше о наших возможностях

Визуальный конструктор бизнес-логики на основе Camunda BPM

Визуальный конструктор бизнес-логики на основе Camunda BPM

Узнать больше
Результат от внедрения системы управления доступом

Результат от внедрения системы управления доступом

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