お客様のDXの推進やクラウド活用をサポートする
NRIグループのプロフェッショナルによるブログ記事を掲載

NRIの先進テクノロジーに関する取り組み ~マイクロサービスの認証認可、サービスメッシュ~

IT基盤技術戦略室

小売・製造、金融・公共をはじめ、幅広い業界において「先進技術を活用してビジネスモデルを変革(DX)し、お客さまへ価値提供していきたい」というテクノロジー活用への期待が高まっています。一方、その期待に反して、技術変化のスピードが速く、技術キャッチアップやその活用が難しいといった悩みもお聞きします。

そのような声にお応えするため、株式会社野村総合研究所(NRI)では「潜在的な顧客ニーズ発の技術調査」「技術動向を見据えた先進技術の早期評価「獲得した技術の事業適用」に継続的に取り組んでいます。このような活動を通して、NRIは専門知識を用いて企業様のビジネスとテクノロジーの架け橋となり、DX実現まで伴走します。

このブログでは、NRIで推進している先進的な技術獲得の取り組みについて、ご紹介していきます。今回は、「マイクロサービスの認証認可」、「サービスメッシュ」に関する調査研究の成果をピックアップしました。

 

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

近年のシステムのアーキテクチャはモノリシックだけではなく、マイクロサービスを意識したアーキテクチャも増えてきました。マイクロサービスは一言でいうとアプリケーションの処理を疎結合に分解した要素(サービス)のことです。これらのサービスは、標準的なプロトコルやAPIから利用することができ、またベンダー、製品、技術に依存しない特徴があります。個々のサービスが独立しているためシステム改修時の影響範囲を限定でき、ビジネスの変化に合わせたシステムの素早い追従が可能となるため、注目度は年々高まっています。

システムの構成と認証認可のポイント

図1はモノリシックアーキテクチャとサービス指向アーキテクチャ、マイクロサービスアーキテクチャの概要図です。モノリシックアーキテクチャはシステムが単一のサービスから構成され、そのサービスを構成するコンポーネントは互いに密結合となっています。つまり、モノリシックアーキテクチャでは全てのコンポーネントが連携して1つのサービスとして機能します。サービス指向アーキテクチャではシステムが複数のサービスから構成され、これらはESB(エンタープライズサービスバス)という中継の仕組みを経由して通信を行います。マイクロサービスアーキテクチャではシステムが複数のサービスから構成され、それらは互いに疎結合で独立しています。また、サービス指向アーキテクチャとは異なりサービス同士が直接通信を行います。

さて、マイクロサービスはサービス同士が直接通信を行いますが、どのサービスからでも自由にアクセスできて良いのでしょうか。例えば、ECサイトで商品情報のサービスがユーザの情報を参照しても良いのでしょうか。こうした制御を行うために「認証認可」という考え方があります。認証認可とはアクセス主体に対するサービスの実行可否を確認する仕組みで、アクセス主体の確認(認証)とアクセス主体の権限の確認(認可)を意味します。図1にある「モノリシックアーキテクチャ」や「サービス指向アーキテクチャ」の場合、信頼できるシステムの内部通信として認証認可はほとんど考えられてきませんでした。考えられているのは外部システムとの連結部分のみでした。その一方で「マイクロサービス」は、サービス毎に独立して実行することができるため、たとえシステムの内部通信であっても完全には信用しないよう、各サービス間の認証認可の仕組みが求められます。

マイクロサービスの認証認可を設計する際は、権限管理、セッション管理、プロトコル、非同期処理の認証認可など様々な観点が必要です。認証認可は、セキュリティ上重要な機能であり当該機能の欠落は重大インシデントに直結します。そのため、認証認可は標準化された仕様に従うことがベストプラクティスとされています。そして、マイクロサービスの認証認可はNIST※1のSP800シリーズ※2をベースに議論されることが多いため、関連する資料を一読することを推奨します。

各サービスが個別に認証認可の仕組みを開発する際は、システム全体として統制がとれない、脆弱性の作りこみ原因になる、開発者要員の確保が困難、といった様々な課題があります。そのため、マイクロサービスの特性を踏まえたうえで、認証認可の仕組みの標準化が重要です。

 

サービスメッシュ

マイクロサービスの認証認可の仕組みを標準化するには、上記にあげた権限管理、セッション管理など様々な観点での検討が必要です。今回は、その仕組みの中で運用機能の重要な一部を担う、「サービスメッシュ」についてご紹介します。「サービスメッシュ」とは、各マイクロサービス間で共通する機能を集約した仕組みのことで、サービス間認証認可や流量制御などの機能を有します。これらの機能を個別に開発する必要がないため開発工数の削減や一定の品質確保が期待できます。一方で、各マイクロサービス間、各マイクロサービスを管理するために導入するプロキシとの通信コストがかかるといった課題があります。

ここでは代表的なサービスメッシュの製品、Istio、Cilium、Linkerdの特長を紹介します。Istioは、サービスメッシュ製品のデファクトスタンダードとなるOSSの製品です。通信管理、セキュリティ管理、可観測性の機能を持ち、柔軟な通信制御ができます。各マイクロサービスにプロキシ(サイドカープロキシ)を導入する仕組みのため、通信コストの増加に伴う性能への影響が懸念されます。そのため性能要件は高くないが、できるだけ多くの機能要件を実現したい際はIstioが適しています。また最近、Istioは、Pod群をホストしているノードにプロキシを配置する新たな仕組みを採用しました。マイクロサービスの管理の容易性向上、コンピューティングリソースの効率化が期待されています。Ciliumは、Linuxカーネルの eBPFを利用し、サイドカーレスなサービスメッシュを実現しています。サイドカープロキシを利用するIstioと比較してネットワークレイテンシの低減が可能です。しかし、認証認可の機能を有しておらず、Kubernetes(Service Account)といった他サービスとの連携が必要です。そのため、多くの機能は利用しないが、性能要件が高く、また高負荷のアプリケーションに適しています。Linkerdは、機能面を抑えたシンプルな設計で作られた製品です。認証認可の機能を有しておらず、Ciliumと同様、Kubernetes(Service Account)やKeycloakといった他サービスとの連携が必要です。サイドカープロキシには、Rustで実装したLinkerd2-proxy を使用しており、汎用的なEnvoyを利用したサービスメッシュよりもセキュアで、パフォーマンスが高く、軽量に動作します。そのため、多くの機能は利用しないが、可能な限りネットワークレイテンシを小さくしたい場合に適しています。これらIstio、Cilium、Linkerdの特徴を表1に纏めます。

サービスメッシュ製品の比較表

 

NRIでは、マイクロサービスの認証認可の仕組みの標準化にあたり、設計ポイントの整理やアーキテクチャのモデルケースを設計し、検証・評価を実施しました。今回は、これらの取り組みの一部についてご紹介しました。今後も、NRIでは、この分野での最新の動向をキャッチアップ、調査・検証を通じて、安全・安心で、より柔軟なシステムの実現に取り組んでまいります。

※1 NIST:National Institute of Standards and Technologyの略称で、日本語では米国立標準技術研究所と呼ばれる政府機関のことです。アメリカ商務省に属し、科学技術分野における計測と標準に関する研究が行われています。詳細はこちらをご参照ください。
※2 SP800シリーズ:NISTから発行されているコンピュータセキュリティ関連のレポート、ガイドラインを指します。

[関連キーワード] #API #認証認可 #マイクロサービス #サービスメッシュ

 

※ 記事に記載されている商品またはサービスなどの名称は、各社の商標又は登録商標です。