BIS Journal №1(48)2023

11 апреля, 2023

Защищая API, нужно сократить расходы на ИБ

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

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

Безопасная работа с API — объёмная тема, требующая вдумчивого изучения и подробного обозрения. В этой статье мы остановимся в основном на безопасности при выпуске токена доступа, рассмотрим методы его защиты и хранения.

Мы покажем, как можно защитить доступ к API, заметно сократив расходы на информационную безопасность. Продемонстрированная вам практика реализации этой задачи основывается на опыте разработки и внедрения ПО eKassir Identity Platform. 

 

API ДЛЯ ПАРТНЁРОВ И API ДЛЯ КЛИЕНТОВ

Открывая API в своей ИТ-инфраструктуре, компания может выделить два сценария:

  • API для клиентов;
  • API для партнёров.

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

Когда компания предоставляет API для пользователей (клиентов), обычно подразумевается взаимодействие с человеком посредством UI. Клиент скачивает мобильное приложение либо открывает веб-сайт и работает в интерфейсе. В ответ приложение или браузер отправляют запрос к API компании. 

API для партнёра предполагает тип взаимодействия «система к системе» (system 2 system), при котором UI не используется. Одна информационная система подключается к API другой, передаёт входные параметры и обрабатывает полученные данные напрямую.

Партнёры, как правило, обладают высокой квалификацией в области информационных технологий и безопасности и содержат собственную ИТ-инфраструктуру. Им не составит проблемы использовать инфраструктуру публичных ключей (PKI), чтобы идентифицировать друг друга и организовать взаимную аутентификацию mutual TLS (mTLS). Клиенты же, являющиеся конечными потребителями продукта, не только не обладают, но и не должны обладать компетенциями в ИТ-области. 

Взгляните на таблицу, которая демонстрирует принципиальную разницу между клиентами и партнёрами (рис. 1).

Рисунок 1. Таблица демонстрирует принципиальную разницу между клиентами и партнёрами

 

ЧТО ТАКОЕ ТОКЕН ДОСТУПА?

Сервис, который предоставляет API, должен авторизовать запрос, то есть убедиться, что запрашивающий субъект обладает привилегиями на его выполнение. Современные стандарты авторизации и аутентификации OAuth 2.0 и OpenID Connect используют токен доступа (access token) в качестве источника авторизационной информации.

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

Молодой житель Российской Федерации обращается в территориальный орган МВД, чтобы получить выпущенный и заверенный государством паспорт гражданина. Все структуры и службы России безоговорочно доверяют государству, и когда гражданин предъявляет паспорт, например, в банк или в МФЦ, их сотрудники уверены, что данные о Ф. И. О., прописке и дате рождения гражданина полностью достоверны.

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

Рисунок 2. Пользователь (или система) аутентифицируется на сервере, после чего тот выпускает токен доступа, содержащий в виде утверждений информацию о пользователе (системе) и его привилегиях: каким сервисом он может пользоваться и какие действия на сервере ему разрешены

 

Мы в eKassir разработали программный комплекс Identity Platform, позволяющий создать единый центр аутентификации, управления доступом и защиты API. Один из его компонентов (Access Manager) как раз является таким сервером. После публикации токена Access Manager заверяет данные цифровой подписью, благодаря чему их невозможно модифицировать.

При каждом обращении к API сервиса пользователь предъявляет токен доступа. Поскольку сервис доверяет Access Manager, то и в релевантности токена не сомневается. Сервис проверяет подпись, и если всё в порядке, то, удостоверившись, что токен доступа не был модифицирован, считывает утверждения и на их основании авторизует пользователя. В противном случае запрос отклоняется. Например, если для запрашиваемой операции нужна административная роль, а сервис не находит значение privileged в утверждении role, он отклоняет запрос.

 

ПОЧЕМУ ВАЖНО ЗАЩИЩАТЬ ТОКЕН ДОСТУПА?

Как сказано выше, токен доступа определяет привилегии пользователя. Большинство токенов имеют формат bearer («предъявитель»), то есть их предъявители получают и могут пользоваться установленными привилегиями. 

Токен доступа — этакая «шкатулка» с драгоценностями в виде клиентской информации, которая представляет первостепенный интерес для злоумышленников. Наличие токенов доступа на устройстве создаёт предпосылку для возникновения вектора хакерской атаки на него, а потому их максимальная защита так важна. 

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

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

 

ЗАЩИТА API ПАРТНЁРА

Как правило, партнёры eKassir обладают собственной ИТ-инфраструктурой и способны обеспечить безопасность токенов доступа. Однако перекрыть все уязвимости или полностью обезопасить себя от кражи токена они не могут.

Мы передаём им токены доступа и при помощи Identity Platform принимаем дополнительные меры безопасности. Например, можем привязать токен к системам партнёра на принудительной основе — и даже если он будет украден, то злоумышленники никак не смогут им воспользоваться.

 

