Взлом Drift вызвал тревогу: сообщения о кадровых перестановках в руководстве и масштабном изменении мультиподписи перед атакой
Взлом Drift вызвал тревогу: сообщения о кадровых перестановках в руководстве и масштабном изменении мультиподписи перед атакой
1 апреля 2026 года экосистема DeFi на Solana вновь столкнулась с кризисом доверия. Протокол Drift, крупная площадка бессрочных фьючерсов, подтвердил факт активной атаки на систему безопасности и приостановил ключевые функции, пока следователи разбирались с масштабными оттоками средств. По предварительным оценкам аналитиков по безопасности и сообщениям СМИ, сумма пострадавших активов составила от 200 до 285 миллионов долларов, что делает этот инцидент одним из крупнейших взломов в сфере DeFi в 2026 году. (decrypt.co)
Особую тревогу в этом инциденте вызывает не только колоссальная сумма, но и растущий список "операционных" аномалий, активно обсуждаемых в сообществе: наличие административных полномочий без временной задержки (timelock), миграция мультиподписи в последний момент и слухи об изменениях в команде незадолго до инцидента. (tw.theblockbeats.news)
В этой статье мы разберем, что известно на данный момент, что является лишь предположением, и, самое главное, какие уроки пользователи DeFi должны извлечь из очередного напоминания о том, что "децентрализованные" системы могут подвести на критическом этапе управления ключами.
Что произошло (и что мы можем ответственно заявить сегодня)
Согласно общедоступной информации, Drift приостановил приём депозитов и вывод средств после обнаружения несанкционированных перемещений средств. Различные источники сообщают об убытках, превышающих 200 миллионов долларов, а некоторые — около 285 миллионов долларов. (techcrunch.com)
На момент написания статьи (2 апреля 2026 года) полная первопричина инцидента в этих отчетах не была окончательно установлена. Эта неопределенность имеет значение, поскольку меры защиты пользователей кардинально различаются в зависимости от того, являлось ли событие:
- уязвимостью смарт-контракта,
- компрометацией приватного ключа / набора подписантов мультиподписи,
- захватом управления или полномочий на обновление,
- или комбинацией вышеперечисленного.
На практике рынок склонен "закладывать" наихудший сценарий, когда появляются достоверные свидетельства злоупотребления мощными ключами, особенно при отсутствии механизма принудительной задержки для замедления ущерба.
Ключевая проблема: мощный ключ подписи без временной задержки
Согласно отчету BlockBeats, ссылающемуся на основателя Chaos Labs Омера Гольдберга (консультанта по рискам Aave), ключ подписи протокола Drift, по сообщениям, обладал множеством привилегий, оказывающих высокое влияние, и, что крайне важно, не имел временной задержки или аналогичного механизма. (tw.theblockbeats.news)
Почему это важно:
- Если ключ подписи может изменять критические параметры, отключать модули безопасности или перенаправлять активы, то компрометация этого ключа может выглядеть не как типичный "взлом", а скорее как быстрый, привилегированный захват контроля.
- Без временной задержки пользователи и интеграторы теряют то единственное окно для защиты, которое часто отличает "локализованный инцидент" от "полного опустошения".
Временная задержка — это не модное слово, а практический контроль, который вводит минимальную задержку между планированием привилегированного действия и его исполнением, давая экосистеме время на обнаружение и реакцию. (docs.openzeppelin.com)
Миграция мультиподписи "за неделю до": почему детали выглядят ненормально
BlockBeats также сообщил, что за неделю до инцидента Drift мигрировал на новый мультиподписной счет, созданный одним из подписантов из старой мультиподписи. Отчет добавляет особо необычную деталь: создатель не добавил себя в качестве подписанта в новую мультиподпись, а порог подписи был изменен на 2 из 5 (1 старый подписант + 4 новых подписанта). (tw.theblockbeats.news)
С точки зрения управления и операционной безопасности, это вызывает ряд вопросов, которые следователи обычно задают незамедлительно:
-
Зачем мигрировать мультиподпись незадолго до крупного инцидента? Иногда это обычная ротация подписантов. Иногда — реакция на предполагаемый компрометации. Иногда — ни то, ни другое, и совпадение по времени случайно. Но время всегда заслуживает пристального внимания.
-
Почему создатель мультиподписи исключил себя? Существуют благонамеренные причины (например, инженер по эксплуатации, развертывающий инфраструктуру для других), но это достаточно необычно, чтобы усилить необходимость прозрачных, поддающихся аудиту объяснений.
-
Является ли порог "2 из 5" достаточным для "критически важных для протокола" разрешений? Более низкий порог может уменьшить операционные трудности, но также снижает количество независимых сбоев, которые должен эксплуатировать злоумышленник. Безопасность мультиподписи — это не только математика; это также независимость подписантов, практики хранения ключей и дисциплина в процессе управления. (frameworks.securityalliance.org)
Проще говоря: когда самые мощные разрешения протокола становятся выполнимыми всего двумя одобрениями, а временной задержки нет — всю безопасность системы тесно связывают с управлением ключами человека.
Слухи об уходе руководства / основной команды: почему "риск, связанный с людьми" является частью ончейн-риска
Там же в материале BlockBeats отмечаются обсуждения в сообществе о том, что ключевой член команды Drift мог уйти в предыдущем месяце, что вызывает опасения по поводу внутреннего управления, передачи ключей и мер контроля рисков. (tw.theblockbeats.news)
Речь идет не о сплетнях, а об известном сценарии провала в сфере криптобезопасности:
- Ротация ролей (люди меняют должности, уходят или теряют доступ, в то время как разрешения остаются) может создавать невидимые единые точки отказа.
- В худшем случае, владение ключами становится неясным именно тогда, когда ясность нужна больше всего (реагирование на инциденты, ротация подписантов, решения о экстренной приостановке).
Даже при использовании мультиподписи "граница безопасности" может рухнуть, если выбор подписантов, документация и процесс увольнения сотрудников не управляются как задачи с высоким уровнем ответственности.
Тренд 2025-2026: повторяющийся "краш-тест административных ключей" в DeFi
В предыдущем цикле DeFi стал быстрее, более компонуемым и более близким к институциональным игрокам, но безопасность протоколов по-прежнему неоднократно подрывается централизованными полномочиями на обновление и привилегированными ролями. Программы Solana, в частности, часто сохраняют полномочия на обновление, если они явно не ограничены или не отказаны, поэтому "риск административного ключа" остается ключевым фактором должной осмотрительности для любого серьезного участника DeFi. (solana.com)
Таким образом, инцидент с Drift следует рассматривать не как изолированное событие, а как часть более широкой тенденции:
- Смарт-контракты могут быть проверены, а операционное управление ключами труднее постоянно проверять извне.
- Мультиподпись не является автоматически "децентрализованной"; ее безопасность зависит от независимости подписантов, выбора порогов и механизмов защиты, таких как временные задержки и мониторинг.
- Поскольку TVL в 2026 году возвращается к более динамичным стратегиям, злоумышленники следуют за ликвидностью, особенно там, где привилегированные действия могут быть выполнены быстро.
Что делать пользователям после таких инцидентов, как с Drift (практический чек-лист)
Если вы использовали Drift напрямую или косвенно (через пулы, интеграции или продукты стратегий DeFi на Solana), отнеситесь к ситуации как к напоминанию о необходимости более строгого соблюдения правил управления рисками:
1) Перепроверьте косвенное подверженность риску
Даже если вы никогда не вносили средства в Drift, вы можете иметь подверженность через интегрированные пулы или продукты стратегий, которые направляют фонды в сторонние протоколы. Публичные заявления других проектов Solana показывают, как быстро "не затронуто" может отличаться от "частично затронуто через пул". (tw.theblockbeats.news)
2) Сократите "постоянно активные" разрешения и подписание вслепую
Многие утечки усугубляются, когда пользователи (или операторы) подписывают сообщения или транзакции под давлением. Отдавайте предпочтение настройкам, где одобрения минимизированы, ограничены по времени и легко отзываются.
3) Храните долгосрочные средства отдельно от "горячих" кошельков, используемых для DeFi
Разделяйте кошельки по назначению:
- "торговый кошелек" для обычного использования DeFi,
- и "кошелек-хранилище" для долгосрочного хранения.
Это не предотвращает взломы на уровне протокола, но уменьшает зону поражения от фишинга, вредоносных dApps и случайных одобрений во время хаотичных информационных циклов.
Где аппаратный кошелек, такой как OneKey, подходит в этой истории (и где нет)
Аппаратный кошелек не может исправить уже скомпрометированный протокол. Но тревожные сигналы, сообщенные о Drift — мощные ключи, изменения в мультиподписи и возможность отказа системы управления ключами — подчеркивают, почему дисциплина в хранении ключей остается непреложным требованием как для пользователей, так и для команд.
Если вы пользователь DeFi (или подписант мультиподписи):
- Использование аппаратного кошелька помогает изолировать приватные ключи от скомпрометированных браузеров, расширений и сред с большим количеством вредоносного ПО.
- Четкая верификация транзакций на устройстве может снизить вероятность одобрения неправильного действия в стрессовые моменты (что часто встречается во время "живых" окон взлома).
- Для команд разделение устройств подписантов и обеспечение последовательных процедур подписания является базовым ожиданием, когда протоколы контролируют большие объемы пользовательских средств.
OneKey широко используется в крипто-ориентированных рабочих процессах для безопасного подписания транзакций в основных сетях, что делает его практичным выбором для пользователей, желающих усилить самостоятельное хранение активов, не меняя фундаментальную работу DeFi.
Заключительная мысль: безопасность DeFi все больше сводится к "безопасности управления"
Взлом Drift все еще анализируется, но выводы уже знакомы: самые опасные уязвимости — это часто не экзотические криптографические ошибки, а высокопривилегированные действия, выполняемые слишком быстро, с недостаточным количеством препятствий и недостаточным временем для реакции общественности. (tw.theblockbeats.news)
Для пользователей в 2026 году "Какая сеть?" имеет меньшее значение, чем:
- Кто может изменять правила?
- Как быстро они это могут сделать?
- Какие механизмы дают пользователям время для вывода средств, если что-то пойдет не так?
Пока временные задержки, прозрачное управление мультиподписью и проверяемые ограничения на обновление не станут стандартом, каждый серьезный участник DeFi должен предполагать, что риск протокола — это также и риск управления ключами, и планировать соответственно. (docs.openzeppelin.com)
