Первые две статьи этой серии объясняют, зачем крипто-институтам нужно тестирование на проникновение в блокчейн (Часть 1) и что представляет собой эта дисциплина (Часть 2). Данная статья посвящена тому, как институциональное тестирование готовится и безопасно проводится: правила проведения тестирования (RoE), меры защиты продакшн-среды, а также процесс устранения недостатков и повторного тестирования, превращающий обнаруженные проблемы в исправления — жизненный цикл тестирования показан ниже.
Web3 повышает ставки тестирования на продакшн-системах особым образом: действия в блокчейне, как правило, необратимы, тестовая активность зачастую публично видна в блокчейне, а системы, входящие в область тестирования, могут перемещать реальные средства. Поэтому изложенные ниже меры защиты придают выбору среды, лимитам стоимости, обращению с ключами и сверке данных больше значения, чем в обычном тестировании.
RoE как рабочий мандат
Согласно Национальному институту стандартов и технологий США (NIST), RoE устанавливает руководящие принципы и ограничения для тестирования безопасности [1]. Для институционального тестирования RoE превращает решение о проведении тестирования в санкционированный мандат: определённую цель, определённую область охвата и уполномоченных лиц, наделённых правом действовать.
Этот мандат важен, поскольку команда тестирования не может безопасно выводить свои полномочия из списка контрактов или активов. Без совместно принятого решения о том, какой риск оценивается, какие системы задействованы и кто за них отвечает, команда может протестировать не тот путь, упустить критически важную зависимость или не иметь полномочий для подтверждения существенного вывода.
Отправной точкой служит бизнес-решение, которое должно быть подкреплено результатами тестирования. Цель может касаться публичной доступности системы перед запуском. Она может быть сосредоточена на авторизации клиентов и интерфейсов прикладного программирования (API) либо на достижимости привилегированных облачных и операционных систем. Она также может предусматривать тестирование рабочего процесса подписания или вывода средств либо оценку стороннего интеграционного решения. Эта цель определяет, какие системы имеют значение, какой риск нужно снизить и какой результат необходим руководству для принятия решения.
Цель должна трансформироваться в область охвата, соответствующую операционной модели. В крипто-институте это обычно включает клиентские веб-, мобильные сервисы и сервисы интерфейса прикладного программирования (API); облачные учётные записи и систему управления идентификацией и доступом (IAM); системы непрерывной интеграции и непрерывной доставки (CI/CD) и секреты; операционные консоли; кошельки и рабочие процессы утверждения; системы подписания; реестр и сервисы вывода средств; а также поставщиков, связывающих эти компоненты. Вместе эти компоненты определяют, как клиенты и внутренние команды инициируют, утверждают, подписывают, выпускают и сверяют операции, связанные со средствами. Институт и команда тестирования также должны согласовать релевантную точку зрения: внешний злоумышленник, обычный пользователь, партнёр, сотрудник с низким уровнем привилегий или условно скомпрометированная учётная запись.
У каждой системы, учётной записи, интерфейса и активности в области охвата должен быть назначенный владелец и чёткий путь авторизации. То же самое относится и к сторонним зависимостям, включая поставщиков услуг хранения, интерфейсы кошельков, поставщиков услуг удалённого вызова процедур (RPC), платформы «программное обеспечение как услуга» (SaaS), поставщиков идентификации, хостинги кода и управляемые сервисы. Тестирование среды, принадлежащей стороннему поставщику, требует письменного разрешения этого поставщика; одно лишь разрешение института может не давать полномочий на действия в отношении систем поставщика.
Вместе цель, область охвата и путь авторизации определяют, что команда может оценивать. Следующий шаг фиксирует, как команда может проводить эту оценку.
Операционные границы
Операционные границы — это письменные ограничения, регулирующие выполнение работ после согласования мандата. Они отделяют то, что входит в область охвата, от того, какая активность разрешена: производственный сервис вывода средств может входить в область охвата для проверки пути авторизации, тогда как реальные клиентские выводы средств, извлечение приватных ключей, изменения в персистентности и атаки, создающие нагрузку, остаются запрещёнными.
Это разграничение предотвращает превращение неопределённости в операционный риск. В ходе тестирования продакшн-среды институту и команде тестирования необходимо заранее знать, какие методы разрешены, когда активность должна быть остановлена, кто может принять такое решение и как следует обращаться с доказательствами. В противном случае даже санкционированное тестирование может привести к неоправданному воздействию на сервис или клиентов.
RoE должен фиксировать эти решения до начала тестирования. Более того, документ должен быть достаточно точным, чтобы обе стороны могли действовать без необходимости пересматривать фундаментальные вопросы в ходе тестирования.
Таблица ниже переводит установленный выше мандат тестирования в практическую запись RoE. Она группирует решения, которые должны быть согласованы до начала тестирования: что оценивается, кто уполномочен, какие виды активности и ограничения применяются, как стороны координируют действия и как обрабатываются доказательства. Это не универсальный контрольный список, который следует копировать без изменений; зафиксированные значения должны отражать операционную модель института, ракурс тестирования и производственный риск.
| Тема RoE | Решение, которое нужно зафиксировать перед началом тестирования |
|---|---|
| Цель и область охвата | Бизнес-решение, системы и интерфейсы, входящие в область охвата, владельцы, а также ракурсы злоумышленника, которые будут протестированы. |
| Авторизация | Письменное полномочие, тестовые учётные записи, утверждённые пути доступа и одобрения поставщиков для сторонних сред. |
| Метод тестирования и завершение | Разрешённые методы и точка, в которой команда должна остановиться, такая как продемонстрированный доступ, повышение привилегий или контролируемая имитация рабочего процесса. |
| Операционные ограничения | Окна тестирования, лимиты частоты запросов и параллелизма, лимиты операций с учётными записями, границы доступа к данным, периоды заморозки изменений, а также, если утверждённый сценарий предполагает транзакцию, — разрешённая сеть, тестовые адреса, типы транзакций, максимальная тестовая стоимость и бюджет на газ. |
| Запрещённая деятельность | Примеры включают тестирование на отказ в обслуживании, социальную инженерию, реальное перемещение клиентских активов, экспорт приватных ключей, персистентность или несанкционированные изменения в продакшн-среде. |
| Чувствительные рабочие процессы | Назначенные кошельки и учётные записи, адреса в белом списке, максимальная тестовая стоимость, участники утверждения, ожидаемое поведение политики, шаги сверки и самая дальняя точка в цепочке контроля транзакций, до которой может дойти проверка. |
| Коммуникации и приостановка | Модель рутинных уведомлений, защищённый канал безопасности, контакты для эскалации, порог существенности выводов, назначенное лицо, уполномоченное приостанавливать или возобновлять тестирование, а также ожидаемая модель наблюдаемости и обработки оповещений для утверждённой публичной трансляции транзакции. |
| Обращение с доказательствами | Минимально необходимые доказательства, минимизация и редактирование данных, шифрование, утверждённые получатели, срок хранения, подтверждение уничтожения, а также хеш транзакции и метаданные сети, связанные с внутренним утверждением и данными реестра для утверждённой тестовой транзакции. |
После согласования границ выполнения работ институт может подготовить развёрнутые системы и операционные условия, с которыми столкнётся тестирование.
Операционная среда и защита действующих сервисов
Операционная среда — это развёрнутая система и бизнес-активность вокруг неё: границы доверия, потоки средств, зависимости сервисов, операционные рабочие процессы и люди, отвечающие за каждый компонент. Это контекст, в котором результат тестирования приобретает своё истинное значение.
Этот контекст важен, поскольку одна и та же техническая уязвимость может иметь совершенно разные последствия. Проблема API, разрешение в облаке или недостаток в рабочем процессе утверждения могут затронуть данные клиентов, внутренние операции, полномочия на подписание, изменения баланса или выводы средств. Для действующей биржи, платёжной компании, кастодиана или поставщика кошельков тестирование также должно сосуществовать с торговыми, платёжными, депозитными операциями, операциями вывода средств, расчётами и поддержкой.
Актуальное представление должно охватывать реестр активов и сервисов, архитектуру и точки интеграции, облачную модель и модель идентификации, операционные рабочие процессы и сторонние зависимости. Планирование также должно учитывать соответствующие бизнес-периоды, запланированные релизы, периоды заморозки изменений, периоды высокой нагрузки, активность горячих кошельков и другие операционные события. Сигналы состояния сервиса, наблюдаемые в ходе тестирования, должны включать объёмы транзакций и API-запросов, время отклика, частоту ошибок, глубину очередей, состояние сервиса подписания и доступность сервиса кошельков. Операционная среда включает производственные сервисы, учётные записи и операционные рабочие процессы, а также внешние зависимости, используемые для инициирования и контроля транзакций. RoE фиксирует утверждённую тестовую среду, тестовые учётные записи, разрешённые шаги в рамках рабочего процесса подписания или вывода средств, а также меры защиты, применимые к любому контролируемому сценарию проверки. Эти параметры позволяют сосредоточить оценку на контролях института, одновременно защищая обычную клиентскую и операционную активность.
Закон Европейского союза о цифровой операционной устойчивости (DORA) представляет собой полезный ориентир с высоким уровнем регулирования. Для финансовых организаций, отобранных для тестирования на проникновение под руководством угроз, статья 26 требует, чтобы тестирование охватывало критические или важные функции и проводилось на производственных системах, поддерживающих эти функции, включая соответствующие переданные на аутсорсинг услуги в области информационных и коммуникационных технологий (ИКТ) [2]. Это не является общим разрешением на тестирование продакшн-систем; каждому институту по-прежнему необходимы собственные полномочия, меры защиты и применимые правовые и договорные одобрения.
Этот базовый уровень производственных мер позволяет институту применять более конкретные меры защиты к рабочим процессам, которые могут напрямую влиять на средства или доступ клиентов.
Границы для чувствительных рабочих процессов
Чувствительные рабочие процессы — это системы и действия, обычная работа которых может напрямую влиять на средства, доступ клиентов или целостность записей. К ним относятся рабочие процессы подписания и вывода средств, привилегированный доступ к продакшн-среде, обработка клиентских данных и операции с реестром.
Эти рабочие процессы требуют более строгих границ, поскольку в противном случае реалистичное тестирование может перейти от проверки контроля к изменению клиентского или финансового результата. Риск заключается не только в техническом сбое: он может включать несанкционированное перемещение средств, некорректные балансы, раскрытие конфиденциальных данных или путаницу между тестовой активностью и реальным инцидентом. Там, где сбой контроля может затронуть средства, отмена может быть затруднительной или невозможной, поэтому эти границы должны исключать возникновение любого непреднамеренного или несанкционированного перемещения средств в результате тестирования.
Рабочие процессы подписания и вывода средств требуют контролируемых сценариев, проверяющих, как институт аутентифицирует запрос, применяет политику, направляет утверждения и сверяет результат. RoE определяет назначенные тестовые учётные записи, уполномоченных участников, ожидаемое поведение политики, верхний предел для сценария и доказательства, необходимые для проверки рабочего процесса. Затем фиксируется самый дальний разрешённый шаг рабочего процесса: создание запроса, решение по политике, отображение утверждения, запрос на подписание, решение о выпуске или сверка. Тестовые учётные записи предоставляются, используются и выводятся из эксплуатации через согласованный процесс доступа. Та же дисциплина применяется к привилегированному доступу, клиентским данным и операциям с реестром: модель доступа, ожидаемое поведение системы и границы доказательств согласовываются до начала тестирования; доступ к клиентским данным осуществляется только при необходимости, данные минимизируются и редактируются в доказательствах, а также хранятся в пределах утверждённого хранилища доказательств.
Эти меры контроля позволяют тестировать чувствительные пути в продакшн-среде, не рассматривая их как обычные функции приложения. Они также дают операционной команде и команде тестирования единую основу для координации живой активности.
Тестирование и координация
Тестирование и координация — это рабочая модель проведения тестирования в реальном времени. Она связывает владельца сервиса, команду операций по безопасности, функцию реагирования на инциденты и руководителя тестирования на протяжении всего тестирования.
Эта модель необходима, поскольку ожидаемая тестовая активность и реальное событие безопасности могут выглядеть схожим образом. Если мониторинг, уведомления или решения о приостановке неясны, тестирование может задержать реагирование на инцидент или создать неопределённость относительно необходимости принятия мер в продакшн-среде.
Модель коммуникаций определяет, кто знает полный план тестирования, кто получает срочные уведомления и кто может приостановить или возобновить активность. Она варьируется в зависимости от цели: некоторые тестирования требуют тесной координации с центром операций по безопасности (SOC) в отношении чувствительных систем, тогда как тестирования с ограниченным раскрытием информации оценивают, обнаруживает ли мониторинг активность и доходит ли эскалация до нужных людей. Если контролируемый сценарий затрагивает рабочий процесс, связанный с транзакциями, план также охватывает соответствующие уведомления и ожидаемые оповещения от поставщиков услуг хранения, кошельков, проверки транзакций и мониторинга. Отдельный контакт по вопросам безопасности и назначенное лицо, уполномоченное на приостановку, остаются доступными в любое время. Владелец сервиса и команда тестирования согласовывают измеримые критерии остановки, такие как отклонение от бюджета ошибок, неожиданное увеличение времени отклика на уровне 95-го процентиля (p95) или глубины очереди, подозрительная активность учётной записи или кошелька, существенные расхождения при сверке или незапланированное оповещение системы безопасности.
Эта подготовка также укрепляет операционную устойчивость. Комиссия по ценным бумагам и фьючерсам Гонконга (SFC) ожидает от операторов платформ торговли виртуальными активами круглосуточного мониторинга и документированных процедур эскалации, а также проведения аварийных учений и учений по обеспечению непрерывности бизнеса с участием соответствующих третьих сторон [3]. Эти нормативные ссылки носят иллюстративный характер и не являются юридической консультацией; применимость зависит от юрисдикции и должна быть подтверждена юристом.
Диаграмма показывает контур управления, действующий во время проведения тестирования. Её ключевая идея заключается в том, что границы RoE не заканчиваются на этапе авторизации: мониторинг и защищённый канал связи превращают эти границы в решения о возобновлении, приостановке, локализации или передаче подтверждённого вывода в процесс устранения недостатков. Она приведена здесь, поскольку эти решения относятся к живой координации, а не к более раннему определению области охвата или подготовке продакшн-среды.
Та же модель регулирует критические выводы: продемонстрированный путь к несанкционированному перемещению средств, компрометацию полномочий на подписание или плоскости управления продакшн-средой, раскрытие крайне конфиденциальных клиентских данных или существенный риск для критически важного сервиса. Путь реагирования должен определять порог эскалации, людей, классифицирующих вывод, полномочия на приостановку соответствующей активности, а также процесс локализации, устранения недостатков и проверки. Команда тестирования на проникновение демонстрирует и сообщает о проблеме; институт сохраняет полномочия в отношении решений, касающихся продакшн-среды, коммуникации с клиентами и устранения недостатков. Уведомление о существенном выводе должно сначала использовать защищённый канал безопасности, а затем сопровождаться согласованной письменной записью, не раскрывающей излишние детали эксплойта.
После того как вывод локализован и назначен, ценность тестирования зависит от того, сможет ли институт превратить этот результат в подтверждённое улучшение контроля.
Устранение недостатков, повторное тестирование и возврат к нормальному режиму работы
Устранение недостатков и повторное тестирование — это процесс завершения, превращающий продемонстрированную уязвимость в подтверждённое улучшение. Возврат к нормальному режиму работы является частью того же процесса: тестовый доступ, контролируемые сценарии и собранные доказательства не должны становиться новым долгосрочным риском.
Этот заключительный этап определяет, снижает ли тестирование риск или лишь формирует отчёт. Вывод без назначенного владельца, пути устранения и условия проверки может оставаться открытым, в то время как тот же путь атаки продолжает существовать в продакшн-среде.
До начала тестирования следует определить, как выводы попадают в рабочие процессы разработки, облачных операций, операций с кошельками или бизнес-контроля; кто отвечает за устранение недостатков; и какие выводы требуют повторного тестирования. По завершении временные тестовые учётные записи, разрешения и контролируемые сценарии возвращаются к своей исходной конфигурации, а владельцы сервисов подтверждают, что соответствующие показатели состояния остаются в ожидаемом диапазоне. Итоговая запись связывает каждый вывод с соответствующими доказательствами, воздействием, владельцем, планом устранения и условием повторного тестирования. Для контролируемого сценария, связанного с транзакциями, она также связывает ссылку на рабочий процесс, тестовую учётную запись, временную метку, запись об утверждении и итоговую запись в реестре; любой временный доступ, утверждение или тестовая конфигурация, созданные для данного сценария, выводятся из эксплуатации. Доказательства хранятся только в течение согласованного периода, после чего надёжно уничтожаются или возвращаются.
Результатом является не список уязвимостей, а протестированный, устранённый и повторно проверенный набор контролей, способный поддержать следующее операционное решение института.
Заключение
Подготовка к тестированию на проникновение в блокчейн — это институциональная задача. Институт определяет цель, операционный контекст, полномочия, ограничения сервисов и модель реагирования; команда тестирования применяет состязательную проверку к этой подготовленной среде.
При наличии этих элементов тестирование на проникновение становится чем-то большим, чем техническое упражнение. Оно становится контролируемым способом понять, как развёрнутые системы, люди и процессы института справляются с атакой.
BlockSec помогает институтам готовить и проводить этот процесс: определять область охвата, составлять карту операционной среды, устанавливать RoE и меры защиты продакшн-среды, а также превращать выводы в устранённые и повторно проверенные контроли. Чтобы спланировать правила проведения тестирования и меры защиты продакшн-среды для вашего следующего тестирования, запросите консультацию по определению области охвата; дополнительная информация предоставляется по запросу.
Продолжение серии:
Также в этой серии, скоро в публикации:
- Часть 5: Безопасность авторизации и подписания: веб, dApps и
- Часть 6: Безопасность облака и CI/CD: поверхности атак автоматизированных операций
- Часть 7: Безопасность плоскости управления казначейством: утверждения подписания и вывода средств
- Часть 8: Безопасность реестра биржи: пути кражи и логика плоскости данных
Обзорная страница по тестированию на проникновение в блокчейн предоставляет представление на уровне всего процесса тестирования.
Источники
Пронумерованы в порядке первого упоминания.
- National Institute of Standards and Technology, Rules of Engagement (ROE), CSRC Glossary.
- European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Article 26.
- Hong Kong Securities and Futures Commission, Circular to Licensed Virtual Asset Trading Platform Operators on Custody of Virtual Assets (15 August 2025).
