セキュリティポリシーを導入させることに成功した中村君だったが、安心するのはまだ早かった。ポリシーというものはそもそも作って終わりではない。作って動かして、動いていることをチェックして、それで初めて役に立っているといえるわけだ。作っただけでは終わらない。
中村君はポリシーがちゃんと効果を発揮しているのか、それをチェックすることが大事だとは認識していたが、それは思った以上に大変なことだった……。
意外な支持者
やっつけたいターゲットはいくつかある。野良無線LANアクセスポイント（無断設置されている無線LANアクセスポイント）、ネットワークの私的利用、そして諸悪の根源である無防備なネットワーク……。だが、一度に全部を退治することはできない。どこから手を付けるにしても、いまはともかくポリシーがある。ポリシーがちゃんと守られているか、まずはその大義名分の下で、片っ端からチェックして回るしかなさそうだった。
ポリシーのことが大々的に発表された後、中村君は部内の飲み会に出た。とはいえ、中村君の部（情報システム部）は部員が1人、つまり中村君しかいない。もう1人の小野さんはまだ自宅静養中だ。飲み会は総務人事部と合同だった。
平山さん 「中村くーん、こっちこっち」
遅れて場所に到着した中村君は早速平山さんに呼びつけられた。この平山さん、中村君がちょっと苦手の気が強そうな女性で、いつも中村君を捕まえてはPCについて質問しまくる先輩社員だった。
平山さん 「こないだのセキュリティポリシー、あれいいわねー」
中村君 「え？ そうですか？」
平山さん 「ここのところ情報漏えいとかよく聞くんだけど、やっぱこれからはセキュリティちゃんとしておかないとねえ。それでなくても仕事中に変なことやってそうな人多いし、ああいうルールがちゃんとないとダメだなあって思ってたのよね」
正直なところ意外だった。たまに社内システムに関連してほかの部の会議とかに呼ばれると、「大変なルールが追加されちゃいましたからねえ」などとちくちく皮肉とか当てこすりのようなことをいわれるのも珍しくなかったからだ。もちろん先日のセキュリティ勉強会の飲み会アドバイザーさんの教え（偉い人を悪役に仕立てていい訳に使うこと）を守って中村君は「いやあ、久保部長が張り切ってて大変なんですよー。あんな大変なルールにしなくても、って思うんですけどねえ」と応じてはいたが、表には出てこないけど結構反発があるんだろうなあ、と感じていたからだ。
平山さんは曲がったことが大嫌いなタイプのようだし、会社が出してくるルールとかでも、理不尽なものには敢然と抗議する方だったので、ストレートにガンガンいわれる覚悟をして参加したのだ（1人部員の中村君としては、部長から直々にいわれると参加しないわけにはいかなかった）。
平山さん 「あのポリシー、中村君が作ったんでしょ？」
中村君 「ええ。ちょうどよいサンプルがあったので、ほとんどコピーですけどね」
平山さん 「社内の人は締め付けを煙たがってる人もいるけど、大事な仕事だから頑張んなさいよ」
そう。頑張らなければならないことはよく分かっていた。飲み会アドバイザーの人にもしつこいくらいいわれていたのだ。ポリシーは作り終えたときが始まりで、その後が大変だから、と。とはいえ、中村君はある意味、高をくくっていた。社長直々に御触れを出して、「会社のリソースを勝手に使うな」とくぎを刺しているうえに、セキュリティポリシーというものまで適用しようというのだ。いくらなんでも会社が本気であることは伝わっているはずだ。それでもまだ違反するなんていう人は、そうはいないだろう……、そう思っていたのだ。
中村君 「ルールを作れば守るってもんじゃないだろうけど、いくらなんでも社長がいってるんだし、社内で一番力を持ってる営業部長が推進してるんだからなあ……」
しかし、その認識は完全に甘かった。
とにかくチェック、またチェック
意外な支持者にちょっと勇気付けられた中村君は、危なさそうなところから手を付けることにした。まずは野良無線LANだ。といってもこれは簡単な話だった。無線LAN利用については、情報システム部と久保部長の許可が必要、というルールになったからだ。
さすがにそういうルールが施行されたのに、無線LANのアクセスポイントのような分かりやすい違反の目印を置いておくわけにはいかない。Network Stumbler（http://www.netstumbler.com/）で調査した結果を基に、さり気なく小笠原さんの机付近とかをチェックすると、しっかり撤去されているようだった。念のためNetwork Stumblerで再度チェックしてみたが、設置したまま忘れていたアクセスポイントが1つあっただけで（これもすぐに撤去してもらえた）、怪しいところからは全部撤去されていた。
中村君は通信量の測定のためにMRTG（http://www.mrtg.jp/）を導入することにした。MRTGはいろいろな使い方ができるグラフ化ツールで、Webサーバのアクセス量や、ネットワークの通信量（トラフィック）など、数字に換算できるものは基本的に何でもグラフ化できる。勉強会でもこのツールによってグラフ化された画面を見せながら、講師が「数量化できるデータは重要です。機会があればできる限りデータを取っておくべきですね」といっていたので、準備だけはしていたのだ。
いきなり情報システムの面倒を見ろといわれて以来、さまざまな修羅場をくぐってきた（というと大げさだが）中村君にとって、MRTGのセットアップはそれほど難しくはなかった。半日かけて仕掛けた後、帰宅して翌日を待つことにした。
翌日出勤した中村君は、朝一番でMRTGサーバにアクセスした。
中村君 「しかし、こういう便利なツールを、フリーで使えるなんて、世の中すごいことになってるなあ。どれどれ、グラフ出してみるか」
最初はよく分からなかったが、グラフは見事に描き出されていた。折れ線がジグザグときれいに表示されている。
中村君 「おおー。やったやった」
つかの間喜んだ中村君。しかし、すぐに事態を認識した。ネットワークの私的利用は全然収まっていなかった。グラフは特徴的なパターンを描いていた。夜中になっても通信量がなかなか衰えていないのだ。明け方に向かって多少減衰する傾向はあるが、どう見ても社員の残業パターンには合致しない。にわかには信じがたかったが、ファイルダウンロード活動はやんでいないようだった。うそだろ……、と思いつつも、1日だけでは証拠にならないと思い直し、念のため何らかのネットワーク障害が起きていないか可能な限りのチェックを行った。特に障害とかはなさそうだ。把握している限りのネットワーク機器やサーバにping＊1してみても応答があるし、traceroute＊2してみるといつもどおりの経路（といってもクライアント→スイッチ→ルータというようなシンプルなものでしかなかったが）がしっかり見えている。メールが届かないとかも聞こえてこないし、Webが見られないということもなさそうだ。
＊1
【参考記事】ping 〜 ネットワークの疎通を確認する（Master of IP Networkフォーラム）
＊2
【参考記事】traceroute 〜 ネットワークの経路を調査する（Master of IP Networkフォーラム）
さらに中村君はファイアウォール機の付近でtcpdump＊3を使って通信をモニタしてみた。何がなんだか分からないくらいザザーッと通信パケットが表示されて画面上を流れていったが、見る限りおかしな通信とかはなさそうな気がした。あまり自信はなかったが、メール、Web閲覧などの主要な通信に支障が出ていないし、異常なし、といえそうだった。
＊3
【参考記事】連載：ゼロから始めるLinuxセキュリティ 第6回 ファイアウォールの設定・動作チェック方法（Linux Squareフォーラム）
どう見ても異常なし、と分かった瞬間、いつもならそこで安どするのだが、今回ばかりは失望のため息を抑えることができなかった。
中村君 「ふー。やっぱりやってるんだー」
つまり中村君はコケにされたわけだ。どちらかといえば温和な中村君も、頭に血が上ってきた。このデータを持って犯人の高原さんのところに怒鳴り込む、そんな想像ばかりが駆け巡る。しかし、そのときに飲み会アドバイザーさんのひと言が思い出された。
飲み会アドバイザー 「怒るときはとにかく冷静に。冷静に怒るべし」
中村君 「冷静に怒るってどういうことですか？」
飲み会アドバイザー 「怒ってそのまま怒鳴り込んだりしても、理論武装されてないとただの感情的ないい合いになってしまうだけだよ。怒るときはとにかくこれでもかってくらいに証拠を集めて、相手の反論も可能な限り予想して、いい逃れできないようにしてから怒るのがいいと思う」
その言葉を思い出して中村君は大きく深呼吸をした。確かにまだ証拠が足りない感じがした。いい訳を論破できないかもしれない。それに、いきなり平社員の中村君が怒鳴り込んでいっても、相手は職場の先輩だし、強権発動ということにならないとも限らない。
中村君 「証拠だ。とにかく証拠証拠」
辛うじて冷静になって考えてみると、いま分かっているのはただ単に「夜中に通信量が多い」という事実だけだ。それだけだと高原さんが犯人だと決め付けることすらできない。犯人である、という証拠がもっともっと必要だった。
まずは高原さんのPCからの通信なのかどうかを確かめる必要がある。中村君はファイアウォールともう1つ別なマシンでtcpdumpして調べることにした。ファイアウォール！ 最初はファイアウォールがどこにあるのかすら分かっていなかったが、いまははっきりその場所が分かっている。ファイアウォールでは普段は通信を拒否するログくらいしか取っていない。それもインターネット側から来ている通信のログだけだ。LANからインターネットに出て行く通信は記録していないわけだが、今回はそれを取ることにする。
そしてもう1つ、高原さんのマシンの付近に調査用のPCを設置し、そこでtcpdumpを動かしてとにかく通信記録を取ることにする。「付近」といっても物理的な近所ということではなく、ネットワーク上の近く、という意味だ。セグメント、と呼ばれるネットワーク上の同区画につなげておいて、そこで通信記録を全部取っておくのだ。tcpdumpというコマンド（ツール）はほかのコンピュータ同士の通信をモニタすることもできるらしい。とにかく仕掛けて、中村君は意気揚々と帰宅した。
Traffic Analysis
Intranet Traffic graph/LAN Interface
| System: | localhost in Right here, right now. |
|---|---|
| Maintainer: | Me <me@somewhere.org> |
| Description: | eth0 |
| ifType: | ethernetCsmacd (6) |
| ifName: | |
| Max Speed: | 1250.0 kBytes/s |
| Ip: | 192.168.252.2 (switch) |
最終更新日時 11:55, 2004年4月12日(月),
'localhost'の稼働時間 20 days, 5:50:01.
一日グラフ(5分間平均)
| 最大値 受信: | 2488.3 kb/秒 (24.9%) | 平均値 受信: | 851.2 kb/秒 (8.5%) | 現在値 受信: | 2274.1 kb/秒 (22.7%) | |
| 最大値 送信: | 623.2 kb/秒 (6.2%) | 平均値 送信: | 158.4 kb/秒 (1.6%) | 現在値 送信: | 226.1 kb/秒 (2.3%) |
週間グラフ(30分間平均)
| 最大値 受信: | 4257.5 kb/秒 (42.6%) | 平均値 受信: | 875.6 kb/秒 (8.8%) | 現在値 受信: | 614.3 kb/秒 (6.1%) | |
| 最大値 送信: | 503.2 kb/秒 (5.0%) | 平均値 送信: | 159.9 kb/秒 (1.6%) | 現在値 送信: | 130.9 kb/秒 (1.3%) |
月間グラフ(2時間平均)
| 最大値 受信: | 2933.1 kb/秒 (29.3%) | 平均値 受信: | 780.7 kb/秒 (7.8%) | 現在値 受信: | 631.1 kb/秒 (6.3%) | |
| 最大値 送信: | 750.0 kb/秒 (7.5%) | 平均値 送信: | 156.8 kb/秒 (1.6%) | 現在値 送信: | 122.6 kb/秒 (1.2%) |
年間グラフ(1日平均)
| 最大値 受信: | 981.4 kb/秒 (9.8%) | 平均値 受信: | 565.3 kb/秒 (5.7%) | 現在値 受信: | 827.9 kb/秒 (8.3%) | |
| 最大値 送信: | 562.6 kb/秒 (5.6%) | 平均値 送信: | 111.9 kb/秒 (1.1%) | 現在値 送信: | 154.2 kb/秒 (1.5%) |
| 緑 ### | 受信量(ビット/秒) | |
| 青 ### | 送信量(ビット/秒) |
Copyright © ITmedia, Inc. All Rights Reserved.