JP2019056986A - 検証装置及び検証方法 - Google Patents

Abstract

【課題】コンテナイメージのバージョンアップの検証を適切に行う検証装置を提供する。【解決手段】検証装置１００は、本番サーバ１１０と、バッチジョブ解析部１２０と、コンテナイメージ情報収集部１３０と、コンテナイメージ検証管理部１４０と、検証用サーバ１５０と、監視検証部１６０を備える。バッチジョブ解析部は、本番サーバに配備されたバッチジョブの実行前に、バッチジョブを解析し、利用するコンテナイメージを特定する。コンテナイメージ情報収集部は、コンテナイメージレジストリ２００を参照して、コンテナイメージのバージョン情報を収集する。コンテナイメージ検証管理部は、バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、バッチジョブを検証用サーバで実行する。監視検証部は、検証用サーバで実行されるバッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う。【選択図】図１

Description

本発明は、検証装置及び検証方法に関し、特に、コンテナ上でのバッチ処理実行に関するコンテナイメージのセキュリティ安全性を検証する検証装置及び検証方法に関する。

近年、Ｄｏｃｋｅｒをはじめとするコンテナ技術が広がりを見せており、エンタープライズシステムにおける導入実績も報告されている。従来から、ＩＴシステムにおいて、開発面や運用面を効率化する解決策の１つとして仮想化が採用されてきたが、複数のＯＳ（Operating System）を集約した場合の性能劣化等が問題視されてきた。一方、Ｄｏｃｋｅｒは、ゲストＯＳがカーネルや様々なリソースを共有するため、リソースを個別に保持するサーバ型仮想化と比較するとリソース消費量が少なく、軽量に動作することが特徴である。

コンテナは、コンテナイメージから生成される。システムによっては、連動して実行する複数のコンテナとして、一般公開されたコンテナイメージから生成されるコンテナを含む場合があり、セキュリティ面での安全性の確保が求められる。

続いて、バッチ処理について説明する。バッチ処理とは、コンピュータで１つの流れのプログラム群（ジョブ）を順番に実行することである。バッチ処理は、処理の内容があらかじめ決まっているという特徴を有する。バッチ処理では、あらかじめ定めた処理を夜間等にまとめて行う。バッチ処理は、コンテナの考え方である、必要な時に立ち上げて、不要になったら廃棄するという考え方と相性が良い。

続いて、バッチ処理をコンテナ上で行う場合のコンテナイメージのバージョンアップについて説明する。バッチ処理で利用するコンテナイメージのバージョンとして、特定のバージョンが指定されている場合、指定されたものより新しいバージョンがリリースされた際に、新しいバージョンの適用の可否を検討する必要がある。例えば、あるバージョンアップが既知の脆弱性に対応したものであるならば、新バージョンへの移行を検討すべきである。

また、反対に、バッチ処理で利用するコンテナイメージのバージョンとして、特定のバージョンが指定されておらず、「バッチ実行時の最新バージョン」という指定をされている場合がある。この場合、前回のジョブ実行と今回のジョブ実行の間に、あるコンテナイメージのバージョンアップが発生し、意図せず利用するコンテナイメージが変わってしまう可能性がある。これにより、システムにおける脆弱性の発生や、動作の変更が発生する可能性がある。

バッチ処理は、月次バッチや年次バッチ等、前回の実行から期間が開くものがある。このため、バッチ処理をコンテナ上で行う場合、バッチ処理実行時において、前回のバッチ処理実行時から、システムを構成するコンテナイメージのバージョンが更新されている可能性は比較的高い。そして、コンテナイメージのバージョンが更新されている場合には、そのバージョンの適用についての検討が必要となる。

バージョンアップ適用の検討の基準としては、バージョンアップによりセキュリティ強度が下がらないこと、バッチ処理の処理に影響を与えないこと等が挙げられる。これらの検討を行うためには、旧バージョンと新バージョンでの比較を行うことが必要となる。

特許文献１には、システムを構成するアプリケーションのバージョンアップを検出した場合、バージョンアップ前後のアプリケーションのセキュリティ脆弱性レートを算出して、その値によって、バージョンアップをするかどうかを決定する技術が開示されている。

特表２０１６−５２１８９６号公報

しかし、特許文献１に開示の技術では、システム上で動作するバッチ処理についての解析を行わないため、バージョンアップによる動作変更により、バッチ処理結果に影響を与える可能性があるという問題があった。

本発明は、このような問題点を解決するためになされたものであり、バッチ処理をコンテナ上で行う場合のコンテナイメージのバージョンアップの検証を適切に行うことができる検証装置及び検証方法を提供することを目的とする。

本発明の第１の態様にかかる検証装置は、本番サーバに配備されているバッチジョブの実行前に、前記バッチジョブを解析して前記バッチジョブが利用するコンテナイメージを特定するバッチジョブ解析手段と、外部に存在するコンテナイメージレジストリを参照して、前記バッチジョブが利用するコンテナイメージのバージョン情報を収集するコンテナイメージ情報収集手段と、前記バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、前記バッチジョブを検証用サーバにて実行するコンテナイメージ検証管理手段と、前記検証用サーバにて実行される前記バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う監視検証手段と、を備えるものである。

本発明の第２の態様にかかる検証方法は、本番サーバに配備されているバッチジョブの実行前に、前記バッチジョブを解析して前記バッチジョブが利用するコンテナイメージを特定し、外部に存在するコンテナイメージレジストリを参照して、前記バッチジョブが利用するコンテナイメージのバージョン情報を収集し、前記バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、前記バッチジョブを検証用サーバにて実行し、前記検証用サーバにて実行される前記バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う、ことを含むものである。

