AI Platform Docs
Онбординг

Роли, ключи и ограничения доступа

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

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

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

Д-01. Обычный пользователь видит доступные ему разделы

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

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

  1. Откройте отдельный профиль браузера и войдите в https://cp-qa.ai-dev.inno.tech.
  2. Проверьте имя пользователя в меню профиля.
  3. Сравните боковое меню с административной сессией. Разделы провайдеров, моделей, тарифов и общих политик не должны отображаться без соответствующего доступа.
  4. Откройте «Мои ключи». Список должен содержать ключи этого пользователя, а не административный список всех владельцев.
  5. Введите напрямую https://cp-qa.ai-dev.inno.tech/providers. Недоступная страница не должна раскрыть таблицу провайдеров; ожидается сообщение об отсутствии доступа.
  6. Через «В доступный раздел» вернитесь к разрешённой странице.

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

Д-02. Самостоятельная выдача включена

Условия: включённая политика выдачи, проверенные разрешённые модель и тариф, число активных ключей ниже лимита.

  1. Под администратором откройте «Политики» → «Выдача ключей» и запишите ревизию.
  2. Под обычным пользователем откройте «Мои ключи» → «Выпустить ключ».
  3. Введите уникальное имя и выберите разрешённый тариф.
  4. Проверьте модели, которые будут предоставлены. Пользователь не выбирает произвольного владельца и не добавляет модель вне политики.
  5. Выпустите ключ, сохраните одноразовый секрет и перейдите в карточку.
  6. Выполните разрешённый запрос к модели из документа «Вызовы моделей и агентов».

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

Д-03. Самостоятельная выдача выключена

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

  1. Сохраните исходные настройки политики и приготовьте ранее выпущенный тестовый ключ, который успешно вызывает модель.
  2. Под администратором откройте «Политики» → «Выдача ключей» → «Выключить». Дождитесь подтверждения.
  3. Под пользователем обновите «Мои ключи».
  4. Проверьте, что новый выпуск недоступен и причина понятна.
  5. Повторите вызов модели уже существующим ключом.
  6. Верните исходное включённое состояние политики, если оно было включённым.

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

Д-04. Исчерпан лимит активных ключей

  1. Используйте отдельного пользователя с согласованным лимитом, например один активный ключ.
  2. Выпустите разрешённое число ключей.
  3. Обновите «Мои ключи» и проверьте число оставшихся выпусков.
  4. Убедитесь, что «Выпустить ключ» недоступно и есть сообщение об исчерпанном лимите.
  5. Отзовите один собственный тестовый ключ, который нигде не используется, и дождитесь окончания операции.
  6. Обновите страницу. Проверьте, что возможность выпуска восстановилась.

Ожидается: лимит относится к активным ключам владельца. Он не снимается изменением имени ключа или повторным открытием страницы.

Пример исчерпанного лимита при включённой выдаче

Пример исчерпанного лимита при включённой выдаче

Д-05. Изменение политики не переписывает старый ключ

  1. Выпустите ключ K1, когда в политике разрешена только тестовая модель M1.
  2. Под администратором добавьте в политику отдельную тестовую модель M2, сохранив прочие разрешения.
  3. Откройте карточку K1. Зафиксируйте исходный набор моделей.
  4. Проверьте, что K1 не получил доступ к M2 только из-за изменения политики.
  5. Если лимит позволяет, выпустите новый K2. Проверьте наличие M1 и M2 у нового ключа.
  6. По окончании восстановите согласованную общую политику с учётом параллельных изменений.

Ожидается: изменения применяются к последующим выпускам. Тариф, модельные разрешения и счётчики существующего ключа не меняются задним числом.

Д-06. Административная выдача другому пользователю

  1. Получите точные issuer и sub отдельного тестового владельца. Не подставляйте почту или отображаемое имя.
  2. Под администратором откройте «Ключи» → «Выпустить ключ».
  3. Выберите тип «Пользователь», заполните владельца, тариф и одну тестовую модель.
  4. Выпустите ключ и передайте одноразовый секрет владельцу согласованным способом.
  5. Под владельцем проверьте карточку в «Моих ключах» и вызов модели.
  6. Под вторым обычным пользователем проверьте, что ключ не появился в его списке. Открытие прямой ссылки на чужой ключ не должно возвращать его данные или секрет.

Ожидается: ключ принадлежит указанному владельцу, а не администратору, который нажал кнопку. Формы не позволяют обойти права произвольной заменой ID.

Д-07. Ротация собственного ключа

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

  1. Выполните запрос к разрешённой модели старым секретом и сохраните результат без заголовка авторизации.
  2. Откройте «Мои ключи» → тестовый ключ → «Перевыпустить».
  3. Укажите причину и подтвердите действие.
  4. Дождитесь завершения, сохраните новый одноразовый секрет.
  5. Повторите одинаковый запрос старым и новым секретом.
  6. Откройте карточку и сравните ID, владельца, модели, тариф и поколение ключа.

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

Д-08. Отзыв собственного ключа

  1. Убедитесь, что тестовый ключ успешно выполняет разрешённый запрос.
  2. В его карточке нажмите «Отозвать», укажите причину и подтвердите.
  3. Дождитесь состояния отозванного ключа и завершения операции.
  4. Повторите запрос прежним секретом.
  5. Обновите карточку и «Мои ключи».

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

Д-09. Одноразовая выдача секрета

  1. Выпустите отдельный тестовый ключ и убедитесь, что значение доступно в окне выдачи.
  2. Сохраните его разрешённым способом, закройте окно и снова откройте карточку.
  3. Обновите страницу и повторите вход.
  4. Проверьте, что карточка показывает безопасные сведения о ключе, но не его исходное значение.

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

Д-10. Ключ опубликованного агента нельзя обслуживать как личный

  1. Под администратором откройте «Ключи» и найдите ключ с типом владельца «Агент», созданный публикацией тестового агента.
  2. Проверьте сведения о владельце и назначении.
  3. Убедитесь, что интерфейс не предлагает обычную ручную выдачу агентного ключа.
  4. Если проверяете API, попытка публичной ротации или отзыва такого ключа должна завершиться 409 agent_key_lifecycle_owned_by_publication, без фактического изменения секрета.

Ожидается: жизненным циклом этого ключа управляет публикация. Это доступ агента к модели, а не ключ для пользователя, вызывающего агента.

Д-11. Лимит запросов действует на ключ

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

  1. Создайте тестовый тариф с малым лимитом и отдельный ключ с доступом к одной модели.
  2. Последовательно отправьте три коротких разрешённых запроса за одно окно ограничения.
  3. Запишите HTTP-статус каждого запроса, время и безопасное содержимое ошибки.
  4. После восстановления доступного лимита повторите один запрос.
  5. Убедитесь, что другой ключ с собственным неиспользованным лимитом не потерял доступ из-за этого теста.

Ожидается: превышение лимита возвращает 429, после восстановления лимита запрос снова проходит. Не проверяйте секунду сброса по догадке: учитывайте сведения ответа и конфигурацию лимитера. Ошибки Guardrails или поставщика не засчитывайте как доказательство работы лимита.

На этой странице