Витік API-ключа: права й мінімальні дозволи

Коли мова заходить про витік API-ключа, більшість уявляє одне: «монети вивели». Насправді найпоширеніший сценарій інший — право на виведення зазвичай вимкнене, тож вивести монети в блокчейн зловмисник не може, зате може твоїми ж грошима наторгувати на свою користь, а ще — перекидати кошти між твоїми власними рахунками. Поки ти це помітиш, гроші все ще на рахунку, просто їх стало менше.

Ця стаття — про механіку й наслідки: що означає кожен із трьох типів прав, що зловмисник після витоку зможе зробити, а чого не зможе, який замок дає найбільше за найменші зусилля, звідки ключі зазвичай витікають і в якому порядку діяти, коли витік уже стався. Якщо потрібен список, який проходять по пунктах, візьми Чек-лист безпеки API; тут — та половина, що пояснює «чому».

Три типи прав — спершу розберімося

Назви в різних біржах трохи різняться, але права, які видають при створенні API-ключа, майже завжди зводяться до трьох груп — від найменш небезпечної до найнебезпечнішої:

Право	Що дозволяє	Що означає після витоку
Читання	дивитися ринок, баланс, історію ордерів	розкриття інформації, кошти зрушити не можна
Торгівля	виставляти й скасовувати ордери, відкривати й закривати позиції; за документацією OKX — іще й перекази фандинговий рахунок ↔ торговий рахунок, перекази між основним рахунком і субрахунками, а також частина налаштувань рахунку	монети не вийдуть у блокчейн, але їх можуть проторгувати, а ще — перекинути між твоїми власними рахунками
Виведення в блокчейн	вивести активи на адресу в блокчейні (окреме право Withdraw, у право торгівлі не входить)	фактично втрата монет

Право на виведення вмикати не варто майже ніколи. Причина пряма: автоматизованій торгівлі воно не потрібне. Скрипт стратегії має купувати й продавати, а не виносити монети кудись. Можливо, промайне думка «а якщо я напишу скрипт, що сам зводить залишки на один рахунок?» — таке краще робити руками. Ключ із правом виведення після витоку майже не лишає вікна на порятунок: один запит — і активи вже на чужій адресі, а переказ у блокчейні не відкотити. Кілька зекономлених ручних дій цього ризику не варті.

Ще одна річ, про яку варто пам'ятати: на деяких біржах право виведення реально працює лише в парі з білим списком адрес для виводу, і правила в кожної свої. Але «додав білий список адрес — і безпечно» — небезпечне спрощення: сам білий список теж є налаштуванням рахунку, а чи можна його змінити й чи діє після зміни період очікування — залежить від біржі. Надійний варіант залишається тим самим: не вмикати.

Як саме твій скрипт виставляє ордери з ключем

Щоб зрозуміти ризик ключа, спершу треба розібратися, хто і в який спосіб ним користується.

Твоя стратегія працює на власному комп'ютері або на сервері, і вона не «заходить» на біржу — вона шле запити через HTTP-інтерфейс. У кожному запиті йдуть apiKey і підпис, обчислений за допомогою секретного ключа; біржа перевіряє підпис, переконується, що «це надіслав власник того ключа», і виконує. У цьому ланцюжку немає ні підтвердження людиною, ні SMS-коду, ні додаткового вікна — ключ і є посвідченням особи.

Знімок головної сторінки офіційної документації CCXT: ліворуч кілька рядків прикладу виклику на TypeScript, праворуч відповідь із ринковими даними в уніфікованому форматі, а нижче — теги бірж, які він підтримує — Головна сторінка офіційної документації CCXT, знімок зроблено 2026-09. Один уніфікований інтерфейс до понад сотні бірж — саме через такі бібліотеки твій скрипт бере API-ключ і виставляє ордери.

Переважна більшість не пише підпис самотужки, а бере готову бібліотеку (уніфіковані обгортки на кшталт тієї, що на знімку, — найпоширеніший варіант), вписує ключ у конфіг, а решту віддає бібліотеці. Зручно, але це означає й інше: твій ключ у відкритому вигляді лежить у якомусь конфігу, змінній середовища або прямо в коді — а саме звідти й починається витік.

Після витоку: що зловмисник зможе, а чого не зможе

Припустімо, у твоєму ключі ввімкнені лише читання й торгівля, виведення вимкнене, і ключ опинився в чужих руках.

