JP5504886B2 - メールチェック装置、メールチェックプログラム、およびメールチェック方法 - Google Patents

Description

本発明は、送信メールをチェックするポリシーの内容を自動調整するメールチェック技術に関する。

企業等の組織体で使用される電子メールシステムでは、メール送信時における宛先ミスやファイルの誤添付などに起因した情報漏洩の問題が頻繁に生じている。

メールの誤送信は、情報漏洩という重大な問題につながるものもあれば、情報は漏れなくても、顧客の信頼を失うなど企業としての信頼低下を招きかねず、メール誤送信を防止する対策が求められている。

従来、こうしたメールの誤送信を防止するために、予めメール送信時のポリシーを設定しておき、該ポリシーに基づいて送信予定のメールをチェックするフィルタリング技術が提案されている。

特開２００７−１０２３３４号公報

しかしながら、上記フィルタリングによる従来のメール誤送信対策では、セキュリティを管理する担当者が、情報セキュリティに関する企業の基本方針に従って、これまでのインシデント（事象）を確認した上で、ポリシーの設定や改定を行わなければならず、大変煩雑な作業となっていた。

上記問題を解決するため、本発明では、メール送信の際に、予め定めた送信ポリシーに基づいて確認した後に、送信がキャンセルされたログ情報を用いて送信ポリシーを自動的に調整するメールチェック装置、プログラム、及び方法を提供する。

発明の一つの態様は、ネットワークを介して複数のクライアント装置と接続するメールチェック装置であって、所定のチェックポリシーに基づき、クライアントが送信した要確認メールを検出するメールチェック手段と、前記要確認メールが検出された場合に、前記クライアントに確認依頼を送信する確認依頼手段と、前記確認依頼の応答であってキャンセルの有無を含む確認結果のログ情報を前記クライアントから取得して記憶装置に格納するログ格納手段と、格納した前記確認結果に基づいてキャンセル量または率を算出する算出手段と、算出した前記キャンセル量または率にしたがって前記チェックポリシーを変更するポリシー変更手段と、を有することを特徴とするメールチェック装置に関する。

上記本発明の一態様によれば、メールチェック手段が、所定のチェックポリシーに基づいてクライアントが送信した要確認メールを検出し、確認依頼手段が、要確認メールが検出された場合に、クライアントに確認依頼を送信する。その後、格納手段が、確認依頼の応答であってキャンセルの有無を含む確認結果のログ情報をクライアントから取得して記憶装置に格納し、算出手段が、格納した確認結果に基づいてキャンセル量または率を算出する。そして、ポリシー変更手段が、算出したキャンセル量または率にしたがってチェックポリシーを変更する構成とすることによって、企業等の組織体を単位とする送信メールの傾向や状況が確認できる。また、これらの傾向や状況から、送信メールをフィルタリングするポリシーに対し適確なフィードバックを行うことが可能となる。

上述したように、予め定めた送信ポリシーにしたがって、クライアントによる送信メールの確認結果が蓄積されたキャンセルログの情報を基に、キャンセル量または率を算出し、キャンセル量または率に応じてポリシーを自動的に変更する構成とすることによって、企業等の組織体を単位とする送信メールの傾向や状況に応じたポリシーの変更が、人手を介さず、容易に実現される。

本発明の実施の形態になるメールチェックシステムの一基本構成を示す図である。 本発明の実施の形態になるメールチェック装置の機能ブロック図である。 本発明の実施の形態になる送信メールの基本ポリシーテーブルを示す図である。 本発明の実施の形態になるクライアント装置に表示される送信メールの確認画面例を示す図である。 本発明の実施の形態になるメールチェック装置におけるログ分析事例を示す図である。 本発明の実施の形態になるポリシーの変更を規定するポリシー変更ルールテーブルを示す図である。 本発明の実施の形態になるメールチェック装置の動作フローを示す図である。 本発明の実施の形態になるポリシー配信時における各クライアントへの個別情報の提供フローを示す図である。

以下、図面にしたがって本発明の実施形態について説明する。

図１は、メールチェック装置１、クライアントＰＣ（Personal Computer ）２、およびメールサーバ３がＬＡＮ（Local Area Network）４を介して互いに接続するメールチェックシステムの一構成例を示している。送信メールは、さらにゲートウエイ（図示していない）を介して外部ネットワーク５に送信される。

