セキュリティシステムをマネジメントせよ：セキュリティ、そろそろ本音で語らないか（12）（1/3 ページ）
セキュリティマネジメントをシステム化することと、セキュリティシステムのマネジメントは似て非なるもの。その区別、できていますか？（編集部）
再度問います――ログ、なんのために取ってますか？
最近、「統合ログ」という言葉があちらこちらで聞かれるようになりました。ログをキーワードとしたセミナーなども各地で開催されており、多くのユーザーが参加しているようです。
ログへの注目は、内部統制が浸透したことが大きく影響しています。粉飾のない決算書の作成のためには各種のログが必要という認識で、上場企業を中心に多くの企業でログが収集されるようになりました。ところが、「何のため」ということが抜け落ちたまま、「収集」だけが目的のログが集められるようになりました。
監査人や内部統制コンサルタントによっても、ログの必要性がことさらに強調されてきたようです。データベースやネットワーク機器、セキュリティ機器、PCの操作ログに至るまで、あらゆるログの収集を推進してきたのです。このこと自体は「何か起こったときのために」必要ではあるのですが、なんとなく集めたログは、果たしていざというときに役に立つのでしょうか。
なぜログが役に立たないのか
私がこれまでに見てきた現場では、残念ながら役に立つログが収集されているケースはほとんどありませんでした。その多くは、監査を無事にやり過ごすためにログを取っている状況です。多くの内部統制コンサルタントでさえも「役に立つログ」という観点ではなく、内部統制構築という漠然とした目標に向かって、漠然とログを集めるようにアドバイスを行っています。
ここでの「役に立つログ」とは、以下の情報セキュリティ要件を満たすものです。
- セキュリティ事案に関する予兆の発見に有効なこと
- セキュリティ事案の発生に速やかに気付くこと
- セキュリティ事案の具体的事象や規模の把握が速やかに行えること
- 犯人や関係者を特定しうること
ログを取るのであれば、これらの目的要件を満たすように設計すべきです。しかし、漠然とログを取るだけで上記が満たせるものと勘違いしているケースが多いようです。システム構築業者、コンサルタント、そしてユーザーも「ログがあるから安心」と思っています。
PCの操作ログやデータベースへのアクセスログがあれば、売上データの改ざんが行われた場合に、その痕跡を見つけることができるかもしれません。その場合、肝心なデータ――何のデータをどう書き換えて、その結果どのようにデータが改ざんされたのか――が記録されていないと意味がありません。これを具体的に知るためには、必要なデータ項目の定義と、それをどこでどのように取得するのかを設計しなければなりません。
「規模の把握」という難題
内部統制関連で取られているログは、情報漏えいという観点から見ると、取得の範囲が十分ではありません。
情報漏えい事件が起きた場合には、犯人特定よりも「規模の把握」の方が重要です。これまでに起きた情報漏えい事件でも、漏えいした個人情報の内容や件数が記者発表のたびに増え続けることが珍しくありませんでした。これは企業にとって、大きなイメージダウンとなります。
「規模の把握をせよ」というのは簡単ですが、実現は非常に困難です。データベースに個人情報が入っていたとすれば、通常のアクセス記録ではユーザー名と時刻くらいしか残されていません。もう少し踏み込んだログの場合でも、データベースへの要求のみが残されている程度です。これだけでも膨大な量になります。すべてのデータベースへのアクセスの記録となると、それだけで十分に大きなデータベースになってしまいます。
データベースへの要求が記録されているだけでは、漏えい件数の特定はできません。データベースは生きていますから、その時点でのデータベースの状態をスナップショットのように取っておくか、すべての要求と処理内容を記録しておき、そこから時間をさかのぼってその時点でのデータベースを再現しないと、正確な個人の情報までを知ることはできません。正確な個人特定までができないと、謝罪を個別に行うことができないことになりますから、結局は報道発表とともに「全員に金券を送付」などということになってしまうのです。
Copyright © ITmedia, Inc. All Rights Reserved.