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

検証装置及び検証方法 Download PDF

Info

Publication number
JP6926879B2
JP6926879B2 JP2017179679A JP2017179679A JP6926879B2 JP 6926879 B2 JP6926879 B2 JP 6926879B2 JP 2017179679 A JP2017179679 A JP 2017179679A JP 2017179679 A JP2017179679 A JP 2017179679A JP 6926879 B2 JP6926879 B2 JP 6926879B2
Authority
JP
Japan
Prior art keywords
verification
container image
version
batch job
container
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017179679A
Other languages
English (en)
Other versions
JP2019056986A (ja
Inventor
岳大 渡邊
岳大 渡邊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Priority to JP2017179679A priority Critical patent/JP6926879B2/ja
Publication of JP2019056986A publication Critical patent/JP2019056986A/ja
Application granted granted Critical
Publication of JP6926879B2 publication Critical patent/JP6926879B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Description

本発明は、検証装置及び検証方法に関し、特に、コンテナ上でのバッチ処理実行に関するコンテナイメージのセキュリティ安全性を検証する検証装置及び検証方法に関する。
近年、Dockerをはじめとするコンテナ技術が広がりを見せており、エンタープライズシステムにおける導入実績も報告されている。従来から、ITシステムにおいて、開発面や運用面を効率化する解決策の1つとして仮想化が採用されてきたが、複数のOS(Operating System)を集約した場合の性能劣化等が問題視されてきた。一方、Dockerは、ゲストOSがカーネルや様々なリソースを共有するため、リソースを個別に保持するサーバ型仮想化と比較するとリソース消費量が少なく、軽量に動作することが特徴である。
コンテナは、コンテナイメージから生成される。システムによっては、連動して実行する複数のコンテナとして、一般公開されたコンテナイメージから生成されるコンテナを含む場合があり、セキュリティ面での安全性の確保が求められる。
続いて、バッチ処理について説明する。バッチ処理とは、コンピュータで1つの流れのプログラム群(ジョブ)を順番に実行することである。バッチ処理は、処理の内容があらかじめ決まっているという特徴を有する。バッチ処理では、あらかじめ定めた処理を夜間等にまとめて行う。バッチ処理は、コンテナの考え方である、必要な時に立ち上げて、不要になったら廃棄するという考え方と相性が良い。
続いて、バッチ処理をコンテナ上で行う場合のコンテナイメージのバージョンアップについて説明する。バッチ処理で利用するコンテナイメージのバージョンとして、特定のバージョンが指定されている場合、指定されたものより新しいバージョンがリリースされた際に、新しいバージョンの適用の可否を検討する必要がある。例えば、あるバージョンアップが既知の脆弱性に対応したものであるならば、新バージョンへの移行を検討すべきである。
また、反対に、バッチ処理で利用するコンテナイメージのバージョンとして、特定のバージョンが指定されておらず、「バッチ実行時の最新バージョン」という指定をされている場合がある。この場合、前回のジョブ実行と今回のジョブ実行の間に、あるコンテナイメージのバージョンアップが発生し、意図せず利用するコンテナイメージが変わってしまう可能性がある。これにより、システムにおける脆弱性の発生や、動作の変更が発生する可能性がある。
バッチ処理は、月次バッチや年次バッチ等、前回の実行から期間が開くものがある。このため、バッチ処理をコンテナ上で行う場合、バッチ処理実行時において、前回のバッチ処理実行時から、システムを構成するコンテナイメージのバージョンが更新されている可能性は比較的高い。そして、コンテナイメージのバージョンが更新されている場合には、そのバージョンの適用についての検討が必要となる。
バージョンアップ適用の検討の基準としては、バージョンアップによりセキュリティ強度が下がらないこと、バッチ処理の処理に影響を与えないこと等が挙げられる。これらの検討を行うためには、旧バージョンと新バージョンでの比較を行うことが必要となる。
特許文献1には、システムを構成するアプリケーションのバージョンアップを検出した場合、バージョンアップ前後のアプリケーションのセキュリティ脆弱性レートを算出して、その値によって、バージョンアップをするかどうかを決定する技術が開示されている。
特表2016−521896号公報
しかし、特許文献1に開示の技術では、システム上で動作するバッチ処理についての解析を行わないため、バージョンアップによる動作変更により、バッチ処理結果に影響を与える可能性があるという問題があった。
本発明は、このような問題点を解決するためになされたものであり、バッチ処理をコンテナ上で行う場合のコンテナイメージのバージョンアップの検証を適切に行うことができる検証装置及び検証方法を提供することを目的とする。
本発明の第1の態様にかかる検証装置は、本番サーバに配備されているバッチジョブの実行前に、前記バッチジョブを解析して前記バッチジョブが利用するコンテナイメージを特定するバッチジョブ解析手段と、外部に存在するコンテナイメージレジストリを参照して、前記バッチジョブが利用するコンテナイメージのバージョン情報を収集するコンテナイメージ情報収集手段と、前記バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、前記バッチジョブを検証用サーバにて実行するコンテナイメージ検証管理手段と、前記検証用サーバにて実行される前記バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う監視検証手段と、を備えるものである。
本発明の第2の態様にかかる検証方法は、本番サーバに配備されているバッチジョブの実行前に、前記バッチジョブを解析して前記バッチジョブが利用するコンテナイメージを特定し、外部に存在するコンテナイメージレジストリを参照して、前記バッチジョブが利用するコンテナイメージのバージョン情報を収集し、前記バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、前記バッチジョブを検証用サーバにて実行し、前記検証用サーバにて実行される前記バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う、ことを含むものである。
本発明により、バッチ処理をコンテナ上で行う場合のコンテナイメージのバージョンアップの検証を適切に行うことができる検証装置及び検証方法を提供することができる。
本発明の実施の形態1にかかる検証装置の構成例を示すブロック図である。 本発明の実施の形態1にかかる本番サーバの構成例を示すブロック図である。 本発明の実施の形態1にかかるバッチジョブ解析部によりリストアップされる情報の例を示す図である。 本発明の実施の形態1にかかるコンテナイメージ情報収集部により収集されるコンテナイメージの最新バージョンの例を示す図である。 本発明の実施の形態1にかかる検証用サーバの構成例を示すブロック図である。 本発明の実施の形態1にかかる監視検証部の構成例を示すブロック図である。 本発明の実施の形態1にかかる検証装置の処理例を示すフローチャートである。 本発明の実施の形態1にかかる検証装置におけるコンテナイメージ検証の有無を判断するための処理の流れを示すシーケンス図である。 本発明の実施の形態1にかかる検証装置における検証環境構築から実行結果の検証までの処理の流れを示すシーケンス図である。 本発明の実施の形態1の変形例にかかる検証装置の構成例を示すブロック図である。 本発明の実施の形態2にかかる検証装置の構成例を示すブロック図である。 本発明の実施の形態2の変形例にかかる検証装置の構成例を示すブロック図である。
以下では、本発明の実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
実施の形態1
まず、図1のブロック図を用いて、本発明の実施の形態1にかかる検証装置100の構成例について説明する。検証装置100は、本番サーバ110と、バッチジョブ解析部120と、コンテナイメージ情報収集部130と、コンテナイメージ検証管理部140と、検証用サーバ150と、監視検証部160と、を備えている。なお、図1には、コンテナイメージレジストリ200が示されているが、コンテナイメージレジストリ200は、検証装置100が備える構成ではなく、検証装置100の外部に存在するものである。
本番サーバ110は、検証用ではなく、実際にバッチジョブを実行するためのサーバである。本番サーバ110には、バッチジョブの実行に必要な各種コンテナが生成されている。なお、本番サーバ110に配備されているバッチジョブであって、解析の対象となるバッチジョブのことを第1バッチジョブとも呼ぶ。
本実施の形態1にかかる本番サーバ110の構成例を図2に示す。図2に示す例では、本番サーバ110には、コンテナA、コンテナB、コンテナC、コンテナDが生成されている。また、図2に示す例では、本番サーバ110に生成されているコンテナAは、バージョン1.0である。また、本番サーバ110に生成されているコンテナBは、バージョン1.0である。また、本番サーバ110に生成されているコンテナCは、バージョン2.5である。また、本番サーバ110に生成されているコンテナDは、バージョン1.5である。また、本番サーバ110に生成されているコンテナAからコンテナDは、それぞれ内部にバッチ処理基盤111を有し、バッチ処理基盤111に第1バッチジョブを配備している。
バッチジョブ解析部120は、本番サーバ110に配備されているバッチジョブの実行前に、当該バッチジョブを解析し、当該バッチジョブが利用するコンテナイメージを特定する。
具体的には、バッチジョブ解析部120は、コンテナイメージ検証管理部140から第1バッチジョブの解析依頼を受けた場合に、第1バッチジョブの解析を行い、第1バッチジョブの実行に利用するコンテナイメージ及び当該コンテナイメージの現在の利用バージョンをリストアップする。
本実施の形態1にかかるバッチジョブ解析部120によりリストアップされる情報の例を図3に示す。図3の例では、コンテナイメージAからコンテナイメージDがリストアップされている。また、コンテナイメージA、コンテナイメージB、コンテナイメージDは、それぞれ現在の利用バージョンとして、1.0、1.0、1.5が対応付けられている。これらのコンテナイメージは、明示的にバージョンを指定されてバッチジョブを実行されたものであることを意味する。また、コンテナイメージCは、現在の利用バージョンにlatest(2.5)と記載されているが、これは明示的なバージョン指定を行わず、「その時点での最新バージョン」という指定によりバッチジョブを実行されたものであることを意味する。そして、括弧内の2.5は、前回のバッチジョブ実行時に実際に利用したバージョンを、現在の利用バージョンとして格納している。
図1に戻り説明を続ける。コンテナイメージ情報収集部130は、外部に存在するコンテナイメージレジストリ200を参照して、バッチジョブが利用するコンテナイメージのバージョン情報を収集する。
具体的には、コンテナイメージ情報収集部130は、コンテナイメージ検証管理部140からのコンテナイメージ情報採取依頼を受けた場合に、採取依頼されたコンテナイメージの最新バージョンの情報を収集する。
本実施の形態1にかかるコンテナイメージ情報収集部130により収集されるコンテナイメージの最新バージョンの例を図4に示す。図4に示す例では、コンテナイメージA、コンテナイメージB、コンテナイメージC、コンテナイメージDの最新バージョンは、それぞれ、1.1、1.0、2.5、1.5である。
コンテナイメージ検証管理部140は、第1バッチジョブの解析依頼を、バッチジョブ解析部120へ出力する。また、コンテナイメージ検証管理部140は、リストアップされたコンテナイメージの情報を、バッチジョブ解析部120から受け取る。
また、コンテナイメージ検証管理部140は、リストアップされたコンテナイメージについて、コンテナイメージ情報採取依頼をコンテナイメージ情報収集部130へ出力する。また、コンテナイメージ検証管理部140は、リストアップされたコンテナイメージの最新バージョンの情報を、コンテナイメージ情報収集部130から受け取る。また、コンテナイメージ検証管理部140は、リストアップされたコンテナイメージの現在利用しているバージョンと最新バージョンとを比較する。そして、コンテナイメージ検証管理部140は、現在利用しているバージョンよりも新しいバージョンがリリースされているコンテナイメージがある場合に、コンテナイメージ検証を実施すると判断し、そうでなければコンテナイメージ検証を実施しないと判断する。
図3及び図4を参照すると、コンテナイメージAについて、現在の利用バージョン1.0よりも新しいバージョン1.1がリリースされている。このため、コンテナイメージ検証管理部140は、コンテナイメージ検証を実施すると判断する。
また、コンテナイメージ検証管理部140は、第1バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、第1バッチジョブを検証用サーバ150にて実行することにより、コンテナイメージ検証を実施する。
具体的には、コンテナイメージ検証管理部140は、検証用サーバ150に、新バッチ処理基盤151及び旧バッチ処理基盤152を構築する。なお、新バッチ処理基盤とは、新しいバージョンのコンテナイメージにより生成された新しいバージョンのコンテナを含むバッチ処理基盤である。また、旧バッチ処理基盤とは、本番サーバ110にて前回のバッチジョブを実行した時と同様の構成のバッチ処理基盤である。
本実施の形態1にかかる検証用サーバ150の構成例を図5に示す。検証用サーバ150には、コンテナAからコンテナDについて、最新バージョンのコンテナを含む新バッチ処理基盤151が構築されている。また、検証用サーバ150には、コンテナAからコンテナDについて、前回のバッチジョブを実行した際の利用バージョンのコンテナにより構成される旧バッチ処理基盤152が構築されている。なお、新バッチ処理基盤151向けの新バージョンのコンテナイメージ、すなわち、コンテナイメージAのバージョン1.1は、コンテナイメージレジストリ200からダウンロードされる。また、旧バッチ処理基盤152向けの旧バージョンのコンテナイメージについてもコンテナイメージレジストリ200からダウンロードされてもよいが、これに限らない。
また、コンテナイメージ検証管理部140は、新バッチ処理基盤151及び旧バッチ処理基盤152にて第1バッチジョブを実行する。そして、コンテナイメージ検証管理部140は、第1バッチジョブが起動すると、第1バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方の依頼を、監視検証部160へ出力する。
監視検証部160は、検証用サーバ150にて実行されるバッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う。
監視検証部160は、例えば、図6のように構成される。図6の例では、監視検証部160は、コンテナ監視部161と、動作検証部162と、を備えている。
コンテナ監視部161は、新バッチ処理基盤151及び旧バッチ処理基盤152における監視を実施する。具体的には、コンテナ監視部161は、コンテナイメージ検証管理部140から第1バッチジョブの監視を依頼された場合に、第1バッチジョブの開始から終了まで、新バッチ処理基盤151及び旧バッチ処理基盤152における監視を実施する。なお、コンテナ監視部161による監視対象は、例えば、CPU(Central Processing Unit)使用率、メモリ使用量、I/O(In/Out)状態等のパフォーマンス情報である。
そして、コンテナ監視部161は、監視結果をコンテナイメージ検証管理部140へ出力する。コンテナイメージ検証管理部140は、コンテナ監視部161から監視結果を受け取る。また、コンテナイメージ検証管理部140は、受け取った監視結果により、第1バッチジョブ実行時のパフォーマンス情報について、新バッチ処理基盤151と旧バッチ処理基盤152との比較を行う。そして、コンテナイメージ検証管理部140は、旧バッチ処理基盤152に比べて、新バッチ処理基盤151のパフォーマンス情報に異常や特殊な動きがあるか否かを判断する。「異常」の例としては、パフォーマンス情報として、CPU使用率、メモリ使用量、I/O状態に異常な増減が発生すること等である。また、「特殊な動き」の例としては、意図せず測定値が周期的に増減することや、特定のURL(Uniform Resource Locator)にデータを送出しようとする動作等である。コンテナイメージ検証管理部140は、新バッチ処理基盤151のパフォーマンス情報に異常や特殊な動きがあった場合には、新しいバージョンのコンテナにセキュリティ脆弱性があると判断する。
動作検証部162は、新バッチ処理基盤151におけるバッチジョブの実行結果と旧バッチ処理基盤152におけるバッチジョブの実行結果とを比較することにより検証を実施する。具体的には、動作検証部162は、コンテナイメージ検証管理部140から第1バッチジョブの実行結果の検証を依頼された場合に、新バッチ処理基盤151における第1バッチジョブの実行結果と旧バッチ処理基盤152における第1バッチジョブの実行結果とを比較する。
実行結果の比較について例を挙げて説明する。コンテナイメージのあるモジュールのある動作が、バージョンアップによって英字の大文字小文字を区別するようになったケースについて説明する。このケースでは、旧バッチ処理基盤152では、バッチジョブの実行により、すべて大文字でデータベースに書き込まれる。また、新バッチ処理基盤151では、バッチジョブの実行により、大文字小文字を区別してデータベースに書き込まれる。動作検証部162は、例えば、このデータベースに書き込まれる文字を比較することにより検証を実施する。
そして、動作検証部162は、検証結果をコンテナイメージ検証管理部140へ出力する。コンテナイメージ検証管理部140は、動作検証部162から検証結果を受け取る。また、コンテナイメージ検証管理部140は、受け取った検証結果に基づいて、コンテナイメージのバージョンアップがバッチジョブの実行結果に影響を与えたか否かを判断する。例えば、コンテナイメージ検証管理部140は、新バッチ処理基盤151における第1バッチジョブの実行結果が、旧バッチ処理基盤152における第1バッチジョブの実行結果とは異なる場合に、コンテナイメージのバージョンアップがバッチジョブの実行結果に影響を与えたと判断する。
続いて、図7のフローチャートを用いて、本実施の形態1にかかる検証装置100の処理例について説明する。
まず、検証装置100は、バッチジョブ解析部120により、本番サーバ110に配備されている第1バッチジョブの実行前に、第1バッチジョブを解析して第1バッチジョブが利用するコンテナイメージを特定する(ステップS101)。
次に、検証装置100は、コンテナイメージ情報収集部130により、外部に存在するコンテナイメージレジストリ200を参照して、第1バッチジョブが利用するコンテナイメージのバージョン情報を収集する(ステップS102)。
次に、検証装置100は、コンテナイメージ検証管理部140により、第1バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされているか否かを判断する(ステップS103)。
なお、ステップS101からS103までの処理のことを、コンテナイメージ検証の有無を判断するための処理とも呼ぶ。コンテナイメージ検証の有無を判断するための処理は、例えば、本番サーバ110での第1バッチジョブの実行予定時刻の所定時間前に実行される。
第1バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされていない場合(ステップS103にてNO)、処理を終了する。
他方、第1バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合(ステップS103にてYES)、検証装置100は、コンテナイメージ検証管理部140により、第1バッチジョブを検証用サーバ150にて実行する(ステップS104)。
次に、検証装置100は、監視検証部160により、検証用サーバ150にて実行される第1バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う(ステップS105)。
続いて、図8のシーケンス図を用いて、本実施の形態1にかかる検証装置100におけるコンテナイメージ検証の有無を判断するための処理の流れについて説明する。
まず、コンテナイメージ検証管理部140は、バッチジョブ解析依頼をバッチジョブ解析部120へ出力する(ステップS201)。
バッチジョブ解析部120は、バッチジョブ解析依頼を受けると、本番サーバ110に配備されている第1バッチジョブを解析し、第1バッチジョブの実行に利用するコンテナイメージをリストアップする(ステップS202)。そして、バッチジョブ解析部120は、リストアップされたコンテナイメージ情報を、コンテナイメージ検証管理部140へ出力する(ステップS203)。
次に、コンテナイメージ検証管理部140は、コンテナイメージ情報採取依頼を、コンテナイメージ情報収集部130へ出力する(ステップS204)。
コンテナイメージ情報収集部130は、コンテナイメージ情報採取依頼を受けると、コンテナイメージ検証管理部140から依頼されたコンテナイメージのバージョンの情報を収集する(ステップS205)。そして、コンテナイメージ情報収集部130は、コンテナイメージの最新バージョン情報をコンテナイメージ検証管理部140へ出力する(ステップS206)。
次に、コンテナイメージ検証管理部140は、コンテナイメージ検証の有無を判断する(ステップS207)。具体的には、コンテナイメージ検証管理部140は、リストアップされたコンテナイメージについて、現在利用しているバージョンと最新バージョンとを比較する。そして、コンテナイメージ検証管理部140は、現在利用しているバージョンよりも新しいバージョンがリリースされているコンテナイメージがある場合に、コンテナイメージ検証を実施すると判断し、そうでなければコンテナイメージ検証を実施しないと判断する。
続いて、図9のシーケンス図を用いて、本実施の形態1にかかる検証装置100における検証環境構築から実行結果の検証までの処理の流れについて説明する。
コンテナイメージ検証管理部140は、コンテナイメージ検証を実施すると判断すると、検証用サーバ150に必要なコンテナイメージをダウンロードする(ステップS301)。
次に、コンテナイメージ検証管理部140は、検証用サーバ150上に、ダウンロードしたコンテナイメージから新バッチ処理基盤151及び旧バッチ処理基盤152を構築する。
次に、コンテナイメージ検証管理部140は、検証用サーバ150にて第1バッチジョブを実行する(ステップS303)。
第1バッチジョブが起動すると、コンテナイメージ検証管理部140は、コンテナ監視依頼をコンテナ監視部161へ出力する(ステップS304)。
コンテナ監視部161は、コンテナ監視依頼を受けると、第1バッチジョブの開始から終了まで、新バッチ処理基盤151及び旧バッチ処理基盤152における監視を実施する(ステップS305)。そして、コンテナ監視部161は、監視結果をコンテナイメージ検証管理部140へ出力する(ステップS306)。
コンテナイメージ検証管理部140は、監視結果を受けて、パフォーマンス情報に異常や特殊な動きがあるか否かを判断する(ステップS307)。
次に、コンテナイメージ検証管理部140は、第1バッチジョブの実行結果の検証を、動作検証部162へ依頼する(ステップS308)。
動作検証部162は、検証依頼を受けて、新バッチ処理基盤151における第1バッチジョブの実行結果と旧バッチ処理基盤152における第1バッチジョブの実行結果とを比較することにより検証を実施する(ステップS309)。そして、動作検証部162は、検証結果をコンテナイメージ検証管理部140へ出力する(ステップS310)。
コンテナイメージ検証管理部140は、検証結果を受けて、コンテナイメージのバージョンアップが、バッチジョブの実行結果に影響を与えたか否かを判断する(ステップS311)。
以上のように、本発明の実施の形態1にかかる検証装置100は、本番サーバ110に配備されている第1バッチジョブの実行前に、第1バッチジョブを解析して第1バッチジョブが利用するコンテナイメージを特定するバッチジョブ解析部120を備える構成としている。また、検証装置100は、外部に存在するコンテナイメージレジストリ200を参照して、第1バッチジョブが利用するコンテナイメージのバージョン情報を収集するコンテナイメージ情報収集部130を備える構成としている。また、検証装置100は、第1バッチジョブが利用するコンテナイメージの新しいバージョンがリリースされている場合に、第1バッチジョブを検証用サーバ150にて実行するコンテナイメージ検証管理部140を備える構成としている。さらに、検証装置100は、検証用サーバ150にて実行される第1バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う監視検証部160を備える構成としている。すなわち、検証装置100では、本番サーバ110に配備されている第1バッチジョブについて、そのコンテナイメージの新しいバージョンがリリースされている場合に、第1バッチジョブを検証用サーバ150にて実行し、検証用サーバ150にて実行される第1バッチジョブの実行中のパフォーマンス情報の監視及び実行結果の検証の少なくとも一方を行う構成としている。これにより、本実施の形態1にかかる検証装置100では、システム上で動作する第1バッチジョブについての検証を検証用サーバ150にて行うことができ、コンテナイメージのバージョンアップによる動作変更による影響を検証することができる。すなわち、本実施の形態1にかかる検証装置100では、バッチ処理をコンテナ上で行う場合のコンテナイメージのバージョンアップの検証を適切に行うことができる。
また、本実施の形態1にかかる検証装置100では、コンテナイメージ検証管理部140が、第1バッチジョブを検証用サーバ150にて実行する際に、新しいバージョンのコンテナを含む新バッチ処理基盤151と、前回のバッチジョブを実行した際の利用バージョンのコンテナにより構成される旧バッチ処理基盤152とを検証用サーバ150に構築する構成としている。また、検証装置100では、コンテナイメージ検証管理部140が、新バッチ処理基盤151及び旧バッチ処理基盤152にて第1バッチジョブを実行する構成としている。これにより、本実施の形態1にかかる検証装置100では、検証用サーバ150において、新しいバージョンのコンテナ及び前回のバッチジョブを実行した際の利用バージョンのコンテナを用いて、バッチジョブの検証を行うことができる。
また、本実施の形態1にかかる検証装置100では、監視検証部160が、新バッチ処理基盤151及び旧バッチ処理基盤152における監視を実施するコンテナ監視部161を備える構成としている。また、検証装置100では、コンテナイメージ検証管理部140が、コンテナ監視部161による監視結果に基づいて、新しいバージョンのコンテナにセキュリティ脆弱性があるか否かを判断する構成としている。これにより、本実施の形態1にかかる検証装置100では、検証用サーバ150におけるバッチジョブ実行中の新バッチ処理基盤151及び旧バッチ処理基盤152における監視により、新しいバージョンのコンテナにセキュリティ脆弱性があるか否かを判断することができる。
また、本実施の形態1にかかる検証装置100では、監視検証部160が、新バッチ処理基盤151における第1バッチジョブの実行結果と旧バッチ処理基盤152における第1バッチジョブの実行結果とを比較することにより検証を実施する動作検証部162を備える構成としている。また、検証装置100では、コンテナイメージ検証管理部140が、動作検証部162による検証結果に基づいて、コンテナイメージのバージョンアップが第1バッチジョブの実行結果に影響を与えたか否かを判断する構成としている。これにより、本実施の形態1にかかる検証装置100では、検証用サーバ150におけるバッチジョブの実行により、コンテナイメージのバージョンアップが、バッチジョブの実行結果に影響を与えたか否かを判断することができる。
実施の形態1の変形例
続いて、図10のブロック図を用いて、本発明の実施の形態1の変形例にかかる検証装置100Aの構成例について説明する。検証装置100Aは、本番サーバ110と、バッチジョブ解析部120と、コンテナイメージ情報収集部130と、コンテナイメージ検証管理部140Aと、検証用サーバ150と、監視検証部160と、脆弱性情報収集部170と、システム構成管理部180と、を備えている。なお、図10には、脆弱性情報データベース300が示されているが、脆弱性情報データベース300は、検証装置100Aが備える構成ではなく、検証装置100Aの外部に存在するものである。
脆弱性情報収集部170は、外部に存在する脆弱性情報データベース300を参照して、各種の脆弱性情報を収集する。例えば、脆弱性情報収集部170は、コンテナイメージ検証管理部140Aから問い合わせを受けると、脆弱性情報データベース300を参照して、脆弱性情報を収集する。そして、脆弱性情報収集部170は、脆弱性情報の収集結果をコンテナイメージ検証管理部140Aへ出力する。
コンテナイメージ検証管理部140Aは、実施の形態1のコンテナイメージ検証管理部140の機能に加えて、以下に説明する機能も備えるものである。
コンテナイメージ検証管理部140Aは、コンテナイメージ検証を実施すると判断した場合に、バッチジョブで利用する新しいバージョンのコンテナイメージについての脆弱性情報の問い合わせを、脆弱性情報データベース300に出力する。また、コンテナイメージ検証管理部140Aは、問い合わせに対する脆弱性情報の収集結果を、脆弱性情報収集部170から受け取る。そして、コンテナイメージ検証管理部140Aは、バッチジョブで利用する新しいバージョンのコンテナイメージが、脆弱性情報データベース300に登録された脆弱性を保持しているか否かの判断を行う。
また、コンテナイメージ検証管理部140Aは、監視検証部160による監視結果及び検証結果の少なくとも一方と、脆弱性情報収集部170による脆弱性情報の収集結果とに基づいて、利用するコンテナイメージのバージョンを新しいバージョンに更新するか否かの判断を行う。具体的には、コンテナイメージ検証管理部140Aは、新しいバージョンのコンテナイメージが、脆弱性情報データベース300に登録されておらず、新バッチ処理基盤151のパフォーマンス情報に異常や特殊な動きがなく、且つコンテナイメージのバージョンアップがバッチジョブの実行結果に影響を与えないと判断した場合に、利用するコンテナイメージのバージョンを新しいバージョンに更新すると判断する。
コンテナイメージ検証管理部140Aは、利用するコンテナイメージのバージョンを新しいバージョンに更新すると判断した場合に、バージョン更新情報をシステム構成管理部180へ出力する。
システム構成管理部180は、本番サーバ110の構築を行う機能部である。システム構成管理部180は、コンテナイメージ検証管理部140Aからバージョン更新情報を受けると、以降の本番サーバ110の構築について、コンテナイメージの新しいバージョンを採用して行う。
以上のように、本発明の実施の形態1の変形例にかかる検証装置100Aは、外部に存在する脆弱性情報データベース300を参照して、脆弱性情報を収集する脆弱性情報収集部170をさらに備える構成としている。また、検証装置100Aでは、コンテナイメージ検証管理部140Aにより、新しいバージョンのコンテナイメージが、脆弱性情報データベース300に登録された脆弱性を保持しているか否かの判断を行う構成としている。これにより、本実施の形態1の変形例にかかる検証装置100Aでは、新しいバージョンのコンテナイメージが、脆弱性情報データベース300に登録された脆弱性を保持していないかどうかの検証を行うことができる。
また、本実施の形態1の変形例にかかる検証装置100Aは、本番サーバ110の構築を行うシステム構成管理部180をさらに備える構成としている。また、検証装置100Aでは、コンテナイメージ検証管理部140Aが、監視検証部160による監視結果及び検証結果の少なくとも一方と、脆弱性情報収集部170による脆弱性情報の収集結果とに基づいて、利用するコンテナイメージのバージョンを新しいバージョンに更新するか否かの判断を行う構成としている。さらに、検証装置100Aでは、システム構成管理部180が、コンテナイメージ検証管理部140Aにより新しいバージョンに更新すると判断された場合に、以降の本番サーバ110の構築について、新しいバージョンのコンテナイメージを用いて行う構成としている。これにより、本実施の形態1の変形例にかかる検証装置100Aでは、新しいバージョンについて脆弱性やバージョンアップによる実行結果への影響がない場合に、新しいバージョンのコンテナイメージを用いて本番サーバ110の構築を行うことができる。
実施の形態2
続いて、図11のブロック図を用いて、本発明の実施の形態2にかかる検証装置100Bの構成例について説明する。検証装置100Bは、本番サーバ110と、バッチジョブ解析部120と、コンテナイメージ情報収集部130と、コンテナイメージ検証管理部140Bと、検証用サーバ150と、監視検証部160と、脆弱性情報収集部170と、システム構成管理部180と、コンテナイメージ保持部190と、を備えている。
コンテナイメージ保持部190は、本番サーバ110のバッチ処理基盤111に含まれるコンテナについて、現在利用しているバージョンのコンテナイメージを格納する。
前提として、コンテナ利用に際して、「必要な時だけコンテナを起動し、不要になったら破棄する」という考え方があるため、バッチジョブが終わると、不要なコンテナを削除するという運用が行われる。このため、前回のバッチジョブ実行時と今回のバッチジョブ実行との間にバージョンアップが発生した場合に、前回のバッチジョブ実行時のバッチ処理基盤111を構成するコンテナイメージがコンテナイメージレジストリ200から削除されている可能性がある。このような場合には、旧バージョンのコンテナ環境を再現できなくなる。すなわち、旧バッチ処理基盤152を構築することができなくなり、新バッチ処理基盤151と旧バッチ処理基盤152との比較をすることができない。このため、新しいバージョンのコンテナイメージの正当性を検証することができないという問題が生じる。コンテナイメージ保持部190に、本番サーバ110のバッチ処理基盤111に含まれるコンテナについての現在利用しているバージョンのコンテナイメージを格納することにより、この問題を解消することができる。
コンテナイメージ検証管理部140Bは、旧バッチ処理基盤152向けの旧バージョンのコンテナイメージをコンテナイメージ保持部190から取得する。
具体的には、コンテナイメージ検証管理部140Bは、旧バッチ処理基盤152を構築する際に、旧バッチ処理基盤152向けの旧バージョンのコンテナイメージがコンテナイメージレジストリ200からダウンロードできない場合、旧バージョンのコンテナイメージをコンテナイメージ保持部190から取得する。
そして、コンテナイメージ検証管理部140Bは、コンテナイメージ保持部190から取得された旧バージョンのコンテナイメージを用いて旧バッチ処理基盤152を構築する。
以上のように、本発明の実施の形態2にかかる検証装置100Bは、現在利用しているバージョンのコンテナイメージを格納するコンテナイメージ保持部190をさらに備える構成としている。また、検証装置100Bでは、コンテナイメージ検証管理部140Bが、旧バッチ処理基盤152向けの旧バージョンのコンテナイメージをコンテナイメージ保持部190から取得する構成としている。さらに、検証装置100Bでは、コンテナイメージ検証管理部140Bが、コンテナイメージ保持部190から取得された旧バージョンのコンテナイメージを用いて旧バッチ処理基盤152を構築する構成としている。これにより、本実施の形態2にかかる検証装置100Bでは、前回のバッチジョブ実行時のバッチ処理基盤111を構成する旧バージョンのコンテナイメージがコンテナイメージレジストリ200から削除されている場合であっても、検証用サーバ150に旧バージョンのコンテナ環境を構築することができる。
実施の形態2の変形例
続いて、図12のブロック図を用いて、本発明の実施の形態2の変形例にかかる検証装置100Cの構成例について説明する。検証装置100Cは、本番サーバ110と、バッチジョブ解析部120と、コンテナイメージ情報収集部130と、コンテナイメージ検証管理部140Cと、検証用サーバ150と、監視検証部160と、脆弱性情報収集部170と、システム構成管理部180と、を備えている。
検証装置100Cは、実施の形態2の検証装置100Bが備えているコンテナイメージ保持部190を備えていない。検証装置100Cでは、前回のバッチジョブ実行時のバッチ処理基盤111を構成する旧バージョンのコンテナイメージがコンテナイメージレジストリ200から削除されている場合の対処を、コンテナイメージ検証管理部140Cの処理により行う。すなわち、実施の形態2の変形例では、前回のバッチジョブ実行時の旧バージョンのコンテナイメージが存在しないため、旧バージョンからバージョンアップせざるを得ないという状況である。このため、コンテナイメージ検証管理部140Cは、旧バージョンより新しいバージョンのうち、どのバージョンにバージョンアップするかを選択する処理を行う。
コンテナイメージ検証管理部140Cは、旧バッチ処理基盤152向けの旧バージョンのコンテナイメージがコンテナイメージレジストリ200からダウンロードできない場合、当該コンテナイメージについて、前回のバッチジョブ実行時の旧バージョンより新しいバージョンをすべてダウンロードする。そして、コンテナイメージ検証管理部140Cは、ダウンロードされたすべてのバージョンの検証を実施し、最も適したバージョンを選択する。
なお、最も適したバージョンの選択は、監視検証部160による監視結果及び検証結果の少なくとも一方と、脆弱性情報収集部170による脆弱性情報の収集結果とに基づいて行われる。
以上のように、本発明の実施の形態2の変形例にかかる検証装置100Cでは、コンテナイメージ検証管理部140Cが、旧バッチ処理基盤152向けの旧バージョンのコンテナイメージがコンテナイメージレジストリ200からダウンロードできない場合、当該コンテナイメージについて、前回のバッチジョブ実行時の旧バージョンより新しいバージョンをすべてダウンロードする構成としている。また、検証装置100Cでは、コンテナイメージ検証管理部140Cが、ダウンロードされたすべてのバージョンの検証を実施し、最も適したバージョンを選択する構成としている。これにより、本実施の形態2の変形例にかかる検証装置100Cでは、前回のバッチジョブ実行時のバッチ処理基盤111を構成する旧バージョンのコンテナイメージがコンテナイメージレジストリ200から削除されている場合であっても、現在利用できるバージョンの中からバッチジョブの実行に影響を与えない、且つ最もセキュリティ強度が高いバージョンを検出することができる。
なお、上述した実施の形態では、動作検証部162によるバッチジョブの実行結果の比較について、新バッチ処理基盤151における実行結果が、旧バッチ処理基盤152における実行結果とは異なる場合に、その内容を考慮せずに影響ありと判定することについて説明したが、これに限らない。動作検証部162によるバッチジョブの実行結果が異なる場合であっても、最終的なバッチジョブの実行結果に影響を及ぼさない結果であれば、バッチジョブの実行結果に影響はないと判断してもよい。この場合、バッチジョブ解析部120により取得されるバッチジョブ情報を利用することにより、バッチジョブの全体の処理内容を把握し、その処理内容に応じて、実行結果が異なる場合であっても許容するようにしてもよい。
ここで、実施の形態1において説明した、コンテナイメージのあるモジュールのある動作が、バージョンアップによって英字の大文字小文字を区別するようになったケースを、再び例にとって説明する。
今回の例では第1バッチジョブが、処理Aとそれに続けて実行される処理Bからなるものとする。処理Aの実行結果としては、旧バージョンでは、すべて大文字で書き込まれ、新バージョンでは、大文字小文字を区別して書き込まれるものとする。上述の実施の形態では、この時点で、新バージョンはバッチジョブに影響ありと判断し、バージョンアップを行わない。
ここで、処理Bは、処理Aの結果を入力とするが、その英字の大文字小文字を無視して処理を実行するものとする。この場合、処理Aの新旧バージョンによる差異は、処理Bで無効化され、最終的なバッチジョブの実行結果には影響を及ぼさない。このため、コンテナイメージ検証管理部は、新バージョンはバッチジョブに影響を及ぼさない、という判断を行うようにしてもよい。
なお、上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、検証装置が備えるCPU等のプロセッサに、上述した各処理を行うためのコンピュータ・プログラムを実行させることにより実現することも可能である。
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、DVD(Digital Versatile Disc)、BD(Blu-ray(登録商標) Disc)、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施の形態によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
100、100A、100B、100C 検証装置
110 本番サーバ
111 バッチ処理基盤
120 バッチジョブ解析部
130 コンテナイメージ情報収集部
140、140A、140B、140C コンテナイメージ検証管理部
150 検証用サーバ
151 新バッチ処理基盤
152 旧バッチ処理基盤
160 監視検証部
161 コンテナ監視部
162 動作検証部
170 脆弱性情報収集部
180 システム構成管理部
190 コンテナイメージ保持部
200 コンテナイメージレジストリ
300 脆弱性情報データベース

Claims (10)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017179679A JP6926879B2 (ja) 2017-09-20 2017-09-20 検証装置及び検証方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017179679A JP6926879B2 (ja) 2017-09-20 2017-09-20 検証装置及び検証方法

Publications (2)

Publication Number Publication Date
JP2019056986A JP2019056986A (ja) 2019-04-11
JP6926879B2 true JP6926879B2 (ja) 2021-08-25

Family

ID=66107424

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017179679A Active JP6926879B2 (ja) 2017-09-20 2017-09-20 検証装置及び検証方法

Country Status (1)

Country Link
JP (1) JP6926879B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110069921B (zh) * 2019-04-12 2021-01-01 中国科学院信息工程研究所 一种面向容器平台的可信软件授权验证系统及方法
JP7340585B2 (ja) 2021-12-14 2023-09-07 株式会社日立製作所 脆弱性管理システム、及び脆弱性管理方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4978061B2 (ja) * 2006-05-31 2012-07-18 富士通株式会社 ソフトウェア更新要否判定方法
JP4907309B2 (ja) * 2006-11-22 2012-03-28 日立コンピュータ機器株式会社 シェルプログラム配信システム及び同配信プログラム
JP2009245380A (ja) * 2008-03-31 2009-10-22 Nomura Research Institute Ltd ジョブ処理システムおよびジョブテスト方法
JP5703195B2 (ja) * 2011-11-15 2015-04-15 株式会社日本総合研究所 プログラムの新旧バージョンに対する差分比較テストシステム及びテスト方法
US9594665B2 (en) * 2014-03-05 2017-03-14 Microsoft Technology Licensing, Llc Regression evaluation using behavior models of software applications
JP2016058006A (ja) * 2014-09-12 2016-04-21 富士ゼロックス株式会社 情報処理装置及びプログラム

Also Published As

Publication number Publication date
JP2019056986A (ja) 2019-04-11

Similar Documents

Publication Publication Date Title
US10324708B2 (en) Managing updates to container images
US10001990B2 (en) Method and system for enhancing application container and host operating system security in a multi-tenant computing environment
US10079719B2 (en) Automatically tuning middleware in a mobilefirst platform running in a docker container infrastructure
CN109117169B (zh) 用于修复内核漏洞的方法和装置
EP2210183B1 (en) Managing updates to create a virtual machine facsimile
US10885201B2 (en) Apparatus for quantifying security of open-source software package, and apparatus and method for optimizing open-source software package
WO2020157607A1 (en) Patch management in a hybrid computing environment
US8627469B1 (en) Systems and methods for using acquisitional contexts to prevent false-positive malware classifications
US9038059B2 (en) Automatically targeting application modules to individual machines and application framework runtimes instances
US9235491B2 (en) Systems and methods for installing, managing, and provisioning applications
US10521325B2 (en) Managing configuration drift
CN109800005B (zh) 一种客户端热更新方法及装置
US20090204946A1 (en) Intelligent software code updater
CN108255708B (zh) 测试环境中访问生产文件的方法、装置、存储介质及设备
US9317269B2 (en) Systems and methods for installing, managing, and provisioning applications
US10372572B1 (en) Prediction model testing framework
JP6926879B2 (ja) 検証装置及び検証方法
US11769067B2 (en) Topology-based migration assessment
US10432548B2 (en) Workload deployment in computing networks
US8949824B2 (en) Systems and methods for installing, managing, and provisioning applications
US20220318129A1 (en) Automated code checking
US10445213B2 (en) Non-transitory computer-readable storage medium, evaluation method, and evaluation device
US20220229689A1 (en) Virtualization platform control device, virtualization platform control method, and virtualization platform control program
US9317273B2 (en) Information processing apparatus and information processing method
US9730038B2 (en) Techniques to manage platform migrations

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200817

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210609

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210706

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210719

R150 Certificate of patent or registration of utility model

Ref document number: 6926879

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150