Безопасность Open API в банковской сфере: архитектура, токены и защита от атак

Развитие экосистемы открытых банковских интерфейсов (Open API) фундаментально меняет финансовый рынок. Открытые API позволяют банкам, финтех-сервисам и маркетплейсам обмениваться финансовыми данными клиентов, запускать платежи и создавать бесшовные пользовательские сценарии.

Однако разграничение контура безопасности и открытие программных интерфейсов во внешнюю среду создают новые векторы атак. В отличие от традиционного веб-клиента, где поведение пользователя ограничено UI, API предоставляет прямому клиенту (или стороннему поставщику услуг — TPP) доступ к бизнес-логике и базе данных.

В этой статье разберём фундамент (чем OAuth 2.0 отличается от OpenID Connect и почему это важно), ключевые архитектурные принципы безопасных Open API, лучшие практики работы с токенами, механизмы защиты от специфических атак — и то, как всё это закреплено в российской системе стандартов, к части которых я приложил руку в Банке России.

Фундамент: OAuth 2.0 и OpenID Connect

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

OAuth 2.0 — это делегирование авторизации. Он отвечает на вопрос: «Может ли этот клиент получить доступ к этому ресурсу?» Пользователь (владелец ресурса) даёт стороннему приложению ограниченный доступ к своим данным, не передавая пароль. Приложение получает токен доступа — строго с теми разрешениями и на тот срок, которые одобрены.

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

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

Каждый, кто нажимал «Продолжить с Госуслугами», видел эту связку в действии: вас перенаправляют на страницу входа, Госуслуги спрашивают «Разрешаете ли вы приложению просматривать ваш профиль и e-mail?», вы нажимаете «Разрешить» — и приложение получает токен, которым подтверждает вашу личность и создаёт учётную запись. Пароль от Госуслуг приложение не видит никогда.

Роли в этой схеме стандартизированы: в OAuth это владелец ресурса, клиент, сервер авторизации и сервер ресурсов; в OIDC — конечный пользователь (EU), доверяющая сторона (RP) и поставщик OpenID (OP). Дальше в статье эти термины будут встречаться постоянно — банковский Open API целиком построен на этом фундаменте.

Архитектурный контур безопасного Open API

Использование устаревших подходов (простые API-ключи или классический OAuth 2.0 без дополнительных профилей безопасности) в банковском секторе недопустимо. Безопасная архитектура банковского Open API строится на принципах Zero Trust (нулевого доверия) и Defense in Depth (эшелонированной защиты).

Ключевые компоненты архитектуры

1. API Gateway (шлюз API): единственная точка входа для внешних запросов. Отвечает за терминацию mTLS, первоначальную проверку токенов, фильтрацию атак (WAF), лимитирование запросов (Rate Limiting) и логирование.
2. Сервер авторизации (Identity Provider / OAuth 2.0 Authorization Server): изолированный сервис, отвечающий за аутентификацию TPP, проверку согласий клиентов (Consent Management) и выпуск токенов. Централизация входов через IdP даёт побочный, но важный эффект: полную видимость того, кто, откуда и когда получил доступ, — каждый запрос на вход проходит через одну точку и попадает в аудит.
3. mTLS (Mutual TLS): двусторонняя аутентификация по протоколу TLS. Банковский API обязан проверять не только сертификат сервера, но и клиентский x509-сертификат TPP (в РФ — с поддержкой алгоритмов ГОСТ Р 34.10-2012 или квалифицированных сертификатов).

Профили FAPI и работа с токенами: OAuth 2.0 на максималках

Для финансовых организаций стандартного OAuth 2.0 недостаточно. Международным стандартом и основой для стандартов Банка России стал профиль Financial-grade API (FAPI 1.0 / FAPI 2.0) от OpenID Foundation.

Ключевые требования FAPI к токенам и авторизации

Связывание токенов с отправителем (Sender-Constrained Tokens). Обычный Bearer-токен может быть перехвачен и использован злоумышленником. В FAPI применяются методы привязки токена:

• mTLS Client Certificate-Bound Access Tokens (RFC 8705): Access Token привязывается к хэшу клиентского сертификата TPP. Даже если токен украден, использовать его без закрытого ключа сертификата невозможно.
• DPoP (Demonstrating Proof-of-Possession, RFC 9449): применение асимметричных ключей на стороне TPP для подписи каждого запроса с токеном.

Защита процесса авторизации (PKCE, PAR, state и nonce).

