За пределами безопасного хранения, часть 1: проектирование безопасных процессов проведения платежей и подписания транзакций

Предварительное описание инцидента 30.10.2026 от Binance указывает, что похищенный токен развёртывания позволил получить доступ к внутреннему сервису подписания и провести транзакции в обход обычного процесса вывода средств [1]. Согласно опубликованному описанию этого пути атаки, злоумышленник мог запрашивать подписи, не получая предварительно доступ к приватному ключу кошелька.

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

Чтобы ответить на этот вопрос, нужно проследить, как бизнес-запрос превращается в подписанную и исполненную транзакцию. Платёж через кошелёк проходит этапы подтверждения полномочий на проведение операции, формирования транзакции, подписания, исполнения и расчётов [2, 3]. На схеме злоупотребление этим процессом показано наряду с другим способом получить возможность подписывать транзакции: восстановлением ключа вследствие ошибок в реализации криптографии.

В серии Beyond Secure Storage на основе реальных инцидентов выводятся принципы проектирования и реализации, направленные на устранение этих рисков. Часть 1, Проектирование безопасных процессов проведения платежей и подписания, посвящена тому, как злоумышленники используют возможность исходной системы подписывать транзакции, не получая её приватные ключи. Часть 2, Безопасная реализация криптографии кошельков, рассматривает ошибки реализации, позволяющие злоумышленникам восстановить ключи и подписывать транзакции самостоятельно. Ни один из этих путей не требует непосредственной кражи защищённого секрета.

Раздел 1 на примере реальных инцидентов рассматривает риски и упущенные из виду допущения на разных этапах проведения платежа, а затем выводит из них проверки проектных решений и реализации, призванные устранить эти риски. Раздел 2 исходит из того, что эти проверки не предотвратили несанкционированную операцию, и рассматривает, как ограничить связанные с ней потери. Раздел 3 объясняет, как анализ проектных решений, аудиты, тесты на проникновение и учения помогают проверить как предотвращение таких операций, так и ограничение потерь.

1. Проектирование для предотвращения несанкционированных операций

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

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

Три типичных операции при кастодиальном хранении. Разделение функций само по себе не означает независимости учётных записей или разграничения прав доступа.

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

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

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

1,1 Основание платежа и подтверждение полномочий

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

Случаи сбоев: сфабрикованное основание платежа

Во время инцидента 24.09.2026 в Bitget злоумышленник использовал уязвимость стороннего продукта безопасности, чтобы получить внутренние учётные данные с высоким уровнем доступа. Согласно официальному сообщению Bitget, эти данные использовались для отправки в систему кошельков поддельных команд на вывод средств, в результате чего переводы обошли действовавшие механизмы контроля рисков [4]. Команды поступили в процесс проведения платежей через внутренний доступ, но наличие такого доступа не подтверждало подлинного распоряжения клиента или решения организации о перемещении средств.

BigONE сообщила о несанкционированном перемещении средств из горячих кошельков 16.07.2025 и заявила, что её приватные ключи остались в безопасности. BigONE Eurasia объяснила инцидент на глобальной платформе изменениями в рабочей логике учёта и контроля рисков [5, 6]. Это указывает на связанную проблему: записи и правила, используемые для обоснования платежа, сами могут быть изменены. В опубликованном описании не раскрыты подробные записи о запросах или API подписания, поэтому оно не позволяет утверждать, что механизм атаки был таким же, как в случае Bitget.

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

Проверяемые меры контроля

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

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

Когда основание платежа установлено независимо, следующий вопрос — соответствует ли транзакция утверждённой операции.

1.2 Формирование и проверка транзакции

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

Случаи сбоев: подписанные операции расходятся с одобренными