上記構成は、勿論、メールサーバ３にメールチェック装置１の機能を内蔵させ、一つのサーバで管理する構成としてもよい。また、クライアントＰＣ２単体で、全ての処理を行うことで、個人利用での実現などに対応させることも可能である。

メールチェック装置１は、所定のチェックポリシーに基づき、クライアントが送信した要確認メールを検出するメールチェック部１１、要確認メールが検出された場合に、クライアントＰＣ２に確認依頼を送信する確認依頼部１２、確認依頼の応答であってキャンセルの有無を含む確認結果のログ情報を前記クライアントから取得して記憶装置に格納するログ格納部１３、格納した確認結果に基づいてキャンセル量または率を算出する算出部１４、および算出したキャンセル量または率にしたがってチェックポリシーを変更するポリシー変更部１５を有する。

本発明によれば、メールチェック装置１は、送信メールの確認のログを採取し、そのログを集計し、統計情報としてキャンセル量または率を算出する構成とすることによって、集計の単位を個人だけでなく、グループあるいは業務単位、組織単位等に対応させ、各単位に応じた傾向や状況が確認できる。これらの傾向や状況から、送信メールのポリシーへの適確なフィードバックが可能となる。

なお、メールチェック装置１は、図示していないが、ＣＰＵ（Central Processing Unit ）、メモリを有するコンピュータであり、上記各処理部を処理するプログラムは、起動時に記憶装置（例えば、記憶装置１００）からメモリに展開され、ＣＰＵによって実行される。

また、該プログラムは、フレキシブルディスク（ＦＤ）、光磁気ディスク（ＭＯ）、メモリースティック、コンパクトディスク（ＣＤ）などの可搬媒体に記録され、各媒体に対応した読取装置（図にない）によって読み込む構成としてもよい。

図２は、メールチェック装置１における機能ブロック図を示している。図１とあわせて、メールチェック装置１の各機能を以下に説明する。

メールチェック部１１は、メールチェック装置１から各クライアントＰＣ２に既に配信している現行ポリシーにしたがって要確認メールを検出し、確認依頼部１２が、要確認メールの確認を依頼し、ログ格納部１３が、各クライアントＰＣ２側の記憶装置２００に蓄積された確認結果としてのキャンセルログ（個人）を、任意のタイミングで収集し、当該収集したキャンセルログを管理単位毎に自記憶装置１００に格納する。

つぎに、算出部１４は、収集したキャンセルログを基に、管理単位毎のキャンセル量または率を算出し、ポリシー変更部１５が、管理単位毎のキャンセル量または率を分析し、ポリシー変更ルールを適用することで、現行ポリシーを適宜調整し、新規のポリシーを設定し、各クライアントに新規ポリシーをＬＡＮ４を介して配信する。

ポリシー変更部１５によって変更されたポリシーは、関係者全てに適用される必要がある。そのため、ＸＭＬ（Extensible Markup Language）ベースの構造化フォーマットで記述されるＲＳＳ（Really Simple Syndication ）配信の機能を利用して、定められた最新のポリシーを各関係者に強制的に配信し適用させる。

なお、ＲＳＳ配信では、装置起動時、メールチェックプログラムが起動されるタイミングで、最新のポリシー設定の存在を確認し、最新のものがあれば、自動的に更新する形態を実現している。

図３は、送信メールをチェックする際の基本ポリシーテーブルのデータ構造を示す。基本ポリシーテーブルは、ポリシーの項目と内容からなる複数のレコードで構成されている。

送信確認のポリシーとして、規約１−１：「社外アドレスのあるメールは確認表示を行う」、規約１−２：「送信アドレスが社内のみのメールは確認表示しない（スルー）」が規定されている。

また、警告表示のポリシーとして、規約２−１：「メールの宛先総数が20件を超えた場合に警告する」、規約２−２：「社外宛先のあるメールの本文、タイトル、添付ファイル名に社外秘キーワードを含む場合に警告する」、規約２−３：「タイトルがないメール」が規定されている。

さらに、ブロックのポリシーとして、規約３−１：「メールの宛先件数が200 件を超えているものはブロックする」が規定されている。

こうした基本ポリシーは、各クライアントに配信され、一定期間（例えば、１〜２週間）運用され、その運用の中で利用状況に関する動作ログが蓄積される。

