Открытые API в банках: метод оценки безопасности интеграции
88% участников опроса Ассоциации ФинТех называют утечки данных главным риском внедрения Открытых API. 85% выделяют несанкционированный доступ. В 2025 году пилот среды Открытых API охватил 19 финансовых организаций.
Макар Литвинов·Обновлено: 27 октября 2026 г.·9 мин
Ещё 10 банков тестировали централизованную Платформу коммерческих согласий.
Оценка безопасности интеграции через открытые API в банках строится на проверяемых фактах: протоколах, сертификатах, токенах, разграничении прав и согласиях клиентов. С 1 января 2025 года в силу вступили профильные стандарты Банка России для финансовых сервисов на базе OpenID Connect и потока аутентификации CIBA. С 2026 года переход к обязательному применению стандартов запланирован поэтапно.
Нормативный каркас открытых интерфейсов
Банк России утвердил два ключевых профиля информационной безопасности:
- СТО БР ФАПИ.СЕК-1.6-2024 — профиль безопасности финансовых сервисов на базе OpenID Connect.
- СТО БР ФАПИ.ПАОК-1.0-2024 — поток аутентификации по отдельному каналу CIBA.
Профили построены поверх международных стандартов Financial-grade API и OpenID Connect. Российская нормативная база адаптирует их к требованиям законодательства и отечественной криптографии. Обновления учитывают методические рекомендации МР.26.2.002-2024 Технического комитета по стандартизации «Криптографическая защита информации».
| Событие | Значение для архитектуры и аудита |
|---|---|
| 2024 год | Утверждены профили безопасности ФАПИ редакции 2024 года |
| 1 января 2025 года | Начали действовать рекомендательные требования к профилям безопасности |
| 2025 год | В пилоте среды Открытых API участвовали 19 финансовых организаций; 10 банков тестировали Платформу коммерческих согласий |
| 19 декабря 2025 года | Утверждён расширенный комплект стандартов открытого банкинга |
| 2026 год | Запланирован поэтапный переход к обязательному применению стандартов |
Стандарты не открывают счета и данные любому зарегистрированному разработчику. Доступ к банковскому API регулируется ролями, сертификатами клиентов, криптографическими токенами и согласиями. Ошибка возникает именно на стыке этих механизмов: корректный протокол сочетается с неверной политикой scopes, слабым управлением ключами или непрозрачной цепочкой согласий.
Точный перечень коммерческих API, которые первыми станут юридически обязательными, пока не определён. Поэтому аудит должен опираться на действующие профили, архитектуру конкретного банка и зафиксированные риски. Проверка по одному универсальному перечню параметров даст ложную полноту.
Метод аудита: переход от деклараций к проверяемым фактам
Единой математической формулы оценки рисков интеграции не существует. Банки и регулятор применяют риск-ориентированный аудит: чек-листы соответствия ФАПИ и ГОСТ, моделирование угроз, проверку конфигурации и анализ подтверждающих артефактов.
Практическая последовательность аудита состоит из шести этапов.
1. Инвентаризация интеграции. Фиксируются конечные точки, HTTP-методы, client_id, зарегистрированные scopes, типы данных, потребители, сроки действия токенов и точки доверия.
2. Модель угроз. Определяются нарушители: внешний атакующий, скомпрометированный TPP, внутренний оператор, ошибка конфигурации, отказ gateway или обход системы согласий.
3. Проверка аутентификации. Тестируются mTLS, private_key_jwt, срок жизни сертификатов, audience токенов, обработка отзыва и отрицательные сценарии доступа.
4. Проверка авторизации. Сопоставляются заявленные и фактические права, tenant, клиент, скоуп и ресурс. Проверяется запрет доступа к чужому клиентскому контексту.
5. Проверка согласий. Сопоставляются TPP, клиент, цель операции, запрошенные данные, срок действия, версия согласия и процедура отзыва.
6. Воспроизведение и фиксация. Результаты тестов, конфигурация, журналы и оценка остаточного риска сохраняются как доказательства аудита.
| Контроль | Типичная декларация | Что служит подтверждением |
|---|---|---|
| Транспортная идентификация | «mTLS включён» | Успешный handshake с сертификатом клиента; отказ при отсутствии сертификата или неверной цепочке |
| Аутентификация клиента | «Используется private_key_jwt» | Подпись challenge закрытым ключом; проверка регистрации ключа; отказ при подмене assertion |
| Разграничение прав | «Выдан минимальный доступ» | Матрица client_id и scopes; запрет доступа к чужому tenant; отрицательный тест на расширение полномочий |
| Согласия | «Клиент подтвердил операцию» | Идентификатор согласия, версия, TPP, назначение, срок, журнал выдачи и отдельная процедура отзыва |
| Наблюдаемость | «Все запросы записываются» | Корреляционные идентификаторы, полный контекст решения доступа и отсутствие bearer-токенов в логах |
| Отзыв доступа | «Доступ можно прекратить» | Проверка блокировки ключа, client_id или согласия с задержкой, приемлемой для сценария |
Стандарт задаёт минимальную архитектурную схему. Проверяемость обеспечивают журналы, тесты и процедура отзыва.
Для оценки результатов применяется трёхуровневая шкала:
- Допуск в продуктивную среду. Обязательные механизмы аутентификации работают. Нарушения ограниченного доступа не обнаружены. Согласия, журналы и отзыв подтверждены тестами.
- Ограниченный пилот. Выявлены локальные недостатки. Компенсирующие меры ограничивают TPP, scopes, tenant, объём трафика и срок эксплуатации.
- Отказ от интеграции до устранения дефектов. Отсутствуют обязательные механизмы защиты, аудит невозможен, компрометация ключа не приводит к отзыву доступа.
Архитектура аутентификации: mTLS, private_key_jwt, OAuth 2.0 и CIBA
Требования профилей безопасности предусматривают доступ к конечным точкам токена по mTLS. Аутентификация доверенного клиента выполняется через private_key_jwt. Взаимодействие строится на стеке OAuth 2.0 и OpenID Connect.
| Механизм | Функция | Что остаётся за пределами контроля |
|---|---|---|
| mTLS | Взаимная аутентификация узлов по сертификатам | Состояние процесса, права scopes и согласия клиента |
| private_key_jwt | Подтверждение клиента закрытым ключом через подписанное assertion | Компрометация самого закрытого ключа |
| OAuth 2.0 | Выдача токенов, scopes и управление доступом к ресурсам | Проверка бизнес-разрешения за пределами resource server |
| OpenID Connect | Передача идентификатора клиента и связанных identity-claims | Согласие на конкретную финансовую операцию |
| CIBA | Аутентификация через отдельный канал | Связь согласия с нужной операцией и TPP |
Механизмы выполняют разные задачи. mTLS подтверждает узел, private_key_jwt — клиента OAuth, токен — заявленные полномочия, OIDC — идентичность субъекта. Отказ одного слоя компенсирует функцию другого, если архитектура спроектирована без логических разрывов.
Типовые сценарии дефектов:
- Компрометация узла. Валидный mTLS-сертификат подтверждает инфраструктурный идентификатор, но не состояние приложения. Сертификат связывается с рабочей нагрузкой, срок действия ограничивается, ключи регулярно ротируются.
- Повтор assertion. Перехваченный private_key_jwt с допустимым сроком жизни может быть повторно предъявлен. Проверяются issuer, audience, срок, nonce и уникальность подписанного запроса там, где это предусмотрено профилем.
- Подмена контекста клиента. Token с широким scope направляется в tenant другого клиента. Resource server проверяет audience, tenant и фактический идентификатор получателя.
- Повышение полномочий TPP. Токен, выпущенный одному набору операций, используется для другого. Политика scopes связывается с client_id, методом, ресурсом и параметрами запроса.
- Подмена redirect URI. При неверном списке разрешённых адресов код авторизации может уйти другому клиенту. Сравнение выполняется по точному URI, без ослабляющих правил.
- Утечка через журналы. Запросы заголовков, тела и URL иногда содержат токены или чувствительные параметры. Перед записью применяется маскирование и фильтрация.
- Разрыв согласия. Пользователь подтвердил одну операцию, а токен позволяет выполнить другую. Идентификатор согласия связывается с назначением, TPP, набором данных и сроком.
Похожий принцип разделения ролей встречается в цифровой трансформации логистики и рынке экспресс-доставки. Цифровой контур связывает заказчиков, перевозчиков и агрегаторов, ограничивая каналы обмена. Банковский API добавляет к этой модели криптографическую идентификацию, согласия и требования к отзыву доступа.
Криптографическая защита: профиль ТК 26 и жизненный цикл ключей
Поддержка российских криптографических алгоритмов заложена в обновлённые стандарты ФАПИ. МР.26.2.002-2024 ТК 26 используется как методическая основа. Наличие алгоритма в профиле не подтверждает корректность его применения. Проверяются конкретные реализация, сертификаты, ключи и параметры соединения.
| Область | Материал аудита | Признак дефекта |
|---|---|---|
| Алгоритмы | Реестр применённых наборов, версии библиотек, результаты тестовых соединений | Поддержка заявлена, но фактический набор не документирован |
| Закрытые ключи | Процедура выпуска, хранения, ротации и уничтожения | Ключ доступен конфигурации, сборке или широкому кругу операторов |
| Сертификаты | Срок действия, цепочка, отзыв, привязка к client_id | Долгоживущий сертификат используется после компрометации узла |
| Проверка сервера | Валидация имени, срока, цепочки и политики доверия | Hostname verification отключена либо задан широкий набор корней |
| Транспорт | Версии TLS, наборы шифров, параметры renegotiation | Неактуальные протоколы или несовместимые с профилем параметры |
| Эксплуатация | Мониторинг отказов, журналы, процедура замены ключа | Инцидент требует ручного поиска неизвестного сертификата |
Для коммерческого контура закрытые ключи целесообразно размещать в HSM или эквивалентном защищённом хранилище. Передача ключа в конфигурацию приложения снижает уровень защиты. Процесс выпуска ключа должен связываться с конкретным клиентом, средой и владельцем риска.
Отдельный слой аудита проверяет алгоритмическую agility. Обновление криптопрофиля не должно требовать полной остановки API-контура. Нужны реест поддерживаемых версий, тестовые стенды и заранее определённая процедура миграции.
Цифровые согласия и контроль сторонних поставщиков
Платформа коммерческих согласий и профиль CIBA решают разные задачи. CIBA переносит подтверждение аутентификации в отдельный канал. Платформа согласий связывает разрешение клиента с конкретной коммерческой операцией и TPP.
В 2025 году централизованную Платформу коммерческих согласий тестировали 10 банков. Испытания не означают ввод универсальной платформы в обязательную эксплуатацию. Для аудита важен фактический контур каждого банка: локальный реестр согласий, интеграция с платформой или комбинация обоих вариантов.
В контуре различаются три решения:
1. Аутентификация подтверждает личность клиента или представителя.
2. Авторизация определяет технические права токена.
3. Коммерческое согласие фиксирует разрешение на операцию, данные и TPP.
OAuth-подтверждение сам по себе не заменяет коммерческое согласие. Пользователь мог разрешить приложению вход в профиль, но не согласовал передачу платежных данных стороннему сервису. Идентификатор согласия должен входить в контекст вызова API. Иначе аудит покажет наличие разрешения, но не сможет связать его с выполненной операцией.
Аудит TPP включает:
- перечень зарегистрированных client_id и их сертификатов;
- связь каждого клиента с конкретными scopes, ресурсами и tenant;
- контроль сроков действия согласий и порядка их отзыва;
- журналы выдачи токенов без копирования секретных значений;
- процедуру блокировки клиента после компрометации;
- контроль цепочки поставки ПО и зависимых компонентов;
- сроки уведомления об инцидентах и порядок предоставления журналов;
- проверку отсутствия обхода gateway через прямой доступ к внутренним нодам.
Контроль разграничения прав должен действовать на каждом вызове. Ограничение только на стороне TPP считается перемещением риска. Скомпрометированный поставщик получает собственные credentials и пытается обратиться к ресурсам за пределами зарегистрированного контракта.
Отзыв согласия, блокировка client_id и отзыв криптографического ключа также должны быть раздельными процедурами. Отзыв согласия не закрывает действующий токен, если resource server не проверяет его состояние. Блокировка ключа закрывает транспорт, но не исправляет ошибочно выданные полномочия.
Согласие считается подтверждённым только тогда, когда его можно связать с конкретным запросом, клиентом, поставщиком и сроком действия.
Нагрузка, наблюдаемость и границы LLM-моделей
Прогнозируемый эффект открытого банкинга — рост одновременных запросов и нагрузки на банковскую IT-инфраструктуру в 2–3 раза. Узкое место может сместиться с криптографии на пропускную способность gateway, backend API, базы данных и очередей.
Защита от деградации требует отдельного контура:
- квоты и лимиты скорости для каждого client_id, tenant и конечной точки;
- разделение приоритетов для платёжных, справочных и аналитических операций;
- отказоустойчивые circuit breaker и backpressure вместо неограниченной очереди;
- идемпотентность операций записи для защиты от повторной обработки;
- безопасное кэширование короткоживущих токенов с привязкой к client_id и audience;
- контроль burst-трафика и повторных запросов после таймаутов;
- журналирование задержек, ошибок, отказов авторизации и отзывов;
- нагрузочные тесты с воспроизведением распределения scopes и трафика;
- автоматическое масштабирование нод без обхода индивидуальных квот.
LLM-модели могут сократить время разбора инцидентов, но не должны участвовать в выдаче разрешений. Токен, scope и согласие выдаёт детерминированный policy engine. Модель получает подготовленные и обезличенные события.
| Задача | Применение LLM | Решение, остающееся вне модели |
|---|---|---|
| Анализ журналов API | Группировка событий, извлечение признаков, краткая сводка инцидента | Блокировка client_id, отзыв ключа и изменение политики |
| Проверка спецификации | Поиск расхождений между API-контрактом и политикой доступа | Валидация scopes, audience, tenant и consent_id |
| Расследование аномалий | Ранжирование потока запросов по вероятности злоупотребления | Решение о допуске или блокировке запроса |
| Генерация тестов | Создание сценариев для негативных проверок | Исполнение тестов, фиксация результата и расчёт покрытия |
Внешние поля запроса могут содержать инструкции, ориентированные на модель. Это создаёт риск prompt injection. Поля пользовательского ввода требуется маркировать как недоверенные данные. Политические решения остаются вне контекста генерации.
Для LLM-моделей нужен отдельный бенчмарк на размеченном наборе нормального и злонамеренного трафика. Измеряются false positive, false negative, задержка, стоимость обработки и устойчивость к изменению формата событий. Версии модели, prompt, справочник правил и тестовый набор фиксируются. Без такого контроля LLM остаётся вспомогательным интерфейсом с непроверяемой логикой.
Допуск интеграции к продуктивной среде подтверждается работающей конфигурацией, воспроизводимыми тестами, журналами и проверенной процедурой отзыва. Декларация о соответствии продолжает оставаться декларацией.