本発明により、バッチ処理をコンテナ上で行う場合のコンテナイメージのバージョンアップの検証を適切に行うことができる検証装置及び検証方法を提供することができる。

本発明の実施の形態１にかかる検証装置の構成例を示すブロック図である。 本発明の実施の形態１にかかる本番サーバの構成例を示すブロック図である。 本発明の実施の形態１にかかるバッチジョブ解析部によりリストアップされる情報の例を示す図である。 本発明の実施の形態１にかかるコンテナイメージ情報収集部により収集されるコンテナイメージの最新バージョンの例を示す図である。 本発明の実施の形態１にかかる検証用サーバの構成例を示すブロック図である。 本発明の実施の形態１にかかる監視検証部の構成例を示すブロック図である。 本発明の実施の形態１にかかる検証装置の処理例を示すフローチャートである。 本発明の実施の形態１にかかる検証装置におけるコンテナイメージ検証の有無を判断するための処理の流れを示すシーケンス図である。 本発明の実施の形態１にかかる検証装置における検証環境構築から実行結果の検証までの処理の流れを示すシーケンス図である。 本発明の実施の形態１の変形例にかかる検証装置の構成例を示すブロック図である。 本発明の実施の形態２にかかる検証装置の構成例を示すブロック図である。 本発明の実施の形態２の変形例にかかる検証装置の構成例を示すブロック図である。

以下では、本発明の実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

実施の形態１
まず、図１のブロック図を用いて、本発明の実施の形態１にかかる検証装置１００の構成例について説明する。検証装置１００は、本番サーバ１１０と、バッチジョブ解析部１２０と、コンテナイメージ情報収集部１３０と、コンテナイメージ検証管理部１４０と、検証用サーバ１５０と、監視検証部１６０と、を備えている。なお、図１には、コンテナイメージレジストリ２００が示されているが、コンテナイメージレジストリ２００は、検証装置１００が備える構成ではなく、検証装置１００の外部に存在するものである。

本番サーバ１１０は、検証用ではなく、実際にバッチジョブを実行するためのサーバである。本番サーバ１１０には、バッチジョブの実行に必要な各種コンテナが生成されている。なお、本番サーバ１１０に配備されているバッチジョブであって、解析の対象となるバッチジョブのことを第１バッチジョブとも呼ぶ。

本実施の形態１にかかる本番サーバ１１０の構成例を図２に示す。図２に示す例では、本番サーバ１１０には、コンテナＡ、コンテナＢ、コンテナＣ、コンテナＤが生成されている。また、図２に示す例では、本番サーバ１１０に生成されているコンテナＡは、バージョン１．０である。また、本番サーバ１１０に生成されているコンテナＢは、バージョン１．０である。また、本番サーバ１１０に生成されているコンテナＣは、バージョン２．５である。また、本番サーバ１１０に生成されているコンテナＤは、バージョン１．５である。また、本番サーバ１１０に生成されているコンテナＡからコンテナＤは、それぞれ内部にバッチ処理基盤１１１を有し、バッチ処理基盤１１１に第１バッチジョブを配備している。

バッチジョブ解析部１２０は、本番サーバ１１０に配備されているバッチジョブの実行前に、当該バッチジョブを解析し、当該バッチジョブが利用するコンテナイメージを特定する。

具体的には、バッチジョブ解析部１２０は、コンテナイメージ検証管理部１４０から第１バッチジョブの解析依頼を受けた場合に、第１バッチジョブの解析を行い、第１バッチジョブの実行に利用するコンテナイメージ及び当該コンテナイメージの現在の利用バージョンをリストアップする。

本実施の形態１にかかるバッチジョブ解析部１２０によりリストアップされる情報の例を図３に示す。図３の例では、コンテナイメージＡからコンテナイメージＤがリストアップされている。また、コンテナイメージＡ、コンテナイメージＢ、コンテナイメージＤは、それぞれ現在の利用バージョンとして、１．０、１．０、１．５が対応付けられている。これらのコンテナイメージは、明示的にバージョンを指定されてバッチジョブを実行されたものであることを意味する。また、コンテナイメージＣは、現在の利用バージョンにｌａｔｅｓｔ（２．５）と記載されているが、これは明示的なバージョン指定を行わず、「その時点での最新バージョン」という指定によりバッチジョブを実行されたものであることを意味する。そして、括弧内の２．５は、前回のバッチジョブ実行時に実際に利用したバージョンを、現在の利用バージョンとして格納している。

図１に戻り説明を続ける。コンテナイメージ情報収集部１３０は、外部に存在するコンテナイメージレジストリ２００を参照して、バッチジョブが利用するコンテナイメージのバージョン情報を収集する。

具体的には、コンテナイメージ情報収集部１３０は、コンテナイメージ検証管理部１４０からのコンテナイメージ情報採取依頼を受けた場合に、採取依頼されたコンテナイメージの最新バージョンの情報を収集する。

本実施の形態１にかかるコンテナイメージ情報収集部１３０により収集されるコンテナイメージの最新バージョンの例を図４に示す。図４に示す例では、コンテナイメージＡ、コンテナイメージＢ、コンテナイメージＣ、コンテナイメージＤの最新バージョンは、それぞれ、１．１、１．０、２．５、１．５である。

コンテナイメージ検証管理部１４０は、第１バッチジョブの解析依頼を、バッチジョブ解析部１２０へ出力する。また、コンテナイメージ検証管理部１４０は、リストアップされたコンテナイメージの情報を、バッチジョブ解析部１２０から受け取る。

