最終回 傷だらけの勝利? 情報漏えい事件解決

根津 研介
園田 道夫
宮本 久仁男
2005/3/31
※ご注意
本記事はフィク ションであり、実在の人物・組織などとは一切関係ありません。

 エピローグ


平山さん 「あ、そういえば社内システム利用手順書のことなんだけど……」
中村君 「ストップ。デートしてるときくらいそういう話はやめませんか?」
平山さん 「あ、そうね。ふふ。ごめんなさい」

 2人は向き合って、しばらく黙ってお酒をちびちびなめている。

中村君 「しかし、社長室のときに、A社に渡した顧客情報入りCD-Rのことを話さなくてよかったなあ」
平山さん 「あら、仕事の話してもよかったの(笑)? まあでも、CD-Rの中身は結局古かったし、話してもよかったんじゃないの?」
中村君 「いや、あそこで話していたらややこしくなる一方だったしね」
平山さん 「怒っているくせにやけに冷静だったのね」

 感嘆するような平山さんのいい方に中村君はちょっと照れる。

中村君 「ファイルサーバにあった顧客情報ファイルのことも喋らなくてよかったよね。結局MACタイムを見る限りではシロっぽかったけど」
平山さん 「でも、A社からのアクセスはあまりにも不自然に通信量が多かったじゃない。中身を詳しく見てみたら顧客情報だったんでしょ?」
中村君 「結局今回は、ものすごくラッキーだったってことかな」
平山さん 「そうねえ」
中村君 「久保部長が戻ってきたとき、勉強会仲間からのメールが来ていなかったら、あのブログのことも知らなかったからなあ」

 まさにラッキーとしかいいようがない。メールが一瞬でも遅かったら、タヌキに押し切られていたかもしれなかった。

 原因究明にしてもそうだった。大量の情報漏えいに限っても流出経路となる可能性は数種類ある。顧客情報ファイルがコピー、メールなどで持ち出される可能性や、今回のように管理者用画面経由でダウンロードされる場合などである。管理者権限を持つ人間がリモートからサーバのデータをダウンロードする可能性もある。その中でいきなりビンゴを当ててしまったわけだ。どうやら中村君はかなりツイてるといえそうだ。

平山さん 「でも、まだまだやること多いわね。少なくとも非常事態のときの動き方マニュアルみたいなものは最低限必要よね。いきなりネットニュースに載った件も、結局クレーム処理担当の三戸州さんが不用意に取材対応しちゃってたのが原因だったみたいだし。三戸州さん、あとで中田本部長にこっぴどく怒られたらしいけどね」
中村君 「うん。でも正直そういうの、いろいろ経験とかないと作るの難しそうだよね。小野さんもシステム開発の方で忙しそうだし、ぼく1人じゃ対応できそうもないなあ」
平山さん 「また怒ればできるわよ。怒ったときだけは頼もしいしね」

 からかうように平山さんがいうのを聞きながら、「そうそう怒ってばかりいられるわけじゃないんだけどなあ」と中村君はため息をついた。

平山さん 「でも頑張ってね。わたしも協力するから」

 少なくともやることは見えていた。いわゆる不正アクセスを主なターゲットにしたセキュリティ対策は、情報漏えい発生前に中村君がいろいろ進めていた作業で何とかカバーできる。しかし、情報漏えいというのはまた違う考え方、違うレベルでの対策が必要だ。通信というポイントから見れば、不正なアクセスではなく「正常なアクセス」の内容が問題になるわけだ。

 その中身を記録する、しかも内容を解析するというのは、考えただけでもため息が出てくる。「また勉強会で議論してみようかなあ」と中村君は思った。まだまだ奮闘記は終わらないようだった。

 新にわか管理者奮闘記 終わり
 
長い間ご愛読どうもありがとうございました。(作者一同)

【今回の教訓】

・ログは取るべし

 ログにはいろいろな種類があります。

  • OSのログ
  • ファイアウォール、ルータ、スイッチなどに残るネットワーク通信のログ
  • WebやDNS、メールなどのサーバのログ

 しかし、「情報漏えい」ということを考えると、Webアプリケーションのログや、tcpdumpのような通信内容についての記録なども重要になってきます。また、小野さんが第2回のときに持ち出してきたファイルのMACタイムの記録も必要でしょう。

 ディスクの容量内に収めるためのローテーションさえ気を付ければ、大量のログであっても取っておくことは可能でしょう。しかし、データベースサーバのログは、クエリごとに取得していたら重くて使い物にならなくなりますし、ファイアウォールのアクセプト(許可)された通信ログもファイアウォールへの負荷が無視できません。重要なサーバに無理やり負荷をかけてログを取るよりも、安くて高性能なPCを1台別に調達して、そこで記録するという方が現実的ではないでしょうか。

 通信のログを取る場合には、高性能なネットワークカードと、可能ならばTAPという機器が必要です。あるいは希少品になってしまったリピーターハブなど。しかし、この手の機器をそろえてもそれほど高くはありません。

 適材適所、というのはすごく難しいことですが、全体に負荷を掛けずに上手なログ取りを目指しましょう。この話では触れてませんが、取ったログのバックアップも含めた管理についても忘れずに検討を。

・ 時系列で何をやったかメモを取っておこう

 今回のケースのように、情報漏えいというのは非常にデリケートな対処をしなければなりません。手順や手段を間違えると、もしかすると裁判ざたに巻き込まれるかもしれません。そうならないように、対処のときに何をいつ実施したのか、どんな作業内容だったのか、ということをメモしておきましょう。できれば、「誰にいわれて」そういう作業を行ったのか、ということもメモしておきましょう。

 万が一裁判にでもなったら、メモ程度でも重要な材料になりますし、そうならなかったとしても自分の立場を弁護するために必要になるかもしれません。とにかく時系列メモは取りましょう。


5/5
 

Index
傷だらけの勝利? 情報漏えい事件解決
  Page1
逆転への秘策
  Page2
タヌキとの対決
  Page3
真犯人は誰だ?
  Page4
終わりなき奮闘
Page5
エピローグ


基礎解説記事
にわか管理者奮闘記
5分で絶対に分かるシリーズ
管理者のためのセキュリティ推進室
情報セキュリティ運用の基礎知識
Security&Trustウォッチ

連載:にわか管理者奮闘記


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Security & Trust 記事ランキング

本日 月間