Стандарт безопасности ФАПИ.СЕК. Детали и главное

Стандарт безопасности ФАПИ.СЕК. Детали и главное

Рынок финансовых технологий движется в сторону поэтапного перехода к свободному информационному обмену на основе Открытых API. В конце 2023 года Ассоциация ФинТех, оператор среды открытого банкинга, опубликовала исследование [1] ряда реальных бизнес-кейсов, в которых были применены открытые программные интерфейсы. Двусторонняя передача данных между банками, оформление цифровой ипотеки, быстрое согласование медицинских услуг — все эти задачи успешно решаются «в один клик» при помощи Открытых API.

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

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

ЗНАКОМЬТЕСЬ, ФАПИ.СЕК!

Концепция Открытых API опирается на применение двух компонентов:

• Прикладные стандарты — такие как стандарты «Инициирования перевода денежных средств клиента» [2] и «Получения информации о счёте клиента» [3]. С последующим внедрением технологии открытого информационного обмена на российский рынок количество таких стандартов будет возрастать.
• Протоколы безопасности финансовых операций — ФАПИ.ПАОК и ФАПИ.СЕК.

Летом 2021 года Банк России утвердил и ввёл в оборот один из ключевых  стандартов Открытых API — СТО БР ФАПИ.СЕК-1.6–2020 [4] «Безопасность финансовых (банковских) операций. Прикладные программные интерфейсы обеспечения безопасности финансовых сервисов на основе протокола Open ID» (далее — ФАПИ.СЕК).

Стандарт ФАПИ.СЕК описывает обязательные требования по использованию криптографических механизмов и взаимной аутентификации на уровне транспортного слоя (mTLS). Он задаёт алгоритмы подписи и шифрования сообщений в процессе информационного обмена и унифицирует требования для систем аутентификации клиентов в финансовых приложениях и для подтверждения операций.

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

В отличие от СТО БР ФАПИ.ПАОК-1.0.2021 [5], который ещё не реализован участниками и не представлен на сертификационном стенде Ассоциации ФинТех, ФАПИ.СЕК получил распространение в России и уже применяется в пилотных проектах по открытому банкингу. Разобраться с механизмами организации безопасного обмена данными, регламентированными этим стандартом, поможет его ретроспектива.

ЯВНОЕ СОГЛАСИЕ ПОЛЬЗОВАТЕЛЯ

От других моделей информационного обмена Открытые API отличает обязательность явного согласия пользователя на передачу и хранение данных. Без осведомлённого участия владельца бизнес-информации запустить обмен невозможно. Согласие бывает двух видов. 

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

Рассмотрим ситуацию, когда существует некий кешбэк-сервис, предоставляющий клиенту финансовое приложение для возврата денежных средств. Сам сервис выступает в роли потребителя Открытых API — а как в этом случае проявляются обязательства, накладываемые на участников информационного обмена стандартом ФАПИ.СЕК?

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

ИНФОРМАЦИОННЫЙ ПОТОК ФАПИ.СЕК

Стандарт СТО БР ФАПИ.СЕК-1.6–2020 разработан на основе технологии защищённой авторизации OAuth 2.0 и профилирующего её протокола Open ID Connect. OAuth 2.0 [6] — протокол авторизации, который позволяет одному сервису (приложению) получить доступ к данным другого приложения (сервера ресурсов). В этом случае сервис может авторизоваться от имени владельца ресурса, но при этом аутентичные учётные данные ему не передаются. Open ID Connect (OIDC) [7] — расширение протокола OAuth 2.0, отвечающее за аутентификацию владельца ресурса и передачу стороннему сервису точной информации о нём. 

СТО БР ФАПИ.СЕК-1.6–2020 не новый стандарт, он базируется на OAuth 2.0, OIDC и Financial-Grade API. Чтобы проследить «эволюционный» путь стандарта Банка России, необходимо рассмотреть преимущества и недостатки его предшественников (рис. 1).

Рисунок 1. Информационный поток стандарта ФАПИ.СЕК

Для этого вернёмся к примеру с приложением кешбэк-сервиса и опишем пути передачи информации, обеспечивающие взаимодействие в рамках стандарта ФАПИ.СЕК:

• Пользователь регистрируется в приложении, затем изъявляет желание передать кешбэк-сервису доступ к своим банковским счетам и для этой цели выбирает нужный.
• Чтобы подтвердить подлинность обращения, кешбэк-сервис передаёт аутентификационный запрос на сервер авторизации, после чего перенаправляет пользователя в выбранный им банк.
• Пользователь видит знакомый экран входа в банковское приложение и авторизуется по своим реквизитам — логину, паролю и/или второму фактору аутентификации, доступа к которым кешбэк-сервис не имеет. Далее пользователь получает запрос на авторизацию согласия кешбэк-сервиса для временного доступа к счёту и, если всё в порядке, авторизует его. 
• Сервер авторизации выпускает и передаёт токен доступа кешбэк-сервису, который, вызвав прикладные Открытые API, при каждом следующем обращении этот токен предъявляет.

ПРОТОКОЛ АВТОРИЗАЦИИ OAUTH 2.0

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

Рисунок 2. Принцип работы токенов доступа и обновления

Для этого протокола авторизации важны два объекта — токен доступа (access token [8]) и токен обновления (refresh token [9]). Первый характеризует крайне ограниченное время жизни. Обычно он действует не более часа, так что для выдачи долгосрочного согласия одного токена доступа недостаточно. Проблему решает токен обновления: используя его, кешбэк-сервис может запрашивать новые токены доступа на протяжении всего времени обращения к ресурсам пользователя.

