Плоский RBAC

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

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

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

Плоский RBAC возник как ответ на эти сложности. Впервые термин «плоский RBAC» (Flat RBAC) был предложен в 2000-х годах в контексте разработки систем управления идентификацией (IAM) для облачных платформ и корпоративных приложений. Основным стимулом стало стремление к предсказуемости и простоте аудита: в плоской модели каждое разрешение явно привязано к конкретной роли, и администратору не нужно отслеживать цепочки наследования.

Основные принципы и архитектура

Определение ролей и разрешений

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

Отсутствие наследования

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

Управление сессиями

В плоском RBAC сессии пользователя могут активировать только те роли, которые были явно назначены. При этом пользователь может выбрать, какие из доступных ролей активировать в данный момент, что позволяет гибко ограничивать привилегии в рамках одного сеанса работы. Однако в отличие от динамического RBAC, в плоской модели нет механизмов автоматической активации ролей на основе контекста (например, времени суток или местоположения).

Сравнение с иерархическим RBAC

Применение

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

Плоский RBAC широко используется в облачных сервисах, таких как Amazon Web Services (AWS) и Google Cloud Platform (GCP). В AWS, например, политики доступа (IAM Policies) привязываются к ролям, которые не имеют иерархии. Пользователь может иметь несколько ролей, но каждая из них определяет строго ограниченный набор действий. Это позволяет реализовать принцип наименьших привилегий (least privilege) и упрощает аудит безопасности.

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

В небольших и средних компаниях, где количество ролей не превышает 10–15, плоский RBAC часто оказывается более эффективным, чем иерархический. Например, в системах управления проектами (Trello, Jira) или CRM (Salesforce) роли «Администратор», «Менеджер», «Разработчик» и «Тестировщик» могут быть независимыми, и каждому пользователю назначается одна или несколько из них. Это исключает путаницу при наследовании и ускоряет onboarding новых сотрудников.

Системы с высокими требованиями к безопасности

В финансовых и государственных учреждениях, где требуется строгий контроль доступа, плоский RBAC позволяет минимизировать риски. Например, в банковских системах роли «Кассир», «Операционист» и «Руководитель отделения» не должны наследовать права друг друга. Если бы существовала иерархия, то кассир мог бы получить доступ к операциям, не предусмотренным его должностными обязанностями, из-за ошибки в настройке родительской роли.

Мобильные приложения и IoT

В мобильных приложениях и системах Интернета вещей (IoT) плоский RBAC часто применяется из-за ограниченных вычислительных ресурсов. Например, в умных домах роли «Владелец», «Гость» и «Администратор» могут быть независимыми, и каждое устройство проверяет разрешения без необходимости обращаться к иерархической базе данных.

Преимущества и недостатки

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

• Простота администрирования. Администратору не нужно отслеживать цепочки наследования, что снижает вероятность ошибок.
• Предсказуемость полномочий. Каждое разрешение явно привязано к роли, что упрощает аудит и соответствие нормативным требованиям (например, GDPR, Федеральный закон «О персональных данных» № 152-ФЗ).
• Минимизация риска эскалации привилегий. Изменение одной роли не влияет на другие, что особенно важно в системах с высокими требованиями к безопасности.
• Лёгкость отладки. При возникновении инцидента безопасности можно быстро определить, какие роли были назначены пользователю, и какие разрешения они предоставляли.

Недостатки

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

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

Плоский RBAC критикуется за неэффективность в крупных системах с большим количеством ролей. Например, в корпорациях с тысячами сотрудников и десятками отделов создание независимых ролей для каждого сочетания полномочий приводит к «взрывному» росту их числа. В таких случаях предпочтительнее использовать иерархический RBAC или атрибутивный контроль доступа (ABAC), где разрешения вычисляются на основе атрибутов пользователя, ресурса и окружения.

Кроме того, плоский RBAC не поддерживает динамическое изменение полномочий в зависимости от контекста (например, времени суток или местоположения). Для этого применяются расширения, такие как Context-Aware RBAC или Relationship-Based Access Control (ReBAC).

Интересные факты

• В стандарте ANSI INCITS 359-2004 плоский RBAC соответствует уровню RBAC0, который является базовым и не включает иерархию или ограничения.
• В 2020 году компания Google опубликовала исследование, согласно которому около 60% инцидентов безопасности в облачных средах были связаны с неправильной настройкой иерархических ролей. В ответ на это Google рекомендовала использовать плоский RBAC для критически важных систем.
• В России плоский RBAC применяется в государственных информационных системах, таких как Единая система идентификации и аутентификации (ЕСИА) и Система межведомственного электронного взаимодействия (СМЭВ), где требуется строгий контроль доступа к персональным данным.

Источники

• Ferraiolo, D. F., & Kuhn, D. R. (1992). Role-Based Access Controls. Proceedings of the 15th National Computer Security Conference.
• ANSI INCITS 359-2004. Role Based Access Control.
• Sandhu, R., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-Based Access Control Models. IEEE Computer, 29(2), 38–47.
• Google Cloud. (2020). Best Practices for IAM Roles. Google Cloud Documentation.
• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».