Является ли служба безопасности единственной точкой отказа в архитектуре микросервиса?

Question

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

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

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

Моя проблема с этим подходом заключается в том, что если сервер безопасности выключен, вся система не работает.

Я имею в виду следующее решение:

Каждый microservice должны сохраняться пользовательские данные в своей базе данных. Если пользователь обращается к микросервису, пользователь аутентифицируется внутри службы без удаленного вызова службы безопасности. У меня все равно должна быть служба безопасности для управления пользователями. Изменения в пользователях снова повысят события, а другие микросервисы могут обновлять свои пользовательские данные. Конечно, все с https. И, возможно, чтобы уменьшить избыточный код для обеспечения безопасности, я мог бы использовать пакет nuget.

Как вы думаете, это разумный подход?

Спасибо за ваши советы

Answer 1

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

Обратите внимание, что при использовании решения SSO, подобного OAuth2/OpenID Connect, нет необходимости в каждом микросервисе (Service Povider, SP в SSO) для подключения к службе безопасности (поставщик удостоверений, IP) для каждого запроса , Как только клиент (клиент, являющийся потребителем микросервисов) получил маркер из IP, токен может быть проверен на SP независимо от IP (например, с помощью криптографии с открытым ключом). Это означает, что если IP не работает, не будут выдаваться новые токены доступа, но уже выпущенные будут продолжать работать, а микросервисы не обязательно будут разговаривать напрямую друг с другом, только через своего потребителя.

Answer 2

Ваше решение предполагает дублирование логики и состояния IdentityServer через несколько микросервисов. Вы можете добиться практически той же цели, но более элегантным способом, создав несколько экземпляров IdentityServer в нескольких географически распределенных местах, чтобы минимизировать риски сбоя (кластер HA). Вы будете вводить больше рисков, дублируя эту логику (даже повторно используя пакет NuGet) в нескольких сервисах. Вы все равно должны подключить эту штуку к каждой микросервису, не так ли? Это один из возможных источников ошибок.

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

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