Bybit намеревалась перевести ETH с холодного кошелька на тёплый. Согласно официальному сообщению компании, злоумышленники получили доступ к инфраструктуре провайдера благодаря скомпрометированным учётным данным разработчика Safe и ввели в заблуждение подписантов [7]. Safe проверяет через execTransaction подписи для полей транзакции, включая to, value, data и operation [15]. Однако скомпрометированный интерфейс сохранял видимость ожидаемого перевода, подменяя поля на вредоносные до подписания. Подписи были действительны для подставленных байтов [7].

В результате в транзакции с помощью DELEGATECALL была изменена реализация кошелька, что позволило злоумышленнику вывести активы без нового одобрения первоначальных владельцев [7, 8]. Одобренной бизнес-операцией был перевод; подписанная операция изменила то, кто мог управлять кошельком. Проверка отображаемого получателя или непосредственной суммы транзакции не позволила бы установить, что операция целиком соответствовала одобрению.

Инцидент Kiln/SwissBorg показывает, что вредоносные транзакции могут также появиться вследствие изменения работающего сервиса формирования транзакций. По сообщению Kiln, скомпрометированный токен GitHub позволил злоумышленнику через процессы CI получить учётные данные производственной среды. Злоумышленник изменил работающий модуль Kubernetes, не меняя развёрнутый образ, чтобы тот возвращал транзакцию на смену полномочий по выводу средств вместе с легитимной транзакцией деактивации стейкинга в Solana. Подписанты кастодиального сервиса клиента одобрили добавленную транзакцию; согласно Kiln, подписание произошло 31 августа, а обнаружение — 08.09.2025 [9]. SwissBorg также связала подмену транзакции с инфраструктурой провайдера. При этом стороны разошлись во мнениях о том, насколько доступные на тот момент инструменты декодирования были пригодны к использованию и интегрированы [10].

Меры контроля, которые следует проверить

Случаи Bybit и Kiln/SwissBorg показывают, как транзакция может отличаться от того, что подписант намеревался одобрить. Система должна связывать одобрение с операцией целиком, а проверка должна анализировать фактическую транзакцию независимо от сервиса, который её сформировал или отобразил.

• Связывать одобрение с операцией целиком. Одобрение должно охватывать все последствия транзакции, включая любые изменения контроля над активами или делегирование полномочий на выполнение операций [16]. Изменения за пределами этих рамок требуют нового одобрения. Следует убедиться, что подменённые или добавленные операции не могут использовать одобрение легитимного платежа, а повторные попытки не позволяют использовать одно одобрение для санкционирования дополнительных платежей.
• Независимо проверять транзакцию и её последствия. Сопоставлять фактические данные, переданные на подписание, с одобренной бизнес-операцией, охватывая каждую транзакцию в пакете и её последствия для активов и разрешений. Проверка должна быть независимой от сервиса, который формирует или отображает транзакцию. Следует проверить, может ли этот сервис изменять механизм проверки или обходить его проверки, а также отклоняются ли транзакции при вводящем в заблуждение отображении или изменении их содержимого.

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

1,3 Авторизация подписания и использование ключа

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

Случаи нарушения: скомпрометированный доступ к подписанию

Инцидент Resolv от 22.03.2026 показывает, как изменение правил доступа к ключу может открыть путь к подписанию. Для выпуска токенов пользователю требовалось внести обеспечение, а авторизованному сервису вне блокчейна — завершить выпуск. В официальном разборе инцидента описано, как доступ к репозиторию и облачной среде привёл к получению роли с повышенными привилегиями, с помощью которой после отклонения более ранних попыток доступа были изменены правила доступа к ключу подписи. Это изменение предоставило злоумышленнику право подписи в облачном сервисе управления ключами, где требовались и разрешения на уровне идентификатора, и правила доступа на уровне ключа [11].

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

