JP2018180595A - セキュリティ対策提案装置、セキュリティ対策提案方法及びプログラム - Google Patents

Abstract

【課題】効果的なセキュリティ対策の選定を支援すること。【解決手段】セキュリティ対策提案装置は、コンピュータシステムのセキュリティに関する複数の対策の中から、いずれか１以上の対策の選択を受け付ける受付部と、前記複数の対策それぞれについて、安全性に関する各条件の充足の有無及び実施に要するコストを記憶した記憶部を参照して、それぞれが選択された対策を１以上の含む対策の組み合わせの中から、前記各条件を充足する組み合わせを抽出する抽出部と、抽出された各組み合わせに含まれる各対策の前記コストに基づいて、当該各組み合わせを比較する比較部と、比較結果に基づいて提案対象の対策を出力する出力部と、を有する。【選択図】図６

Description

本発明は、セキュリティ対策提案装置、セキュリティ対策提案方法及びプログラムに関する。

Ｗｅｂブラウザを利用してアクセスされるコンピュータシステムの形態には、従来の２者モデルに加えて、ＷｅｂＡＰＩシステムに代表される３者モデルが存在する。

図１は、２者モデルを説明するための図である。２者モデルにおいて、各ユーザのデータを管理するＷｅｂサーバにアクセスするクライアントは、Ｗｅｂサーバのみから配信され、ブラウザ上において実行されるＪａｖａＳｃｒｉｐｔ（登録商標）プログラム等に限定される。したがって、情報漏洩や不正なりすましによる利用を防ぐためには、ブラウザのユーザの違いのみに基づいてアクセス制限が行われれば十分である。すなわち、２者モデルでは、不正なりすましだけを考慮すれば十分である。

一方、図２は、３者モデル（ＷｅｂＡＰＩシステム）を説明するための図である。３者モデルにおいて、各ユーザのデータを管理するリソースサーバは、ＷｅｂＡＰＩによってクライアントからアクセスされる。斯かるクライアントは、様々な事業者が様々な形態で提供することがあるため、１つのリソースサーバに対して複数種類のクライアントがアクセスする可能性が有る。また、１ブラウザ（ユーザ）が、複数種類のクライアントを介してリソースサーバにアクセスする可能性も有る。このように、１つのリソースサーバから見て、複数種類のクライアントが存在するシステム環境を、ここでは「３者モデル」と呼んでいる。

ＷｅｂＡＰＩシステムにおいて、代表的なクライアントの形態としては、ＪａｖａＳｃｒｉｐｔ（登録商標）で記述されたユーザサイドのマシンで実行されるプログラムであるが、これ以外にもスマートフォンアプリも存在する。また、リソースサーバとは別の事業者のサーバ上で実行されるサーバプログラムであるマッシュアップもクライアントの一例である。ＷｅｂＡＰＩシステムでは、クライアント形態のバリエーションが増えたため、従来の２者モデルではなく３者モデルとして考える必要がある。

１つのリソースサーバから見て複数のクライアントが存在する３者モデルを前提に、情報漏洩や不正なりすまし利用を防ぐためには、２者モデルの場合と異なりユーザ認証だけでは不十分である。ユーザ認証に加え、クライアントの認証と、ユーザとクライアントのペア検証とを合わせた３条件を満たすことが必要となる。

すなわち、２者モデルと同様に、ユーザの不正ななりすましによって、別のユーザのデータがリソースサーバから取得されるのを防ぐためにユーザ認証が必要である。

また、３者モデルでは複数種類のクライアントが存在するところ、多くのケースでクライアント毎にアクセスできるデータの範囲やアクセス権が異なる。クライアントの不正なりすましによって、本来の権限を越えたアクセスを防ぐために、リソースサーバがクライアントの認証を行う必要がある。

更に、ユーザとクライアントのペア検証の必要性について説明する。通常、ユーザはクライアントをアプリ名やＵＲＬ（Uniform Resource Locator）等の名称などから識別して、リソースサーバから取得される自身のデータの内容や、クライアントの利用目的に応じて、各クライアントについて当該データの対する利用の許否を決める。このため、ユーザが、或るクライアントに対してデータの利用を許可し、他のクライアントに対して不許可を決めた場合、リソースサーバは、当該他のクライアントが当該ユーザのデータにアクセスするのを防ぐ必要がある。

