JP2023183886A - ストレージシステム及び不正アクセス検知方法 - Google Patents

Abstract

【課題】クライアントＯＳがコントロールできなくなった場合においてもストレージレイヤでランサムウェアによるデータ暗号化に至る前段階のデータ窃取時の不正アクセスを検知できるストレージシステム及び不正アクセス検知方法を提供する。【解決手段】ストレージシステムのコントローラは、第１パラメータが第１閾値パラメータより小さいことを、異常ふるまいとして検知する第１異常ふるまい検知処理、第２パラメータが第２閾値パラメータより大きいことを、異常ふるまいとして検知する第２異常ふるまい検知処理、及び、第３パラメータが第３閾値パラメータより小さいことを、異常ふるまいとして検知する第３異常ふるまい検知処理の少なくとも一つを含む異常ふるまい検知処理を実行する。【選択図】図１

Description

本発明は、ストレージシステム及び不正アクセス検知方法に関する。

従来のランサムウェアによるサイバー攻撃は、データを暗号化し、利用不能とさせ、復元のための身代金を要求するものだった。このようなランサムウェアであれば、暗号化前にバックアップを取得することで、身代金を支払う必要なく復旧可能となる。

一方、近年のランサムウェアは、従来の手法に加え、データを暗号化する前に、あらかじめデータ窃取を行い、窃取したデータを公開すると脅迫し、さらに身代金を要求するという２重脅迫を行う傾向にある。このようなランサムウェアを対策するために、データ窃取される段階での早期検知が必要となる。

本発明に関連する技術としては、特許文献１及び特許文献２が開示する従来技術がある。特許文献１は、コンピュータにより実行されるランサムウェア検知方法を開示する。このランサムウェア検知方法は、ファイル・アクセス・ログを定期的に監視する。ランサムウェア検知方法は、許可されたファイル・アクセスのレコードのうち、ランサムウェアが典型的に行なうファイル・アクセスの頻度が所定の閾値を超えた場合には、ランサムウェアによる攻撃の可能性があると判定し、対策を取る。対策には、ファイル・アクセス制御手段に指令を送り、ファイル・アクセスを遮断することが含まれる。

特許文献２は、ホストに提供される第１のボリュームと、第１のボリュームのバックアップデータまたはスナップショットイメージを格納する第２のボリュームとがあるストレージシステムを開示する。

ストレージシステムのコントローラは、第１のボリュームにおけるバックアップデータまたはスナップショットイメージを所定の間隔で定期的に取得し、第１のボリュームにおけるホストのアクセス情報とボリューム使用容量とを含む監視情報を取得する。コントローラは、取得した監視情報を用い第１のボリュームにおける通常使用における定常状態を設定し、設定した定常状態から逸脱したボリュームにおけるアクセス挙動を検知する。

国際公開第２０１９／０７３７２０号 特開２０２０－２０１７０３号公報

従来技術（特許文献１）では、ランサムウェアによる不正アクセスによって、クライアントＯＳ上のセキュリティ対策ソフト、プログラム及びログ生成が不正に停止される場合、ランサムウェアを検知できなくなることが生じ得る。

従来技術（特許文献２）は、不正なデータ暗号化を検知する技術であって、ストレージシステム（ストレージレイヤ）でデータ窃取時の不正アクセスを検知することができないため、近年のランサムウェアの動向である不正なデータ暗号化の前に実行されるデータ窃取に対応できない。

本発明は上記課題を解決するためになされた。即ち、本発明の目的の一つは、クライアントＯＳがコントロールできなくなった場合においてもストレージレイヤでランサムウェアによるデータ暗号化に至る前段階のデータ窃取時の不正アクセスを検知できるストレージシステム及び不正アクセス検知方法を提供することにある。

上記課題を解決するために、本発明のストレージシステムは、コントローラとデータをキャッシュするキャッシュとを含み、複数のボリュームを１又は複数の計算機に提供するストレージシステムであって、前記コントローラは、所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第１パラメータを取得し、前記第１パラメータが第１閾値パラメータより小さいことを、異常ふるまいとして検知する第１異常ふるまい検知処理、所定のサンプリング間隔内の前記ボリュームに関連するサーバのサーバキャッシュ占用率に基づく第２パラメータを取得し、前記第２パラメータが第２閾値パラメータより大きいことを、異常ふるまいとして検知する第２異常ふるまい検知処理、及び、所定のサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第３パラメータを取得し、前記第３パラメータが第３閾値パラメータより小さいことを、異常ふるまいとして検知する第３異常ふるまい検知処理、の少なくとも一つを含む異常ふるまい検知処理を実行するように構成されている。

本発明の不正アクセス検知方法は、コントローラとデータをキャッシュするキャッシュとを含み、複数のボリュームを１又は複数の計算機に提供するストレージシステムにおける不正アクセス検知方法であって、前記コントローラによって、所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第１パラメータを取得し、前記第１パラメータが第１閾値パラメータより小さいことを、異常ふるまいとして検知する第１異常ふるまい検知、所定のサンプリング間隔内の前記ボリュームに関連するサーバのサーバキャッシュ占用率に基づく第２パラメータを取得し、前記第２パラメータが第２閾値パラメータより大きいことを、異常ふるまいとして検知する第２異常ふるまい検知、及び、所定のサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第３パラメータを取得し、前記第３パラメータが第３閾値パラメータより小さいことを、異常ふるまいとして検知する第３異常ふるまい検知、の少なくとも一つを含む異常ふるまい検知を実行する。

本発明によれば、クライアントＯＳがコントロールできなくなった場合においてもストレージレイヤでランサムウェアによるデータ暗号化に至る前段階のデータ窃取時の不正アクセスを検知できる。

図１は本発明の実施形態に係るストレージシステムの構成例を示す概略構成図である。 図２は初期パラメータテーブルを説明するための図である。 図３はキャッシュヒット率蓄積テーブルを説明するための図である。 図４はキャッシュ占用率蓄積テーブルを説明するための図である。 図５はデータアクセス速度蓄積テーブルを説明するための図である。 図６はＩＯＰＳ蓄積テーブルを説明するための図である。 図７は監視間隔テーブルを説明するための図である。 図８は閾値テーブルを説明するための図である。 図９はボリューム－サーバ関係テーブルを説明するための図である。 図１０Ａは検知観点１を説明するための図である。 図１０Ｂは検知観点１を説明するための図である。 図１１Ａは検知観点２を説明するための図である。 図１１Ｂは検知観点２を説明するための図である。 図１２は検知観点３を説明するための図である。 図１３はストレージシステムが実行する全体処理の流れを説明するための処理フローを示すフローチャートである。 図１４は初期設定変更プログラムが実行する処理フローを示すフローチャートである。 図１５はデータ蓄積プログラムが実行する処理フローを示すフローチャートである。 図１６Ａはボリュームキャッシュヒット率監視プログラムが実行する処理フローを示すフローチャートである。 図１６Ｂは図１６Ａの処理フローの理解を容易にするための具体例を説明するための図である。 図１７Ａはサーバキャッシュ占用率監視プログラムが実行する処理フローを示すフローチャートである。 図１７Ｂは図１７Ａの処理フローの理解を容易にするための具体例を説明するための図である。 図１８Ａはデータアクセス速度監視プログラムが実行する処理フローを示すフローチャートである。 図１８Ｂは図１８Ａの処理フローの理解を容易にするための具体例を説明するための図である。 図１９Ａは閾値フィードバックプログラムが実行する処理フローを示すフローチャートである。 図１９Ｂは図１９Ａの処理フローの理解を容易にするための具体例を説明するための図である。 図２０Ａは監視間隔フィードバックプログラムが実行する処理フローを示すフローチャートである。 図２０Ｂは図２０Ａの処理フローの理解を容易にするための図である。 図２１Ａはランサムウェア判定プログラム（キャッシュヒット率観点）が実行する処理フローを示すフローチャートである。 。図２１Ｂは図２１Ａの処理フローの理解を容易にするための具体例を説明するための図である。 図２２Ａはランサムウェア判定プログラム（データアクセス速度観点）が実行する処理フローを示すフローチャートである。 図２２Ｂは図２２Ａの処理フローの理解を容易にするための具体例を説明するための図である。

以下、本発明の実施形態について図面を参照しながら説明する。実施形態の全図において、同一又は対応する部分には同一の符号を付す場合がある。

以下の説明では、識別情報について説明する際、「識別番号」等の表現を用いるが、これら以外の識別情報（例えば、名称等）に置換されてもよい。また、以下の説明では、プログラム又は機能ブロックを主語として処理を説明する場合があるが、処理の主語が、機能ブロックに代えて、コントローラ又はＣＰＵとされてもよい。また、以下の説明では、「テーブル」、「レコード」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されてもよい。

＜＜実施形態＞＞
図１は本発明の実施形態に係るストレージシステム１００を含むシステムの構成例を示す概略構成図である。図１に示すよう、システムは、ストレージシステム１００と、複数（本例においてＮ個（Ｎ≧４以上））のホストサーバ（１）ＨＳＶ１乃至ホストサーバ（Ｎ）ＨＳＶＮと、を含む。

なお、ホストサーバ（１）ＨＳＶ１乃至ホストサーバ（Ｎ）ＨＳＶＮは、これらを特に区別する必要がない場合、「ホストサーバＨＳＶ」と称呼される。ホストサーバＨＳＶは、単にサーバとも称呼される場合がある。ホストサーバＨＳＶＮは一つであってもよい。ストレージシステム１００とホストサーバＨＳＶとは、ネットワークＮＷ１を介してデータ（情報）を送受信可能に接続されている。

ストレージシステム１００は、コントローラ２００を含む。コントローラ２００は、ストレージとしての機能をホストサーバＨＳＶに提供するために必要なソフトウェアが実装された装置である。

コントローラ２００は、ＣＰＵ２１０と、メモリ２２０と、を含む。ＣＰＵ２１０は、コントローラ２００の全体の動作制御を司るハードウェアである。ＣＰＵ２１０は、ホストサーバＨＳＶからポート５００を介して与えられたＩ／Ｏ要求であるリードコマンドやライトコマンドに応じて、データを読み書きする。

メモリ２２０は、例えば、ＳＤＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の半導体メモリから構成され、各種プログラムやデータを記憶（保持、格納）するために利用される。

メモリ２２０は、ＣＰＵ２１０の主記憶装置であり、以下に述べるように、ＣＰＵ２１０が実行するプログラムや、ＣＰＵ２１０が参照する各種テーブル等が格納される。

メモリ２２０は、初期パラメータテーブル２３０、キャッシュヒット率蓄積テーブル２４０、キャッシュ占用率蓄積テーブル２５０、データアクセス速度蓄積テーブル２６０、ＩＯＰＳ蓄積テーブル２７０、監視間隔テーブル２８０、閾値テーブル２９０及びボリューム－サーバ関係テーブル３００を記憶する。なお、これらのテーブルの詳細は、後に説明する。

メモリ２２０は、初期設定変更プログラム３１０、データ蓄積プログラム３２０、ボリュームキャッシュヒット率監視プログラム３３０、サーバキャッシュ占用率監視プログラム３４０、データアクセス速度監視プログラム３５０、閾値フィードバックプログラム３６０、監視間隔フィードバックプログラム３７０、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０及びランサムウェア判定プログラム（データアクセス速度観点）３９０を記憶する。なお、これらプログラムの詳細は、後に説明する。これらのプログラムは、ＣＰＵ２１０によって実行される。

ストレージシステム１００は、キャッシュ４００と、プール４１０と、ＤＰボリューム４２０と、プールボリューム４３０とを含む。キャッシュ４００は、データを一時的に格納するための高速アクセス可能なメモリである。キャッシュ４００は、ストレージシステム１００のＩ／Ｏ処理のスループット及びレスポンスを向上させるために設けられている。

