Иерархический RBAC

Иерархический RBAC (англ. Hierarchical Role-Based Access Control, иерархическое управление доступом на основе ролей) — это расширение модели управления доступом на основе ролей (RBAC), в котором роли могут быть организованы в иерархическую структуру, наследуя права доступа от вышестоящих ролей. В отличие от плоского RBAC, где каждая роль определяется независимо, иерархический RBAC позволяет задавать отношения «родитель-потомок», где роль-потомок автоматически получает все разрешения роли-родителя, а также может иметь собственные уникальные разрешения. Данная модель широко применяется в корпоративных информационных системах, базах данных, операционных системах и облачных платформах для упрощения администрирования прав доступа и снижения вероятности ошибок при назначении полномочий.

История

Концепция RBAC была формализована в начале 1990-х годов, в частности, в работах Дэвида Феррайоло и Ричарда Куна (Национальный институт стандартов и технологий США, NIST). Первоначальные модели (плоский RBAC) предполагали, что каждая роль является независимой сущностью, а пользователю могут быть назначены несколько ролей. Однако на практике в крупных организациях (например, в банках или государственных учреждениях) роли часто имеют иерархическую природу: должность «старшего инженера» включает в себя права «инженера», а «руководитель отдела» — права «старшего инженера».

В 2000 году NIST опубликовал стандарт INCITS 359-2004 (ANSI), который определил четыре уровня RBAC, включая иерархический RBAC (уровень 2). Этот стандарт стал основой для реализации модели во многих коммерческих и открытых системах, таких как Microsoft Active Directory, Oracle Database, PostgreSQL, Apache Hadoop и Kubernetes.

Основные понятия

Модель иерархического RBAC опирается на следующие ключевые сущности:

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

Отношение наследования обычно обозначается как «роль A является родителем роли B» (или «роль B является потомком роли A»). Если роль B наследует от роли A, то все разрешения, назначенные роли A, автоматически становятся доступными для роли B. При этом роль B может иметь дополнительные разрешения, не свойственные родителю.

Типы иерархий

Иерархии ролей могут быть реализованы двумя основными способами:

1. Общая иерархия (General Hierarchy)

Роль может иметь несколько родителей и несколько потомков (множественное наследование). Например, роль «главный бухгалтер» может наследовать права от ролей «бухгалтер» и «финансовый аналитик». Такая иерархия наиболее гибкая, но требует осторожности при проектировании, чтобы избежать коллизий разрешений.

2. Ограниченная иерархия (Limited Hierarchy)

Каждая роль имеет не более одного родителя (одиночное наследование). Это упрощает администрирование и снижает риск циклических зависимостей. Чаще всего используется в системах с жёсткой организационной структурой (например, в государственных информационных системах).

Свойства иерархического RBAC

• Наследование разрешений — автоматическая передача прав от родительской роли к дочерней.
• Транзитивность — если роль C наследует от роли B, а роль B наследует от роли A, то роль C получает все разрешения роли A.
• Антисимметричность — если роль A является родителем роли B, то роль B не может быть родителем роли A (отсутствие циклов).
• Переопределение разрешений — в некоторых реализациях дочерняя роль может отменять или ограничивать разрешения родителя (например, «запрет на удаление» при наследовании «полного доступа»).

Преимущества

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

Недостатки и ограничения

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

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

Корпоративные системы

В Microsoft Active Directory (начиная с Windows Server 2003) реализована иерархическая модель групп безопасности, где группы могут быть вложены друг в друга. Например, группа «Domain Admins» является родительской для группы «Enterprise Admins» (в определённых конфигурациях).

Базы данных

В СУБД PostgreSQL (начиная с версии 14) поддерживается иерархия ролей через использование предложения INHERIT. Роль может наследовать разрешения от одной или нескольких родительских ролей. Например: ``sql CREATE ROLE employee; CREATE ROLE manager INHERIT; GRANT employee TO manager; ` В этом случае роль manager автоматически получает все права, назначенные роли employee`.

Облачные платформы

В Kubernetes (система оркестрации контейнеров) RBAC реализован с поддержкой иерархии через агрегацию ClusterRole. Роль cluster-admin может быть родительской для роли admin, которая, в свою очередь, наследует права от роли edit.

Критика и альтернативы

Иерархический RBAC критикуется за недостаточную гибкость в современных распределённых и микросервисных архитектурах. В таких системах часто применяется атрибутный контроль доступа (ABAC), где решения о доступе принимаются на основе атрибутов субъекта, объекта и окружения, а не только на основе ролей. Также существует политико-ориентированный контроль доступа (PBAC), который позволяет описывать сложные правила доступа в декларативном виде (например, на языке XACML). Однако иерархический RBAC остаётся стандартом де-факто для большинства корпоративных приложений благодаря своей простоте и предсказуемости.

Источники

• Ferraiolo D. F., Kuhn D. R. Role-Based Access Controls // Proceedings of the 15th National Computer Security Conference. — 1992.
• ANSI INCITS 359-2004. Information Technology — Role Based Access Control. — American National Standards Institute, 2004.
• Sandhu R., Coyne E. J., Feinstein H. L., Youman C. E. Role-Based Access Control Models // IEEE Computer. — 1996. — Vol. 29, No. 2.
• PostgreSQL Documentation. Chapter 21. Database Roles and Privileges. — The PostgreSQL Global Development Group, 2023.
• Kubernetes Documentation. Using RBAC Authorization. — The Kubernetes Authors, 2024.