Ограниченный RBAC

Ограниченный RBAC — это модель управления доступом на основе ролей (Role-Based Access Control, RBAC), реализованная с дополнительными ограничениями, сужающими область применения ролей по сравнению с классической моделью RBAC. В отличие от стандартного RBAC, где доступ к ресурсам определяется исключительно ролями пользователя, ограниченный RBAC вводит дополнительные условия: контекстные, временные, пространственные или атрибутивные. Такая модель используется в системах, где требуется более тонкое разграничение прав без перехода к более сложным моделям, таким как ABAC (Attribute-Based Access Control) или PBAC (Policy-Based Access Control).

История и предпосылки появления

Классическая модель RBAC была формализована в 1992 году Дэвидом Феррайоло и Ричардом Куном (Национальный институт стандартов и технологий США, NIST). Стандарт NIST RBAC (ANSI INCITS 359-2004) описывает четыре уровня: плоский, иерархический, ограниченный и симметричный. Ограниченный RBAC (constrained RBAC) в этой классификации представляет собой расширение иерархического RBAC, вводящее ограничения на назначение ролей и их использование.

Предпосылками появления ограниченного RBAC стали:

• Необходимость предотвращения конфликта интересов (например, один сотрудник не может быть одновременно и заказчиком, и исполнителем одной закупки).
• Требования регуляторов в финансовом, медицинском и государственном секторах (например, закон Сарбейнса-Оксли в США, 152-ФЗ в РФ о персональных данных).
• Ограниченность классического RBAC в условиях динамических бизнес-процессов.

Классификация ограниченного RBAC

В рамках стандарта NIST выделяют три основных типа ограничений:

Статические ограничения (Static Separation of Duty, SSD)

Запрещают одному пользователю одновременно иметь две или более ролей, которые считаются конфликтующими. Например, в банковской системе роли «Операционист» и «Контролёр» не могут быть назначены одному сотруднику. SSD задаётся на этапе назначения ролей (администратором).

Динамические ограничения (Dynamic Separation of Duty, DSD)

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

Ограничения по числу пользователей (Cardinality constraints)

Ограничивают максимальное количество пользователей, которым может быть назначена конкретная роль. Например, роль «Главный бухгалтер» может быть назначена не более чем одному сотруднику.

Механизмы реализации

Ограниченный RBAC реализуется через:

• Политики разделения обязанностей (SoD) — формальные правила, описывающие конфликтующие пары ролей.
• Контекстные фильтры — условия, при которых роль активируется (например, только из корпоративной сети, только в рабочее время, только для определённых IP-адресов).
• Временные ограничения — роли могут быть активны только в заданные временные интервалы (например, с 9:00 до 18:00).
• Атрибуты сессии — в момент входа в систему пользователь выбирает, какие из назначенных ему ролей активировать, при этом система проверяет отсутствие конфликтов.

Отличия от классического RBAC

Применение

Ограниченный RBAC широко используется в:

• Финансовом секторе — для предотвращения мошенничества (например, один сотрудник не может и создавать платёж, и подтверждать его).
• Государственных информационных системах — в России требования к разграничению доступа в государственных информационных системах (ГИС) часто включают элементы ограниченного RBAC (постановление Правительства РФ № 1119 о требованиях к защите персональных данных).
• Медицинских информационных системах — для разделения ролей врача, медсестры и администратора, а также для контроля доступа к разным категориям медицинских записей.
• Корпоративных ERP-системах (SAP, 1С) — где реализованы механизмы разделения обязанностей (SoD) и конфликтующие роли блокируются на уровне назначений.

Пример реализации

В системе управления закупками крупной компании определены роли:

• «Инициатор закупки» — может создать заявку.
• «Согласующий» — может одобрить заявку.
• «Закупщик» — может разместить заказ поставщику.

Ограниченный RBAC вводит SSD-правило: роли «Инициатор» и «Согласующий» не могут быть назначены одному сотруднику. DSD-правило: если сотрудник имеет роли «Согласующий» и «Закупщик», он не может одновременно согласовывать и размещать заказ по одной и той же заявке. Cardinality-ограничение: роль «Главный закупщик» может быть назначена не более чем двум сотрудникам.

Критика и ограничения

Основные недостатки ограниченного RBAC:

• Сложность администрирования — при большом числе ролей и правил SoD управление становится трудоёмким.
• Негибкость — ограничения жёстко заданы на этапе проектирования, что затрудняет адаптацию к изменяющимся бизнес-процессам.
• Отсутствие учёта атрибутов объекта — в отличие от ABAC, ограниченный RBAC не позволяет разграничивать доступ к разным экземплярам одного типа ресурса (например, «доступ к документам только своего отдела» требует дополнительных механизмов).
• Риск избыточных ограничений — чрезмерное разделение обязанностей может парализовать работу, если не предусмотрены временные замещения.

Связь с другими моделями

Ограниченный RBAC часто комбинируется с:

• ABAC — для учёта атрибутов пользователя, ресурса и окружения.
• PBAC — для централизованного управления политиками.
• RBAC с наследованием — для построения иерархий ролей с учётом ограничений.

В современных системах (например, Azure RBAC, AWS IAM) ограниченный RBAC реализуется как часть более широкого набора механизмов управления доступом, где статические и динамические ограничения задаются через политики.

Источники

• Ferraiolo, D. F., & Kuhn, D. R. (1992). Role-Based Access Controls. Proceedings of the 15th National Computer Security Conference.
• Sandhu, R., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-Based Access Control Models. IEEE Computer, 29(2).
• ANSI INCITS 359-2004. Information Technology — Role Based Access Control.
• Постановление Правительства РФ от 1 ноября 2012 г. № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных».
• Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных».