Перейти к содержанию

Роли и права — справочник

Эта страница сводит в одном месте модель доступа НайсСофт — ИИ Студии 0.3.66. Для пошаговой настройки используйте административную главу «Права на возможности».


Главное правило

Доступ нельзя описать одной надписью USER или ADMIN.

Эффективный результат складывается из нескольких независимых уровней:

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

Самый строгий запрет должен иметь приоритет.


1. Базовые роли

USER

Обычный пользователь Студии. Его назначение — работать с разрешёнными чатами, файлами, помощниками, поиском, проектами и другими функциями согласно политике организации.

USER не должен автоматически получать:

  • управление модельным маршрутом;
  • административную панель;
  • создание произвольных внешних подключений;
  • выполнение произвольного кода;
  • изменение серверных политик;
  • доступ к чужим частным объектам.

ADMIN

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

Warning

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

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

Администратор может создавать дополнительные роли под организационную модель, например:

  • «Разработчик»;
  • «Аналитик»;
  • «Аудитор»;
  • «Оператор пользователей»;
  • «Администратор знаний».

Один пользователь может состоять в нескольких ролях.


2. Группы

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

Примеры:

  • отдел разработки;
  • финансовая служба;
  • пилотная группа памяти;
  • команда эксплуатации.

Группы удобны для:

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

3. Права на классы функций

В административной модели Студии встречаются следующие классы возможностей:

Класс Что контролирует
Помощники использование, создание и распространение помощников
Библиотека запросов использование и публикацию шаблонов запросов
Память использование постоянной памяти
Подключённые сервисы использование и, если разрешено, управление подключениями
Удалённые помощники внешние точки подключения помощников, если они включены
Навыки использование, создание и публикацию навыков
Общие ссылки публикацию разговоров
Плановые задания автоматический запуск помощников
Закладки пользовательские закладки
Несколько разговоров параллельную работу/сравнение
Временный чат временные разговоры
Интернет-поиск обращение к веб-поиску
Поиск по файлам RAG по загруженным документам
Цитаты файлов отображение оснований ответа по файлам
Каталог расширений в поставке НайсСофт отключён для всех ролей
Выбор людей поиск пользователей, групп и ролей при выдаче доступа
Выполнение кода в продуктовом профиле Студии отключено

Note

Наличие класса в административной схеме базовой платформы не означает, что он разрешён продуктовой политикой НайсСофт.


4. Типовые действия над функцией

В интерфейсе могут встречаться буквальные системные действия USE, CREATE, SHARE, SHARE_PUBLIC. В документации они означают:

Системное действие Понятный смысл
USE использовать существующую функцию/объект
CREATE создавать новые объекты
SHARE выдавать доступ конкретным получателям
SHARE_PUBLIC публиковать для всех пользователей текущей установки

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


5. Доступ к конкретному объекту

Право использовать класс функции не даёт автоматически доступ ко всем объектам этого класса.

Для помощников, навыков и других совместно используемых объектов применяются роли доступа:

Роль объекта Возможности
Наблюдатель (Viewer) просматривать/использовать объект без изменения конфигурации
Редактор (Editor) использовать и изменять объект
Владелец (Owner) полный контроль, включая доступ и жизненный цикл

Конкретный набор действий зависит от типа ресурса.

Пример

Пользователю разрешено использовать помощников, но помощник «Финансовый анализ» выдан только группе «Финансы».

Пользователь вне группы помощника его не получает.


6. Системные административные полномочия

Текущая административная панель 0.3.66 поддерживает отдельные системные полномочия. В числе подтверждённых:

Полномочие Назначение
Доступ к панели администратора открыть административный интерфейс
Просмотр пользователей видеть список и профили пользователей
Управление пользователями создавать, изменять и удалять пользователей
Просмотр групп видеть группы и участников
Управление группами создавать, менять и удалять группы
Просмотр ролей видеть роли и их разрешения
Управление ролями создавать, изменять и удалять роли
Просмотр конфигураций читать настройки экземпляра
Управление конфигурациями изменять настройки экземпляра
Назначение конфигураций назначать профили конфигурации
Просмотр статистики использования читать эксплуатационную аналитику
Просмотр помощников читать конфигурации помощников
Управление помощниками создавать, изменять и удалять помощников
Просмотр библиотеки запросов читать шаблоны запросов
Управление библиотекой запросов создавать и изменять шаблоны
Просмотр навыков читать конфигурации навыков
Управление навыками создавать, изменять и удалять навыки
Просмотр общих ссылок видеть опубликованные ссылки
Управление общими ссылками управлять опубликованными ссылками
Просмотр ассистентов читать соответствующие конфигурации совместимости
Управление ассистентами управлять такими конфигурациями
Просмотр журнала аудита читать и экспортировать журнал изменений системных полномочий

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


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

Профиль конфигурации — ещё один уровень, не равный роли.

Он может задавать значения параметров для:

  • группы;
  • роли;
  • отдельного пользователя;
  • иной поддерживаемой области.

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


8. Продуктовые запреты, которые не следует обходить ролью

В стандартном профиле 0.3.66:

  • выполнение произвольного кода отключено (runCode: false);
  • каталог расширений отключён для всех ролей;
  • пользовательское создание/публикация произвольных подключённых сервисов запрещены;
  • системные сервисы Яндекс Облака работают в управляемом режиме только чтения;
  • неизвестные или рискованные операции не должны становиться доверенными только из-за текста запроса модели;
  • физический модельный маршрут меняет администратор, а не обычный пользователь.

9. Внешние права — отдельная граница

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

Например, для Яндекс Облака одновременно важны:

право пользователя в Студии
        +
политика шлюза НайсСофт
        +
Folder/Cloud/Billing Account
        +
роль служебной учётной записи в Яндекс Облаке

Если служебная учётная запись не имеет нужного права, выдача ADMIN в Студии не исправит внешний 403.


10. Рекомендуемые шаблоны

Обычный сотрудник

  • роль USER;
  • чат и файлы — разрешены;
  • поиск/память — по политике организации;
  • использование опубликованных помощников — разрешено;
  • создание и широкая публикация — только если действительно нужны;
  • административные полномочия отсутствуют.

Создатель помощников

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

Оператор пользователей

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

Аудитор

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

11. Проверка после изменения прав

После каждого существенного изменения выполните два теста:

  1. действие, которое должно быть разрешено;
  2. действие, которое должно быть запрещено.

Проверка только положительного сценария недостаточна.

Особенно после обновления или восстановления проверьте:

  • USER не получил административную панель;
  • выполнение кода осталось запрещено;
  • пользователь не может публиковать внешний сервис;
  • пользователь А не видит частные объекты пользователя Б;
  • права на общую ссылку/помощника соответствуют назначению.

См. также