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

Управление доступом на основе ролей (англ. Role Based Access Control, RBAC) — развитие политики избирательного управления доступом, при этом права доступа субъектов системы на объекты группируются с учётом специфики их применения, образуя роли.^[1][2]

Формирование ролей призвано определить чёткие и понятные для пользователей компьютерной системы правила разграничения доступа. Ролевое разграничение доступа позволяет реализовать гибкие, изменяющиеся динамически в процессе функционирования компьютерной системы правила разграничения доступа.

Такое разграничение доступа является составляющей многих современных компьютерных систем. Как правило, данный подход применяется в системах защиты СУБД, а отдельные элементы реализуются в сетевых операционных системах. Ролевой подход часто используется в системах, для пользователей которых чётко определён круг их должностных полномочий и обязанностей.

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

Так как привилегии не назначаются пользователям непосредственно и приобретаются ими только через свою роль (или роли), управление индивидуальными правами пользователя, по сути, сводится к назначению ему ролей. Это упрощает такие операции, как добавление пользователя или смена подразделения пользователем.

Элементарные формы модели RBAC были осуществлены во множестве специальных форм на многих системах, начиная с 1970-х годов. Контроль доступа на основе ролей, используемый в настоящее время происходит из модели, предложенной Феррайоло (англ. Ferraiolo) и Куном (англ. Kuhn) (1992) и как образцовая модель позже усовершенствованная Санди (англ. Sandhu), Койн, Фейнштейн и Йоман (1996).

• 1992 год — статья Феррайоло и Куна, определяющая RBAC посредством доступа только через роли, иерархии и ограничения. формальная модель;
• 1994 год — DTOS базировал опытный образец RBAC, на прототипе модели, предложенной Феррайоло, Кун, Гаврилья (англ. Gavrila)
• 1994 год — статья Nyanchama и Osborn определяет модель;
• 1994 год — IBM подаёт (в Европе) первую заявку на патент в области RBAC, цитирующую Феррайоло и Куна;
• 1995 год — Феррайоло, Кугини (англ. Cugini), Кун расширили формальную модель, введя определение форм разделения обязанностей;
• 1996 год — метод Санди для того, чтобы осуществить МАС на основе RBAC;
• 1997—1998 годы — Sybase, Безопасное Вычисление, Siemens объявляет о продуктах RBAC, описанных как базирующиеся непосредственно на модели
• 1997 год — безопасное вычисление включает модель Феррайоло-Куна RBAC в американскую Глобальную Команду DoD и Систему управления; выходит статья Куна на тему разделения обязанностей, необходимых и достаточных условий для безопасности разделения;
• 1997 год — статья Осборна основанная на отношениях между RBAC и многоуровневой безопасностью мандатной модели политики безопасности; аннотация роли, связывающая RBAC и многоуровневую безопасность
• 1998 год — RBAC — метод Куна для того, чтобы осуществить RBAC на системе МАС;
• 1999 год — Барклей (англ. Barkley), Феррайоло, Кун открывают исходный опытный образец RBAC для развитых веб-серверов;
• 2000 год — Санди, Феррайоло, Кун публикуют статью, определяющую объединенную модели RBAC, и предлагают стандарт RBAC;
• 2004 год — Американский национальный институт стандартов и Международный комитет по стандартам информационных технологий (ANSI/INCITS) принимают предложенную Санди, Феррайоло и Куном модель RBAC как единый стандарт.

Для определения модели RBAC используются следующие соглашения:

• S = Субъект (англ. Subject) = Человек или автоматизированный агент (множество пользователей);
• R = Роль (англ. Role) = Рабочая функция или название, которое определяется на уровне авторизации (множество ролей);
• P = Разрешения (англ. Permissions) = Утверждения режима доступа к ресурсу (множество прав доступа на объекты системы);
• SE = Сессия (англ. Session) = Соответствие между S, R и/или P
• SA = Назначение субъекта (англ. Subject Assignment)
• PA: R → 2^p — функция, определяющая для каждой роли множество прав доступа; при этом для каждого p ∈ P существует r ∈ R такая, что p ∈ PA(r); (англ. Permission Assignment)
• RH = Частично упорядоченная иерархия ролей (англ. Role Hierarchy). RH может быть еще записана так: ≥
• Один субъект может иметь несколько ролей.
• Одну роль могут иметь несколько субъектов.
• Одна роль может иметь несколько разрешений.
• Одно разрешение может принадлежать нескольким ролям.

