В первых двух статьях этой серии объяснялось, почему криптоинститутам нужно тестирование на проникновение блокчейна (Часть 1) и что представляет собой эта дисциплина (Часть 2). В этой статье речь пойдёт о том, как институциональный проект подготавливается и безопасно проводится: правила взаимодействия, меры безопасности на продакшене и устранение уязвимостей с повторным тестированием, которые превращают находки в исправления — жизненный цикл проекта показан ниже.
Web3 повышает ставки тестирования на продакшене особым образом: действия в блокчейне обычно необратимы, тестовая активность часто публично видна в блокчейне, а системы в области охвата могут перемещать реальные средства. Поэтому приведённые ниже меры защиты придают большее значение выбору среды, лимитам стоимости, обращению с ключами и сверке, чем при обычном проекте.
Тестирование на проникновение блокчейна
Найдите путь внутрь — через контракты, узлы, API и облако
RoE как операционный полномочный документ
Согласно Национальному институту стандартов и технологий США (NIST), RoE устанавливает руководящие принципы и ограничения для тестирования безопасности [1]. В институциональном проекте они превращают решение о тестировании в санкционированный мандат: определённую цель, определённую область охвата и назначенные полномочия на выполнение действий.
Этот мандат важен, потому что команда тестирования не может безопасно выводить полномочия из договора или списка активов. Без общего решения о риске, который оценивается, задействованных системах и ответственных за них людях команда может протестировать не тот путь, исключить критическую зависимость или не иметь полномочий для подтверждения существенной находки.
Отправной точкой является бизнес-решение, которое должен поддержать тест. Цель может касаться публичной экспозиции перед запуском. Она может быть сосредоточена на авторизации клиентов и интерфейсов прикладного программирования (API) или на достижимости привилегированных облачных и операционных систем. Она также может проверять процесс подписания или вывода средств либо оценивать интеграцию с третьей стороной. Эта цель определяет системы, которые имеют значение, риск, который нужно снизить, и результат, необходимый руководству для принятия решения.
Цель должна преобразовываться в область охвата, которая следует операционной модели. В криптоинституте она обычно включает клиентские веб-, мобильные и API-сервисы; облачные аккаунты и управление идентификацией и доступом (IAM); системы непрерывной интеграции и непрерывной доставки (CI/CD) и секреты; операционные консоли; кошельки и процессы утверждения; системы подписания; сервисы реестра и вывода средств; а также поставщиков, которые их связывают. В совокупности эти компоненты определяют, как клиенты и внутренние команды инициируют, утверждают, подписывают, выпускают и сверяют действия, связанные со средствами. Институт и команда тестирования также должны согласовать соответствующую перспективу: внешний злоумышленник, обычный пользователь, партнёр, сотрудник с низкими привилегиями или предполагаемо скомпрометированная идентификация.
У каждой системы, аккаунта, интерфейса и активности в области охвата должен быть назначенный владелец и чёткий путь авторизации. То же относится к зависимостям от третьих сторон, включая кастодиальных провайдеров, интерфейсы кошельков, провайдеров удалённого вызова процедур (RPC), платформы программного обеспечения как услуги (SaaS), провайдеров идентификации, хостинги кода и управляемые сервисы. Тестирование среды, принадлежащей провайдеру, требует письменного разрешения этого провайдера; авторизации института самого по себе может быть недостаточно для действий против систем провайдера.
В совокупности цель, область охвата и путь авторизации определяют, что команда может оценивать. Следующий шаг фиксирует, как команда может выполнять эту оценку.
Операционные границы
Операционные границы — это письменные ограничения, которые регулируют выполнение после согласования мандата. Они отличают то, что входит в область охвата, от того, какие действия разрешены: продакшен-сервис вывода средств может входить в область охвата для проверки пути авторизации, тогда как реальные клиентские выводы, извлечение приватных ключей, изменения персистентности и атаки, создающие нагрузку, остаются запрещёнными.
Это различие не позволяет неопределённости превратиться в операционный риск. Во время проекта на продакшене институт и команда тестирования должны заранее знать, какие методики разрешены, когда активность должна быть остановлена, кто может принять это решение и как можно обрабатывать доказательства. В противном случае даже санкционированный тест может создать предотвратимое воздействие на сервис или клиентов.
RoE должен фиксировать эти решения до начала тестирования. Более того, документ должен быть достаточно точным, чтобы обе стороны могли действовать, не пересматривая фундаментальные вопросы во время проекта.
Таблица ниже переводит установленный выше мандат на тестирование в практическую запись RoE. Она группирует решения, которые должны быть урегулированы до тестирования: что оценивается, кто авторизован, какие действия и ограничения применяются, как стороны координируются и как обрабатываются доказательства. Это не универсальный контрольный список для копирования без изменений; зафиксированные значения должны отражать операционную модель института, перспективу тестирования и продакшен-риск.
| Тема RoE | Решение, которое нужно зафиксировать до тестирования |
|---|---|
| Цель и область охвата | Бизнес-решение, системы и интерфейсы в области охвата, владельцы и перспективы злоумышленника, которые нужно протестировать. |
| Авторизация | Письменные полномочия, тестовые идентификации, одобренные пути доступа и разрешения провайдеров для сред третьих сторон. |
| Метод тестирования и завершение | Разрешённые методики и момент, когда команда должна остановиться, например продемонстрированный доступ, повышение привилегий или контролируемая симуляция процесса. |
| Операционные ограничения | Окна тестирования, ограничения частоты запросов и параллелизма, ограничения операций с аккаунтами, границы доступа к данным, периоды заморозки изменений и, если одобренный сценарий использует транзакцию, разрешённую сеть, тестовые адреса, типы транзакций, максимальную тестовую стоимость и бюджет газа. |
| Запрещённая деятельность | Примеры включают тестирование отказа в обслуживании, социальную инженерию, реальные перемещения клиентских активов, экспорт приватных ключей, персистентность или несогласованные изменения на продакшене. |
| Чувствительные процессы | Назначенные кошельки и аккаунты, адреса из белого списка, максимальная тестовая стоимость, участники утверждения, ожидаемое поведение политики, шаги сверки и самая дальняя точка в цепочке контроля транзакций, до которой может дойти проверка. |
| Коммуникации и пауза | Модель обычных уведомлений, защищённый канал безопасности, контакты для эскалации, порог существенной находки, назначенные полномочия на приостановку или возобновление тестирования, а также ожидаемая наблюдаемость и обработка алертов для одобренной публичной трансляции транзакции. |
| Обработка доказательств | Минимально необходимые доказательства, минимизация и редактирование данных, шифрование, одобренные получатели, срок хранения, подтверждение уничтожения, а также метаданные хеша транзакции и сети, связанные с внутренним одобрением и доказательствами из реестра для одобренной тестовой транзакции. |
После согласования границ выполнения институт может подготовить развёрнутые системы и операционные условия, с которыми столкнётся тест.
Операционная среда и защита работающего сервиса
Операционная среда — это развёрнутая система и бизнес-активность вокруг неё: границы доверия, потоки средств, зависимости сервисов, операционные процессы и люди, ответственные за каждый компонент. Это контекст, в котором находка тестирования приобретает своё фактическое значение.
Этот контекст важен, потому что одна и та же техническая слабость может иметь совершенно разные последствия. Проблема API, облачное разрешение или слабость процесса утверждения может затронуть клиентские данные, внутренние операции, полномочия подписания, изменения баланса или выводы средств. Для работающей биржи, платёжной компании, кастодиана или провайдера кошельков тестирование также должно сосуществовать с торговыми, платёжными, депозитными, выводными, расчётными и поддерживающими операциями.
Актуальное представление должно охватывать инвентаризацию активов и сервисов, архитектуру и точки интеграции, облачную модель и модель идентификации, операционные процессы и зависимости от третьих сторон. Планирование также должно определять соответствующие бизнес-окна, запланированные релизы, заморозки изменений, периоды высокой нагрузки, активность горячих кошельков и другие операционные события. Сигналы работоспособности сервисов, наблюдаемые во время тестирования, должны включать объёмы транзакций и API, время отклика, частоту ошибок, глубину очереди, работоспособность сервиса подписания и доступность сервиса кошелька. Операционная среда включает продакшен-сервисы, идентификации, операционные процессы и внешние зависимости, используемые для инициирования и контроля транзакций. RoE фиксирует одобренную тестовую среду, тестовые идентификации, разрешённые шаги внутри процесса подписания или вывода средств и меры защиты, применяемые к любому контролируемому сценарию проверки. Эти параметры удерживают оценку в фокусе на средствах контроля института, защищая обычную клиентскую и операционную активность.
Закон Европейского союза о цифровой операционной устойчивости (DORA) служит полезным ориентиром в условиях строгого регулирования. Для финансовых организаций, отобранных для тестирования на проникновение под руководством угроз, статья 26 требует, чтобы тест охватывал критически важные или важные функции и проводился на поддерживающих их продакшен-системах, включая соответствующие переданные на аутсорсинг услуги информационно-коммуникационных технологий (ICT) [2]. Это не является общим разрешением на тестирование продакшена; каждому институту всё ещё нужны собственные полномочия, меры защиты и применимые юридические и договорные одобрения.
Эта базовая линия для продакшена позволяет институту применять более конкретные меры защиты к процессам, которые могут напрямую влиять на средства или клиентский доступ.
Границы для чувствительных процессов
Чувствительные процессы — это системы и действия, нормальная работа которых может напрямую влиять на средства, клиентский доступ или целостность записей. Они включают процессы подписания и вывода средств, привилегированный доступ к продакшену, обращение с клиентскими данными и операции с реестром.
Эти процессы нуждаются в более строгих границах, потому что в противном случае реалистичный тест может перейти от проверки средства контроля к изменению клиентского или финансового результата. Риск заключается не только в техническом нарушении: он может включать несанкционированное перемещение средств, некорректные балансы, раскрытие чувствительных данных или путаницу между тестовой активностью и реальным инцидентом. Там, где сбой контроля может повлиять на средства, откат может быть трудным или невозможным, поэтому эти границы должны не позволять тесту создавать любое непреднамеренное или несанкционированное перемещение средств.
Процессы подписания и вывода средств требуют контролируемых сценариев, которые проверяют, как институт аутентифицирует запрос, применяет политику, направляет утверждения и сверяет результат. RoE определяет назначенные тестовые аккаунты, авторизованных участников, ожидаемое поведение политики, верхний предел для сценария и доказательства, необходимые для проверки процесса. Затем он фиксирует самый дальний разрешённый шаг процесса: создание запроса, решение по политике, отображение утверждения, запрос подписания, решение о выпуске или сверку. Тестовые идентификации создаются, используются и выводятся из эксплуатации через согласованный процесс доступа. Та же дисциплина применяется к привилегированному доступу, клиентским данным и операциям с реестром: модель доступа, ожидаемое поведение системы и граница доказательств согласуются до начала тестирования; клиентские данные доступны только там, где это необходимо, минимизируются и редактируются в доказательствах и хранятся в одобренном репозитории доказательств.
Эти меры контроля позволяют тестировать чувствительные пути на продакшене, не рассматривая их как обычные функции приложения. Они также дают операционной команде и команде тестирования общую основу для координации активности в реальном времени.
Тестирование и координация
Тестирование и координация — это операционная модель проекта в реальном времени. Они связывают владельца сервиса, команду безопасности, функцию реагирования на инциденты и руководителя тестирования, пока тест выполняется.
Эта модель необходима, потому что ожидаемая тестовая активность и реальное событие безопасности могут выглядеть похоже. Если мониторинг, уведомления или решения о паузе неясны, тестирование может задержать реагирование на инцидент или создать неопределённость относительно того, требуются ли действия на продакшене.
Модель коммуникаций определяет, кто знает полный план тестирования, кто получает срочные уведомления и кто может приостановить или возобновить активность. Она зависит от цели: некоторые тесты требуют тесной координации с центром операций безопасности (SOC) вокруг чувствительных систем, тогда как тесты с ограниченным раскрытием информации оценивают, обнаруживает ли мониторинг активность и доходит ли эскалация до нужных людей. Если контролируемый сценарий задействует процесс, связанный с транзакциями, план также охватывает соответствующие уведомления и ожидаемые алерты от кастодиальных, кошелёчных, транзакционно-скрининговых и мониторинговых провайдеров. Отдельный контакт по безопасности и назначенный орган приостановки должны оставаться доступными в любое время. Владелец сервиса и команда тестирования согласуют измеримые критерии остановки, такие как отклонение от бюджета ошибок, неожиданный рост времени отклика 95-го процентиля (p95) или глубины очереди, подозрительная активность аккаунта или кошелька, существенные расхождения при сверке или незапланированный алерт безопасности.
Эта подготовка также укрепляет операционную устойчивость. Комиссия по ценным бумагам и фьючерсам Гонконга (SFC) ожидает, что операторы торговых платформ виртуальных активов будут поддерживать круглосуточный мониторинг и документированные процедуры эскалации, а также проводить учения по чрезвычайным ситуациям и непрерывности бизнеса с соответствующими третьими сторонами [3]. Эти нормативные ссылки приведены для иллюстрации и не являются юридической консультацией; применимость зависит от юрисдикции и должна быть подтверждена с юристом.
На диаграмме показан контур управления, который применяется во время тестирования. Её центральная мысль в том, что границы RoE не заканчиваются на авторизации: мониторинг и канал безопасности превращают эти границы в решения возобновить, приостановить, локализовать или передать подтверждённую находку в устранение. Она приведена здесь, потому что эти решения относятся к координации в реальном времени, а не к более раннему определению области охвата или подготовке продакшена.
Та же модель управляет критическими находками: продемонстрированный путь к несанкционированному перемещению средств, компрометация полномочий подписания или продакшен-плоскости управления, раскрытие особо чувствительных клиентских данных или существенный риск для критического сервиса. Путь реагирования должен определять порог эскалации, людей, классифицирующих находку, полномочия на приостановку соответствующей активности и процесс локализации, устранения и проверки. Команда тестирования на проникновение демонстрирует и сообщает о проблеме; институт сохраняет полномочия для решений на продакшене, коммуникаций с клиентами и устранения. Уведомление о существенной находке должно сначала использовать защищённый канал безопасности, а затем согласованную письменную запись, которая не раскрывает ненужные детали эксплуатации.
Как только находка локализована и назначена, ценность проекта зависит от того, сможет ли институт превратить этот результат в подтверждённое улучшение контроля.
Устранение, повторное тестирование и возвращение к обычному режиму
Устранение и повторное тестирование — это процесс закрытия, который превращает продемонстрированную слабость в проверенное улучшение. Возвращение к обычному режиму — часть того же процесса: тестовый доступ, контролируемые сценарии и собранные доказательства не должны становиться новым долгоживущим риском.
Этот заключительный этап определяет, снижает ли проект риск или лишь создаёт отчёт. Находка без владельца, пути устранения и условия проверки может оставаться открытой, пока тот же путь атаки сохраняется на продакшене.
До начала тестирования определите, как находки попадают в инженерные, облачные, кошелёчно-операционные или бизнес-контрольные процессы; кто отвечает за устранение; и какие находки требуют повторного тестирования. При закрытии временные тестовые идентификации, разрешения и контролируемые сценарии возвращаются к предполагаемой конфигурации, а владельцы сервисов подтверждают, что соответствующие показатели работоспособности остаются в ожидаемом диапазоне. Итоговая запись связывает каждую находку с её доказательствами, воздействием, владельцем, планом устранения и условием повторного тестирования. Для контролируемого сценария, связанного с транзакцией, она также связывает ссылку на процесс, тестовую идентификацию, отметку времени, запись об утверждении и результирующую запись в реестре; любой временный доступ, утверждение или тестовая конфигурация, созданные для сценария, выводятся из эксплуатации. Доказательства хранятся только в течение согласованного периода, после чего безопасно уничтожаются или возвращаются.
Результат — это не список уязвимостей, а протестированный, исправленный и повторно протестированный набор средств контроля, который может поддержать следующее операционное решение института.
Заключение
Подготовка к тестированию на проникновение блокчейна — это институциональная задача. Институт определяет цель, операционный контекст, полномочия, ограничения сервиса и модель реагирования; команда тестирования применяет состязательную проверку к этой подготовленной среде.
Когда эти элементы на месте, проект по тестированию на проникновение становится больше, чем техническим упражнением. Он становится контролируемым способом понять, как развёрнутые системы, люди и процессы института выдерживают атаку.
BlockSec помогает институтам подготовить и провести этот процесс: определить область охвата, составить карту операционной среды, установить RoE и меры защиты продакшена и превратить находки в исправленные и повторно протестированные средства контроля. Чтобы спланировать правила взаимодействия и меры безопасности продакшена для вашего следующего теста, запросите встречу для определения объёма работ; дополнительная информация доступна по запросу.
Продолжите серию:
Также в этой серии, скоро публикация:
- Часть 5: Безопасность авторизации и подписания: веб, dApps и мобильные приложения
- Часть 6: Безопасность облака и CI/CD: поверхности атак автоматизированных операций
- Часть 7: Безопасность плоскости управления казначейством: утверждения подписания и вывода средств
- Часть 8: Безопасность реестра биржи: пути кражи и логика плоскости данных
Основная страница по тестированию на проникновение блокчейна даёт представление на уровне проекта.
Лучший аудитор безопасности для Web3
Проверьте дизайн, код и бизнес-логику перед запуском
Ссылки
Нумерованы в порядке первого появления.
- Национальный институт стандартов и технологий, Rules of Engagement (ROE), глоссарий CSRC.
- Европейский союз, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), статья 26.
- Комиссия по ценным бумагам и фьючерсам Гонконга, Циркуляр для лицензированных операторов торговых платформ виртуальных активов о кастодиальном хранении виртуальных активов (15 августа 2025 г.).