仮に、ユーザとクライアントのペア検証がおろそかにされた場合、図３に示すような状況が発生しうる。図３は、ユーザとクライアントのペアのなりすましの一例を示す図である。図３において、ユーザＸは、ユーザＸの個人データへのアクセスについて、クライアントＣＬ_１にはリードのみを許可し、クライアントＣＬ_２にはリード・ライトの双方を許可している。例えば、ユーザＸが、クライアントＣＬ_１を利用中に、クライアントＣＬ_１からクライアントＣＬ_２に対してユーザＸのトークンｘが横流しされると、クライアントＣＬ_２は、ユーザＸとクライアントＣＬ_２とのペアになりすまして、ユーザＸの個人データにライト（書き込み）を行えてしまう。ユーザＸのトークンｘの横流しは現実的な攻撃であり、例えば、クライアントＣＬ_１とクライアントＣＬ_２とが結託している場合や、クライアントＣＬ_１とクライアントＣＬ_２とが同一事業者に属し、認証秘密情報を共有している場合等に起こりうる。なお、クライアントＣＬ_２は、別のユーザが利用を許可するかもしれない正規のクライアントであるため、前述のクライアント認証にはパスする。このため、３者モデルのシステム環境では、ユーザ認証とクライアント認証だけでは不十分であり、ユーザとクライアントのペア検証が必要となる。

したがって、ＷｅｂＡＰＩシステムにおいては、上記の３つの条件を満たすことができるセキュリティ対策の導入が必要とされる。

特開２００９−１１０１７７号公報 特開２００１−１５５０８１号公報 特開２０１６−４５７３６号公報

但し、ＷｅｂＡＰＩシステムのビジネス環境には、以下のような特徴が有るため、セキュリティ対策の導入には、以下のような特徴が考慮される必要が有る。

第１に、技術の採否に制約があるという特徴が有る。ＷｅｂＡＰＩシステムでは、既存の外部サービスなどを利用するケースが多いため、システム設計の段階で既に採用できる技術に制約があることがある。当該技術にはＳＳＬ暗号化通信など、セキュリティ対策に関わる技術も含まれる。例えば、ビジネス戦略の都合から、クライアントをスマートフォンアプリとして提供することを決定した場合、ブラウザには利用できた同一オリジンポリシー（ＳＯＰ（Same-Origin Policy））をセキュリティ対策として採用することができない。また、リソースサーバにＧｏｏｇｌｅ（登録商標）などの既存サービスを利用する場合、接続方式の技術がＯＡｕｔｈ２．０などに指定されている場合も考えられる。

第２に、システム変更の機会が多いという特徴が有る。ＷｅｂＡＰＩシステムでは、サービス規模の拡大によって、システム構成や採用技術が変わることが有る。例えば、サポートするデバイスの種類を増やすケースや、利用していた他社既存サービスの技術的な仕様が変更されることが考えられる。

第３に、セキュリティ対策についてサンクコストが存在するという特徴が有る。既に述べたように、ＷｅｂＡＰＩシステムではビジネス環境や外部環境に依存して、既に採用せざるを得ない技術が存在するケースが多い。既に採用済みの技術は、既に投資済みのコスト（サンクコスト）である。投資対効果を考える場合の総対策コストからサンクコストを除外して、セキュリティ対策同士を比較しないと正しい判断ができない。これは、採用済の技術がセキュリティ対策に寄与しなくても他の対策とセキュリティ上の効果が重複していて無駄であっても、必ず導入する必要があるため、サンクコストの大小はセキュリティ対策の決定に影響を与えないためである。つまり、コストに基づいて各セキュリティ対策の採否を決定する場合には、各セキュリティ対策に対応する技術が採用済みかどうかに基づいて、サンクコストに該当するか否かを判別し、総対策コストから除外される必要がある。

例えば、図４の（１）において、プランＡは、セキュリティ対策として対策Ａ及び対策Ｂを含むプランであり、プランＢは対策Ｃ及び対策Ｄを含むプランであることが示されている。また、各対策を示す矩形の高さは、各対策のコストに対応する。したがって、プランＡとプランＢとを単純に比較した場合、プランＢの方が低コストということになる。しかし、対策Ａが採用済みの対策である場合、図４の（２）のように、プランＡからは対策Ａのコストを除外する必要がある。そうすると、プランＡの方が低コストということになる。

