Положение № 851-П: новое нормативное поле защиты платежей. Практический подход

Ирина Чурикова, директор по работе с финансовым сектором SAFETECH, о том, как Положение № 851-П меняет подход к защите платежей, почему SMS- и push-коды больше не работают, чем опасны «обходные» схемы с облачной подписью и какие практические шаги банкам стоит сделать, чтобы выполнить требования регулятора и снизить уровень мошенничества.

С 1 октября 2025 г. в соответствии с Положением 851-П1 российские банки должны обеспечить своим клиентам подтверждение операций по новым правилам, применяя криптографические механизмы для обеспечения целостности электронных сообщений. Стремясь выполнить требования Положения 851-П быстро и с минимальными затратами, некоторые банки рассматривают «обходные» пути, которые не обеспечивают реальной информационной безопасности. Разбираем ошибочные и правильные подходы.

Проблема мошенничества в системах дистанционного банковского обслуживания носит глобальный характер. В связи с этим финансовые регуляторы во многих странах, например США, Европе, Австралии, Сингапуре, вводят запреты на использование уязвимых технологий, таких как направление одноразовых кодов через SMS и push-уведомления. Россия активно поддерживает эту тенденцию. Банк России выпускает нормативные акты, обязывающие кредитные организации использовать средства криптографической защиты информации (СКЗИ) для подтверждения целостности и подлинности электронных сообщений. Данная мера направлена на устранение распространенных сценариев мошенничества, связанных с компрометацией SMS и push-кодов. Статистика Банка России подтверждает критичность ситуации: общий объем хищений через цифровые каналы в 2024 г. превысил 27 млрд руб., при этом банки возместили клиентам около 9% от этой суммы. Эти цифры наглядно демонстрируют, что традиционные методы защиты перестали быть эффективными, а финансовые потери несут как клиенты, так и сами кредитные организации.

Задача регулятора заключается в комплексном противодействии мошенничеству. Борьба с социальной инженерией сложна и не может быть решена одним действием, тогда как нейтрализовать технические уязвимости, связанные с OTP-кодами, — достижимая цель. Обеспечив безопасность транзакций с помощью СКЗИ, банки устраняют саму необходимость в применении SMS и push-кодов. Как следствие, это позволяет исключить целый класс мошенничества — MiTM-атаки: перехват кодов на уровнях канала и агрегатора, использование вредоносного ПО для их кражи, фишинг, перевыпуск SIM-карты, переадресацию сообщений с кодами, разглашение кодов самими клиентами и иные. С 1 октября 2025 г. российские банки должны обеспечить своим клиентам подтверждение операций по новым правилам: использование SMS и push-кодов не соответствует данным требованиям (рис. 1).

Рисунок 1 — Уязвимость SMS-кодов на всех этапах жизненного цикла

Что именно требует Положение № 851-П: от OTP-кодов — к криптографии

Пункт 5.1 Положения 851-П обязывает банки применять исключительно криптографические механизмы для обеспечения целостности электронных сообщений (рис. 2):

Рисунок 2 — Анатомия реализации требований Положения № 851-П

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

2. Усиленную неквалифицированную электронную подпись (УНЭП) или усиленную квалифицированную электронную подпись (УКЭП), созданную с использованием средств, сертифицированных ФСБ России. Критически важный аспект — место размещения СКЗИ. СКЗИ должны функционировать на контролируемой клиентом стороне — его устройстве: именно это и требует регулятор в Положении 851-П. Только такой подход гарантирует:

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

Риски невыполнения Положения № 851-П: больше, чем штрафы

Нарушение требований может привести не только к известным рискам банка, таким как:

— репутационные риски: банк, продолжающий использовать SMS и push-коды, становится легкой мишенью для мошенников. Каждый успешный инцидент хищения наносит ущерб доверию клиентов к банку;

— финансовые потери: прямые убытки клиентов от невозвращенных средств продолжают расти. Дополнительно банк несет расходы на возмещение похищенных средств, расследование инцидентов, урегулирование споров и саму рассылку SMS и push-кодов;

— правовые риски: растет количество судебных разбирательств с клиентами, оспаривающими операции, подтвержденные скомпрометированными OTP-кодами, но и к более серьезным последствиям. Так, Банк России вправе применить следующие меры при выявлении нарушений установленных требований:

• предписание об устранении нарушений (срок до 30 дней);
• наложение штрафа первоначально до 0,1% уставного капитала кредитной организации, при неисполнении предписания — до 1% уставного капитала;
• ограничение проведения операций (полное или частичное);
• запрет на открытие филиалов;
• введение временной администрации;
• отзыв лицензии (в крайних случаях).

Типичные ошибки: иллюзия соответствия требованиям

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

«Облачная» электронная подпись

Суть подхода: Ключ ЭП хранится в HSM на стороне банка — в «облаке». Клиент для доступа к своему «облачному» ключу для подписания электронного документа вводит OTP-код, полученный через SMS/push. Банк считает, что раз подпись создается сертифицированным СКЗИ, требования выполнены.