Тем не менее полностью решить задачу, возложенную на стандарт Открытых API, протокол OAuth 2.0 не может: разработчиками он позиционируется как фреймворк, который нуждается в дальнейшем профилировании.

ПРОТОКОЛ АУТЕНТИФИКАЦИИ OPEN ID CONNECT

Протокол Open ID Connect представляет собой расширительный слой OAuth 2.0, дополняющий его идентификационным токеном (ID token), через который банк передаёт информацию о пользователе третьей стороне (кешбэк-сервису из примера выше). В ID token можно «зашить» подтверждающую личность пользователя информацию — полные имя и фамилию или адрес электронной почты. Когда кешбэк-сервис отправит запрос на сервер авторизации в следующий раз, в ответ он получит оба токена (идентификации и доступа) и со стопроцентной точностью удостоверит подлинность своего обращения.

В отличие от OAuth 2.0, протокол OpenID Connect поддерживает защиту запроса аутентификации, поэтому злоумышленникам гораздо сложнее подменить его содержимое. Open ID Connect содержит набор параметров, дополнительно увеличивающих информационную безопасность. Такой механизм гарантирует целостность аутентификации сервиса, то есть его абсолютную неотрекаемость от сформированной цифровой подписи.

МЕЖДУНАРОДНЫЙ СТАНДАРТ FINANCIAL-GRADE API

Протокол Open ID Connect носит общий характер, благодаря чему его можно адаптировать под различные требования к информационной безопасности. В частности, именно на основе OIDC был разработан международный стандарт для финансовых операций в банковской отрасли — Financial-Grade API (FAPI) [10].

Financial-Grade API определяет два профиля:

• базовый (Baseline) применяется к Открытым интерфейсам, которые не изменяют состояние (доступ к пользовательскому счёту);
• продвинутый (Advanced) повышает требования к защите данных относительно базового и применяется к Открытым интерфейсам, которые изменяют состояние (проведение платёжных операций).

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

Для продвинутого профиля необходим request object (объект запроса) — JWT (JSON Web Token), включающий необходимые для запроса авторизации OAuth 2.0 параметры: client_id, response_type и прочие. Без этого невозможно обеспечить целостность и конфиденциальность параметров запроса авторизации. Если request object отсутствует, то любые обращения должны быть немедленно отклонены.

Продвинутый профиль вводит обязательное условие взаимной аутентификации на транспортном уровне (mutual TLS) между кешбэк-сервисом и банком. Чтобы оно было выполнено, не только банк, но и сам сервис должны предъявить к проверке цифровой сертификат X.509 (рис. 3).

Рисунок 3. Защита аутентификации в профиле стандарта FAPI

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

ОТЛИЧИЯ РОССИЙСКОГО СТАНДАРТА

Спецификации некоммерческой организации Open ID Foundation, которая определяет технологии Open ID и порядок модели Открытых API со структурированными данными, предполагают, что Financial-Grade API могут использоваться на международном уровне в качестве «коробочного стандарта». То есть каждая страна вправе адаптировать FAPI под свои реалии.

Стандарт ФАПИ.СЕК, выпущенный Банком России, базируется на основных положениях FAPI, но с включением заметных дополнений, которые не наследуются от оригинального протокола и связаны с необходимостью соответствовать нормативным и законодательным актам Российской Федерации.

Ключевым отличием для России является исключительное применение отечественной криптографии согласно технической спецификации ТК 26 «Использование российских криптографических алгоритмов в протоколах Open ID Connect» [11] (JWT, JWS, JWE, JWK на отечественных стандартах алгоритмов криптографической защиты).

Работа над внедрением на российский рынок Открытых API продолжается, и применение стандартов вида ФАПИ в качестве базисных должно существенно её облегчить. Как одна из стран, успешно развивающих технологии открытого банковского дела, Россия будет использовать эти стандарты в дальнейшем, хотя специфика национального финансового рынка, безусловно, скорректирует их профили.

Кроме нашей страны, открытый банкинг на основе ФАПИ сегодня развивают семь государств: США, Великобритания, Канада, Австралия, Бразилия, Нигерия и Новая Зеландия. Можно с уверенностью говорить, что большая часть рынка окончательно определилась и выбрала стандарты ФАПИ в качестве функциональных «строительных блоков» для решения разнообразных проблем, вызванных запуском сред открытого информационного обмена, где прозрачность и согласие пользователя стоят во главе угла.

[1] https://www.fintechru.org/api/download/?id=6149&fid=3268.

[2] https://www.cbr.ru/StaticHtml/File/59420/standart_3.pdf.

[3] https://www.cbr.ru/StaticHtml/File/59420/standart_2.pdf.

[4] https://www.cbr.ru/StaticHtml/File/59420/Standart_1.6-2020.pdf.

[5] Стандарт обеспечения безопасности финансовых сервисов при инициации Open ID Connect клиентом потока аутентификации по отдельному каналу.

[6] https://datatracker.ietf.org/doc/html/rfc6749.

[7] https://openid.net/specs/openid-connect-core-1_0.html.

[8] https://auth0.com/docs/secure/tokens/access-tokens.

[9] https://oauth.net/2/refresh-tokens/.

[10] https://curity.io/resources/learn/what-is-financial-grade/.

[11] https://www.ruscrypto.ru/resource/archive/rc2022/cdn-cgi/image/quality=75/https://journal.ib-bank.ru/files/07_gruntovitch.pdf.