マイクロサービスにおける認証の深掘り

認証サービスとは何か

認証とは、ユーザーの身元を確認し、ユーザーにシステムへのアクセスと必要な権限を付与するプロセスです。この機能を提供するサービスが認証サービスです。従来のモノリシックなソフトウェアアプリケーションでは、これらすべてが同じアプリケーション内で行われますが、マイクロサービスアーキテクチャでは、システムは複数のサービスで構成されています。各マイクロサービスには独自のタスクがあるため、各マイクロサービスに対して認証と認可のプロセスを個別に実装することは完全には機能しません。

この記事では、従来の認証とマイクロサービス認証を比較します。そして、アーキテクチャの変化によってもたらされる認証の変化を説明します。最後に、マイクロサービスアーキテクチャにおけるさまざまな認証サービスと、それらの実装における利点と欠点を分析します。

従来のアーキテクチャにおける認証サービス

初期の頃、企業がサービスを開発する際、すべての機能は同じアプリケーション内で実装されていました。このモデルを「モノリシック」と呼び、現在のより主流な「マイクロサービス」アーキテクチャと区別します。

モノリシックアプリケーションは、単一の分割不可能なユニットで構成されています。通常、個別の事業部門によって独立して開発され、デプロイ時に同じ環境に結合されます。これらすべてが密接に統合され、1つのユニットですべての機能を提供します。このユニットには必要なすべてのリソースが含まれています。モノリシックアプリケーションの利点は、デプロイと反復が容易であることです。これは、より独立した事業部門が少ない企業に適しています。

企業が開発するビジネスがますます複雑になるにつれて、単一のサービスでは現実の世界での迅速な反復のニーズを満たせなくなります。この巨大なシステムを分割し、既存の機能間の呼び出しが正常に行われるようにする必要があります。この問題を解決するために、**ESB（Enterprise Service Bus）**が登場しました。

「エンタープライズサービスバス」は、さまざまなエンタープライズサービスを接続するパイプラインです。ESBの存在意義は、異なるプロトコルを持つ異なるサービスを統合することです。ESBは、クライアントリクエストの翻訳やルーティングなどのサービスを提供するため、異なるサービスを簡単に相互接続できます。名前からわかるように、その概念はコンピュータ構成の原則における通信モデル（バス）から借用しています。外部システムと通信する必要があるすべてのシステムはESBに接続されます。既存のシステムを使用して、新しい疎結合の異種分散システムを構築できます。

ESBはリクエストを翻訳およびルーティングするため、異なるサービスが互いに通信できます。従来のESBサービス呼び出し方法では、呼び出し元は毎回中央のESBを経由してサービスにルーティングされる必要があります。

モノリシックアーキテクチャ

ユーザー認証とセッション管理は比較的単純です：認証と認可は同じアプリケーション内で行われ、通常はセッションベースの認証スキームを使用します。認証されると、セッションが作成され、サーバー上に保存されます。どのコンポーネントもこれにアクセスして使用し、後続のリクエストを通知および認可できます。セッションIDはクライアントに送信され、後続のすべてのリクエストを現在のセッションに関連付けるために使用されます。

ESBアーキテクチャ

ESBアーキテクチャでは、サービス間のすべてのプロセスはESBバスを介して処理されます。ESBアーキテクチャはモノリシックアーキテクチャから派生しているため、認証方法はモノリシックアーキテクチャと比較して変更されていません。

マイクロサービスアーキテクチャにおける認証サービス

モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行には多くの利点があります。しかし、分散アーキテクチャとして、マイクロサービスアーキテクチャは攻撃対象が広く、ユーザーコンテキストを共有することがより困難です。そのため、マイクロサービスアーキテクチャでは、より大きなセキュリティ課題に対応するために異なる認証サービスが必要です。

マイクロサービスアーキテクチャにおける認証サービスは、以下の3つのカテゴリに分類できます：

各マイクロサービスで認証を実装する
認証サービスを介して認証を実装する
APIゲートウェイを介して認証を実装する

それぞれのアプローチには固有の利点と欠点があります。

各マイクロサービスで認証を実装する

per service authentication

各マイクロサービスはモノリシックアーキテクチャから分割されているため、認証を実装する自然な移行方法は、各マイクロサービスが独自に認証を実装することです。

各マイクロサービスは、各エントリーポイントで強制される独立したセキュリティ保証を実装する必要があります。このアプローチにより、マイクロサービスのチームは、セキュリティソリューションの実装について自律的な決定を下すことができます。しかし、このアプローチにはいくつかの欠点があります：

