Открыть сервис
Главная → Блог → RBAC

RBAC

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

Основные принципы и концепции

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

Ключевой принцип RBAC — разделение обязанностей (Separation of Duties, SoD). Он предотвращает конфликт интересов, требуя, чтобы критически важные операции выполнялись несколькими пользователями с разными ролями. Например, один пользователь не может одновременно иметь роль «Бухгалтер» и роль «Аудитор» в финансовой системе.

Второй важный принцип — минимальные привилегии (Least Privilege). Каждой роли назначается ровно тот набор разрешений, который необходим для выполнения её задач, и не более. Пользователь, в свою очередь, получает только те роли, которые нужны ему для работы.

Базовые элементы модели

Стандарт RBAC (ANSI INCITS 359-2004, NIST SP 800-53) определяет следующие ключевые элементы:

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

История и стандартизация

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

В 2004 году ANSI (Американский национальный институт стандартов) принял стандарт INCITS 359-2004, описывающий четыре уровня RBAC:

Стандарт NIST SP 800-53 (контроль доступа) рекомендует использование RBAC как один из основных методов реализации политики безопасности в государственных информационных системах США. В России аналогичные требования содержатся в документах ФСТЭК России (например, в требованиях к системам защиты информации для государственных информационных систем).

Виды и реализации RBAC

Плоский RBAC

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

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

Роли могут быть организованы в древовидную или частично упорядоченную структуру. Дочерняя роль наследует все разрешения родительской. Например, роль «Старший инженер» может включать все разрешения роли «Инженер» плюс дополнительные. Это упрощает администрирование в крупных организациях.

Ограниченный RBAC (с разделением обязанностей)

Вводит статические и динамические ограничения. Статические ограничения (SSD — Static Separation of Duty) запрещают одному пользователю иметь две конфликтующие роли одновременно. Динамические ограничения (DSD — Dynamic Separation of Duty) разрешают иметь обе роли, но не активировать их в одной сессии.

Реализации в программном обеспечении

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

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

Недостатки

Сравнение с другими моделями

RBAC vs DAC (Discretionary Access Control)

В DAC владелец объекта сам решает, кому предоставить доступ. RBAC централизованно управляется администратором. RBAC безопаснее для корпоративных сред, DAC удобнее для персональных устройств.

RBAC vs MAC (Mandatory Access Control)

MAC основан на метках безопасности (уровни секретности) и жёсткой политике, не зависящей от пользователя. RBAC гибче, но требует большего контроля за назначением ролей. MAC применяется в военных и государственных системах, RBAC — в коммерческих.

RBAC vs ABAC (Attribute-Based Access Control)

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

Применение в России

В российских организациях RBAC широко используется в государственных информационных системах (ГИС), в том числе в системах электронного документооборота, бухгалтерского учёта и управления персоналом. Требования к RBAC содержатся в методических документах ФСТЭК России (например, «Меры защиты информации в государственных информационных системах»). Ряд российских разработчиков программного обеспечения (1С, «Лаборатория Касперского», «Код Безопасности») реализуют RBAC в своих продуктах.

В банковском секторе RBAC обязателен для соблюдения стандарта Банка России СТО БР ИББС-1.0-2014, который предписывает разграничение доступа на основе ролей и разделение обязанностей. В медицинских информационных системах RBAC применяется для обеспечения конфиденциальности персональных данных пациентов (ФЗ-152 «О персональных данных»).

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

Основная критика RBAC связана с его статичностью. В современных динамических средах, где права доступа должны меняться в зависимости от контекста (например, доступ к данным только в рабочее время или только с определённого IP-адреса), RBAC требует дополнительных надстроек. Кроме того, при большом количестве ролей (сотни и тысячи) управление ими становится трудоёмким, что приводит к появлению «ролевого хаоса» — когда роли дублируются или конфликтуют.

Также отмечается, что RBAC не решает проблему атак, связанных с кражей учётных данных пользователя с высокой ролью. Если злоумышленник получает доступ к аккаунту администратора, он автоматически получает все его полномочия. Для снижения этого риска применяются дополнительные механизмы: многофакторная аутентификация, мониторинг сессий, временные повышения привилегий (Just-In-Time access).

Перспективы развития

Современные тенденции в управлении доступом направлены на интеграцию RBAC с другими моделями. Например, в облачных платформах (AWS, Azure) используется RBAC как базовая модель, дополненная атрибутивными политиками (ABAC) для тонкой настройки. Развивается подход Policy-Based Access Control (PBAC), где политики задаются на естественном языке и автоматически транслируются в RBAC-структуры.

В области DevOps и контейнеризации RBAC адаптируется для управления доступом к кластерам Kubernetes (Role-Based Access Control в Kubernetes), где роли и разрешения назначаются как пользователям, так и сервисным аккаунтам.

Источники

  1. Ferraiolo D.F., Kuhn D.R. Role-Based Access Controls // Proceedings of the 15th National Computer Security Conference. — 1992. — P. 554–563.
  2. ANSI INCITS 359-2004. Information Technology — Role Based Access Control. — American National Standards Institute, 2004.
  3. NIST Special Publication 800-53 Rev. 5. Security and Privacy Controls for Information Systems and Organizations. — National Institute of Standards and Technology, 2020.
  4. Sandhu R., Coyne E.J., Feinstein H.L., Youman C.E. Role-Based Access Control Models // IEEE Computer. — 1996. — Vol. 29, № 2. — P. 38–47.
  5. ФСТЭК России. Методический документ «Меры защиты информации в государственных информационных системах». — 2014.
  6. Банк России. Стандарт СТО БР ИББС-1.0-2014. Обеспечение информационной безопасности организаций банковской системы Российской Федерации. — 2014.
  7. Документация Kubernetes. RBAC Authorization. — Kubernetes.io, 2023.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы