В 2021 году ежегодный рейтинг десяти наиболее серьезных угроз безопасности веб-приложений (OWASP) возглавил сломанный контроль доступа. Проблемы аутентификации пользователей заняли седьмую строчку.
19-20 мая 2023 года финтех-компания eKassir выступила на Positive Hack Days 12 — крупнейшем российском форуме по кибербезопасности, объединяющем лучших ИБ-экспертов, а также этичных хакеров со всего мира. И в рамках этого мероприятия, Юрий Кардюков — руководитель направления Identity и Open API, рассказал, как с помощью API Gateway и Authentication Server построить безопасную архитектуру предприятия и при этом сэкономить.
Ниже вы можете посмотреть запись доклада или ознакомиться с саммари выступления нашего специалиста.
Claim-based аутентификация и токен доступа
До появления аутентификации на основе утверждений (claim-based) в веб-процессах взаимодействовали две стороны: пользователь, передававший свои credentials, и сервер, который их принимал для клиентской авторизации.
Подобный подход требовал от пользователя передавать каждому сервису логин и пароль, и если они отличались небольшим набором символов, то взлом любого сервиса компрометировал реквизиты входа. Пароли также могли сохраняться в сервисных логах, свободный доступ к которым оставался за администратором. Кроме того, утечки могли происходить через тестовые среды или Debug-режим.
В современной модели claim-based аутентификации появляется третья действующая сторона — Authentication Server (сервер аутентификации, STS, OP), который проверяет данные входа и выпускает мандат (токен доступа), удостоверяющий личность пользователя, но не сообщающий сервисам личную информацию. В нецифровой жизни есть хорошая аналогия токену доступа — паспорт гражданина, удостоверяющий личность на территории государства, которое в этом случае выступает «сервером аутентификации».
Механизм токена доступа в нецифровом мире
Механизм токена доступа в цифровом мире
Технология API Gateway
Токен доступа передается в HTTP-заголовке авторизации при каждом обращении к API сервиса. Сложности возникают, когда токена нет или срок его действия истек. Кажется, что решить вопрос аутентификации можно на стороне сервиса или переложить эту задачу на UI пользователя.
Проблема состоит в том, что разработчики сервисов не являются специалистами в протоколах аутентификации, поэтому могут выбрать неверные библиотеки или некорректно их сконфигурировать. К тому же их основной задачей остается развитие бизнес-функциональности сервера, из-за чего решение инфраструктурных вопросов находится не в приоритете.
Решить описанную проблему позволяет API Gateway. Он перехватывает не аутентифицированный запрос от UI приложения, формирует обратный запрос с указанием расположения сервера аутентификации. Происходит передача логина и пароля — но UI приложения получает не подписанный токен доступа, а некий суррогат кода авторизации. Он возвращается к API Gateway, который и обменивает код авторизации на токен доступа.
Решение: API Gateway
API Gateway сохраняет токен доступа в сессионном хранилище, возвращает на UI зашифрованную сессионную cookie, и получив обратный запрос от UI, обогащает его, удалив cookie и прописав токен доступа в HTTP-заголовке авторизации. При этом конфиденциальные данные хранятся в зашифрованном виде и дешифровать их невозможно без Initial Vector, который содержится в сессионной cookie и есть только у пользователя.
Преимущества API Gateway:
- Токены доступа и идентификационный токен не покидают защищенного контура компании.
- Пользователь не раскрывает логин и пароль сервисам – он вводит его только на сервере аутентификации.
- Разработчики не тратят время на модификацию «бэка» или «фронта».
- Если нужно добавить аутентификацию иного толка (например, биометрию), то это делается на сервере, а не на сервисах.
Хранение чувствительной информации
Refresh token, Single Sign-On и длительная сессионная cookie
Токены доступа обладают ограниченным сроком жизни — от 20 до 60 минут. Для продления их времени действия используются токены обновления (refresh token). Эти токены очень сильны и позволяют получать информацию о пользователе, даже когда тот не находится онлайн.
Проблема с токеном обновления заключается в том, что он позволяет стороннему приложению авторизовать применение токена доступа без согласия со стороны пользователя. Аналогией для нецифрового мира может быть нотариальная доверенность, благодаря которой операционист банка может без участия клиента раз за разом переводить средства с его счета.
Для безопасного использования токена обновления требуется два условия: явное согласие пользователя и возможность его отозвать. В UI-сценариях вместо refresh token применяется технология Single Sign-On (SSO) или, что бывает реже, длительная сессионная cookie.
Решение проблемы безопасной передачи данных
Архитектура System 2 System
Архитектура System 2 System не использует устройства конечного пользователя (например, браузер или мобильное приложение) — она предполагает, что две системы (партнера и сервиса) напрямую общаются друг с другом. Примером использования такой архитектуры могут быть банки, обменивающиеся выписками в конце операционного дня.
Архитектуры пользователей и партнеров имеют ряд существенных отличий.
| Пользователи | Партнеры |
| Всегда есть пользователь | Пользователь может быть, а может и не быть |
| Взаимодействие через UI | Взаимодействие через сервисы (system 2 system) |
| Нет компетенций в IT | Высокая компетенция в IT, наличие собственной инфраструктуры |
| Сложность при работе с сертификатами | Возможность работы с сертификатами |
Типовая архитектура System 2 System выглядит следующим образом. Партнер проходит аутентификацию на сервере и получает токен доступа, содержимое которого подписано, а целостность данных обеспечена. При обращении к сервису партнер добавляет токен доступа в HTTP-заголовок Authorization.
Для безопасной аутентификации в этой архитектуре применяют закрытый ключ и сертификат (private_key_jwt) и криптографический протокол mTLS. Оба этих метода являются безопасными, так как используют PKI инфраструктуру, обладают временем жизни, а в ходе сетевого обмена не отправляются закрытые части ключей, а только их производные.
По умолчанию партнеру выдается токен доступа на предъявителя (bearer). Его особенность состоит в том, что работать с сервисом может тот, кто продемонстрировал токен. Если злоумышленник похитит его, то сможет сам воспользоваться привилегиями доступа. Проблема решается апгрейдом токена доступа до механизма Proof of Possession (PoP) или Holder of the Key (HoK), при котором токен доступа получает «привязку» к партнеру, требующую подтверждения.
Привязка токена доступа к партнеру
Нераскрытие информации и reference token
Токен доступа защищен от изменений, однако содержит ряд утверждений в открытом виде. Они необязательно будут критичными, но могут нести информацию, нежелательную для раскрытия. Чтобы сохранить информацию нераскрытой, обычно используется шифрование. Метод рабочий, но у него есть значительные изъяны:
- Шифрование и расшифровка — трудоемкий процесс, увеличивающий потребление ресурсов.
- Зашифрованный токен доступа в два с лишним раза более «тяжелый», чем обычный подписанный. Для каждого сетевого запроса трафик возрастает на размер самого токена доступа.
- Чтобы выполнить шифрование, нужно использовать открытый ключ не того партнера, который обращается, а сервиса, который будет его потреблять.
- Сервер авторизации не может самостоятельно расшифровать токен, затрудняя его отзыв.
Альтернативой шифрования является технология reference token: его размер в 8 раз меньше, чем у подписанного, и в 16 раз меньше, чем у зашифрованного токена доступа. Reference token обладает всеми свойствами подписанного токена, но не содержит никакой осмысленной информации, и партнер не знает, что за этим скрывается. Сервисы должны обратиться к серверу авторизации, чтобы выполнить процедуру «разыменования», то есть превратить reference token в набор понятных утверждений.
У подобной архитектуры можно выделить следующие плюсы:
- Безопасная аутентификация использует PKI-сертификаты;
- Токен доступа выпущен на предъявителя с привязкой к партнеру;
- Токен доступа имеет формат reference, что снижает сетевую нагрузку и помогает сохранить информацию в тайне.
Итоговая архитектура
Сокращение расходов
API Gateway забирает на себя всю «черновую» работу по обеспечению безопасности. Он валидирует токен доступа, проверяет его актуальность и цифровую подпись, проводит авторизацию, разыменовывает reference token в набор понятных утверждений и многое другое. Таким образом, программисты освобождаются от необходимости от решения инфраструктурных и могут сосредоточиться на бизнес-задачах.
