Ключи API: хранение, лимиты и ротация без простоя

Ключ от API — это одновременно пароль и платёжное средство. Утёкший ключ не просто даёт доступ к вашим данным, он ещё и тратит ваши деньги, пока вы об этом не узнаете. При этом хранение ключей почти всегда откладывают на потом.

Один ключ на всю команду — плохая идея

Когда ключ один, у вас нет ответов ни на один важный вопрос. Кто израсходовал бюджет за прошлую неделю? Какой сервис начал слать вдвое больше запросов? Что произойдёт, если ключ утечёт через репозиторий подрядчика?

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

Где ключ не должен лежать

Список короткий, но нарушается регулярно.

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

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

Лимит расхода как страховка

Лимит на ключ — самая дешёвая защита из существующих. Он спасает не только от утечки, но и от собственных ошибок: цикл, который случайно ушёл в бесконечность в пятницу вечером, обойдётся в сумму лимита, а не в весь баланс.

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

Отдельно настройте уведомление о приближении к порогу. Узнавать о перерасходе из отказов в продакшене — плохой способ.

Ротация: как менять ключ без простоя

Смена ключа кажется страшной, пока не разложена по шагам. Ключ ротируется по расписанию, а не только после инцидента: если менять его раз в квартал, к моменту реальной утечки процедура уже отлажена.

Главное правило — новый ключ выпускается до того, как отзывается старый. Оба работают одновременно, конфигурация обновляется, сутки вы наблюдаете за ошибками, и только потом старый ключ отзывается. Если что-то пошло не так, возврат занимает одну правку конфигурации.

Что делать при утечке

Порядок действий стоит написать заранее, потому что в момент инцидента думать некогда.

1. Отозвать ключ. Немедленно, до выяснения обстоятельств.
2. Выпустить новый и обновить конфигурацию.
3. Посмотреть журнал: когда начались чужие запросы и сколько израсходовано.
4. Найти источник утечки — репозиторий, лог, скриншот, переписка.
5. Проверить, не утекли ли остальные ключи тем же путём.

Пункт пятый пропускают чаще всего, а он важнее остальных: ключи редко утекают поодиночке.

Если ключ хотя бы на минуту оказался в публичном репозитории, считайте его скомпрометированным независимо от того, удалили вы коммит или нет. История доступна, и сканеры находят такие ключи за минуты.

Разграничение внутри команды

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

Ключ без описания через полгода превращается в проблему: отозвать страшно, потому что неизвестно, что сломается. Заведите правило: у каждого ключа есть владелец, назначение и дата следующей ротации.

Уход сотрудника и смена подрядчика

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

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

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

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

Автоматизация проверок

Часть работы можно снять с людей. Сканер секретов в системе сборки ловит ключ, случайно попавший в коммит, ещё до того, как код уйдёт в общий репозиторий. Настраивается это один раз и работает дальше само.

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

Короткий чек-лист

• Ключи только в переменных окружения или в хранилище секретов.
• Отдельный ключ на каждое окружение и каждого подрядчика.
• Лимит расхода на каждом ключе, уведомление о приближении к порогу.
• Ротация по расписанию, а не только после инцидента.
• Список действующих ключей с владельцем и назначением.
• Заголовок авторизации не попадает в логи.

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