PR

 ここまで検討してきたインシデント・レスポンスの仕組みは,ごくベーシックなもので,無視し得ない脅威となりつつあるワームやウイルスへの対応が主な目的である。


 しかし,対応すべき現実的な脅威には,ほかに内部犯行がある。内部の人間は基本的に情報に触れる権利を与えられるので,悪意を持ってしまった場合にはインシデントになりやすく,防ぐことは非常に困難である。


 このために本連載の主テーマである「セキュリティ・ポリシー」が存在し,その下にルールや手順が存在するわけだ。


 しかし,前述したように「エンドユーザーは信用できない」。ということは,矛盾するようだがルールや手順は「守られないものである」という前提で,インシデントに対する仕組みを考えるべきだろう(これはもちろん,ポリシーが不要だとかいうことではない)。

記録装置が必要


 実はその面からも,ネットワーク構成上のポイントごとにファイアウォール・ブリッジを導入するという方法は有効なのだ。この場合はフィルタとしてではなく,記録装置としてである。


 ご承知のように,ファイアウォールは細かな通信記録を残すことができる。もちろんログをどこまでどれだけ残すのか,ということは常に課題となるテーマだが,内部犯行対策という側面から見れば,アクセプトする通信の記録が必要となる。


 とはいえ,ファイアウォールで許可した通信のログは膨大になるのが常識だ。しかし,区画ポイントごとに設置されたファイアウォールなら,全社のゲートウェイとなる位置に配備されたものよりははるかに少ないだろう。おまけに最近のハードディスクの大容量化と低価格化のおかげで,ハード的な容量はまず気にしなくてもよくなってきている。アクセプト・ログを取ることに,あまり躊躇しなくてもいいだろう。


 さらに言えば,IPアドレスは個人に紐付くように固定にしておきたいところだ。もちろんDHCPという仕組みの利点はある。どこにでも差し込めばすぐに使えるというのは,運用管理面から言えばメリットが大きい。DHCPを導入するのであれば,せめてMACアドレスと振り出しIPアドレスを紐付けて管理,もしくは記録すべきだろう。記録は個人に紐付いていなければあまり意味がない。


 その点,DHCPの場合はMACアドレスを詐称されると厄介で,やはりファイアウォールやフィルタを経由させるなど,別途紐付ける手段を併用すべきかもしれない。


 通信の記録をすべて採取していることは公表すればいいだろう。抑止効果が期待できるからだ。通信のログがすべて機械的に採取されている場合,何らかの情報を盗み出そうとするならば,それをごまかすか(しかしごまかすのは非常に困難),物理的に目標となるコンピュータに接触しなければならなくなる。


 となれば,あとは重要なコンピュータに物理的に接触しにくくし,あるいは物理的な接触についても記録し,ログイン管理を実施すればよい。すでに記録するインフラともいうべきベースができ上がっているので,その上に乗っかっているコンピュータの対策はインフラを考慮して実施すればよい。

園田 道夫 Michio Sonoda


筆者は情報処理推進機構(IPA)の脆弱性分析ラボ研究員,および日本ネットワークセキュリティ協会(JNSA)の研究員を務める。JNSAではハニーポットワーキンググループ,セキュリティスタジアム企画運営ワーキンググループのリーダーとして活動している。MicrosoftのSecurity MVP。現在セキュリティ夜話(http://www.asahi-net.or.jp/~vp5m-snd/sec/),極楽せきゅあ日記(http://d.hatena.ne.jp/sonodam/)にて連続的に読み物掲載中。