Ролевая модель доступа (RBAC).

Ролевая модель доступа назначает права абстрактным ролям (например, «администратор биллинга» или «аудитор только для чтения») и предоставляет доступ, добавляя пользователей в эти роли. Такая косвенность упрощает администрирование, поддерживает разделение обязанностей и облегчает аудит, поскольку права документируются по ролям, а не по пользователям. RBAC — доминирующая модель в корпоративном IAM, облачных платформах (AWS IAM, Azure RBAC, Kubernetes RBAC) и ERP-системах.

RBAC была формализована Дэвидом Ферраиоло и Риком Куном из NIST в статье 1992 года «Role-Based Access Controls», затем объединена с моделью Сандху и стандартизирована как ANSI/INCITS 359-2004 (пересмотрена как INCITS 359-2012). Стандарт определяет четыре кумулятивных компонента: базовый RBAC (пользователи–роли–права), иерархический RBAC (роли наследуются от вышестоящих) и две формы ограниченного RBAC — статическое и динамическое разделение обязанностей (SSD/DSD), которые блокируют опасные сочетания прав, например когда один пользователь и создаёт, и утверждает платёж.

Главная слабость — взрывной рост ролей: в крупных организациях кодирование каждой тонкой бизнес-потребности отдельной ролью порождает тысячи почти одинаковых, неуправляемых ролей. Это подталкивает к гибридным решениям ABAC/RBAC, где роли задают грубую основу, а атрибуты (отдел, время, тег ресурса) уточняют каждое решение — принцип, лежащий в основе ключей условий AWS IAM и модели RBAC-плюс-admission-webhook в Kubernetes.

flowchart LR
  U["Пользователь: Алиса"] -->|назначена в| R1["Роль: администратор биллинга"]
  U -->|назначена в| R2["Роль: аудитор"]
  R1 -->|наследует| R3["Роль: читатель биллинга"]
  R1 -->|даёт| P1["Право: создать счёт"]
  R3 -->|даёт| P2["Право: читать счёт"]
  R2 -->|даёт| P3["Право: экспорт журналов"]
  P1 --> RES[("Система биллинга")]
  P2 --> RES
  P3 --> RES
  SSD["Ограничение SSD:<br/>нельзя быть и создателем, и утверждающим"] -. блокирует .-> R1