プール４１０は、ストレージシステム１００が備えるＳＤＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、フラッシュメモリ等の各記憶装置が提供する論理的な記憶領域である複数のプールボリューム４３０（実ボリューム）により構成されている。例えば、プール４１０は、高速な記憶装置（例えば、ＦＭＤ（Ｆｌａｓｈ Ｍｏｄｕｌｅ Ｄｒｉｖｅ））、ＳＳＤ、ＦＣドライブ、ＳＡＳドライブ等）と、低速な記憶装置（例えば、ＳＡＴＡドライブ等）とを混在させて構成される。記憶領域は、対応する記憶装置の応答性に応じて、複数の階層（ＴｉｅｒＮ（Ｎは２以上の整数））に分けて管理されている。なお、本例においては、Ｔｉｅｒ１（ｔｉｒｅ１）、Ｔｉｅｒ２（ｔｉｒｅ２）及びＴｉｅｒ３（ｔｉｒｅ３）の３個の階層に分けて管理されている。データは、そのデータに対するアクセス頻度に応じた層に自動配置される。例えば、アクセス頻度の高いデータについては、より高い階層に自動配置され、アクセス頻度の低いデータについては、より低い階層に自動配置される。

複数のＤＰボリューム４２０は、ストレージシステム１００内に定義された仮想的な論理ボリュームであり、ホストサーバＨＳＶに提供される。ＤＰボリューム４２０は、ホストサーバＨＳＶから認識される論理的な記憶領域であり、ホストサーバＨＳＶからのリード要求／ライト要求の発行対象となる記憶領域である。

ＤＰボリューム４２０は、ホストサーバＨＳＶに割り当てられる。コントローラ２００は、ホストサーバＨＳＶによるＤＰボリューム４２０に対するデータの書き込みに応じて実領域（プールボリューム４３０）を使用することで、ストレージリソースである各記憶装置を有効に利用する。

ホストサーバＨＳＶは、Ｉ／Ｏ要求を発行する計算機（サーバ装置）である。ホストサーバＨＳＶは、物理的な計算機であってもよく、仮想的な計算機であってもよい。ホストサーバＨＳＶは、ＨＢＡ（ホストバスアダプタ）を備える。ホストサーバＨＳＶは、ＨＢＡ及びネットワークＮＷ１を介してストレージシステム１００のポート５００に接続される。

図２は初期パラメータテーブル２３０を説明するための図である。図２に示すように、初期パラメータテーブル２３０は、情報（値）を格納する列（カラム）として、ＬｄｅｖＩｄ２３１と、監視開始時刻２３２と、サンプリング間隔２３３と、過去データの見る量２３４と、を含む。初期パラメータには、データ監視に関する各列に対応する情報が互いに関連づけられて行単位の情報（レコード）として格納されている。具体的に述べると、ＬｄｅｖＩｄ２３１には、ＬＤＥＶ（ＤＰボリューム４２０）を識別するための識別番号が格納されている。

監視開始時刻２３２には、監視を開始する時刻が格納されている。デフォルト値の場合、監視開始時刻２３２には、例えば、ＬＤＥＶの作成時刻、システム設計者やソフトウェア設計者が設計した値が格納される。サンプリング間隔２３３には、監視のサンプリング間隔が格納されている。デフォルト値の場合、サンプリング間隔２３３には、システム設計者やソフトウェア設計者が設計した値が格納される。過去データの見る量２３４には、過去データの見る量を特定するための情報が格納されている。本例において、過去データの見る量２３４には、過去データを見る範囲の開始時刻が格納されている。

図３はキャッシュヒット率蓄積テーブル２４０を説明するための図である。図３に示すように、キャッシュヒット率蓄積テーブル２４０は、情報（値）を格納する列（カラム）として、ＬｄｅｖＩｄ２４１と、時刻２４２と、キャッシュヒット率２４３と、を含む。キャッシュヒット率蓄積テーブル２４０には、キャッシュヒット率に関する各列に対応する情報が互いに関連づけられて行単位の情報（レコード）として格納されている。具体的に述べると、ＬｄｅｖＩｄ２４１には、ＬＤＥＶ（ＤＰボリューム４２０）を識別するための識別番号が格納されている。時刻２４２には、キャッシュヒット率が検出された時刻が格納されている。キャッシュヒット率２４３には、キャッシュヒット率が格納されている。なお、「キャッシュヒット率」とは、キャッシュヒットの確率である。「キャッシュヒット」とは、キャッシュ４００にアクセスしたときにライト又はリードの対象のデータが見つかることである。

図４はキャッシュ占用率蓄積テーブル２５０を説明するための図である。図４に示すように、キャッシュ占用率蓄積テーブル２５０は、情報（値）を格納する列（カラム）として、ＬｄｅｖＩｄ２５１と、時刻２５２と、キャッシュヒット率２５３と、を含む。キャッシュ占用率蓄積テーブル２５０には、キャッシュ占用率に関する各列に対応する情報が互いに関連づけられて行単位の情報（レコード）として格納されている。具体的に述べると、ＬｄｅｖＩｄ２５１には、ＬＤＥＶ（ＤＰボリューム４２０）を識別するための識別番号が格納されている。時刻２５２には、キャッシュ占用率が検出された時刻が格納されている。キャッシュ占用率２５３には、キャッシュ占用率が格納されている。なお、キャッシュ占用率とは、キャッシュ４００の容量に対するボリュームに割り当てられたキャッシュ４００の容量の比率である。

図５はデータアクセス速度蓄積テーブル２６０を説明するための図である。図５に示すように、データアクセス速度蓄積テーブル２６０は、情報（値）を格納する列（カラム）として、ＬｄｅｖＩｄ２６１と、時刻２６２と、データアクセス速度２６３と、を含む。データアクセス速度蓄積テーブル２６０には、データアクセス速度に関する各列に対応する情報が互いに関連づけられて行単位の情報（レコード）として格納されている。具体的に述べると、ＬｄｅｖＩｄ２６１には、ＬＤＥＶ（ＤＰボリューム４２０）を識別するための識別番号が格納されている。時刻２６２には、データアクセス速度が検出された時刻が格納されている。データアクセス速度２６３には、データへのアクセス速度（データアクセス速度）が格納されている。

図６はＩＯＰＳ蓄積テーブル２７０を説明するための図である。図６に示すように、ＩＯＰＳ蓄積テーブル２７０は、情報（値）を格納する列（カラム）として、ＬｄｅｖＩｄ２７１と、時刻２７２と、ＩＯＰＳ２７３と、を含む。ＩＯＰＳ蓄積テーブル２７０には、ＩＯＰＳに関する各列に対応する情報が互いに関連づけられて行単位の情報（レコード）として格納されている。具体的に述べると、ＬｄｅｖＩｄ２７１には、ＬＤＥＶ（ＤＰボリューム４２０）を識別するための識別番号が格納されている。時刻２７２には、ＩＯＰＳ（Input/Output Per Second）が検出された時刻が格納されている。ＩＯＰＳ２７３には、ＩＯＰＳが格納されている。なお、ＩＯＰＳは、ストレージが１秒あたりに処理できるＩ／Ｏアクセスの数である。

図７は監視間隔テーブル２８０を説明するための図である。図７に示すように、監視間隔テーブル２８０は、情報（値）を格納する列（カラム）として、ＬｄｅｖＩｄ２８１と、キャッシュヒット率監視間隔２８２と、キャッシュ占用率監視間隔２８３と、データへのアクセス速度監視間隔２８４と、を含む。監視間隔テーブル２８０には、監視間隔に関する各列に対応する情報が互いに関連づけられて行単位の情報（レコード）として格納されている。具体的に述べると、ＬｄｅｖＩｄ２８１には、ＬＤＥＶ（ＤＰボリューム４２０）を識別するための識別番号が格納されている。キャッシュヒット率監視間隔２８２には、キャッシュヒット率監視間隔を示す時間が格納されている。キャッシュ占用率監視間隔２８３には、キャッシュ占用率監視間隔を示す時間が格納されている。データへのアクセス速度監視間隔２８４には、データへのアクセス速度監視間隔を示す時間が格納されている。

図８は閾値テーブル２９０を説明するための図である。図８に示すように、閾値テーブル２９０は、情報（値）を格納する列（カラム）として、ＬｄｅｖＩｄ２９１と、キャッシュヒット率２９２と、キャッシュ占用率２９３と、データへのアクセス速度２９４と、を含む。閾値テーブル２９０には、閾値に関する各列に対応する情報が互いに関連づけられて行単位の情報（レコード）として格納されている。具体的に述べると、ＬｄｅｖＩｄ２９１には、ＬＤＥＶ（ＤＰボリューム４２０）を識別するための識別番号が格納されている。キャッシュヒット率２９２には、閾値キャッシュヒット率が格納されている。キャッシュ占用率２９３には、閾値キャッシュ占用率が格納されている。データへのアクセス速度２９４には、閾値アクセス速度が格納されている。

図９はボリューム－サーバ関係テーブル３００を説明するための図である。図９に示すように、ボリューム－サーバ関係テーブル３００は、情報（値）を格納する列（カラム）として、ＳｅｒｖｅｒＩｄ３０１と、ＬｄｅｖＩｄ３０２と、を含む。ボリューム－サーバ関係テーブル３００には、ボリュームとサーバとの関係に関する各列に対応する情報が互いに関連づけられて行単位の情報（レコード）として格納されている。具体的に述べると、ＳｅｒｖｅｒＩｄ３０１には、ホストサーバＨＳＶを識別するための識別番号が格納されている。ＬｄｅｖＩｄ３０２には、ＬＤＥＶ（ＤＰボリューム４２０）を識別するための識別番号が格納されているが格納されている。

＜概要＞
本発明の実施形態に係るストレージシステム１００は、ランサムウェアによる不正アクセスを検知する。まず本発明の理解を容易にするため、ストレージシステム１００が、ランサムウェアによる不正アクセスの検知に利用する検知観点１乃至検知観点３について説明する。

（検知観点１）
図１０Ａ及び図１０Ｂは、検知観点１を説明するためのシステムの概略図である。このシステムは、サーバＳＶ１及びストレージシステム１００を含む。図１０Ａは、サーバＳＶ１の通常運用におけるアプリケーション１のデータの参照状態を示し、図１０ＢはサーバＳＶ１がランサムウェアＲＳＭに感染した状態のデータの参照状態を示す。図１０Ａ及び図１０Ｂにおいて、サーバＳＶ１は、ホストサーバＨＳＶに対応し、ＶＯＬ１乃至ＶＯＬ５は、サーバＳＶ１に割り当てられた仮想ボリュームであるＤＰボリューム４２０に対応する。キャッシュＣＡ１は、キャッシュ４００に対応し、ボリュームＰＶ１はプールボリューム４３０に対応する（図１１Ａ及び図１１Ｂにおいても同様。）。矢印はデータのアクセス元及びアクセス先（参照元及び参照先）を示す（図１１Ａ及び図１１Ｂにおいても同様。）。

図１０Ａに示すように、通常運用において、サーバＳＶ１内の１つのアプリケーション１ＡＰ１が常に該当サーバＳＶ１のＶＯＬ１乃至ＶＯＬ５の全てのデータを参照することは考えにくい。例えば、安定稼働しているシステムでの通常運用では、サーバＳＶ１内のアプリケーション１ＡＰ１が常にＶＯＬ１を参照している。

これに対して、図１０Ｂに示すように、サーバＳＶ１がランサムウェアＲＳＭに感染した場合、ランサムウェアＲＳＭによるデータ窃取で、大量のデータにアクセスする。例えば、ランサムウェアＲＳＭはＶＯＬ１乃至ＶＯＬ５の全てを参照する。更に、ランサムウェアＲＳＭは、ＶＯＬ１乃至ＶＯＬ５のそれぞれにおいてもほとんど全てのデータを参照する。キャッシュＣＡ１が一時的に保持するデータ量には、限界があるので、ボリューム単位のキャッシュヒット率は低下する。

よって、通常運用において、ボリューム単位のキャッシュヒット率が定常であり、サーバＳＶ１がランサムウェアＲＳＭに感染した状態では、通常運用に比べて、ボリューム単位のキャッシュヒット率が低下する傾向にあることがわかる。

