API-ключ криптобиржи: права, IP whitelist и отзыв

Что должен уметь безопасный API-ключ

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

Ключ — отдельная учётная запись машины, а не копия пароля

Обычно API key идентифицирует интеграцию, а API secret участвует в подписи запросов. Secret нельзя вставлять в тикет поддержки, публичный репозиторий, таблицу или скриншот; после создания площадка может больше не показать его целиком. Это не приватный ключ блокчейн-кошелька, но утечка способна дать злоумышленнику все действия, разрешённые именно этой связке. Пароль аккаунта при этом может остаться неизвестен.

Что меняет каждое разрешение
Право	Что обычно позволяет	Основной ущерб	Безопасная граница
Read	Читать баланс, историю и ордера	Утечка позиций и торговой активности	Выдавать только системе учёта, если торговля не нужна
Trade	Создавать и отменять ордера	Убыточные сделки, комиссии, воздействие на ликвидный портфель	Отдельный ключ на один бот и нужные рынки, если площадка поддерживает scope
Transfer	Перемещать средства между внутренними сегментами	Изменение залога или доступного баланса	Не считать эквивалентом withdraw: читать точное описание площадки
Withdraw	Запрашивать внешний вывод, если разрешено	Прямой риск потери средств	По умолчанию выключено; включать только для доказанной задачи и дополнительного контроля

Что меняет каждое разрешение

Право: Read
Что обычно позволяет: Читать баланс, историю и ордера
Основной ущерб: Утечка позиций и торговой активности
Безопасная граница: Выдавать только системе учёта, если торговля не нужна

Право: Trade
Что обычно позволяет: Создавать и отменять ордера
Основной ущерб: Убыточные сделки, комиссии, воздействие на ликвидный портфель
Безопасная граница: Отдельный ключ на один бот и нужные рынки, если площадка поддерживает scope

Право: Transfer
Что обычно позволяет: Перемещать средства между внутренними сегментами
Основной ущерб: Изменение залога или доступного баланса
Безопасная граница: Не считать эквивалентом withdraw: читать точное описание площадки

Право: Withdraw
Что обычно позволяет: Запрашивать внешний вывод, если разрешено
Основной ущерб: Прямой риск потери средств
Безопасная граница: По умолчанию выключено; включать только для доказанной задачи и дополнительного контроля

Минимальные права выбирают от действия, а не от удобства

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

Decision tool: задача и минимальная конфигурация
Задача	Стартовые права	IP-ограничение	Stop-сигнал
Портфельный трекер	Read only	Статический egress IP, если он есть	Приложение просит trade или withdraw
Торговый бот	Read + нужный trade scope	Разрешённые IP серверов бота	Один key обслуживает несколько несвязанных ботов
Бухгалтерский экспорт	Read only на отдельном key	IP рабочего шлюза	Secret передают через обычный документ или чат
Автоматический вывод	Только после отдельной risk review	IP, лимиты и адресные ограничения площадки	Нельзя независимо ограничить направление и сумму

Decision tool: задача и минимальная конфигурация

Задача: Портфельный трекер
Стартовые права: Read only
IP-ограничение: Статический egress IP, если он есть
Stop-сигнал: Приложение просит trade или withdraw

Задача: Торговый бот
Стартовые права: Read + нужный trade scope
IP-ограничение: Разрешённые IP серверов бота
Stop-сигнал: Один key обслуживает несколько несвязанных ботов

Задача: Бухгалтерский экспорт
Стартовые права: Read only на отдельном key
IP-ограничение: IP рабочего шлюза
Stop-сигнал: Secret передают через обычный документ или чат

Задача: Автоматический вывод
Стартовые права: Только после отдельной risk review
IP-ограничение: IP, лимиты и адресные ограничения площадки
Stop-сигнал: Нельзя независимо ограничить направление и сумму

Безопасная настройка должна быть воспроизводимой

1
Назовите владельца и задачу
Запишите, какой сервис использует key, кто отвечает за него и когда доступ нужно пересмотреть. Один key не должен быть общей бессрочной связкой команды.
2
Снимите лишние permissions
Начните с read и добавляйте только действие, без которого интеграция не работает. Сохраните снимок выбранных прав без secret.
3
Ограничьте источник
Если площадка поддерживает IP allowlist — список разрешённых IP-адресов или диапазонов — внесите только стабильные egress-адреса сервиса. Динамический домашний IP требует отдельного operational plan.
4
Передайте secret один раз
Поместите его в менеджер секретов или зашифрованное хранилище, исключите из логов и переменных, которые печатает CI — автоматизированный pipeline сборки и развёртывания. Не отправляйте копии разработчикам.
5
Проверьте отказ
Убедитесь, что запрос с неразрешённого IP и действие вне scope действительно отклоняются. Затем проверьте, что отзыв key немедленно останавливает интеграцию.

При утечке ротация начинается с отзыва

Recovery без повторного использования secret

1
Остановите интеграцию
Отключите задания, которые могут продолжать отправлять запросы или путать incident log собственными повторами.
2
Отзовите подозрительный key
Удалите либо деактивируйте именно скомпрометированную связку в кабинете биржи. Смена пароля не доказывает, что API credential отозван.
3
Зафиксируйте факты
Сохраните key label, permissions, разрешённые IP, last-used данные, ордера, выводы и время отзыва. Сам secret в доказательства не включают.
4
Сдержите последствия
Отмените неизвестные ордера, проверьте позиции и историю вывода, завершите незнакомые сессии и восстановите двухфакторную аутентификацию (2FA), если есть признаки захвата аккаунта.
5
Создайте новую связку
Не включайте старый secret обратно. Выдайте новый key с меньшими правами, новым allowlist и явным сроком следующей проверки.

Если одновременно потерян телефон с 2FA, используйте официальный recovery-процесс площадки и не передавайте коды посреднику. API incident и восстановление интерактивного входа — две связанные, но разные процедуры: закрытие одной не является доказательством закрытия другой.

Закрытие инцидента доказывают журналом, а не новым логином

Сопоставьте server logs и историю площадки по UTC-времени, методу API, рынку, order ID, withdrawal ID и IP. Не сохраняйте подписи запросов как вечный диагностический артефакт: они могут раскрывать чувствительные части авторизации. Если неизвестное действие дошло до блокчейна, отдельно проверьте transaction hash и то, что именно подписывает или подтверждает кошелёк; API log сам по себе не доказывает onchain-исполнение.

Инцидент можно закрыть, когда

скомпрометированный key больше не проходит аутентификацию;
неизвестные ордера, позиции, переводы и выводы перечислены и обработаны;
причина утечки устранена в коде, CI, логах или хранилище;
новый key имеет только нужные permissions и проверенный allowlist;
у владельца доступа назначены дата пересмотра и процедура экстренного отзыва.

Источники

Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.

Kraken Support — How to create an API key Kraken · Проверено 20 августа 2026 г. в 09:25 GMT+5
Kraken Support — API key security Kraken · Проверено 20 августа 2026 г. в 09:25 GMT+5
Coinbase Developer Platform — API authentication Coinbase · Проверено 20 августа 2026 г. в 09:25 GMT+5

Материал носит информационный характер и не является индивидуальной рекомендацией. Криптоактивы связаны с риском волатильности, технических сбоев, хищения и полной потери средств.