管理者からの未既読判断は可能か? -7-
<話題の履歴>
管理者からの未既読判断は可能か? -1-
管理者からの未既読判断は可能か? -2-
管理者からの未既読判断は可能か? -3-
管理者からの未既読判断は可能か? -4-
管理者からの未既読判断は可能か? -5-
管理者からの未既読判断は可能か? -6-
前回は、改めて開発すべきSpam/Virus 調査Toolの技術的課題の検討を行ってみました。
今回は、この機能要件に従い実装するための概要設計を行ってみます。
まず、調査しなければならないMail ServerはUserの環境にもよりますが複数存在します。
前々回に、Spam/Virus Mailの調査方法の検討を行いましたが、db.Searchで探すのが最も妥当なのではないかと思われます。
しかし、それ程Performanceが良いとは思われない訳で、数千人とか数万人の環境だと、1 Serverで処理したとしたら、膨大な時間が掛かることが予測されます。
となると、処理の分散化を当初から考えておく必要があると思います。
しかし、調査用のDBをMail Server単位に配置したのでは、全てのデータを集約して会社全体の状態を確認することが困難になります。
ここは、Notes/Dominoの特徴であるReplicaを活用して設計するのが得策と思われます。
後は、Replica配置したRemote Server上でのAgentの実行や実行後の収集Dataや実行Logの集約が出来、それがMail ServerではないDB Server上に登録された調査用のDBから集中管理が出来ることが重要です。
この制限条件に基づいて、設計してみます。
【環境】(DB配置)
1) 集中コントロールするDB ServerにSpam/Virus調査DBを配置する
2) Mail ServerにSpam/Virus調査DBのReplicaを配置する
3) 分散配置されたReplicaでは操作は禁止する
【調査対象Mail Server定義】(環境設定Form/View)
1) Cluster環境も考慮して調査対象Mail Server(Cluster Server)の定義
2) 調査対象Serverに対して調査Program(Agent)を実行可能とする
【調査対象Spam/Virus Mailパターン定義】(調査パターン定義Form/View)
1) Subjectの「始まる/終わる/含む」のパターンで定義を可能とする
2) 追加オプションとして添付ファイル名(「始まる/終わる/含む」のパターン)の定義を可能とする
3) 追加オプションとして送信者名(FromまたはSMTPOriginator)が詐称のパターンの定義を可能とする
【Spam/Virus Mail受信者情報収集定義】(収集情報Form/View)
1) Notes基本名/別名
2) Home Mail Server名/Mail DB File名
3) Internet Address
4) DJX組織情報
【Spam/Virus Mail収集情報定義】(収集情報Form/View)
1) 送信者(From)
2) 送信元(SMTPOriginator)
3) 送信先(To/Cc/Bcc)
4) 件名(Subject)
5) 本文(Body)のText情報(フィッシングを考慮してLink先情報を変更できること)
6) 添付ファイル名
7) 文書UNID(削除対応用)
8) SMTP配信経路情報(Received Field内容)
9) 未既読情報
10) 発見場所情報(ごみ箱/ごみ箱以外)
11) Spam/Virus判断情報(削除対象/削除対象外)
12) 削除情報(管理者強制削除/User削除)
【設定情報配布】(ViewのButton)
1) 「調査対象Mail Server定義」、「調査対象Spam/Virus Mailパターン定義」のMail Serverへの即時配布を可能とする
2) 配布完了のチェックを実施する
【Spam/Virus Mail情報収集】(ViewのButton/Agent)
1) 「調査対象Mail Server定義」に定義された全てのMail Serverで並行でSpam/Virus Mail情報収集実行可能とする
2) 「調査対象Spam/Virus Mailパターン定義」に一致するMail調査結果を文書として保存する
3) 収集したSpam/Virus Mail情報を集中コントロールするDB Serverに配置したDBに集約する
4) 情報収集Logを集中コントロールするDB Serverに配置したDBに集約する
【Spam/Virus Mailの調査】(ViewのButton/Agent)
1) 個別(User名指定)/対象User List(Textファイルで指定)/全Userでの調査を可能とする
2) 複数あるMail Serverでの同時並行実行を可能とする
3) 調査Logを保存する
4) 取集されたSpam/Virus Mailの分類(Spam/Virus及び対象外の判断)を可能とする
【Spam/Virus Mailの駆除】(ViewのButton/Agent)
1) Spam/Virus Mailと判断されたMailの一括削除(ごみ箱を含む)を可能とする
2) 削除状態を調査した収集情報に反映する
3) 削除Logを保存する
4) Spam/Virus Mailと判断されたMailの検体保存(調査用)を可能とする
【情報収集Log情報】(収集Log Form/View)
1) Agent開始時間
2) Agent実行Server名
3) 調査したUserのNotes基本名/別名
4) 調査したUserのHome Mail Server名/Mail DB File名
5) 調査状況
5-1) 調査したSpam/Virus名
5-2) 発見情報(ごみ箱以外での発見数/ごみ箱での発見数)
6) Agent終了時間及びError情報
【削除Log情報】(削除Log Form/View)
1) Agent開始時間
2) Agent実行Server名
3) 削除したUserのNotes基本名/別名
4) 削除したUserのHome Mail Server名/Mail DB File名
5) 削除状況
5-1) 削除したSpam/Virus名
5-2) 削除情報(ごみ箱以外での削除数/ごみ箱での削除数)
6) Agent終了時間及びError情報
これで実際の詳細設計/開発が行えるのではないかと思います。
実は、この仕組みは概要設計も詳細設計もすることなく、頭の中だけで設計し既に開発がほぼ終わっています。
全UserのSpam/Virus Mail CheckはPerformanceの観点で考慮点がありますので、Test的に100 User程度に制限して実行しましたが、ごみ箱を探さない場合で、1-2GB程度のMail DB容量の100 Userで8-10分程度という状態でした。
1 Serverあたり1000 Userとか2000 Userを登録されている会社が多いと思いますので、へたをすると200分程度の実行時間が必要ではないかと見積もっています。
特にごみ箱に多くの文書がある場合は、更に時間が掛かると思われます。
Agentとしてはかなり時間が掛かりますので、発見後夜に実行するとかの考慮が必要でしょうし、Agentの最大実行時間を拡張することも必要です。
逆に、SMTP Logなどから、Spam/Virus Mailが侵入したUserが特定可能な場合は、1 Userあたり1分以下で情報収集が可能です(正確な時間は測定していませんが、Agent Logの開始時間と終了時間で判断できます)。
先にSMTP LogからSpam/Virus Mailの侵入先を特定できるのであれば、侵入先のみ調査するのが得策と言えます。
削除も、集中管理Serverから、10文書程度の削除を行っても、直ぐに終わることが確認できています。
実際のCodeを紹介することは行いませんが、これまでの記事から、皆さんなら直ぐに開発できるのではないかと思います。
最近では、Spam/Virus Mailが日々発生し、企業としては悩まされる毎日だと思いますが、この情報が参考になれば幸いです。
<終わり>
管理者からの未既読判断は可能か? -1-
管理者からの未既読判断は可能か? -2-
管理者からの未既読判断は可能か? -3-
管理者からの未既読判断は可能か? -4-
管理者からの未既読判断は可能か? -5-
管理者からの未既読判断は可能か? -6-
前回は、改めて開発すべきSpam/Virus 調査Toolの技術的課題の検討を行ってみました。
今回は、この機能要件に従い実装するための概要設計を行ってみます。
まず、調査しなければならないMail ServerはUserの環境にもよりますが複数存在します。
前々回に、Spam/Virus Mailの調査方法の検討を行いましたが、db.Searchで探すのが最も妥当なのではないかと思われます。
しかし、それ程Performanceが良いとは思われない訳で、数千人とか数万人の環境だと、1 Serverで処理したとしたら、膨大な時間が掛かることが予測されます。
となると、処理の分散化を当初から考えておく必要があると思います。
しかし、調査用のDBをMail Server単位に配置したのでは、全てのデータを集約して会社全体の状態を確認することが困難になります。
ここは、Notes/Dominoの特徴であるReplicaを活用して設計するのが得策と思われます。
後は、Replica配置したRemote Server上でのAgentの実行や実行後の収集Dataや実行Logの集約が出来、それがMail ServerではないDB Server上に登録された調査用のDBから集中管理が出来ることが重要です。
この制限条件に基づいて、設計してみます。
【環境】(DB配置)
1) 集中コントロールするDB ServerにSpam/Virus調査DBを配置する
2) Mail ServerにSpam/Virus調査DBのReplicaを配置する
3) 分散配置されたReplicaでは操作は禁止する
【調査対象Mail Server定義】(環境設定Form/View)
1) Cluster環境も考慮して調査対象Mail Server(Cluster Server)の定義
2) 調査対象Serverに対して調査Program(Agent)を実行可能とする
【調査対象Spam/Virus Mailパターン定義】(調査パターン定義Form/View)
1) Subjectの「始まる/終わる/含む」のパターンで定義を可能とする
2) 追加オプションとして添付ファイル名(「始まる/終わる/含む」のパターン)の定義を可能とする
3) 追加オプションとして送信者名(FromまたはSMTPOriginator)が詐称のパターンの定義を可能とする
【Spam/Virus Mail受信者情報収集定義】(収集情報Form/View)
1) Notes基本名/別名
2) Home Mail Server名/Mail DB File名
3) Internet Address
4) DJX組織情報
【Spam/Virus Mail収集情報定義】(収集情報Form/View)
1) 送信者(From)
2) 送信元(SMTPOriginator)
3) 送信先(To/Cc/Bcc)
4) 件名(Subject)
5) 本文(Body)のText情報(フィッシングを考慮してLink先情報を変更できること)
6) 添付ファイル名
7) 文書UNID(削除対応用)
8) SMTP配信経路情報(Received Field内容)
9) 未既読情報
10) 発見場所情報(ごみ箱/ごみ箱以外)
11) Spam/Virus判断情報(削除対象/削除対象外)
12) 削除情報(管理者強制削除/User削除)
【設定情報配布】(ViewのButton)
1) 「調査対象Mail Server定義」、「調査対象Spam/Virus Mailパターン定義」のMail Serverへの即時配布を可能とする
2) 配布完了のチェックを実施する
【Spam/Virus Mail情報収集】(ViewのButton/Agent)
1) 「調査対象Mail Server定義」に定義された全てのMail Serverで並行でSpam/Virus Mail情報収集実行可能とする
2) 「調査対象Spam/Virus Mailパターン定義」に一致するMail調査結果を文書として保存する
3) 収集したSpam/Virus Mail情報を集中コントロールするDB Serverに配置したDBに集約する
4) 情報収集Logを集中コントロールするDB Serverに配置したDBに集約する
【Spam/Virus Mailの調査】(ViewのButton/Agent)
1) 個別(User名指定)/対象User List(Textファイルで指定)/全Userでの調査を可能とする
2) 複数あるMail Serverでの同時並行実行を可能とする
3) 調査Logを保存する
4) 取集されたSpam/Virus Mailの分類(Spam/Virus及び対象外の判断)を可能とする
【Spam/Virus Mailの駆除】(ViewのButton/Agent)
1) Spam/Virus Mailと判断されたMailの一括削除(ごみ箱を含む)を可能とする
2) 削除状態を調査した収集情報に反映する
3) 削除Logを保存する
4) Spam/Virus Mailと判断されたMailの検体保存(調査用)を可能とする
【情報収集Log情報】(収集Log Form/View)
1) Agent開始時間
2) Agent実行Server名
3) 調査したUserのNotes基本名/別名
4) 調査したUserのHome Mail Server名/Mail DB File名
5) 調査状況
5-1) 調査したSpam/Virus名
5-2) 発見情報(ごみ箱以外での発見数/ごみ箱での発見数)
6) Agent終了時間及びError情報
【削除Log情報】(削除Log Form/View)
1) Agent開始時間
2) Agent実行Server名
3) 削除したUserのNotes基本名/別名
4) 削除したUserのHome Mail Server名/Mail DB File名
5) 削除状況
5-1) 削除したSpam/Virus名
5-2) 削除情報(ごみ箱以外での削除数/ごみ箱での削除数)
6) Agent終了時間及びError情報
これで実際の詳細設計/開発が行えるのではないかと思います。
実は、この仕組みは概要設計も詳細設計もすることなく、頭の中だけで設計し既に開発がほぼ終わっています。
全UserのSpam/Virus Mail CheckはPerformanceの観点で考慮点がありますので、Test的に100 User程度に制限して実行しましたが、ごみ箱を探さない場合で、1-2GB程度のMail DB容量の100 Userで8-10分程度という状態でした。
1 Serverあたり1000 Userとか2000 Userを登録されている会社が多いと思いますので、へたをすると200分程度の実行時間が必要ではないかと見積もっています。
特にごみ箱に多くの文書がある場合は、更に時間が掛かると思われます。
Agentとしてはかなり時間が掛かりますので、発見後夜に実行するとかの考慮が必要でしょうし、Agentの最大実行時間を拡張することも必要です。
逆に、SMTP Logなどから、Spam/Virus Mailが侵入したUserが特定可能な場合は、1 Userあたり1分以下で情報収集が可能です(正確な時間は測定していませんが、Agent Logの開始時間と終了時間で判断できます)。
先にSMTP LogからSpam/Virus Mailの侵入先を特定できるのであれば、侵入先のみ調査するのが得策と言えます。
削除も、集中管理Serverから、10文書程度の削除を行っても、直ぐに終わることが確認できています。
実際のCodeを紹介することは行いませんが、これまでの記事から、皆さんなら直ぐに開発できるのではないかと思います。
最近では、Spam/Virus Mailが日々発生し、企業としては悩まされる毎日だと思いますが、この情報が参考になれば幸いです。
<終わり>