そこで、一側面では、本発明は、効果的なセキュリティ対策の選定を支援することを目的とする。

一つの態様では、セキュリティ対策提案装置は、コンピュータシステムのセキュリティに関する複数の対策の中から、いずれか１以上の対策の選択を受け付ける受付部と、前記複数の対策それぞれについて、安全性に関する各条件の充足の有無及び実施に要するコストを記憶した記憶部を参照して、それぞれが選択された対策を１以上の含む対策の組み合わせの中から、前記各条件を充足する組み合わせを抽出する抽出部と、抽出された各組み合わせに含まれる各対策の前記コストに基づいて、当該各組み合わせを比較する比較部と、比較結果に基づいて提案対象の対策を出力する出力部と、を有する。

一側面として、効果的なセキュリティ対策の選定を支援することができる。

２者モデルを説明するための図である。 ３者モデル（ＷｅｂＡＰＩシステム）を説明するための図である。 ユーザとクライアントのペアのなりすましの一例を示す図である。 サンクコストの影響を説明するための図である。 第１の実施の形態におけるセキュリティ対策提案装置１０のハードウェア構成例を示す図である。 第１の実施の形態におけるセキュリティ対策提案装置１０の機能構成例を示す図である。 第１の実施の形態におけるセキュリティ対策提案装置１０が実行する処理手順の一例を説明するためのフローチャートである。 対策情報記憶部１２１の構成例を示す図である。 第１の実施の形態の具体例を示す図である。 第２の実施の形態におけるセキュリティ対策提案装置１０の機能構成例を示す図である。 第２の実施の形態におけるセキュリティ対策提案装置１０が実行する処理手順の一例を説明するためのフローチャートである。 第２の実施の形態の具体例を示す図である。 第３の実施の形態の具体例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図５は、第１の実施の形態におけるセキュリティ対策提案装置１０のハードウェア構成例を示す図である。図５のセキュリティ対策提案装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

セキュリティ対策提案装置１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってセキュリティ対策提案装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等であり、様々な操作指示を入力させるために用いられる。

なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

図６は、第１の実施の形態におけるセキュリティ対策提案装置１０の機能構成例を示す図である。図６において、セキュリティ対策提案装置１０は、選択部１１、安全性判定部１２及び出力部１３等を有する。これら各部は、セキュリティ対策提案装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。セキュリティ対策提案装置１０は、また、対策情報記憶部１２１を利用する。対策情報記憶部１２１は、例えば、補助記憶装置１０２、又はセキュリティ対策提案装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

選択部１１は、ＷｅｂＡＰＩシステムのような３者モデルを採用するコンピュータシステムに関して、対策情報記憶部１２１に評価対象の候補として記憶されている複数のセキュリティ対策の中から、評価対象とする１以上のセキュリティ対策の選択をユーザから受け付ける。例えば、当該ユーザは、図２に示されるような構成を有するＷｅｂＡＰＩシステムにおけるクライアントの開発者であってもよい。

安全性判定部１２は、評価対象として選択されたセキュリティ対策の組み合わせについて、安全性の各条件（ユーザ認証、クライアント認証、及びユーザとクライアントのペア検証）について、対策情報記憶部１２１を参照して充足の有無を判定（評価）し、全ての条件について安全性が満たされる場合に、選択されたセキュリティ対策の組み合わせは安全であると判定する。

出力部１３は、安全性判定部１２による判定結果を出力する。

対策情報記憶部１２１には、選択候補のセキュリティ対策ごとに、安全性の各条件について充足の有無（評価結果）と、コストとが記憶されている。

以下、セキュリティ対策提案装置１０が実行する処理手順について説明する。図７は、第１の実施の形態におけるセキュリティ対策提案装置１０が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ１０１において、選択部１１は、対策情報記憶部１２１に記憶されているセキュリティ対策名の一覧を選択候補として表示装置１０６に表示する。

図８は、対策情報記憶部１２１の構成例を示す図である。図８に示されるように、対策情報記憶部１２１は、評価候補のセキュリティ対策ごとに、セキュリティ対策名、安全性条件の評価値、及びコスト等が記憶されている。