В предварительном сообщении Binance об инциденте от 30.10.2026 описан другой путь к полномочиям на подписание. По данным Binance, скомпрометированные устройства сотрудников и внутренний инструмент ИИ позволили получить доступ к устройствам инженеров, отвечавших за кошельки; затем похищенный токен развёртывания контейнеров был использован для развёртывания контейнера и запуска вредоносных скриптов. Злоумышленник получил несанкционированный доступ к внутреннему сервису подписания транзакций кошельков и инициировал транзакции вне обычного процесса вывода средств [1]. Это сообщение связывает полномочия на развёртывание с доступом к сервису подписания, но не раскрывает, какие именно внутренние проверки разрешений были обойдены. В отличие от описанного Resolv изменения правил доступа к ключу, здесь раскрытый путь проникновения проходил через рабочую среду сервиса подписания.

Меры контроля, которые следует проверить

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

• Требовать одобрения бизнес-операции на каждом пути к подписанию. Разрешение использовать ключ не означает, что конкретная операция одобрена [17, 18, 19]. Ограничьте использование ключа рамками одобренной бизнес-операции и убедитесь, что другие вызывающие субъекты или прямой доступ не позволяют обойти это ограничение. Обеспечение соблюдения требования об одобрении не должно зависеть от вызывающего субъекта, способного отправлять произвольные запросы на подписание. Если на каком-либо пути обеспечить соблюдение этого требования невозможно, зафиксируйте пробел и оцените его последствия в соответствии с разделом 2.
• Контролировать изменения полномочий на подписание. Административные полномочия и права на развёртывание могут открыть доступ к подписанию, даже если исходный идентификатор не имеет права подписи [20, 21, 22]. Разделите право использовать ключ и полномочия изменять правила подписания, идентификаторы или развёрнутый код; требуйте независимого одобрения таких изменений. Убедитесь, что ни одна сторона не может, используя совокупность своих полномочий, предоставить себе доступ к подписанию или отключить проверки бизнес-операций, регулирующие этот доступ.

Проверки авторизации не должны прекращаться после создания подписи: транзакция ещё должна быть исполнена на одобренных условиях, а её результат — корректно отражён при расчётах.

1,4 Исполнение и расчёты

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

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

Случай Drift показывает, как вводящий в заблуждение запрос на подписание может оставить полномочия, которыми можно воспользоваться позднее. В ходе инцидента от 01.04.2026 заранее полученные одобрения были сохранены в транзакциях Solana с долговременным nonce, а позднее эти транзакции были отправлены для захвата административных полномочий [12]. Долговременный nonce определяет действительность транзакции; он отличается от секретного nonce, используемого при криптографическом подписании. Он позволяет отправлять транзакцию после офлайн-подписания или с задержкой без обычного истечения срока действия недавнего хеша блока, хотя изменения состояния аккаунта или программы всё же могут помешать исполнению. Обновление этого nonce делает недействительными транзакции, привязанные к прежнему значению [23].

В сообщении о восстановлении от 16 апреля Drift предложила использовать отдельные устройства для подписания, проводить проверку вне основного интерфейса подписания, устанавливать задержки перед выполнением критически важных административных действий и отключить долговременные nonce для подписантов [24]. Эти меры касаются и того, что одобряют подписанты, и того, когда подписанная операция может быть исполнена. Они были объявлены как план восстановления; сообщение не подтверждает, что меры уже были внедрены.

Chainflip различает клиентские обмены, выводы средств поставщиков ликвидности (LP) и внутренние операции по сбору депозитов, называемые fetches [25]. В Tron инструкции для обмена могут передаваться в полях memo транзакций. Согласно сообщению Chainflip от 15 сентября об инциденте 12.09.2026, злоумышленник отправил подписанную валидатором операцию fetch с некорректным полем memo, содержимое которого он контролировал. Слой наблюдения ошибочно воспринял ситуацию как неудавшийся обмен и инициировал возвраты средств в дополнение к обычным выводам LP. В результате средства по шести выводам были выплачены дважды [13, 14].