図４は、クライアントＰＣ２に表示される送信メールの確認画面例を示す。

本確認画面例では、送信メールの案件として、件名、差出人、添付ファイルの有無、適用運用ポリシーの属性情報が表示される。また、警告メッセージ欄には、（１）抵触ルールとして「社外宛メールに社外秘情報が入っていませんか」など、（２）社内宛先として、Ｔｏ、Ｃｃ、Ｂｃｃの宛先種別、宛先名、メールアドレス、件数など、（３）社外宛先として、同様に、宛先種別、宛先名、メールアドレス、件数などが表示されている。

本確認画面による確認結果は、送信日付と時間、組織内の送信先、組織外の送信先、確認に関するポリシー内のチェック済ルールのＩＤ、送信メールの最終的なチェック結果、送信結果（ＯＫかブロックか）、および確認チェック処理に費やした時間をメール毎に関連付けられて各クライアントＰＣ２の記憶装置２００にログとして記録される。

組織内の送信先は、統計値として、Ｔｏ、Ｃｃ、Ｂｃｃを区別して整理、さらに、加えて、ホワイトリストによって予めチェック済の送信先数も、Ｔｏ、Ｃｃ、Ｂｃｃを区別して整理して記録される。

また、組織外の送信先は、統計値として、同様に、Ｔｏ、Ｃｃ、Ｂｃｃを区別して整理、加えてホワイトリストによって予めチェック済の送信先数も、Ｔｏ、Ｃｃ、Ｂｃｃを区別して整理している。さらに、組織外に関してブラックリストにある送信先の数が記録される。

また、送信メールの最終的なチェック結果は、ｃａｎｃｅｌ：取り消し／ｓｅｎｄ：送信／ｔｈｒｏｕｇｈ：確認なしで送信を区別して記録される。

これらクライアントＰＣ２に蓄積されたログ情報は、送信ポリシーを配信するメールチェック装置１で収集され、その収集した情報をもとに分析して、予め定めたポリシー変更ルールにしたがって、送信確認のためのポリシー内容を変更することとなる。

変更のタイミングや単位（区切り）などは、パターンから管理者が定めることによって、詳細なポリシーの変更がなされる。

以上、上述したクライアントＰＣ２で処理されるメール送信の確認は、利用しているメーラー（アプリケーション）に依存することなく、どのメーラからでも送信メールの送信先アドレスの確認（組織内や組織外、ドメイン、注意先や要注意先、ホワイトリストやブラックリストなど）を行い、この確認の結果、送信をキャンセル（取りやめ、取り戻し) したか、送信したかなどの状況、確認のために適用されたルール（抵触ルール) などの情報を日時情報とともにログとして蓄積することを前提としている。

図５は、ログ分析の事例を示す。事例は、図３に示した基本ポリシーを一定期間運用することで収集されたクライアントによる確認結果のログ情報を基に、送信メール数に対するキャンセル率を１日の時間帯別に算出したものである。

時間帯として、１２時、１６時、１７時は、キャンセル率が高い。すなわち、昼休み、退社前後など、キャンセル率の高い時間帯があることがわかる。このような時間帯に対しては、ポリシーを強化させるように、ポリシー変更ルール（図６に後述）を適用する。

なお、図５の本実施例では、キャンセル率の分析の単位を１日の時間帯別に示したが、本発明は、これに限らず、曜日、月度、あるいは年度等の時間軸で示してもよい。

このように、チェックポリシーは、集計されたログ情報に基づき、上記一日の時間帯、曜日、月度、あるいは年度を含む時間軸を単位として算出されたキャンセル量または率にしたがって変更されることとなる。

図６は、ポリシーの変更を規定するポリシー変更ルールテーブルのデータ構造を示す。ポリシー変更ルールテーブルは、分析パターンに対応した変更ポリシーのルールを示したものである。具体的内容は以下のとおりである。

分析パターン１：送信数が減少、キャンセル数が増加の場合、規制を厳しく強化し、「その１：ホワイトリストの自動学習機能をＯＦＦにする、その２：組織内外の添付ファイル送信を警告する」を適用する。

分析パターン２：送信数に変化なし、キャンセル数が増加の場合、規制を強化し、「警告する社外宛先件数を減らす( ２０→１０) 」を適用する。