セキュリティ対策名は、セキュリティ対策の技術名である。安全性条件の評価値は、セキュリティ対策について予め行われた、安全性の３条件（ユーザ認証、クライアント認証、及びペア検証）の評価結果を示す値である。ユーザ認証とは、ブラウザの認証が行われることの条件である。クライアント認証とは、クライアントの認証が行われることの条件である。ペア検証とは、ユーザとクライアントのペアの検証が行われることの条件である。

図８において、○は、有効であることを示し、×は、無効であることを示す。有効とは、当該条件に対して有効な対策であること（当該条件を充足すること）をいう。無効とは、当該条件に対して無効な対策であること（当該条件を充足しないこと）をいう。コストは、対策の実施に要されるコストが数値化されたものである。コストの数値化には、技術導入の実費金額や、技術的難易度等が考慮されてもよい。なお、対策情報記憶部１２１には、安全性の３条件のうちの少なくともいずれか１条件について有効なセキュリティ対策が予め登録される。

ステップＳ１０１では、対策情報記憶部１２１に記憶されている全てのセキュリティ対策名が選択候補として表示される。

続いて、選択部１１は、選択候補の中から１以上の評価対象の選択をユーザから受け付ける（Ｓ１０２）。すなわち、ユーザは、例えば、採用を検討している１以上のセキュリティ対策について、セキュリティ対策名を選択する。すなわち、複数のセキュリティ対策名が評価対象として選択されてもよい。

続いて、安全性判定部１２は、評価対象として選択されたセキュリティ対策名ごとに、ステップＳ１１１及びＳ１１２を実行する。以下、処理対象とされているセキュリティ対策名を、「対象対策名」という。ステップＳ１１１において、安全性判定部１２は、対象対策名に対応付けられて対策情報記憶部１２１に記憶されている、「ユーザ認証」の評価値を取得する。続いて、安全性判定部１２は、当該評価値が「○（有効）」であるか否かを判定する（Ｓ１１２）。

全ての評価対象について当該評価値が「×（無効）」である場合、ステップＳ１４１に進む。ステップＳ１４１において、安全性判定部１２は、評価対象とされたセキュリティ対策の組み合わせは、安全でないと判定する。この場合、出力部１３は、安全でないことを示すメッセージ等を表示装置１０６に表示する。

一方、評価対象のうちのいずれかのセキュリティ対策名について当該評価値が「○（有効）」である場合、安全性判定部１２は、評価対象として選択されたセキュリティ対策名ごとに、ステップＳ１２１及びＳ１２２を実行する。以下、処理対象とされているセキュリティ対策名を、「対象対策名」という。ステップＳ１２１において、安全性判定部１２は、対象対策名に対応付けられて対策情報記憶部１２１に記憶されている、「クライアント認証」の評価値を取得する。続いて、安全性判定部１２は、当該評価値が「○（有効）」であるか否かを判定する（Ｓ１２２）。

全ての評価対象について当該評価値が「×（無効）」である場合、ステップＳ１４１に進む。一方、評価対象のうちのいずれかのセキュリティ対策名について当該評価値が「○（有効）」である場合、安全性判定部１２は、評価対象として選択されたセキュリティ対策名ごとに、ステップＳ１３１及びＳ１３２を実行する。以下、処理対象とされているセキュリティ対策名を、「対象対策名」という。

ステップＳ１３１において、安全性判定部１２は、対象対策名に対応付けられて対策情報記憶部１２１に記憶されている、「ペア検証」の評価値を取得する。続いて、安全性判定部１２は、当該評価値が「○（有効）」であるか否かを判定する（Ｓ１３２）。全ての評価対象について当該評価値が「×（無効）」である場合、ステップＳ１４１に進む。一方、評価対象のうちのいずれかのセキュリティ対策名について当該評価値が「○（有効）」である場合、安全性判定部１２は、評価対象とされたセキュリティ対策の組み合わせは、安全あると判定する（Ｓ１４２）。この場合、出力部１３は、安全であることを示すメッセージ等を表示装置１０６に表示する。