Защита от внешних угроз

На первой линии защиты необходимо ограничить использование API, предоставив эту возможность только доверенным партнёрам. Для этого понадобится его безопасная аутентификация. 

Согласно Стандарту Банка России СТО БР ФАПИ.ПАОК-1.0-2021 считаются безопасными те методы аутентификации, которые одновременно:

  • не передают секрет в открытом виде;
  • используют инфраструктуру публичных ключей (PKI).

К сожалению, распространённые методы аутентификации при помощи пароля, API Key или с применением симметричного хеширования HMAC не обеспечивают должный уровень защиты. Так, пароль и API Key передают секрет в открытом виде, а HMAC не использует PKI.

Но можно обойти эту проблему, сделав обязательной взаимную аутентификацию между сервером API и партнёром на транспортном уровне mTLS с проверкой сертификата. Подключиться к API в этом случае могут лишь партнёры, получившие от доверенного удостоверяющего центра сертификат X.509. Уже эта мера отсекает существенную часть внешних угроз.

 

Защита от кражи токенов доступа

На второй линии выполняется привязка токена доступа к партнёру. Тип токена доступа как бы замещается другим, с более высоким статусом: токен bearer («предъявитель») становится токеном PoP (Proof of Possession — «доказательство обладания») или, по-другому, HoK (Holder of the Key — «держатель ключа»).

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

Реализация такого мероприятия помогает защитить партнёров и предотвратить неправомерное использование токенов доступа, которые были похищены (рис. 3).

Рисунок 3. Реализация такого мероприятия помогает защитить партнёров и предотвратить неправомерное использование токенов доступа, которые были похищены

 

Защита от внутренних угроз

Ключевые меры обеспечения безопасности — настроенная взаимная mTLS-аутентификация и привязка токена доступа к партнёру — надёжно защищают API «снаружи». Но что делать с внутренними угрозами?

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

Решить проблему партнёр может при помощи цифровой подписи полезной нагрузки. Перед отправлением запроса нагрузка подписывается, и подпись размещается в HTTP-заголовке. Получив запрос, сервер API вычисляет подпись и сравнивает с содержимым заголовка, тем самым проверяя аутентичность полезной нагрузки. Если внутри контура нагрузка была модифицирована, сервис обнаружит фрод и откажется выполнять запрос (рис. 4). 

Рисунок 4. Если внутри контура нагрузка была модифицирована, сервис обнаружит фрод и откажется выполнять запрос

 

Защита от нераспространения информации  

Партнёрам доступно содержимое токена доступа, и они видят его утверждения — это создаёт риск непреднамеренного раскрытия информации. Утверждения токена могут содержать информацию о местоположении партнёра или критически важные бизнес-данные. В состав утверждений также может входить определение уровня доверия (trust_level) компании, открывающей API, к партнёру. Может выйти конфуз, если партнёр вдруг увидит в этом поле значение low.

Как скрыть информацию в этом случае? Очевидное решение зашифровать содержимое токена доступа может сработать, однако несёт в себе немало минусов:

  • шифрование и дешифрование — затратный процесс, значительно увеличивающий потребление ресурсов;
  • размер зашифрованного токена в два с лишним раза превышает размер незашифрованного; более того, предъявлять токен нужно при каждом запросе API, что кратно увеличивает объём сетевого трафика;
  • шифрование должно выполняться ключом сервиса, получающего запрос, но стандарта обмена подобными ключами не существует;
  • сервер авторизации не сможет расшифровать токен доступа, выпущенный для сервиса. Поэтому механизмы отзыва токена (revocation endpoint) и проверки содержимого и актуальности токена доступа (introspectionendpoint) затруднены или невозможны.

Иными словами, шифрование токена превращает меры информационной безопасности в трудоёмкое и дорогостоящее для бизнеса предприятие. eKassir Identity Platform предлагает решить проблемы другим, лишённым перечисленных недостатков, способом (рис. 5).

Рисунок 5. Identity Platform предлагает решить проблемы другим, лишённым перечисленных недостатков, способом

 

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

Здесь в дело вступает второй компонент Identity Platform — Identity Gateway, ​​сервисное приложение для организации единой точки входа. Оно поддерживает функцию реверсивного установления соединений, при которой один Identity Gateway установлен в DMZ, а второй — во внутреннем сегменте сети, и установление соединения инициируется из внутреннего сегмента в DMZ. 

Identity Gateway перехватит запрос от партнёра к API и заменит reference-токен доступа на полноценный, содержащий утверждения и цифровую JTW-подпись (JSON Web Token). Получив полноценный токен, сервис успешно выполнит авторизацию.

 

Результат защиты API партнёра

В описанной выше ситуации API оказывается защищён от внутренних и внешних угроз, а также устранена опасность, связанная с возможной кражей токена доступа. 

