JP2016192185A - なりすまし検出システムおよびなりすまし検出方法 - Google Patents

Abstract

【課題】ユーザのなりすましを確実に検出できるようにする。【解決手段】なりすまし検出システム１において、クラウドサービスのユーザに関する複数種のログを蓄積する記憶装置と、各ユーザに関する複数種のログを、クラウドサービスでの該当ユーザのセッション毎にグルーピングし、グルーピングしたセッション毎に該当各ログの所定項目を集約して第一の統合ログを生成し、これを所定アルゴリズムに適用して該当ユーザに関するプロファイルを作成し、その後に得たログについてグルーピングおよび統合ログの生成を実行して第二の統合ログを生成し、これをプロファイルに照合してなりすましのリスクを判定し、リスクが所定基準より高い場合に所定装置の所定情報を出力する演算装置を備える構成とする。【選択図】図１

Description

本発明は、なりすまし検出システムおよびなりすまし検出方法に関するものであり、具体的には、クラウドサービスにおけるユーザのなりすましを確実に検出する技術に関する。

近年、クラウドサービスの普及に伴い、ＩＴベンダが顧客企業にオンプレミス（社内設置）でシステムを提供する形態から、クラウドサービス（特にＳａａＳ；Ｓｏｆｔｗａｒｅ ａｓ Ｓｅｒｖｉｃｅ）で提供する形態に、サービス提供形態が変化しつつある。上述のオンプレミスの形態においては、閉じられた環境でシステムが使われるのに対し、クラウドサービスでは、インターネット経由での提供やマルチテナントでの提供など、オープンな環境でシステム提供がなされるため、そうしたクラウドサービス（特にＳａａＳ）のセキュリティ強化が必要である。

このようにオープンな環境で提供されるＳａａＳでは、ユーザ認証をパスすれば誰でもクラウドサービスを利用し、情報資産が格納されるデータベースにアクセスできる。そのため、他サイトで漏洩したＩＤとパスワードを活用し、標的とするサイトの認証を一度も失敗することなくパスするといった、リスト型攻撃も登場している。従ってこの場合、ユーザ認証のログを確認しても、攻撃を受けてなりすましに成功されたか否かを検出することは困難である。

こうしたログの分析に関連する技術としては、例えば、ユーザによる操作の記録であるシステムログを蓄積するシステムに対して、当該システムログを出力させ、前記システムに応じた変換ルールにしたがって、出力されたシステムログを変換するシステムログ収集ステップと、変換後のシステムログを登録するシステムログ登録ステップと、変換後のシステムログを対象に、分析を実行するための条件である分析設定情報に合致するシステムログを検索することで、不正な操作とみなされるシステムログを抽出するシステムログ検索ステップと、前記システムログ検索ステップにて抽出されたシステムログに示された不正な操作を行ったユーザのユーザ情報を、ディレクトリサービスシステムより取得するユーザ情報取得ステップと、を含むことを特徴とするシステムログ分析方法（特許文献１参照）などが提案されている。

特開２０１１−３０９０号公報

しかしながら従来技術においては、不正操作とみなされるシステムログを検索するための条件はユーザに非依存であって、画一的に設定されている。そのため、悪意のあるユーザが行う操作を全て事前に想定し、確実に対応することは難しい。

そこで本発明は、上記問題点に鑑みて成されたもので、クラウドサービスにおけるユーザのなりすましを確実に検出することを目的とする。

上記課題を解決する本発明のなりすまし検出システムは、クラウドサービスのユーザに
関する複数種のログを蓄積する記憶装置と、各ユーザに関する前記複数種のログを、前記クラウドサービスでの該当ユーザのセッション毎にグルーピングし、グルーピングしたセッション毎に該当各ログの所定項目を集約して第一の統合ログを生成し、前記第一の統合ログを所定アルゴリズムに適用して該当ユーザに関する前記クラウドサービスでの挙動特徴を示すプロファイルを作成する処理と、前記プロファイルの作成後に所定装置より得た、所定ユーザに関する複数種のログについて前記グルーピングおよび前記統合ログの生成を実行して第二の統合ログを生成し、当該第二の統合ログを、前記プロファイルのうち該当ユーザに関するものと照合し、所定アルゴリズムにより該当ユーザに関するなりすましのリスクを判定し、前記リスクが所定基準より高い場合に所定装置の所定情報を出力する処理を実行する演算装置と、を備えることを特徴とする。

また、本発明のなりすまし検出方法は、クラウドサービスのユーザに関する複数種のログを蓄積する記憶装置を備えた情報処理システムが、各ユーザに関する前記複数種のログを、前記クラウドサービスでの該当ユーザのセッション毎にグルーピングし、グルーピングしたセッション毎に該当各ログの所定項目を集約して第一の統合ログを生成し、前記第一の統合ログを所定アルゴリズムに適用して該当ユーザに関する前記クラウドサービスでの挙動特徴を示すプロファイルを作成する処理と、前記プロファイルの作成後に所定装置より得た、所定ユーザに関する複数種のログについて前記グルーピングおよび前記統合ログの生成を実行して第二の統合ログを生成し、当該第二の統合ログを、前記プロファイルのうち該当ユーザに関するものと照合し、所定アルゴリズムにより該当ユーザに関するなりすましのリスクを判定し、前記リスクが所定基準より高い場合に所定装置の所定情報を出力する処理と、を実行することを特徴とする。

本発明によれば、クラウドサービスにおけるユーザのなりすましを確実に検出できる。

本実施形態のなりすまし検出システムを含むネットワーク構成例を示す図である。 本実施形態におけるログ間トレース確認装置の機能構成例を示す図である 本実施形態におけるプロファイル学習装置の機能構成例を示す図である。 本実施形態におけるなりすまし検出装置の機能構成例を示す図である。 本実施形態における画面遷移例１を示す図である。 本実施形態におけるセッション管理テーブルのデータ例を示す図である。 本実施形態におけるＷｅｂアクセスログの構成例を示す図である。 本実施形態におけるＡＰＰ利用ログの構成例を示す図である。 本実施形態におけるＤＢアクセスログの構成例を示す図である。 本実施形態におけるなりすまし検出方法の全体フロー例を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例１を示すフロー図である。 本実施形態におけるなりすまし検出方法の処理手順例２を示すフロー図である。 本実施形態における第一中間ログ（Ｗｅｂアクセス）のデータ例を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例３を示すフロー図である。 本実施形態における第一中間ログ（ＡＰＰ利用）のデータ例を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例４を示すフロー図である。 本実施形態における第一中間ログ（ＤＢアクセス）のデータ例を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例５を示すフロー図である。 本実施形態における第二中間ログのデータ例を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例６を示すフロー図である。 本実施形態における統合ログのデータ例を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例７を示すフロー図である。 本実施形態における重み付けＤＢの構成例１を示す図である。 本実施形態における重み付けＤＢの構成例２を示す図である。 本実施形態における重み付けＤＢの構成例３を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例８を示すフロー図である。 本実施形態におけるプロファイル（決定木）の例を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例９を示すフロー図である。 本実施形態における画面遷移例２を示す図である。 本実施形態における出力画面例１を示す図である。 本実施形態におけるなりすまし検出方法の処理手順例１０を示すフロー図である。 本実施形態におけるログ間トレース確認処理に使うデータ例を示す図である。 本実施形態における出力画面例２を示す図である。 本実施形態におけるログ間トレースＤＢのデータ例を示す図である。

−−−システム構成−−−

以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のなりすまし検出システム１を含むネットワーク構成例を示す図である。図１に示すなりすまし検出システム１は、クラウドサービスにおけるユーザのなりすましを確実に検出するコンピュータシステムである。ここでまず、本実施形態におけるなりすまし検出システム１の位置づけを明確にするため、クラウドサービスのうち特にＳａａＳのサービス提供モデルと、本実施形態のなりすまし検出システム１との関係を、図１に基づき説明する。

この場合、ＳａａＳは、Ｗｅｂサーバ、ＡＰＰ（アプリケーション）サーバ、ＤＢ（データベース）サーバなどからなるＳａａＳ提供サーバ１０が、内部ネットワーク３０およびファイアウォール（ＦＷ）３１を経由して、外部ネットワーク３２に接続された各ユーザの端末４０ａ〜４０ｃにサービスを提供する形態を想定する。なお、サービスの提供主体は上述のＳａａＳ提供サーバ１０である。一方、このＳａａＳ提供サーバ１０にアクセスして、クラウドサービスの提供を受けるのは、上述の端末４０ａ〜４０ｃを操作する各ユーザ４１ａ〜４１ｃである。

ＳａａＳ提供サーバ１０に対し、例えば端末４０ａがアクセスすると、ＳａａＳ提供サーバ１０における認証管理部１１、セッション管理部１２、および動的ページ生成部１３が連動して該当アクセスを処理し、例えばユーザＡ画面１４ａを生成し、これを該当端末４０ａに返信する。なお、認証管理部１１では、ユーザＡ４１ａが端末４０ａで入力したＩＤとパスワードを取得し、これを適宜な認証用情報と照合することで本人確認処理を行
う。こうしたユーザ画面の生成や本人認証処理に関しては、他のユーザに関しても同様である（例：ＳａａＳ提供サーバ１０にユーザＢ４１ｂの端末４０ｃがアクセスすると、ユーザＢ画面１４ｂが生成され、返信される）。

上述のようなＳａａＳ提供サーバ１０に対する各ユーザの端末４０ａ〜４０ｃによるアクセスのログすなわちアクセスログは、ＳａａＳ提供サーバ１０を構成する前述のＷｅｂサーバ、ＡＰＰサーバ、ＤＢサーバにシステムログとして記録される。一方、ログ収集サーバ２０は、上述のＳａａＳ提供サーバ１０におけるＷｅｂサーバ、ＡＰＰサーバ、およびＤＢサーバのそれぞれからシステムログを収集し、Ｗｅｂアクセスログ６０、ＡＰＰ利用ログ７０、ＤＢアクセスログ８０としてシステムログを記憶装置に蓄積する。

こうしたログ収集サーバ２０としては、近年、ＳＩＥＭ（Ｓｅｃｕｒｉｔｙ Ｉｎｃｉｄｅｎｔ ａｎｄ Ｅｖｅｎｔ Ｍａｎａｇｅｍｅｎｔ）と呼ばれる、ログ収集を主な機能の一つにもつセキュリティ製品が知られており、このような既存製品を活用してログ収集サーバ２０を構成することを想定出来る。また、ログの収集は、Ｓｙｓｌｏｇなどの所定のプロトコルを使用してもよく、ログファイルをファイル転送することでログを収集するものであってもよい。