図９は、第１の実施の形態の具体例を示す図である。図９では、評価候補の中から、「利用者認証（認証ｃｏｏｋｉｅ）」と「クライアントサイトの限定」との組み合わせが評価対象として選択された例が示されている。この場合、「利用者認証（認証ｃｏｏｋｉｅ）」について、「ユーザ認証」、「クライアント認証」、「ペア検証」の３つの安全性条件に対する評価値は、「○、×、×」である。一方、「クライアントサイトの限定」について、「ユーザ認証」、「クライアント認証」、「ペア検証」の３つの安全性条件に対する評価値は、「×、○、○」である。この２つの評価値について、安全性条件ごとにＯＲをとる（論理和を求める）と、「○、○、○」となる。したがって、この場合、当該組み合わせは、安全であると判定される。

上述したように、第１の形態によれば、ユーザが評価対象として選択したセキュリティ対策の組み合わせについて、各安全性条件の有効性に基づいて、自動的に安全性が判定（評価）され、判定結果が出力される。安全でないとの結果が得られた場合には、ユーザは、セキュリティ対策の組み合せを変更して安全性の評価を繰り返すことで、安全なセキュリティ対策の組み合わせを得ることができる。したがって、効果的なセキュリティ対策の選定を支援することができる。また、セキュリティ分析に詳しくない開発者でも安全性の評価を得ることができる。

なお、安全性判定部１２は、判定結果が安全でない場合、満足できていない安全性条件を満足するセキュリティ対策の組み合わせを抽出して出力してもよい。

次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において、特に言及されない点については、第１の実施の形態と同様でもよい。

ＷｅｂＡＰＩシステムでは、ビジネス環境や外部環境に依存して、セキュリティ対策に関する技術も含めて、採用が必要な技術や採用できない技術が決まっている場合がある。第２の実施の形態では、技術の採用に関する条件を、各セキュリティ対策の採用の確度情報としてユーザに入力させて、当該条件を満たすセキュリティ対策の組み合わせを提案する例について説明する。

図１０は、第２の実施の形態におけるセキュリティ対策提案装置１０の機能構成例を示す図である。図１０中、図６と同一部分には同一符号を付し、その説明は省略する。

図１０において、セキュリティ対策提案装置１０は、確度情報付与部１４、安全プラン抽出部１５、プラン比較部１６及び出力部１３を有する。これら各部は、セキュリティ対策提案装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

確度情報付与部１４は、対策情報記憶部１２１に登録されているセキュリティ対策ごとに、採用の確度情報をユーザから受け付ける。採用の確度情報は、セキュリティ対策ごとに、「採用」、「任意」及び「不採用」の中から選択されることで付与される。

「採用」は、当該セキュリティ対策の安全性条件に対する有効性への寄与の有無に関わらず、必ず採用すること（採用が必須であること）を意味する。「任意」は、安全性条件の有効性に対して寄与する場合にのみ採用することを意味する。「不採用」は、採用することができないこと（採用が不可能であること）を意味する。

安全プラン抽出部１５は、対策情報記憶部１２１に登録されているセキュリティ対策について取りうる全ての組み合わせの中から、安全であり（３つの安全性条件を充足し）、かつ、確度情報を満たす組み合わせを抽出する。なお、１以上のセキュリティ対策の組み合わせを「プラン」という。

プラン比較部１６は、安全プラン抽出部１５によって抽出された各プランを、それぞれに含まれるセキュリティ対策のコストに基づいて比較する。具体的には、プラン比較部１６は、当該各プランの総コストを比較し、総コストが最も低いプランを提案対象として決定する。各プランの総コストは、当該プランに係るセキュリティ対策について対策情報記憶部１２１に記憶されているコストの合計によって算出される。但し、採用の確度情報が「採用」であるセキュリティ対策のコストを総コストに含めないことで、サンクコストを含まない総コストが算出される。その結果、費用対効果が最も高いプランを正しく判別することができる。

出力部１３は、プラン比較部１６による比較結果を出力する。

図１１は、第２の実施の形態におけるセキュリティ対策提案装置１０が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ２０１において、確度情報付与部１４は、対策情報記憶部１２１に記憶されているセキュリティ対策名ごとに、確度情報（採用／任意／不採用）の入力をユーザから受け付け、入力された確度情報を各セキュリティ対策名に付与する。なお、確度情報の入力は、セキュリティ対策の選択の一例に該当する。

続いて、安全プラン抽出部１５は、対策情報記憶部１２１に記憶されているセキュリティ対策名の全ての組み合わせ（プラン）を列挙し、列挙結果をプランリストに代入する（Ｓ２０２）。すなわち、対策情報記憶部１２１に記憶されているセキュリティ対策名の集合について、全てに部分集合が列挙される。したがって、Ｎ個のセキュリティ対策名が対策情報記憶部１２１に記憶されている場合、（２^Ｎ−１）個のプランが列挙される。

