特許 7536436 情報処理システムおよび情報処理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-09

(45)【発行日】2024-08-20

(54)【発明の名称】情報処理システムおよび情報処理装置

(51)【国際特許分類】

   G06F 9/54 20060101AFI20240813BHJP

【ＦＩ】

G06F9/54 F

【請求項の数】 3

(21)【出願番号】P 2019192687

(22)【出願日】2019-10-23

(65)【公開番号】P2021068160

(43)【公開日】2021-04-30

【審査請求日】2022-10-05

(73)【特許権者】

【識別番号】000155469

【氏名又は名称】株式会社野村総合研究所

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(72)【発明者】

【氏名】近藤 健

(72)【発明者】

【氏名】昼間 貴宏

(72)【発明者】

【氏名】岩佐 歩

(72)【発明者】

【氏名】戸島 達哉

(72)【発明者】

【氏名】太田 茂

【審査官】坂東 博司

(56)【参考文献】

【文献】米国特許出願公開第２００３／０００５１０５（ＵＳ，Ａ１）

【文献】特表２０１８－５２３２４４（ＪＰ，Ａ）

【文献】特表２０１８－５１５８３５（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１５／００６１９０５（ＵＳ，Ａ１）

【文献】特開２０１６－０１２２７２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／５４

(57)【特許請求の範囲】

【請求項1】

アプリケーションフレームワークにより提供される機能を利用する業務アプリケーションを実行する業務処理部と、
外部装置から送信された前記業務アプリケーションに対する複数種類のリクエストを受け付け、受け付けたリクエストを予め定められた単一形式のリクエストに変換し、変換後のリクエストを前記業務処理部に渡すアダプタ部と、
を備え、
前記アプリケーションフレームワークは、前記業務アプリケーションに対するリクエストを前記業務アプリケーションで処理可能なオブジェクトに変換する機能として複数種類の変換機能を備えるものであり、
前記業務処理部は、前記アプリケーションフレームワークが備える前記複数種類の変換機能の一部であって、かつ、前記単一形式のリクエストを前記業務アプリケーションで処理可能なオブジェクトに変換する変換機能以外の変換機能を無効化するよう構成されたことを特徴とする情報処理システム。

【請求項2】

前記アダプタ部により変換されるリクエストの形式は、ＪＳＯＮ（JavaScript Object Notation）であることを特徴とする請求項１に記載の情報処理システム。

【請求項3】

アプリケーションフレームワークにより提供される機能を利用する業務アプリケーションを実行する業務処理部と、
外部装置から送信された前記業務アプリケーションに対する複数種類のリクエストを受け付け、受け付けたリクエストを予め定められた単一形式のリクエストに変換し、変換後のリクエストを前記業務処理部に渡すアダプタ部と、
を備え、
前記アプリケーションフレームワークは、前記業務アプリケーションに対するリクエストを前記業務アプリケーションで処理可能なオブジェクトに変換する機能として複数種類の変換機能を備えるものであり、
前記業務処理部は、前記アプリケーションフレームワークが備える前記複数種類の変換機能の一部であって、かつ、前記単一形式のリクエストを前記業務アプリケーションで処理可能なオブジェクトに変換する変換機能以外の変換機能を無効化するよう構成されたことを特徴とする情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、データ処理技術に関し、特に情報処理システムおよび情報処理装置に関する。

【背景技術】

【0002】

近年、業務処理に必要な機能を実装する複数のアプリケーション間で共通する機能をアプリケーションフレームワーク（以下単に「フレームワーク」と呼ぶ。）として実装し、アプリケーションはフレームワークの機能を利用することでシステム開発の効率化が図られることがある（例えば特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１６－０１２２７２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

フレームワークにセキュリティ上の脆弱性が存在する場合に、そのフレームワークを利用するアプリケーションに対する脆弱性の影響範囲を確認することは容易でない。また、脆弱性を解消するためにフレームワークをバージョンアップすることも考えられるが、アプリケーションがフレームワークの既存機能に強く依存する場合、フレームワークのバージョンアップが困難なこともあった。

【0005】

本発明は、上記課題を鑑みてなされたものであり、１つの目的は、フレームワークの脆弱性に起因するリスクを低減することにある。

