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

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

Введение цифрового рубля — ​это огромный шаг вперед для российской финтех-индустрии. Из плоскости теоретических дискуссий проект перешел в стадию реальной имплементации: банки-участники пилотной группы уже интегрируют в свои мобильные приложения Программный модуль Банка России (ПМ БР).

Однако за фасадом пользовательских интерфейсов скрывается сложнейший технологический и регуляторный вызов. ПМБР — ​это не рядовая библиотека, а компонент, содержащий средства криптографической защиты информации (СКЗИ). Встраивание такого модуля превращает обычное банковское приложение в среду функционирования СКЗИ, что автоматически активирует жесткие требования регуляторов, в частности ФСБ России.

Перед индустрией встал вопрос: как совместить требования безопасности с реальностью мобильной разработки, в которой релизы выходят, как правило, каждые две недели? В этой статье мы детально разберем опыт пилотного тестирования, проанализируем недостатки классических инструментов анализа кода и представим методику, позволяющую соблюдать требования стандарта платформы цифрового рубля без ущерба для скорости выпуска ПО на рынок (Time-to-Market).

1. Конфликт парадигм: скорость релизов против регламентов безопасности

Современное банковское приложение — ​это живой организм. Команды работают спринтами, «выкатывая» обновления функционала, исправления багов и UI-улучшения в непрерывном режиме.

С точки зрения регуляторики любое изменение программного обеспечения, взаимодействующего с криптографическим модулем, требует прохождения повторной оценки влияния. Согласно нормативной базе, любое обновление приложения («среды функционирования») потенциально может сказаться на работе СКЗИ.

Что говорит Стандарт? Опубликованный «Стандарт платформы цифрового рубля» от 20 ноября 2024 года четко определяет правила игры. В классическом сценарии, работающем «по умолчанию», каждое обновление приложения требовало бы прохождения процедуры «оценки влияния изменений» в аккредитованной испытательной лаборатории. Эта процедура включает экспертизу кода, анализ документации и составление заключения. В реалиях рынка это могло бы занимать недели или даже месяцы, что фактически парализовало бы развитие мобильного банка.

Нормативное «окно возможностей». Регулятор, понимая специфику мобильной экосистемы, заложил в Стандарт критически важный механизм оптимизации. Документ вводит понятие «неизменности трасс вызовов». В частности, в эксплуатационной документации на мобильное ПО должны быть определены условия, неизменность которых будет являться достаточной для подтверждения его безопасности, включая неизменность трасс вызовов [1] и порядка вызовов ПМ БР в составе приложения.

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

2. Технический тупик: почему SAST-инструменты не справились

На старте пилота казалось логичным использовать существующие на рынке инструменты статического анализа кода (SAST, Static Application Security Testing). Задача выглядела тривиальной: просканировать репозиторий, построить граф вызовов (Call Graph) и сравнить его с предыдущим. Однако практика показала несостоятельность этого подхода для задач цифрового рубля. Мы столкнулись с тем, что анализ исходного кода не дает достоверной картины.

Проблема 1: Полиглотизм и разрывы контекста. Современное мобильное приложение представляет собой полноценную систему со своими архитектурными подходами и правилами разработки, крайне сложную для анализа. В экосистеме Android код пишется на Kotlin и Java, которые компилируются в байт-код DEX, но критичные участки часто реализуются на C/C++ (Native Code) и подключаются через механизм JNI (Java Native Interface). Классические анализаторы, работающие с Java или Kotlin, часто «слепнут» на границе JNI, не видя, что происходит внутри нативной библиотеки.

В свою очередь, приложения iOS сочетают Swift и Objective-C, а также C-библиотеки. Динамическая диспетчеризация методов в Objective-C (message passing) часто ставит статические анализаторы в тупик, не позволяя построить связную картину вызовов.

Проблема 2: Фреймворки и «синтаксический сахар». Разработчики активно используют реактивные фреймворки (RxJava, Combine) и синтаксические конструкции, называемые «сахаром», которые делают код удобным для чтения человеком, но сложным для анализа машиной. Статические анализаторы исходного кода часто не могут развернуть эти абстракции в реальную последовательность вызовов, что приводит к разрывам в графе.

Проблема 3: Ложные срабатывания. Попытка анализировать «сырой» исходный код приводила к огромному количеству ложноположительных срабатываний. Изменение форматирования, рефакторинг внутренней логики UI или обновление не связанных библиотек воспринимались сканерами как изменения кода, требующие перепроверки. Для регулятора такой вероятностный подход недопустим. Требовалась математическая точность.

3. Решение: смена парадигмы — анализ бинарного кода

Ключевая идея альтернативного подхода — отказ от анализа исходников в пользу анализа результата компиляции. Компилятор выступает здесь как «великий уравнитель»: он разворачивает все высокоуровневые абстракции, фреймворки и синтаксический сахар в унифицированные инструкции. Анализ бинарного файла дает единственно верную картину того, как приложение будет исполняться на устройстве.

Алгоритм прозрачной проверки (Step-by-Step)

Подход к анализу регламентирует строгий процесс, состоящий из четырех последовательных этапов.

Этап 1: Подготовка «Чистой сборки». Для корректного анализа необ­ходимо сформировать специальную версию приложения. В ней должна быть отключена обфускация (запутывание кода), но при этом сохранены все криптографические подписи. Для платформы Android требуется предоставить приложение в формате Android Package (APK) или Android App Bundle (AAB) без применения R8/ProGuard. Для iOS критически важно наличие dSYM-файлов (Debug Symbols), так как без них имена методов в бинарном файле превращаются в бессмысленные адреса памяти и построить осмысленный граф становится затруднительно.

