RBAC в корпоративном портале: роли и доступы без хаоса

Когда в корпоративном портале работают десятки и сотни сотрудников, рано или поздно возникает один и тот же вопрос: кому что можно? Кто публикует новости, кто модерирует ленту, кто видит HR-аналитику, а кто вообще не должен заходить в настройки пространства. Если на этот вопрос отвечать «по ситуации», доступы быстро превращаются в хаос: половина команды оказывается администраторами «на всякий случай», а реальную ответственность за разделы никто не несёт. Решает эту проблему ролевая модель RBAC.

Что такое RBAC и почему это про порядок

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

В TeamHero ролевая модель построена на сочетании гибких ролей и более чем 90 гранулярных разрешений. Гранулярность здесь — ключевое слово. Доступ — это не грубый переключатель «всё или ничего», а множество мелких прав, которые можно комбинировать. Именно за счёт этого роли и доступы получаются точными: вы не выдаёте лишнего и не блокируете нужное.

Права доступа привязаны к модулям

Главный принцип, который делает управление доступом предсказуемым, — права привязаны к каждому модулю портала. Разрешения сгруппированы по функциональным областям, и вы всегда понимаете, к чему именно относится тот или иной флаг.

Несколько примеров того, как выглядят права доступа в разрезе модулей:

• Новости — публикация новостей, редактирование чужих публикаций, снятие с публикации.
• Благодарности и лента — модерация благодарностей и ленты активности, удаление неуместного контента.
• Идеи — работа с банком идей: рассмотрение, перевод между статусами, ответы авторам.
• Аналитика — доступ к HR-аналитике и отчётам, выгрузка данных.
• Управление пространством — настройки портала, оформление, структура разделов.
• Безопасность — управление доступом других пользователей, ролями и параметрами входа.

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

Четыре базовые роли

Чтобы не настраивать всё с нуля, в портале есть четыре базовые роли — готовые наборы разрешений под типовые сценарии:

• Сотрудник — базовый доступ: читает новости, ставит реакции, отправляет благодарности, предлагает идеи, участвует в жизни портала.
• Руководитель — всё то же плюс расширенный обзор своей команды и доступ к части аналитики по подразделению.
• HR-менеджер — работа с HR-данными, аналитикой, оргструктурой и кадровыми сценариями.
• Администратор — управление пространством, настройками и доступами других пользователей.

Этих ролей достаточно для старта в большинстве компаний. Но реальная структура ответственности почти всегда богаче четырёх ролей — и здесь на помощь приходят кастомные роли.

Кастомные роли: собираем под себя

Базовые роли — не потолок. Вы можете создавать собственные роли, комбинируя любые из 90+ разрешений. Это и есть настоящая сила RBAC: роль перестаёт быть жёстким шаблоном и становится конструктором.

Пример — роль «Создатель курсов». Человеку нужно создавать и редактировать обучающий контент, но не нужны ни настройки безопасности, ни HR-аналитика, ни управление пространством. Вы собираете роль из нужных разрешений по модулю обучения — и выдаёте её всем, кто отвечает за курсы.

Модератор — не базовая роль, а собранная

Показательный случай — модерация. Роли «Модератор» нет среди базовых, и это сделано осознанно. Модерация в разных компаниях выглядит по-разному: где-то это только лента и благодарности, где-то ещё и комментарии к новостям, где-то идеи. Поэтому модератор собирается из отдельных разрешений на модерацию и выдаётся кому угодно — хоть выделенному сотруднику, хоть руководителю в нагрузку к основной роли. Вы сами решаете, что входит в «модерацию» именно у вас.

Принцип наименьших привилегий

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

На практике это означает простую вещь: не нужно плодить суперадминов. Соблазн «дать полные права, чтобы не разбираться» понятен, но именно он и создаёт риски — и для безопасности, и для случайных ошибок. Чем больше людей с полным доступом, тем выше шанс, что кто-то удалит лишнее, изменит настройки или увидит данные, которые ему не предназначены. Гранулярные права доступа позволяют этого избежать: человек получает ровно то, что нужно для работы.

Как спроектировать роли: мини-чеклист

Чтобы управление доступом не превратилось в хаос, при настройке RBAC стоит пройти по короткому списку:

1. Опишите реальные функции, а не должности. Отталкивайтесь от того, что человек делает в портале, а не от строчки в штатном расписании.
2. Начните с базовых ролей. Сотрудник, Руководитель, HR-менеджер, Администратор закроют большую часть людей без всякой настройки.
3. Вынесите исключения в кастомные роли. Создатель курсов, модератор, редактор новостей — всё, что не укладывается в базовые роли, оформляйте отдельно.
4. Собирайте права по модулям. Идите от разделов портала: какие модули нужны этой роли и какие действия в них допустимы.
5. Применяйте наименьшие привилегии. Если сомневаетесь, давать ли право, — не давайте. Расширить доступ всегда проще, чем потом разбирать последствия.
6. Ограничьте число администраторов. Полный доступ — у единиц, и под конкретную зону ответственности.
7. Пересматривайте роли регулярно. Команды меняются, задачи перераспределяются — права доступа сотрудников должны успевать за этим.

Смежные механизмы: SSO, JIT и аудит

Ролевая модель не существует в вакууме — её усиливают несколько смежных возможностей. SSO позволяет входить через единую корпоративную учётную запись, а принудительный SSO запрещает любые другие способы входа, закрывая лазейки с локальными паролями. JIT-провижининг автоматически создаёт учётную запись и назначает роль в момент первого входа сотрудника — людей не нужно заводить вручную. А аудит-лог фиксирует действия с доступами и важные операции, так что в любой момент можно понять, кто и что менял.

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