以下,本実施の形態について,図を用いて説明する。
本実施の形態では,特に送信するのに承認者による承認が必要となる電子メールを抽出する技術を例に,チェックの対象となるデータの抽出に適用するルールを調整する技術を説明する。なお,以下では,電子メールを単にメールとも呼ぶ。
図1は,本実施の形態によるメールシステムの構成例を示す図である。
図1に示すメールシステムは,会社などの組織におけるメールシステムの例である。
図1に示すメールシステムにおいて,メールフィルタ装置1は,各ユーザ端末2から組織の外部への送信が要求されたメールのフィルタリングを行うコンピュータである。メールフィルタ装置1は,ユーザ端末2,承認者端末3,管理用端末4と,組織内のLAN5で接続されている。また,メールフィルタ装置1は,DBサーバ6,メールサーバ7と接続されている。以下では,ユーザ端末2の操作者から送信が要求されたメールを,送信メールとも呼ぶ。
ユーザ端末2は,組織の従業者が操作するコンピュータである。以下では,ユーザ端末2を使用する組織の従業者を,ユーザとも呼ぶ。
承認者端末3は,組織の外部に送信されるメールの承認を行う承認者が使用するコンピュータである。承認者端末3が,同時にユーザ端末2であってもよい。また,承認者が,組織の従業者であってもよい。承認者は,例えば,組織内の部門ごとの管理職などである。
管理用端末4は,メールフィルタ装置1の設定等を行う,メールシステムの管理者が使用するコンピュータである。管理用端末4が,同時にユーザ端末2や承認者端末3であってもよい。また,管理者が,組織の従業者や承認者であってもよい。
DBサーバ6は,メールシステムを利用するすべてのユーザによって送信が要求されたメールのコピーを保存するコンピュータである。
メールサーバ7は,メールの送受信を管理するコンピュータである。メールサーバ7は,インターネット8に接続されている。
ユーザ端末2から送信が要求されたメールは,その内容がメールフィルタ装置1で分析される。メールフィルタ装置1は,外部に送信されるメールの内容を分析し,あらかじめ設定されたルールに合致する電子メールの送信を保留する。承認者は,承認者端末3を用いて保留された承認対象のメールの内容を確認し,承認するか否かを判断する。承認者により承認されたメールは,メールサーバ7によって,組織の外部すなわちインターネット8に送信される。メールフィルタ装置1に入力されたすべての送信メールは,そのコピーがDBサーバ6に保存される。
なお,本実施の形態では,外部に送信するメールのみのフィルタリングを行うものとする。実際には,内部のユーザ端末2間でやり取りされるメールのフィルタリングも,同様に行うようにしてもよい。
また,メールシステムは,Webメーラのシステムであってもよい。例えばWebメールを管理する装置をLAN5とメールフィルタ装置1との間に配置すれば,Webメーラのシステムが実現可能である。
また,本実施の形態では,メールフィルタ装置1,DBサーバ6,メールサーバ7が,それぞれ別のコンピュータで実現されているが,それらを1台のコンピュータで実現するなどは,任意である。
図2は,メールのフィルタリングを説明する図である。
図2(A)は,送信メールをフィルタリングするルールの例を示す。メールフィルタ装置1は,図2(A)に示すような,あらかじめ設定されたルールに基づいて,送信メールのフィルタリングを行う。
図2(A)において,ルール番号は,ルールを識別する番号である。
図2(A)において,ルール内容は,設定されたルールの内容を示す。ルール内容には,条件とアクションとが含まれ,条件に該当するメールに対するアクションが設定されている。例えば,ルール1の「添付ファイル付きだったら保留」というルールは,「添付ファイル付き」という条件に該当するメールに対するアクションが「保留」であることを意味している。「保留」は,承認者によって承認がなされるまで,そのメールの送信を保留しておくことを意味している。
図2(A)において,優先度は,どのルールを優先するかを示す。図2(A)の例では,優先度は優先順位によって表されており,数値が低いルールほど優先度が高くなっている。
なお,アクションとしては,「保留」以外にも,自動的にメールの削除を行う「破棄」や,メールの送信が行われたことを承認者に通知する「通知」など,様々なものが考えられる。ここでは,説明を簡単にするために,図2(A)に示すアクションとして「保留」のみが設定されたルールの例について,説明する。
図2(B)は,適用するルールを調整するイメージを示す。図2(B)では,図2(A)に示すルールの条件が,優先度が高い順に上から並べられて記載されている。
図2(B)において,太線は,メールのフィルタリングに適用されるルールと,メールのフィルタリングに適用されないルールとの境界を示す。ここでは,太線より上のルールが適用されるルールとなり,太線から下のルールが適用されないルールとなるものとする。図2(B)に示す例では,太線より上のルール1とルール2とが適用となり,太線より下のルール3とルール4とが不適用となる。
図2(B)において,太線の位置を下げると,すなわち適用するルールを増やすと,全体としてルールが厳しくなるため,セキュリティ効果が高くなる。しかし,図2(A)に示すルールで指定されたアクションは,すべて「保留」であるので,適用するルールが増えれば増えるほど,承認が必要となるメールの数が多くなる。そのため,承認者の負荷が大きくなったり,メールの返信が遅れたりするなどの問題が多く発生するようになり,システム運用が難しくなる。
図2(B)において,太線の位置を上げると,すなわち適用するルールを減らすと,承認が必要となるメールの数が少なくなるため,システムの運用が簡単になる。しかし,全体としてルールが緩くなるため,セキュリティ効果が低くなる。
メールシステムの管理者は,セキュリティ面とシステムの運用面とのバランスを考慮しながら,複数のルールを組み合わせて設定し,検証する。
管理者はシステムの導入時に最初のルール設定を行わなければならないが,このルール設定の作業は,煩雑かつ複雑である。セキュリティポリシ,承認者,送信メールの内容などがシステムを導入する企業によって異なるため,あらかじめデフォルトの設定を行って対応することも困難である。
また,管理者は,システムの運用開始後も,メールフィルタ装置1によってブロックされたメール・ブロックされないメールを監査し,フィルタリングのルールを最適化していく必要がある。
このように,管理者は,とりあえずルールを設定→運用→ルールを修正→運用→ルールを修正→... ,という煩雑な作業を繰り返さなければならない。
以下では,管理者によるルール設定やルール修正の作業の煩雑さを軽減しつつ,セキュリティ面とシステムの運用面とのバランス考慮して,適用するルールを適切に調整することが可能となる技術の例を説明する。
図3は,本実施の形態によるメールフィルタ装置の構成例を示す図である。
図3の例に示すメールフィルタ装置1は,適用ルールを調整する機能と,適用ルールを用いて送信メールのフィルタリングを行う機能とを有する。
メールフィルタ装置1は,ルール情報記憶部10,承認可能数情報記憶部11,ユーザ情報記憶部12,メール件数集計部13,メール集計情報記憶部14,ルール設定部15,メール受信部16,メール抽出部17,承認対象メール記憶部18,メール転送部19,承認処理部110,承認情報記憶部111,承認可能数算出部112を備える。メールフィルタ装置1およびメールフィルタ装置1が備える各機能部は,コンピュータが備えるCPU,メモリ等のハードウェアとソフトウェアプログラムとにより実現される。
適用ルールを調整する機能は,主に,ルール情報記憶部10,承認可能数情報記憶部11,ユーザ情報記憶部12,メール件数集計部13,メール集計情報記憶部14,ルール設定部15,承認情報記憶部111,承認可能数算出部112等により,実現される。適用ルールの調整は,例えば,新たなメールシステムの導入設定時やメンテナンス時などに行われる。また,メールシステムの運用中などにも,定期的な適用ルールの自動調整が行われる。
適用ルールを用いて送信メールのフィルタリングを行う機能は,主に,ルール情報記憶部10,メール受信部16,メール抽出部17,承認対象メール記憶部18,メール転送部19,承認処理部110,等により実現される。
また,DBサーバ6は,メール記憶部61を備える。DBサーバ6およびDBサーバ6が備える各機能部は,コンピュータが備えるCPU,メモリ等のハードウェアとソフトウェアプログラムとにより実現される。
ルール情報記憶部10は,管理者により登録されたルールに関する情報を記憶する,コンピュータがアクセス可能な記憶装置である。
ルールの登録は,例えば,管理用端末4でメールフィルタ装置1にアクセスすることにより行われる。管理者によるルール登録開始の操作を受けると,管理用端末4は,メールフィルタ装置1にアクセスし,管理用端末4の表示装置にルール登録画面を表示する。
図4は,本実施の形態によるルール登録画面の例を示す図である。
管理者は,管理用端末4を用いてメールフィルタ装置1にアクセスする。このとき,管理用端末4の表示装置には,例えば図4に示すようなルール登録画面が表示される。管理者は,図4に示すようなルール登録画面から,組織のセキュリティポリシに応じて必要と考えられる,送信メールをフィルタリングするためのルールを,すべて入力する。
図4に示すルール登録画面において,ルール名の欄は,登録するルールの名称を入力する欄である。条件の欄は,抽出する送信メールの条件を入力する欄である。条件の欄には,すべて一致(AND)/いずれか一致(OR)を指定して,複数の条件を入力することもできる。アクションの欄は,条件を満たす送信メールに対して行う処理を入力する欄である。本実施の形態では,条件を満たす送信メールに対して行う処理をアクションと呼ぶ。ルール名,条件,アクション等が入力され,登録ボタンが押下されると,入力されたルールが登録される。
図4に示すルール登録画面から登録されたルールは,メールフィルタ装置1において,ルール情報記憶部10に記憶される。
図5は,本実施の形態によるルールデータの例を示す図である。
図5に示すルールデータ201は,送信メールのフィルタリングを行うために登録されたルールを管理するためのデータとして,ルール情報記憶部10に記憶されている。管理者により登録されたルールは,ルールデータ201に記録される。
図5に示すルールデータ201において,ルールIDは,各ルールを一意に識別するための識別情報である。
図5に示すルールデータ201において,ルール名は,登録されたそのルールの名称である。例えば,管理用端末4にルールの一覧が表示される場合などには,ルール名で提示される。
図5に示すルールデータ201において,優先度は,そのルールが優先的に適用される度合いを示す。すなわち,登録されたルールをすべて適用できないような場合には,優先度が高いルールが優先的に適用され,優先度が低いルールは適用されないこともある。なお,図5に示すルールデータ201における優先度は,優先順位で示されている。すなわち,図5に示すルールデータ201では,優先度の値が小さいルールほど優先度が高く,優先度の値が大きいルールほど優先度が低くなる。
優先度は,例えば,管理用端末4にルールの一覧が提示され,管理者によって優先度が高い順にルールが並べ替えられるなどにより指定される。また,図4に示すルール登録画面に優先度を入力する欄を設けて,そこで優先度を指定させるようにしてもよい。
図6は,本実施の形態によるルールリストの例を示す図である。
例えば,管理用端末4は,管理者によるルールの登録がひと通り終了した後,図6に示すような登録されたルールのリストを,表示画面に提示する。ここでは,当初,管理者によって入力された順番に優先順位が付けられて,登録されたルールのルール名が提示されるものとする。管理者は,マウスのドラッグなどにより,表示画面に提示されたルールリスト上で,優先したい順にルールを並べ替えることができる。
図5に示すルールデータ201において,条件は,そのルールでどのような送信メールが抽出されるかを示す。例えば,図5に示すルールデータ201におけるルールID“rule001 ”のルールの条件“添付ファイルが付いている”によって,添付ファイル付きの送信メールが抽出される。また,例えば,図5に示すルールデータ201におけるルールID“rule002 ”のルールの条件“宛先がフリーメールアドレスである”によって,フリーメールアドレス宛ての送信メールが抽出される。
なお,図5に示すルールデータ201では,条件が管理者による登録時に条件欄に入力された文で記録されているが,条件が送信メールをフィルタリングするプログラムが解釈する条件式で記録されていてもよい。例えば,図5に示すルールデータ201におけるルールID“rule001 ”の条件文“添付ファイルが付いている”が,所定の条件式“if(attach==true)”で記録されていてもよい。また,例えば,図5に示すルールデータ201におけるルールID“rule002 ”の条件文“宛先がフリーメールアドレスである”が,所定の条件式“if(to _domain==free_address)”で記録されていてもよい。
図5に示すルールデータ201において,アクションは,そのルールの条件に合致する送信メールに対して行う処理を示す。例えば,図5に示すルールデータ201におけるルールID“rule001 ”のルールのアクションは,“保留”となっている。“保留”は,条件に合致するメールに対して,承認者によって承認の作業が行われるまで,送信せずに一時保管する処理を示すアクションである。
なお,図5に示すルールデータ201では,アクションとして“保留”のみが指定されている。“保留”以外にも,“破棄”,“通知”,“事後監査リストに登録”など,様々なアクションの指定が可能である。“破棄”は,条件に合致する送信メールに対して,承認なしに自動的に削除する処理を示すアクションである。“通知”は,条件に合致する送信メールに対して,送信し,送信した旨を承認者に通知する処理を示すアクションである。“事後監査リストに登録”は,条件に合致する送信メールに対して,送信し,送信した旨を事後監査用に作成されるリストに記録する処理を示すアクションである。
なお,図5に示すルールデータ201では,アクションが管理者による登録時に条件欄に入力された文で記録されているが,アクションが送信メールをフィルタリングするプログラムが解釈する式で記録されていてもよい。例えば,図5に示すルールデータ201におけるルールID“rule001 ”のアクション文“保留”が,所定のアクション式“{hold()}”で記録されていてもよい。
また,条件とアクションとを合わせたルールの式として,ルールがルールデータに記録されていてもよい。例えば,図5に示すルールデータ201におけるルールID“rule001 ”のルールについて,条件とアクションとを合わせた所定のルール式“if(attach==true){hold()}”で記録されていてもよい。
図5に示すルールデータ201において,適用フラグは,そのルールが送信メールのフィルタリングに適用されるか否かを示すフラグである。“ON”は適用されることを示し,“OFF”は適用されないことを示す。メールシステムの運用状況によっては,登録されたすべてのルールが適用できない場合もある。
なお,適用するルールの調整を,組織の部門ごとや日付ごとなどに行う場合には,組織の部門ごと,日付ごとの適用フラグが用意される。
図5に示すルールデータ201において,一時アクションは,そのルールが適用されなかった場合に,そのルールで指定された条件に合致する送信メールに対して,アクションで指定された処理の代わりに行う処理を示す。一時アクションは,適用されないルールに対して,所定のアクションが定義される。一時アクションとしては,例えば,“通知”,“事後監査リストに登録”などの,メールシステム運用面での負荷が小さいアクションが定義される。
例えば,メールシステムの運用面での問題から,図5に示すルールデータ201におい,ルールID“rule003 ”と“rule004 ”とのルールが,適用されないものとする。このとき,ルールID“rule003 ”と“rule004 ”とのルールに対して一時アクションが定義されなければ,承認者や管理者は,それらのルールに該当する送信メールがどのくらい送信されたかを知ることができない。ルールID“rule003 ”と“rule004 ”とのルールに対して一時アクション“通知”が定義されれば,承認者は,それらのルールに該当する送信メールがどのくらい送信されたかを通知により知ることができる。また,ルールID“rule003 ”と“rule004 ”とのルールに対して一時アクション“事後監査リストに登録”が定義されれば,それらのルールに該当する送信メールがどのくらい送信されたかを,承認者や管理者などが事後監査時に確認することができる。
このように,一時アクションを定義することにより,メールシステムの運用上適用されなかったルールに該当する送信メールがどれぐらい送信されたか,そのメールの内容がどのようであったかなどの情報の確認や調査が容易になる。
なお,一時アクションは,常時定義されるものでなくてもよい。例えば,メールフィルタ装置1が,一時アクションを定義するか否かの設定を保持する機能を持ち,管理者が管理用端末4を用いてその設定を変更できるようにする。このようにすれば,必要に応じた一時アクションを定義する/定義しないの変更が可能となる。
図3において,承認可能数情報記憶部11は,メールシステムの運用面に関する情報を記憶する,コンピュータがアクセス可能な記憶装置である。
本実施の形態では,メールシステムの運用面における情報として,承認の作業を行う単位ごとの承認可能なメール数の情報が,承認可能数情報記憶部11に記憶される。ここでは,承認の作業を行う単位ごとの承認可能なメール数を,承認可能数と呼ぶ。また,承認の作業を行う単位を,承認作業単位と呼ぶ。承認作業単位は,承認者単位,組織の部門単位など,任意である。
承認可能数に関する情報の設定は,例えば,管理用端末4でメールフィルタ装置1にアクセスすることにより行われる。管理者による承認可能数の設定開始の操作を受けると,管理用端末4は,メールフィルタ装置1にアクセスし,管理用端末4の表示装置に承認可能数情報入力画面を表示する。
図7は,本実施の形態による承認可能数情報入力画面の例を示す図である。
管理者は,管理用端末4を用いてメールフィルタ装置1にアクセスする。このとき,管理用端末4の表示装置には,例えば図7(A)〜(C)に示すような承認可能数情報入力画面が表示される。管理者は,図7(A)〜(C)に示すような承認可能数情報入力画面から,承認可能数を入力する。入力する承認可能数は,例えば,承認作業単位ごとの実績などから求められたものであってもよいし,承認者や管理者等により予測されたものであってもよい。
なお,図7(A)〜(C)に示す承認可能数情報入力画面の例では,承認作業単位は,承認者単位であるものとする。組織内の複数の部門が存在する場合に,承認作業単位を組織内の部門単位とし,部門ごとの承認可能数を入力させるようにしてもよい。
また,図7(A)〜(C)に示す承認可能数情報入力画面において,実行ボタンは,入力された承認可能数を用いた適用ルールの調整処理の実行を指示するボタンである。例えば,管理者は,承認可能数入力欄に承認可能数を入力し,実行ボタンを押下することにより,メールフィルタ装置1に適用ルールの調整処理を実行させる。
図7(A)は,承認可能数が承認者1人あたり1日あたりの承認可能なメール数である場合の承認可能数情報入力画面の例である。この例の場合には,管理者は,承認可能数情報入力画面において,承認可能数の入力欄に,承認者1人あたり1日あたりの平均的な承認可能数を入力する。
図7(B)は,承認可能数が承認者1人あたり1日あたりの承認可能なメール数である場合に,暦や日付等に応じた承認可能数を入力する承認可能数情報入力画面の例である。この例の場合には,管理者は,承認可能数情報入力画面において,承認可能数の入力欄に,曜日ごとの承認者1人あたり1日あたりの平均的な承認可能数を入力する。暦や日付等の分類は,必ずしも曜日ごとである必要はなく,例えば月末の一週間とそれ以外の日,五十日(ごとおび)とそれ以外の日など,任意である。
例えば,曜日ごとの承認可能数が設定された場合には,メールフィルタ装置1は,曜日ごとに適用ルールの調整を行う。すなわち,一週間の内で,承認者が承認作業を行う時間をほとんど取れない曜日の承認可能数を少なく設定し,逆に承認者が承認作業を行う時間を多く取れる曜日の承認可能数を多く設定すれば,曜日に応じて適切な適用ルールの調整を行うことができるようになる。
このように,暦や日付等の分類に応じた承認可能数を設定することにより,暦や日付等の分類に応じた適切な適用ルールの調整が可能となる。
図7(C)は,承認者ごとに,1日あたりの承認可能数を入力する承認可能数情報入力画面の例である。この例の場合には,管理者は,承認可能数情報入力画面において,承認可能数の入力欄に,承認者ごとに,1日あたりの承認可能数を入力する。このように,承認者ごとに承認可能数を設定することもできる。
図7(A)〜(C)に示す承認可能数情報入力画面から登録された承認可能数の情報は,メールフィルタ装置1において,承認可能数情報記憶部11に記憶される。
なお,承認可能数情報入力画面から登録された承認可能数を,後述のルール設定部15による適用ルール決定の判定に用いる承認可能数とするケースの他にも,後述の承認可能数算出部112によって適用ルール決定の判定に用いる承認可能数を算出するケースも考えられる。例えば,図7(C)に示す承認者ごとに承認可能数を設定する場合には,承認可能数算出部112が,承認者ごとの承認可能数から,適用ルール決定の判定に用いる承認可能数を算出する必要がある。このような,承認可能数算出部112により算出された適用ルール決定の判定に用いる承認可能数の情報も,承認可能数情報記憶部11に記憶される。
また,図7(A)〜(C)に示す例では,1日あたりの承認可能数の情報が設定されているが,1週間あたり,1時間あたりなど,承認可能数の時間基準は任意である。
図3において,ユーザ情報記憶部12は,メールシステムを利用するユーザの情報や,登録された承認者の情報などを記憶する,コンピュータがアクセス可能な記憶装置である。
図8は,本実施の形態によるユーザデータの例を示す図である。
図8に示すユーザデータ202は,ユーザ情報記憶部12に記憶された,メールシステムを利用するユーザの情報の例である。図8に示すユーザデータ202において,ユーザIDは,各ユーザを一意に識別するための識別情報である。名前は,ユーザの名前である。部門IDは,ユーザが所属する部門を一意に識別するための識別情報である。所属部門は,ユーザが所属する部門の名称である。メールアドレスは,ユーザのメールアドレスである。
図9は,本実施の形態による承認者データの例を示す図である。
図9に示す承認者データ203は,ユーザ情報記憶部12に記憶された,管理者により登録された承認者の情報の例である。図9に示す承認者データ203において,ユーザIDは,承認者のユーザIDであり,ユーザデータ202のユーザIDと対応する。名前は,承認者の名前である。部門IDは,承認者が所属する部門の部門IDである。所属部門は,承認者が所属する部門の名称である。
本実施の形態では,承認者は,ユーザの中から選ばれている。図9に示す承認者データ203は,図8に示すユーザデータ202から承認者として登録されたユーザのデータを抽出することにより,生成されている。
図3において,メール記憶部61は,過去の送信メールのコピーやその送信メールに関する情報を記憶保存する,コンピュータがアクセス可能な記憶装置である。送信メールには,実際に送信されたメールだけではなく,ユーザにより送信が要求されたものの,メールフィルタ装置1でのフィルタリングにより送信されなかったメールも含まれる。送信メールについては,そのコピーが,逐次,メール記憶部61に蓄積保存される。
図10は,本実施の形態によるメッセージデータの例を示す図である。
図10に示すメッセージデータ204は,メール記憶部61に記憶された,過去の送信メールのコピーやその送信メールに関する情報の例である。本実施の形態では,図10に示すメッセージデータ204によって,過去の送信メールのコピーが管理保存されているものとする。
図10に示すメッセージデータ204において,メッセージIDは,送信メールを一意に識別するための識別情報である。ユーザIDは,送信メールの送信者のユーザIDである。送信日時は,送信メールが送信された日時である。ここでは,送信日時として,送信者のユーザ端末2から送信メールの送信が要求された日時が記録される。送信者アドレスは,送信メールの送信者のアドレスである。宛先アドレスは,送信メールの宛先のアドレスである。件名は,送信メールの件名である。本文は,送信メールの本文である。添付ファイルは,送信メールに添付されたファイルである。
図3において,メール件数集計部13は,登録されてルール情報記憶部10に記憶されたルールを優先度が高い方から順に組み合わせた,ルールの組合せごとに,そのルールの組合せに該当する,メール記憶部61に記憶された過去の送信メールの件数を集計する。ルールの組合せに該当する送信メールとは,組み合わされたルールの条件の論理和を満たす送信メールである。
ここでは,図5に示すルールデータ201に基づいて,メール件数集計部13による集計処理の例を説明する。なお,図5のルールデータ201の例には示されていないが,運用上の問題がないルール,例えばアクションが“破棄”や“通知”であるルールも混在する場合もある。このような場合に,集計処理を行うルールに運用上の問題がないルールを含めてもよいが,本実施の形態では,運用上の問題がないルールを集計処理を行うルールから除外する。
まず,メール件数集計部13は,図5に示すルールデータ201において優先度が高い順に1つのルールの組合せ,すなわち最も優先度が高いルールID“rule001 ”のルールについての集計処理を行う。
メール件数集計部13は,メール記憶部61に記憶された,所定の集計の対象となる送信メールから,ルールID“rule001 ”のルールに該当する送信メールの件数を集計する。より具体的には,メール件数集計部13は,所定の集計の対象となる送信メールの1つ1つについて,ルールID“rule001 ”のルールの条件を満たすか否かの判定を行い,満たすと判定された送信メールの件数を集計する。
所定の集計の対象となる送信メールは,例えば,メール記憶部61に保存されたすべての送信メールや,メール記憶部61に保存された送信日時が最近4週間以内の送信メール,メール記憶部61に保存された送信日時が月曜日である送信メールなど,任意である。所定の集計の対象となる送信メールは,例えば,管理者によって管理用端末4から設定される。
例えば,部門ID“section001”の部門について,過去10日分で1日平均100通,すなわち全部で1000通の送信メールが,所定の集計の対象となる送信メールであるものとする。
次に,メール件数集計部13は,図5に示すルールデータ201において優先度が高い順に2つのルールの組合せ,すなわちルールID“rule001 ”と“rule002 ”とのルールの組合せについての集計処理を行う。
メール件数集計部13は,メール記憶部61に記憶された,所定の集計の対象となる送信メールから,ルールID“rule001 ”のルールまたはルールID“rule001 ”のルールのいずれかに該当する送信メールの件数を集計する。より具体的には,メール件数集計部13は,所定の集計の対象となる送信メールの1つ1つについて,ルールID“rule001 ”のルールの条件またはルールID“rule002 ”のルールの条件のいずれかを満たすか否かの判定を行い,満たすと判定された送信メールの件数を集計する。
さらに,メール件数集計部13は,図5に示すルールデータ201において優先度が高い順に3つ,4つとルールを組み合わせて,メール記憶部61に記憶された,所定の集計の対象となる送信メールから,それぞれの組合せに該当する送信メールの件数を集計する。
例えば,上記の1000通の送信メールからの,ルールの組合せごとの該当送信メールの集計結果が次の通りとなったものとする。
〔rule001 〕 :40通
〔rule001 〕+〔rule002 〕 :180通
〔rule001 〕+〔rule002 〕+〔rule003 〕 :300通
〔rule001 〕+〔rule002 〕+〔rule003 〕+〔rule004 〕 :400通
なお,ここでは,〔rule001 〕は,ルールID“rule001 ”のルールを意味しており,〔rule001 〕+〔rule002 〕は,ルールID“rule001 ”ルールとルールID“rule002 ”のルールの組合せを意味している。
このように,メール件数集計部13は,ルール情報記憶部10に記憶されたルールを優先度が高い順に組み合わせて,ルールの組合せごとに,メール記憶部61に記憶された集計の対象となる各送信メールがルールの組合せに該当するかを判定し,該当すると判定された送信メールの件数を集計する。
なお,メール件数集計部13が,組織内の部門や曜日などの特定の区分ごとに,ルールの組合せに該当する送信メールの件数の集計を行うようにしてもよい。部門ごとに適用ルールの調整が行われる場合には,該当部門の送信メールが所定の集計対象となる。また,日付ごとに適用ルールの調整が行われる場合には,該当日付の送信メールが所定の集計対象となる。
メール件数集計部13は,ルールの組合せごとに集計された送信メールの件数に関する情報を,メール集計情報記憶部14に記憶する。ルールの組合せごとに集計された送信メールの件数に関する情報は,例えば,ルールの組合せごとの,集計の対象となる全送信メール数に対する,集計された送信メールの件数の割合であってもよいし,その割合から求められる,ルール組合せごとの,1日あたりの該当送信メール件数であってもよい。
図3において,メール集計情報記憶部14は,ルールの組合せごとに集計された送信メールの件数に関する情報を記憶する,コンピュータがアクセス可能な記憶装置である。
図11は,本実施の形態によるヒット率データの例を示す図である。
図11に示すヒット率データ205は,メール集計情報記憶部14に記憶された,ルールの組合せごとに集計されたメールの件数に関する情報の例である。図11に示すヒット率データ205は,ルールの組合せごとの,集計の対象となる全メール数に対する,集計された送信メールの件数の割合が記録されたデータである。以下では,集計の対象となる全メール数に対する,集計されたメールの件数の割合を,ヒット率と呼ぶ。図11に示すヒット率データ205には,組織の部門ごとに,ルールの組合せごとのヒット率が記録されている。例えば,部門ID“section001”の部門については,上記の1000通の送信メールからの,ルールの組合せごとの該当送信メールの集計結果から算出された,ヒット率の値が記録されている。
図11に示すヒット率データ205において,部門IDは,メールシステムを運用する組織内の部門を一意に識別するための識別情報である。ルールID(組合せ)は,優先度が高い順に組み合わされた各ルールのルールIDである。ヒット率は,ルールの組合せごとに集計された送信メール件数から求められたヒット率である。
図3において,ルール設定部15は,メール件数集計部13によるルールの組合せごとの送信メール件数の集計結果に基づいて,送信メールのフィルタリングに適用するルールの設定を行う。
より具体的には,ルール設定部15は,メール集計情報記憶部14に記憶されたルールの組合せごとに集計された送信メールの件数に関する情報を参照し,各ルールの組合せについて,集計された送信メールの件数と所定の承認可能数との比較を行う。ルール設定部15は,集計されたメールの件数が,所定の承認可能数以下でその承認可能数に最も近い件数となるルールの組合せを,送信メールのフィルタリングに適用するルールとして決定する。ルール設定部15は,送信メールのフィルタリングに適用するルールを,ルール情報記憶部10に記憶されたルールデータ201に設定する。なお,所定の承認可能数は,承認可能数情報記憶部11に記憶された,適用ルール決定の判定に用いる承認可能数である。
図12は,本実施の形態による適用ルールの決定を説明する図である。
例えば,メール件数集計部13による集計結果として,図11に示すヒット率データ205が得られたものとする。また,1日あたりの送信メールの発生数が,平均100通であったものとする。
部門ID“section001”の部門について,ルールの組合せごとの,1日あたりの送信メールの件数を求めると,次の通りとなる。
〔rule001 〕 :4通
〔rule001 〕+〔rule002 〕 :18通
〔rule001 〕+〔rule002 〕+〔rule003 〕 :30通
〔rule001 〕+〔rule002 〕+〔rule003 〕+〔rule004 〕 :40通
なお,ここでは,〔rule001 〕は,ルールID“rule001 ”のルールを意味しており,〔rule001 〕+〔rule002 〕は,ルールID“rule001 ”ルールとルールID“rule002 ”のルールの組合せを意味している。
部門ID“section001”の部門における承認者数が2人であるものとする。このとき,ルールの組合せごとの,1人あたり1日あたりの送信メールの件数は,図12に示す通りとなる。
承認者1人あたり1日あたりの承認可能数が,10通と設定され,承認可能数情報記憶部11に記憶されているものとする。ルール設定部15は,送信メールの件数が,承認可能数10通以下であり,承認可能数10通に最も近い件数である,ルールID“rule001 ”ルールとルールID“rule002 ”のルールの組合せを,適用するルールとして決定する。この場合,ルールID“rule003 ”ルールとルールID“rule004 ”のルールは,不適用となる。
なお,ここでは,承認者1人あたり1日あたりの承認可能数を所定の承認可能数として用いる例を示しているが,例えば組織や部門における1日あたりの承認可能数を所定の承認可能数として用いるなどしてもよい。例えば,上記の部門ID“section001”の部門における1日あたりの承認可能数は,承認者数2人と,1人あたり1日あたりの承認可能数10通とから,20通と求められる。ルール設定部15は,1日あたりの承認可能数20通と,上記のルールの組合せごとの,1日あたりの送信メールの件数とを比較する。ルール設定部15は,1日あたりの送信メールの件数が18通である,ルールID“rule001 ”ルールとルールID“rule002 ”のルールの組合せを,適用するルールとして決定する。
ルール設定部15は,図5に示すルールデータ201において,適用するとされたルールID“rule001 ”のルールとルールID“rule002 ”のルールにおける適用フラグを,ONに設定する。また,ルール設定部15は,図5に示すルールデータ201において,不適用となったルールID“rule003 ”のルールとルールID“rule004 ”のルールにおける適用フラグを,OFFに設定する。
なお,図5のルールデータ201の例には示されていないが,本実施の形態では,運用上の問題がないルール,例えばアクションが“破棄”や“通知”であるルールについては,適用フラグがすべてONに設定される。
また,組織の部門ごとや日付ごとに適用ルールの調整を行う場合には,ルール設定部15は,組織の部門ごと,日付ごとに適用フラグの設定を行う。
ここで,不適用となったルール,すなわち適用フラグがOFFとなったルールについて,一時アクションを自動設定するようにもできる。ここでは,一時アクションとして,“通知”が設定されるものとする。ルール設定部15は,不適用となったルールID“rule003 ”のルールとルールID“rule004 ”のルールの一時アクションを,“通知”に設定する。一時アクションの自動設定を行うか否かは,例えば,管理者が管理用端末4を用いて,メールフィルタ装置1に設定する。
図3において,メール受信部16は,メールシステム内のユーザ端末2から新規に送信が要求されたメールを受信する。
なお,メールフィルタ装置1は,ユーザ端末2から新規にメールの送信が要求された場合に,そのメールのコピーをDBサーバ6に送る。DBサーバ6は,メールフィルタ装置1から受けた送信メールのコピーを,メール記憶部61に記憶する。
図3において,メール抽出部17は,ルール情報記憶部10に記憶されたルールデータ201に従って,受信された新規の送信メールのフィルタリングを行う。メール抽出部17は,新規の送信メールが受信されると,その新規送信メールが,ルールデータ201に登録された適用フラグがONであるルールの条件を満たすか否かを,優先度が高いルールから順に判定する。
新規送信メールがいずれかのルールの条件を満たすと判定された場合には,メール抽出部17は,条件を満たすと判定されたルールで指定されたアクションを実行する。
例えば,実行するアクションが“保留”であれば,メール抽出部17は,受信された新規送信メールを,送信するために承認者による承認が必要なメールとして,承認対象メール記憶部18に保存する。以下では,送信するために承認者による承認が必要なメールを,承認対象メールと呼ぶ。図3において,承認対象メール記憶部18は,承認対象メールを一時的に保存する,コンピュータがアクセス可能な記憶装置である。
また,例えば,実行するアクションが“破棄”であれば,メール抽出部17は,受信された新規送信メールを送信せずに,自動的に削除する。このとき,メールフィルタ装置1は,新規送信メールの送信者のユーザ端末2に対して,送信メールが破棄された旨を通知する。
また,例えば,実行するアクションが“通知”であれば,メール抽出部17は,受信された新規送信メールを送信すると判断する。メール抽出部17は,承認者に対して,ルールに該当する送信メールが送信された旨を通知する。
新規送信メールがいずれのルールの条件も満たさなかった場合には,メール抽出部17は,その新規送信メールを送信すると判断する。
なお,メール抽出部17は,原則として,適用フラグがOFFであるルールによる新規送信メールの抽出判定を行わない。ただし,ルール設定部15で一時アクションが設定された場合には,メール抽出部17は,適用フラグがOFFであるルールによる新規送信メールの抽出判定を行う。メール抽出部は,適用フラグがOFFであるルールの条件を満たす新規送信メールについて,ルールデータ201の一時アクションで指定されたアクションを実行する。
図3において,メール転送部19は,メール抽出部17において送信すると判断された新規送信メールを,メールサーバ7に転送する。また,メール転送部19は,メール抽出部17において保留とされ,承認対象メール記憶部18に一時保存された承認対象メールが,承認者によって送信が承認された場合に,その承認対象メールをメールサーバ7に転送する。
図3において,承認処理部110は,承認対象メール記憶部18に一時保存された承認対象メールの承認処理を行う。より具体的には,承認者による承認者端末3からのアクセスを受けると,承認処理部110は,承認対象メール記憶部18に一時保存された承認対象メールの情報を,承認者端末3に送る。なお,組織の部門ごとに承認者が決まっている場合などには,承認処理部110は,その承認者に該当する部門に属するユーザが送信者となっている承認対象メールの情報のみを,承認者端末3に送る。承認者は,承認者端末3で,保留となっている各承認対象メールを確認し,送信の許可や不許可等の判断を行う。
承認者により送信が許可された承認対象メールについては,承認処理部110は,メール転送部19に転送を依頼する。メール転送部19は,承認者により送信が許可された承認対象メールを,新規送信メールとしてメールサーバ7に転送する。
承認処理部110は,承認者により送信が不許可とされた承認対象メールを,削除する。このとき,メールフィルタ装置1は,送信が不許可とされた承認対象メールの送信者のユーザ端末2に対して,メールが破棄された旨を通知する。
また,承認処理部110は,承認情報記憶部111に,承認処理のログや,承認者端末3からメールフィルタ装置1へのアクセス時間など,メールの承認に関連する各種情報を記録する。
図3において,承認情報記憶部111は,メールの承認に関連する各種情報を記憶する,コンピュータがアクセス可能な記憶装置である。承認情報記憶部111に記憶されるメールの承認に関連する各種情報としては,例えば,
・承認者端末3がメールフィルタ装置1にアクセスした時間の情報,
・承認対象メールごとの承認処理に関するログ情報,
・承認者の出退勤などのスケジュール情報,
・滞納されている承認対象メールの件数の情報,
・承認者端末3がメールフィルタ装置1からログアウトしたときに残された承認対象メールの件数の情報
など,様々な情報が考えられる。
図3において,承認可能数算出部112は,承認情報記憶部111に記憶された各種情報や,ユーザ情報記憶部12に記憶された承認者の情報,承認可能数情報記憶部11に記憶された承認可能数の情報などに基づいて,適用ルール決定の判定に用いる承認可能数を算出する。例えば,図7(C)に示すように,管理者により承認者ごとの承認可能数が登録された場合に,承認可能数算出部112は,登録された承認者ごとの承認可能数を合算し,適用ルール決定の判定に用いる承認可能数を算出する。
以下,承認可能数算出部112による承認可能数の算出の例を,いくつか紹介する。なお,ここでは,適用ルール決定の判定に用いる承認可能数として,組織や部門における1日あたりの承認可能数を算出する。承認者1人あたり1日あたりの承認可能数を,適用ルール決定の判定に用いる承認可能数とする場合には,組織や部門における1日あたりの承認可能数を,承認者の人数で割ればよい。
まず,承認可能数算出部112による承認可能数の算出の例として,アクティブ承認者数の期待値から,適用ルール決定の判定に用いる承認可能数を算出する例を説明する。
ある部門において1日に承認処理できるメール数,すなわち該当部門における承認可能数は,例えば,次のように求められる。
(該当部門における承認可能数)
= (承認者1人が1日に承認できるメール数)
×(該当部門で登録されている承認者の人数)
ここで,承認者1人が1日に承認できるメール数は,例えば,管理者により運用面に関する情報として入力された,承認者1人あたり1日あたりの承認可能数の情報から得ることができる。また,該当部門で登録されている承認者の人数は,例えば,ユーザ情報記憶部12に記憶された承認者データ203から得ることができる。
しかし,該当部門において,システムに登録された承認者が10人であったとしても,実際には,承認者として登録されたユーザにも承認作業以外の仕事があり,登録された10人全員が毎日1人分の承認者として活動できない可能性もある。例えば,登録された承認者が10人であっても,1日あたり実質5人しか活動できないような場合には,想定された半分のメールしか承認処理ができないという事態も起こり得る。
ここでは,承認可能数算出部112は,1日あたりの実質的な承認者の人数の期待値,すなわち実質的に承認者として活動することが期待できる1日あたりの人数を求め,適用ルール決定の判定に用いる所定の承認可能数を算出する。以下では,1日あたりの実質的な承認者の人数の期待値を,アクティブ承認者数の期待値と呼ぶ。
承認可能数算出部112は,まず,承認情報記憶部111に記憶された,メールの承認に関連する各種情報から,承認者ごとに,承認処理が可能な状態である確率を計算する。以下では,承認処理が可能な状態である確率を,アクティブ確率と呼ぶ。
承認者ごとのアクティブ確率の算出方法としては,様々な情報を用いた算出方法が考えられる。ここでは,その一例として,各承認者が承認処理のために承認者端末3でメールフィルタ装置1にアクセスした時間の情報から,承認者ごとのアクティブ確率を算出する例を説明する。
図13は,本実施の形態による承認アクセス時間データの例を示す図である。
図13に示す承認アクセス時間データ206は,承認情報記憶部111に記憶された,メールの承認に関連する情報の一例である。図13に示す承認アクセス時間データ206は,各承認者が承認処理のために承認者端末3でメールフィルタ装置1にアクセスした時間の情報である。すなわち,図13に示す承認アクセス時間データ206は,登録された承認者が過去に承認処理のために実際に割いた時間の情報である。例えば,承認処理部110は,承認者による承認者端末3を用いた承認処理の時間を1日ごとに計測し,計測された時間を,承認情報記憶部111に記憶された承認アクセス時間データ206の該当承認者のレコードに記録する。
図13に示す承認アクセス時間データ206において,ユーザID(承認者)は,承認者のユーザIDである。承認アクセス時間は,日付ごとの,承認者が承認処理のために承認者端末3でメールフィルタ装置1にアクセスした時間である。すなわち,承認アクセス時間は,日付ごとの,承認者が承認処理を行った時間である。
ここでは,部門ID“section001”の部門における1日あたりの承認可能数を算出するものとする。図9に示す承認者データ203から,部門ID“section001”の部門における承認者は,ユーザID“user101 ”のユーザと,ユーザID“user102 ”のユーザの2人である。
承認可能数算出部112は,承認者ごとに,所定期間内の1日あたりの承認アクセス時間の平均値を算出する。ここでは,2009/01/22〜2009/01/27を所定期間として,承認者ごとの1日あたりの承認アクセス時間の平均値は,
ユーザID“user101 ”の承認者:
108[分]/6[日]=18[分/日]
ユーザID“user102 ”の承認者:
162[分]/6[日]=27[分/日]
となる。
ここで,承認者1人あたり1日あたり10通の承認対象メールの承認処理が想定されており,一人の承認者が10通の承認対象メールの承認処理を行うのに,平均30分の時間がかかるものとする。すなわち,承認者が1人分の承認処理を行うためには,1日あたりの承認アクセス時間が平均30分必要であると想定される。
承認可能数算出部112は,承認者ごとに,アクティブ確率を求める。この例の場合には,承認者が1人分の承認処理を行うために必要とされる1日あたりの承認アクセス時間に対する,実際の1日あたりの承認アクセス時間の平均値を求め,アクティブ確率とする。各承認者のアクティブ確率は,
ユーザID“user101 ”の承認者:
18[分/日]/30[分/日]=0.6
ユーザID“user102 ”の承認者:
27[分/日]/30[分/日]=0.9
となる。これらのアクティブ確率の算出結果から,実質的に,ユーザID“user101 ”の承認者が0.6人前の承認処理を行っており,ユーザID“user102 ”の承認者が0.9人前の承認処理を行っていることがわかる。
承認可能数算出部112は,承認者ごとのアクティブ確率の算出結果から,アクティブ承認者数の期待値を算出する。すなわち,上記の承認者ごとのアクティブ確率の算出結果から,
部門ID“section001”の部門におけるアクティブ承認者数の期待値
= ユーザID“user101 ”の承認者のアクティブ確率:0.6
+ユーザID“user102 ”の承認者のアクティブ確率:0.9
=1.5
となる。算出されたアクティブ承認者数の期待値から,部門ID“section001”の部門では,実質的に1日あたり1.5人の承認者によって,承認処理が行われていることがわかる。
承認可能数算出部112は,得られたアクティブ承認者数の期待値を用いて,該当部門における1日あたりの承認可能数を算出する。すなわち,上記のアクティブ承認者数の期待値から,
部門ID“section001”の部門における1日あたりの承認可能数
= 承認者1人が1日に承認できるメール数:10[通]
×アクティブ承認者数の期待値:1.5
=15[通]
となる。
承認可能数算出部112は,算出された部門ID“section001”の部門における1日あたりの承認可能数を,部門ID“section001”の部門における適用ルール決定の判定に用いる承認可能数として,承認可能数情報記憶部11に記憶する。ルール設定部15は,承認可能数情報記憶部11に記憶された承認可能数を用いて,送信メールのフィルタリングに適用するルールの組合せを決定する。
なお,特定の日付の条件を指定して,1日あたりの承認アクセス時間の平均値を算出すれば,特定の日付に関する1日あたりの承認アクセス時間の平均値を得ることができる。例えば,特定の日付の条件として木曜日が指定されていれば,承認アクセス時間データ206から木曜日のデータのみを抽出して,木曜日に関する1日あたりの承認アクセス時間の平均値を得ることができる。このように,日付の条件を指定して,1日あたりの承認アクセス時間の平均値を算出すれば,日付に応じた適用ルール決定の判定に用いる承認可能数を算出することもできる。
このように,承認者ごとの承認処理が可能の状態である確率を求め,実質的な承認者の人数の期待値を求めて,適用ルール決定の判定に用いる承認可能数を算出することにより,より承認処理の実状に見合った,送信メールのフィルタリングに適用するルールの調整が可能となる。これにより,より現実に即した運用面での負荷や,セキュリティレベルのバランスを考慮した,送信メールのフィルタリングの設定が可能となる。
なお,各承認者が承認処理のために承認者端末3でメールフィルタ装置1にアクセスした時間の情報から,アクティブ確率を算出する方法以外にも,様々な承認に関する情報を用いた算出方法が考えられる。例えば,承認者のスケジュール情報から求められる,承認者のスケジュールの埋まり具合に応じて,アクティブ確率を算出するようにもできる。また例えば,承認対象メールの送信日時や承認処理日時などのログ情報から求められる,承認対象メールが保留されてから承認されるまでの平均時間に応じて,アクティブ確率を算出するようにもできる。また,例えば,承認処理を終了したときに残された承認対象メール数の情報から求められる,承認対象メールの滞納率に応じて,アクティブ確率を算出するようにもできる。また,複数の情報を用いて,それぞれの情報に所定の重み付けなどを行い,アクティブ確率を算出するようにもできる。
次に,承認可能数算出部112による承認可能数の算出の例として,各承認対象メールの承認処理が行われた日時の情報から,承認者ごとに1日あたりの承認可能数を求めて,適用ルール決定の判定に用いる承認可能数を算出する例を説明する。
図14は,本実施の形態による承認ログデータの例を示す図である。
図14に示す承認ログデータ207は,承認情報記憶部111に記憶された,メールの承認に関連する情報の一例である。図14に示す承認ログデータ207は,各承認対象メールの承認処理に関するログ情報である。例えば,承認処理部110は,承認者により,承認対象メールの承認が行われたときに,その承認対象メールへの承認処理のログを,承認情報記憶部111に記憶された承認ログデータ207に記録する。
図14に示す承認ログデータ207において,メッセージIDは,承認対象メールのメッセージIDである。ユーザID(承認者)は,その承認対象メールの承認を行った承認者のユーザIDである。承認結果は,その承認対象メールに対する承認者による承認の結果である。“OK”は,承認対象メールの送信が許可されたことを示し,“NG”は,承認対象メールの送信が不許可であったことを示す。送信日時は,その承認対象メールの送信が送信者のユーザ端末2から要求された日時である。送信日時は,その承認対象メールが保留とされた日時とも捉えられる。承認日時は,その承認対象メールの承認処理が行われた日時である。
ここでは,部門ID“section001”の部門における1日あたりの承認可能数を算出するものとする。図9に示す承認者データ203から,部門ID“section001”の部門における承認者は,ユーザID“user101 ”のユーザと,ユーザID“user102 ”のユーザの2人である。
承認可能数算出部112は,承認者ごとに,所定期間における1日あたりの承認対象メールの承認数を算出する。承認ログデータ207において,承認日時が同じ日である承認対象メールをユーザID(承認者)で示される承認者ごとに集計することにより,承認者ごと,日付ごとの承認対象メールの承認数を得ることができる。所定期間内の承認者ごと,日付ごとの承認対象メールの承認数を,承認者ごとに平均することにより,承認者ごとの所定期間内の1日あたりの承認対象メールの承認数を算出することができる。ここでは,近傍一週間を所定期間とした場合に,ユーザID“user101 ”の承認者の近傍の一週間における,1日あたりの承認対象メールの承認数が8通であったものとする。また,ユーザID“user102 ”の承認者の近傍の一週間における,1日あたりの承認対象メールの承認数が11通であったものとする。
承認可能数算出部112は,承認者ごとの1日あたりの承認対象メールの承認数を合算することにより,適用ルール決定の判定に用いる承認可能数を算出する。例えば,部門ID“section001”の部門における1日あたりの承認可能数は,上記のユーザID“user101 ”の承認者の1日あたりの承認対象メールの承認数8通と,ユーザID“user102 ”の承認者の1日あたりの承認対象メールの承認数11通とを合算して,19通となる。
承認可能数算出部112は,算出された部門ID“section001”の部門における1日あたりの承認可能数を,部門ID“section001”の部門における適用ルール決定の判定に用いる承認可能数として,承認可能数情報記憶部11に記憶する。ルール設定部15は,承認可能数情報記憶部11に記憶された承認可能数を用いて,送信メールのフィルタリングに適用するルールの組合せを決定する。
なお,特定の日付の条件を指定して,承認者ごとの1日あたりの承認対象メールの承認数を算出すれば,特定の日付に関する承認者ごとの1日あたりの承認対象メールの承認数を得ることができる。例えば,特定の日付の条件として五十日(ごとおび)が指定されていれば,承認ログデータ207から五十日(ごとおび)のデータのみを抽出して,五十日(ごとおび)に関する承認者ごとの1日あたりの承認対象メールの承認数を得ることができる。このように,日付の条件を指定して,承認者ごとの1日あたりの承認対象メールの承認数を算出すれば,日付に応じた適用ルール決定の判定に用いる承認可能数を算出することもできる。
このように,各承認対象メールの承認処理日時のログ情報から,承認者ごとの実質的な承認可能数を求めて,適用ルール決定の判定に用いる承認可能数を算出することにより,より承認処理の実状に見合った,送信メールのフィルタリングに適用するルールの調整が可能となる。これにより,より現実に即した運用面での負荷や,セキュリティレベルのバランスを考慮した,送信メールのフィルタリングの設定が可能となる。
本実施の形態のメールフィルタ装置1により,運用面を考慮しながらの,煩雑なフィルタルールの設定作業を,自動化することができる。また,メールシステム導入企業の運用形態に合った最適なフィルタを,短時間で作成することができる。また,ルールの見直しにおける管理者の負荷や運用コストが削減できる。また,一定のセキュリティレベルを保ちながら,運用負荷の最適化を行うことができる。
以下,図15〜図20に示すフローチャートを用いて,本実施の形態のメールフィルタ装置1による各処理の流れを説明する。
図15は,本実施の形態のメールフィルタ装置による適用ルール調整処理フローチャートである。
メール件数集計部13は,カウンタiを1に設定する(ステップS10)。
メール件数集計部13は,登録されてルール情報記憶部10に記憶されたルールについて,優先度が高い方からi個のルールを組み合わせる(ステップS11)。
メール件数集計部13は,DBサーバ6のメール記憶部61から,所定の期間や日付などの指定に応じて,集計対象となる過去の送信メールを取得する(ステップS12)。
メール件数集計部13は,取得された集計対象の送信メールに対して組み合わされたi個のルールによるフィルタリングを行い,そのi個のルールの組合せに該当する送信メールの件数を集計する(ステップS13)。i個のルールの条件の論理和に該当する送信メールの件数が得られる。
メール件数集計部13は,i個のルールの組合せにおける該当送信メールの集計結果を,メール集計情報記憶部14に記録する(ステップS14)。
メール件数集計部13は,すべての優先度が高い順からのルールの組合せについて,該当送信メールの集計処理を行ったかを判定する(ステップS15)。
すべてのルールの組合せについて処理が終了していなければ(ステップS15のNO),メール件数集計部13は,カウンタiをインクリメントし(ステップS16),ステップS11に戻って,次のルールの組合せについて処理を行う。
すべてのルールの組合せについて処理が終了していれば(ステップS15のYES),ルール設定部15は,ルールの組合せごとの送信メールの集計結果と,所定の承認可能数とから,送信メールのフィルタリングに適用するルールを決定する(ステップS17)。例えば,ルール設定部15は,メール集計情報記憶部14に記憶されたルールの組合せごとの送信メールの集計結果の情報から,ルールの組合せごとの1日あたりの該当送信メールの件数を得る。また,ルール設定部15は,承認可能数情報記憶部11に記憶された承認可能数の情報から,適用ルール決定の判定に用いる1日あたりの承認可能数を得る。ルール設定部15は,集計によって得られた該当送信メールの件数が,得られた承認可能数以下で,その承認可能数に最も近い件数になるルールの組合せを,送信メールのフィルタリングに適用するルールとして決定する。
ルール設定部15は,適用すると決定されたルールの設定を行う(ステップS18)。具体的には,ルール情報記憶部10に記憶された各ルールについて,適用するとされたルールについては適用フラグをONに設定し,適用されなかったルールについては適用フラグをOFFに設定する。
ルール設定部15は,適用されなかったルールについて,登録されたルールで指定されたアクションの代わりとなる一時アクションを設定するか否かを判定する(ステップS19)。一時アクションを設定するか否かは,管理者等によりあらかじめ設定され,その設定情報がメールフィルタ装置1に保持されている。
一時アクションを設定する場合には(ステップS19のYES),ルール設定部15は,適用しないルールについて,所定の一時アクションを設定する(ステップS20)。具体的には,所定の一時アクションが“通知”である場合に,ルール設定部15は,ルール情報記憶部10に記憶された適用しないルールに対して,一時アクションとして“通知”を設定する。
組織の部門ごとに応じた適用ルールの調整を行う場合には,図15に示す適用ルール調整処理を,部門ごとに実行する。また,曜日などの日付ごとに応じた適用ルールの調整を行う場合には,図15に示す適用ルール調整処理を,日付ごとに実行する。
図15に示すような,メールフィルタ装置1の適用ルールを調整する機能による適用ルール調整処理は,例えば,管理者によるメールシステムの導入時やメンテナンス時,メールフィルタ装置1により行われる定期的な自動メンテナンス時などに実行される。
図16は,本実施の形態のメールフィルタ装置による管理者介在時の処理フローチャートである。
メールフィルタ装置1は,管理用端末4からのルールの入力を受け付けると(ステップS30),入力されたルールをルール情報記憶部10に記録する(ステップS31)。このとき,メールフィルタ装置1は,ルールに対して優先度を対応付けて記録する。
メールフィルタ装置1は,管理用端末4から承認可能数に関する情報の入力を受けると(ステップS32),入力された承認可能数に関する情報を承認可能数情報記憶部11に記録する(ステップS33)。なお,適用ルール決定のための判定に用いる承認可能数を,入力された承認可能数に関する情報を用いて求める必要がある場合には,承認可能数算出部112による承認可能数の算出を行い,算出された承認可能数に関する情報を承認可能数情報記憶部11に記録する。
図15に示す適用ルール調整処理を行う(ステップS34)。
メールフィルタ装置1は,管理レポートを作成し(ステップS35),作成された管理レポートを管理用端末4に出力する(ステップS36)。
管理レポートは,管理者に提示するための,適用ルールの調整結果についてのレポート情報である。例えば,登録されたルールに対する適用されたルールの一覧情報や,メール記憶部61に記憶された過去の送信メールに対する適用ルールを用いたフィルタリングの結果,承認対象メールとして抽出されたメールのリスト情報などが,管理レポートとなる。管理者は,管理レポートを,登録するルールの調整,各ルールの優先度の調整,承認可能数の調整,承認者数の調整等を行うための参考情報として,使用することができる。
図17は,本実施の形態のメールフィルタ装置1による送信メールフィルタリング処理フローチャートである。
メール受信部16が新規の送信メールを受信すると(ステップS40),メール抽出部17は,カウンタnを1に設定する(ステップS41)。
メール抽出部17は,ルール情報記憶部10から優先度がn番目のルールを取得する(ステップS42)。メール抽出部17は,受信された新規送信メールが,取得されたn番目のルールの条件に該当するかを判定する(ステップS43)。
新規送信メールがn番目のルールの条件に該当しなければ(ステップS43のNO),メール抽出部17は,ルール情報記憶部10に記憶されたすべてのルールを用いて新規送信メールのフィルタリングを行ったかを判定する(ステップS44)。
まだすべてのルールを用いてフィルタリングを行っていなければ(ステップS44のNO),メール抽出部17は,カウンタnをインクリメントし(ステップS45),ステップS42に戻って,次のルールを用いた処理を行う。
すべてのルールを用いてフィルタリングを行っていれば(ステップS44のYES),メール転送部19は,新規送信メールをメールサーバ7に転送し(ステップS46),メールフィルタ装置1は処理を終了する。
新規送信メールがn番目のルールの条件に該当すれば(ステップS43のYES),メール抽出部17は,ルール情報記憶部10を参照し,n番目のルールが適用ルールであるかを判定する(ステップS47)。
n番目のルールが適用ルールであれば(ステップS47のYES),メール抽出部17は,ルール情報記憶部10を参照し,n番目のルールに設定されたアクションを実行し(ステップS48),メールフィルタ装置1は処理を終了する。例えば,ルール情報記憶部10を参照し,n番目のルールに設定されたアクションが“保留”であれば,メール抽出部17は,新規送信メールを承認対象メールとして,承認対象メール記憶部18に一時保存する。
n番目のルールが適用ルールでなければ(ステップS47のNO),メール抽出部17は,ルール情報記憶部10を参照し,一時アクションが設定されているかを判定する(ステップS49)。
一時アクションが設定されていなければ(ステップS49のNO),メール転送部19は,新規送信メールをメールサーバ7に転送し(ステップS46),メールフィルタ装置1は処理を終了する。
一時アクションが設定されていれば(ステップS49のYES),メール抽出部17は,ルール情報記憶部10を参照し,n番目のルールに設定された一時アクションを実行する(ステップS50)。例えば,ルール情報記憶部10を参照し,n番目のルールに設定されたアクションが“通知”であれば,メール抽出部17は,新規送信メールの送信を承認者端末3に通知する。メール転送部19は,新規送信メールをメールサーバ7に転送し(ステップS46),メールフィルタ装置1は処理を終了する。
図18は,本実施の形態の承認処理部による承認処理フローチャートである。
承認処理部110は,承認者端末3からの承認のためのアクセスを受け付けると(ステップS60),承認対象メール記憶部18に記憶された承認対象メールのリストを,承認者端末3に提示する(ステップS61)。
承認処理部110は,承認者端末3から承認対象メールに対する承認指示を受けると(ステップS62),その承認指示が該当承認対象メールの送信許可であるかを判定する(ステップS63)。
承認指示が送信許可であれば(ステップS63のYES),メール転送部19は,承認対象メール記憶部18から該当承認対象メールを取得し,取得された承認対象メールをメールサーバ7に転送する(ステップS64)。
承認指示が送信許可でなければ(ステップS63のNO),すなわち承認指示が送信不許可であれば,承認処理部110は,承認対象メール記憶部18から該当承認対象メールを削除する(ステップS65)。
承認処理部110は,承認処理のログを,承認情報記憶部111の承認ログデータ207に記録する(ステップS66)。
承認処理部110は,新たな承認指示がなく,承認者端末3からの承認のためのアクセスが終了であるかを判定する(ステップS67)。
承認のためのアクセスが終了せずに(ステップS67のNO),ステップS62の処理に戻って次の承認指示があれば,承認処理部110は,その承認処理を行う。
新たな承認指示がなく,承認のためのアクセスが終了であれば(ステップS67のYES),承認処理部110は,処理を終了する。
図19は,本実施の形態の承認可能数算出部による承認可能数算出処理フローチャート(1)である。
ここでは,ある部門について,各承認者の承認アクセス時間の履歴に基づいてアクティブ承認者数の期待値を算出し,そのアクティブ承認者数の期待値から,適用ルール決定の判定に用いる承認可能数を算出する処理の例を説明する。
承認可能数算出部112は,カウンタjを1に設定する(ステップS70)。
承認可能数算出部112は,ユーザ情報記憶部12に記憶された承認者データ203から,該当部門に属するj番目の承認者のユーザIDを取得する(ステップS71)。
承認可能数算出部112は,承認情報記憶部111に記憶された承認アクセス時間データ206を,j番目の承認者のユーザIDで検索し,その承認者についての承認アクセス時間の履歴情報を取得する(ステップS72)。
承認可能数算出部112は,取得された承認アクセス時間の履歴情報から,j番目の承認者についての,1日あたりの平均承認アクセス時間を算出する(ステップS73)。
承認可能数算出部112は,j番目の承認者についてのアクティブ確率を算出する(ステップS74)。アクティブ確率は,基準となる1日あたりの承認アクセス時間に対する,算出された1日あたりの平均承認アクセス時間から算出される。
承認可能数算出部112は,該当部門のすべての承認者について,アクティブ確率算出の処理が終了したかを判定する(ステップS75)。
すべての承認者について処理が終了していなければ(ステップS75のNO),承認可能数算出部112は,カウンタjをインクリメントし(ステップS76),ステップS71に戻って,次の承認者についての処理を行う。
すべての承認者について処理が終了していれば(ステップS75のYES),承認可能数算出部112は,すべての承認者のアクティブ確率を合算することにより,アクティブ承認者数の期待値を算出する(ステップS77)。
承認可能数算出部112は,算出されたアクティブ承認者数の期待値と,管理者により設定された承認者1人あたり1日あたりの承認可能数とを掛け合わせることにより,適用ルール決定の判定に用いる承認可能数を算出する(ステップS78)。管理者により設定された承認者1人あたり1日あたりの承認可能数の情報は,承認可能数情報記憶部11に記憶されているものとする。
承認可能数算出部112は,算出された適用ルール決定の判定に用いる承認可能数を,承認可能数情報記憶部11に記録し(ステップS79),処理を終了する。
図20は,本実施の形態の承認可能数算出部による承認可能数算出処理フローチャート(2)である。
ここでは,ある部門について,承認処理のログに基づいて承認者ごとの1日あたりの承認件数を算出し,その承認者ごとの1日あたりの承認件数から,適用ルール決定の判定に用いる承認可能数を算出する処理の例を説明する。
承認可能数算出部112は,カウンタkを1に設定する(ステップS80)。
承認可能数算出部112は,ユーザ情報記憶部12に記憶された承認者データ203から,該当部門に属するk番目の承認者のユーザIDを取得する(ステップS81)。
承認可能数算出部112は,承認情報記憶部111に記憶された承認処理のログを取得する(ステップS82)。承認処理のログは,例えば,承認情報記憶部111に記憶された承認ログデータ207である。
承認可能数算出部112は,取得された承認処理のログをk番目の承認者のユーザIDで検索し,1日ごとのk番目の承認者による承認処理件数を集計する(ステップS83)。
承認可能数算出部112は,1日ごとのk番目の承認者による承認処理件数の集計結果から,k番目の承認者についての,1日あたりの平均承認処理件数を算出する(ステップS84)。
承認可能数算出部112は,該当部門のすべての承認者について,1日あたりの平均承認処理件数算出の処理が終了したかを判定する(ステップS85)。
すべての承認者について処理が終了していなければ(ステップS85のNO),承認可能数算出部112は,カウンタkをインクリメントし(ステップS86),ステップS81に戻って,次の承認者についての処理を行う。
すべての承認者について処理が終了していれば(ステップS85のYES),承認可能数算出部112は,すべての承認者の1日あたりの平均承認処理件数を合算することにより,適用ルール決定の判定に用いる承認可能数を算出する(ステップS87)。
承認可能数算出部112は,算出された適用ルール決定の判定に用いる承認可能数を,承認可能数情報記憶部11に記録し(ステップS88),処理を終了する。
以上説明したメールフィルタ装置1またはメールフィルタ装置1が有する機能による処理は,コンピュータが備えるCPU,メモリ等のハードウェアとソフトウェアプログラムとにより実現することができる。また,そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも,ネットワークを通して提供することも可能である。
以上,本実施の形態について説明したが,本発明はその主旨の範囲において種々の変形が可能であることは当然である。
例えば,本実施の形態では,送信メールのフィルタリングに適用するルールの調整の例について説明したが,受信メールなどのフィルタリングに適用するルールの調整であってもよい。
また,メールのフィルタリングに適用するルールの調整に限らず,一般に,あるデータがチェックの対象となるデータであるか否かの判定に適用するルールの調整であってもよい。例えば,本実施の形態における,承認対象メールは,一般的に何らかのチェックの対象となるデータであると言える。また,例えば,送信メールから承認対象メールを抽出するためのフィルタリングに用いるルールは,一般的にあるデータから何らかのチェックの対象となるデータを抽出するためのルールであると言える。また,例えば,メール記憶部61に記憶された過去の送信処理の対象となったメールは,一般的に何らかのデータ処理の対象となったデータであると言える。また,例えば,承認者などの承認の作業を行う単位は,一般的にチェック処理作業を行う単位であると言える。また,例えば,所定の承認可能数は,一般的に所定のチェック可能件数であると言える。また,例えば,新規送信メールは,一般的に新規受付データであると言える。また,例えば,承認処理のログは,一般的にチェック処理のログであると言える。このように,本実施の形態によるメールのフィルタリングに適用するルールの調整を,あるデータがチェックの対象となるデータであるか否かの判定に適用するルールの調整に一般化することができる。
以上説明した本実施の形態の特徴を列記すると以下のとおりである。
(付記1)
あるデータがチェック対象データに該当するデータか否かを決定するルールであるチェックルールと,優先度とを対応付けて記憶するルール記憶部と,
処理対象データを記憶するデータ記憶部と,
前記ルール記憶部に記憶されたチェックルールを優先度が高い順に組み合わせた,チェックルールの組合せごとに,前記データ記憶部に記憶された処理対象データが該チェックルールの組合せに該当するか否かを判定して,該当すると判定された処理対象データの件数を集計する集計部と,
前記集計によって得られた件数が,所定のチェック可能件数以下で該チェック可能件数に最も近い件数になる前記チェックルールの組合せを,適用ルールとして設定する設定部と,
新規受付データが前記適用ルールに該当するか否かを判定し,該当すると判定した場合に,該新規受付データをチェック対象データとして抽出する抽出部とを備える
ことを特徴とする適用ルール調整装置。
(付記2)
チェック処理作業単位ごとのチェック可能件数に基づき,前記所定のチェック可能件数を求めるチェック可能件数算出部をさらに備える
ことを特徴とする付記1に記載された適用ルール調整装置。
(付記3)
前記チェック処理作業単位による,前記抽出されたチェック対象データのチェック処理日付を記憶するチェック処理ログ記憶部をさらに備え,
前記チェック可能件数算出部は,前記チェック処理ログ記憶部に記憶された,前記チェック処理日付が所定の条件に該当するチェック対象データの数をもとに,前記所定のチェック可能件数を求める
ことを特徴とする付記2に記載された適用ルール調整装置。
(付記4)
前記データ記憶部は,前記処理対象データごとのデータ処理日付をさらに記憶し,
前記集計部は,前記ルール記憶部に記憶されたチェックルールを優先度が高い順に組み合わせた,チェックルールの組合せごとに,前記データ記憶部に記憶された,前記データ処理日付が所定の条件に該当する前記処理対象データが,該チェックルールの組合せに該当するか否かを判定し,該当すると判定した処理対象データの件数を集計する
ことを特徴とする付記1から付記3までのいずれかに記載された適用ルール調整装置。
(付記5)
コンピュータが実行するプログラムであって,
前記コンピュータに,
前記コンピュータがアクセス可能な記憶装置に記憶された,あるデータがチェック対象データに該当するデータか否かを決定するルールであるチェックルールと,優先度との対応付けに基づいて,チェックルールを優先度が高い順に組み合わせた,チェックルールの組合せごとに,前記コンピュータがアクセス可能な記憶装置に記憶された処理対象データが該チェックルールの組合せに該当するか否かを判定して,該当すると判定された処理対象データの件数を集計する手順と,
前記集計によって得られた件数が,所定のチェック可能件数以下で該チェック可能件数に最も近い件数になる前記チェックルールの組合せを,適用ルールとして設定する手順と,
新規受付データが前記適用ルールに該当するか否かを判定し,該当すると判定した場合に,該新規受付データをチェック対象データとして抽出する手順とを
実行させるための適用ルール調整プログラム。
(付記6)
コンピュータによる適用ルール調整方法であって,
前記コンピュータが,
前記コンピュータがアクセス可能な記憶装置に記憶された,あるデータがチェック対象データに該当するデータか否かを決定するルールであるチェックルールと,優先度との対応付けに基づいて,チェックルールを優先度が高い順に組み合わせた,チェックルールの組合せごとに,前記コンピュータがアクセス可能な記憶装置に記憶された処理対象データが該チェックルールの組合せに該当するか否かを判定して,該当すると判定された処理対象データの件数を集計する過程と,
前記集計によって得られた件数が,所定のチェック可能件数以下で最も近い,前記チェックルールの組合せを,適用ルールとして設定する過程と,
新規受付データが前記適用ルールに該当するか否かを判定し,該当すると判定した場合に,該新規受付データをチェック対象データとして抽出する過程とを実行する
ことを特徴とする適用ルール調整方法。
(付記7)
送信が要求された電子メールが承認対象となる電子メールであるか否かを判定するためのルールと,優先度とが対応付けられて記憶されたルール記憶部と,
承認可能な電子メールの件数である承認可能数が記憶された承認可能数記憶部と,
過去に送信が要求された電子メールが記憶されたメール記憶部と,
前記ルールを前記優先度が高い方から順に組み合わされたルールの組合せごとに,前記過去に送信が要求された電子メールが,組み合わされたいずれかのルールに該当するか否かを判定し,該当すると判定された前記過去に送信が要求された電子メールの件数を集計するメール件数集計部と,
前記メール件数集計部での集計により得られた件数が,前記承認可能数以下で,かつ前記承認可能数に最も近い件数になる,前記ルールの組合せに含まれるルールを,適用ルールとして設定するルール設定部と,
新規に送信が要求された電子メールが,前記適用ルールに該当するか否かを判定し,該当すると判定された場合に,新規に送信が要求された電子メールを承認対象となる電子メールとして抽出するメール抽出部とを備える
ことを特徴とするメールフィルタ装置。
(付記8)
前記ルールは,承認対象の電子メールを抽出する条件と,抽出された承認対象の電子メールに対して実行する承認処理の指定とを有し,
前記ルール設定部は,前記ルール記憶部に記憶されたルールのうちで適用ルールに設定されなかったルールについて,前記承認対象の電子メールに対して実行する承認処理の指定を,前記承認処理よりも運用上の負荷が少ない処理の指定に変更し,
前記メール抽出部は,前記新規に送信が要求された電子メールが,前記適用ルールに設定されなかったルールに該当するか否かを判定し,該当すると判定された場合に,前記新規に送信が要求された電子メールに対して,前記変更された処理を実行する
ことを特徴とする付記7に記載されたメールフィルタ装置。
(付記9)
承認対象となる電子メールの承認を行う単位である承認処理作業単位ごとの承認可能な電子メールの件数に基づいて,前記承認可能数を算出して,前記承認可能数記憶部に記憶する承認可能数算出部をさらに備える
ことを特徴とする付記7または付記8に記載されたメールフィルタ装置。
(付記10)
前記抽出された承認対象となる電子メールに対して,前記承認処理作業単位によって承認が行われた承認処理の日付が記憶された承認ログ情報記憶部をさらに備え,
前記承認可能数算出部は,前記承認ログ情報記憶部に記憶された前記承認処理の日付が,所定の条件に該当する前記承認対象となる電子メールの数に基づいて,前記承認可能数を求める
ことを特徴とする付記9に記載されたメールフィルタ装置。
(付記11)
前記抽出された承認対象となる電子メールに対する承認処理に関する情報を記憶する承認情報記憶部をさらに備え,
前記承認可能数算出部は,前記承認情報記憶部に記憶された前記承認処理に関する情報に基づいて,承認処理の実行が可能な前記承認処理作業単位数の期待値を算出して,算出された承認処理の実行が可能な前記承認処理作業単位数の期待値から,前記承認可能数を求める
ことを特徴とする付記9に記載されたメールフィルタ装置。
(付記12)
前記メール記憶部は,前記過去に送信が要求された電子メールごとの,送信が要求された日付をさらに記憶し,
前記メール件数集計部は,前記ルールを前記優先度が高い方から順に組み合わせたルールの組合せごとに,前記送信が要求された日付が所定の条件に該当する前記過去に送信が要求された電子メールが,組み合わされたいずれかのルールに該当するか否かを判定し,該当すると判定された前記過去に送信が要求された電子メールの件数を集計する
ことを特徴とする付記7から付記11までのいずれかに記載されたメールフィルタ装置。