RBAC vs ABAC: выбор модели доступа для бизнес-приложения

Зачем вообще выбирать модель доступа

Почти в любом бизнес-приложении доступ сначала выглядит простым: админ, менеджер, пользователь. Но как только появляются новые сотрудники, функции и ограничения (разные филиалы, тарифы, уровни поддержки), права начинают расползаться. Кому-то «временно» дают доступ, чтобы закрыть задачу, а потом забывают отозвать.

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

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

Выбор между RBAC vs ABAC имеет смысл, когда вы хотите заранее ограничить хаос. Особенно если продукт развивается быстро и новые модули появляются каждые недели: в таких условиях «временные» решения закрепляются моментально.

Признаки, что текущая схема уже не подходит:

• Ролей стало много, и никто не может объяснить разницу между «Менеджер 2» и «Менеджер расширенный».
• Чтобы выдать доступ, нужно ручное исключение или просьба «сделайте как у Пети».
• Появились филиалы, проекты, тарифы или регионы, а права по ним не разделены.
• Аудит или разбор инцидента занимает дни, потому что непонятно, откуда у человека право.
• Новая фича требует «еще одной роли», и это стало привычным решением.

Если узнаете хотя бы два пункта, стоит остановиться и выбрать модель доступа осознанно, пока изменения еще можно контролировать.

RBAC и ABAC без теории: в чем разница

RBAC vs ABAC проще всего понять через один вопрос: вы управляете доступом через «кто ты» или через «в какой ситуации ты сейчас».

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

ABAC (Attribute-Based Access Control) - это правила на основе атрибутов и контекста. Решение принимает не одна роль, а условия: атрибуты пользователя (отдел, регион, уровень), атрибуты объекта (владелец, статус, тип документа) и контекст (время, канал, среда). Примеры: «сотрудник видит только заявки своего региона» или «редактировать можно только черновики, созданные тобой».

Где обычно выигрывает RBAC: старт проекта, небольшой бизнес, понятная оргструктура. Его легко объяснить команде, можно проверить «глазами», удобно вести в админке.

Где RBAC начинает мешать: когда появляются исключения и формулировки типа «почти как менеджер, но без этого одного права». Роли размножаются, и каждая новая роль тянет правки, согласования и риск забыть убрать лишнее.

ABAC удобнее там, где много вариативности: филиалы, проектные команды, разные типы клиентов, ограничения по статусам и владельцам. Но он требует дисциплины: атрибуты должны быть точными и актуальными, а правила - понятными и не противоречить друг другу.

Короткое сравнение «по ощущению»:

• RBAC: проще стартовать, но роли быстро растут из-за исключений.
• ABAC: гибче, но придется следить за качеством данных и логикой правил.
• На практике часто берут гибрид: роли задают базу, атрибуты ограничивают детали.

Какие данные собрать перед выбором

Выбор между RBAC vs ABAC редко упирается в определения. Почти всегда все решают входные данные: что именно вы защищаете, какие решения о доступе уже принимаются в компании и какие факты о пользователе и объекте вы реально можете получить в момент запроса.

Сначала зафиксируйте «словарь» доступа: ресурсы и действия.

Ресурс - это не только экран или документ, но и запись в базе (заказ, счет, клиент, задача). Действие - не просто «доступ есть/нет», а чтение, создание, изменение, удаление, экспорт, согласование, публикация.

Дальше опишите, какие роли уже существуют и как они появляются. Важно не название роли, а кто ее назначает (руководитель, HR, админ, сам пользователь), и как быстро можно отозвать права. Если роль выдается вручную раз в месяц, она плохо подходит для тонких правил и частых изменений.

Третий блок - атрибуты, которые действительно доступны и надежны. В презентациях часто есть «отдел» и «проект», но в реальности поля не заполнены или обновляются с задержкой. Проверьте, что у вас есть:

• для пользователя: отдел, филиал, должность, грейд;
• для объекта: владелец, проект, статус, сумма;
• для контекста: время, устройство, сеть, среда (если это вообще нужно).

Полезно заранее ответить на пять вопросов и записать примеры:

• Какие ресурсы и действия критичны и какие последствия у ошибки доступа?
• Какие роли уже есть, кто их выдает и как выглядит процесс снятия прав?
• Какие атрибуты заполнены стабильно и кто отвечает за их качество?
• Нужен ли контекст (время, устройство, IP, статус договора) или достаточно «кто ты» и «что это за объект»?
• Как часто меняются правила и кто будет их поддерживать: продукт, безопасность, техподдержка?

Если правила меняются каждую неделю и зависят от проекта, статуса и владельца, без атрибутов будет больно. Если доступ в основном по должностям и редким исключениям, роли часто оказываются проще и надежнее.