分析パターン３：送信数が増加、キャンセル数が増加の場合、規制を強化し、「警告する宛先数を減らす( ２０→１０) 」を適用する。

分析パターン４：送信数が増加、キャンセル数変化なしの場合、現状維持とし、ポリシーに変更なし。

分析パターン５：送信数に関わらず、キャンセル数が減少する場合、規制を緩和し、「ホワイトリストの自動学習機能をＯＮにする」を適用する。

図７は、メールチェック装置１の動作フローを示す。まず、ステップＳ１１において、算出部１４は、各クライアント装置２から収集したキャンセルログを基に、例えば、１日の時間帯あるいは週などの組織体におけるインシデント（事象）単位毎に送信メール数に対するキャンセル率を算出するログ統計処理を行う。

つぎに、ステップＳ１２において、ログ統計処理で算出されたキャンセル率にしたがって、キャンセル率が変動する時間帯などの特徴となる事象単位を抽出する特徴抽出処理を行う。

そして、ステップＳ１３において、ポリシー変更部１５は、ポリシー変更ルールテーブルを参照し、分析パターンと照合し、対応する変更ポリシーが存在するか否かを判定する。該当する分析パターンが存在する場合には、ステップＳ１４において、対応する変更ポリシーを適用する。抽出した特徴とする全ての事象単位に対し、該当する分析パターンがなくなるまでステップＳ１３〜Ｓ１４の処理を繰り返す。

全ての特徴抽出した事象単位への対応が終わったら、ステップＳ１５において、現行ポリシーに代えて更新ポリシーを新規ポリシーとして各クライアントに配信する。

なお、上述したメールチェック装置１での集計は、様々な単位を設定できるが、クライアント側で集計させて、クライアント内で個人やそのクライアントＰＣ２の利用状況に応じたポリシーの設定を行わせることも可能である。

以上、本実施態様によれば、ポリシーの設定を、対象としたいインシデント（事象）に対して、人に依存せず、画一的に実現できる。また、処理状況に応じて、ポリシーの柔軟な対応を実現でき、インシデント発生前に、その兆候から対応することが可能となる。さらに、変更すべきポリシーの設定も、ネットワーク上で強要させることができ、セキュリティレベルを常に一定以上に保持することが可能となる。

図８は、ポリシー配信時における各クライアントへの個別情報の提供フローを示す。本実施例は、ＲＳＳ配信の際に、利用者毎にピンポイントで案内やコメント情報を提供するものである。

まず、ステップＳ２１において、メールチェック装置１は、クライアントから現在使用しているツールやポリシーのバージョン、利用メーラー等の情報を取得する。つぎに、各クライアント毎に、ステップＳ２２、Ｓ２４、およびＳ２６において、それぞれ、ポリシーのバージョン、ツールのバージョン、および利用メーラの情報がチェック済みか否かを判定する。チェック済みとなっていなければ、ステップＳ２３、Ｓ２５、およびＳ２７において、それぞれ、ポリシー、利用ツール、および利用メーラに応じた任意の提供情報を選択する。上記ステップＳ２２〜Ｓ２３、ステップＳ２４〜Ｓ２５、およびステップＳ２６〜Ｓ２７の処理を複数のクライアントに対し繰り返す。

全てのクライアントについてチェック済みとなったら、メールチェック装置１は、ステップＳ２８において、クライアントに提供すべき情報を整理し、ステップＳ２９において、各クライアントへの情報提供を行う。

以上のように、ポリシーバージョン、ツールバージョン、および利用メーラの情報に基づいて、クライアント側にピンポイントで任意の情報が提供できる。これにより、例えば、クライアント側は、システム起動時に、利用状況に応じて、任意のメッセージを受取ることができ、個別のシステム修正やバージョンアップの案内情報、指示などがタイムリーに受信することが可能となる。

企業体の組織毎にメール送信時のポリシーの内容を自動調整可能とするメール送信フィルタの技術分野。

１ メールチェック装置
２ クライアントＰＣ
３ メールサーバ
４ ネットワーク（ＬＡＮ）
５ 外部ネットワーク
１０ 記憶装置（キャンセルログ（全員））
１１ メールチェック部
１２ 確認依頼部
１３ ログ格納部
１４ 算出部
１５ ポリシー変更部
２０ 記憶装置（キャンセルログ（個人））

Claims (7)