Из-за этой ошибки внутреннее перемещение активов было принято за свидетельство нового обязательства перед клиентом. Chainflip интерпретировала поля memo даже тогда, когда переводы в её хранилище выполнялись внутри вызовов других контрактов. Исправление ограничило интерпретацию memo как инструкций для обмена простыми переводами TRX или прямыми переводами TRC-20, исключив вызовы, вложенные в другие вызовы [14]. У корректно подписанной операции fetch была собственная цель; её исполнение не давало оснований для дополнительного возврата средств.

Меры контроля, которые следует проверить

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

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

2. Проектирование для ограничения потерь и реагирования на инциденты

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

В таблице обобщены три цели проектирования, направленные на ограничение потерь и обеспечение реагирования на инциденты.

2,1 Независимо обеспечиваемые лимиты расходов

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

• Обеспечьте соблюдение лимитов независимо от одобрения платежей. Даже платёж, прошедший проверки авторизации, должен подчиняться лимитам расходов, соблюдение которых обеспечивается за пределами предполагаемой зоны контроля злоумышленника. Убедитесь, что эти лимиты действуют для всех способов подписания и исполнения, включая альтернативные способы исполнения [26, 27], и что злоумышленник не может изменить механизм их применения или отключить его. Если обеспечить соблюдение независимого лимита невозможно, не представляйте настроенный бюджет как ограничение возможных потерь.
• Ограничивайте совокупные расходы, а не только отдельные платежи. Определите область применения, период и основу оценки для каждого бюджета, обеспечив последовательный учёт завершённых платежей и зарезервированных сумм. Убедитесь, что повторные запросы, параллельное выполнение и повторные попытки не позволяют в совокупности превысить бюджет или преждевременно снять резервирование. Если лимиты зависят от цен активов, убедитесь, что манипулируемые, устаревшие или недоступные цены не могут увеличить разрешённый объём расходов.

2,2 Остатки средств, пополнения и ещё не исполненные подписанные транзакции

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

• Ограничьте объём средств, к которым злоумышленник может получить доступ. Оцените все активы, на которые распространяются затронутые полномочия на подписание, в том числе в других кошельках, блокчейнах и контрактах. Учитывайте имеющиеся остатки и последующие поступления. Для пополнения должны требоваться независимая авторизация и соблюдение совокупного лимита. Убедитесь, что повторяющийся отток средств не может вызывать непрерывные пополнения из казначейства, а поступление новых средств можно перенаправить или остановить, не упуская из виду депозиты, которые продолжают поступать.
• Учитывайте средства, остающиеся под угрозой из-за действующих подписанных полномочий. Прекращение подписания новых транзакций не обязательно делает недействительными уже выпущенные транзакции или разрешения. Определите, какие средства всё ещё можно с их помощью перевести, не учитывая одни и те же активы дважды. Убедитесь, что подтверждённые платежи учитываются как произведённые расходы, а связанные с ними резервирования сверяются с фактическим результатом; при этом резервирования для неисполненных транзакций должны сохраняться, пока надёжные данные не подтвердят, что эти транзакции больше нельзя исполнить. Один лишь локальный тайм-аут или запрос на отмену не должен уменьшать учитываемый объём средств под угрозой.

2,3 Независимый мониторинг и реагирование на инциденты

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

Предварительное описание инцидента Binance показывает, почему одного отключения приложения может быть недостаточно: отключение не устранило существовавшее делегирование EIP-7702. Для отзыва требовались транзакции в блокчейне, а в используемой Binance системе MPC — отдельно разработанная процедура [1]. Это было ограничение конкретной реализации, а не принципиальная неспособность MPC отзывать полномочия. Поэтому обнаружение и сдерживание необходимо проверять отдельно: надёжные данные должны приводить к действию, которое действительно прерывает путь оттока средств.