• PKCE (Proof Key for Code Exchange, RFC 7636): защищает от перехвата Authorization Code. Поток кода авторизации с PKCE — базовая гигиена для любых публичных клиентов, особенно мобильных и браузерных.
• PAR (Pushed Authorization Requests, RFC 9126): параметры авторизации передаются не через URL браузера (где они утекают в журналы и Referer), а напрямую на сервер авторизации защищённым POST-запросом.
• state и nonce: одноразовые случайные значения, связывающие запрос и ответ. Значение nonce, возвращённое в ID-токене, обязано совпадать с отправленным в запросе — это отсекает атаки повторного воспроизведения.
• Белый список redirect URI: перенаправление разрешено только на заранее зарегистрированные адреса, без подстановочных знаков. Это закрывает целый класс атак с перехватом кода через вредоносные редиректы.

Валидация каждого токена. Токен не считается безопасным по факту получения. На каждом шаге проверяются подпись, эмитент (iss), аудитория (aud) и время истечения (exp). Открытые ключи для проверки подписи распространяются через JWKS (JSON Web Key Sets) с автоматической ротацией — статические ключи в финансовых системах недопустимы.

Управление согласиями (Consent Management). Клиент банка должен чётко понимать и явно подтверждать, к каким именно счетам, на какой срок и для каких операций стороннее приложение получает доступ. Токен выпускается строго в рамках выданного согласия (Consent Scope), а области действия (scopes) определяются по принципу минимальной достаточности: только то, что требуется, ничего больше.

Короткий срок жизни (Short-Lived Access Tokens). Access Token должен быть действителен от нескольких минут до нескольких часов: короткоживущий токен резко уменьшает ущерб от компрометации. Для обновления используется Refresh Token с обязательной ротацией (Refresh Token Rotation). Клиентские секреты тоже ротируются по расписанию — к ним стоит относиться как к учётным данным, уникальным для каждого клиента.

Отдельный плюс токен-ориентированной модели: скомпрометированный токен можно отозвать, а рискованный сеанс — прервать, не трогая остальных пользователей. MFA и условный доступ (по устройству, геолокации, сигналам риска) подключаются на стороне провайдера идентичности — без изменения кода приложений.

Защита от специфических атак на Open API

Банковские API чаще всего подвергаются не стандартным инъекциям, а атакам на логику и авторизацию.

И общее правило, которое я вынес из работы над стандартами: потоки авторизации нужно регулярно тестировать под давлением, как и любой другой критичный код. Моделирование угроз плюс негативные сценарии: что происходит, когда токен истёк, использован повторно, выпущен с неверной аудиторией. Автотесты на эти случаи окупаются при первом же инциденте.

Регуляторный контекст: как устроена система стандартов в РФ

Эту часть я знаю изнутри — в Департаменте информационной безопасности Банка России я участвовал в работе над стандартами по Open API. Чтобы требования не казались произвольным списком аббревиатур, полезно понимать саму конструкцию.

Два уровня: техрегламенты и стандарты

Основа системы — Федеральный закон № 184-ФЗ «О техническом регулировании». Он разводит обязательные требования (технические регламенты, имеющие силу закона: нарушил — нарушил закон, независимо от формы собственности) и добровольные стандарты — проверенные практики, объясняющие, как выполнить требования. Я формулирую это так: регламент задаёт правила игры, стандарт предлагает выигрышную тактику. Нюанс, который часто упускают: как только организация ссылается на добровольный стандарт в своей документации или договоре, он становится для неё обязательным — в рамках внутреннего контроля и контрактных обязательств.

Стандарты для финансовой отрасли разрабатывают технические комитеты: ТК 122 «Стандарты финансовых операций» (и его Подкомитет № 1 по безопасности финансовых операций — площадка, где встречаются Банк России, банки, финтех и наука), ТК 26 «Криптографическая защита информации» и ТК 362 «Защита информации» под эгидой ФСТЭК.

Комплекс ГОСТ Р 57580: фундамент защиты

• ГОСТ Р 57580.1-2017 — базовый состав организационных и технических мер защиты информации. Определяет уровни защиты и требования к каждому; ключевая идея — адекватность мер актуальным угрозам и принятому организацией риск-аппетиту. На него опирается всё остальное, включая контур Open API.
• ГОСТ Р 57580.2-2018 — методика оценки соответствия первой части: единые, воспроизводимые и сопоставимые правила проверки.
• ГОСТ Р 57580.3-2022 — управление риском реализации информационных угроз: от планирования мер до контроля и совершенствования, с учётом скрытности и скорости распространения современных атак.
• ГОСТ Р 57580.4-2022 — операционная надёжность: как выявлять инциденты, реагировать и восстанавливаться, чтобы атака на один банк не превратилась в каскадный сбой национальной платёжной системы.

Обе первые части сейчас актуализируются в ТК 122, а в плане национальной стандартизации — методики оценки операционной надёжности, требования к проверяющим организациям, стандарт по рискам при ИТ-аутсорсинге и облачных сервисах и методика оценки зрелости управления рисками ИБ.

Стандарты ФАПИ: FAPI по-русски и с ГОСТ-криптографией

Ядро регулирования Open API — два стандарта Банка России, обновлённые в 2024 году и действующие с 1 января 2025 года:

