Дружба дружбой, а табачок врозь?

Концепция открытого банкинга сегодня очень популярна, Центробанк даже создал профильную Ассоциацию ФинТех. Многие банкиры, не будучи членами этой ассоциации, подумывают об использовании архитектуры открытого банкинга как основы для модернизации своего бизнеса. Именно эти банкиры по большей части и пришли на конференцию. Правда, не для выступлений, а пока послушать о серьезных плюсах новой глобальной концепции — предоставлении клиентам большего контроля над своими финансовыми данными, появляющимися новым возможностям для оказания адресных услуг клиентам, ну, и, конечно, возможностями получения новых доходов уже для самого банка. Энтузиазма всем присутствующим добавляла неоднократно цитируемая Вторая директива о платежных услугах (PSD2), в соответствии с которой финтех-компании в Европе могут применять методы открытого банковского обслуживания — к этому их подталкивают государственное регулирование и давление рынка. Открывая API для финтех-компаний, банки порождают совершенно новую цифровую экономику составных (многоступенчатых) финансовых услуг, улучшая этим качество обслуживания собственных клиентов. Но при этом появляется ключевая и болезненная точка соприкосновения банка и финтех-компаний — банковские данные.

Риски всякие важны

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

Уязвимости API под прицелом

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

Все это не пустые страхи и опасения — количество атак на API с каждым годом растет. Фактически некоторые из самых серьезных нарушений безопасности в последнее время связаны именно с уязвимостью API.

В недавних публикациях сообщалось о взломах API на примере LinkedIn и Experian. Во всем мире API печально прославилась своей уязвимостью, когда лазейка в API Facebook позволила компания Cambridge Analytica раскрыть личную информацию более чем 50 млн человек.

Компания Gartner уже много лет заявляет, что к 2022 году проникновения злоумышленников через API станут более частыми, а это, в свою очередь, приведет к утечкам данных в корпоративных веб-приложениях. Gartner недавно обновила собственный прогноз, заявив, что «к 2024 году число атак, использующих уязвимости в API, и связанных с этим утечек данных практически удвоится».

Именно в АPI традиционные технологии защиты приобретают свою специфику, это касается всего. Скажем, на 100% правильно организовать авторизацию для API, видимо, невозможно.

Почему авторизация в API сложна?

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

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

ЦБ нам поможет

Банк России, давно работающий в направлении безопасности интерфейсов, создал уже два стандарта безопасности, заточенных именно на API.

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

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

Положения стандартов применяются на добровольной основе, отмечает ЦБ.

Но даже выполнение этих стандартов Банка России не гарантирует 100%-ной защиты от атак злоумышленников.

В ответе за все

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

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