【０００１】
【発明の属する技術分野】
本発明は，計算機のセキュリティに係わり，特に計算機上におけるファイルのアクセス制御において，実環境に適用する前にポリシーの調整をおこなう技術に関する。
【０００２】
【従来の技術】
計算機上でファイルのアクセス制御を実施するために，例えばオペレーティングシステムでは，ファイルにアクセスできる条件（ポリシー）をファイルごとに設定し，上記ポリシーにもとづくアクセス制御をおこなっている。こうしたポリシーにもとづくアクセス制御においては，不当なファイルアクセスをブロックするために，ポリシー設定を適切におこなう必要がある。さらに，計算機を実運用する前には，ポリシー設定が適切であることが十分確認されていなければならない。
【０００３】
特許文献１では，ディレクトリ・ファイル全体のアクセス権設定状況を把握した上で，アクセス権の参照，更新操作を行うことにより，理解容易性を向上させ，設定誤りを減少させる方法が紹介されている。
【０００４】
【特許文献１】
特開平７−２９５９４１号公報
【０００５】
【発明が解決しようとする課題】
上述のように，上記ポリシーにはファイルに対するアクセス条件を設定する。しかし，必要以上の制限をおこなうなど，過度に厳しい条件であれば，アプリケーションの動作に必要なアクセスがブロックされ，計算機を利用した業務遂行ができないことがある。
【０００６】
一方，上記アクセス条件に最低限必要な制限が不足するなど，過度にゆるい条件であれば，不正なアクセスまで許してしまうことになり，情報漏えいや改ざんなどのセキュリティ脅威の発生につながる。
【０００７】
したがって，計算機に適切なポリシーというのは，計算機の用途に必要なアクセスを通し，不必要なアクセスをブロックするものだと言える。
【０００８】
こうした過度に厳しい条件が設定したポリシーに含まれるか否か，あるいは，設定したポリシーが過度にゆるい条件となっているか否かを管理者自身が事前に検査することは，従来技術では難しかった。また，これらの条件を含むポリシーの場合に，必要以上の制限をおこなうポリシーがどこなのかを特定したり，不足しているポリシーが何であるかをを把握することが難しかった。
【０００９】
そこで，本発明の第一の目的は，ポリシーを実環境に適用する前に，上記ポリシーに過度に厳しい条件や過度にゆるい条件があるか否かを調べ，これらの条件を含むポリシーの場合に，必要以上の制限をおこなうポリシーがどこなのかを特定したり，不足しているポリシーが何であるかを提示することで，適切なポリシーへと修正する上で必要な情報を与えるポリシー診断方法を提供することにある。
【００１０】
また，本発明の第二の目的は，実環境にすでに適用したポリシーに過度に厳しい条件があるか否かを調べ，必要以上の制限をおこなうポリシーがどこなのかを特定し，適切なポリシーへと修正する上で必要な情報を与えるポリシー診断方法を提供することである。
【００１１】
【課題を解決するための手段】
上記課題を解決するために，本発明は，アクセス制御のポリシーを格納するポリシー格納手段と，システムで発生するアクセスを上記ポリシーと照合することにより違反アクセスを判別し，上記違反アクセスを格納する違反アクセス格納手段と，違反アクセスの発生した原因となるポリシーの設定項目を特定するポリシー分析手段と，上記ポリシーを表示するポリシー表示手段とを有し，上記ポリシーにおけるどこの設定項目で違反アクセスが発生したかを，上記ポリシー表示手段における表示領域上で強調表示することを特徴とするポリシー診断システムを提供する。
【００１２】
また，既知の不正アクセス情報と，上記不正アクセスをブロックするためのポリシーとを格納する不正アクセス情報格納手段と，上記ポリシー格納手段に格納されるポリシーと上記不正アクセスとを照合し，上記照合した結果を表示するポリシー照合結果表示手段とを有し，上記ポリシーではブロックできないと判断される上記不正アクセス情報については，当該不正アクセス情報に対応するポリシーを，上記ポリシー照合結果表示手段における表示領域上で表示することを特徴とするポリシー診断システムを提供する。
【００１３】
また，上記ポリシー格納手段における上記ポリシーと照合した結果違反アクセスと判定されたアクセスのうち，管理者が真の不正アクセスと判断したアクセスと，上記不正アクセス情報格納手段に格納される上記不正アクセス情報から上記ポリシーではブロックできないアクセスとを記録する不正アクセス記録手段と，上記不正アクセス情報のブロックに必要となるポリシーを提示する追加修正ポリシー提示手段と，上記追加修正ポリシー提示手段で提示された情報をもとにポリシーを修正するポリシー修正手段とを有し，上記不正アクセス記録手段は，さらに，修正後のポリシーでブロックできていない不正アクセスを記録するものであり，管理者は上記不正アクセス記録手段によって記録される不正アクセスがなくなるまでポリシーを上記ポリシー修正手段によって修正を繰り返すことを特徴とするポリシー診断システムを提供する。
【００１４】
また，上記ポリシー格納手段における上記ポリシーと照合した結果違反アクセスと判定されたアクセスのうち，管理者が正当なアクセスであると判断したアクセスと，上記ポリシーと照合した結果正当なアクセスであると判定されたアクセスとを記録する正当アクセス記録手段と，上記違反アクセスのうち管理者が正当なアクセスであると判断したアクセスを許可するのに必要となるポリシーの設定箇所を提示する追加修正ポリシー提示手段と，上記追加修正ポリシー提示手段で提示された情報をもとにポリシーを修正するポリシー修正手段とを有し，上記正当アクセス記録手段は，さらに，修正後のポリシーで許可できていない正当アクセスを記録するものであり，管理者は上記正当アクセス記録手段によって記録される許可できていない正当アクセスがなくなるまで，管理者は上記ポリシー修正手段によって修正を繰り返すことを特徴とするポリシー診断システムを提供する。
【００１５】
また，上記ポリシー表示手段において，当該ポリシーに合致したアクセスが何回あったかを示すカウントを集計するカウント集計手段を有し，上記ポリシー表示手段における表示領域において，上記カウント集計手段で集計したカウントを上記ポリシーとあわせて表示することを特徴とするポリシー診断システムを提供する。
【００１６】
さらに，上記ポリシー表示手段と，上記カウント集計手段とを有し，上記ポリシー表示手段における表示領域において，上記カウント集計手段で集計したカウントが０回である場合に，上記カウントを強調表示することを特徴とするポリシー診断システムを提供する。
【００１７】
また，本発明は別の見地からすれば，違反アクセスの中で管理者が真の不正アクセスであると判断したものがある場合に，上記不正アクセスを再現するための情報および上記不正アクセスをブロックするためのポリシー情報を，上記不正アクセス格納手段に格納するための手段を提供することを特徴とする。
【００１８】
【発明の実施の形態】
本発明の一実施の形態を，図１から図１０ならびに図１２を用いて説明する。図１は，本発明を適用したシステムの全体構成を示す図である。１００はポリシー診断モジュール，１１０はアクセス制御モジュール，１２０はポリシーデータ，１３０はログデータ，１４０は不正アクセスデータである。計算機１０は，ハードウェア要素として，ＣＰＵ１１，メモリ１２，ハードディスクなどの外部記憶装置１３，上記外部記憶装置１３の制御をおこなうコントローラ１４，キーボードやマウスなどの入力装置１５，ディスプレイなどの出力装置１６，ネットワーク３０に接続している他の計算機との通信をおこなう通信装置１７，バス等の信号線１８から構成され，また，ソフトウェア要素として，オペレーティングシステム２０，ファイルシステム２１，アプリケーション２２から構成される。上記ポリシー診断モジュール１００および上記アクセス制御モジュール１１０は，外部記憶装置１３からメモリ１２上にロードされ，ＣＰＵ１１上で処理されるプロセスである。また，上記ポリシーデータ１２０と上記ログデータ１３０は，外部記憶装置１３上に永続的に格納されるデータである。
【００１９】
上記アクセス制御モジュール１１０は，計算機１０上で常駐プロセスとして存在する。上記アクセス制御モジュール１１０は，上記アプリケーション２２がファイルシステム２１を通して外部記憶装置１３上のファイルにアクセスすることを監視し，監視結果を上記ポリシーデータ１２０の内容と比較することにより，違反アクセスを検出する。違反アクセスであれば，該アクセスをブロックし，該アクセスの内容を上記ログデータ１３０に記録する。
【００２０】
上記ポリシー診断モジュール１００は，計算機１０上で管理者が任意のタイミングで起動命令を出すときに実行開始されるプロセスとして存在する。上記ポリシー診断モジュール１００は，上記ログデータ１３０をもとに，上記ポリシーデータ１２０におけるどの設定項目で違反が発生したかを割り出し，出力装置１６に表示する。また，上記ポリシー診断モジュール１００は，入力装置１５から管理者の入力情報を受け取り，上記ポリシーデータ１２０の変更もおこなう。
【００２１】
次に，図２を用いて，ポリシー診断のフェーズ全体について説明する。ポリシーを管理する管理者の作業は，作成フェーズ２１０とテストフェーズ２２０と運用フェーズ２３０とに分類できる。まず，作成フェーズ２１０にてポリシーの草案２３１を作成すると，次にテストフェーズ２２０では，実際に計算機１０のユーザに，後述する運用フェーズ２３０で想定される操作を，例えば年に１度しかおこなわない操作なども含めて一通りおこなってもらい（ステップ２２１），そこで発生した違反アクセスの記録をおこない（ステップ２２２），該違反アクセスの情報をもとにポリシーのどこの設定で違反が起きたかの表示をおこない（ステップ２２３），必要があればポリシーの修正をおこない，修正後の再チェックをおこなう（ステップ２２４）。再チェックの後は，再度計算機１０を使用してもらうこと（ステップ２２１）をおこなう。
【００２２】
上記テストフェーズ２２０においては，計算機を正常動作させる限りは違反アクセスが発生しないと考えられるため，運用フェーズ２３０で想定される操作を一通りおこなう間に発生する違反アクセスの数が一定値を下回るようになればテストフェーズを抜け，該ポリシーを完成したポリシー２３２として確定し，運用フェーズ２３０へとうつる。運用フェーズ２３０では，ポリシーの修正をおこなうことはできない。しかし，違反アクセスがあまりにも多発するなど，ポリシーが計算機１０に適切でないと判断されるならば，上記完成したポリシー２３２を保守が必要なものとみなして，２３３で示すように再度テストフェーズ２２０にうつり，ポリシーの修正をおこなう。
【００２３】
本実施形態のポリシー診断は，おもに上記テストフェーズ２２０の作業を支援するためのものである。
【００２４】
なお，以下では，アクセス制御のポリシーに適合しないアクセスを「違反アクセス」と呼び，一方，悪意のある者がおこなう正当でないアクセスを「不正アクセス」と呼ぶことにする。「違反アクセス」の中には「不正アクセス」も操作ミスも含まれることがあり，また「不正アクセス」の全てが「違反アクセス」に含まれるとは限らない。これは「違反アクセス」がポリシーに依存して定義されるものであるのに対し，「不正アクセス」はポリシーとは関係なく計算機１０上で発生する可能性があるためである。
【００２５】
続いて，図３から図５ならびに図１２を用いて，図２で示した全体フェーズのうち実際に計算機を使用すること（ステップ２２１）から違反アクセスを記録すること（ステップ２２２）にかけての説明を中心にして，ポリシーの詳細と，計算機１０を使用していく上で発生する違反アクセスの詳細，ならびに，アクセス制御モジュール１１０の動作の詳細について説明する。
【００２６】
図３は，上記ポリシーデータ１２０の構造の一例を示した図である。上記ポリシーデータは，ポリシー定義テーブル３００から構成される。上記ポリシー定義テーブル３００は，テーブル内のレコードを一意に特定するための値をもつポリシーＩＤフィールド３０１と，計算機１０上のファイルを一意に特定するための絶対パスを格納するファイルフィールド３０２と，計算機１０上のユーザを一意に特定するためのユーザＩＤあるいはユーザ名を格納するユーザフィールド３０３と，計算機１０上のアプリケーションを一意に特定するための絶対パスを格納するプログラムフィールド３０４と，上記ユーザが上記プログラムをもちいて上記ファイルにアクセスできる種別をあらわすアクセスタイプフィールド３０５と，上記プログラムのファイルサイズあるいはハッシュ値などを格納する特徴値フィールド３０６と，アクセスできるための時間帯を指定する時間帯フィールド３０７とから一つのレコードが構成される，レコードの集まりである。
【００２７】
例えば図３においてポリシーＩＤ３０１が「１」のポリシーは，ファイル「Ｃ：￥ｄｏｃｕｍｅｎｔ￥ｓｅｃｒｅｔ．ｄｏｃ」にアクセスできるのは，ユーザ「ｓｕｚｕｋｉ」が特徴値「０ｘ１２３４」なるプログラム「Ｃ：￥ｐｒｏｇｒａｍ￥ｗｏｒｄ．ｅｘｅ」を使って，時間帯「９：００から１７：００」のあいだに読み込み（ｒ）あるいは書き込み（ｗ）することに限る，という意味をあらわす。
【００２８】
なお，上記ファイル３０２は計算機１０上のフォルダであってもよく，また，上記ユーザ３０３は計算機１０上のユーザグループであってもよい。
【００２９】
図４は，上記ログデータ１３０の構造の一例を示した図である。上記ログデータ１３０は，アクセスログ４００ならびにポリシー照合ログ４２０とから構成される。さらに，図２に示したテストフェーズ２２０にて，ステップ２２１からステップ２２４まで１周することを１回と数えるときに，何回目のテストにおける上記アクセスログ４００と上記ポリシー照合ログ４２０とであるかを示す４３１および４３２のシートから構成される。
【００３０】
上記アクセスログ４００は，計算機１０上で発生した全てのファイルアクセスを記録したものであり，上記ポリシー定義テーブル３００で規定するポリシーに適合したアクセスならば，不正フラグフィールド４１７を「０」とするレコードとして格納し，違反したアクセスならば，不正フラグフィールド４１７を「１」とするレコードとして格納する。上記アクセスログ４００の一つのレコードは，適合アクセスならびに違反アクセスの場合に共通して，アクセス対象となったファイルを示すファイルフィールド４０１と，誰がアクセスしたかを示すユーザフィールド４０２と，どのプログラムでアクセスしたかを示すプログラムフィールド４０３と，読み・書き・実行等のアクセスの種別を示すアクセスタイプフィールド４０４と，いつアクセスしたかを示す時刻フィールド４０６と，上記プログラムの特徴値を示す特徴値フィールド４０５から構成される。
【００３１】
さらに違反アクセスの場合であれば，４１１から４１６に示す理由フィールドには，上記違反アクセスがポリシーのどのフィールドで合致しなかったかを示す情報が格納される。例えば，一つの違反アクセス４０７は，上記ポリシー定義テーブル３００におけるポリシーＩＤが「１」のポリシーとはプログラム・特徴値が異なることが理由で違反となり，ポリシーＩＤが「２」のポリシーとはユーザ・プログラム・アクセスタイプ・特徴値が異なることが理由で違反となり，上位フォルダから継承されたポリシーとなっているポリシーＩＤ「４」のポリシーとは，アクセスタイプが異なることが理由で違反となったものである。
【００３２】
さらに，上記アクセスログ４００は，後述するポリシーの再診断で利用するための再診断フラグフィールド４１８とから構成される。また，上記ポリシー照合ログ４２０は，計算機１０上で発生したファイルアクセスが上記ポリシー定義テーブル３００にあるポリシーのいずれかに合致する（ヒットすると呼ぶことにする）場合に，上記ポリシーのヒット回数を集計したヒット数４２１と，上記ポリシーのポリシーＩＤ３０１とのペアを一つのレコードとする，レコードの集まりである。
【００３３】
また，図１２に上記不正アクセスデータ１４０のデータ構造の一例を示す。上記不正アクセスデータ１４０は，１２０１に示す一つの不正アクセス再現データに，１２０２および１２０３および１２０４に示すような０個以上のポリシーデータとを組み合わせたものを一つのペアとする，複数のペアから構成される。例えば，１２０５に示す不正アクセス再現データには，２つのポリシー１２０６と１２０７とが対応する。
【００３４】
例えば，上記不正アクセスデータ１４０には，コンピュータウィルスやトロイの木馬の挙動を上記不正アクセス再現データ１２０１および１２０５として格納しておく。Ｓｙｓｔｅｍフォルダにある通常は書き換えの行われるはずのないＤＬＬファイルの書き換えをおこなおうとする挙動や，計算機の起動と同時に不正なプログラムを動作させようとするためにスタートアップフォルダにプログラムを書き込もうとする挙動などを，上記不正アクセス再現データ１２０１および１２０５として格納しておく。
【００３５】
つづいて図５を使って，上記アクセス制御モジュール１１０にて実行される処理をあらわすフローチャートを説明する。ユーザが計算機１０を使用していく上でアプリケーション２２を実行すると，ファイルアクセスが発生する。例えば，ワープロソフトを起動する場合，ドキュメントファイルをオープンすることとなる。上記アクセス制御モジュール１１０はこうしたファイルアクセスの監視をおこない（ステップ５０１），
該ファイルアクセスの情報，
ファイル＝（ファイルの絶対パス）
ユーザ＝（ユーザＩＤあるいはユーザ名）
プログラム＝（プログラムの絶対パス）
アクセスタイプ＝（アクセスタイプの種別）
特徴値＝（上記プログラムの特徴値）
時刻＝（システム時刻）
を収集する（ステップ５０２）。
【００３６】
つぎに，収集した該ファイルアクセスの情報における該ファイルが上記ポリシー定義テーブル３００のファイルフィールド３０２に合致するものかどうか，さらに，上記ファイルフィールド３０２が該ファイルの上位フォルダとなっているかどうかを調べる（ステップ５０３）。上記ステップ５０３にて合致しないならば，該ファイルアクセスをファイルシステム２１へとフォワードし，アクセスを許可する（ステップ５０７）。
【００３７】
一方，上記ステップ５０３にて合致するものであれば，次に該ファイルアクセスを上記ポリシー定義テーブル３００にあるポリシーの一つのレコードずつと照合をおこない（ステップ５０４），もしポリシーのいずれかに合致するならば，該ファイルアクセスの情報を上記アクセスログ４００における４０１から４０６のフィールドに記録し，また上記不正フラグフィールド４１７の値を「０」ならびに上記再診断フラグフィールド４１８の値を「１」として記録し（ステップ５０５），合致した上記ポリシーに該当する，上記ポリシー照合ログ４２０のヒット数４２１の値をインクリメントし（ステップ５０６），ファイルシステム２１へと該ファイルアクセスをフォワードする。
【００３８】
一方，上記ステップ５０４においてポリシーのいずれのレコードにも合致しないならば，上記違反アクセスログ４００に該ファイルアクセスの内容を４０１から４０６のフィールドに記録し，また上記不正フラグフィールド４１７の値を「１」ならびに上記再診断フラグフィールド４１８の値を「０」として記録し（ステップ５０８），該アクセスの発行元となるプログラムに対してファイルへのアクセスを禁止した旨のエラーを通知する（ステップ５０９）。以上の処理が完了すると，ふたたび上記ステップ５０１へと戻る。
【００３９】
ここで，ファイルアクセスがポリシーに違反する場合に，ファイルアクセスを禁止されることにより想定しない不具合をアプリケーション２２が起こさないようにするため，違反アクセスである旨のログ記録をおこなった上でファイルアクセスを許可するものとしてもよい。
【００４０】
続いて，図６から図１０を用いて，図２で示した全体フェーズのうちポリシーを見直すこと（ステップ２２３）からポリシーを修正すること（ステップ２２４）にかけての説明を中心に，上記ポリシー診断モジュール１００の動作の詳細について説明する。
【００４１】
図６は，管理者が上記ポリシー診断モジュール１００を起動したときに出力装置１６に表示される画面の一例を表したものである。上記ポリシー診断画面６００は，図２における何周目のテストフェーズ２２０であるかを示す６０１と，計算機１０上で発生した違反アクセスの一覧を示す領域６１０とから構成される。つづいて，上記領域６１０にてプルダウンメニュー６１１から一つの違反アクセスを選択したときに一意に決定される，６２０に示す上記違反アクセスのアクセス対象となったファイルに対するポリシーの一覧と，６３０に示すその他のポリシーの一覧とを表示する。この表示の方法を，図７を使って説明する。
【００４２】
図７は，上記ポリシー診断画面６００を表示するためのフローチャートを示したものである。まず上記ポリシー診断画面６００の表示を開始すると，図４に示す上記違反アクセスログ４００の再診断フラグフィールド４１８が「０」であるレコードを検索し，検索結果であるレコードの一覧を図６の領域６１０に表示する。ここで，図６に示す４１７のチェックボックスを管理者がＯＮにすると図４に示す不正フラグフィールド４１７の値が「２」となり，ＯＦＦにすると値が「１」となるように連動している（ステップ７０１）。
【００４３】
つぎに，上記領域６１０から管理者が一つの違反アクセスを選択すると（ステップ７０２），上記ポリシー定義テーブル３００にあるポリシーのレコードを順に参照していくループ処理を開始する。ここで管理者の選択した違反アクセスをＡと呼び，ループ処理されているときの一つのポリシーをＰと呼ぶことにする。上記違反アクセスＡに対応する上記理由フィールド４１１から４１６にかけての中に上記ポリシーＰが含まれるならば（ステップ７０３），上記ポリシーＰを違反アクセスのアクセス対象となったファイルに対するポリシーとして図６に示す領域６２０に表示する（ステップ７０４）。
【００４４】
このとき，上記理由フィールド４１１から４１６に対応して，図６の６２２に示すように強調表示する（ステップ７０５）。さらに，上記ポリシーＰに対応する，上記ポリシー照合ログ４２０のヒット数フィールド４２１にある値を，図６の４２１に示すように表示し，さらに上記ヒット数４２１の値が「０」ならば６２３に示すように強調表示する（ステップ７０７）。
【００４５】
上記ステップ７０３において，含まれないならば，上記ポリシーＰを図６に示すその他のポリシー一覧の領域６３０に表示する（ステップ７０６）。このとき，上記ポリシーＰに対応する上記ヒット数４２１にある値が「０」ならば，図６の６３１に示すように強調表示する（ステップ７０７）。
【００４６】
例えば図６の表示例は，管理者が上記違反アクセスログ４００における違反アクセス４０７を選択したときのものであり，管理者は図６を見ながら次に述べるようにポリシー診断ならびにポリシー修正を行っていくことができる。まず，違反アクセスのアクセス対象となったファイルに関係するポリシーの一覧６２０を見ると，上記ポリシー定義テーブル３００におけるポリシーＩＤ３０１が「１」と「２」と「４」のポリシーが該当しており，さらにそれぞれのポリシーごとに６２２に示すように違反を引き起こした原因のフィールドを知ることができる。
【００４７】
もし，６２２に示すように強調表示された部分の中に原因があると管理者が判断するならば，該原因となるポリシーをマウスでクリックし選択状態にしたうえでポリシー更新ボタン６５３を押下することで，上記ポリシーの編集をおこなうための図８に示す画面８００を呼び出すことができる。さらに，ヒット数４２１を見ると，ポリシーＩＤが「１」のポリシーはまだ一度もヒットしていないことが分かり，それゆえポリシーＩＤが「１」のポリシーのプログラムフィールドが設定ミスである可能性のあることや，また，図２に示すステップ２２１にて実際に計算機を利用する上で，実行動作させていないアプリケーションとして「Ｃ：￥ｐｒｏｇｒａｍ￥ｗｏｒｄ．ｅｘｅ」が残っている可能性のあることを示唆している。
【００４８】
また，そのほかのポリシー一覧６３０を見ると，ポリシーＩＤ３０１が「３」のポリシーが一度もヒットしていないことも分かる。さらに，管理者が上記違反アクセス４０７を本当の不正アクセスであると判断するならば，図６に示すチェックボックス４１７にて，該違反アクセスにマークをつけることができる。また，上記違反アクセス４０７が実はポリシーで許可すべきアクセスであることを管理者が判断したならば，ポリシー新規追加ボタン６５２を押下することにより図８に示す画面８００を呼び出し，あらたなポリシーを追加したり，違反アクセスをポリシーに追加するボタン６５１を押下するならば，上記違反アクセス４０７を許可するようなポリシーの草案があらかじめ入力される図８に示す画面８００を呼び出して，上記違反アクセス４０７をもとにしたポリシーを適宜修正して設定することをおこなう。
【００４９】
さらに，アプリケーションのバージョンアップなどにより，上記特徴値４０５の値がポリシーで規定されないものと管理者が判断する場合，一括更新ボタン６５４を押下することにより，上記特徴値４０５の値に関するポリシー設定を一括しておこなうことのできる図８に示す画面８１０を呼び出すことをおこなう。
【００５０】
さて，図６において違反アクセスをポリシーに追加するボタン６５１，あるいは，ポリシー新規追加ボタン６５２を押下，あるいは，領域６２０と領域６３０に表示されているポリシーをクリックし選択状態にした上でポリシー更新ボタン６５３を押下したときに表示されるポリシー設定画面８００を図８に示す。上記ポリシー設定画面８００では，上記ポリシー定義テーブル３００にレコードを追加あるいは更新するために，ファイル３０２の絶対パスと，ユーザ３０３のユーザＩＤあるいはユーザ名と，プログラム３０４の絶対パスと，アクセスタイプ３０５の種別と，時間帯３０７と，該プログラムの特徴値３０６を入力するようになっており，管理者がＯＫボタン８０１を押下することで，上記ポリシー定義テーブル３００に上記入力したポリシーの情報を格納し，上記ポリシー設定画面８００を閉じることをおこなう。
【００５１】
あるいは，削除ボタン８０２を押下することで，管理者がポリシーをクリックして選択したことをあらわす表示になっているポリシーのレコードを上記ポリシー定義テーブル３００から削除することをおこなう。あるいは，キャンセルボタン８０３を押下することで，上記ポリシー定義テーブル３００へ上記入力したポリシーの格納をおこなわずに，上記ポリシー設定画面８００を閉じることをおこなう。あるいは，適用ボタン８０３を押下することで，上記ポリシー定義テーブル３００へと上記入力したポリシーの格納をおこない，上記ポリシー設定画面８００を開いたままにしておくことをおこなう。
【００５２】
ここで，図８における６２２に示す強調表示のように，図６で違反アクセスの原因となったポリシーの設定項目を示す６２２の強調表示を，図８においても引き継ぐものとする。
【００５３】
また，図６の一括更新ボタン６５４を押下したときに表示されるポリシー一括更新画面８１０を図８に示す。上記ポリシー一括更新画面８１０では，更新方法についてラジオボタン８１１から８１４の中から一つを選択することができ，例えば８１１を選択した時には，管理者が８１５に指定するファイルをもつポリシーについて，該ポリシーのファイルフィールド３０２を８１６で指定する絶対パスに一括更新することが可能である。
【００５４】
また，図６の「再診断へ」ボタン６５５を押下すると，図９に示すポリシー再診断画面９００へと遷移する。上記ポリシー再診断画面９００は，管理者が図６に示すポリシー診断画面６００にて全ての違反アクセスにわたってポリシーの修正を行ったあとに，ポリシーに適切な修正がおこなわれたかどうかの再チェックをおこなうために呼び出すものであり，図１０に示すフローチャートに沿った処理をおこなう。上記ポリシー再診断画面９００は，不正アクセスデータ１４０に格納される既知の不正アクセスをシミュレートした結果を示す９１０の領域と，違反アクセスの中から管理者が真の不正アクセスであると判断したものについてシミュレートした結果を示す９２０の領域と，違反アクセスの中から上記不正アクセス以外のものについてシミュレートした結果を示す９３０の領域と，システムで発生した適合アクセスについてシミュレートした結果を示す９４０の領域とから構成される。
【００５５】
上記ポリシー再診断画面９００の表示を開始すると，図１２に示す上記不正アクセスデータ１４０を検索し，１２０１や１２０５の全ての不正アクセス再現データを取得する（ステップ１００１）。つぎに上記不正アクセス再現データをポリシーと照合し（ステップ１００２），もし許可ならば，上記領域９１０にて上記不正アクセスデータを表示する部分の真横に，上記不正アクセス再現データをブロックするためのポリシーを設定するためのボタン９１１を表示し，許可という結果を模擬結果フィールド９０１に９１２に示すように強調表示する（ステップ１００４）。もし禁止ならば，上記不正アクセス再現データを表示する部分の真横に上記ポリシー設定ボタン９１１を表示することはせずに，禁止という結果を模擬結果フィールド９０１に表示する（ステップ１００４）。以上のステップ１００２からステップ１００４までの処理を，ステップ１００１で取得した上記不正アクセスデータ１４０にある不正アクセス再現データすべてについておこなう。
【００５６】
上記ポリシー設定ボタン９１１を管理者が押下したときには，図８に示すポリシー設定画面８００を複数回呼び出すことで，図１２に示すポリシー１２０２から１２０４の内容を表示する。これにより管理者は，ポリシーで防止できていない既知の不正アクセスに対してのポリシー追加設定をおこなうことができる。
【００５７】
つぎに，図４に示す上記アクセスログ４００にて，不正フラグフィールド４１７の値が「２」となるレコードを検索する（ステップ１００６）。上記不正フラグフィールド４１７の値が「２」とは，計算機上で発生した違反アクセスの中でも，管理者が不正アクセスであると判断したものである。上記不正アクセスについてポリシーと照合をおこない（ステップ１００６），もし許可ならば上記不正アクセスのレコードにおける上記再診断フラグフィールド４１８の値を「０」に更新し（ステップ１００７），模擬結果フィールド９０１に許可という結果を９２２に示すように強調表示する（ステップ１００９），もし禁止ならば上記再診断フラグフィールド４１８の値を「１」に更新し（ステップ１００８），模擬結果フィールド９０１に禁止という結果を表示する（ステップ１００８）。以上のステップ１００６からステップ１００９までの処理をステップ１００５で検索した全てのレコードにわたっておこなう。
【００５８】
さらに，上記アクセスログ４００にて，上記不正フラグフィールド４１７の値が「１」であるレコードを検索し（ステップ１０１０），ポリシーと照合する（ステップ１０１１）。この場合，違反アクセスの中でも不正アクセスではないため，アクセスが許可となることが想定される。そこで，ポリシー照合の結果が禁止ならば，上記再診断フィールド４１８の値を「０」に更新し，模擬結果フィールド９０１を９３１に示すように強調表示し（ステップ１０１２），ポリシー照合の結果が許可ならば，該値を「１」に更新し（ステップ１０１３），それぞれ禁止あるいは許可の結果を模擬結果フィールド９０１に表示する（ステップ１０１４）。以上のステップ１０１１からステップ１０１４までの処理を，ステップ１０１０で検索したレコード全てにわたっておこなう。
【００５９】
最後に，上記アクセスログ４００にて，上記不正フラグフィールド４１７の値が「０」であるレコードを検索し（ステップ１０１５），ポリシーと照合する（ステップ１０１６）。もし禁止ならば，一度適合アクセスとなったものが，ポリシー修正を行ったことにより，アクセスが禁止されるようになったことが分かり，上記再診断フラグフィールド４１８の値を「０」に更新し，模擬結果フィールド９０１を９４１に示すように強調表示し（ステップ１０１７），許可ならば該値を「１」に更新し（ステップ１０１８），上記模擬結果フィールド９０１に禁止あるいは許可の結果を表示する。以上のステップ１０１６からステップ１０１９までの処理を，ステップ１０１５で検索したレコード全てにわたっておこなう。
【００６０】
以上で，上記ポリシー再診断画面９００の表示を完了する。
【００６１】
ここで，管理者が「ＤＢに追加」ボタン９２１を押下するならば，９２０に示す「システムで発生した違反アクセス中の不正アクセス」の全てを，上記不正アクセスデータ１４０に格納する。このとき，上記不正アクセスをブロックするためのポリシー設定の入力を，図８に示すポリシー設定画面８００と同じ画面を複数回呼び出すことを通じておこなう。
【００６２】
また，図９において，管理者が上記ポリシー再診断画面９００を参照することで，不正アクセスなのに許可をしていたり，正常アクセスなのに禁止をしていたりすることが分かり，ポリシーの修正がさらに必要だと管理者が判断するならば「ポリシー診断へ」ボタン９０２を押下することで遷移する図６に示す上記ポリシー診断画面６００上で，再度ポリシー診断および修正をおこなう。このとき，図４に示す上記アクセスログ４００における上記再診断フラグフィールド４１８の値が「０」であるレコードを再度見直していくこととなる。
【００６３】
また，図９において，管理者がポリシーの修正が一通り終了したことを確認し，まだ計算機１０上で動作させていないアプリケーションがあるなど，図２に示すテストフェーズ２２０をさらにおこなうと判断する場合には，「３回目テストの開始」ボタン９０３を押下すればよい。このとき，図４に示すシート４３１およびシート４３２において，新たに「３回目テスト」のシートが追加され，アクセスログ４００およびヒット数４２１などがリセットされた状態からテストフェーズ２２０を実施することとなる。
【００６４】
また，図９において，不正アクセスなのに許可をしていたり，正常アクセスなのに禁止をしていたりすることが管理者の許容範囲内におさまり，これ以上テストフェーズ２２０をおこなう必要がないと管理者が判断するならば，「テストフェーズを終了する」ボタン９０４を押下すればよい。これにより，上記ポリシー再診断画面９００を閉じる。
【００６５】
以上，本発明の第一の実施例によれば，ポリシーを実環境に適用する前に，想定される利用の全てにわたってユーザに計算機を利用してもらい，計算機上で発生した違反アクセスを記録しておき，上記違反アクセスの発生した原因となるポリシーの設定項目を特定し，上記ポリシーにおけるどこの設定項目で違反アクセスが発生したかを，上記ポリシーを示す表示領域上で強調表示することにより，適切なポリシーへと修正するうえで必要な情報を提供することができる。
【００６６】
ならびに，既知の不正アクセスをシミュレートすることで，必要な制限をポリシーが行っていることを確認し，制限が不足しているならば，上記不正アクセスを防止するためのポリシーの草案を提示することにより，適切なポリシーへと修正するのに必要な情報を提供することができる。
【００６７】
これにより，第一の目的を満たす。
【００６８】
続いて本発明の第二の実施例を説明する。第二の実施例は，図２に示す運用フェーズ２３０において実環境にすでに適用したポリシーに過度に厳しい条件がある場合，例えば，テストフェーズ２２０において想定しなかったアプリケーションを運用フェーズ２３０になってはじめて利用したときに動作できないことが分かった場合などに，適切なポリシーへと修正をおこなうためのものである。
【００６９】
第二の実施例におけるシステム構成は，図１に示すものと同等であり，区別のため，第一の実施例におけるポリシーデータを１２０ａおよびログデータを１３０ａおよび不正アクセスデータを１４０ａとし，第二の実施例におけるポリシーデータを１２０ｂおよびログデータを１３０ｂおよび不正アクセスデータを１４０ｂとする。
【００７０】
運用フェーズ２３０においては，上記ポリシーデータ１２０ｂのもと計算機１０上のファイルにアクセス制御が適用されており，計算機１０上で発生した違反アクセスを上記ログデータ１３０ｂに記録する。運用フェーズ２３０で計算機１０のユーザが動作できないアプリケーションがある旨が管理者に伝えられるなどして，管理者がポリシーを保守すべきだと判断した場合，管理者は図１に示す上記ポリシー診断モジュール１００を起動する。このとき，図２に示す２３３のパスにおいては，上記ポリシーデータ１２０ｂおよび上記ログデータ１３０ｂとをテストフェーズ２２０へとわたす。ここで，テストフェーズ２２０ではステップ２２１とステップ２２２とをスキップし，ステップ２２３へと進む。
【００７１】
上記ポリシー診断モジュール１００は，上記ポリシーデータ１２０ｂおよび上記ログデータ１３０ｂをもとに，図７に示すフローチャートにしたがって動作し，図６に示すポリシー診断画面６００を出力装置１６に表示する。このとき管理者は，第一の実施例における図２に示すステップ２２３と同様にポリシーの診断および修正をおこない，第一の実施例におけるステップ２２４と同様に図９に示すポリシー再診断画面９００を呼び出すことにより，ポリシーの再チェックをおこなう。ここで，上記ポリシー再診断画面９００を呼び出す際には，領域９１０の表示，すなわち，不正アクセスデータ１４０ｂにある既知の不正アクセスとの照合をおこない，結果を表示する。
【００７２】
管理者は，以上のステップ２２３およびステップ２２４における作業を通じて，違反アクセスの発生した原因となるポリシーの設定箇所を容易に特定することができ，適切なポリシーへと修正をおこない，適切な修正をおこなったかの確認をおこなうことができる。以上の管理者の作業が終了したならば，修正後のポリシーデータ１２０ｂを図２に示す完成したポリシー２３２としてふたたび運用フェーズ２３０へとわたすことをおこなう。
【００７３】
続いて本発明の第三の実施例を，図１１をもちいて説明する。計算機１０は図１で示したシステム構成を有しネットワーク３０に接続した複数台の計算機であり，１２０はマスターとなるポリシーを保有するポリシー配布サーバであり，１００はネットワーク経由でリモートから計算機１０上のポリシーを診断するポリシー診断コンソールであり，１４０は上記計算機１０上で発生した不正アクセスの情報を集中的に保持するための不正アクセスＤＢである。上記ポリシー配布サーバ１２０は，図２の全体フェーズでいうポリシーの草案２３１を保有しており，各計算機１０へと上記ポリシーの草案２３１をネットワーク経由で一律に配布する。次に，上記ポリシー診断コンソール１００は，各計算機１０をユーザに使用してもらいながら，管理者はネットワーク３０経由でリモートから図２のテストフェーズを実現する。上記不正アクセスＤＢ１４０は，各計算機１０上で不正アクセスが発生した場合に，上記不正アクセスを再現するための情報を集中保持するものであり，上記再現データをもとに，各計算機１０上では不正アクセスのシミュレートをおこなうことが可能となる。
【００７４】
管理者は，各計算機１０の端末まで行かなくても，ネットワーク経由でリモートからポリシー診断をおこなうことができるとともに，計算機１０の台数が増えた場合にも，ポリシー配布とポリシー診断のスケーラビリティを確保することができる。また，いずれかの計算機１０上で不正アクセスが発生したときには，上記不正アクセスの情報を計算機１０間で共有することができ，対策のためのノウハウを蓄積してくことができる。
【００７５】
以上のように，ポリシーを実環境に適用する前に，想定される利用全てにわたりユーザに計算機を利用してもらい，計算機上で発生した違反アクセスを記録しておき，上記違反アクセスの発生した原因となるポリシーの設定項目を特定し，上記ポリシーにおけるどこの設定項目で違反アクセスが発生したかを，上記ポリシーを示す表示領域上で強調表示することにより，適切なポリシーへと修正するのに必要な情報を提供することができる。これにより，管理者はポリシーの過剰な設定となっている部分を容易に特定でき，適切な修正へと取りかかることができる。
【００７６】
また，既知の不正アクセスをシミュレートすることで，必要な制限をポリシーが行っていることを確認し，制限が不足しているならば，上記不正アクセスを防止するためのポリシーの草案を提示することにより，適切なポリシーへと修正するのに必要な情報を提供することができる。これにより，管理者はポリシーに不足があることに気づくことができ，適切な修正へと取りかかることができる。
【００７７】
また，すでに実環境に適用したポリシーにおいて，上記ポリシーで発生した違反アクセスを記録しておき，上記違反アクセスの発生した原因となるポリシーの設定箇所を特定し，上記ポリシーにおけるどこの設定項目で違反アクセスが発生したかを，上記ポリシーを示す表示領域上で強調表示することにより，適切なポリシーへと修正するのに必要な情報を提供することができる。これにより，管理者はすでに実環境に適用したポリシーの過剰な設定となっている部分を容易に特定でき，適切な修正へと取りかかることができる。
【００７８】
【発明の効果】
本発明によれば，適切なポリシーへと修正する上で必要な情報を与えるポリシー診断方法を提供できる。
【図面の簡単な説明】
【図１】ポリシー診断システムの全体ブロック図。
【図２】ポリシー診断のフェーズ全体をあらわした図。
【図３】ポリシーデータのデータ構成図。
【図４】ログデータのデータ構成図。
【図５】アクセス制御モジュールの動作をあらわすフローチャート図。
【図６】ポリシー診断モジュールのポリシー診断画面例。
【図７】ポリシー診断モジュールの，ポリシー診断画面を表示するための動作をあらわすフローチャート図。
【図８】ポリシー診断モジュールのポリシー設定画面例およびポリシー一括更新画面例。
【図９】ポリシー診断モジュールのポリシー再診断画面例。
【図１０】ポリシー診断モジュールの，ポリシー再診断画面を表示するための動作をあらわすフローチャート図。
【図１１】第二の実施例における，ネットワーク構成図。
【図１２】不正アクセスデータのデータ構成図。
【符号の説明】
１０・・・計算機、１１・・・ＣＰＵ、１２・・・メモリ、１３・・・外部記憶装置、１４・・・コントローラ、１５・・・入力装置、１６・・・出力装置、１７・・・通信装置、１８・・・バス、２０・・・ＯＳ、２１・・・ファイルシステム、２２・・・アプリケーション、３０・・・ネットワーク、１００・・・ポリシー診断モジュール、１１０・・・アクセス制御モジュール、１２０・・・ポリシーデータ、１３０・・・ログデータ、１４０・・・不正アクセスデータ、２１０・・・作成フェーズ、２２０・・・テストフェーズ、２３０・・・運用フェーズ、３００・・・ポリシー定義テーブル、３０１・・・ポリシーＩＤフィールド、３０２・・・ファイルフィールド、３０３・・・ユーザフィールド、３０４・・・プログラムフィールド、３０５・・・アクセスタイプフィールド、３０６・・・特徴値フィールド、３０７・・・時間帯フィールド、４００・・・アクセスログ、４０１・・・ファイルフィールド、４０２・・・ユーザフィールド、４０３・・・プログラムフィールド、４０４・・・アクセスタイプフィールド、４０５・・・特徴値フィールド、４０６・・・時刻フィールド、４１１〜４１６・・・理由フィールド、４１７・・・不正フラグフィールド、４１８・・・再診断フラグフィールド、４２０・・・ポリシー照合ログ、４２１・・・ヒット数、１２０１，１２０５・・・不正アクセス再現データ、１２０２〜１２０４，１２０６〜１２０７，ポリシーデータ。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to computer security, and more particularly to a technique for adjusting a policy in file access control on a computer before applying the policy to a real environment.
[0002]
[Prior art]
In order to implement file access control on a computer, for example, in an operating system, a condition (policy) for accessing a file is set for each file, and access control is performed based on the policy. In access control based on such a policy, it is necessary to appropriately set a policy in order to block unauthorized file access. In addition, before the computer is actually operated, it must be sufficiently confirmed that the policy setting is appropriate.
[0003]
Patent Literature 1 discloses a method for improving the understandability and reducing setting errors by referring to and updating the access right after grasping the access right setting status of the entire directory and file. .
[0004]
[Patent Document 1]
JP-A-7-295941
[0005]
[Problems to be solved by the invention]
As described above, access conditions for files are set in the policy. However, if the conditions are excessively severe, such as restricting more than necessary, the access required for the operation of the application may be blocked, and it may not be possible to perform the business using the computer.
[0006]
On the other hand, if the access conditions are excessively loose, such as a shortage of the minimum necessary restrictions, unauthorized access will be allowed, leading to the occurrence of security threats such as information leakage and falsification.
[0007]
Therefore, a policy that is appropriate for a computer can be said to block unnecessary access through access required for the purpose of the computer.
[0008]
It has been difficult in the prior art for the administrator to check in advance whether such excessively strict conditions are included in the set policy or whether the set policy is excessively loose. Further, in the case of a policy including these conditions, it has been difficult to specify a policy that restricts more than necessary and to grasp what the missing policy is.
[0009]
Therefore, a first object of the present invention is to examine whether or not there are excessively strict or excessively loose conditions in a policy before applying the policy to a real environment. A policy diagnosis method that gives information necessary to correct an appropriate policy by specifying where the policy that places more restrictions than necessary and presenting what the missing policy is. To provide.
[0010]
A second object of the present invention is to check whether a policy already applied to a real environment has an excessively strict condition, identify a policy that restricts more than necessary, and determine an appropriate policy. And providing a policy diagnosis method that gives necessary information for correction.
[0011]
[Means for Solving the Problems]
In order to solve the above-mentioned problem, the present invention provides a policy storage means for storing an access control policy, a violation access discrimination by comparing an access generated in a system with the policy, and a violation storage for storing the violation access. It has access storage means, policy analysis means for specifying a setting item of a policy that causes a violation access, and policy display means for displaying the policy, and in which setting item of the policy a violation access occurs A policy diagnosis system is provided in which the result is highlighted on a display area of the policy display means.
[0012]
In addition, an unauthorized access information storage unit for storing known unauthorized access information and a policy for blocking the unauthorized access, and a policy stored in the policy storage unit and the unauthorized access are compared. A policy matching result display means for displaying a result, and for the unauthorized access information determined not to be blocked by the policy, a policy corresponding to the unauthorized access information is displayed on a display area of the policy matching result display means. And a policy diagnosis system characterized in that:
[0013]
Also, of the accesses determined as violation access as a result of collation with the policy in the policy storage means, the access determined by the administrator as a true unauthorized access, and the unauthorized access information stored in the unauthorized access information storage means. From unauthorized access recording means for recording an access which cannot be blocked by the above policy, additional correction policy presenting means for presenting a policy necessary for blocking the above unauthorized access information, and information presented by the additional correction policy presenting means. The unauthorized access recording means for recording unauthorized access that could not be blocked by the modified policy. Policy until there is no unauthorized access recorded by Providing policy diagnosis system and repeating the correction by the policy correcting means.
[0014]
Also, of the accesses determined as a violation access as a result of collation with the policy in the policy storage unit, an access determined by the administrator to be a legitimate access, and an access determined to be a legitimate access as a result of collation with the policy Valid access recording means for recording the authorized access, and additional correction policy presenting means for presenting a setting part of a policy necessary for permitting an access determined by the administrator to be a legitimate access among the above-mentioned violation access. And a policy modifying means for modifying a policy based on the information presented by the additional modified policy presenting means. The valid access recording means further comprises a legitimate access which cannot be permitted by the modified policy. It is recorded, and the administrator is not allowed to record it by the above-mentioned authorized access recording means To date access disappears, the administrator provides the policy diagnosis system and repeating the correction by the policy correction means.
[0015]
Further, the policy display means includes count totalization means for counting the number of accesses that match the policy. In the display area of the policy display means, the count totaled by the count totalization means is counted. Provided is a policy diagnosis system characterized in that it is displayed together with a policy.
[0016]
Further, the information processing apparatus further includes the policy display means and the count totalizing means, and when the count totaled by the count totaling means is 0 in a display area of the policy display means, highlights the count. Provide a characteristic policy diagnosis system.
[0017]
From another viewpoint, the present invention blocks information for reproducing the unauthorized access and blocks the unauthorized access when there is a violation access determined by the administrator to be a true unauthorized access. Means for storing policy information for performing the operation in the unauthorized access storage means.
[0018]
BEST MODE FOR CARRYING OUT THE INVENTION
One embodiment of the present invention will be described with reference to FIGS. 1 to 10 and FIG. FIG. 1 is a diagram showing the overall configuration of a system to which the present invention is applied. 100 is a policy diagnosis module, 110 is an access control module, 120 is policy data, 130 is log data, and 140 is unauthorized access data. The computer 10 includes, as hardware elements, a CPU 11, a memory 12, an external storage device 13 such as a hard disk, a controller 14 for controlling the external storage device 13, an input device 15 such as a keyboard and a mouse, an output device 16 such as a display, It comprises a communication device 17 for communicating with other computers connected to the network 30, a signal line 18 such as a bus, and also comprises an operating system 20, a file system 21, and an application 22 as software elements. The policy diagnosis module 100 and the access control module 110 are processes that are loaded from the external storage device 13 onto the memory 12 and processed on the CPU 11. The policy data 120 and the log data 130 are data permanently stored in the external storage device 13.
[0019]
The access control module 110 exists on the computer 10 as a resident process. The access control module 110 detects that the application 22 accesses a file on the external storage device 13 through the file system 21 and compares the monitoring result with the contents of the policy data 120 to detect an illegal access. . If the access is a violation, the access is blocked and the content of the access is recorded in the log data 130.
[0020]
The policy diagnosis module 100 exists as a process that is started when an administrator issues a start command at an arbitrary timing on the computer 10. The policy diagnosis module 100 determines which setting item in the policy data 120 has caused the violation based on the log data 130 and displays the setting item on the output device 16. Further, the policy diagnosis module 100 receives the input information of the administrator from the input device 15 and also changes the policy data 120.
[0021]
Next, the entire phase of the policy diagnosis will be described with reference to FIG. The operation of the administrator who manages the policy can be classified into a creation phase 210, a test phase 220, and an operation phase 230. First, when the draft policy 231 is created in the creation phase 210, then, in the test phase 220, the user of the computer 10 actually performs the operation assumed in the operation phase 230 described later only once a year, for example. The user is asked to perform all operations including the operation (step 221), and records the violation access that has occurred there (step 222). Based on the information on the violation access, an indication of which setting in the policy caused the violation is displayed. The policy is modified (step 223), and if necessary, the policy is modified, and a recheck after the modification is performed (step 224). After the recheck, the user is requested to use the computer 10 again (step 221).
[0022]
In the test phase 220, since it is considered that no illegal access occurs as long as the computer is operated normally, the number of illegal accesses generated during performing all the operations assumed in the operation phase 230 may be less than a certain value. Then, the test phase is exited, the policy is determined as the completed policy 232, and the process proceeds to the operation phase 230. In the operation phase 230, the policy cannot be modified. However, if it is determined that the policy is not appropriate for the computer 10, for example, if there are too many violating accesses, the completed policy 232 is regarded as requiring maintenance, and the test phase 220 is again executed as indicated by 233. Move and modify the policy.
[0023]
The policy diagnosis of the present embodiment is mainly for supporting the operation of the test phase 220.
[0024]
In the following, an access that does not conform to the access control policy will be referred to as “violating access”, while an unauthorized access performed by a malicious person will be referred to as “illegal access”. “Violated access” may include “illegal access” and operation error, and not all “illegal access” is included in “violating access”. This is because “violating access” is defined depending on the policy, whereas “illegal access” may occur on the computer 10 regardless of the policy.
[0025]
Next, referring to FIG. 3 to FIG. 5 and FIG. 12, a description will be given from the actual use of the computer (step 221) to the recording of the violation access (step 222) in the entire phase shown in FIG. Focusing on the details of the policy, the details of the violation access that occurs when using the computer 10, and the details of the operation of the access control module 110 will be described.
[0026]
FIG. 3 is a diagram showing an example of the structure of the policy data 120. The policy data includes a policy definition table 300. The policy definition table 300 includes a policy ID field 301 having a value for uniquely specifying a record in the table, a file field 302 for storing an absolute path for uniquely specifying a file on the computer 10, and a computer A user field 303 for storing a user ID or a user name for uniquely specifying a user on the computer 10; a program field 304 for storing an absolute path for uniquely specifying an application on the computer 10; An access type field 305 indicating the type of access to the file using the program; a feature value field 306 for storing the file size or hash value of the program; and a time zone field 30 for specifying a time zone during which the program can be accessed. One of the record is composed of a, is a collection of records.
[0027]
For example, in FIG. 3, the policy with the policy ID 301 of “1” can access the file “C: \ document \ secret.doc” because the user “suzuki” has the program “C: \ program @ word” with the characteristic value “0x1234”. .Exe ”means that reading (r) or writing (w) is limited during the time period“ 9:00 to 17:00 ”.
[0028]
The file 302 may be a folder on the computer 10, and the user 303 may be a user group on the computer 10.
[0029]
FIG. 4 is a diagram showing an example of the structure of the log data 130. The log data 130 includes an access log 400 and a policy collation log 420. Further, in the test phase 220 shown in FIG. 2, when one round from step 221 to step 224 is counted as one time, the access log 400 and the policy collation log 420 in what number of tests are performed. 431 and 432 sheets.
[0030]
The access log 400 is a record of all file accesses that have occurred on the computer 10. If the access conforms to the policy defined in the policy definition table 300, a record that sets the invalid flag field 417 to “0” If the access is a violation, it is stored as a record in which the invalid flag field 417 is set to “1”. One record of the access log 400 includes a file field 401 indicating a file to be accessed, a user field 402 indicating who accessed the file, and a program Field 403 indicating the type of access such as read / write / execution, time field 406 indicating the time of access, and feature value field 405 indicating the characteristic value of the program. Be composed.
[0031]
Further, in the case of a violation access, information indicating in which field of the policy the violation access did not match is stored in the reason fields 411 to 416. For example, one violation access 407 is a violation because the program / feature value is different from the policy with the policy ID “1” in the policy definition table 300, and the user with the policy ID “2” is the user and the violation. Violation because the program, access type, and characteristic value are different, and the policy with policy ID "4", which is a policy inherited from the upper folder, violated because the access type is different It is.
[0032]
Further, the access log 400 includes a re-diagnosis flag field 418 for use in re-diagnosis of a policy described later. The policy collation log 420 counts the number of hits of the policy when the file access generated on the computer 10 matches any of the policies in the policy definition table 300 (it will be called a hit). This is a group of records in which a pair of the hit number 421 obtained and the policy ID 301 of the policy is one record.
[0033]
FIG. 12 shows an example of the data structure of the unauthorized access data 140. The unauthorized access data 140 is composed of a plurality of pairs in which a single combination of one unauthorized access reproduction data 1201 and zero or more policy data 1202, 1203, and 1204 constitutes one pair. Is done. For example, two policies 1206 and 1207 correspond to the unauthorized access reproduction data 1205.
[0034]
For example, in the unauthorized access data 140, the behavior of a computer virus or Trojan is stored as the unauthorized access reproduction data 1201 and 1205. Behavior that attempts to rewrite DLL files in the System folder that are not normally supposed to be rewritten, and behavior that attempts to write programs to the startup folder in order to run illegal programs at the same time as the computer starts up Are stored as the unauthorized access reproduction data 1201 and 1205.
[0035]
Next, a flowchart showing processing executed by the access control module 110 will be described with reference to FIG. When the user executes the application 22 while using the computer 10, a file access occurs. For example, when starting word processing software, a document file is opened. The access control module 110 monitors such file access (step 501),
Information on the file access,
File = (absolute path of file)
User = (user ID or user name)
Program = (absolute path of program)
Access type = (type of access type)
Feature value = (feature value of the above program)
Time = (system time)
Are collected (step 502).
[0036]
Next, it is checked whether or not the file in the collected file access information matches the file field 302 of the policy definition table 300, and whether or not the file field 302 is an upper folder of the file (see FIG. 4). Step 503). If they do not match in step 503, the file access is forwarded to the file system 21 and access is permitted (step 507).
[0037]
On the other hand, if the file access is found to match at step 503, the file access is checked against each record of the policy in the policy definition table 300 (step 504). If so, the file access information is recorded in the fields 401 to 406 in the access log 400, and the value of the illegal flag field 417 is recorded as "0" and the value of the re-diagnosis flag field 418 is recorded as "1". Then, the value of the hit number 421 of the policy collation log 420 corresponding to the matched policy is incremented (step 506), and the file access is forwarded to the file system 21.
[0038]
On the other hand, if the record does not match any record of the policy in step 504, the contents of the file access are recorded in the violation access log 400 in the fields 401 to 406, and the value of the illegal flag field 417 is set to "1". "And the value of the re-diagnosis flag field 418 are recorded as" 0 "(step 508), and an error indicating that access to the file is prohibited is notified to the program which is the source of the access (step 509). . When the above processing is completed, the process returns to step 501 again.
[0039]
Here, when the file access violates the policy, in order to prevent the application 22 from causing an unexpected problem due to the prohibition of the file access, a log indicating that the access is a violation is performed, and then the file access is performed. May be permitted.
[0040]
Subsequently, the policy diagnosis module will be described with reference to FIGS. 6 to 10, focusing on the description from the review of the policy (step 223) to the modification of the policy (step 224) in the overall phase shown in FIG. 100 will be described in detail.
[0041]
FIG. 6 shows an example of a screen displayed on the output device 16 when the administrator starts the policy diagnosis module 100. The policy diagnosis screen 600 includes a 601 indicating the number of the test phase 220 in FIG. 2 and a region 610 indicating a list of violation accesses that have occurred on the computer 10. Next, a list of policies for the file to be accessed by the violation access shown in 620, which is uniquely determined when one violation access is selected from the pull-down menu 611 in the area 610, and other information shown in 630 And a list of policies. This display method will be described with reference to FIG.
[0042]
FIG. 7 shows a flowchart for displaying the policy diagnosis screen 600. First, when the display of the policy diagnosis screen 600 is started, a record in which the re-diagnosis flag field 418 of the violation access log 400 shown in FIG. 4 is “0” is searched, and a list of records as a search result is displayed in the area of FIG. 610. Here, when the administrator turns on the check box 417 shown in FIG. 6, the value of the fraud flag field 417 shown in FIG. 4 becomes "2", and when the check box is turned off, the value becomes "1". (Step 701).
[0043]
Next, when the administrator selects one violation access from the area 610 (step 702), a loop process for sequentially referring to policy records in the policy definition table 300 is started. Here, the violation access selected by the administrator is called A, and one policy during loop processing is called P. If the policy P is included in the reason fields 411 to 416 corresponding to the violation access A (step 703), the policy P is shown in FIG. 6 as a policy for the file to be accessed for the violation access. It is displayed in the area 620 (step 704).
[0044]
At this time, corresponding to the reason fields 411 to 416, highlighting is performed as shown at 622 in FIG. 6 (step 705). Further, the value in the hit number field 421 of the policy collation log 420 corresponding to the policy P is displayed as shown at 421 in FIG. 6, and if the value of the hit number 421 is “0”, it is changed to 623. It is highlighted as shown (step 707).
[0045]
In step 703, if not included, the policy P is displayed in the other policy list area 630 shown in FIG. 6 (step 706). At this time, if the value of the hit number 421 corresponding to the policy P is “0”, the highlight is displayed as shown by 631 in FIG. 6 (step 707).
[0046]
For example, the display example in FIG. 6 is a case where the administrator selects the violation access 407 in the violation access log 400. The administrator performs a policy diagnosis and a policy correction as described below while referring to FIG. I can go. First, looking at a list 620 of policies related to the file that has been accessed for the violation access, the policies whose policy IDs 301 in the policy definition table 300 are "1,""2," and "4" correspond to each other. Further, the field of the cause of the violation can be known as shown at 622 for each policy.
[0047]
If the administrator determines that there is a cause in the highlighted portion as shown at 622, the user clicks the policy causing the cause with the mouse to select the policy and presses the policy update button 653. Thus, a screen 800 shown in FIG. 8 for editing the policy can be called. Further, looking at the number of hits 421, it can be seen that the policy with the policy ID “1” has not yet been hit, and therefore, the program field of the policy with the policy ID “1” may have a setting error. In addition, there is a possibility that “C: \ program \ word.exe” may remain as an application that has not been executed when actually using the computer in step 221 shown in FIG. Suggests.
[0048]
Looking at the other policy list 630, it can be seen that the policy whose policy ID 301 is "3" has never been hit. Further, if the administrator judges that the illegal access 407 is a true unauthorized access, the illegal access can be marked with a check box 417 shown in FIG. If the administrator determines that the violation access 407 is actually an access that should be permitted by a policy, the user presses a new policy addition button 652 to call up a screen 800 shown in FIG. 8 and add a new policy. Or if the user presses a button 651 for adding a violation access to a policy, a screen 800 shown in FIG. 8 in which a draft of a policy permitting the violation access 407 is input in advance is called, and the violation access 407 is set. Correct and set the base policy as appropriate.
[0049]
Further, when the administrator determines that the value of the characteristic value 405 is not specified by the policy due to an upgrade of the application or the like, the user can press the batch update button 654 to collectively set the policy setting relating to the value of the characteristic value 405. Then, a screen 810 shown in FIG. 8 that can be executed is called.
[0050]
In FIG. 6, a button 651 for adding a violation access to a policy or a new policy addition button 652 is pressed, or a policy displayed in the area 620 and the area 630 is clicked to select the policy, and a policy update button is clicked. FIG. 8 shows a policy setting screen 800 displayed when the user presses the button 653. On the policy setting screen 800, in order to add or update a record in the policy definition table 300, the absolute path of the file 302, the user ID or user name of the user 303, the absolute path of the program 304, and the access type 305 A type, a time period 307, and a feature value 306 of the program are input. When the administrator presses an OK button 801, the information of the input policy is stored in the policy definition table 300. , The policy setting screen 800 is closed.
[0051]
Alternatively, by pressing the delete button 802, the record of the displayed policy indicating that the administrator has clicked and selected the policy is deleted from the policy definition table 300. Alternatively, by pressing the cancel button 803, the policy setting screen 800 is closed without storing the input policy in the policy definition table 300. Alternatively, by pressing the apply button 803, the input policy is stored in the policy definition table 300, and the policy setting screen 800 is kept open.
[0052]
Here, like the highlighting indicated by 622 in FIG. 8, the highlighting of 622 indicating the setting item of the policy that caused the violation access in FIG. 6 is also taken over in FIG.
[0053]
FIG. 8 shows a policy batch update screen 810 displayed when the batch update button 654 in FIG. 6 is pressed. On the policy batch update screen 810, one of radio buttons 811 to 814 can be selected for an update method. For example, when 811 is selected, a policy having a file designated by the administrator as 815 is selected. Can be collectively updated to the absolute path specified by 816.
[0054]
When the “re-diagnosis” button 655 in FIG. 6 is pressed, the screen transits to the policy re-diagnosis screen 900 shown in FIG. In the policy re-diagnosis screen 900, after the administrator corrects the policy on all the violation accesses on the policy diagnosis screen 600 shown in FIG. 6, the re-check is performed to determine whether the policy has been appropriately corrected. The processing is performed according to the flowchart shown in FIG. The policy re-diagnosis screen 900 shows an area 910 indicating a result of simulating a known unauthorized access stored in the unauthorized access data 140, and a screen determined by the administrator from the violation access as a true unauthorized access. The area 920 shows the result of simulating the access, the area 930 shows the result of simulating the illegal access other than the illegal access, and the area 940 shows the result of the simulated adaptive access generated in the system. And an area.
[0055]
When the display of the policy re-diagnosis screen 900 is started, the unauthorized access data 140 shown in FIG. 12 is searched, and all unauthorized access reproduction data 1201 and 1205 are obtained (step 1001). Next, the unauthorized access reproduction data is compared with a policy (step 1002), and if permitted, a policy for blocking the unauthorized access reproduction data beside the portion where the unauthorized access data is displayed in the area 910. Is displayed, and the result of permission is highlighted in the simulation result field 901 as shown by 912 (step 1004). If it is prohibited, the result of the prohibition is displayed in the simulation result field 901 without displaying the policy setting button 911 right next to the portion displaying the unauthorized access reproduction data (step 1004). The processing from step 1002 to step 1004 is performed for all the unauthorized access reproduction data in the unauthorized access data 140 acquired in step 1001.
[0056]
When the administrator presses the policy setting button 911, the contents of the policies 1202 to 1204 shown in FIG. 12 are displayed by calling the policy setting screen 800 shown in FIG. 8 a plurality of times. As a result, the administrator can perform additional policy setting for known unauthorized access that cannot be prevented by the policy.
[0057]
Next, the access log 400 shown in FIG. 4 is searched for a record in which the value of the illegal flag field 417 is "2" (step 1006). When the value of the illegal flag field 417 is "2", the administrator determines that the illegal access is an illegal access even among the violation accesses that occurred on the computer. The illegal access is checked against the policy (Step 1006). If the access is permitted, the value of the re-diagnosis flag field 418 in the record of the unauthorized access is updated to “0” (Step 1007), and the simulation result field 901 is permitted. Is highlighted as shown in 922 (step 1009). If prohibited, the value of the re-diagnosis flag field 418 is updated to "1" (step 1008), and the result of prohibition is displayed in the simulation result field 901. (Step 1008). The processing from step 1006 to step 1009 is performed for all the records retrieved in step 1005.
[0058]
Further, the access log 400 is searched for a record in which the value of the illegal flag field 417 is "1" (step 1010), and is compared with a policy (step 1011). In this case, since the illegal access is not an unauthorized access, it is assumed that the access is permitted. Therefore, if the result of the policy comparison is prohibited, the value of the re-diagnosis field 418 is updated to “0”, the simulation result field 901 is highlighted as shown by 931 (step 1012), and the result of the policy comparison is permitted. If so, the value is updated to "1" (step 1013), and the result of prohibition or permission is displayed in the simulation result field 901 (step 1014). The processing from step 1011 to step 1014 is performed for all the records retrieved in step 1010.
[0059]
Lastly, the access log 400 is searched for a record in which the value of the illegal flag field 417 is "0" (step 1015), and is compared with a policy (step 1016). If the access is prohibited, it is found that the access that is once conforming access has been prohibited by modifying the policy, and the value of the re-diagnosis flag field 418 is updated to “0”. The simulation result field 901 is highlighted as indicated by 941 (step 1017), and if the permission is granted, the value is updated to "1" (step 1018), and the result of the prohibition or permission is displayed in the simulation result field 901. . The processing from step 1016 to step 1019 is performed for all the records retrieved in step 1015.
[0060]
Thus, the display of the policy re-diagnosis screen 900 is completed.
[0061]
Here, if the administrator presses the “Add to DB” button 921, all “Unauthorized access during violation access that has occurred in the system” 920 is stored in the unauthorized access data 140. At this time, the input of the policy setting for blocking the unauthorized access is performed by calling the same screen as the policy setting screen 800 shown in FIG. 8 a plurality of times.
[0062]
Further, in FIG. 9, the administrator refers to the policy re-diagnosis screen 900 to find out that the access is permitted even if the access is unauthorized or that the access is prohibited even if the access is normal, and it is necessary to further modify the policy. If the administrator determines, the policy diagnosis and correction are performed again on the policy diagnosis screen 600 shown in FIG. At this time, the record in which the value of the re-diagnosis flag field 418 in the access log 400 shown in FIG. 4 is “0” is to be reviewed again.
[0063]
In FIG. 9, when the administrator confirms that the policy modification has been completed, and determines that the test phase 220 shown in FIG. 2 is to be further performed, such as when there is an application that has not been operated on the computer 10. The user may press a “start third test” button 903. At this time, in the sheets 431 and 432 shown in FIG. 4, a new “third test” sheet is added, and the test phase 220 is executed from a state where the access log 400 and the number of hits 421 are reset. .
[0064]
Further, in FIG. 9, it is within the allowable range of the administrator that the unauthorized access is permitted or the normal access is prohibited within the allowable range of the administrator, and the administrator determines that there is no need to perform the test phase 220 any more. If so, the “end test phase” button 904 may be pressed. Thus, the policy re-diagnosis screen 900 is closed.
[0065]
As described above, according to the first embodiment of the present invention, before the policy is applied to the real environment, the user is allowed to use the computer for all possible uses, and the violation access that has occurred on the computer is recorded. In advance, by specifying the setting items of the policy that caused the above-mentioned violation access, the setting items in the above-mentioned policy that caused the violation access are highlighted in the display area indicating the above-mentioned policy. Can provide the information needed to make the appropriate policy changes.
[0066]
Also, simulate known unauthorized access to confirm that the policy enforces the necessary restrictions, and if the restrictions are insufficient, present a draft policy to prevent the above unauthorized access This can provide the information needed to revise the policy.
[0067]
This satisfies the first purpose.
[0068]
Next, a second embodiment of the present invention will be described. In the second embodiment, when there are excessively severe conditions in the policy already applied to the real environment in the operation phase 230 shown in FIG. This is used to modify the policy to an appropriate one if it is found that it cannot operate when used.
[0069]
The system configuration in the second embodiment is the same as that shown in FIG. 1, and for the sake of distinction, the policy data in the first embodiment is 120a, the log data is 130a, the unauthorized access data is 140a, In the embodiment, the policy data is 120b, the log data is 130b, and the unauthorized access data is 140b.
[0070]
In the operation phase 230, access control is applied to a file on the computer 10 under the policy data 120b, and a violation access generated on the computer 10 is recorded in the log data 130b. In the operation phase 230, when the administrator determines that the policy should be maintained, for example, by notifying the administrator that there is an application that the user of the computer 10 cannot operate, the administrator determines the policy diagnosis module shown in FIG. Start 100. At this time, the policy data 120b and the log data 130b are passed to the test phase 220 in the path 233 shown in FIG. Here, in the test phase 220, steps 221 and 222 are skipped, and the process proceeds to step 223.
[0071]
The policy diagnosis module 100 operates according to the flowchart shown in FIG. 7 based on the policy data 120b and the log data 130b, and displays the policy diagnosis screen 600 shown in FIG. At this time, the administrator diagnoses and corrects the policy in the same manner as in step 223 shown in FIG. 2 in the first embodiment, and displays the policy re-diagnosis screen 900 shown in FIG. 9 in the same manner as in step 224 in the first embodiment. Recall the policy by calling it. Here, when the policy re-diagnosis screen 900 is called, the display of the area 910, that is, the comparison with the known unauthorized access in the unauthorized access data 140b is performed, and the result is displayed.
[0072]
The administrator can easily specify the setting position of the policy that caused the violation access through the operations in the above steps 223 and 224, make a correction to an appropriate policy, and make an appropriate correction. Can be confirmed. When the above-mentioned operation of the administrator is completed, the modified policy data 120b is transferred to the operation phase 230 again as the completed policy 232 shown in FIG.
[0073]
Next, a third embodiment of the present invention will be described with reference to FIG. The computer 10 is a plurality of computers having the system configuration shown in FIG. 1 and connected to the network 30, a policy distribution server 120 having a master policy, and a computer 100 remotely running on the computer 10 via the network. Is a policy diagnosis console for diagnosing the above policy, and 140 is an unauthorized access DB for intensively storing information on unauthorized access that has occurred on the computer 10. The policy distribution server 120 holds a draft policy 231 referred to in the overall phase of FIG. 2 and uniformly distributes the draft policy 231 to each computer 10 via a network. Next, the policy diagnosis console 100 allows the administrator to implement the test phase of FIG. 2 remotely via the network 30 while using each computer 10 by the user. The unauthorized access DB 140 is for centrally storing information for reproducing the unauthorized access when an unauthorized access occurs on each computer 10, and based on the reproduced data, the unauthorized access on each computer 10 is performed. Access simulation can be performed.
[0074]
The administrator can perform the policy diagnosis remotely via the network without going to the terminal of each computer 10 and secure the scalability of the policy distribution and the policy diagnosis even when the number of computers 10 increases. be able to. Further, when an unauthorized access occurs on any of the computers 10, the information of the unauthorized access can be shared between the computers 10, and know-how for measures can be accumulated.
[0075]
As described above, before applying the policy to the real environment, have the user use the computer for all possible uses, record the violation access that occurred on the computer, and record the cause of the violation access. It is necessary to identify the setting items of the policy that is to be changed, and to highlight the setting item in the above policy where the violation access occurred on the display area indicating the policy, so that it can be corrected to the appropriate policy Information can be provided. As a result, the administrator can easily identify a portion where the policy is excessively set, and can start an appropriate correction.
[0076]
Also, by simulating known unauthorized access, confirm that the policy has the necessary restrictions, and if the restrictions are insufficient, submit a draft policy to prevent the unauthorized access. This can provide the information needed to revise the policy. As a result, the administrator can notice that there is a shortage in the policy, and can start an appropriate correction.
[0077]
Also, in the policies that have already been applied to the real environment, the violation access that occurred in the above policy is recorded, the policy setting location that caused the violation access is specified, and where in the above policy, By highlighting whether access has occurred on the display area indicating the policy, it is possible to provide information necessary for correcting the policy to an appropriate one. As a result, the administrator can easily identify the portion of the policy that has already been applied to the real environment, and can start an appropriate modification.
[0078]
【The invention's effect】
According to the present invention, it is possible to provide a policy diagnosis method that gives information necessary for correcting an appropriate policy.
[Brief description of the drawings]
FIG. 1 is an overall block diagram of a policy diagnosis system.
FIG. 2 is a diagram showing an entire phase of a policy diagnosis.
FIG. 3 is a data configuration diagram of policy data.
FIG. 4 is a data configuration diagram of log data.
FIG. 5 is a flowchart showing the operation of the access control module.
FIG. 6 is an example of a policy diagnosis screen of the policy diagnosis module.
FIG. 7 is a flowchart showing an operation of the policy diagnosis module for displaying a policy diagnosis screen.
FIG. 8 is an example of a policy setting screen and a policy batch update screen of the policy diagnosis module.
FIG. 9 is an example of a policy re-diagnosis screen of the policy diagnosis module.
FIG. 10 is a flowchart showing an operation of the policy diagnosis module for displaying a policy re-diagnosis screen.
FIG. 11 is a network configuration diagram in the second embodiment.
FIG. 12 is a data configuration diagram of unauthorized access data.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 10 ... Computer, 11 ... CPU, 12 ... Memory, 13 ... External storage device, 14 ... Controller, 15 ... Input device, 16 ... Output device, 17 ... Communication device, 18 bus, 20 OS, 21 file system, 22 application, 30 network, 100 policy diagnosis module, 110 access control module 120: policy data, 130: log data, 140: unauthorized access data, 210: creation phase, 220: test phase, 230: operation phase, 300: policy definition table , 301: Policy ID field, 302: File field, 303: User field, 304: Program file , Access type field, 306, feature value field, 307, time zone field, 400, access log, 401, file field, 402, user field, 403,. Program field, 404 access type field, 405 feature value field, 406 time field, 411 to 416 reason field, 417 illegal flag field, 418 re-diagnosis Flag field, 420: policy collation log, 421: number of hits, 1201, 1205: unauthorized access reproduction data, 1202 to 1204, 1206 to 1207, policy data.