また、コンテナイメージ検証管理部１４０は、リストアップされたコンテナイメージについて、コンテナイメージ情報採取依頼をコンテナイメージ情報収集部１３０へ出力する。また、コンテナイメージ検証管理部１４０は、リストアップされたコンテナイメージの最新バージョンの情報を、コンテナイメージ情報収集部１３０から受け取る。また、コンテナイメージ検証管理部１４０は、リストアップされたコンテナイメージの現在利用しているバージョンと最新バージョンとを比較する。そして、コンテナイメージ検証管理部１４０は、現在利用しているバージョンよりも新しいバージョンがリリースされているコンテナイメージがある場合に、コンテナイメージ検証を実施すると判断し、そうでなければコンテナイメージ検証を実施しないと判断する。

図３及び図４を参照すると、コンテナイメージＡについて、現在の利用バージョン１．０よりも新しいバージョン１．１がリリースされている。このため、コンテナイメージ検証管理部１４０は、コンテナイメージ検証を実施すると判断する。

また、コンテナイメージ検証管理部１４０は、第１バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、第１バッチジョブを検証用サーバ１５０にて実行することにより、コンテナイメージ検証を実施する。

具体的には、コンテナイメージ検証管理部１４０は、検証用サーバ１５０に、新バッチ処理基盤１５１及び旧バッチ処理基盤１５２を構築する。なお、新バッチ処理基盤とは、新しいバージョンのコンテナイメージにより生成された新しいバージョンのコンテナを含むバッチ処理基盤である。また、旧バッチ処理基盤とは、本番サーバ１１０にて前回のバッチジョブを実行した時と同様の構成のバッチ処理基盤である。

本実施の形態１にかかる検証用サーバ１５０の構成例を図５に示す。検証用サーバ１５０には、コンテナＡからコンテナＤについて、最新バージョンのコンテナを含む新バッチ処理基盤１５１が構築されている。また、検証用サーバ１５０には、コンテナＡからコンテナＤについて、前回のバッチジョブを実行した際の利用バージョンのコンテナにより構成される旧バッチ処理基盤１５２が構築されている。なお、新バッチ処理基盤１５１向けの新バージョンのコンテナイメージ、すなわち、コンテナイメージＡのバージョン１．１は、コンテナイメージレジストリ２００からダウンロードされる。また、旧バッチ処理基盤１５２向けの旧バージョンのコンテナイメージについてもコンテナイメージレジストリ２００からダウンロードされてもよいが、これに限らない。

また、コンテナイメージ検証管理部１４０は、新バッチ処理基盤１５１及び旧バッチ処理基盤１５２にて第１バッチジョブを実行する。そして、コンテナイメージ検証管理部１４０は、第１バッチジョブが起動すると、第１バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方の依頼を、監視検証部１６０へ出力する。

監視検証部１６０は、検証用サーバ１５０にて実行されるバッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う。

監視検証部１６０は、例えば、図６のように構成される。図６の例では、監視検証部１６０は、コンテナ監視部１６１と、動作検証部１６２と、を備えている。

コンテナ監視部１６１は、新バッチ処理基盤１５１及び旧バッチ処理基盤１５２における監視を実施する。具体的には、コンテナ監視部１６１は、コンテナイメージ検証管理部１４０から第１バッチジョブの監視を依頼された場合に、第１バッチジョブの開始から終了まで、新バッチ処理基盤１５１及び旧バッチ処理基盤１５２における監視を実施する。なお、コンテナ監視部１６１による監視対象は、例えば、ＣＰＵ（Central Processing Unit）使用率、メモリ使用量、Ｉ／Ｏ（In/Out）状態等のパフォーマンス情報である。

そして、コンテナ監視部１６１は、監視結果をコンテナイメージ検証管理部１４０へ出力する。コンテナイメージ検証管理部１４０は、コンテナ監視部１６１から監視結果を受け取る。また、コンテナイメージ検証管理部１４０は、受け取った監視結果により、第１バッチジョブ実行時のパフォーマンス情報について、新バッチ処理基盤１５１と旧バッチ処理基盤１５２との比較を行う。そして、コンテナイメージ検証管理部１４０は、旧バッチ処理基盤１５２に比べて、新バッチ処理基盤１５１のパフォーマンス情報に異常や特殊な動きがあるか否かを判断する。「異常」の例としては、パフォーマンス情報として、ＣＰＵ使用率、メモリ使用量、Ｉ／Ｏ状態に異常な増減が発生すること等である。また、「特殊な動き」の例としては、意図せず測定値が周期的に増減することや、特定のＵＲＬ（Uniform Resource Locator）にデータを送出しようとする動作等である。コンテナイメージ検証管理部１４０は、新バッチ処理基盤１５１のパフォーマンス情報に異常や特殊な動きがあった場合には、新しいバージョンのコンテナにセキュリティ脆弱性があると判断する。

動作検証部１６２は、新バッチ処理基盤１５１におけるバッチジョブの実行結果と旧バッチ処理基盤１５２におけるバッチジョブの実行結果とを比較することにより検証を実施する。具体的には、動作検証部１６２は、コンテナイメージ検証管理部１４０から第１バッチジョブの実行結果の検証を依頼された場合に、新バッチ処理基盤１５１における第１バッチジョブの実行結果と旧バッチ処理基盤１５２における第１バッチジョブの実行結果とを比較する。

実行結果の比較について例を挙げて説明する。コンテナイメージのあるモジュールのある動作が、バージョンアップによって英字の大文字小文字を区別するようになったケースについて説明する。このケースでは、旧バッチ処理基盤１５２では、バッチジョブの実行により、すべて大文字でデータベースに書き込まれる。また、新バッチ処理基盤１５１では、バッチジョブの実行により、大文字小文字を区別してデータベースに書き込まれる。動作検証部１６２は、例えば、このデータベースに書き込まれる文字を比較することにより検証を実施する。

