1. マイクロサービスが直面する課題 (なぜマイクロサービスのセキュリティを提案する必要があるのか?)
- 攻撃対象領域が広くなり、攻撃のリスクが高まります (展開内で 10、15、あるいは数百の独立したマイクロサービスを管理するのはどれほど難しいでしょうか? どうすれば数千のマイクロサービスを安全に管理できるでしょうか?)
- 複数のセキュリティチェックによりパフォーマンスの問題が発生する可能性があります
- マイクロサービス間の信頼が複雑になる
- マイクロサービスの分散的な性質により、ユーザー セッションの共有が困難になります
- 多言語アーキテクチャにはより多くのセキュリティ専門家が必要
2. 主流のセキュリティ メカニズム、マイクロサービスのセキュリティを保護するためのいくつかの一般的なテクノロジ
2.1 国境警備
境界セキュリティの強制は、マイクロサービスを保護するための非常に伝統的なアプローチです。これは、個々のマイクロサービスが安全ではないことを意味し、マイクロサービスにアクセスするレイヤーは信頼される必要があります。Web アプリケーションへのアクセスは安全であり、Web アプリケーションはマイクロサービス層を自由に呼び出します。個々のマイクロサービスは相互に自由に対話します。マイクロサービスに関連するいくつかの特性と要件により、限界セキュリティが不十分になります。
1. さまざまな理由から、認証または認可はサービスごとに実行する必要があります。
2. きめ細かいサービスはそれぞれ、小規模なチームの責任です。これは、データを安全に保つことも彼らの責任であることを意味するかもしれません。
2.2 ユーザー認証（ユーザー名とパスワード）
マイクロサービス アーキテクチャでは、マイクロサービス アプリケーションは複数の独立したマイクロサービス プロセスで構成され、各マイクロサービスへのアクセスにはユーザー認証が必要です。
マイクロサービス アプリケーションは単一責任の原則に従う必要があります。つまり、マイクロサービスは単一のビジネス ロジックのみを処理します。認証と認可の共通ロジックをマイクロサービス実装に配置すべきではありません。したがって、身元認証やユーザーの認証サービスを行うには、抽象的かつ共通のロジックを考える必要があります。マイクロサービスアーキテクチャではAPI Gatewayが外部サービスを提供する入り口として利用されるため、API Gatewayで統一的なユーザー認証を提供することが考えられます。
具体的には、Zuul+Spring Security+OAuth2/JWTを技術実装に使用します。
このアプローチでは、各マイクロサービスは BasicAuthentication を使用して保護されます。これを実現するにはいくつかの方法があります。
1. エンドユーザーの認証情報。この場合、各マイクロサービスは、認証または認可を実行するためにエンド ユーザーのユーザー名とパスワードを必要とします。アプリケーションがマイクロサービスを呼び出すとき、またはマイクロサービスが別のマイクロサービスを呼び出すときは、エンド ユーザーのユーザー名とパスワードを渡す必要があります。このアプローチには多くのセキュリティ リスクが伴います。
2. すべてのマイクロサービスは、エンド ユーザーの資格情報ストアにアクセスできる必要があります。
3. ユーザー名とパスワードは、あるマイクロサービスが別のマイクロサービスを呼び出すときに使用するために、各サービスによってメモリまたはセッションに保存される必要があります。
4. 信頼できるサブシステムの資格情報。ユーザー名とパスワードは、信頼されたサブシステムに使用されます (たとえば、システム内の各エンティティには資格情報セットがあります)。このアプローチの欠点は、エンド ユーザーが不明なため、承認を実行できないことです。エンティティが資格情報を更新するとどうなりますか? 資格情報がファイルに保存されている場合、このファイルはインスタンスごとに更新する必要があります。
2.3 双方向SSL
このセキュリティ メカニズムでは、システム内の各エンティティは証明書 (公開キーと秘密キー) のペアを持ち、双方向 SSL を使用して相互に通信します。, 通常の SSL シナリオでは、サーバーはクライアントによって認証されますが、双方向 SSL では、双方が相互に認証します。、リスクがほとんどないため、エンドユーザーのユーザー名とパスワードを使用するアプローチよりも優れたアプローチです。
ただし、このアプローチのいくつかの欠点を以下に示します。
(1) 各マイクロサービスには証明書が必要となるため、証明書を更新する場合はすべてのインスタンスで更新を行う必要があります。
(2) このモードではエンド ユーザーを認可または認証できません。
(3) これには、信頼されたサブシステム パターンと同様の利点と欠点があります。
2.4 OAuth 2.0 OpenID Connect
OAuth 2.0 は、アプリケーションが相互のデータにアクセスするためのオープンソースの認可プロトコルです。つまり、OAuth は API やサービスではなく、認証と認可 (Authorization) のオープン標準であり、誰もがこの標準に基づいた独自の OAuth を持っています。
マイクロサービスは、OAuth 2.0 および OpenID 接続を使用してユーザーを認証および認可できます。OAuth 2.0 トークンをリクエスターに提供する IdP プロバイダーがあります。たとえば、アプリケーションは OAuth 2.0 アクセス トークンを取得し、このアクセス トークンは MSA 内のすべてのサービスを呼び出すために使用されます。マイクロサービス間の通信にも使用できます。トークンは有効期間の短いアクセスにより、システム全体のセキュリティを簡素化し、向上させます。OpenID Connect を使用すると、エンド ユーザーの ID を取得でき、マイクロサービス自体が承認を実行できるようになります。
ただし、このアプローチの欠点は、IdP 追加パーティを呼び出すことです。
(アイデンティティ プロバイダー (IdP) は、ユーザーの ID を保存および検証するサービスです。IdP は通常、クラウドでホストされるサービスであり、ユーザーの ID を検証するためにシングル サインオン (SSO) プロバイダーと組み合わせられることがよくあります。)
2.5 自己完結型 JWT トークン
これは、マイクロサービスを保護するための最も適切な方法です。
自己完結型 JWT トークンは、トークン自体に認証情報が含まれるトークンです。つまり、トークンは発行者によって署名されており、すべての関係者がトークンの有効性を検証できます。
これは、マイクロサービスがアクセス トークンを検証して JWT トークンを取得するために外部パーティを呼び出す必要がないことを意味します。アクセス トークンを検証してベアラー トークンを取得するための追加の呼び出しがなくなりました。
OAuth2.0 のすべての利点を備えていますが、有効期間の短いトークンの欠点はありません。
1. 強制オフラインなどのクライアント制御の問題
2. トークン取得によるセキュリティリスク