Безопасность

Обновлено 3 августа 2026

TLS-аутентификация

Для защиты канала связи используется взаимная TLS-аутентификация (mTLS). Банк предъявляет свой клиентский сертификат, а ваш сервер обязан его проверить.

Для этого добавьте в доверенное хранилище вашего сервера цепочку сертификатов УЦ Банка:

• Корневой сертификат
• Промежуточный сертификат

В настройках сервера включите обязательную проверку клиентских сертификатов.

Серверный сертификат должен быть получен в одном из аккредитованных банком УЦ:

Национальные УЦ Российской Федерации:

• НУЦ (УЦ Минцифры России)
• НСПК (УЦ Национальной системы платежных карт)

Дополнительно рекомендуется проверять расширение SAN CI00854520PROMCSYNGXExternal сертификата на прикладном уровне — это позволяет привязать доступ к имени конкретного сервиса и не потерять безопасность при замене сертификата.

Проверка подписи запроса

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

1. Определение формата

Обратите внимание на заголовок Content-Type запроса:

• Если его значение — application/jose, это означает, что тело запроса упаковано в специальный формат JWS (JSON Web Signature) в компактном виде.

2. Структура подписанного сообщения

Сообщение состоит из трех частей, разделенных точками (.):

Заголовок.Полезная_нагрузка.Подпись

Каждая из этих частей кодируется в безопасный для передачи формат Base64Url.

• Стандарт: Описание формата JWS регулируется международной спецификацией RFC 7515 .

• Криптография: Используется алгоритм ГОСТ Р 34.10-2012 (для электронной подписи) совместно с хэш-функцией ГОСТ Р 34.11-2012.

3. Разбор частей

• Заголовок (Header): Это служебный JSON-блок, который говорит, как именно подписано сообщение. Он всегда содержит два поля:

  {
    "typ": "JOSE",
    "alg": "gost34.10-2012"
  }

• "typ": "JOSE" — тип токена.

• "alg": "gost34.10-2012" — алгоритм шифрования, используемый для подписи (российский стандарт ГОСТ).

• Полезная нагрузка (Payload): Это и есть само тело уведомления, содержащее данные о событии (реквизиты, статусы и т.д.). Содержимое этой части соответствует тому, что вы ожидаете получить в событии.

• Подпись (Signature): Это результат криптографического преобразования. Она вычисляется на основе первых двух частей сообщения (Заголовка и Полезной нагрузки), соединенных точкой.

4. Как проверить подпись (алгоритм действий)

Чтобы убедиться в целостности данных, ваш сервер должен выполнить следующие шаги:

1. Разделите полученную строку по символу . на три части.
2. Возьмите первые две части (Заголовок и Payload) и склейте их обратно через точку в том виде, в каком они пришли. Это будет строка для проверки.
3. Используя открытый ключ Банка и алгоритм gost34.10-2012, вычислите сигнатуру для полученной строки.
4. Сравните вычисленный результат с третьей частью (присланной Подписью). Если они совпадают — запрос подлинный и не был изменен.

Важно: Не пытайтесь декодировать первую и вторую части перед проверкой подписи. Подпись всегда вычисляется именно от строки в формате Base64Url(Header) || '.' || Base64Url(Payload).