Ключ от API обычно утекает буднично. Его пересылают в мессенджер, чтобы коллега быстро проверил сборку, кладут в конфиг демо-стенда и забывают, копируют в рабочий блокнот. Через месяц в счёте появляется строка, которую никто не может объяснить.
Ниже рабочая механика: как ключ выдают, где он должен лежать, по каким признакам видно утечку и что делать в первые минуты. Схема одинаковая у любого провайдера, включая российский шлюз к китайским моделям.
Ключ — это доступ к вашему балансу
Технически ключ — длинная строка, которую приложение подставляет в заголовок запроса. Практически это право тратить деньги от вашего имени. Сервер не спрашивает, кто именно отправил запрос: он видит валидный ключ и выполняет работу.
Отсюда два следствия. Ключ живёт дольше, чем проект, для которого его создали. И об утечке никто не узнаёт сразу: запросы выглядят как обычный трафик, а расход растёт постепенно.
Как выдают ключи: три распространённые схемы
- Личный кабинет. Ключ создаётся вручную, у него есть имя, срок жизни и набор прав. Так работает большинство провайдеров, включая шлюзы к китайским моделям.
- Корпоративный аккаунт. Ключи выдаются сотрудникам по заявке, у каждого свой, отзыв одного не затрагивает остальные.
- Сервисный ключ для машины. Один ключ на приложение или на среду, без привязки к человеку. Удобно для продакшена, опасно тем, что меняется только вместе с релизом.
Выбирая схему, смотрите не на удобство выдачи, а на цену отзыва. Если ключ нельзя отключить за минуту без остановки сервиса, схема плохая.
Правило одной строки
Самая частая утечка случается в репозитории. Git хранит всё, что в него попало, и удаление файла следующим коммитом ничего не исправляет. Ключ остаётся в истории, а история разъезжается по форкам и клонам.
Проверка перед пушем: если в диффе появилась строка длиннее 30 символов, собранная из букв и цифр без пробелов, это почти наверняка секрет. Такую строку не отправляют в репозиторий никогда, даже в приватный.
Если ключ уже попал в публичный репозиторий, порядок обратный привычному. Сначала отзыв, потом всё остальное: чистка истории, перевыпуск, разбор. Пока вы удаляете коммиты, ключ остаётся рабочим у всех, кто успел его склонировать, а форки вы не отзовёте.
Рабочее правило звучит так: в коде живёт ссылка на переменную окружения, а не само значение. Файл со значением лежит вне репозитория и попадает в .gitignore до первого коммита, а не после инцидента.
Где ключу место
Для локальной разработки хватает файла .env, который не покидает машину. На сервере это переменные окружения контейнера или systemd, доступные только процессу приложения. Для команды — хранилище секретов: Vault, параметры в облаке, Secrets в CI. Разница в одном: у секрета есть владелец и журнал доступа.
Несколько мелочей, которые экономят нервы. Не печатайте ключ в логи, маскируйте всё похожее на токен на уровне логгера. Не выводите его в текст ошибки для клиента. Не отправляйте в трекер задач скриншот конфига, даже если кажется, что там нет ничего важного.
Отдельная история — пересылка ключа в чате. Даже если сообщение удалить, оно остаётся в копиях на телефонах и в почтовых уведомлениях. Для разовой помощи коллеге заведите временный ключ с коротким сроком жизни: его не жалко отключить через час.
Ротацию стоит поставить в календарь, а не вспоминать о ней после инцидента. Раз в квартал перевыпускайте сервисные ключи и удаляйте те, что не использовались месяц. Это скучная процедура, которая экономит самый дорогой ресурс — спокойствие руководителя.
Признаки утечки
Сигналы приходят с двух сторон. Со стороны счёта — рост расхода без роста продукта: запросы идут ночью, в выходные, из городов, где у вас нет пользователей. Со стороны инфраструктуры — обращения с чужих адресов, всплеск ошибок 401 и 429 по одному ключу.
Если заметили хотя бы один признак, порядок такой: отозвать ключ, выпустить новый, урезать права до минимально нужных, посмотреть журнал запросов за последние сутки. Разбор причин — после, потому что счётчик тикает сейчас.
Разделяйте ключи по средам и задачам
Один ключ на всё удобен ровно до первого инцидента. Держите отдельные ключи для разработки, тестов и продакшена. Внутри продакшена разделите то, что генерирует контент, и то, что отвечает клиентам в чате: у второго сценария нагрузка непредсказуема.
Лимит расходов ставьте на каждом ключе отдельно. Тогда сбой одного сценария не съедает бюджет остальных. Как считать такой лимит, разбирали в статье о лимитах расходов на API. Там же про то, как выбрать порог, после которого приходит уведомление.
Чек-лист на пять минут
- Ключ лежит в переменной окружения, а не в коде.
- Файл с секретом в .gitignore, история репозитория проверена поиском по префиксу ключа.
- У ключа понятное имя: среда и сценарий.
- Права урезаны: только те модели и методы, что реально нужны.
- Лимит расходов задан, уведомление о превышении включено.
- Есть второй человек, который знает, где отозвать ключ.
Последний пункт не формальность. Отзыв доступа часто делают в панике и в одиночку, а посмотреть, что ключ успел натворить, лучше вдвоём.
Откройте репозиторий и поищите по первым символам своих ключей. Проверьте .gitignore. Заведите отдельный ключ для тестов и удалите старый общий. Эти три действия не требуют бюджета и закрывают большинство бытовых утечек.
Если работаете с несколькими моделями, добавьте проверку прав: ключ для Qwen не обязан уметь вызывать DeepSeek. Чем уже права, тем дешевле ошибка. Про перенос кода на другую модель есть отдельный разбор — миграция с OpenAI на DeepSeek.
Где мы в этой схеме
Китай-API — российский шлюз к моделям DeepSeek, Qwen, GLM и Kimi. Доступ выдаётся ключом, совместимым с OpenAI SDK, оплата в рублях, для юрлица счёт и закрывающие документы: об этом подробно в статье про оплату API юрлицом. Ключи раздельные по среде, лимиты расходов настраиваются в кабинете.
Продукт в подготовке: запуск скоро, идёт приём заявок на ранний доступ. Если хотите проверить схему на своём сценарии, оставьте заявку на ранний доступ — пригласим, когда откроем кабинет.