Того, чого зловмисник не зможе, насправді лише дві речі: вивести монети на адресу в блокчейні (для цього потрібне окреме право виведення) і зайти у твій вебкабінет (для цього потрібні облікові дані). Тож із перших хвилин не варто виходити з припущення «монети вже вивели».

Але список «не зможе» коротший, ніж багатьом здається. Документація OKX визначає право торгівлі як «виставлення й скасування ордерів, переказ коштів, зміна налаштувань» — тобто перекази між фандинговим і торговим рахунками, перекази між основним рахунком і субрахунками, а також частина налаштувань рахунку доступні вже з правом торгівлі. Теза «ввімкнена лише торгівля, виведення вимкнене, отже й переказів він не зробить» не витримує перевірки. Гроші справді не вийдуть за межі твоєї системи рахунків, але всередині неї їх пересунуть — а це рівно той крок, яким зловмисник зводить кошти на один торговий рахунок, щоб потім укласти на ньому вигідні собі угоди.

Те, що він зможе, і є справжньою проблемою:

Наторгувати твоїм балансом собі в кишеню. Зловмисник заздалегідь ставить власні ордери в парі з дуже слабкою ліквідністю, а потім твоїм рахунком б'є по них ринковим ордером — твої гроші виконуються за відверто поганою ціною, а різниця осідає в нього. Кошти рахунку не покидали, але вартість уже перетекла. Саме про це мало хто думає, і саме тут найбільша діра в тезі «ввімкнув лише торгівлю — значить безпечно».
Стерти баланс комісіями. Нічого вигадливого не потрібно: достатньо раз за разом торгувати проти себе, щоб потроху з'їдати кошти.
Рухати твої відкриті позиції. Зняти твої ордери, закрити позиції або відкрити на ф'ючерсах велику позицію в протилежний бік.
Переказувати між твоїми ж рахунками. Між фандинговим і торговим, між основним і субрахунками. Монети не залишають твого імені, але той поділ на субрахунки, яким ти розмежовував ризик, зникає одним переказом.
Змінити частину налаштувань рахунку. Режим рахунку, плече — тобто те, що йде через інтерфейс; що саме змінюється, дивись у документації своєї біржі.

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

Білий список IP — найвигідніший замок

Якщо з усієї статті лишити одну пораду, це буде вона: прив'яжи до ключа білий список IP.

Логіка проста: ключ діє тільки в запитах із зазначених адрес. Ключ витік — а скористатися ним не вийде, виклик із чужої машини відхиляється одразу. Цей замок не залежить ні від того, чи згадав ти вчасно змінити пароль, ні від того, чи помітив аномалію: він структурний, а не тримається на людській сумлінності.

Коштує це теж небагато. Скрипт працює на сервері зі сталою адресою (навіть найдешевшому) — налаштував один раз і забув. Тим, у кого все крутиться на домашньому інтернеті з плавучим IP, це здасться морокою — і це ще один аргумент перенести стратегію на машину зі сталою адресою, не лише заради безперебійного живлення.

Є й правило, яке легко проґавити: за офіційною документацією OKX ключ без прив'язаного IP, але з правом торгівлі чи виведення, втрачає чинність після 14 днів без активності — тож ключ без білого списку не просто ризикованіший, він ще може одного дня відвалитися сам і лишити скрипт без з'єднання без видимої причини. І ще: до одного ключа можна прив'язати до 20 IP (підтримуються IPv4/IPv6 та підмережі), тож лишити запас під сценарії, де вихідна адреса змінюється, зовсім не складно.

Але треба чітко розуміти, чого він не спиняє: білий список захищає від «хтось узяв твій ключ і викликає звідкись іще», а не від «зламали саме твою машину». Щойно машину контролює хтось інший, запити йдуть з адреси, яка в білому списку, і замок стає декорацією. Тому він додається до мінімальних дозволів, а не замінює їх.

Звідки ключі витікають найчастіше

Ключі рідко «зламують» — переважно вони виходять назовні самі. За частотою, яку доводиться бачити:

