Односторонний обмен 1С с API банковской системы — разработка в условиях отсутствия документации

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

При отсутствии документации API — поможет Postman

Первое, с чем мы столкнулись еще до начала разработки, это отсутствие документации для методов API — сервис был совсем свежий, и еще не было кейсов его интеграции с 1С.

Нам была предоставлена спецификация для API в формате YAML — описание конечных точек с параметрами, типами данных и возвращаемыми значениями. Для работы с ней мы использовали Postman, который позволяет на основе файла YAML создать удобную для чтения коллекцию методов API с возможностью генерации кода запросов на разных языках программирования.
 

Postman — инструмент, предназначенный специально для тестирования и разработки API

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

Экспорт Postman запроса в cUrl

Postman также позволяет выбрать клиентский сертификат для отправки запроса, что было актуально в нашем случае, так как API работает по протоколу mTLS.

Настраиваем криптографию: mTLS, «КриптоПро», ViPNet

Следующая задача, которую надо было решить — реализовать особый подход к безопасности API банка. Вместо обычного TLS он работает на протоколе mTLS — при таком варианте для подключения и отправки запросов кроме серверного сертификата требуется также и клиентский. Сертификаты, используемые для подключения, должны быть нового формата ГОСТ-2012, который 1С не поддерживает без установки криптопровайдера.

Помимо этого, для верификации запросов механизм банка предполагал в заголовок запроса прикладывать открепленную подпись тела в формате CAdES-X Long Type 1. Данный формат 1С также не поддерживает, и для работы с ним необходимы внешние программы.
 

Типовой менеджер криптографии не поддерживает формат CAdES-X Long Type 1

Для работы с API предполагалось использовать «КриптоПро», все сертификаты подключения банка выпущены именно под этот криптопровайдер. Для подписания документов «КриптоПро» также предоставляет утилиту командной строки cryptcp.exe, которая может быть использована из 1С и поддерживает нужный формат подписи.

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

Доступным и бесплатным аналогом «КриптоПро», который поддерживает работу с 1С, является ViPNet. Но, повторимся, все сертификаты безопасности банка были выпущены для работы с «КриптоПро» и не могут быть установлены с помощью ViPNet. Решение нашлось на партнерском форуме 1С: Gost PEM Extractor — бесплатный аналог P12FromGostCSP для извлечения сертификата и ключа в PEM формате из ГОСТ-контейнера.
 

Gost PEM Extractor в Docker-контейнере

После этого осталось разобраться с форматом подписи для тела запросов. ViPNet не предоставляет приложение командной строки для работы с криптографией, так что в распоряжении у нас остались лишь типовые возможности платформы 1С. Здесь на помощь пришли разработчики API банка, разрешив нам использование стандартного формата подписи с меткой времени CAdES -T.
 

Работа с электронной подписью: иногда не обойтись без человека

Мы успешно протестировали механизм решения на тестовом контуре API банка. Однако при переходе на рабочий контур возник ещё один нюанс — необходимость использовать квалифицированную электронную подпись вместо неквалифицированной. УКЭП предполагает бОльшую юридическую силу, чем УНЭП, и, соответственно, бОльшую опасность при утечке доступа. Оставлять квалифицированную подпись вместе с паролем на сервере организации для использования регламентным заданием было нельзя, слишком большая брешь в безопасности.

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

***

В итоге разработано решение для одностороннего обмена 1С с банком, которое соответствовало требованиям безопасности заказчика, и в процессе удалось сократить затраты на приобретение дополнительных лицензий ПО.