Представьте, что вы построили город из сотен маленьких, умных домов – микросервисов. Каждый дом выполняет свою функцию: один готовит еду, другой следит за отоплением, третий охраняет ворота. Но как сделать так, чтобы жилец из кухни не мог самовольно менять настройки системы безопасности? Как дать почтальону доступ только к почтовому ящику, а не во все комнаты? В этом и есть суть авторизации в распределенной системе – решать, кто, что и при каких условиях может делать.
Почему старые правила здесь не работают
В монолите все просто: проверил права пользователя один раз при входе и храни их в сессии. В мире микросервисов такой подход ломается. Сервисы независимы, общаются по сети, и повторять полную проверку прав для каждого вызова – это долго и создает чудовищную нагрузку. Вам нужна легковесная, но надежная система пропусков, которую каждый сервис сможет проверить самостоятельно.
Основа основ: токены вместо паролей
Ключевую роль здесь играют токены, чаще всего в формате JWT (JSON Web Tokens). Это цифровой пропуск, который сервис выдает пользователю после успешной аутентификации. Внутри него в зашифрованном виде хранятся данные (claims) о пользователе: его идентификатор, роли, скоуп (scope – область допустимых действий). Когда пользователь через API Gateway (единую точку входа) обращается к какому-либо сервису, он просто предъявляет этот токен.
Сервис, не спрашивая главную базу, может расшифровать токен, проверить его подлинность и извлечь данные о правах. Это быстро и снимает нагрузку с централизованных систем.
OAuth2 и OIDC: протоколы для сложного мира
Но кто выдает эти токены и как они попадают от одного сервиса к другому? Здесь на сцену выходят протоколы OAuth2 и OIDC (OpenID Connect).
OAuth2 отвечает за делегирование доступа. Классический пример: вы разрешаете приложению-фоторедактору загрузить ваши фото из облака, не передавая ему ваш пароль. В микросервисах по такому же принципу один сервис может запросить доступ к ресурсам другого от имени пользователя, используя свои клиентские учетные данные и проходя flow обмена токенами.
OIDC расширяет OAuth2, добавляя стандартизированную информацию о пользователе (идентичность). Именно он чаще выступает в роли Identity Provider (IdP) – единого центра аутентификации. Вы логинитесь один раз у IdP, получаете набор токенов (access_token, id_token), и с ними ходите по всем сервисам. Это и есть федеративная идентификация.
Где и как применять политики доступа
Сами политики доступа – это правила, написанные на специальном языке (например, Rego для Open Policy Agent). Они отвечают на вопрос «Разрешено ли действие X для пользователя Y над ресурсом Z?». И применять их можно на разных уровнях:
- На уровне API Gateway: Это первый рубеж обороны. Здесь можно отфильтровать очевидные нарушения: проверить наличие токена, его базовую валидность и наличие минимально необходимого скоупа для вызова группы сервисов. Быстро и эффективно отсекает массу некорректных запросов.
- Внутри каждого микросервиса: Это самый тонкий и важный уровень. Сервис, получив JWT-токен и извлекая из него контекст безопасности (роли, права, атрибуты), сверяет его со своими внутренними политиками. Например, сервис «Заказы» проверяет, может ли пользователь с ролью «менеджер» просматривать заказы только своего филиала, а не всех.
- Через выделенный сервис авторизации: В очень сложных системах политики выносят в отдельный специализированный микросервис. Все остальные сервисы при каждом запросе спрашивают у него: «Можно ли?». Это централизует логику управления, но создает зависимость и потенциальную точку отказа.
- С помощью Service Mesh: В продвинутых архитектурах сервис-меш (например, Istio) позволяет декларативно настраивать политики доступа между сервисами на уровне сетевого трафика. Вы можете задать правила вида «сервису А разрешено вызывать только методы GET сервиса Б», не трогая код самих сервисов.
Антипример: что будет, если этого не делать
Допустим, вы просто передаете идентификатор пользователя между сервисами, полагаясь на их «честность». Сервис «Отзывы» получает запрос на удаление отзыва с ID=123. Он проверяет, принадлежит ли этот отзыв пользователю с ID=456. Но кто гарантировал, что этот ID=456 – подлинный? Предыдущий сервис мог подменить его. Без криптографически подписанного токена с мандатами пользователя вы строите безопасность на песке.
Постройте свою защиту слоями. Используйте API Gateway с поддержкой OAuth2/OIDC как единый фасад для входа. Наделите каждый микросервис способностью самостоятельно проверять JWT-токены и оценивать встроенные в них claims против своих локальных политик. Для сложных межсервисных сценариев используйте обмен токенами по OAuth2. И помните: в распределенной системе безопасность – это не стена, а проверка документов на каждом пропускном пункте. Надежные документы (токены) и четкие инструкции для охраны (политики) не дадут вашему цифровому городу погрузиться в хаос.