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

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

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

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

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

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

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

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

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


security event-sourcing
person kaz    schedule 07.12.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

person Gabor Lengyel    schedule 07.12.2016
comment
Я понимаю вашу точку зрения. Это полезно знать по соображениям производительности. Но моя первоначальная проблема, заключающаяся в том, что вся система зависит от одного сервиса, все еще не решена. Итак, вы говорите мне, что каждый, кто использует эту архитектуру, должен жить с этим риском? Даже netflix? - person kaz; 08.12.2016
comment
Очевидно, @Illiakaill я опередил меня, но он прав (проголосовало за! :)), вы все равно можете распределить поставщика удостоверений на любое количество узлов и создать надлежащую высокую доступность, как и в любом другом случае. Итак, если говорить об одной конкретной службе безопасности, это логический уровень, это может (и должно) быть несколько физических компьютеров в HA. - person Gabor Lengyel; 09.12.2016
comment
Я согласен, но разве эти службы не должны совместно использовать базу данных (потому что они являются экземплярами одной и той же службы безопасности)? Разве это не единственная точка отказа? - person kaz; 09.12.2016
comment
Есть HA и для баз данных. :) Зеркальное отображение, доставка журналов, Always On для SQL Server, но и другие (серьезные) базы данных также поддерживают высокую доступность. - person Gabor Lengyel; 11.12.2016

arrow_upward
1
arrow_downward

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

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

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

person IlliakaillI    schedule 08.12.2016