Part3 監視のポイントをどこに置くか：「社内ブラックリスト」の作り方（7/7 ページ）
どのようにシステムを監視すればよいのだろうか？ 監視対象ごとにそのポイントを解説する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
社内にUNIX系のサーバがあるなら、これらにTelnetで接続が行える可能性がある。Telnetで接続に成功すれば、サーバに置かれた情報のダウンロードは、比較的簡単に行えてしまう。
たとえば、Telnet接続に成功した犯人が、「cat」というUNIXコマンドでファイルの内容を端末画面に表示したとする。そして、端末画面のスクリーンショットを取る、Telnetソフトウェアのログ機能で表示した内容をすべて端末上のファイルに記録するといった方法で、情報は端末にダウンロードできる。サーバ側だけでは、端末に表示されたことまでしかわからないが、端末側の操作ログを組み合わせると、ファイルに記録されたかどうかまで知ることができる。ただし、端末は社員の手元にあるので、端末ログの改ざん防止が適切に設定されていないと、改ざんされてしまう恐れがある。また、Telnetのやっかいなところは、接続できてしまうと、サーバ上のログも改ざんできる可能性が高いという点だ。
そこで、壁で仕切られ侵入が困難なエリアにサーバを置く、Telnetサービスは停止してネットワーク経由でのアクセスを禁止する、システムコンソールは物理的に外しておくなどの対策を講じるとよい。
また、システム管理者が、Telnet接続して不正に情報を取得する可能性もある。これに対しては、システムコンソールからのアクセスこそ監視できないものの、ネットワーク監視を併用することが望ましい。ネットワーク上で、Telnetによって、いつ、どこの端末から、どのユーザーが、どのような行動をとったのかを記録しておくのだ。なお、Telnetの監視も、ファイル共有と同様に疑わしい社員しかリストアップできないのが普通である。共有情報では、イエローリストの作成までが一般的な監視結果となる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
業務アプリケーションで扱われる情報は、企業にとって重要なものが大半なので、それに対して、ユーザーがどのような行動をとったのかを把握する必要がある。ところが、業務アプリケーションでこのような確認をするためのログを取得できるケースは、非常にまれである。また、詳細なログを取るための作り込みを行おうとすると、業務アプリケーションのパフォーマンスに何らかの影響が出ることが多いので、一般には避けたほうが賢明だ。
そこで、業務アプリケーションについても、既存システム（業務）に影響の出にくいネットワーク監視を行うことを推奨する。ただし、業務アプリケーションでは、端末（クライアント）／サーバ間の通信に独自プロトコルを使用することがめずらしくない。一般に、独自プロトコルを解析できるソフトウェアはないので、専用の解析ツールを開発しなければならないかもしれない。しかし、そのような場合でも、トランスポートのプロトコルにはTCP/IPが使われることが多く（表2）、このトランスポートプロトコルの解析が行えれば、アプリケーションデータの内容は確認できる。アプリケーションデータを完全に抽出するのではなく、トランスポートプロトコルの解析で代用することで監視を行うのだ。
たとえば、トランスポートプロトコルにTCP/IPを使用する電子メール（SMTP）を、各レイヤのプロトコルに従ってトランスポートプロトコルまで解析すると、図4のようになる。
この図に書かれているのは、「taro@xxxx.com」から「hanako@xxxx.com」へ送信された電子メールを解析したものだ。1行目から4行目は、SMTPプロトコルのコネクションを確立している部分で、5行目の「MAIL FROM」から8行目までがSMTPヘッダの送信部分、9行目から18行目がメールとなり、19行目から20行目でコネクションを終了している。いわゆるメールヘッダは11行目から13行目で、メール本文が14行目から16行目、17行目はメールの終了を示す。メールソフトで表示すると、11行目から16行目のみが表示されるが、この部分がアプリケーションデータである。
このように、トランスポートプロトコルを解析すれば、アプリケーションデータの内容を確認できる。コストをかけずに業務アプリケーションの監視を行いたければ、トランスポートプロトコルの解析で代用できないかを検討してみるべきだろう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
Copyright © ITmedia, Inc. All Rights Reserved.