Большинство крупных инцидентов 2025–2026 годов в конечном счёте восходят к ключам или подписи — скомпрометированному инструменту подписи, утечке административного ключа или фишингу в отношении оператора. (Мы разбираем эти случаи отдельно в нашем обзоре недавних взломов криптовалютных платежей.) Общая нить, как правило, тянется к тому, как ключи авторизуются, хранятся или используются для подписи.
Проблема в том, что мультиподпись, MPC, горячие/холодные кошельки и HSM обсуждаются так, словно это равнозначные варианты выбора, и их смешение превращает выбор в хаос. На самом деле это три независимых измерения, а реальная система управления ключами представляет собой комбинацию всех трёх. В этой статье мы разберём каждое из них, а затем рассмотрим гибридную архитектуру, инфраструктуру подписи и операционные стандарты, на которых всё держится, а также более широкую операционную поверхность — изоляцию API и инфраструктуры, людей и вендоров, домены и идентификацию, и самый новый и наименее понятый риск: ИИ-агентов с доступом к вашим средствам.
Приватные ключи, сид-фразы и почему «это на моём устройстве» не является безопасностью
В основе всего этого лежит приватный ключ: строка криптографических случайных чисел. Тот, кто им владеет, может подписывать транзакции и перемещать средства на соответствующем адресе. Это абсолютный контроль над средствами адреса — и абсолютная единственная точка риска.
Сид-фраза (обычно 12 или 24 слова, стандарт BIP-39) — это человекочитаемое кодирование приватного ключа. Правило «иерархически детерминированного» (HD) кошелька позволяет получить тысячи приватных ключей и адресов из одной сид-фразы. Это делает сид-фразу как минимум столь же чувствительной, как отдельный приватный ключ, а возможно, и более: утечка одного приватного ключа означает потерю одного адреса; утечка сид-фразы означает потерю всего кошелька.
Стоит прямо назвать одно распространённое заблуждение: некоторые полагают, что пока устройство для подписи и кошелёк находятся в ваших руках, а ключ хранится офлайн, ничего не может пойти не так. Проблема в том, что приватные ключи и сид-фразы в обычных программных и аппаратных кошельках можно экспортировать. Любой, кто имеет внутренний доступ к устройству или резервной копии, может экспортировать и скопировать приватный ключ, а затем управлять средствами откуда угодно — не прикасаясь к «своему» устройству.
Таким образом, «ключ на моём устройстве» не означает «никто другой не может его забрать». По-настоящему важно то, можно ли экспортировать приватный ключ. Как вы увидите ниже, HSM — единственный вариант, который блокирует экспорт на аппаратном уровне.
Три независимых измерения, а не один спектр
Прежде чем выбирать конфигурацию, полезно разделить три вопроса, на которые вы в действительности отвечаете.
Модель авторизации: одиночная подпись, мультиподпись или MPC/TSS
Одиночная подпись означает, что всем управляет один приватный ключ — самая простая конфигурация и наибольшая единственная точка отказа.
Мультиподпись требует совместной подписи M из N независимых приватных ключей (например, 3 из 5), при этом каждый подписант держит полный независимый приватный ключ. В сетях с поддержкой смарт-контрактов контрактная мультиподпись (Safe является де-факто стандартом) реализует эту логику в контракте, где подписи и пороговые правила публично проверяемы в сети — ценой более высокого расхода газа на транзакцию и необходимости редактировать конфигурацию контракта при каждой смене подписантов. Здесь есть и легко упускаемая из виду слабость: инфраструктура подписи для контрактной мультиподписи всё ещё незрелая. Вызов execTransaction в Safe нередко отображается на аппаратном кошельке как длинная строка calldata, поэтому подписанты с трудом понимают, что именно они одобряют, а поддержка Clear Signing и разбора транзакций в экосистеме всё ещё ограничена. Именно эта поверхность атаки была использована в инциденте с Bybit, поэтому компании, внедряющие контрактную мультиподпись, нередко вынуждены привлекать сторонний разбор транзакций и перекрёстную верификацию, чтобы закрыть этот пробел. Такие сети, как Bitcoin, напротив, поддерживают мультиподпись нативно на уровне скриптов, без зависимости от контракта.
MPC (пороговые подписи, TSS) — это не «разрезание одного полного приватного ключа на части». Настоящий MPC использует распределённую генерацию ключей (DKG): ключ распределяется с момента создания, каждая сторона держит независимую долю ключа, и полного приватного ключа не существует ни в какой момент. Каждая сторона вычисляет частичную подпись из своей доли, и эти частичные подписи объединяются криптографическим протоколом в одну стандартную подпись — это вычисление, а не конкатенация байтовых строк — поэтому результат в сети неотличим от обычной одиночной подписи. Стоимость газа обычная, совместимость между сетями высокая, а смена подписантов или порога не требует взаимодействия с контрактом.
Стоит отличать MPC/TSS от старого, легко путаемого метода: разделения секрета Шамира (SSS). SSS разрезает уже существующий полный приватный ключ на n частей; для подписи собирается достаточное количество частей и полный приватный ключ восстанавливается в памяти перед подписью — и этот момент восстановления является единственной точкой отказа. TSS никогда не восстанавливает ключ; полный приватный ключ никогда не появляется. Именно это делает его более безопасным, чем SSS.
И мультиподпись, и MPC устраняют риск единственной точки отказа, только через разные механизмы. Мультиподпись — это несколько полных ключей плюс верификация в сети: прозрачно, но дорого и неудобно при смене подписантов. MPC — это несколько долей ключа плюс объединение частичных подписей вне сети: гибко и дёшево, но координация зависит от вашей инфраструктуры.
Аппаратная защита: программное хранилище, аппаратный кошелёк, TEE или HSM
Программное хранилище держит приватный ключ на сервере или в программном обеспечении — наиболее удобный вариант и наиболее уязвимый. Аппаратный кошелёк (Ledger, Trezor и аналоги) хранит ключ в защищённом чипе, подписывает внутри устройства и никогда не позволяет ключу покинуть его.
TEE (доверенная среда исполнения) — например, Intel SGX, AWS Nitro или Apple Secure Enclave — выделяет изолированную зашифрованную область памяти на обычном процессоре, где ключи и вычисления подписи недоступны даже злоумышленнику с привилегиями root в ОС. По уровню защиты он находится между программным обеспечением и HSM: сильная логическая изоляция, хорошая производительность, возможность выполнять произвольный код (включая протоколы MPC), хотя физическая устойчивость к вмешательству и сертификация соответствия уступают HSM. Это также наиболее распространённый способ хранения долей ключей MPC — генерируются через DKG внутри анклава и никогда из него не извлекаются. Fireblocks, например, распределяет доли ключей MPC по SGX-анклавам в нескольких облаках.
HSM (аппаратный модуль безопасности) — это корпоративное аппаратное обеспечение с защитой от вмешательства, соответствующее таким сертификациям, как FIPS 140-2/3, с физической защитой и автоматическим уничтожением данных при вторжении. Его главная гарантия: приватный ключ генерируется внутри аппаратного обеспечения, помечается как неэкспортируемый и физически не может покинуть устройство. Именно это принципиально отличает его от программных и аппаратных кошельков, и именно поэтому HSM подходит для хранения полных приватных ключей с высокой стоимостью.
Это измерение ортогонально модели авторизации, описанной выше: каждый полный ключ в мультиподписи может храниться в аппаратном кошельке или HSM, тогда как каждая доля MPC обычно хранится в TEE-анклаве.
Температура средств: горячий, тёплый или холодный
Это измерение не зависит от способа хранения ключа — оно определяет только то, насколько приватный ключ подвержен воздействию интернета, то есть насколько быстро и автоматически могут перемещаться средства.
Горячие кошельки всегда онлайн, используются для мгновенных платежей и автоматических выплат — самые быстрые и самые рискованные, обычно хранящие лишь однозначный процент от общих средств. Тёплые кошельки онлайн, но приватный ключ изолирован в защищённой среде (специализированный сервис подписи или HSM), и требуют участия человека в процессе подписи; они обрабатывают повседневные операционные расчёты. Холодные кошельки полностью офлайн и изолированы от сети, используются для долгосрочного хранения крупных резервов — максимальная безопасность, медленнее всего в использовании, обычно хранят большую часть средств.
Чтобы прояснить: температура — это принципиально степень онлайн-воздействия на приватный ключ и то, насколько легко перемещаются средства; частота переводов и доля средств — это следствие этого, а не определение. Это измерение также ортогонально первым двум: холодный кошелёк может использовать мультиподпись плюс HSM, а горячий кошелёк может использовать MPC.
Объедините все три, и вы получите полную картину: модель авторизации, аппаратная защита и температура средств независимы друг от друга, а реальная система управления ключами сочетает все три.
Распространённые конфигурации управления ключами
Вот как индустрия обычно комбинирует три измерения:
| Конфигурация | Модель авторизации | Аппаратная защита | Типичная температура | Сценарий использования |
|---|---|---|---|---|
| MPC-кошелёк | Доли ключей MPC | Доли в TEE/анклаве | Горячий / тёплый | Частые выплаты, автоматическое накопление |
| Контрактная мультиподпись (напр., Safe) | Контрактная мультиподпись | Подписанты используют аппаратные кошельки | Тёплый / холодный | Управление, привилегии контрактов, резервы |
| Мультиподпись + холодное хранилище HSM | Мультиподпись | HSM | Холодный | Крупные долгосрочные резервы |
| Одиночная подпись с аппаратным кошельком | Одиночная подпись | Аппаратный кошелёк | Холодный / тёплый | Небольшие команды, нечастые операции |
| Хранение у третьей стороны | Зависит от вендора | HSM/MPC вендора | Все температуры | Компании, не строящие собственную инфраструктуру ключей |
Суть выбора — разделить по температуре средств и использовать наилучшую комбинацию на каждом уровне. Горячие кошельки требуют скорости, поэтому предпочтительнее MPC. Холодные кошельки требуют стабильности и возможности аудита, поэтому предпочтительнее мультиподпись плюс HSM. Управление и привилегии контрактов требуют прозрачности и подотчётности, поэтому предпочтительнее контрактная мультиподпись плюс таймлок.
Рекомендуемая гибридная архитектура BlockSec
BlockSec рекомендует гибридную архитектуру с разделением по температуре.
Горячие/тёплые кошельки: подпись через MPC. Это устраняет единственную точку отказа в виде приватного ключа, сохраняет низкую задержку подписи и подходит для высокочастотных платежей. Доли следует распределить по разным физическим местам и доменам безопасности.
Холодные кошельки: многостороннее управление плюс возможность аудита в сети, подходящие для крупных резервов. Выбор реализации зависит от уровня зрелости команды в операциях в сети — здесь есть два пути:
- Для максимальной прозрачности при зрелых операциях в сети: используйте контрактную мультиподпись (например, Safe 3 из 5), где пороговые правила и каждая подпись публично проверяемы в сети. В Bitcoin используйте нативную мультиподпись на уровне скриптов, где каждый подписант защищает свой ключ в HSM или аппаратном кошельке. Обратите внимание, что инструментарий разбора подписей для контрактной мультиподписи всё ещё незрел, поэтому команде придётся самостоятельно добавлять перекрёстную верификацию — это непростые в операционном плане решения.
- Для команд с меньшим опытом операций в сети, стремящихся снизить операционную сложность: используйте пороговую подпись MPC с долями в TEE, а затем привлеките независимую третью сторону в качестве со-подписанта для проверки безопасности транзакций перед каждой подписью. Это позволяет избежать пробела в инструментарии контрактной мультиподписи и встраивает независимую стороннюю верификацию непосредственно в порог подписи.
Обновления контрактов и изменения политик: мультиподпись плюс таймлок. Любая привилегированная операция требует многостороннего одобрения и временной задержки.
Несколько параметров важны независимо от выбранного пути. Используйте не менее 3 подписантов с порогом не менее 50%, но ниже общего числа — избегайте схемы N-из-N, так как один недоступный подписант заблокирует подписание и заморозит средства, а если каждый подписант незаменим, каждый становится критической целью для принуждения или похищения. Порог ниже общего числа оставляет резервирование и снижает ценность атаки на отдельного подписанта. Каждый подписант также должен использовать новый выделенный адрес в каждой мультиподписи, никогда не используемый совместно с другими мультиподписями или личными кошельками, а подписанты должны быть разнообразны по географии, организационной роли и юридическому лицу — при этом степень рассредоточенности должна возрастать по мере роста уровня риска кошелька.
Этот уровень риска должен быть получен на основе формальной классификации: оценивайте каждый кошелёк по его финансовому влиянию на бизнес, зависимости протокола и репутационному риску, и сопоставляйте каждую категорию с разным порогом, процессом одобрения и плотностью мониторинга. Пересматривайте классификацию каждые 6 месяцев, а также незамедлительно после значительного изменения TVL, обновления контракта или инцидента безопасности.
Слепая подпись и изоляция среды подписи
Слепая подпись означает, что ваш инструмент подписи показывает хеш calldata — а не то, что транзакция в действительности делает. Это не гипотетический риск: в момент подписания подписант не может понять реальный смысл транзакции из интерфейса, и этот пробел стал одной из прямых причин инцидента с Bybit, где фронтенд или бэкенд, используемый для подписания, был скомпрометирован, и подписанты одобрили вредоносную транзакцию без каких-либо ошибок в самих контрактах.
Блокировка трёх измерений, описанных выше, работает лишь в том случае, если процесс подписи вокруг них столь же защищён. Ряд стандартов применяется независимо от конфигурации:
- Обязательное аппаратное обеспечение для подписи. Все производственные операции с мультиподписью должны выполняться с аппаратным кошельком с экраном достаточного размера для отображения полного резюме транзакции и поддержкой Clear Signing, PIN-защитой с верификацией целостности прошивки, и цепочкой поставок, ограниченной производителем или авторизованными реселлерами — проверяйте подлинность при получении.
- Физически изолированная среда подписи. Подпись должна выполняться на изолированных от сети устройствах, не использующих общую офисную сеть; высококритичные операции требуют выделенных устройств подписи. Разворачивайте сервис подписи в независимом домене безопасности, физически изолированном от бизнес-логики и фронтенда. Узлы подписи не должны быть напрямую доступны из публичного интернета — подключайтесь к ним только через VPN или выделенный канал. Журналы операций подписи должны храниться отдельно и не могут быть изменены бизнес-системой.
- Независимая верификация транзакций. Перед подписанием верифицируйте содержимое транзакции через независимый канал — специализированный терминал, аппаратное устройство или сторонний сервис симуляции/оценки рисков транзакций. Эту проверку лучше всего проводить независимой третьей стороне, а не только собственному фронтенду или бэкенду — доверие исключительно внутренним системам само по себе является единственной точкой отказа. Как только внутренний фронтенд или бэкенд скомпрометирован, как в случае с Bybit, то, что подписант видит на экране, — это подделанная информация, и проверять себя самим собой — не проверка вовсе. Путь выплат особенно нуждается в этой независимой линии защиты.
- Clear Signing и перекрёстная верификация. Используйте инструменты, которые разбирают семантику транзакций, чтобы подписант видел «перевод 1000 USDC на адрес 0x1234...» вместо строки calldata, и перекрёстно верифицируйте ключевые параметры — chain ID, целевой адрес, calldata, сумму, нонс и тип операции — как идентичные как минимум в двух независимых инструментах или интерфейсах.
- Двойная проверка: человек и автоматика. Автоматизированный механизм правил выполняет первичную проверку, а человек подтверждает крупные транзакции перед отправкой.
- Нулевое доверие и резервные копии. Разворачивайте сервис подписи, бизнес-логику и фронтенд-интерфейс в разных доменах безопасности и держите резервные варианты для основного UI подписи, RPC и обозревателя блоков, чтобы отказ одного вендора или сервиса не мог заблокировать экстренное подписание.
Операционные стандарты мультиподписи
Выбор ключей и порогов — это лишь часть дела. Ряд операционных стандартов имеет не меньшее значение.
Реестр мультиподписей. Ведите единый реестр каждой мультиподписи, где каждая запись включает как минимум: адрес, сеть, порог подписи, класс риска, назначение, адреса подписантов, контролируемые контракты, роли в сети и дату последней проверки. Чувствительные изменения безопасности должны обновляться в реестре в течение 24 часов, рутинные изменения — в течение 3 дней.
Управление жизненным циклом подписантов. Верифицируйте адреса при вводе в эксплуатацию, попросив кандидата подписать определённое сообщение, проверенное независимым инструментом. Установите SLA для отзыва привилегий уходящего или удалённого подписанта по классу риска — срочные в течение 48–72 часов, критические в течение 7 дней, остальные в течение 14 дней. Проводите ежеквартальную проверку доступа для подтверждения того, что каждый подписант по-прежнему контролирует свой ключ, и обновляйте обучение подписантов не реже раза в год, охватывая верификацию транзакций, аварийные процедуры и защиту от социальной инженерии/фишинга с практической оценкой по итогам.
Защита сид-фраз и резервных копий. Никакого цифрового хранения какого-либо рода — ни облачных дисков, ни фотоальбомов, ни документов. Храните резервные копии рассредоточенными по разным географическим местам, с возможностью восстановления при стихийном бедствии, краже или отсутствии оператора. Ни в одной точке не должна находиться полная информация для восстановления.
Безопасные коммуникации. Координируйте действия подписантов с использованием основных и резервных каналов на разных платформах, каждая из которых требует MFA, сквозного шифрования и членства только по приглашению. Перед подписанием верифицируйте личность подписанта через независимый канал — видеозвонок, кодовую фразу и аутентифицированный второй канал — чтобы исключить возможность того, что взломанная учётная запись IM выдаёт себя за подписанта.
SLA аварийного реагирования. Устанавливайте время отклика подписантов по степени серьёзности инцидента, например: срочные — менее 2 часов, чувствительные ко времени — 2–12 часов, рутинные — 24–48 часов. Ежеквартально проверяйте доступность подписантов не только на бумаге, и проводите как минимум одно комплексное аварийное учение в год, охватывающее сценарии утечки ключа, недоступности подписанта, компрометации канала связи и аварийных операций с протоколом.
Мониторинг мультиподписи в сети. Отслеживайте изменения подписантов/порога, переводы сверх порога, пробелы в нонсах, взаимодействия с неизвестными адресами, неудавшиеся транзакции, изменения Module/Guard и аномальные балансы кошельков предлагающих. Инфраструктура мониторинга сама должна быть защищена от вмешательства.
Безопасность API
Безопасность API — это первая линия защиты вашего платёжного бэкенда. Это означает аутентификацию через ключ API плюс HMAC-подпись или FIDO2/WebAuthn, ограничение частоты запросов для предотвращения брутфорса и злоупотреблений, защиту от DDoS через CDN/WAF-сервис, строгую валидацию каждого входного параметра для предотвращения инъекций и аудит журналов, чтобы каждый вызов API оставлял полный след.
Среды подписи требуют изоляции от всего этого, а не просто защиты с его помощью — именно поэтому сервис подписи принадлежит собственному домену безопасности, как описано выше.
Операционная безопасность: люди, вендоры и независимые аудиты
Ряд крупных инцидентов 2026 года был связан с социальной инженерией — среди них фиктивный рекрутинг, имперсонация IT-поддержки и замена лица с помощью ИИ. Защита от этого требует совместной работы на трёх уровнях.
Прежде всего — обучение и оценка: каждый, у кого есть доступ к системам подписи, производственным учётным данным или чувствительным операциям, проходит обучение безопасности при вводе в должность, обновляет его ежегодно и обновляет содержание в течение 30 дней после любого изменения процессов.
Не менее важно разделение обязанностей: инициирование, одобрение и исполнение не могут выполняться одним лицом, а административные учётные записи не могут осуществлять выплаты напрямую. Для высокочувствительных операций, таких как подписание, следует использовать выделенные устройства — с полным шифрованием диска и автоблокировкой — при этом аппаратные кошельки следует хранить в сейфе, когда они не используются, а весь удалённый доступ должен осуществляться через VPN.
Третьи стороны требуют той же дисциплины. Проводите due diligence перед выбором вендора, ежегодно пересматривайте статус соответствия и безопасности ключевых вендоров и предоставляйте доступ третьих сторон с чётко ограниченным объёмом, целью и сроком действия — отзывается немедленно по истечении срока или завершении проекта. Независимо верифицируйте личность сотрудников третьих сторон перед предоставлением любого доступа.
Всё это не должно строиться исключительно на внутренних самопроверках. Регулярно проводите независимые сторонние оценки безопасности, охватывающие как минимум тестирование на проникновение, учения красной команды и аудит кода и смарт-контрактов. Исправляйте найденные проблемы по одной и проверяйте их устранение в следующем цикле оценки.
Безопасность разработки и инфраструктуры
Ряд крупных инцидентов с платежами и в крипто-сфере в последние годы восходит к скомпрометированному процессу разработки — при том что сами контракты и логика подписи были в полном порядке. Это означает, что уровень разработки и инфраструктуры заслуживает такого же внимания, как и уровень подписи, в четырёх областях.
Изоляция среды разработки: держите учётные записи разработки отдельно от привилегированных (подписание, управление облаком), не допускайте попадания производственных учётных данных в среду разработки и ведите список согласованных инструментов и расширений разработки.
Репозитории кода и цепочка поставок: защита веток, подписанные коммиты и проверка несколькими людьми в основной ветке. Загружайте зависимости только из официальных репозиториев с закреплёнными версиями и проверками на тайпсквоттинг, и запускайте автоматическое сканирование секретов, которое незамедлительно отзывает и ротирует любой обнаруженный ключ.
В CI/CD: изменения конфигурации пайплайна требуют многостороннего одобрения и контроля версий, со воспроизводимыми сборками. Секреты управляются через специализированный менеджер, такой как Vault или облачный KMS — производственные секреты никогда не должны быть напрямую доступны людям — а SAST и сканирование зависимостей являются предварительными условиями для развёртывания, а не опциональными дополнениями.
Для инфраструктуры и облака: предоставляйте привилегированный доступ через just-in-time provisioning, многостороннее одобрение и временные ограничения. Держите аварийные аккаунты для чрезвычайных ситуаций, но оповещайте о каждом использовании. Ведите полные журналы аудита, оповещения в реальном времени об административных операциях и регулярно отрабатывайте резервное копирование и аварийное восстановление.
Лучший аудитор безопасности для Web3
Проверяйте дизайн, код и бизнес-логику до запуска
Домены, DNS и идентификация: недооценённая поверхность атаки
Домены и DNS — крайне недооценённая поверхность атаки в крипто-сфере: многие фишинговые инциденты и кражи восходят к скомпрометированной учётной записи регистратора или перехваченному DNS. Защита доменов, через которые пользователи инициируют операции с средствами, так же важна, как защита самой среды подписи.
Управляйте учётной записью регистратора как привилегированной: требуйте MFA с аппаратным ключом и внеполосного второго подтверждения для критических изменений, таких как передача, удаление или смена nameserver. На стороне DNS и электронной почты: включите DNSSEC на критических доменах, используйте CAA для ограничения того, какие CA могут выпускать сертификаты, и настройте SPF/DKIM/DMARC (p=reject) на всех отправляющих доменах — для неотправляющих доменов также явно настройте отклонение почты, чтобы предотвратить подмену.
Непрерывно отслеживайте изменения DNS-записей, делегирование nameserver и аномальные выпуски в журналах Certificate Transparency, используя инфраструктуру мониторинга, не зависящую от наблюдаемого домена. Документируйте процесс обработки перехвата домена и несанкционированной передачи, отрабатывайте его ежегодно и устанавливайте многоуровневые предупреждения об истечении срока плюс автопродление, чтобы истёкший домен не стал точкой входа.
Идентификация и учётные записи — это точка входа для почти всего бокового перемещения. Полная инвентаризация организационных учётных записей плюс строгий стандарт MFA важнее любой одиночной точечной защиты.
Начните с инвентаризации учётных записей: зарегистрируйте каждую организационную учётную запись — социальные сети, электронная почта, SSO/IdP, регистратор, платформы хранения, репозитории кода, корень облака, ключевые SaaS — с чётко указанным владельцем и регулярно их проверяйте. Требуйте фишинго-устойчивой MFA с аппаратными ключами FIDO2/WebAuthn на привилегированных учётных записях и никогда не полагайтесь на SMS или голосовой звонок как основной фактор — замена SIM, SS7 и голосовой фишинг позволяют их обойти. Это единственная наиболее эффективная защита от захвата учётных записей.
Используйте менеджер паролей с уникальными надёжными паролями, запретите общие логины и ограничьте электронную почту и телефон для восстановления организационным доменом — храните коды восстановления в защищённом хранилище, а не в личной почте или облаке. При увольнении сотрудника отзывайте весь его доступ в течение 24 часов и ротируйте все общие учётные данные, к которым он имел доступ, и продолжайте вести поведенческий мониторинг и мониторинг утечек учётных данных на привилегированных учётных записях всё время их активности.
Почему архитектура ИИ-агента небезопасна по своей природе
Платёжные компании всё активнее используют ИИ-инструменты и агентов для повышения эффективности разработки и операций — но это открывает новую поверхность атаки, которая при ненадлежащем управлении напрямую угрожает средствам.
Вот что легко упустить из виду: ИИ-агент — это не просто модель, которая отвечает на вопросы. Это машина, которая может читать внешний контент, вызывать инструменты, хранить учётные данные и выполнять действия. Корень риска в том, что она воспринимает текст, прочитанный из ненадёжного контента, как инструкции для исполнения.
Это означает, что злоумышленнику не нужна никакая уязвимость и никакая похищенная учётная запись. Достаточно спрятать одно предложение в документе, на веб-странице, в комментарии к коду или в описании PR — и поведение агента может быть захвачено для утечки данных или выполнения несанкционированных действий. Это называется инъекцией подсказок, и к 2026 году было показано, что она может непосредственно приводить к удалённому выполнению кода — Microsoft продемонстрировала, что одна подсказка запускает программу на машине, где работает агент, а в инфраструктуре GitHub Copilot, Cursor и MCP были раскрыты уязвимости RCE с рейтингом CVSS 9,6 или выше.
Для всего привилегированного ситуация ещё хуже. Агент разработки или операций по умолчанию наследует доступ к файлам оператора, привилегии оболочки и ключи базы данных. Исследование 2026 года, охватившее основных агентов для программирования, показало, что все они могут быть взломаны с помощью инъекции подсказок, при этом успешность адаптивных атак превышает 85%. Любой агент, обрабатывающий ненадёжный ввод, следует воспринимать как потенциального инсайдера, держащего ваши учётные данные — и цепочка поставок является звеном высокого риска: в марте 2026 года отравленная зависимость ИИ-шлюза пролежала в публичном репозитории 3 часа и была загружена почти 47 000 раз.
Как получить эффективность ИИ-агента, не теряя контроль над средствами
Подход заключается в том, чтобы поместить агента под те же ограничения, которые вы бы применили к ненадёжному коду, через пять мер контроля:
- Изолированное исполнение — запускайте выполнение инструментов агента в песочнице, чтобы инъекция подсказок не могла добраться до реальной оболочки, производственных ключей или среды подписи.
- Принцип минимальных привилегий — предоставляйте инструментам агента, ключам базы данных и MCP-сервисам только минимум, необходимый для одной операции, никогда не давая «полный доступ».
- Человеческий контроль над операциями с средствами — для всего, что касается переводов, подписания или изменений привилегий, агент может только предлагать, но никогда не исполнять автоматически. Независимое одобрение человека применяется и здесь — тот же принцип, что лежит в основе верификации подписи, описанной выше.
- Разделение доверенных инструкций и ненадёжных данных — делайте это на архитектурном уровне и не рассчитывайте на то, что модель «самостоятельно их различит».
- Блокировка цепочки поставок — применяйте те же закрепление версий и проверки происхождения к зависимостям, связанным с ИИ, которые вы применяете к обычным репозиториям кода.
Эти ограничения не обязаны оставаться теоретическими. Открытый Web3 Companion от BlockSec — это эталонная реализация безопасного агентного кошелька (лицензия MIT, исследовательский превью). Он позволяет ИИ-агенту помогать пользователю готовить транзакции в сети, полностью сохраняя приватные ключи и финальную авторизацию вне досягаемости агента. Его модель угроз рассматривает сам агент как ненадёжный — вся система должна гарантировать, что даже полностью скомпрометированный агент не сможет переместить средства пользователя.
Архитектура строится на трёх точках. Изоляция ключей означает, что только один независимый модуль подписи (отдельный процесс Go) может когда-либо взаимодействовать с приватным ключом — агент получает идентификатор намерения транзакции, может запросить подпись, но никогда не видит ключ. Ключи хранятся с конвертным шифрованием (AWS KMS или локальный AES-256), и открытый текст существует в памяти только в момент подписания, после чего обнуляется.
Перед трансляцией транзакция проходит через четыре уровня последовательно, каждый из которых предполагает, что предыдущий мог дать сбой: симуляция транзакции (декодирование calldata, предсказание откатов), оценка риска контрагента, жёсткие политические ограничения на чистом Go (лимит на транзакцию, дневной бюджет, белый список — ни одно из которых агент не может изменить), и наконец подтверждение человека через passkey — скан отпечатка пальца или лица по WebAuthn, который программная атака не может подделать. Ключ, политика и passkey образуют три независимые границы доверия, так что взлом одной оставляет две другие нетронутыми.
ИИ-агент действительно может повысить эффективность, но не должен иметь единоличного контроля над средствами и подписанием. Поместите его в песочницу с минимальными привилегиями как ассистента, и позвольте людям принимать окончательное решение по средствам и подписанию.
Подведение итогов
Управление ключами — это не одно решение, а три, принятых независимо и затем скомбинированных: кто должен подписывать, где физически находится ключ или доля, и насколько он подвержен воздействию интернета. Правильная комбинация для каждого уровня средств, подкреплённая защищённой инфраструктурой подписи и поддерживаемая операционными стандартами, описанными выше, — вот как BlockSec подходит к закрытию пробелов, стоящих за большинством инцидентов 2025–2026 годов, связанных с ключами и подписями. А поскольку поверхность теперь распространяется за пределы ключей — на API, людей, вендоров, пайплайны кода, домены, идентификацию и ИИ-агентов — каждый из них требует одинакового подхода: предполагайте, что предыдущий уровень дал сбой, и сохраняйте человека в петле везде, где могут перемещаться средства.
Для полной картины того, как управление ключами и операционная безопасность соотносятся с остальной частью программы соответствия платёжной системы, скачайте наш сборник по безопасности и соответствию криптовалютных платежей (PDF).
FAQ
В чём реальная разница между MPC и мультиподписью? Мультиподпись — это несколько полных приватных ключей, каждый из которых верифицируется отдельно в сети — прозрачно, но дорого и неудобно при смене подписантов. MPC (пороговые подписи) — это несколько долей ключа, сгенерированных таким образом, что полный приватный ключ никогда не существует; частичные подписи объединяются вне сети в одну подпись — гибко и дёшево, но зависит от вашей инфраструктуры координации.
Является ли разделение секрета Шамира (SSS) тем же, что и MPC? Нет. SSS разрезает уже существующий полный приватный ключ на части и восстанавливает его полностью в памяти для подписи, что делает момент восстановления единственной точкой отказа. Настоящий MPC (TSS) никогда не восстанавливает полный приватный ключ — каждая сторона вычисляет только частичную подпись из своей доли.
В чём разница между TEE и HSM? TEE (например, Intel SGX, AWS Nitro или Apple Secure Enclave) — это изолированная зашифрованная область на обычном процессоре, которая может выполнять произвольный код, включая протоколы MPC — сильная логическая изоляция, но более слабая физическая защита от вмешательства и сертификация по сравнению с HSM. HSM — это специализированное аппаратное обеспечение с защитой от вмешательства, где приватный ключ генерируется внутри, помечается как неэкспортируемый и физически не может покинуть устройство.
Что такое тёплый кошелёк и чем он отличается от горячего или холодного? Тёплый кошелёк онлайн, но хранит приватный ключ в защищённой среде (специализированный сервис подписи или HSM) и требует участия человека в процессе подписи, используется для повседневных расчётов — находится между всегда онлайн, автоматизированным горячим кошельком и полностью офлайн, изолированным холодным кошельком.
Что BlockSec рекомендует конкретно для холодного хранения? Это зависит от уровня зрелости команды в операциях в сети: команды со зрелыми операциями в сети могут использовать контрактную мультиподпись (например, Safe 3 из 5) с ключом каждого подписанта в HSM или аппаратном кошельке; команды, которым нужна меньшая операционная сложность, могут использовать пороговую подпись MPC с долями в TEE плюс независимый сторонний со-подписант для проверки безопасности транзакций.
Что такое слепая подпись и почему она опасна? Слепая подпись — это когда интерфейс подписи показывает только хеш calldata вместо того, что транзакция в действительности делает. Подписант не может проверить реальный смысл того, что он одобряет, что стало одной из прямых причин инцидента с Bybit.
Можно ли доверять ИИ-агентам операции с криптовалютными платежами? Не с единоличным контролем. ИИ-агенту следует разрешать только предлагать операции с средствами, но никогда не исполнять их автоматически — переводы, подписание и изменения привилегий требуют независимого одобрения человека, при этом агент работает в песочнице с минимальными привилегиями.
Что такое инъекция подсказок и насколько она серьёзна? Инъекция подсказок прячет инструкции в ненадёжном контенте — документе, веб-странице, комментарии к коду или описании PR — которые захватывают поведение ИИ-агента. К 2026 году это привело к удалённому выполнению кода в раскрытых уязвимостях, затрагивающих основные инструменты программирования, с рейтингом CVSS 9,6 или выше.
Какова единственная наиболее эффективная защита от захвата учётных записей? Фишинго-устойчивая MFA — использование аппаратных ключей FIDO2/WebAuthn на привилегированных учётных записях и отказ от SMS или голосового звонка как основного фактора, поскольку замена SIM, SS7 и голосовой фишинг позволяют обойти эти каналы.
