web-dev-qa-db-ja.com

サービス間のマイクロサービス認証

ServiceAがserviceB（またはホワイトリストに登録されたサービスのセット）によってのみ呼び出されるようにする方法はありますか？すべてのサービスは独立しており、完全に独立しているため、サービスゲートウェイを経由しません。

これについてフォローするのに適したマイクロサービスパターンはありますか？

microservicesauthentication
1
Neo

認証の目的は何ですか？

  • これはセキュリティのためですか？脅威モデルから始めます。何を防御していますか？
  • それとも、単にあなたのアーキテクチャを強制するためですか？

セキュリティのためにこれを行っていると思います。

マイクロサービスを不正アクセスから保護することは妥当です。一般的なアプローチの1つは、DMZを使用してネットワークを設計することです。

---LAN------ --DMZ--     #: router/firewall

          inner   outer
+---+---+---#---+---#--- internet
|   |   |       |
S   S   S       G

 services     gateway,
             web server

すべての外部接続は、認証を提供できるゲートウェイを経由します。

ルーターはファイアウォールとして機能し、次のルールを実装します。

  • ファイアウォールはすべての発信接続を許可します。
  • 内部ファイアウォールは、サービスへの着信接続を許可します。
  • 外部ファイアウォールは、ゲートウェイへの着信接続のみを許可し、内部ルーターへの接続は許可しません。

これにより、内部サービスへの直接の外部接続が防止されます。攻撃者がサービスに接続するには、サービスが接続を開始するか、ゲートウェイ/ Webサーバーを最初に危険にさらすか、ルーターを危険にさらす必要があります。ゲートウェイが危険にさらされている場合、攻撃者はサービスに接続できますが、同じネットワーク上には存在しないため、 LAN上のパケットを盗聴またはスプーフィングできません。

そのため、このネットワーク設計により、特にスタックの下位レベル（オペレーティングシステム、Webサーバーなど）を標的とする攻撃に対して、徹底的な防御が可能になります。また、Wordpressなどの一般的なCMSなどのリスクの高いソフトウェアを公に実行している場合にもお勧めします。より複雑なネットワークトポロジを使用すると、可能な接続をより詳細に制御できます。 2つのサービスセットを異なるネットワークに配置し、それらの間にルートを構成しないことにより、2つのサービスセットが互いに接続するのを防ぐことができます。サービスが同じ物理ネットワーク上にない場合でも、ネットワークブリッジ、VPN、VLANなどの技術を使用して、それらの間のトラフィックをルーティングできます。

このパターンのバリエーションは、「ローカルホストでWebアプリを実行し、Nginxをリバースプロキシとして使用する」展開スタイルです。外部インターフェイス/ IPアドレスをリッスンしないことにより、外部からWebアプリにアクセスできなくなります。 NginxサーバーはパブリックIPアドレスで公開されており、同じコンピューター上のWebアプリに接続できます。 localhostでリッスンする代わりに、Unixソケットがよく使用されます。 Nginxは、不正なリクエストがWebアプリでバグをトリガーする前に拒否するなど、いくつかの潜在的な問題を処理できます。

別のレイヤーとして、アプリケーションレベルのセキュリティ対策を追加して、ネットワーク内の攻撃者による任意のサービスへの接続を防ぐことができます。たとえば、デプロイメントシステムの秘密鍵を作成します。サービスがデプロイされると、対応する公開鍵と、他のサービスを呼び出すことができるJWTスタイルの署名済みトークンが取得されます。サービスはリクエストを受信すると、トークンの署名をチェックし、トークンがこの種のリクエストを許可することを確認します。ただし、これを適切に行うことは困難です。攻撃者がトークンを再利用できるようにします。

3
amon

サービス間認証は非常に重要です。マイクロサービスアーキテクチャは通常、ネットワークセキュリティなどが失敗した場合に備えて、各サービスが自身のセキュリティを担当することに依存しています。 SPIFFE https://spiffe.io/ と呼ばれるよく知られたフレームワークさえあり、Istioのニースの人々によって使用されています。

これについて詳しく話し合ったMobycastのエピソードを行いました： https://mobycast.fm/episode/service-to-service-authentication-for-microservice-apis/

0
broughten

これを行うための明白な方法の1つは、サービスAのAPIキーをサービスBなどの許可された呼び出し元にのみ発行することです。次に、サービスAのエンドポイントは、すべてのリクエストに、許可された呼び出し元に対応する有効なAPIキーヘッダーがあることを確認します。 RESTサービスを構築している場合は、Open API仕様でAPIキーの要件を指定することもできます。

APIキーはマイクロサービスセキュリティの完全なソリューションではなく、より大きなパズルの一部にすぎないことに注意してください。次のような記事で、APIキーでできることとできないことを確認できます。 https://nordicapis.com/why-api-keys-are-not-enough/

0
Aaron M. Eshbach

なぜあなたはそのようなことをしますか？

技術的には、サービスAの使用をサービスBに対応するユーザーXに制限するだけで可能です。サービスにアクセスしようとする他のユーザーは認証できません。つまり、応答としてHTTP 401 Unauthorizedを受け取ります。

IPアドレスをホワイトリストに登録することは、サービスBが複数のインスタンスにデプロイされる可能性があり、他のサービスに再利用される古いマシンで廃止される可能性があるため、維持するのは悪夢です。それをしないでください。

0
Arseni Mourzenko