Утёк API-ключ OpenAI: что делать в первые 10 минут

Ключ ушёл в публичный репозиторий, в логи или в клиентский бандл. Часы уже тикают: свежие ключи из GitHub начинают дёргать боты меньше чем через минуту после коммита. План действий — по шагам.

Шаг 1. Отзовите ключ немедленно

Откройте platform.openai.com/api-keys и удалите скомпрометированный ключ. Если сервис должен продолжать работать — сначала создайте новый ключ, переключите продакшен на него, затем удалите старый. Пара минут двойной работы лучше простоя.

Важно: «я удалил файл из репозитория» — это не отзыв. Ключ остаётся в git-истории, в форках, в кэшах поисковиков и в выдаче сканеров, которые уже успели его скопировать. Единственное, что делает утёкший ключ бесполезным, — его отзыв на стороне провайдера.

Шаг 2. Оцените ущерб

В разделе Usage посмотрите расход за последние часы и дни. Ищите:

• всплески запросов в нетипичное время (ночь, выходные);
• модели, которыми вы не пользуетесь (чужой трафик часто идёт на самые дорогие);
• рост числа запросов при неизменном вашем трафике.

Если списания заметные — напишите в поддержку OpenAI: при явной компрометации расходы иногда компенсируют, но решается это индивидуально.

Шаг 3. Найдите источник утечки

Отзыв без поиска причины — это перезарядка мины. Типичные места:

• Git-история. Проверьте репозиторий сканером: gitleaks detect или trufflehog git file://. — они найдут секреты во всей истории, не только в текущих файлах.
• Логи. Ключ, попавший в строку запроса или в отладочный вывод, оседает в логах приложения, nginx, CI и систем мониторинга.
• Клиентский код. Ключ, «зашитый» во фронтенд или мобильное приложение, публичен по определению — его достаёт любой, кто откроет DevTools.
• CI и окружение. Переменные, напечатанные в логах сборки; .env, случайно попавший в Docker-образ.

Если утечка была в публичном GitHub-репозитории — перепишите историю (git filter-repo) или, что проще и честнее, считайте всё содержимое репозитория скомпрометированным и отзовите все секреты, которые в нём когда-либо были.

Шаг 4. Сделайте следующую утечку бесполезной

Ключ утёк, потому что он лежал там, куда дотянулись чужие руки. Новый ключ, положенный в то же место, утечёт так же. Рабочие меры, по возрастанию надёжности:

1. Секреты — вне кода. Переменные окружения, .env в .gitignore, секрет-хранилища CI. Минимум, который должен быть у всех.
2. Сканер секретов в CI. gitleaks/trufflehog как pre-commit hook и обязательная проверка в пайплайне — утечка ловится до пуша.
3. Не раздавать настоящий ключ вообще. Настоящий ключ хранится в одном зашифрованном месте, а приложения, скрипты и ИИ-агенты получают прокси-токены — виртуальные ключи с привязкой к IP, своими лимитами и мгновенным отзывом. Утечка токена ничего не даёт: с чужого адреса он не работает, лимиты не дают слить баланс, а отзыв не трогает оригинал.

Частые вопросы

Достаточно ли просто перевыпустить ключ?

Перевыпуск закрывает конкретную утечку, но не причину. Если ключ хранится так же, как раньше, — новый утечёт тем же путём. Меняйте схему: настоящий ключ в хранилище, наружу — отзываемые токены.

Как быстро находят утёкшие ключи?

Публичный GitHub сканируется непрерывно. Первые чужие запросы по свежесклонированному ключу появляются в течение минуты. Считайте, что опубликованный ключ скомпрометирован мгновенно.

А если ключ нужен ИИ-агенту?

Никогда не отдавайте агенту настоящий ключ: всё, что попало в контекст модели, может оказаться в логах и трейсах. Выдайте прокси-токен — подробнее в статье о ключах для ИИ-агентов.