Обзор стандартов Банка России. Безопасность финансовых (банковских) операций

Руслан Рахметов, Security Vision

В последние годы Центральный банк уделяет особое внимание финансовым технологиям (финтеху) как источнику повышения конкурентоспособности российского платежного пространства, развития внутренней конкуренции, повышения качества и безопасности оказываемых на финансовом рынке услуг. Ряд инициатив в сфере финтеха ввиду естественных причин, таких как ресурсоемкость, масштабность необходимых изменений и сопротивление определенных групп бизнес-участников, не смог бы развиваться без активной позиции мегарегулятора. В качестве примера можно назвать создание Системы быстрых платежей, Цифрового рубля, Единой биометрической системы и других финтех проектов.

Одной из важных инициатив Центрального Банка является развитие открытого банкинга, концепции, подразумевающей использование открытых API (программных интерфейсов) в банках в целях обеспечения конкуренции на «последней миле» до клиента. Чтобы было понятнее, клиент сможет использовать для осуществления финансовых операций множество сервисов/приложений, предоставляя им доступ к своим данным в банке. Например, поставить приложение, по сути, универсальный клиент-банк, с помощью которого сможет подключить свои счета в разных банках и управлять средствами из одного приложения, попутно получая дополнительные удобства и преимущества, например, в виде автоматического выбора наиболее выгодного способа оплаты товара или независимого выбора страховки при оформлении кредита.

Очевидно, это встречает сильное сопротивление со стороны банков, развивающих собственные приложения и экосистемы и не желающих допускать до своего клиента сторонние сервисы. Поэтому регулятор в данный момент занимается стандартизацией открытых API, инициирует создание соответствующей инфраструктуры (например, создание сертификационного стенда на базе Ассоциации ФинТех). Всё это подготовительные мероприятия для внедрения данной концепции на платежном пространстве РФ через обязательные требования, по примеру Евросоюза с его Директивой о платежных услугах, известной как PSD2. Открытые API подтолкнут развитие инноваций и цифровых технологий, оказание максимально персонализированных услуг через гарантированный требованиями доступ провайдеров финансовых услуг к инфраструктуре. С помощью таких интерфейсов смогут взаимодействовать друг с другом, в том числе, и банки.

Вместе с тем, в конечном счете все участники получат выгоду от внедрения открытых API.

·  Банки получат доступ к новейшим технологиям (смогут обеспечить их для своих клиентов), смогут получать дополнительную информацию о своих клиентах.

·  Финтех компании получат унификацию и уменьшат сроки вывода на рынок новых продуктов с широчайшим охватом аудитории, смогут сосредоточиться на совершенствовании своих решений.

·  Клиенты получат новые сервисы, снижение их стоимости и повышение качества, скорости, получат возможность выбирать сервисы и управлять своими данными.

Начиная с 2020 года Банком России выпущен ряд стандартов, посвященных открытым API. Важным моментом в таком взаимодействии сторон при оказании финансовых услуг является обеспечение информационной безопасности, что тоже является объектом стандартизации. В соответствующем разделе «Информационная безопасность» сайта Банка России размещены посвященные вопросам безопасности открытых (доступных извне) API в финансовой сфере Стандарт Банка России СТО БР ФАПИ.ПАОК-1.0-2021 «Безопасность финансовых (банковских) операций. Прикладные программные интерфейсы. Обеспечение безопасности финансовых сервисов при инициации OpenID Connect клиентом потока аутентификации по отдельному каналу. Требования» от 16.08.2021 и Стандарт Банка России СТО БР ФАПИ.СЕК-1.6-2020 «Безопасность финансовых (банковских) операций. Прикладные программные интерфейсы обеспечения безопасности финансовых сервисов на основе протокола OpenID. Требования» от 23.10.2020.

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

В самом начале документа стоит обратить внимание на абзац, в котором указано, что требования стандарта применяются добровольно, если только обязательность не установлена нормативными актами Банка России, что говорит о ранее обозначенном в статье намерении регулятора постепенно перейти к обязательному характеру требований. Важным разделом является часть Стандарта, содержащая отсылки к действующим нормативным требованиям, при этом, хоть некоторые документы скоро и утратят силу (Положение Банка России от 9 июня 2012 года № 382-П), но явно обозначается, что необходим анализ уязвимостей в прикладном ПО, обеспечение иных требований законодательства (защита персональных данных) и применение соответствующих (угрозам и нарушителям) средств криптографической защиты информации.

Остальное содержимое Стандарта посвящено профилю безопасности в условиях применения открытых API для доступа к сервисам в различных режимах. Но во всем документе необходимо отметить следующие требования/подходы по обеспечению информационной безопасности:

·  Применение токенизации. Обеспечивает замену критических данных аутентификации производными данными (токенами) с определенными характеристиками, позволяющими минимизировать риски при компрометации.

·  Использование при передаче данных протокола TLS, обеспечивающего шифрование.

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

·  Применение на серверах авторизации предварительной регистрации адресов переадресации. Данная мера позволяет минимизировать риски использования мошеннических сервисов на определенных шагах процесса получения доступа к ресурсам, за счет разрешительного ведения сервисов для переадресации.

·  URI переадресации (доступные по ним сервисы) должны использовать протокол HTTPS.