以上のような、ＳａａＳ提供サーバ１０と各ユーザの端末４０ａ〜４０ｃ、およびログ収集サーバ２０で構成される、クラウドサービスとそのログ収集のネットワーク構成に対し、本実施形態のなりすまし検出システム１は、例えばログ収集サーバ２０とアクセスし必要なデータであるログの取得を行うこととなる。図１にて例示するように、本実施形態のなりすまし検出システム１は、ログ間トレース確認装置１００、プロファイル学習装置２００、およびなりすまし検出装置３００を含んで構成される。

機能やデータの具体的な詳細については後述するが、ログ間トレース確認装置１００は、ログ収集サーバ２０と接続され、このログ収集サーバ２０から集められた各種システムログどうしの関係を分析するコンピュータである。またログ間トレース確認装置１００は、異種ログ解析部１１０、トレース確認部１２０、およびログ間トレースＤＢ１３０を備えている。

一方、プロファイル学習装置２００は、上述のログ収集サーバ２０と接続され、ログ収集サーバ２０から集められた各種システムログからなりすましを検出するための基準データとなるプロファイルを作成するコンピュータである。こうしたプロファイル学習装置２００は、インポート部２１０、重み付けＤＢ２２０、統合ログＤＢ２３０、プロファイル作成部２４０、およびプロファイルＤＢ２５０を備えている。

また、なりすまし検出装置３００は、ログ収集サーバ２０およびセキュリティ管理者５１の監視端末５０と接続され、ログ収集サーバ２０から集められた各種システムログからユーザのなりすましを検出するコンピュータである。なりすまし検出装置３００は、インポート部３１０、統合ログＤＢ３２０、プロファイル照合部３３０、およびアラート部３４０を備えている。
−−−ハードウェア構成の例−−−

次に、本実施形態のなりすまし検出システム１を構成する各装置のハードウェア構成例について説明する。図２は本実施形態におけるログ間トレース確認装置１００の構成例を示す図である。図２で例示するログ間トレース確認装置１００は、ＣＰＵ１０１、メモリ１０２、記憶装置１０３、通信装置１０４、電源装置１０５、入力装置１０６、および出力装置１０７を備え、これらはバス１０８で接続された構成となっている。

このうちＣＰＵ１０１は、中央演算処理装置（演算装置）であり、上述のようにプログラム１０３１の実行により、異種ログ解析部１１０およびトレース確認部１２０を実装する。

また、メモリ１０２は、ＣＰＵ１０１が処理を実行するときにプログラムやデータをロードする主記憶装置であり、揮発性記憶素子で構成される。また、記憶装置１０３は、ＣＰＵ１０１への入力データや出力データやプログラム１０３１を保管するための補助記憶装置であり、不揮発記憶素子で構成される。この記憶装置１０３は、ログ間トレースＤＢ１３０を格納する。なお、このログ間トレースＤＢ１３０はメモリ１０２に格納するようにしてもよい。

また、通信装置１０４は、外部ノードとの通信を行う通信装置であり、各種ネットワークと通信を行う。なお、外部ノードは、ログ収集サーバ２０を提供する計算機や、監視端末５０の計算機などを含む。

また、電源装置１０５は、ログ間トレース確認装置１００に電源を供給する装置であり、電源コンセントなどと接続される。

また、入力装置１０６は、操作者が入力するためのインタフェースであり、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力などである。また出力装置１０７は、操作者にフィードバックや演算結果などを提供するためのインタフェースであり、例えば、画面表示装置、音声出力装置、印字装置などである。

なお、図２に示すログ間トレース確認装置１００は、１台のハードウェア上に構成するものであるが、大規模なサービスに対応するための負荷分散や、可用性を高めるための冗長構成をとる場合に、２台以上のハードウェア上で構成されるものであってもよい。

また、ログ間トレース確認装置１００の各機能を実現するプログラム、テーブル等の情報は、記憶装置１０３や、ストレージサブシステム、不揮発半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤなどの計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

図３は本実施形態におけるプロファイル学習装置２００の構成例を示す図である。本実施形態におけるプロファイル学習装置２００は、ＣＰＵ２０１、メモリ２０２、記憶装置２０３、通信装置２０４、電源装置２０５、入力装置２０６、および出力装置２０７を備え、これらはバス２０８で接続された構成となっている。

このうちＣＰＵ２０１は、中央演算処理装置（演算装置）であり、記憶装置２０３のプログラム２０３１を実行することで、インポート部２１０およびプロファイル作成部２４０を実装する。

また、メモリ２０２は、ＣＰＵ２０１が処理を実行するときにプログラム２０３１やデータをロードする主記憶装置であり、揮発性記憶素子で構成される。また、記憶装置２０３は、ＣＰＵ２０１への入力データや出力データやプログラム２０３１を保管するための補助記憶装置であり、不揮発性記憶素子で構成される。この記憶装置２０３は、重み付けＤＢ２２０、統合ログＤＢ２３０、およびプロファイルＤＢ２５０を格納する。なお、重み付けＤＢ２２０、統合ログＤＢ２３０、プロファイルＤＢ２５０はメモリ２０２に格納するようにしてもよい。

また通信装置２０４は、外部ノードとの通信を行う通信装置であり、各種ネットワークと通信を行う。なお、外部ノードは、ログ収集サーバ２０を提供する計算機や、監視端末５０の計算機などを含む。また電源装置２０５は、プロファイル学習装置２００に電源を供給する装置であり、電源コンセントなどと接続される。

また、入力装置２０６は、操作者が入力するためのインタフェースであり、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力などである。また、出力装置２０７は、操作者にフィードバックや演算結果などを提供するためのインタフェースであり、例えば、画面表示装置、音声出力装置、印字装置などである。

なお、図３に示すプロファイル学習装置２００は、１台のハードウェア上に構成するものであるが、大規模なサービスに対応するための負荷分散や、可用性を高めるための冗長構成をとる場合に、２台以上のハードウェア上で構成されるものであってもよい。

図４は本実施形態におけるなりすまし検出装置３００の構成例を示す図である。本実施形態におけるなりすまし検出装置３００、ＣＰＵ３０１、メモリ３０２、記憶装置３０３、通信装置３０４、電源装置３０５、入力装置３０６、および出力装置３０７を備え、これらはバス３０８で接続された構成となっている。

このうちＣＰＵ３０１は、中央演算処理装置（演算装置）であり、記憶装置３０３のプログラム３０３１を実行することで、インポート部３１０、プロファイル照合部３３０、およびアラート部３４０を実装する。

また、メモリ３０２は、ＣＰＵ３０１が処理を実行するときにプログラム３０３１やデータをロードする主記憶装置であり、揮発性記憶素子で構成される。また、記憶装置３０３は、ＣＰＵ３０１への入力データや出力データやプログラム３０３１を保管するための補助記憶装置であり、不揮発性記憶素子で構成される。この記憶装置３０３は統合ログＤＢ３２０を格納する。なお、統合ログＤＢ３２０はメモリ３０２に格納するようにしてもよい。

また通信装置３０４は、外部ノードとの通信を行う通信装置であり、各種ネットワークと通信を行う。なお、外部ノードは、ログ収集サーバ２０を提供する計算機や、監視端末５０の計算機などを含む。また電源装置３０５は、なりすまし検出装置３００に電源を供給する装置であり、電源コンセントなどと接続される。

また、入力装置３０６は、操作者が入力するためのインタフェースであり、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力などである。また、出力装置３０７は、操作者にフィードバックや演算結果などを提供するためのインタフェースであり、例えば、画面表示装置、音声出力装置、印字装置などである。

なお、図４に示すなりすまし検出装置３００は、１台のハードウェア上に構成するものであるが、大規模なサービスに対応するための負荷分散や、可用性を高めるための冗長構成をとる場合に、２台以上のハードウェア上で構成されるものであってもよい。

本実施形態では、ログ間トレース確認装置１００、プロファイル学習装置２００およびなりすまし検出装置３００はそれぞれ独立した１台のコンピュータであるとして例示した。しかしながら、ログ間トレース確認装置１００、プロファイル学習装置２００およびなりすまし検出装置３００の機能を、１台のコンピュータが備える構成としてもよい。或いは、ログ間トレース確認装置１００、プロファイル学習装置２００およびなりすまし検出装置３００のそれぞれを複数台のコンピュータにより構成するようにしてもよい。さらに
、ログ間トレース確認装置１００、プロファイル学習装置２００およびなりすまし検出装置３００の各機能は、ＳａａＳ提供サーバ１０を構成する例えばＷｅｂサーバ、ＡＰＰサーバおよびＤＢサーバ、ならびにログ収集サーバ２０の１つまたは複数に配置するようにしてもよい。
−−−データ等の例−−−

続いて、本実施形態のなりすまし検出システム１が取り扱うデータについて説明する。ここではまず、そうしたデータの取得契機となるクラウドサービスの利用時に想定される画面について示す。図５は、本実施形態における画面遷移例１を示す図である。この図５では、上述のＳａａＳ提供サーバ１０が提供するサービスにユーザがログインした場合に、その端末に提供されるユーザ画面の遷移状況例を示している。

この場合、例えばユーザ４１ａが端末４０ａを操作して、ＳａａＳ指定のＵＲＬにＷｅｂブラウザでアクセスすると、ＳａａＳ提供サーバ１０の認証管理部１１が、ログイン画面４００を端末４０ａに表示させる。

上述のユーザ４１ａがログイン画面４００上でＩＤとパスワードを入力し、ログインに成功すると、ＳａａＳ提供サーバ１０のセッション管理部１２は、該当ユーザがログアウトするまでの一連のアクセスを関連付けるためのセッションを作成し、また、動的ページ生成部１３が、ユーザ４１ａ向けのポータル画面４１０を生成して端末４０ａに表示させる。以降、ユーザ４１ａは、ポータル画面４１０上のメニュー１ボタン４１１、メニュー２ボタン４１２、メニュー３ボタン４１３を押下し、ＳａａＳ上で業務を遂行するために、メニュー１画面４２０や、メニュー２画面４３０に画面遷移し、作業を行うこととなる。

なお、上述のユーザ４１ａがポータル画面４１０上でログアウトボタン４１４を押下すると、ＳａａＳ提供サーバ１０のセッション管理部１２は、該当ユーザに関して管理しているセッションを切断する。また、セッション管理部１２は、ユーザ４１ａがログインした後に所定時間が経過した場合や、あるいは、ユーザ４１ａが最後にユーザ画面１４にアクセスしてから所定時間が経過した場合に該当セッションを切断するようにしてもよい。