セキュリティロジックを各マイクロサービスで繰り返し実装する必要があります。これにより、サービス間でコードが重複します。
開発チームが主要なサービスに集中するのを妨げます。
各マイクロサービスは、自身が所有していないユーザー認証データに依存します。
保守と監視が困難です。

このソリューションを改善するための1つのオプションは、各マイクロサービスにロードされる共有認証ライブラリを使用することです。これにより、コードの重複が防止され、開発チームはビジネスドメインにのみ集中できます。しかし、この改善では解決できない欠点もあります。共有認証ライブラリは、対応するユーザー識別データを持っている必要があり、各マイクロサービスが認証ライブラリの正確なバージョンを使用していることを確認する必要もあります。共有認証ライブラリは、サービスの分割が不十分な結果に似ています。

利点: 迅速な実装、強い独立性

欠点: サービス間でのコード重複、単一責任原則の違反、保守の難しさ

認証サービスを介して認証を実装する

authentication service

各マイクロサービスが独自に認証を実装することが難しいため、共有認証ライブラリを使用することはマイクロサービスの分割の本来の意図に反します。では、共有認証ライブラリを専用の認証サービスにアップグレードすることは可能でしょうか？

この場合、すべてのアクセスは同じサービスによって制御され、モノリシックアプリケーション内の認証機能と同様です。各ビジネスサービスは、操作を実行する際に、アクセス制御モジュールに個別の認可リクエストを送信する必要があります。

しかし、このアプローチはサービスを遅くし、サービス間の相互接続を増やします。そして、各マイクロサービスはこの「単一の」認証サービスに依存します。これは単一障害点となり、連鎖反応を引き起こして追加の損害をもたらす可能性があります。

利点: 各マイクロサービスが単一責任を持ち、認証が一元化される

欠点: 単一障害点、リクエストの遅延増加

APIゲートウェイを介して認証を実装する

authentication in the API gateway

マイクロサービスアーキテクチャに移行する際に、マイクロサービスが互いにどのように通信するかという疑問に答える必要があります。前述のESBは1つのアプローチですが、より一般的にはAPIゲートウェイが採用されます。APIゲートウェイは、すべてのリクエストの単一のエントリーポイントです。これにより、これらのマイクロサービスを消費するための中央インターフェースとして機能し、柔軟性を提供します。他のマイクロサービスにアクセスする必要があるマイクロサービス（これ以降、アクセスするマイクロサービスと区別するために「クライアント」と呼びます）は、サービスに直接アクセスするのではなく、リクエストをAPIゲートウェイに送信し、APIゲートウェイがクライアントをアップストリームサービスにルーティングします。

すべてのリクエストは最初にAPIゲートウェイを通過する必要があるため、認証問題を強制するのに適しています。これにより、遅延（認証サービスへの呼び出し）が減少し、アプリケーション全体で認証プロセスが一貫していることが保証されます。

例えば、APISIXのjwt-authプラグインを使用して、ゲートウェイで認証を実装できます。

APISIXにいくつかのユーザー識別情報（名前、キーなど）を設定する必要があります。
指定されたユーザーのキーに基づいて、APISIXに署名リクエストを送信し、ユーザーのJWTトークンを取得します。
その後、クライアントがアップストリームサービスにアクセスする必要がある場合、JWTトークンを持参し、APISIXがAPIゲートウェイとしてこのアクセスをプロキシします。
最後に、APISIXはJWTトークンを使用して認証操作を完了します。

もちろん、すべてに利点と欠点があり、完璧な技術はありません。APIゲートウェイを使用して認証を完了することには、いくつかの問題があります。ゲートウェイでこの問題を解決することは、各マイクロサービス内で認証を完了するよりも安全性が低いです。例えば、APIゲートウェイが侵害されると、その背後にあるすべてのマイクロサービスが暴露されます。しかし、リスクは相対的です。単一の認証サービスと比較すると、APIゲートウェイを使用する問題は軽微です。

利点: バックエンドのマイクロサービスを効果的に保護、マイクロサービスは認証ロジックを処理する必要がない

欠点: 単一障害点

まとめ

異なるシナリオでは、異なる認証スキームが必要になります。モノリシックアプリケーションでは、認証は同じアプリケーション内で行われ、サーバーがすべてのセッションを保存します。マイクロサービスの時代には、モノリシックアプリケーションは分散サービスに進化し、従来の認証方法は適用されません。マイクロサービスアーキテクチャでは、以下の3つの認証方法から選択できます：

各マイクロサービスで認証を実装する
認証サービスを介して認証を実装する
APIゲートウェイを介して認証を実装する

各オプションには固有の利点と欠点があり、状況に応じて詳細に分析する必要があります。