- Раздел
- Модели и API
- Сложность
- средняя
- Обновлено
- 2026-05-20
Модели и API
ДоказательстваДанные, права, ограничения и метрики в тексте статьи.
АудитКороткий разбор процесса перед пилотом.
Короткий ответ
YandexGPT API key нельзя выдавать как личный пароль разработчика и класть в репозиторий. Для рабочего контура нужен отдельный сервисный аккаунт, минимальные роли, хранение в секретах, лимит расходов, журнал использования и план ротации.
Ключ нужен приложению, а не человеку. Если ключ выдан на личный аккаунт, используется в нескольких проектах и лежит в .env без контроля, команда не сможет быстро понять, кто его использует, где он утек и что отключится при ротации.
Безопасная схема
Минимальная схема для пилота:
- Создать отдельный сервисный аккаунт под приложение.
- Выдать только нужные роли для AI Studio и связанных ресурсов.
- Создать API key или другой разрешенный способ аутентификации.
- Положить секрет в vault, CI/CD секреты или runtime environment.
- Не отдавать ключ во frontend.
- Включить логирование запросов и расходов.
- Проверить ротацию на тестовом контуре.
Если ключ нужен только для локального эксперимента, все равно фиксируйте владельца, 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-поиск;
- ручную проверку;
- лимит на день или месяц;
- поведение при превышении лимита.
Если лимитов нет, ошибка в цикле агента может быстро превратить тест в неожиданный счет.
Ротация и инциденты
План ротации нужен до утечки:
- Создать новый ключ.
- Обновить секрет в runtime.
- Перезапустить приложение.
- Проверить запросы.
- Отключить старый ключ.
- Зафиксировать дату и владельца.
Если ключ попал в Git или чат, считайте его скомпрометированным. Не “удаляйте строку и продолжайте”; создайте новый ключ и отключите старый.
Чеклист
- Ключ выдан сервисному аккаунту.
- Роли минимальны.
- Секрет не попадает во frontend.
- Секрет не записан в Git.
- Есть лимит расходов.
- Есть журнал вызовов.
- Есть процедура ротации.
- Есть владелец и дата пересмотра.
FAQ
Можно ли использовать личный ключ разработчика?
Для короткого локального теста возможно, но не для продукта. В рабочем контуре нужен сервисный аккаунт и управляемые секреты.
Где хранить ключ?
В vault, секретах CI/CD, секретах хостинга или переменных окружения сервера. Не в frontend и не в документации.
Что делать при утечке?
Сразу создать новый ключ, переключить приложение и отключить старый. Затем проверить логи и места, куда ключ мог попасть.
Что читать дальше?
Читайте YandexGPT API и стоимость LLM API.
Источники
Следующий шаг
Проверьте этот сценарий на своем процессе
Опишите систему учета, данные, ограничения по правам и ожидаемый эффект. Ответим, что можно запускать в пилот, а где сначала нужен порядок в процессе.