概要 - Notes Watcher® ：Notesログ取得ツール

１）軽いアクセスフックモジュール（Notes Watcherアクセスロガー）

Dominoサーバー内に配置され、実際のNotesユーザーからのNotes文書閲覧のアクセスをフックし、ログとして出力するツールが「Notes Watcher アクセスロガー」です。アクセスロガーは必要最小限のログを高速に処理することに特化したモジュールであり、Dominoサーバーへの負荷を最小限に抑えます。

２）アクセスログ書き込みの非同期処理を実現するメッセージキューイング（Notes Watcherキューマネージャ）

Domino サーバーと同じ筐体（Windows版は別プロセス。UNIX版はDomino内の１プロセスとして稼動）に配置され、アクセスロガーから出力されたアクセスログをRDBへ送信する仲立ちをするのがNotes Watcherキューマネージャです。Notes WatcherキューマネージャがアクセスロガーとRDB間でメッセージキューイングの仕組みでバッファとして働きます。キューマネージャによってアクセスロガーは非同期で動作することができるので、NotesユーザーによるDominoへのアクセスの際に処理の遅延をおこしません。

キューマネージャによってNotesユーザーは即座に処理を継続可能

キューが無ければ、Notesユーザーはアクセスログが書込されるまで処理待ちが発生

３）大量のログ格納を可能にするRDBの採用（Notes Watcher DBマネージャ）

日々発生する大量のログを格納するRDBとその管理を行うのが「Notes Watcher DBマネージャ」です。１台のNotes Watcher DBマネージャで、４～６台程度のDominoサーバーのログを格納することができます。Notesの標準ログがNotes DB（log.nsf）に格納 されることに較べ、Notes Watcherではログ格納にRDBを採用することで、以下のようなメリットが生じます。

• NSFに比べ、大量のログを格納することができる
• ログの格納にDominoサーバーのCPU/リソースを使用しない
• ログの分析にDominoサーバーのCPU/リソースを使用しない
• ログのアーカイブ処理にDominoサーバーのCPU/リソースを使用しない

ポイント： 実際のログの量はどれくらいか？

Notes Watcherは、Notesユーザーによる1つのアクセスを１つのログのレコードとして取得するため、Notesの標準ログに比べ非常に大量のログが発生します。以下は実際のお客様環境での一例です。この大量のログを格納するために、Notes Watcherでは外部のRDBを採用しているのです。

• ユーザー数：約8000名
• Notes　DB数：約 600DB
• 平日日中アクセス　20アクセス/秒（繁忙期アクセス40アクセス/秒）
• 計算式：20アクセス/秒×60秒×60分×8時間≒57万ログ/1日

※ Notes Watcher DBマネージャは、溜まったログの数を監視し、閾値を超えたら自動でアーカイブする機能も備えています。

Notesのログとは違い、閲覧だけではなく、削除、レプリカ、コピーの履歴も収集することができます。また、文書単位でのアクセスログも収集できます。これらの情報を利用し、情報漏洩の原因解明へ向けたユーザーや期間の絞り込みが可能になります。また、不正な情報がNotes上に登録されてしまった際に、その文書を閲覧したユーザーのリスト等を絞り込むことも可能です。

ポイント： NotesのACL（アクセスコントロールリスト）との違い

Notesは非常に強固なセキュリティを持ったシステムです。ユーザーは強力なNotes認証基盤の元厳密なACLで管理され、権限の無い文書にはアクセスすることはできません。

しかし、情報共有基盤として見たとき、このようなアクセス権限による情報の防御措置に加え、アクセス権の有権限者による正規の手順を踏んで入手された情報の漏洩対策も非常に重要です。この場合、有効な対策は、

1. 情報フローの監視の周知による利用者のモラル向上
2. 情報漏えい発覚後の履歴チェックによる不正アクセスの特定

の2点です。このように、詳細なアクセスログを収集しておくことは、情報共有基盤におけるセキュリティの第一歩といえるのです。

1.Notes DBの分類・整理

Notesの標準ログではわからない各DBの利用状況パターンを把握することで、Notes DBの分類・整理を図ることができます。特に、利用されている・いないという観点だけではなく、情報が作成されているが閲覧されていない、情報が更新されていないが良く閲覧されている、といった軸でも分析することができるため、Notes DBの設計・配置場所の見直しや、Web化の検討に対して、定量的な指針を得ることができます。

2.文書の再配置検討

文書単位のログにより、DB内の実際に利用されている文書の比率や、文書の作成日から一定のユーザーに実際に閲覧された日時の分析などが行えます。

例）全社掲示板に新規に作成された文書は、作成後一定の日数であまり利用されなくなる事がわかった。古くなった文書のアーカイブルールを設定することで、全社掲示板を軽いまま活用することができた。

例）営業所単位で運用していた提案資料用DBについて、特定のカテゴリの文書はあまり利用されていないことがわかった。このカテゴリに属する文書はひとまとめにして全社提案資料アーカイブとして、必要な資料を取り出しやすくした。

3.マイグレーションコストの削減

Notesのバージョン アップで最もコストがかかるものの一つにNotes DBの動作検証があります。Notes Watcherを将来のマイグレーションに備えて予め Notes DBの利用状況把握のために稼動させておけば、実際のマイグレーション時にはログの分析から実際に必要とされているDBを明確化することができ、全体的なマイグレーションのコストと時間を削減する事ができます。