RBAC vs ABAC для внутренних инструментов: как выбирать масштабируемые права доступа

Почему с правами всё усложняется во внутренних инструментах

Внутренние инструменты работают рядом с самыми чувствительными частями бизнеса: карточки клиентов, возвраты, счета, заметки по зарплате, суммы сделок и приватные внутренние комментарии. Не всем нужно всё видеть, и ещё меньшему числу — редактировать.

Обычно права начинаются просто: «Support может просматривать тикеты», «Finance может утверждать возвраты», «Managers видят показатели команды». Затем организация растёт, процессы меняются, и инструмент превращается в набор исключений.

Паттерн «взорвётся позже» распространён:

• Разрастание ролей: вы добавляете Support, потом Support — Senior, потом Support — EU, потом Support — EU — Night Shift, пока никто не помнит, что входит в каждую роль.
• Нарастание исключений: нескольким людям нужен «еще один доступ», и однократные переключатели накапливаются.
• Случайные утечки: кто‑то видит заметки по зарплате, PII клиентов или отчёты о доходах, потому что экран был переиспользован без повторной проверки доступа.
• Сломанные сценарии работы: пользователь видит запись, но не может выполнить следующий шаг (или, что хуже, может выполнить действие, не видя контекста).
• Болезненные аудиты: трудно ответить на вопрос «Кто может утверждать возвраты свыше $1,000?» без ручного копания.

Цель выбора RBAC или ABAC на раннем этапе — не только закрыть экраны. Это сохранить правила понятными, когда появляются новые команды, регионы и политики.

Модель прав, которая выдерживает изменения, обладает четырьмя качествами: её легко объяснить, легко проверить, трудно использовать неверно и просто изменить.

RBAC простыми словами (роли и что они открывают)

RBAC (управление доступом по ролям) — это подход «по должности». Пользователю присваивают одну или несколько ролей (Support Agent, Admin). Каждая роль имеет фиксированный набор действий и данных, доступных этой роли. Если у двух людей одна роль, у них одинаковый доступ.

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

Пример ролей для консоли поддержки:

• Support Agent: просматривать тикеты, отвечать клиентам, добавлять внутренние заметки
• Support Lead: всё, что может агент, плюс переназначать тикеты и смотреть метрики команды
• Admin: управлять пользователями, менять системные настройки, редактировать правила прав

Ключевая идея в том, что роли привязаны к обязанностям, а не к конкретным людям. Когда обязанности стабильны, роли остаются стабильными, и модель легко объяснить.

RBAC подходит, когда:

• Организационная схема ясна (команды, лиды, админы)
• Большинство решений по доступу — «может ли он пользоваться этой функцией?»
• Онбординг должен быть предсказуемым (назначил роль X — и всё готово)
• Аудиты важны (легко перечислить, что может роль)

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

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

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

ABAC (управление доступом по атрибутам) принимает решение о доступе, опираясь на правила, а не только на должности. Вместо «что может роль Finance?» ABAC спрашивает: «Учитывая, кто этот человек, что это за запись и что происходит прямо сейчас, разрешаем ли мы это?».

Атрибуты — это факты, которые вы уже отслеживаете. Правило может звучать так:

• «Агенты поддержки могут просматривать тикеты в своём регионе.»
• «Менеджеры могут утверждать расходы до $5,000 в рабочее время.»

Большинство ABAC‑систем опирается на категории атрибутов:

• Атрибуты пользователя: отдел, регион, статус менеджера
• Атрибуты данных: владелец записи, приоритет тикета, статус счёта
• Атрибуты контекста: время суток, тип устройства, сеть
• Атрибуты действия: просмотр vs редактирование vs экспорт

Конкретный пример: агент поддержки может редактировать тикет только если (a) приоритет не критический, (b) тикет назначен на него, и (c) регион клиента совпадает с его регионом. Вы избегаете создания отдельных ролей вроде Support - EU - Noncritical и Support - US - Noncritical.

Компромисс в том, что ABAC может стать трудночитаемым, если исключения продолжают накапливаться. Через несколько месяцев люди перестают отвечать на простые вопросы вроде «Кто может экспортировать счета?» без чтения длинной цепочки условий.

Хорошая практика ABAC — держать правила немногочисленными, согласованными и давать им понятные имена.

Доступ на уровне записей: где происходит большинство ошибок

Многие команды рассматривают права как «может ли пользователь открыть этот экран?» — это только первый уровень. Доступ на уровне записей отвечает на другой вопрос: даже если вы можете открыть экран, какие строки вам разрешено видеть или изменять?

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

Распространённые правила на уровне записей:

• Только ваши клиенты (assigned_owner_id = current_user.id)
• Только ваш регион (customer.region IN current_user.allowed_regions)
• Только ваш центр затрат (invoice.cost_center_id IN current_user.cost_centers)
• Только тикеты вашей команды (ticket.team_id = current_user.team_id)
• Только записи, которые вы создали (created_by = current_user.id)

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

Типичная ошибка — «закрытая страница, открытый API». Кнопка скрыта для не‑админов, но эндпоинт всё ещё возвращает все записи. Любой, кто имеет доступ к приложению, может вызвать этот запрос, повторно используя запрос или подправив фильтр.