【課題を解決するための手段】

【0006】

上記課題を解決するために、本発明のある態様の情報処理システムは、アプリケーションフレームワークにより提供される機能を利用する業務アプリケーションを実行する業務処理部と、外部装置から送信された業務アプリケーションに対する複数種類のリクエストを受け付け、受け付けたリクエストを予め定められた単一形式のリクエストに変換し、変換後のリクエストを業務処理部に渡すアダプタ部と、を備える。

【0007】

本発明の別の態様は、情報処理装置である。この装置は、アプリケーションフレームワークにより提供される機能を利用する業務アプリケーションに対するリクエストであって、外部装置から送信された複数種類のリクエストを受け付ける受付部と、受付部により受け付けられたリクエストを予め定められた単一形式のリクエストに変換し、変換後のリクエストを業務アプリケーションを実行するプロセスに渡す変換部と、を備える。

【0008】

なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、方法、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。

【発明の効果】

【0009】

本発明によれば、フレームワークの脆弱性に起因するリスクを低減することができる。

【図面の簡単な説明】

【0010】

【図1】実施例の通信システムの構成を示す図である。

【図2】図１の業務処理装置の機能ブロックを示すブロック図である。

【図3】引数解決オブジェクトの一部を示す図である。

【図4】業務処理装置におけるリクエスト変換の例を示す図である。

【発明を実施するための形態】

【0011】

実施例のシステム（後述の業務処理装置１２）は、所定のフレームワークの機能を利用する業務アプリケーション（以下「業務Ａｐｐ」とも呼ぶ。）を実行する。実施例のシステムは、業務Ａｐｐに対してフレームワークの脆弱性が影響する範囲が限定されたソフトウェアスタックとなるように構成される。また、実施例のシステムでは、業務Ａｐｐに影響を及ぼすフレームワークの脆弱性が発覚した場合に、業務Ａｐｐに手を加えずに脆弱性に対応可能となるポイントを設ける。これにより、フレームワークの脆弱性に対して迅速かつ柔軟な対応を可能にする。

【0012】

なお、脆弱性とは、コンピュータプログラムの不具合や設計上のミスが原因となって発生した情報セキュリティ上の欠陥のことをいう。フレームワークの脆弱性を突いた攻撃には、特定のデータ列を含むリクエストを送りつけることによって、任意のコードを実行させることや、任意のＯＳ（Operating System）のコマンドを実行させること、任意のファイルを参照すること等がある。

【0013】

図１は、実施例の通信システムの構成を示す。通信システム１０は、業務処理装置１２、クライアント装置１４ａ、クライアント装置１４ｂ、クライアント装置１４ｃ（総称する場合「クライアント装置１４」と呼ぶ。）を備える。業務処理装置１２とクライアント装置１４は、ＬＡＮ・ＷＡＮ・インターネット等を含む通信網１６を介して接続される。

【0014】

業務処理装置１２は、企業等の業務を支援するサービスを提供する情報処理装置である。クライアント装置１４は、業務処理装置１２が提供するサービスを利用する情報処理装置である。クライアント装置１４は、業務処理装置１２が実行する業務アプリケーションに対するリクエストを業務処理装置１２へ送信する。

【0015】

図２は、図１の業務処理装置１２の機能ブロックを示すブロック図である。本明細書のブロック図で示す各ブロックは、ハードウェア的には、コンピュータのプロセッサ、ＣＰＵ、メモリをはじめとする素子や電子回路、機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。

【0016】

業務処理装置１２は、業務処理部２０とアダプタ部３０を備える。業務処理部２０は、アプリケーションコンテナとも言え、アプリケーションフレームワークが提供する機能を利用する業務Ａｐｐを実行する。アダプタ部３０は、アダプタコンテナとも言え、クライアント装置１４から送信された業務Ａｐｐに対する複数種類のリクエストを業務処理部２０の前段で一旦受け付けるＯＳ上のプロセスである。アダプタ部３０は、受け付けたリクエストを予め定められた単一形式のリクエストに変換し、変換後のリクエストを業務処理部２０に渡す。

【0017】