（検知観点２）
図１１Ａ及び図１１Ｂは、検知観点２を説明するためのシステムの概略図である。このシステムは、サーバ（１）ＳＶ１１乃至サーバ（３）ＳＶ１３を含む。図１１Ａは、サーバ（１）ＳＶ１１乃至サーバ（３）ＳＶ１３の通常運用におけるアプリケーションのデータの参照状態を示し、図１１Ｂはサーバ（２）ＳＶ１２がランサムウェアに感染した状態のデータの参照状態を示す。

図１１Ａに示すように、通常運用において、サーバ（１）ＳＶ１１乃至サーバ（３）ＳＶ１３のうちのあるサーバだけ常にキャッシュＣＡ１を大量に占有していることは考えにくい。例えば、安定稼働しているシステムの通常運用では、サーバ（１）ＳＶ１１、サーバ（２）ＳＶ１２及びサーバ（３）ＳＶ１３は、１：１：１の量でキャッシュＣＡ１を占有している。

これに対して、図１１Ｂに示すように、サーバ（２）ＳＶ１２がランサムウェアＲＳＭに感染した場合、ランサムウェアＲＳＭによるデータ窃取で、大量のデータに不正にアクセスする。例えば、ランサムウェアＲＳＭに感染されたサーバ（２）ＳＶ１２では、データのＲ／Ｗがたくさん発生し、キャッシュＣＡ１への占用が急速に増える。

よって、通常運用において、各サーバのキャッシュ占用率が定常であり、ランサムウェアＲＳＭに感染した状態では、通常運用に比べて、ランサムウェアＲＳＭが侵入したサーバ（２）ＳＶ１２のキャッシュ占用率が上がる傾向にあることがわかる。

（検知観点３）
図１２は、検知観点３を説明するための説明図である。ストレージシステム１００では、上述したように、階層最適化機能によって、通常運用において、アクセス頻度の解析をして、平均アクセス時間が短くなるようにデータがＴｉｅｒに配置されている。例えば、普段よくアクセスするデータがＴｉｅｒ１及びＴｉｅｒ２に配置される。ほとんどアクセスしないデータがＴｉｅｒ３に配置される。通常運用では、階層最適化機能によって、データのアクセス時間が短くなっているので、データへのアクセス速度が速い。

例えば、表ＴＢ１に示すように、通常運用では、アクセス比がアクセス時間に影響し、１００ＧＢのＲ／Ｗがあるとした場合、図１２に示した計算により、アクセス時間は、１００ＧＢあたり、２７０ｍｓかかる。

これに対して、サーバがランサムウェアに感染した場合、ランサムウェアによるデータ窃取で、大量のデータにアクセスする。ランサムウェアによって、Ｔｉｅｒ１，２，３に関係なく、Ｔｉｅｒ３まで大量にデータをアクセスすると、グラフＧｒ１及びグラフＧｒ２に示すように、今までの傾向と異なる動きをし、アクセス時間が長くなり、データへのアクセス速度が下がる。

例えば、表ＴＢ２に示すように、ランサムウェアにサーバが感染した状態では、Ｔｉｅｒ１，２，３に存在するデータの容量比がアクセス時間に影響する。１００ＧＢのＲ／Ｗがあるとした場合、図１２に示した計算により、データアクセス時間は、１００ＧＢあたり、６５０ｍｓかかる。

よって、通常運用において、データへのアクセス時間が短い（即ち、データへのアクセス速度が速い）のに対して、サーバがランサムウェアに感染した状態では、データへのアクセス速度が下がる傾向（低下する傾向）にあることがわかる。

＜処理の概要＞
ストレージシステム１００のコントローラ２００は、上記検知観点１乃至検知観点３を利用して、ランサムウェアに感染している可能性のあるふるまいを、通常と異なるふるまいである「異常ふるまい」として検知する「異常ふるまい検知処理」を実行する。

コントローラ２００は、異常ふるまいを検知する精度を向上するために、閾値及び閾値を算出するときの監視間隔をフィードバックする（更新する）「フィードバック処理」を実行する。

コントローラ２００は、異常ふるまいを検知した場合において、ランサムウェアに起因した異常ふるまいであることの判定精度をあげるために、異常ふるまいをランサムウェアによる不正データアクセスとして検知するか否かを判定する「ランサムウェア判定」を実行する。

コントローラ２００は、ランサムウェア判定によって、異常ふるまいをランサムウェアによる不正データアクセスとして検知した場合、不正アクセス検知に対する処理である「不正アクセス対応処理」を実行する。

以下、異常ふるまい検知処理、フィードバック処理、ランサムウェア判定及び不正アクセス対応処理の各処理の概要について順に説明する。

＜異常ふるまい検知処理＞
異常ふるまい検知処理は、以下に説明する異常ふるまい検知処理１、異常ふるまい検知処理２及び異常ふるまい検知処理３を含む。なお、異常ふるまい検知処理１は、便宜上、「第１異常ふるまい検知処理」とも称呼される場合がある。異常ふるまい検知処理２は、便宜上、「第２異常ふるまい検知処理」とも称呼される場合がある。異常ふるまい検知処理３は、便宜上、「第３異常ふるまい検知処理」とも称呼される場合がある。

（異常ふるまい検知処理１）
検知観点１によれば、通常運用に比べてボリューム単位のキャッシュヒット率が低下した場合、ランサムウェアによる感染（ランサムウェアによる不正なデータアクセス）が生じた可能性があることがいえる。従って、ストレージシステム１００は、通常運用に比べてボリューム単位のキャッシュヒット率が低下したことを、異常ふるまいとして検知する。この検知を行うため、コントローラ２００は、ボリュームキャッシュヒット率監視プログラム３３０によって、以下に述べるデータ参照処理、計算処理及び比較処理を行う。

（データ参照処理）
ボリュームキャッシュヒット率監視プログラム３３０は、初期パラメータテーブル２３０からサンプリング間隔を取得する。ボリュームキャッシュヒット率監視プログラム３３０は、キャッシュヒット率蓄積テーブル２４０から、各時刻のキャッシュヒット率を取得する。ボリュームキャッシュヒット率監視プログラム３３０は、データ参照処理によって、閾値テーブル２９０から閾値キャッシュヒット率を取得する。

（計算処理）
ボリュームキャッシュヒット率監視プログラム３３０は、サンプリング間隔（現在）におけるキャッシュヒット率を算出する。即ち、現在の時点からサンプリング間隔だけ前（過去）の時点までの間（サンプリング間隔内）の各時刻のキャッシュヒット率に基づいて、サンプリング間隔（現在）におけるキャッシュヒット率を計算する。

サンプリング間隔（現在）におけるキャッシュヒット率の算出方法は、例えば、以下に述べる(1)乃至（３）の何れかである。
（１）サンプリング間隔内の各時刻のキャッシュヒット率を用いて、それらの平均値を算出する。
（２）サンプリング間隔内の各時刻のキャッシュヒット率を時間で積分し、面積を算出する。
（３）サンプリング間隔内において、時刻の差分とキャッシュヒット率の差分とを用いて、傾きを算出する。

なお、サンプリング間隔（現在）におけるキャッシュヒット率の算出方法は、他の算出方法であってもよい。サンプリング間隔内のキャッシュヒット率（即ち、算出された平均値、面積又は傾き等）は、便宜上、「第１パラメータ」とも称呼される場合がある。閾値キャッシュヒット率は、便宜上、「第１閾値パラメータ」とも称呼される場合がある。

（比較処理）
ボリュームキャッシュヒット率監視プログラム３３０は、サンプリング間隔（現在）におけるキャッシュヒット率（第１パラメータ）と閾値キャッシュヒット率とを比較する。閾値キャッシュヒット率は、例えば、初期設定値等又は過去データに基づく値（例えば、過去データのある期間のサンプリング間隔におけるキャッシュヒット率（第１パラメータ）の最小値）である。ボリュームキャッシュヒット率監視プログラム３３０は、キャッシュヒット率が閾値キャッシュヒット率より小さい場合、キャッシュヒット率が閾値キャッシュヒット率より小さいことを、異常ふるまいとして検知する。

（異常ふるまい検知処理２）
検知観点２によれば、通常運用に比べて、ランサムウェアが侵入したホストサーバＨＳＶのキャッシュ占用率が上がった場合、ランサムウェアによる感染（ランサムウェアによる不正なデータアクセス）が生じた可能性があることがいえる。従って、ストレージシステム１００は、通常運用に比べてランサムウェアが侵入したホストサーバＨＳＶのキャッシュ占用率が上がったことを、異常ふるまいとして検知する。

この検知を行うため、コントローラ２００は、サーバキャッシュ占用率監視プログラム３４０によって、以下に述べるデータ参照処理、計算処理及び比較処理を行う。

（データ参照処理）
サーバキャッシュ占用率監視プログラム３４０は、初期パラメータテーブル２３０からサンプリング間隔を取得する。サーバキャッシュ占用率監視プログラム３４０は、キャッシュ占用率蓄積テーブル２５０から、各時刻のボリュームのキャッシュ占用率を取得する。サーバキャッシュ占用率監視プログラム３４０は、ボリューム－サーバ関係テーブル３００からボリュームとホストサーバＨＳＶとの対応関係を取得する。サーバキャッシュ占用率監視プログラム３４０は、閾値テーブル２９０から閾値サーバキャッシュ占用率（ホストサーバＨＳＶに割り当てられているボリューム（ＬｄｅｖＩｄ）に関連付けられた閾値キャッシュ占用率の総和）を取得する。

（計算処理）
サーバキャッシュ占用率監視プログラム３４０は、サンプリング間隔（現在）におけるボリュームのキャッシュ占用率を算出する。即ち、現在の時点からサンプリング間隔だけ前（過去）の時点までの間（サンプリング間隔内）の各時刻のボリュームのキャッシュ占用率に基づいて、サンプリング間隔（現在）におけるボリュームのキャッシュ占用率を計算する。

サンプリング間隔（現在）におけるボリュームのキャッシュ占用率の算出方法は、例えば、以下に述べる（１）乃至（３）の何れかである。
（１）サンプリング間隔内の各時刻のボリュームのキャッシュ占用率を用いて、それらの平均値を算出する。
（２）サンプリング間隔内の各時刻のボリュームのキャッシュ占用率を時間で積分し、面積を算出する。
（３）サンプリング間隔内において、時刻の差分とボリュームのキャッシュ占用率の差分とを用いて、傾きを算出する。

ボリュームとホストサーバＨＳＶとの対応関係を用いて、ホストサーバＨＳＶのキャッシュ占用率（サーバキャッシュ占用率）を算出する。

なお、ボリュームのキャッシュ占用率の算出方法は、他の算出方法であってもよい。サンプリング間隔内のボリュームのキャッシュ占用率（即ち、算出された平均値、面積又は傾き等）は、便宜上、「第２パラメータ計算用パラメータ」とも称呼される場合がある。サンプリング間隔内のサーバキャッシュ占用率（即ち、算出された平均値、面積又は傾き等）は、便宜上、「第２パラメータ」とも称呼される場合がある。閾値サーバキャッシュ占用率は、便宜上、「第２閾値パラメータ」とも称呼される場合がある。

（比較処理）
サーバキャッシュ占用率監視プログラム３４０は、サンプリング間隔（現在）におけるサーバキャッシュ占用率（第２パラメータ）と閾値サーバキャッシュ占用率とを比較する。閾値サーバキャッシュ占用率は、例えば、初期設定値等又は過去データのある期間のサンプリング間隔におけるサーバキャッシュ占用率（第２パラメータ）の最大値である。サーバキャッシュ占用率監視プログラム３４０は、サーバキャッシュ占用率が閾値サーバキャッシュ占用率より大きい場合、サーバキャッシュ占用率が閾値サーバキャッシュ占用率より大きいことを、異常ふるまいとして検知する。

（異常ふるまい検知処理３）
検知観点３によれば、通常運用に比べて、データアクセス速度（データへのアクセス速度）が下がった場合、ランサムウェアによる感染（ランサムウェアによる不正なデータアクセス）が生じた可能性があることがいえる。従って、ストレージシステム１００は、通常運用に比べて、データアクセス速度が下がったことを、ランサムウェアによる異常ふるまいとして検知する。

