プロパティ・ログで証拠を押さえる　ヘルプ業務「捜査」手法

テクてくLotus 技術者夜会 (ザ・アドミン編) 2012年2月17日 プロパティ・ログで 証拠を押さえる ヘルプ業務「捜査」手法 阿部 覚 所属：ネオアクシス株式会社

このセッションの内容 これまで携わった Notes/Dominoヘルプデスク業務で ユーザー問い合わせ時に 行なっている調査方法のご紹介 制約のある状況/立場でも、 環境によって、まぁまあ対応できるもの 制約とは例えば・・・ ・社内には2,000DBあるけど、いまのNotes担当は自分ひとり DB一個一個の内容までは押さえられない。 ・自分は一支社の担当者。Domino管理者としての権限がそんなにない ✔ サーバーコンソール、使えません ✔ Domino Administratorすらありません

捜査に使用するおもなツール ノーツログデータベース(log.nsf) カタログデータベース(catalog.nsf) 文書のプロパティ ・更新情報タブ ・フィールドタブ アプリケーションのプロパティ（データベースのプロパティ） ・ユーザーの使用状況

事例その1 「メールで承認依頼が来ました。 でも、リンクをクリックすると 権限のエラーが出て開けないんです」 どうやらアクセス権限の設定もれ。 ヘルプ担当者にも、開けませんでした。 ついでに、 メールソフトはNotesクライアント以外 データベース名 不明 ✔管理者 不明 ✔

事例その1「 何データベース？」 リンクの内容 notes://server01/4925xxxxxxxxxxxx/... 16桁のレプリカIDを手がかりに ID カタログデータベースで突き止めます。

事例その1「 何データベース？」 レプリカID順ビューでDB名を確認 4925xxxxxxxxxxxx 検索バーにレプリカIDを入力します

事例その1「 何データベース？」 レプリカID順ビューでDB名を確認 4925xxxxxxxxxxxx 検索バーにレプリカIDを入力します ウソです ごめんなさい

事例その1「 何データベース？」 レプリカID順ビューでDB名を確認 レプリカIDで「検索」はできません。 （カタログ文書にレプリカIDは含まれないため） 「クイック検索」で目的のDBを見つけます。

事例その1「 何データベース？」 カタログ文書上のACLで、管理者が誰か確認 長い名前が 途中で切れて分らない場合、 ACL別のビューでも 確認できます。

事例その2 山田さん「先週の申請、 ご承認まだですか..？」 部長「そんな申請知らないよ。 メール来てないよ」 かくして、山田さんよりヘルプ担当へ 「システムの不具合じゃないんですか？」 でも、お忙しい部長は けっこう、メールを見落としたままだったり 消去済みだったりします。

事例その2「メール未送信？」 調査1 山田さんの申請をチェック 状況から、承認して欲しい文書は、 山田さんが申請したときのままと判断できます。 であれば、わざわざ該当の文書を開いて中を見ずと も・・・

事例その2「メール未送信？」 調査1 山田さん申請の文書プロパティをチェック 山田さんが申請したときのまま（最終更新者）なら 多くの場合、更新日＝申請/送信した日時と判断できます。

事例その2「メール未送信？」 調査2 あとは、ログDBで該当時間のメールを確認 申請したDBのサーバーではなく 部長や山田さんの メールサーバー(ホームサーバー)の ログを確認します。 サーバーが異なる分、 申請時間と送信時間には 若干のずれがあるかも。

事例その2「メール未送信？」 調査2 あとは、ログで確認 文書プロパティから得た 日時を手がかりに Mail Routing Events を 検索します。

事例その2「メール未送信？」 調査2 あとは、ログで確認 ＜注意＞ サーバー設定でのログの設定によって、 証拠能力に多少の差がつきます。 Log_MailRouting=20 （デフォルト）の場合 ※サーバー日時のずれを正確に把握していれば、証拠能力を補えます。 Log_MailRouting=30の場合 ※この例では、送信者と宛先が同じメールサーバーで す。

