Обеспечение безопасности в микросервисной архитектуре¶
В микросервисной архитектуре каждый запрос клиента обрабатывается API-шлюзом и минимум одним сервисом. Чтобы обеспечить безопасность в микросервисной архитектуре, нужно определиться с тем, кто отвечает за аутентификацию пользователя, а кто - за авторизацию.
Выполнение аутентификации на API-шлюзе¶
Лучше всего сделать так, чтобы клиент аутентифицировался API-шлюзом.
Это - шаблон токен доступа.
Для API-клиентов последовательность событий такая:
- Клиент делает запрос, содержащий учётные данные.
- API-шлюз аутентифицирует учетные данные, создает токен безопасности и передает сервису или сервисам.
Клиенты, которые используют сеанс, проходят через такую цепочку событий:
- Клиент делает запрос на вход в систему, содержащий учётные данные.
- API-шлюз возвращает токен безопасности.
- Клиент включает токен безопасности в запрос на выполнение операции.
- API-шлюз проверяет токен безопасности и направляет запрос с сервису или сервисам.
Выполнение авторизации¶
Авторизацию можно выполнять в API-шлюзе. Если пользователю не разрешено обращаться по определенному пути, шлюз может отклонить запрос до того, как он будет направлен к сервису. Централизованное размещение авторизации в рамках шлюза снижает риск возникновения уязвимостей.
Одним из недостатков такого подхода является риск привязки API-шлюза к сервисам, что потребует синхронизации их обновлений. Также на API-шлюзе можно реализовать только ролевой доступ (не на основе ACL).
Авторизацию можно реализовать и внутри сервисов. Сервис может выполнять ролевую авторизацию, а также поддерживать списки ACL для управления доступом к агрегатам.
Использование JWT для передачи ролей и учетных данных пользователя¶
Нужно решить, какого рода токен будет передаваться шлюзом сервисам. Существует два типа токенов.
- Непрозрачные токены — обычно имеют формат UUID. Получателям таких токенов нужно делать синхронные RPC-вызовы к сервису безопасности для получения информации о пользователе. Это приводит к понижению доступности и увеличению латентности.
- Прозрачные токены — токены, содержащие пользовательские данные. Например, JWT.
Токен JWT имеет полезную нагрузку (payload) в виде JSON-объекта с необходимыми сведениями о пользователе. Он подписывается секретным ключом, известным только создателю (шлюзу) и получателю (сервису).
Из-за автономности у токена есть проблема - его нельзя отозвать. Следовательно, нельзя отозвать отдельный скомпрометированный токен. Чтобы минимизировать проблему, устанавливают короткий срок годности токена, что вынуждает постоянно перевыпускать токены для поддержки активного сеанса.
Использование OAuth 2.0 в микросервисной архитектуре¶
Однако, OAuth 2.0 — не единственный способ обеспечения безопасности. Однако, в любом случае важно помнить три ключевых принципа:
- API-шлюз ответственен за аутентификацию клиентов
- API-шлюз и сервисы задействуют прозрачные токены, такие как JWT, для обмена информацией о субъекте безопасности.
- Сервис использует токен для получения учетных данных и ролей субъекта.
Дата создания : 2 августа 2022 г.