続いて、上述のＳａａＳ提供サーバ１０におけるセッション管理部１２が管理する、セッション管理テーブル１０００について説明する。図６は本実施形態におけるセッション管理テーブル１０００のデータ例を示す図である。

本実施形態におけるセッション管理テーブル１０００は、ユーザＩＤ１００１、セッション開始時刻１００２、セッション終了時刻１００３、なりすましリスク値１００４を含む、ユーザ数だけのエントリからなるテーブル構造をもつ。このうちセッション開始時刻１００２には、ユーザＩＤ１００１を名乗るユーザが最後に認証管理部１１の認証を通過した時刻が記録されている。また、セッション終了時刻１００３には、ユーザＩＤ１００１を名乗るユーザが最後にログアウトした時刻が記録されている。また、なりすましリスク値１００４には、当該セッションを利用したユーザがなりすましであるリスクを表す値（なりすましリスク値）が格納されている。このなりすましリスク値の算出方法については後述する。

次に、ログ収集サーバ２０が収集するシステムログ（Ｗｅｂアクセスログ６０、ＡＰＰ利用ログ７０、ＤＢアクセスログ８０）について説明する。

図７は本実施形態におけるＷｅｂアクセスログ６０の構成例を示す図である。本実施形態におけるＷｅｂアクセスログ６０には、ユーザによるＳａａＳへのアクセス時に、端末
４０からどのＷｅｂページにアクセスしたかの記録が残される。例えば、Ｗｅｂアクセスログ６０は、日時６１、ユーザＩＤ６２、アクセスページ６３、応答コード６４、セッションＩＤ６５を含む。

図８は本実施形態におけるＡＰＰ利用ログ７０の構成例を示す図である。本実施形態のＡＰＰ利用ログ７０には、ＳａａＳへアクセスするミドルウェアとして上述のＷｅｂサーバから呼び出されるＡＰＰサーバへのアクセスの記録が残される。例えば、ＡＰＰ利用ログ７０は、日時７１、セッションＩＤ７２、アクションクラス７３、プロセスＩＤ７４、トランザクションＩＤ７５、応答コード７６、応答時間７７を含む。

図９は本実施形態におけるＤＢアクセスログ８０の構成例を示す図である。本実施形態のＤＢアクセスログ８０には、ＳａａＳが管理する情報資産へのアクセスとして、上述のＡＰＰサーバからのＤＢサーバへのアクセスが記録される。例えば、ＤＢアクセスログ８０は、日時８１、ＩＰアドレス８２、トランザクションＩＤ８３、ＳＱＬクエリ８４、応答コード８５、応答時間８６を含む。

ここでセキュリティ課題の一つとして、例えば、ユーザ４１ａのＩＤとパスワードが他のサイトと共通のものを使っていた場合、もし他サイトでＩＤとパスワードが漏洩すると、悪意のある者はそのＩＤとパスワードを認証管理部１１に入力することで、ユーザ４１ａになりすましてＳａａＳ提供サーバ１０にログインすることができる。リスト型攻撃として知られている攻撃手法である。なりすましに成功した悪意のある者は、ユーザＡ画面１４ａにアクセスできてしまうが、認証管理部１１では、認証に一度も失敗していないため、セキュリティ管理者がＷｅｂアクセスログ６０、ＡＰＰ利用ログ７０、ＤＢアクセスログ８０からなりすましを目視で検出することは困難な作業となる。

しかしながら本発明のなりすまし検出技術によれば、こうした状況にも確実に対応して、なりすましを確実に検出することが可能である。以下、なりすまし検出方法の具体的な処理内容について説明する。
−−−処理フロー−−−

以下、本実施形態におけるなりすまし検出方法の実際手順について図に基づき説明する。以下で説明するなりすまし検出方法に対応する各種動作は、なりすまし検出システム１を構成する各装置がメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図１０は、本実施形態におけるなりすまし検出方法の全体フロー例を示す図である。本実施形態のなりすまし検出システム１による処理は、ＳａａＳのシステムの開発およびテスト段階とシステム運用段階とを含み、このうち開発およびテスト段階には、ログ間トレース確認装置１００により実行されるログ間トレース確認処理７０１が含まれる。ログ間トレース確認処理７０１の詳細は、後述する図１８を使って説明する。

また、システム運用段階には、プロファイル学習装置２００により実行されるプロファイル学習処理７０２と、その後になりすまし検出装置３００により実行されるなりすまし検出処理７０３とが含まれる。

ここで図１１にて、上述のシステム運用段階におけるプロファイル学習処理７０２の詳細を示す。当該フローにおいて、ステップ８０１では、プロファイル学習装置２００のインポート部２１０が、ログ収集サーバ２０からＷｅｂアクセスログ６０、ＡＰＰ利用ログ７０、ＤＢアクセスログ８０を収集する。なお、収集するタイミングは、例えば一日に一
回の業務時間外である深夜に、バッチとして処理するものであっても良い。あるいは週に一回の休日に、バッチとして処理するものであっても良い。

ステップ８０２では、プロファイル学習装置２００のインポート部２１０が、Ｗｅｂアクセスログ６０、ＡＰＰ利用ログ７０、ＤＢアクセスログ８０から統合ログ２３０を生成する。この統合ログ生成について図１２のフローに示す。

図１２のフローにおいて、プロファイル学習装置２００のインポート部２１０は、ステップ８０２１にて、Ｗｅｂアクセスログ６０から第一中間ログ５００を作成し、ステップ８０２２において、ＡＰＰ利用ログ７０から第一中間ログ５１０を作成し、ステップ８０２３において、ＤＢアクセスログ８０から第一中間ログ５２０を作成し、ステップ８０２４において、第一中間ログ５１０，５２０から第二中間ログ５３０を作成し、ステップ８０２５において、統合ログ２２０を作成する。

上述の各ログのうち第一中間ログ５００の例について図１３にて示す。インポート部２１０がＷｅｂアクセスログ６０から作成する第一中間ログ５００（以下、「第一中間ログ（Ｗｅｂアクセス）」とも表記する。）は、通番５０１、日時５０２、ユーザＩＤ５０３、セッションＩＤ５０４、ＵＲＬ１（５０５）、ＵＲＬ２（５０６）、・・・、ＵＲＬｎ（５０７）の組合せを含む、０個以上のエントリから構成されるテーブル構造をもつ。

こうした第一中間ログ５００の作成手順の詳細については図１４のフローに示している。このフローにおいて、ステップ８０２１１では、第一中間ログ５００インポート部２１０が、上述の第一中間ログ５００の新しいエントリを作成する。

ステップ８０２１２では、第一中間ログ５００インポート部２１０が、Ｗｅｂアクセスログ６０の各エントリを個々に区別するために通し番号を振って、新しいエントリの通番５０１に設定する。

またステップ８０２１３では、第一中間ログ５００インポート部２１０がＷｅｂアクセスログ６０の日時６１を所定の年月日フォーマットに変換して、新しいエントリの日時５０２に設定する。

ステップ８０２１４では、第一中間ログ５００インポート部２１０は、Ｗｅｂアクセスログ６０のユーザＩＤ６２を、新しいエントリのユーザＩＤ５０３にそのまま格納する。

ステップ８０２１５では、第一中間ログ５００インポート部２１０は、Ｗｅｂアクセスログ６０のセッションＩＤ６５を、新しいエントリのセッションＩＤ５０４にそのまま格納する。

ステップ８０２１６では、第一中間ログ５００インポート部２１０は、Ｗｅｂアクセスログ６０のアクセスページ６３に含まれる各ＵＲＬについて、当該ＵＲＬにおけるユーザの滞在時間を日時６１から求める。なお、ＵＲＬにおけるユーザの滞在時間を求めるには一般的な手法を用いることができ、ここでは説明を省略する。

ステップ８０２１７では、第一中間ログ５００インポート部２１０は、求めた滞在時間をそれぞれ新しいエントリのＵＲＬ１（５０５）、ＵＲＬ２（５０６）、・・・、ＵＲＬｎ（５０７）に設定する。図１３の例では、たとえばＵＲＬ１（５０５）である「ｌｏｇｉｎ．ｊｓｐ」での滞在時間が１ｓ（秒）であったことや、ＵＲＬ２（５０６）である「ｐｏｒｔａｌ．ｊｓｐ」での滞在時間が１０ｓであったことが示されている。以上のようにして、Ｗｅｂアクセスログ６０から第一中間ログ５００が作成される。

次に、インポート部２１０がＡＰＰ利用ログ７０から作成する第一中間ログ５１０（以下、「第一中間ログ（ＡＰＰ利用）」とも表記する）について説明する。図１５に例示する第一中間ログ５１０は、通番５１１、セッションＩＤ５１２、トランザクションＩＤ５１３、アクションクラス１（５１４）、アクションクラス２（５１５）、・・・、アクションクラスｎ（５１６）の組合せを含む、０個以上のエントリから構成されるテーブル構造をもつ。こうした第一中間ログ５１０を作成する処理について図１６に基づき説明する。

図１６のフローにて、ステップ８０２２１では、プロファイル学習部２００のインポート部２１０が第一中間ログ５１０の新しいエントリを作成する。

ステップ８０２２２では、プロファイル学習部２００のインポート部２１０がＡＰＰ利用ログ７０の各エントリを個々に区別するために通し番号を振って、新しいエントリの通番５１１に設定する。

また、ステップ８０２２３では、プロファイル学習部２００のインポート部２１０は、ＡＰＰ利用ログ７０のセッションＩＤ７２を、新しいエントリのセッションＩＤ５１２にそのまま格納する。

また、ステップ８０２２４では、プロファイル学習部２００のインポート部２１０は、ＡＰＰ利用ログ７０のトランザクションＩＤ７５を、新しいエントリのトランザクションＩＤ５１３にそのまま格納する。

ステップ８０２２５では、プロファイル学習部２００のインポート部２１０は、ＡＰＰ利用ログ７０のアクションクラス７３を構成する各アクションクラスについて、当該アクションクラスに対応するＡＰＰ利用ログ７０の応答時間７７を、新しいエントリのアクションクラス１（５１４）、アクションクラス２（５１５）、・・・、アクションクラスｎ（５１６）のいずれかに対応付けて設定する。図１５の例では、たとえばアクションクラス１（５１４）である「ｌｏｇｉｎ．ｊａｖａ」の応答時間が２０ｍｓ（ミリ秒）であったことや、アクションクラス２（５１５）である「ｐｏｒｔａｌ．ｊａｖａ」の応答時間が３０ｍｓであったことなどが示されている。以上のようにして、ＡＰＰ利用ログ７０から第一中間ログ５１０が作成される。