業務処理部２０とアダプタ部３０の構成を詳細に説明する。業務処理部２０は、サーブレットエンジン２２、ＯＳＳフレームワーク２４、ミドルウェア２６、業務Ａｐｐ２８を含む。

【0018】

ＯＳＳフレームワーク２４は、オープンソースのアプリケーションフレームワークであり、実施例では「Spring Framework」である。ミドルウェア２６は、株式会社野村総合研究所が提供するフレームワーク製品である「オブジェクトワークス（登録商標）」である。業務Ａｐｐ２８は、ＯＳＳフレームワーク２４およびミドルウェア２６により提供される機能を利用するよう実装され、かつ、業務固有の機能が実装されたアプリケーションソフトウェアである。

【0019】

ＯＳＳフレームワーク２４は、業務Ａｐｐ２８に対するリクエストを業務Ａｐｐ２８で処理可能なＪａｖａ（登録商標）オブジェクトに変換する機能として、複数種類のリクエストに対応する複数種類の変換機能を備える。業務Ａｐｐ２８は、ＯＳＳフレームワーク２４の変換機能を利用して、リクエストをＪａｖａオブジェクトとして取得し、そのＪａｖａオブジェクトのデータを用いて業務処理を実行する。

【0020】

アダプタ部３０は、リクエスト受信部３２、変換部３４、リクエスト送信部３６、レスポンス転送部３８を含む。これら複数の機能ブロックに対応する複数のモジュールを含むコンピュータプログラムが、記録媒体に格納され、その記録媒体を介して業務処理装置１２のストレージにインストールされてもよい。または、このコンピュータプログラムがネットワークを介して業務処理装置１２のストレージにインストールされてもよい。業務処理装置１２のＣＰＵは、このコンピュータプログラムをメインメモリに読み出して実行することにより上記複数の機能ブロックの機能を発揮してもよい。

【0021】

リクエスト受信部３２は、複数のクライアント装置１４から送信された複数種類のリクエストを受け付ける。複数種類のリクエストは、ＨＴＴＰ（Hyper Text Transfer Protocol）で規定された複数の通信メソッドを含む。例えば、ＧＥＴ、ＨＥＡＤ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ、ＣＯＮＮＥＣＴ、ＯＰＴＩＯＮＳ、ＴＲＡＣＥ、ＰＡＴＣＨを含む。また、通信データの形式も「https://www.iana.org/assignments/media-types/media-types.xhtml」のＴｅｍｐｌａｔｅ列に記載されるように複数存在する。

【0022】

変換部３４は、リクエスト受信部３２により受け付けられたリクエストを予め定められた単一形式のリクエストに変換する。変換部３４により変換されるリクエストの形式は、ＪＳＯＮ（JavaScript Object Notation）（「JavaScript」は登録商標）である。変換部３４は、変換後のリクエストをリクエスト送信部３６に渡す。リクエスト送信部３６は、変換部３４による変換後のリクエストを業務処理部２０に送信し、すなわち、変換後のリクエストを業務Ａｐｐ２８を実行するプロセスに渡す。

【0023】

レスポンス転送部３８は、クライアント装置１４からのリクエストに対するレスポンスデータであり、業務処理部２０から送信されたレスポンスデータを受け付ける。レスポンス転送部３８は、受け付けたレスポンスデータを変換せずにそのままリクエスト送信元のクライアント装置１４へ送信する。

【0024】

既述したように、実施例のＯＳＳフレームワーク２４はＳｐｒｉｎｇである。通常では、Ｓｐｒｉｎｇを利用する業務Ａｐｐ２８の起動時に、リクエストをＪａｖａオブジェクトに変換するための多くのリクエスト－Ｊａｖａオブジェクト変換機能が有効化される。リクエスト－Ｊａｖａオブジェクト変換機能は、例えば、リクエストパラメータ変換、パス変数変換、ボディ（ＪＳＯＮ）変換、ボディ（フォーム）変換、ファイルアップロード、ヘッダ変換等を含む。実施例の業務処理部２０では、Ｓｐｒｉｎｇが備える複数種類のリクエスト－Ｊａｖａオブジェクト変換機能の一部を無効化するように構成される。言い換えれば、Ｓｐｒｉｎｇが備える複数種類のリクエスト－Ｊａｖａオブジェクト変換機能のうちＪＳＯＮデータをＪａｖａオブジェクトに変換するために必要な機能（例えばボディ（ＪＳＯＮ）変換、ヘッダ変換）のみ有効化する。