この検知を行うため、コントローラ２００は、データアクセス速度監視プログラム３５０によって、データ参照処理、計算処理及び比較処理を行う。

（データ参照処理）
データアクセス速度監視プログラム３５０は、初期パラメータテーブル２３０からサンプリング間隔を取得する。データアクセス速度監視プログラム３５０は、データアクセス速度蓄積テーブル２６０から、各時刻のデータアクセス速度を取得する。データアクセス速度監視プログラム３５０は、閾値テーブル２９０から、閾値データアクセス速度を取得する。

（計算処理）
データアクセス速度監視プログラム３５０は、サンプリング間隔（現在）におけるデータアクセス速度を算出する。即ち、データアクセス速度監視プログラム３５０は、現在の時点からサンプリング間隔だけ前（過去）の時点までの間（サンプリング間隔内）の各時刻のデータアクセス速度に基づいて、サンプリング間隔（現在）におけるデータアクセス速度を計算する。

データアクセス速度の算出方法は、例えば、以下に述べる（１）乃至（３）の何れかである。
（１）サンプリング間隔内の各時刻のデータアクセス速度を用いて、それらの平均値を算出する。
（２）サンプリング間隔内の各時刻のデータアクセス速度を時間で積分し、面積を算出する。
（３）サンプリング間隔内において、時刻の差分とデータアクセス速度の差分とを用いて、傾きを算出する。

なお、サンプリング間隔（現在）におけるデータアクセス速度の算出方法は、他の算出方法であってもよい。サンプリング間隔（現在）におけるデータアクセス速度（即ち、算出された平均値、面積又は傾き等）は、便宜上、「第３パラメータ」とも称呼される場合がある。閾値データアクセス速度は、便宜上、「第３閾値パラメータ」とも称呼される場合がある。

（比較処理）
データアクセス速度監視プログラム３５０は、サンプリング間隔（現在）におけるデータアクセス速度（第３パラメータ）と閾値データアクセス速度とを比較する。閾値データアクセス速度は、例えば、初期設定値等又は過去データのある期間のサンプリング間隔におけるデータアクセス速度（第３パラメータ）の最小値である。データアクセス速度監視プログラム３５０は、データアクセス速度が閾値データアクセス速度より小さい場合、データアクセス速度が閾値データアクセス速度より小さいことを、異常ふるまいとして検知する。

＜フィードバック処理＞
以下フィードバック処理について説明する。フィードバック処理は、閾値フィードバックプログラム３６０による閾値フィードバック及び監視間隔フィードバックプログラム３７０による監視間隔フィードバックを含む。

（閾値フィードバック）
コントローラ２００は、閾値フィードバックプログラム３６０によって、閾値をフィードバックする。

運用テストで得た測定値、又は、システム設計者やソフトウェア設計者が設計した値などで閾値の暫定値とする。システムが本番稼働に入ると、蓄積したデータからキャッシュヒット率（第１パラメータ）の最小値、サーバキャッシュ占用率（第２パラメータ）を計算するためのボリュームのキャッシュ占用率（第２パラメータ計算用パラメータ）の最大値、データアクセス測度（第３パラメータ）の最小値を計算する。その結果で、閾値（閾値キャッシュヒット率、閾値サーバキャッシュ占用率及び閾値データアクセス速度）を動的に修正する。なお、これらの最大値又は最小値は、所定の監視間隔毎に計測した値に基づいて、計算される。この監視間隔は、監視間隔フィードバックにより動的に修正される。

閾値フィードバックプログラム３６０は、システムの稼働状況によって、閾値を再計算し、動的に更新していくことで、異常ふるまい（ランサムウェアによる不正アクセス）の検知精度を向上させる。閾値フィードバックプログラム３６０の呼び出されるタイミングとしては、１日に１回、１週間に１回、１ヵ月に１回などであってもよい。閾値フィードバックプログラム３６０は、ユーザが必要なタイミングで手動により実行されるようにしてもよい。

（監視間隔フィードバック）
コントローラ２００は、監視間隔フィードバックプログラム３７０によって、監視間隔をフィードバックする。

システムの運用が多種多様で、ほぼ変化なしのシステムもあるし、定期又は不定期的に変化しているシステムもある。同じシステムにおいて、運用方法が時期によって変化する可能性もある。よって、コントローラ２００は、システムの運用パターンに対応するように、監視間隔をフィードバックする。

例えば、システムの運用パターンが、「大体常に一定」である場合、１日又は所定の複数日を監視間隔に設定する。そして、上述した閾値フィードバックによって、その監視間隔で計算された値が比較されることにより、閾値が算出される。

システムの運用パターンが、年度ごとに同じ傾向にある場合、去年、一昨年・・・と、監視間隔を１年で設定する。そして、上述した閾値フィードバックによって、その監視間隔で計算された値が比較されることにより、閾値が算出される。

システムの運用パターンが、「曜日ごとに傾向がある」である場合、毎週の同じ曜日と比較するように、監視間隔を設定する。そして、上述した閾値フィードバックによって、その監視間隔で計算された値が比較されることにより、閾値が算出される。

システムの運用パターンが、「日付ごとに傾向がある」である場合、先月、先々月・・・のその日付と比較するように、監視間隔を設定する。そして、上述した閾値フィードバックによって、その監視間隔で計算された値が比較されることにより、閾値が算出される。

このように、監視間隔フィードバックプログラム３７０は、ストレージシステム１００の本番稼働に入って、定期的に生じるデータの傾向（挙動）があるシステムであれば、システムの運用状況に応じて、その傾向の周期を計算し、その傾向の周期により監視間隔を動的に修正する。これにより、異常ふるまいの検知精度を向上することができる。

＜ランサムウェア判定＞
ストレージレイヤにおいて「異常ふるまい」を検知した場合、ランサムウェアがデータを窃取している可能性がある。一方で、正常業務中の一時的な特殊イベント（例：構成変更／ＡＰＰ新規追加）があった場合も、いつもと違う傾向になる。即ち、異常ふるまいと類似するデータ傾向（データ変化傾向）が生じる可能性がある。

この異常ふるまいが検知されたことによって、ランサムウェアによる不正アクセスを検知してもよい（後述の変形例１を参照。）が、一方で、その場合の異常ふるまいが、ランサムウェアと区別つかないことも生じ得るので、検知精度が低下してしまう可能性がある。例えば、単に過去値で求めた正常範囲からピンポイント（１つのボリュームのキャッシュヒット率が下がったなど）外れた場合、検知精度が低下してしまう可能性がある。

そこで、コントローラ２００は、異常ふるまいを検知した場合、ランサムウェア判定プログラムによって、異常ふるまいがランサムウェアに起因するふるまいであるか否かを判定する。これにより、コントローラ２００は、ランサムウェアの検知精度を上げることができる。

ここで、ランサムウェアの挙動としては、以下の（１）乃至（４）の挙動がある。

挙動（１）ランサムウェアによるデータ窃取時に大量のデータアクセスが生じたり、データ転送が急増したりする。
挙動（２）ランサムウェアによるデータ窃取時にネットワーク内の端末やサーバを一斉に攻撃する。
挙動（３）データ窃取後にデータを破壊する。
挙動（４）ランサムウェアは、データ搾取時にできるだけ早くデータをとろうとする。

このようなランサムウェアの挙動に着目して、ランサムウェア判定は、以下に述べるように、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０及びランサムウェア判定プログラム（データアクセス速度観点）３９０によって、実行される。

（ランサムウェア判定チェック（キャッシュヒット率観点））
ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、異常ふるまいが検知された場合、以下に述べる判定Ａ乃至判定Ｄの少なくとも一つを行うことにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。

（判定Ａ）
挙動（１）によれば、ランサムウェアは大量アクセスをするため、同一ホストサーバＨＳＶの他のボリュームも同様の傾向が現れているかを調べることにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。

従って、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、異常ふるまいが検知された該当ボリュームが割り当てられているホストサーバＨＳＶ内の他のボリュームも、同様なキャッシュヒット率傾向が現れているか否かを判定する（即ち、サンプリング間隔（現在）におけるキャッシュヒット率が閾値キャッシュヒット率より小さいか否かを判定する。）。

ホストサーバＨＳＶ内の他のボリュームも、同様なキャッシュヒット率傾向が現れている場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。

（判定Ｂ）
挙動（１）によれば、ランサムウェアは大量アクセスをするため、他のホストサーバＨＳＶの他のボリュームも同様の傾向が現れているかを調べることにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。

従って、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、該当ボリュームが割り当てられているホストサーバＨＳＶ以外の他のホストサーバＨＳＶのボリュームも、同様なキャッシュヒット率傾向が現れているか否かを判定する。

他のホストサーバＨＳＶのボリュームも、同様なキャッシュヒット率傾向が現れている場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。

（判定Ｃ）
挙動（３）によれば、ランサムウェアはデータ搾取後データを破壊するため、キャッシュヒット率が正常に戻らないはずである。そのため、キャッシュヒット率がいつもの傾向に戻ったかどうかを調べることにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。

従って、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、キャッシュヒット率がいつもの傾向に戻ったボリュームがないか否かを判定する。ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、キャッシュヒット率がいつもの傾向に戻ったボリュームがない場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。

（判定Ｄ）
キャッシュヒット率の低下はウイルススキャンによっても生じるため、キャッシュヒット率の低下がウイルススキャンによるものか否かを判別することは誤検知低下の観点から好ましい。ここで、ＩＯＰＳに関し、挙動（４）によればランサムウェアは早速でデータを抜き出すという動作であるのでＩＯＰＳが普段より大きくなるのに対して、ウイルススキャンはデータをチェックしながらデータを読んでいるため、ウイルススキャンの場合のＩＯＰＳは小さい。このような観点に着目して、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ボリューム（該当ボリューム及び同様なキャッシュヒット率傾向が現れている他のボリューム）のＩＯＰＳが普段より大きいか否かを判定する。ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ボリュームのＩＯＰＳが普段より大きい場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。

ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、上記判定Ａ乃至判定Ｄの少なくとも一つの判定を実行し、少なくとも一つの判定結果が、「ＹＥＳ」である場合に、異常ふるまいがランサムウェアに起因するふるまいであると判定してもよい。なお、本例ではストレージシステムが複数台のホストサーバＨＳＶで使用されおり、本例の後述の図２１Ａのフローチャートにより示した処理フローでは、上記判定Ａ乃至判定Ｄの全ての判定結果が「ＹＥＳ」である場合に、異常ふるまいがランサムウェアに起因するふるまいであると判定されるようになっている。

（ランサムウェア判定チェック（データアクセス速度観点））
挙動（２）によれば、ランサムウェアによるデータ窃取時にネットワーク内の端末やサーバを一斉に攻撃する。このため、該当ボリュームが割り当てられているホストサーバＨＳＶ以外の他のホストサーバＨＳＶのボリュームも、同様なデータアクセス速度傾向が現れているかを調べることにより、異常ふるまいがランサムウェアに起因するふるまいであるかを判定することができる。

従って、ランサムウェア判定プログラム（データサクセス速度観点）３９０は、異常ふるまいが検知された該当ボリュームが割り当てられているホストサーバＨＳＶ以外の他のホストサーバＨＳＶのボリュームも、データアクセス速度が低下しているか否かを判定する（（即ち、サンプリング間隔（現在）におけるデータアクセス速度が閾値アクセス速度より小さいか否かを判定する。））。

他のホストサーバＨＳＶのボリュームも、データアクセス速度が低下している場合、異常ふるまいがランサムウェアに起因するふるまいであると判定する。即ち、ランサムウェア判定プログラム（データアクセス速度観点）３９０は、異常ふるまいをランサムウェアに起因する不正アクセスとして検知する。

＜不正アクセス対応処理＞
コントローラ２００は、ランサムウェアによる不正アクセスを検知した場合、不正アクセス対応処理を実行する。