·  Одновременное применение на прикладном уровне шифрования данных для обеспечения конфиденциальности и подписи для аутентификации отправителя.

·  Требования к серверу авторизации по использованию при взаимодействии с клиентом мер противодействия подделке межсайтовых запросов (CSRF) и перехвату кликов (Clickjacking).

·  Рекомендации по применению, где это возможно, одноразовых токенов и кодов авторизации с внедрением соответствующих проверок в программном коде.

·  Применение кратковременных (как можно сильнее ограниченных по времени действия) токенов и кодов авторизации.

·  Отслеживание ошибок применения токенов/кодов авторизации, в частости регистрация неоднократных попыток их использования и, в частности, реализация соответствующего отзыва всех токенов доступа, выданных на основе скомпрометированного кода авторизации.

·  Контроль клиентом полноты указанных параметров с отказом в обработке при отсутствии заполнения обязательных параметров.

·  Игнорирование клиентом (без возврата кодов) нераспознанных параметров ответа.

·  Контроль клиентом длины параметров.

·  Контроль временных меток токена (сопоставление времени создания токена, срока действия и текущего времени).

·  Уведомление владельца ресурса при запросе долгосрочного разрешения на доступ клиента к ресурсам. Должны быть обеспечены механизмы управления выданными токенами ( с возможностью частичного отзыва).

·  Применение TLS с взаимной аутентификацией клиента и сервера, причем как с использованием самоподписанных сертификатов, так и PKI.

·  Исключение применения одного и того же ключа как для подписи, так и для шифрования данных. Также должны применяться различные ключи для TLS и реализации OIDC.

·  Своевременный вывод криптографических ключей из эксплуатации.

·  Требования по генерации ключевой информации с помощью СКЗИ.

·  Реализация протокола TLS с использованием современных (в стандарте указаны конкретные криптонаборы) криптографических алгоритмов РФ и сертифицированных СКЗИ.

·  Применение стойкой версии TLS версии 1.2 и выше.

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

·  Применение технологии привязки токенов к TLS соединению. Технологическая мера, обеспечивающая сверку владельца канала и токенов.

Рассмотрим следующий Стандарт Банка России СТО БР ФАПИ.ПАОК-1.0-2021 «Безопасность финансовых (банковских) операций. Прикладные программные интерфейсы. Обеспечение безопасности финансовых сервисов при инициации OpenID Connect клиентом потока аутентификации по отдельному каналу. Требования». Особенностью стандарта является предъявление требований к аутентификации в условиях рисков использования клиента (например, при использовании публичного клиента) и применения отдельного канала для аутентификации. В данном стандарте, также как и в первом упомянутом документе, есть раздел с отсылкой на те же нормативные требования, отличие только в том, что сразу же сделан акцент на использовании сертифицированных СКЗИ и на то, что класс СКЗИ должен определяться по результатам анализа системы (что весьма нетривиальное занятие в условиях участия в процессе множества сторон). В целом, данный Стандарт является продолжением (развитием) первого Стандарта в разрезе более конкретной задачи и имеет следующие особенности (требования/подходы):

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

·  При доступе к сервисам только для чтения допускается применение TLS c взаимной аутентификацией сторон, а при доступе для записи, требуется применение TLS только с двухсторонней аутентификацией.

·  При обращении клиента на сервер аутентификации передается идентификационная информация о пользователе. Например, токен идентификации пользователя, токен определяющий логин пользователя или напрямую логин пользователя (login_hint).

·  При взаимодействии по отдельному каналу сервер авторизации не взаимодействует с пользователем через устройство доступа к услугам.

·  В зависимости от рисков доступен дополнительный user_code для исключения риска запросов запросов на аутентификацию для конечного пользователя третьими лицами, знающими login_hint или другие идентификаторы конечного пользователя. Клиент запрашивает у конечного пользователя код пользователя для каждого потока аутентификации и не должен хранить его.

·  Регистрация заранее допустимого для клиента метода аутентификации.

·  Значение идентификаторов не должно указывать клиенту на связь с другими данными или иметь смысловую нагрузку.

·  Значения задержек между запросами, то есть количество времени, которое клиент ожидает между запросами на опрос к конечной точке токена.

·  Требования к исключениям и типам ошибок, таких как, отсутствие обязательных параметров, наличие недопустимых параметров, повторы параметров (дублирование), неправильные значения, ошибки идентификации и т.д.

·  Контроль областей действия токенов (контроль назначения).

·  Требования по поддержке только конфиденциальных (надежных) клиентов для потока аутентификации по отдельному каналу.

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

·  Надежная передача токенов и иный чувствительной информации между устройством аутентификации и устройством доступа конченого пользователя к услугам.

·  Требования по контролю (мониторингу) атаки подмены аутентификации по отдельному потоку аутентификации, параллельному основному.

Интересным моментом являются требования по применению отечественных СКЗИ – сейчас это необязательные стандарты, но вероятно, что мы в перспективе увидим массовый переход финансовой отрасли на использование ГОСТ TLS как продолжение вектора по импортозамещению в кредитно-финансовой сфере. Также хотелось бы отметить широкие возможности по выстраиванию мониторинга событий, соответствующих процессов реагирования. В любом случае, реализация безопасных открытых API даст большой положительный эффект для рынка, но необходим строгий контроль требований безопасности и сертификация решений, представляемых на рынок.