1. ネットワークを介して複数のクライアント装置と接続するメールチェック装置であって、
   前記クライアント装置に配信済みの所定のチェックポリシーの表示に基づき、クライアントが要確認とした要確認メールを送信したときに、前記要確認メールを検出するメールチェック手段と、
   前記要確認メールが検出された場合に、前記クライアント装置に前記要確認メールに対する確認依頼を送信する確認依頼手段と、
   前記確認依頼の応答であって、前記クライアントが行ったキャンセルの有無を含む確認結果のログ情報を前記クライアント装置から取得して記憶装置に格納するログ格納手段と、
   格納した前記確認結果に基づいてキャンセル量または率を算出する算出手段と、
   前記キャンセル量または率の変動と関連する事象を抽出し、前記抽出した事象に対する対応をチェックポリシー変更ルールから選択し、前記選択したチェックポリシー変更ルールに基づいて変更したチェックポリシーを前記クライアント装置に配信するポリシー変更手段と、を有することを特徴とするメールチェック装置。
2. 前記ポリシー変更手段は、前記キャンセル量または率の変動と関連する事象に応じて、前記変更したチェックポリシーには、要確認メールの検出に係わるホワイトリストの学習の停止、添付ファイルの検出開始、検出に係わる宛先件数の閾値削減、の少なくとも１つを含むことを特徴とする請求項１に記載のメールチェック装置。
3. 前記算出手段は、前記クライアント装置からのログ情報を集計して、前記クライアントあるいは前記クライアントが属する対象グループにて定められた分類ごとに分析を行うことを特徴とする請求項１または２に記載のメールチェック装置。
4. 前記ポリシー変更手段によって変更されたチェックポリシーは、構造化フォーマットで記述されたＲＳＳ配信方式を用いて対象となる前記クライアント装置に配信されることを特徴とする請求項１乃至３のいずれか１項に記載のメールチェック装置。
5. 前記チェックポリシーは、前記集計されたログ情報を一日の時間帯、曜日、月度、および年度を含む時間軸で分析し、前記時間軸を単位として算出された前記キャンセル量または率の変動と関連する事象にしたがって変更されることを特徴とする請求項１及至４のいずれか１項に記載のメールチェック装置。
6. ネットワークを介して複数のクライアント装置と接続するメールチェック装置で処理されるメールチェックプログラムであって、
   コンピュータに、
   クライアント装置に配信済みの所定のチェックポリシーの表示に基づき、クライアントが要確認とした要確認メールを送信したときに、前記要確認メールを検出するメールチェックステップと、
   前記要確認メールが検出された場合に、前記クライアント装置に前記要確認メールに対する確認依頼を送信する確認依頼ステップと、
   前記確認依頼の応答であって、クライアントが行ったキャンセルの有無を含む確認結果のログ情報を前記クライアント装置から取得して記憶装置に格納するログ格納ステップと、
   格納した前記確認結果に基づいてキャンセル量または率を算出する算出ステップと、
   前記キャンセル量または率の変動と関連する事象を抽出し、前記抽出した事象に対する対応をチェックポリシー変更ルールから選択し、前記選択したチェックポリシー変更ルールに基づいて変更したチェックポリシーを前記クライアント装置に配信するポリシー変更ステップと、を実行させるメールチェックプログラム。
7. ネットワークを介して複数のクライアント装置と接続するメールチェック装置で処理されるメールチェック方法であって、
   クライアント装置に配信済みの所定のチェックポリシーの表示に基づき、クライアントが要確認とした要確認メールを送信したときに、前記要確認メールを検出するメールチェックステップと、
   前記要確認メールが検出された場合に、前記クライアント装置に前記要確認メールに対する確認依頼を送信する確認依頼ステップと、
   前記確認依頼の応答であって、クライアントが行ったキャンセルの有無を含む確認結果のログ情報を前記クライアント装置から取得して記憶装置に格納するログ格納ステップと、
   格納した前記確認結果に基づいてキャンセル量または率を算出する算出ステップと、
   前記キャンセル量または率の変動と関連する事象を抽出し、前記抽出した事象に対する対応をチェックポリシー変更ルールから選択し、前記選択したチェックポリシー変更ルールに基づいて変更したチェックポリシーを前記クライアント装置に配信するポリシー変更ステップと、を有することを特徴とするメールチェック方法。