Глубокое погружение в аутентификацию в микросервисах

Что такое сервис аутентификации

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

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

Сервис аутентификации в традиционной архитектуре

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

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

По мере того как бизнесы, разрабатываемые предприятиями, становятся все более сложными, мы обнаруживаем, что отдельные сервисы больше не могут удовлетворять потребности быстрой итерации в реальной жизни. Нам необходимо разделить эту гигантскую систему и обеспечить нормальное взаимодействие между существующими функциями. Для решения этой проблемы появился ESB (Enterprise Service Bus).

"Шина корпоративных сервисов" — это канал, соединяющий различные корпоративные сервисы. Существование ESB предназначено для интеграции различных сервисов с разными протоколами. ESB предоставляет такие услуги, как перевод и маршрутизация клиентских запросов, чтобы различные сервисы могли легко взаимодействовать. Как видно из названия, его концепция заимствована из модели коммуникации в принципах компьютерной архитектуры — шина, все системы, которые нуждаются в общении с внешними системами, подключаются к ESB. Вы можете использовать существующую систему для создания новой слабосвязанной гетерогенной распределенной системы.

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

Монолитная архитектура

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

Архитектура ESB

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

Сервис аутентификации в микросервисной архитектуре

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

Мы можем разделить сервисы аутентификации в микросервисной архитектуре на следующие три категории:

1. Реализация аутентификации в каждом микросервисе
2. Реализация аутентификации через сервис аутентификации
3. Реализация аутентификации через API-шлюз

Каждый подход имеет свои конкретные преимущества и недостатки.

Реализация аутентификации в каждом микросервисе

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

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

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

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

Преимущества: быстрая реализация, высокая независимость

Недостатки: дублирование кода между сервисами; нарушение принципа единой ответственности; сложность в поддержке

Реализация аутентификации через сервис аутентификации

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

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

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

Преимущества: каждый микросервис имеет единую ответственность, аутентификация централизована

Недостатки: единая точка отказа; увеличение задержки запросов

Реализация аутентификации через API-шлюз

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

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

Например, используя плагин jwt-auth в APISIX, мы можем реализовать аутентификацию на шлюзе.

1. Необходимо настроить несколько данных о личности пользователя (имя, ключ и т.д.) в APISIX.
2. В соответствии с предоставленным ключом пользователя, инициировать запрос на подпись в APISIX, чтобы получить JWT-токен пользователя.
3. Затем, когда клиенту нужно получить доступ к вышестоящему сервису, он передает JWT-токен, и APISIX действует как API-шлюз для проксирования этого доступа.
4. Наконец, APISIX выполнит операцию аутентификации с использованием JWT-токена.

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

Преимущества: эффективная защита бэкенд-микросервисов; микросервисы не должны обрабатывать логику аутентификации

Недостаток: единая точка отказа

Итог

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

1. Реализация аутентификации в каждом микросервисе
2. Реализация аутентификации через сервис аутентификации
3. Реализация аутентификации через API-шлюз

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