RBAC vs ABAC: как выбрать модель доступа для бизнес-приложения, примеры правил, подходы к тестированию, типовые ошибки и что ломается при росте ролей.
Почти в любом бизнес-приложении доступ сначала выглядит простым: админ, менеджер, пользователь. Но как только появляются новые сотрудники, функции и ограничения (разные филиалы, тарифы, уровни поддержки), права начинают расползаться. Кому-то «временно» дают доступ, чтобы закрыть задачу, а потом забывают отозвать.
Когда схема доступа растет без правил, лишние права появляются по инерции. Новую роль копируют с похожей, добавляют пару разрешений, а старые не пересматривают. Или делают исключение «только для этого клиента», и через месяц таких исключений уже десять. В итоге доступ становится неуправляемым: люди видят то, что не должны, или, наоборот, не могут сделать свою работу.
Для бизнеса риски обычно важнее, чем «красота» архитектуры. Ошибка в доступе может привести к утечке данных, штрафам за нарушение требований к персональным данным, простоям из-за блокировок и инцидентов, а также к потере доверия клиентов. Иногда самый дорогой сценарий не утечка, а остановка процессов: бухгалтерия не может закрыть месяц, поддержка не может помочь пользователям, руководитель не видит отчеты.
Выбор между RBAC vs ABAC имеет смысл, когда вы хотите заранее ограничить хаос. Особенно если продукт развивается быстро и новые модули появляются каждые недели: в таких условиях «временные» решения закрепляются моментально.
Признаки, что текущая схема уже не подходит:
Если узнаете хотя бы два пункта, стоит остановиться и выбрать модель доступа осознанно, пока изменения еще можно контролировать.
RBAC vs ABAC проще всего понять через один вопрос: вы управляете доступом через «кто ты» или через «в какой ситуации ты сейчас».
RBAC (Role-Based Access Control) - это роли и наборы разрешений. Вы задаете роли вроде «менеджер», «бухгалтер», «поддержка» и прикрепляете к ним права: что можно смотреть, создавать, менять, удалять. Пользователю назначаете роль, и на этом все. Такой подход хорошо работает, когда процессы стабильны, а набор задач понятен.
ABAC (Attribute-Based Access Control) - это правила на основе атрибутов и контекста. Решение принимает не одна роль, а условия: атрибуты пользователя (отдел, регион, уровень), атрибуты объекта (владелец, статус, тип документа) и контекст (время, канал, среда). Примеры: «сотрудник видит только заявки своего региона» или «редактировать можно только черновики, созданные тобой».
Где обычно выигрывает RBAC: старт проекта, небольшой бизнес, понятная оргструктура. Его легко объяснить команде, можно проверить «глазами», удобно вести в админке.
Где RBAC начинает мешать: когда появляются исключения и формулировки типа «почти как менеджер, но без этого одного права». Роли размножаются, и каждая новая роль тянет правки, согласования и риск забыть убрать лишнее.
ABAC удобнее там, где много вариативности: филиалы, проектные команды, разные типы клиентов, ограничения по статусам и владельцам. Но он требует дисциплины: атрибуты должны быть точными и актуальными, а правила - понятными и не противоречить друг другу.
Короткое сравнение «по ощущению»:
Выбор между RBAC vs ABAC редко упирается в определения. Почти всегда все решают входные данные: что именно вы защищаете, какие решения о доступе уже принимаются в компании и какие факты о пользователе и объекте вы реально можете получить в момент запроса.
Сначала зафиксируйте «словарь» доступа: ресурсы и действия.
Ресурс - это не только экран или документ, но и запись в базе (заказ, счет, клиент, задача). Действие - не просто «доступ есть/нет», а чтение, создание, изменение, удаление, экспорт, согласование, публикация.
Дальше опишите, какие роли уже существуют и как они появляются. Важно не название роли, а кто ее назначает (руководитель, HR, админ, сам пользователь), и как быстро можно отозвать права. Если роль выдается вручную раз в месяц, она плохо подходит для тонких правил и частых изменений.
Третий блок - атрибуты, которые действительно доступны и надежны. В презентациях часто есть «отдел» и «проект», но в реальности поля не заполнены или обновляются с задержкой. Проверьте, что у вас есть:
Полезно заранее ответить на пять вопросов и записать примеры:
Если правила меняются каждую неделю и зависят от проекта, статуса и владельца, без атрибутов будет больно. Если доступ в основном по должностям и редким исключениям, роли часто оказываются проще и надежнее.
Выбор между RBAC vs ABAC лучше делать не по описаниям, а по тому, как люди реально работают в вашем приложении. Цель простая: чтобы правила было легко объяснить, проверять и менять без хаоса.
Опишите сценарии, а не «права». Пишите глаголами и объектами: «менеджер видит заявки своего филиала», «бухгалтер выгружает акты по своим юрлицам», «руководитель утверждает отпуск команды». Так быстро видно, где решает роль, а где контекст.
Набросайте матрицу и посчитайте ручную работу. Для RBAC это «роль -> действия». Для ABAC это «атрибуты пользователя/объекта/контекста -> условия». Выбирайте вариант, где меньше постоянных правок. Если каждую неделю надо «добавить еще одну роль», это уже сигнал.
Отметьте исключения сразу. Наивные модели чаще всего ломают два типа формулировок: «можно всем, кроме…» (например, всем можно читать, кроме стажеров) и «можно только если…» (например, редактировать можно только если заявка в статусе Черновик и автор = текущий пользователь).
Оцените рост на год вперед и согласование. Спросите: сколько ролей станет, когда появятся новые отделы, регионы, партнеры? Кто утверждает доступ, как быстро, и кто отвечает за актуальность после увольнений и переводов?
Выберите модель и зафиксируйте правила именования. Часто выигрывает гибрид: роли дают «каркас» (сотрудник, менеджер, админ), а атрибуты уточняют границы (филиал, проект, юрлицо, статус, время). Сразу договоритесь, как называются роли и атрибуты, и где это хранится (в коде, в таблице, в конфиге).
Пример: в приложении для заявок роль «Менеджер» может давать право «просмотр заявок», а атрибуты ограничат видимость только «заявки своего филиала» и запретят доступ к архиву без отдельного признака. Так вы не плодите роли вроде «Менеджер-СПб», «Менеджер-Казань», «Менеджер-СПб-архив».
Когда сравнивают RBAC vs ABAC, проще смотреть не на определения, а на формулировки правил. Хорошее правило можно прочитать вслух и понять без переводчика с языка разработки.
RBAC удобно начинать с действий в интерфейсе. Роль отвечает на вопрос: какие операции вообще доступны.
Такие правила легко согласовать с бизнесом. Проблема начинается, когда ролей становится десятки, и каждая отличается одной «галочкой».
ABAC отвечает на вопрос: можно ли выполнить действие именно с этим объектом.
Пример для заявок: пользователь может открыть заявку, только если его филиал совпадает с филиалом заявки и статус не «закрыта». Другой пример: редактирование разрешено, если пользователь автор заявки или он руководитель автора.
На уровне данных чаще всего нужны два базовых паттерна:
Обычно это завязано на атрибуты вроде owner_id, team_id, branch_id.
Практичная схема такая: роль дает доступ к функции (например, «может редактировать заявки»), а атрибуты добавляют ограничение (только свой филиал, только не закрытые, только свою команду). Так проще поддерживать систему, особенно когда приложение быстро растет.
Чтобы правила понимали все, удобно писать их в одном шаблоне: «Кто (роль) делает что (действие) над чем (объект) при каких условиях (атрибуты)». И обязательно фиксировать примеры: 2-3 кейса, где доступ должен быть разрешен, и 2-3 где должен быть запрещен.
Права почти всегда ломаются не там, где вы их ждете. Поэтому начните не с кода, а с простой матрицы проверок: пользователь (или роль) x действие x ресурс x ожидаемый результат. Так вы заранее увидите дыры, которые вылезут после добавления новой роли или нового типа объекта.
Это одинаково важно и для RBAC, и для ABAC: ошибки чаще в проверках и фильтрации данных, чем в самой выбранной модели.
Держите матрицу как таблицу в таск-трекере или как тест-кейсы. Для каждого ключевого сценария проверьте не только UI, но и API: UI может скрыть кнопку, а доступ к операции при этом останется.
Самые полезные тесты - негативные.
Пример: менеджер видит только своих клиентов. Он должен получать 403, если пытается открыть клиента по чужому ID. И еще важнее: он не должен обходить запрет через другой эндпоинт, например через «экспорт» или через связанную сущность (контакт, счет, комментарий).
Чтобы изменения правил не ломали доступ, заведите набор «сигнальных» тестов для критичных ролей: админ, обычный сотрудник, руководитель, поддержка. После любой правки политики гоняйте их в CI. Так вы заметите проблему сразу, а не после жалоб пользователей.
«Взрыв ролей» обычно начинается не с плохого дизайна, а с исключений. Сначала есть 5-7 понятных ролей, потом появляется «менеджер, но без выгрузки», «оператор, но только по своему региону», «аудитор, но без персональных данных». Каждое уточнение рождает новую роль, и через пару месяцев никто уже не уверен, чем «Менеджер 2» отличается от «Менеджер 3».
Роли начинают дублироваться, потому что ими пытаются описать разные вещи: должность, уровень доверия, регион, проект, тип клиента, стаж, временные ограничения. В RBAC это превращается в роли, отличающиеся одной галочкой, и каждая новая просьба бизнеса становится новой комбинацией.
Признаки, что вы приближаетесь к хаосу:
Чтобы навести порядок, полезны группы, наследование и шаблоны, но без фанатизма. Выберите один базовый принцип: роль описывает набор действий. А ограничения по данным (регион, подразделение, объект) по возможности не зашивайте в название роли.
Рабочий подход обычно выглядит так:
Когда стоит переносить часть логики из RBAC в условия ABAC, это видно по природе исключений. Если отличия роли почти всегда связаны с атрибутами (регион пользователя, владелец заявки, тип договора, уровень доступа к данным), роли лучше оставить крупными, а детали описывать условиями: «можно редактировать только свои объекты», «видит только свой филиал». Тогда рост компании не превращается в бесконечное размножение ролей.
Самая частая проблема начинается незаметно: правила доступа прячутся внутри бизнес-логики. Сегодня это пара условий в обработчике заказа, завтра еще проверки в отчете, а через месяц никто не помнит, где именно решается, кому что можно. Любое изменение превращается в «обойти весь код», и скорость разработки падает.
Вторая ловушка - отсутствие единого места правды. Команда ограничивает доступ в интерфейсе (кнопку скрыли), но забывает проверить права в API. Или наоборот: API защищен, но в UI показываются чужие данные, потому что запросы не фильтруются по правам. Иногда добавляют ограничения на уровне базы, но без понятной связи с тем, что делает приложение. Итог один: поведение отличается в разных слоях и становится непредсказуемым.
С ABAC часто ошибаются иначе: недооценивают атрибуты. Модель выглядит логично на бумаге, но если у сущностей нет корректных полей (владелец, отдел, регион, статус), правила будут постоянно ломаться. Еще хуже, когда атрибуты заполняются «как получится»: у части клиентов не указан регион, у сотрудников неактуальный отдел, а доступ уже завязан на эти значения.
Отдельный риск в RBAC - слишком общие роли. «Админ» и «менеджер» без ограничений по данным быстро превращаются в универсальный пропуск. Сначала это кажется удобным, потом появляются «временные» исключения, и система перестает быть управляемой.
И наконец, без аудита изменений прав вы теряете контроль. Если доступ расширился, должно быть понятно, кто это сделал, когда и почему.
Короткая проверка, которая спасает от большинства сюрпризов:
Перед релизом важнее не спорить о том, что «правильно по модели», а проверить, что доступ работает предсказуемо. Особенно если вы выбирали между RBAC vs ABAC или собрали гибрид: в проде ошибки выглядят одинаково неприятно.
Дальше проверьте две ситуации, на которых чаще всего горят релизы: «пользователь меняет отдел» и «пользователь временно замещает коллегу». Если после изменения атрибутов или роли доступ не пересчитается сразу, вы получите жалобы и ручные обходы.
Практичный пример: в приложении на React с бэкендом на Go можно скрыть вкладку «Админка» в интерфейсе, но это не защита. Защита - серверная проверка прав на каждом методе и фильтрация выборок на уровне запроса к базе.
Компания начинала как сеть из 3 офисов. Были роли: «Менеджер продаж», «Оператор», «Руководитель». RBAC хватало: менеджер создает сделки, руководитель смотрит отчеты, оператор меняет статусы.
Через год офисов стало 30. Появились регионы, проектные команды и разные типы клиентов (например, VIP и обычные). Роли начали плодиться: «Менеджер продаж (Север)», «Менеджер продаж (Юг)», затем «(Север, проект А)» и дальше по списку. Каждая комбинация требовала правок в интерфейсах, отчетах и выгрузках.
Чтобы не переписывать все, команда оставила роли для того, что человек вообще может делать, а ограничения по данным вынесла в атрибуты. Получился гибрид: роль отвечает за действия, атрибуты - за границы видимости.
Обычно удобно разделить так:
Пример: «Менеджер» может редактировать сделки, но только если сделка в его регионе и в его проекте. «Руководитель региона» видит все по региону, но не по другим. «Финансы» могут смотреть платежи по всем регионам, но не менять сделки.
Плюс в том, что новый регион или проект добавляется без новой роли. Достаточно корректно заполнить атрибуты у пользователя и у данных.
Проверка «сотрудник не видит чужой филиал» должна быть не только в интерфейсе. Команда сделала три уровня контроля: фильтр в списках, проверка на сервере при чтении карточки, и запрет в отчетах и экспорте. В тестах добавили отрицательные сценарии: пользователь из региона А пытается открыть сделку региона Б по прямому идентификатору, получить ее через API и найти в выгрузке. Если хоть где-то видно - правило реализовано не везде.
Сначала зафиксируйте, что именно вы внедряете: RBAC, ABAC или гибрид. Не пытайтесь сразу покрыть все исключения. Выберите минимальный набор правил, который защищает деньги, персональные данные и ключевые операции, а остальное добавляйте постепенно.
Дальше превратите ожидания бизнеса в понятные артефакты. Сделайте матрицу доступа (кто что может) и сразу же переведите ее в тестовые кейсы на уровне API. Так вы проверите реальное поведение системы, а не только интерфейс.
Порядок действий, который обычно работает:
Отдельно запланируйте поддержку. Ответьте на три вопроса: кто добавляет новые роли, кто меняет атрибуты (отдел, регион, тариф, проект), кто отвечает за аудит и разбор инцидентов. Если это не назначить, права быстро снова превратятся в хаос.
Если нужно быстро собрать прототип и проверить модель на практике, иногда удобно делать это на платформе TakProsto (takprosto.ai): вы описываете роли и правила в чате, а затем держите изменения под контролем через planning mode и snapshots с rollback. Когда схема устоится, можно выгрузить исходный код, настроить деплой, хостинг и подключить свой домен.
Если у вас стабильные процессы и доступ в основном определяется должностью, начните с RBAC: роли проще объяснить и быстро внедрить. Если права часто зависят от филиала, проекта, владельца записи или статуса, сразу планируйте ABAC или гибрид, чтобы не плодить десятки ролей.
Это когда для каждой новой «почти такой же» ситуации создается новая роль: «менеджер-СПб», «менеджер-СПб-архив», «менеджер-СПб-без-экспорта». Обычно причина в том, что вы пытаетесь ролями описать ограничения по данным (регион, филиал, проект), хотя это лучше решать атрибутами и условиями.
Роль отвечает на вопрос «что человек вообще может делать», а атрибуты — «с какими именно данными и при каких условиях». На практике удобно оставлять роли крупными (например, менеджер, бухгалтер, поддержка), а видимость и ограничения задавать через branch_id, team_id, owner_id, status и похожие поля.
Сначала опишите ресурсы и действия: что защищаете и какие операции важны (чтение, изменение, экспорт, массовые операции). Затем выпишите реальные сценарии работы людей и пометьте, где решает роль, а где решает контекст объекта. После этого станет видно, сколько ручных правок потребует RBAC и насколько вы готовы поддерживать качество атрибутов для ABAC.
Базовый вариант — гибрид: RBAC для доступа к функциям и ABAC для ограничений по данным. Например, роль дает право «редактировать заявки», а правила ограничивают это «только свой филиал» и «только пока статус не закрыт». Так проще масштабироваться и не превращать админку в каталог случайных ролей.
Делайте правила читаемыми: «кто делает что над чем при каких условиях». Если правило нельзя объяснить одной фразой и проверить на паре примеров, оно почти наверняка будет ломаться и вызывать споры. Для каждого правила сразу фиксируйте примеры, когда доступ должен быть разрешен и когда должен быть запрещен.
Не полагайтесь на интерфейс: скрытая кнопка не защищает. Проверяйте серверные ответы (401 без входа и 403 при запрете), фильтрацию списков и поиска, доступ к карточкам по прямому ID, а также экспорт, отчеты, массовые операции и «служебные» эндпоинты. Самые полезные проверки — негативные: попытки получить чужие данные обходными путями.
Часто права разъезжаются по коду и начинаются расхождения между UI, API и отчетами. Другая проблема — атрибуты в ABAC существуют «на бумаге», но в данных они пустые или не обновляются, из‑за чего доступ становится случайным. И еще одна типовая ошибка — слишком широкие роли вроде «админ» без четких границ и без журнала изменений прав.
Когда сотрудник меняет отдел, филиал или проект, его доступ должен пересчитываться быстро и предсказуемо. То же самое с временным замещением: если выдали доступ на неделю, должен быть понятный механизм автоматического завершения или быстрого отзыва. Эти ситуации лучше продумать до релиза, иначе появятся «временные» исключения, которые останутся навсегда.
Если вы прототипируете приложение на TakProsto, удобно сразу описать роли и правила в чате и проверить их на сценариях, а затем фиксировать изменения через planning mode. Для безопасных правок помогают snapshots и rollback, чтобы быстро откатиться, если правило сломало работу. Когда схема устоится, можно выгрузить исходный код и продолжить развитие уже в своей инфраструктуре.
