Контроль доступа на основе ролей

Введение

Управление доступом на основе ролей (англ. 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, Безопасное Вычисление,
• 1997 — Безопасное Вычисление включает модель Ферраильо-Куна RBAC в американскую Глобальную Команду DoD и Систему управления; выходит статья Куна на тему разделения обязанностей, необходимых и достаточных условий для безопасности разделения;
• 1997 — статья Осборна основанная на отношениях между RBAC и многоуровневой безопасностью мандатной модели политики безопасности; аннотация роли, связывающая RBAC и многоуровневую безопасность
• 1998 — RBAC — метод Куна для того, чтобы осуществить RBAC на системе МАС;
• 1999 — Барклей (англ. Barkley), Ферраильо, Кун открывают исходный опытный образец RBAC для развитых веб-серверов;
• 2000 — Санди, Ферраильо, Кун публикуют статью, определяющую объединенную модели RBAC, и предлагают стандарт RBAC;
• 2004 — Американский Национальный Институт Стандартов, Международный Комитет по Стандартам Информационной технологии (ANSI/INCITS) принимает предложенную Санди, Ферраильо и Куном модель RBAC как единый стандарт.

Базовая модель RBAC

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

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

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

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

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

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

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

Возможности и применение

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

До разработки RBAC, единственными известными моделями управления доступом были MAC и DAC: если модель была не 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 становится крайне запутанным. В статье «Дополнительные роли: практический подход к обслуживанию пользователей предприятия»^[5] обсуждаются стратегии, альтернативные большому масштабу присвоения привилегий пользователям.

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

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

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

Примечания

1. ↑ Ferraiolo D. F., Kuhn D. R. (October 1992). "Role Based Access Control" (15th National Computer Security Conference: 554—563. 
2. ↑ Sandhu R., Coyne E. J., Feinstein H. L., Youman C. E. (August 1996). "Role-Based Access Control Models" (IEEE Computer 29 (2): 38–47.
3. ↑ .Ravi Sandhu, Qamar Munawer (October 1998). "How to do discretionary access control using roles". 3rd ACM Workshop on Role-Based Access Control: 47—54. 
4. ↑ Sylvia Osborn, Ravi Sandhu, Qamar Munawer (2000). "Configuring role-based access control to enforce mandatory and discretionary access control policies". ACM Transactions on Information and System Security (TISSEC): 85—106. 
5. ↑ Beyond Roles: A Practical Approach to Enterprise User Provisioning
6. ↑ Sandhu R., Ferraiolo D.F. and Kuhn D.R. (July 2000). "The NIST Model for Role Based Access Control: Toward a Unified Standard". 5th ACM Workshop Role-Based Access Control: 47—63. 

См. также

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

Ссылки

• FAQ on RBAC models and standards
• Role Based Access Controls at NIST
• XACML core and hierarchical role based access control profile — OASIS XACML-стандарт