594 BTC, потому что из-за уязвимости в аппаратном кошельке стало больше нельзя.
Многие, увидев такие новости, в первую очередь думают: «виноват производитель кошелька», но с точки зрения системной архитектуры всё не так просто.
Любой этап, связанный с приватными ключами, подписью и авторизацией, — это самое уязвимое звено во всей цепочке транзакции. При ручной торговле приватный ключ находится у человека, и риск дискретный, точечный. Но когда вы переносите торговую стратегию в автоматизированную систему, вопрос становится таким: где хранится приватный ключ? как распределяются права API? есть ли возможность перехвата подписи посредником?
Те, кто пишет код, знают одну фразу: безопасность — это не функция, а архитектура.
В автоматизированной количественной системе управление правами ключей API должно обеспечивать три вещи: минимальные привилегии, контроль актуальности по времени и аудит операций. Что это значит? Ключ для размещения ордеров может только размещать ордера и не может выводить средства; ключи регулярно ротируются и не действуют долго; на все запросы подписи ведётся журналирование, а аномальные вызовы можно обнаружить и заблокировать.
Логика программы в таких вопросах отличается от человеческой.
Человек полагается на самосознание и осторожность, программа — на правила и проверки. В хорошо спроектированной количественной системе перед каждым выполнением сделки программа проверяет источник подписи, сверяет целостность команд, подтверждает адрес назначения по белому списку — это не «добавки», а обязательное условие для запуска и эксплуатации системы.
Чему учит потеря 594 BTC?
Не «не используйте тот кошелёк», а «достаточно ли тщательно спроектирована безопасность вашей торговой системы».
#Coldcard #量化交易 #API安全 #风险管理 #程序化交易
Многие, увидев такие новости, в первую очередь думают: «виноват производитель кошелька», но с точки зрения системной архитектуры всё не так просто.
Любой этап, связанный с приватными ключами, подписью и авторизацией, — это самое уязвимое звено во всей цепочке транзакции. При ручной торговле приватный ключ находится у человека, и риск дискретный, точечный. Но когда вы переносите торговую стратегию в автоматизированную систему, вопрос становится таким: где хранится приватный ключ? как распределяются права API? есть ли возможность перехвата подписи посредником?
Те, кто пишет код, знают одну фразу: безопасность — это не функция, а архитектура.
В автоматизированной количественной системе управление правами ключей API должно обеспечивать три вещи: минимальные привилегии, контроль актуальности по времени и аудит операций. Что это значит? Ключ для размещения ордеров может только размещать ордера и не может выводить средства; ключи регулярно ротируются и не действуют долго; на все запросы подписи ведётся журналирование, а аномальные вызовы можно обнаружить и заблокировать.
Логика программы в таких вопросах отличается от человеческой.
Человек полагается на самосознание и осторожность, программа — на правила и проверки. В хорошо спроектированной количественной системе перед каждым выполнением сделки программа проверяет источник подписи, сверяет целостность команд, подтверждает адрес назначения по белому списку — это не «добавки», а обязательное условие для запуска и эксплуатации системы.
Чему учит потеря 594 BTC?
Не «не используйте тот кошелёк», а «достаточно ли тщательно спроектирована безопасность вашей торговой системы».
#Coldcard #量化交易 #API安全 #风险管理 #程序化交易