続いて、安全プラン抽出部１５は、プランリストに含まれるプランごと（部分集合）ごとに、ステップＳ２０３〜Ｓ２０７を含むループ処理を実行する。以下、当該ループ処理において処理対象とされているプランを、「対象プラン」という。

ステップＳ２０３において、安全プラン抽出部１５は、対象プランが、全ての安全性条件を満たすか否かを判定する。すなわち、対象プランが、「ユーザ認証」、「クライアント認証」及び「ペア検証」の全てについて、有効であるか否かが判定される。斯かる判定は、図７のステップＳ１１１〜Ｓ１４２を実行することで行うことができる。

対象プランが、全ての安全性条件を満たす場合（Ｓ２０３でＹｅｓ）、安全プラン抽出部１５は、対象プランが、確度情報として「採用」が付与された全てのセキュリティ対策名を含むか否かを判定する（Ｓ２０４）。

対象プランが、確度情報として「採用」が付与された全てのセキュリティ対策名を含む場合（Ｓ２０４でＹｅｓ）、安全プラン抽出部１５は、対象プランが、確度情報として「不採用」が付与されたいずれかのセキュリティ対策名を含むか否かを判定する（Ｓ２０５）。

対象プランが、確度情報として「不採用」が付与されたいずれのセキュリティ対策名も含まない場合（Ｓ２０５でＮｏ）、プラン比較部１６は、対象プランに含まれるセキュリティ対策名のうち、確度情報として「任意」が付与されたセキュリティ対策名について対策情報記憶部１２１に記憶されているコストを合計することで、対象プランの総コストを算出する（Ｓ２０６）。

一方、対象プランが、いずれかの安全性条件を満たすことができない場合（Ｓ２０３でＮｏ）、確度情報として「採用」が付与されたいずれかのセキュリティ対策名を含まない場合（Ｓ２０４でＮｏ）、又は確度情報として「不採用」が付与されたいずれかのセキュリティ対策名を含む場合（Ｓ２０５でＹｅｓ）、安全プラン抽出部１５は、対象プランをプランリストから除去する（Ｓ２０７）。

ループ処理が、プランリストに含まれる全てのプランについて実行されると、プラン比較部１６は、プランリストに含まれているプランの中で、総コストが最小のプランを提案対象として決定する（Ｓ２０８）。

続いて、出力部１３は、提案対象として決定されたプランに含まれるセキュリティ対策名を出力する（Ｓ２０９）。この際、当該プランの総コストが出力されてもよい。

図１２は、第２の実施の形態の具体例を示す図である。図１２の（１）には、確度情報の付与結果の一例が示されている。（２）には、この場合に確度情報を満たすセキュリティ対策のプランが示されている。なお、各セキュリティ対策は、＃１〜＃５の記号によって示されている。また、これらのプランについて、安全性（３つの安全性条件）を満たすか（○）否か（×）が、（３）に示されている。更に、安全性を満たすプランについて、確度情報が「採用」であるセキュリティ対策を除く総コストが（４）に示されている。（４）によれば、総コストが最小であるプランは、＃１＋＃５である。したがって、この場合、＃１＋＃５が、提案対象として出力される。

なお、上記では、総コストが最小であるプランのみが出力される例に付いて説明したが、ステップＳ２０８の時点においてプランリストに含まれている全てのプラン（すなわち、安全性条件及び確度情報の条件を満たすプラン）が提案対象として出力されてもよい。この場合、総コストに基づいて順位付けが行われてもよい。具体的には、プラン比較部１６は、ステップＳ２０８において、総コストの降順でプランリストをソートする。出力部１３は、ソート結果の順番で、プランリストに含まれる各プランを出力する。

上述したように、第２の実施の形態によれば、セキュリティ対策の採否の条件（確度情報）の指定が可能とされ、当該条件を満たし、かつ、安全性条件を満たすセキュリティ対策のプランが出力される。また、各プランについて、コストの観点における優劣に基づく出力も行われる。この際、既に採用済のセキュリティ対策のサンクコストを除外して優劣が判定される。したがって、ビジネス環境における様々な制約が考慮された、効果的なセキュリティ対策の選定を支援することができる。

