Раздел
Модели и API
Сложность
средняя
Обновлено
2026-05-20
Сценарий

Модели и API

Доказательства

Данные, права, ограничения и метрики в тексте статьи.

Аудит

Короткий разбор процесса перед пилотом.

Короткий ответ

YandexGPT API key нельзя выдавать как личный пароль разработчика и класть в репозиторий. Для рабочего контура нужен отдельный сервисный аккаунт, минимальные роли, хранение в секретах, лимит расходов, журнал использования и план ротации.

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

Безопасная схема

Минимальная схема для пилота:

  1. Создать отдельный сервисный аккаунт под приложение.
  2. Выдать только нужные роли для AI Studio и связанных ресурсов.
  3. Создать API key или другой разрешенный способ аутентификации.
  4. Положить секрет в vault, CI/CD секреты или runtime environment.
  5. Не отдавать ключ во frontend.
  6. Включить логирование запросов и расходов.
  7. Проверить ротацию на тестовом контуре.

Если ключ нужен только для локального эксперимента, все равно фиксируйте владельца, folder, роли и дату удаления.

Что нельзя делать

Не делайте так:

  • один ключ на все проекты;
  • ключ в клиентском JavaScript;
  • ключ в Git, README, issue или чате;
  • личный ключ сотрудника в продакшене;
  • роли шире, чем нужны приложению;
  • отсутствие лимита бюджета;
  • нет владельца и даты пересмотра.

Публичный сайт должен видеть только public-настройки вроде PUBLIC_YANDEX_METRICA_ID. API key для YandexGPT не является public-настройкой.

Роли и сервисный аккаунт

Сервисный аккаунт позволяет отделить приложение от личных учетных записей. Для каждого продукта лучше иметь свой аккаунт и понятное имя: например woghan-ai-portal-fm-prod или support-assistant-fm-dev.

Проверьте:

ВопросЧто зафиксировать
Где работает приложениеfolder, окружение, runtime
Зачем нужен ключсценарий и API
Какие роли выданытолько минимально необходимые
Кто владелецкоманда и ответственный
Где хранится секретvault, CI/CD, переменные окружения
Когда ротироватьдата и процедура

Чем уже контур, тем проще отключить ключ без поломки соседних систем.

Хранение секрета

Рабочие варианты:

  • секреты CI/CD;
  • секреты хостинга;
  • vault;
  • переменные окружения на сервере;
  • локальный .env, который не коммитится.

Для репозитория оставьте только пример имени переменной:

YANDEXGPT_API_KEY=

Не добавляйте реальный ключ в .env.example. Если в проекте есть .env.production, убедитесь, что файл не содержит приватных секретов или не попадает в публичный артефакт.

Проверка доступа

После выдачи ключа проверьте:

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

Лог должен показывать факт вызова, сценарий, статус, стоимость и correlation ID. Сам prompt с персональными данными может требовать отдельной политики хранения.

Стоимость и ROI

Ключ сам ничего не стоит, но открывает расходы. До запуска определите:

  • ожидаемое число запросов;
  • размер входного и выходного контекста;
  • retries;
  • RAG-поиск;
  • ручную проверку;
  • лимит на день или месяц;
  • поведение при превышении лимита.

Если лимитов нет, ошибка в цикле агента может быстро превратить тест в неожиданный счет.

Ротация и инциденты

План ротации нужен до утечки:

  1. Создать новый ключ.
  2. Обновить секрет в runtime.
  3. Перезапустить приложение.
  4. Проверить запросы.
  5. Отключить старый ключ.
  6. Зафиксировать дату и владельца.

Если ключ попал в Git или чат, считайте его скомпрометированным. Не “удаляйте строку и продолжайте”; создайте новый ключ и отключите старый.

Чеклист

  • Ключ выдан сервисному аккаунту.
  • Роли минимальны.
  • Секрет не попадает во frontend.
  • Секрет не записан в Git.
  • Есть лимит расходов.
  • Есть журнал вызовов.
  • Есть процедура ротации.
  • Есть владелец и дата пересмотра.

FAQ

Можно ли использовать личный ключ разработчика?

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

Где хранить ключ?

В vault, секретах CI/CD, секретах хостинга или переменных окружения сервера. Не в frontend и не в документации.

Что делать при утечке?

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

Что читать дальше?

Читайте YandexGPT API и стоимость LLM API.

Источники

Следующий шаг

Проверьте этот сценарий на своем процессе

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

Разобрать YandexGPT API key Вернуться к маршруту раздела →