web-dev-qa-db-ja.com

マイクロサービスを使用する場合、認証+承認はゲートウェイレベルで良い考えですか？

私はこのシンプルなデザインを持っています：

                   ---------               -------------
----> Queries ----> Gateway ---- RPC ----> Microservices
                   ---------               -------------

ゲートウェイに認証と承認を処理させて、マイクロサービスがゲートウェイを完全に信頼できるようにすることを考えています（ユーザーxを削除する必要があるとゲートウェイが言った場合は、認証トークンを再確認せずに、実行してください）。マイクロサービスは世界に公開されず、ゲートウェイへの安全な接続（おそらくVPN）を確立します。

これは良い考えですか？または、より合理的なソリューションを採用し、ゲートウェイとマイクロサービスの両方で、各リクエストの認証トークンを確認する必要がありますか？何がうまくいかないのですか？

web-applicationwebserverserverweb-servicearchitecture
3
Valentin Radu

マイクロサービスはどのようにロックダウンされていますか？

攻撃者が内部にいる、または組織内のどこかで弱点を見つけてマイクロサービスを攻撃している場合、攻撃者は完全にセグメンテーションされているため、リクエストのみがゲートウェイを通過しますか？

マイクロサービスのいずれかが、他のマイクロサービスよりも特権があると考えられるアクションを実行しますか？複数のサービスがページコンテンツを生成し、別のサービスが支払いを処理する例？

私の見解では、ゲートウェイで認証した後、すべてのサービスに認証トークンを渡す必要がありますが、これはシステムの脅威モデルによって異なります。

4
McMatty

必ずしも悪い考えではありませんが、少し複雑すぎると思います。あなたが私たちに提供した情報から、私はゲートウェイの必要性をまったく理解していません。

まず、認証サーバーとして機能する個別のサービス/サーバーがあり、ユーザー資格情報を消費し、各ユーザーの役割と認証を保証する署名済みのJWTトークンを吐き出しているとしましょう。次に、クライアントがアクセスするマイクロサービスの1つでクエリを実行する場合、JWTトークンがまだない場合は、認証サーバーからJWTトークンをフェッチし、このJWTトークンをリクエストの認証ヘッダーに直接渡します。マイクロサービス。

次に、マイクロサービスは、署名に使用したのと同じアルゴリズム（HMAC-SHA256アルゴリズムなど）を使用してJWTトークンの署名を検証できます。署名が有効な場合、マイクロサービスはJWTトークンで提供されたロールをチェックし、要求を実行するか拒否します。

このメソッドの問題は、ゲートウェイを回避してマイクロサービスに直接リクエストを送信する可能性です。例えば：

                   ---------               -------------
----> Queries ----> Gateway ---- RPC ----> Microservices
                   ---------               -------------
                                              ^
                                              |
----> Attacker Query -------------------------

攻撃者がJWTトークンを渡さない場合でも、マイクロサービスはリクエストを実行します。

説明したようにゲートウェイを使用する唯一の正当な理由は、クエリを作成する人がこのマイクロサービスがどこにあるかを知る方法がなく、クエリをマイクロサービスに転送するためにゲートウェイを使用する必要がある場合です。この場合、ゲートウェイからのリクエスト以外のリクエストがマイクロサービスに到達できないことを完全に保証できない場合を除き、マイクロサービスとゲートウェイの両方でトークンを確認する必要があります。

それが役に立てば幸い！

2
dFrancisco