• СТО БР ФАПИ.СЕК-1.6-2024 (взамен редакции 2020 года) — требования ИБ к прикладным программным интерфейсам на основе OpenID Connect: порядок использования API на технологическом участке идентификации, аутентификации и авторизации, требования к защите персональных данных и банковской тайны при передаче через API, безопасный доступ к финансовым данным в реальном времени на связке OAuth + OIDC.
• СТО БР ФАПИ.ПАОК-1.0-2024 (взамен редакции 2021 года) — безопасность при инициации потока аутентификации по отдельному каналу (аналог международного CIBA). Это сценарий, когда доверяющая сторона уже знает идентификатор пользователя и получает токены от сервера авторизации без браузерного перенаправления — например, подтверждение операции происходит в мобильном приложении банка, пока клиент общается с сервисом по другому каналу. Не путать с PAR: PAR защищает параметры классического редиректного потока, ПАОК описывает поток вообще без редиректа.

Причина пересмотра обоих стандартов в 2024 году показательна: ТК 26 завершил методические рекомендации по использованию российских криптографических алгоритмов в протоколах OpenID Connect — и профили ФАПИ привели в соответствие с ними. Международная архитектура FAPI, национальная криптография.

Смежные стандарты, которые стоит знать архитектору Open API

Контур безопасности API не живёт в вакууме — вокруг него работает ещё несколько СТО БР:

• БФБО-1.5-2023 — формы и сроки взаимодействия с Банком России при инцидентах (обмен через АСОИ ФинЦЕРТ, в том числе сведения о мошеннических операциях более чем по 50 уникальным признакам, включая идентификаторы устройств, с последующей передачей данных в МВД).
• БФБО-1.7-2023 — технология цифровых отпечатков устройств: единые правила формирования и сравнения отпечатков с эталонными, чтобы быстрее выявлять переводы без согласия клиента.
• БФБО-1.8-2024 — дистанционная идентификация и аутентификация: уровни доверия и выбор стандартных или усиленных протоколов организация определяет сама, исходя из критичности операции, в рамках системы управления рисками.
• БФБО-1.9-2024 — безопасность QR-платежей: систематизация угроз по всем этапам жизненного цикла QR-кода и типовые меры защиты, включая противодействие подделке и перехвату.

Плюс общий каркас: 152-ФЗ о персональных данных (передача сведений о счетах через API требует надлежащего согласия и шифрования при транспортировке) и Указ Президента № 250 (требования к защищённости инфраструктуры и контролю за используемым ПО и сертификатами).

Чек-лист для CISO и архитектора Open API

• Все внешние подключения требуют mTLS с валидацией сертификатов сторонних сервисов (TPP).
• Реализован профиль FAPI 1.0 Advanced / FAPI 2.0; для сценариев без браузера — поток по отдельному каналу в соответствии с СТО БР ФАПИ.ПАОК.
• Все Access-токены являются Sender-Constrained (mTLS Binding или DPoP).
• Запросы авторизации передаются через PAR, используется PKCE, проверяются state и nonce.
• Redirect URI ограничены белым списком без подстановочных знаков.
• Каждый токен проходит валидацию подписи, iss, aud и exp; ключи ротируются через JWKS.
• Клиентские секреты уникальны для каждого клиента и ротируются по расписанию.
• На шлюзе API настроены Rate Limiting, WAF и валидация схем JSON по OpenAPI-спецификации.
• Проверка прав доступа (BOLA/BFLA) выполняется на уровне каждого микросервиса, а не только на внешнем шлюзе.
• Система ведёт аудит всех обращений к API с привязкой к TPP ID, Consent ID и User ID; аномалии по геолокации, устройству и частоте подсвечиваются.
• Потоки авторизации покрыты автотестами с негативными сценариями (истёкший, повторно использованный, чужой токен).
• Соответствие ГОСТ Р 57580.1 подтверждено оценкой по ГОСТ Р 57580.2; криптография — ГОСТ, в соответствии с профилями ФАПИ.

Три принципа, которыми я закончил бы любой разговор об Open API (ими же завершал доклад о стандартах): в основе безопасности должен лежать протокол, утверждённый стандартом, а не самописная схема; меры защиты применяются взвешенно, под конкретный риск, а не «всё и сразу»; и безопасность обеспечивается на всех этапах жизненного цикла — от проектирования до эксплуатации и обновлений.

Полезные ссылки

• 📚 Спецификации FAPI — рабочая группа Financial-grade API в OpenID Foundation
• 🏦 Стандарты Банка России по ИБ — СТО БР, включая ФАПИ.СЕК и ФАПИ.ПАОК
• 📖 Мой разбор изменений ИБ-законодательства 2026 — регуляторный контекст шире Open API
• 📖 Комплаенс в финтехе: мой опыт работы с нормативкой — как жить с этими требованиями на практике