Проверьте модель простыми вопросами:

• Если пользователь вызовет эндпоинт напрямую, вернёт ли он только разрешённые записи?
• Применяются ли одинаковые правила к списковым, детальным, экспортным и счётным эндпоинтам?
• Проверяются ли отдельно create, update и delete (не только read)?
• Обходят ли админы правила намеренно или случайно?

Права экранов решают, кто входит в комнату. Права на уровне записей решают, какие ящики они могут открыть внутри неё.

Реальные примеры: поддержка, финансы и менеджеры

Цель не в «идеальной безопасности». Цель — права, которые люди понимают сегодня и которые можно изменить позже, не ломая процессы.

Команда поддержки

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

Простая модель: агенты могут открывать и обновлять тикеты, назначенные им, а также всё, что в их очереди. Лиды команды могут переназначать тикеты и вмешиваться в эскалации. Менеджерам часто нужны дашборды без права редактировать каждый тикет.

Массовые операции и экспорты — частая сложность. Многие команды разрешают массовое закрытие, ограничивают массовое переназначение и дают право на экспорт только лидам и менеджерам с логированием.

Финансы

Доступ в финансах в основном про шаги утверждения и чистый аудит‑трейл.

Обычная схема: клерк AP может создавать счета и сохранять черновики, но не может утверждать или платить. Контролёр может утверждать и запускать платежи. Аудиторам нужен доступ только для чтения, включая вложения, без возможности менять данные поставщика.

Реалистичное правило: «Клерки AP могут редактировать созданные ими черновики; после отправки менять их могут только контролёры.» Это правило уровня записей (статус + владелец) и часто лучше ложится на ABAC, чем на создание дополнительных ролей.

Менеджеры

Большинству менеджеров нужна широкая видимость, но ограниченная возможность редактировать.

Практичный паттерн: менеджеры могут просматривать большинство операционных данных, но редактировать только записи, принадлежащие их команде или связанные с их прямыми подчинёнными (запросы на отпуск, цели, заметки о производительности). Атрибуты вроде team_id, manager_id и статус занятости обычно понятнее, чем создание отдельной роли для каждого отдела.

Во всех этих группах обычно требуется:

• Support: видимость по назначению/очереди, тщательный контроль экспортов, управляемое переназначение
• Finance: правила по статусу (черновик vs отправлен vs утверждён), строгие схемы утверждения, безопасный доступ только для чтения для аудиторов
• Managers: широкая видимость, узкие права редактирования (записи, принадлежащие команде или прямым подчинённым)

Матрица решений: роли vs атрибуты vs фильтры на уровне записей

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

Обращайтесь с логикой прав как с ежемесячным счётом. Каждая лишняя роль, правило и исключение требует времени на тестирование, объяснение и отладку. Тратьте минимально необходимое, чтобы покрыть реальные сценарии сегодня.

Практический дефолт:

• Начните с RBAC для широких линий (Support, Finance, Manager).
• Добавляйте ABAC для повторяющихся условий (регион, старшинство, уровень клиента).
• Добавляйте правила на уровне записей, когда пользователи должны видеть «свои» элементы, а не всю таблицу.

Пошагово: проектируйте права до того, как строите экраны

Если вы решаете вопросы прав после создания UI, обычно вы получаете слишком много ролей или груду особых случаев. Простой план предотвращает постоянные переработки.

1) Начните с действий, а не экранов

Запишите, что люди реально делают в каждом процессе:

• Просмотр (read)
• Создание (create)
• Редактирование (edit)
• Утверждение (approve)
• Экспорт (export)
• Удаление (delete)

В потоке возвратов Approve — не то же самое, что Edit. Это различие часто решает, нужен ли строгий контроль или достаточно роли.

2) Определите роли, соответствующие должностям

Выберите роли, которые люди узнают без обсуждения: Support Agent, Support Lead, Finance Analyst, Finance Manager, Auditor, Admin. Избегайте ролей типа «Support Agent - Can edit VIP notes». Они быстро разрастаются.

3) Перечислите атрибуты, которые создают реальные исключения

Добавляйте ABAC только там, где это экономически оправдано. Типичные атрибуты: регион, команда, уровень клиента, владение, сумма.

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

4) Пишите правила на уровне записей в виде одно‑предложных политик

Именно на этом уровне большинство внутренних инструментов ломается. Пишите правила так, чтобы их могла понять не‑техническая руководящая ставка:

“Support Agents can view tickets in their region.”

“Finance Analysts can edit invoices they created until they’re approved.”

“Managers can approve refunds over $500 only for their team.”

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

5) Протестируйте на пяти реальных людях перед сборкой

Пройдитесь по реальным сценариям:

• Агент поддержки, работающий с VIP‑клиентом
• Финансовый аналитик, корректирующий счёт
• Менеджер, утверждающий крупный возврат
• Админ, выполняющий обслуживание
• Аудитор, который должен видеть историю, но ничего не менять

Исправьте путаницу здесь, до того как она превратится в лабиринт прав.

Обычные ловушки (и как их избежать)