次に、インポート部２１０がＤＢアクセスログ８０から作成する第一中間ログ５２０の構成例について説明する。図１７に例示する第一中間ログ５２０（以下、「第一中間ログ（ＤＢアクセス）」とも表記する）は、通番５２１、トランザクションＩＤ５２２、テーブル１（５２３）、テーブル２（５２４）、・・・、テーブルｎ（５２５）の組合せを含む、０個以上のエントリから構成される。こうした第一中間ログ５２０を、ＤＢアクセスログ８０から作成する処理（図１２のステップ８０２３）の詳細を続いて説明する。

図１８のフローにて、ステップ８０２３１では、プロファイル学習装置２００のインポート部２１０が第一中間ログ５２０の新しいエントリを作成する。

また、ステップ８０２３２では、プロファイル学習装置２００のインポート部２１０がＤＢアクセスログ８０の各エントリを個々に区別するために通し番号を振って、新しいエントリの通番５２１に設定する。

また、ステップ８０２３３では、プロファイル学習装置２００のインポート部２１０は、ＤＢアクセスログ８０のトランザクションＩＤ８３を、新しいエントリのトランザクシ
ョンＩＤ５２２にそのまま格納する。

ステップ８０２３４では、プロファイル学習装置２００のインポート部２１０は、ＤＢアクセスログ８０のＳＱＬクエリ８４に含まれる各テーブルについて、当該テーブルに対応するＤＢアクセスログ８０の応答時間８６を、新しいエントリのテーブル１（５２３）、テーブル２（５２４）、・・・、テーブルｎ（５２５）のいずれかに対応付けて設定する。図１７の例では、たとえばテーブル１（５２３）である「Ｔ＿ＵＳＥＲ」に対するクエリの応答時間が１０ｍｓ（ミリ秒）であったことや、テーブル２（５２４）である「Ｔ＿ＰＯＲＴＡＬ」に対するクエリの応答時間が５００ｍｓであったことなどが示されている。なお、ＳＱＬクエリ８４中に複数のテーブルが含まれる場合には、応答時間８６はＳＱＬクエリ８４に含まれるすべてのテーブルに同等にかかったものとして、複数のテーブルのそれぞれに対応づけて設定するようにしても良い。以上のようにして、ＤＢアクセスログ８０から第一中間ログ５２０が作成される。

次に、上述のインポート部２１０が第一中間ログ５１０、５２０から作成する第二中間ログ５３０の構成例について説明する。図１９に例示する第二中間ログ５３０は、第一中間ログ５１０のトランザクションＩＤ５１３と、ＤＢアクセスログ８０に係る第一中間ログ５２０のトランザクションＩＤ５２２とが同じ値をとるような各エントリを１個のエントリとしたものである。こうした第二中間ログ５３０は、通番５３１、セッションＩＤ５３２、アクションクラス１（５３３）、アクションクラス２（５３４）、・・・、アクションクラスｎ（５３５）、テーブル１（５３６）、テーブル２（５３７）、・・・、テーブルｎ（５３８）、トレース通番（５３９）の組合せを含む、０個以上のエントリから構成されるテーブル構造をもつ。

こうした第二中間ログ５３０の作成処理について説明する。図２０は、第一中間ログ５１０、５２０から第二中間ログ５３０を作成する処理（図１２のステップ８０２４）の詳細を説明する図である。この場合、ステップ８０２４１では、プロファイル学習装置２００のインポート部２１０が第二中間ログ５３０の新しいエントリを作成する。

次にステップ８０２４２では、プロファイル学習装置２００のインポート部２１０が第二中間ログ５３０の各エントリを個々に区別するために通し番号を振って、新しいエントリの通番５３１に設定する。

また、ステップ８０２４３では、プロファイル学習装置２００のインポート部２１０は、第一中間ログ５１０のセッションＩＤ５１２をセッションＩＤ５３２にそのまま格納する。

次にステップ８０２４４では、プロファイル学習装置２００のインポート部２１０は、第一中間ログ５１０のアクションクラス１（５１４）、アクションクラス２（５１５）、・・・、アクションクラスｎ（５１６）を、アクションクラス１（５３３）、アクションクラス２（５３４）、・・・、アクションクラスｎ（５３５）にそのまま格納する。

また、ステップ８０２４５では、プロファイル学習装置２００のインポート部２１０は、第一中間ログ５２０のテーブル１（５２３）、テーブル２（５２４）、・・・、テーブルｎ（５２５）を、テーブル１（５３６）、テーブル２（５３７）、・・・、テーブルｎ（５３８）にそのまま格納する。

次にステップ８０２４６では、プロファイル学習装置２００のインポート部２１０は、第一中間ログ５１０の通番５０１と第一中間ログ５２０の通番５１１とをトレース通番５３９に格納する。以上のようにして、第一中間ログ５１０、５２０から第二中間ログ５３
０が作成される。

続いて、上述のインポート部２１０が第一中間ログ５００と第二中間ログ５３０から作成する統合ログ２２０の構成例について説明する。図２１に例示する統合ログ２２０は、第一中間ログ５００のセッションＩＤ５０４と、第二中間ログ５３０のセッションＩＤ５３２とが同じ値をとるような各エントリを１個のエントリとしたものである。こうした統合ログ２２０は、通番５４１、日時５４２、ユーザＩＤ５４３、ＵＲＬ１（５４４）、ＵＲＬ２（５４５）、ＵＲＬｎ（５４６）、アクションクラス１（５４７）、アクションクラス２（５４８）、アクションクラスｎ（５４９）、テーブル１（５５０）、テーブル２（５５１）、テーブルｎ（５５２）、トレース通番５５３の組合せを含む、０個以上のエントリから構成される。以下に、この統合ログ２２０の作成処理について説明する。

図２２は、第一中間ログ５００と第二中間ログ５３０から統合ログ２２０を作成する処理（図１２のステップ８０２５）の詳細を説明する図である。このフローにおいて、ステップ８０２５１では、プロファイル学習装置２００のインポート部２１０が統合ログ２２０の新しいエントリを作成する。

次にステップ８０２５２では、プロファイル学習装置２００のインポート部２１０が統合ログ２２０の各エントリを個々に区別するために通し番号を振って、新しいエントリの通番５４１に設定する。

また、ステップ８０２５３では、プロファイル学習装置２００のインポート部２１０は、第一中間ログ５００の日時５０２を日時５４２にそのまま格納する。

続いてステップ８０２５４では、プロファイル学習装置２００のインポート部２１０は、第一中間ログ５００のユーザＩＤ５０３をユーザＩＤ５４３にそのまま格納する。

また、ステップ８０２５５では、プロファイル学習装置２００のインポート部２１０は、第一中間ログ５００のＵＲＬ１（５０５）、ＵＲＬ２（５０６）、・・・、ＵＲＬｎ（５０７）を、ＵＲＬ１（５４４）、ＵＲＬ２（５４５）、・・・、ＵＲＬｎ（５４６）にそのまま格納する。

次にステップ８０２５６では、プロファイル学習装置２００のインポート部２１０は、第二中間ログ５３０のアクションクラス１（５３３）、アクションクラス２（５３４）、・・・、アクションクラスｎ（５３５）を、アクションクラス１（５４７）、アクションクラス２（５４８）、・・・、アクションクラスｎ（５４９）にそのまま格納する。

また、ステップ８０２５７では、プロファイル学習装置２００のインポート部２１０は、第二中間ログ５３０のテーブル１（５３６）、テーブル２（５３７）、・・・、テーブルｎ（５３８）を、テーブル１（５５０）、テーブル２（５５１）、・・・、テーブルｎ（５５２）にそのまま格納する。

また、ステップ８０２５８では、プロファイル学習装置２００のインポート部２１０は、第一中間ログ５００の通番５０１と第二中間ログ５３０の通番５３１とをトレース通番５５３に格納する。以上述べてきたステップ８０２で作成された統合ログ２３０では、ユーザ４１がログインしてからログアウトするまでのユーザＩＤ５４３にもとづき、アクセスしたＵＲＬや、起動されたアクションクラスや、読み書きが行われたテーブルの一覧を、１個のエントリとして把握することができる。

ここで示した統合ログ２３０の作成形態は一例であり、後述するログ間トレース確認装
置１００が出力するログ間トレースＤＢ１３０の内容を使って、その他の手順で統合ログ２３０を作成するものであっても良い。

ここで図１１のフローに関する説明に戻る。ステップ８０２に続いて、ステップ８０３において、プロファイル学習装置２００のインポート部２１０が、重み付けＤＢ２２０を使って、統合ログ２３０の各項目に重みをつける処理を行う。ここで用いる重み付けＤＢ２２０のデータ構造を、図２３〜２５にそれぞれ基づき説明する。本実施形態では、重み付けＤＢ２２０が３つの重み付けテーブル６００、６１０、６２０から構成される場合を想定する。

このうち重み付けテーブル６００は、図２３にて例示するように、ＵＲＬの滞在時間に対して用いる重みを管理するテーブルである。この重み付けテーブル６００に管理される重み付け値は、高い頻度でアクセスするＵＲＬほど軽く、低い頻度でアクセスするＵＲＬほど重くなるように設定されている。こうした重み付けテーブル６００は、ＵＲＬ６０１、重み付け値６０２、理由６０３を含む、０個以上のエントリからなるテーブル構造をもつ。

一方、重み付けテーブル６１０は、図２４にて例示するように、アクションクラスの応答時間に対して用いる重みを管理するテーブルである。この重み付けテーブル６１０に管理される重み付け値は、高い頻度で呼び出されるアクションクラスほど軽く、低い頻度で呼び出されるアクションクラスほど重くなるように設定されている。この重み付けテーブル６１０は、アクションクラス６１１、重み付け値６１２、理由６１３を含む、０個以上のエントリからなるテーブル構造をもつ。

また、重み付けテーブル６２０は、図２５にて例示するように、テーブルの応答時間に対して用いる重みを管理するテーブルである。重み付けテーブル６２０に管理される重み付け値は、価値の高い情報を保持するテーブルほど重く、価値の低い情報を保持するテーブルほど値を軽くなるように設定されている。こうした重み付けテーブル６２０は、テーブル６２１、重み付け値６２２、理由６２３を含む、０個以上のエントリからなるテーブル構造をもつ。

