IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社日立製作所の特許一覧

特開2023-183886ストレージシステム及び不正アクセス検知方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023183886
(43)【公開日】2023-12-28
(54)【発明の名称】ストレージシステム及び不正アクセス検知方法
(51)【国際特許分類】
   G06F 3/06 20060101AFI20231221BHJP
【FI】
G06F3/06 304N
【審査請求】有
【請求項の数】14
【出願形態】OL
(21)【出願番号】P 2022097680
(22)【出願日】2022-06-16
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110001689
【氏名又は名称】青稜弁理士法人
(72)【発明者】
【氏名】許 莎彬
(72)【発明者】
【氏名】小林 正和
(72)【発明者】
【氏名】宮澤 彰人
(57)【要約】
【課題】クライアントOSがコントロールできなくなった場合においてもストレージレイヤでランサムウェアによるデータ暗号化に至る前段階のデータ窃取時の不正アクセスを検知できるストレージシステム及び不正アクセス検知方法を提供する。
【解決手段】ストレージシステムのコントローラは、第1パラメータが第1閾値パラメータより小さいことを、異常ふるまいとして検知する第1異常ふるまい検知処理、第2パラメータが第2閾値パラメータより大きいことを、異常ふるまいとして検知する第2異常ふるまい検知処理、及び、第3パラメータが第3閾値パラメータより小さいことを、異常ふるまいとして検知する第3異常ふるまい検知処理の少なくとも一つを含む異常ふるまい検知処理を実行する。
【選択図】図1
【特許請求の範囲】
【請求項1】
コントローラとデータをキャッシュするキャッシュとを含み、複数のボリュームを1又は複数の計算機に提供するストレージシステムであって、
前記コントローラは、
所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第1パラメータを取得し、前記第1パラメータが第1閾値パラメータより小さいことを、異常ふるまいとして検知する第1異常ふるまい検知処理、
所定のサンプリング間隔内の前記ボリュームに関連するサーバのサーバキャッシュ占用率に基づく第2パラメータを取得し、前記第2パラメータが第2閾値パラメータより大きいことを、異常ふるまいとして検知する第2異常ふるまい検知処理、及び、
所定のサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第3パラメータを取得し、前記第3パラメータが第3閾値パラメータより小さいことを、異常ふるまいとして検知する第3異常ふるまい検知処理、
の少なくとも一つを含む異常ふるまい検知処理を実行する、
ように構成された、
ストレージシステム。
【請求項2】
請求項1に記載のストレージシステムにおいて、
前記コントローラは、
前記第1異常ふるまい検知処理、前記第2異常ふるまい検知処理及び前記第3異常ふるまい検知処理の全てを含む前記異常ふるまい検知処理を実行する、
ように構成された、
ストレージシステム。
【請求項3】
請求項2に記載のストレージシステムにおいて、
前記コントローラは、
前記異常ふるまい検知処理によって、前記異常ふるまいを検知した場合に、前記異常ふるまいが前記ランサムウェアに起因するふるまいであるか否かを判定するランサムウェア判定を行い、
前記ランサムウェア判定として、
前記第1異常ふるまい検知処理及び前記第2異常ふるまい検知処理の少なくとも一つによって前記異常ふるまいを検知した前記ボリューム以外の他のボリュームのふるまいに基づいて、前記異常ふるまいが前記ランサムウェアに起因するふるまいであるか否かを判定し、
前記ランサムウェア判定によって、前記異常ふるまいが前記ランサムウェアに起因するふるまいであると判定した場合、前記異常ふるまいを前記ランサムウェアによる不正なデータアクセスとして検知する、
ように構成されたストレージシステム。
【請求項4】
請求項3に記載のストレージシステムにおいて、
前記コントローラは、
前記ランサムウェア判定として、
前記第1異常ふるまい検知処理によって、前記異常ふるまいを検知した場合、前記異常ふるまいを検知した前記ボリュームが割り当てられた前記計算機を特定し、特定した前記計算機に割り当てられた、同様の前記異常ふるまいがある、前記異常ふるまいを検知した前記ボリューム以外の他のボリュームが存在するか否かを判定する第1判定を行い、
前記第1判定によって、同様の前記異常ふるまいがある前記他のボリュームが存在すると判定した場合に、前記異常ふるまいを検知した前記ボリューム及び前記他のボリュームのIOPSが所定の閾値IOPSより大きいか否かを判定する第2判定を行い、
前記第2判定によって、前記異常ふるまいを検知した前記ボリューム及び前記他のボリュームのIOPSが所定の閾値IOPSより大きいと判定した場合、前記異常ふるまいを検知した前記ボリューム及び前記他のボリュームの中に、前記異常ふるまいが解消されたボリュームが存在するか否かを判定する第3判定を行い、
前記第3判定によって、前記異常ふるまいが解消されたボリュームが存在しないと判定した場合、
前記異常ふるまいを前記ランサムウェアによる不正なデータアクセスとして検知する、
ように構成された、
ストレージシステム。
【請求項5】
請求項4に記載のストレージシステムにおいて、
前記コントローラは、
前記第3判定によって、前記異常ふるまいを検知した前記ボリューム及び前記他のボリュームの中に、前記異常ふるまいが解消されたボリュームが存在すると判定した場合、
特定した前記計算機以外にストレージシステムを使用している他の計算機が存在するか否かを判定する第4判定を行い、
前記第4判定によって、特定した前記計算機以外にストレージシステムを使用している他の計算機が存在する場合、前記他の計算機に割り当てられた前記ボリュームも、同様の前記異常ふるまいが生じているか否かを判定する第5判定を行い、
前記第5判定によって、前記他の計算機に割り当てられた前記ボリュームも、同様の前記異常ふるまいが生じていると判定した場合、前記異常ふるまいを前記ランサムウェアによる不正なデータアクセスとして検知する、
ように構成された、
ストレージシステム。
【請求項6】
請求項3に記載のストレージシステムにおいて、
前記コントローラは、
前記ランサムウェア判定として、
前記第1異常ふるまい検知処理によって、前記異常ふるまいを検知した場合、前記異常ふるまいを検知した前記ボリュームが割り当てられた前記計算機を特定し、特定した前記計算機以外の他の計算機のボリュームのデータアクセス速度に基づく前記第3パラメータが前記第3閾値パラメータより小さいと判定した場合、前記異常ふるまいを前記ランサムウェアによる不正なデータアクセスとして検知する、
ように構成された、
ストレージシステム。
【請求項7】
請求項1に記載のストレージシステムにおいて、
前記コントローラは、
前記ボリュームのキャッシュヒット率、前ボリュームのキャッシュ占用率及び前記ボリュームのデータアクセス速度を含む過去データを取得し、前記過去データに基づいて、前記第1閾値パラメータ、前記第2閾値パラメータの計算用パラメータ及び前記第3閾値パラメータを更新する、閾値フィードバック処理を実行する、
ように構成された、
ストレージシステム。
【請求項8】
請求項7に記載のストレージシステムにおいて、
前記コントローラは、
前記過去データについて、監視間隔毎にサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第1パラメータを取得し、取得した前記第1パラメータの最小値を前記第1閾値パラメータとし、
前記過去データについて、監視間隔毎にサンプリング間隔内の前記ボリュームのキャッシュ占用率に基づく前記第2パラメータの計算用パラメータを取得し、取得した前記第2パラメータ計算用のパラメータの最大値を前記第2閾値パラメータの計算用パラメータとし、
前記過去データについて、監視間隔毎にサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第3パラメータを取得し、取得した前記第3パラメータの最小値を前記第3閾値パラメータとする、
ように構成された、
ストレージシステム。
【請求項9】
請求項8に記載のストレージシステムにおいて、
前記コントローラは、
前記過去データに基づいて、第1時点と、前記第1時点と同様のデータ変化傾向を示す第2時点との間の期間を前記監視間隔として設定する、監視間隔フィードバック処理を実行する、
ように構成された、
ストレージシステム。
【請求項10】
請求項1に記載のストレージシステムにおいて、
前記コントローラは、
前記所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率の傾き、面積又は平均値を前記第1パラメータとして算出し、
前記所定のサンプリング間隔内の前記ボリュームのキャッシュ占用率の傾き、面積又は平均値を前記第2パラメータの計算用パラメータとして算出し、
前記所定のサンプリング間隔内の前記ボリュームのデータアクセス速度の傾き、面積又は平均値を前記第3パラメータとして算出する、
ように構成された、
ストレージシステム。
【請求項11】
請求項3に記載のストレージシステムにおいて、
前記コントローラは、
前記異常ふるまいを、前記ランサムウェアによる不正なデータアクセスとして検知した場合、不正なデータアクセスに対応するための不正アクセス対応処理を実行する、
ように構成された、
ストレージシステム。
【請求項12】
請求項11に記載のストレージシステムにおいて、
前記コントローラは、
前記不正アクセス対応処理として、
不正なデータアクセスがあった計算機を特定し、特定した前記計算機の前記ボリュームへのパスを切断する処理を行う、
ように構成された、
ストレージシステム。
【請求項13】
請求項11に記載のストレージシステムにおいて、
前記コントローラは、
前記不正アクセス対応処理として、
ユーザの端末に不正なデータアクセスがあった旨を通知する通知処理と、
前記計算機へ転送するデータの転送量を減少させる処理及びストレージシステム内のデータの転送速度を低下させる処理の少なくとも一つの処理と、
を行う、
ように構成された、
ストレージシステム。
【請求項14】
コントローラとデータをキャッシュするキャッシュとを含み、複数のボリュームを1又は複数の計算機に提供するストレージシステムにおける不正アクセス検知方法であって、
前記コントローラによって、
所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第1パラメータを取得し、前記第1パラメータが第1閾値パラメータより小さいことを、異常ふるまいとして検知する第1異常ふるまい検知、
所定のサンプリング間隔内の前記ボリュームに関連するサーバのサーバキャッシュ占用率に基づく第2パラメータを取得し、前記第2パラメータが第2閾値パラメータより大きいことを、異常ふるまいとして検知する第2異常ふるまい検知、及び、
所定のサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第3パラメータを取得し、前記第3パラメータが第3閾値パラメータより小さいことを、異常ふるまいとして検知する第3異常ふるまい検知、
の少なくとも一つを含む異常ふるまい検知を実行する、
不正アクセス検知方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ストレージシステム及び不正アクセス検知方法に関する。
【背景技術】
【0002】
従来のランサムウェアによるサイバー攻撃は、データを暗号化し、利用不能とさせ、復元のための身代金を要求するものだった。このようなランサムウェアであれば、暗号化前にバックアップを取得することで、身代金を支払う必要なく復旧可能となる。
【0003】
一方、近年のランサムウェアは、従来の手法に加え、データを暗号化する前に、あらかじめデータ窃取を行い、窃取したデータを公開すると脅迫し、さらに身代金を要求するという2重脅迫を行う傾向にある。このようなランサムウェアを対策するために、データ窃取される段階での早期検知が必要となる。
【0004】
本発明に関連する技術としては、特許文献1及び特許文献2が開示する従来技術がある。特許文献1は、コンピュータにより実行されるランサムウェア検知方法を開示する。このランサムウェア検知方法は、ファイル・アクセス・ログを定期的に監視する。ランサムウェア検知方法は、許可されたファイル・アクセスのレコードのうち、ランサムウェアが典型的に行なうファイル・アクセスの頻度が所定の閾値を超えた場合には、ランサムウェアによる攻撃の可能性があると判定し、対策を取る。対策には、ファイル・アクセス制御手段に指令を送り、ファイル・アクセスを遮断することが含まれる。
【0005】
特許文献2は、ホストに提供される第1のボリュームと、第1のボリュームのバックアップデータまたはスナップショットイメージを格納する第2のボリュームとがあるストレージシステムを開示する。
【0006】
ストレージシステムのコントローラは、第1のボリュームにおけるバックアップデータまたはスナップショットイメージを所定の間隔で定期的に取得し、第1のボリュームにおけるホストのアクセス情報とボリューム使用容量とを含む監視情報を取得する。コントローラは、取得した監視情報を用い第1のボリュームにおける通常使用における定常状態を設定し、設定した定常状態から逸脱したボリュームにおけるアクセス挙動を検知する。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】国際公開第2019/073720号
【特許文献2】特開2020-201703号公報
【発明の概要】
【発明が解決しようとする課題】
【0008】
従来技術(特許文献1)では、ランサムウェアによる不正アクセスによって、クライアントOS上のセキュリティ対策ソフト、プログラム及びログ生成が不正に停止される場合、ランサムウェアを検知できなくなることが生じ得る。
【0009】
従来技術(特許文献2)は、不正なデータ暗号化を検知する技術であって、ストレージシステム(ストレージレイヤ)でデータ窃取時の不正アクセスを検知することができないため、近年のランサムウェアの動向である不正なデータ暗号化の前に実行されるデータ窃取に対応できない。
【0010】
本発明は上記課題を解決するためになされた。即ち、本発明の目的の一つは、クライアントOSがコントロールできなくなった場合においてもストレージレイヤでランサムウェアによるデータ暗号化に至る前段階のデータ窃取時の不正アクセスを検知できるストレージシステム及び不正アクセス検知方法を提供することにある。
【課題を解決するための手段】
【0011】
上記課題を解決するために、本発明のストレージシステムは、コントローラとデータをキャッシュするキャッシュとを含み、複数のボリュームを1又は複数の計算機に提供するストレージシステムであって、前記コントローラは、所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第1パラメータを取得し、前記第1パラメータが第1閾値パラメータより小さいことを、異常ふるまいとして検知する第1異常ふるまい検知処理、所定のサンプリング間隔内の前記ボリュームに関連するサーバのサーバキャッシュ占用率に基づく第2パラメータを取得し、前記第2パラメータが第2閾値パラメータより大きいことを、異常ふるまいとして検知する第2異常ふるまい検知処理、及び、所定のサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第3パラメータを取得し、前記第3パラメータが第3閾値パラメータより小さいことを、異常ふるまいとして検知する第3異常ふるまい検知処理、の少なくとも一つを含む異常ふるまい検知処理を実行するように構成されている。
【0012】
本発明の不正アクセス検知方法は、コントローラとデータをキャッシュするキャッシュとを含み、複数のボリュームを1又は複数の計算機に提供するストレージシステムにおける不正アクセス検知方法であって、前記コントローラによって、所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第1パラメータを取得し、前記第1パラメータが第1閾値パラメータより小さいことを、異常ふるまいとして検知する第1異常ふるまい検知、所定のサンプリング間隔内の前記ボリュームに関連するサーバのサーバキャッシュ占用率に基づく第2パラメータを取得し、前記第2パラメータが第2閾値パラメータより大きいことを、異常ふるまいとして検知する第2異常ふるまい検知、及び、所定のサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第3パラメータを取得し、前記第3パラメータが第3閾値パラメータより小さいことを、異常ふるまいとして検知する第3異常ふるまい検知、の少なくとも一つを含む異常ふるまい検知を実行する。
【発明の効果】
【0013】
本発明によれば、クライアントOSがコントロールできなくなった場合においてもストレージレイヤでランサムウェアによるデータ暗号化に至る前段階のデータ窃取時の不正アクセスを検知できる。
【図面の簡単な説明】
【0014】
図1図1は本発明の実施形態に係るストレージシステムの構成例を示す概略構成図である。
図2図2は初期パラメータテーブルを説明するための図である。
図3図3はキャッシュヒット率蓄積テーブルを説明するための図である。
図4図4はキャッシュ占用率蓄積テーブルを説明するための図である。
図5図5はデータアクセス速度蓄積テーブルを説明するための図である。
図6図6はIOPS蓄積テーブルを説明するための図である。
図7図7は監視間隔テーブルを説明するための図である。
図8図8は閾値テーブルを説明するための図である。
図9図9はボリューム-サーバ関係テーブルを説明するための図である。
図10A図10Aは検知観点1を説明するための図である。
図10B図10Bは検知観点1を説明するための図である。
図11A図11Aは検知観点2を説明するための図である。
図11B図11Bは検知観点2を説明するための図である。
図12図12は検知観点3を説明するための図である。
図13図13はストレージシステムが実行する全体処理の流れを説明するための処理フローを示すフローチャートである。
図14図14は初期設定変更プログラムが実行する処理フローを示すフローチャートである。
図15図15はデータ蓄積プログラムが実行する処理フローを示すフローチャートである。
図16A図16Aはボリュームキャッシュヒット率監視プログラムが実行する処理フローを示すフローチャートである。
図16B図16B図16Aの処理フローの理解を容易にするための具体例を説明するための図である。
図17A図17Aはサーバキャッシュ占用率監視プログラムが実行する処理フローを示すフローチャートである。
図17B図17B図17Aの処理フローの理解を容易にするための具体例を説明するための図である。
図18A図18Aはデータアクセス速度監視プログラムが実行する処理フローを示すフローチャートである。
図18B図18B図18Aの処理フローの理解を容易にするための具体例を説明するための図である。
図19A図19Aは閾値フィードバックプログラムが実行する処理フローを示すフローチャートである。
図19B図19B図19Aの処理フローの理解を容易にするための具体例を説明するための図である。
図20A図20Aは監視間隔フィードバックプログラムが実行する処理フローを示すフローチャートである。
図20B図20B図20Aの処理フローの理解を容易にするための図である。
図21A図21Aはランサムウェア判定プログラム(キャッシュヒット率観点)が実行する処理フローを示すフローチャートである。
図21B】。図21B図21Aの処理フローの理解を容易にするための具体例を説明するための図である。
図22A図22Aはランサムウェア判定プログラム(データアクセス速度観点)が実行する処理フローを示すフローチャートである。
図22B図22B図22Aの処理フローの理解を容易にするための具体例を説明するための図である。
【発明を実施するための形態】
【0015】
以下、本発明の実施形態について図面を参照しながら説明する。実施形態の全図において、同一又は対応する部分には同一の符号を付す場合がある。
【0016】
以下の説明では、識別情報について説明する際、「識別番号」等の表現を用いるが、これら以外の識別情報(例えば、名称等)に置換されてもよい。また、以下の説明では、プログラム又は機能ブロックを主語として処理を説明する場合があるが、処理の主語が、機能ブロックに代えて、コントローラ又はCPUとされてもよい。また、以下の説明では、「テーブル」、「レコード」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されてもよい。
【0017】
<<実施形態>>
図1は本発明の実施形態に係るストレージシステム100を含むシステムの構成例を示す概略構成図である。図1に示すよう、システムは、ストレージシステム100と、複数(本例においてN個(N≧4以上))のホストサーバ(1)HSV1乃至ホストサーバ(N)HSVNと、を含む。
【0018】
なお、ホストサーバ(1)HSV1乃至ホストサーバ(N)HSVNは、これらを特に区別する必要がない場合、「ホストサーバHSV」と称呼される。ホストサーバHSVは、単にサーバとも称呼される場合がある。ホストサーバHSVNは一つであってもよい。ストレージシステム100とホストサーバHSVとは、ネットワークNW1を介してデータ(情報)を送受信可能に接続されている。
【0019】
ストレージシステム100は、コントローラ200を含む。コントローラ200は、ストレージとしての機能をホストサーバHSVに提供するために必要なソフトウェアが実装された装置である。
【0020】
コントローラ200は、CPU210と、メモリ220と、を含む。CPU210は、コントローラ200の全体の動作制御を司るハードウェアである。CPU210は、ホストサーバHSVからポート500を介して与えられたI/O要求であるリードコマンドやライトコマンドに応じて、データを読み書きする。
【0021】
メモリ220は、例えば、SDRAM(Synchronous Dynamic Random Access Memory)等の半導体メモリから構成され、各種プログラムやデータを記憶(保持、格納)するために利用される。
【0022】
メモリ220は、CPU210の主記憶装置であり、以下に述べるように、CPU210が実行するプログラムや、CPU210が参照する各種テーブル等が格納される。
【0023】
メモリ220は、初期パラメータテーブル230、キャッシュヒット率蓄積テーブル240、キャッシュ占用率蓄積テーブル250、データアクセス速度蓄積テーブル260、IOPS蓄積テーブル270、監視間隔テーブル280、閾値テーブル290及びボリューム-サーバ関係テーブル300を記憶する。なお、これらのテーブルの詳細は、後に説明する。
【0024】
メモリ220は、初期設定変更プログラム310、データ蓄積プログラム320、ボリュームキャッシュヒット率監視プログラム330、サーバキャッシュ占用率監視プログラム340、データアクセス速度監視プログラム350、閾値フィードバックプログラム360、監視間隔フィードバックプログラム370、ランサムウェア判定プログラム(キャッシュヒット率観点)380及びランサムウェア判定プログラム(データアクセス速度観点)390を記憶する。なお、これらプログラムの詳細は、後に説明する。これらのプログラムは、CPU210によって実行される。
【0025】
ストレージシステム100は、キャッシュ400と、プール410と、DPボリューム420と、プールボリューム430とを含む。キャッシュ400は、データを一時的に格納するための高速アクセス可能なメモリである。キャッシュ400は、ストレージシステム100のI/O処理のスループット及びレスポンスを向上させるために設けられている。
【0026】
プール410は、ストレージシステム100が備えるSDD(Solid State Drive)、HDD(Hard Disk Drive)、フラッシュメモリ等の各記憶装置が提供する論理的な記憶領域である複数のプールボリューム430(実ボリューム)により構成されている。例えば、プール410は、高速な記憶装置(例えば、FMD(Flash Module Drive))、SSD、FCドライブ、SASドライブ等)と、低速な記憶装置(例えば、SATAドライブ等)とを混在させて構成される。記憶領域は、対応する記憶装置の応答性に応じて、複数の階層(TierN(Nは2以上の整数))に分けて管理されている。なお、本例においては、Tier1(tire1)、Tier2(tire2)及びTier3(tire3)の3個の階層に分けて管理されている。データは、そのデータに対するアクセス頻度に応じた層に自動配置される。例えば、アクセス頻度の高いデータについては、より高い階層に自動配置され、アクセス頻度の低いデータについては、より低い階層に自動配置される。
【0027】
複数のDPボリューム420は、ストレージシステム100内に定義された仮想的な論理ボリュームであり、ホストサーバHSVに提供される。DPボリューム420は、ホストサーバHSVから認識される論理的な記憶領域であり、ホストサーバHSVからのリード要求/ライト要求の発行対象となる記憶領域である。
【0028】
DPボリューム420は、ホストサーバHSVに割り当てられる。コントローラ200は、ホストサーバHSVによるDPボリューム420に対するデータの書き込みに応じて実領域(プールボリューム430)を使用することで、ストレージリソースである各記憶装置を有効に利用する。
【0029】
ホストサーバHSVは、I/O要求を発行する計算機(サーバ装置)である。ホストサーバHSVは、物理的な計算機であってもよく、仮想的な計算機であってもよい。ホストサーバHSVは、HBA(ホストバスアダプタ)を備える。ホストサーバHSVは、HBA及びネットワークNW1を介してストレージシステム100のポート500に接続される。
【0030】
図2は初期パラメータテーブル230を説明するための図である。図2に示すように、初期パラメータテーブル230は、情報(値)を格納する列(カラム)として、LdevId231と、監視開始時刻232と、サンプリング間隔233と、過去データの見る量234と、を含む。初期パラメータには、データ監視に関する各列に対応する情報が互いに関連づけられて行単位の情報(レコード)として格納されている。具体的に述べると、LdevId231には、LDEV(DPボリューム420)を識別するための識別番号が格納されている。
【0031】
監視開始時刻232には、監視を開始する時刻が格納されている。デフォルト値の場合、監視開始時刻232には、例えば、LDEVの作成時刻、システム設計者やソフトウェア設計者が設計した値が格納される。サンプリング間隔233には、監視のサンプリング間隔が格納されている。デフォルト値の場合、サンプリング間隔233には、システム設計者やソフトウェア設計者が設計した値が格納される。過去データの見る量234には、過去データの見る量を特定するための情報が格納されている。本例において、過去データの見る量234には、過去データを見る範囲の開始時刻が格納されている。
【0032】
図3はキャッシュヒット率蓄積テーブル240を説明するための図である。図3に示すように、キャッシュヒット率蓄積テーブル240は、情報(値)を格納する列(カラム)として、LdevId241と、時刻242と、キャッシュヒット率243と、を含む。キャッシュヒット率蓄積テーブル240には、キャッシュヒット率に関する各列に対応する情報が互いに関連づけられて行単位の情報(レコード)として格納されている。具体的に述べると、LdevId241には、LDEV(DPボリューム420)を識別するための識別番号が格納されている。時刻242には、キャッシュヒット率が検出された時刻が格納されている。キャッシュヒット率243には、キャッシュヒット率が格納されている。なお、「キャッシュヒット率」とは、キャッシュヒットの確率である。「キャッシュヒット」とは、キャッシュ400にアクセスしたときにライト又はリードの対象のデータが見つかることである。
【0033】
図4はキャッシュ占用率蓄積テーブル250を説明するための図である。図4に示すように、キャッシュ占用率蓄積テーブル250は、情報(値)を格納する列(カラム)として、LdevId251と、時刻252と、キャッシュヒット率253と、を含む。キャッシュ占用率蓄積テーブル250には、キャッシュ占用率に関する各列に対応する情報が互いに関連づけられて行単位の情報(レコード)として格納されている。具体的に述べると、LdevId251には、LDEV(DPボリューム420)を識別するための識別番号が格納されている。時刻252には、キャッシュ占用率が検出された時刻が格納されている。キャッシュ占用率253には、キャッシュ占用率が格納されている。なお、キャッシュ占用率とは、キャッシュ400の容量に対するボリュームに割り当てられたキャッシュ400の容量の比率である。
【0034】
図5はデータアクセス速度蓄積テーブル260を説明するための図である。図5に示すように、データアクセス速度蓄積テーブル260は、情報(値)を格納する列(カラム)として、LdevId261と、時刻262と、データアクセス速度263と、を含む。データアクセス速度蓄積テーブル260には、データアクセス速度に関する各列に対応する情報が互いに関連づけられて行単位の情報(レコード)として格納されている。具体的に述べると、LdevId261には、LDEV(DPボリューム420)を識別するための識別番号が格納されている。時刻262には、データアクセス速度が検出された時刻が格納されている。データアクセス速度263には、データへのアクセス速度(データアクセス速度)が格納されている。
【0035】
図6はIOPS蓄積テーブル270を説明するための図である。図6に示すように、IOPS蓄積テーブル270は、情報(値)を格納する列(カラム)として、LdevId271と、時刻272と、IOPS273と、を含む。IOPS蓄積テーブル270には、IOPSに関する各列に対応する情報が互いに関連づけられて行単位の情報(レコード)として格納されている。具体的に述べると、LdevId271には、LDEV(DPボリューム420)を識別するための識別番号が格納されている。時刻272には、IOPS(Input/Output Per Second)が検出された時刻が格納されている。IOPS273には、IOPSが格納されている。なお、IOPSは、ストレージが1秒あたりに処理できるI/Oアクセスの数である。
【0036】
図7は監視間隔テーブル280を説明するための図である。図7に示すように、監視間隔テーブル280は、情報(値)を格納する列(カラム)として、LdevId281と、キャッシュヒット率監視間隔282と、キャッシュ占用率監視間隔283と、データへのアクセス速度監視間隔284と、を含む。監視間隔テーブル280には、監視間隔に関する各列に対応する情報が互いに関連づけられて行単位の情報(レコード)として格納されている。具体的に述べると、LdevId281には、LDEV(DPボリューム420)を識別するための識別番号が格納されている。キャッシュヒット率監視間隔282には、キャッシュヒット率監視間隔を示す時間が格納されている。キャッシュ占用率監視間隔283には、キャッシュ占用率監視間隔を示す時間が格納されている。データへのアクセス速度監視間隔284には、データへのアクセス速度監視間隔を示す時間が格納されている。
【0037】
図8は閾値テーブル290を説明するための図である。図8に示すように、閾値テーブル290は、情報(値)を格納する列(カラム)として、LdevId291と、キャッシュヒット率292と、キャッシュ占用率293と、データへのアクセス速度294と、を含む。閾値テーブル290には、閾値に関する各列に対応する情報が互いに関連づけられて行単位の情報(レコード)として格納されている。具体的に述べると、LdevId291には、LDEV(DPボリューム420)を識別するための識別番号が格納されている。キャッシュヒット率292には、閾値キャッシュヒット率が格納されている。キャッシュ占用率293には、閾値キャッシュ占用率が格納されている。データへのアクセス速度294には、閾値アクセス速度が格納されている。
【0038】
図9はボリューム-サーバ関係テーブル300を説明するための図である。図9に示すように、ボリューム-サーバ関係テーブル300は、情報(値)を格納する列(カラム)として、ServerId301と、LdevId302と、を含む。ボリューム-サーバ関係テーブル300には、ボリュームとサーバとの関係に関する各列に対応する情報が互いに関連づけられて行単位の情報(レコード)として格納されている。具体的に述べると、ServerId301には、ホストサーバHSVを識別するための識別番号が格納されている。LdevId302には、LDEV(DPボリューム420)を識別するための識別番号が格納されているが格納されている。
【0039】
<概要>
本発明の実施形態に係るストレージシステム100は、ランサムウェアによる不正アクセスを検知する。まず本発明の理解を容易にするため、ストレージシステム100が、ランサムウェアによる不正アクセスの検知に利用する検知観点1乃至検知観点3について説明する。
【0040】
(検知観点1)
図10A及び図10Bは、検知観点1を説明するためのシステムの概略図である。このシステムは、サーバSV1及びストレージシステム100を含む。図10Aは、サーバSV1の通常運用におけるアプリケーション1のデータの参照状態を示し、図10BはサーバSV1がランサムウェアRSMに感染した状態のデータの参照状態を示す。図10A及び図10Bにおいて、サーバSV1は、ホストサーバHSVに対応し、VOL1乃至VOL5は、サーバSV1に割り当てられた仮想ボリュームであるDPボリューム420に対応する。キャッシュCA1は、キャッシュ400に対応し、ボリュームPV1はプールボリューム430に対応する(図11A及び図11Bにおいても同様。)。矢印はデータのアクセス元及びアクセス先(参照元及び参照先)を示す(図11A及び図11Bにおいても同様。)。
【0041】
図10Aに示すように、通常運用において、サーバSV1内の1つのアプリケーション1AP1が常に該当サーバSV1のVOL1乃至VOL5の全てのデータを参照することは考えにくい。例えば、安定稼働しているシステムでの通常運用では、サーバSV1内のアプリケーション1AP1が常にVOL1を参照している。
【0042】
これに対して、図10Bに示すように、サーバSV1がランサムウェアRSMに感染した場合、ランサムウェアRSMによるデータ窃取で、大量のデータにアクセスする。例えば、ランサムウェアRSMはVOL1乃至VOL5の全てを参照する。更に、ランサムウェアRSMは、VOL1乃至VOL5のそれぞれにおいてもほとんど全てのデータを参照する。キャッシュCA1が一時的に保持するデータ量には、限界があるので、ボリューム単位のキャッシュヒット率は低下する。
【0043】
よって、通常運用において、ボリューム単位のキャッシュヒット率が定常であり、サーバSV1がランサムウェアRSMに感染した状態では、通常運用に比べて、ボリューム単位のキャッシュヒット率が低下する傾向にあることがわかる。
【0044】
(検知観点2)
図11A及び図11Bは、検知観点2を説明するためのシステムの概略図である。このシステムは、サーバ(1)SV11乃至サーバ(3)SV13を含む。図11Aは、サーバ(1)SV11乃至サーバ(3)SV13の通常運用におけるアプリケーションのデータの参照状態を示し、図11Bはサーバ(2)SV12がランサムウェアに感染した状態のデータの参照状態を示す。
【0045】
図11Aに示すように、通常運用において、サーバ(1)SV11乃至サーバ(3)SV13のうちのあるサーバだけ常にキャッシュCA1を大量に占有していることは考えにくい。例えば、安定稼働しているシステムの通常運用では、サーバ(1)SV11、サーバ(2)SV12及びサーバ(3)SV13は、1:1:1の量でキャッシュCA1を占有している。
【0046】
これに対して、図11Bに示すように、サーバ(2)SV12がランサムウェアRSMに感染した場合、ランサムウェアRSMによるデータ窃取で、大量のデータに不正にアクセスする。例えば、ランサムウェアRSMに感染されたサーバ(2)SV12では、データのR/Wがたくさん発生し、キャッシュCA1への占用が急速に増える。
【0047】
よって、通常運用において、各サーバのキャッシュ占用率が定常であり、ランサムウェアRSMに感染した状態では、通常運用に比べて、ランサムウェアRSMが侵入したサーバ(2)SV12のキャッシュ占用率が上がる傾向にあることがわかる。
【0048】
(検知観点3)
図12は、検知観点3を説明するための説明図である。ストレージシステム100では、上述したように、階層最適化機能によって、通常運用において、アクセス頻度の解析をして、平均アクセス時間が短くなるようにデータがTierに配置されている。例えば、普段よくアクセスするデータがTier1及びTier2に配置される。ほとんどアクセスしないデータがTier3に配置される。通常運用では、階層最適化機能によって、データのアクセス時間が短くなっているので、データへのアクセス速度が速い。
【0049】
例えば、表TB1に示すように、通常運用では、アクセス比がアクセス時間に影響し、100GBのR/Wがあるとした場合、図12に示した計算により、アクセス時間は、100GBあたり、270msかかる。
【0050】
これに対して、サーバがランサムウェアに感染した場合、ランサムウェアによるデータ窃取で、大量のデータにアクセスする。ランサムウェアによって、Tier1,2,3に関係なく、Tier3まで大量にデータをアクセスすると、グラフGr1及びグラフGr2に示すように、今までの傾向と異なる動きをし、アクセス時間が長くなり、データへのアクセス速度が下がる。
【0051】
例えば、表TB2に示すように、ランサムウェアにサーバが感染した状態では、Tier1,2,3に存在するデータの容量比がアクセス時間に影響する。100GBのR/Wがあるとした場合、図12に示した計算により、データアクセス時間は、100GBあたり、650msかかる。
【0052】
よって、通常運用において、データへのアクセス時間が短い(即ち、データへのアクセス速度が速い)のに対して、サーバがランサムウェアに感染した状態では、データへのアクセス速度が下がる傾向(低下する傾向)にあることがわかる。
【0053】
<処理の概要>
ストレージシステム100のコントローラ200は、上記検知観点1乃至検知観点3を利用して、ランサムウェアに感染している可能性のあるふるまいを、通常と異なるふるまいである「異常ふるまい」として検知する「異常ふるまい検知処理」を実行する。
【0054】
コントローラ200は、異常ふるまいを検知する精度を向上するために、閾値及び閾値を算出するときの監視間隔をフィードバックする(更新する)「フィードバック処理」を実行する。
【0055】
コントローラ200は、異常ふるまいを検知した場合において、ランサムウェアに起因した異常ふるまいであることの判定精度をあげるために、異常ふるまいをランサムウェアによる不正データアクセスとして検知するか否かを判定する「ランサムウェア判定」を実行する。
【0056】
コントローラ200は、ランサムウェア判定によって、異常ふるまいをランサムウェアによる不正データアクセスとして検知した場合、不正アクセス検知に対する処理である「不正アクセス対応処理」を実行する。
【0057】
以下、異常ふるまい検知処理、フィードバック処理、ランサムウェア判定及び不正アクセス対応処理の各処理の概要について順に説明する。
【0058】
<異常ふるまい検知処理>
異常ふるまい検知処理は、以下に説明する異常ふるまい検知処理1、異常ふるまい検知処理2及び異常ふるまい検知処理3を含む。なお、異常ふるまい検知処理1は、便宜上、「第1異常ふるまい検知処理」とも称呼される場合がある。異常ふるまい検知処理2は、便宜上、「第2異常ふるまい検知処理」とも称呼される場合がある。異常ふるまい検知処理3は、便宜上、「第3異常ふるまい検知処理」とも称呼される場合がある。
【0059】
(異常ふるまい検知処理1)
検知観点1によれば、通常運用に比べてボリューム単位のキャッシュヒット率が低下した場合、ランサムウェアによる感染(ランサムウェアによる不正なデータアクセス)が生じた可能性があることがいえる。従って、ストレージシステム100は、通常運用に比べてボリューム単位のキャッシュヒット率が低下したことを、異常ふるまいとして検知する。この検知を行うため、コントローラ200は、ボリュームキャッシュヒット率監視プログラム330によって、以下に述べるデータ参照処理、計算処理及び比較処理を行う。
【0060】
(データ参照処理)
ボリュームキャッシュヒット率監視プログラム330は、初期パラメータテーブル230からサンプリング間隔を取得する。ボリュームキャッシュヒット率監視プログラム330は、キャッシュヒット率蓄積テーブル240から、各時刻のキャッシュヒット率を取得する。ボリュームキャッシュヒット率監視プログラム330は、データ参照処理によって、閾値テーブル290から閾値キャッシュヒット率を取得する。
【0061】
(計算処理)
ボリュームキャッシュヒット率監視プログラム330は、サンプリング間隔(現在)におけるキャッシュヒット率を算出する。即ち、現在の時点からサンプリング間隔だけ前(過去)の時点までの間(サンプリング間隔内)の各時刻のキャッシュヒット率に基づいて、サンプリング間隔(現在)におけるキャッシュヒット率を計算する。
【0062】
サンプリング間隔(現在)におけるキャッシュヒット率の算出方法は、例えば、以下に述べる(1)乃至(3)の何れかである。
(1)サンプリング間隔内の各時刻のキャッシュヒット率を用いて、それらの平均値を算出する。
(2)サンプリング間隔内の各時刻のキャッシュヒット率を時間で積分し、面積を算出する。
(3)サンプリング間隔内において、時刻の差分とキャッシュヒット率の差分とを用いて、傾きを算出する。
【0063】
なお、サンプリング間隔(現在)におけるキャッシュヒット率の算出方法は、他の算出方法であってもよい。サンプリング間隔内のキャッシュヒット率(即ち、算出された平均値、面積又は傾き等)は、便宜上、「第1パラメータ」とも称呼される場合がある。閾値キャッシュヒット率は、便宜上、「第1閾値パラメータ」とも称呼される場合がある。
【0064】
(比較処理)
ボリュームキャッシュヒット率監視プログラム330は、サンプリング間隔(現在)におけるキャッシュヒット率(第1パラメータ)と閾値キャッシュヒット率とを比較する。閾値キャッシュヒット率は、例えば、初期設定値等又は過去データに基づく値(例えば、過去データのある期間のサンプリング間隔におけるキャッシュヒット率(第1パラメータ)の最小値)である。ボリュームキャッシュヒット率監視プログラム330は、キャッシュヒット率が閾値キャッシュヒット率より小さい場合、キャッシュヒット率が閾値キャッシュヒット率より小さいことを、異常ふるまいとして検知する。
【0065】
(異常ふるまい検知処理2)
検知観点2によれば、通常運用に比べて、ランサムウェアが侵入したホストサーバHSVのキャッシュ占用率が上がった場合、ランサムウェアによる感染(ランサムウェアによる不正なデータアクセス)が生じた可能性があることがいえる。従って、ストレージシステム100は、通常運用に比べてランサムウェアが侵入したホストサーバHSVのキャッシュ占用率が上がったことを、異常ふるまいとして検知する。
【0066】
この検知を行うため、コントローラ200は、サーバキャッシュ占用率監視プログラム340によって、以下に述べるデータ参照処理、計算処理及び比較処理を行う。
【0067】
(データ参照処理)
サーバキャッシュ占用率監視プログラム340は、初期パラメータテーブル230からサンプリング間隔を取得する。サーバキャッシュ占用率監視プログラム340は、キャッシュ占用率蓄積テーブル250から、各時刻のボリュームのキャッシュ占用率を取得する。サーバキャッシュ占用率監視プログラム340は、ボリューム-サーバ関係テーブル300からボリュームとホストサーバHSVとの対応関係を取得する。サーバキャッシュ占用率監視プログラム340は、閾値テーブル290から閾値サーバキャッシュ占用率(ホストサーバHSVに割り当てられているボリューム(LdevId)に関連付けられた閾値キャッシュ占用率の総和)を取得する。
【0068】
(計算処理)
サーバキャッシュ占用率監視プログラム340は、サンプリング間隔(現在)におけるボリュームのキャッシュ占用率を算出する。即ち、現在の時点からサンプリング間隔だけ前(過去)の時点までの間(サンプリング間隔内)の各時刻のボリュームのキャッシュ占用率に基づいて、サンプリング間隔(現在)におけるボリュームのキャッシュ占用率を計算する。
【0069】
サンプリング間隔(現在)におけるボリュームのキャッシュ占用率の算出方法は、例えば、以下に述べる(1)乃至(3)の何れかである。
(1)サンプリング間隔内の各時刻のボリュームのキャッシュ占用率を用いて、それらの平均値を算出する。
(2)サンプリング間隔内の各時刻のボリュームのキャッシュ占用率を時間で積分し、面積を算出する。
(3)サンプリング間隔内において、時刻の差分とボリュームのキャッシュ占用率の差分とを用いて、傾きを算出する。
【0070】
ボリュームとホストサーバHSVとの対応関係を用いて、ホストサーバHSVのキャッシュ占用率(サーバキャッシュ占用率)を算出する。
【0071】
なお、ボリュームのキャッシュ占用率の算出方法は、他の算出方法であってもよい。サンプリング間隔内のボリュームのキャッシュ占用率(即ち、算出された平均値、面積又は傾き等)は、便宜上、「第2パラメータ計算用パラメータ」とも称呼される場合がある。サンプリング間隔内のサーバキャッシュ占用率(即ち、算出された平均値、面積又は傾き等)は、便宜上、「第2パラメータ」とも称呼される場合がある。閾値サーバキャッシュ占用率は、便宜上、「第2閾値パラメータ」とも称呼される場合がある。
【0072】
(比較処理)
サーバキャッシュ占用率監視プログラム340は、サンプリング間隔(現在)におけるサーバキャッシュ占用率(第2パラメータ)と閾値サーバキャッシュ占用率とを比較する。閾値サーバキャッシュ占用率は、例えば、初期設定値等又は過去データのある期間のサンプリング間隔におけるサーバキャッシュ占用率(第2パラメータ)の最大値である。サーバキャッシュ占用率監視プログラム340は、サーバキャッシュ占用率が閾値サーバキャッシュ占用率より大きい場合、サーバキャッシュ占用率が閾値サーバキャッシュ占用率より大きいことを、異常ふるまいとして検知する。
【0073】
(異常ふるまい検知処理3)
検知観点3によれば、通常運用に比べて、データアクセス速度(データへのアクセス速度)が下がった場合、ランサムウェアによる感染(ランサムウェアによる不正なデータアクセス)が生じた可能性があることがいえる。従って、ストレージシステム100は、通常運用に比べて、データアクセス速度が下がったことを、ランサムウェアによる異常ふるまいとして検知する。
【0074】
この検知を行うため、コントローラ200は、データアクセス速度監視プログラム350によって、データ参照処理、計算処理及び比較処理を行う。
【0075】
(データ参照処理)
データアクセス速度監視プログラム350は、初期パラメータテーブル230からサンプリング間隔を取得する。データアクセス速度監視プログラム350は、データアクセス速度蓄積テーブル260から、各時刻のデータアクセス速度を取得する。データアクセス速度監視プログラム350は、閾値テーブル290から、閾値データアクセス速度を取得する。
【0076】
(計算処理)
データアクセス速度監視プログラム350は、サンプリング間隔(現在)におけるデータアクセス速度を算出する。即ち、データアクセス速度監視プログラム350は、現在の時点からサンプリング間隔だけ前(過去)の時点までの間(サンプリング間隔内)の各時刻のデータアクセス速度に基づいて、サンプリング間隔(現在)におけるデータアクセス速度を計算する。
【0077】
データアクセス速度の算出方法は、例えば、以下に述べる(1)乃至(3)の何れかである。
(1)サンプリング間隔内の各時刻のデータアクセス速度を用いて、それらの平均値を算出する。
(2)サンプリング間隔内の各時刻のデータアクセス速度を時間で積分し、面積を算出する。
(3)サンプリング間隔内において、時刻の差分とデータアクセス速度の差分とを用いて、傾きを算出する。
【0078】
なお、サンプリング間隔(現在)におけるデータアクセス速度の算出方法は、他の算出方法であってもよい。サンプリング間隔(現在)におけるデータアクセス速度(即ち、算出された平均値、面積又は傾き等)は、便宜上、「第3パラメータ」とも称呼される場合がある。閾値データアクセス速度は、便宜上、「第3閾値パラメータ」とも称呼される場合がある。
【0079】
(比較処理)
データアクセス速度監視プログラム350は、サンプリング間隔(現在)におけるデータアクセス速度(第3パラメータ)と閾値データアクセス速度とを比較する。閾値データアクセス速度は、例えば、初期設定値等又は過去データのある期間のサンプリング間隔におけるデータアクセス速度(第3パラメータ)の最小値である。データアクセス速度監視プログラム350は、データアクセス速度が閾値データアクセス速度より小さい場合、データアクセス速度が閾値データアクセス速度より小さいことを、異常ふるまいとして検知する。
【0080】
<フィードバック処理>
以下フィードバック処理について説明する。フィードバック処理は、閾値フィードバックプログラム360による閾値フィードバック及び監視間隔フィードバックプログラム370による監視間隔フィードバックを含む。
【0081】
(閾値フィードバック)
コントローラ200は、閾値フィードバックプログラム360によって、閾値をフィードバックする。
【0082】
運用テストで得た測定値、又は、システム設計者やソフトウェア設計者が設計した値などで閾値の暫定値とする。システムが本番稼働に入ると、蓄積したデータからキャッシュヒット率(第1パラメータ)の最小値、サーバキャッシュ占用率(第2パラメータ)を計算するためのボリュームのキャッシュ占用率(第2パラメータ計算用パラメータ)の最大値、データアクセス測度(第3パラメータ)の最小値を計算する。その結果で、閾値(閾値キャッシュヒット率、閾値サーバキャッシュ占用率及び閾値データアクセス速度)を動的に修正する。なお、これらの最大値又は最小値は、所定の監視間隔毎に計測した値に基づいて、計算される。この監視間隔は、監視間隔フィードバックにより動的に修正される。
【0083】
閾値フィードバックプログラム360は、システムの稼働状況によって、閾値を再計算し、動的に更新していくことで、異常ふるまい(ランサムウェアによる不正アクセス)の検知精度を向上させる。閾値フィードバックプログラム360の呼び出されるタイミングとしては、1日に1回、1週間に1回、1ヵ月に1回などであってもよい。閾値フィードバックプログラム360は、ユーザが必要なタイミングで手動により実行されるようにしてもよい。
【0084】
(監視間隔フィードバック)
コントローラ200は、監視間隔フィードバックプログラム370によって、監視間隔をフィードバックする。
【0085】
システムの運用が多種多様で、ほぼ変化なしのシステムもあるし、定期又は不定期的に変化しているシステムもある。同じシステムにおいて、運用方法が時期によって変化する可能性もある。よって、コントローラ200は、システムの運用パターンに対応するように、監視間隔をフィードバックする。
【0086】
例えば、システムの運用パターンが、「大体常に一定」である場合、1日又は所定の複数日を監視間隔に設定する。そして、上述した閾値フィードバックによって、その監視間隔で計算された値が比較されることにより、閾値が算出される。
【0087】
システムの運用パターンが、年度ごとに同じ傾向にある場合、去年、一昨年・・・と、監視間隔を1年で設定する。そして、上述した閾値フィードバックによって、その監視間隔で計算された値が比較されることにより、閾値が算出される。
【0088】
システムの運用パターンが、「曜日ごとに傾向がある」である場合、毎週の同じ曜日と比較するように、監視間隔を設定する。そして、上述した閾値フィードバックによって、その監視間隔で計算された値が比較されることにより、閾値が算出される。
【0089】
システムの運用パターンが、「日付ごとに傾向がある」である場合、先月、先々月・・・のその日付と比較するように、監視間隔を設定する。そして、上述した閾値フィードバックによって、その監視間隔で計算された値が比較されることにより、閾値が算出される。
【0090】
このように、監視間隔フィードバックプログラム370は、ストレージシステム100の本番稼働に入って、定期的に生じるデータの傾向(挙動)があるシステムであれば、システムの運用状況に応じて、その傾向の周期を計算し、その傾向の周期により監視間隔を動的に修正する。これにより、異常ふるまいの検知精度を向上することができる。
【0091】
<ランサムウェア判定>
ストレージレイヤにおいて「異常ふるまい」を検知した場合、ランサムウェアがデータを窃取している可能性がある。一方で、正常業務中の一時的な特殊イベント(例:構成変更/APP新規追加)があった場合も、いつもと違う傾向になる。即ち、異常ふるまいと類似するデータ傾向(データ変化傾向)が生じる可能性がある。
【0092】
この異常ふるまいが検知されたことによって、ランサムウェアによる不正アクセスを検知してもよい(後述の変形例1を参照。)が、一方で、その場合の異常ふるまいが、ランサムウェアと区別つかないことも生じ得るので、検知精度が低下してしまう可能性がある。例えば、単に過去値で求めた正常範囲からピンポイント(1つのボリュームのキャッシュヒット率が下がったなど)外れた場合、検知精度が低下してしまう可能性がある。
【0093】
そこで、コントローラ200は、異常ふるまいを検知した場合、ランサムウェア判定プログラムによって、異常ふるまいがランサムウェアに起因するふるまいであるか否かを判定する。これにより、コントローラ200は、ランサムウェアの検知精度を上げることができる。
【0094】
ここで、ランサムウェアの挙動としては、以下の(1)乃至(4)の挙動がある。
【0095】
挙動(1)ランサムウェアによるデータ窃取時に大量のデータアクセスが生じたり、データ転送が急増したりする。
挙動(2)ランサムウェアによるデータ窃取時にネットワーク内の端末やサーバを一斉に攻撃する。
挙動(3)データ窃取後にデータを破壊する。
挙動(4)ランサムウェアは、データ搾取時にできるだけ早くデータをとろうとする。
【0096】
このようなランサムウェアの挙動に着目して、ランサムウェア判定は、以下に述べるように、ランサムウェア判定プログラム(キャッシュヒット率観点)380及びランサムウェア判定プログラム(データアクセス速度観点)390によって、実行される。
【0097】
(ランサムウェア判定チェック(キャッシュヒット率観点))
ランサムウェア判定プログラム(キャッシュヒット率観点)380は、異常ふるまいが検知された場合、以下に述べる判定A乃至判定Dの少なくとも一つを行うことにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。
【0098】
(判定A)
挙動(1)によれば、ランサムウェアは大量アクセスをするため、同一ホストサーバHSVの他のボリュームも同様の傾向が現れているかを調べることにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。
【0099】
従って、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、異常ふるまいが検知された該当ボリュームが割り当てられているホストサーバHSV内の他のボリュームも、同様なキャッシュヒット率傾向が現れているか否かを判定する(即ち、サンプリング間隔(現在)におけるキャッシュヒット率が閾値キャッシュヒット率より小さいか否かを判定する。)。
【0100】
ホストサーバHSV内の他のボリュームも、同様なキャッシュヒット率傾向が現れている場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。
【0101】
(判定B)
挙動(1)によれば、ランサムウェアは大量アクセスをするため、他のホストサーバHSVの他のボリュームも同様の傾向が現れているかを調べることにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。
【0102】
従って、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、該当ボリュームが割り当てられているホストサーバHSV以外の他のホストサーバHSVのボリュームも、同様なキャッシュヒット率傾向が現れているか否かを判定する。
【0103】
他のホストサーバHSVのボリュームも、同様なキャッシュヒット率傾向が現れている場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。
【0104】
(判定C)
挙動(3)によれば、ランサムウェアはデータ搾取後データを破壊するため、キャッシュヒット率が正常に戻らないはずである。そのため、キャッシュヒット率がいつもの傾向に戻ったかどうかを調べることにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。
【0105】
従って、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、キャッシュヒット率がいつもの傾向に戻ったボリュームがないか否かを判定する。ランサムウェア判定プログラム(キャッシュヒット率観点)380は、キャッシュヒット率がいつもの傾向に戻ったボリュームがない場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。
【0106】
(判定D)
キャッシュヒット率の低下はウイルススキャンによっても生じるため、キャッシュヒット率の低下がウイルススキャンによるものか否かを判別することは誤検知低下の観点から好ましい。ここで、IOPSに関し、挙動(4)によればランサムウェアは早速でデータを抜き出すという動作であるのでIOPSが普段より大きくなるのに対して、ウイルススキャンはデータをチェックしながらデータを読んでいるため、ウイルススキャンの場合のIOPSは小さい。このような観点に着目して、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ボリューム(該当ボリューム及び同様なキャッシュヒット率傾向が現れている他のボリューム)のIOPSが普段より大きいか否かを判定する。ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ボリュームのIOPSが普段より大きい場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。
【0107】
ランサムウェア判定プログラム(キャッシュヒット率観点)380は、上記判定A乃至判定Dの少なくとも一つの判定を実行し、少なくとも一つの判定結果が、「YES」である場合に、異常ふるまいがランサムウェアに起因するふるまいであると判定してもよい。なお、本例ではストレージシステムが複数台のホストサーバHSVで使用されおり、本例の後述の図21Aのフローチャートにより示した処理フローでは、上記判定A乃至判定Dの全ての判定結果が「YES」である場合に、異常ふるまいがランサムウェアに起因するふるまいであると判定されるようになっている。
【0108】
(ランサムウェア判定チェック(データアクセス速度観点))
挙動(2)によれば、ランサムウェアによるデータ窃取時にネットワーク内の端末やサーバを一斉に攻撃する。このため、該当ボリュームが割り当てられているホストサーバHSV以外の他のホストサーバHSVのボリュームも、同様なデータアクセス速度傾向が現れているかを調べることにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。
【0109】
従って、ランサムウェア判定プログラム(データサクセス速度観点)390は、異常ふるまいが検知された該当ボリュームが割り当てられているホストサーバHSV以外の他のホストサーバHSVのボリュームも、データアクセス速度が低下しているか否かを判定する((即ち、サンプリング間隔(現在)におけるデータアクセス速度が閾値アクセス速度より小さいか否かを判定する。))。
【0110】
他のホストサーバHSVのボリュームも、データアクセス速度が低下している場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム(データアクセス速度観点)390は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。
【0111】
<不正アクセス対応処理>
コントローラ200は、ランサムウェアによる不正アクセスを検知した場合、不正アクセス対応処理を実行する。
【0112】
不正アクセス対応処理としては、例えば、以下に述べる処理が挙げられる。
・コントローラ200は、不正アクセスがあった対象サーバを特定しpath(パス)を切る。
・コントローラ200は、管理者の端末に不正アクセスがあった旨を通知する。
・コントローラ200は、上記通知に加えて、データの転送量を減少する。これが管理者の対応を待っている間に実施されると、データ流出の対策となる。
・コントローラ200は、上記通知に加えて、ストレージ内のデータの転送速度をおとす。これが管理者の対応を待っている間に実施されるとデータ流出の対策となる。
・システムが、ユーザが定期的にバックアップを取っているシステムなどである場合、コントローラ200は、正常だったと判断したタイミングにバックアップを戻す。
・システムが、CDPのような技術が適用されているシステムである場合、コントローラ200は、正常だったと判断したタイミングと組み合わせでデータを戻す。なお、CDP(Continuous Data Protection)は、過去データをライト毎に継続的にプール内に残すことで、ランサムウェア等の影響で改竄されたデータを任意の時点のデータ状態に戻す機能である。
・コントローラ200は、ウイルススキャンを自動的に走らせる。
【0113】
<具体的作動>
以下、ストレージシステム100の具体的作動について説明する。図13はストレージシステム100のコントローラ200が実行する全体処理の流れを説明するための処理フローを示すフローチャートである。コントローラ200は、図13に示す処理フローを実行する。従って、コントローラ200は、図13のステップ1300から処理を開始してステップ1305に進み、ボリューム(DPボリューム420)を作成する。ボリュームは、例えば、図示しない管理者端末からの指示に応じて作成される。
【0114】
その後、コントローラ200は、ステップ1310に進み、初期値を変更するか否かを判定する。
【0115】
初期値を変更する場合、コントローラ200は、ステップ1310にて「YES」と判定してステップ1315に進み、初期設定プログラム(初期設定変更プログラム310)によって、初期パラメータをユーザの指定に応じて変更する。ユーザは、例えば、図示しない管理者端末を操作することによって、初期パラメータを指定することができる。なお、ステップ1315の処理の詳細は、後述する。
【0116】
これに対して、初期値を変更しない場合、コントローラ200は、ステップ1310にて「NO」と判定してステップ1320に直接進む。
【0117】
コントローラ200は、ステップ1320に進むと、ストレージシステム100の監視を開始し、以下に述べるステップ1325及びステップ1330の処理の並行実行を開始させた後、ステップ1335に進む。
【0118】
ステップ1325:コントローラ200は、データ蓄積プログラム320によって、通常運用時のデータを蓄積する。なお、ステップ1325の処理の詳細は、後述する。
【0119】
ステップ1330:コントローラ200は、各監視プログラムと各フィードバックプログラムとを動作させる。なお、監視プログラムは、ボリュームキャッシュヒット率監視プログラム330、サーバキャッシュ占用率監視プログラム340及びデータアクセス速度監視プログラム350のことである。フィードバックプログラムは、閾値フィードバックプログラム360及び閾値間隔フィードバックプログラム370のことである。ステップ1330の処理の詳細は、後述する。
【0120】
コントローラ200は、ステップ1335に進むと、監視プログラムの少なくとも一つが、上述したいつもと異なるふるまいである「異常ふるまい」を検知したか否かを判定する。
【0121】
「異常ふるまい」を検知した場合、コントローラ200は、ステップ1335にて「YES」と判定してステップ1340に進み、ランサムウェア判定によるランサムウェア判定チェックを開始する。なお、ステップ1340の処理の詳細は、後述する。
【0122】
その後、コントローラ200は、ステップ1345に進んで、ランサムウェアの挙動による特異な傾向があるか否かを判定する。即ち、コントローラ200は、ランサムウェア判定によって、異常ふるまいがランサムウェアに起因するふるまいであるか否かを判定する。
【0123】
ランサムウェアの挙動による特異な傾向がない場合、コントローラ200は、ステップ1345にて「NO」と判定してステップ1320に戻り、監視を継続する。
【0124】
これに対して、ランサムウェアの挙動による特異な傾向がある場合、コントローラ200は、ステップ1345にて「YES」と判定してステップ1350に進み、不正アクセス検知後のアクションを開始する(即ち、上述した不正アクセス対応処理の実行を開始する。)。その後、コントローラ200は、ステップ1395に進んで本処理フローを一旦終了する。
【0125】
<ステップ1315>
上述したステップ1315の処理の詳細を説明する。図14は初期設定変更プログラム310が実行する処理フローを示すフローチャートである。初期設定変更プログラム310は、ステップ1400から処理を開始して以下に述べるステップ1405乃至ステップ1415の処理を順に実行した後、ステップ1495に進んで本処理フローを一旦終了する。
【0126】
ステップ1405:初期設定変更プログラム310は、初期パラメータテーブル230から監視開始時刻、サンプリング間隔及び過去データの見る量のデフォルト値を取得する。
【0127】
ステップ1410:初期設定変更プログラム310は、ユーザが変更したいパラメータを設定変更する。
【0128】
ステップ1415:初期設定変更プログラム310は、ユーザの指定値で初期パラメータテーブル230を更新する。
【0129】
<ステップ1325>
上述したステップ1325の処理の詳細を説明する。図15はデータ蓄積プログラム320が実行する処理フローを示すフローチャートである。データ蓄積プログラム320は、ステップ1500から処理を開始して以下に述べるステップ1505の処理を実行した後、ステップ1595に進んで本処理フローを一旦終了する。
【0130】
ステップ1505:データ蓄積プログラム320は、ストレージシステム100の通常運用時のデータ(時系列データ)を蓄積する。データは、逐次取得され、キャッシュヒット率蓄積テーブル240、キャッシュ占用率蓄積テーブル250、データアクセス速度蓄積テーブル260及びIOPS蓄積テーブル270等に格納される。
【0131】
<ステップ1330>
上述したステップ1330の処理の詳細を図16A乃至図20Bを用いて説明する。図16Aはボリュームキャッシュヒット率監視プログラム330が実行する処理フローを示すフローチャートである。図16B図16Aの処理フローの理解を容易にするための具体例を説明するための図である。
【0132】
ボリュームキャッシュヒット率監視プログラム330は、ステップ1600から処理を開始して以下に述べるステップ1605乃至ステップ1620の処理を順に実行した後、ステップ1625に進む。
【0133】
ステップ1605:ボリュームキャッシュヒット率監視プログラム330は、初期パラメータテーブル230(初期設定テーブル)から、サンプリング間隔を取得する。図16Bに示すように、ボリュームキャッシュヒット率監視プログラム330は、例えば、LdevId1について、初期パラメータテーブル230から矢印a1が示すレコードのサンプリング間隔600sを取得する。なお、他のLdevIdのそれぞれについても、同様の処理が実行されるが、説明は省略する(以下、同様。)。
【0134】
ステップ1610:ボリュームキャッシュヒット率監視プログラム330は、現在時刻から遡って、サンプリング間隔内のボリュームキャッシュヒット率(ボリューム単位のキャッシュヒット率)を取得する。図16Bの説明文EX1に示すように、ボリュームキャッシュヒット率監視プログラム330は、例えば、LdevId1について、キャッシュヒット率蓄積テーブル240から「2021/11/26 14:50:02」から「2021/11/26 15:00:02」までのサンプリング間隔内の各時刻のキャッシュヒット率を取得する。
【0135】
ステップ1615:ボリュームキャッシュヒット率監視プログラム330は、サンプリング間隔内のボリュームキャッシュヒット率(=Hit Rate(current))をLdevId毎に算出する。なお、ここでのサンプリング間隔内のボリュームキャッシュヒット率(=Hit Rate(current))は、例えば、サンプリング間隔内の各時刻のボリューム単位のキャッシュヒット率の平均値(即ち、第1パラメータ)である。
【0136】
ステップ1620:ボリュームキャッシュヒット率監視プログラム330は、閾値テーブル290からLdevIdをキーとした閾値キャッシュヒット率(=キャッシュヒット率(第1パラメータ)の最小値(=Hit Rate(past)min))を取得する。図16Bに示すように、ボリュームキャッシュヒット率監視プログラム330は、例えば、LdevId1について、閾値テーブル290から矢印a2が示すレコードの閾値キャッシュヒット率(=0.01)を取得する。
【0137】
ボリュームキャッシュヒット率監視プログラム330は、ステップ1625に進むと、サンプリング間隔内のボリュームキャッシュヒット率(=Hit Rate(current))が閾値キャッシュヒット率(=キャッシュヒット率(第1パラメータ)の最小値(=Hit Rate(past)min)より小さいか否かを判定する。なお、この処理も、LdevId毎に実行される。
【0138】
サンプリング間隔内のボリュームキャッシュヒット率(=Hit Rate(current))が閾値キャッシュヒット率(=Hit Rate(past)min)より小さい場合、ボリュームキャッシュヒット率監視プログラム330は、ステップ1625にて「YES」と判定してステップ1630に進み、サンプリング間隔内のボリュームキャッシュヒット率が閾値キャッシュヒット率より小さいことを、いつもと異なるふるまい(異常ふるまい)として検知する。なお、この判定は各LdevId毎に実行される。
【0139】
その後、ボリュームキャッシュヒット率監視プログラム330は、ステップ1695に進んで本処理フローを一旦終了する。
【0140】
これに対して、サンプリング間隔内のボリュームキャッシュヒット率(=Hit Rate(current))が閾値キャッシュヒット率(=Hit Rate(past)min)以上である場合、ボリュームキャッシュヒット率管理プログラムは、ステップ1625にて「NO」と判定してステップ1695に進んで本処理フローを一旦終了する。
【0141】
図17Aはサーバキャッシュ占用率監視プログラム340が実行する処理フローを示すフローチャートである。図17B図17Aの処理フローの理解を容易にするための具体例を説明するための図である。
【0142】
サーバキャッシュ占用率監視プログラム340は、ステップ1700から処理を開始して以下に述べるステップ1705乃至ステップ1735の処理を順に実行した後、ステップ1740に進む。
【0143】
ステップ1705:サーバキャッシュ占用率監視プログラム340は、初期パラメータテーブル230(初期設定テーブル)からサンプリング間隔を取得する。図17Bに示すように、サーバキャッシュ占用率監視プログラム340は、例えば、LdevId1について、初期パラメータテーブル230から矢印b1が示すレコードのサンプリング間隔600sを取得する。なお、他のLdevIdのそれぞれについても、同様の処理が実行されるが、説明は省略する(以下、同様。)。
【0144】
ステップ1710:サーバキャッシュ占用率監視プログラム340は、現在時刻から遡って、サンプリング間隔内のボリュームキャッシュ占用率を取得する。図17Bの説明文EX2に示すように、サーバキャッシュ占用率監視プログラム340は、LdevId1について、キャッシュ占用率蓄積テーブル250から「2021/11/26 14:50:02」から「2021/11/26 15:00:02」までのサンプリング間隔内の各時刻のボリューム単位のキャッシュ占用率を取得する。
【0145】
ステップ1715:サーバキャッシュ占用率監視プログラム340は、現在のサンプリング間隔内のボリュームキャッシュ占用率(=Occupancy Rate(current)’)をLdevId毎に算出する。なお、ここでのサンプリング間隔内のボリュームキャッシュ占用率(=Occupancy Rate(current)’)は、サンプリング間隔内の各時刻のキャッシュ占用率の平均値(即ち、第2パラメータ計算用パラメータ)である。
【0146】
ステップ1720:サーバキャッシュ占用率監視プログラム340は、ボリュームとホストサーバHSVの関係テーブル(ボリューム-サーバ関係テーブル300)からLdevIdとServerIdの関係を取得する。
【0147】
ステップ1725:サーバキャッシュ占用率監視プログラム340は、ServerId毎に、同一サーバに割り当てられているサンプリング間隔内のボリュームのキャッシュ占用率(第2パラメータ計算用パラメータ)の総和を算出し、そのホストサーバHSVの現在のサーバキャッシュ占用率(=Occupancy Rate(current))(即ち、第2パラメータ)とする。図17Bの説明文EX3に示すように、サーバキャッシュ占用率監視プログラム340は、例えば、ServerId101について、Ldev1,4,5のサンプリング間隔内のキャッシュ占用率(第2パラメータ計算用パラメータ)の総和を算出する。なお、他のServerIdについても、同様の処理が実行されるが、説明は省略する(以下、同様。)。
【0148】
ステップ1730:サーバキャッシュ占用率監視プログラム340は、閾値テーブル290から同一サーバに割り当てられているボリューム毎の閾値キャッシュ占用率(即ち、キャッシュ占用率の最大値(=Occupancy Rate(current)max’))を取得する。
【0149】
ステップ1735:サーバキャッシュ占用率監視プログラム340は、閾値キャッシュ占用率(=Occupancy Rate(current)max’)の総和を算出し、そのホストサーバHSVのサーバキャッシュ占用率の閾値サーバキャッシュ占用率(=Occupancy Rate(current)max)とする。図17Bに示すように、サーバキャッシュ占用率監視プログラム340は、例えば、閾値テーブル290の矢印b2、矢印b3及び矢印b4が示す各レコードのキャッシュ占用率の総和を算出する。
【0150】
サーバキャッシュ占用率監視プログラム340は、ステップ1740に進むと、サンプリング間隔内のサーバキャッシュ占用率(=Occupancy Rate(current))が閾値サーバキャッシュ占用率(=Occupancy Rate(past)max)より大きいか否かを判定する。
【0151】
サンプリング間隔内のサーバキャッシュ占用率(=Occupancy Rate(current))が閾値サーバキャッシュ占用率(=Occupancy Rate(past)max)より大きい場合、サーバキャッシュ占用率監視プログラム340は、ステップ1740にて「YES」と判定してステップ1745に進み、サーバキャッシュ占用率(=Occupancy Rate(current))が閾値サーバキャッシュ占用率(=Occupancy Rate(past)maxより大きいことを、いつもと異なるふるまい(異常ふるまい)として検知する。なお、この判定は、各ServerId毎に実行される。その後、サーバキャッシュ占用率監視プログラム340は、ステップ1795に進んで本処理フローを一旦終了する。
【0152】
これに対して、サンプリング間隔内のサーバキャッシュ占用率(=Occupancy Rate(current))が閾値サーバキャッシュ占用率(=Occupancy Rate(past)max)以下である場合、サーバキャッシュ占用率監視プログラム340は、ステップ1740にて「NO」と判定してステップ1795に進んで本処理フローを一旦終了する。
【0153】
図18Aはデータアクセス速度監視プログラム350が実行する処理フローを示すフローチャートである。図18B図18Aの処理フローの理解を容易にするための具体例を説明するための図である。
【0154】
データアクセス速度監視プログラム350は、ステップ1800から処理を開始して以下に述べるステップ1805乃至ステップ1820の処理を順に実行した後、ステップ1825に進む。
【0155】
ステップ1805:データアクセス速度監視プログラム350は、初期パラメータテーブル230(初期設定テーブル)から、サンプリング間隔を取得する。図18Bに示すように、データアクセス速度監視プログラム350は、例えば、LdevId1について、初期パラメータテーブル230から矢印c1が示すレコードのサンプリング間隔600sを取得する。なお、他のLdevIdのそれぞれについても、同様の処理が実行されるが、説明は省略する(以下、同様。)。
【0156】
ステップ1810:データアクセス速度監視プログラム350は、現在時刻から遡って、サンプリング間隔内のボリューム毎のデータへのアクセス速度を取得する。図18Bの説明文EX3に示すように、ボリュームキャッシュヒット率監視プログラム330は、例えば、LdevId1について、データアクセス速度蓄積テーブル260から「2021/11/26 14:50:02」から「2021/11/26 15:00:02」までのサンプリング間隔内の各時刻のデータアクセス速度を取得する。
【0157】
ステップ1815:データアクセス速度監視プログラム350は、サンプリング間隔内のデータへのアクセス速度(=Access Velocity(current))をLdevId毎に算出する。なお、ここでのサンプリング間隔内のデータへのアクセス速度(データアクセス速度)は、例えば、サンプリング間隔内の各時刻のデータアクセス速度の平均値(即ち、第3パラメータ)である。
【0158】
ステップ1820:データアクセス速度監視プログラム350は、閾値テーブル290からLdevIdをキーとした閾値データアクセス速度(=データアクセス速度(第3パラメータ)の最小値(=Access Velocity(past)min))を取得する。図18Bに示すように、データアクセス速度監視プログラム350は、例えば、LdevId1について、閾値テーブル290から矢印c2が示すレコードの閾値データアクセス速度(=0.14Gbps)を取得する。
【0159】
データアクセス速度監視プログラム350は、ステップ1825に進むと、サンプリング間隔内のデータへのアクセス速度(=Access Velocity(current))が、閾値データアクセス速度(=Access Velocity(past)min)より小さいか否かを判定する。
【0160】
サンプリング間隔内のデータへのアクセス速度(=Access Velocity(current))が、閾値データアクセス速度(=Access Velocity(past)min)より小さい場合、データアクセス速度監視プログラム350はステップ1825にて「YES」と判定してステップ1830に進み、サンプリング間隔内のデータへのアクセス速度(=Access Velocity(current))が、閾値データアクセス速度(=Access Velocity(past)min)より小さいことを、いつもと異なるふるまい(異常ふるまい)として検知する。
【0161】
なお、この判定は各LdevId毎に実行される。その後、データアクセス速度監視プログラム350は、ステップ1895に進んで本処理フローを一旦終了する。
【0162】
これに対して、サンプリング間隔内のデータへのアクセス速度(=Access Velocity(current))が、閾値データアクセス速度(=Access Velocity(past)min)以上である場合、データアクセス速度監視プログラム350は、ステップ1825にて「NO」と判定してステップ1895に進んで本処理フローを一旦終了する。
【0163】
図19Aは閾値フィードバックプログラム360が実行する処理フローを示すフローチャートである。図19B図19Aの処理フローの理解を容易にするための具体例を説明するための図である。
【0164】
閾値フィードバックプログラム360は、ステップ1900から処理を開始して以下に述べるステップ1905乃至ステップ1930の処理を順に実行した後、ステップ1995に進んで本処理フローを一旦終了する。
【0165】
ステップ1905:閾値フィードバックプログラム360は、初期パラメータテーブル230からLdevId毎のサンプリング間隔及び過去データの見る量を取得する。図19Bに示すように、閾値フィードバックプログラム360は、例えば、LdevId1について、初期パラメータテーブル230から矢印d1が示すレコードのサンプリング間隔600s及び過去データの見る量(2019/01/27 10:00:00)を取得する。なお、他のLdevIdのそれぞれについても、同様の処理が実行されるが、説明は省略する(以下、同様。)。
【0166】
ステップ1910:閾値フィードバックプログラム360は、監視間隔テーブル280からLdevId毎の監視間隔を取得する。図19Bに示すように、閾値フィードバックプログラム360は、例えば、LdevId1について、監視間隔テーブル280から矢印d2が示すレコードのキャッシュヒット率監視間隔(86400s)を取得する。
【0167】
ステップ1915:閾値フィードバックプログラム360は、取得した過去データの見る量の値に基づき、キャッシュヒット率蓄積テーブル240、キャッシュ占用率蓄積テーブル250及びデータアクセス速度蓄積テーブル260から、LdevId毎の過去データを取得する。図19Bの説明文EX11に示すように、閾値フィードバックプログラム360は、例えば、LdevId1について、キャッシュヒット率蓄積テーブル240から「2019/1/27 10:00:00」から現在までの蓄積された各時刻のキャッシュヒット率のデータを全部取得する。
【0168】
ステップ1920:閾値フィードバックプログラム360は、LdevId毎の過去データにおいて、監視間隔毎に、サンプリング間隔を用いて、サンプリング間隔内のボリュームのキャッシュヒット率、ボリュームのキャッシュ占用率及びデータへのアクセス速度を算出する。図19Bの説明文EX12に示すように、閾値フィードバックプログラム360は、例えば、上記取得したデータにおいて、86,400s(1day)間隔毎に、600s(10min)をサンプリング間隔として、その10min間のデータを利用して計算する。本例において、例えば、10min間のデータの平均値(即ち、第1パラメータ、第2パラメータ計算用パラメータ、及び、第3パラメータ)を算出する。
【0169】
ステップ1925:閾値フィードバックプログラム360は、算出したLdevId毎のサンプリング間隔内のボリュームのキャッシュヒット率(第1パラメータ)、キャッシュ占用率(第2パラメータ)、及び、データへのアクセス速度(第3パラメータ)から、サンプリング間隔内のボリュームのキャッシュヒット率(即ち、第1パラメータ)の最小値、ボリュームのキャッシュ占用率(即ち、第2パラメータ計算用パラメータ)の最大値、及び、データへのアクセス速度(即ち、第3パラメータ)の最小値を取得する。
【0170】
図19Bの説明文EX13及びグラフGr11に示すように、閾値フィードバックプログラム360は、86,400s(1day)間隔毎に一回計算しているので計算結果(キャッシュヒット率の過去値)が複数ある。それらの計算結果から、キャッシュヒット率(第1パラメータ)の最小値を取り出す(なお、キャッシュ占用率(第2パラメータ計算用パラメータ)の最大値及びデータへのアクセス速度(第3パラメータ)の最小値についても同様。)。
【0171】
ステップ1930:閾値フィードバックプログラム360は、取得したキャッシュヒット率(第1パラメータ)の最小値、ボリュームのキャッシュ占用率(第2パラメータ計算用パラメータ)の最大値及びデータへのアクセス速度(即ち、第3パラメータ)の最小値により、LdevIdをキーとした閾値テーブル290を更新する。
【0172】
図20Aは監視間隔フィードバックプログラム370が実行する処理フローを示すフローチャートである。図20B図20Aの処理フローの理解を容易にするための図である。
【0173】
監視間隔フィードバックプログラム370は、ステップ2000から処理を開始して以下に述べるステップ2005乃至ステップ2015の処理の並行実行を開始させた後、ステップ2020に進む。
【0174】
ステップ2005:監視間隔フィードバックプログラム370は、キャッシュヒット率蓄積テーブル240に蓄積したデータからLdevId毎のキャッシュヒット率の変化傾向を記録する。
【0175】
ステップ2010:監視間隔フィードバックプログラム370は、キャッシュ占用率蓄積テーブル250に蓄積したデータからLdevId毎のキャッシュ占用率の変化傾向を記録する。
【0176】
ステップ2015:監視間隔フィードバックプログラム370は、データアクセス速度蓄積テーブル260に蓄積したデータからLdevId毎のデータへのアクセス速度の変化傾向を記録する。
【0177】
その後、監視間隔フィードバックプログラム370は、以下に述べるステップ2020及びステップ2025の処理を順に実行した後、ステップ2095に進んで本処理フローを一旦終了する。
【0178】
ステップ2020:監視間隔フィードバックプログラム370は、同一LdevIdにおいて、同様の変化傾向間の間隔を算出する。図20BのグラフGr21に示すように、監視間隔フィードバックプログラム370は、例えば、キャッシュヒット率について同様の変化が現れた第1時点t1と第2時点t2との間の監視間隔(t2-t1)を算出する。なお、キャッシュ占用率及びデータへのアクセス速度についても同様である。
【0179】
ステップ2025:監視間隔フィードバックプログラム370は、算出した結果によって、LdevIdをキーとして監視間隔テーブル280を更新する。
【0180】
<ステップ1340>
上述したステップ1340の処理の詳細を図21A乃至図22Bを用いて説明する。図21Aはランサムウェア判定プログラム(キャッシュヒット率観点)380が実行する処理フローを示すフローチャートである。図21B図21Aの処理フローの理解を容易にするための具体例を説明するための図である。ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2100から処理を開始して以下に述べるステップ2105及びステップ2110の処理を順に実行した後、ステップ2115に進む。
【0181】
ステップ2105:ランサムウェア判定プログラム(キャッシュヒット率観点)380は、キャッシュヒット率における、異常ふるまいが検知されたボリュームのLdevIdを取得する。図21Bに示すように、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、例えば、異常ふるまいが検知されたボリュームのLdevId1を取得する。
【0182】
ステップ2110:ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ボリューム-サーバ関係テーブル300を参照して、該当ボリュームの割り当てられているホストサーバHSVのServerIdを特定する。図21Bに示すように、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、例えば、ボリューム-サーバ関係テーブル300を参照して、LdevId1のボリュームが割り当てられているServerId101を特定する。
【0183】
ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2115に進むと、該当ホストサーバHSV内に、同様なキャッシュヒット率傾向が現れる他ボリュームがあるのか否かを判定する。これにより、ランサムウェアによる大量のデータアクセスが行われている可能性が高いかどうかを判定できる。なお、ステップ2115の判定は、便宜上、「第1判定」とも称呼される場合がある。図21Bの説明文EX21に示すように、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ボリューム-サーバ関係テーブル300を参照して、ServerId101に割り当てられている他のLdevId4及びLdevId5を特定する。ランサムウェア判定プログラム(キャッシュヒット率観点)380は、キャッシュヒット率蓄積テーブル240を参照して、他のLdevId4及びLdevId5に、LdevId1のボリュームのキャッシュヒット率の傾向と同様なキャッシュヒット率傾向(異常ふるまい)が現れているか否かを判定する。
【0184】
該当サーバ内に、同様なキャッシュヒット率傾向が現れる他ボリュームがない場合、ランサムウェアによる大量のデータアクセスが行われている可能性が低い。従って、この場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2115にて「NO」と判定してステップ2195に進んで本処理フローを一旦終了する。
【0185】
これに対して、該当サーバ内に、同様なキャッシュヒット率傾向が現れる他ボリュームがある場合、ランサムウェアによる大量のデータアクセスが行われている可能性が高い。従って、この場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2115にて「YES」と判定してステップ2120に進む。
【0186】
ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2120に進むと、それらのボリュームのIOPSは普段よりも大きいか否かを判定する。普段より大きいか否かは、例えば、所定の閾値IOPSと比較することにより、判定される。これにより、異常ふるまいがウイルススキャンによるふるまいである可能性が高いか否かを判定できる。なお、ステップ2120の判定は、便宜上、「第2判定」とも称呼される場合がある。
【0187】
それらのボリュームのIOPSは普段以下である場合、異常ふるまいがウイルススキャンによるふるまいである可能性が高いと考えられる。従って、この場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2120にて「NO」と判定してステップ2195に進んで本処理フローを一旦終了する。
【0188】
それらのボリュームのIOPSは普段よりも大きい場合、異常ふるまいがウイルススキャンによるふるまいである可能性が低いと考えられる。従って、この場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2120にて「YES」と判定してステップ2125に進む。
【0189】
ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2125に進み、キャッシュヒット率はいつもの傾向に戻ったボリュームがないか否かを判定する。図21Bの説明文EX22に示すように、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、例えば、LdevId1、LdevId4及びLdevId5のボリュームのうち、キャッシュヒット率がいつもの傾向に戻ったボリュームがないか否かを判定する。換言すると、LdevId1、LdevId4及びLdevId5のボリュームのうち、キャッシュヒット率がいつもの傾向に戻った(異常ふるまいが検知されなくなった)ボリュームが存在するか否かを判定する。ランサムウェアによるデータの搾取後データ破棄するため、ボリュームキャッシュヒット率が下がったとしてもまたいつもの傾向にも戻らない。従って、ボリュームキャッシュヒット率が低下していつもの傾向に戻るか否かを判定することにより、異常ふるまいがランサムウェアに起因するふるまいであるか否かを判定できる。なお、ステップ2125の判定は、便宜上、「第3判定」とも称呼される場合がある。
【0190】
キャッシュヒット率がいつもの傾向に戻ったボリュームがある場合、キャッシュヒット率の低下はランサムウェアによるものだという可能性が低い。従って、この場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2125にて「NO」と判定してステップ2195に進んで本処理フローを一旦終了する。
【0191】
キャッシュヒット率がいつもの傾向に戻ったボリュームがない場合、キャッシュヒット率の低下はランサムウェアによるものだという可能性が高い。従って、この場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2125にて「YES」と判定してステップ2130に進む。
【0192】
ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2130に進むと、ストレージシステム100を複数台のホストサーバHSVで使用しているか否かを判定する。なお、ステップ2130の判定は、便宜上、「第4判定」とも称呼される場合がある。
【0193】
ストレージシステム100を複数台のホストサーバHSVで使用している場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2130にて「YES」と判定してステップ2135に進む。
【0194】
ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2135に進むと、他のホストサーバHSVのボリュームも同様なキャッシュヒット率傾向となっているか否か(異常ふるまいが検知されたか否か)を判定する。図21Bの説明文EX23に示すように、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、例えば、他のServerId102に割り当てられているLdevId2、LdevId6及びLdevId3のボリュームが、LdevId1のキャッシュヒット率と同様なキャッシュヒット率傾向となっているか否かを判定する。なお、ステップ2135の判定は、便宜上、「第5判定」とも称呼される場合がある。
【0195】
他のホストサーバHSVのボリュームも同様なキャッシュヒット率傾向となっている場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2135にて「YES」と判定してステップ2140に進んで、異常ふるまいをランサムウェアとして検知する(即ち、異常ふるまいをランサムウェアに起因するふるまい(ランサムウェアに起因する不正データアクセス)として検知する。)。その後、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2195に進んで本処理フローを一旦終了する。
【0196】
これに対して、他のホストサーバHSVのボリュームも同様なキャッシュヒット率傾向となっていない場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2135にて「NO」と判定してステップ2195に進んで本処理フローを一旦終了する。
【0197】
なお、ステップ2130にて、ストレージシステム100を複数台のホストサーバHSVで使用していない場合、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2130にて「NO」と判定して、ステップ2140に進み、異常ふるまいをランサムウェアとして検知する(即ち、異常ふるまいをランサムウェアに起因するふるまい(ランサムウェアに起因する不正データアクセス)として検知する。)。その後、ランサムウェア判定プログラム(キャッシュヒット率観点)380は、ステップ2195に進んで本処理フローを一旦終了する。
【0198】
図22Aはランサムウェア判定プログラム(データアクセス速度観点)390が実行する処理フローを示すフローチャートである。図22B図22Aの処理フローの理解を容易にするための具体例を説明するための図である。ランサムウェア判定プログラム(データアクセス速度観点)390は、ステップ2200から処理を開始して以下に述べるステップ2205及びステップ2210の処理を順に実行した後、ステップ2215に進む。
【0199】
ステップ2205:ランサムウェア判定プログラム(データアクセス速度観点)390は、データへのアクセス速度について、異常ふるまいが検知されたボリュームのLdevIdを取得する。図22Bに示すように、ランサムウェア判定プログラム(データアクセス速度観点)390は、例えば、異常ふるまいが検知されたボリュームのLdevId1を取得する。
【0200】
ステップ2210:ランサムウェア判定プログラム(データアクセス速度観点)390は、ボリューム-サーバ関係テーブル300を参照して、該当ボリュームの割り当てられているホストサーバHSVのServerIdを特定する。図22Bに示すように、ランサムウェア判定プログラム(データアクセス速度観点)390は、例えば、ボリューム-サーバ関係テーブル300の矢印g2が示すレコードからLdevId1のボリュームが割り当てられているServerId101を特定する。
【0201】
その後、ランサムウェア判定プログラム(データアクセス速度観点)390は、ステップ2215に進み、他のホストサーバHSVのボリュームも同様な傾向となっているか否かを判定する。図22Bの説明文EX31に示すように、ランサムウェア判定プログラム(データアクセス速度観点)390は、例えば、他のServerId102に割り当てられているLdevId2及びLdevId6、他のServerId103に割り当てられているLdevId3のボリュームのデータアクセス速度が、LdevId1と同様なデータアクセス速度傾向(即ち、異常ふるまい)となっているか否かを判定する。
【0202】
他のホストサーバHSVのボリュームも同様な傾向となっている場合、ランサムウェア判定プログラム(データアクセス速度観点)390は、ステップ2215にて「YES」と判定してステップ2220に進み、異常ふるまいをランサムウェアとして検知する(即ち、異常ふるまいをランサムウェアに起因するふるまい(ランサムウェアに起因する不正データアクセス)として検知する。)。その後、ランサムウェア判定プログラム(データアクセス速度観点)390は、ステップ2295に進んで本処理フローを一旦終了する。
【0203】
これに対して、他のホストサーバHSVのボリュームも同様な傾向となっていない場合、ランサムウェア判定プログラム(データアクセス速度観点)390は、ステップ2215にて「NO」と判定してステップ2295に進んで本処理フローを一旦終了する。
【0204】
<効果>
以上説明したように、本発明の実施形態に係るストレージシステム100は、ランサムウェアによるデータ暗号化に至る前段階で、ランサムウェア(ランサムウェアによる不正なデータアクセス)を早期に検知することができる。ストレージシステム100は、セキュリティ対策ソフトなどを用いらずに、クライアントOSにも依存せず、ストレージレイヤでランサムウェアによるデータ窃取(データ窃取時の不正なデータアクセス)を検出することができる。ストレージシステム100は、データそのものの分析ではなく、ストレージシステム100に固有のキャッシュヒット率やIOPSなどの指標を用いることでデータの中身によらず、ランサムウェアによる不正なデータアクセスを精度よく検知でき、セキュリティ対策を行うことができる。ストレージシステム100は、事前の攻撃パターン分析やシグネチャーに頼らず、学習期間も設けず、常にデータへのアクセス傾向を監視し、今までに蓄積した通常時のパターンの情報と照合することで、通常業務をしながら、ランサムウェアの攻撃による不正アクセスを検出することができる。
【0205】
<<変形例>>
本発明は上記実施形態に限定されることなく、本発明の範囲内において種々の変形例を採用することができる。
【0206】
(変形例1)
上記実施形態において、「ランサムウェア判定」を省略して、異常ふるまいが検知された場合、その異常ふるまいがランサムウェアに起因する不正アクセスとして検知されて、「不正アクセス対応処理」が実行されるようにしてもよい。
(変形例2)
上記実施形態において、異常ふるまい検知処理1乃至異常ふるまい検知処理3の何れか一つの処理又は2つの処理が実行されることによって、異常ふるまいが検知されるようにしてもよい。
(変形例3)
上記実施形態において、閾値フィードバック及び監視間隔フィードバックの何れか一つが実行されるようにしてもよい。
(変形例4)
上記実施形態において、閾値フィードバック及び監視間隔フィードバックが省略されてもよい。
(変形例5)
上記実施形態において、(ランサムウェア判定チェック(キャッシュヒット率観点)及びランサムウェア判定チェック(データアクセス速度観点)の何れか一つが実行されるようにしてもよい。
(変形例6)
上記実施形態において、図21Aのステップ2130及びステップ2135の処理が省略されてもよい。
【符号の説明】
【0207】
100…ストレージシステム、200…コントローラ、210…CPU、220…メモリ、310…初期設定変更プログラム、320…データ蓄積プログラム、330…ボリュームキャッシュヒット率監視プログラム、340…サーバキャッシュ占用率監視プログラム、350…データアクセス速度監視プログラム、360…閾値フィードバックプログラム、370…監視間隔フィードバックプログラム、380…ランサムウェア判定プログラム(キャッシュヒット率観点)、390…ランサムウェア判定プログラム(データアクセス速度観点)、400…キャッシュ、420…DPボリューム
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10A
図10B
図11A
図11B
図12
図13
図14
図15
図16A
図16B
図17A
図17B
図18A
図18B
図19A
図19B
図20A
図20B
図21A
図21B
図22A
図22B