• Выявляйте несанкционированную активность на основе независимо защищённых данных. Сопоставляйте одобрения бизнес-операций с действиями по подписанию и результатами исполнения, а также отслеживайте изменения разрешений и правил контроля. Затронутый сервис не должен иметь возможности переписывать данные, на которые опирается мониторинг. Убедитесь, что операции, принятые рабочим процессом, всё равно могут вызывать оповещения, позволяющие принять меры, если они не соответствуют авторизации бизнес-операций, даже когда локальные записи отсутствуют или были изменены.
• Обеспечьте доступность и действенность средств реагирования. Сохраняйте независимые полномочия, позволяющие остановить подписание новых транзакций и пополнение средств, а также аннулировать ещё не исполненные транзакции или отозвать продолжающие действовать полномочия там, где это поддерживается. Убедитесь, что реагирование остаётся возможным при недоступности или компрометации обычного рабочего доступа и что принятые меры действительно блокируют дальнейший отток средств. Определите остаточные риски для средств и необходимость координации с внешними сторонами; остановка приложения сама по себе не отзывает подписанные полномочия, а возврат активов нельзя считать гарантированным.

3. Проверка проектных решений и реализации

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

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

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

Сторонние команды или специалисты по безопасности могут дополнить работу внутренних команд при проведении этих оценок, аудитов, тестов и учений. Их проверка должна охватывать взаимодействие логики платежей, инфраструктуры подписания и операционных разрешений и давать подтверждение способности системы предотвращать несанкционированные операции и ограничивать потери.

4. Заключение

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

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

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

Источники

• [1] Binance, на китайском: Инцидент безопасности 30.10.2026: предварительные выводы и обновленная информация о реагировании (03.11.2026); на английском: Инцидент безопасности 30.10.2026: предварительные выводы и обновленная информация о реагировании (03.11.2026).
• [2] BlockSec, Управление ключами и операционная безопасность криптовалютных платежей.
• [3] BlockSec, Архитектура системы криптовалютных платежей: 6 уровней и движение средств через них.
• [4] Bitget, Разбор взлома Bitget: хронология, последствия и меры реагирования (обновлено 20.10.2026).
• [5] BigONE, Объявление об инциденте безопасности BigONE 16.07.2025.
• [6] BigONE Eurasia, Временное техническое обслуживание платформы (16.07.2025).
• [7] Bybit, Подтверждение безопасности на фоне инцидента с Safe{Wallet} (26.02.2025).
• [8] BlockSec, Взлом Bybit на 1,5 млрд USD: подробный анализ атаки через вредоносное обновление кошелька Safe.
• [9] Kiln, Возобновление работы сервисов Kiln и информация об инциденте безопасности (07.10.2025).
• [10] SwissBorg, Информация о безопасности: взлом Kiln 8 сентября 2025 года и его последствия для SwissBorg.
• [11] Resolv, Разбор инцидента Resolv 22.03.2026 (04.04.2026).
• [12] BlockSec, Инцидент Drift Protocol: компрометация управления через мультиподпись с использованием долговременного одноразового номера.
• [13] Chainflip, Эксплойт Tron USDT: что произошло и что будет дальше (13.09.2026).
• [14] Chainflip, Восстановление работы Chainflip (15.09.2026).
• [15] Safe, execTransaction.
• [16] Ethereum, EIP-7702: назначение кода для EOA.
• [17] AWS KMS, Sign API.
• [18] Google Cloud KMS, cryptoKeyVersions.asymmetricSign.
• [19] Azure Key Vault, Sign API.
• [20] Google Cloud KMS, Разделение обязанностей.
• [21] Google Cloud IAM, Роли для аутентификации сервисных аккаунтов.
• [22] AWS IAM, Предоставление разрешений на передачу роли сервису AWS.
• [23] Solana, Подписание транзакций с использованием одноразовых номеров для отложенного выполнения и в автономном режиме.
• [24] Drift, Обновленная информация о восстановлении после инцидента (16.04.2026).
• [25] Chainflip, Архитектура хранилища EVM (Ethereum).
• [26] Safe, Защитные механизмы.
• [27] Safe, Модули.