セキュリティサービスは、マイクロサービスアーキテクチャの単一障害点ですか？

Question

私はマイクロサービスアーキテクチャのアプリケーションを開発中です。各マイクロサービスは、それ自身のために生存することができ、システム内の他のマイクロサービスと直接の依存関係はありません。各マイクロサービスでは、サービスの状態変化を通知するためにCQRSとイベントソーシングを使用しています。他のサービスは、関心があり、データを更新することができる場合、それらのイベントについて通知されます。

これまでのところ、システムは非常にうまく動作します。 1つのマイクロサービスがダウンしている場合、他のマイクロサービスはまだ動作しています。中断されたサービスが再び開始されると、そのサービスが存在しない場合に発生したすべてのイベントを受信し、それらのイベントに応じて自身の状態を更新します。

サービスを保護する必要があり、IdentityServerを使用しています。トークンを取得するために他のマイクロサービスから呼び出されるもう1つのサービス、セキュリティサービスがあります。これは、マイクロサービスが別のマイクロサービスと直接対話しなければならない初めてのことです。

私の問題点は、セキュリティサーバーがダウンしている場合、システム全体が停止していることです。

私は、次の解決策を考えています：

すべてmicroserviceは、独自のデータベース内のユーザデータを保持する必要があります。ユーザーがマイクロサービスにアクセスすると、そのユーザーはセキュリティサービスへのリモートコールなしでサービス内で認証されます。私はまだユーザー管理のためのセキュリティサービスを用意しておくべきです。ユーザへの変更はイベントを再度発生させ、他のマイクロサービスはユーザデータを更新することができる。もちろん、httpsのすべて。セキュリティのために冗長なコードを減らすために、私はナゲットパッケージを使うことができました。

これは合理的なアプローチだと思いますか？

Answer 1

あなたの解決策は、ある特定のセキュリティサービスとは対照的に、任意の microservice を侵害し、攻撃者のために利用可能であること、ユーザーデータのリスクを導入するあなたのアドバイスのための

感謝。私はこれが大きな違いであり、あなたが受け入れたくないリスクだと思います。

OAuth2/OpenID Connectと同様のSSOソリューションでは、各マイクロサービス（SSOが話すService Povider、SP）は、セキュリティサービス（アイデンティティプロバイダ、IP）に接続する必要はありません。クライアント（マイクロサービスの消費者であるクライアント）がIPからトークンを取得すると、そのトークンはIPとは独立して（例えば、公開鍵暗号方式によって）SP上で検証することができる。つまり、IPがダウンしていれば、新しいアクセストークンは発行されませんが、すでに発行されているトークンは引き続き使用され、マイクロサービスは必ずしも消費者を介して直接お互いに話す必要はありません。

Answer 2

解決策は、複数のマイクロサービスにわたってIdentityServerのロジックと状態を複製することを提案しています。基本的に同じことを達成できますが、障害の危険性（HAクラスタ）を最小限に抑えるために、複数の地理的に分散した場所にIdentityServerの複数のインスタンスを作成することにより、より洗練された方法で実現できます。 複数のサービスで（NuGetパッケージを再利用しても）このロジックを複製することで、より多くのリスクを導入します。あなたはまだ、すべてのマイクロサービスにそのナゲットを結びつけなければなりませんか？これがエラーの原因の1つです。

また、彼の答えに記載されているGaborとして、これはユーザーデータベースを侵害するリスクを増加させます。

新しいバージョンのIdentityServerをデプロイした後にエラーが発生する可能性があることを心配している場合は、本番環境にデプロイする前にステージング環境で完全にテストして解決できます。