図２６にて上述の重み付けＤＢ２２０を用いて重み付け値を適用する処理（図１１のステップ８０３）の詳細フローを示す。このフローにおいて、ステップ８０３１では、プロファイル学習装置２００のインポート部２１０は、統合ログ２３０のＵＲＬ１（５４４）、ＵＲＬ２（５４５）、・・・、ＵＲＬｎ（５４６）のそれぞれに対して、重み付けテーブル６００において対応するＵＲＬの重み付け値６０２を掛け算する。

また、ステップ８０３２では、プロファイル学習装置２００のインポート部２１０は、統合ログ２３０のアクションクラス１（５４７）、アクションクラス２（５４８）、・・・、アクションクラスｎ（５４９）に対して、重み付けテーブル６１０において対応するアクションクラスの重み付け値６１２を掛け算する。

次にステップ８０３３では、プロファイル学習装置２００のインポート部２１０は、統合ログ２３０のテーブル１（５５０）、テーブル２（５５１）、・・・、テーブルｎ（５５２）に対して、重み付けテーブル６２０において対応するテーブルの重み付け値６２２を掛け算する。

ここで再び図１１のフローの説明に戻る。上述のステップ８０３の続き、ステップ８０４では、プロファイル学習装置２００のプロファイル作成部２４０がプロファイルＤＢ２５０を作成する。図２７に、プロファイルＤＢ２５０のデータ構造の一例を示す。ここで
例示するプロファイルＤＢ２５０は、プロファイル学習装置２００のプロファイル作成部２４０によって機械学習の結果（プロファイル）として作成される。プロファイルはユーザによる操作の特徴を示すデータであり、決定木と呼ばれるツリー構造を有する。

図２７で示すプロファイルすなわち決定木の例は、プロファイルＤＢ２５０がノード９００、９１０、９２０、９３０、９４０とリンク９０１、９０２、９０３、９２１、９２２、９２３とを格納していることを示す。ルートのノード９００は、統合ログＤＢ２３０のうち、機械学習の入力としたログを示す。決定木において、リンク９０１は、ノード９００に含まれる統合ログのうち、ＵＲＬ１（５４４）の滞在時間の長さによって、６０秒より長ければ（分岐９０２）ノード９１０に分類され、６０秒以下であれば（分岐９０３）ノード９２０に分類されることを意味する。

また、リンク９２１は、ノード９２０に含まれる統合ログのうち、アクションクラス２（５４８）の応答時間の長さによって、３秒以下であれば（分岐９２２）ノード９３０に分類され、３秒より長ければ（分岐９２３）ノード９４０に分類されることを意味する。ルート以外のノード９１０、９２０、９３０、９４０は、ユーザＩＤを示す。すなわち、決定木を辿ることによりユーザＩＤを決定することができる。このような決定木の作成方法の詳細は公知であり、ここでの詳細な説明については割愛する。

以上述べてきたステップ８０１〜８０４により、プロファイルプロファイル学習装置２００のプロファイル学習処理７０２が完了する。

続いて、なりすまし検出装置３００による処理について説明する。図２８は、なりすまし検出処理７０３でのフローを示す図である。このフローにて、ステップ８１１では、なりすまし検出装置３００のインポート部３１０がログ収集サーバ２０からシステムログを収集する。

またステップ８１２では、なりすまし検出装置３００のインポート部３１０がシステムログから統合ログＤＢ３２０を生成する。

次にステップ８１３では、なりすまし検出装置３００のインポート部３１０が重み付けＤＢ２２０にもとづき統合ログＤＢ３２０に重みをつける。

上述のステップ８１１からステップ８１３は、プロファイル学習処理７０２のステップ８０１からステップ８０３と同等であるが、ログ収集サーバ２０から収集するシステムログは、ユーザ４１がＳａａＳ提供サーバ１０にログインしてからログアウトするまで次々に生成されるシステムログを次々に収集するものであっても良い。

続いてステップ８１４では、なりすまし検出装置３００が、つづくステップ８１５からステップ８１８までの処理を、統合ログ３２０のエントリの個数だけ繰り返す。

ステップ８１５では、なりすまし検出装置３００のプロファイル照合部３３０が、機械学習アルゴリズムの決定木の照合をつかって、プロファイルＤＢ２５０にしたがい、ユーザＩＤを予測する。本実施形態では、なりすまし検出装置３００は、プロファイル学習装置２００と通信可能に接続しており、なりすまし検出装置３００のプロファイル照合部３３０は、プロファイル学習装置２００が備えるプロファイルＤＢ２５０にアクセスできるものとする。図２７の例においてユーザＩＤの予測にあたっては、プロファイルＤＢ２５０のノード９００から開始し、リンク９０１を見て統合ログ３２０のエントリが分岐９０２と分岐９０３のいずれかに該当するかを判断する。分岐９０２に該当するなら、ノード９１０では８０％の確率で「ユーザＡ」と予測する。分岐９０３に該当するなら、ノード
９２０に進み、つぎのリンク９２１にて分岐する。このようにして、プロファイル照合部３３０は、統合ログ２３０のエントリからどのユーザＩＤに該当するかを予測することができる。

次にステップ８１６では、なりすまし検出装置３００のプロファイル照合部３３０が、上述のステップ８１５で予測したユーザＩＤが、統合ログ３２０のエントリに含まれるユーザＩＤ５４３と一致するかどうかを判定する。ユーザＩＤが一致しない場合にはステップ８１７に進み、ユーザＩＤが一致する場合にはステップ８１８に進む。

また、ステップ８１７では、なりすまし検出装置３００のプロファイル照合部３３０が、図６に示したセッション管理テーブル１０００において当該ユーザＩＤ１００１に対応するなりすましリスク値１００４の値を増加させる。

次にステップ８１８では、なりすまし検出装置３００のプロファイル照合部３３０が、セッション管理テーブル１０００の当該ユーザＩＤ１００１の、なりすましリスク値１００４の値を減少させる。

また、ステップ８１９では、なりすまし検出装置３００のプロファイル照合部３３０が、セッション管理テーブル１０００のなりすましリスク値１００４を見て、所定の値以上かどうかを判定する。なりすましリスク値１００４が所定の値以上であれば、ステップ８２０に進む。所定の値未満であれば、なりすまし検出処理７０３は終了する。

またステップ８２０では、なりすまし検出装置３００のアラート部３４０がアラートを生成する。以下、このアラート部３４０について説明する。本実施形態では、アラート部３４０は、ＳａａＳ提供サーバ１０にアクセスしているユーザ４１に対してアラート表示を出力する場合（図２９）と、セキュリティ管理者５１の監視端末５０に対してアラート表示を出力する場合（図３０）と、セッションを切断することによりアラートとする場合とがある。

なお、なりすまし検出装置３００のアラート部３４０は、ユーザ４１およびセキュリティ管理者５１以外のユーザ（例えば、システムの運用者、ＳａａＳサービスを提供する事業者など）に対して出力するようにしてもよい。また、アラート部３４０は、画面にアラートを表示する形態に限らず、例えば電子メールでアラートを送信するようにしてもよいし、音声により報知するようにしてもよい。さらに、アラート部３４０は、セッションを切断することに代えて、ＳａａＳシステム全体または一部の運用を停止するようにしてもよい。また、アラート部３４０は、なりすましリスク値が所定値よりも高くなったユーザＩＤについて、以後のログインを許可しないように設定するようにしてもよい。

図２９は、上述のステップ８２０において、アラート出力画面を、動的ページ生成部１３が作成するユーザ画面１４（ユーザＡ画面１４ａ、ユーザＢ画面１４ｂ）の一部として構成する場合の例を示す図である。この場合、ユーザ４１は、ログイン画面１１００でログインが成功した後、ポータル画面１１１０にアクセスする。ユーザ４１がメニュー１ボタンを押下してメニュー１画面１１２０を操作する間、なりすましのリスクが低いとプロファイル照合部３３０が判定した場合（ステップ８１９：所定値未満）、とくにアラートは出ない。

ユーザ４１がメニュー３ボタンを押下してメニュー３画面１１３０を利用しだし、このメニュー３画面１１３０の利用に係るシステムログからプロファイル照合部３３０が、プロファイルと合わない操作（ユーザ４１が通常は行わない操作）と判定し、セッション管理テーブル１０００のなりすましリスク値１００４が所定値よりも高い場合（ステップ８
１９：所定値以上）、メニュー３画面１１３０上に、アラート部３４０がアラート表示１１３１を出す。

以上のようにして、ステップ８２０において、システムに実際にアクセスしているユーザ４１に対してなりすましのリスクに係る警告を発することができる。ユーザ４１になりすました悪意のある第三者がアラート表示１１３１を見たならば、警告とうつり、抑止効果となることが期待される。

図３０は、上述のステップ８２０において、なりすまし検出装置３００が、アラートをセキュリティ管理者５１の監視端末５０に出す画面の一例を示す図である。ここで例示するなりすまし監視画面１２００は、クラウドサービス（ＳａａＳ）を所定の日に利用したセッションとアラートの一覧を表示する本日アラート表示領域１２１０と、一人のユーザに着目した場合の過去の日をさかのぼってのアラート履歴を表示するユーザ履歴表示領域１２２０と、ログ履歴表示領域１２３０と、ＯＫボタン１２３０と、キャンセルボタン１２４０とを含んで構成される。

本日アラート表示領域１２１０には、ユーザＩＤ１２１１、セッション開始時間１２１２、セッション終了時間１２１３、なりすましリスク値１２１４などが表示される。セキュリティ管理者５１は、本日アラート表示領域１２１０を毎日確認することで、その日のうちに急いで対処が必要な高リスクのセッションがないかどうかを容易に見つけることができる。

なりすまし検出装置３００は、ユーザ履歴表示領域１２２０において、本日から順に日付をさかのぼったアラートの履歴を表示し、本日のリスク値１２２１、１日前のリスク値１２２２、３日前のリスク値１２２３というように、セッションを確立していた時間帯と、そのセッションのなりすましリスク値を表示する。セキュリティ管理者５１は、ユーザ履歴表示領域１２２０を確認することで、当該ユーザＩＤのアラートの傾向を分析することができる。

さらにリスク値１２２１、１２２２、１２２３をクリックすると、なりすまし検出装置３００は、ログ履歴表示領域１２３０にて、該当する統合ログ２３０を出力する。