【0025】

具体的には、通常では、Ｓｐｒｉｎｇを利用する業務Ａｐｐ２８の起動時に、リクエスト－Ｊａｖａオブジェクト変換機能として、２６種類の引数解決オブジェクト（HandlerMethodArgumentResolver）が生成される。図３は、引数解決オブジェクトの一部を示す。引数解決を行う際には、引数解決オブジェクトごとに引数解決を行うかを判定し（supportsParameterメソッド）、該当した最初の引数解決オブジェクトを使用して引数解決を行う（resolveArgumentメソッド）。

【0026】

業務処理部２０（ミドルウェア２６およびＯＳＳフレームワーク２４）は、Ｓｐｒｉｎｇが提供する２６種類の引数解決オブジェクトのうち図３の有効化対象欄で「○」を付した項番７、８以外の引数解決オブジェクトを無効化する。言い換えれば、業務処理部２０は、業務Ａｐｐ２８の起動時に、図３の項番７、８の引数解決オブジェクトのみ起動する。図３の項番７、８の引数解決オブジェクトは、ＪＳＯＮ形式のリクエスト処理に必要な引数解決オブジェクトである。

【0027】

このように、実施例の業務処理装置１２では、クライアント装置１４から送信されうる業務Ａｐｐ２８に対する複数種類のリクエストをアダプタ部３０が一括して受け付ける。アダプタ部３０は、受け付けうる複数種類のリクエストを単一形式（ＪＳＯＮ形式）のリクエストに変換した上で、変換後のリクエストを業務処理部２０に渡す。これにより、業務処理部２０側で必要となるＯＳＳフレームワーク２４の機能（例えばリクエスト－Ｊａｖａオブジェクト変換機能）の種類を低減し、ＯＳＳフレームワーク２４に脆弱性が存在する場合のリスクを低減することができる。

【0028】

また、実施例の業務処理装置１２によると、クライアント装置１４に対して業務処理部２０（ＯＳＳフレームワーク２４）の外部インタフェース仕様を隠蔽することで、業務処理部２０の脆弱性（ここではＳｐｒｉｎｇの脆弱性）を突いた攻撃を受けるリスクを低減することができる。攻撃者にとっては、外部インタフェース仕様が隠蔽されていないシステムを攻撃対象とすることが効率的であり、逆に、外部インタフェース仕様が隠蔽されたシステムは攻撃対象から早々に除外されやすいからである。

【0029】

さらにまた、実施例の業務処理装置１２では、リクエストが単一形式（ＪＳＯＮ形式）に変換されることで不要となったＯＳＳフレームワーク２４のリクエスト－Ｊａｖａオブジェクト変換機能を無効化する。これにより、仮に、変換後のリクエストの処理に不要なＯＳＳフレームワーク２４のリクエスト－Ｊａｖａオブジェクト変換機能に脆弱性が見つかっても、業務Ａｐｐ２８への影響を低減でき、例えば、業務Ａｐｐ２８の改修の必要性を低減できる。

【0030】

さらにまた、これまではアダプタという概念がなかったため、フレームワークに脆弱性が存在した場合、フレームワークをバージョンアップする必要があった。しかし、フレームワークとアプリケーションとは密に結合しており、フレームワークをバージョンアップするとアプリケーション全体の再テストが必要になるため、フレームワークのアップデータは現実的に困難なことがあった。実施例の業務処理装置１２の構成によると、ＯＳＳフレームワーク２４に脆弱性が存在しても、アダプタ部３０の変換機能でその脆弱性による悪影響を回避できる場合、アダプタ部３０の変換機能をバージョンアップ（改修や機能追加等）することで対応でき、業務Ａｐｐ２８への影響を回避することができる。

【0031】