そして、動作検証部１６２は、検証結果をコンテナイメージ検証管理部１４０へ出力する。コンテナイメージ検証管理部１４０は、動作検証部１６２から検証結果を受け取る。また、コンテナイメージ検証管理部１４０は、受け取った検証結果に基づいて、コンテナイメージのバージョンアップがバッチジョブの実行結果に影響を与えたか否かを判断する。例えば、コンテナイメージ検証管理部１４０は、新バッチ処理基盤１５１における第１バッチジョブの実行結果が、旧バッチ処理基盤１５２における第１バッチジョブの実行結果とは異なる場合に、コンテナイメージのバージョンアップがバッチジョブの実行結果に影響を与えたと判断する。

続いて、図７のフローチャートを用いて、本実施の形態１にかかる検証装置１００の処理例について説明する。

まず、検証装置１００は、バッチジョブ解析部１２０により、本番サーバ１１０に配備されている第１バッチジョブの実行前に、第１バッチジョブを解析して第１バッチジョブが利用するコンテナイメージを特定する（ステップＳ１０１）。

次に、検証装置１００は、コンテナイメージ情報収集部１３０により、外部に存在するコンテナイメージレジストリ２００を参照して、第１バッチジョブが利用するコンテナイメージのバージョン情報を収集する（ステップＳ１０２）。

次に、検証装置１００は、コンテナイメージ検証管理部１４０により、第１バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされているか否かを判断する（ステップＳ１０３）。

なお、ステップＳ１０１からＳ１０３までの処理のことを、コンテナイメージ検証の有無を判断するための処理とも呼ぶ。コンテナイメージ検証の有無を判断するための処理は、例えば、本番サーバ１１０での第１バッチジョブの実行予定時刻の所定時間前に実行される。

第１バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされていない場合（ステップＳ１０３にてＮＯ）、処理を終了する。

他方、第１バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合（ステップＳ１０３にてＹＥＳ）、検証装置１００は、コンテナイメージ検証管理部１４０により、第１バッチジョブを検証用サーバ１５０にて実行する（ステップＳ１０４）。

次に、検証装置１００は、監視検証部１６０により、検証用サーバ１５０にて実行される第１バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う（ステップＳ１０５）。

続いて、図８のシーケンス図を用いて、本実施の形態１にかかる検証装置１００におけるコンテナイメージ検証の有無を判断するための処理の流れについて説明する。

まず、コンテナイメージ検証管理部１４０は、バッチジョブ解析依頼をバッチジョブ解析部１２０へ出力する（ステップＳ２０１）。

バッチジョブ解析部１２０は、バッチジョブ解析依頼を受けると、本番サーバ１１０に配備されている第１バッチジョブを解析し、第１バッチジョブの実行に利用するコンテナイメージをリストアップする（ステップＳ２０２）。そして、バッチジョブ解析部１２０は、リストアップされたコンテナイメージ情報を、コンテナイメージ検証管理部１４０へ出力する（ステップＳ２０３）。

次に、コンテナイメージ検証管理部１４０は、コンテナイメージ情報採取依頼を、コンテナイメージ情報収集部１３０へ出力する（ステップＳ２０４）。

コンテナイメージ情報収集部１３０は、コンテナイメージ情報採取依頼を受けると、コンテナイメージ検証管理部１４０から依頼されたコンテナイメージのバージョンの情報を収集する（ステップＳ２０５）。そして、コンテナイメージ情報収集部１３０は、コンテナイメージの最新バージョン情報をコンテナイメージ検証管理部１４０へ出力する（ステップＳ２０６）。

次に、コンテナイメージ検証管理部１４０は、コンテナイメージ検証の有無を判断する（ステップＳ２０７）。具体的には、コンテナイメージ検証管理部１４０は、リストアップされたコンテナイメージについて、現在利用しているバージョンと最新バージョンとを比較する。そして、コンテナイメージ検証管理部１４０は、現在利用しているバージョンよりも新しいバージョンがリリースされているコンテナイメージがある場合に、コンテナイメージ検証を実施すると判断し、そうでなければコンテナイメージ検証を実施しないと判断する。

続いて、図９のシーケンス図を用いて、本実施の形態１にかかる検証装置１００における検証環境構築から実行結果の検証までの処理の流れについて説明する。

コンテナイメージ検証管理部１４０は、コンテナイメージ検証を実施すると判断すると、検証用サーバ１５０に必要なコンテナイメージをダウンロードする（ステップＳ３０１）。

次に、コンテナイメージ検証管理部１４０は、検証用サーバ１５０上に、ダウンロードしたコンテナイメージから新バッチ処理基盤１５１及び旧バッチ処理基盤１５２を構築する。

次に、コンテナイメージ検証管理部１４０は、検証用サーバ１５０にて第１バッチジョブを実行する（ステップＳ３０３）。

第１バッチジョブが起動すると、コンテナイメージ検証管理部１４０は、コンテナ監視依頼をコンテナ監視部１６１へ出力する（ステップＳ３０４）。

コンテナ監視部１６１は、コンテナ監視依頼を受けると、第１バッチジョブの開始から終了まで、新バッチ処理基盤１５１及び旧バッチ処理基盤１５２における監視を実施する（ステップＳ３０５）。そして、コンテナ監視部１６１は、監視結果をコンテナイメージ検証管理部１４０へ出力する（ステップＳ３０６）。

コンテナイメージ検証管理部１４０は、監視結果を受けて、パフォーマンス情報に異常や特殊な動きがあるか否かを判断する（ステップＳ３０７）。

次に、コンテナイメージ検証管理部１４０は、第１バッチジョブの実行結果の検証を、動作検証部１６２へ依頼する（ステップＳ３０８）。