以上のようにして、ステップ８２０において、セキュリティ管理者５１に対してなりすましのリスクに係る警告を発することができる。なりすまし監視画面１２００により、セキュリティ管理者５１は、ＳａａＳを利用する複数のユーザのなりすましリスクを統合的に把握することができる。

上述のステップ８２０においてアラート部３４０は、なりすましリスク値１００４の高いセッションに対して、セッション管理部１２と連動して、該当するセッションを強制切断するものであっても良い。セッションを強制切断することで、ユーザ４１に悪意のある者がなりすましていた場合に、被害拡大を防ぐことができる。

以上、システム運用におけるプロファイル学習処理７０２となりすまし検出処理７０３（図１０参照）の処理を説明してきた。次に、システム開発・テスト段階におけるログ間トレース確認装置１００によるログ間トレース確認処理７０１（図１０参照）の処理について説明する。図３１はログ間トレース確認処理７０１に対応したフロー図であり、図３２は、ログ間トレース確認処理７０１に係るデータ図である。

図３１のフローにおいて、ステップ１４００では、ログ間トレース確認装置１００の異種ログ解析部１１０が、ログ収集サーバ２０からシステムログを収集する。このとき、図
３２に示すようにログ収集サーバ２０がもつＷｅｂアクセスログ６０、ＡＰＰ利用ログ７０、ＤＢアクセスログ８０に限らず、ＳａａＳ提供サーバ１０を構成するＯＳやミドルウェアが生成する、ＯＳイベントログ１３００、ＤＢコネクタログ１３１０などまで含めてシステムログを収集するものであっても良い。

次にステップ１４０１では、ログ間トレース確認装置１００の異種ログ解析部１１０が、異種ログの組合せの数だけ、以降のステップ１４０７までの処理を繰り返す。異種ログの組合せは、図３２の組合せテーブル１３２０に示すように、異なるログどうしの全ての組合せである。ログの種類をＮ個とすると、異なるログどうしの全ての組合せはＮ（Ｎ−１）／２個である。

また、ステップ１４０２では、ログ間トレース確認装置１００の異種ログ解析部１１０が、上述のステップ１４０１で突き合わせるログ同士が、同じ時間帯のものかどうかを判定する。同じ時間帯のものでない場合は、次の組合せへと処理を進める。

次にステップ１４０３では、ログ間トレース確認装置１００の異種ログ解析部１１０が、異種ログどうしの列を比較する。例えば、図３２に示す列比較テーブル１３３０では、Ｗｅｂアクセスログ６０とＡＰＰ利用ログ７０との列を比較している。以降のステップ１４０６までを、比較対象とする列の数だけ繰り返す。

また、ステップ１４０４では、ログ間トレース確認装置１００の異種ログ解析部１１０が、上述のステップ１４０３で比較すると抽出した列どうしに含まれる値について比較する。例えば、図３２に示す比較図１５４０では、Ｗｅｂアクセスログ６０のセッションＩＤとＡＰＰ利用ログ７０のセッションＩＤとの間で、同じ値かどうかを比較する。一方、図３２に示す比較図１５５０では、Ｗｅｂアクセスログ６０のユーザＩＤとＡＰＰ利用ログ７０の応答時間との間で、同じ値かどうかを比較する。

次にステップ１４０５では、ログ間トレース確認装置１００が、上述のステップ１４０４で述べた比較の結果、値が一致していた個数を算出する。例えば、図３２に示す比較図１５４０では、値が７０個同じだったことを示している。比較図１５５０では、値が０個同じだったことを示している。以上の値が同じ個数は、列比較テーブル１３３０内の該当箇所に格納する。

なお、ステップ１４０６は、ステップ１４０３からの繰り返しである。また、ステップ１４０７は、ステップ１４０１からの繰り返しである。

次にステップ１４０８では、ログ間トレース確認装置１００のトレース確認部１２０が、異種ログがどのようにトレースできたかを、出力装置２０７に表示する。異種ログトレース確認画面のインタフェース図を、図３３を使って説明する。

図３３に例示する異種ログトレース確認画面１６００は、異種ログとして解析対象としたシステムログの一覧を表示する表示領域１６１０と、異種ログ間でトレースできる可能性を示した表示領域１６２０と、異種ログとして具体的にどのような値が入っているかを確認するための表示領域１６３０とを含んで構成される。

表示領域１６２０では、異種ログであってもトレースできる可能性があるログとして、たとえば、Ｗｅｂアクセスログ１６２１のセッションＩＤとＡＰＰ利用ログ１６２２のセッションＩＤとがリンク１６２４により紐付けられることを示す。また、ＡＰＰ利用ログ１６２２のトランザクションＩＤとＤＢアクセスログ１６２３のトランザクションＩＤとがリンク１６２５により紐付けられることを示す。

ユーザが上述のリンク１６２４をクリックすると、ログ間トレース確認装置１００は、表示領域１６３０上で、Ｗｅｂアクセスログ１６２１に対応して上述のログの具体的な内容をテーブルビュー１６３１で示し、ＡＰＰ利用ログ１６２２に対応して上述のログの具体的な内容をテーブルビュー１６３２で示す。さらにログ間トレース確認装置１００は、上述のリンク１６２４に対応して、紐付けの理由となっている、Ｗｅｂアクセスログ上のセッションＩＤ１６３３と、ＡＰＰ利用ログ上のセッションＩＤ１６３４とを強調表示する。

以上のように、異種ログトレース確認画面１６００により、ＳａａＳの開発者は、ＳａａＳの開発およびテスト段階において、テスト時に発生させたシステムログを使って、どのシステムログ同士が紐付けられるかを確認することができる。ＳａａＳの開発者は、もしログが思ったとおりに紐付けられない場合には、ＳａａＳのソースコードを改良して、ＳａａＳにおいて生成されるシステムログを変更し、ふたたび異種ログ解析部１１０を動かすことで、所定の紐付けが可能なことを確認することができる。

ここで、図３１のフローの説明に戻る。上述のステップ１４０８に続き、ステップ１４０９では、ログ間トレース確認装置１００のトレース確認部１２０が、紐付け結果として、ログ間トレースＤＢ１３０を出力する。ログ間トレースＤＢ１３０のデータ図の一例を、図３４を使って説明する。

図３４で例示するログ間トレースＤＢ１３０は、異種ログの入力として使ったログのスキーマ構造を格納している。例えば、Ｗｅｂアクセスログ１５０１、ＡＰＰ利用ログ１５０２、ＤＢアクセスログ１５０３、ＯＳイベントログ１５０４、ＤＢコネクタログ１５０５のデータベースのスキーマ構造をもつ。なお、上述のスキーマ構造間にはリンクが設定されている。例えば、Ｗｅｂアクセスログ１５０１のセッションＩＤとＡＰＰ利用ログ１５０２のセッションＩＤとの間に、リンク１５１０が設定されている。さらには、ＡＰＰ利用ログ１５０２のトランザクションＩＤとＤＢアクセスログ１５０３のトランザクションＩＤとの間に、リンク１５２０が設定されている。さらには、ＡＰＰ利用ログ１５０２のプロセスＩＤと、ＯＳイベントログ１５０４のプロセスＩＤとの間に、リンク１５３０が設定されている。さらには、ＤＢアクセスログ１５０３のＳＱＬクエリとＤＢコネクタログ１５０５のＳＱＬクエリとの間に、リンク１５４０が設定されている。このようにログ間トレースＤＢ１３０を構成することで、データベースのスキーマどうしを紐付けることができる。

以上述べてきたログ間トレース確認装置１００のログ間トレース確認処理７０１により、ＳａａＳ提供サーバ１０が出力する異種のシステムログどうしで互いに紐付けられる可能性があるログの候補を、容易に見つけ出すことができる。これにより、プロファイル学習装置２００で生成する統合ログ２３０や、なりすまし検出装置３００で生成する統合ログ３２０を容易に構成することができる。

以上のようにして、本実施形態のなりすまし検出システム１によれば、プロファイル学習処理７０２において統合ログ２２０から作成した決定木（プロファイルＤＢ２５０）に対して、その後のなりすまし検出処理７０３において収集したシステムログを照合し、決定木を辿ることにより決定されたユーザＩＤが、統合ログ２２０のユーザＩＤと一致するか否かにより、なりすましのリスクを求めることができる。

統合ログ２２０は、ログ収集サーバ２０が収集するシステムログ（Ｗｅｂアクセスログ６０、ＡＰＰ利用ログ７０、ＤＢアクセスログ８０）をセッションＩＤおよびトランザクションＩＤで紐付けたものであり、ユーザのシステムにおける一連の操作を表す。したが
って、例えば一日に一回の業務時間外である深夜、あるいは週に一回の休日などにバッチとして処理されるプロファイル学習処理７０２において作成された決定木は、ユーザによる操作の特徴を表すといえる。

そして、例えば、ユーザ４１がＳａａＳ提供サーバ１０にログインしてからログアウトするまでのセッションにおいて収集されたシステムログから作成された統合ログ２２０に係る操作を行ったユーザ（すなわち、統合ログ２２０に含まれるユーザＩＤが示すユーザ）と、当該統合ログ２２０を決定木に照合して決定されるユーザとが異なる場合には、当該セッションのユーザ４１はそのユーザに特徴的な操作を行わなかったといえる。そのようなユーザ４１はなりすましのリスクがある。とくにクラウドサービスとくにＳａａＳのようなサービスでは、一般的なユーザが取り得る行動の幅はＳａａＳを使いこなすうちに定型化すると予想されることから、比較的似通った行動をとることになり、セキュリティに脅威を与える悪意のユーザ（なりすましユーザ）のとる行動は特異であることが期待される。

よって、本実施形態に係るなりすまし検出処理７０３によれば、大量のシステムログの中からなりすましの有無を早く正確に検出でき、なりすました第三者を効果的に追い出すことができる。またこれにより、ＳａａＳの認証が突破された場合に被害が拡大するリスクを軽減できる。

また、本実施形態のなりすまし検出システム１では、恣意的に設定したプロファイルを用いることなく、システムログからユーザの操作の特徴を抽出したものをプロファイルとしている。すなわち、ユーザごとに最適化されたプロファイルを用いてユーザのなりすましを検出することができる。よって、なりすましの検出を精度良く行うことができる。

また、本実施形態のなりすまし検出システム１によれば、システム開発・テスト段階におけるログ間トレース確認処理７０１により、異種のシステムログを比較して共通する値を検索し、共通する値（本実施形態では、セッションＩＤとトランザクションＩＤ）が所定数以上である場合に、これを用いて紐付け、統合ログ２２０として統合することができる。したがって、例えばユーザＩＤなど、異種のシステムログに一貫して共通する識別情報がなくても、２つのシステムログの組み合わせで共通するＩＤ等の共通値があれば、これらを紐付けることができる。

