26 сентября 2023, 11:42
Количество просмотров 4138

Как мы интегрировали Open API Adapter в контур банка. Опыт МКБ

Летом 2022 года МКБ (Московский кредитный банк) стал участником среды Открытых банковских интерфейсов (ОБИ) Банка России, интегрировав спецификацию Open API. Проект успешно завершен, и теперь команда МКБ готова создавать новые инновационные сервисы для клиентов. Как внедрить открытые интерфейсы в банковской сфере и снизить риски на этом непростом пути, рассказывает Сергей Костюк, советник заместителя председателя правления МКБ.
Как мы интегрировали Open API Adapter в контур банка. Опыт МКБ

Зачем все это надо

Для банковской среды Open API — это способ упростить обмен данными между банковской системой и другими компаниями (например, другими кредитными организациями). За счет этого банк может создать более комфортный клиентский сервис. Например, если человек захочет взять кредит в стороннем банке, он получит решение по своему запросу в один клик — банк-кредитор и банк, в котором обслуживается покупатель, за секунды обмениваются данными. Без него клиенту пришлось бы ходить и собирать документы.

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

Сейчас, развивая и внедряя у себя Open API, банк может подключаться к среде ОБИ ЦБ РФ: своеобразной интернет-витрине, к которой удобно давать доступ партнерам, бизнес-заказчикам. Программисты и партнеры через эту среду-витрину могут получить всю нужную документацию, что также ускоряет подключение нового продукта. К тому же стандарты этой среды обеспечивают высокую безопасность, создаются лидерами индустрии и утверждены Банком России.

Особенности внедрения финтех-решения в банке

Для интеграции адаптера выбранное решение должно соответствовать стандарту Банка России СТО БР ФАПИ.СЕК-1.6-2020 и пройти обязательные тесты на сертификационном стенде «Ассоциации ФинТех» (АФТ). Сначала в ограниченном режиме, а потом в расширенном («боевом») — с проверкой настроек ИБ (информационной безопасности).

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

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

Мы решили подключать Open API с помощью сторонней команды-интегратора и использовали готовое коробочное решение, поскольку нашли проверенный продукт, обкатанный на других проектах. Для выбора подходящего решения мы проводили аудит с помощью внешних и внутренних экспертов.

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

Как это было: этапы внедрения и сложности

На этапе подготовки мы собрали рабочую конфигурацию (прототип) на стенде подрядчика. В процессе подготовки обнаружили, что не все так просто: с момента запуска сертификационного стенда АФТ до начала нашего пилотного проекта прошло много времени, стандарт Open API изменился. В итоге в части библиотек.NET и JavaScript в адаптере мы нашли уязвимости.

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

Дополнительное время ушло также на проработку сетевой инфраструктуры — настроить прокси, выпустить сертификаты, настроить криптографию — средства информационной безопасности, которые применяются в банке, для соответствия стандарту ЦБ РФ. Этим занимались специалисты самого банка из отдела ИБ, используя информацию, которую предоставлял вендор коробочного решения.

Взаимодействие шло в несколько этапов — то, что можно было выполнить за 1–2 часа, заняло несколько дней. Не всегда удавалось сразу в полном объеме получить информацию от вендоров, как именно должны быть сконфигурированы настройки средств безопасности. Приходилось как-то стыковаться со всеми участниками процесса, чтобы все обсудить. Мы проводили тесты и получали замечания, что обмен произошел неудачно, — нам корректировали исходные данные средств защиты. Но после нескольких итераций мы успешно выполнили настройку криптографии.

Когда мы закончили все настройки, наступил этап отладки на сертификационном стенде АФТ. Нужно было протестировать открытые API банка и приложения на соответствие стандартам ЦБ РФ. Эти тесты мы успешно прошли, но столкнулись с некорректной настройкой mTLS — криптографического протокола взаимной аутентификации, необходимого, чтобы клиент и сервер друг друга правильно опознали. На корректировку конфигурации связанного с ним межсетевого экрана WAF — с помощью специалистов на стороне вендора также потребовалось время.

Финальным этапом стала заявка на официальную процедуру тестирования в АФТ. После ее запуска банк должен завершить тесты в «боевом» модуле с разными реалистичными сценариями в течение 7 дней и логировать результат. Успех — когда все сценарии пройдены без замечаний за один подход. Интегрированный адаптер справился с этим за два часа.

Топ-3 рекомендаций бизнесу по интеграции Open API

  1. Определите, как будете развивать все интеграции и внедрения в компании. Если в ближайшей перспективе их немного, разумно будет искать квалифицированные отработанные решения на рынке и устанавливать их в контур банка. Если же бизнес планирует покрывать десятки или сотни внешних разнонаправленных интеграций, лучше взращивать собственную экспертизу специалистов и знания в направлении открытых интерфейсов.
  2. Не пренебрегайте подготовкой: проверяйте соответствия механизма контейнеризации у подрядчика принятому в банке механизму, есть риски потерять много времени в процессе интеграции. Потратьте больше времени на анализ настроек, шаблонов и пр.
  3. Если есть возможность предоставить специалистам вендора доступ в контур банка, предоставляйте. Для этого понадобится оформить отдельное разрешение, но этот шаг может спасти и от ошибок, и от потерянного времени, поскольку позволит провести более глубокий анализ на этапе подготовки.
Рубрика:
{}Open Banking

PLUSworld в соцсетях:
telegram
vk
dzen
youtube