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

В организациях роли определяют различные рабочие функции, а права на выполнение конкретных операций назначаются определённым ролям. Участники (пользователи) получают те или иные роли и, посредством этих назначений, приобретают права на выполнение определённых действий. Поскольку разрешения назначаются не непосредственно пользователю, а только роли (или ролям), которые ему присвоены, управление индивидуальными правами пользователя сводится к простой выдаче или отзыву ролей. Такой подход значительно упрощает администрирование — например, при добавлении нового пользователя или переводе его в другой отдел.

Для RBAC определяются три основные правила:

1. Назначение роли: субъект может выполнить действие (транзакцию) только в том случае, если он выбрал или ему назначена определённая роль.
2. Авторизация роли: активная роль субъекта должна быть ему явно разрешена. В совокупности с первым правилом это гарантирует, что пользователи могут принимать только разрешённые им роли.
3. Авторизация транзакций: субъект может выполнять транзакцию только в том случае, если данная операция разрешена для его активной роли. С учётом первых двух правил это гарантирует, что пользователь может выполнять только те действия, на которые у него есть права.

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

Использование ограничений и иерархий ролей позволяет воспроизводить и моделировать подход управления доступом на основе решётки (LBAC). Таким образом, RBAC можно рассматривать как развитие идей LBAC.

Распространённая нотация включает:

• S = Субъект (пользователь или автоматический агент)
• R = Роль (рабочая функция, должность, определённый уровень полномочий)
• P = Разрешения (утверждённый способ доступа к ресурсу)
• SE = Сессия (связь, объединяющая S, R и/или P)
• SA = Назначение субъекта (mapping назначения ролей субъектам)
• PA = Назначение разрешения (назначение разрешений ролям)
• RH = Частично упорядоченная иерархия ролей (иногда обозначается ≥, где x ≥ y означает, что x наследует разрешения y)

Дополнительные правила:

• Один субъект может иметь несколько ролей.
• Одна роль может назначаться нескольким субъектам.
• Роль может иметь множество разрешений.
• Разрешение может быть связано с несколькими ролями.
• Операция может быть включена в несколько разрешений.
• Разрешение может включать несколько операций.

Ограничения (constraints) служат для введения жёстких правил, например, предотвращающих конфликт интересов: субъект, уполномоченный создавать учётную запись, не должен иметь права её утверждать.

Математически:

• ${\displaystyle PA\subseteq P\times R}$: отношение многие ко многим между разрешениями и ролями;
• ${\displaystyle SA\subseteq S\times R}$: отношение многие ко многим между субъектами и ролями;
• ${\displaystyle RH\subseteq R\times R}$: отношение многие ко многим между ролями (иерархия ролей).

Пользователь (субъект) может иметь несколько параллельных сессий с разными ролями одновременно.

RBAC — гибкая технология управления доступом, позволяющая реализовать системы дискреционного управления доступом (DAC)^[3] или обязательного управления доступом (MAC)^[4]. В свою очередь, DAC с группами (например, в файловых системах POSIX) может эмулировать RBAC^[5]. MAC также может симулировать RBAC, если дерево ролей организовано как иерархическое дерево, а не частично упорядоченное множество^[6].

До развития RBAC основными моделями считались модель Белла — ЛаПадулы (BLP, синоним MAC) и разрешения файловых систем (DAC). Любая система управления доступом относилась только к одной из этих категорий. Исследования конца 1990-х показали, что RBAC не вписывается ни в одну из них^[7][8]. В отличие от контекстно-ориентированного контроля доступа (CBAC), RBAC не опирается на сообщения о контексте (например, источник соединения). Среди известных критических замечаний — проблема "взрывного роста числа ролей"^[9], присутствующая в корпоративных системах, где требуется более гибкое и детальное управление доступом, чем позволяет простая иерархия ролей. Похожим образом системы управления доступом на основе отношений (ERBAC, не путать с расширенным RBAC — Extended Role-Based Access Control^[1]), позволяют привязывать разрешения к конкретным субъектам посредством связей с данными^[10].