Поскольку токен доступа хранится только в Access Manager (сервер авторизации), не нужно думать о его безопасном хранении. Identity Gateway перехватывает reference-токен, обращается к Access Manager и получает токен доступа в формате JWT. Далее он обогащает запрос и отправляет этот токен на сервис.

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

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

 

API ДЛЯ ПОЛЬЗОВАТЕЛЕЙ

В отличие от партнёров, никакими ИТ-компетенциями пользователи не обладают и потому не способны обеспечить безопасное хранение токенов доступа. Многие фреймворки предлагают свести риски, связанные с хранением токенов на пользовательских устройствах, к минимуму. Это не слишком безопасно, ведь токены будут передаваться на фронтальные устройства, которые могут работать в недоверенной среде исполнения. 

Мы предлагаем решить эту проблему иначе: вообще не передавать токены доступа на устройства пользователей. Вместо этого хранение токенов будет обеспечивать сервисный компонент комплекса Identity Platform — Identity Gateway.

Выглядит это так. Identity Gateway открыто перехватывает неавторизованный запрос пользователя и направляет его в Access Manager, где пользователь проходит аутентификацию. Далее Identity Gateway самостоятельно, без участия браузера или мобильного приложения пользователя, получает токен доступа и сохраняет его в базе данных NoSQL. Вместо токена на пользовательское устройство отправляется безопасная сессионная cookie.

Всякий раз, когда с устройства передаётся запрос, к нему добавляется сессионная cookie. Identity Gateway её получает, извлекает токен доступа из хранилища и добавляет к запросу. Таким образом, Identity Platform не отдаёт сам токен из защищённого контура, а замещает и отправляет вместо него на устройство пользователя «артефакт» — сессионную cookie.

Таким образом, сервисы и API не получают информацию о логине и пароле пользователя — он вводит их только на стороне Identity Platform. Сервис не владеет, не знает и не хранит credentials пользователя, что существенно снижает риск компрометации учётных данных. С другой стороны, токен доступа не покидает ИТ-инфраструктуру и пользователь его никогда не получает.

 

БЕЗОПАСНОЕ ХРАНЕНИЕ ТОКЕНА ДОСТУПА

Токен доступа относится к чувствительной информации — критически важно обеспечить его безопасность. В Identity Platform перед записью токена в базу данных применяется шифрование по алгоритмам с обязательным использованием Initial Vector. Чтобы успешно дешифровать токен, требуется два ключа, один из которых находится у Identity Platform, другой (Initial Vector) — в сессионной cookie. Можно сравнить это с доступом в хранилище банковского депозитария, дверь в который открывается двумя ключами — работника депозитария и сотрудника охраны банка (рис. 6). 

Рисунок 6. Чтобы успешно дешифровать токен, требуется два ключа, один из которых находится у Identity Platform, другой (Initial Vector) — в сессионной cookie

 

При таком подходе зашифрованные данные бесполезны для злоумышленника, даже если он получит в распоряжение диски с базой данных, ведь для расшифровки нужен Initial Vector — а тот есть лишь в сессионной cookie у пользователя.

 

ЗАКЛЮЧЕНИЕ

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

Их эффективным решением может быть использование программного решения «коробочного» формата, который не нужно дорабатывать. В практике нашей компании таким решением стал комплекс eKassir Identity Platform. Выполняющий роль сервера авторизации Access Manager аутентифицирует клиентов и партнёров, выпускает токены доступа, а Identity Gateway обеспечивает защиту API. Интеграция «фронта» не требует ни единой строчки кода, а «бэк» внедряется минимальными усилиями, о чём мы подробно рассказали выше.

Предложенный нами способ решения задачи не является единственным, однако на практике мы убедились, что он вполне реализуем и надёжен. В частности, Identity Platform был использован при внедрении системы аутентификации для организации безопасного доступа клиентов к финансовым услугам «Открытия Инвестиции». 

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

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

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

19.04.2024
Банкиры просят продлить сроки импортозамещения «инософта»
19.04.2024
Россияне смогут получить ЭП за пределами страны
19.04.2024
В России появится консорциум по кибербезопасности ИИ
18.04.2024
У нас есть GitHub дома. Вместо нацрепозитория готовое решение от вендора?
18.04.2024
Минэк создаст профильную комиссию по ИИ-расследованиям
18.04.2024
Видеоидентификация клиентов банков уже в этом году?
18.04.2024
Дано: смартфон. Форма: «Аквариус». Суть: «Лаборатория Касперского»
18.04.2024
Члены АБД утвердили отраслевой стандарт защиты данных
17.04.2024
ФСТЭК будет аттестовать не готовое ПО, а процесс его разработки
17.04.2024
Китайцы используют карты «Мир» для бизнес-платежей

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

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