不正アクセス対応処理としては、例えば、以下に述べる処理が挙げられる。
・コントローラ２００は、不正アクセスがあった対象サーバを特定しｐａｔｈ（パス）を切る。
・コントローラ２００は、管理者の端末に不正アクセスがあった旨を通知する。
・コントローラ２００は、上記通知に加えて、データの転送量を減少する。これが管理者の対応を待っている間に実施されると、データ流出の対策となる。
・コントローラ２００は、上記通知に加えて、ストレージ内のデータの転送速度をおとす。これが管理者の対応を待っている間に実施されるとデータ流出の対策となる。
・システムが、ユーザが定期的にバックアップを取っているシステムなどである場合、コントローラ２００は、正常だったと判断したタイミングにバックアップを戻す。
・システムが、ＣＤＰのような技術が適用されているシステムである場合、コントローラ２００は、正常だったと判断したタイミングと組み合わせでデータを戻す。なお、ＣＤＰ（Ｃｏｎｔｉｎｕｏｕｓ Ｄａｔａ Ｐｒｏｔｅｃｔｉｏｎ）は、過去データをライト毎に継続的にプール内に残すことで、ランサムウェア等の影響で改竄されたデータを任意の時点のデータ状態に戻す機能である。
・コントローラ２００は、ウイルススキャンを自動的に走らせる。

＜具体的作動＞
以下、ストレージシステム１００の具体的作動について説明する。図１３はストレージシステム１００のコントローラ２００が実行する全体処理の流れを説明するための処理フローを示すフローチャートである。コントローラ２００は、図１３に示す処理フローを実行する。従って、コントローラ２００は、図１３のステップ１３００から処理を開始してステップ１３０５に進み、ボリューム（ＤＰボリューム４２０）を作成する。ボリュームは、例えば、図示しない管理者端末からの指示に応じて作成される。

その後、コントローラ２００は、ステップ１３１０に進み、初期値を変更するか否かを判定する。

初期値を変更する場合、コントローラ２００は、ステップ１３１０にて「ＹＥＳ」と判定してステップ１３１５に進み、初期設定プログラム（初期設定変更プログラム３１０）によって、初期パラメータをユーザの指定に応じて変更する。ユーザは、例えば、図示しない管理者端末を操作することによって、初期パラメータを指定することができる。なお、ステップ１３１５の処理の詳細は、後述する。

これに対して、初期値を変更しない場合、コントローラ２００は、ステップ１３１０にて「ＮＯ」と判定してステップ１３２０に直接進む。

コントローラ２００は、ステップ１３２０に進むと、ストレージシステム１００の監視を開始し、以下に述べるステップ１３２５及びステップ１３３０の処理の並行実行を開始させた後、ステップ１３３５に進む。

ステップ１３２５：コントローラ２００は、データ蓄積プログラム３２０によって、通常運用時のデータを蓄積する。なお、ステップ１３２５の処理の詳細は、後述する。

ステップ１３３０：コントローラ２００は、各監視プログラムと各フィードバックプログラムとを動作させる。なお、監視プログラムは、ボリュームキャッシュヒット率監視プログラム３３０、サーバキャッシュ占用率監視プログラム３４０及びデータアクセス速度監視プログラム３５０のことである。フィードバックプログラムは、閾値フィードバックプログラム３６０及び閾値間隔フィードバックプログラム３７０のことである。ステップ１３３０の処理の詳細は、後述する。

コントローラ２００は、ステップ１３３５に進むと、監視プログラムの少なくとも一つが、上述したいつもと異なるふるまいである「異常ふるまい」を検知したか否かを判定する。

「異常ふるまい」を検知した場合、コントローラ２００は、ステップ１３３５にて「ＹＥＳ」と判定してステップ１３４０に進み、ランサムウェア判定によるランサムウェア判定チェックを開始する。なお、ステップ１３４０の処理の詳細は、後述する。

その後、コントローラ２００は、ステップ１３４５に進んで、ランサムウェアの挙動による特異な傾向があるか否かを判定する。即ち、コントローラ２００は、ランサムウェア判定によって、異常ふるまいがランサムウェアに起因するふるまいであるか否かを判定する。

ランサムウェアの挙動による特異な傾向がない場合、コントローラ２００は、ステップ１３４５にて「ＮＯ」と判定してステップ１３２０に戻り、監視を継続する。

これに対して、ランサムウェアの挙動による特異な傾向がある場合、コントローラ２００は、ステップ１３４５にて「ＹＥＳ」と判定してステップ１３５０に進み、不正アクセス検知後のアクションを開始する（即ち、上述した不正アクセス対応処理の実行を開始する。）。その後、コントローラ２００は、ステップ１３９５に進んで本処理フローを一旦終了する。

＜ステップ１３１５＞
上述したステップ１３１５の処理の詳細を説明する。図１４は初期設定変更プログラム３１０が実行する処理フローを示すフローチャートである。初期設定変更プログラム３１０は、ステップ１４００から処理を開始して以下に述べるステップ１４０５乃至ステップ１４１５の処理を順に実行した後、ステップ１４９５に進んで本処理フローを一旦終了する。

ステップ１４０５：初期設定変更プログラム３１０は、初期パラメータテーブル２３０から監視開始時刻、サンプリング間隔及び過去データの見る量のデフォルト値を取得する。

ステップ１４１０：初期設定変更プログラム３１０は、ユーザが変更したいパラメータを設定変更する。

ステップ１４１５：初期設定変更プログラム３１０は、ユーザの指定値で初期パラメータテーブル２３０を更新する。

＜ステップ１３２５＞
上述したステップ１３２５の処理の詳細を説明する。図１５はデータ蓄積プログラム３２０が実行する処理フローを示すフローチャートである。データ蓄積プログラム３２０は、ステップ１５００から処理を開始して以下に述べるステップ１５０５の処理を実行した後、ステップ１５９５に進んで本処理フローを一旦終了する。

ステップ１５０５：データ蓄積プログラム３２０は、ストレージシステム１００の通常運用時のデータ（時系列データ）を蓄積する。データは、逐次取得され、キャッシュヒット率蓄積テーブル２４０、キャッシュ占用率蓄積テーブル２５０、データアクセス速度蓄積テーブル２６０及びＩＯＰＳ蓄積テーブル２７０等に格納される。

＜ステップ１３３０＞
上述したステップ１３３０の処理の詳細を図１６Ａ乃至図２０Ｂを用いて説明する。図１６Ａはボリュームキャッシュヒット率監視プログラム３３０が実行する処理フローを示すフローチャートである。図１６Ｂは図１６Ａの処理フローの理解を容易にするための具体例を説明するための図である。

ボリュームキャッシュヒット率監視プログラム３３０は、ステップ１６００から処理を開始して以下に述べるステップ１６０５乃至ステップ１６２０の処理を順に実行した後、ステップ１６２５に進む。

ステップ１６０５：ボリュームキャッシュヒット率監視プログラム３３０は、初期パラメータテーブル２３０（初期設定テーブル）から、サンプリング間隔を取得する。図１６Ｂに示すように、ボリュームキャッシュヒット率監視プログラム３３０は、例えば、ＬｄｅｖＩｄ１について、初期パラメータテーブル２３０から矢印ａ１が示すレコードのサンプリング間隔６００ｓを取得する。なお、他のＬｄｅｖＩｄのそれぞれについても、同様の処理が実行されるが、説明は省略する（以下、同様。）。

ステップ１６１０：ボリュームキャッシュヒット率監視プログラム３３０は、現在時刻から遡って、サンプリング間隔内のボリュームキャッシュヒット率（ボリューム単位のキャッシュヒット率）を取得する。図１６Ｂの説明文ＥＸ１に示すように、ボリュームキャッシュヒット率監視プログラム３３０は、例えば、ＬｄｅｖＩｄ１について、キャッシュヒット率蓄積テーブル２４０から「2021/11/26 14:50:02」から「2021/11/26 15:00:02」までのサンプリング間隔内の各時刻のキャッシュヒット率を取得する。

ステップ１６１５：ボリュームキャッシュヒット率監視プログラム３３０は、サンプリング間隔内のボリュームキャッシュヒット率(＝Hit Rate(current))をＬｄｅｖＩｄ毎に算出する。なお、ここでのサンプリング間隔内のボリュームキャッシュヒット率(＝Hit Rate(current))は、例えば、サンプリング間隔内の各時刻のボリューム単位のキャッシュヒット率の平均値（即ち、第１パラメータ）である。

ステップ１６２０：ボリュームキャッシュヒット率監視プログラム３３０は、閾値テーブル２９０からＬｄｅｖＩｄをキーとした閾値キャッシュヒット率（＝キャッシュヒット率（第１パラメータ）の最小値(＝Hit Rate(past)min))を取得する。図１６Ｂに示すように、ボリュームキャッシュヒット率監視プログラム３３０は、例えば、ＬｄｅｖＩｄ１について、閾値テーブル２９０から矢印ａ２が示すレコードの閾値キャッシュヒット率（＝０．０１）を取得する。

ボリュームキャッシュヒット率監視プログラム３３０は、ステップ１６２５に進むと、サンプリング間隔内のボリュームキャッシュヒット率(＝Hit Rate(current))が閾値キャッシュヒット率（＝キャッシュヒット率（第１パラメータ）の最小値（＝Hit Rate(past)min）より小さいか否かを判定する。なお、この処理も、ＬｄｅｖＩｄ毎に実行される。

サンプリング間隔内のボリュームキャッシュヒット率(＝Hit Rate(current))が閾値キャッシュヒット率（＝Hit Rate(past)min）より小さい場合、ボリュームキャッシュヒット率監視プログラム３３０は、ステップ１６２５にて「ＹＥＳ」と判定してステップ１６３０に進み、サンプリング間隔内のボリュームキャッシュヒット率が閾値キャッシュヒット率より小さいことを、いつもと異なるふるまい（異常ふるまい）として検知する。なお、この判定は各ＬｄｅｖＩｄ毎に実行される。

その後、ボリュームキャッシュヒット率監視プログラム３３０は、ステップ１６９５に進んで本処理フローを一旦終了する。

これに対して、サンプリング間隔内のボリュームキャッシュヒット率(＝Hit Rate(current))が閾値キャッシュヒット率（＝Hit Rate(past)min）以上である場合、ボリュームキャッシュヒット率管理プログラムは、ステップ１６２５にて「ＮＯ」と判定してステップ１６９５に進んで本処理フローを一旦終了する。

図１７Ａはサーバキャッシュ占用率監視プログラム３４０が実行する処理フローを示すフローチャートである。図１７Ｂは図１７Ａの処理フローの理解を容易にするための具体例を説明するための図である。

サーバキャッシュ占用率監視プログラム３４０は、ステップ１７００から処理を開始して以下に述べるステップ１７０５乃至ステップ１７３５の処理を順に実行した後、ステップ１７４０に進む。

ステップ１７０５：サーバキャッシュ占用率監視プログラム３４０は、初期パラメータテーブル２３０（初期設定テーブル）からサンプリング間隔を取得する。図１７Ｂに示すように、サーバキャッシュ占用率監視プログラム３４０は、例えば、ＬｄｅｖＩｄ１について、初期パラメータテーブル２３０から矢印ｂ１が示すレコードのサンプリング間隔６００ｓを取得する。なお、他のＬｄｅｖＩdのそれぞれについても、同様の処理が実行されるが、説明は省略する（以下、同様。）。

ステップ１７１０：サーバキャッシュ占用率監視プログラム３４０は、現在時刻から遡って、サンプリング間隔内のボリュームキャッシュ占用率を取得する。図１７Ｂの説明文ＥＸ２に示すように、サーバキャッシュ占用率監視プログラム３４０は、ＬｄｅｖＩｄ１について、キャッシュ占用率蓄積テーブル２５０から「2021/11/26 14:50:02」から「2021/11/26 15:00:02」までのサンプリング間隔内の各時刻のボリューム単位のキャッシュ占用率を取得する。

ステップ１７１５：サーバキャッシュ占用率監視プログラム３４０は、現在のサンプリング間隔内のボリュームキャッシュ占用率（＝Occupancy Rate(current)’）をＬｄｅｖＩｄ毎に算出する。なお、ここでのサンプリング間隔内のボリュームキャッシュ占用率（＝Occupancy Rate(current)’）は、サンプリング間隔内の各時刻のキャッシュ占用率の平均値（即ち、第２パラメータ計算用パラメータ）である。