動作検証部１６２は、検証依頼を受けて、新バッチ処理基盤１５１における第１バッチジョブの実行結果と旧バッチ処理基盤１５２における第１バッチジョブの実行結果とを比較することにより検証を実施する（ステップＳ３０９）。そして、動作検証部１６２は、検証結果をコンテナイメージ検証管理部１４０へ出力する（ステップＳ３１０）。

コンテナイメージ検証管理部１４０は、検証結果を受けて、コンテナイメージのバージョンアップが、バッチジョブの実行結果に影響を与えたか否かを判断する（ステップＳ３１１）。

以上のように、本発明の実施の形態１にかかる検証装置１００は、本番サーバ１１０に配備されている第１バッチジョブの実行前に、第１バッチジョブを解析して第１バッチジョブが利用するコンテナイメージを特定するバッチジョブ解析部１２０を備える構成としている。また、検証装置１００は、外部に存在するコンテナイメージレジストリ２００を参照して、第１バッチジョブが利用するコンテナイメージのバージョン情報を収集するコンテナイメージ情報収集部１３０を備える構成としている。また、検証装置１００は、第１バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、第１バッチジョブを検証用サーバ１５０にて実行するコンテナイメージ検証管理部１４０を備える構成としている。さらに、検証装置１００は、検証用サーバ１５０にて実行される第１バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う監視検証部１６０を備える構成としている。すなわち、検証装置１００では、本番サーバ１１０に配備されている第１バッチジョブについて、そのコンテナイメージの新しいバージョンがリリースされている場合に、第１バッチジョブを検証用サーバ１５０にて実行し、検証用サーバ１５０にて実行される第１バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う構成としている。これにより、本実施の形態１にかかる検証装置１００では、システム上で動作する第１バッチジョブについての検証を検証用サーバ１５０にて行うことができ、コンテナイメージのバージョンアップによる動作変更による影響を検証することができる。すなわち、本実施の形態１にかかる検証装置１００では、バッチ処理をコンテナ上で行う場合のコンテナイメージのバージョンアップの検証を適切に行うことができる。

また、本実施の形態１にかかる検証装置１００では、コンテナイメージ検証管理部１４０が、第１バッチジョブを検証用サーバ１５０にて実行する際に、新しいバージョンのコンテナを含む新バッチ処理基盤１５１と、前回のバッチジョブを実行した際の利用バージョンのコンテナにより構成される旧バッチ処理基盤１５２とを検証用サーバ１５０に構築する構成としている。また、検証装置１００では、コンテナイメージ検証管理部１４０が、新バッチ処理基盤１５１及び旧バッチ処理基盤１５２にて第１バッチジョブを実行する構成としている。これにより、本実施の形態１にかかる検証装置１００では、検証用サーバ１５０において、新しいバージョンのコンテナ及び前回のバッチジョブを実行した際の利用バージョンのコンテナを用いて、バッチジョブの検証を行うことができる。

また、本実施の形態１にかかる検証装置１００では、監視検証部１６０が、新バッチ処理基盤１５１及び旧バッチ処理基盤１５２における監視を実施するコンテナ監視部１６１を備える構成としている。また、検証装置１００では、コンテナイメージ検証管理部１４０が、コンテナ監視部１６１による監視結果に基づいて、新しいバージョンのコンテナにセキュリティ脆弱性があるか否かを判断する構成としている。これにより、本実施の形態１にかかる検証装置１００では、検証用サーバ１５０におけるバッチジョブ実行中の新バッチ処理基盤１５１及び旧バッチ処理基盤１５２における監視により、新しいバージョンのコンテナにセキュリティ脆弱性があるか否かを判断することができる。

また、本実施の形態１にかかる検証装置１００では、監視検証部１６０が、新バッチ処理基盤１５１における第１バッチジョブの実行結果と旧バッチ処理基盤１５２における第１バッチジョブの実行結果とを比較することにより検証を実施する動作検証部１６２を備える構成としている。また、検証装置１００では、コンテナイメージ検証管理部１４０が、動作検証部１６２による検証結果に基づいて、コンテナイメージのバージョンアップが第１バッチジョブの実行結果に影響を与えたか否かを判断する構成としている。これにより、本実施の形態１にかかる検証装置１００では、検証用サーバ１５０におけるバッチジョブの実行により、コンテナイメージのバージョンアップが、バッチジョブの実行結果に影響を与えたか否かを判断することができる。

実施の形態１の変形例
続いて、図１０のブロック図を用いて、本発明の実施の形態１の変形例にかかる検証装置１００Ａの構成例について説明する。検証装置１００Ａは、本番サーバ１１０と、バッチジョブ解析部１２０と、コンテナイメージ情報収集部１３０と、コンテナイメージ検証管理部１４０Ａと、検証用サーバ１５０と、監視検証部１６０と、脆弱性情報収集部１７０と、システム構成管理部１８０と、を備えている。なお、図１０には、脆弱性情報データベース３００が示されているが、脆弱性情報データベース３００は、検証装置１００Ａが備える構成ではなく、検証装置１００Ａの外部に存在するものである。

脆弱性情報収集部１７０は、外部に存在する脆弱性情報データベース３００を参照して、各種の脆弱性情報を収集する。例えば、脆弱性情報収集部１７０は、コンテナイメージ検証管理部１４０Ａから問い合わせを受けると、脆弱性情報データベース３００を参照して、脆弱性情報を収集する。そして、脆弱性情報収集部１７０は、脆弱性情報の収集結果をコンテナイメージ検証管理部１４０Ａへ出力する。

コンテナイメージ検証管理部１４０Ａは、実施の形態１のコンテナイメージ検証管理部１４０の機能に加えて、以下に説明する機能も備えるものである。

