Здравствуйте, уважаемые посетители портала! Меня зовут Александр Омельченко, я – новый сотрудник компании Cleverics. Буду заниматься проектами по внедрению решений IDM и управлению доступом. В связи с появлением нового направления в компании, хочу рассказать подробнее про связанные с управлением доступом понятия. Сегодня поговорим о наиболее популярной на сегодняшний день модели предоставления доступа – управление доступом на основе ролей, известной как RBAC (Role Based Access Control).

Управление доступом на основе ролей

Ключевой особенностью ролевой модели является то, что весь доступ к информационным системам и ресурсам предоставляется только через роли. Роль – это набор прав доступа. Пользователи получают доступ только через присвоенные им роли.

Идея предоставления доступа на основе ролей возникла из необходимости группировки наборов прав в какие-то отдельные сущности, которые четко давали бы понять, какой доступ есть у пользователя, с которыми было бы удобнее и понятнее работать в случае изменений как положения пользователя в организации, так и набора прав доступа пользователя. Исторически сложилось, что наборы прав стали привязывать к должностям сотрудников, по сути – к функциональным ролям. Отсюда появилось понятие роли. Первые приложения, реализующие ролевое управление доступом пользователей, начали появляться еще в 1970х годах. В то время это были достаточно простые системы и приложения. Не было единой модели, описывающей как именно доступ предоставляется пользователю на основе его роли в организации. Системы разрабатывались различными организациями без согласованных определений и стандартов.

Универсальную модель ролевого управления доступом впервые предложили Дэвид Феррайоло и Ричард Кун из Национального Института Стандартов и Технологий США (NIST) в 1992 году. Документ давал определения основным понятиям, их отношениям и зависимостям, и представлял ролевое управление доступом (RBAC – Role Based Access Control) как альтернативу мандатному управлению (MAC – Mandatory Access Control) и избирательному управлению (DAC – Discretionary Access Control) доступом. Об этих и других моделях можно прочитать здесь. Сегодня этот документ вырос в полноценный международный стандарт INCITS 359-2012, о нём, я думаю, мы ещё расскажем подробнее. 

Преимущества ролевого управления доступом

По сравнению с указанными выше моделями, ролевое управление доступом обладает рядом важных положительных свойств. Например:

• Возможность построения иерархии ролей с наследованием набора прав. Это позволяет упростить ролевую модель, особенно в организациях с разнородной инфраструктурой, где используется много информационных систем. С использованием иерархии нет необходимости повторно указывать права в нескольких подобных ролях, достаточно поместить их в одну большую роль, как дочерние, указав лишь уникальные права для каждой роли.  
• Просто и эффективно осуществляется предоставление одинаковых прав большому количеству пользователей – достаточно назначить пользователям одну роль.
• При необходимости изменения набора прав большому количеству пользователей достаточно изменить набор прав в роли.
• Возможность реализации принципа разделения полномочий (SoD – Segregation of Duties). Это значительно снижает риск предоставления пользователям избыточных полномочий, например, когда две роли не могут быть в один момент времени назначены одному пользователю.

Особенности

При проектировании, внедрении и использовании ролевой модели управления доступом нужно принимать в расчёт факторы, которые могут привести к серьезным потерям времени и средств.

Во-первых, «разнообразие пользователей»: на практике в крупных организациях может оказаться достаточно большое количество пользователей с уникальными правами, при этом некоторые из них могут быть на одной должности, а то и в одном подразделении. Это усложняет построение ролевой модели и может привести к ситуации, когда каждому пользователю необходима своя уникальная роль. Такие ситуации могут возникнуть, когда сотрудник «вырос» в рамках своей должности или у него просто есть уникальные функции в рамках своего подразделения. Это может стать серьезной проблемой для системы управления доступом:

• В таком случае трудно определить "разумно малый" набор ролей, которые отвечают за права доступа основной массы пользователей.
• Непрактично создавать столько же ролей сколько пользователей – это равносильно ручному управлению доступом.

Во-вторых, «слишком много ролей»: это не всегда так, но может случиться такая ситуация, когда при подключении к системе  управления доступом еще одной управляемой системы, роли, определенные для ранее подключенных систем, необходимо раздробить на несколько других ролей, с учетом всех возможных вариантов использования совместно с новой системой. Если таких новых систем несколько, то может возникнуть ситуация, когда ролей окажется больше чем пользователей.

В-третьих, «изменение обязанностей пользователей и реорганизация бизнеса»: даже если ролевая модель отражает текущую ситуацию в организации, ее необходимо поддерживать в актуальном состоянии, отслеживать изменения обязанностей пользователей и оперативно вносить изменения в ролевую модель.

В-четвёртых, «стоимость»: необходимо учитывать, что разработка и поддержка ролевой модели в итоге может стоить дороже ручного администрирования. Кроме того, управление ролевой моделью требует более квалифицированных специалистов, чем администратор, который предоставляет права.

Практика применения

Ранее мы увидели, почему управление правами пользователей на основе ролевой модели может быть сложным и дорогим, и даже после успешного внедрения доставить много проблем как ИТ, так и бизнесу.

В каких же случаях, несмотря на перечисленные особенности, организация доступа на основании ролей оправдывает себя? Во-первых, в рамках одной системы, где возможное количество комбинации прав довольно невелико, и как следствие, несложно управлять малым количеством ролей. На самом деле, использование RBAC уже давно считается лучшей практикой при разработке приложений, серверов баз данных и операционных систем. Во-вторых, в организациях, где достаточно большое количество пользователей имеет одинаковые права. Например, кассиры в банках, продавцы в розничной торговле и сетях быстрого питания, бухгалтерия и т.д. В каждом из этих примеров нескольких ролей достаточно для предоставления доступа тысячам пользователей.

Следует отметить также, что неизбежны ситуации, когда мы можем смоделировать роли для достаточно большого числа пользователей, при этом в той же организации останутся пользователи, чьи права определить в рамках ролевой модели затруднительно, либо вообще невозможно. Нужно понимать, что одно лишь использование RBAC – не панацея, необходимо параллельно продумывать и другие способы предоставления доступа – это динамические правила, запросы прав доступа, анализ атрибутов пользователей. Подробнее об этом я могу рассказать в следующих заметках.

Резюмируя, можно сказать следующее – RBAC является полезным решением для некоторых конкретных проблем: управление пользователями в одном каталоге или управление большими группами пользователей с одинаковыми правами. Но RBAC, как единственная модель предоставления доступа, не подходит для более общей проблемы управления правами большого количества разнообразных пользователей и динамического доступа пользователей во многих системах.

ОБУЧЕНИЕ

ITIL 4 Foundation, DSV, DPI, CDS, HVIT, DITS

и другие интересные аббревиатуры от соавторов ITIL 4