Безопасная среда открытого банкинга (open banking)

0
193

This post is also available in: Английский Французский Немецкий Итальянский Португальский, Бразилия Испанский

Многие из нас пользуются такими службами, как Mint, Chime и Venmo, не зная, что в их основе лежат открытые банковские API (Open Banking APIs).

Инициатива открытого банкинга продиктована главным образом второй версией директивы Евросоюза о платежных услугах (Payment Services Directive 2, PSD2), которая обязала банки безопасно предоставлять закрытые данные клиентов внешним поставщикам услуг с помощью публичных API. Цель директивы — стимулировать инновации и повысить конкуренцию. В отличие от традиционного банкинга, в котором все данные клиентов контролируются головным банком, открытый банкинг предполагает, что пользовательские данные безопасно предоставляются внешним поставщикам услуг через API только при получении разрешения от пользователя. По прогнозу Gartner, к 2022 году атаки на API станут самым распространенным видом атак, что будет приводить к утечке данных из корпоративных веб-приложений. Чтобы защитить API, требуется контроль всех угроз, простая интеграция и полная прозрачность документированных и недокументированных API.

Согласно исследованию, проведенному Celent в 2018 году, количество американских финансовых организаций, использующих открытый банкинг для упрощения доступа сторонних организаций к финансовым и другим данным клиентов, возрастет с 20 до 200 и выше к концу 2021 года. По состоянию на первый квартал 2020 года в Великобритании было зарегистрировано более 300 организаций, заинтересованных в открытом банкинге. В других странах, последовавших европейской модели, например Индии и Австралии, уже образовалась стабильная экосистема открытого банкинга.

Открытые банковские API: что может пойти не так?

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

У API масса преимуществ, но их использование также сопряжено с вопросами безопасности и доступности сервисов, такими как:

  • Нарушение в работе сервиса. Сервисы API могут стать недоступными из-за ошибок в настройках систем безопасности, сетей и приложений, из-за DoS-атак, сбоя в работе инфраструктуры приложений или аутентификации.
  • Проблемы с доверием. Многие решения открытого банкинга созданы только для облачной или гибридной инфраструктуры. При миграции в публичное облако возникают проблемы с доверием из-за несовместимости решений безопасности, различий в конфигурации сред и сложности настройки профилей и политик безопасности приложений.
  • Увеличение поверхности атаки. API часто становятся целями различных типов атак. Исследование Radware показало, что по крайней мере раз в месяц 55% организаций сталкиваются с DoS-атаками на API, 48% — с атаками с внедрением, а 42% — с манипуляциями с элементами или атрибутами. Также происходят атаки на системы аутентификации и авторизации, атаки с внедрением, например внедрение SQL-кода или межсайтовый скриптинг (XSS), и атаки ботов.
  • Атаки ботов на API. Вредоносные боты — это автоматизированные программы, в сценариях которых прописывается взлом учетных записей пользователей, кража учетных данных, мошенничество с платежами, скрейпинг (содержимого, цен, купонов или данных), рассылка спама или пропагандистских материалов и негативное воздействие на работу бизнеса.
  • Кража данных. Многие API обрабатывают персональные данные (PII). Возможность утечки конфиденциальных данных из-за непрозрачной работы API и приложений сторонних организаций — ночной кошмар служб ИТ-безопасности.
  • Публикация недокументированных API. Если недокументированные API не протестировать, они могут стать причиной случайного раскрытия конфиденциальных данных и средством манипуляций.
Une image contenant texte, rideau, corbeille

Description générée automatiquement

Разве шлюза API и брандмауэра веб-приложений недостаточно?

Угрозы варьируют, поэтому для обеспечения безопасности API требуется комбинация мер защиты, включая:

  • Контроль доступа к API для управления аутентификацией, авторизацией и доступом; 
  • Защита API от атак ботов; 
  • Предотвращение DDoS-атак и атак, снижающих доступность сервисов; 
  • Защита от встроенных атак и манипуляций API, устранение уязвимостей API; 
  • Предотвращение утечки персональных данных (PII) и ограничение права доступа к информации; 
  • Защита от мошенничества и фишинга. 

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

[Также вам может быть интересно. Четыре вопроса о соответствии открытого банкинга нормативным требованиям]

Боты не всегда дружелюбны или заметны!

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

Если в организации нет специальных решений для управления ботами, выше вероятность, что она станет жертвой атак на API, например атаки с заполнением учетных данных (credential stuffing), атаки методом перебора (brute force) или скрейпинга.

Что требуется для защиты открытых банковских API?

Une image contenant texte

Description générée automatiquement

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

Выводы:

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

[Понравилась статья? Подпишитесь на еженедельную рассылку свежих новостей от Radware и получите эксклюзивный доступ к премиум-материалам Radware.]

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here