コンテナイメージ検証管理部１４０Ａは、コンテナイメージ検証を実施すると判断した場合に、バッチジョブで利用する新しいバージョンのコンテナイメージについての脆弱性情報の問い合わせを、脆弱性情報データベース３００に出力する。また、コンテナイメージ検証管理部１４０Ａは、問い合わせに対する脆弱性情報の収集結果を、脆弱性情報収集部１７０から受け取る。そして、コンテナイメージ検証管理部１４０Ａは、バッチジョブで利用する新しいバージョンのコンテナイメージが、脆弱性情報データベース３００に登録された脆弱性を保持しているか否かの判断を行う。

また、コンテナイメージ検証管理部１４０Ａは、監視検証部１６０による監視結果及び検証結果の少なくとも一方と、脆弱性情報収集部１７０による脆弱性情報の収集結果とに基づいて、利用するコンテナイメージのバージョンを新しいバージョンに更新するか否かの判断を行う。具体的には、コンテナイメージ検証管理部１４０Ａは、新しいバージョンのコンテナイメージが、脆弱性情報データベース３００に登録されておらず、新バッチ処理基盤１５１のパフォーマンス情報に異常や特殊な動きがなく、且つコンテナイメージのバージョンアップがバッチジョブの実行結果に影響を与えないと判断した場合に、利用するコンテナイメージのバージョンを新しいバージョンに更新すると判断する。

コンテナイメージ検証管理部１４０Ａは、利用するコンテナイメージのバージョンを新しいバージョンに更新すると判断した場合に、バージョン更新情報をシステム構成管理部１８０へ出力する。

システム構成管理部１８０は、本番サーバ１１０の構築を行う機能部である。システム構成管理部１８０は、コンテナイメージ検証管理部１４０Ａからバージョン更新情報を受けると、以降の本番サーバ１１０の構築について、コンテナイメージの新しいバージョンを採用して行う。

以上のように、本発明の実施の形態１の変形例にかかる検証装置１００Ａは、外部に存在する脆弱性情報データベース３００を参照して、脆弱性情報を収集する脆弱性情報収集部１７０をさらに備える構成としている。また、検証装置１００Ａでは、コンテナイメージ検証管理部１４０Ａにより、新しいバージョンのコンテナイメージが、脆弱性情報データベース３００に登録された脆弱性を保持しているか否かの判断を行う構成としている。これにより、本実施の形態１の変形例にかかる検証装置１００Ａでは、新しいバージョンのコンテナイメージが、脆弱性情報データベース３００に登録された脆弱性を保持していないかどうかの検証を行うことができる。

また、本実施の形態１の変形例にかかる検証装置１００Ａは、本番サーバ１１０の構築を行うシステム構成管理部１８０をさらに備える構成としている。また、検証装置１００Ａでは、コンテナイメージ検証管理部１４０Ａが、監視検証部１６０による監視結果及び検証結果の少なくとも一方と、脆弱性情報収集部１７０による脆弱性情報の収集結果とに基づいて、利用するコンテナイメージのバージョンを新しいバージョンに更新するか否かの判断を行う構成としている。さらに、検証装置１００Ａでは、システム構成管理部１８０が、コンテナイメージ検証管理部１４０Ａにより新しいバージョンに更新すると判断された場合に、以降の本番サーバ１１０の構築について、新しいバージョンのコンテナイメージを用いて行う構成としている。これにより、本実施の形態１の変形例にかかる検証装置１００Ａでは、新しいバージョンについて脆弱性やバージョンアップによる実行結果への影響がない場合に、新しいバージョンのコンテナイメージを用いて本番サーバ１１０の構築を行うことができる。

実施の形態２
続いて、図１１のブロック図を用いて、本発明の実施の形態２にかかる検証装置１００Ｂの構成例について説明する。検証装置１００Ｂは、本番サーバ１１０と、バッチジョブ解析部１２０と、コンテナイメージ情報収集部１３０と、コンテナイメージ検証管理部１４０Ｂと、検証用サーバ１５０と、監視検証部１６０と、脆弱性情報収集部１７０と、システム構成管理部１８０と、コンテナイメージ保持部１９０と、を備えている。

コンテナイメージ保持部１９０は、本番サーバ１１０のバッチ処理基盤１１１に含まれるコンテナについて、現在利用しているバージョンのコンテナイメージを格納する。

前提として、コンテナ利用に際して、「必要な時だけコンテナを起動し、不要になったら破棄する」という考え方があるため、バッチジョブが終わると、不要なコンテナを削除するという運用が行われる。このため、前回のバッチジョブ実行時と今回のバッチジョブ実行との間にバージョンアップが発生した場合に、前回のバッチジョブ実行時のバッチ処理基盤１１１を構成するコンテナイメージがコンテナイメージレジストリ２００から削除されている可能性がある。このような場合には、旧バージョンのコンテナ環境を再現できなくなる。すなわち、旧バッチ処理基盤１５２を構築することができなくなり、新バッチ処理基盤１５１と旧バッチ処理基盤１５２との比較をすることができない。このため、新しいバージョンのコンテナイメージの正当性を検証することができないという問題が生じる。コンテナイメージ保持部１９０に、本番サーバ１１０のバッチ処理基盤１１１に含まれるコンテナについての現在利用しているバージョンのコンテナイメージを格納することにより、この問題を解消することができる。

コンテナイメージ検証管理部１４０Ｂは、旧バッチ処理基盤１５２向けの旧バージョンのコンテナイメージをコンテナイメージ保持部１９０から取得する。

具体的には、コンテナイメージ検証管理部１４０Ｂは、旧バッチ処理基盤１５２を構築する際に、旧バッチ処理基盤１５２向けの旧バージョンのコンテナイメージがコンテナイメージレジストリ２００からダウンロードできない場合、旧バージョンのコンテナイメージをコンテナイメージ保持部１９０から取得する。