ステップ１７２０：サーバキャッシュ占用率監視プログラム３４０は、ボリュームとホストサーバＨＳＶの関係テーブル（ボリューム－サーバ関係テーブル３００）からＬｄｅｖＩｄとＳｅｒｖｅｒＩｄの関係を取得する。

ステップ１７２５：サーバキャッシュ占用率監視プログラム３４０は、ＳｅｒｖｅｒＩｄ毎に、同一サーバに割り当てられているサンプリング間隔内のボリュームのキャッシュ占用率（第２パラメータ計算用パラメータ）の総和を算出し、そのホストサーバＨＳＶの現在のサーバキャッシュ占用率（＝Occupancy Rate(current)）（即ち、第２パラメータ）とする。図１７Ｂの説明文ＥＸ３に示すように、サーバキャッシュ占用率監視プログラム３４０は、例えば、ＳｅｒｖｅｒＩｄ１０１について、Ｌｄｅｖ１，４，５のサンプリング間隔内のキャッシュ占用率（第２パラメータ計算用パラメータ）の総和を算出する。なお、他のＳｅｒｖｅｒＩｄについても、同様の処理が実行されるが、説明は省略する（以下、同様。）。

ステップ１７３０：サーバキャッシュ占用率監視プログラム３４０は、閾値テーブル２９０から同一サーバに割り当てられているボリューム毎の閾値キャッシュ占用率（即ち、キャッシュ占用率の最大値（＝Occupancy Rate(current)max’））を取得する。

ステップ１７３５：サーバキャッシュ占用率監視プログラム３４０は、閾値キャッシュ占用率（＝Occupancy Rate(current)max’）の総和を算出し、そのホストサーバＨＳＶのサーバキャッシュ占用率の閾値サーバキャッシュ占用率（＝Occupancy Rate(current)max）とする。図１７Ｂに示すように、サーバキャッシュ占用率監視プログラム３４０は、例えば、閾値テーブル２９０の矢印ｂ２、矢印ｂ３及び矢印ｂ４が示す各レコードのキャッシュ占用率の総和を算出する。

サーバキャッシュ占用率監視プログラム３４０は、ステップ１７４０に進むと、サンプリング間隔内のサーバキャッシュ占用率（＝Occupancy Rate(current)）が閾値サーバキャッシュ占用率（＝Occupancy Rate(past)max）より大きいか否かを判定する。

サンプリング間隔内のサーバキャッシュ占用率（＝Occupancy Rate(current)）が閾値サーバキャッシュ占用率（＝Occupancy Rate(past)max）より大きい場合、サーバキャッシュ占用率監視プログラム３４０は、ステップ１７４０にて「ＹＥＳ」と判定してステップ１７４５に進み、サーバキャッシュ占用率（＝Occupancy Rate(current)）が閾値サーバキャッシュ占用率（＝Occupancy Rate(past)maxより大きいことを、いつもと異なるふるまい（異常ふるまい）として検知する。なお、この判定は、各ＳｅｒｖｅｒＩｄ毎に実行される。その後、サーバキャッシュ占用率監視プログラム３４０は、ステップ１７９５に進んで本処理フローを一旦終了する。

これに対して、サンプリング間隔内のサーバキャッシュ占用率（＝Occupancy Rate(current)）が閾値サーバキャッシュ占用率（＝Occupancy Rate(past)max）以下である場合、サーバキャッシュ占用率監視プログラム３４０は、ステップ１７４０にて「ＮＯ」と判定してステップ１７９５に進んで本処理フローを一旦終了する。

図１８Ａはデータアクセス速度監視プログラム３５０が実行する処理フローを示すフローチャートである。図１８Ｂは図１８Ａの処理フローの理解を容易にするための具体例を説明するための図である。

データアクセス速度監視プログラム３５０は、ステップ１８００から処理を開始して以下に述べるステップ１８０５乃至ステップ１８２０の処理を順に実行した後、ステップ１８２５に進む。

ステップ１８０５：データアクセス速度監視プログラム３５０は、初期パラメータテーブル２３０（初期設定テーブル）から、サンプリング間隔を取得する。図１８Ｂに示すように、データアクセス速度監視プログラム３５０は、例えば、ＬｄｅｖＩｄ１について、初期パラメータテーブル２３０から矢印ｃ１が示すレコードのサンプリング間隔６００ｓを取得する。なお、他のＬｄｅｖＩｄのそれぞれについても、同様の処理が実行されるが、説明は省略する（以下、同様。）。

ステップ１８１０：データアクセス速度監視プログラム３５０は、現在時刻から遡って、サンプリング間隔内のボリューム毎のデータへのアクセス速度を取得する。図１８Ｂの説明文ＥＸ３に示すように、ボリュームキャッシュヒット率監視プログラム３３０は、例えば、ＬｄｅｖＩｄ１について、データアクセス速度蓄積テーブル２６０から「2021/11/26 14:50:02」から「2021/11/26 15:00:02」までのサンプリング間隔内の各時刻のデータアクセス速度を取得する。

ステップ１８１５：データアクセス速度監視プログラム３５０は、サンプリング間隔内のデータへのアクセス速度（＝Access Velocity(current)）をＬｄｅｖＩｄ毎に算出する。なお、ここでのサンプリング間隔内のデータへのアクセス速度（データアクセス速度）は、例えば、サンプリング間隔内の各時刻のデータアクセス速度の平均値（即ち、第３パラメータ）である。

ステップ１８２０：データアクセス速度監視プログラム３５０は、閾値テーブル２９０からＬｄｅｖＩｄをキーとした閾値データアクセス速度（＝データアクセス速度（第３パラメータ）の最小値（＝Access Velocity(past)min））を取得する。図１８Ｂに示すように、データアクセス速度監視プログラム３５０は、例えば、ＬｄｅｖＩｄ１について、閾値テーブル２９０から矢印ｃ２が示すレコードの閾値データアクセス速度（＝０．１４Ｇｂｐｓ）を取得する。

データアクセス速度監視プログラム３５０は、ステップ１８２５に進むと、サンプリング間隔内のデータへのアクセス速度（＝Access Velocity(current)）が、閾値データアクセス速度（＝Access Velocity(past)min）より小さいか否かを判定する。

サンプリング間隔内のデータへのアクセス速度（＝Access Velocity(current)）が、閾値データアクセス速度（＝Access Velocity(past)min）より小さい場合、データアクセス速度監視プログラム３５０はステップ１８２５にて「ＹＥＳ」と判定してステップ１８３０に進み、サンプリング間隔内のデータへのアクセス速度（＝Access Velocity(current)）が、閾値データアクセス速度（＝Access Velocity(past)min）より小さいことを、いつもと異なるふるまい（異常ふるまい）として検知する。

なお、この判定は各ＬｄｅｖＩｄ毎に実行される。その後、データアクセス速度監視プログラム３５０は、ステップ１８９５に進んで本処理フローを一旦終了する。

これに対して、サンプリング間隔内のデータへのアクセス速度（＝Access Velocity(current)）が、閾値データアクセス速度（＝Access Velocity(past)min）以上である場合、データアクセス速度監視プログラム３５０は、ステップ１８２５にて「ＮＯ」と判定してステップ１８９５に進んで本処理フローを一旦終了する。

図１９Ａは閾値フィードバックプログラム３６０が実行する処理フローを示すフローチャートである。図１９Ｂは図１９Ａの処理フローの理解を容易にするための具体例を説明するための図である。

閾値フィードバックプログラム３６０は、ステップ１９００から処理を開始して以下に述べるステップ１９０５乃至ステップ１９３０の処理を順に実行した後、ステップ１９９５に進んで本処理フローを一旦終了する。

ステップ１９０５：閾値フィードバックプログラム３６０は、初期パラメータテーブル２３０からＬｄｅｖＩｄ毎のサンプリング間隔及び過去データの見る量を取得する。図１９Ｂに示すように、閾値フィードバックプログラム３６０は、例えば、ＬｄｅｖＩｄ１について、初期パラメータテーブル２３０から矢印ｄ１が示すレコードのサンプリング間隔６００ｓ及び過去データの見る量（２０１９／０１／２７ １０：００：００）を取得する。なお、他のＬｄｅｖＩｄのそれぞれについても、同様の処理が実行されるが、説明は省略する（以下、同様。）。

ステップ１９１０：閾値フィードバックプログラム３６０は、監視間隔テーブル２８０からＬｄｅｖＩｄ毎の監視間隔を取得する。図１９Ｂに示すように、閾値フィードバックプログラム３６０は、例えば、ＬｄｅｖＩｄ１について、監視間隔テーブル２８０から矢印ｄ２が示すレコードのキャッシュヒット率監視間隔（８６４００ｓ）を取得する。

ステップ１９１５：閾値フィードバックプログラム３６０は、取得した過去データの見る量の値に基づき、キャッシュヒット率蓄積テーブル２４０、キャッシュ占用率蓄積テーブル２５０及びデータアクセス速度蓄積テーブル２６０から、ＬｄｅｖＩｄ毎の過去データを取得する。図１９Ｂの説明文ＥＸ１１に示すように、閾値フィードバックプログラム３６０は、例えば、ＬｄｅｖＩｄ１について、キャッシュヒット率蓄積テーブル２４０から「2019/1/27 10:00:00」から現在までの蓄積された各時刻のキャッシュヒット率のデータを全部取得する。

ステップ１９２０：閾値フィードバックプログラム３６０は、ＬｄｅｖＩｄ毎の過去データにおいて、監視間隔毎に、サンプリング間隔を用いて、サンプリング間隔内のボリュームのキャッシュヒット率、ボリュームのキャッシュ占用率及びデータへのアクセス速度を算出する。図１９Ｂの説明文ＥＸ１２に示すように、閾値フィードバックプログラム３６０は、例えば、上記取得したデータにおいて、８６，４００ｓ（１ｄａｙ）間隔毎に、６００ｓ（１０ｍｉｎ）をサンプリング間隔として、その１０ｍｉｎ間のデータを利用して計算する。本例において、例えば、１０ｍｉｎ間のデータの平均値（即ち、第１パラメータ、第２パラメータ計算用パラメータ、及び、第３パラメータ）を算出する。

ステップ１９２５：閾値フィードバックプログラム３６０は、算出したＬｄｅｖＩｄ毎のサンプリング間隔内のボリュームのキャッシュヒット率（第１パラメータ）、キャッシュ占用率（第２パラメータ）、及び、データへのアクセス速度（第３パラメータ）から、サンプリング間隔内のボリュームのキャッシュヒット率（即ち、第１パラメータ）の最小値、ボリュームのキャッシュ占用率（即ち、第２パラメータ計算用パラメータ）の最大値、及び、データへのアクセス速度（即ち、第３パラメータ）の最小値を取得する。

図１９Ｂの説明文ＥＸ１３及びグラフＧｒ１１に示すように、閾値フィードバックプログラム３６０は、８６，４００ｓ（１ｄａｙ）間隔毎に一回計算しているので計算結果（キャッシュヒット率の過去値）が複数ある。それらの計算結果から、キャッシュヒット率（第１パラメータ）の最小値を取り出す（なお、キャッシュ占用率（第２パラメータ計算用パラメータ）の最大値及びデータへのアクセス速度（第３パラメータ）の最小値についても同様。）。

ステップ１９３０：閾値フィードバックプログラム３６０は、取得したキャッシュヒット率（第１パラメータ）の最小値、ボリュームのキャッシュ占用率（第２パラメータ計算用パラメータ）の最大値及びデータへのアクセス速度（即ち、第３パラメータ）の最小値により、ＬｄｅｖＩｄをキーとした閾値テーブル２９０を更新する。

図２０Ａは監視間隔フィードバックプログラム３７０が実行する処理フローを示すフローチャートである。図２０Ｂは図２０Ａの処理フローの理解を容易にするための図である。