以上の構成による業務処理装置１２の動作を説明する。
図４は、業務処理装置１２におけるリクエスト変換の例を示す。クライアント装置１４は、業務処理装置１２に対してＨＴＴＰ－ＰＯＳＴのリクエストデータ（オリジナルリクエスト４０）を送信する（Ｓ１）。業務処理装置１２のアダプタ部３０は、オリジナルリクエスト４０をＪＳＯＮ形式に変換する。具体的には、アダプタ部３０の変換部３４は、オリジナルリクエスト４０のヘッダデータとボディデータの両方をＪＳＯＮのボディ部４４に設定する。例えば、オリジナルリクエスト４０に含まれるメソッド名、「Content-type」、「Custom-Header」、パス名およびクエリ文字列をＪＳＯＮのボディ部４４に設定する。アダプタ部３０は、ＪＳＯＮ形式の変換後リクエスト４２を業務処理部２０へ送信する（Ｓ２）。

【0032】

業務処理部２０の業務Ａｐｐ２８は、ＯＳＳフレームワーク２４が提供するリクエスト－Ｊａｖａオブジェクト変換機能を利用して、変換後リクエスト４２に対応するＪａｖａオブジェクトを取得する。業務Ａｐｐ２８は、取得したＪａｖａオブジェクトから変換後リクエスト４２のデータ（すなわちオリジナルリクエスト４０のデータ）を取得し、そのデータに基づく業務処理を実行する。業務処理部２０は、業務Ａｐｐ２８による処理結果を含むレスポンス４６をアダプタ部３０へ送信する（Ｓ３）。アダプタ部３０のレスポンス転送部３８は、業務処理部２０から受け付けたレスポンス４６をそのままリクエスト元のクライアント装置１４へ転送する（Ｓ４）。

【0033】

以上、本発明を実施例をもとに説明した。実施例に記載の内容は例示であり、実施例の構成要素や処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

【0034】

第１変形例を説明する。アダプタ部３０のリクエスト受信部３２は、処理対象とするリクエストのパターンを制限してもよい。リクエスト受信部３２は、複数パターンのリクエストのうち業務処理部２０（業務Ａｐｐ２８）が想定するパターン以外のリクエストを拒否してもよく、それらのリクエストに対する後続の処理（ＪＳＯＮ形式への変換処理等）をスキップしてもよい。例えば、既述したように、ＨＴＴＰの通信メソッドには、ＧＥＴ、ＨＥＡＤ、ＰＯＳＴ、ＰＵＴ、ＤＥＬＥＴＥ、ＣＯＮＮＥＣＴ、ＯＰＴＩＯＮＳ、ＴＲＡＣＥ、ＰＡＴＣＨがあるが、リクエスト受信部３２は、ＧＥＴ、ＰＯＳＴ以外のメソッドを指定するＨＴＴＰリクエストを拒否してもよい。

【0035】

同様に、リクエスト受信部３２は、複数形式のリクエストのうち業務処理部２０（業務Ａｐｐ２８）が想定するパターン以外のリクエストを拒否してもよく、それらのリクエストに対する後続の処理（ＪＳＯＮ変換処理等）をスキップしてもよい。例えば、リクエスト受信部３２は、「application/json」、「application/x-www-form-urlencoded」、「multipart/form-data」以外の通信形式をとるＨＴＴＰリクエストを拒否してもよい。第１変形例によると、ＪＳＯＮ形式への変換処理の実装を容易化でき、また、業務処理部２０（業務Ａｐｐ２８）に対する攻撃を受けるリスクを一層低減することができる。

【0036】

第２変形例を説明する。上記実施例では、業務処理部２０とアダプタ部３０を同じ装置（業務処理装置１２）内に設けたが、業務処理部２０とアダプタ部３０を異なる装置内に設けてもよい。すなわち、業務処理部２０を備える第１装置と、アダプタ部３０を備える第２装置とが通信して連携することにより、実施例に記載の業務処理装置１２と同様の機能を発揮する情報処理システムが実現されてもよい。

【0037】

上述した実施例および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。

【符号の説明】

【0038】

１０ 通信システム、 １２ 業務処理装置、 ２０ 業務処理部、 ２４ ＯＳＳフレームワーク、 ２８ 業務Ａｐｐ、 ３０ アダプタ部、 ３２ リクエスト受信部、 ３４ 変換部、 ３６ リクエスト送信部、 ３８ レスポンス転送部。

【図1】

【図2】

【図3】

【図4】