次に、第３の実施の形態について説明する。第３の実施の形態では第２の実施の形態と異なる点について説明する。第３の実施の形態において、特に言及されない点については、第２の実施の形態と同様でもよい。

第３の実施の形態では、対象のＷｅｂＡＰＩシステムの変更時に、安全性条件を満たしつつ、最も低コストで実現できる代替のセキュリティ対策のプランを提案する例について説明する。

この場合、ユーザは、ステップＳ２０１において、システムの変更に伴って変化した確度情報を入力する。その結果、ステップＳ２０９では、システムの変更に応じた提案対象が出力される。

図１３は、第３の実施の形態の具体例を示す図である。図１３の（１）には、システムの変更前に採用されていたセキュリティ対策のプランが、＃１＋＃４であることが示されている。

（２）には、システムの変更により＃４を採用できなくなったため、＃４の確度情報に「不採用」が付与されたことが示されている。（２）に示される確度情報と、図８に示される安全性条件に基づいて、図１１と同じ処理が実行された結果、（３）に示されるように、代替プランが出力される。なお、図１３では、総コストが最低であるプランが１位の代替対象として出力され、総コストが２番目に低いプランが２位の代替対象として出力される例が示されている。

上述したように、第３の実施の形態によれば、システム変更時（或るセキュリティ対策が採用から不採用に見直された時）に、代替のセキュリティ対策のプランを提案することができる。

なお、上記各実施の形態において、確度情報付与部１４は、受付部の一例である。対策情報記憶部１２１は、記憶部の一例である。安全プラン抽出部１５は、抽出部の一例である。プラン比較部１６は、比較部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
コンピュータシステムのセキュリティに関する複数の対策の中から、いずれか１以上の対策の選択を受け付ける受付部と、
前記複数の対策それぞれについて、安全性に関する各条件の充足の有無及び実施に要するコストを記憶した記憶部を参照して、それぞれが選択された対策を１以上の含む対策の組み合わせの中から、前記各条件を充足する組み合わせを抽出する抽出部と、
抽出された各組み合わせに含まれる各対策の前記コストに基づいて、当該各組み合わせを比較する比較部と、
比較結果に基づいて提案対象の対策を出力する出力部と、
を有することを特徴とするセキュリティ対策提案装置。
（付記２）
前記受付部は、前記複数の対策の中から、採用が必須である対策と、採用が不可能な対策との選択を受け付け、
前記抽出部は、前記組み合わせの中から、前記採用が必須である対策の全てを含み、かつ、前記採用が不可能な対策を含まない組み合わせであって、前記各条件を充足する組み合わせを抽出する、
ことを特徴とする付記１記載のセキュリティ対策提案装置。
（付記３）
前記比較部は、抽出された各組み合わせに含まれる各対策のうち前記採用が必須である対策を除く対策の前記コストに基づいて、当該各組み合わせを比較する、
ことを特徴とする付記２記載のセキュリティ対策提案装置。
（付記４）
コンピュータシステムのセキュリティに関する複数の対策の中から、いずれか１以上の対策の選択を受け付ける処理と、
前記複数の対策それぞれについて、安全性に関する各条件の充足の有無及び実施に要するコストを記憶した記憶部を参照して、それぞれが選択された対策を１以上の含む対策の組み合わせの中から、前記各条件を充足する組み合わせを抽出する処理と、
抽出された各組み合わせに含まれる各対策の前記コストに基づいて、当該各組み合わせを比較する処理と、
比較結果に基づいて提案対象の対策を出力する処理と、
をコンピュータが実行ことを特徴とするセキュリティ対策提案方法。
（付記５）
前記受け付ける処理は、前記複数の対策の中から、採用が必須である対策と、採用が不可能な対策との選択を受け付け、
前記抽出する処理は、前記組み合わせの中から、前記採用が必須である対策の全てを含み、かつ、前記採用が不可能な対策を含まない組み合わせであって、前記各条件を充足する組み合わせを抽出する、
ことを特徴とする付記４記載のセキュリティ対策提案方法。
（付記６）
前記比較する処理は、抽出された各組み合わせに含まれる各対策のうち前記採用が必須である対策を除く対策の前記コストに基づいて、当該各組み合わせを比較する、
ことを特徴とする付記５記載のセキュリティ対策提案方法。
（付記７）
コンピュータシステムのセキュリティに関する複数の対策の中から、いずれか１以上の対策の選択を受け付ける処理と、
前記複数の対策それぞれについて、安全性に関する各条件の充足の有無及び実施に要するコストを記憶した記憶部を参照して、それぞれが選択された対策を１以上の含む対策の組み合わせの中から、前記各条件を充足する組み合わせを抽出する処理と、
抽出された各組み合わせに含まれる各対策の前記コストに基づいて、当該各組み合わせを比較する処理と、
比較結果に基づいて提案対象の対策を出力する処理と、
をコンピュータに実行させることを特徴とするプログラム。
（付記８）
前記受け付ける処理は、前記複数の対策の中から、採用が必須である対策と、採用が不可能な対策との選択を受け付け、
前記抽出する処理は、前記組み合わせの中から、前記採用が必須である対策の全てを含み、かつ、前記採用が不可能な対策を含まない組み合わせであって、前記各条件を充足する組み合わせを抽出する、
ことを特徴とする付記７記載のプログラム。
（付記９）
前記比較する処理は、抽出された各組み合わせに含まれる各対策のうち前記採用が必須である対策を除く対策の前記コストに基づいて、当該各組み合わせを比較する、
ことを特徴とする付記８記載のプログラム。

