Кабинет клиента: вход, создание и отзыв ключа

Реальный путь hosted-клиента, лимиты и восстановление при ошибках.

Роль: hosted-клиент. Отдельный кабинет содержит собственные ключи и лимиты. Политики, маскирование и управление организациями доступны администратору контура; вход через SSO этих прав не выдаёт.

Войти

  1. Откройте адрес консоли, полученный от администратора. Для публичного сервиса — IAM.Secure. У staging отдельные аккаунт и API: не переносите его адрес в production-конфигурацию.
  2. Нажмите Войти через корпоративный SSO / Sign in with corporate SSO и выполните вход в IAM.Identity. Если показаны условия использования, самостоятельно изучите и примите их перед продолжением.
  3. Проверьте своё имя и адрес API в карточке. Вход в консоль одного продукта не подключает аккаунт к другому.

Создать и сохранить ключ

  1. Нажмите Создать API-ключ / Create API key один раз и дождитесь ответа. Пока кнопка занята, не повторяйте создание.
  2. Сохраните одноразово показанное значение в хранилище секретов приложения. Скрыть / Hide убирает его со страницы. ID строки в списке — не секретный ключ для авторизации.
  3. Перезагрузите страницу: ID остаётся, секрет больше не показывается. Дополнительной кнопки «Сохранить» и поля для смены Tenant ID в клиентском кабинете нет.
Кабинет hosted-клиента: созданный ключ без секрета
Кабинет hosted-клиента: созданный ключ без секрета
2026-10-15 · Работающий staging, штатный SSO синтетического клиента. Ключ создан в кабинете, перечитан после reload, проверен API-запросом и отозван; старый ключ вернул 401. На кадре только ID, секрет скрыт. Это не production-аккаунт.
  1. Создать API-ключ
  2. Отозвать этот ключ

Выполнить контрольный запрос

Задайте IAM_API_BASE адресом API из своей карточки, включая /v1, а IAM_API_KEY получите из приватного хранилища. Не размещайте ключ в URL, переписке или скриншоте. Пример проверяет учебный вопрос без генерации ответа провайдера; сам классификатор может использовать Tier 3 LLM.

curl --fail-with-body "$IAM_API_BASE/inspect" \
  -H "Authorization: Bearer $IAM_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"messages":[{"role":"user","content":"What is the capital of France?"}],"context":"docs-client-qualification"}'

Проверьте verdict и decision: Request ID, действие и policy/rule при наличии. HTTP 200 подтверждает выполнение инспекции, но не обещает allow, генерацию модели или отсутствие ложных срабатываний. На staging 15.10.2026 Router вернул решение route; Secure ошибочно отнёс этот общедоступный вопрос к CONFIDENTIAL и вернул reroute. Расхождение передано оператору.

Лимиты и доступ

  • Запросы за месяц (UTC) — использовано / месячный лимит. Запросов в секунду — постоянная скорость; burst — разрешённый кратковременный всплеск. Нулевой лимит интерфейс показывает как ∞.
  • Поля доступны клиенту только для чтения. Попросите администратора изменить конкретные значения, затем перезагрузите кабинет и сравните их.
  • Приостановка доступа клиента отличается от паузы политики. Пауза одного правила не выключает остальные; клиент из этого кабинета не отключает защиту.

Отозвать и проверить

  1. Остановите использование ключа приложением либо заранее подключите замену через приватное хранилище.
  2. Найдите точный ID и нажмите Отозвать / Revoke. Дождитесь исчезновения строки.
  3. Перезагрузите страницу: строка не должна вернуться. Новый запрос старым ключом должен получить HTTP 401; обычный выход из кабинета ключ не отзывает.

В реальном staging-контроле создано по одному ключу Router и Secure, проверены сохранение списка после reload и запросы с ключами. Оба ключа затем отозваны через UI и вернули 401. Использовался только синтетический аккаунт; на кадре нет секрета.

Если не получилось

  • Войдите через IAM.Identity после нажатия: сессия могла истечь при открытой старой странице. Выйдите, повторите SSO и проверьте свой аккаунт; перед повтором создания убедитесь, что новая строка не появилась.
  • Аккаунт не подключён: администратор должен связать эту Identity-учётную запись именно с этим продуктом. Не создавайте дубликат и не выдавайте себе операторские роли.
  • Доступ приостановлен: попросите восстановить доступ, затем выполните новый вход.
  • HTTP 401: проверьте адрес API, продукт ключа и отзыв. HTTP 429: сверьте месячный лимит и скорость с администратором. Расширение прав не исправляет эти ошибки.
  • Нет меню Политики / Маскирование: это штатный клиентский кабинет. Для согласования изменения используйте настройки администратора.

Администратору: сохранить лимиты и приостановить доступ

Клиенты · администрирование → найдите точного клиента → откройте строку. Измените Запросов в месяц (UTC), Запросов / секунду, Burst и нажмите Сохранить настройки. Полностью перезагрузите страницу, найдите тот же ID и сравните поля. Клиент также должен перезагрузить свой отдельный кабинет.

Клиент: сохранённые лимиты 90 / 8 RPS / burst 16
Клиент: сохранённые лимиты 90 / 8 RPS / burst 16
2026-10-15 · Работающий staging, только синтетический клиент. Значения сохранены в форме, перечитаны после полной перезагрузки и показаны клиенту. Приостановка и восстановление входа проверены отдельно; в конце восстановлены 100 / 10 / 20 и доступ разрешён. Письма не отправлялись.
  1. Запросов в месяц
  2. Запросов в секунду
  3. Burst
  4. Доступ разрешён
  5. Сохранить настройки

Для приостановки снимите Доступ разрешён → Сохранить настройки, перечитайте значение и проверьте новый вход клиента. Для восстановления включите этот флаг, сохраните и повторите вход. В проверке клиент увидел 90/8/16, приостановка запретила вход, а финальное состояние восстановлено до «доступ разрешён», 100/10/20. Уведомления оставались выключены; приглашения и письма об изменении не отправлялись.

Если после входа клиента в другой вкладке операторская вкладка возвращает 403, выйдите из клиентской сессии и восстановите нужный вход оператора. Отображаемая роль сама по себе не доказывает эффективную серверную сессию; не расширяйте права ради обхода ошибки.