Внедрение новых информационных технологий в банке – всегда компромисс. Как бы нам с одной стороны сделать лучше для клиента, с другой не вызвать негативных комментариев коллег из ИБ, а с третьей – продумать перспективу и доказать её пользу для всего банка в целом. Еще и зерна от плевел нужно отличить и понять, какая технология будет перспективнее на дистанции.
Всем привет! Меня зовут Алексей Шарненков, я работаю руководителем направления в Центре компетенций интеграционных решений МКБ. Под катом расскажу о том, зачем мы внедрили спецификацию OpenAPI, какие у нас были сложности и почему мы все равно уверены, что оно того стоило.
Зачем МКБ OpenAPI
В октябре 2021 года мы завершили прием заявок на участие в “Непрерывной акселерационной программе ИТ-инновации”. Цель этой программы – поиск перспективных технологических проектов в сфере финтеха. Цифровой мир постоянно меняется, а банковский сектор стоит на гребне этой волны, хоть и с серьезной оглядкой на безопасность.
Бизнес-подразделения определили восемь ключевых направлений, одним из которых стали решения в области OpenAPI. Эта спецификация предназначена для подключения банков к доверенной среде Открытых банковских интерфейсов Банка России (ОБИ) для обеспечения возможности цифрового обмена данными с поставщиками услуг (с согласия клиента) и клиентами и предоставления финансовых услуг.
Внедрение спецификации обеспечивает удобство обмена информацией между участниками рынка и снижение издержек на вывод новых продуктов. Кроме того, по инициативе Центрального Банка (ЦБ) изучением возможностей OpenAPI активно занимается Ассоциация ФинТех. В будущем это приведет к созданию на его базе новых стандартов, обязательных для всех, и в этом случае мы окажемся в числе новаторов, у которых уже все будет готово.
Что такое OpenAPI-спецификация
Договоримся, что разбирать до атомов спецификацию мы в рамках этого материала не будем: хоть это и статья на Хабр, сам OpenAPI прекрасно описан в других местах. Тем более, для нас это было отчасти “коробочное” решение.
Спецификация не требует доступа к коду, что упрощает механизм передачи данных: не нужно думать, на каком языке написан “приёмник”. Спецификация представлена двумя форматами, JSON, который удобен для взаимодействия информационных систем без участия человека, и YAML, в котором человек определенной сноровки имеет неплохие шансы разобраться при необходимости.
Из этого становится понятно, почему OpenAPI Центральный Банк видит будущим стандартом в отрасли. Банки используют разные решения, а новая спецификация позволит перейти на единый стандарт, по которому всем будет удобно обмениваться информацией. “Открытость” решения в данном случае не будет проблемой, а скорее, наоборот, способствует скорейшему закрытию уязвимостей.
OpenAPI в перспективе должен стать не просто стандартом, а целой философией, основанной на унификации. Он позволит использовать общие правовые нормативы и тестовые сертификационные регламенты. Ключевой выгодой для банков будет снижение value, причем как в части времени на разработку решения, так и в части обеспечения качества и безопасности.
Почему нельзя так просто взять и сделать
Когда вы хотите развернуть внутри организации сложную информационную систему, вы можете пойти несколькими путями. Первый путь – внутренняя разработка. Для этого можно использовать либо сотрудников, обладающих нужными компетенциями, либо пригласить новых специалистов. Но штат, который расширяется без ограничений, не самая изящная бизнес-модель. Без конца перебрасывать сотрудников с проекта, где они уже работают, на что-то новое тоже не получится. И, хотя все мы любим новые задачи, иногда нужно признать, что развитие не должно идти в ущерб стратегическим задачам. Поэтому существует второй путь.
Он более гибкий и предполагает найм команды-интегратора. На рынке можно найти профессионалов, которые уже преуспели в решении конкретной задачи или имеют опыт в смежных направлениях. По этому пути пошли мы, разместив заявку на внедрение решения на основе OpenAPI, которое бы позволило присоединиться к среде ОБИ Банка России. Откликнулась компания eKassir, разработчик ПО для банков и кредитных организаций.
Что предложил eKassir
Компания eKassir оказалась единственной, предложившей нам готовое “коробочное” решение. Подобное ПО обычно “подпиливается по месту” под нужды заказчика, но освобождает от необходимости лезть в заказную разработку. Плюсы решения: обкатанность на других проектах и стоимость. Полностью их продукт называется eKassir OpenAPI Adapter.
В этом программном обеспечении реализована поддержка Стандарта безопасности СТО БР ФАПИ.СЕК-1.6-2020 Банка России, а также двух прикладных стандартов: «Открытые банковские интерфейсы. Получение информации о счете клиента третьей стороной» и «Открытые банковские интерфейсы. Кроме того, в качестве сервера авторизации Open API Adapter используется то же решение, что и в сертификационном стенде «Ассоциации ФинТех» — eKassir Access Manager.
OpenAPI Adapter мы тщательно оценили с помощью внутренних и внешних экспертов. Результаты аудита нас более, чем устроили.
Без труда не вытащишь и Docker в Kubernetes
Пилотный проект стартовал в марте 2022 года. По плану к 31 мая должны были быть внедрены все компоненты OpenAPI Adapter в инфраструктуру МКБ и банк должен был успешно пройти сертификацию на стенде “Ассоциации ФинТех”. Все работы можно условно поделить на 3 этапа: сборка прототипа, внедрение, финальное тестирование и сертификация на стенде.
Первый этап: собираем рабочий конфиг на стенде подрядчика
Начинать работы сразу на стендах МКБ смысла не было: во-первых, не так-то просто стороннему разработчику начать что-то делать внутри контура банка, во-вторых, никакой смысловой нагрузки это не несло. Всю “черновую” работу можно было произвести на своих серверах. Инфраструктура при этом должна была эмулировать МКБ. Для этого eKassir использовали API-платформу Postman.
После окончания подготовительных работ решение передали на внутренний аудит, и тут выявились проблемы: в нескольких библиотеках .NET и JavaScript, используемых в OpenAPI Adapter, обнаружились уязвимости. Это произошло из-за того, что между запуском сертификационного стенда Ассоциации Финтех и пилотного проекта в МКБ прошло несколько месяцев, за которые стандарт OpenAPI успел измениться. Также теперь он требовал перехода на процесс разработки ПО Secure SDLC. Если кратко, это методология, направленная на производство безопасного от взломов ПО. Согласно этой методологии, обнаружение бага на этапе разработки будет стоить в разы дешевле, чем заплатка уязвимости после релиза. На подстройку наших процессов под новые требования также ушло время.
Этап второй: контейнеровоз прибывает в порт
Вскрылась проблема, которой на старте не было придано достаточное внимание. Команда eKassir передала коллегам из МКБ настроенные Docker-контейнеры, но вот незадача: в МКБ уже пользовались Kubernetes. Потребовалось время, чтобы адаптировать разные среды контейнеризации друг к другу, но в конечном итоге задача была решена, хоть и часть конфигурационных настроек при этом потеряли.
После распаковки контейнеров нужно было ещё немного поработать с сетевой инфраструктурой: настроить прокси, выпустить сертификаты, закончить настройку криптографии. Сроки проведения пилотного проекта, как вы уже догадались, пришлось увеличить.
Этап третий: стучимся на тестовый стенд, слышим стуки в ответ
Итак, после настройки всего, что входило в комплекс решения, нам необходимо было пройти тестовые испытания на сертификационном стенде Ассоциации ФинТех (АФТ). Он построен на базе решения “Access Manager” вендора eKassir и является частью технологической песочницы АФТ. Стенд нужен для того, чтобы тестировать банковские открытые API и приложения на соответствие стандартам ЦБ РФ. Доступ к этому стенду получают все организации, присоединившиеся к “соглашению о соблюдении стандартов ОБИ”.
Модуль “песочница” состоит из 2-х частей: “песочница 0” и “песочница”. К первой части доступ может получить любая организация, прошедшая регистрацию на портале ОБИ. Там можно тестировать API и приложения ограниченным набором сценариев без проверки настроек информационной безопасности. Доступ ко второй части получают только организации, которые подписали соглашение “о соблюдении стандартов ОБИ”.
Для защиты данных стандарт предполагает использование OIDC для идентификации и аутентификации, компактный формат для передачи утверждений между сторонами JWT и криптографического протокола взаимной аутентификации mTLS, который позволяет клиентской и серверной стороне верифицировать сертификаты друг друга.
При прохождении тестов по стандарту Банка России СТО БР ФАПИ.СЕК-1.6-2020 у нас возникли проблемы из-за некорректной настройки mTLS. Сам по себе протокол трудностей не вызывал, а вот конфигурация связанного с ним WAF потребовала корректировок. Эксперты eKassir быстро уточнили все нюансы и mTLS заработал, как положено.
Для прохождения официальной процедуры тестирования необходимо отправить запрос в Ассоциацию ФинТех через кабинет банка на сайте openbankingrussia.ru. После этого будет открыто временное окно в 7 дней, в течении которого необходимо завершить все тесты с логированием результата. При тестировании в “боевом” модуле происходят сценарии, похожие на реальную жизнь, то есть как позитивные, так и негативные. OpenAPI Adapter успешно справился всего за 2 часа в то время, как без него тестирование занимает от 1 до 7 дней.
Что под капотом у OpenAPI Adapter
В предыдущих разделах мы ссылались на целый пласт различных нормативных документов, технологий, протоколов и так далее. Теперь покажем, как работают механизмы безопасности OpenAPI.
Базовая вещь - сервисы внутри инфраструктуры не могут постоянно общаться по сложным протоколам с постоянной аутентификацией. Согласитесь, было бы странно, если бы вы каждую комнату в своей квартире запирали на ключ - у вас для защиты от воров есть хорошая входная дверь и стены. Для eKassir OpenAPI adapter такой дверью являются два Identity Gateway (IG), которые выполняют роль API Gateway. Всё это нагромождение слов выполняет роль шлюза, который отделяет внешнюю сеть от Intranet (INT), сети локальной.
Один IG расположен в сегменте сети DMZ. Этот сегмент доступен для обращений как из Интер-, так и из Интранета. Он служит некоей буферной зоной - будем считать её предбанником в нашей метафоре, дополнительным рубежом безопасности. IG INT общается с ним из локальной сети. Соединение инициировано из доверенной зоны по протоколу WSS и всегда открыто.
Identity Gateway обогащает прикладной API доступа к счету информацией о ресурсе согласия и отправляет обогащенный запрос на сервис Account Service. IG выполняет работу ФАПИ.СЕК, в том числе привязку транспортного сертификата к токену доступа, проверку на идемпотентность, валидацию цифровой подписи тела прикладного запроса и так далее.
Теперь МКБ – участник ОБИ
Как вы уже поняли, проект успешно завершен. МКБ стал полноценным участником среды ОБИ в роли поставщика платежных услуг для сценария “Получение информации о счете клиента третьей стороной” и обрел опыт работы по стандарту безопасности ФАПИ.СЕК-1.6-2020.
С одной стороны, мы не уложились в первоначальные сроки. Но, как и с любой интеграцией, а тем более с банковским регулятором, этого можно было ожидать. Проблемы мы решали оперативно, и единственное, что можно было бы предусмотреть, – несоответствие механизма контейнеризации у подрядчика принятому в банке.
OpenAPI Adapter показал себя как отличный инструмент для решения конкретной задачи в понятные сроки. Возможно, существует способ что-то оптимизировать конкретно для нас или написать полностью кастомное приложение, но скорость разработки и внедрения точно оказалась бы ниже. Никаких подводных камней нами обнаружено не было, решение прошло строгий аудит: в банках по-другому никак. Буду рад узнать ваше мнение о внедрённом решении и обсудить альтернативные сценарии в комментариях.