捜査のお邪魔要因 その1 ログによる捜査が困難な場合 ３ヶ月前の申請についてお問い合わせ カタログタスクが動いていない・・・

事例その3 承認フローの途中で おかしな計数がセットされてる いつのまに、誰が？？ 皆、気づかずに、続いて承認や更新をしていた 関係者の誰もが編集可能な項目

事例その3「いつの間に誰が？」 改ざんされたのは「いつ」可能なら、「誰が」まで 文書プロパティ（主に「フィールド」タブ）から 突き止めます。 ＜注意＞ フィールドタブは、ビューから見てください。 文書画面上では正確な情報がとれない場合があります。

事例その3「いつの間に誰が？」 捜査1 いつ？ を突き止める 該当フィールドの「シーケンス番号」を見る 「このフィールドは、何回目の文書保存で現在値になったか」が、 わかります。

事例その3「いつの間に誰が？」 捜査1 いつ？ を突き止める 「$Revisions」フィールドを見る 保存の都度、前回までの保存日時を リストに追加します。 ゆえに通常はこうなります。 １つ目は、シーケンス番号1の日時 ２つ目は、シーケンス番号2の日時 ３つ目は、シーケンス番号3の日時 ： 最終更新分は含まないので 文書情報タブで補ってください。

事例その3「いつの間に誰が？」 捜査1 いつ？ を突き止める 文書全体の更新回数を確認 この文書は作成以来、合計何回、更新＝保存されているか、 IDのタブに文書のシーケンス番号があります。 ただし、 16進表記です。 最近、私は見ません。 $Revisionsフィールドの シーケンス番号の方が 手っ取り早いです。

事例その3「いつの間に誰が？」 捜査2 誰？ を割り出す 「$UpdatedBy」フィールドの内容を見る 保存の都度、保存者のIDをリストに追加します。 ただし、同じ人が連続して保存した場合は追加しません。 上図の文書では、最初の4回はYamadaさんの保存です。

事例その3「いつの間に誰が？」 捜査2 誰？ を割り出す 問題のフィールドが、シーケンス番号「5」の場合 $Revisions （シーケンス番号「11」）

事例その3「いつの間に誰が？」 おまけの話 私は最近、フィールドのシーケンス番号を 捜査に使わなくなりました。代わりに。。。 逆に、Lotusscript側のプロパティに「シーケンス番号」は、見当たりませ ん。

事例その3「いつの間に誰が？」 おまけの話 LastModifiedを含めてCSVに書き出すアクション

捜査のお邪魔要因 その2 プロパティ捜査を邪魔しそうな要因たち。。。 ・$UpdatedBy フィールドのエントリ制限 ・匿名のフォーム ・毎日のようにアップデートされる文書 ・会議室予約の文書 ・(XPiNC)NotesクライアントのXPage

事例その4 あの文書が 消されている！ 昨日まであったのに 条件によっては、 いつ、誰が消したか 原因を割り出せることがあります。

事例その4「なぜ消された？」 データベースのプロパティ 「ユーザーの使用状況」で、 ある程度 文書更新のログを追えます。

事例その4「なぜ消された？」 Notesクライアントからのアクセス記録は、 DB画面を閉じたタイミングでまとめて記録されるようです。 表示の日時は実際の削除と数時間ずれることも。。 ODS48 ODS43以下のDBでは、 細かなアクセス内容までは 分りません。 ODS43

事例その4「なぜ消された？」 変更/削除したのが「他のサーバー」である場合、 複製に伴う更新である場合が多いです。 （本当に更新した相手は、 複製先の「ユーザーの使用状況」に） OsakaServer SapporoServer

ご清聴 ありがとうございました。 今回お話ししたより もっといい方法があるかも知れません。 ご存知の方、ぜひ教えてください。 （次回以降の講師として・・・）