• Все разделы
  • Статьи
  • Медиа
  • Новости
  • Нормативные материалы
  • Конференции
  • Глоссарий

Статьи по теме: «Информационная безопасность»

Безопасность API

Статья посвящена теме безопасной работы с интерфейсом программирования приложений (Application Programming Interface, API). В ней рассказывается, что такое токен доступа, почему важно его защищать, как обеспечить его безопасное хранение и защищенный доступ к API.

Безопасность API

Введение

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

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

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

API для партнеров vs. API для клиентов

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

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

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

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

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

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

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

Клиенты
Партнеры
Всегда есть пользователь
Пользователь может отсутствовать
Взаимодействие через UI
Взаимодействие через сервисы (system 2 system)
Компетенции в ИТ отсутствуют
Высокая компетенция в ИТ.
Есть собственная инфраструктура
Сложность при работе с сертификатами
Возможность работы с сертификатами

Что такое токен доступа?

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

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

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

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


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

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

Почему важно защищать токен доступа?

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

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

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

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

Защита API партнера

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

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

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

На первой линии защиты необходимо ограничить использование 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 – «держатель ключа»).

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

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


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

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

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

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


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

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

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

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

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


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

Здесь в дело вступает API gateway (сервис защиты API), сервисное приложение для организации единой точки входа. Оно поддерживает функцию реверсивного установления соединений, при которой один gateway установлен в DMZ, а второй — во внутреннем сегменте сети, и установление соединения инициируется из внутреннего сегмента в DMZ.

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

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

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

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

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

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

API для пользователей

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

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

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

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

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

Безопасное хранение токена доступа

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

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


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

Заключение

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

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

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

Автор:
Тимур Есенбаев, специалист отдела маркетинга и рекламы компании eKassir.
Интервью с экспертом: «На острие атак - мобильный пользователь» Российские SOC на пределе, но выход найден