RBAC также отличается от списков контроля доступа (ACL), традиционно применяющихся в DAC-системах: в них разрешения выдаются для операций над объектами верхнего уровня (например, файлом), а не для детальной бизнес-логики. Так, ACL может разрешать или запрещать запись в конкретный файл, но не определяет, каким именно образом этот файл может быть изменён. В RBAC операция может быть определена более детально, например, "создать кредитный счёт" в банковском приложении или "добавить анализ уровня сахара в крови" в медицинском ПО. Это важно для разделения обязанностей (SoD, англ. separation of duties), предполагающего, что выполнение критических операций требует участия нескольких лиц. Исследования определили необходимые и достаточные условия для обеспечения SoD в системах RBAC: никто не должен иметь возможность совершить нарушение безопасности, обладая одновременно контролирующими и проверяющими ролями^[11][12].

В системе дискреционного управления доступом (DAC) пользователь может предоставлять или запрещать доступ к «своим» объектам другим субъектам (лично или по группам) по собственному усмотрению. Централизованного контроля со стороны администратора не требуется: права могут передаваться произвольно, а не только через специальные механизмы.

В RBAC, напротив, именно администратор определяет и обеспечивает соблюдение политики безопасности: допуск к ресурсам производится по ролям, определяющим права и обязанности, а отдельный пользователь не может сам передавать свои полномочия^[1].

RBAC можно трактовать как разновидность обязательного управления доступом (MAC), хотя он не обязательно основывается на многоуровневой модели секретности. Важно, что RBAC преимущественно управляет доступом к функциям и операциям, а не только к информации. В классической политике MAC (например, военной) главным является правило «кто может читать что»: основная задача — предотвратить несанкционированную передачу данных с высокого уровня секретности на низший. В RBAC приоритетом выступает обеспечение целостности, то есть контроль — «кто и что может делать с объектом»^[1]

Альтернативой модели RBAC служит подход на базе списков контроля доступа (ACL). Минимальная версия RBAC (RBACm) может быть сравнена с формой ACL, оперирующей только группами (ACLg), где в списках регистрации могут присутствовать исключительно группы. Barkley (1997)^[13]. показал эквивалентность RBACm и ACLg.

В последних версиях СУБД и фреймворков (например, CakePHP) ACL поддерживают группы и наследование в иерархии групп, и современные реализации ACL и RBAC сравнимы, в отличие от различий между RBAC и ранними файловыми системами.

Для обмена данными и для сопоставления на высоком уровне данные ACL могут быть представлены в формате XACML.

Управление доступом на основе атрибутов (англ. attribute-based access control, ABAC) развивает RBAC, учитывая дополнительные атрибуты пользователей и объектов. В ABAC разрешения можно зависеть от:

• характеристик пользователя (например, гражданство, разрешения),
• свойств ресурса (например, уровень секретности, отдел, владелец),
• типа действия,
• контекста (например, времени, местоположения, IP-адреса).

Политики ABAC динамические (policy-based), а не статические, что обеспечивает большую гибкость контроля.

Широко признано, что RBAC является одним из лучших подходов для управления пользовательскими привилегиями и доступом внутри отдельного приложения или компьютерной системы. Экономическая оценка, проведённая институтом Research Triangle по заказу NIST, показала, что внедрение RBAC позволяет существенно снижать простои и издержки на администрирование политики доступа^[14].

Однако при управлении ролями и назначениях для десятков или сотен систем и приложений в крупных организациях использование RBAC становится крайне сложным без формирования иерархий ролей и автоматизации назначения прав^[15]. Современные системы развивают классическую модель NIST RBAC^[16], чтобы снимать эти ограничения. Модель NIST принята в качестве стандарта ANSI/INCITS 359-2004, обсуждаются и её концептуальные особенности^[17].