ソフトウェアのセキュリティは複雑な問題だが,それぞれのサービスがセキュリティを扱わなくてはならないマイクロサービスを採用することで,さらに複雑なものになる – 先日ロンドンで開催されたMicroservices ConferenceでDavid Borsos氏は,マイクロサービスベースのシステムにおける4つのエンドユーザ認証方法を評価した自身の講演の中で,このように説明した。
従来のモノリシックなアーキテクチャでは,ひとつのサーバがすべてのユーザ情報を保持することで,認証されたユーザの検証とHTTPセッションの生成を行なうことが可能だ。マイクロサービスアーキテクチャでは,ユーザはサービスの集合体と対話するため,それぞれのサービスがユーザが誰であるかを知る,潜在的な必要性がある。単純な解決方法は,モノリシックなシステムと同じパターンをマイクロサービスシステムにも適用することだが,すべてのサービスがユーザ情報にアクセスするための方法という問題が生じる。さらに,ユーザデータベースを共有する場合には,スキーマのアップデートも難しい問題になる。すべてのサービスを同時に更新しなくてはならないからだ。同じデータをすべてのサービスに分散するのであれば,ユーザが認証されたことを各サービスが知るための方法が問題になる。
別の解決方法として,シングルサインオン(SSO)ソリューションがよいアイデアに思えるかも知れないが,Borsos氏はそれについて,すべての公開サービスが認証サービスと対話しなくてはならないため,トラフィックが極めて大きなものになる点を指摘する。実装もかなり複雑だ。ただしセキュリティの面は選択したSSOと同等となり,ユーザのログイン状態が隠蔽されるため,攻撃者がそこから有意な情報を推測することを防止できる。
分散セッションソリューションでは,ユーザ認証に関する情報は共有データストアに保存される。これにはユーザセッションをキーとした,単純な分散ハッシュマップが使われることも少なくない。ユーザがマイクロサービスにアクセスすると,ユーザ情報がデータストアからフェッチされる。このソリューションにはもうひとつ,ユーザのログイン状態が不透明だというメリットがある。分散データベースを使用するソリューションは,可用性と拡張性の面でも優れている。一方でマイナス面としては,データストア保護のためにセキュアなコネクションを通じてのみアクセス可能にする必要があることから,ソリューションの実装が比較的複雑なものになる場合が多いという事実などがあげられる。
ユーザの認証にはクライアント側のトークンを使用する。このトークンはクライアント側で生成され,認証サービスによって署名される。トークンには,すべてのマイクロサービスでユーザ認証が行なえるように,十分な情報が含まれていなければならない。トークンは各リクエストにアタッチされ,サービスがそのユーザを確認できる。このソリューションが実現するセキュリティは比較的良好だが,大きな問題は,ログアウトが難しいことだ。これを軽減する方法としては,認証サービスで短命なトークンを用いたり,頻繁にチェックを行なうことなどがある。クライアント側のトークンを使用する場合,Borsos氏は,シンプルである,ライブラリサポートが充実している,といった理由から,JSON Web Token (JWT)の使用を推奨する。
APIゲートウェイとクライアント側のトークンを併用すれば,すべてのリクエストがゲートウェイを通過することになり,マイクロサービスの効果的な隠蔽が実現する。リクエスト上の元のユーザトークンを,ゲートウェイが内部的なセッションIDトークンに置換する。ログアウト時にはゲートウェイがユーザのトークンを取り消すことができるため,この場合,ログアウトは問題にならない。ライブラリのサポートも良好だが,実装が複雑になる可能性はある。
一般的な推奨事項としてBorsos氏は,クライアント側トークンの使用,JWTの使用,APIゲートウェイを提案する。一般的に簡単で,実装が単純であり,パフォーマンスが良好だからだ。SSOも有効ではあるが,避けるべきだと氏は考えている。必要な技術がすでに導入去れているユースケースであれば,分散セッションの利用も興味深いものになるかも知れない。いずれにしても氏は,ソリューションを選択する場合において,ログアウトの重要性を考慮することの重要さを強調している。
2017年のMicroservies Conference in Londonは,11月6日と7日に実施される予定だ。
この記事を評価
- 編集者評
- 編集長アクション