Следующий рубеж криптобезопасности: как перестроить систему авторизации за пределами смарт-контрактов?

Автор: Кен Вонг (основатель BitDATA PayFi Infra, бывший исследователь кибербезопасности)

Перевод: AididiaoJP, Foresight News

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

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

1. Структура потерь изменилась: почти половина больше не является «уязвимостями кода»

Согласно отчету Hacken «Отчет о безопасности и комплаенсе за третий квартал 2026 года», за квартал в отрасли произошло 107 инцидентов с убытками в размере 1,18 млрд долларов США, что на 55% больше по сравнению с предыдущим кварталом. Еще более показательна структура потерь: 48% пришлось на уязвимости смарт-контрактов, а 40% — на сбои контроля доступа и операционные сбои.

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

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

Это заставляет отрасль отвечать на более сложные вопросы: кто имеет право перемещать средства? Какие системы наследуют право подписи? Что произойдет, если «авторизованный» сервис начнет действовать злонамеренно? Насколько разрушительным может быть взлом одной учетной записи?

Это уже не чисто проблема программирования Web3, а проблема финансовой инфраструктуры.

2. Расширение поверхности атаки: доступность — это тоже безопасность

Криптобезопасность не изолирована. Она находится в глобальной среде киберугроз, где масштаб, скорость и операционная гибкость атак растут.

Согласно отчету Cloudflare «Отчет об угрозах DDoS за третий квартал 2026 года», за квартал было отражено 18,2 млн сетевых DDoS-атак и 14,4 трлн HTTP DDoS-запросов, в среднем около 8226 сетевых атак в час. Количество кратковременных атак с низкой пропускной способностью выросло на 208%, атак с усилением DNS — на 215%, UDP-флуд-атак — на 122%. Цели атак также стали более распределенными.

Эти данные означают для криптовалют и PayFi две вещи.

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

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

Система безопасности должна не только предотвращать кражи, но и оставаться надежной под давлением, быстро сдерживать злоупотребления и безопасно восстанавливаться.

3. Ключевая деталь инцидента с Binance: безопасность приватных ключей не равна безопасности транзакций

В заявлении о безопасности от 29 октября 2026 года Binance раскрыла, что было затронуто около 6,34 млрд долларов США в цифровых активах, около 2,85 млрд долларов США было заморожено или перехвачено; по состоянию на 31 октября 98% затронутых токенов было восстановлено.

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

Эта деталь важнее суммы. Она показывает, что защита приватных ключей не равна защите прав на транзакции.

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

Действительная подпись не равна действительному бизнес-решению. Именно это отрасль должна сейчас четко различать.

4. Аутентификация, авторизация и легитимность транзакций — это три разные вещи

В цифровых финансах необходимо разделять как минимум три вопроса:

• Кто инициирует запрос? Это аутентификация.
• Что этому субъекту разрешено делать? Это авторизация.
• Следует ли разрешить данную конкретную транзакцию в текущем контексте? Это легитимность транзакции.

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

Украденные токены сеанса могут обойти проверку пароля; скомпрометированный поставщик может стать точкой входа; внутренний сервис с чрезмерными привилегиями может стать каналом для транзакций; законный подписант может одобрить незаконный платеж.

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

Это более значимый показатель устойчивости.

5. Чем сложнее PayFi, тем четче должны быть границы разрешений

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

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

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

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

Машинная идентичность не равна финансовым полномочиям. Делегированные полномочия также не должны становиться неограниченными.

6. Переход от защиты активов к контролю разрешений

Отрасли по-прежнему нужны более качественные смарт-контракты, более качественные аудиты и более качественное управление ключами.

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

Поэтому на следующем этапе безопасности криптовалют и PayFi следует одновременно уделять приоритетное внимание четырем вещам:

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

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

7. Вопросы, на которые отрасли необходимо ответить

Если злоумышленник получит идентичность доверенной системы или контроль над авторизованным транзакционным сервисом, сколько защиты фактически останется?

И более того: чему следует отдать приоритет на следующем этапе — аудиту смарт-контрактов, контролю идентичности, авторизации на уровне транзакций или операционной устойчивости?

Мой ответ: они не конкурируют, а дополняют друг друга. Но порядок важен, потому что капитал, инженерное время и внимание руководства ограничены.

Следующий кризис безопасности не будет ждать, пока отрасль закончит споры.