Права доступа¶

Зачем нужна эта страница¶

Безопасная ИИ Студия не должна управляться одной кнопкой «ADMIN / не ADMIN». Для корпоративного использования права нужно выдавать по обязанностям.

Общая модель¶

аутентификация
    ↓
роль
    ↓
группа
    ↓
право на класс функции
    ↓
доступ к конкретному ресурсу
    ↓
системное административное полномочие
    ↓
серверная политика
    ↓
права внешнего сервиса

Каждый слой отвечает на свой вопрос.

1. Аутентификация¶

Аутентификация отвечает только на вопрос:

кто этот пользователь?

Она не определяет автоматически, что ему разрешено.

успешный вход ≠ административный доступ

и

корпоративная учётная запись ≠ право видеть все данные компании

2. Роли¶

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

Базовые роли:

USER — обычный пользователь;
ADMIN — полный администратор.

Для крупной организации полезны дополнительные роли по обязанностям, например:

AI-USERS — обычная работа;
AI-CONTENT-EDITORS — помощники и навыки;
AI-SUPPORT — ограниченная диагностика;
AI-SECURITY-AUDIT — просмотр определённых прав и журналов;
AI-ADMIN — полный административный доступ.

Названия организация определяет сама.

3. Группы¶

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

Пример групп:

Бухгалтерия
Разработка
Служба поддержки
Юристы

Группе можно назначить профиль конфигурации или использовать её при предоставлении доступа к корпоративным ресурсам.

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

4. Права на функции¶

Права на функции отвечают на вопросы:

может ли пользователь использовать помощников;
может ли создавать помощников;
может ли делиться ими;
может ли публиковать их для всей установки;
может ли использовать навыки;
может ли создавать навыки;
может ли пользоваться поиском;
может ли создавать общие ссылки.

Важно различать:

использовать
создавать
делиться
публиковать

Пользователь может использовать корпоративного помощника, но не иметь права публиковать собственного.

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

Право на функцию отвечает «можно ли вообще работать с этим типом ресурсов».

Доступ к объекту отвечает:

можно ли работать именно с этим помощником, навыком или другим конкретным ресурсом?

Для совместных ресурсов применяются уровни вроде:

Наблюдатель;
Редактор;
Владелец.

Наблюдатель¶

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

Редактор¶

Изменяет конфигурацию в пределах разрешённой модели доступа.

Владелец¶

Управляет жизненным циклом и доступом.

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

Административная панель позволяет делегировать отдельные административные возможности без полного ADMIN.

Например:

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

Пример¶

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

Ему не нужен полный ADMIN.

7. Серверные политики¶

Скрытая кнопка не является защитой.

Неверно:

кнопка скрыта → значит защищено

Правильно:

кнопка скрыта
+
сервер проверяет право
+
внешний сервис имеет минимальные права

Особенно это важно для:

запрещённых функций;
внешних сервисов;
Яндекс Облака;
подтверждения рискованных действий;
административных программных интерфейсов.

8. Права служебной учётной записи¶

Для Яндекс Облака существует ещё один независимый уровень.

пользователь
  ↓
права Студии
  ↓
серверная политика «только чтение»
  ↓
служебная учётная запись с минимальными ролями
  ↓
Яндекс Облако

Даже при ошибке внутренней конфигурации внешняя учётная запись должна ограничивать фактический ущерб.

Подробнее: Права Яндекс Облака.

9. Запрет по умолчанию¶

Для опасной или неизвестной функции предпочтительнее:

не определено → запретить или запросить подтверждение

а не:

не определено → разрешить

10. Пример безопасной схемы ролей¶

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

Разрешить по политике:

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

Запретить:

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

Редактор ИИ-контента¶

Дополнительно может получить:

создание помощников;
создание навыков;
изменение корпоративных ресурсов своей области.

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

Служба поддержки¶

Может получить только:

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

Полный администратор¶

Только тем, кому действительно нужен полный контроль.

11. Выдача повышенного доступа¶

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

12. Отрицательные тесты¶

Положительный тест:

разрешённое действие работает?

Отрицательный:

запрещённое действие действительно невозможно?

Под USER проверьте:

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

13. Перевод сотрудника¶

При изменении должности:

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

14. Увольнение¶

Процедура должна включать:

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

15. Регулярная ревизия¶

Периодически просматривайте:

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

Для повышенных прав полезно хранить владельца права и дату следующего пересмотра.

Типичные ошибки¶

«Дадим ADMIN, потом заберём»¶

Временный доступ часто остаётся надолго. Используйте делегируемое полномочие.

Проверять только интерфейс¶

Скрытая кнопка не защищает сервер. Проверяйте фактический отказ.

Смешивать группу и роль¶

Группа — состав людей. Роль — полномочия.

Забыть владельца помощника¶

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

Считать «только чтение» несекретным¶

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