Как безопасно хранить API-ключи для AI-сервисов

Скомпрометированный API-ключ — это открытый кошелёк: любой, кто его получил, тратит ваш баланс на свои запросы. Поэтому модель угроз строится не вокруг «секретности ради секретности», а вокруг денег: где ключ лежит, кто его читает, что ограничивает ущерб.

Два числа определяют blast radius: spend limit ключа и скорость, с которой вы замечаете аномалию. Всё ниже — про то, как сузить оба.

Единственное допустимое место — секреты среды выполнения на сервере: env-переменные процесса, secret manager, хранилище CI. Клиентское приложение ходит в ваш backend, backend подставляет Authorization и идёт в NormaHub.

Разделяйте ключи: тестовый для разработки, отдельный для продакшена, отдельный для каждого внешнего сервиса и агента. Отзыв одного ключа тогда не останавливает весь продукт.

Постоянный ключ в браузере, мобильном приложении или URL — это уже утечка, даже если «никто не смотрит». Секреты оседают и там, где их не ждут: логи reverse-proxy, crash-дампы, тексты исключений HTTP-клиента, слои Docker-образов.

Проверяйте не только исходники. Сканер секретов должен гоняться по репозиториям регулярно, а не один раз при настройке.

Порядок строгий: сначала отозвать или отключить ключ, потом смотреть историю расходов, потом выпускать новый. Обновите secret store и перезапустите только зависимые процессы — полный редеплой не нужен.

Удаление строки из Git ничего не чинит: значение живёт в истории, форках и артефактах. Скомпрометированный ключ считается мёртвым с момента подозрения, даже если источник утечки уже удалён.

Spend limit — единственная защита, которая работает, пока вы спите. Даже щедрый лимит лучше его отсутствия: злоумышленник упрётся в потолок, а вы получите время на ротацию.

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

Прогоните этот список перед первым боевым запросом. Каждый невыполненный пункт — это инцидент, отложенный во времени.