監視間隔フィードバックプログラム３７０は、ステップ２０００から処理を開始して以下に述べるステップ２００５乃至ステップ２０１５の処理の並行実行を開始させた後、ステップ２０２０に進む。

ステップ２００５：監視間隔フィードバックプログラム３７０は、キャッシュヒット率蓄積テーブル２４０に蓄積したデータからＬｄｅｖＩｄ毎のキャッシュヒット率の変化傾向を記録する。

ステップ２０１０：監視間隔フィードバックプログラム３７０は、キャッシュ占用率蓄積テーブル２５０に蓄積したデータからＬｄｅｖＩｄ毎のキャッシュ占用率の変化傾向を記録する。

ステップ２０１５：監視間隔フィードバックプログラム３７０は、データアクセス速度蓄積テーブル２６０に蓄積したデータからＬｄｅｖＩｄ毎のデータへのアクセス速度の変化傾向を記録する。

その後、監視間隔フィードバックプログラム３７０は、以下に述べるステップ２０２０及びステップ２０２５の処理を順に実行した後、ステップ２０９５に進んで本処理フローを一旦終了する。

ステップ２０２０：監視間隔フィードバックプログラム３７０は、同一ＬｄｅｖＩｄにおいて、同様の変化傾向間の間隔を算出する。図２０ＢのグラフＧｒ２１に示すように、監視間隔フィードバックプログラム３７０は、例えば、キャッシュヒット率について同様の変化が現れた第１時点ｔ１と第２時点ｔ２との間の監視間隔（ｔ２－ｔ１）を算出する。なお、キャッシュ占用率及びデータへのアクセス速度についても同様である。

ステップ２０２５：監視間隔フィードバックプログラム３７０は、算出した結果によって、ＬｄｅｖＩｄをキーとして監視間隔テーブル２８０を更新する。

＜ステップ１３４０＞
上述したステップ１３４０の処理の詳細を図２１Ａ乃至図２２Ｂを用いて説明する。図２１Ａはランサムウェア判定プログラム（キャッシュヒット率観点）３８０が実行する処理フローを示すフローチャートである。図２１Ｂは図２１Ａの処理フローの理解を容易にするための具体例を説明するための図である。ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１００から処理を開始して以下に述べるステップ２１０５及びステップ２１１０の処理を順に実行した後、ステップ２１１５に進む。

ステップ２１０５：ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、キャッシュヒット率における、異常ふるまいが検知されたボリュームのＬｄｅｖＩｄを取得する。図２１Ｂに示すように、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、例えば、異常ふるまいが検知されたボリュームのＬｄｅｖＩｄ１を取得する。

ステップ２１１０：ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ボリューム－サーバ関係テーブル３００を参照して、該当ボリュームの割り当てられているホストサーバＨＳＶのＳｅｒｖｅｒＩｄを特定する。図２１Ｂに示すように、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、例えば、ボリューム－サーバ関係テーブル３００を参照して、ＬｄｅｖＩｄ１のボリュームが割り当てられているＳｅｒｖｅｒＩｄ１０１を特定する。

ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１１５に進むと、該当ホストサーバＨＳＶ内に、同様なキャッシュヒット率傾向が現れる他ボリュームがあるのか否かを判定する。これにより、ランサムウェアによる大量のデータアクセスが行われている可能性が高いかどうかを判定できる。なお、ステップ２１１５の判定は、便宜上、「第１判定」とも称呼される場合がある。図２１Ｂの説明文ＥＸ２１に示すように、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ボリューム－サーバ関係テーブル３００を参照して、ＳｅｒｖｅｒＩｄ１０１に割り当てられている他のＬｄｅｖＩｄ４及びＬｄｅｖＩｄ５を特定する。ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、キャッシュヒット率蓄積テーブル２４０を参照して、他のＬｄｅｖＩｄ４及びＬｄｅｖＩｄ５に、ＬｄｅｖＩｄ１のボリュームのキャッシュヒット率の傾向と同様なキャッシュヒット率傾向（異常ふるまい）が現れているか否かを判定する。

該当サーバ内に、同様なキャッシュヒット率傾向が現れる他ボリュームがない場合、ランサムウェアによる大量のデータアクセスが行われている可能性が低い。従って、この場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１１５にて「ＮＯ」と判定してステップ２１９５に進んで本処理フローを一旦終了する。

これに対して、該当サーバ内に、同様なキャッシュヒット率傾向が現れる他ボリュームがある場合、ランサムウェアによる大量のデータアクセスが行われている可能性が高い。従って、この場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１１５にて「ＹＥＳ」と判定してステップ２１２０に進む。

ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１２０に進むと、それらのボリュームのＩＯＰＳは普段よりも大きいか否かを判定する。普段より大きいか否かは、例えば、所定の閾値ＩＯＰＳと比較することにより、判定される。これにより、異常ふるまいがウイルススキャンによるふるまいである可能性が高いか否かを判定できる。なお、ステップ２１２０の判定は、便宜上、「第２判定」とも称呼される場合がある。

それらのボリュームのＩＯＰＳは普段以下である場合、異常ふるまいがウイルススキャンによるふるまいである可能性が高いと考えられる。従って、この場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１２０にて「ＮＯ」と判定してステップ２１９５に進んで本処理フローを一旦終了する。

それらのボリュームのＩＯＰＳは普段よりも大きい場合、異常ふるまいがウイルススキャンによるふるまいである可能性が低いと考えられる。従って、この場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１２０にて「ＹＥＳ」と判定してステップ２１２５に進む。

ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１２５に進み、キャッシュヒット率はいつもの傾向に戻ったボリュームがないか否かを判定する。図２１Ｂの説明文ＥＸ２２に示すように、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、例えば、ＬｄｅｖＩｄ１、ＬｄｅｖＩｄ４及びＬｄｅｖＩｄ５のボリュームのうち、キャッシュヒット率がいつもの傾向に戻ったボリュームがないか否かを判定する。換言すると、ＬｄｅｖＩｄ１、ＬｄｅｖＩｄ４及びＬｄｅｖＩｄ５のボリュームのうち、キャッシュヒット率がいつもの傾向に戻った（異常ふるまいが検知されなくなった）ボリュームが存在するか否かを判定する。ランサムウェアによるデータの搾取後データ破棄するため、ボリュームキャッシュヒット率が下がったとしてもまたいつもの傾向にも戻らない。従って、ボリュームキャッシュヒット率が低下していつもの傾向に戻るか否かを判定することにより、異常ふるまいがランサムウェアに起因するふるまいであるか否かを判定できる。なお、ステップ２１２５の判定は、便宜上、「第３判定」とも称呼される場合がある。

キャッシュヒット率がいつもの傾向に戻ったボリュームがある場合、キャッシュヒット率の低下はランサムウェアによるものだという可能性が低い。従って、この場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１２５にて「ＮＯ」と判定してステップ２１９５に進んで本処理フローを一旦終了する。

キャッシュヒット率がいつもの傾向に戻ったボリュームがない場合、キャッシュヒット率の低下はランサムウェアによるものだという可能性が高い。従って、この場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１２５にて「ＹＥＳ」と判定してステップ２１３０に進む。

ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１３０に進むと、ストレージシステム１００を複数台のホストサーバＨＳＶで使用しているか否かを判定する。なお、ステップ２１３０の判定は、便宜上、「第４判定」とも称呼される場合がある。

ストレージシステム１００を複数台のホストサーバＨＳＶで使用している場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１３０にて「ＹＥＳ」と判定してステップ２１３５に進む。

ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１３５に進むと、他のホストサーバＨＳＶのボリュームも同様なキャッシュヒット率傾向となっているか否か（異常ふるまいが検知されたか否か）を判定する。図２１Ｂの説明文ＥＸ２３に示すように、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、例えば、他のＳｅｒｖｅｒＩｄ１０２に割り当てられているＬｄｅｖＩｄ２、ＬｄｅｖＩｄ６及びＬｄｅｖＩｄ３のボリュームが、ＬｄｅｖＩｄ１のキャッシュヒット率と同様なキャッシュヒット率傾向となっているか否かを判定する。なお、ステップ２１３５の判定は、便宜上、「第５判定」とも称呼される場合がある。

他のホストサーバＨＳＶのボリュームも同様なキャッシュヒット率傾向となっている場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１３５にて「ＹＥＳ」と判定してステップ２１４０に進んで、異常ふるまいをランサムウェアとして検知する（即ち、異常ふるまいをランサムウェアに起因するふるまい（ランサムウェアに起因する不正データアクセス）として検知する。）。その後、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１９５に進んで本処理フローを一旦終了する。

これに対して、他のホストサーバＨＳＶのボリュームも同様なキャッシュヒット率傾向となっていない場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１３５にて「ＮＯ」と判定してステップ２１９５に進んで本処理フローを一旦終了する。

なお、ステップ２１３０にて、ストレージシステム１００を複数台のホストサーバＨＳＶで使用していない場合、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１３０にて「ＮＯ」と判定して、ステップ２１４０に進み、異常ふるまいをランサムウェアとして検知する（即ち、異常ふるまいをランサムウェアに起因するふるまい（ランサムウェアに起因する不正データアクセス）として検知する。）。その後、ランサムウェア判定プログラム（キャッシュヒット率観点）３８０は、ステップ２１９５に進んで本処理フローを一旦終了する。

図２２Ａはランサムウェア判定プログラム（データアクセス速度観点）３９０が実行する処理フローを示すフローチャートである。図２２Ｂは図２２Ａの処理フローの理解を容易にするための具体例を説明するための図である。ランサムウェア判定プログラム（データアクセス速度観点）３９０は、ステップ２２００から処理を開始して以下に述べるステップ２２０５及びステップ２２１０の処理を順に実行した後、ステップ２２１５に進む。

ステップ２２０５：ランサムウェア判定プログラム（データアクセス速度観点）３９０は、データへのアクセス速度について、異常ふるまいが検知されたボリュームのＬｄｅｖＩｄを取得する。図２２Ｂに示すように、ランサムウェア判定プログラム（データアクセス速度観点）３９０は、例えば、異常ふるまいが検知されたボリュームのＬｄｅｖＩｄ１を取得する。

ステップ２２１０：ランサムウェア判定プログラム（データアクセス速度観点）３９０は、ボリューム－サーバ関係テーブル３００を参照して、該当ボリュームの割り当てられているホストサーバＨＳＶのＳｅｒｖｅｒＩｄを特定する。図２２Ｂに示すように、ランサムウェア判定プログラム（データアクセス速度観点）３９０は、例えば、ボリューム－サーバ関係テーブル３００の矢印ｇ２が示すレコードからＬｄｅｖＩｄ１のボリュームが割り当てられているＳｅｒｖｅｒＩｄ１０１を特定する。

その後、ランサムウェア判定プログラム（データアクセス速度観点）３９０は、ステップ２２１５に進み、他のホストサーバＨＳＶのボリュームも同様な傾向となっているか否かを判定する。図２２Ｂの説明文ＥＸ３１に示すように、ランサムウェア判定プログラム（データアクセス速度観点）３９０は、例えば、他のＳｅｒｖｅｒＩｄ１０２に割り当てられているＬｄｅｖＩｄ２及びＬｄｅｖＩｄ６、他のＳｅｒｖｅｒＩｄ１０３に割り当てられているＬｄｅｖＩｄ３のボリュームのデータアクセス速度が、ＬｄｅｖＩｄ１と同様なデータアクセス速度傾向（即ち、異常ふるまい）となっているか否かを判定する。

他のホストサーバＨＳＶのボリュームも同様な傾向となっている場合、ランサムウェア判定プログラム（データアクセス速度観点）３９０は、ステップ２２１５にて「ＹＥＳ」と判定してステップ２２２０に進み、異常ふるまいをランサムウェアとして検知する（即ち、異常ふるまいをランサムウェアに起因するふるまい（ランサムウェアに起因する不正データアクセス）として検知する。）。その後、ランサムウェア判定プログラム（データアクセス速度観点）３９０は、ステップ２２９５に進んで本処理フローを一旦終了する。

これに対して、他のホストサーバＨＳＶのボリュームも同様な傾向となっていない場合、ランサムウェア判定プログラム（データアクセス速度観点）３９０は、ステップ２２１５にて「ＮＯ」と判定してステップ２２９５に進んで本処理フローを一旦終了する。