Роли назначаются субъектам, вследствие чего субъекты получают те или иные разрешения через роли. RBAC требует именно такого назначения, а не прямого - назначение разрешений субъектам, иначе это приводит к сложно контролируемым отношениям между субъектами и разрешениями^[3].

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

Используя нотацию теории множеств:

• ${\displaystyle PA\subseteq P\times R}$, при этом разрешения назначаются связям ролей в отношении «многие ко многим».
• ${\displaystyle SA\subseteq S\times R}$, при этом субъекты назначаются связям ролей и субъектов в отношении «многие ко многим».
• ${\displaystyle RH\subseteq R\times R}$

Обозначение: x ≥ y означает, что x наследует разрешения y.

Субъект может иметь множество одновременных сессий с различными разрешениями.

Технология управления доступом на основе ролей достаточно гибка и сильна, чтобы смоделировать как избирательное управление доступом (DAC)^[4], так и мандатное управление доступом (MAC)^[5]

До разработки RBAC, единственными известными моделями управления доступом были MAC и DAC. Исследования в 90-х показали, что RBAC не попадает ни в ту, ни в другую категорию.

Роли создаются внутри организации для различных рабочих функций. Определённым ролям присваиваются полномочия (permissions) для выполнения тех или иных операций. Штатным сотрудникам (или другим пользователям системы) назначаются фиксированные роли, через которые они получают соответствующие привилегии для выполнения фиксированных системных функций. В отличие от управления доступом на основе контекста (англ. context-based access control, CBAC), реализация RBAC в чистом виде не принимает во внимание текущую ситуацию (такую как, например, откуда было установлено соединение).

RBAC отличается от списков контроля доступа (англ. access control lists, ACL), используемых в традиционных избирательных системах управления доступом, тем, что может давать привилегии на сложные операции с составными данными, а не только на атомарные операции с низкоуровневыми объектами данных. Например, список контроля доступа может предоставить или лишить права записи в такой-то системный файл, но он не может ограничить то, каким образом этот файл может быть изменен. Система, основанная на RBAC, позволяет создать такую операцию как открытие «кредита» в финансовом приложении или заполнение записи «тест на уровень сахара в крови» в медицинском приложении. Присвоение привилегии на выполнение какой-либо операции многозначно, так как операции являются дробящимися в пределах приложения.

Концепции иерархии ролей и ограничений позволяют создать или смоделировать контроль доступа на основе решетки (англ. lattice-based access control, LBAC) средствами RBAC. Таким образом, RBAC может быть основанием и расширением LBAC.

В организациях с разнородной IT-инфраструктурой, содержащих десятки и сотни систем и приложений, помогает использование иерархии ролей и наследования привилегий. Без этого использование RBAC становится крайне запутанным. В статье «Дополнительные роли: практический подход к обслуживанию пользователей предприятия»^[6] обсуждаются стратегии, альтернативные большому масштабу присвоения привилегий пользователям.

Современные системы расширяют старую модель NIST^[7] ограничениями RBAC для развертывания на больших предприятиях.

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

RBAC широко используется для управления пользовательскими привилегиями в пределах единой системы или приложения. Список таких систем включает в себя Microsoft Active Directory, SELinux, FreeBSD, Solaris, СУБД Oracle, PostgreSQL 8.1, SAP R/3, Lotus Notes и множество других.

• Информационная безопасность
• Проверка подлинности

• FAQ on RBAC models and standards (англ.)
• Role Based Access Controls at NIST (англ.)
• XACML core and hierarchical role based access control profile (англ.) — OASIS XACML-стандарт
• Подходы к контролю доступа: RBAC vs. ABAC  (рус.) — Сравнение управления доступом на основе ролей и управления доступом на основе атрибутов.