Этап 2: Построение ориентированного графа. Специа­ли­зи­­рованное ПО загружает бинарный файл и дизассемблирует его. Инс­тру­мент строит полный ориентированный граф вызовов приложения, где вершины представляют собой методы и функции, а ребра отражают факты вызова одного метода другим. Важно, что на этом этапе инструмент должен уметь проходить сквозь границы языков (Cross-languageanalysis), корректно обрабатывая JNI-вызовы и нативные методы.

Этап 3: Фильтрация и выделение трасс ПМ БР. Полный граф приложения может содержать сотни тысяч узлов, но для целей Стандарта нас интересует только взаимодействие с ПМ БР. Алгоритм фильтрации берет известные точки входа в модуль ПМ БР и рекурсивно обходит граф, находя все пути, которые ведут к этим точкам. Результатом становится выделенный подграф или трасса, описывающая все возможные маршруты обращения приложения к криптомодулю.

Этап 4: Автоматическое сравнение с эталоном. На финальном этапе полученный подграф сравнивается с эталонной трассой, зафиксированной при первичном прохождении оценки влияния. Сравнение идет не по тексту кода, а по структуре графа. Алгоритм проверяет наличие новых узлов, удаление старых элементов и изменения порядка вызовов. Результат сравнения всегда бинарен: либо «Изменений нет», либо «Есть изменения». Это исключает человеческий фактор и субъективную трактовку результатов.

4. Экосистема доверия: роли участников и необходимые ресурсы

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

Участник, использующий ПМ БР (банк). В банке должна быть создана или наделена соответствующими полномочиями Служба безопасности и контроля. Стандарт требует наличия у персонала профильного высшего образования в области ИБ и стажа работы не менее трех лет. Банку необходимо внедрить практики DevSecOps, при которых сборка «чистой» версии для анализа происходит автоматически в Continuous integration (CI)/Continuous deployment (CD)-контуре, исключая ручное вмешательство разработчиков. Ответственность за процесс несет сотрудник службы безопасности, который проводит сравнение трасс. Если изменений нет, он составляет отчет, разрешает релиз и отправляет отчет вместе с новой контрольной суммой и сборочным манифестом в лабораторию.

Испытательная лаборатория. Лаборатория выступает гарантом объективности. Получив отчет и сборку от банка, она проводит процедуру построения и сравнения трасс, используя свои экземпляры инструментов. Кроме того, в архиве лаборатории хранятся эталонные версии и результаты всех проверок, обеспечивая непрерывный «аудиторский след». Раз в полгода в лаборатория направляет аккумулированные данные регулятору.

Регулятор (ФСБ России). Ре­гу­ля­тор получает сводные данные и уведомления об инцидентах. В случае выявления нарушений, таких как расхождение контрольных сумм или несанкционированное изменение трасс, регулятор может потребовать блокировки использования ПМ БР до устранения нарушений.

5. «Подводные камни»: проблема идентичности сборок

Существует еще одна неочевидная проблема, связанная с дистрибуцией приложений. Стандарт требует гарантии, что проверенная в лаборатории программа идентична той, что скачает пользователь. Однако сравнить их простым вычислением контрольной суммы (хэша) невозможно по техническим причинам.

В магазине Google Play при загрузке формата Android App Bundle (AAB) платформа сама разделяет приложение на части (split APKs) и переподписывает их своими ключами, из-за чего хэш-сумма меняется полностью. Магазин App Store применяет к бинарным файлам технологию FairPlay-шифрования (DRM — digital rights management, управление цифровыми правами), которая изменяет структуру исполняемого файла и, соответственно, хэш-сумму.

Решение: «Отпечаток происхождения». Поскольку побайтовое сравнение невозможно, было предложено решение, основанное на комплексе организационно-технических мер. Вместо контроля всего бинарного файла внедряется проверка «отпечатка происхождения» — набора неизменяемых метаданных, вшиваемых в приложение на этапе сборки.

Процесс выстроен следующим образом: CI/CD-система в рамках одной сессии собирает из одного исходного кода два артефакта — «чистую» сборку для лаборатории (без обфускации) и продуктовую сборку для магазина приложений (с обфускацией). Затем в обе сборки автоматически внедряются уникальные идентификаторы номера коммита из системы управления исходным кодом и отпечаток релизного ключа, которым подписывается приложение. Организационные меры, такие как строгое ограничение доступа к ключам подписи и логирование всех действий CI/CD, гарантируют, что подмены кода между этими двумя действиями не произошло.

Заключение

Предложенная методология, закрепленная в стандарте платформы цифрового рубля, позволяет достичь баланса интересов всех вовлеченных сторон. Бизнес сохраняет скорость Time-to-Market, проходя проверки в упрощенном режиме. Регулятор, в свою очередь, получает гарантию неизменности условий эксплуатации СКЗИ, подтвержденную независимой лабораторией.

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

[1] Трасса вызовов (трасса выполнения программ) — ​это последовательность машинных инструкций в порядке их выполнения в программе. В трассе могут быть вызовы функций, создание объектов и операции выделения памяти.

Реклама. ООО «АППСЕК СОЛЮШЕНС», ИНН: 7726435251, Erid: 2VfnxwMix3j