電子メール保留システム及び方法
【課題】組織外への電子メール監査のために電子メール送信システム上で復号鍵通知メールをトラッキングし、暗号化電子メールの添付ファイルの復号を行う。
【解決手段】内部クライアントが外部クライアントへ送信した電子メールを保留するメール保留サーバが、電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを判断し、暗号化電子メールであれば復号鍵待ち保留状態に設定して保留メールデータベースに登録し、受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断し、復号鍵通知メールであれば復号鍵通知メールの復号鍵を復号鍵候補として用いて、復号鍵待ち保留状態にある暗号化電子メールの暗号化添付ファイルの復号を試み、正しく復号されれば復号鍵待ち保留状態の設定を解除し、外部クライアントへの送信を保留する状態に設定し、その後送信する。
【解決手段】内部クライアントが外部クライアントへ送信した電子メールを保留するメール保留サーバが、電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを判断し、暗号化電子メールであれば復号鍵待ち保留状態に設定して保留メールデータベースに登録し、受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断し、復号鍵通知メールであれば復号鍵通知メールの復号鍵を復号鍵候補として用いて、復号鍵待ち保留状態にある暗号化電子メールの暗号化添付ファイルの復号を試み、正しく復号されれば復号鍵待ち保留状態の設定を解除し、外部クライアントへの送信を保留する状態に設定し、その後送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メールを所定時間保留した後に送信する電子メールの保留に関し、特に暗号化された添付ファイルを監査可能な電子メール保留システム及び方法に関する。
【背景技術】
【０００２】
近年、営業秘密や個人情報を記載したファイルが電子メールに添付して送信され、その結果、組織外に情報が漏洩する事件が頻発し、社会問題にもなっている。こうした情報漏洩は、コンピュータ・ウィルスにより発生することも多いが、一方、電子メールの送信者が宛先や添付すべきファイルの指定を誤るといった誤操作によって発生することが多い。
【０００３】
このような電子メール送信時の誤操作による情報漏えいを防止するため、送信指示がなされた電子メールデータを端末装置上で取得し、電子メールの本文中に所定の規制語句が検出された場合は、送信者に対してアラーム（警告）メッセージを表示する技術が開示されている(特許文献１参照)。また、添付ファイルに記載されたポリシー(社外秘、人事課限定等) を読み取り、電子メールの宛先情報がそのポリシーに適合するかを判断し、ポリシーに適合しない宛先が含まれている場合は、その旨を送信者に通知する技術が開示されている(特許文献２参照) 。これらにより、情報漏えいの危険性が高い電子メールについてはその送信者に内容や宛先を再確認させ、誤操作であったと判断した場合は送信を取りやめることができるため、情報漏洩のリスクを低減することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−２２７０５６号公報
【特許文献２】特開２０１０−２６７６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１に開示された技術は、電子メール本文に関する監査のみであり、電子メールに添付されたファイルの内容までは考慮されていないため、メール本文に規制語句がなければ添付ファイルの内容が営業秘密であっても送信者に警告されることなく外部へ送信されてしまうという問題がある。様々な文書を電子ファイルで管理することが多い企業の実情からすると、電子メールに添付したファイルの内容まで監査できなければ適切な情報漏洩防止を図ることはできない。
【０００６】
一方、特許文献２に開示された技術では、添付ファイルの内容まで監査対象としているが、ファイルは平文で添付されることを前提としている。したがって、暗号化された添付ファイルが送信された場合には添付ファイルからポリシーを読み取れず、毎回電子メール送信者への問い合わせが発生することになり、送信者の負担は大きい。また、近年では、電子メール送信途中での情報漏えいを防止する観点からも、企業間のデータのやり取りでは、添付ファイルの暗号化は一般的に実施されているものであるため、暗号化した添付ファイルも適切に監査可能とすることが求められる。
【０００７】
本発明は、これらの課題を解決し、電子メールの添付ファイルが暗号化されている場合であっても、その内容を適切に監査可能とする電子メール保留システム及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、本発明は、以下の構成を提供する。
本発明の第１の態様は、内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバを備えた電子メール保留システムであって、前記メール保留サーバは、前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断する手段と、受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録する手段と、前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断する手段と、受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得する手段と、取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定する手段と、前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信する手段と、を備える。
【０００９】
上記システムにおいて、前記メール保留サーバは、前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録する手段と、前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、をさらに備えることが、好適である。
【００１０】
上記システムにおいて、前記メール保留サーバは、所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信する手段をさらに備えることが、好適である。
【００１１】
本発明の第２の態様は、内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバが行う電子メール保留方法であって、前記メール保留サーバは、前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断するステップと、受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録するステップと、前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断するステップと、受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得するステップと、取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定するステップと、前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信するステップと、を実行する。
【００１２】
上記方法において、前記メール保留サーバは、前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録するステップと、前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、をさらに実行することが、好適である。
【００１３】
上記方法において、前記メール保留サーバは、所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信するステップをさらに実行することが、好適である。
【発明の効果】
【００１４】
以上のように構成された本発明によれば、電子メールの添付ファイルが暗号化されている場合であっても、その復号鍵を電子メール送信システム上で自動的にトラッキングして復号することができ、暗号化されたファイルであってもその内容を監査可能にし、情報漏洩をより実効的に防止することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明に係る電子メール保留システムのシステム機能構成を示す図である。
【図２】本発明に係る保留メールＤＢの構成図である。
【図３】本発明に係る保留メールのデータ構成図 である。
【図４】本発明に係る復号鍵ＤＢの構成図である。
【図５】本発明に係る暗号化メール処理フローである。
【図６】本発明に係る復号鍵候補の取得処理フローである。
【発明を実施するための形態】
【００１６】
以下、本発明の実施例を示した図面を参照して実施形態を説明する。
図１は、本発明に係る電子メール保留システムのシステム構成図である。なお、明細書及び図面中「メール」と記載している場合、特に説明がない限り「電子メール」を意味する。
【００１７】
電子メール保留システムは、内部クライアント１、メール保留サーバ２、メールサーバ４、ルータ６、および外部クライアント５の各装置を、有線又は無線の通信回線により通信可能に接続したシステムである。各装置は１台ずつ図示しているが、それぞれ２以上存在していてもよい。また、各装置はそれぞれ１台ずつ存在する必要はなく、例えば、１台の装置が、メール保留サーバ２とメールサーバ４の両方の機能を備えるように構成することも可能である。
【００１８】
図１において、内部クライアント１、メール保留サーバ２、メールサーバ４、およびルータ６はＬＡＮ（Local Area Network）７によって互いに通信可能に接続されている。接続方法はＬＡＮに限定されるものではなく、互いに通信可能に接続されていればよい。また、図１においては、外部クライアント５がインターネット８によってＬＡＮ７と接続されているが、例えば、外部クライアント５がＬＡＮ７とは別のＬＡＮに接続されており、ルータ６がこれらのＬＡＮ同士を接続していても構わない。
【００１９】
内部クライアント１及び外部クライアント５は、メール送受信手段１１、５１を有する。これらはメール送受信プログラムであり、例えばＯＵＴＬＯＯＫ（登録商標）のような、いわゆるメーラソフトである。また、両クライアントはそれぞれ、入力装置１８、表示装置１９を備えている。
【００２０】
メール保留サーバ２は、内部クライアント１から送信されたメールの保留処理と、暗号化された添付ファイルの復号処理を実施する。
以下、メール保留サーバ２が有する各手段について説明する。
メール送受信手段２１は、例えばＳｅｎｄｍａｉｌ（登録商標）等の、いわゆるＳＭＴＰ（Simple Mail Transfer Protocol）サーバソフトであり、メールを送受信する機能を有している。
【００２１】
メール保留判定手段２２は、メール送受信手段２１がメールを受信した場合に、メール送受信手段２１によって起動され、受信したメールを所定時間保留する必要があるか否かを判定し、保留する必要があるメールを保留メールデータベース（ＤＢ）３２に記憶し、保留する必要がないメールは、直ちにメールサーバ４に送信する。すなわち、メール保留判定手段２２は、メール送受信手段２１の機能の一部を代替する。
【００２２】
保留メール送信手段２３は、いわゆるデーモン（ソフト）であり、メール保留サーバ２により（より正確にはメール保留サーバ２のオペレーティングシステムにより）所定の時間間隔で継続的に起動される。保留メール送信手段２３は、保留メールＤＢ３２に記憶された各メールについて、保留時間を経過したか否かを判定し、保留時間が経過したメールをメールサーバ４に送信する。そして、メールサーバ４に送信したメール（すなわち保留時間が経過したメール）を保留メールＤＢ３２から削除する。
【００２３】
暗号メール判断手段２４は、メール送受信手段２１がメールを受信した場合に、メール送受信手段２１によって起動され、受信したメールの添付ファイルが暗号化されているか否かを判断する処理である。この判断は、添付ファイルのファイル形式に基づいて行われる。暗号化判断可能なファイル形式については、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ（登録商標）製品の読み取りパスワードの設定、ＰＤＦのパスワード設定、パスワードＺＩＰなど一般的な形式のものから、秘文（登録商標）暗号化形式などの独自形式まで、いずれのファイル形式であってもよい。一般的なファイル形式の暗号化判断に関しては、ツール等による判断が可能である。独自形式の暗号化判断に関しては、その形式ごとの暗号化判断プログラム、ツール等を利用する。
【００２４】
復号鍵取得手段２５は、メール送受信手段２１がメールを受信した場合に、メール送受信手段２１によって起動され、受信したメールが復号鍵通知メールであるか否か、すなわちメール本文内に復号鍵が含まれているか否かを判断し、復号鍵が含まれていると判断した場合はその復号鍵を取得して復号鍵候補とするとともに、復号鍵ＤＢ３１に登録する。
【００２５】
暗号メール復号手段２６は、いわゆるデーモン（ソフト）であり、メール保留サーバ２により（より正確にはメール保留サーバ２のオペレーティングシステムにより）所定の時間間隔で継続的に起動される。暗号メール復号手段２６は、メール保留サーバ上にて復号鍵待ちで保留されているメール毎に、例えば、対応する復号鍵を復号鍵ＤＢ３１より抽出して復号鍵候補とし、復号化を試みる。復号化に成功すれば、暗号化メールの復号鍵待ち保留状態を解除する。復号不可または復号鍵候補がない場合は、まだ復号鍵通知メールがメール保留サーバに到達していないものと判断し、そのまま終了する。
【００２６】
復号鍵要求手段２７は、いわゆるデーモン（ソフト）であり、メール保留サーバ２により（より正確にはメール保留サーバ２のオペレーティングシステムにより）所定の時間間隔で継続的に起動される。復号鍵要求手段２７は、所定時間以上、復号鍵通知メール待ちのままとなった暗号化メール毎に、その送信者に対して復号鍵をメール保留サーバに連絡するよう促す復号鍵要求メールを作成し、メール保留サーバ２上のメール送信手段２１にて暗号化メールの送信者に復号鍵要求メールを送信する。
【００２７】
メール保留サーバ２は、保留メールＤＢ３２と復号鍵ＤＢ３１を有する記憶装置３と、入力装置２８、表示装置２９と接続されている。
【００２８】
保留メールＤＢ３２には、所定時間だけ保留した後に送信すべきメールが記憶されており、メール保留判定手段２３によって保留が必要と判断されるとそのメールに関する情報が追加される。そして、所定の保留時間を経過した場合や上長によるそのメールの送信承認がなされた場合など、所定の条件を満たした場合はメールの保留が解除されるので、そのメールに関する情報が削除される。
【００２９】
復号鍵ＤＢ３１は、復号鍵通知メールから取得した復号鍵を格納し、暗号メール復号手段２６に対して復号鍵候補を提供する。メールから復号鍵を検出するとその復号鍵に関する情報が追加される。
【００３０】
メールサーバ４はＰＣ等の装置であり、メール送受信手段４１（メール送受信プログラム）を備えている。メール送受信手段４１は、メール送受信手段２１と同様、ＳＭＴＰサーバソフトである。
【００３１】
ルータ６は、ＬＡＮ７に接続された装置以外の宛先に送信されるメールを、インターネット８に送信する。逆に、このような機能を備えている装置であればよく、必ずしもルータである必要はない。
【００３２】
インターネット８に送信されたメールは、図示していないが各種通信装置を経由して送信先（例えば外部クライアント５）が受信する。
【００３３】
図２は、保留メールＤＢ３２のデータ構成図である。
保留メールレコード２１０は、保留メールＩＤ２１１、保留開始時２１２、保留時間２１３、保留メール２１４及び保留ステータス２１５のデータ項目から構成される。
【００３４】
保留対象となったメール毎に、１つの保留メールレコード２１０が作成される。保留メールＩＤ２１１は、保留メールレコード２１０を一意に識別するための識別情報である。保留開始時刻２１２には、例えば“20080428131504”（２００８年４月２８日１３時１５分４秒）といったように、保留メールレコード２１０を追加する際の時刻が設定される。保留時間２１３には、例えば“001500”（０時間１５分０秒）といったように、保留メールレコード２１０の保留を継続する時間が設定される。
【００３５】
保留メール送信手段２３は、保留開始時刻２１２とシステム時刻を比較し、保留時間２１３が経過した場合に、保留メール２１４を送信する。保留メール２１４は、保留しているメールに内容が設定される。具体的には図３を用いて説明する。保留ステータス２１５は、そのメールの処理状況が設定される。例えば、所定の保留時間が経過する間メール送信を保留している場合は「一時保留中」、上長によるメール送信の承認を待つための保留の場合は「上長承認待ち」等、所定の条件を満たすまで外部クライアントへの送信を保留する保留状態となり、復号鍵を検出するために保留している場合は「復号鍵待ち」の保留状態となる。
【００３６】
なお、保留時間２１３は、メールの宛先(またはドメイン)と保留ステータスごとに保留時間を予め指定したテーブルを参照して設定する方法、または全てのメールに対して同じ保留時間を設定する方法のいずれを用いてもよい。
【００３７】
図３は、図２の保留メールＤＢ３２の中の保留メール２１４のデータ構成図である。
保留メール２１４は、メールエンベロープ３１５、メールヘッダ３１６、および本文３１７から構成される。
本文３１７は、内部クライアント１を操作する送信者が入力したメールの本文、およびメールに添付したファイルからなる。また、メールヘッダ３１６は、送信者が入力したメールの宛先、タイトル等を、メール送受信手段２１が編集した結果データからなる。すなわち、メールヘッダ３１６、および本文３１７は、内部クライアント１がメール保留サーバ２に送信したメールの内容である。
【００３８】
メールエンベロープ３１５は、メールの送信元（mail from）と、１以上の宛先（rcpt to）から構成され、メール保留判定手段２２が受信したメールから作成する。内部クライアント１を操作する送信者は、宛先としてメーリングリストのアドレス等、実際の宛先とは異なる宛先を入力する場合がある。そこで、メール保留判定手段２２は、メールを受信すると、メールに設定されている（送信者が入力した）宛先を実際の宛先に変換して宛先（rcpt to）を作成する。そして、送信元（mail from）と宛先（rcpt to）をメールエンベロープ３１５としてメールに追加する。
【００３９】
図４は、復号鍵ＤＢ３１のデータ構成図である。
復号鍵レコード４１０は、登録日４１１、復号鍵４１２、通知件名４１３、通知送信者（ヘッダ）４１４、通知宛先(エンベロープ) ４１５、通知宛先（ヘッダ）４１６、復号成功回数４１７及び最終復号日時４１８のデータ項目から構成される。
【００４０】
登録日４１１は、復号鍵取得手段２５により復号鍵を取得して復号鍵ＤＢ３１に登録した日、復号鍵４１２はパスワード等の鍵の内容である。通知件名４１３は復号鍵を取得したメールの件名、通知送信者（ヘッダ）４１４と通知宛先（ヘッダ）４１６は復号鍵を取得したメールのメールヘッダ３１６に含まれているメール送信者とメール宛先の電子メールアドレス、通知宛先(エンベロープ) ４１５は、復号鍵を取得したメールの図３に示したエンベロープ３１５に含まれるメール宛先の電子メールアドレスである。さらに、復号成功回数４１７は、その復号鍵を用いて暗号化ファイルの復号に成功した回数、最終復号日時４１８は、最後にその復号鍵を用いて暗号化ファイルを復号した日時を意味する。
【００４１】
このように復号鍵を登録しておくことで、暗号化された送信メールをアーカイブしても、監査したいタイミングで復号化されたデータを確認できるため、アーカイブデータとしての有用性も高まる。
【００４２】
なお、復号鍵ＤＢ３１は蓄積型であるが、復号鍵レコード４１０の復号成功回数４１７や最終復号日時４１８の情報から今後利用される可能性の低い復号鍵レコード４１０の除去を定期的に行ってもよい。
【００４３】
図５は、図１のメール保留サーバ２における暗号化メール処理フローである。以下の説明においては、図１〜図４中の符号を適宜参照する。
内部クライアント１から外部クライアント５に送信した電子メールはメール保留サーバ２にて受信され（ステップ５０１）、暗号メール判断手段２４によってその電子メールの添付ファイルが暗号化されているか否か（すなわち暗号化電子メールであるか非暗号化電子メールであるか）を判断する（ステップ５０２）。
【００４４】
非暗号化電子メールであれば、非暗号化電子メールの保留状態である「一時保留中」や「上長承認待ち」等を保留ステータス２１５として保留メールＤＢ３２にその電子メールに関する情報を登録する。同時に保留時間経過待ちまたは上長承認待ち処理等、所定の条件を満たすまで外部クライアントへの送信を保留する待ち処理へ移行する。この場合は、送信者が設定した保留時間経過または上長が承認した時点で、外部クライアント５宛に電子メールが送信される。または、電子メール送信システム上であらかじめ定められたセキュリティポリシ(例えばメール本文や添付ファイルの「社外秘」の文字や、「機密情報」のような語句がある場合など) により、メールの内容によってはメール送信がキャンセルされる。
【００４５】
ステップ５０２において、暗号化電子メールであると判断すると、復号鍵を取得するために、その暗号化電子メールは所定時間の間、メール保留サーバ２上に保留される。この場合、保留ステータス２１５を「復号鍵待ち」保留状態に設定して、その他の電子メールに関する情報とともに保留メールＤＢ３２に登録される（ステップ５０３）。
【００４６】
メール保留サーバ２は、所定時間、メール保留サーバ２を経由する外部クライアント５宛の電子メールについて、復号鍵通知メールの有無を監視する(ステップ５０４)。送信者が手動で設定したパスワード等の復号鍵は、通常、暗号化電子メールとは別に、後から電子メールで通知することが多いためである。
【００４７】
メール保留サーバ２は、復号鍵通知メールを検出すると、その復号鍵通知メールに含まれる復号鍵を復号鍵候補として取得し、取得した復号鍵候補を用いて、保留ステータス２１５が「復号鍵待ち」保留状態となっている暗号化電子メールの暗号化添付ファイルの復号処理を試み(ステップ５０６)、復号が可能か否かを判断する（ステップ５０７）。復号不能の場合（復号鍵が正しくない場合）は、再び復号鍵通知メールを監視する(ステップ５０４)。
【００４８】
なお、復号鍵通知メールを監視する所定時間が経過したか否かを計時し（ステップ５０５）、所定時間経過しても復号鍵候補を取得できない場合(復号鍵候補の取得処理をタイムアウトした場合)は復号を断念し、「復号鍵待ち」保留状態の対象の暗号化電子メールをメール保留サーバ２から削除し、保留メールＤＢ３２からも該当保留メールレコード２１０を削除する(ステップ５１１)。さらに、暗号化された添付ファイルの内容を監査できないためメール送信できない旨を、メール保留サーバ２から「復号鍵待ち」保留状態の対象の暗号化電子メールの送信者に通知する（ステップ５１１）。
【００４９】
ステップ５０７において、取得した復号鍵候補を用いて暗号化添付ファイルを正しく復号できた場合は、その復号鍵を復号鍵ＤＢ３１に登録し(ステップ５０８)、暗号化添付ファイルの平文データを保留対象の電子メールとする（ステップ５０９）。そして、保留ステータス２１５の「復号鍵待ち」の設定を解除し、非暗号化電子メールと同様の「一時保留中」又は「上長承認待ち」等に設定し(ステップ５１０)、保留時間経過待ちまたは上長承認待ち処理へ移行する。すなわち、所定の条件を満たすまで送信を保留する待ち状態に移行する。これにより、例えば上長承認が必要とされる電子メールの場合、上長は添付ファイルの内容まで確認したうえで外部クライアント５等への電子メール送信の可否を判断できるため、実効的な情報漏洩の防止が可能である。そして、電子メール送信者から別途上長に対してパスワード等の復号鍵情報を送付する必要がないため、電子メール送信者の負担も軽減できる。
【００５０】
図６は、図５のメール保留サーバ２における復号鍵候補の取得処理フロー５０４の詳細フローである。
メール保留サーバ２は、自身に送信されてくる電子メールが復号鍵を有するか否かをチェックする（ステップ６０１）。
【００５１】
電子メールから復号鍵を検出する方法の１つとして、メール本文内にある復号鍵を示唆するキーワードに基づいて検出する方法がある。具体的には、「パスワード」、「Password」、「Pass」等の語句をキーワードとして、このようなキーワードがメール本文中に記載されていた場合、その前後の文章から半角英数の文字列を抽出して復号鍵候補とする。また、「：」や「；」等の区切り記号をキーワードとして、その直後に半角英数の文字列が続いている場合はそれを復号鍵候補として抽出することも考えられる。
【００５２】
その他の復号鍵を検出する方法としては、復号鍵を相手方に通知する場合は、暗号化した添付ファイルを送付した電子メールに返信する形で通知することが多いため、保留対象の電子メールに対する返信メールや転送メールが送信された場合は、その電子メールにおいて新規に追記された部分(例えば文頭が「>」から始まっていない行) に着目して半角英数の文字列を抽出することも考えられる。
【００５３】
このような復号鍵検出を効率よく実施するために、パスワードの性質を利用することも考えられる。例えば、パスワードの多くは半角英数で３文字程度から長くても２０文字程度で構成され、間に空白は含まないため、前述のようにキーワードに基づいて取得した復号鍵候補に対しパスワードの性質に一致するか否かによりフィルタリングすることで、通常の英文との混同を回避できる。また、パスワードの性質を会社内で定めている場合(例えば「パスワードは8文字以上12文字以内で英数を併用すること」といった規定) は、その性質を利用してフィルタリングをかければより効率よくパスワードを取得できる。
【００５４】
さらに、メール本文中に「パスワードはいつもの形式です」というようなセンテンスを検出した場合は、この電子メールの送信者や宛先、件名と、復号鍵ＤＢ３１に登録された各復号鍵レコード４１０の通知件名４１３、通知送信者（ヘッダ）４１４、通知宛先（ヘッダ）４１６、通知宛先（エンベロープ）４１５を照らし合わせ、復号鍵候補を抽出することも可能である。
【００５５】
復号鍵通知メールと思われる電子メールを検出した場合、そのメール本文より復号鍵を取得し、復号鍵候補の取得処理を終了する。復号鍵通知メールを検出できない場合は、所定時間が経過するまで復号鍵候補を有する電子メールを待つ（ステップ６０２、ステップ６０３）。
【００５６】
復号鍵が取得できないままで所定時間が経過した場合は、復号鍵の送信を求める催促メールを、「復号鍵待ち」保留状態の対象電子メールの送信者に送信し（ステップ６０２、ステップ６０４）、送信者から復号鍵が通知されるのを待つ( ステップ６０５)。メール保留サーバ２は、自身宛てに送信されてくる電子メールが復号鍵を有するかチェックする（ステップ６０６）。復号鍵通知メールと思われる電子メールを検知した場合はそのメール本文より復号鍵を取得して復号鍵取得処理を終了する。一方で、送信者から復号鍵を通知するメールが所定時間経過しても送られてこない場合は復号鍵待ちを断念し、タイムアウトしたとして復号鍵候補の取得処理を終了する( ステップ６０７)。
【００５７】
なお、本実施例では暗号化された添付ファイルを正常に復号できた復号鍵のみを復号鍵ＤＢ３１に登録するものとして記載したが、復号鍵候補の取得処理において復号鍵候補として検出したものは一律に復号鍵ＤＢ３１に登録するようにしてもよい。このような場合、不要な復号鍵レコード４１０が累積的に蓄積しやすいので、登録日４１１から一定期間経過し、かつ復号成功回数４１７が0回のままの復号鍵候補や、最終復号日時４１８から一定期間を経過した復号鍵候補がないか定期的にチェックし、復号鍵ＤＢ３１を定期的に整理する方が適切である。
【００５８】
さらに、本実施例では個々の「復号鍵待ち」保留状態の電子メールに対して復号鍵を取得する時間を設ける処理を記載したが、メール通信プロトコル実装上、復号鍵通知メールが暗号化電子メールよりも先にメール保留サーバ２に到達する可能性もあるため、「復号鍵待ち」保留状態の電子メール毎に復号鍵通知メールを監視するのではなく、メール保留サーバに到達した全ての電子メールに対して、復号鍵が格納されていないか検査を行う方がより適切である。
【００５９】
また、復号鍵候補を取得する方法については他の方法も考えられる。
パスワード等の復号鍵はプロジェクトとして過去のものを使いまわすことが多い。例えば、最初にある復号鍵を決めておき、その後はそのプロジェクト内では同じ復号鍵を用いることをルールとするような場合である。したがって、暗号化されたファイルが添付されている電子メールの件名や本文からプロジェクト名を推定し、復号鍵ＤＢ３１の通知件名４１３等の情報からプロジェクト名が一致するものを探し、その復号鍵を復号鍵候補としてもよい。この場合、復号鍵候補の取得処理(ステップ５０４)においては、復号鍵が付された電子メールからプロジェクト名を推測し、復号鍵ＤＢ３１に登録しておく方がより効率的と考えられる。
【００６０】
さらに、電子メール以外（例えば電話やFAX等）で復号鍵をやり取りしている場合には、復号鍵通知メールがメール保留サーバ２を経由しない。このようなケースに対応するため、復号鍵通知メール取得のため所定時間以上経過した保留メールに対して、メール保留サーバ２はメール送信者に対して、復号鍵要求メールを送信する手段を設けることも可能である。復号鍵要求メールを受け取った当該保留メールの送信者は、その復号鍵要求メールに対する返信メールのメール本文に復号鍵を記載してメール保留サーバ２に返信する。この場合、復号鍵ＤＢ３１に、復号鍵文字列、日付、送信者、宛先、件名として格納しておくことで、前述の復号鍵候補の検出に用いることができ、毎回暗号化電子メールが送信されるたびに送信者に対して復号鍵の要求を行わなくてもすむ可能性が高くなる。
【００６１】
さらに、所定時間以上経過した保留メールに対する復号鍵の特定は、復号鍵ＤＢ３１に登録されている複数の復号鍵を順次適用して行ってもよい。この場合、復号鍵レコード４１０の復号成功回数４１７から、過去に正常復号できた実績のある復号鍵を優先的に使用して、添付ファイルの復号を試みるようにしてもよい。
【００６２】
また復号鍵として日付を含んだ形式であると判断できる場合は、メール送信日時の値を変換して復号鍵とすることも考えられる。
【００６３】
以上、本実施形態について説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。例えば、上記実施形態では、電子メールにファイルを添付する際に添付ファイルの検査を行ったが、電子メールが送信されるまでの任意のタイミングで検査を行って良い。その他、上記実施形態に、種々の変更または改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。
【符号の説明】
【００６４】
１ 内部クライアント
２ メール保留サーバ
４ メールサーバ
５ 外部クライアント
３１ 保留メールデータベース
３２ 復号鍵データベース
３１４ 保留メール
２１０ 保留メールレコード
４１０ 復号鍵レコード
【技術分野】
【０００１】
本発明は、電子メールを所定時間保留した後に送信する電子メールの保留に関し、特に暗号化された添付ファイルを監査可能な電子メール保留システム及び方法に関する。
【背景技術】
【０００２】
近年、営業秘密や個人情報を記載したファイルが電子メールに添付して送信され、その結果、組織外に情報が漏洩する事件が頻発し、社会問題にもなっている。こうした情報漏洩は、コンピュータ・ウィルスにより発生することも多いが、一方、電子メールの送信者が宛先や添付すべきファイルの指定を誤るといった誤操作によって発生することが多い。
【０００３】
このような電子メール送信時の誤操作による情報漏えいを防止するため、送信指示がなされた電子メールデータを端末装置上で取得し、電子メールの本文中に所定の規制語句が検出された場合は、送信者に対してアラーム（警告）メッセージを表示する技術が開示されている(特許文献１参照)。また、添付ファイルに記載されたポリシー(社外秘、人事課限定等) を読み取り、電子メールの宛先情報がそのポリシーに適合するかを判断し、ポリシーに適合しない宛先が含まれている場合は、その旨を送信者に通知する技術が開示されている(特許文献２参照) 。これらにより、情報漏えいの危険性が高い電子メールについてはその送信者に内容や宛先を再確認させ、誤操作であったと判断した場合は送信を取りやめることができるため、情報漏洩のリスクを低減することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−２２７０５６号公報
【特許文献２】特開２０１０−２６７６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１に開示された技術は、電子メール本文に関する監査のみであり、電子メールに添付されたファイルの内容までは考慮されていないため、メール本文に規制語句がなければ添付ファイルの内容が営業秘密であっても送信者に警告されることなく外部へ送信されてしまうという問題がある。様々な文書を電子ファイルで管理することが多い企業の実情からすると、電子メールに添付したファイルの内容まで監査できなければ適切な情報漏洩防止を図ることはできない。
【０００６】
一方、特許文献２に開示された技術では、添付ファイルの内容まで監査対象としているが、ファイルは平文で添付されることを前提としている。したがって、暗号化された添付ファイルが送信された場合には添付ファイルからポリシーを読み取れず、毎回電子メール送信者への問い合わせが発生することになり、送信者の負担は大きい。また、近年では、電子メール送信途中での情報漏えいを防止する観点からも、企業間のデータのやり取りでは、添付ファイルの暗号化は一般的に実施されているものであるため、暗号化した添付ファイルも適切に監査可能とすることが求められる。
【０００７】
本発明は、これらの課題を解決し、電子メールの添付ファイルが暗号化されている場合であっても、その内容を適切に監査可能とする電子メール保留システム及び方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記の目的を達成するために、本発明は、以下の構成を提供する。
本発明の第１の態様は、内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバを備えた電子メール保留システムであって、前記メール保留サーバは、前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断する手段と、受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録する手段と、前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断する手段と、受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得する手段と、取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定する手段と、前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信する手段と、を備える。
【０００９】
上記システムにおいて、前記メール保留サーバは、前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録する手段と、前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、をさらに備えることが、好適である。
【００１０】
上記システムにおいて、前記メール保留サーバは、所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信する手段をさらに備えることが、好適である。
【００１１】
本発明の第２の態様は、内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバが行う電子メール保留方法であって、前記メール保留サーバは、前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断するステップと、受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録するステップと、前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断するステップと、受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得するステップと、取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定するステップと、前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信するステップと、を実行する。
【００１２】
上記方法において、前記メール保留サーバは、前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録するステップと、前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、をさらに実行することが、好適である。
【００１３】
上記方法において、前記メール保留サーバは、所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信するステップをさらに実行することが、好適である。
【発明の効果】
【００１４】
以上のように構成された本発明によれば、電子メールの添付ファイルが暗号化されている場合であっても、その復号鍵を電子メール送信システム上で自動的にトラッキングして復号することができ、暗号化されたファイルであってもその内容を監査可能にし、情報漏洩をより実効的に防止することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明に係る電子メール保留システムのシステム機能構成を示す図である。
【図２】本発明に係る保留メールＤＢの構成図である。
【図３】本発明に係る保留メールのデータ構成図 である。
【図４】本発明に係る復号鍵ＤＢの構成図である。
【図５】本発明に係る暗号化メール処理フローである。
【図６】本発明に係る復号鍵候補の取得処理フローである。
【発明を実施するための形態】
【００１６】
以下、本発明の実施例を示した図面を参照して実施形態を説明する。
図１は、本発明に係る電子メール保留システムのシステム構成図である。なお、明細書及び図面中「メール」と記載している場合、特に説明がない限り「電子メール」を意味する。
【００１７】
電子メール保留システムは、内部クライアント１、メール保留サーバ２、メールサーバ４、ルータ６、および外部クライアント５の各装置を、有線又は無線の通信回線により通信可能に接続したシステムである。各装置は１台ずつ図示しているが、それぞれ２以上存在していてもよい。また、各装置はそれぞれ１台ずつ存在する必要はなく、例えば、１台の装置が、メール保留サーバ２とメールサーバ４の両方の機能を備えるように構成することも可能である。
【００１８】
図１において、内部クライアント１、メール保留サーバ２、メールサーバ４、およびルータ６はＬＡＮ（Local Area Network）７によって互いに通信可能に接続されている。接続方法はＬＡＮに限定されるものではなく、互いに通信可能に接続されていればよい。また、図１においては、外部クライアント５がインターネット８によってＬＡＮ７と接続されているが、例えば、外部クライアント５がＬＡＮ７とは別のＬＡＮに接続されており、ルータ６がこれらのＬＡＮ同士を接続していても構わない。
【００１９】
内部クライアント１及び外部クライアント５は、メール送受信手段１１、５１を有する。これらはメール送受信プログラムであり、例えばＯＵＴＬＯＯＫ（登録商標）のような、いわゆるメーラソフトである。また、両クライアントはそれぞれ、入力装置１８、表示装置１９を備えている。
【００２０】
メール保留サーバ２は、内部クライアント１から送信されたメールの保留処理と、暗号化された添付ファイルの復号処理を実施する。
以下、メール保留サーバ２が有する各手段について説明する。
メール送受信手段２１は、例えばＳｅｎｄｍａｉｌ（登録商標）等の、いわゆるＳＭＴＰ（Simple Mail Transfer Protocol）サーバソフトであり、メールを送受信する機能を有している。
【００２１】
メール保留判定手段２２は、メール送受信手段２１がメールを受信した場合に、メール送受信手段２１によって起動され、受信したメールを所定時間保留する必要があるか否かを判定し、保留する必要があるメールを保留メールデータベース（ＤＢ）３２に記憶し、保留する必要がないメールは、直ちにメールサーバ４に送信する。すなわち、メール保留判定手段２２は、メール送受信手段２１の機能の一部を代替する。
【００２２】
保留メール送信手段２３は、いわゆるデーモン（ソフト）であり、メール保留サーバ２により（より正確にはメール保留サーバ２のオペレーティングシステムにより）所定の時間間隔で継続的に起動される。保留メール送信手段２３は、保留メールＤＢ３２に記憶された各メールについて、保留時間を経過したか否かを判定し、保留時間が経過したメールをメールサーバ４に送信する。そして、メールサーバ４に送信したメール（すなわち保留時間が経過したメール）を保留メールＤＢ３２から削除する。
【００２３】
暗号メール判断手段２４は、メール送受信手段２１がメールを受信した場合に、メール送受信手段２１によって起動され、受信したメールの添付ファイルが暗号化されているか否かを判断する処理である。この判断は、添付ファイルのファイル形式に基づいて行われる。暗号化判断可能なファイル形式については、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ（登録商標）製品の読み取りパスワードの設定、ＰＤＦのパスワード設定、パスワードＺＩＰなど一般的な形式のものから、秘文（登録商標）暗号化形式などの独自形式まで、いずれのファイル形式であってもよい。一般的なファイル形式の暗号化判断に関しては、ツール等による判断が可能である。独自形式の暗号化判断に関しては、その形式ごとの暗号化判断プログラム、ツール等を利用する。
【００２４】
復号鍵取得手段２５は、メール送受信手段２１がメールを受信した場合に、メール送受信手段２１によって起動され、受信したメールが復号鍵通知メールであるか否か、すなわちメール本文内に復号鍵が含まれているか否かを判断し、復号鍵が含まれていると判断した場合はその復号鍵を取得して復号鍵候補とするとともに、復号鍵ＤＢ３１に登録する。
【００２５】
暗号メール復号手段２６は、いわゆるデーモン（ソフト）であり、メール保留サーバ２により（より正確にはメール保留サーバ２のオペレーティングシステムにより）所定の時間間隔で継続的に起動される。暗号メール復号手段２６は、メール保留サーバ上にて復号鍵待ちで保留されているメール毎に、例えば、対応する復号鍵を復号鍵ＤＢ３１より抽出して復号鍵候補とし、復号化を試みる。復号化に成功すれば、暗号化メールの復号鍵待ち保留状態を解除する。復号不可または復号鍵候補がない場合は、まだ復号鍵通知メールがメール保留サーバに到達していないものと判断し、そのまま終了する。
【００２６】
復号鍵要求手段２７は、いわゆるデーモン（ソフト）であり、メール保留サーバ２により（より正確にはメール保留サーバ２のオペレーティングシステムにより）所定の時間間隔で継続的に起動される。復号鍵要求手段２７は、所定時間以上、復号鍵通知メール待ちのままとなった暗号化メール毎に、その送信者に対して復号鍵をメール保留サーバに連絡するよう促す復号鍵要求メールを作成し、メール保留サーバ２上のメール送信手段２１にて暗号化メールの送信者に復号鍵要求メールを送信する。
【００２７】
メール保留サーバ２は、保留メールＤＢ３２と復号鍵ＤＢ３１を有する記憶装置３と、入力装置２８、表示装置２９と接続されている。
【００２８】
保留メールＤＢ３２には、所定時間だけ保留した後に送信すべきメールが記憶されており、メール保留判定手段２３によって保留が必要と判断されるとそのメールに関する情報が追加される。そして、所定の保留時間を経過した場合や上長によるそのメールの送信承認がなされた場合など、所定の条件を満たした場合はメールの保留が解除されるので、そのメールに関する情報が削除される。
【００２９】
復号鍵ＤＢ３１は、復号鍵通知メールから取得した復号鍵を格納し、暗号メール復号手段２６に対して復号鍵候補を提供する。メールから復号鍵を検出するとその復号鍵に関する情報が追加される。
【００３０】
メールサーバ４はＰＣ等の装置であり、メール送受信手段４１（メール送受信プログラム）を備えている。メール送受信手段４１は、メール送受信手段２１と同様、ＳＭＴＰサーバソフトである。
【００３１】
ルータ６は、ＬＡＮ７に接続された装置以外の宛先に送信されるメールを、インターネット８に送信する。逆に、このような機能を備えている装置であればよく、必ずしもルータである必要はない。
【００３２】
インターネット８に送信されたメールは、図示していないが各種通信装置を経由して送信先（例えば外部クライアント５）が受信する。
【００３３】
図２は、保留メールＤＢ３２のデータ構成図である。
保留メールレコード２１０は、保留メールＩＤ２１１、保留開始時２１２、保留時間２１３、保留メール２１４及び保留ステータス２１５のデータ項目から構成される。
【００３４】
保留対象となったメール毎に、１つの保留メールレコード２１０が作成される。保留メールＩＤ２１１は、保留メールレコード２１０を一意に識別するための識別情報である。保留開始時刻２１２には、例えば“20080428131504”（２００８年４月２８日１３時１５分４秒）といったように、保留メールレコード２１０を追加する際の時刻が設定される。保留時間２１３には、例えば“001500”（０時間１５分０秒）といったように、保留メールレコード２１０の保留を継続する時間が設定される。
【００３５】
保留メール送信手段２３は、保留開始時刻２１２とシステム時刻を比較し、保留時間２１３が経過した場合に、保留メール２１４を送信する。保留メール２１４は、保留しているメールに内容が設定される。具体的には図３を用いて説明する。保留ステータス２１５は、そのメールの処理状況が設定される。例えば、所定の保留時間が経過する間メール送信を保留している場合は「一時保留中」、上長によるメール送信の承認を待つための保留の場合は「上長承認待ち」等、所定の条件を満たすまで外部クライアントへの送信を保留する保留状態となり、復号鍵を検出するために保留している場合は「復号鍵待ち」の保留状態となる。
【００３６】
なお、保留時間２１３は、メールの宛先(またはドメイン)と保留ステータスごとに保留時間を予め指定したテーブルを参照して設定する方法、または全てのメールに対して同じ保留時間を設定する方法のいずれを用いてもよい。
【００３７】
図３は、図２の保留メールＤＢ３２の中の保留メール２１４のデータ構成図である。
保留メール２１４は、メールエンベロープ３１５、メールヘッダ３１６、および本文３１７から構成される。
本文３１７は、内部クライアント１を操作する送信者が入力したメールの本文、およびメールに添付したファイルからなる。また、メールヘッダ３１６は、送信者が入力したメールの宛先、タイトル等を、メール送受信手段２１が編集した結果データからなる。すなわち、メールヘッダ３１６、および本文３１７は、内部クライアント１がメール保留サーバ２に送信したメールの内容である。
【００３８】
メールエンベロープ３１５は、メールの送信元（mail from）と、１以上の宛先（rcpt to）から構成され、メール保留判定手段２２が受信したメールから作成する。内部クライアント１を操作する送信者は、宛先としてメーリングリストのアドレス等、実際の宛先とは異なる宛先を入力する場合がある。そこで、メール保留判定手段２２は、メールを受信すると、メールに設定されている（送信者が入力した）宛先を実際の宛先に変換して宛先（rcpt to）を作成する。そして、送信元（mail from）と宛先（rcpt to）をメールエンベロープ３１５としてメールに追加する。
【００３９】
図４は、復号鍵ＤＢ３１のデータ構成図である。
復号鍵レコード４１０は、登録日４１１、復号鍵４１２、通知件名４１３、通知送信者（ヘッダ）４１４、通知宛先(エンベロープ) ４１５、通知宛先（ヘッダ）４１６、復号成功回数４１７及び最終復号日時４１８のデータ項目から構成される。
【００４０】
登録日４１１は、復号鍵取得手段２５により復号鍵を取得して復号鍵ＤＢ３１に登録した日、復号鍵４１２はパスワード等の鍵の内容である。通知件名４１３は復号鍵を取得したメールの件名、通知送信者（ヘッダ）４１４と通知宛先（ヘッダ）４１６は復号鍵を取得したメールのメールヘッダ３１６に含まれているメール送信者とメール宛先の電子メールアドレス、通知宛先(エンベロープ) ４１５は、復号鍵を取得したメールの図３に示したエンベロープ３１５に含まれるメール宛先の電子メールアドレスである。さらに、復号成功回数４１７は、その復号鍵を用いて暗号化ファイルの復号に成功した回数、最終復号日時４１８は、最後にその復号鍵を用いて暗号化ファイルを復号した日時を意味する。
【００４１】
このように復号鍵を登録しておくことで、暗号化された送信メールをアーカイブしても、監査したいタイミングで復号化されたデータを確認できるため、アーカイブデータとしての有用性も高まる。
【００４２】
なお、復号鍵ＤＢ３１は蓄積型であるが、復号鍵レコード４１０の復号成功回数４１７や最終復号日時４１８の情報から今後利用される可能性の低い復号鍵レコード４１０の除去を定期的に行ってもよい。
【００４３】
図５は、図１のメール保留サーバ２における暗号化メール処理フローである。以下の説明においては、図１〜図４中の符号を適宜参照する。
内部クライアント１から外部クライアント５に送信した電子メールはメール保留サーバ２にて受信され（ステップ５０１）、暗号メール判断手段２４によってその電子メールの添付ファイルが暗号化されているか否か（すなわち暗号化電子メールであるか非暗号化電子メールであるか）を判断する（ステップ５０２）。
【００４４】
非暗号化電子メールであれば、非暗号化電子メールの保留状態である「一時保留中」や「上長承認待ち」等を保留ステータス２１５として保留メールＤＢ３２にその電子メールに関する情報を登録する。同時に保留時間経過待ちまたは上長承認待ち処理等、所定の条件を満たすまで外部クライアントへの送信を保留する待ち処理へ移行する。この場合は、送信者が設定した保留時間経過または上長が承認した時点で、外部クライアント５宛に電子メールが送信される。または、電子メール送信システム上であらかじめ定められたセキュリティポリシ(例えばメール本文や添付ファイルの「社外秘」の文字や、「機密情報」のような語句がある場合など) により、メールの内容によってはメール送信がキャンセルされる。
【００４５】
ステップ５０２において、暗号化電子メールであると判断すると、復号鍵を取得するために、その暗号化電子メールは所定時間の間、メール保留サーバ２上に保留される。この場合、保留ステータス２１５を「復号鍵待ち」保留状態に設定して、その他の電子メールに関する情報とともに保留メールＤＢ３２に登録される（ステップ５０３）。
【００４６】
メール保留サーバ２は、所定時間、メール保留サーバ２を経由する外部クライアント５宛の電子メールについて、復号鍵通知メールの有無を監視する(ステップ５０４)。送信者が手動で設定したパスワード等の復号鍵は、通常、暗号化電子メールとは別に、後から電子メールで通知することが多いためである。
【００４７】
メール保留サーバ２は、復号鍵通知メールを検出すると、その復号鍵通知メールに含まれる復号鍵を復号鍵候補として取得し、取得した復号鍵候補を用いて、保留ステータス２１５が「復号鍵待ち」保留状態となっている暗号化電子メールの暗号化添付ファイルの復号処理を試み(ステップ５０６)、復号が可能か否かを判断する（ステップ５０７）。復号不能の場合（復号鍵が正しくない場合）は、再び復号鍵通知メールを監視する(ステップ５０４)。
【００４８】
なお、復号鍵通知メールを監視する所定時間が経過したか否かを計時し（ステップ５０５）、所定時間経過しても復号鍵候補を取得できない場合(復号鍵候補の取得処理をタイムアウトした場合)は復号を断念し、「復号鍵待ち」保留状態の対象の暗号化電子メールをメール保留サーバ２から削除し、保留メールＤＢ３２からも該当保留メールレコード２１０を削除する(ステップ５１１)。さらに、暗号化された添付ファイルの内容を監査できないためメール送信できない旨を、メール保留サーバ２から「復号鍵待ち」保留状態の対象の暗号化電子メールの送信者に通知する（ステップ５１１）。
【００４９】
ステップ５０７において、取得した復号鍵候補を用いて暗号化添付ファイルを正しく復号できた場合は、その復号鍵を復号鍵ＤＢ３１に登録し(ステップ５０８)、暗号化添付ファイルの平文データを保留対象の電子メールとする（ステップ５０９）。そして、保留ステータス２１５の「復号鍵待ち」の設定を解除し、非暗号化電子メールと同様の「一時保留中」又は「上長承認待ち」等に設定し(ステップ５１０)、保留時間経過待ちまたは上長承認待ち処理へ移行する。すなわち、所定の条件を満たすまで送信を保留する待ち状態に移行する。これにより、例えば上長承認が必要とされる電子メールの場合、上長は添付ファイルの内容まで確認したうえで外部クライアント５等への電子メール送信の可否を判断できるため、実効的な情報漏洩の防止が可能である。そして、電子メール送信者から別途上長に対してパスワード等の復号鍵情報を送付する必要がないため、電子メール送信者の負担も軽減できる。
【００５０】
図６は、図５のメール保留サーバ２における復号鍵候補の取得処理フロー５０４の詳細フローである。
メール保留サーバ２は、自身に送信されてくる電子メールが復号鍵を有するか否かをチェックする（ステップ６０１）。
【００５１】
電子メールから復号鍵を検出する方法の１つとして、メール本文内にある復号鍵を示唆するキーワードに基づいて検出する方法がある。具体的には、「パスワード」、「Password」、「Pass」等の語句をキーワードとして、このようなキーワードがメール本文中に記載されていた場合、その前後の文章から半角英数の文字列を抽出して復号鍵候補とする。また、「：」や「；」等の区切り記号をキーワードとして、その直後に半角英数の文字列が続いている場合はそれを復号鍵候補として抽出することも考えられる。
【００５２】
その他の復号鍵を検出する方法としては、復号鍵を相手方に通知する場合は、暗号化した添付ファイルを送付した電子メールに返信する形で通知することが多いため、保留対象の電子メールに対する返信メールや転送メールが送信された場合は、その電子メールにおいて新規に追記された部分(例えば文頭が「>」から始まっていない行) に着目して半角英数の文字列を抽出することも考えられる。
【００５３】
このような復号鍵検出を効率よく実施するために、パスワードの性質を利用することも考えられる。例えば、パスワードの多くは半角英数で３文字程度から長くても２０文字程度で構成され、間に空白は含まないため、前述のようにキーワードに基づいて取得した復号鍵候補に対しパスワードの性質に一致するか否かによりフィルタリングすることで、通常の英文との混同を回避できる。また、パスワードの性質を会社内で定めている場合(例えば「パスワードは8文字以上12文字以内で英数を併用すること」といった規定) は、その性質を利用してフィルタリングをかければより効率よくパスワードを取得できる。
【００５４】
さらに、メール本文中に「パスワードはいつもの形式です」というようなセンテンスを検出した場合は、この電子メールの送信者や宛先、件名と、復号鍵ＤＢ３１に登録された各復号鍵レコード４１０の通知件名４１３、通知送信者（ヘッダ）４１４、通知宛先（ヘッダ）４１６、通知宛先（エンベロープ）４１５を照らし合わせ、復号鍵候補を抽出することも可能である。
【００５５】
復号鍵通知メールと思われる電子メールを検出した場合、そのメール本文より復号鍵を取得し、復号鍵候補の取得処理を終了する。復号鍵通知メールを検出できない場合は、所定時間が経過するまで復号鍵候補を有する電子メールを待つ（ステップ６０２、ステップ６０３）。
【００５６】
復号鍵が取得できないままで所定時間が経過した場合は、復号鍵の送信を求める催促メールを、「復号鍵待ち」保留状態の対象電子メールの送信者に送信し（ステップ６０２、ステップ６０４）、送信者から復号鍵が通知されるのを待つ( ステップ６０５)。メール保留サーバ２は、自身宛てに送信されてくる電子メールが復号鍵を有するかチェックする（ステップ６０６）。復号鍵通知メールと思われる電子メールを検知した場合はそのメール本文より復号鍵を取得して復号鍵取得処理を終了する。一方で、送信者から復号鍵を通知するメールが所定時間経過しても送られてこない場合は復号鍵待ちを断念し、タイムアウトしたとして復号鍵候補の取得処理を終了する( ステップ６０７)。
【００５７】
なお、本実施例では暗号化された添付ファイルを正常に復号できた復号鍵のみを復号鍵ＤＢ３１に登録するものとして記載したが、復号鍵候補の取得処理において復号鍵候補として検出したものは一律に復号鍵ＤＢ３１に登録するようにしてもよい。このような場合、不要な復号鍵レコード４１０が累積的に蓄積しやすいので、登録日４１１から一定期間経過し、かつ復号成功回数４１７が0回のままの復号鍵候補や、最終復号日時４１８から一定期間を経過した復号鍵候補がないか定期的にチェックし、復号鍵ＤＢ３１を定期的に整理する方が適切である。
【００５８】
さらに、本実施例では個々の「復号鍵待ち」保留状態の電子メールに対して復号鍵を取得する時間を設ける処理を記載したが、メール通信プロトコル実装上、復号鍵通知メールが暗号化電子メールよりも先にメール保留サーバ２に到達する可能性もあるため、「復号鍵待ち」保留状態の電子メール毎に復号鍵通知メールを監視するのではなく、メール保留サーバに到達した全ての電子メールに対して、復号鍵が格納されていないか検査を行う方がより適切である。
【００５９】
また、復号鍵候補を取得する方法については他の方法も考えられる。
パスワード等の復号鍵はプロジェクトとして過去のものを使いまわすことが多い。例えば、最初にある復号鍵を決めておき、その後はそのプロジェクト内では同じ復号鍵を用いることをルールとするような場合である。したがって、暗号化されたファイルが添付されている電子メールの件名や本文からプロジェクト名を推定し、復号鍵ＤＢ３１の通知件名４１３等の情報からプロジェクト名が一致するものを探し、その復号鍵を復号鍵候補としてもよい。この場合、復号鍵候補の取得処理(ステップ５０４)においては、復号鍵が付された電子メールからプロジェクト名を推測し、復号鍵ＤＢ３１に登録しておく方がより効率的と考えられる。
【００６０】
さらに、電子メール以外（例えば電話やFAX等）で復号鍵をやり取りしている場合には、復号鍵通知メールがメール保留サーバ２を経由しない。このようなケースに対応するため、復号鍵通知メール取得のため所定時間以上経過した保留メールに対して、メール保留サーバ２はメール送信者に対して、復号鍵要求メールを送信する手段を設けることも可能である。復号鍵要求メールを受け取った当該保留メールの送信者は、その復号鍵要求メールに対する返信メールのメール本文に復号鍵を記載してメール保留サーバ２に返信する。この場合、復号鍵ＤＢ３１に、復号鍵文字列、日付、送信者、宛先、件名として格納しておくことで、前述の復号鍵候補の検出に用いることができ、毎回暗号化電子メールが送信されるたびに送信者に対して復号鍵の要求を行わなくてもすむ可能性が高くなる。
【００６１】
さらに、所定時間以上経過した保留メールに対する復号鍵の特定は、復号鍵ＤＢ３１に登録されている複数の復号鍵を順次適用して行ってもよい。この場合、復号鍵レコード４１０の復号成功回数４１７から、過去に正常復号できた実績のある復号鍵を優先的に使用して、添付ファイルの復号を試みるようにしてもよい。
【００６２】
また復号鍵として日付を含んだ形式であると判断できる場合は、メール送信日時の値を変換して復号鍵とすることも考えられる。
【００６３】
以上、本実施形態について説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。例えば、上記実施形態では、電子メールにファイルを添付する際に添付ファイルの検査を行ったが、電子メールが送信されるまでの任意のタイミングで検査を行って良い。その他、上記実施形態に、種々の変更または改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。
【符号の説明】
【００６４】
１ 内部クライアント
２ メール保留サーバ
４ メールサーバ
５ 外部クライアント
３１ 保留メールデータベース
３２ 復号鍵データベース
３１４ 保留メール
２１０ 保留メールレコード
４１０ 復号鍵レコード
【特許請求の範囲】
【請求項１】
内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバを備えた電子メール保留システムであって、
前記メール保留サーバは、
前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断する手段と、
受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録する手段と、
前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断する手段と、
受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得する手段と、
取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、
前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定する手段と、
前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信する手段と、を備えることを特徴とする電子メール保留システム。
【請求項２】
前記メール保留サーバは、
前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録する手段と、
前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、をさらに備えることを特徴とする請求項１に記載の電子メール保留システム。
【請求項３】
前記メール保留サーバは、
所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信する手段をさらに備えることを特徴とする請求項１または２に記載の電子メール保留システム。
【請求項４】
内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバが行う電子メール保留方法であって、
前記メール保留サーバは、
前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断するステップと、
受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録するステップと、
前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断するステップと、
受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得するステップと、
取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、
前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定するステップと、
前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信するステップと、を実行することを特徴とする電子メール保留方法。
【請求項５】
前記メール保留サーバは、
前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録するステップと、
前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、をさらに実行することを特徴とする請求項４に記載の電子メール保留方法。
【請求項６】
前記メール保留サーバは、
所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信するステップをさらに実行することを特徴とする請求項４または５に記載の電子メール保留方法。
【請求項１】
内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバを備えた電子メール保留システムであって、
前記メール保留サーバは、
前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断する手段と、
受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録する手段と、
前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断する手段と、
受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得する手段と、
取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、
前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定する手段と、
前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信する手段と、を備えることを特徴とする電子メール保留システム。
【請求項２】
前記メール保留サーバは、
前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録する手段と、
前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みる手段と、をさらに備えることを特徴とする請求項１に記載の電子メール保留システム。
【請求項３】
前記メール保留サーバは、
所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信する手段をさらに備えることを特徴とする請求項１または２に記載の電子メール保留システム。
【請求項４】
内部クライアントが外部クライアントへ送信した電子メールを前記外部クライアントへ送信する前に所定時間保留するメール保留サーバが行う電子メール保留方法であって、
前記メール保留サーバは、
前記内部クライアントから受信した電子メールが暗号化添付ファイルを有する暗号化電子メールであるか否かを、添付ファイルのファイル形式に基づいて判断するステップと、
受信した電子メールが暗号化電子メールである場合、前記暗号化電子メールを復号鍵待ち保留状態に設定して保留メールデータベースに登録するステップと、
前記内部クライアントから受信した電子メールがメール本文に復号鍵を含む復号鍵通知メールであるか否かを判断するステップと、
受信した電子メールが復号鍵通知メールである場合、前記復号鍵通知メールのメール本文に含まれる復号鍵を復号鍵候補として取得するステップと、
取得した前記復号鍵候補を用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、
前記暗号化添付ファイルが正しく復号された場合、前記暗号化電子メールの復号鍵待ち保留状態の設定を解除し、所定の条件を満たすまで前記外部クライアントへの送信を保留する保留状態に設定するステップと、
前記所定の条件が満たされた場合、前記暗号化電子メールを前記外部クライアントに送信するステップと、を実行することを特徴とする電子メール保留方法。
【請求項５】
前記メール保留サーバは、
前記復号鍵候補を取得したとき、前記復号鍵候補を新たな復号鍵として復号鍵データベースに登録するステップと、
前記復号鍵データベースに登録されている複数の前記復号鍵を順次用いて、前記保留メールデータベースに登録された復号鍵待ち保留状態にある前記暗号化電子メールの暗号化添付ファイルの復号を試みるステップと、をさらに実行することを特徴とする請求項４に記載の電子メール保留方法。
【請求項６】
前記メール保留サーバは、
所定時間の間、前記複合鍵候補を取得できない場合、前記暗号化電子メールの送信者に対し復号鍵の送信を求める復号鍵要求メールを送信するステップをさらに実行することを特徴とする請求項４または５に記載の電子メール保留方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−２０８５８３（Ｐ２０１２−２０８５８３Ａ）
【公開日】平成２４年１０月２５日（２０１２．１０．２５）
【国際特許分類】
【出願番号】特願２０１１−７２０６７（Ｐ２０１１−７２０６７）
【出願日】平成２３年３月２９日（２０１１．３．２９）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
【公開日】平成２４年１０月２５日（２０１２．１０．２５）
【国際特許分類】
【出願日】平成２３年３月２９日（２０１１．３．２９）
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【Ｆターム（参考）】
[ Back to top ]