Ролевое управление доступом (RBAC)

Ключевая косвенность

Вся идея RBAC — один слой косвенности: вместо выдачи разрешений напрямую пользователям, вы выдаёте разрешения ролям, а пользователей назначаете на роли. Разрешение — это одно допустимое действие над типом ресурса: invoice:read, user:delete, report:export. Роль — именованный набор разрешений: accountant может объединять invoice:read, invoice:create, report:export. Пользователь получает одну или несколько ролей. Тогда авторизация сводится к вопросу, на который отвечает join по базе данных: содержит ли хоть одна роль этого пользователя то разрешение, которое требует запрос?

Выигрыш реален, и поэтому RBAC — выбор по умолчанию для большинства корпоративных систем. Логика выдачи живёт в одном месте на роль, а не размазана по каждому пользователю. Когда бухгалтерия получает право экспортировать новый тип отчёта, вы один раз добавляете report:export-tax в роль accountant, и сорок бухгалтеров наследуют это атомарно — никакого обновления сорока строк, никакого дрейфа, где про 23-го сотрудника забыли. Онбординг становится «назначить роль accountant» вместо «восстановить, что бухгалтеру вообще разрешено». Аудит становится «перечислить, кто держит admin» вместо обхода таблиц выдач по каждому пользователю. Отображение бизнес-языка («она менеджер») в принуждение («она может одобрять возвраты до $5k») явно и проверяемо.

Где модель окупается — и её пределы

RBAC блистает, когда авторизация действительно отслеживает организационную структуру: стабильные рабочие функции, их обозримое число и разрешения, чисто группирующиеся по функции. Больница, где каждый клиницист с ролью attending может делать ровно один и тот же набор вещей, — родная стихия RBAC. NIST формализовал это в модели, ставшей стандартом ANSI INCITS 359, включая иерархии ролей (роль senior-editor наследует все разрешения editor плюс несколько) и статическое разделение обязанностей — ограничения, запрещающие одному пользователю держать две конфликтующие роли, например никто не может быть одновременно payment-initiator и payment-approver, так что ни один человек не проведёт деньги от начала до конца в одиночку.

Эта возможность разделения обязанностей — не сноска, а зачастую причина, по которой организация вообще принимает RBAC. Sarbanes-Oxley, PCI-DSS и большинство финансовых контролей строятся на посылке, что чувствительные действия требуют двух разных людей. RBAC кодирует это напрямую как ограничение между ролями, и аудитор может проверить его, осмотрев назначения ролей, а не прослеживая каждую транзакцию.

Взрыв ролей: комбинаторный сбой

Вот механизм, и важно, что он комбинаторный, а не линейный. У RBAC ровно одно измерение вариативности — роль. Любое правило авторизации, которое вы хотите выразить, приходится сворачивать в то, какую роль держит пользователь. Пока ваши правила про «какую работу ты делаешь», всё в порядке. Беда начинается в тот момент, когда правило зависит от чего-то, что не является работой, — от региона (данные ЕС против США), атрибута ресурса (только свой отдел), окружения (prod против staging), области видимости (вот этот один проект). RBAC не может сказать «editor, но только для записей ЕС». Он может лишь отчеканить новую роль: editor-eu.

Теперь усложните. Добавьте исключение «без удаления»: нужны editor-eu, editor-eu-no-delete, editor-no-delete. Добавьте три отдела, два существующих региона и флаг удаления: это потенциально 3 × 2 × 2 = 12 ролей, чтобы выразить то, что на самом деле — одна роль плюс три независимых атрибута. Каждое новое ортогональное измерение умножает число ролей, а не прибавляет к нему. Реальные системы рутинно переваливают за 1000 ролей на несколько тысяч пользователей; в этой точке таблица ролей уже не абстракция — это денормализованный кэш пользовательской политики с интерфейсом хуже того, что он заменил. Ревью становятся бессмысленными, потому что ни один человек не удержит 1000 определений ролей в голове, а избыточная выдача прав подкрадывается, потому что путь наименьшего сопротивления — выдать чуть слишком мощную существующую роль, а не чеканить ещё одну точную.

Когда роли перестают масштабироваться — и что делает зрелый инженер

Зрелое суждение — распознать взрыв рано, пока таблица ролей не окаменела. Признак прост: когда имена ролей начинают нести атрибуты (-eu, -no-delete, -readonly, -projectX), ваши правила авторизации переросли одно измерение. Дисциплинированные ответы, грубо по порядку: держите роли строго про рабочую функцию и сдвиньте контекстную часть решения (принадлежит ли запись отделу вызывающего? это ли тенант ЕС?) в проверку авторизации приложения как ограниченное условие — роль даёт edit И record.region == user.region. Этот гибрид сохраняет проверяемые грубые выдачи RBAC, позволяя небольшому набору проверок отношений/атрибутов справляться с разрастанием. Полное обобщение — ABAC, где политика есть функция от атрибутов субъекта, ресурса, действия и окружения, но это более тяжёлый движок, и большинство команд сначала тянется к гибриду, потому что чистый RBAC — всё ещё самое аудируемое, что можно вручить ревьюеру комплаенса.