РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-10
Ротация ключа AI API: как заменить секрет и проверить отзыв
Новый ключ в кабинете ещё не означает, что приложение перестало использовать старый. Разберём потребителей, переключение и проверку фактического отзыва.
Для плановой ротации найдите всех потребителей, подготовьте новый ключ с нужными правами и прежними ограничениями, переключите их и проверьте отзыв старого. Такой порядок возможен только при поддержке совместного существования ключей. При подтверждённой утечке не сохраняйте опасный секрет ради плавного перехода.
1. Найдите реальных потребителей
Составьте список приложений, фоновых заданий, CI и локальных интеграций, использующих ключ. В учёте храните идентификатор и владельца секрета, а не его полное значение. Проверьте, откуда каждый процесс читает конфигурацию и обновляет ли её без перезапуска. Учитывайте старые экземпляры приложения и очереди, которые могут продолжить работу с прежними данными. Не вставляйте ключ в тикет, переписку или URL проверки. Если список потребителей неизвестен, обещание ротации без простоя не имеет достаточного основания даже при успешном создании нового секрета.
2. Разделите плановую смену и инцидент
При плановой замене проверьте, позволяет ли сервис иметь два действующих ключа на время перехода. При подтверждённой утечке выбирайте порядок отзыва по процедуре инцидента, не оставляя известный посторонним секрет активным ради удобства. Новый ключ сам по себе не отменяет доступ старого. Сохраните область проекта, необходимые полномочия и финансовые ограничения. Ротация предназначена для управления секретом, а не для обхода RPM, TPM или денежного потолка. Если смена требует перезапуска сервисов, согласуйте её как отдельное эксплуатационное действие.
3. Подготовьте переключение без лишних прав
Выдайте новому ключу только необходимые возможности и сохраните заданный бюджет, если это поддерживается сервисом. Разместите его в предусмотренном серверном хранилище секретов. Проверьте, что клиентская сборка, диагностический журнал и тестовые отчёты не содержат значения. Для каждой интеграции отметьте точку изменения и способ возврата при плановом переходе. Не используйте один ключ во всех проектах только ради удобства учёта. При этом конкретные scopes, сроки и одновременное действие нескольких ключей зависят от API; нельзя обещать их без опубликованного контракта.
4. Проверьте переключение и старый доступ
Подтвердите, какой идентификатор использует каждый потребитель, и выберите безопасный разрешённый метод проверки. Обычный HTTP200 не доказывает новый ключ, если ответ мог прийти из кэша или без авторизации. После отзыва проверьте старый секрет методом, для которого аутентификация действительно обязательна, не публикуя его в выводе. Учитывайте документированные задержки применения и существующие сессии. Не запускайте платную генерацию лишь ради проверки доступа, если есть подходящий способ без неё; реальные вызовы требуют выделенного бюджета. Сохраните результат и время проверки, а не только нажатие кнопки удаления.
5. Обновите учёт и устраните причину
Зафиксируйте новый идентификатор, дату, потребителей, прежние ограничения и подтверждение отзыва. Если ключ утёк, найдите канал: репозиторий, логи, клиентский код или случайная пересылка. Удаление видимого файла не отзывает уже скопированный секрет. Проверьте наблюдаемые обращения и расход в разрешённом журнале, не объявляя отсутствие известной активности доказательством отсутствия компрометации. В Tokenmost сверяйте реальные возможности кабинета и API. Это руководство не выполняет смену ключей и не изменяет лимиты; сначала подготовьте карту потребителей и сценарий проверки на тестовых данных.
Частые вопросы
Создание нового ключа отзывает старый?
Только если так устроен сервис. Обычно нужно отдельно проверить состояние старого ключа и выполнить предусмотренный отзыв.
Можно гарантировать замену без простоя?
Не без знания потребителей и контракта. Совместное действие ключей, обновление конфигурации и сессии могут иметь ограничения.
Нужно менять ключ при каждом 429?
429 требует проверки лимитов и политики ожидания. Смена ключа не является способом обходить ограничения проекта или сервиса.
Можно вернуть старый ключ после утечки?
Не используйте известный посторонним секрет как обычный путь возврата. Применяйте процедуру инцидента и подготовленный новый доступ.