Как выбрать: пошаговый алгоритм

Выбор между RBAC vs ABAC лучше делать не по описаниям, а по тому, как люди реально работают в вашем приложении. Цель простая: чтобы правила было легко объяснить, проверять и менять без хаоса.

5 шагов, которые обычно дают ясный ответ

1. Опишите сценарии, а не «права». Пишите глаголами и объектами: «менеджер видит заявки своего филиала», «бухгалтер выгружает акты по своим юрлицам», «руководитель утверждает отпуск команды». Так быстро видно, где решает роль, а где контекст.

2. Набросайте матрицу и посчитайте ручную работу. Для RBAC это «роль -> действия». Для ABAC это «атрибуты пользователя/объекта/контекста -> условия». Выбирайте вариант, где меньше постоянных правок. Если каждую неделю надо «добавить еще одну роль», это уже сигнал.

3. Отметьте исключения сразу. Наивные модели чаще всего ломают два типа формулировок: «можно всем, кроме…» (например, всем можно читать, кроме стажеров) и «можно только если…» (например, редактировать можно только если заявка в статусе Черновик и автор = текущий пользователь).

4. Оцените рост на год вперед и согласование. Спросите: сколько ролей станет, когда появятся новые отделы, регионы, партнеры? Кто утверждает доступ, как быстро, и кто отвечает за актуальность после увольнений и переводов?

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

Пример: в приложении для заявок роль «Менеджер» может давать право «просмотр заявок», а атрибуты ограничат видимость только «заявки своего филиала» и запретят доступ к архиву без отдельного признака. Так вы не плодите роли вроде «Менеджер-СПб», «Менеджер-Казань», «Менеджер-СПб-архив».

Примеры правил: RBAC, ABAC и гибрид

Когда сравнивают RBAC vs ABAC, проще смотреть не на определения, а на формулировки правил. Хорошее правило можно прочитать вслух и понять без переводчика с языка разработки.

Примеры RBAC (по ролям)

RBAC удобно начинать с действий в интерфейсе. Роль отвечает на вопрос: какие операции вообще доступны.

• Кассир: создает продажу, делает возврат по чеку, печатает документы, но не меняет цены и не видит зарплаты.
• Менеджер: подтверждает скидки, открывает смену, смотрит отчеты по точке, но не правит бухгалтерские проводки.
• Бухгалтер: видит финансовые отчеты и проводки, выгружает акты, но не меняет товары в каталоге.

Такие правила легко согласовать с бизнесом. Проблема начинается, когда ролей становится десятки, и каждая отличается одной «галочкой».

Примеры ABAC (по атрибутам) и правила на уровне данных

ABAC отвечает на вопрос: можно ли выполнить действие именно с этим объектом.

Пример для заявок: пользователь может открыть заявку, только если его филиал совпадает с филиалом заявки и статус не «закрыта». Другой пример: редактирование разрешено, если пользователь автор заявки или он руководитель автора.

На уровне данных чаще всего нужны два базовых паттерна:

• «видит только свои записи» (например, менеджер по продажам видит только свои сделки);
• «видит записи команды» (руководитель видит сделки сотрудников своего отдела).

Обычно это завязано на атрибуты вроде owner_id, team_id, branch_id.

Гибрид: роли задают рамки, атрибуты уточняют

Практичная схема такая: роль дает доступ к функции (например, «может редактировать заявки»), а атрибуты добавляют ограничение (только свой филиал, только не закрытые, только свою команду). Так проще поддерживать систему, особенно когда приложение быстро растет.

Чтобы правила понимали все, удобно писать их в одном шаблоне: «Кто (роль) делает что (действие) над чем (объект) при каких условиях (атрибуты)». И обязательно фиксировать примеры: 2-3 кейса, где доступ должен быть разрешен, и 2-3 где должен быть запрещен.

Как тестировать доступ: что и где проверять

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

Это одинаково важно и для RBAC, и для ABAC: ошибки чаще в проверках и фильтрации данных, чем в самой выбранной модели.

Минимальный набор проверок

Держите матрицу как таблицу в таск-трекере или как тест-кейсы. Для каждого ключевого сценария проверьте не только UI, но и API: UI может скрыть кнопку, а доступ к операции при этом останется.

• Аутентификация: без токена запрос должен получать 401, с токеном - работать только в рамках своих прав.
• Авторизация: запрет на действие должен возвращать 403, а не «тихо» выполнять операцию.
• Фильтрация данных: список и поиск не должны возвращать чужие объекты (например, заявки другого отдела).
• Запрет на изменение: нельзя менять поля, которые не разрешены (роль может читать, но не править, или править только статус).
• «Скрытые» действия: экспорт, удаление, массовые операции, импорты, админские эндпоинты.