Закомічений у Git. Вписаний просто в код — і одним недбалим комітом опиняється в репозиторії. Навіть якщо репозиторій приватний і навіть якщо ти потім прибрав той рядок, в історії він лишається; а публічні репозиторії спеціально сканують у пошуках таких рядків.
Потрапив на знімок екрана. Скидаєш скріншот термінала з проханням допомогти, записуєш демонстрацію — і той рядок конфіга саме в кадрі. Ключ — довгий набір випадкових символів, око по ньому просто ковзає, але він там є.
Вставлений у чат. Копіюєш текст помилки разом із конфігом, у чаті кількасот людей, і хто там сидить — ти не знаєш.
Встановлений «скрипт стратегії» невідомого походження. Це найважчий випадок: тобі дають «бота, що точно заробляє», і просять вписати туди apiKey. До чийого сервера він під'єднується й куди відправляє ключ — тобі невідомо. Будь-яку сторонню програму, яка просить API-ключ, за замовчуванням варто вважати такою, що його забере.
Логи й повідомлення про помилки. Під час налагодження виводиш увесь об'єкт запиту — і ключ потрапляє в лог-файл, а права на логи зазвичай вільніші, ніж на код, та ще й логи часто відвантажують у якийсь зовнішній сервіс.

Як мінімальні дозволи виглядають на практиці

«Мінімальні дозволи» — не гасло; якщо розкласти, це кілька цілком конкретних дій:

Один ключ — одне призначення. Для дашборда й статистики — ключ лише на читання, для торгової стратегії — ключ із торгівлею, і це два різні ключі. Витече той, що для дашборда, — втрата зведеться до інформації; та ще й при інциденті ти одразу бачиш, який саме канал протік.
Одна стратегія — один ключ. Коли одночасно крутиться кілька стратегій, не роби їм спільний ключ: при проблемі зупиняєш один, решта працює далі.
Регулярно міняй, невживане видаляй. Кожен ключ — це відкрита поверхня. Створив для тесту — видали одразу після тесту; купа давно забутих ключів у кабінеті — це найчастіша прихована пробоїна.
Ключ не має потрапляти в код. Тримай його у змінній середовища або в локальному конфігу, який нікуди не синхронізується, а сам конфіг впиши в .gitignore.
Гроші під скрипт відокремлені від основної позиції. Якщо біржа підтримує субрахунки, виділи капітал під квант окремо, щоб основна позиція в цьому не брала участі. Помилка стратегії чи інцидент із ключем випалять лише ту частину, яка має межу. Важливий нюанс: цей поділ тримається тільки на ключі самого субрахунку — ключ основного рахунку, якщо в ньому є право торгівлі, переказує кошти між основним і субрахунками, тож запускати стратегію з ним означає знову відкрити той поділ.

Порядок дій, коли витік уже стався

Спершу видали ключ, причини — потім. Зайди в кабінет і просто видали той ключ — не зміни права, а видали. Забрати в нападника можливість діяти важливіше, ніж з'ясувати правду; причини можна розбирати згодом.
Зупини програми, що працюють. Інакше стратегія почне безперервно сипати помилками через недійсний ключ і може запустити якусь дивну логіку повторів.
Перевір відкриті ордери й позиції. Зніми всі ордери, які виставляв не ти, подивися, чи не з'явилися нові позиції — особливо уважно на ф'ючерсах.
Перегорни недавні угоди. Шукай виконання за явно відхиленою ціною й ордери, яких ти не робив. Саме цей крок показує реальний розмір втрат.
Перевір історію переказів і субрахунки. Право торгівлі саме собою дозволяє перекази, тож самих ордерів мало: перегорни рух між фандинговим і торговим рахунками, між основним рахунком і субрахунками, а потім по черзі звір залишки на кожному субрахунку.
Звір налаштування рахунку. Режим рахунку, розмір плеча й інші параметри, які змінюються через інтерфейс, — перевір, чи це справді твої значення.
Заміни облікові дані. Пароль і двофакторну автентифікацію разом, бо ти ще не знаєш напевно, що витік обмежився ключем.
Створи ключ заново — цього разу з мінімальними правами й білим списком IP. А потім повернися й пройди шляхи витоку: код, знімки екрана, логи, встановлені скрипти — по одному.

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

Безпека й попередження про ризик: у статті йдеться про загальні принципи, а назви прав, правила білого списку IP і можливості субрахунків у кожної біржі свої — перед створенням ключа орієнтуйся на офіційну документацію тієї платформи, якою користуєшся. Ціни на криптоактиви різко коливаються, квант-стратегія не гарантує прибутку, а ф'ючерси й плече можуть призвести до втрати всього капіталу. Ця стаття не є інвестиційною порадою і не оцінює безпеку чи стабільність інтерфейсів якоїсь конкретної платформи.