そして、コンテナイメージ検証管理部１４０Ｂは、コンテナイメージ保持部１９０から取得された旧バージョンのコンテナイメージを用いて旧バッチ処理基盤１５２を構築する。

以上のように、本発明の実施の形態２にかかる検証装置１００Ｂは、現在利用しているバージョンのコンテナイメージを格納するコンテナイメージ保持部１９０をさらに備える構成としている。また、検証装置１００Ｂでは、コンテナイメージ検証管理部１４０Ｂが、旧バッチ処理基盤１５２向けの旧バージョンのコンテナイメージをコンテナイメージ保持部１９０から取得する構成としている。さらに、検証装置１００Ｂでは、コンテナイメージ検証管理部１４０Ｂが、コンテナイメージ保持部１９０から取得された旧バージョンのコンテナイメージを用いて旧バッチ処理基盤１５２を構築する構成としている。これにより、本実施の形態２にかかる検証装置１００Ｂでは、前回のバッチジョブ実行時のバッチ処理基盤１１１を構成する旧バージョンのコンテナイメージがコンテナイメージレジストリ２００から削除されている場合であっても、検証用サーバ１５０に旧バージョンのコンテナ環境を構築することができる。

実施の形態２の変形例
続いて、図１２のブロック図を用いて、本発明の実施の形態２の変形例にかかる検証装置１００Ｃの構成例について説明する。検証装置１００Ｃは、本番サーバ１１０と、バッチジョブ解析部１２０と、コンテナイメージ情報収集部１３０と、コンテナイメージ検証管理部１４０Ｃと、検証用サーバ１５０と、監視検証部１６０と、脆弱性情報収集部１７０と、システム構成管理部１８０と、を備えている。

検証装置１００Ｃは、実施の形態２の検証装置１００Ｂが備えているコンテナイメージ保持部１９０を備えていない。検証装置１００Ｃでは、前回のバッチジョブ実行時のバッチ処理基盤１１１を構成する旧バージョンのコンテナイメージがコンテナイメージレジストリ２００から削除されている場合の対処を、コンテナイメージ検証管理部１４０Ｃの処理により行う。すなわち、実施の形態２の変形例では、前回のバッチジョブ実行時の旧バージョンのコンテナイメージが存在しないため、旧バージョンからバージョンアップせざるを得ないという状況である。このため、コンテナイメージ検証管理部１４０Ｃは、旧バージョンより新しいバージョンのうち、どのバージョンにバージョンアップするかを選択する処理を行う。

コンテナイメージ検証管理部１４０Ｃは、旧バッチ処理基盤１５２向けの旧バージョンのコンテナイメージがコンテナイメージレジストリ２００からダウンロードできない場合、当該コンテナイメージについて、前回のバッチジョブ実行時の旧バージョンより新しいバージョンをすべてダウンロードする。そして、コンテナイメージ検証管理部１４０Ｃは、ダウンロードされたすべてのバージョンの検証を実施し、最も適したバージョンを選択する。

なお、最も適したバージョンの選択は、監視検証部１６０による監視結果及び検証結果の少なくとも一方と、脆弱性情報収集部１７０による脆弱性情報の収集結果とに基づいて行われる。

以上のように、本発明の実施の形態２の変形例にかかる検証装置１００Ｃでは、コンテナイメージ検証管理部１４０Ｃが、旧バッチ処理基盤１５２向けの旧バージョンのコンテナイメージがコンテナイメージレジストリ２００からダウンロードできない場合、当該コンテナイメージについて、前回のバッチジョブ実行時の旧バージョンより新しいバージョンをすべてダウンロードする構成としている。また、検証装置１００Ｃでは、コンテナイメージ検証管理部１４０Ｃが、ダウンロードされたすべてのバージョンの検証を実施し、最も適したバージョンを選択する構成としている。これにより、本実施の形態２の変形例にかかる検証装置１００Ｃでは、前回のバッチジョブ実行時のバッチ処理基盤１１１を構成する旧バージョンのコンテナイメージがコンテナイメージレジストリ２００から削除されている場合であっても、現在利用できるバージョンの中からバッチジョブの実行に影響を与えない、且つ最もセキュリティ強度が高いバージョンを検出することができる。

なお、上述した実施の形態では、動作検証部１６２によるバッチジョブの実行結果の比較について、新バッチ処理基盤１５１における実行結果が、旧バッチ処理基盤１５２における実行結果とは異なる場合に、その内容を考慮せずに影響ありと判定することについて説明したが、これに限らない。動作検証部１６２によるバッチジョブの実行結果が異なる場合であっても、最終的なバッチジョブの実行結果に影響を及ぼさない結果であれば、バッチジョブの実行結果に影響はないと判断してもよい。この場合、バッチジョブ解析部１２０により取得されるバッチジョブ情報を利用することにより、バッチジョブの全体の処理内容を把握し、その処理内容に応じて、実行結果が異なる場合であっても許容するようにしてもよい。

ここで、実施の形態１において説明した、コンテナイメージのあるモジュールのある動作が、バージョンアップによって英字の大文字小文字を区別するようになったケースを、再び例にとって説明する。

今回の例では第１バッチジョブが、処理Ａとそれに続けて実行される処理Ｂからなるものとする。処理Ａの実行結果としては、旧バージョンでは、すべて大文字で書き込まれ、新バージョンでは、大文字小文字を区別して書き込まれるものとする。上述の実施の形態では、この時点で、新バージョンはバッチジョブに影響ありと判断し、バージョンアップを行わない。

ここで、処理Ｂは、処理Ａの結果を入力とするが、その英字の大文字小文字を無視して処理を実行するものとする。この場合、処理Ａの新旧バージョンによる差異は、処理Ｂで無効化され、最終的なバッチジョブの実行結果には影響を及ぼさない。このため、コンテナイメージ検証管理部は、新バージョンはバッチジョブに影響を及ぼさない、という判断を行うようにしてもよい。