また、本実施形態のなりすまし検出システムによれば、なりすましのリスクが高くなった場合に、ユーザ４１が閲覧する画面（例えば図２９のメニュー３画面１１３０）にアラート表示１１３１を出力し、ユーザ４１に対して直接警告することができる。したがって、抑止効果が期待される。

また、本実施形態のなりすまし検出システムによれば、なりすましのリスクが高くなった場合に、アラートを表示することなくセッションを切断することもできる。この場合、なりすましによる被害をできる限り少なくすることができる。

また、本実施形態のなりすまし検出システムによれば、なりすましのリスクが高くなった場合に、セキュリティ管理者が閲覧する画面にアラートを表示することもできる。この場合、セキュリティ管理者はなりすましのリスクを容易かつ迅速に把握することができる。

また、本実施形態のなりすまし検出システムでは、プロファイルとして決定木が作成される。したがって、なりすまし検出処理７０３では、統合ログ２２０をプロファイルと照合してリンクを辿っていくだけで、現在のユーザの行動に見合ったユーザＩＤを容易に特
定することが可能となる。すなわち、なりすましの検知処理の負荷を軽減することができる。

また、本実施形態のなりすまし検出システムによれば、ＵＲＬへのアクセス頻度に応じて変化させた重みをＵＲＬにつけるとともに、格納されている情報の重要度に応じて変化させた重みをテーブルにつけたうえで決定木を作成することができる。したがって、アクセス頻度が高く、ユーザの操作の特徴が表れていないＵＲＬについての評価を落として決定木を作成するとともに、重要な情報へのアクセスはなりすましによる被害のリスクが高いものとして評価を上げて決定木を作成することができる。よって、よりユーザの操作の特徴を表すプロファイルを作成することが可能となるとともに、よりなりすましのリスクが高い操作についてのリスクを高く評価してプロファイルを作成することが可能となり、なりすましのリスクを適切に評価することができる。

以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。

例えば、本実施形態では、プロファイル学習装置２００は物理的に１台のコンピュータであるものとしたが、これに限らず、例えば複数台のコンピュータで仮想的に１台のコンピュータを構成するようにしてもよいし、複数台のコンピュータに機能部および記憶部を分散させて連携動作させるようにしてもよい。例えば、記憶部をプロファイル学習装置２００とは別体のデータベースサーバに管理させるようにしてもよい。

また、本実施形態では、ログ間トレース確認処理７０１の後にプロファイル学習処理７０２を実行するものとしたが（図１０）、これに限らず、ログ間トレース処理７０１と、プロファイル学習処理７０２の後にログ間トレース処理７０１を再度実行するようにしてもよいし、ログ間トレース処理７０１をプロファイル学習処理７０２から独立させて実行するようにしてもよい。また、ログ間トレース確認処理７０１をシステム運用時に実行するようにしてもよい。

また、本実施形態では、システムログは２つずつ統合していくものとしたが、これに限らず、共通するＩＤ（本実施形態では、セッションＩＤとトランザクションＩＤ）を用いて３つ以上のシステムログを１度に統合ログに統合するようにしてもよい。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のなりすまし検出システムにおいて、前記演算装置は、前記グルーピングに際し、各ユーザに関する前記複数種のログについて、同時間帯の異種のログ間で共通の値を検索し、該当値が所定基準以上含まれる異種ログ同士を紐付けて、対応する所定セッションにグルーピングするものであるとしてもよい。

これによれば、同時間帯のセッションに含まれる各処理のログに関してグルーピングを行うことで、無駄なログ間のトレース処理等は発生せず、全体として処理の効率化とグルーピング精度の向上が図られる。ひいては、ユーザのなりすましを確実に検出できることとなる。

また、本実施形態のなりすまし検出システムにおいて、前記演算装置は、前記プロファイルを作成する処理に際し、各ユーザの第一の統合ログがそれぞれ示す所定事象の特徴量のうち、全ユーザ中での該当ユーザを一意に特定可能なものを判定して、前記プロファイルたる決定木を作成するものであり、前記なりすましのリスク判定に際し、前記第二の統合ログを前記決定木に照合して、該当ユーザのプロファイルとの相違を特定し、所定アル
ゴリズムにより該当ユーザに関するなりすましのリスクを判定するものであるとしてもよい。

これによれば、ユーザのプロファイルを決定木として生成・管理し、以後のなりすましリスクの判定に際しても、煩雑な手順を伴わず効率的な処理で判定手順を精度良く実行することができる。ひいては、ユーザのなりすましを確実に検出できることとなる。

また、本実施形態のなりすまし検出システムにおいて、前記記憶装置は、各ユーザの通常において所定頻度以上でアクセスまたは使用する事物に関するログの所定項目に対し、所定基準以下の重み付け値が対応付けされ、各ユーザの通常において所定頻度以下でアクセスまたは使用する事物に関するログの所定項目に対し、所定基準以上の重み付け値が対応付けされた、重み付けデータベースを更に格納しており、前記演算装置は、前記第一の統合ログの生成に際し、前記グルーピングしたセッション毎の該当各ログの所定項目に対して、前記重み付けデータベースでの該当項目の重み付け値を所定ルールで演算処理して重み付けした上で、前記集約をして第一の統合ログを生成するものであるとしてもよい。

これによれば、なりすまし検出に重要となる真にイレギュラーな挙動について、上述の重み付け値に基づく処理を行うことで効率的かつ確実に特定することが可能となり、全体として処理の効率化とグルーピング精度の向上が図られる。ひいては、ユーザのなりすましを確実に検出できることとなる。

また、本実施形態のなりすまし検出システムにおいて、前記記憶装置は、各ユーザがアクセスまたは使用する各情報の重要度の高さに応じて増大する重み付け値を規定した重み付けデータベースを更に格納しており、前記演算装置は、前記第一の統合ログの生成に際し、前記グルーピングしたセッション毎の該当各ログの所定項目について、該当所定項目が示す情報に関する重み付け値を前記重み付けデータベースで特定し、当該特定した重み付け値を前記所定項目に対して所定ルールで演算処理して重み付けした上で、前記集約をして第一の統合ログを生成するものであるとしてもよい。

これによれば、なりすましのリスク判定に際して重要となる、クラウドサービスで利用される情報の重要度を考慮したグルーピングが可能となり、ひいては、ユーザのなりすましを情報の重要度の観点も踏まえた上で確実に検出できることとなる。

また、本実施形態のなりすまし検出システムにおいて、前記演算装置は、前記所定装置に所定情報を出力する処理に際し、該当ユーザが前記クラウドサービスにログイン後のユーザ端末に対して所定のアラート情報を送信するものであるとしてもよい。

これによれば、クラウドサービスにおける通常状況である、ユーザのログイン状態になりすましのアラートを上げて、該当ユーザに対する牽制をかけることが可能となり、ひいては、ユーザのなりすましを確実に検出できることとなる。

また、本実施形態のなりすまし検出システムにおいて、前記演算装置は、前記所定装置に所定情報を出力する処理に際し、該当ユーザと前記クラウドサービスとの間のセッションを切断する指示を、前記クラウドサービスの所定装置に対して送信するものであるとしてもよい。

これによれば、なりすましが疑われるユーザに関して強制力を作動させ、以後のなりすまし行動を確実に遮断することが出来る。ひいては、ユーザのなりすましを確実に検出できることとなる。

また、本実施形態のなりすまし検出システムにおいて、前記演算装置は、前記所定装置に所定情報を出力する処理に際し、該当ユーザの所属組織または前記クラウドサービスにおける所定管理者の端末に対し、所定のアラート情報を送信するものである、としてもよい。

これによれば、所定の管理責任を有する者に対する確実ななりすまし検出の報告処理が可能となり、ひいては、ユーザのなりすましを確実に検出できることとなる。

また、本実施形態のなりすまし検出方法において、前記情報処理システムが、前記グルーピングに際し、各ユーザに関する前記複数種のログについて、同時間帯の異種のログ間で共通の値を検索し、該当値が所定基準以上含まれる異種ログ同士を紐付けて、対応する所定セッションにグルーピングするとしてもよい。

また、本実施形態のなりすまし検出方法において、前記情報処理システムが、前記プロファイルを作成する処理に際し、各ユーザの第一の統合ログがそれぞれ示す所定事象の特徴量のうち、全ユーザ中での該当ユーザを一意に特定可能なものを判定して、前記プロファイルたる決定木を作成し、前記なりすましのリスク判定に際し、前記第二の統合ログを前記決定木に照合して、該当ユーザのプロファイルとの相違を特定し、所定アルゴリズムにより該当ユーザに関するなりすましのリスクを判定するとしてもよい。

また、本実施形態のなりすまし検出方法において、前記情報処理システムが、前記記憶装置において、各ユーザの通常において所定頻度以上でアクセスまたは使用する事物に関するログの所定項目に対し、所定基準以下の重み付け値が対応付けされ、各ユーザの通常において所定頻度以下でアクセスまたは使用する事物に関するログの所定項目に対し、所定基準以上の重み付け値が対応付けされた、重み付けデータベースを更に格納しており、前記第一の統合ログの生成に際し、前記グルーピングしたセッション毎の該当各ログの所定項目に対して、前記重み付けデータベースでの該当項目の重み付け値を所定ルールで演算処理して重み付けした上で、前記集約をして第一の統合ログを生成するとしてもよい。

また、本実施形態のなりすまし検出方法において、前記情報処理システムが、前記記憶装置において、各ユーザがアクセスまたは使用する各情報の重要度の高さに応じて増大する重み付け値を規定した重み付けデータベースを更に格納しており、前記第一の統合ログの生成に際し、前記グルーピングしたセッション毎の該当各ログの所定項目について、該当所定項目が示す情報に関する重み付け値を前記重み付けデータベースで特定し、当該特定した重み付け値を前記所定項目に対して所定ルールで演算処理して重み付けした上で、前記集約をして第一の統合ログを生成するとしてもよい。

また、本実施形態のなりすまし検出方法において、前記情報処理システムが、前記所定装置に所定情報を出力する処理に際し、該当ユーザが前記クラウドサービスにログイン後のユーザ端末に対して所定のアラート情報を送信するとしてもよい。