＜効果＞
以上説明したように、本発明の実施形態に係るストレージシステム１００は、ランサムウェアによるデータ暗号化に至る前段階で、ランサムウェア（ランサムウェアによる不正なデータアクセス）を早期に検知することができる。ストレージシステム１００は、セキュリティ対策ソフトなどを用いらずに、クライアントＯＳにも依存せず、ストレージレイヤでランサムウェアによるデータ窃取（データ窃取時の不正なデータアクセス）を検出することができる。ストレージシステム１００は、データそのものの分析ではなく、ストレージシステム１００に固有のキャッシュヒット率やＩＯＰＳなどの指標を用いることでデータの中身によらず、ランサムウェアによる不正なデータアクセスを精度よく検知でき、セキュリティ対策を行うことができる。ストレージシステム１００は、事前の攻撃パターン分析やシグネチャーに頼らず、学習期間も設けず、常にデータへのアクセス傾向を監視し、今までに蓄積した通常時のパターンの情報と照合することで、通常業務をしながら、ランサムウェアの攻撃による不正アクセスを検出することができる。

＜＜変形例＞＞
本発明は上記実施形態に限定されることなく、本発明の範囲内において種々の変形例を採用することができる。

（変形例１）
上記実施形態において、「ランサムウェア判定」を省略して、異常ふるまいが検知された場合、その異常ふるまいがランサムウェアに起因する不正アクセスとして検知されて、「不正アクセス対応処理」が実行されるようにしてもよい。
（変形例２）
上記実施形態において、異常ふるまい検知処理１乃至異常ふるまい検知処理３の何れか一つの処理又は２つの処理が実行されることによって、異常ふるまいが検知されるようにしてもよい。
（変形例３）
上記実施形態において、閾値フィードバック及び監視間隔フィードバックの何れか一つが実行されるようにしてもよい。
（変形例４）
上記実施形態において、閾値フィードバック及び監視間隔フィードバックが省略されてもよい。
（変形例５）
上記実施形態において、（ランサムウェア判定チェック（キャッシュヒット率観点）及びランサムウェア判定チェック（データアクセス速度観点）の何れか一つが実行されるようにしてもよい。
（変形例６）
上記実施形態において、図２１Ａのステップ２１３０及びステップ２１３５の処理が省略されてもよい。

１００…ストレージシステム、２００…コントローラ、２１０…ＣＰＵ、２２０…メモリ、３１０…初期設定変更プログラム、３２０…データ蓄積プログラム、３３０…ボリュームキャッシュヒット率監視プログラム、３４０…サーバキャッシュ占用率監視プログラム、３５０…データアクセス速度監視プログラム、３６０…閾値フィードバックプログラム、３７０…監視間隔フィードバックプログラム、３８０…ランサムウェア判定プログラム（キャッシュヒット率観点）、３９０…ランサムウェア判定プログラム（データアクセス速度観点）、４００…キャッシュ、４２０…ＤＰボリューム

Claims (14)

1. コントローラとデータをキャッシュするキャッシュとを含み、複数のボリュームを１又は複数の計算機に提供するストレージシステムであって、
   前記コントローラは、
   所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第１パラメータを取得し、前記第１パラメータが第１閾値パラメータより小さいことを、異常ふるまいとして検知する第１異常ふるまい検知処理、
   所定のサンプリング間隔内の前記ボリュームに関連するサーバのサーバキャッシュ占用率に基づく第２パラメータを取得し、前記第２パラメータが第２閾値パラメータより大きいことを、異常ふるまいとして検知する第２異常ふるまい検知処理、及び、
   所定のサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第３パラメータを取得し、前記第３パラメータが第３閾値パラメータより小さいことを、異常ふるまいとして検知する第３異常ふるまい検知処理、
   の少なくとも一つを含む異常ふるまい検知処理を実行する、
   ように構成された、
   ストレージシステム。
2. 請求項１に記載のストレージシステムにおいて、
   前記コントローラは、
   前記第１異常ふるまい検知処理、前記第２異常ふるまい検知処理及び前記第３異常ふるまい検知処理の全てを含む前記異常ふるまい検知処理を実行する、
   ように構成された、
   ストレージシステム。
3. 請求項２に記載のストレージシステムにおいて、
   前記コントローラは、
   前記異常ふるまい検知処理によって、前記異常ふるまいを検知した場合に、前記異常ふるまいが前記ランサムウェアに起因するふるまいであるか否かを判定するランサムウェア判定を行い、
   前記ランサムウェア判定として、
   前記第１異常ふるまい検知処理及び前記第２異常ふるまい検知処理の少なくとも一つによって前記異常ふるまいを検知した前記ボリューム以外の他のボリュームのふるまいに基づいて、前記異常ふるまいが前記ランサムウェアに起因するふるまいであるか否かを判定し、
   前記ランサムウェア判定によって、前記異常ふるまいが前記ランサムウェアに起因するふるまいであると判定した場合、前記異常ふるまいを前記ランサムウェアによる不正なデータアクセスとして検知する、
   ように構成されたストレージシステム。
4. 請求項３に記載のストレージシステムにおいて、
   前記コントローラは、
   前記ランサムウェア判定として、
   前記第１異常ふるまい検知処理によって、前記異常ふるまいを検知した場合、前記異常ふるまいを検知した前記ボリュームが割り当てられた前記計算機を特定し、特定した前記計算機に割り当てられた、同様の前記異常ふるまいがある、前記異常ふるまいを検知した前記ボリューム以外の他のボリュームが存在するか否かを判定する第１判定を行い、
   前記第１判定によって、同様の前記異常ふるまいがある前記他のボリュームが存在すると判定した場合に、前記異常ふるまいを検知した前記ボリューム及び前記他のボリュームのＩＯＰＳが所定の閾値ＩＯＰＳより大きいか否かを判定する第２判定を行い、
   前記第２判定によって、前記異常ふるまいを検知した前記ボリューム及び前記他のボリュームのＩＯＰＳが所定の閾値ＩＯＰＳより大きいと判定した場合、前記異常ふるまいを検知した前記ボリューム及び前記他のボリュームの中に、前記異常ふるまいが解消されたボリュームが存在するか否かを判定する第３判定を行い、
   前記第３判定によって、前記異常ふるまいが解消されたボリュームが存在しないと判定した場合、
   前記異常ふるまいを前記ランサムウェアによる不正なデータアクセスとして検知する、
   ように構成された、
   ストレージシステム。
5. 請求項４に記載のストレージシステムにおいて、
   前記コントローラは、
   前記第３判定によって、前記異常ふるまいを検知した前記ボリューム及び前記他のボリュームの中に、前記異常ふるまいが解消されたボリュームが存在すると判定した場合、
   特定した前記計算機以外にストレージシステムを使用している他の計算機が存在するか否かを判定する第４判定を行い、
   前記第４判定によって、特定した前記計算機以外にストレージシステムを使用している他の計算機が存在する場合、前記他の計算機に割り当てられた前記ボリュームも、同様の前記異常ふるまいが生じているか否かを判定する第５判定を行い、
   前記第５判定によって、前記他の計算機に割り当てられた前記ボリュームも、同様の前記異常ふるまいが生じていると判定した場合、前記異常ふるまいを前記ランサムウェアによる不正なデータアクセスとして検知する、
   ように構成された、
   ストレージシステム。
6. 請求項３に記載のストレージシステムにおいて、
   前記コントローラは、
   前記ランサムウェア判定として、
   前記第１異常ふるまい検知処理によって、前記異常ふるまいを検知した場合、前記異常ふるまいを検知した前記ボリュームが割り当てられた前記計算機を特定し、特定した前記計算機以外の他の計算機のボリュームのデータアクセス速度に基づく前記第３パラメータが前記第３閾値パラメータより小さいと判定した場合、前記異常ふるまいを前記ランサムウェアによる不正なデータアクセスとして検知する、
   ように構成された、
   ストレージシステム。
7. 請求項１に記載のストレージシステムにおいて、
   前記コントローラは、
   前記ボリュームのキャッシュヒット率、前ボリュームのキャッシュ占用率及び前記ボリュームのデータアクセス速度を含む過去データを取得し、前記過去データに基づいて、前記第１閾値パラメータ、前記第２閾値パラメータの計算用パラメータ及び前記第３閾値パラメータを更新する、閾値フィードバック処理を実行する、
   ように構成された、
   ストレージシステム。
8. 請求項７に記載のストレージシステムにおいて、
   前記コントローラは、
   前記過去データについて、監視間隔毎にサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第１パラメータを取得し、取得した前記第１パラメータの最小値を前記第１閾値パラメータとし、
   前記過去データについて、監視間隔毎にサンプリング間隔内の前記ボリュームのキャッシュ占用率に基づく前記第２パラメータの計算用パラメータを取得し、取得した前記第２パラメータ計算用のパラメータの最大値を前記第２閾値パラメータの計算用パラメータとし、
   前記過去データについて、監視間隔毎にサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第３パラメータを取得し、取得した前記第３パラメータの最小値を前記第３閾値パラメータとする、
   ように構成された、
   ストレージシステム。
9. 請求項８に記載のストレージシステムにおいて、
   前記コントローラは、
   前記過去データに基づいて、第１時点と、前記第１時点と同様のデータ変化傾向を示す第２時点との間の期間を前記監視間隔として設定する、監視間隔フィードバック処理を実行する、
   ように構成された、
   ストレージシステム。
10. 請求項１に記載のストレージシステムにおいて、
    前記コントローラは、
    前記所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率の傾き、面積又は平均値を前記第１パラメータとして算出し、
    前記所定のサンプリング間隔内の前記ボリュームのキャッシュ占用率の傾き、面積又は平均値を前記第２パラメータの計算用パラメータとして算出し、
    前記所定のサンプリング間隔内の前記ボリュームのデータアクセス速度の傾き、面積又は平均値を前記第３パラメータとして算出する、
    ように構成された、
    ストレージシステム。
11. 請求項３に記載のストレージシステムにおいて、
    前記コントローラは、
    前記異常ふるまいを、前記ランサムウェアによる不正なデータアクセスとして検知した場合、不正なデータアクセスに対応するための不正アクセス対応処理を実行する、
    ように構成された、
    ストレージシステム。
12. 請求項１１に記載のストレージシステムにおいて、
    前記コントローラは、
    前記不正アクセス対応処理として、
    不正なデータアクセスがあった計算機を特定し、特定した前記計算機の前記ボリュームへのパスを切断する処理を行う、
    ように構成された、
    ストレージシステム。
13. 請求項１１に記載のストレージシステムにおいて、
    前記コントローラは、
    前記不正アクセス対応処理として、
    ユーザの端末に不正なデータアクセスがあった旨を通知する通知処理と、
    前記計算機へ転送するデータの転送量を減少させる処理及びストレージシステム内のデータの転送速度を低下させる処理の少なくとも一つの処理と、
    を行う、
    ように構成された、
    ストレージシステム。
14. コントローラとデータをキャッシュするキャッシュとを含み、複数のボリュームを１又は複数の計算機に提供するストレージシステムにおける不正アクセス検知方法であって、
    前記コントローラによって、
    所定のサンプリング間隔内の前記ボリュームのキャッシュヒット率に基づく第１パラメータを取得し、前記第１パラメータが第１閾値パラメータより小さいことを、異常ふるまいとして検知する第１異常ふるまい検知、
    所定のサンプリング間隔内の前記ボリュームに関連するサーバのサーバキャッシュ占用率に基づく第２パラメータを取得し、前記第２パラメータが第２閾値パラメータより大きいことを、異常ふるまいとして検知する第２異常ふるまい検知、及び、
    所定のサンプリング間隔内の前記ボリュームのデータアクセス速度に基づく第３パラメータを取得し、前記第３パラメータが第３閾値パラメータより小さいことを、異常ふるまいとして検知する第３異常ふるまい検知、
    の少なくとも一つを含む異常ふるまい検知を実行する、
    不正アクセス検知方法。

Images