Негативные кейсы и регрессия

Самые полезные тесты - негативные.

Пример: менеджер видит только своих клиентов. Он должен получать 403, если пытается открыть клиента по чужому ID. И еще важнее: он не должен обходить запрет через другой эндпоинт, например через «экспорт» или через связанную сущность (контакт, счет, комментарий).

Чтобы изменения правил не ломали доступ, заведите набор «сигнальных» тестов для критичных ролей: админ, обычный сотрудник, руководитель, поддержка. После любой правки политики гоняйте их в CI. Так вы заметите проблему сразу, а не после жалоб пользователей.

Когда ролей становится слишком много

«Взрыв ролей» обычно начинается не с плохого дизайна, а с исключений. Сначала есть 5-7 понятных ролей, потом появляется «менеджер, но без выгрузки», «оператор, но только по своему региону», «аудитор, но без персональных данных». Каждое уточнение рождает новую роль, и через пару месяцев никто уже не уверен, чем «Менеджер 2» отличается от «Менеджер 3».

Роли начинают дублироваться, потому что ими пытаются описать разные вещи: должность, уровень доверия, регион, проект, тип клиента, стаж, временные ограничения. В RBAC это превращается в роли, отличающиеся одной галочкой, и каждая новая просьба бизнеса становится новой комбинацией.

Признаки, что вы приближаетесь к хаосу:

• Ролей больше, чем команд или процессов, которые ими пользуются.
• Появились роли с именами вроде «SalesPlus», «SalesPlus2», «SalesTemp».
• Никто не может быстро назвать владельца роли и цель ее существования.
• Для новой роли приходится вручную копировать права из старой и править 1-2 пункта.
• Одно и то же действие доступно разным людям «по договоренности», а не по понятному правилу.

Чтобы навести порядок, полезны группы, наследование и шаблоны, но без фанатизма. Выберите один базовый принцип: роль описывает набор действий. А ограничения по данным (регион, подразделение, объект) по возможности не зашивайте в название роли.

Рабочий подход обычно выглядит так:

• Держать 5-10 шаблонов ролей по функциям (продажи, поддержка, финансы) и наследоваться от них.
• Вести каталог ролей: описание, список прав, владелец, дата создания, причина.
• Описать процесс изменений: кто запрашивает, кто утверждает, кто проверяет риски.
• Ограничить создание новых ролей: сначала ищем существующую и четко объясняем отличие.
• Делать регулярную чистку: устаревшие роли закрывать, не оставлять «на всякий случай».

Когда стоит переносить часть логики из RBAC в условия ABAC, это видно по природе исключений. Если отличия роли почти всегда связаны с атрибутами (регион пользователя, владелец заявки, тип договора, уровень доступа к данным), роли лучше оставить крупными, а детали описывать условиями: «можно редактировать только свои объекты», «видит только свой филиал». Тогда рост компании не превращается в бесконечное размножение ролей.

Частые ошибки и ловушки при внедрении

Самая частая проблема начинается незаметно: правила доступа прячутся внутри бизнес-логики. Сегодня это пара условий в обработчике заказа, завтра еще проверки в отчете, а через месяц никто не помнит, где именно решается, кому что можно. Любое изменение превращается в «обойти весь код», и скорость разработки падает.

Вторая ловушка - отсутствие единого места правды. Команда ограничивает доступ в интерфейсе (кнопку скрыли), но забывает проверить права в API. Или наоборот: API защищен, но в UI показываются чужие данные, потому что запросы не фильтруются по правам. Иногда добавляют ограничения на уровне базы, но без понятной связи с тем, что делает приложение. Итог один: поведение отличается в разных слоях и становится непредсказуемым.

С ABAC часто ошибаются иначе: недооценивают атрибуты. Модель выглядит логично на бумаге, но если у сущностей нет корректных полей (владелец, отдел, регион, статус), правила будут постоянно ломаться. Еще хуже, когда атрибуты заполняются «как получится»: у части клиентов не указан регион, у сотрудников неактуальный отдел, а доступ уже завязан на эти значения.

Отдельный риск в RBAC - слишком общие роли. «Админ» и «менеджер» без ограничений по данным быстро превращаются в универсальный пропуск. Сначала это кажется удобным, потом появляются «временные» исключения, и система перестает быть управляемой.

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

Короткая проверка, которая спасает от большинства сюрпризов:

