Роли и группы¶

Что вы сделаете¶

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

1. Роль и группа — не одно и то же¶

Роль¶

Отвечает на вопрос:

Что пользователь может делать в ИИ Студии?

Например:

Сотрудник
Исследователь
Редактор базы знаний
Оператор пользователей
Аудитор

Группа¶

Отвечает на вопрос:

К какой команде или подразделению относится пользователь?

Например:

Финансы
Разработка
Продажи
ИТ

2. Базовые роли¶

Системно присутствуют как минимум:

USER;
ADMIN.

USER¶

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

ADMIN¶

Даёт полный административный доступ и должна назначаться минимальному числу людей.

Не создавайте рабочую схему, в которой все технические сотрудники имеют ADMIN.

3. Пользовательские роли¶

Для промежуточных сценариев создавайте собственные роли.

Хорошие примеры:

Исследователь¶

Разрешено:

обычный чат;
файлы;
интернет-поиск;
использование готовых помощников;
память.

Не разрешено:

публичное распространение ресурсов;
управление пользователями;
изменение системной конфигурации.

Редактор базы знаний¶

Разрешено:

использовать помощников;
создавать/редактировать определённые ресурсы;
работать с файлами;
создавать навыки, если это предусмотрено политикой.

Аудитор¶

Можно выдать:

вход в административную панель;
просмотр пользователей;
просмотр ролей;
просмотр журнала аудита.

Но не выдавать право изменения.

4. Создание роли¶

Откройте «Доступ».
Перейдите на вкладку «Роли».
Нажмите «Создать роль».
Укажите понятное название.
Сохраните.
Настройте матрицу разрешений.
Добавьте тестового участника.
Проверьте роль фактическим входом.

Правило названия¶

Название должно описывать функцию, а не конкретного сотрудника.

Хорошо:

Аудиторы
Редакторы знаний
Исследователи

Плохо:

Роль Ивана
Роль для Марии 2
Новая роль тест

5. Несколько ролей у одного пользователя¶

Пользователь может состоять более чем в одной роли.

Эффективные разрешения складываются.

Это означает:

строгая роль
+
широкая роль
=
широкие итоговые права

Поэтому «добавить ещё одну роль для одной функции» может неожиданно открыть и другие возможности.

Перед назначением второй роли проверьте её полностью.

6. Создание группы¶

Откройте «Доступ».
Перейдите в «Группы».
Нажмите «Создать группу».
Укажите название подразделения или функциональной команды.
Добавьте участников.
При необходимости назначьте профиль конфигурации.
Используйте группу при выдаче доступа к конкретным ресурсам.

7. Что удобно выдавать группе¶

Группе удобно предоставлять:

доступ к корпоративному помощнику;
доступ к навыку;
доступ к библиотеке запросов;
профиль конфигурации;
ограниченный набор системных административных возможностей;
доступ к конкретному сервису, если это предусмотрено политикой.

Преимущество:

изменили состав группы
        ↓
доступ автоматически следует за членством

Вместо ручного редактирования десятков отдельных ресурсов.

8. Профили конфигурации¶

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

Пример:

Базовая конфигурация
        ↓
Профиль группы «Исследователи»
        ↓
Профиль конкретного пользователя
        ↓
Итоговая конфигурация

При нескольких профилях важен приоритет.

В административной панели элементы с более высоким приоритетом должны рассматриваться раньше при разрешении конфликтов согласно текущей модели панели.

Практическое правило¶

Не создавайте конфликтующие профили без письменного объяснения, зачем они нужны.

9. Приоритет профилей¶

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

После изменения порядка:

сохраните порядок;
войдите тестовым пользователем;
проверьте эффективную настройку;
проверьте вторую роль или группу пользователя;
зафиксируйте результат.

Не считайте положение карточек в интерфейсе чисто декоративным.

10. Доступ к конкретным ресурсам¶

Роль на функцию не означает автоматического доступа ко всем ресурсам этого типа.

Пример:

Роль разрешает пользоваться помощниками
        ↓
помощник «Финансы» закрыт
        ↓
пользователь всё равно его не видит

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

11. Просмотр, редактирование и владение¶

Для совместных объектов обычно различаются:

Просмотр¶

Пользователь может использовать или просматривать объект в допустимом объёме.

Редактирование¶

Может менять конфигурацию объекта.

Владение¶

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

Безопасность¶

Редактор и владелец могут видеть больше внутренней конфигурации объекта, чем обычный пользователь.

Не выдавайте редактирование только ради возможности «запустить помощника».

12. Системные административные права¶

Отдельно от роли существуют системные возможности.

Пример делегирования:

Оператор кадрового доступа¶

Доступ к панели администратора
Просмотр пользователей
Управление пользователями
Просмотр групп

без:

управления конфигурацией
управления моделями
полного ADMIN

Аудитор¶

Доступ к панели администратора
Просмотр пользователей
Просмотр ролей
Просмотр журнала аудита

без изменяющих прав.

13. Проектирование ролей с нуля¶

Не начинайте с интерфейса.

Сначала составьте таблицу:

Действие	Обычный сотрудник	Исследователь	Редактор знаний	Аудитор	Полный администратор
Чат	да	да	да	по необходимости	да
Файлы	да	да	да	нет	да
Интернет-поиск	по политике	да	да	нет	да
Создание помощников	по политике	да	да	нет	да
Публикация для всех	нет	нет	по политике	нет	да
Управление пользователями	нет	нет	нет	нет	да
Просмотр аудита	нет	нет	нет	да	да

После этого переносите таблицу в панель.

14. Тест роли¶

Для каждой новой роли создайте тестового пользователя.

Проверьте две группы сценариев.

Должно работать¶

Перечислите 5–10 разрешённых действий и выполните их.

Не должно работать¶

Перечислите 5–10 запрещённых действий и убедитесь, что они действительно блокируются.

Именно вторая часть чаще всего выявляет ошибку настройки.

15. Удаление роли или группы¶

Перед удалением:

посмотрите участников;
посмотрите назначенные профили;
проверьте, использовалась ли роль/группа в доступе к ресурсам;
определите замену;
предупредите владельцев критичных ресурсов.

После удаления:

проверьте пользователей;
проверьте доступ к общим помощникам;
проверьте административные права;
проверьте эффективную конфигурацию.

16. Рекомендуемая минимальная модель¶

Для небольшой компании достаточно:

USER
ADMIN
+
группы по подразделениям

Пользовательские роли добавляйте только при реальной необходимости.

Для крупной компании:

базовая роль USER
+
функциональные роли
+
организационные группы
+
точечные системные права администраторам
+
доступы к конкретным ресурсам

Частые ошибки¶

Создали роль, но пользователь ничего не получил¶

Проверьте:

пользователь назначен в роль;
права роли сохранены;
функция не отключена глобально;
есть доступ к конкретному ресурсу;
сессия пользователя обновлена.

Пользователь получил лишнее¶

Проверьте:

вторые роли;
группы;
индивидуальные профили;
публичные для установки ресурсы;
системные административные права.

Удаление группы «сломало» отдел¶

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

Что дальше¶

Перейдите к правам на возможности.