Большинство сбоев с правами не из‑за выбора RBAC или ABAC. Они возникают, когда мелкие исключения накапливаются и никто не может объяснить, кто что может и почему.

Взрыв ролей обычно начинается с «лиду поддержки нужна одна дополнительная кнопка», а затем вырастают 25 ролей, отличающихся одной привилегией. Держите роли широкими (по обязанностям) и используйте небольшое число правил‑исключений для повторяющихся краёв.

Невнятная логика атрибутов — ABAC‑версия той же проблемы. Если у вас условия вроде “department == X AND region != Y” разбросаны повсюду, аудит превращается в гадание. Используйте именованные политики (хотя бы в общей документации), чтобы можно было сказать «политика RefundApproval», а не разбирать формулу.

Экспорты, отчёты и массовые операции — место утечек. Команда закрывает вид записи, но забывает, что Export CSV или массовое обновление обходят те же проверки. Относитесь к каждому пути, не связанному с экраном, как к полноценному действию с собственной проверкой прав.

Ловушки, за которыми стоит следить:

• Новая роль для каждого исключения
• Трудночитаемая или неименованная логика атрибутов
• Экспорты и запланированные отчёты, пропускающие проверки
• Разные инструменты, дающие разные ответы на один и тот же вопрос доступа
• Правила на уровне записей, применённые в одном месте, но не в другом

Самое безопасное решение — единый источник прав для ролей, атрибутов и правил на уровне записей, применяемый последовательно в бэкенд‑логике.

Быстрый чек‑лист перед релизом

Если вашу модель трудно объяснить, её будет ещё труднее отлаживать, когда кто‑то скажет «Я должен видеть этого клиента» или «Почему они могут это экспортировать?»

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

• Может ли реальный пользователь описать свой доступ одним предложением (например: «Я — Support, регион = EU, могу просматривать тикеты моего региона, но не могу экспортировать»)? Если нет, правила, вероятно, рассредоточены.
• Есть ли явный ответ на «кто может экспортировать?» и «кто может утверждать?» Относитесь к экспорту и утверждению как к высокорисковым действиям.
• Применяются ли правила на уровне записей везде, где данные выгружаются (API‑эндпоинты, отчёты, фоновые задания), а не только скрываются кнопки?
• Безопасен ли дефолт для чувствительных действий (deny by default)? Новые роли, атрибуты и экраны не должны по ошибке наследовать мощные права.
• Можете ли вы ответить «Кто может увидеть эту запись и почему?» за минуту, используя единый источник прав (роль, атрибуты и поля владения/статус)?

Пример: Финансы могут просматривать все счета, но только Approvers могут утверждать, и только Managers могут экспортировать полный список поставщиков. Support видит тикеты, но только команда владельца видит внутренние заметки.

Как менять права, не ломая всё

Права меняются по скучным причинам: новый менеджер, разделение Finance на AP и AR, или поглощение другой команды. Планируйте изменения так, чтобы они были небольшими, обратимыми и легко проверяемыми.

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

Добавление доступа без полной переработки

Когда появляется новый отдел (или при слиянии добавляются команды), сохраняйте базовые роли и добавляйте слои сверху:

• Держите базовые роли немногочисленными (Support, Finance, Manager), затем добавляйте небольшие надстройки (Refunds, Export, Approvals).
• Предпочитайте атрибуты для организационных изменений (team, region, cost center), чтобы новым группам не требовалось создавать роли.
• Используйте правила на уровне записей для владения и назначения (ticket.assignee_id, invoice.cost_center).
• Добавляйте шаг утверждения для чувствительных действий (выплаты, списания).
• Во всех местах относитесь к экспорту как к отдельному разрешению.

Временный доступ не должен требовать постоянной смены роли. Для замены на время отпуска или при инциденте используйте доступ с ограничением по времени: «Finance Approver на 48 часов», с датой окончания и обязательной причиной.

Ритм аудита и готовность к расследованию

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

Логируйте достаточно, чтобы ответить, кто и почему сделал то или иное действие:

• Кто просматривал, редактировал, утверждал или экспортировал
• Когда это произошло (и откуда, если вы это фиксируете)
• Какую запись трогали (ID, тип, до/после для изменений)
• Почему это было разрешено (роль, атрибут, правило записи, временный грант)
• Кто выдал доступ (и когда он истекает)

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

Начните с маленькой, скучной модели прав. Именно такая модель переживёт полгода изменений.

Хороший дефолт — простой RBAC: горстка ролей, соответствующих реальным должностям (Support Agent, Support Lead, Finance, Manager, Admin). Используйте эти роли для управления основными дверьми: какие экраны есть, какие действия доступны и какие рабочие процессы можно стартовать.

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

Пишите правила простыми предложениями сначала. Если правило тяжело сформулировать в одном предложении, его будет тяжело поддерживать.

Если хотите быстро опробовать это в реальном внутреннем инструменте, no‑code платформа вроде AppMaster (appmaster.io) может помочь смоделировать роли, поля данных вроде owner/team/status и бизнес‑процессы с проверками в бэкенде заранее, до того как решения интерфейса зафиксируют рискованные допущения.