また、本実施形態のなりすまし検出方法において、前記情報処理システムが、前記所定装置に所定情報を出力する処理に際し、該当ユーザと前記クラウドサービスとの間のセッションを切断する指示を、前記クラウドサービスの所定装置に対して送信するとしてもよい。

また、本実施形態のなりすまし検出方法において、前記情報処理システムが、前記所定装置に所定情報を出力する処理に際し、該当ユーザの所属組織または前記クラウドサービスにおける所定管理者の端末に対し、所定のアラート情報を送信するとしてもよい。

１ なりすまし検出システム
１０ ＳａａＳ提供サーバ
１１ 認証管理部
１２ セッション管理部
１３ 動的ページ生成部
１４ ユーザ画面
２０ ログ収集サーバ
３０ 内部ネットワーク
３１ ＦＷ（ファイアウォール）
３２ 外部ネットワーク
４０ 端末
４１ ユーザ
５０ 監視端末
５１ セキュリティ管理者
６０ Ｗｅｂアクセスログ
７０ ＡＰＰ利用ログ
８０ ＤＢアクセスログ
１０１、２０１、３０１ ＣＰＵ
１０２、２０２、３０２ メモリ
１０３、２０３、３０３ 記憶装置
１０４、２０４、３０４ 通信装置
１０５、２０５、３０５ 電源装置
１０６、２０６、３０６ 入力装置
１０７、２０７、３０７ 出力装置
１０８、２０８、３０８ バス
１００ ログ間トレース確認装置
１１０ 異種ログ解析部
１２０ トレース確認部
１３０ ログ間トレースＤＢ
２００ プロファイル学習装置
２１０ インポート部
２２０ 重み付けＤＢ
２３０ 統合ログＤＢ
２４０ プロファイル作成部
２５０ プロファイルＤＢ
３００ なりすまし検出装置
３１０ インポート部
３２０ 統合ログＤＢ
３３０ プロファイル照合部
３４０ アラート部
４００ ログイン画面
４１０ ポータル画面
４２０ メニュー１画面
４３０ メニュー２画面
５００ 第一中間ログ
５１０、５２０ 第一中間ログ
５３０ 第二中間ログ
６００、６１０、６２０ 重み付けテーブル
１１００ ログイン画面
１１１０ ポータル画面
１１２０ メニュー１画面
１１３０ メニュー３画面
１２００ なりすまし監視画面
１６００ 異種ログトレース確認画面

Claims (16)

1. クラウドサービスのユーザに関する複数種のログを蓄積する記憶装置と、
   各ユーザに関する前記複数種のログを、前記クラウドサービスでの該当ユーザのセッション毎にグルーピングし、グルーピングしたセッション毎に該当各ログの所定項目を集約して第一の統合ログを生成し、前記第一の統合ログを所定アルゴリズムに適用して該当ユーザに関する前記クラウドサービスでの挙動特徴を示すプロファイルを作成する処理と、
   前記プロファイルの作成後に所定装置より得た、所定ユーザに関する複数種のログについて前記グルーピングおよび前記統合ログの生成を実行して第二の統合ログを生成し、当該第二の統合ログを、前記プロファイルのうち該当ユーザに関するものと照合し、所定アルゴリズムにより該当ユーザに関するなりすましのリスクを判定し、前記リスクが所定基準より高い場合に所定装置の所定情報を出力する処理と、
   を実行する演算装置と、
   を備えることを特徴とするなりすまし検出システム。
2. 前記演算装置は、
   前記グルーピングに際し、各ユーザに関する前記複数種のログについて、同時間帯の異種のログ間で共通の値を検索し、該当値が所定基準以上含まれる異種ログ同士を紐付けて、対応する所定セッションにグルーピングするものである、
   ことを特徴とする請求項１に記載のなりすまし検出システム。
3. 前記演算装置は、
   前記プロファイルを作成する処理に際し、各ユーザの第一の統合ログがそれぞれ示す所定事象の特徴量のうち、全ユーザ中での該当ユーザを一意に特定可能なものを判定して、前記プロファイルたる決定木を作成するものであり、
   前記なりすましのリスク判定に際し、前記第二の統合ログを前記決定木に照合して、該当ユーザのプロファイルとの相違を特定し、所定アルゴリズムにより該当ユーザに関するなりすましのリスクを判定するものである、
   ことを特徴とする請求項１に記載のなりすまし検出システム。
4. 前記記憶装置は、
   各ユーザの通常において所定頻度以上でアクセスまたは使用する事物に関するログの所定項目に対し、所定基準以下の重み付け値が対応付けされ、各ユーザの通常において所定頻度以下でアクセスまたは使用する事物に関するログの所定項目に対し、所定基準以上の重み付け値が対応付けされた、重み付けデータベースを更に格納しており、
   前記演算装置は、
   前記第一の統合ログの生成に際し、前記グルーピングしたセッション毎の該当各ログの所定項目に対して、前記重み付けデータベースでの該当項目の重み付け値を所定ルールで演算処理して重み付けした上で、前記集約をして第一の統合ログを生成するものである、
   ことを特徴とする請求項１に記載のなりすまし検出システム。
5. 前記記憶装置は、
   各ユーザがアクセスまたは使用する各情報の重要度の高さに応じて増大する重み付け値を規定した重み付けデータベースを更に格納しており、
   前記演算装置は、
   前記第一の統合ログの生成に際し、前記グルーピングしたセッション毎の該当各ログの所定項目について、該当所定項目が示す情報に関する重み付け値を前記重み付けデータベースで特定し、当該特定した重み付け値を前記所定項目に対して所定ルールで演算処理して重み付けした上で、前記集約をして第一の統合ログを生成するものである、
   ことを特徴とする請求項１に記載のなりすまし検出システム。
6. 前記演算装置は、
   前記所定装置に所定情報を出力する処理に際し、該当ユーザが前記クラウドサービスにログイン後のユーザ端末に対して所定のアラート情報を送信するものである、
   ことを特徴とする請求項１に記載のなりすまし検出システム。
7. 前記演算装置は、
   前記所定装置に所定情報を出力する処理に際し、該当ユーザと前記クラウドサービスとの間のセッションを切断する指示を、前記クラウドサービスの所定装置に対して送信するものである、
   ことを特徴とする請求項１に記載のなりすまし検出システム。
8. 前記演算装置は、
   前記所定装置に所定情報を出力する処理に際し、該当ユーザの所属組織または前記クラウドサービスにおける所定管理者の端末に対し、所定のアラート情報を送信するものである、
   ことを特徴とする請求項１に記載のなりすまし検出システム。
9. クラウドサービスのユーザに関する複数種のログを蓄積する記憶装置を備えた情報処理システムが、
   各ユーザに関する前記複数種のログを、前記クラウドサービスでの該当ユーザのセッション毎にグルーピングし、グルーピングしたセッション毎に該当各ログの所定項目を集約して第一の統合ログを生成し、前記第一の統合ログを所定アルゴリズムに適用して該当ユーザに関する前記クラウドサービスでの挙動特徴を示すプロファイルを作成する処理と、
   前記プロファイルの作成後に所定装置より得た、所定ユーザに関する複数種のログについて前記グルーピングおよび前記統合ログの生成を実行して第二の統合ログを生成し、当該第二の統合ログを、前記プロファイルのうち該当ユーザに関するものと照合し、所定アルゴリズムにより該当ユーザに関するなりすましのリスクを判定し、前記リスクが所定基準より高い場合に所定装置の所定情報を出力する処理と、
   を実行することを特徴とするなりすまし検出方法。
10. 前記情報処理システムが、
    前記グルーピングに際し、各ユーザに関する前記複数種のログについて、同時間帯の異種のログ間で共通の値を検索し、該当値が所定基準以上含まれる異種ログ同士を紐付けて、対応する所定セッションにグルーピングする、
    ことを特徴とする請求項９に記載のなりすまし検出方法。
11. 前記情報処理システムが、
    前記プロファイルを作成する処理に際し、各ユーザの第一の統合ログがそれぞれ示す所定事象の特徴量のうち、全ユーザ中での該当ユーザを一意に特定可能なものを判定して、前記プロファイルたる決定木を作成し、
    前記なりすましのリスク判定に際し、前記第二の統合ログを前記決定木に照合して、該当ユーザのプロファイルとの相違を特定し、所定アルゴリズムにより該当ユーザに関するなりすましのリスクを判定する、
    ことを特徴とする請求項９に記載のなりすまし検出方法。
12. 前記情報処理システムが、
    前記記憶装置において、各ユーザの通常において所定頻度以上でアクセスまたは使用する事物に関するログの所定項目に対し、所定基準以下の重み付け値が対応付けされ、各ユーザの通常において所定頻度以下でアクセスまたは使用する事物に関するログの所定項目
    に対し、所定基準以上の重み付け値が対応付けされた、重み付けデータベースを更に格納しており、
    前記第一の統合ログの生成に際し、前記グルーピングしたセッション毎の該当各ログの所定項目に対して、前記重み付けデータベースでの該当項目の重み付け値を所定ルールで演算処理して重み付けした上で、前記集約をして第一の統合ログを生成する、
    ことを特徴とする請求項９に記載のなりすまし検出方法。
13. 前記情報処理システムが、
    前記記憶装置において、各ユーザがアクセスまたは使用する各情報の重要度の高さに応じて増大する重み付け値を規定した重み付けデータベースを更に格納しており、
    前記第一の統合ログの生成に際し、前記グルーピングしたセッション毎の該当各ログの所定項目について、該当所定項目が示す情報に関する重み付け値を前記重み付けデータベースで特定し、当該特定した重み付け値を前記所定項目に対して所定ルールで演算処理して重み付けした上で、前記集約をして第一の統合ログを生成する、
    ことを特徴とする請求項９に記載のなりすまし検出方法。
14. 前記情報処理システムが、
    前記所定装置に所定情報を出力する処理に際し、該当ユーザが前記クラウドサービスにログイン後のユーザ端末に対して所定のアラート情報を送信する、
    ことを特徴とする請求項９に記載のなりすまし検出方法。
15. 前記情報処理システムが、
    前記所定装置に所定情報を出力する処理に際し、該当ユーザと前記クラウドサービスとの間のセッションを切断する指示を、前記クラウドサービスの所定装置に対して送信する、
    ことを特徴とする請求項９に記載のなりすまし検出方法。
16. 前記情報処理システムが、
    前記所定装置に所定情報を出力する処理に際し、該当ユーザの所属組織または前記クラウドサービスにおける所定管理者の端末に対し、所定のアラート情報を送信する、
    ことを特徴とする請求項９に記載のなりすまし検出方法。