Почему это ошибка:

1. Нарушение принципа «контролируемой клиентом стороны». Ключ подписи физически не находится у клиента. Мошенник, перехвативший сессию в браузере или мобильном приложении (через троян), может инициировать платеж на свои реквизиты, а для его подтверждения запросить OTP, который клиент и введет, думая, что подтверждает свой платеж.
2. Уязвимости каналов доставки ОТР-кодов: SMS/push. При использовании такого вида подписи не производится повышение уровня информационной безопасности, так как остаются все те же уязвимости, связанные с ОТР-кодами, — MiTM-атаки: перехват кодов на уровнях канала и агрегатора, использование вредоносного ПО для их кражи, фишинг, перевыпуск SIM-карты, переадресация сообщений с кодами, разглашение кодов самими клиентами.
3. Отсутствие целостности данных на клиентском устройстве. Клиент подписывает одним OTP-кодом «слепую» транзакцию, каналы передачи SMS/push-сообщений не позволяют обеспечить визуализацию подписываемых данных. Возможна MiTM-атака, когда вредоносное ПО меняет реквизиты платежа после ввода OTP, но до отправки на сервер.
4. Легитимность: на сегодняшний день нет сертифицированных ФСБ России решений «облачной» подписи.

Формирование имитовставки на стороне сервера

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

Суть подхода: банк на своем сервере вычисляет имитовставку (например, с использованием HMAC на алгоритме ГОСТ) от содержимого электронного документа и своего ключа. Полученное зна- чение усекается до короткого кода (например, 6 цифр) и отправляется клиенту по SMS/push. Клиент вводит этот код, а банк, сверив его, считает, что документ аутентифицирован и его целостность под- тверждена.

Почему это ошибка:

1. Отсутствие криптографической привязки к действиям клиента. Данные, которые клиент видит на экране своего устройства, и данные, которые были обработаны сервером, не связаны криптографически. Злоумышленник может подменитьреквизиты транзакции на устройстве клиента (например, с помощью вредоносного ПО), после чего клиент, сам того не зная, подтвердит своим кодом уже измененный документ.
2. Уязвимость канала доставки кода подтверждения. Каналы SMS и push-уведомлений не являются безопасными и могут быть перехвачены или скомпрометированы. Доставка по ним даже части имитовставки (кода) создает дополнительный риск.
3. Невыполнение требования аутентификации отправителя. Поскольку имитовставка создана сервером, а не клиентом, она не может служить доказательством того, что документ был сформирован и отправлен именно этим клиентом.

Использование «эфемерных ключей» в рамках одностороннего TLS-соединения

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

Почему это ошибка:

1. Аутентификация клиента отсутствует в принципе. Любой пользователь, успешно прошедший начальный логин и пароль, может установить защищенное TLS-соединение с банком. Протокол не отличает легитимного клиента от мошенника, укравшего учетные данные.
2. После расшифровки на стороне сервера банка нет криптогра- фического доказательства (подписи или имитовставки), что именно клиент сформировал иутвердил именно эти реквизиты платежа.
3. Уязвимость к атакам на активной сессии. Если сессия клиента скомпрометирована (например, через вредоносное ПО или MiTM-атаку), мошенник может инжектировать в эту зашифрованную сессию модифицированное платежное поручение. TLS честно передаст его на сервер, так как не проверяет смысловое содержание и источник транзакции внутри сессии.

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

Практические рекомендации
по выполнению Положения № 851-П для банков

Чтобы обеспечить соответствие Положению 851-П и избежать рисков, банкам стоит придерживаться следующих принципов:

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

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

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

Требования Положения 851-П не существуют «в вакууме» и могут быть реализованы в рамках единой криптографической инфраструктуры. Такой подход может быть применим не только в проекте цифрового рубля, регулируемого Положением  833-П.

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

• Сокращение размера мобильного приложения. Использование единого криптографического модуля для всех задач позволяет избежать дублирования функциональности и сокращает итоговый размер мобильного приложения.
• Экономия на затратах на разработку и сопровождение. Интеграция и последующее обновление СКЗИ (например, при смене версий или алгоритмов) выполняются один раз, что значительно сокращает трудозатраты команды разработки.
• Сокращение затрат на приобретение лицензий на СКЗИ.
• Упрощение пользовательского пути (пример: однократный вызов БиоДСЧ — биометрического датчика случайных чисел) может обеспечить энтропией сразу несколько процессов — и подписание документа по Положению 851-П, и операцию с цифровым рублем. Это не только упрощает сценарий для пользователя, но и укрепляет безопасность, минимизируя число обращений к критически важным функциям.

Использование СКЗИ не только повышает уровень информационной безопасности, но и упрощает клиентский опыт: отпадает необходимость ввода OTP-кодов, что делает подтверждение операций быстрым и удобным.

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

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