Забуті API-ключі: як відкликати їх, не зупинивши сервіс

Внутрішня перевірка OpenRouter виявила понад 1 000 активних API-ключів у 85 співробітників; 168 ключів, за словами компанії, не використовувалися місяцями. Це цифри самоаудиту OpenRouter, а не незалежне дослідження галузі. Але навіть як окремий приклад вони показують знайому інженерну пастку: ключ можна забути, а застосунок, який на нього покладається, — ні. Компанія датувала анонс Security Center 28 вересня 2026 року.

Проблема не зводиться до того, щоб знайти найстаріші облікові дані й видалити їх. Команді потрібно встановити власника, з’ясувати, де використовується ключ, і зрозуміти, як його замінити, не вимкнувши рідкісне завдання чи забутий сервіс. Без цих відомостей відкликання доступу перетворюється з прибирання на ризикований експеримент.

Що видно в Security Center — і чого це не доводить

За описом OpenRouter, Security Center об’єднує ключі в обліковому записі та показує власника, час останнього використання, ліміт витрат і строк дії; адміністратори організації бачать усі ключі, а учасники — створені ними. Для масових дій можна вибрати до 500 ключів: вимкнути, заархівувати або встановити ліміт витрат. Вимкнення можна скасувати, архівування — ні. Це характеристики інструмента, наведені самим постачальником, а не незалежна оцінка його ефективності.

Особливо важливо сприймати статус «можна видалити» як підказку для перевірки, а не як доказ відсутності залежностей. Метрика використання показує минулі запити, але не обов’язково пояснює, якому завданню cron, аварійному сценарію чи сезонному процесу належить ключ. Сам OpenRouter радить підтвердити видалення у власника; документація з налаштувань безпеки також застерігає: перед вимкненням або архівуванням потрібно перевірити залежності.

Для обмежень мережі є окреме застереження: IP allowlist доступний адміністраторам плану Enterprise і застосовується до всіх ключів організації. Запити з адрес, яких немає у списку, відхиляються з помилкою 403, а зміни набувають чинності одразу. Тому перед увімкненням обмеження потрібно врахувати адреси production-серверів, офісної мережі та CI runners; інакше сам захід захисту може перервати легітимні виклики.

Порядок очищення: спочатку власник, потім відкликання

1. Складіть інвентар. Для кожного ключа зафіксуйте власника, призначення, середовище, споживачів, ліміт витрат і строк дії. Якщо система показує власника лише як людину, призначте також команду або сервіс, які візьмуть відповідальність, якщо ця людина піде.
2. Перевірте використання та залежності. Зіставте час останнього запиту з розкладами фонових завдань, резервними сценаріями, конвеєрами релізів і зовнішніми інтеграціями. Відсутність нещодавньої активності — привід запитати власника, а не достатня підстава для негайного видалення.
3. Зменште ризик до міграції. Якщо це підтримується, задайте розумний ліміт витрат і строк дії. Звіртеся з принципом найменших привілеїв і правилами зберігання секретів: посібник OWASP з керування секретами розглядає облік, доступ і життєвий цикл облікових даних як окремі частини процесу.
4. Створіть заміну й перенесіть споживачів. Оновіть секрет у сховищі або конфігурації розгортання, а потім переводьте застосунки поетапно. Не вставляйте значення ключа в тікети, журнали чи вихідний код.
5. Перевірте production до відкликання. Переконайтеся, що новий ключ працює в усіх відомих споживачах, зокрема в CI та рідкісних завданнях. Потім спочатку вимкніть старий ключ, якщо доступна зворотна операція; архівуйте або видаляйте його після підтвердження міграції та завершення погодженого періоду спостереження.

Послідовність «створити новий ключ → перевести застосунки → перевірити роботу → видалити старий» відповідає інструкції OpenRouter з ротації. Це рекомендований порядок, а не гарантія відсутності простою: результат залежить від того, чи знайшли ви всі системи, які використовують облікові дані.

Сервісні ключі — не всі секрети організації

Панель конкретного постачальника допомагає керувати ключами цього сервісу, але сама по собі не централізує секрети з хмарних сервісів, баз даних, CI/CD та інших API. Загальні рекомендації OWASP щодо життєвого циклу секретів охоплюють централізоване зберігання, контроль доступу, аудит, ротацію та відкликання. Окремо рекомендації Google Cloud радять обмежувати сферу застосування ключів, видаляти непотрібні облікові дані та відстежувати використання.

OpenRouter також стверджує, що Security Center використовує метадані ключів, витрати та строки дії, а не читає запити й відповіді. Це заява самого постачальника; у розглянутих джерелах незалежної технічної перевірки немає. І загалом наявність панелі не доводить, що команда вже скоротила кількість інцидентів або витрати: у вивчених матеріалах не виявлено оприлюднених результатів після запуску.