１０ セキュリティ対策提案装置
１１ 選択部
１２ 安全性判定部
１３ 出力部
１４ 確度情報付与部
１５ 安全プラン抽出部
１６ プラン比較部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
１２１ 対策情報記憶部
Ｂ バス

Claims (5)

1. コンピュータシステムのセキュリティに関する複数の対策の中から、いずれか１以上の対策の選択を受け付ける受付部と、
   前記複数の対策それぞれについて、安全性に関する各条件の充足の有無及び実施に要するコストを記憶した記憶部を参照して、それぞれが選択された対策を１以上の含む対策の組み合わせの中から、前記各条件を充足する組み合わせを抽出する抽出部と、
   抽出された各組み合わせに含まれる各対策の前記コストに基づいて、当該各組み合わせを比較する比較部と、
   比較結果に基づいて提案対象の対策を出力する出力部と、
   を有することを特徴とするセキュリティ対策提案装置。
2. 前記受付部は、前記複数の対策の中から、採用が必須である対策と、採用が不可能な対策との選択を受け付け、
   前記抽出部は、前記組み合わせの中から、前記採用が必須である対策の全てを含み、かつ、前記採用が不可能な対策を含まない組み合わせであって、前記各条件を充足する組み合わせを抽出する、
   ことを特徴とする請求項１記載のセキュリティ対策提案装置。
3. 前記比較部は、抽出された各組み合わせに含まれる各対策のうち前記採用が必須である対策を除く対策の前記コストに基づいて、当該各組み合わせを比較する、
   ことを特徴とする請求項２記載のセキュリティ対策提案装置。
4. コンピュータシステムのセキュリティに関する複数の対策の中から、いずれか１以上の対策の選択を受け付ける処理と、
   前記複数の対策それぞれについて、安全性に関する各条件の充足の有無及び実施に要するコストを記憶した記憶部を参照して、それぞれが選択された対策を１以上の含む対策の組み合わせの中から、前記各条件を充足する組み合わせを抽出する処理と、
   抽出された各組み合わせに含まれる各対策の前記コストに基づいて、当該各組み合わせを比較する処理と、
   比較結果に基づいて提案対象の対策を出力する処理と、
   をコンピュータが実行ことを特徴とするセキュリティ対策提案方法。
5. コンピュータシステムのセキュリティに関する複数の対策の中から、いずれか１以上の対策の選択を受け付ける処理と、
   前記複数の対策それぞれについて、安全性に関する各条件の充足の有無及び実施に要するコストを記憶した記憶部を参照して、それぞれが選択された対策を１以上の含む対策の組み合わせの中から、前記各条件を充足する組み合わせを抽出する処理と、
   抽出された各組み合わせに含まれる各対策の前記コストに基づいて、当該各組み合わせを比較する処理と、
   比較結果に基づいて提案対象の対策を出力する処理と、
   をコンピュータに実行させることを特徴とするプログラム。

Images