Летом 2022 года Банк России начал готовить к публикации документ, получивший название «Концепция внедрения Открытых API». Публикация концепции — очередной шаг в последовательном процессе, который регулятор реализует уже несколько лет. Цель мероприятия — распространить новые технологии обслуживания при помощи API на всю банковскую отрасль России.
API. Определение и особенности применения
Открытые API (Open API) — это технология обмена данными между информационными системами разных субъектов коммерческой деятельности по стандартным протоколам взаимодействия. По данным РБК, немалое количество крупных отечественных банков уже обладают опытом успешного внедрения Открытых API в собственные бизнес-процессы.
Однако Open API — лишь частный случай применения API как таковых. Банки и другие финансовые организации уже давно используют API (интерфейсы прикладного программирования) для подключения внешних финтех-приложений и сервисов к своим внутренним программным системам. API помогают реализовать то, что мы называем «цифровыми банковскими услугами»: обработку транзакций, перевод денежных средств, работу с клиентскими счетами, подачу кредитных заявлений и проч.
Принцип работы API
Когда пользователь запрашивает баланс в банковском приложении, оно обращается ко внутреннему API, который, в свою очередь, формирует запрос к автоматизированной банковской системе (АБС) и возвращает ответ клиенту.
В широкой трактовке API позволяет получить доступ к различным программным инструментам, вынести в отдельное приложение функциональность, которую необходимо защитить. Благодаря API те же банки могут связывать отдельные компоненты своей системы между собой. Например, к единой экосистеме можно подключить платежный сервис, функционал обмена межбанковскими документами или настроить аутентификацию в личном кабинете пользователя через социальную сеть.
Требования аутентификации и авторизации API
В программной системе современного финансового учреждения, пользователю, прежде чем обратиться к API для получения необходимой услуги, потребуется пройти процедуру аутентификации. API-интерфейсы нуждаются в этой процедуре: поскольку при запросе программной системы банка со стороны стороннего приложения (например, финтех-сервиса) происходит обращение к конфиденциальным клиентским данным. Более того, требования информационной безопасности предполагают, что клиентские запросы должны быть верифицированы — то есть их подлинность не должна вызывать сомнений. На этом основано безопасное взаимодействие между коммерческими партнерами при помощи API.
Напомним, что аутентификация — один из этапов защиты информации (функциональной, персональной или финансовой), во время которого пользователь предоставляет доказательства, что он и есть тот субъект, который запрашивает доступ к защищенным данным.
Аутентификация API необходима еще и потому, что без защиты интерфейсы могли бы быть вызываемы бесчисленное количество раз, что создавало бы избыточную нагрузку на программную инфраструктуру. То есть программная система не смогла бы связывать запросы пользователей с конкретными данными, не рискуя их скомпрометировать.
Методов аутентификации API-интерфейсов довольно много, но мы остановимся на наиболее часто используемых:
- Базовая аутентификации (Basic Auth)
- С использованием API-ключа
- На основе токенов доступа
- Аутентификация сообщений на основе хэша
- Стандарты OAuth 2.0 и OpenID Connect
Базовая аутентификация — наиболее простая схема, при которой в отправленный на сервер запрос помещаются имя пользователя и пароль. Чтобы передать реквизиты через веб, они преобразуются в кодированный набор 64 символов. Когда сервер API получает сообщение, он декодирует его и сверяет заголовок с сохраненными учетными данными. Расшифровав и проанализировав содержимое строки, он принимает или отклоняет запрос.
Аутентификацию API-ключом использует большинство программных интерфейсов. Ключ — это длинная последовательность уникальных символов, используемая вместо стандартных реквизитов. Как правило, такой ключ размещается в заголовок или в URL запроса и позволяет идентифицировать запрашивающий API субъект. Помимо раздачи ключей, сервер API может также заранее ограничить клиенту доступ к части административных функций.
При построении распределенных систем Single Sign-On (когда один сервис делегирует другому функцию аутентификации пользователя) применяют аутентификацию по токенам. Примером такого способа является вход в приложение при помощи привязанного аккаунта социальной сети. Соцсеть передает достоверные сведения о пользователе в виде токена, который приложение сможет использовать для идентификации, аутентификации и авторизации.
Токен содержит широкий набор информации: кем он сгенерирован? кто может его получить? в течение какого срока токен действителен? Также токен может заключать в себе ряд сведений о пользователе и иметь уникальную подпись, подтверждающих достоверность данных.
Hash-based message authentication code (или HMAC) — тип аутентификации на основе хэша, который часто используется в API организаций, обслуживающих финансовые операции. При использовании этого метода сообщение пропускается через алгоритм безопасного хэширования, затем от хэша вычисляется HMAC-подпись.
В методе HMAC отправитель кодирует сообщение, предназначенное получателю, секретным ключом, который после этого пропускается через алгоритм безопасного хэширования. Значение, полученное на выходе (сигнатура или подпись) помещает в заголовок запроса. Сервер API, зная секретный ключ, принимает подпись и генерирует аналогичную строку. Запрос успешно принимается, если содержимое строки и сигнатуры совпадают.
Стандарт OAuth 2.0 относится к одним из наиболее популярных методов аутентификации и авторизации. Он описывает, каким образом стороннее приложение получает доступ к ресурсам пользователя, благодаря чему тот может «связывать» между собой «клиент» (то есть приложение, которым он пользуется) с сервером API и сервером аутентификации.
Схема работы протокола OAuth 2.0
Сперва пользователь дает «клиенту» (приложению или серверу) разрешение на доступ к своим ресурсам. Приложение отправляет данные на страницу входа в систему на сервере аутентификации. Если все успешно — сервер возвращает пользователю токен доступа. После чего пользователь отправляет на сервер API запрос, в заголовок которого добавлена строка токена. Сервер API проверяет токен и принимает решение об авторизации пользователя.
Стандарт OpenID Connect описывает слой учетных данных, накладываемых поверх OAuth. По этому стандарту сервер аутентификации предоставляет дополнительный токен с набором добавочных полей, содержащих некие сведения о пользователе.
Обеспечение безопасности API-ключей
Поскольку все больше организаций используют API для работы с разными сервисами, а количество обрабатываемых данных постоянно увеличивается, API-интерфейсы все чаще становятся объектами кибератак. Проблема с API заключается в том, что они предоставляют доступ к большим объемам информации, минуя традиционные защитные механизмы веб-браузеров. Недостаточно просто перекрыть XSS-эксплойты и подобрать защиту от встраиваний вредоносного SQL-кода — нужно побеспокоиться о злоумышленниках, которые могут авторизоваться и постранично просматривать пользовательские записи.
Выше мы говорили, что обычно программные интерфейсы защищены API-ключом или требуют аутентификации при помощи токена (например, по стандарту JSON Web Token). На практике таким образом обеспечивается естественная защита API, так как инструменты безопасности могут обнаружить аномальное поведение интерфейса и заблокировать доступ к API-ключу. Тем не менее злоумышленники могут сгенерировать колоссальный набор API¬-ключей, перебирая их подобно тому, как это делают с ID-адресами при совершении DDoS-атак.
Самым простым способом обезопасить веб-сайт или сервис является запрет генерировать API-ключи новым пользователям, едва прошедшим регистрацию. Только пользователи, получившие от системы статус доверенных, должны иметь возможность программно генерировать API-ключи.
Можно сократить шанс компрометации ключа, если задать определенное время доступа к API, по истечении которого рабочая сессия завершится. Также хорошей практикой является использование двухфакторной аутентификации для сгенерированных API-ключей.
Используя два токена вместо одного, можно дополнительно защитить API-ключ от раскрытия злоумышленником. Такая схема реализована в OAuth 2.0 — где первый токен (Access token) применяется для запроса к серверу. Как правило, он может быть использован несколько раз и имеет небольшой срок действия. Второй токен (Refresh token) — одноразовый и «живет дольше», он используется для обновления истекшего Access token’а.
Преимущество схемы с двумя токенам состоит в том, что сокращается временное окно, в течение которого злоумышленники могут провести успешную кибератаку на сервис и получить к нему доступ.
Применение API Gateway
С ростом количества пользователей и их запросов к какому-либо сервису API-трафик может замедляться. Поэтому в высоконагруженных системах информация перенаправляется в API Gateway — сервис шлюза, который является единой точкой входа для веб-приложений и API. Этот шлюз выполняет разные задачи — от получения и обработки API-запросов до контроля трафика и уровня доступа.
API Gateway устанавливается «на входе» в инфраструктуру организации и выступает в качестве прокси-буфера между пользователями и API-сервисами. Любые наружные запросы к интерфейсам прикладного программирования проходят через этот шлюз, после чего перенаправляются в один из нескольких микросервисов.
Схема работы API Gateway
Сегодня в разработке все чаще используют облачные API Gateway. Наряду со стандартными задачами, они могут реализовывать быстрое масштабирование, создание и публикацию API, отладку API внутренними средствами, мониторинг, а также интеграцию с иными облачными сервисами.
Самые известные облачные платформы по управлению трафиком API:
- Amazon API Gateway
- Azure API Management
- Oracle API Gateway
- Google API Gateway
- Yandex API Gateway и прочие.
Все они обладают схожим набором функций и позволяют предоставлять контролируемый доступ к API, использовать и тестировать различные типы интерфейсов в одном приложении, создавать API-ключи и проч.
