Управление доступом часто начинается с понятной модели: администратор может всё, менеджер — часть операций, сотрудник — ещё меньше.
Проблема появляется, когда бизнес добавляет исключения. Менеджер может видеть данные только своего региона. Партнёр — только своих клиентов. Сотрудник поддержки — только определённые категории данных и только во время работы с обращением.
Какую проблему мы решаем
RBAC — role-based access control — назначает права через роли. ABAC — attribute-based access control — принимает решение по атрибутам пользователя, ресурса, действия и контекста.
Это не соревнование двух технологий. Вопрос в том, насколько сложные правила доступа реально нужны бизнесу.
Что получает бизнес
RBAC даёт простоту. Роли легко объяснить, согласовать и проверить. Для многих организаций этого достаточно.
ABAC даёт более точный контроль там, где правила действительно зависят от контекста. Компания может выразить политику ближе к реальному бизнес-правилу, не создавая сотни комбинированных ролей.
Это особенно важно, когда цена ошибочного доступа высока: лишние данные могут увидеть не те люди, партнёры или подразделения.
Что получает команда
С RBAC команда получает относительно простую модель прав и понятные проверки.
С ABAC появляется мощный механизм политик, но возрастает сложность тестирования. Нужно понимать, какие атрибуты участвуют в решении, откуда они приходят и что произойдёт, если один из них отсутствует или устарел.
Что получает клиент
Клиент получает более точное разделение данных и функций. Пользователь видит только то, что относится к его роли, компании, региону или конкретному объекту.
Но слишком сложные правила могут приводить к непредсказуемым отказам: вчера доступ был, сегодня исчез, а объяснить причину трудно.
Чем мы за это платим
Цена RBAC — рост числа ролей при сложных комбинациях правил. Возникают роли вроде «менеджер региона X для продукта Y с правом Z», и модель начинает разваливаться.
Цена ABAC — сложность политик, данных и аудита. Гибкое правило труднее прочитать глазами и труднее доказать, почему конкретный пользователь получил или не получил доступ.
Когда ABAC не нужен
Если правила хорошо укладываются в десяток устойчивых ролей, переход к атрибутам может только усложнить систему.
Часто разумна гибридная модель: роли задают базовый уровень доступа, а атрибуты уточняют отдельные чувствительные сценарии.
Что стоит спросить перед решением
- Сколько ролей у нас уже есть и почему их становится больше?
- Зависит ли доступ от контекста или только от должности?
- Можем ли мы объяснить решение системы аудитору и пользователю?
- Насколько надёжны атрибуты, на которых строятся политики?
- Где простота важнее точности, а где наоборот?
В итоге
RBAC выигрывает простотой, ABAC — выразительностью. Более гибкая модель не является автоматически более зрелой.
Правильная модель доступа — та, которая выражает реальные бизнес-ограничения без такой сложности, что сама политика становится новым риском.