Поширені запитання

Ввімкнена лише торгівля, виведення вимкнене — при витоку кошти в безпеці?

У блокчейн активи не підуть, але це ще не безпека. За документацією OKX право торгівлі вже містить перекази коштів і частину налаштувань рахунку, тож той, хто отримав ключ, пересуне гроші між фандинговим, торговим рахунками й субрахунками, а ще може твоїм балансом виконатися за відверто поганою ціною в малоліквідній парі й забрати різницю собі, крутити угоди проти себе, поки не з'їсть кошти комісіями, закрити твої позиції або відкрити на ф'ючерсах зустрічну. Гроші лишаються на твоє ім'я — просто їх може стати менше або вони можуть опинитися на іншому рахунку. Саме тому мінімальні дозволи працюють лише в парі з білим списком IP.

Коли взагалі потрібне право на виведення?

Для переважної більшості тих, хто займається квантом, — ніколи. Виведення відповідає за відправлення монет на адресу в блокчейні, а скрипт стратегії має виставляти ордери. Тут легко заплутатися в одному: перекази між фандинговим і торговим рахунками та між основним рахунком і субрахунками доступні вже з правом торгівлі, тож заради переказів виведення вмикати не треба. Після витоку ключа з правом виведення вікна на порятунок практично немає: один запит — і активи на чужій адресі, а переказ у блокчейні незворотний. Якщо справді треба вивести — краще зроби це руками, ніж вимінюй таку відкриту поверхню на кілька зекономлених кліків.

Що важливіше — білий список IP чи мінімальні дозволи?

Вони перекривають різні шляхи й не замінюють одне одного. Мінімальні дозволи визначають, які двері цей ключ узагалі відчиняє; білий список IP — на якій машині цей ключ чинний. Білий список не врятує, якщо зламали саме твою машину, а мінімальні дозволи не завадять комусь виставляти ордери з дозволеної тобою адреси. Зарахувати можна лише те, що зроблено і те, і те.

Чи можна кільком програмам користуватися одним API-ключем?

Краще ні. Спільний ключ означає, що через проблему в будь-якій одній програмі доведеться зупиняти все, що на нього спирається, та ще й при інциденті майже неможливо зрозуміти, який саме канал протік. Розділяй за призначенням: для дашборда й статистики — ключ на читання, для кожної торгової стратегії — свій ключ із торгівлею. Створити кілька ключів коштує дрібницю, а при розборі й зупинці втрат виграш великий.

Хтось дав скрипт стратегії й просить вписати API-ключ — можна?

За замовчуванням — ні. Ти не можеш знати, куди той код відправляє ключ, а щойно він отримає право торгівлі, твоїм балансом можна робити вигідні комусь іншому речі. Якщо все ж хочеш спробувати сторонню програму, то принаймні переконайся, що код відкритий для читання і ти сам простежуєш шлях ключа всередині, а запускай спершу на субрахунку з мізерною сумою й із налаштованим білим списком IP. А там, де обіцяють гарантований прибуток, ризик не обмежується самим лише ключем.

Помітив, що ключ міг витекти — що зробити першим?

Видали той ключ, саме видали, а не зміни права. Забрати в нападника можливість діяти терміновіше, ніж з'ясувати причину. Після видалення зупини локальні програми, зніми незнайомі ордери, перевір позиції й недавні угоди; оскільки право торгівлі саме собою дозволяє перекази, перегорни ще й історію переказів, звір залишки на субрахунках і подивися, чи не змінилися налаштування рахунку. Далі заміни пароль і двофакторну автентифікацію, і лише наостанок створи новий ключ із мінімальними правами й білим списком IP, а тоді пройди можливі шляхи витоку.

Коли ці кілька речей зроблено, ризик у частині API-ключа перестає бути справою везіння й отримує стелю. Хто хоче пройтися по пунктах — бери Чек-лист безпеки API; хто ще не дійшов до написання скриптів — почни з тексту Що таке квант-трейдинг. І ще одне: хоч як добре бережи ключ, якщо сама стратегія збиткова, це не врятує — перш ніж заводити справжні гроші, прожени її в демо OKX.

Що буде при витоку API-ключа: права й мінімальні дозволи