• Есть один модуль или таблица, где живут правила, а не десятки условий по коду.
• Один и тот же смысл проверки применяется в UI и API.
• Для ABAC определены обязательные атрибуты и правила их заполнения.
• Роли не «шире», чем нужно, и ограничения по данным не маскируются под роль.
• Ведется журнал изменений прав и попыток доступа.

Короткий чеклист перед релизом

Перед релизом важнее не спорить о том, что «правильно по модели», а проверить, что доступ работает предсказуемо. Особенно если вы выбирали между RBAC vs ABAC или собрали гибрид: в проде ошибки выглядят одинаково неприятно.

5 вещей, которые должны быть готовы

• Зафиксирован каталог ресурсов и действий (например: «счета: просмотр, создание, экспорт»). Добавили новое действие - сразу добавили правило и тест.
• Для каждой операции есть простое объяснение «кто может и почему»: «менеджер видит счета только своего отдела», «бухгалтер экспортирует только после закрытия месяца».
• Проверки стоят на сервере. Интерфейс может скрыть кнопку, но сервер обязан отклонить запрос и вернуть понятную ошибку.
• Есть базовые тесты не только на разрешение, но и на запрет, плюс на фильтрацию данных.
• Любые новые роли и правила проходят короткое согласование и записываются в единый каталог: кто запросил, кто одобрил, что изменилось, когда вступило в силу.

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

Практичный пример: в приложении на React с бэкендом на Go можно скрыть вкладку «Админка» в интерфейсе, но это не защита. Защита - серверная проверка прав на каждом методе и фильтрация выборок на уровне запроса к базе.

Пример из жизни: рост компании и переход к гибриду

Компания начинала как сеть из 3 офисов. Были роли: «Менеджер продаж», «Оператор», «Руководитель». RBAC хватало: менеджер создает сделки, руководитель смотрит отчеты, оператор меняет статусы.

Через год офисов стало 30. Появились регионы, проектные команды и разные типы клиентов (например, VIP и обычные). Роли начали плодиться: «Менеджер продаж (Север)», «Менеджер продаж (Юг)», затем «(Север, проект А)» и дальше по списку. Каждая комбинация требовала правок в интерфейсах, отчетах и выгрузках.

Чтобы не переписывать все, команда оставила роли для того, что человек вообще может делать, а ограничения по данным вынесла в атрибуты. Получился гибрид: роль отвечает за действия, атрибуты - за границы видимости.

Обычно удобно разделить так:

• Роли: создавать/редактировать/удалять, доступ к разделам, право утверждать или экспортировать.
• Атрибуты: регион пользователя и объекта, проект, тип клиента, принадлежность к филиалу.

Пример: «Менеджер» может редактировать сделки, но только если сделка в его регионе и в его проекте. «Руководитель региона» видит все по региону, но не по другим. «Финансы» могут смотреть платежи по всем регионам, но не менять сделки.

Плюс в том, что новый регион или проект добавляется без новой роли. Достаточно корректно заполнить атрибуты у пользователя и у данных.

Проверка «сотрудник не видит чужой филиал» должна быть не только в интерфейсе. Команда сделала три уровня контроля: фильтр в списках, проверка на сервере при чтении карточки, и запрет в отчетах и экспорте. В тестах добавили отрицательные сценарии: пользователь из региона А пытается открыть сделку региона Б по прямому идентификатору, получить ее через API и найти в выгрузке. Если хоть где-то видно - правило реализовано не везде.

Следующие шаги: как внедрить и не утонуть в правках

Сначала зафиксируйте, что именно вы внедряете: RBAC, ABAC или гибрид. Не пытайтесь сразу покрыть все исключения. Выберите минимальный набор правил, который защищает деньги, персональные данные и ключевые операции, а остальное добавляйте постепенно.

Дальше превратите ожидания бизнеса в понятные артефакты. Сделайте матрицу доступа (кто что может) и сразу же переведите ее в тестовые кейсы на уровне API. Так вы проверите реальное поведение системы, а не только интерфейс.

Порядок действий, который обычно работает:

• Зафиксировать роли, атрибуты и 10-20 самых важных правил на старте.
• Описать ресурсы и действия: например, «счет», «возврат», «экспорт», «изменение статуса».
• Сформировать матрицу доступа и на ее основе написать API-тесты.
• Настроить логирование и аудит: что проверялось, кто получил доступ, почему.
• Определить владельцев правил и график пересмотра (например, раз в месяц).

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

Если нужно быстро собрать прототип и проверить модель на практике, иногда удобно делать это на платформе TakProsto (takprosto.ai): вы описываете роли и правила в чате, а затем держите изменения под контролем через planning mode и snapshots с rollback. Когда схема устоится, можно выгрузить исходный код, настроить деплой, хостинг и подключить свой домен.