なお、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、検証装置が備えるＣＰＵ等のプロセッサに、上述した各処理を行うためのコンピュータ・プログラムを実行させることにより実現することも可能である。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施の形態によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

１００、１００Ａ、１００Ｂ、１００Ｃ 検証装置
１１０ 本番サーバ
１１１ バッチ処理基盤
１２０ バッチジョブ解析部
１３０ コンテナイメージ情報収集部
１４０、１４０Ａ、１４０Ｂ、１４０Ｃ コンテナイメージ検証管理部
１５０ 検証用サーバ
１５１ 新バッチ処理基盤
１５２ 旧バッチ処理基盤
１６０ 監視検証部
１６１ コンテナ監視部
１６２ 動作検証部
１７０ 脆弱性情報収集部
１８０ システム構成管理部
１９０ コンテナイメージ保持部
２００ コンテナイメージレジストリ
３００ 脆弱性情報データベース

Claims (10)

1. 本番サーバに配備されているバッチジョブの実行前に、前記バッチジョブを解析して前記バッチジョブが利用するコンテナイメージを特定するバッチジョブ解析手段と、
   外部に存在するコンテナイメージレジストリを参照して、前記バッチジョブが利用するコンテナイメージのバージョン情報を収集するコンテナイメージ情報収集手段と、
   前記バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、前記バッチジョブを検証用サーバにて実行するコンテナイメージ検証管理手段と、
   前記検証用サーバにて実行される前記バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う監視検証手段と、
   を備える検証装置。
2. 前記コンテナイメージ検証管理手段は、前記バッチジョブを前記検証用サーバにて実行する際に、新しいバージョンのコンテナを含む新バッチ処理基盤と、前回のバッチジョブを実行した際の利用バージョンのコンテナにより構成される旧バッチ処理基盤とを前記検証用サーバに構築し、前記新バッチ処理基盤及び前記旧バッチ処理基盤にて前記バッチジョブを実行する、請求項１に記載の検証装置。
3. 前記監視検証手段は、前記新バッチ処理基盤及び前記旧バッチ処理基盤における監視を実施するコンテナ監視手段を備え、
   前記コンテナイメージ検証管理手段は、前記コンテナ監視手段による監視結果に基づいて、前記新しいバージョンのコンテナにセキュリティ脆弱性があるか否かを判断する、
   請求項２に記載の検証装置。
4. 前記監視検証手段は、前記新バッチ処理基盤における前記バッチジョブの実行結果と前記旧バッチ処理基盤における前記バッチジョブの実行結果とを比較することにより検証を実施する動作検証手段を備え、
   前記コンテナイメージ検証管理手段は、前記動作検証手段による検証結果に基づいて、コンテナイメージのバージョンアップが前記バッチジョブの実行結果に影響を与えたか否かを判断する、請求項２又は３に記載の検証装置。
5. 前記コンテナイメージ検証管理手段は、前記新バッチ処理基盤における前記バッチジョブの実行結果と前記旧バッチ処理基盤における前記バッチジョブの実行結果とに差異がある場合であっても、最終的なバッチジョブの実行結果に影響を及ぼさない結果であれば、前記バッチジョブの実行結果に影響はないと判断する、請求項４に記載の検証装置。
6. 現在利用しているバージョンのコンテナイメージを格納するコンテナイメージ保持手段をさらに備え、
   前記コンテナイメージ検証管理手段は、前記旧バッチ処理基盤向けの旧バージョンのコンテナイメージを前記コンテナイメージ保持手段から取得し、前記旧バージョンのコンテナイメージを用いて前記旧バッチ処理基盤を構築する、
   請求項２から５のいずれか１項に記載の検証装置。
7. 前記コンテナイメージ検証管理手段は、前記旧バッチ処理基盤向けの旧バージョンのコンテナイメージが前記コンテナイメージレジストリからダウンロードできない場合、前記旧バージョンより新しいバージョンのコンテナイメージをすべてダウンロードし、ダウンロードされたすべてのバージョンの検証を実施し、最も適したバージョンを選択する、請求項２から５のいずれか１項に記載の検証装置。
8. 外部に存在する脆弱性情報データベースを参照して、脆弱性情報を収集する脆弱性情報収集手段をさらに備え、
   前記コンテナイメージ検証管理手段は、前記新しいバージョンのコンテナイメージが、前記脆弱性情報データベースに登録された脆弱性を保持しているか否かの判断を行う、
   請求項１から７のいずれか１項に記載の検証装置。
9. 前記本番サーバの構築を行うシステム構成管理手段をさらに備え、
   前記コンテナイメージ検証管理手段は、前記監視検証手段による監視結果及び検証結果の少なくとも一方と、前記脆弱性情報収集手段による脆弱性情報の収集結果とに基づいて、利用するコンテナイメージのバージョンを前記新しいバージョンに更新するか否かの判断を行い、
   前記システム構成管理手段は、前記コンテナイメージ検証管理手段により前記新しいバージョンに更新すると判断された場合に、以降の前記本番サーバの構築について、前記新しいバージョンのコンテナイメージを用いて行う、
   請求項８に記載の検証装置。
10. 本番サーバに配備されているバッチジョブの実行前に、前記バッチジョブを解析して前記バッチジョブが利用するコンテナイメージを特定し、
    外部に存在するコンテナイメージレジストリを参照して、前記バッチジョブが利用するコンテナイメージのバージョン情報を収集し、
    前記バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、前記バッチジョブを検証用サーバにて実行し、
    前記検証用サーバにて実行される前記バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う、
    ことを含む検証方法。

Images